What is Nostr?
Michael Folkson [ARCHIVE] /
npub103y…kpam
2023-06-07 23:21:18
in reply to nevent1q…kep2

Michael Folkson [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-08 🗒️ Summary of this message: A contributor ...

📅 Original date posted:2023-05-08
🗒️ Summary of this message: A contributor expresses concern that maintainers are making decisions without input from long-term contributors, and blocking potential maintainers without explanation. They believe decisions should be discussed in public meetings.
📝 Original message: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 <dave at 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
Author Public Key
npub103ycruxnchhvja33mcnnkfdkgd0s7vlqlfkvufcdm5lnhpuh6f4q82kpam