1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
Return-Path: <michaelfolkson@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id F1317C002A
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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" <dave@dtrt.org>
From: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <tK-uLnT7l8aprKJgs8SZAuWUfoWiZUnUrkFVNG6E4kaXjRzkK7CMj6xGSYrHoSmsGdzUYY6B6pp-hDtixTohE22yu2PsBi6GDOgKR-u1bzQ=@protonmail.com>
In-Reply-To: <f2912dbbad28db5139e8df13f52e082d@dtrt.org>
References: <uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=@protonmail.com>
<qLlgx_AotByY1ZZHTCn3BBK7x1spKEYYd3UP4txYq-RceoclKdVAB1E5MJ4FTV7bWVP1Ilsdbmn43dkrOfqw84EUUQAvnkztN9FY1R5oDOA=@protonmail.com>
<f2912dbbad28db5139e8df13f52e082d@dtrt.org>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <dave@dtrt.org> 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
|
