Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id F1317C002A for ; Mon, 8 May 2023 09:36:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id B6D9A41AEC for ; Mon, 8 May 2023 09:36:45 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org B6D9A41AEC Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=fCJ0WZJg X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0N6pSYREni4x for ; Mon, 8 May 2023 09:36:44 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org C5CE141A43 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by smtp4.osuosl.org (Postfix) with ESMTPS id C5CE141A43 for ; Mon, 8 May 2023 09:36:43 +0000 (UTC) Date: Mon, 08 May 2023 09:36:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1683538601; x=1683797801; bh=o5KIxxhr3hFiz9R3rH1WlIqvBTm+cb81SiFNxFLkKt8=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=fCJ0WZJgLZ+xDiaRbKntMfkAeNSIzKq8AHmvDwiKVQIqcS21xY4zENhV1mo7DLN38 LijmhBRYQCeFFJwppnQYESH3/IYhFVnUF7fd8bA3a8fww9v+JFwvhxievcW32h76iS mtanmJn2ckW0b218pSWnmIv7UiXvDp9eFteGOFkon5IfbZZOyfxas/DsnAkuPDVfy2 fRC+eW0HsXDVa1miavLCfZ2UaHBMLq3WJnv9N3EMaBuKUH33NI8VjMjRSTW9mnzCCR ml/hCi8YfHDg1MmVictt5Dz7KGv2QDwqSdCMU1jqTwQxv1VBt16wtQRRXgR+HXvM5e XYetU2lgoT1og== To: "David A. Harding" From: Michael Folkson Message-ID: In-Reply-To: References: Feedback-ID: 27732268:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 08 May 2023 11:54:58 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2023 09:36:46 -0000 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 mem= bers of a board or other governance group choose who will become a new boar= d member. So long term contributors who aren't maintainers don't get input into the d= ecision? It is starting to seem like the maintainer role is moving from a j= anitorial one to where maintainers make decisions without discussing those = decisions with long term contributors and in some cases even bothering to e= xplain the rationale for those decisions to a broader audience that include= s long term contributors. This unfortunately makes the decision on who beco= mes a maintainer even more important.=20 Decisions have to be made but I was always under the impression that they w= ould be discussed in open, public IRC meetings with at least other long ter= m contributors present and then decisions would be made based on the views = expressed in that meeting. An appointed board or governance group ("the mai= ntainers") 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 merg= e access and what maintainers should communicate in PRs, belong in communic= ation channels dedicated to that project. I have tried. As I said in previous emails in the Vasil maintainer case I a= sked fanquake, Gloria repeatedly over a period of 5 months why Vasil was be= ing 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 o= n this topic on IRC. Especially as I expect they'll be ignored anyway as th= ey 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. An= d fanquake, Gloria not being willing to discuss why publicly for 5 months w= as a second red flag. If that is the precedent for merge decisions anything= is possible in the future including in the worst case contentious consensu= s 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 wrote: > On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote: >=20 > > Essentially my concern is going forward current maintainers will > > decide which proposed new maintainers to add and which to block. >=20 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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 >=20 > 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. >=20 > -Dave