Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Erik Aronesty via bitcoin-dev]

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  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 

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Steve Lee via bitcoin-dev]

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  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 

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[alicexbt via bitcoin-dev]

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 
 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 
> 

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Michael Folkson via bitcoin-dev]

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 
 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 

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Andrew Chow via bitcoin-dev]

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) 

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Steve Lee via bitcoin-dev]

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 <
michaelfolk...@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 
> 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 <
> michaelfolk...@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
>>>
>>
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Michael Folkson via bitcoin-dev]

> 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  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 
>  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 
>>  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 
>>>  wrote:
>>>
 On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev 
  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___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Steve Lee via bitcoin-dev]

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 <
michaelfolk...@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
>>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Michael Folkson via bitcoin-dev]

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 
 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 
>  wrote:
>
>> On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev 
>>  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___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Steve Lee via bitcoin-dev]

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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Bryan Bishop via bitcoin-dev]

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

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Michael Folkson via bitcoin-dev]

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  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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[David A. Harding via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Michael Folkson via bitcoin-dev]

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 
 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 

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Aymeric Vitte via bitcoin-dev]

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
>  > 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
> 

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Erik Aronesty via bitcoin-dev]

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
> > 

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Aymeric Vitte via bitcoin-dev]

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 

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Michael Folkson via bitcoin-dev]

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 
 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 

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Michael Folkson via bitcoin-dev]

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  
wrote:


> On Tue, Apr 18, 2023 at 12:40:44PM +, 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Anthony Towns via bitcoin-dev]

On Tue, Apr 18, 2023 at 12:40:44PM +, 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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[alicexbt via bitcoin-dev]

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 
 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 alice...@protonmail.com 
> wrote:
> 
> 
> 
> > Hi 

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Andrew Chow via 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 

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Aymeric Vitte via bitcoin-dev]

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 

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Michael Folkson via bitcoin-dev]

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  
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 

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[alicexbt via bitcoin-dev]

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 bytes144"

> 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 
 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. 

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Michael Folkson via bitcoin-dev]

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  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 
>  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 

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Erik Aronesty via bitcoin-dev]

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