* [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
@ 2023-04-18 12:40 Michael Folkson
2023-04-19 0:56 ` Erik Aronesty
` (5 more replies)
0 siblings, 6 replies; 28+ messages in thread
From: Michael Folkson @ 2023-04-18 12:40 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5563 bytes --]
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.
[0]: https://github.com/bitcoin/bitcoin/pull/25871
[1]: https://github.com/bitcoin/bitcoin/pull/21702
[2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html
[3]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
[4]: https://utxos.org/signals/
[5]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
[6]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020948.html
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
[-- Attachment #2: Type: text/html, Size: 8480 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-04-18 12:40 [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions Michael Folkson
@ 2023-04-19 0:56 ` Erik Aronesty
2023-04-19 10:09 ` Michael Folkson
2023-04-19 12:24 ` alicexbt
` (4 subsequent siblings)
5 siblings, 1 reply; 28+ messages in thread
From: Erik Aronesty @ 2023-04-19 0:56 UTC (permalink / raw)
To: Michael Folkson, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 6483 bytes --]
yes, the code itself was far less contentious than the weird stab at
forking the network
there remains a real chance that bip 119 is the simplest and most flexible
and reasonably safe covenant tech for many use cases
although im partial to 118 as well because lightning is a killer app and it
makes batch channels more efficient
On Tue, Apr 18, 2023, 7:39 PM Michael Folkson via bitcoin-dev <
bitcoin-dev@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.
>
>
> [0]: https://github.com/bitcoin/bitcoin/pull/25871
>
> [1]: https://github.com/bitcoin/bitcoin/pull/21702
>
> [2]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html
>
> [3]:
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> [4]: https://utxos.org/signals/
>
> [5]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
>
> [6]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020948.html
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 10408 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-04-19 0:56 ` Erik Aronesty
@ 2023-04-19 10:09 ` Michael Folkson
0 siblings, 0 replies; 28+ messages in thread
From: Michael Folkson @ 2023-04-19 10:09 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 8397 bytes --]
Hi Erik
> yes, the code itself was far less contentious than the weird stab at forking the network
>
> there remains a real chance that bip 119 is the simplest and most flexible and reasonably safe covenant tech for many use cases
>
> although im partial to 118 as well because lightning is a killer app and it makes batch channels more efficient
This is moving off the intended subject of the email although latest thoughts on BIP 118 and BIP 119 are an interesting separate topic. Perhaps start a new thread? The latest afaik is that both have been merged in bitcoin-inquisition [0] (default signet) and James O'Beirne concluded that he needed BIP 119/OP_CTV for his latest vault design that includes a new proposed opcode OP_VAULT (BIP 345) [1]. Designing and building vaults with the various proposed opcodes and sighash flags (and Simplicity when it is ready) is definitely what I hoped to see after the chaos of the attempted CTV activation. Hopefully more people will be drawn into this research and development area, I think it is a really interesting one [2] so I'm a bit bemused more people aren't following James and the Revault team and doing their own research and experimentation. I think darosior's (Revault) current view [3] is BIP 118/APO is sufficient for the vaults he wants to build. But yeah needs more informed views and you only really get a more informed view by trying to design and build things and realizing what you need or what is missing. It isn't convincing to embark on a soft fork activation process just because a couple of informed individuals want it.
Thanks
Michael
[0]: https://github.com/bitcoin-inquisition/bitcoin
[1]: https://github.com/bitcoin/bips/pull/1421
[2]: https://www.youtube.com/watch?v=S2lTfS5qMJE
[3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020276.html
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Wednesday, April 19th, 2023 at 01:56, Erik Aronesty <erik@q32•com> wrote:
> yes, the code itself was far less contentious than the weird stab at forking the network
>
> there remains a real chance that bip 119 is the simplest and most flexible and reasonably safe covenant tech for many use cases
>
> although im partial to 118 as well because lightning is a killer app and it makes batch channels more efficient
>
> On Tue, Apr 18, 2023, 7:39 PM Michael Folkson via bitcoin-dev <bitcoin-dev@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.
>>
>> [0]: https://github.com/bitcoin/bitcoin/pull/25871
>>
>> [1]: https://github.com/bitcoin/bitcoin/pull/21702
>>
>> [2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html
>>
>> [3]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>>
>> [4]: https://utxos.org/signals/
>>
>> [5]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
>>
>> [6]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020948.html
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 16908 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-04-18 12:40 [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions Michael Folkson
2023-04-19 0:56 ` Erik Aronesty
@ 2023-04-19 12:24 ` alicexbt
2023-04-19 13:33 ` Michael Folkson
2023-04-19 15:17 ` Aymeric Vitte
` (3 subsequent siblings)
5 siblings, 1 reply; 28+ messages in thread
From: alicexbt @ 2023-04-19 12:24 UTC (permalink / raw)
To: Michael Folkson; +Cc: Bitcoin Protocol Discussion
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][0]: "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][1]: "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@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.
>
>
>
> [0]: https://github.com/bitcoin/bitcoin/pull/25871
>
> [1]: https://github.com/bitcoin/bitcoin/pull/21702
>
> [2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html
>
> [3]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> [4]: https://utxos.org/signals/
>
> [5]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
>
> [6]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020948.html
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-04-19 12:24 ` alicexbt
@ 2023-04-19 13:33 ` Michael Folkson
2023-04-19 21:13 ` alicexbt
0 siblings, 1 reply; 28+ messages in thread
From: Michael Folkson @ 2023-04-19 13:33 UTC (permalink / raw)
To: alicexbt; +Cc: Bitcoin Protocol Discussion
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@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@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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-04-18 12:40 [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions Michael Folkson
2023-04-19 0:56 ` Erik Aronesty
2023-04-19 12:24 ` alicexbt
@ 2023-04-19 15:17 ` Aymeric Vitte
2023-04-19 21:33 ` Andrew Chow
` (2 subsequent siblings)
5 siblings, 0 replies; 28+ messages in thread
From: Aymeric Vitte @ 2023-04-19 15:17 UTC (permalink / raw)
To: Michael Folkson, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 7610 bytes --]
The different emails are overlong, it's difficult to follow
It is super surprising to see that Bitcoin has only 4 maintainers funded
by Brink and Blockstream, but I think the decisions are taken elsewhere
And I think the job of the maintainers is not only to be maintainers but
to do the PR sometimes, since the process is too complicate and they are
supposed to know well the code
And it seems like bitcoin is betting its future on lightning and/or
super clever (non understandble) changes to bitcoin scripting
While some simple changes can allow bitcoin to surpass ethereum, as
usual, like "Allow several OP_RETURN in one tx and no limited size"
https://github.com/bitcoin/bitcoin/issues/27043
How long it will take remains mysterious
Le 18/04/2023 à 14:40, Michael Folkson via bitcoin-dev a écrit :
>
> 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.
>
>
> [0]: https://github.com/bitcoin/bitcoin/pull/25871
>
> [1]: https://github.com/bitcoin/bitcoin/pull/21702
>
> [2]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html
>
> [3]:
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> [4]: https://utxos.org/signals/
>
> [5]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
>
> [6]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020948.html
>
> -- Michael Folkson Email: michaelfolkson at protonmail.com
> <http://protonmail.com/>
> Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159
> 214C FEE3
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
[-- Attachment #2: Type: text/html, Size: 14028 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-04-19 13:33 ` Michael Folkson
@ 2023-04-19 21:13 ` alicexbt
0 siblings, 0 replies; 28+ messages in thread
From: alicexbt @ 2023-04-19 21:13 UTC (permalink / raw)
To: Michael Folkson; +Cc: Bitcoin Protocol Discussion
Hi Michael,
I will share something even though you didn't let me write things on several occasions on github, twitter etc.
Try this:
- As Gloria said (respect people you don't like and shared something against), 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 things.
- After some time you will achieve the power you crave.
Its not possible to satisfy everyone even if you were bitcoin core maintainer 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
>
> > 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@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@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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-04-18 12:40 [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions Michael Folkson
` (2 preceding siblings ...)
2023-04-19 15:17 ` Aymeric Vitte
@ 2023-04-19 21:33 ` Andrew Chow
2023-04-20 8:45 ` Michael Folkson
2023-04-20 10:54 ` Aymeric Vitte
2023-04-20 2:27 ` Anthony Towns
2023-05-07 7:03 ` Michael Folkson
5 siblings, 2 replies; 28+ messages in thread
From: Andrew Chow @ 2023-04-19 21:33 UTC (permalink / raw)
To: bitcoin-dev
Responses in-line.
Note that the opinions expressed in this email are my own and are not
representative of what other maintainers think or believe.
On 04/18/2023 08:40 AM, Michael Folkson via bitcoin-dev 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.
What commentary does there need to be?
It's self evident that the maintainer believes the code is ready to be
merged, and has observed enough ACKs from contributors that they are
comfortable to do so.
You're welcome to ask for clarification, but frankly, I don't think
having any commentary on merges is going to be helpful or more elaborate
in any way.
Requiring maintainers to have to write explanations for every single
merge is simply going to increase the burden on them and increase the
rate of burnout and resignations.
We've had too many maintainers step down already.
It'll end up being a bunch of boilerplate comments that don't say
anything meaningful.
There are certainly situations where PRs are merged very quickly or with
otherwise little apparent review.
But, as I said, if you ask a maintainer why it was merged, the answer
will be "I thought it was ready and had enough review".
There may be other reasons that made the maintainer think it was ready
sooner, such as the PR fixes a critical bug or security vulnerability,
but these reasons aren't going to be stated publicly.
> 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.
There are currently 320 open PRs and 366 open issues.
I wake up every morning to 150+ email notifications containing
everything that went on overnight, and throughout the day, I typically
get hundreds more.
It's impossible to keep up with everything that goes on throughout the repo.
ACKs come in sporadically, PRs are updated, reviews are posted, etc.
Often times PRs are not merged simply because the maintainers were not
aware that a PR was ready to be merged.
Things can simply fall through the cracks.
Of course there are other reasons why something might not be merged, and
these generally fall into the camp of "I don't think it has had enough
review".
It's the maintainer's judgement call to make as to whether something has
been sufficiently reviewed, and part of the judgement call is to
consider the quality and competence of the reviewers.
If a PR had 100 ACKs but all from random people who have never
contributed to the project in any capacity, then it's not going to be
merged because those reviewers would be considered low quality.
It's not just about the numbers, but also about whether the reviewers
are people the maintainers think are familiar enough with an area and
have had a history of thoroughly reviewing PRs.
For example, if a reviewer who primarily works on the mempool reviewed a
PR in the wallet, I would consider their review and ACK with less weight
because they are unlikely to be familiar with the intricacies of the wallet.
Obviously that changes over time as they make more reviews.
For another example, if I see an ACK from a reviewer who posts reviews
that primarily contain nits on code style and other trivialities, I
would consider that ACK with less weight.
Furthermore, the maintainers are not necessarily the ones who block a merge.
Part of evaluating if something is ready to be merged is to read the
comments on a PR.
Other frequent contributors may have commented or asked questions that
haven't been resolved yet.
PRs will often not be merged (even if they have ACKs) until a maintainer
deems that those comments and questions have been sufficiently resolved,
typically with the commenter stating in some way that their concerns
were addressed.
In these situations, no commentary from maintainers is given nor
necessary as it should be self evident (by reading the comments) that
something is controversial.
These kinds of comments are not explicit NACKs (so someone who is only
counting (N)ACKs won't see them), but are blocking nonetheless.
Lastly, personally I like to review every PR before I merge it.
This often means that a PR that might otherwise be ready to be merged
wouldn't be merged by myself as I may not be familiar with that part of
the codebase.
It may also mean that I would require more or specific additional people
to review a PR before I merge it as I would weight my own review less
heavily.
With several long time maintainers stepping away, this may be a factor
in PRs taking longer to get merged as the remaining maintainers may be
less familiar with the parts of the codebase that were previously
maintained by someone else.
> 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.
Anyone who thinks that maintainers only look at the numbers of (N)ACKs
is delusional.
As I explained above, there is a whole lot more nuance to determining
even just the status of the opinions on a PR, nevermind the code itself.
In this specific example of a soft fork, there is also consideration of
the opinions outside of the repo itself, such as on this mailing list
and elsewhere that people discuss soft forks.
On 04/19/2023 11:17 AM, Aymeric Vitte via bitcoin-dev wrote:
> While some simple changes can allow bitcoin to surpass ethereum, as
usual, like "Allow several OP_RETURN in one tx and no limited size"
https://github.com/bitcoin/bitcoin/issues/27043
>
> How long it will take remains mysterious
No one (maintainers or contributors) is obligated to implement anything.
A feature request not being implemented is because the people who do
open PRs are either not interested in implementing the feature, or are
working on other things that they believe to be higher priority.
If there is a feature that you want, then you will often need to either
to it yourself, or pay someone to do it for you.
Additionally, a feature may seem like a good idea to you, but there are
often interactions with other things that may end up resulting in it
being rejected or need significant revision, especially for something
which affects transaction relay.
Andrew Chow
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-04-18 12:40 [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions Michael Folkson
` (3 preceding siblings ...)
2023-04-19 21:33 ` Andrew Chow
@ 2023-04-20 2:27 ` Anthony Towns
2023-04-20 9:24 ` Michael Folkson
2023-05-07 7:03 ` Michael Folkson
5 siblings, 1 reply; 28+ messages in thread
From: Anthony Towns @ 2023-04-20 2:27 UTC (permalink / raw)
To: Michael Folkson, Bitcoin Protocol Discussion
On Tue, Apr 18, 2023 at 12:40:44PM +0000, Michael Folkson via bitcoin-dev wrote:
> I do think the perception that it is “the one and only” staging
> ground for consensus changes is dangerous
If you think that about any open source project, the answer is simple:
create your own fork and do a better job. Competition is the only answer
to concerns about the bad effects from a monopoly. (Often the good effects
from cooperation and collaboration -- less wasted time and duplicated
effort -- turn out to outweigh the bad effects, however)
In any event, inquisition isn't "the one and only staging ground for
consensus changes" -- every successful consensus change to date has
been staged through the developers' own repo then the core PR process,
and that option still exists.
Cheers,
aj
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-04-19 21:33 ` Andrew Chow
@ 2023-04-20 8:45 ` Michael Folkson
2023-04-20 10:54 ` Aymeric Vitte
1 sibling, 0 replies; 28+ messages in thread
From: Michael Folkson @ 2023-04-20 8:45 UTC (permalink / raw)
To: Andrew Chow, Bitcoin Protocol Discussion
Thanks for this Andrew.
> What commentary does there need to be?
There doesn't "need" to be explanations about anything. There doesn't "need" to be any review comments whatsoever from anybody. But a world where reviewers explain what they've done to satisfy themselves that a pull request is ready to merge and a world where maintainers explain their thought process behind a merge decision is much easier to follow and much more scalable than the current black box where people see pull requests being self merged by a maintainer with no ACKs within a day of it being opened. Most likely these decisions make sense (low risk, unlikely to be reviewed by anybody else, blocking other pull requests etc). But more and more people are funded to work on Core and increasingly they seem to stick to their own mini projects and not review anybody else's work. Of course you can't put the responsibility for this entirely down to maintainers but the black box isn't scalable. Maintainers (presumably) have private discussions and so know how best to spend their review time. Everyone else (especially new contributors) are playing an uninformed and in the dark lottery with how they spend their review time (to the extent that they allocate any).
> There are currently 320 open PRs and 366 open issues.
I wake up every morning to 150+ email notifications containing
everything that went on overnight, and throughout the day, I typically
get hundreds more.
Indeed. All the more reason for more and higher quality public communication. If you struggle and you're in those private discussions with other maintainers on merge decisions and ready for merge discussions how do you think everyone is trying to assess how to spend their time? It is even more bewildering. As far as I know most of the current maintainers haven't worked on other projects or in the private sector for a sustained period of time but the way other projects and businesses function is that those with the most experience and most responsibilities are able to manage and provide guidance to those with less experience and less responsibilities. I'm sure this goes on within Brink if you've been anointed but this is supposed to be an open source project. If everything is done in private conversations and everything other than the code is open source it is pretty much a façade. It is very hard to make meaningful contributions without getting anointed. Those who do get anointed very early in their careers seem especially bad at hoarding information, refusing to do anything in public and not assisting those who haven't been anointed.
> Things can simply fall through the cracks.
> With several long time maintainers stepping away, this may be a factor
in PRs taking longer to get merged as the remaining maintainers may be
less familiar with the parts of the codebase that were previously
maintained by someone else.
> Requiring maintainers to have to write explanations for every single
merge is simply going to increase the burden on them and increase the
rate of burnout and resignations.
> We've had too many maintainers step down already.
This all points to a a need for additional maintainers (assuming they are sufficiently competent and qualified). We had a potential maintainer (Vasil) come forward (long term contributor, made significant contributions over a number of years, a qualified reviewer, contributes to a part of the codebase that current maintainers aren't very familiar with, ACKed by maintainers and long term contributors) and it was blocked. How does that make sense? You seem to want it both ways. We can't ask maintainers to meet higher standards because there's a shortage and they're close to burning out. But there's no need to add a new maintainer.
I've responded to the parts I disagree with and see inconsistencies with but generally I thought it was a very thoughtful and informative response so thank you. Of the current maintainers you seem to me to be one of (if not the) most responsive and open to public discussion on the project. I've learnt a tonne from your StackExchange posts and Twitch streams that are all public/open source that you do in addition to your contributions and maintenance of Core.
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 22:33, Andrew Chow via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> Responses in-line.
> Note that the opinions expressed in this email are my own and are not
> representative of what other maintainers think or believe.
>
> On 04/18/2023 08:40 AM, Michael Folkson via bitcoin-dev 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.
>
> What commentary does there need to be?
> It's self evident that the maintainer believes the code is ready to be
> merged, and has observed enough ACKs from contributors that they are
> comfortable to do so.
> You're welcome to ask for clarification, but frankly, I don't think
> having any commentary on merges is going to be helpful or more elaborate
> in any way.
> Requiring maintainers to have to write explanations for every single
> merge is simply going to increase the burden on them and increase the
> rate of burnout and resignations.
> We've had too many maintainers step down already.
> It'll end up being a bunch of boilerplate comments that don't say
> anything meaningful.
>
> There are certainly situations where PRs are merged very quickly or with
> otherwise little apparent review.
> But, as I said, if you ask a maintainer why it was merged, the answer
> will be "I thought it was ready and had enough review".
> There may be other reasons that made the maintainer think it was ready
> sooner, such as the PR fixes a critical bug or security vulnerability,
> but these reasons aren't going to be stated publicly.
>
> > 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.
>
> There are currently 320 open PRs and 366 open issues.
> I wake up every morning to 150+ email notifications containing
> everything that went on overnight, and throughout the day, I typically
> get hundreds more.
> It's impossible to keep up with everything that goes on throughout the repo.
> ACKs come in sporadically, PRs are updated, reviews are posted, etc.
> Often times PRs are not merged simply because the maintainers were not
> aware that a PR was ready to be merged.
> Things can simply fall through the cracks.
>
> Of course there are other reasons why something might not be merged, and
> these generally fall into the camp of "I don't think it has had enough
> review".
> It's the maintainer's judgement call to make as to whether something has
> been sufficiently reviewed, and part of the judgement call is to
> consider the quality and competence of the reviewers.
> If a PR had 100 ACKs but all from random people who have never
> contributed to the project in any capacity, then it's not going to be
> merged because those reviewers would be considered low quality.
> It's not just about the numbers, but also about whether the reviewers
> are people the maintainers think are familiar enough with an area and
> have had a history of thoroughly reviewing PRs.
> For example, if a reviewer who primarily works on the mempool reviewed a
> PR in the wallet, I would consider their review and ACK with less weight
> because they are unlikely to be familiar with the intricacies of the wallet.
> Obviously that changes over time as they make more reviews.
> For another example, if I see an ACK from a reviewer who posts reviews
> that primarily contain nits on code style and other trivialities, I
> would consider that ACK with less weight.
>
> Furthermore, the maintainers are not necessarily the ones who block a merge.
> Part of evaluating if something is ready to be merged is to read the
> comments on a PR.
> Other frequent contributors may have commented or asked questions that
> haven't been resolved yet.
> PRs will often not be merged (even if they have ACKs) until a maintainer
> deems that those comments and questions have been sufficiently resolved,
> typically with the commenter stating in some way that their concerns
> were addressed.
> In these situations, no commentary from maintainers is given nor
> necessary as it should be self evident (by reading the comments) that
> something is controversial.
> These kinds of comments are not explicit NACKs (so someone who is only
> counting (N)ACKs won't see them), but are blocking nonetheless.
>
> Lastly, personally I like to review every PR before I merge it.
> This often means that a PR that might otherwise be ready to be merged
> wouldn't be merged by myself as I may not be familiar with that part of
> the codebase.
> It may also mean that I would require more or specific additional people
> to review a PR before I merge it as I would weight my own review less
> heavily.
> With several long time maintainers stepping away, this may be a factor
> in PRs taking longer to get merged as the remaining maintainers may be
> less familiar with the parts of the codebase that were previously
> maintained by someone else.
>
> > 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.
>
> Anyone who thinks that maintainers only look at the numbers of (N)ACKs
> is delusional.
> As I explained above, there is a whole lot more nuance to determining
> even just the status of the opinions on a PR, nevermind the code itself.
>
> In this specific example of a soft fork, there is also consideration of
> the opinions outside of the repo itself, such as on this mailing list
> and elsewhere that people discuss soft forks.
>
> On 04/19/2023 11:17 AM, Aymeric Vitte via bitcoin-dev wrote:
>
> > While some simple changes can allow bitcoin to surpass ethereum, as
>
> usual, like "Allow several OP_RETURN in one tx and no limited size"
> https://github.com/bitcoin/bitcoin/issues/27043
>
> > How long it will take remains mysterious
>
>
> No one (maintainers or contributors) is obligated to implement anything.
> A feature request not being implemented is because the people who do
> open PRs are either not interested in implementing the feature, or are
> working on other things that they believe to be higher priority.
> If there is a feature that you want, then you will often need to either
> to it yourself, or pay someone to do it for you.
>
> Additionally, a feature may seem like a good idea to you, but there are
> often interactions with other things that may end up resulting in it
> being rejected or need significant revision, especially for something
> which affects transaction relay.
>
>
>
> Andrew Chow
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-04-20 2:27 ` Anthony Towns
@ 2023-04-20 9:24 ` Michael Folkson
0 siblings, 0 replies; 28+ messages in thread
From: Michael Folkson @ 2023-04-20 9:24 UTC (permalink / raw)
To: Anthony Towns; +Cc: Bitcoin Protocol Discussion
Hi AJ
> Competition is the only answer to concerns about the bad effects from a monopoly.
Well one can first make suggestions and requests to the monopoly and see if the monopoly is open to them. In the case of bitcoin-inquisition/default signet I like the idea of a group who are interested in following and testing proposed future consensus changes working on the same fork of Core / same signet blockchain. But I've asked on a number of occasions now what the thinking is in terms of criteria for merging a proposed default policy change or a proposed consensus change (progress on BIP, level of review, a work in progress / still in flux / essentially finalized unless a problem is identified) and you haven't been willing to discuss it. So it is essentially the same black box model of maintainership we see on Core. As far as I know you could wake up one day and just merge all open pull requests to the bitcoin-inquisition repo because you're bored. On a custom signet do whatever you want. On the default signet that we're trying to build an ecosystem around, get block explorers to support, can be connected to through the default config in Core etc merge decisions essentially being subject to the whims of AJ doesn't seem ideal to me.
The brunt of having to deal with the CTV activation chaos fell on me (not a long term contributor, unfunded) because few wanted to get involved so it would be nice if lessons were learned and we don't have a soft fork proposal merged onto default signet, a bunch of transactions generated to simulate demand and then this used to justify another contentious soft fork activation attempt on mainnet. When there are vacuums of communication from maintainers and long term contributors it just invites unnecessary chaos.
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 Thursday, April 20th, 2023 at 03:27, Anthony Towns <aj@erisian•com.au> wrote:
> On Tue, Apr 18, 2023 at 12:40:44PM +0000, Michael Folkson via bitcoin-dev wrote:
>
> > I do think the perception that it is “the one and only” staging
> > ground for consensus changes is dangerous
>
>
> If you think that about any open source project, the answer is simple:
> create your own fork and do a better job. Competition is the only answer
> to concerns about the bad effects from a monopoly. (Often the good effects
> from cooperation and collaboration -- less wasted time and duplicated
> effort -- turn out to outweigh the bad effects, however)
>
> In any event, inquisition isn't "the one and only staging ground for
> consensus changes" -- every successful consensus change to date has
> been staged through the developers' own repo then the core PR process,
> and that option still exists.
>
> Cheers,
> aj
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-04-19 21:33 ` Andrew Chow
2023-04-20 8:45 ` Michael Folkson
@ 2023-04-20 10:54 ` Aymeric Vitte
2023-04-20 13:59 ` Erik Aronesty
1 sibling, 1 reply; 28+ messages in thread
From: Aymeric Vitte @ 2023-04-20 10:54 UTC (permalink / raw)
To: Andrew Chow, Bitcoin Protocol Discussion
Personnally I will never criticize the maintainers, but my comment was
about the global process, I thought that for something important like
bitcoin there were many devs/maintainers, and as you point out, a PR
must be done by certified people
I don't get very well why every company involved in bitcoin do not put
at least one person in this process (a bit like W3C specs), with
different time zone so every time you wake up you don't have to look
at/handle hundreds of requests/comments
And we can read in the press that bitcoin maintenance is supposed to
cost 200M per year, probably false then, but this is worrying to see
that devs/maintainers are stepping down one after the other
Le 19/04/2023 à 23:33, Andrew Chow via bitcoin-dev a écrit :
> Responses in-line.
> Note that the opinions expressed in this email are my own and are not
> representative of what other maintainers think or believe.
>
> On 04/18/2023 08:40 AM, Michael Folkson via bitcoin-dev 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.
>
> What commentary does there need to be?
> It's self evident that the maintainer believes the code is ready to be
> merged, and has observed enough ACKs from contributors that they are
> comfortable to do so.
> You're welcome to ask for clarification, but frankly, I don't think
> having any commentary on merges is going to be helpful or more elaborate
> in any way.
> Requiring maintainers to have to write explanations for every single
> merge is simply going to increase the burden on them and increase the
> rate of burnout and resignations.
> We've had too many maintainers step down already.
> It'll end up being a bunch of boilerplate comments that don't say
> anything meaningful.
>
> There are certainly situations where PRs are merged very quickly or with
> otherwise little apparent review.
> But, as I said, if you ask a maintainer why it was merged, the answer
> will be "I thought it was ready and had enough review".
> There may be other reasons that made the maintainer think it was ready
> sooner, such as the PR fixes a critical bug or security vulnerability,
> but these reasons aren't going to be stated publicly.
>
> > 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.
>
> There are currently 320 open PRs and 366 open issues.
> I wake up every morning to 150+ email notifications containing
> everything that went on overnight, and throughout the day, I typically
> get hundreds more.
> It's impossible to keep up with everything that goes on throughout the repo.
> ACKs come in sporadically, PRs are updated, reviews are posted, etc.
> Often times PRs are not merged simply because the maintainers were not
> aware that a PR was ready to be merged.
> Things can simply fall through the cracks.
>
> Of course there are other reasons why something might not be merged, and
> these generally fall into the camp of "I don't think it has had enough
> review".
> It's the maintainer's judgement call to make as to whether something has
> been sufficiently reviewed, and part of the judgement call is to
> consider the quality and competence of the reviewers.
> If a PR had 100 ACKs but all from random people who have never
> contributed to the project in any capacity, then it's not going to be
> merged because those reviewers would be considered low quality.
> It's not just about the numbers, but also about whether the reviewers
> are people the maintainers think are familiar enough with an area and
> have had a history of thoroughly reviewing PRs.
> For example, if a reviewer who primarily works on the mempool reviewed a
> PR in the wallet, I would consider their review and ACK with less weight
> because they are unlikely to be familiar with the intricacies of the wallet.
> Obviously that changes over time as they make more reviews.
> For another example, if I see an ACK from a reviewer who posts reviews
> that primarily contain nits on code style and other trivialities, I
> would consider that ACK with less weight.
>
> Furthermore, the maintainers are not necessarily the ones who block a merge.
> Part of evaluating if something is ready to be merged is to read the
> comments on a PR.
> Other frequent contributors may have commented or asked questions that
> haven't been resolved yet.
> PRs will often not be merged (even if they have ACKs) until a maintainer
> deems that those comments and questions have been sufficiently resolved,
> typically with the commenter stating in some way that their concerns
> were addressed.
> In these situations, no commentary from maintainers is given nor
> necessary as it should be self evident (by reading the comments) that
> something is controversial.
> These kinds of comments are not explicit NACKs (so someone who is only
> counting (N)ACKs won't see them), but are blocking nonetheless.
>
> Lastly, personally I like to review every PR before I merge it.
> This often means that a PR that might otherwise be ready to be merged
> wouldn't be merged by myself as I may not be familiar with that part of
> the codebase.
> It may also mean that I would require more or specific additional people
> to review a PR before I merge it as I would weight my own review less
> heavily.
> With several long time maintainers stepping away, this may be a factor
> in PRs taking longer to get merged as the remaining maintainers may be
> less familiar with the parts of the codebase that were previously
> maintained by someone else.
>
> > 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.
>
> Anyone who thinks that maintainers only look at the numbers of (N)ACKs
> is delusional.
> As I explained above, there is a whole lot more nuance to determining
> even just the status of the opinions on a PR, nevermind the code itself.
>
> In this specific example of a soft fork, there is also consideration of
> the opinions outside of the repo itself, such as on this mailing list
> and elsewhere that people discuss soft forks.
>
> On 04/19/2023 11:17 AM, Aymeric Vitte via bitcoin-dev wrote:
> > While some simple changes can allow bitcoin to surpass ethereum, as
> usual, like "Allow several OP_RETURN in one tx and no limited size"
> https://github.com/bitcoin/bitcoin/issues/27043
> >
> > How long it will take remains mysterious
>
> No one (maintainers or contributors) is obligated to implement anything.
> A feature request not being implemented is because the people who do
> open PRs are either not interested in implementing the feature, or are
> working on other things that they believe to be higher priority.
> If there is a feature that you want, then you will often need to either
> to it yourself, or pay someone to do it for you.
>
> Additionally, a feature may seem like a good idea to you, but there are
> often interactions with other things that may end up resulting in it
> being rejected or need significant revision, especially for something
> which affects transaction relay.
>
>
>
> Andrew Chow
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-04-20 10:54 ` Aymeric Vitte
@ 2023-04-20 13:59 ` Erik Aronesty
2023-04-20 14:25 ` Aymeric Vitte
0 siblings, 1 reply; 28+ messages in thread
From: Erik Aronesty @ 2023-04-20 13:59 UTC (permalink / raw)
To: Aymeric Vitte, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 9201 bytes --]
i think the w3c is a very good example of a slow train wreck, and we should
do everything possible to avoid the decisions they made
On Thu, Apr 20, 2023 at 7:09 AM Aymeric Vitte via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Personnally I will never criticize the maintainers, but my comment was
> about the global process, I thought that for something important like
> bitcoin there were many devs/maintainers, and as you point out, a PR
> must be done by certified people
>
> I don't get very well why every company involved in bitcoin do not put
> at least one person in this process (a bit like W3C specs), with
> different time zone so every time you wake up you don't have to look
> at/handle hundreds of requests/comments
>
> And we can read in the press that bitcoin maintenance is supposed to
> cost 200M per year, probably false then, but this is worrying to see
> that devs/maintainers are stepping down one after the other
>
>
> Le 19/04/2023 à 23:33, Andrew Chow via bitcoin-dev a écrit :
> > Responses in-line.
> > Note that the opinions expressed in this email are my own and are not
> > representative of what other maintainers think or believe.
> >
> > On 04/18/2023 08:40 AM, Michael Folkson via bitcoin-dev 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.
> >
> > What commentary does there need to be?
> > It's self evident that the maintainer believes the code is ready to be
> > merged, and has observed enough ACKs from contributors that they are
> > comfortable to do so.
> > You're welcome to ask for clarification, but frankly, I don't think
> > having any commentary on merges is going to be helpful or more elaborate
> > in any way.
> > Requiring maintainers to have to write explanations for every single
> > merge is simply going to increase the burden on them and increase the
> > rate of burnout and resignations.
> > We've had too many maintainers step down already.
> > It'll end up being a bunch of boilerplate comments that don't say
> > anything meaningful.
> >
> > There are certainly situations where PRs are merged very quickly or with
> > otherwise little apparent review.
> > But, as I said, if you ask a maintainer why it was merged, the answer
> > will be "I thought it was ready and had enough review".
> > There may be other reasons that made the maintainer think it was ready
> > sooner, such as the PR fixes a critical bug or security vulnerability,
> > but these reasons aren't going to be stated publicly.
> >
> > > 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.
> >
> > There are currently 320 open PRs and 366 open issues.
> > I wake up every morning to 150+ email notifications containing
> > everything that went on overnight, and throughout the day, I typically
> > get hundreds more.
> > It's impossible to keep up with everything that goes on throughout the
> repo.
> > ACKs come in sporadically, PRs are updated, reviews are posted, etc.
> > Often times PRs are not merged simply because the maintainers were not
> > aware that a PR was ready to be merged.
> > Things can simply fall through the cracks.
> >
> > Of course there are other reasons why something might not be merged, and
> > these generally fall into the camp of "I don't think it has had enough
> > review".
> > It's the maintainer's judgement call to make as to whether something has
> > been sufficiently reviewed, and part of the judgement call is to
> > consider the quality and competence of the reviewers.
> > If a PR had 100 ACKs but all from random people who have never
> > contributed to the project in any capacity, then it's not going to be
> > merged because those reviewers would be considered low quality.
> > It's not just about the numbers, but also about whether the reviewers
> > are people the maintainers think are familiar enough with an area and
> > have had a history of thoroughly reviewing PRs.
> > For example, if a reviewer who primarily works on the mempool reviewed a
> > PR in the wallet, I would consider their review and ACK with less weight
> > because they are unlikely to be familiar with the intricacies of the
> wallet.
> > Obviously that changes over time as they make more reviews.
> > For another example, if I see an ACK from a reviewer who posts reviews
> > that primarily contain nits on code style and other trivialities, I
> > would consider that ACK with less weight.
> >
> > Furthermore, the maintainers are not necessarily the ones who block a
> merge.
> > Part of evaluating if something is ready to be merged is to read the
> > comments on a PR.
> > Other frequent contributors may have commented or asked questions that
> > haven't been resolved yet.
> > PRs will often not be merged (even if they have ACKs) until a maintainer
> > deems that those comments and questions have been sufficiently resolved,
> > typically with the commenter stating in some way that their concerns
> > were addressed.
> > In these situations, no commentary from maintainers is given nor
> > necessary as it should be self evident (by reading the comments) that
> > something is controversial.
> > These kinds of comments are not explicit NACKs (so someone who is only
> > counting (N)ACKs won't see them), but are blocking nonetheless.
> >
> > Lastly, personally I like to review every PR before I merge it.
> > This often means that a PR that might otherwise be ready to be merged
> > wouldn't be merged by myself as I may not be familiar with that part of
> > the codebase.
> > It may also mean that I would require more or specific additional people
> > to review a PR before I merge it as I would weight my own review less
> > heavily.
> > With several long time maintainers stepping away, this may be a factor
> > in PRs taking longer to get merged as the remaining maintainers may be
> > less familiar with the parts of the codebase that were previously
> > maintained by someone else.
> >
> > > 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.
> >
> > Anyone who thinks that maintainers only look at the numbers of (N)ACKs
> > is delusional.
> > As I explained above, there is a whole lot more nuance to determining
> > even just the status of the opinions on a PR, nevermind the code itself.
> >
> > In this specific example of a soft fork, there is also consideration of
> > the opinions outside of the repo itself, such as on this mailing list
> > and elsewhere that people discuss soft forks.
> >
> > On 04/19/2023 11:17 AM, Aymeric Vitte via bitcoin-dev wrote:
> > > While some simple changes can allow bitcoin to surpass ethereum, as
> > usual, like "Allow several OP_RETURN in one tx and no limited size"
> > https://github.com/bitcoin/bitcoin/issues/27043
> > >
> > > How long it will take remains mysterious
> >
> > No one (maintainers or contributors) is obligated to implement anything.
> > A feature request not being implemented is because the people who do
> > open PRs are either not interested in implementing the feature, or are
> > working on other things that they believe to be higher priority.
> > If there is a feature that you want, then you will often need to either
> > to it yourself, or pay someone to do it for you.
> >
> > Additionally, a feature may seem like a good idea to you, but there are
> > often interactions with other things that may end up resulting in it
> > being rejected or need significant revision, especially for something
> > which affects transaction relay.
> >
> >
> >
> > Andrew Chow
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
> Sophia-Antipolis, France
> CV: https://www.peersm.com/CVAV.pdf
> LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
> GitHub : https://www.github.com/Ayms
> A Universal Coin Swap system based on Bitcoin:
> https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
> A bitcoin NFT system:
> https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
> Move your coins by yourself (browser version): https://peersm.com/wallet
> Bitcoin transactions made simple:
> https://github.com/Ayms/bitcoin-transactions
>
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> Anti-spies and private torrents, dynamic blocklist:
> http://torrent-live.peersm.com
> Peersm : http://www.peersm.com
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 11829 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-04-20 13:59 ` Erik Aronesty
@ 2023-04-20 14:25 ` Aymeric Vitte
0 siblings, 0 replies; 28+ messages in thread
From: Aymeric Vitte @ 2023-04-20 14:25 UTC (permalink / raw)
To: Erik Aronesty, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 11739 bytes --]
Right, that's why I do not participate any longer, they specify things
for the participants (ie big companies), they disregard whatever
suggestion can be made, they are so slow that when they have specified
something someone else has specified something better, then they throw
away their spec and take what the others have specified
And they are wrong in many design decisions
What I meant is that bitcoin big companies should involve people, who
are not just discussing stupid things all the day like W3C folks but do
the work efficiently
Le 20/04/2023 à 15:59, Erik Aronesty a écrit :
> i think the w3c is a very good example of a slow train wreck, and we
> should do everything possible to avoid the decisions they made
>
> On Thu, Apr 20, 2023 at 7:09 AM Aymeric Vitte via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>
> Personnally I will never criticize the maintainers, but my comment was
> about the global process, I thought that for something important like
> bitcoin there were many devs/maintainers, and as you point out, a PR
> must be done by certified people
>
> I don't get very well why every company involved in bitcoin do not put
> at least one person in this process (a bit like W3C specs), with
> different time zone so every time you wake up you don't have to look
> at/handle hundreds of requests/comments
>
> And we can read in the press that bitcoin maintenance is supposed to
> cost 200M per year, probably false then, but this is worrying to see
> that devs/maintainers are stepping down one after the other
>
>
> Le 19/04/2023 à 23:33, Andrew Chow via bitcoin-dev a écrit :
> > Responses in-line.
> > Note that the opinions expressed in this email are my own and
> are not
> > representative of what other maintainers think or believe.
> >
> > On 04/18/2023 08:40 AM, Michael Folkson via bitcoin-dev 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.
> >
> > What commentary does there need to be?
> > It's self evident that the maintainer believes the code is ready
> to be
> > merged, and has observed enough ACKs from contributors that they are
> > comfortable to do so.
> > You're welcome to ask for clarification, but frankly, I don't think
> > having any commentary on merges is going to be helpful or more
> elaborate
> > in any way.
> > Requiring maintainers to have to write explanations for every single
> > merge is simply going to increase the burden on them and
> increase the
> > rate of burnout and resignations.
> > We've had too many maintainers step down already.
> > It'll end up being a bunch of boilerplate comments that don't say
> > anything meaningful.
> >
> > There are certainly situations where PRs are merged very quickly
> or with
> > otherwise little apparent review.
> > But, as I said, if you ask a maintainer why it was merged, the
> answer
> > will be "I thought it was ready and had enough review".
> > There may be other reasons that made the maintainer think it was
> ready
> > sooner, such as the PR fixes a critical bug or security
> vulnerability,
> > but these reasons aren't going to be stated publicly.
> >
> > > 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.
> >
> > There are currently 320 open PRs and 366 open issues.
> > I wake up every morning to 150+ email notifications containing
> > everything that went on overnight, and throughout the day, I
> typically
> > get hundreds more.
> > It's impossible to keep up with everything that goes on
> throughout the repo.
> > ACKs come in sporadically, PRs are updated, reviews are posted, etc.
> > Often times PRs are not merged simply because the maintainers
> were not
> > aware that a PR was ready to be merged.
> > Things can simply fall through the cracks.
> >
> > Of course there are other reasons why something might not be
> merged, and
> > these generally fall into the camp of "I don't think it has had
> enough
> > review".
> > It's the maintainer's judgement call to make as to whether
> something has
> > been sufficiently reviewed, and part of the judgement call is to
> > consider the quality and competence of the reviewers.
> > If a PR had 100 ACKs but all from random people who have never
> > contributed to the project in any capacity, then it's not going
> to be
> > merged because those reviewers would be considered low quality.
> > It's not just about the numbers, but also about whether the
> reviewers
> > are people the maintainers think are familiar enough with an
> area and
> > have had a history of thoroughly reviewing PRs.
> > For example, if a reviewer who primarily works on the mempool
> reviewed a
> > PR in the wallet, I would consider their review and ACK with
> less weight
> > because they are unlikely to be familiar with the intricacies of
> the wallet.
> > Obviously that changes over time as they make more reviews.
> > For another example, if I see an ACK from a reviewer who posts
> reviews
> > that primarily contain nits on code style and other trivialities, I
> > would consider that ACK with less weight.
> >
> > Furthermore, the maintainers are not necessarily the ones who
> block a merge.
> > Part of evaluating if something is ready to be merged is to read the
> > comments on a PR.
> > Other frequent contributors may have commented or asked
> questions that
> > haven't been resolved yet.
> > PRs will often not be merged (even if they have ACKs) until a
> maintainer
> > deems that those comments and questions have been sufficiently
> resolved,
> > typically with the commenter stating in some way that their concerns
> > were addressed.
> > In these situations, no commentary from maintainers is given nor
> > necessary as it should be self evident (by reading the comments)
> that
> > something is controversial.
> > These kinds of comments are not explicit NACKs (so someone who
> is only
> > counting (N)ACKs won't see them), but are blocking nonetheless.
> >
> > Lastly, personally I like to review every PR before I merge it.
> > This often means that a PR that might otherwise be ready to be
> merged
> > wouldn't be merged by myself as I may not be familiar with that
> part of
> > the codebase.
> > It may also mean that I would require more or specific
> additional people
> > to review a PR before I merge it as I would weight my own review
> less
> > heavily.
> > With several long time maintainers stepping away, this may be a
> factor
> > in PRs taking longer to get merged as the remaining maintainers
> may be
> > less familiar with the parts of the codebase that were previously
> > maintained by someone else.
> >
> > > 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 <http://utxos.org> site [4] signalling support for
> a soft fork activation
> > attempt.
> >
> > Anyone who thinks that maintainers only look at the numbers of
> (N)ACKs
> > is delusional.
> > As I explained above, there is a whole lot more nuance to
> determining
> > even just the status of the opinions on a PR, nevermind the code
> itself.
> >
> > In this specific example of a soft fork, there is also
> consideration of
> > the opinions outside of the repo itself, such as on this mailing
> list
> > and elsewhere that people discuss soft forks.
> >
> > On 04/19/2023 11:17 AM, Aymeric Vitte via bitcoin-dev wrote:
> > > While some simple changes can allow bitcoin to surpass
> ethereum, as
> > usual, like "Allow several OP_RETURN in one tx and no limited size"
> > https://github.com/bitcoin/bitcoin/issues/27043
> > >
> > > How long it will take remains mysterious
> >
> > No one (maintainers or contributors) is obligated to implement
> anything.
> > A feature request not being implemented is because the people who do
> > open PRs are either not interested in implementing the feature,
> or are
> > working on other things that they believe to be higher priority.
> > If there is a feature that you want, then you will often need to
> either
> > to it yourself, or pay someone to do it for you.
> >
> > Additionally, a feature may seem like a good idea to you, but
> there are
> > often interactions with other things that may end up resulting in it
> > being rejected or need significant revision, especially for
> something
> > which affects transaction relay.
> >
> >
> >
> > Andrew Chow
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
> Sophia-Antipolis, France
> CV: https://www.peersm.com/CVAV.pdf
> LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
> GitHub : https://www.github.com/Ayms
> A Universal Coin Swap system based on Bitcoin:
> https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
> A bitcoin NFT system:
> https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
> Move your coins by yourself (browser version):
> https://peersm.com/wallet
> Bitcoin transactions made simple:
> https://github.com/Ayms/bitcoin-transactions
>
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> Anti-spies and private torrents, dynamic blocklist:
> http://torrent-live.peersm.com
> Peersm : http://www.peersm.com
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
[-- Attachment #2: Type: text/html, Size: 17819 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-04-18 12:40 [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions Michael Folkson
` (4 preceding siblings ...)
2023-04-20 2:27 ` Anthony Towns
@ 2023-05-07 7:03 ` Michael Folkson
2023-05-07 17:35 ` David A. Harding
2023-05-10 21:24 ` Andrew Chow
5 siblings, 2 replies; 28+ messages in thread
From: Michael Folkson @ 2023-05-07 7:03 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 10139 bytes --]
There has been a proposed new maintainer on Bitcoin Core (ryanofsky). In the Core dev IRC meeting [0] yesterday it received multiple ACKs.
The decision process for adding a new maintainer was according to the IRC meeting that the maintainers decided privately there was a need for a maintainer “who understood our interfaces and modularization efforts well” and that ryanofsky was a “good fit for that”. I don’t know whether this was decided in a private IRC channel or was decided at the recent in person Core Dev meeting. Regardless, many have had no input into the discussion on what kind of maintainer the project needs going forward and it seems the maintainers do not want to discuss that aspect of the decision.
I posted a couple of questions in advance [1] of the meeting (I was unable to attend) that remained unanswered during the meeting. Essentially my concern is going forward current maintainers will decide which proposed new maintainers to add and which to block. If you aren’t anointed by the current maintainers you won’t get added as a maintainer and a half baked rationale will be provided to justify that decision. Longer term this will determine the pull requests that will ultimately get merged and which don't get merged because maintainers merge pull requests.
One of the justifications for blocking Vasil Dimov as a new maintainer despite many initial ACKs from maintainers (including Andrew Chow) and long term contributors was according to Andrew [2]:
“Maintainers inherently need to look at the things that everyone else has already looked at, if only to give it a final once over before merging (but hopefully, an actual review, not just looking it over).”
I follow the Bitcoin Core repo pretty closely and I haven’t seen ryanofsky do this any more than Vasil does. This is not a criticism of ryanofsky, just as I wouldn’t use it as a criticism for Vasil. It would get pretty annoying if everyone who wasn’t a maintainer posted an ACK once many long term contributors had already ACKed to display supposed “desired maintainer traits”. Especially if you are essentially just ACKing that others have done the work to review the PR and you just want to get your ACK on it to increase your ACK count without doing a fraction of what previous reviewers have done.
“I also want to mention that the people who have become maintainers in the past have had this kind of maintainer attitude towards review prior to becoming a maintainer”
Assuming ryanofsky hasn’t had this maintainer attitude in the past (again not a criticism from me at least) does this mean this was a reason to block Vasil but not a reason to block ryanofsky? That seems inconsistent to me. When you’re anointed you don’t need to meet requirements but when you’re blocked these requirements will be used to block your addition as a new maintainer?
For what it is worth from a personal perspective I don’t see any reason for blocking ryanofsky as a maintainer especially if there is broad agreement amongst maintainers and long term contributors that we need a new maintainer who understands interfaces and modularization on the project. For that framing ryanofsky perfectly meets those requirements. But once again the (public) discussion element on the addition of maintainers is essentially a façade, a framing for what the new maintainer needs to be has been decided in advance (in private) and an anointed individual who just so happens to align with that convenient framing will get added as a new maintainer.
On a more positive note there does seem to be more energy and momentum for collaboration and open communication on the project since I discussed communication in a previous post [3]. Hopefully this will continue. It doesn’t address my concerns on maintainers and ultimately merge decisions but it definitely seems to me to be a step in a positive direction for the project.
[0]: https://gnusha.org/bitcoin-core-dev/2023-05-04.log
[1]: https://gnusha.org/bitcoin-core-dev/2023-05-01.log
[2]: https://github.com/bitcoin/bitcoin/pull/25871#issuecomment-1382334059
[3]:https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021565.html
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Tuesday, April 18th, 2023 at 13:40, Michael Folkson <michaelfolkson@protonmail•com> 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.
>
> [0]: https://github.com/bitcoin/bitcoin/pull/25871
>
> [1]: https://github.com/bitcoin/bitcoin/pull/21702
>
> [2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html
>
> [3]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> [4]: https://utxos.org/signals/
>
> [5]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
>
> [6]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020948.html
>
> --
> Michael Folkson
> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
[-- Attachment #2: Type: text/html, Size: 18719 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-05-07 7:03 ` Michael Folkson
@ 2023-05-07 17:35 ` David A. Harding
2023-05-08 9:36 ` Michael Folkson
2023-05-08 12:03 ` Bryan Bishop
2023-05-10 21:24 ` Andrew Chow
1 sibling, 2 replies; 28+ messages in thread
From: David A. Harding @ 2023-05-07 17:35 UTC (permalink / raw)
To: Michael Folkson, Bitcoin Protocol Discussion
On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
> Essentially my concern is going forward current maintainers will
> decide which proposed new maintainers to add and which to block.
This is how a large percentage of organizations are run. The current
members of a board or other governance group choose who will become a
new board member.
One alternative to self-perpetuating governance is membership voting,
but building and maintaining democratic institutions is hard and not a
good fit for many types of endeavors---the building of highly technical
software being one of those cases IMO.
I think the questions we want to ask is whether the current set of
maintainers is capable of moving Bitcoin Core in the direction we want
and what we can do about it if we conclude that they are ill-suited (or
malicious). For the first question, I think that's something everyone
needs to answer for themselves, as we may each have different visions
for the future of the project. That said, I note that several
initiatives championed by the current maintainers in the IRC meeting you
mention received overwhelmingly positive support from a significant
number of current contributors, which seems like a healthy sign to me.
For the second question, I think AJ Towns already answered that quite
well (though he was talking about a different project):
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021578.html
Finally, I don't think this matter warranted a post to this mailing
list. Discussion about internal project decisions, such as who should
have merge access and what maintainers should communicate in PRs, belong
in communication channels dedicated to that project.
-Dave
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-05-07 17:35 ` David A. Harding
@ 2023-05-08 9:36 ` Michael Folkson
2023-05-08 12:03 ` Bryan Bishop
1 sibling, 0 replies; 28+ messages in thread
From: Michael Folkson @ 2023-05-08 9:36 UTC (permalink / raw)
To: David A. Harding; +Cc: Bitcoin Protocol Discussion
Hi David
>> Essentially my concern is going forward current maintainers will decide which proposed new maintainers to add and which to block.
> This is how a large percentage of organizations are run. The current members of a board or other governance group choose who will become a new board member.
So long term contributors who aren't maintainers don't get input into the decision? It is starting to seem like the maintainer role is moving from a janitorial one to where maintainers make decisions without discussing those decisions with long term contributors and in some cases even bothering to explain the rationale for those decisions to a broader audience that includes long term contributors. This unfortunately makes the decision on who becomes a maintainer even more important.
Decisions have to be made but I was always under the impression that they would be discussed in open, public IRC meetings with at least other long term contributors present and then decisions would be made based on the views expressed in that meeting. An appointed board or governance group ("the maintainers") wasn't how I thought the project was run or should be run.
> Finally, I don't think this matter warranted a post to this mailing list. Discussion about internal project decisions, such as who should have merge access and what maintainers should communicate in PRs, belong in communication channels dedicated to that project.
I have tried. As I said in previous emails in the Vasil maintainer case I asked fanquake, Gloria repeatedly over a period of 5 months why Vasil was being blocked. They refused to comment. I get called "rude" and "aggressive" for asking. So I'd rather post my thoughts and observations here than risk being accused of being "rude" and "aggressive" again for asking questions on this topic on IRC. Especially as I expect they'll be ignored anyway as they were in last week's Core Dev IRC meeting.
Until the Vasil situation I thought that we had a common sense approach of any long term contributor who had demonstrated they could add value to the project and had shown good temperament could become a maintainer. Blocking Vasil as a maintainer was a red flag for me that we no longer have that. And fanquake, Gloria not being willing to discuss why publicly for 5 months was a second red flag. If that is the precedent for merge decisions anything is possible in the future including in the worst case contentious consensus change merges with no justification and no rationale.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at protonmail.com
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Sunday, May 7th, 2023 at 18:35, David A. Harding <dave@dtrt•org> wrote:
> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
>
> > Essentially my concern is going forward current maintainers will
> > decide which proposed new maintainers to add and which to block.
>
>
> This is how a large percentage of organizations are run. The current
> members of a board or other governance group choose who will become a
> new board member.
>
> One alternative to self-perpetuating governance is membership voting,
> but building and maintaining democratic institutions is hard and not a
> good fit for many types of endeavors---the building of highly technical
> software being one of those cases IMO.
>
> I think the questions we want to ask is whether the current set of
> maintainers is capable of moving Bitcoin Core in the direction we want
> and what we can do about it if we conclude that they are ill-suited (or
> malicious). For the first question, I think that's something everyone
> needs to answer for themselves, as we may each have different visions
> for the future of the project. That said, I note that several
> initiatives championed by the current maintainers in the IRC meeting you
> mention received overwhelmingly positive support from a significant
> number of current contributors, which seems like a healthy sign to me.
>
> For the second question, I think AJ Towns already answered that quite
> well (though he was talking about a different project):
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021578.html
>
> Finally, I don't think this matter warranted a post to this mailing
> list. Discussion about internal project decisions, such as who should
> have merge access and what maintainers should communicate in PRs, belong
> in communication channels dedicated to that project.
>
> -Dave
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-05-07 17:35 ` David A. Harding
2023-05-08 9:36 ` Michael Folkson
@ 2023-05-08 12:03 ` Bryan Bishop
2023-05-10 2:44 ` Steve Lee
1 sibling, 1 reply; 28+ messages in thread
From: Bryan Bishop @ 2023-05-08 12:03 UTC (permalink / raw)
To: David A. Harding, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]
On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
> > Essentially my concern is going forward current maintainers will
> > decide which proposed new maintainers to add and which to block.
>
> This is how a large percentage of organizations are run. The current
> members of a board or other governance group choose who will become a
> new board member.
>
Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of
independent contributors merging different pull requests or patches. The
github controls are merely because that is how github works. There is also
a secondary issue of people tending to confuse Bitcoin Core with the
bitcoin protocol in general:
https://blog.lopp.net/who-controls-bitcoin-core/
https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd
https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427
- Bryan
https://twitter.com/kanzure
[-- Attachment #2: Type: text/html, Size: 1879 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-05-08 12:03 ` Bryan Bishop
@ 2023-05-10 2:44 ` Steve Lee
2023-05-10 15:55 ` Michael Folkson
0 siblings, 1 reply; 28+ messages in thread
From: Steve Lee @ 2023-05-10 2:44 UTC (permalink / raw)
To: Bryan Bishop, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]
Isn't this as simple as anyone (in particular Core project contributors)
can express their view in this PR?
https://github.com/bitcoin/bitcoin/pull/27604
On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
>> > Essentially my concern is going forward current maintainers will
>> > decide which proposed new maintainers to add and which to block.
>>
>> This is how a large percentage of organizations are run. The current
>> members of a board or other governance group choose who will become a
>> new board member.
>>
>
> Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of
> independent contributors merging different pull requests or patches. The
> github controls are merely because that is how github works. There is also
> a secondary issue of people tending to confuse Bitcoin Core with the
> bitcoin protocol in general:
> https://blog.lopp.net/who-controls-bitcoin-core/
> https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd
>
> https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427
>
> - Bryan
> https://twitter.com/kanzure
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 2885 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-05-10 2:44 ` Steve Lee
@ 2023-05-10 15:55 ` Michael Folkson
2023-05-10 16:36 ` Steve Lee
0 siblings, 1 reply; 28+ messages in thread
From: Michael Folkson @ 2023-05-10 15:55 UTC (permalink / raw)
To: Steve Lee, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2416 bytes --]
Hi Steve
> Isn't this as simple as anyone (in particular Core project contributors) can express their view in this PR?https://github.com/bitcoin/bitcoin/pull/27604
Nope. The extent to which the rationale for blocking Vasil as a maintainer applies or doesn't apply to ryanofsky (or future potential maintainers) isn't discussed. From now on the precedent is proposed maintainers can be blocked for unknown and/or potentially inconsistent reasons by the existing maintainers.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Wednesday, May 10th, 2023 at 03:44, Steve Lee via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> Isn't this as simple as anyone (in particular Core project contributors) can express their view in this PR? https://github.com/bitcoin/bitcoin/pull/27604
>
> On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>>> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
>>>> Essentially my concern is going forward current maintainers will
>>>> decide which proposed new maintainers to add and which to block.
>>>
>>> This is how a large percentage of organizations are run. The current
>>> members of a board or other governance group choose who will become a
>>> new board member.
>>
>> Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of independent contributors merging different pull requests or patches. The github controls are merely because that is how github works. There is also a secondary issue of people tending to confuse Bitcoin Core with the bitcoin protocol in general:
>> https://blog.lopp.net/who-controls-bitcoin-core/
>> https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd
>> https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427
>>
>> - Bryan
>> https://twitter.com/kanzure
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 8718 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-05-10 15:55 ` Michael Folkson
@ 2023-05-10 16:36 ` Steve Lee
2023-05-10 17:22 ` Michael Folkson
0 siblings, 1 reply; 28+ messages in thread
From: Steve Lee @ 2023-05-10 16:36 UTC (permalink / raw)
To: Michael Folkson; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2817 bytes --]
Blocking Vasil was discussed on a similar GitHub PR. Whether or not one
agrees or disagrees, the same process is being used. Anyone can NACK and
give a reason for Russ as well.
On Wed, May 10, 2023 at 8:55 AM Michael Folkson <
michaelfolkson@protonmail•com> wrote:
> Hi Steve
>
> > Isn't this as simple as anyone (in particular Core project
> contributors) can express their view in this PR?
> https://github.com/bitcoin/bitcoin/pull/27604
>
> Nope. The extent to which the rationale for blocking Vasil as a maintainer
> applies or doesn't apply to ryanofsky (or future potential maintainers)
> isn't discussed. From now on the precedent is proposed maintainers can be
> blocked for unknown and/or potentially inconsistent reasons by the existing
> maintainers.
>
> Thanks
> Michael
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>
> ------- Original Message -------
> On Wednesday, May 10th, 2023 at 03:44, Steve Lee via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Isn't this as simple as anyone (in particular Core project contributors)
> can express their view in this PR?
> https://github.com/bitcoin/bitcoin/pull/27604
>
> On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev <
>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>>> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
>>> > Essentially my concern is going forward current maintainers will
>>> > decide which proposed new maintainers to add and which to block.
>>>
>>> This is how a large percentage of organizations are run. The current
>>> members of a board or other governance group choose who will become a
>>> new board member.
>>>
>>
>> Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of
>> independent contributors merging different pull requests or patches. The
>> github controls are merely because that is how github works. There is also
>> a secondary issue of people tending to confuse Bitcoin Core with the
>> bitcoin protocol in general:
>> https://blog.lopp.net/who-controls-bitcoin-core/
>> https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd
>>
>> https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427
>>
>> - Bryan
>> https://twitter.com/kanzure
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
[-- Attachment #2: Type: text/html, Size: 8916 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-05-10 16:36 ` Steve Lee
@ 2023-05-10 17:22 ` Michael Folkson
2023-05-10 18:29 ` Steve Lee
0 siblings, 1 reply; 28+ messages in thread
From: Michael Folkson @ 2023-05-10 17:22 UTC (permalink / raw)
To: Steve Lee; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4046 bytes --]
> Blocking Vasil was discussed on a similar GitHub PR. Whether or not one agrees or disagrees, the same process is being used. Anyone can NACK and give a reason for Russ as well.
With respect Steve the process for Vasil was keeping Vasil's PR open for up to 5 months with zero NACKs and two maintainers refusing to engage on why it wasn't being merged or what it needed for it to be merged. Followed by a later justification for blocking it that they've refused to discuss whether it applies to Russ.
The process for Russ was the maintainers deciding privately there was a need for a maintainer "who understood our interfaces and modularization efforts well" and his PR was merged within 2 days.
If that's the same process to you I don't know what to say. We have different perspectives on what constitutes a decision process.
(I'm sure this is clear but just to reiterate in case it isn't none of this is a criticism of Russ.)
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Wednesday, May 10th, 2023 at 17:36, Steve Lee <steven.j.lee@gmail•com> wrote:
> Blocking Vasil was discussed on a similar GitHub PR. Whether or not one agrees or disagrees, the same process is being used. Anyone can NACK and give a reason for Russ as well.
>
> On Wed, May 10, 2023 at 8:55 AM Michael Folkson <michaelfolkson@protonmail•com> wrote:
>
>> Hi Steve
>>
>>> Isn't this as simple as anyone (in particular Core project contributors) can express their view in this PR?https://github.com/bitcoin/bitcoin/pull/27604
>>
>> Nope. The extent to which the rationale for blocking Vasil as a maintainer applies or doesn't apply to ryanofsky (or future potential maintainers) isn't discussed. From now on the precedent is proposed maintainers can be blocked for unknown and/or potentially inconsistent reasons by the existing maintainers.
>>
>> Thanks
>> Michael
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>>
>> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>>
>> ------- Original Message -------
>> On Wednesday, May 10th, 2023 at 03:44, Steve Lee via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>>> Isn't this as simple as anyone (in particular Core project contributors) can express their view in this PR? https://github.com/bitcoin/bitcoin/pull/27604
>>>
>>> On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>
>>>> On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>>
>>>>> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
>>>>>> Essentially my concern is going forward current maintainers will
>>>>>> decide which proposed new maintainers to add and which to block.
>>>>>
>>>>> This is how a large percentage of organizations are run. The current
>>>>> members of a board or other governance group choose who will become a
>>>>> new board member.
>>>>
>>>> Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of independent contributors merging different pull requests or patches. The github controls are merely because that is how github works. There is also a secondary issue of people tending to confuse Bitcoin Core with the bitcoin protocol in general:
>>>> https://blog.lopp.net/who-controls-bitcoin-core/
>>>> https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd
>>>> https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427
>>>>
>>>> - Bryan
>>>> https://twitter.com/kanzure
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists•linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 15855 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-05-10 17:22 ` Michael Folkson
@ 2023-05-10 18:29 ` Steve Lee
0 siblings, 0 replies; 28+ messages in thread
From: Steve Lee @ 2023-05-10 18:29 UTC (permalink / raw)
To: Michael Folkson; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4578 bytes --]
I see it was merged since my original post. I agree that is a very short
window of time. In particular, if a long-time Core contributor wasn't able
to attend the in-person meeting or last week's IRC meeting, they'd have had
to really been on the ball.
On Wed, May 10, 2023 at 10:22 AM Michael Folkson <
michaelfolkson@protonmail•com> wrote:
> > Blocking Vasil was discussed on a similar GitHub PR. Whether or not one
> agrees or disagrees, the same process is being used. Anyone can NACK and
> give a reason for Russ as well.
>
> With respect Steve the process for Vasil was keeping Vasil's PR open for
> up to 5 months with zero NACKs and two maintainers refusing to engage on
> why it wasn't being merged or what it needed for it to be merged. Followed
> by a later justification for blocking it that they've refused to discuss
> whether it applies to Russ.
>
> The process for Russ was the maintainers deciding privately there was a
> need for a maintainer "who understood our interfaces and modularization
> efforts well" and his PR was merged within 2 days.
>
> If that's the same process to you I don't know what to say. We have
> different perspectives on what constitutes a decision process.
>
> (I'm sure this is clear but just to reiterate in case it isn't none of
> this is a criticism of Russ.)
>
> Thanks
> Michael
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>
> ------- Original Message -------
> On Wednesday, May 10th, 2023 at 17:36, Steve Lee <steven.j.lee@gmail•com>
> wrote:
>
> Blocking Vasil was discussed on a similar GitHub PR. Whether or not one
> agrees or disagrees, the same process is being used. Anyone can NACK and
> give a reason for Russ as well.
>
> On Wed, May 10, 2023 at 8:55 AM Michael Folkson <
> michaelfolkson@protonmail•com> wrote:
>
>> Hi Steve
>>
>> > Isn't this as simple as anyone (in particular Core project
>> contributors) can express their view in this PR?
>> https://github.com/bitcoin/bitcoin/pull/27604
>>
>> Nope. The extent to which the rationale for blocking Vasil as a
>> maintainer applies or doesn't apply to ryanofsky (or future potential
>> maintainers) isn't discussed. From now on the precedent is proposed
>> maintainers can be blocked for unknown and/or potentially inconsistent
>> reasons by the existing maintainers.
>>
>> Thanks
>> Michael
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>>
>> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>>
>> ------- Original Message -------
>> On Wednesday, May 10th, 2023 at 03:44, Steve Lee via bitcoin-dev <
>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> Isn't this as simple as anyone (in particular Core project contributors)
>> can express their view in this PR?
>> https://github.com/bitcoin/bitcoin/pull/27604
>>
>> On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev <
>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>>> On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev <
>>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>
>>>> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
>>>> > Essentially my concern is going forward current maintainers will
>>>> > decide which proposed new maintainers to add and which to block.
>>>>
>>>> This is how a large percentage of organizations are run. The current
>>>> members of a board or other governance group choose who will become a
>>>> new board member.
>>>>
>>>
>>> Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of
>>> independent contributors merging different pull requests or patches. The
>>> github controls are merely because that is how github works. There is also
>>> a secondary issue of people tending to confuse Bitcoin Core with the
>>> bitcoin protocol in general:
>>> https://blog.lopp.net/who-controls-bitcoin-core/
>>>
>>> https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd
>>>
>>> https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427
>>>
>>> - Bryan
>>> https://twitter.com/kanzure
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 16036 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-05-07 7:03 ` Michael Folkson
2023-05-07 17:35 ` David A. Harding
@ 2023-05-10 21:24 ` Andrew Chow
2023-05-11 12:34 ` Michael Folkson
2023-05-11 16:49 ` alicexbt
1 sibling, 2 replies; 28+ messages in thread
From: Andrew Chow @ 2023-05-10 21:24 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 10029 bytes --]
On 05/07/23 03:03 AM, Michael Folkson via bitcoin-dev wrote:
> The decision process for adding a new maintainer was according to the IRC meeting that the maintainers decided privately there was a need for a maintainer “who understood our interfaces and modularization efforts well” and that ryanofsky was a “good fit for that”. I don’t know whether this was decided in a private IRC channel or was decided at the recent in person Core Dev meeting. Regardless, many have had no input into the discussion on what kind of maintainer the project needs going forward and it seems the maintainers do not want to discuss that aspect of the decision.
Since the project began, the decision to seek out and then add a maintainer has always been made by existing maintainers. When the maintainers feel that there is a need for additional maintainers, they may have an open call for volunteers, or may have a candidate already in mind and suggest that specific person for maintainership. Contributors generally are not consulted in the decision to seek a new maintainer as they would not know whether there are things that are being overlooked or that there is maintainership load that needs to be distributed. Even so, it wouldn't be appropriate to add a maintainer if many contributors disagreed with it, just as with any other PR.
We can take a look at how previous maintainers were added to see how this has played out in the past. I think our modern concept of maintainers with nominal scopes began in 2015 with Jonas Schnelli. Both Jonas Schnelli and Marco Falke were simply announced by Wladimir. There was no public discussion, and some IRC logs refer to private emails between the them and the current maintainers at that time. After that, meshcollider was added as a maintainer after a public "call for maintainers" where a recurring topic for a while was finding a maintainer for the wallet. He had volunteered to do it by contacting Wladimir privately before it was discussed during an IRC meeting and then on Github. Fanquake was added as a maintainer during a CoreDev event in Amsterdam during a discussion initiated and led by the maintainers. This was also "private" insofar as the discussion was limited to those in attendance, although there was some opportunity for public discussion in the PR opened on Github. For myself, it was also initially private as I messaged Wladimir to volunteer for it after meshcollider stepped down. There was some discussion on IRC and on Github, but it was also obvious that many already expected me to be the wallet maintainer after meshcollider. Hebasto was added with basically no fanfare or discussion - the only mention I can find is the PR itself. My understanding is that the maintainers asked him he wanted to do it before the PR was opened. Glozow was nominated to be a maintainer by some of the current maintainers, and her nomination was really the first time that there was significant public discussion about it.
Of the past 7 maintainer additions, 5 were nominations/announcements from the current maintainers, one was volunteering following an actual "call for maintainer", and one was an obvious successor. It's obvious and common sense that the maintainers decide when they need help shouldering the load, and then find somebody to help them. There was and always will be some level of private communication prior to any public announcement of the nomination or volunteering of a maintainer. It doesn't make sense to blindside somebody with a nomination without talking to them beforehand. The fact that most of these were non-controversial speaks to how well the maintainers were considering their nominations before publicly announcing them.
It's also clear that we have been moving towards more open discussion about maintainership and who should be maintainers. The process is fundamentally more public than it was previously. We now have public discussion with contributors about the merits of a person, even if that results in said person not becoming a maintainer. Over time, there's been more public participation in the PRs and on IRC meetings when maintainer nominations are brought up. We have nominations as topics during meetings now when they occur. The PRs to add keys are left open for longer to get more discussion.
Ultimately, if you disagree with how the project operates, then you are free to leave and start your own fork that is run in a way that you think is appropriate. This is open source software, no one is beholden to you, and no one is required to do anything.
***
Since you are intent on discussing and re-litigating the decision about Vasil, I will agree that we (the maintainers) could have done a better job of communicating. However we stand by the decision that was made in the end, and we did have a chat with him about it during CoreDev.
It really boils down to three things: 1) we did not ask for a P2P maintainer, 2) some of those who have reviewed Vasil's work expressed discomfort with him being a maintainer, and 3) some contributors and maintainers were uncomfortable with his responses about how he would merge things. You repeatedly insist that it's only the current maintainers who blocked Vasil, but that is not the case. There were concerns brought up by other contributors that contributed to the decision to ultimately NACK his nomination.
> One of the justifications for blocking Vasil Dimov as a new maintainer despite many initial ACKs from maintainers (including Andrew Chow) and long term contributors was according to Andrew [2]:
To be honest, my initial ACK was given without knowing enough information. It was given when he was mostly a name that showed up in my notification emails, and his work had seemed to be fine with me. At that time, I did not think we had a need for a P2P maintainer, but I also did not think that having one would be harmful. However I later spoke to a few others privately who were more familiar with Vasil's work and they had told me that they were not comfortable with Vasil being P2P maintainer.
> “Maintainers inherently need to look at the things that everyone else has already looked at, if only to give it a final once over before merging (but hopefully, an actual review, not just looking it over).”
>
> I follow the Bitcoin Core repo pretty closely and I haven’t seen ryanofsky do this any more than Vasil does. This is not a criticism of ryanofsky, just as I wouldn’t use it as a criticism for Vasil. It would get pretty annoying if everyone who wasn’t a maintainer posted an ACK once many long term contributors had already ACKed to display supposed “desired maintainer traits”. Especially if you are essentially just ACKing that others have done the work to review the PR and you just want to get your ACK on it to increase your ACK count without doing a fraction of what previous reviewers have done.
This opinion was formed not from observing his behavior towards ACK'ing, but rather from his responses to questions about reviewing, in addition to thoughts shared by other contributors.
From having received plenty of reviews from ryanofsky, I can certainly say that his reviews are in depth. He has pointed out subtle bugs, asks questions about very low level details, and has well reasoned critiques and discussions about design decisions. His reviews are high quality, and he's not afraid of being the first person to ACK a pr, the last person to ACK it, or the person to prevent one from being merged even when it already has a few ACKs. We also had a separate discussion with ryanofsky about his approaches to reviewing and merging.
> “I also want to mention that the people who have become maintainers in the past have had this kind of maintainer attitude towards review prior to becoming a maintainer”
>
> Assuming ryanofsky hasn’t had this maintainer attitude in the past (again not a criticism from me at least) does this mean this was a reason to block Vasil but not a reason to block ryanofsky? That seems inconsistent to me.
I don't know why you assume the ryanofsky hasn't had this maintainer attitude? Your claim of inconsistency stems from this assumption that ryanofsky doesn't have a maintainer attitude, but I would argue that he does, as I mentioned above. The idea of adding him as a maintainer has been floated around before, although never really seriously proposed until now, AFAIK.
> When you’re anointed you don’t need to meet requirements but when you’re blocked these requirements will be used to block your addition as a new maintainer?
It seems obvious to me that when the current maintainers approach and nominate a contributor to be a maintainer that that person already meets these requirements. I don't know why you would assume bad faith in that someone who isn't qualified would be nominated by the current maintainers. It's quite frustrating that you seem to just jump straight to the negative conclusion rather than considering that there might be actual reasons based on the merits of the person.
> On a more positive note there does seem to be more energy and momentum for collaboration and open communication on the project since I discussed communication in a previous post [3]. Hopefully this will continue. It doesn’t address my concerns on maintainers and ultimately merge decisions but it definitely seems to me to be a step in a positive direction for the project.
Don't take credit for what you didn't do. The group-wide effort to move towards public discussion again is the result of a discussion that was had at CoreDev. Many cited your behavior as a primary reason to stop discussing things publicly, with things such as dragging project meta discussions onto the mailing list and twitter. These have invited abuse towards maintainers and contributors, which in turn makes them takes those discussions to more private settings. People feel like they're getting sealioned by you (and a few others) when they post publicly, and so they have stopped doing so.
Andrew
[-- Attachment #2: Type: text/html, Size: 13852 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-05-10 21:24 ` Andrew Chow
@ 2023-05-11 12:34 ` Michael Folkson
2023-05-11 16:49 ` alicexbt
1 sibling, 0 replies; 28+ messages in thread
From: Michael Folkson @ 2023-05-11 12:34 UTC (permalink / raw)
To: Andrew Chow, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 13406 bytes --]
Thanks for this Andrew.
> However I later spoke to a few others privately who were more familiar with Vasil's work and they had told me that they were not comfortable with Vasil being P2P maintainer.
Some individuals who will stay anonymous and who were more familiar with Vasil's work than you weren't happy with the standard of his work. Ok I hope they have communicated this to him directly and provided specific examples where he can improve.
> From having received plenty of reviews from ryanofsky, I can certainly say that his reviews are in depth. He has pointed out subtle bugs, asks questions about very low level details, and has well reasoned critiques and discussions about design decisions.
And Vasil didn't provide as in depth reviews when compared to ryanofsky. Again I hope they have communicated this to him directly.
> Many cited your behavior as a primary reason to stop discussing things publicly, with things such as dragging project meta discussions onto the mailing list and twitter. These have invited abuse towards maintainers and contributors, which in turn makes them takes those discussions to more private settings. People feel like they're getting sealioned by you (and a few others) when they post publicly, and so they have stopped doing so.
I have tried over and over again on IRC and on GitHub and I've been ignored. To claim discussions on the bitcoin-dev mailing list invite abuse is just laughable. It is public just like IRC logs and GitHub. If people don't like discussing in public we should give up the pretense and put on the Core README that all important discussions on decision making are done in private and are invite only.
> People feel like they're getting sealioned by you (and a few others) when they post publicly, and so they have stopped doing so.
This is the "rude" and "aggressive" accusation, right. Someone asks questions that maintainers don't want to answer, maintainers accuse them of being "rude" and "aggressive" and then use that as a justification for not answering those questions in the first place. It is a pretty effective strategy. Don't even need to provide examples, just label them and then you can ignore them.
> Since you are intent on discussing and re-litigating the decision about Vasil, I will agree that we (the maintainers) could have done a better job of communicating. However we stand by the decision that was made in the end, and we did have a chat with him about it during CoreDev.
Thanks for at least admitting this on the communication point. If Vasil has been spoken to and is happy with the situation then the situation is much better than I feared. You might think this is re-litigating but the addition, rejection and removal of maintainers is among the most important decisions you can make as a maintainer and perhaps only dwarfed by the merging of consensus changes that can cause chain splits. If anything should be "re-litigated" it should be this.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Wednesday, May 10th, 2023 at 22:24, Andrew Chow via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> On 05/07/23 03:03 AM, Michael Folkson via bitcoin-dev wrote:
>
>> The decision process for adding a new maintainer was according to the IRC meeting that the maintainers decided privately there was a need for a maintainer “who understood our interfaces and modularization efforts well” and that ryanofsky was a “good fit for that”. I don’t know whether this was decided in a private IRC channel or was decided at the recent in person Core Dev meeting. Regardless, many have had no input into the discussion on what kind of maintainer the project needs going forward and it seems the maintainers do not want to discuss that aspect of the decision.
>
> Since the project began, the decision to seek out and then add a maintainer has always been made by existing maintainers. When the maintainers feel that there is a need for additional maintainers, they may have an open call for volunteers, or may have a candidate already in mind and suggest that specific person for maintainership. Contributors generally are not consulted in the decision to seek a new maintainer as they would not know whether there are things that are being overlooked or that there is maintainership load that needs to be distributed. Even so, it wouldn't be appropriate to add a maintainer if many contributors disagreed with it, just as with any other PR.
>
> We can take a look at how previous maintainers were added to see how this has played out in the past. I think our modern concept of maintainers with nominal scopes began in 2015 with Jonas Schnelli. Both Jonas Schnelli and Marco Falke were simply announced by Wladimir. There was no public discussion, and some IRC logs refer to private emails between the them and the current maintainers at that time. After that, meshcollider was added as a maintainer after a public "call for maintainers" where a recurring topic for a while was finding a maintainer for the wallet. He had volunteered to do it by contacting Wladimir privately before it was discussed during an IRC meeting and then on Github. Fanquake was added as a maintainer during a CoreDev event in Amsterdam during a discussion initiated and led by the maintainers. This was also "private" insofar as the discussion was limited to those in attendance, although there was some opportunity for public discussion in the PR opened on Github. For myself, it was also initially private as I messaged Wladimir to volunteer for it after meshcollider stepped down. There was some discussion on IRC and on Github, but it was also obvious that many already expected me to be the wallet maintainer after meshcollider. Hebasto was added with basically no fanfare or discussion - the only mention I can find is the PR itself. My understanding is that the maintainers asked him he wanted to do it before the PR was opened. Glozow was nominated to be a maintainer by some of the current maintainers, and her nomination was really the first time that there was significant public discussion about it.
>
> Of the past 7 maintainer additions, 5 were nominations/announcements from the current maintainers, one was volunteering following an actual "call for maintainer", and one was an obvious successor. It's obvious and common sense that the maintainers decide when they need help shouldering the load, and then find somebody to help them. There was and always will be some level of private communication prior to any public announcement of the nomination or volunteering of a maintainer. It doesn't make sense to blindside somebody with a nomination without talking to them beforehand. The fact that most of these were non-controversial speaks to how well the maintainers were considering their nominations before publicly announcing them.
>
> It's also clear that we have been moving towards more open discussion about maintainership and who should be maintainers. The process is fundamentally more public than it was previously. We now have public discussion with contributors about the merits of a person, even if that results in said person not becoming a maintainer. Over time, there's been more public participation in the PRs and on IRC meetings when maintainer nominations are brought up. We have nominations as topics during meetings now when they occur. The PRs to add keys are left open for longer to get more discussion.
>
> Ultimately, if you disagree with how the project operates, then you are free to leave and start your own fork that is run in a way that you think is appropriate. This is open source software, no one is beholden to you, and no one is required to do anything.
>
> ***
>
> Since you are intent on discussing and re-litigating the decision about Vasil, I will agree that we (the maintainers) could have done a better job of communicating. However we stand by the decision that was made in the end, and we did have a chat with him about it during CoreDev.
>
> It really boils down to three things: 1) we did not ask for a P2P maintainer, 2) some of those who have reviewed Vasil's work expressed discomfort with him being a maintainer, and 3) some contributors and maintainers were uncomfortable with his responses about how he would merge things. You repeatedly insist that it's only the current maintainers who blocked Vasil, but that is not the case. There were concerns brought up by other contributors that contributed to the decision to ultimately NACK his nomination.
>
>> One of the justifications for blocking Vasil Dimov as a new maintainer despite many initial ACKs from maintainers (including Andrew Chow) and long term contributors was according to Andrew [2]:
>
> To be honest, my initial ACK was given without knowing enough information. It was given when he was mostly a name that showed up in my notification emails, and his work had seemed to be fine with me. At that time, I did not think we had a need for a P2P maintainer, but I also did not think that having one would be harmful. However I later spoke to a few others privately who were more familiar with Vasil's work and they had told me that they were not comfortable with Vasil being P2P maintainer.
>
>> “Maintainers inherently need to look at the things that everyone else has already looked at, if only to give it a final once over before merging (but hopefully, an actual review, not just looking it over).”
>>
>> I follow the Bitcoin Core repo pretty closely and I haven’t seen ryanofsky do this any more than Vasil does. This is not a criticism of ryanofsky, just as I wouldn’t use it as a criticism for Vasil. It would get pretty annoying if everyone who wasn’t a maintainer posted an ACK once many long term contributors had already ACKed to display supposed “desired maintainer traits”. Especially if you are essentially just ACKing that others have done the work to review the PR and you just want to get your ACK on it to increase your ACK count without doing a fraction of what previous reviewers have done.
>
> This opinion was formed not from observing his behavior towards ACK'ing, but rather from his responses to questions about reviewing, in addition to thoughts shared by other contributors.
>
> From having received plenty of reviews from ryanofsky, I can certainly say that his reviews are in depth. He has pointed out subtle bugs, asks questions about very low level details, and has well reasoned critiques and discussions about design decisions. His reviews are high quality, and he's not afraid of being the first person to ACK a pr, the last person to ACK it, or the person to prevent one from being merged even when it already has a few ACKs. We also had a separate discussion with ryanofsky about his approaches to reviewing and merging.
>
>> “I also want to mention that the people who have become maintainers in the past have had this kind of maintainer attitude towards review prior to becoming a maintainer”
>>
>> Assuming ryanofsky hasn’t had this maintainer attitude in the past (again not a criticism from me at least) does this mean this was a reason to block Vasil but not a reason to block ryanofsky? That seems inconsistent to me.
>
> I don't know why you assume the ryanofsky hasn't had this maintainer attitude? Your claim of inconsistency stems from this assumption that ryanofsky doesn't have a maintainer attitude, but I would argue that he does, as I mentioned above. The idea of adding him as a maintainer has been floated around before, although never really seriously proposed until now, AFAIK.
>
>> When you’re anointed you don’t need to meet requirements but when you’re blocked these requirements will be used to block your addition as a new maintainer?
>
> It seems obvious to me that when the current maintainers approach and nominate a contributor to be a maintainer that that person already meets these requirements. I don't know why you would assume bad faith in that someone who isn't qualified would be nominated by the current maintainers. It's quite frustrating that you seem to just jump straight to the negative conclusion rather than considering that there might be actual reasons based on the merits of the person.
>
>> On a more positive note there does seem to be more energy and momentum for collaboration and open communication on the project since I discussed communication in a previous post [3]. Hopefully this will continue. It doesn’t address my concerns on maintainers and ultimately merge decisions but it definitely seems to me to be a step in a positive direction for the project.
>
> Don't take credit for what you didn't do. The group-wide effort to move towards public discussion again is the result of a discussion that was had at CoreDev. Many cited your behavior as a primary reason to stop discussing things publicly, with things such as dragging project meta discussions onto the mailing list and twitter. These have invited abuse towards maintainers and contributors, which in turn makes them takes those discussions to more private settings. People feel like they're getting sealioned by you (and a few others) when they post publicly, and so they have stopped doing so.
>
> Andrew
[-- Attachment #2: Type: text/html, Size: 22630 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-05-10 21:24 ` Andrew Chow
2023-05-11 12:34 ` Michael Folkson
@ 2023-05-11 16:49 ` alicexbt
2023-05-11 18:04 ` Steve Lee
1 sibling, 1 reply; 28+ messages in thread
From: alicexbt @ 2023-05-11 16:49 UTC (permalink / raw)
To: Andrew Chow; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 11162 bytes --]
Hi Andrew,
> We can take a look at how previous maintainers were added to see how this has played out in the past.
Can we learn something from past?
Bitcoin's initial release was in 2009 with one developer and few others experimenting with it. It is considered decentralized in 2023 however we have 99% of nodes using bitcoin core, 5 developers deciding what's merged or not and this includes some trying to implement their ideas without soft fork using mempool policies.
We need better process to add maintainers. I am disappointed with the way last last pull request was merged. It says more about maintainers and leader Michael Ford. If you are so scared about opinions on a pull request why not just make him maintainer without pull request?
Maybe you will understand this if your PR to add maintainer was kept open for 4 months.
/dev/fd0
floppy disk
Sent with [Proton Mail](https://proton.me/) secure email.
------- Original Message -------
On Thursday, May 11th, 2023 at 2:54 AM, Andrew Chow via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> On 05/07/23 03:03 AM, Michael Folkson via bitcoin-dev wrote:
>
>> The decision process for adding a new maintainer was according to the IRC meeting that the maintainers decided privately there was a need for a maintainer “who understood our interfaces and modularization efforts well” and that ryanofsky was a “good fit for that”. I don’t know whether this was decided in a private IRC channel or was decided at the recent in person Core Dev meeting. Regardless, many have had no input into the discussion on what kind of maintainer the project needs going forward and it seems the maintainers do not want to discuss that aspect of the decision.
>
> Since the project began, the decision to seek out and then add a maintainer has always been made by existing maintainers. When the maintainers feel that there is a need for additional maintainers, they may have an open call for volunteers, or may have a candidate already in mind and suggest that specific person for maintainership. Contributors generally are not consulted in the decision to seek a new maintainer as they would not know whether there are things that are being overlooked or that there is maintainership load that needs to be distributed. Even so, it wouldn't be appropriate to add a maintainer if many contributors disagreed with it, just as with any other PR.
>
> We can take a look at how previous maintainers were added to see how this has played out in the past. I think our modern concept of maintainers with nominal scopes began in 2015 with Jonas Schnelli. Both Jonas Schnelli and Marco Falke were simply announced by Wladimir. There was no public discussion, and some IRC logs refer to private emails between the them and the current maintainers at that time. After that, meshcollider was added as a maintainer after a public "call for maintainers" where a recurring topic for a while was finding a maintainer for the wallet. He had volunteered to do it by contacting Wladimir privately before it was discussed during an IRC meeting and then on Github. Fanquake was added as a maintainer during a CoreDev event in Amsterdam during a discussion initiated and led by the maintainers. This was also "private" insofar as the discussion was limited to those in attendance, although there was some opportunity for public discussion in the PR opened on Github. For myself, it was also initially private as I messaged Wladimir to volunteer for it after meshcollider stepped down. There was some discussion on IRC and on Github, but it was also obvious that many already expected me to be the wallet maintainer after meshcollider. Hebasto was added with basically no fanfare or discussion - the only mention I can find is the PR itself. My understanding is that the maintainers asked him he wanted to do it before the PR was opened. Glozow was nominated to be a maintainer by some of the current maintainers, and her nomination was really the first time that there was significant public discussion about it.
>
> Of the past 7 maintainer additions, 5 were nominations/announcements from the current maintainers, one was volunteering following an actual "call for maintainer", and one was an obvious successor. It's obvious and common sense that the maintainers decide when they need help shouldering the load, and then find somebody to help them. There was and always will be some level of private communication prior to any public announcement of the nomination or volunteering of a maintainer. It doesn't make sense to blindside somebody with a nomination without talking to them beforehand. The fact that most of these were non-controversial speaks to how well the maintainers were considering their nominations before publicly announcing them.
>
> It's also clear that we have been moving towards more open discussion about maintainership and who should be maintainers. The process is fundamentally more public than it was previously. We now have public discussion with contributors about the merits of a person, even if that results in said person not becoming a maintainer. Over time, there's been more public participation in the PRs and on IRC meetings when maintainer nominations are brought up. We have nominations as topics during meetings now when they occur. The PRs to add keys are left open for longer to get more discussion.
>
> Ultimately, if you disagree with how the project operates, then you are free to leave and start your own fork that is run in a way that you think is appropriate. This is open source software, no one is beholden to you, and no one is required to do anything.
>
> ***
>
> Since you are intent on discussing and re-litigating the decision about Vasil, I will agree that we (the maintainers) could have done a better job of communicating. However we stand by the decision that was made in the end, and we did have a chat with him about it during CoreDev.
>
> It really boils down to three things: 1) we did not ask for a P2P maintainer, 2) some of those who have reviewed Vasil's work expressed discomfort with him being a maintainer, and 3) some contributors and maintainers were uncomfortable with his responses about how he would merge things. You repeatedly insist that it's only the current maintainers who blocked Vasil, but that is not the case. There were concerns brought up by other contributors that contributed to the decision to ultimately NACK his nomination.
>
>> One of the justifications for blocking Vasil Dimov as a new maintainer despite many initial ACKs from maintainers (including Andrew Chow) and long term contributors was according to Andrew [2]:
>
> To be honest, my initial ACK was given without knowing enough information. It was given when he was mostly a name that showed up in my notification emails, and his work had seemed to be fine with me. At that time, I did not think we had a need for a P2P maintainer, but I also did not think that having one would be harmful. However I later spoke to a few others privately who were more familiar with Vasil's work and they had told me that they were not comfortable with Vasil being P2P maintainer.
>
>> “Maintainers inherently need to look at the things that everyone else has already looked at, if only to give it a final once over before merging (but hopefully, an actual review, not just looking it over).”
>>
>> I follow the Bitcoin Core repo pretty closely and I haven’t seen ryanofsky do this any more than Vasil does. This is not a criticism of ryanofsky, just as I wouldn’t use it as a criticism for Vasil. It would get pretty annoying if everyone who wasn’t a maintainer posted an ACK once many long term contributors had already ACKed to display supposed “desired maintainer traits”. Especially if you are essentially just ACKing that others have done the work to review the PR and you just want to get your ACK on it to increase your ACK count without doing a fraction of what previous reviewers have done.
>
> This opinion was formed not from observing his behavior towards ACK'ing, but rather from his responses to questions about reviewing, in addition to thoughts shared by other contributors.
>
> From having received plenty of reviews from ryanofsky, I can certainly say that his reviews are in depth. He has pointed out subtle bugs, asks questions about very low level details, and has well reasoned critiques and discussions about design decisions. His reviews are high quality, and he's not afraid of being the first person to ACK a pr, the last person to ACK it, or the person to prevent one from being merged even when it already has a few ACKs. We also had a separate discussion with ryanofsky about his approaches to reviewing and merging.
>
>> “I also want to mention that the people who have become maintainers in the past have had this kind of maintainer attitude towards review prior to becoming a maintainer”
>>
>> Assuming ryanofsky hasn’t had this maintainer attitude in the past (again not a criticism from me at least) does this mean this was a reason to block Vasil but not a reason to block ryanofsky? That seems inconsistent to me.
>
> I don't know why you assume the ryanofsky hasn't had this maintainer attitude? Your claim of inconsistency stems from this assumption that ryanofsky doesn't have a maintainer attitude, but I would argue that he does, as I mentioned above. The idea of adding him as a maintainer has been floated around before, although never really seriously proposed until now, AFAIK.
>
>> When you’re anointed you don’t need to meet requirements but when you’re blocked these requirements will be used to block your addition as a new maintainer?
>
> It seems obvious to me that when the current maintainers approach and nominate a contributor to be a maintainer that that person already meets these requirements. I don't know why you would assume bad faith in that someone who isn't qualified would be nominated by the current maintainers. It's quite frustrating that you seem to just jump straight to the negative conclusion rather than considering that there might be actual reasons based on the merits of the person.
>
>> On a more positive note there does seem to be more energy and momentum for collaboration and open communication on the project since I discussed communication in a previous post [3]. Hopefully this will continue. It doesn’t address my concerns on maintainers and ultimately merge decisions but it definitely seems to me to be a step in a positive direction for the project.
>
> Don't take credit for what you didn't do. The group-wide effort to move towards public discussion again is the result of a discussion that was had at CoreDev. Many cited your behavior as a primary reason to stop discussing things publicly, with things such as dragging project meta discussions onto the mailing list and twitter. These have invited abuse towards maintainers and contributors, which in turn makes them takes those discussions to more private settings. People feel like they're getting sealioned by you (and a few others) when they post publicly, and so they have stopped doing so.
>
> Andrew
[-- Attachment #2: Type: text/html, Size: 15603 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-05-11 16:49 ` alicexbt
@ 2023-05-11 18:04 ` Steve Lee
2023-05-11 18:48 ` Erik Aronesty
0 siblings, 1 reply; 28+ messages in thread
From: Steve Lee @ 2023-05-11 18:04 UTC (permalink / raw)
To: alicexbt, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 12370 bytes --]
I don't see any reason to be antagonistic in your responses.
One piece of advice I'd offer to you and Michael is to consider whether
your responses are effective. To persuade other people it takes more than
making good points or being right, but you need to find a communication
style and communication path that is effective. My observation is that your
styles need reflection.
On Thu, May 11, 2023 at 10:15 AM alicexbt via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Hi Andrew,
>
> We can take a look at how previous maintainers were added to see how this
> has played out in the past.
>
>
> Can we learn something from past?
>
> Bitcoin's initial release was in 2009 with one developer and few others
> experimenting with it. It is considered decentralized in 2023 however we
> have 99% of nodes using bitcoin core, 5 developers deciding what's merged
> or not and this includes some trying to implement their ideas without soft
> fork using mempool policies.
>
> We need better process to add maintainers. I am disappointed with the way
> last last pull request was merged. It says more about maintainers and
> leader Michael Ford. If you are so scared about opinions on a pull request
> why not just make him maintainer without pull request?
>
> Maybe you will understand this if your PR to add maintainer was kept open
> for 4 months.
>
> /dev/fd0
> floppy disk
>
>
> Sent with Proton Mail <https://proton.me/> secure email.
>
> ------- Original Message -------
> On Thursday, May 11th, 2023 at 2:54 AM, Andrew Chow via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> On 05/07/23 03:03 AM, Michael Folkson via bitcoin-dev wrote:
>
>
> The decision process for adding a new maintainer was according to the IRC
> meeting that the maintainers decided privately there was a need for a
> maintainer “who understood our interfaces and modularization efforts well”
> and that ryanofsky was a “good fit for that”. I don’t know whether this was
> decided in a private IRC channel or was decided at the recent in person
> Core Dev meeting. Regardless, many have had no input into the discussion on
> what kind of maintainer the project needs going forward and it seems the
> maintainers do not want to discuss that aspect of the decision.
>
> Since the project began, the decision to seek out and then add a
> maintainer has always been made by existing maintainers. When the
> maintainers feel that there is a need for additional maintainers, they may
> have an open call for volunteers, or may have a candidate already in mind
> and suggest that specific person for maintainership. Contributors generally
> are not consulted in the decision to seek a new maintainer as they would
> not know whether there are things that are being overlooked or that there
> is maintainership load that needs to be distributed. Even so, it wouldn't
> be appropriate to add a maintainer if many contributors disagreed with it,
> just as with any other PR.
>
> We can take a look at how previous maintainers were added to see how this
> has played out in the past. I think our modern concept of maintainers with
> nominal scopes began in 2015 with Jonas Schnelli. Both Jonas Schnelli and
> Marco Falke were simply announced by Wladimir. There was no public
> discussion, and some IRC logs refer to private emails between the them and
> the current maintainers at that time. After that, meshcollider was added as
> a maintainer after a public "call for maintainers" where a recurring topic
> for a while was finding a maintainer for the wallet. He had volunteered to
> do it by contacting Wladimir privately before it was discussed during an
> IRC meeting and then on Github. Fanquake was added as a maintainer during a
> CoreDev event in Amsterdam during a discussion initiated and led by the
> maintainers. This was also "private" insofar as the discussion was limited
> to those in attendance, although there was some opportunity for public
> discussion in the PR opened on Github. For myself, it was also initially
> private as I messaged Wladimir to volunteer for it after meshcollider
> stepped down. There was some discussion on IRC and on Github, but it was
> also obvious that many already expected me to be the wallet maintainer
> after meshcollider. Hebasto was added with basically no fanfare or
> discussion - the only mention I can find is the PR itself. My understanding
> is that the maintainers asked him he wanted to do it before the PR was
> opened. Glozow was nominated to be a maintainer by some of the current
> maintainers, and her nomination was really the first time that there was
> significant public discussion about it.
>
> Of the past 7 maintainer additions, 5 were nominations/announcements from
> the current maintainers, one was volunteering following an actual "call for
> maintainer", and one was an obvious successor. It's obvious and common
> sense that the maintainers decide when they need help shouldering the load,
> and then find somebody to help them. There was and always will be some
> level of private communication prior to any public announcement of the
> nomination or volunteering of a maintainer. It doesn't make sense to
> blindside somebody with a nomination without talking to them beforehand.
> The fact that most of these were non-controversial speaks to how well the
> maintainers were considering their nominations before publicly announcing
> them.
>
> It's also clear that we have been moving towards more open discussion
> about maintainership and who should be maintainers. The process is
> fundamentally more public than it was previously. We now have public
> discussion with contributors about the merits of a person, even if that
> results in said person not becoming a maintainer. Over time, there's been
> more public participation in the PRs and on IRC meetings when maintainer
> nominations are brought up. We have nominations as topics during meetings
> now when they occur. The PRs to add keys are left open for longer to get
> more discussion.
>
> Ultimately, if you disagree with how the project operates, then you are
> free to leave and start your own fork that is run in a way that you think
> is appropriate. This is open source software, no one is beholden to you,
> and no one is required to do anything.
>
> ***
>
> Since you are intent on discussing and re-litigating the decision about
> Vasil, I will agree that we (the maintainers) could have done a better job
> of communicating. However we stand by the decision that was made in the
> end, and we did have a chat with him about it during CoreDev.
>
> It really boils down to three things: 1) we did not ask for a P2P
> maintainer, 2) some of those who have reviewed Vasil's work expressed
> discomfort with him being a maintainer, and 3) some contributors and
> maintainers were uncomfortable with his responses about how he would merge
> things. You repeatedly insist that it's only the current maintainers who
> blocked Vasil, but that is not the case. There were concerns brought up by
> other contributors that contributed to the decision to ultimately NACK his
> nomination.
>
> One of the justifications for blocking Vasil Dimov as a new maintainer
> despite many initial ACKs from maintainers (including Andrew Chow) and long
> term contributors was according to Andrew [2]:
>
> To be honest, my initial ACK was given without knowing enough information.
> It was given when he was mostly a name that showed up in my notification
> emails, and his work had seemed to be fine with me. At that time, I did not
> think we had a need for a P2P maintainer, but I also did not think that
> having one would be harmful. However I later spoke to a few others
> privately who were more familiar with Vasil's work and they had told me
> that they were not comfortable with Vasil being P2P maintainer.
>
> “Maintainers inherently need to look at the things that everyone else has
> already looked at, if only to give it a final once over before merging (but
> hopefully, an actual review, not just looking it over).”
>
>
> I follow the Bitcoin Core repo pretty closely and I haven’t seen ryanofsky
> do this any more than Vasil does. This is not a criticism of ryanofsky,
> just as I wouldn’t use it as a criticism for Vasil. It would get pretty
> annoying if everyone who wasn’t a maintainer posted an ACK once many long
> term contributors had already ACKed to display supposed “desired maintainer
> traits”. Especially if you are essentially just ACKing that others have
> done the work to review the PR and you just want to get your ACK on it to
> increase your ACK count without doing a fraction of what previous reviewers
> have done.
>
> This opinion was formed not from observing his behavior towards ACK'ing,
> but rather from his responses to questions about reviewing, in addition to
> thoughts shared by other contributors.
>
> From having received plenty of reviews from ryanofsky, I can certainly say
> that his reviews are in depth. He has pointed out subtle bugs, asks
> questions about very low level details, and has well reasoned critiques and
> discussions about design decisions. His reviews are high quality, and he's
> not afraid of being the first person to ACK a pr, the last person to ACK
> it, or the person to prevent one from being merged even when it already has
> a few ACKs. We also had a separate discussion with ryanofsky about his
> approaches to reviewing and merging.
>
> “I also want to mention that the people who have become maintainers in the
> past have had this kind of maintainer attitude towards review prior to
> becoming a maintainer”
>
>
> Assuming ryanofsky hasn’t had this maintainer attitude in the past (again
> not a criticism from me at least) does this mean this was a reason to block
> Vasil but not a reason to block ryanofsky? That seems inconsistent to me.
>
> I don't know why you assume the ryanofsky hasn't had this maintainer
> attitude? Your claim of inconsistency stems from this assumption that
> ryanofsky doesn't have a maintainer attitude, but I would argue that he
> does, as I mentioned above. The idea of adding him as a maintainer has been
> floated around before, although never really seriously proposed until now,
> AFAIK.
>
> When you’re anointed you don’t need to meet requirements but when you’re
> blocked these requirements will be used to block your addition as a new
> maintainer?
>
> It seems obvious to me that when the current maintainers approach and
> nominate a contributor to be a maintainer that that person already meets
> these requirements. I don't know why you would assume bad faith in that
> someone who isn't qualified would be nominated by the current maintainers.
> It's quite frustrating that you seem to just jump straight to the negative
> conclusion rather than considering that there might be actual reasons based
> on the merits of the person.
>
> On a more positive note there does seem to be more energy and momentum for
> collaboration and open communication on the project since I discussed
> communication in a previous post [3]. Hopefully this will continue. It
> doesn’t address my concerns on maintainers and ultimately merge decisions
> but it definitely seems to me to be a step in a positive direction for the
> project.
>
> Don't take credit for what you didn't do. The group-wide effort to move
> towards public discussion again is the result of a discussion that was had
> at CoreDev. Many cited your behavior as a primary reason to stop discussing
> things publicly, with things such as dragging project meta discussions onto
> the mailing list and twitter. These have invited abuse towards maintainers
> and contributors, which in turn makes them takes those discussions to more
> private settings. People feel like they're getting sealioned by you (and a
> few others) when they post publicly, and so they have stopped doing so.
>
>
> Andrew
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 16688 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
2023-05-11 18:04 ` Steve Lee
@ 2023-05-11 18:48 ` Erik Aronesty
0 siblings, 0 replies; 28+ messages in thread
From: Erik Aronesty @ 2023-05-11 18:48 UTC (permalink / raw)
To: Steve Lee, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 13428 bytes --]
i agree 100%. effective communication is challenging, especially in an
environment like this. that being said, alicexbt is probably right that
we
- probably need a well written spec, RFC-style perhaps
- need more anon or nym maintainers where the online reputation isn't
trivially linked to real-world reputation
- github should be replaced with something p2p (maybe move to
https://radicle.xyz/)
meta-stuff like that is probably just as important as picking the next cool
covenant opcode to ignore
On Thu, May 11, 2023 at 2:06 PM Steve Lee via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> I don't see any reason to be antagonistic in your responses.
>
> One piece of advice I'd offer to you and Michael is to consider whether
> your responses are effective. To persuade other people it takes more than
> making good points or being right, but you need to find a communication
> style and communication path that is effective. My observation is that your
> styles need reflection.
>
>
> On Thu, May 11, 2023 at 10:15 AM alicexbt via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> Hi Andrew,
>>
>> We can take a look at how previous maintainers were added to see how this
>> has played out in the past.
>>
>>
>> Can we learn something from past?
>>
>> Bitcoin's initial release was in 2009 with one developer and few others
>> experimenting with it. It is considered decentralized in 2023 however we
>> have 99% of nodes using bitcoin core, 5 developers deciding what's merged
>> or not and this includes some trying to implement their ideas without soft
>> fork using mempool policies.
>>
>> We need better process to add maintainers. I am disappointed with the way
>> last last pull request was merged. It says more about maintainers and
>> leader Michael Ford. If you are so scared about opinions on a pull request
>> why not just make him maintainer without pull request?
>>
>> Maybe you will understand this if your PR to add maintainer was kept open
>> for 4 months.
>>
>> /dev/fd0
>> floppy disk
>>
>>
>> Sent with Proton Mail <https://proton.me/> secure email.
>>
>> ------- Original Message -------
>> On Thursday, May 11th, 2023 at 2:54 AM, Andrew Chow via bitcoin-dev <
>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> On 05/07/23 03:03 AM, Michael Folkson via bitcoin-dev wrote:
>>
>>
>> The decision process for adding a new maintainer was according to the IRC
>> meeting that the maintainers decided privately there was a need for a
>> maintainer “who understood our interfaces and modularization efforts well”
>> and that ryanofsky was a “good fit for that”. I don’t know whether this was
>> decided in a private IRC channel or was decided at the recent in person
>> Core Dev meeting. Regardless, many have had no input into the discussion on
>> what kind of maintainer the project needs going forward and it seems the
>> maintainers do not want to discuss that aspect of the decision.
>>
>> Since the project began, the decision to seek out and then add a
>> maintainer has always been made by existing maintainers. When the
>> maintainers feel that there is a need for additional maintainers, they may
>> have an open call for volunteers, or may have a candidate already in mind
>> and suggest that specific person for maintainership. Contributors generally
>> are not consulted in the decision to seek a new maintainer as they would
>> not know whether there are things that are being overlooked or that there
>> is maintainership load that needs to be distributed. Even so, it wouldn't
>> be appropriate to add a maintainer if many contributors disagreed with it,
>> just as with any other PR.
>>
>> We can take a look at how previous maintainers were added to see how this
>> has played out in the past. I think our modern concept of maintainers with
>> nominal scopes began in 2015 with Jonas Schnelli. Both Jonas Schnelli and
>> Marco Falke were simply announced by Wladimir. There was no public
>> discussion, and some IRC logs refer to private emails between the them and
>> the current maintainers at that time. After that, meshcollider was added as
>> a maintainer after a public "call for maintainers" where a recurring topic
>> for a while was finding a maintainer for the wallet. He had volunteered to
>> do it by contacting Wladimir privately before it was discussed during an
>> IRC meeting and then on Github. Fanquake was added as a maintainer during a
>> CoreDev event in Amsterdam during a discussion initiated and led by the
>> maintainers. This was also "private" insofar as the discussion was limited
>> to those in attendance, although there was some opportunity for public
>> discussion in the PR opened on Github. For myself, it was also initially
>> private as I messaged Wladimir to volunteer for it after meshcollider
>> stepped down. There was some discussion on IRC and on Github, but it was
>> also obvious that many already expected me to be the wallet maintainer
>> after meshcollider. Hebasto was added with basically no fanfare or
>> discussion - the only mention I can find is the PR itself. My understanding
>> is that the maintainers asked him he wanted to do it before the PR was
>> opened. Glozow was nominated to be a maintainer by some of the current
>> maintainers, and her nomination was really the first time that there was
>> significant public discussion about it.
>>
>> Of the past 7 maintainer additions, 5 were nominations/announcements from
>> the current maintainers, one was volunteering following an actual "call for
>> maintainer", and one was an obvious successor. It's obvious and common
>> sense that the maintainers decide when they need help shouldering the load,
>> and then find somebody to help them. There was and always will be some
>> level of private communication prior to any public announcement of the
>> nomination or volunteering of a maintainer. It doesn't make sense to
>> blindside somebody with a nomination without talking to them beforehand.
>> The fact that most of these were non-controversial speaks to how well the
>> maintainers were considering their nominations before publicly announcing
>> them.
>>
>> It's also clear that we have been moving towards more open discussion
>> about maintainership and who should be maintainers. The process is
>> fundamentally more public than it was previously. We now have public
>> discussion with contributors about the merits of a person, even if that
>> results in said person not becoming a maintainer. Over time, there's been
>> more public participation in the PRs and on IRC meetings when maintainer
>> nominations are brought up. We have nominations as topics during meetings
>> now when they occur. The PRs to add keys are left open for longer to get
>> more discussion.
>>
>> Ultimately, if you disagree with how the project operates, then you are
>> free to leave and start your own fork that is run in a way that you think
>> is appropriate. This is open source software, no one is beholden to you,
>> and no one is required to do anything.
>>
>> ***
>>
>> Since you are intent on discussing and re-litigating the decision about
>> Vasil, I will agree that we (the maintainers) could have done a better job
>> of communicating. However we stand by the decision that was made in the
>> end, and we did have a chat with him about it during CoreDev.
>>
>> It really boils down to three things: 1) we did not ask for a P2P
>> maintainer, 2) some of those who have reviewed Vasil's work expressed
>> discomfort with him being a maintainer, and 3) some contributors and
>> maintainers were uncomfortable with his responses about how he would merge
>> things. You repeatedly insist that it's only the current maintainers who
>> blocked Vasil, but that is not the case. There were concerns brought up by
>> other contributors that contributed to the decision to ultimately NACK his
>> nomination.
>>
>> One of the justifications for blocking Vasil Dimov as a new maintainer
>> despite many initial ACKs from maintainers (including Andrew Chow) and long
>> term contributors was according to Andrew [2]:
>>
>> To be honest, my initial ACK was given without knowing enough
>> information. It was given when he was mostly a name that showed up in my
>> notification emails, and his work had seemed to be fine with me. At that
>> time, I did not think we had a need for a P2P maintainer, but I also did
>> not think that having one would be harmful. However I later spoke to a few
>> others privately who were more familiar with Vasil's work and they had told
>> me that they were not comfortable with Vasil being P2P maintainer.
>>
>> “Maintainers inherently need to look at the things that everyone else has
>> already looked at, if only to give it a final once over before merging (but
>> hopefully, an actual review, not just looking it over).”
>>
>>
>> I follow the Bitcoin Core repo pretty closely and I haven’t seen
>> ryanofsky do this any more than Vasil does. This is not a criticism of
>> ryanofsky, just as I wouldn’t use it as a criticism for Vasil. It would get
>> pretty annoying if everyone who wasn’t a maintainer posted an ACK once many
>> long term contributors had already ACKed to display supposed “desired
>> maintainer traits”. Especially if you are essentially just ACKing that
>> others have done the work to review the PR and you just want to get your
>> ACK on it to increase your ACK count without doing a fraction of what
>> previous reviewers have done.
>>
>> This opinion was formed not from observing his behavior towards ACK'ing,
>> but rather from his responses to questions about reviewing, in addition to
>> thoughts shared by other contributors.
>>
>> From having received plenty of reviews from ryanofsky, I can certainly
>> say that his reviews are in depth. He has pointed out subtle bugs, asks
>> questions about very low level details, and has well reasoned critiques and
>> discussions about design decisions. His reviews are high quality, and he's
>> not afraid of being the first person to ACK a pr, the last person to ACK
>> it, or the person to prevent one from being merged even when it already has
>> a few ACKs. We also had a separate discussion with ryanofsky about his
>> approaches to reviewing and merging.
>>
>> “I also want to mention that the people who have become maintainers in
>> the past have had this kind of maintainer attitude towards review prior to
>> becoming a maintainer”
>>
>>
>> Assuming ryanofsky hasn’t had this maintainer attitude in the past (again
>> not a criticism from me at least) does this mean this was a reason to block
>> Vasil but not a reason to block ryanofsky? That seems inconsistent to me.
>>
>> I don't know why you assume the ryanofsky hasn't had this maintainer
>> attitude? Your claim of inconsistency stems from this assumption that
>> ryanofsky doesn't have a maintainer attitude, but I would argue that he
>> does, as I mentioned above. The idea of adding him as a maintainer has been
>> floated around before, although never really seriously proposed until now,
>> AFAIK.
>>
>> When you’re anointed you don’t need to meet requirements but when you’re
>> blocked these requirements will be used to block your addition as a new
>> maintainer?
>>
>> It seems obvious to me that when the current maintainers approach and
>> nominate a contributor to be a maintainer that that person already meets
>> these requirements. I don't know why you would assume bad faith in that
>> someone who isn't qualified would be nominated by the current maintainers.
>> It's quite frustrating that you seem to just jump straight to the negative
>> conclusion rather than considering that there might be actual reasons based
>> on the merits of the person.
>>
>> On a more positive note there does seem to be more energy and momentum
>> for collaboration and open communication on the project since I discussed
>> communication in a previous post [3]. Hopefully this will continue. It
>> doesn’t address my concerns on maintainers and ultimately merge decisions
>> but it definitely seems to me to be a step in a positive direction for the
>> project.
>>
>> Don't take credit for what you didn't do. The group-wide effort to move
>> towards public discussion again is the result of a discussion that was had
>> at CoreDev. Many cited your behavior as a primary reason to stop discussing
>> things publicly, with things such as dragging project meta discussions onto
>> the mailing list and twitter. These have invited abuse towards maintainers
>> and contributors, which in turn makes them takes those discussions to more
>> private settings. People feel like they're getting sealioned by you (and a
>> few others) when they post publicly, and so they have stopped doing so.
>>
>>
>> Andrew
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 18121 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2023-05-11 18:48 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-18 12:40 [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions Michael Folkson
2023-04-19 0:56 ` Erik Aronesty
2023-04-19 10:09 ` Michael Folkson
2023-04-19 12:24 ` alicexbt
2023-04-19 13:33 ` Michael Folkson
2023-04-19 21:13 ` alicexbt
2023-04-19 15:17 ` Aymeric Vitte
2023-04-19 21:33 ` Andrew Chow
2023-04-20 8:45 ` Michael Folkson
2023-04-20 10:54 ` Aymeric Vitte
2023-04-20 13:59 ` Erik Aronesty
2023-04-20 14:25 ` Aymeric Vitte
2023-04-20 2:27 ` Anthony Towns
2023-04-20 9:24 ` Michael Folkson
2023-05-07 7:03 ` Michael Folkson
2023-05-07 17:35 ` David A. Harding
2023-05-08 9:36 ` Michael Folkson
2023-05-08 12:03 ` Bryan Bishop
2023-05-10 2:44 ` Steve Lee
2023-05-10 15:55 ` Michael Folkson
2023-05-10 16:36 ` Steve Lee
2023-05-10 17:22 ` Michael Folkson
2023-05-10 18:29 ` Steve Lee
2023-05-10 21:24 ` Andrew Chow
2023-05-11 12:34 ` Michael Folkson
2023-05-11 16:49 ` alicexbt
2023-05-11 18:04 ` Steve Lee
2023-05-11 18:48 ` Erik Aronesty
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox