path: root/09/ac50776c5f8e802a54aec31fc43378585f8f10

Return-Path: <earonesty@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E3653C002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 May 2023 18:48:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id A831B41ED8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 May 2023 18:48:52 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org A831B41ED8
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=q32-com.20221208.gappssmtp.com
 header.i=@q32-com.20221208.gappssmtp.com header.a=rsa-sha256
 header.s=20221208 header.b=M5II1Xl2
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.6
X-Spam-Level: 
X-Spam-Status: No, score=0.6 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
 PDS_OTHER_BAD_TLD=1.999, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 YfIDrzlXfGeI
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 May 2023 18:48:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7AA1D41EFE
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com
 [IPv6:2607:f8b0:4864:20::b31])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 7AA1D41EFE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 May 2023 18:48:49 +0000 (UTC)
Received: by mail-yb1-xb31.google.com with SMTP id
 3f1490d57ef6-b8f46ca241bso1479479276.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 May 2023 11:48:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20221208.gappssmtp.com; s=20221208; t=1683830928; x=1686422928;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=R3exrdC7QqeEXZm66eM8KMp94h6YPUi8ZOLMSRo6Bv8=;
 b=M5II1Xl2gKcs7NitzFTsi6YmpCmcywMGYLXxLmy7QWIBxo0dbIDmTs3N2fOG6AkVr+
 atsGnZktTI/mjb9gve8bdZuuO7v+jUj+hXa69ZhhLe/CweYK2sTW/xAD1I/MnGyNFl2c
 /7sT31kNoE8QmyYPouEbjXT8TY1p8LXgPGlqNdfFKNsIFc3R9F4iUi1GXjGqx66h29Om
 lxP5H+DD8Mf9rwWpUhCJToPzcVqpgstKducbdW3hxKGbYRiTR0A6l8SLvqHFTgj4ynwj
 c+b7u/Vi46kJe28PUnmObB53zWbY1jNJtB+FmhCHsk/ZBYMCPF8kW0eRBl6Scw7rU2N+
 WkJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1683830928; x=1686422928;
 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=R3exrdC7QqeEXZm66eM8KMp94h6YPUi8ZOLMSRo6Bv8=;
 b=MHvMl4jioh/1yniduk0bo/7H8EZJ5f8MZp2hZ5Yfl3QjHcPR7/iQsPgt1l1v1YpqLH
 WzSqHKO++gTyXmIcerYoQvr/zcC02vxddvFUUZ16sjCq2c6o1/WUUO0GBxS5iBrlYZB0
 /7WgY9ZMFez4hW8Vdt1tXmCH6uefggQGSevPvqPNtPccYtnx//uTOhlye5+WiLhzJr3s
 C7LVgFJCBqU7GgTb1HaLpied90w0U/VRxhIRbyTkMRqEl9MHhg8DD4UPKNbXjMjbONLx
 DyAPt5a/TEEGdulIgfiXAbNOLgk7IZOdmDFs4aVK6B6UiurLjL3NcOLB/nmeO1gA1Rnk
 BstQ==
X-Gm-Message-State: AC+VfDzplOHxC9oXG3EQqKVQ2CxUvNAkakuL0ydpniSPnniI8Dd2yYjm
 xyropGEYfaHNc0ouDPKSWDZ7KQDAOTTpGsAMVaWBYHMQJ4rkdUBY5Q==
X-Google-Smtp-Source: ACHHUZ7LULy3X+gsNBa4gTVKylfL+MrEBXR4Ii5nnPCL9nw5fPdV/DRId2m0ZK5f7GRKpuZ6TPQ9rMgu2hYAUWugOVY=
X-Received: by 2002:a25:ad8a:0:b0:ba1:6097:4405 with SMTP id
 z10-20020a25ad8a000000b00ba160974405mr21078694ybi.6.1683830928117; Thu, 11
 May 2023 11:48:48 -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>
 <CABu3BAcGJZnYb-Lun9T-Fqh1C5htd=P2UQxed5H8jmgsKjTcLA@mail.gmail.com>
In-Reply-To: <CABu3BAcGJZnYb-Lun9T-Fqh1C5htd=P2UQxed5H8jmgsKjTcLA@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Thu, 11 May 2023 14:48:39 -0400
Message-ID: <CAJowKgL2tK_q0Oa_idtKuy-ROjTJdBAhk6jXrqJD63AP4cy85Q@mail.gmail.com>
To: Steve Lee <steven.j.lee@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000055159a05fb6f70d2"
X-Mailman-Approved-At: Fri, 12 May 2023 00:12:33 +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:48:53 -0000

--00000000000055159a05fb6f70d2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

i agree 100%.   effective communication is challenging, especially in an
environment like this.   that being said, alicexbt is probably right that
we

 - probably need a well written spec, RFC-style perhaps
 - need more anon or nym maintainers where the online reputation isn't
trivially linked to real-world reputation
 - github should be replaced with something p2p (maybe move to
https://radicle.xyz/)

meta-stuff like that is probably just as important as picking the next cool
covenant opcode to ignore

On Thu, May 11, 2023 at 2:06=E2=80=AFPM Steve Lee via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 yo=
ur
> 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 thi=
s
>> 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 merge=
d
>> or not and this includes some trying to implement their ideas without so=
ft
>> fork using mempool policies.
>>
>> We need better process to add maintainers. I am disappointed with the wa=
y
>> 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 reque=
st
>> why not just make him maintainer without pull request?
>>
>> Maybe you will understand this if your PR to add maintainer was kept ope=
n
>> 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 IR=
C
>> meeting that the maintainers decided privately there was a need for a
>> maintainer =E2=80=9Cwho understood our interfaces and modularization eff=
orts 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 m=
ay
>> have an open call for volunteers, or may have a candidate already in min=
d
>> and suggest that specific person for maintainership. Contributors genera=
lly
>> 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 ther=
e
>> is maintainership load that needs to be distributed. Even so, it wouldn'=
t
>> be appropriate to add a maintainer if many contributors disagreed with i=
t,
>> just as with any other PR.
>>
>> We can take a look at how previous maintainers were added to see how thi=
s
>> has played out in the past. I think our modern concept of maintainers wi=
th
>> nominal scopes began in 2015 with Jonas Schnelli. Both Jonas Schnelli an=
d
>> Marco Falke were simply announced by Wladimir. There was no public
>> discussion, and some IRC logs refer to private emails between the them a=
nd
>> the current maintainers at that time. After that, meshcollider was added=
 as
>> a maintainer after a public "call for maintainers" where a recurring top=
ic
>> for a while 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 durin=
g a
>> CoreDev event in Amsterdam during a discussion initiated and led by the
>> maintainers. This was also "private" insofar as the discussion was limit=
ed
>> 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 understand=
ing
>> 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 fro=
m
>> the current maintainers, one was volunteering following an actual "call =
for
>> maintainer", and one was an obvious successor. It's obvious and common
>> sense that the maintainers decide when they need help shouldering the lo=
ad,
>> 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 th=
e
>> maintainers were considering their nominations before publicly announcin=
g
>> 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 bee=
n
>> more public participation in the PRs and on IRC meetings when maintainer
>> nominations are brought up. We have nominations as topics during meeting=
s
>> 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 thin=
k
>> 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 j=
ob
>> 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 mer=
ge
>> 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 h=
is
>> nomination.
>>
>> One of the justifications for blocking Vasil Dimov as a new maintainer
>> despite many initial ACKs from maintainers (including Andrew Chow) and l=
ong
>> 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 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 f=
ew
>> others privately who were more familiar with Vasil's work and they had t=
old
>> 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 (=
but
>> 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. I=
t would get
>> pretty annoying if everyone who wasn=E2=80=99t a maintainer posted an AC=
K once many
>> long term contributors had already ACKed to display supposed =E2=80=9Cde=
sired
>> maintainer traits=E2=80=9D. Especially if you are essentially just ACKin=
g 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.
>>
>> 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.
>>
>> 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.
>>
>> =E2=80=9CI also want to mention that the people who have become maintain=
ers 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 pa=
st (again
>> not a criticism from me at least) does this mean this was a reason to bl=
ock
>> 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 b=
een
>> floated around before, although never really seriously proposed until no=
w,
>> 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 maintainer=
s.
>> It's quite frustrating that you seem to just jump straight to the negati=
ve
>> conclusion rather than considering that there might be actual reasons ba=
sed
>> on the merits of the person.
>>
>> On a more positive note there does seem to be more energy and momentum
>> for collaboration and open communication on the project since I discusse=
d
>> communication in a previous post [3]. Hopefully this will continue. It
>> doesn=E2=80=99t address my concerns on maintainers and ultimately merge =
decisions
>> but it definitely seems to me to be a step in a positive direction for t=
he
>> 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 h=
ad
>> at CoreDev. Many cited your behavior as a primary reason to stop discuss=
ing
>> things publicly, with things such as dragging project meta discussions o=
nto
>> the mailing list and twitter. These have invited abuse towards maintaine=
rs
>> and contributors, which in turn makes them takes those discussions to mo=
re
>> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--00000000000055159a05fb6f70d2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">i agree 100%.=C2=A0 =C2=A0effective communication is chall=
enging, especially in an environment like this.=C2=A0 =C2=A0that being=C2=
=A0said, alicexbt is probably right that we=C2=A0<div><br></div><div>=C2=A0=
- probably need a well written spec, RFC-style perhaps=C2=A0</div><div>=C2=
=A0- need more anon or nym maintainers where the online reputation isn&#39;=
t trivially linked to real-world reputation</div><div>=C2=A0- github should=
 be replaced with something p2p (maybe move to=C2=A0<a href=3D"https://radi=
cle.xyz/">https://radicle.xyz/</a>)=C2=A0</div><div><br></div><div>meta-stu=
ff like that is probably just as important as picking the next cool covenan=
t opcode to ignore=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Thu, May 11, 2023 at 2:06=E2=80=AFPM Steve=
 Lee via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">I don&#39;t se=
e any reason to be antagonistic=C2=A0in your responses.=C2=A0<div><br></div=
><div><div>One piece of advice I&#39;d offer to you and Michael is to consi=
der 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 c=
ommunication style and communication path that 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" class=3D"gmail_attr">On Thu, May=
 11, 2023 at 10:15=E2=80=AFAM alicexbt via bitcoin-dev &lt;<a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@list=
s.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div style=3D"font-family:Arial,sans-serif;font-size:1=
4px">Hi Andrew,</div><div style=3D"font-family:Arial,sans-serif;font-size:1=
4px"><br></div><div style=3D"font-family:Arial,sans-serif;font-size:14px"><=
blockquote type=3D"cite" style=3D"padding:0px 0px 0px 1rem;margin:0px;borde=
r-left:4px solid rgb(229,229,229);font-family:system-ui,sans-serif;backgrou=
nd-color:rgb(255,255,255)">We can take a look at how previous maintainers w=
ere added to see how this has played out in the past.<span>=C2=A0</span></b=
lockquote><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-s=
erif;font-size:14px">Bitcoin&#39;s initial release was in 2009 with one dev=
eloper and few others experimenting with it. It is considered decentralized=
 in 2023 however we have 99% of nodes using bitcoin core, 5 developers deci=
ding what&#39;s merged or not and this includes some trying to implement th=
eir 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"fo=
nt-family:Arial,sans-serif;font-size:14px">We need better process to add ma=
intainers. 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 sca=
red about opinions on a pull request why not just make him maintainer witho=
ut 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 maintainer was kept =
open for 4 months.=C2=A0</div><div style=3D"font-family:Arial,sans-serif;fo=
nt-size:14px"><br></div><div style=3D"font-family:Arial,sans-serif;font-siz=
e: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,sans-serif;f=
ont-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=
 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; 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&#39;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 &quot;call for maintainers&quot; 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 &quot;private&quot; 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 &quot;call for maintainer&quot;, and one was an obvious successo=
r. It&#39;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&#39;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&#39;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&#39;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&#39;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&#39;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&#39;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&#39;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&#39;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&#39;t know why you assume the ryanofsky hasn&#39;t had this maint=
ainer
    attitude? Your claim of inconsistency stems from this assumption
    that ryanofsky doesn&#39;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&#39;t know why you would assume
    bad faith in that someone who isn&#39;t qualified would be nominated by
    the current maintainers. It&#39;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&#39;t take credit for what you didn&#39;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&#39;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>
_______________________________________________<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>

--00000000000055159a05fb6f70d2--