public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Michael Folkson <michaelfolkson@protonmail.com>
To: "David A. Harding" <dave@dtrt.org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
Date: Mon, 08 May 2023 09:36:27 +0000	[thread overview]
Message-ID: <tK-uLnT7l8aprKJgs8SZAuWUfoWiZUnUrkFVNG6E4kaXjRzkK7CMj6xGSYrHoSmsGdzUYY6B6pp-hDtixTohE22yu2PsBi6GDOgKR-u1bzQ=@protonmail.com> (raw)
In-Reply-To: <f2912dbbad28db5139e8df13f52e082d@dtrt.org>

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@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


  reply	other threads:[~2023-05-08  9:36 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-18 12:40 [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions Michael Folkson
2023-04-19  0:56 ` Erik Aronesty
2023-04-19 10:09   ` Michael Folkson
2023-04-19 12:24 ` alicexbt
2023-04-19 13:33   ` Michael Folkson
2023-04-19 21:13     ` alicexbt
2023-04-19 15:17 ` Aymeric Vitte
2023-04-19 21:33 ` Andrew Chow
2023-04-20  8:45   ` Michael Folkson
2023-04-20 10:54   ` Aymeric Vitte
2023-04-20 13:59     ` Erik Aronesty
2023-04-20 14:25       ` Aymeric Vitte
2023-04-20  2:27 ` Anthony Towns
2023-04-20  9:24   ` Michael Folkson
2023-05-07  7:03 ` Michael Folkson
2023-05-07 17:35   ` David A. Harding
2023-05-08  9:36     ` Michael Folkson [this message]
2023-05-08 12:03     ` Bryan Bishop
2023-05-10  2:44       ` Steve Lee
2023-05-10 15:55         ` Michael Folkson
2023-05-10 16:36           ` Steve Lee
2023-05-10 17:22             ` Michael Folkson
2023-05-10 18:29               ` Steve Lee
2023-05-10 21:24   ` Andrew Chow
2023-05-11 12:34     ` Michael Folkson
2023-05-11 16:49     ` alicexbt
2023-05-11 18:04       ` Steve Lee
2023-05-11 18:48         ` Erik Aronesty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='tK-uLnT7l8aprKJgs8SZAuWUfoWiZUnUrkFVNG6E4kaXjRzkK7CMj6xGSYrHoSmsGdzUYY6B6pp-hDtixTohE22yu2PsBi6GDOgKR-u1bzQ=@protonmail.com' \
    --to=michaelfolkson@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=dave@dtrt.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox