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
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
|
Return-Path: <steven.j.lee@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 94791C002A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 May 2023 18:04:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 7C96083C4D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 May 2023 18:04:22 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 7C96083C4D
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20221208 header.b=gZvmPKvf
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id qC-Y-oncVv1Y
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 May 2023 18:04:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 660E783C1B
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com
[IPv6:2607:f8b0:4864:20::1029])
by smtp1.osuosl.org (Postfix) with ESMTPS id 660E783C1B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 May 2023 18:04:20 +0000 (UTC)
Received: by mail-pj1-x1029.google.com with SMTP id
98e67ed59e1d1-24ddf274039so6195957a91.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 May 2023 11:04:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1683828260; x=1686420260;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=6Pip6jzzUmFZxdmbAk8DQZCHnaEZdROBa7urWT49bqI=;
b=gZvmPKvfH8bY/lqsy2BThtFjGeA1eR9toJHGaoy1FqPlzC13/P3VnF3RC5n4tHR5DK
D7nX33LCAgtOKuDZpGhr09XctXfzLYPZIU0+lkjD3cAt0RaRBFxUhXrSgTHcOtHoIfzR
RZ+9gSXkVHpAC09liPZDX0maTgPtGsfk3Hw/MIj/nYws9s1ACeNPbTROIg4YRLQ2oaDc
tPxCD2r41q+ISO+RstsiaIYrPLD+LTdX83ui1adfIlOP+6GFsor98oIVZwdTb6dX+cy7
2nSDf3YNSRngv6aU2lRKjr1oCkniU/0eJbPmyGPEqxptBMHCTdvyKySIbuL9xYO7mm6J
A8Bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1683828260; x=1686420260;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=6Pip6jzzUmFZxdmbAk8DQZCHnaEZdROBa7urWT49bqI=;
b=jT9Z1s/uoN8Xr8dee3Jn1hyBXxhOgyJIqf+3lx8AadVgHpx9MuV27LP6cy6ZYwLRZV
KedNFRULx4YkrcTtqzo33AQzmlOisHgkdO/QFAqU+aprYURKyTA0jtg02roQSxoVTXBi
B1kKy2v9vJMuaNn+d92/mjGHtXMfGR7wUdt0jtFsjR0t2jeh/m/hHk/CVtXdpat+Ju9/
M9VxxmhUyNQEq0Iuzqw/YAnO952mv2zjq5qzcZfBQOtRa0BrMzBwoDUYiOS8qmt5YR3u
fVDe+vJnmDmTQjT7ACKdoJ68r/MoFuXakNPqs6TmIGGE0XJULQEjCgnLfib0YqMz27VO
g+NQ==
X-Gm-Message-State: AC+VfDy4r+Z11f2pLaS7iOmtXF02f4l+ZhoCotSWqf5npp17Ei0zfl56
CpWOmNPp9vZIOyK4rNqtMXGIsP00RY8vVOM6BNI=
X-Google-Smtp-Source: ACHHUZ7aDSdL33W3wbdZsNQzcP0Mc+81KbB2/3cRpy/APKUS0UsuUE9lLl7HH8laRL1Odvzaqg0AvaqCd0/thVzYnhg=
X-Received: by 2002:a17:90a:d30f:b0:250:4847:8d71 with SMTP id
p15-20020a17090ad30f00b0025048478d71mr20116388pju.32.1683828259446; Thu, 11
May 2023 11:04:19 -0700 (PDT)
MIME-Version: 1.0
References: <uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=@protonmail.com>
<qLlgx_AotByY1ZZHTCn3BBK7x1spKEYYd3UP4txYq-RceoclKdVAB1E5MJ4FTV7bWVP1Ilsdbmn43dkrOfqw84EUUQAvnkztN9FY1R5oDOA=@protonmail.com>
<d03b42fb-ffbf-1bc4-16c0-746acd3b73c4@achow101.com>
<mkQ79t2QvpsdXlMPbQPb1Mwvde-X6BfkYFDhFtaRCw6xjCoAfG4_w1Del064RKkC4gV2-uj2ROD7VhCyEEE_lxj3oW3Sa2WL2kVfD_nVOSs=@protonmail.com>
In-Reply-To: <mkQ79t2QvpsdXlMPbQPb1Mwvde-X6BfkYFDhFtaRCw6xjCoAfG4_w1Del064RKkC4gV2-uj2ROD7VhCyEEE_lxj3oW3Sa2WL2kVfD_nVOSs=@protonmail.com>
From: Steve Lee <steven.j.lee@gmail.com>
Date: Thu, 11 May 2023 11:04:08 -0700
Message-ID: <CABu3BAcGJZnYb-Lun9T-Fqh1C5htd=P2UQxed5H8jmgsKjTcLA@mail.gmail.com>
To: alicexbt <alicexbt@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000044646b05fb6ed1ca"
X-Mailman-Approved-At: Thu, 11 May 2023 18:06:00 +0000
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: Thu, 11 May 2023 18:04:22 -0000
--00000000000044646b05fb6ed1ca
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I don't see any reason to be antagonistic in your responses.
One piece of advice I'd offer to you and Michael is to consider whether
your responses are effective. To persuade other people it takes more than
making good points or being right, but you need to find a communication
style and communication path that is effective. My observation is that your
styles need reflection.
On Thu, May 11, 2023 at 10:15=E2=80=AFAM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Andrew,
>
> We can take a look at how previous maintainers were added to see how this
> has played out in the past.
>
>
> Can we learn something from past?
>
> Bitcoin's initial release was in 2009 with one developer and few others
> experimenting with it. It is considered decentralized in 2023 however we
> have 99% of nodes using bitcoin core, 5 developers deciding what's merged
> or not and this includes some trying to implement their ideas without sof=
t
> fork using mempool policies.
>
> We need better process to add maintainers. I am disappointed with the way
> last last pull request was merged. It says more about maintainers and
> leader Michael Ford. If you are so scared about opinions on a pull reques=
t
> why not just make him maintainer without pull request?
>
> Maybe you will understand this if your PR to add maintainer was kept open
> for 4 months.
>
> /dev/fd0
> floppy disk
>
>
> Sent with Proton Mail <https://proton.me/> secure email.
>
> ------- Original Message -------
> On Thursday, May 11th, 2023 at 2:54 AM, Andrew Chow via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On 05/07/23 03:03 AM, Michael Folkson via bitcoin-dev wrote:
>
>
> The decision process for adding a new maintainer was according to the IRC
> meeting that the maintainers decided privately there was a need for a
> maintainer =E2=80=9Cwho understood our interfaces and modularization effo=
rts well=E2=80=9D
> and that ryanofsky was a =E2=80=9Cgood fit for that=E2=80=9D. I don=E2=80=
=99t know whether this was
> decided in a private IRC channel or was decided at the recent in person
> Core Dev meeting. Regardless, many have had no input into the discussion =
on
> what kind of maintainer the project needs going forward and it seems the
> maintainers do not want to discuss that aspect of the decision.
>
> Since the project began, the decision to seek out and then add a
> maintainer has always been made by existing maintainers. When the
> maintainers feel that there is a need for additional maintainers, they ma=
y
> have an open call for volunteers, or may have a candidate already in mind
> and suggest that specific person for maintainership. Contributors general=
ly
> are not consulted in the decision to seek a new maintainer as they would
> not know whether there are things that are being overlooked or that there
> is maintainership load that needs to be distributed. Even so, it wouldn't
> be appropriate to add a maintainer if many contributors disagreed with it=
,
> just as with any other PR.
>
> We can take a look at how previous maintainers were added to see how this
> has played out in the past. I think our modern concept of maintainers wit=
h
> nominal scopes began in 2015 with Jonas Schnelli. Both Jonas Schnelli and
> Marco Falke were simply announced by Wladimir. There was no public
> discussion, and some IRC logs refer to private emails between the them an=
d
> the current maintainers at that time. After that, meshcollider was added =
as
> a maintainer after a public "call for maintainers" where a recurring topi=
c
> for a while was finding a maintainer for the wallet. He had volunteered t=
o
> do it by contacting Wladimir privately before it was discussed during an
> IRC meeting and then on Github. Fanquake was added as a maintainer during=
a
> CoreDev event in Amsterdam during a discussion initiated and led by the
> maintainers. This was also "private" insofar as the discussion was limite=
d
> to those in attendance, although there was some opportunity for public
> discussion in the PR opened on Github. For myself, it was also initially
> private as I messaged Wladimir to volunteer for it after meshcollider
> stepped down. There was some discussion on IRC and on Github, but it was
> also obvious that many already expected me to be the wallet maintainer
> after meshcollider. Hebasto was added with basically no fanfare or
> discussion - the only mention I can find is the PR itself. My understandi=
ng
> is that the maintainers asked him he wanted to do it before the PR was
> opened. Glozow was nominated to be a maintainer by some of the current
> maintainers, and her nomination was really the first time that there was
> significant public discussion about it.
>
> Of the past 7 maintainer additions, 5 were nominations/announcements from
> the current maintainers, one was volunteering following an actual "call f=
or
> maintainer", and one was an obvious successor. It's obvious and common
> sense that the maintainers decide when they need help shouldering the loa=
d,
> and then find somebody to help them. There was and always will be some
> level of private communication prior to any public announcement of the
> nomination or volunteering of a maintainer. It doesn't make sense to
> blindside somebody with a nomination without talking to them beforehand.
> The fact that most of these were non-controversial speaks to how well the
> maintainers were considering their nominations before publicly announcing
> them.
>
> It's also clear that we have been moving towards more open discussion
> about maintainership and who should be maintainers. The process is
> fundamentally more public than it was previously. We now have public
> discussion with contributors about the merits of a person, even if that
> results in said person not becoming a maintainer. Over time, there's been
> more public participation in the PRs and on IRC meetings when maintainer
> nominations are brought up. We have nominations as topics during meetings
> now when they occur. The PRs to add keys are left open for longer to get
> more discussion.
>
> Ultimately, if you disagree with how the project operates, then you are
> free to leave and start your own fork that is run in a way that you think
> is appropriate. This is open source software, no one is beholden to you,
> and no one is required to do anything.
>
> ***
>
> Since you are intent on discussing and re-litigating the decision about
> Vasil, I will agree that we (the maintainers) could have done a better jo=
b
> of communicating. However we stand by the decision that was made in the
> end, and we did have a chat with him about it during CoreDev.
>
> It really boils down to three things: 1) we did not ask for a P2P
> maintainer, 2) some of those who have reviewed Vasil's work expressed
> discomfort with him being a maintainer, and 3) some contributors and
> maintainers were uncomfortable with his responses about how he would merg=
e
> things. You repeatedly insist that it's only the current maintainers who
> blocked Vasil, but that is not the case. There were concerns brought up b=
y
> other contributors that contributed to the decision to ultimately NACK hi=
s
> nomination.
>
> One of the justifications for blocking Vasil Dimov as a new maintainer
> despite many initial ACKs from maintainers (including Andrew Chow) and lo=
ng
> term contributors was according to Andrew [2]:
>
> To be honest, my initial ACK was given without knowing enough information=
.
> It was given when he was mostly a name that showed up in my notification
> emails, and his work had seemed to be fine with me. At that time, I did n=
ot
> think we had a need for a P2P maintainer, but I also did not think that
> having one would be harmful. However I later spoke to a few others
> privately who were more familiar with Vasil's work and they had told me
> that they were not comfortable with Vasil being P2P maintainer.
>
> =E2=80=9CMaintainers inherently need to look at the things that everyone =
else has
> already looked at, if only to give it a final once over before merging (b=
ut
> hopefully, an actual review, not just looking it over).=E2=80=9D
>
>
> I follow the Bitcoin Core repo pretty closely and I haven=E2=80=99t seen =
ryanofsky
> do this any more than Vasil does. This is not a criticism of ryanofsky,
> just as I wouldn=E2=80=99t use it as a criticism for Vasil. It would get =
pretty
> annoying if everyone who wasn=E2=80=99t a maintainer posted an ACK once m=
any long
> term contributors had already ACKed to display supposed =E2=80=9Cdesired =
maintainer
> traits=E2=80=9D. Especially if you are essentially just ACKing that other=
s have
> done the work to review the PR and you just want to get your ACK on it to
> increase your ACK count without doing a fraction of what previous reviewe=
rs
> have done.
>
> This opinion was formed not from observing his behavior towards ACK'ing,
> but rather from his responses to questions about reviewing, in addition t=
o
> thoughts shared by other contributors.
>
> From having received plenty of reviews from ryanofsky, I can certainly sa=
y
> that his reviews are in depth. He has pointed out subtle bugs, asks
> questions about very low level details, and has well reasoned critiques a=
nd
> discussions about design decisions. His reviews are high quality, and he'=
s
> not afraid of being the first person to ACK a pr, the last person to ACK
> it, or the person to prevent one from being merged even when it already h=
as
> a few ACKs. We also had a separate discussion with ryanofsky about his
> approaches to reviewing and merging.
>
> =E2=80=9CI also want to mention that the people who have become maintaine=
rs in the
> past have had this kind of maintainer attitude towards review prior to
> becoming a maintainer=E2=80=9D
>
>
> Assuming ryanofsky hasn=E2=80=99t had this maintainer attitude in the pas=
t (again
> not a criticism from me at least) does this mean this was a reason to blo=
ck
> Vasil but not a reason to block ryanofsky? That seems inconsistent to me.
>
> I don't know why you assume the ryanofsky hasn't had this maintainer
> attitude? Your claim of inconsistency stems from this assumption that
> ryanofsky doesn't have a maintainer attitude, but I would argue that he
> does, as I mentioned above. The idea of adding him as a maintainer has be=
en
> floated around before, although never really seriously proposed until now=
,
> AFAIK.
>
> When you=E2=80=99re anointed you don=E2=80=99t need to meet requirements =
but when you=E2=80=99re
> blocked these requirements will be used to block your addition as a new
> maintainer?
>
> It seems obvious to me that when the current maintainers approach and
> nominate a contributor to be a maintainer that that person already meets
> these requirements. I don't know why you would assume bad faith in that
> someone who isn't qualified would be nominated by the current maintainers=
.
> It's quite frustrating that you seem to just jump straight to the negativ=
e
> conclusion rather than considering that there might be actual reasons bas=
ed
> on the merits of the person.
>
> On a more positive note there does seem to be more energy and momentum fo=
r
> collaboration and open communication on the project since I discussed
> communication in a previous post [3]. Hopefully this will continue. It
> doesn=E2=80=99t address my concerns on maintainers and ultimately merge d=
ecisions
> but it definitely seems to me to be a step in a positive direction for th=
e
> project.
>
> Don't take credit for what you didn't do. The group-wide effort to move
> towards public discussion again is the result of a discussion that was ha=
d
> at CoreDev. Many cited your behavior as a primary reason to stop discussi=
ng
> things publicly, with things such as dragging project meta discussions on=
to
> the mailing list and twitter. These have invited abuse towards maintainer=
s
> and contributors, which in turn makes them takes those discussions to mor=
e
> private settings. People feel like they're getting sealioned by you (and =
a
> few others) when they post publicly, and so they have stopped doing so.
>
>
> Andrew
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--00000000000044646b05fb6ed1ca
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I don't see any reason to be antagonistic=C2=A0in your=
responses.=C2=A0<div><br></div><div><div>One piece of advice I'd offer=
to you and Michael is to consider whether your responses are effective. To=
persuade other people it takes more than making good points=C2=A0or being =
right, but you need to find a communication style and communication path th=
at is effective. My observation is that your styles need reflection.</div><=
div><br></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" c=
lass=3D"gmail_attr">On Thu, May 11, 2023 at 10:15=E2=80=AFAM alicexbt via b=
itcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bit=
coin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><div style=3D"font-family:Arial,sans-seri=
f;font-size:14px">Hi Andrew,</div><div style=3D"font-family:Arial,sans-seri=
f;font-size:14px"><br></div><div style=3D"font-family:Arial,sans-serif;font=
-size:14px"><blockquote type=3D"cite" style=3D"padding:0px 0px 0px 1rem;mar=
gin:0px;border-left:4px solid rgb(229,229,229);font-family:system-ui,sans-s=
erif;background-color:rgb(255,255,255)">We can take a look at how previous =
maintainers were added to see how this has played out in the past.<span>=C2=
=A0</span></blockquote><div style=3D"font-family:Arial,sans-serif;font-size=
:14px"><br></div>Can we learn something from past?</div><div style=3D"font-=
family:Arial,sans-serif;font-size:14px"><br></div><div style=3D"font-family=
:Arial,sans-serif;font-size:14px">Bitcoin's initial release was in 2009=
with one developer and few others experimenting with it. It is considered =
decentralized in 2023 however we have 99% of nodes using bitcoin core, 5 de=
velopers deciding what's merged or not and this includes some trying to=
implement their ideas without soft fork using mempool policies.=C2=A0</div=
><div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div =
style=3D"font-family:Arial,sans-serif;font-size:14px">We need better proces=
s to add maintainers. I am disappointed with the way last last pull request=
was merged. It says more about maintainers and leader Michael Ford. If you=
are so scared about opinions on a pull request why not just make him maint=
ainer without pull request?=C2=A0</div><div style=3D"font-family:Arial,sans=
-serif;font-size:14px"><br></div><div style=3D"font-family:Arial,sans-serif=
;font-size:14px">Maybe you will understand this if your PR to add maintaine=
r was kept open for 4 months.=C2=A0</div><div style=3D"font-family:Arial,sa=
ns-serif;font-size:14px"><br></div><div style=3D"font-family:Arial,sans-ser=
if;font-size:14px">/dev/fd0</div><div style=3D"font-family:Arial,sans-serif=
;font-size:14px">floppy disk<br><br></div><div style=3D"font-family:Arial,s=
ans-serif;font-size:14px"><br></div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
<div>
=20
</div>
=20
<div>
Sent with <a href=3D"https://proton.me/" rel=3D"noopener noreferrer=
" target=3D"_blank">Proton Mail</a> secure email.
</div>
</div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div>
------- Original Message -------<br>
On Thursday, May 11th, 2023 at 2:54 AM, Andrew Chow via bitcoin-dev=
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br><br>
<blockquote type=3D"cite">
=20
On 05/07/23 03:03 AM, Michael Folkson via bitcoin-dev wrote:<br>
<blockquote type=3D"cite">
=20
<br>
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
<p style=3D"font:12px Helvetica;margin:0px">The decision process
for adding a new maintainer was according to the IRC meeting
that the maintainers decided privately there was a need for a
maintainer =E2=80=9Cwho understood our interfaces and modularizat=
ion
efforts well=E2=80=9D and that ryanofsky was a =E2=80=9Cgood fit =
for that=E2=80=9D. I
don=E2=80=99t know whether this was decided in a private IRC chan=
nel
or was decided at the recent in person Core Dev meeting.
Regardless, many have had no input into the discussion on what
kind of maintainer the project needs going forward and it
seems the maintainers do not want to discuss that aspect of
the decision.</p>
</div>
</blockquote>
Since the project began, the decision to seek out and then add a
maintainer has always been made by existing maintainers. When the
maintainers feel that there is a need for additional maintainers,
they may have an open call for volunteers, or may have a candidate
already in mind and suggest that specific person for maintainership.
Contributors generally are not consulted in the decision to seek a
new maintainer as they would not know whether there are things that
are being overlooked or that there is maintainership load that needs
to be distributed. Even so, it wouldn't be appropriate to add a
maintainer if many contributors disagreed with it, just as with any
other PR.<br>
<br>
We can take a look at how previous maintainers were added to see how
this has played out in the past. I think our modern concept of
maintainers with nominal scopes began in 2015 with Jonas Schnelli.
Both Jonas Schnelli and Marco Falke were simply announced by
Wladimir. There was no public discussion, and some IRC logs refer to
private emails between the them and the current maintainers at that
time. After that, meshcollider was added as a maintainer after a
public "call for maintainers" where a recurring topic for a w=
hile
was finding a maintainer for the wallet. He had volunteered to do it
by contacting Wladimir privately before it was discussed during an
IRC meeting and then on Github. Fanquake was added as a maintainer
during a CoreDev event in Amsterdam during a discussion initiated
and led by the maintainers. This was also "private" insofar a=
s the
discussion was limited to those in attendance, although there was
some opportunity for public discussion in the PR opened on Github.
For myself, it was also initially private as I messaged Wladimir to
volunteer for it after meshcollider stepped down. There was some
discussion on IRC and on Github, but it was also obvious that many
already expected me to be the wallet maintainer after meshcollider.
Hebasto was added with basically no fanfare or discussion - the only
mention I can find is the PR itself. My understanding is that the
maintainers asked him he wanted to do it before the PR was opened.
Glozow was nominated to be a maintainer by some of the current
maintainers, and her nomination was really the first time that there
was significant public discussion about it.<br>
<br>
Of the past 7 maintainer additions, 5 were nominations/announcements
from the current maintainers, one was volunteering following an
actual "call for maintainer", and one was an obvious successo=
r. It's
obvious and common sense that the maintainers decide when they need
help shouldering the load, and then find somebody to help them.
There was and always will be some level of private communication
prior to any public announcement of the nomination or volunteering
of a maintainer. It doesn't make sense to blindside somebody with a
nomination without talking to them beforehand. The fact that most of
these were non-controversial speaks to how well the maintainers were
considering their nominations before publicly announcing them.<br>
<br>
It's also clear that we have been moving towards more open
discussion about maintainership and who should be maintainers. The
process is fundamentally more public than it was previously. We now
have public discussion with contributors about the merits of a
person, even if that results in said person not becoming a
maintainer. Over time, there's been more public participation in th=
e
PRs and on IRC meetings when maintainer nominations are brought up.
We have nominations as topics during meetings now when they occur.
The PRs to add keys are left open for longer to get more discussion.
<br>
<br>
Ultimately, if you disagree with how the project operates, then you
are free to leave and start your own fork that is run in a way that
you think is appropriate. This is open source software, no one is
beholden to you, and no one is required to do anything.<br>
<br>
***<br>
<br>
Since you are intent on discussing and re-litigating the decision
about Vasil, I will agree that we (the maintainers) could have done
a better job of communicating. However we stand by the decision that
was made in the end, and we did have a chat with him about it during
CoreDev.<br>
<br>
It really boils down to three things: 1) we did not ask for a P2P
maintainer, 2) some of those who have reviewed Vasil's work
expressed discomfort with him being a maintainer, and 3) some
contributors and maintainers were uncomfortable with his responses
about how he would merge things. You repeatedly insist that it's
only the current maintainers who blocked Vasil, but that is not the
case. There were concerns brought up by other contributors that
contributed to the decision to ultimately NACK his nomination.<br>
<blockquote type=3D"cite">
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
<p style=3D"font:12px Helvetica;margin:0px">One of the
justifications for blocking Vasil Dimov as a new maintainer
despite many initial ACKs from maintainers (including Andrew
Chow) and long term contributors was according to Andrew [2]:</p>
</div>
</blockquote>
To be honest, my initial ACK was given without knowing enough
information. It was given when he was mostly a name that showed up
in my notification emails, and his work had seemed to be fine with
me. At that time, I did not think we had a need for a P2P
maintainer, but I also did not think that having one would be
harmful. However I later spoke to a few others privately who were
more familiar with Vasil's work and they had told me that they were
not comfortable with Vasil being P2P maintainer.<br>
<blockquote type=3D"cite">
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
<p style=3D"font:12px Helvetica;margin:0px">=E2=80=9CMaintainers
inherently need to look at the things that everyone else has
already looked at, if only to give it a final once over before
merging (but hopefully, an actual review, not just looking it
over).=E2=80=9D</p>
<p style=3D"font:12px Helvetica;margin:0px;min-height:14px"><br sty=
le=3D"line-height:1.5">
</p>
<p style=3D"font:12px Helvetica;margin:0px">I follow the Bitcoin
Core repo pretty closely and I haven=E2=80=99t seen ryanofsky do =
this
any more than Vasil does. This is not a criticism of
ryanofsky, just as I wouldn=E2=80=99t use it as a criticism for V=
asil.
It would get pretty annoying if everyone who wasn=E2=80=99t a
maintainer posted an ACK once many long term contributors had
already ACKed to display supposed =E2=80=9Cdesired maintainer tra=
its=E2=80=9D.
Especially if you are essentially just ACKing that others have
done the work to review the PR and you just want to get your
ACK on it to increase your ACK count without doing a fraction
of what previous reviewers have done.</p>
</div>
</blockquote>
This opinion was formed not from observing his behavior towards
ACK'ing, but rather from his responses to questions about reviewing=
,
in addition to thoughts shared by other contributors.<br>
<br>
From having received plenty of reviews from ryanofsky, I can
certainly say that his reviews are in depth. He has pointed out
subtle bugs, asks questions about very low level details, and has
well reasoned critiques and discussions about design decisions. His
reviews are high quality, and he's not afraid of being the first
person to ACK a pr, the last person to ACK it, or the person to
prevent one from being merged even when it already has a few ACKs.
We also had a separate discussion with ryanofsky about his
approaches to reviewing and merging.<br>
<br>
<blockquote type=3D"cite">
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
<p style=3D"font:12px Helvetica;margin:0px">=E2=80=9CI also want to
mention that the people who have become maintainers in the
past have had this kind of maintainer attitude towards review
prior to becoming a maintainer=E2=80=9D</p>
<p style=3D"font:12px Helvetica;margin:0px;min-height:14px"><br sty=
le=3D"line-height:1.5">
</p>
<p style=3D"font:12px Helvetica;margin:0px">Assuming ryanofsky
hasn=E2=80=99t had this maintainer attitude in the past (again no=
t a
criticism from me at least) does this mean this was a reason
to block Vasil but not a reason to block ryanofsky? That seems
inconsistent to me.</p>
</div>
</blockquote>
I don't know why you assume the ryanofsky hasn't had this maint=
ainer
attitude? Your claim of inconsistency stems from this assumption
that ryanofsky doesn't have a maintainer attitude, but I would argu=
e
that he does, as I mentioned above. The idea of adding him as a
maintainer has been floated around before, although never really
seriously proposed until now, AFAIK.<br>
<blockquote type=3D"cite">
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
<p style=3D"font:12px Helvetica;margin:0px">When you=E2=80=99re ano=
inted
you don=E2=80=99t need to meet requirements but when you=E2=80=99=
re blocked
these requirements will be used to block your addition as a
new maintainer?</p>
</div>
</blockquote>
It seems obvious to me that when the current maintainers approach
and nominate a contributor to be a maintainer that that person
already meets these requirements. I don't know why you would assume
bad faith in that someone who isn't qualified would be nominated by
the current maintainers. It's quite frustrating that you seem to
just jump straight to the negative conclusion rather than
considering that there might be actual reasons based on the merits
of the person.<br>
<blockquote type=3D"cite">
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
<p style=3D"font:12px Helvetica;margin:0px">On a more positive
note there does seem to be more energy and momentum for
collaboration and open communication on the project since I
discussed communication in a previous post [3]. Hopefully this
will continue. It doesn=E2=80=99t address my concerns on maintain=
ers
and ultimately merge decisions but it definitely seems to me
to be a step in a positive direction for the project.</p>
</div>
</blockquote>
Don't take credit for what you didn't do. The group-wide effort=
to
move towards public discussion again is the result of a discussion
that was had at CoreDev. Many cited your behavior as a primary
reason to stop discussing things publicly, with things such as
dragging project meta discussions onto the mailing list and twitter.
These have invited abuse towards maintainers and contributors, which
in turn makes them takes those discussions to more private settings.
People feel like they're getting sealioned by you (and a few others=
)
when they post publicly, and so they have stopped doing so.<br>
<br>
<br>
Andrew<br>
</blockquote><br>
</div>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--00000000000044646b05fb6ed1ca--
|