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 <d...@dtrt.org> wrote:
> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
>
> > Essentially my concern is going forward current maintainers will
> > decide which proposed new maintainers to add and which to block.
>
>
> This is how a large percentage of organizations are run. The current
> members of a board or other governance group choose who will become a
> new board member.
>
> One alternative to self-perpetuating governance is membership voting,
> but building and maintaining democratic institutions is hard and not a
> good fit for many types of endeavors---the building of highly technical
> software being one of those cases IMO.
>
> I think the questions we want to ask is whether the current set of
> maintainers is capable of moving Bitcoin Core in the direction we want
> and what we can do about it if we conclude that they are ill-suited (or
> malicious). For the first question, I think that's something everyone
> needs to answer for themselves, as we may each have different visions
> for the future of the project. That said, I note that several
> initiatives championed by the current maintainers in the IRC meeting you
> mention received overwhelmingly positive support from a significant
> number of current contributors, which seems like a healthy sign to me.
>
> For the second question, I think AJ Towns already answered that quite
> well (though he was talking about a different project):
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021578.html
>
> Finally, I don't think this matter warranted a post to this mailing
> list. Discussion about internal project decisions, such as who should
> have merge access and what maintainers should communicate in PRs, belong
> in communication channels dedicated to that project.
>
> -Dave
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
