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

[Erik Aronesty <erik@q32.com>]

[-- Attachment #1: Type: text/plain, Size: 13428 bytes --]

i agree 100%.   effective communication is challenging, especially in an
environment like this.   that being said, alicexbt is probably right that
we

 - probably need a well written spec, RFC-style perhaps
 - need more anon or nym maintainers where the online reputation isn't
trivially linked to real-world reputation
 - github should be replaced with something p2p (maybe move to
https://radicle.xyz/)

meta-stuff like that is probably just as important as picking the next cool
covenant opcode to ignore

On Thu, May 11, 2023 at 2:06 PM Steve Lee via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I don't see any reason to be antagonistic in your responses.
>
> One piece of advice I'd offer to you and Michael is to consider whether
> your responses are effective. To persuade other people it takes more than
> making good points or being right, but you need to find a communication
> style and communication path that is effective. My observation is that your
> styles need reflection.
>
>
> On Thu, May 11, 2023 at 10:15 AM alicexbt via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Andrew,
>>
>> We can take a look at how previous maintainers were added to see how this
>> has played out in the past.
>>
>>
>> Can we learn something from past?
>>
>> Bitcoin's initial release was in 2009 with one developer and few others
>> experimenting with it. It is considered decentralized in 2023 however we
>> have 99% of nodes using bitcoin core, 5 developers deciding what's merged
>> or not and this includes some trying to implement their ideas without soft
>> fork using mempool policies.
>>
>> We need better process to add maintainers. I am disappointed with the way
>> last last pull request was merged. It says more about maintainers and
>> leader Michael Ford. If you are so scared about opinions on a pull request
>> why not just make him maintainer without pull request?
>>
>> Maybe you will understand this if your PR to add maintainer was kept open
>> for 4 months.
>>
>> /dev/fd0
>> floppy disk
>>
>>
>> Sent with Proton Mail <https://proton.me/> secure email.
>>
>> ------- Original Message -------
>> On Thursday, May 11th, 2023 at 2:54 AM, Andrew Chow via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> On 05/07/23 03:03 AM, Michael Folkson via bitcoin-dev wrote:
>>
>>
>> The decision process for adding a new maintainer was according to the IRC
>> meeting that the maintainers decided privately there was a need for a
>> maintainer “who understood our interfaces and modularization efforts well”
>> and that ryanofsky was a “good fit for that”. I don’t know whether this was
>> decided in a private IRC channel or was decided at the recent in person
>> Core Dev meeting. Regardless, many have had no input into the discussion on
>> what kind of maintainer the project needs going forward and it seems the
>> maintainers do not want to discuss that aspect of the decision.
>>
>> Since the project began, the decision to seek out and then add a
>> maintainer has always been made by existing maintainers. When the
>> maintainers feel that there is a need for additional maintainers, they may
>> have an open call for volunteers, or may have a candidate already in mind
>> and suggest that specific person for maintainership. Contributors generally
>> are not consulted in the decision to seek a new maintainer as they would
>> not know whether there are things that are being overlooked or that there
>> is maintainership load that needs to be distributed. Even so, it wouldn't
>> be appropriate to add a maintainer if many contributors disagreed with it,
>> just as with any other PR.
>>
>> We can take a look at how previous maintainers were added to see how this
>> has played out in the past. I think our modern concept of maintainers with
>> nominal scopes began in 2015 with Jonas Schnelli. Both Jonas Schnelli and
>> Marco Falke were simply announced by Wladimir. There was no public
>> discussion, and some IRC logs refer to private emails between the them and
>> the current maintainers at that time. After that, meshcollider was added as
>> a maintainer after a public "call for maintainers" where a recurring topic
>> for a while was finding a maintainer for the wallet. He had volunteered to
>> do it by contacting Wladimir privately before it was discussed during an
>> IRC meeting and then on Github. Fanquake was added as a maintainer during a
>> CoreDev event in Amsterdam during a discussion initiated and led by the
>> maintainers. This was also "private" insofar as the discussion was limited
>> to those in attendance, although there was some opportunity for public
>> discussion in the PR opened on Github. For myself, it was also initially
>> private as I messaged Wladimir to volunteer for it after meshcollider
>> stepped down. There was some discussion on IRC and on Github, but it was
>> also obvious that many already expected me to be the wallet maintainer
>> after meshcollider. Hebasto was added with basically no fanfare or
>> discussion - the only mention I can find is the PR itself. My understanding
>> is that the maintainers asked him he wanted to do it before the PR was
>> opened. Glozow was nominated to be a maintainer by some of the current
>> maintainers, and her nomination was really the first time that there was
>> significant public discussion about it.
>>
>> Of the past 7 maintainer additions, 5 were nominations/announcements from
>> the current maintainers, one was volunteering following an actual "call for
>> maintainer", and one was an obvious successor. It's obvious and common
>> sense that the maintainers decide when they need help shouldering the load,
>> and then find somebody to help them. There was and always will be some
>> level of private communication prior to any public announcement of the
>> nomination or volunteering of a maintainer. It doesn't make sense to
>> blindside somebody with a nomination without talking to them beforehand.
>> The fact that most of these were non-controversial speaks to how well the
>> maintainers were considering their nominations before publicly announcing
>> them.
>>
>> It's also clear that we have been moving towards more open discussion
>> about maintainership and who should be maintainers. The process is
>> fundamentally more public than it was previously. We now have public
>> discussion with contributors about the merits of a person, even if that
>> results in said person not becoming a maintainer. Over time, there's been
>> more public participation in the PRs and on IRC meetings when maintainer
>> nominations are brought up. We have nominations as topics during meetings
>> now when they occur. The PRs to add keys are left open for longer to get
>> more discussion.
>>
>> Ultimately, if you disagree with how the project operates, then you are
>> free to leave and start your own fork that is run in a way that you think
>> is appropriate. This is open source software, no one is beholden to you,
>> and no one is required to do anything.
>>
>> ***
>>
>> Since you are intent on discussing and re-litigating the decision about
>> Vasil, I will agree that we (the maintainers) could have done a better job
>> of communicating. However we stand by the decision that was made in the
>> end, and we did have a chat with him about it during CoreDev.
>>
>> It really boils down to three things: 1) we did not ask for a P2P
>> maintainer, 2) some of those who have reviewed Vasil's work expressed
>> discomfort with him being a maintainer, and 3) some contributors and
>> maintainers were uncomfortable with his responses about how he would merge
>> things. You repeatedly insist that it's only the current maintainers who
>> blocked Vasil, but that is not the case. There were concerns brought up by
>> other contributors that contributed to the decision to ultimately NACK his
>> nomination.
>>
>> One of the justifications for blocking Vasil Dimov as a new maintainer
>> despite many initial ACKs from maintainers (including Andrew Chow) and long
>> term contributors was according to Andrew [2]:
>>
>> To be honest, my initial ACK was given without knowing enough
>> information. It was given when he was mostly a name that showed up in my
>> notification emails, and his work had seemed to be fine with me. At that
>> time, I did not think we had a need for a P2P maintainer, but I also did
>> not think that having one would be harmful. However I later spoke to a few
>> others privately who were more familiar with Vasil's work and they had told
>> me that they were not comfortable with Vasil being P2P maintainer.
>>
>> “Maintainers inherently need to look at the things that everyone else has
>> already looked at, if only to give it a final once over before merging (but
>> hopefully, an actual review, not just looking it over).”
>>
>>
>> I follow the Bitcoin Core repo pretty closely and I haven’t seen
>> ryanofsky do this any more than Vasil does. This is not a criticism of
>> ryanofsky, just as I wouldn’t use it as a criticism for Vasil. It would get
>> pretty annoying if everyone who wasn’t a maintainer posted an ACK once many
>> long term contributors had already ACKed to display supposed “desired
>> maintainer traits”. Especially if you are essentially just ACKing that
>> others have done the work to review the PR and you just want to get your
>> ACK on it to increase your ACK count without doing a fraction of what
>> previous reviewers have done.
>>
>> This opinion was formed not from observing his behavior towards ACK'ing,
>> but rather from his responses to questions about reviewing, in addition to
>> thoughts shared by other contributors.
>>
>> From having received plenty of reviews from ryanofsky, I can certainly
>> say that his reviews are in depth. He has pointed out subtle bugs, asks
>> questions about very low level details, and has well reasoned critiques and
>> discussions about design decisions. His reviews are high quality, and he's
>> not afraid of being the first person to ACK a pr, the last person to ACK
>> it, or the person to prevent one from being merged even when it already has
>> a few ACKs. We also had a separate discussion with ryanofsky about his
>> approaches to reviewing and merging.
>>
>> “I also want to mention that the people who have become maintainers in
>> the past have had this kind of maintainer attitude towards review prior to
>> becoming a maintainer”
>>
>>
>> Assuming ryanofsky hasn’t had this maintainer attitude in the past (again
>> not a criticism from me at least) does this mean this was a reason to block
>> Vasil but not a reason to block ryanofsky? That seems inconsistent to me.
>>
>> I don't know why you assume the ryanofsky hasn't had this maintainer
>> attitude? Your claim of inconsistency stems from this assumption that
>> ryanofsky doesn't have a maintainer attitude, but I would argue that he
>> does, as I mentioned above. The idea of adding him as a maintainer has been
>> floated around before, although never really seriously proposed until now,
>> AFAIK.
>>
>> When you’re anointed you don’t need to meet requirements but when you’re
>> blocked these requirements will be used to block your addition as a new
>> maintainer?
>>
>> It seems obvious to me that when the current maintainers approach and
>> nominate a contributor to be a maintainer that that person already meets
>> these requirements. I don't know why you would assume bad faith in that
>> someone who isn't qualified would be nominated by the current maintainers.
>> It's quite frustrating that you seem to just jump straight to the negative
>> conclusion rather than considering that there might be actual reasons based
>> on the merits of the person.
>>
>> On a more positive note there does seem to be more energy and momentum
>> for collaboration and open communication on the project since I discussed
>> communication in a previous post [3]. Hopefully this will continue. It
>> doesn’t address my concerns on maintainers and ultimately merge decisions
>> but it definitely seems to me to be a step in a positive direction for the
>> project.
>>
>> Don't take credit for what you didn't do. The group-wide effort to move
>> towards public discussion again is the result of a discussion that was had
>> at CoreDev. Many cited your behavior as a primary reason to stop discussing
>> things publicly, with things such as dragging project meta discussions onto
>> the mailing list and twitter. These have invited abuse towards maintainers
>> and contributors, which in turn makes them takes those discussions to more
>> private settings. People feel like they're getting sealioned by you (and a
>> few others) when they post publicly, and so they have stopped doing so.
>>
>>
>> Andrew
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 18121 bytes --]