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.
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.
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.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]:
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.“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 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.“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.
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.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?
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.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.