Date: Wed, 19 Apr 2023 13:33:35 +0000
To: alicexbt <alicexbt@protonmail.com>
From: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <nA4t0JwOs8yCz3Io6CHunt4VEVKRcmjhYz8Lt-v0O0upC0NT4G7VGN6OcdJfp4pw2eqZEmipXxhLLgJ5PUqbF9k_r41MTtdc9OCZF6YdgRQ=@protonmail.com>
In-Reply-To: <BAQJaPAUBbUwqKc5cf1jnO5LYij-gRKMrWHtc_wog7QUUrjxPwzXnIoegql7xsPhpUJXpRdBMwxdmlBt75k8aRT1NJVGLuhH7ZwpWmW8PU8=@protonmail.com>
References: <uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=@protonmail.com>
 <BAQJaPAUBbUwqKc5cf1jnO5LYij-gRKMrWHtc_wog7QUUrjxPwzXnIoegql7xsPhpUJXpRdBMwxdmlBt75k8aRT1NJVGLuhH7ZwpWmW8PU8=@protonmail.com>
Feedback-ID: 27732268:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin Core maintainers and communication on
	merge decisions
Precedence: list

Hi alicexbt

> I don't think commentary is required for each pull request that gets merg=
ed with enough reviews, ACKs and no controversy.

The problem is defining what is "enough". "Enough" is determined by the qua=
lity of the review, the expertise of the reviewer(s), the complexity of the=
 pull request and most importantly what risks a merge of the pull request p=
oses. When there is zero communication on merge decisions (both merging and=
 not merging over a long period of time) it creates frustration and worse v=
acuums and soft fork activation chaos. It is a complete black box. The vast=
 majority of merge decisions are uncontroversial but it would still be nice=
 to have a comment saying something like:

"This pull request only has 2 ACKs but it is low risk, relatively simple an=
d is unlikely to be reviewed by anybody else in the near term"

"This pull request is a consensus change, extremely high risk and is unlike=
ly to be merged in the near term"

On the rare occasions when merge decisions are controversial communication =
becomes a lot more important. If some maintainers aren't responsive on IRC =
and refuse to discuss merge decisions what can we expect in future? We wake=
 up one day, a contentious consensus change has been merged with little rev=
iew in advance of a release window and the maintainer won't discuss why the=
y have merged it. This isn't a toy anymore, it is supporting hundreds of bi=
llions of dollars of value and could end up supporting a lot more. It is su=
rely completely unreasonable to let maintainers merge or not merge whatever=
 they like with no explanation and no willingness to discuss their merge de=
cisions.

> So I'll add that if you wish to have more decentralization in Bitcoin Cor=
e funding, you can start by creating a nonprofit, gathering donations, and =
funding somebody who works on Bitcoin Core."=20

As I responded on the pull request if any long term contributor from this a=
lternative nonprofit is blocked from being a maintainer and current maintai=
ners refuse to discuss merge decisions it is irrelevant. To contribute you =
need a maintainer to merge your pull request(s) and to spend your review ti=
me 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 opac=
ity on merge decisions for normal pull requests (e.g. code) we also now hav=
e opacity on decisions for the addition of new maintainers. I was always un=
der the impression that any long term contributor who demonstrated over tim=
e that they were sufficiently competent, qualified and able to contribute b=
oth through opening pull requests and reviewing other people's pull request=
s 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 impac=
ts Vasil's and others' commitment to the project but it impacts what pull r=
equests are ultimately reviewed and merged. What is the point of spending t=
ime opening or reviewing a pull request if the current maintainers won't lo=
ok at it or are unqualified to review it and hence won't merge it?

Gloria's advice effectively boils down to spend months setting up a non-pro=
fit, spend years becoming a long term contributor to the project and then y=
ou can have the honor of being blocked from becoming a maintainer and have =
your contributions stunted by the current maintainers with no recourse or a=
bility to discuss their merge decisions. So yeah thanks for repeating that =
advice but I'm sure most would rather pass and do something else.

Thanks
Michael

--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3


------- Original Message -------
On Wednesday, April 19th, 2023 at 13:24, alicexbt <alicexbt@protonmail.com>=
 wrote:


> Hi Michael,
>=20
> I was initially sad about the politics in Vasil's pull request, written a=
bout it and also tried to document the process. Still think he deserves to =
be a maintainer. Although I have some counter arguments:
>=20
> > Maintainers merge a pull request and provide no commentary on why they=
=E2=80=99ve merged it.
>=20
>=20
> I don't think commentary is required for each pull request that gets merg=
ed with enough reviews, ACKs and no controversy.
>=20
> > Maintainers leave a pull request with many ACKs and few (if any) NACKs =
for months and provide no commentary on why they haven't merged it
>=20
>=20
> This could be considered normal in pull requests that involve code change=
s.
>=20
> > The difference between say previous maintainers like Wladimir and some =
of the current maintainers is that previous maintainers were extremely resp=
onsive on IRC.
>=20
>=20
> Unfair to expect every human to behave the same or work similarly. Someti=
mes the unresponsiveness could be to avoid controversies and heated debates=
 that go off-topic.
>=20
> > One farcical recent example 0 was the pull request to add Vasil Dimov a=
s a maintainer where despite many ACKs from other maintainers and other lon=
g term contributors two maintainers (fanquake and Gloria) refused to discus=
s it on the pull request or on IRC. It took almost 5 months for Gloria to c=
omment on the pull request despite many requests from me on the PR and on I=
RC. I even requested that they attend the weekly Core Dev IRC meeting to di=
scuss it which they didn=E2=80=99t attend.
>=20
>=20
> - Maintainers should be free to avoid involvement in a pull request. As l=
ong as a subset of maintainers have an opinion on the pull request, things =
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 interpreted=
 as personal attacks, and Brink has been antagonized on Twitter each time m=
ultiple grantees have similar opinions about this. So I'll add that if you =
wish to have more decentralization in Bitcoin Core funding, you can start b=
y creating a nonprofit, gathering donations, and funding somebody who works=
 on Bitcoin Core." Last part of this comment also solves the problem shared=
 in other thread related to new bitcoin implementation. Brink needs some co=
mpetition and bitcoin core needs more reviewers.
> - I also agree with Andrew's comment: "frankly, I think opinions aren't b=
eing shared because of potential backlash from aggressive users such as you=
rself and bytes1440000"
>=20
> > Maintainers and long term contributors (if they commented at all) were =
gently enthusiastic (Concept ACKing etc) without ACKing that it was ready t=
o merge. A long term observer of the Core repo would have known that it was=
n=E2=80=99t ready to merge or ready to attempt to activate (especially give=
n it was a consensus change) but a casual observer would have only seen Con=
cept ACKs and ACKs with 3 stray NACKs. Many of these casual observers infla=
ted the numbers on the utxos.org site 4 signalling support for a soft fork =
activation attempt.
>=20
>=20
> - I don't see anything wrong with sharing honest opinion if someone agree=
s 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 BIP=
 119. Everyone is free to maintain such lists and I think you had also crea=
ted one as GitHub gist.
>=20
> > I will probably write about bitcoin-inquisition/default signet in a fut=
ure email as I do think the perception that it is =E2=80=9Cthe one and only=
=E2=80=9D staging ground for consensus changes is dangerous 6 if the mainta=
iner(s) on that project have the same inclinations as a subset of the Core =
maintainers.
>=20
>=20
> This perception (if exists) can be killed by creating a custom signet, ma=
intaining it differently, get more reviews, testing and share details with =
community regularly.
>=20
> /dev/fd0
> floppy disk guy
>=20
> 0: https://github.com/bitcoin/bitcoin/pull/25871#issuecomment-1381654564
> 1: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-01-12#883748
>=20
>=20
> Sent with Proton Mail secure email.
>=20
> ------- Original Message -------
> On Tuesday, April 18th, 2023 at 6:10 PM, Michael Folkson via bitcoin-dev =
bitcoin-dev@lists.linuxfoundation.org wrote:
>=20
>=20
>=20
> > Communication has been a challenge on Bitcoin Core for what I can tell =
the entire history of the project. Maintainers merge a pull request and pro=
vide no commentary on why they=E2=80=99ve merged it. Maintainers leave a pu=
ll request with many ACKs and few (if any) NACKs for months and provide no =
commentary on why they haven't merged it. I can only speculate on why and i=
t probably depends on the individual maintainer. Sometimes it will be poor =
communication skills, sometimes it will be a desire to avoid accountability=
, sometimes it will be fear of unreasonable and spiteful legal action if th=
ey mistakenly merge a pull request that ends up containing a bug. But searc=
h through the pull requests on Bitcoin Core and you will rarely see a ratio=
nale for a merge decision. The difference between say previous maintainers =
like Wladimir and some of the current maintainers is that previous maintain=
ers were extremely responsive on IRC. If you disagreed with a merge decisio=
n or thought it had been merged prematurely they would be happy to discuss =
it on IRC. In present times at least a subset of the current maintainers ar=
e not responsive on IRC and will refuse to discuss a merge decision. One fa=
rcical recent example 0 was the pull request to add Vasil Dimov as a mainta=
iner where despite many ACKs from other maintainers and other long term con=
tributors two maintainers (fanquake and Gloria) refused to discuss it on th=
e 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 w=
hich they didn=E2=80=99t attend.
> >=20
> > A pull request to add a maintainer isn=E2=80=99t a normal pull request.=
 Generally pull requests contain a lot more lines of code than a single lin=
e adding a trusted key. Not merging a pull request for a long period of tim=
e can be extremely frustrating for a pull request author especially when ma=
intainers and long term contributors don=E2=80=99t comment on the pull requ=
est and the pull request is stuck in =E2=80=9Crebase hell=E2=80=9D. Clearly=
 it is the lesser evil when compared to merging a harmful or bug ridden pul=
l request but poor non-existent communication is not the only way to preven=
t this. Indeed it creates as many problems as it solves.
> >=20
> > Another farcical recent(ish) example was the CTV pull request 1 that ul=
timately led to a contentious soft fork activation attempt that was called =
off at the last minute. If you look at the comments on the pull request the=
re 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 contr=
ibutors to Bitcoin Core. I have criticised Jeremy Rubin multiple times for =
continuing to pursue a soft fork activation attempt when it was clear it wa=
s contentious 3 but if you look at the pull request comments it certainly i=
sn=E2=80=99t clear it was. Maintainers and long term contributors (if they =
commented at all) were gently enthusiastic (Concept ACKing etc) without ACK=
ing that it was ready to merge. A long term observer of the Core repo would=
 have known that it wasn=E2=80=99t ready to merge or ready to attempt to ac=
tivate (especially given it was a consensus change) but a casual observer w=
ould have only seen Concept ACKs and ACKs with 3 stray NACKs. Many of these=
 casual observers inflated the numbers on the utxos.org site 4 signalling s=
upport for a soft fork activation attempt.
> >=20
> > I set out originally to write about the controls and processes around m=
erges on the default signet (bitcoin-inquisition 5) but it quickly became o=
bvious to me that if communication around Core merges/non-merges is this we=
ak you can hardly expect it to be any better on bitcoin-inquisition/default=
 signet where there is no real monetary value at stake. I will probably wri=
te about bitcoin-inquisition/default signet in a future email as I do think=
 the perception that it is =E2=80=9Cthe one and only=E2=80=9D staging groun=
d for consensus changes is dangerous 6 if the maintainer(s) on that project=
 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 i=
ndividual(s) specific and an adverse reaction to outright malicious actors =
external to any of these projects. I do not think any of the current mainta=
iners on Core or bitcoin-inquisition are outright malicious even if a subse=
t of them consistently frustrate me with their lack of transparency and acc=
ountability. But this issue isn't going away and I'm sure we'll hear more o=
n this from others in the coming months. To me it is a straight choice of t=
aking transparency and accountability much more seriously or failing that i=
nvesting more heavily (time and resources) in consensus compatible forks of=
 Core and treating Core like it is a proprietary "open source" project wher=
e 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