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
