Michael Folkson [ARCHIVE] on Nostr: 📅 Original date posted:2023-04-19 🗒️ Summary of this message: Communication ...

📅 Original date posted:2023-04-19
🗒️ Summary of this message: Communication on merge decisions in Bitcoin Core is important to avoid frustration and chaos. Defining "enough" reviews and ACKs is crucial, especially for high-risk pull requests. Lack of communication can lead to controversial decisions and potential harm to the project's value. Creating a nonprofit to fund Bitcoin Core contributors is a solution, but it's irrelevant if current maintainers refuse to discuss merge decisions and block long-term contributors from becoming maintainers.
📝 Original message:Hi alicexbt

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

The problem is defining what is "enough". "Enough" is determined by the quality 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 poses. When there is zero communication on merge decisions (both merging and 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 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 and is unlikely to be reviewed by anybody else in the near term"

"This pull request is a consensus change, extremely high risk and is unlikely 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 review in advance of a release window and the maintainer won't discuss why they 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 whatever they like with no explanation and no willingness to discuss their merge decisions.

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

As I responded on the pull request if any long term contributor from this alternative nonprofit is blocked from being a maintainer and current maintainers 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 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 opacity on merge decisions for normal pull requests (e.g. code) we also now have opacity on decisions for the addition of new maintainers. I was always under the impression that any long term contributor who demonstrated over time that they were sufficiently competent, qualified and able to contribute both through opening pull requests and reviewing other people's pull requests 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 impacts 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?

Gloria's advice effectively boils down to spend months setting up a non-profit, 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 have your contributions stunted by the current maintainers with no recourse or ability 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 at protonmail.com> wrote:


> Hi Michael,
>
> 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 to be a maintainer. Although I have some counter arguments:
>
> > Maintainers merge a pull request and provide no commentary on why they’ve merged it.
>
>
> I don't think commentary is required for each pull request that gets merged with enough reviews, ACKs and no controversy.
>
> > 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
>
>
> This could be considered normal in pull requests that involve code changes.
>
> > The difference between say previous maintainers like Wladimir and some of the current maintainers is that previous maintainers were extremely responsive on IRC.
>
>
> Unfair to expect every human to behave the same or work similarly. Sometimes the unresponsiveness could be to avoid controversies and heated debates that go off-topic.
>
> > 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 long term contributors 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 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’t attend.
>
>
> - 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, 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 multiple 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 by 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 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 yourself and bytes1440000"
>
> > Maintainers and long term contributors (if they commented at all) were 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 wasn’t 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 these casual observers inflated the numbers on the utxos.org site 4 signalling support for a soft fork activation attempt.
>
>
> - I don't see anything wrong with sharing honest opinion if someone agrees 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 created one as GitHub gist.
>
> > I will probably write about bitcoin-inquisition/default signet in a future email as I do think the perception that it is “the one and only” staging ground for consensus changes is dangerous 6 if the maintainer(s) on that project have the same inclinations as a subset of the Core maintainers.
>
>
> This perception (if exists) can be killed by creating a custom signet, maintaining it differently, get more reviews, testing and share details with community regularly.
>
> /dev/fd0
> floppy disk guy
>
> 0: https://github.com/bitcoin/bitcoin/pull/25871#issuecomment-1381654564
> 1: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-01-12#883748
>
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Tuesday, April 18th, 2023 at 6:10 PM, Michael Folkson via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>
>
>
> > 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 provide no commentary on why they’ve merged it. 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. I can only speculate on why and it 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 they mistakenly merge a pull request that ends up containing a bug. But search through the pull requests on Bitcoin Core and you will rarely see a rationale for a merge decision. The difference between say previous maintainers like Wladimir and some of the current maintainers is that previous maintainers were extremely responsive on IRC. If you disagreed with a merge decision 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 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 maintainer where despite many ACKs from other maintainers and other long term contributors 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 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’t attend.
> >
> > A pull request to add a maintainer isn’t a normal pull request. Generally pull requests contain a lot more lines of code than a single line adding a trusted key. Not merging a pull request for a long period of time can be extremely frustrating for a pull request author especially when maintainers and long term contributors don’t comment on the pull request and the pull request is stuck in “rebase hell”. Clearly it is the lesser evil when compared to merging a harmful or bug ridden pull request but poor non-existent communication is not the only way to prevent this. Indeed it creates as many problems as it solves.
> >
> > Another farcical recent(ish) example was the CTV pull request 1 that ultimately 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 there 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 contributors to Bitcoin Core. I have criticised Jeremy Rubin multiple times for 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’t clear it was. Maintainers and long term contributors (if they commented at all) were 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 wasn’t 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 these casual observers inflated the numbers on the utxos.org site 4 signalling support for a soft fork activation attempt.
> >
> > 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/default signet where there is no real monetary value at stake. I will probably write about bitcoin-inquisition/default signet in a future email as I do think the perception that it is “the one and only” staging ground for consensus changes is dangerous 6 if the maintainer(s) on that project have the same inclinations as a subset of the Core maintainers.
> >
> > 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 actors external to any of these projects. I do not think any of the current maintainers on Core or bitcoin-inquisition are outright malicious even if a subset of them consistently frustrate me with their lack of transparency and accountability. 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 where merge decisions are not explained or justified in the open.
> >
> > --
> > Michael Folkson
> > Email: michaelfolkson at protonmail.com
> > Keybase: michaelfolkson
> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3