path: root/b5/393a3c2d9dfba10fc5c1dce1248551a86fc97b

Return-Path: <alicexbt@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 18D0AC002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Apr 2023 21:13:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id E0F8F60B5C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Apr 2023 21:13:39 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E0F8F60B5C
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=Wp0bOHKb
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id tvO1G-RoEK76
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Apr 2023 21:13:38 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org AA81E60073
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
 [185.70.40.130])
 by smtp3.osuosl.org (Postfix) with ESMTPS id AA81E60073
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Apr 2023 21:13:37 +0000 (UTC)
Date: Wed, 19 Apr 2023 21:13:23 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1681938814; x=1682198014;
 bh=wqNsH1VKKM/pKPN3r7gTfBX0oORlhYjv/jwUMgzaUlE=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector;
 b=Wp0bOHKba0FuOX3MkhwTOJvjyjWNYIc/yXR2wU86hbL4Y44pkk7tBotVpoU2X3lz8
 rcDCmg2N5YwczTijDsc2t/3W+1+lfopnsVj9xtaXv7TVcwrkyz+NdeGdrsb7gMmWhT
 WZrTf+Og6jGU5kE9YKLye3QFfPqkAQx+f+SU9Yj9qU2CUtApqZouu4T6ZnsMAhOLuY
 qDu18MHl7O2vu3drvv8M5ZerCRByWAr0EpeJkLyJaVL8xbbg7BX3+4C/rfR4X9vJJV
 30nux3lFR0GAHQtw5tjjWIfO1QBnnDvaKBrwSmhAIOMtJ+gD/+TiQam3SYlSwWi0/d
 6rdfHDBwrPg5g==
To: Michael Folkson <michaelfolkson@protonmail.com>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <ZNeHbwF5IGr6p142QqLON7L2Qvt2H0fLHr-nczawVUTQMtHXTtNRWspC-9Lsp6xtjuNC5ZewHD7xaMJnzsYVRUWSMQRjaxBknfsy3-jGsPQ=@protonmail.com>
In-Reply-To: <nA4t0JwOs8yCz3Io6CHunt4VEVKRcmjhYz8Lt-v0O0upC0NT4G7VGN6OcdJfp4pw2eqZEmipXxhLLgJ5PUqbF9k_r41MTtdc9OCZF6YdgRQ=@protonmail.com>
References: <uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=@protonmail.com>
 <BAQJaPAUBbUwqKc5cf1jnO5LYij-gRKMrWHtc_wog7QUUrjxPwzXnIoegql7xsPhpUJXpRdBMwxdmlBt75k8aRT1NJVGLuhH7ZwpWmW8PU8=@protonmail.com>
 <nA4t0JwOs8yCz3Io6CHunt4VEVKRcmjhYz8Lt-v0O0upC0NT4G7VGN6OcdJfp4pw2eqZEmipXxhLLgJ5PUqbF9k_r41MTtdc9OCZF6YdgRQ=@protonmail.com>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 20 Apr 2023 00:44:37 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin Core maintainers and communication on
	merge decisions
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Apr 2023 21:13:40 -0000

Hi Michael,

I will share something even though you didn't let me write things on severa=
l occasions on github, twitter etc.

Try this:

- As Gloria said (respect people you don't like and shared something agains=
t), create a competition for Brink. Fund bitcoin developers.
- Do more reviews personally and devs you train even if they are neglected.
- Acknowledge some reviewer know more than you. Try to learn and test thing=
s.
- After some time you will achieve the power you crave.

Its not possible to satisfy everyone even if you were bitcoin core maintain=
er now, some people would have issues. Closing a pull request hurt more so =
I respect them if they kept open something.

Note: Do not disrespect people who are new and say something. Do not try to=
 harass them. Do not try to be boss.

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, April 19th, 2023 at 7:03 PM, Michael Folkson <michaelfolkson@=
protonmail.com> wrote:


> Hi alicexbt
>=20
> > I don't think commentary is required for each pull request that gets me=
rged with enough reviews, ACKs and no controversy.
>=20
>=20
> The problem is defining what is "enough". "Enough" is determined by the q=
uality of the review, the expertise of the reviewer(s), the complexity of t=
he pull request and most importantly what risks a merge of the pull request=
 poses. When there is zero communication on merge decisions (both merging a=
nd not merging over a long period of time) it creates frustration and worse=
 vacuums and soft fork activation chaos. It is a complete black box. The va=
st majority of merge decisions are uncontroversial but it would still be ni=
ce to have a comment saying something like:
>=20
> "This pull request only has 2 ACKs but it is low risk, relatively simple =
and is unlikely to be reviewed by anybody else in the near term"
>=20
> "This pull request is a consensus change, extremely high risk and is unli=
kely to be merged in the near term"
>=20
> On the rare occasions when merge decisions are controversial communicatio=
n becomes a lot more important. If some maintainers aren't responsive on IR=
C and refuse to discuss merge decisions what can we expect in future? We wa=
ke up one day, a contentious consensus change has been merged with little r=
eview in advance of a release window and the maintainer won't discuss why t=
hey have merged it. This isn't a toy anymore, it is supporting hundreds of =
billions of dollars of value and could end up supporting a lot more. It is =
surely completely unreasonable to let maintainers merge or not merge whatev=
er they like with no explanation and no willingness to discuss their merge =
decisions.
>=20
> > So I'll add that if you wish to have more decentralization in Bitcoin C=
ore funding, you can start by creating a nonprofit, gathering donations, an=
d funding somebody who works on Bitcoin Core."
>=20
>=20
> As I responded on the pull request if any long term contributor from this=
 alternative nonprofit is blocked from being a maintainer and current maint=
ainers refuse to discuss merge decisions it is irrelevant. To contribute yo=
u need a maintainer to merge your pull request(s) and to spend your review =
time wisely you need to know what pull request(s) could viably be merged by=
 a maintainer. Otherwise you're just wasting your time. We not only have op=
acity on merge decisions for normal pull requests (e.g. code) we also now h=
ave opacity on decisions for the addition of new maintainers. I was always =
under the impression that any long term contributor who demonstrated over t=
ime that they were sufficiently competent, qualified and able to contribute=
 both through opening pull requests and reviewing other people's pull reque=
sts could become a maintainer. To me and many others (until it was blocked =
by two maintainers for 5 months) Vasil met this criteria. This not only imp=
acts Vasil's and others' commitment to the project but it impacts what pull=
 requests are ultimately reviewed and merged. What is the point of spending=
 time opening or reviewing a pull request if the current maintainers won't =
look at it or are unqualified to review it and hence won't merge it?
>=20
> Gloria's advice effectively boils down to spend months setting up a non-p=
rofit, spend years becoming a long term contributor to the project and then=
 you can have the honor of being blocked from becoming a maintainer and hav=
e your contributions stunted by the current maintainers with no recourse or=
 ability to discuss their merge decisions. So yeah thanks for repeating tha=
t advice but I'm sure most would rather pass and do something else.
>=20
> Thanks
> Michael
>=20
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>=20
>=20
> ------- Original Message -------
> On Wednesday, April 19th, 2023 at 13:24, alicexbt alicexbt@protonmail.com=
 wrote:
>=20
>=20
>=20
> > Hi Michael,
> >=20
> > I was initially sad about the politics in Vasil's pull request, written=
 about it and also tried to document the process. Still think he deserves t=
o be a maintainer. Although I have some counter arguments:
> >=20
> > > Maintainers merge a pull request and provide no commentary on why the=
y=E2=80=99ve merged it.
> >=20
> > I don't think commentary is required for each pull request that gets me=
rged with enough reviews, ACKs and no controversy.
> >=20
> > > Maintainers leave a pull request with many ACKs and few (if any) NACK=
s for months and provide no commentary on why they haven't merged it
> >=20
> > This could be considered normal in pull requests that involve code chan=
ges.
> >=20
> > > The difference between say previous maintainers like Wladimir and som=
e of the current maintainers is that previous maintainers were extremely re=
sponsive on IRC.
> >=20
> > Unfair to expect every human to behave the same or work similarly. Some=
times the unresponsiveness could be to avoid controversies and heated debat=
es that go off-topic.
> >=20
> > > One farcical recent example 0 was the pull request to add Vasil Dimov=
 as a maintainer where despite many ACKs from other maintainers and other l=
ong term contributors two maintainers (fanquake and Gloria) refused to disc=
uss it on the pull request or on IRC. It took almost 5 months for Gloria to=
 comment on the pull request despite many requests from me on the PR and on=
 IRC. I even requested that they attend the weekly Core Dev IRC meeting to =
discuss it which they didn=E2=80=99t attend.
> >=20
> > - Maintainers should be free to avoid involvement in a pull request. As=
 long as a subset of maintainers have an opinion on the pull request, thing=
s should be fine.
> > - I agree with Gloria's comment: "I had not NACKed this either because =
my opinion could change over time, NACKs are sometimes needlessly interpret=
ed as personal attacks, and Brink has been antagonized on Twitter each time=
 multiple grantees have similar opinions about this. So I'll add that if yo=
u wish to have more decentralization in Bitcoin Core funding, you can start=
 by creating a nonprofit, gathering donations, and funding somebody who wor=
ks on Bitcoin Core." Last part of this comment also solves the problem shar=
ed in other thread related to new bitcoin implementation. Brink needs some =
competition and bitcoin core needs more reviewers.
> > - I also agree with Andrew's comment: "frankly, I think opinions aren't=
 being shared because of potential backlash from aggressive users such as y=
ourself and bytes1440000"
> >=20
> > > Maintainers and long term contributors (if they commented at all) wer=
e gently enthusiastic (Concept ACKing etc) without ACKing that it was ready=
 to merge. A long term observer of the Core repo would have known that it w=
asn=E2=80=99t ready to merge or ready to attempt to activate (especially gi=
ven it was a consensus change) but a casual observer would have only seen C=
oncept ACKs and ACKs with 3 stray NACKs. Many of these casual observers inf=
lated the numbers on the utxos.org site 4 signalling support for a soft for=
k activation attempt.
> >=20
> > - I don't see anything wrong with sharing honest opinion if someone agr=
ees with the concept. It does not make a pull request ready to get merged.
> > - utxos.org is an external site maintained by Jeremy with opinions on B=
IP 119. Everyone is free to maintain such lists and I think you had also cr=
eated one as GitHub gist.
> >=20
> > > I will probably write about bitcoin-inquisition/default signet in a f=
uture email as I do think the perception that it is =E2=80=9Cthe one and on=
ly=E2=80=9D staging ground for consensus changes is dangerous 6 if the main=
tainer(s) on that project have the same inclinations as a subset of the Cor=
e maintainers.
> >=20
> > This perception (if exists) can be killed by creating a custom signet, =
maintaining it differently, get more reviews, testing and share details wit=
h community regularly.
> >=20
> > /dev/fd0
> > floppy disk guy
> >=20
> > 0: https://github.com/bitcoin/bitcoin/pull/25871#issuecomment-138165456=
4
> > 1: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-01-12#883748
> >=20
> > Sent with Proton Mail secure email.
> >=20
> > ------- Original Message -------
> > On Tuesday, April 18th, 2023 at 6:10 PM, Michael Folkson via bitcoin-de=
v bitcoin-dev@lists.linuxfoundation.org wrote:
> >=20
> > > Communication has been a challenge on Bitcoin Core for what I can tel=
l the entire history of the project. Maintainers merge a pull request and p=
rovide no commentary on why they=E2=80=99ve merged it. Maintainers leave a =
pull request with many ACKs and few (if any) NACKs for months and provide n=
o commentary on why they haven't merged it. I can only speculate on why and=
 it probably depends on the individual maintainer. Sometimes it will be poo=
r communication skills, sometimes it will be a desire to avoid accountabili=
ty, sometimes it will be fear of unreasonable and spiteful legal action if =
they mistakenly merge a pull request that ends up containing a bug. But sea=
rch through the pull requests on Bitcoin Core and you will rarely see a rat=
ionale for a merge decision. The difference between say previous maintainer=
s like Wladimir and some of the current maintainers is that previous mainta=
iners were extremely responsive on IRC. If you disagreed with a merge decis=
ion or thought it had been merged prematurely they would be happy to discus=
s it on IRC. In present times at least a subset of the current maintainers =
are not responsive on IRC and will refuse to discuss a merge decision. One =
farcical recent example 0 was the pull request to add Vasil Dimov as a main=
tainer where despite many ACKs from other maintainers and other long term c=
ontributors two maintainers (fanquake and Gloria) refused to discuss it on =
the pull request or on IRC. It took almost 5 months for Gloria to comment o=
n the pull request despite many requests from me on the PR and on IRC. I ev=
en requested that they attend the weekly Core Dev IRC meeting to discuss it=
 which they didn=E2=80=99t attend.
> > >=20
> > > A pull request to add a maintainer isn=E2=80=99t a normal pull reques=
t. Generally pull requests contain a lot more lines of code than a single l=
ine adding a trusted key. Not merging a pull request for a long period of t=
ime can be extremely frustrating for a pull request author especially when =
maintainers and long term contributors don=E2=80=99t comment on the pull re=
quest and the pull request is stuck in =E2=80=9Crebase hell=E2=80=9D. Clear=
ly it is the lesser evil when compared to merging a harmful or bug ridden p=
ull request but poor non-existent communication is not the only way to prev=
ent this. Indeed it creates as many problems as it solves.
> > >=20
> > > Another farcical recent(ish) example was the CTV pull request 1 that =
ultimately led to a contentious soft fork activation attempt that was calle=
d off at the last minute. If you look at the comments on the pull request t=
here were 3 individuals (including myself) who NACKed the pull request and =
I think it is fair to say that none of us would be considered long term con=
tributors to Bitcoin Core. I have criticised Jeremy Rubin multiple times fo=
r continuing to pursue a soft fork activation attempt when it was clear it =
was contentious 3 but if you look at the pull request comments it certainly=
 isn=E2=80=99t clear it was. Maintainers and long term contributors (if the=
y commented at all) were gently enthusiastic (Concept ACKing etc) without A=
CKing that it was ready to merge. A long term observer of the Core repo wou=
ld have known that it wasn=E2=80=99t ready to merge or ready to attempt to =
activate (especially given it was a consensus change) but a casual observer=
 would have only seen Concept ACKs and ACKs with 3 stray NACKs. Many of the=
se casual observers inflated the numbers on the utxos.org site 4 signalling=
 support for a soft fork activation attempt.
> > >=20
> > > I set out originally to write about the controls and processes around=
 merges on the default signet (bitcoin-inquisition 5) but it quickly became=
 obvious to me that if communication around Core merges/non-merges is this =
weak you can hardly expect it to be any better on bitcoin-inquisition/defau=
lt signet where there is no real monetary value at stake. I will probably w=
rite about bitcoin-inquisition/default signet in a future email as I do thi=
nk the perception that it is =E2=80=9Cthe one and only=E2=80=9D staging gro=
und for consensus changes is dangerous 6 if the maintainer(s) on that proje=
ct have the same inclinations as a subset of the Core maintainers.
> > >=20
> > > As I stated at the beginning there is an element to this which is not=
 individual(s) specific and an adverse reaction to outright malicious actor=
s external to any of these projects. I do not think any of the current main=
tainers on Core or bitcoin-inquisition are outright malicious even if a sub=
set of them consistently frustrate me with their lack of transparency and a=
ccountability. But this issue isn't going away and I'm sure we'll hear more=
 on this from others in the coming months. To me it is a straight choice of=
 taking transparency and accountability much more seriously or failing that=
 investing more heavily (time and resources) in consensus compatible forks =
of Core and treating Core like it is a proprietary "open source" project wh=
ere merge decisions are not explained or justified in the open.
> > >=20
> > > --
> > > Michael Folkson
> > > Email: michaelfolkson at protonmail.com
> > > Keybase: michaelfolkson
> > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3