Delivery-date: Sun, 21 Apr 2024 17:20:50 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of michaelfolkson@gmail.com designates 2a00:1450:4864:20::42c as permitted sender) client-ip=2a00:1450:4864:20::42c;
MIME-Version: 1.0
References: <2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com>
 <070755a0-10e9-4903-9524-dd8ef98c1c8b@achow101.com> <CABu3BAeYqzp439z8Ug6_4QdhvSQ0fCysz-t2h1zzp2pX6Hsebg@mail.gmail.com>
 <0d4d85e3-9fbb-4bd4-af0f-92225e699b63@achow101.com> <CAFvNmHSH4aPvP88wJHg4uwSmRZS7iJxVaOYhamz5L4yPx7GsYg@mail.gmail.com>
 <97a10141-8847-417a-af11-d95e7d3be064@achow101.com> <CAFvNmHQVrzrmodRV1QUC3Ft39XEMW18YsfiZu_GTTnVde=nd_w@mail.gmail.com>
 <0591e62d-12da-48ac-9d19-faea473c647c@achow101.com> <CAFvNmHTgfwSx-kNzHSFW_7HWfOG1yupJQGZqXWzG47i=-DjSsA@mail.gmail.com>
 <84bb3ca1-a18e-48c8-a934-6fcef5470a36@achow101.com>
In-Reply-To: <84bb3ca1-a18e-48c8-a934-6fcef5470a36@achow101.com>
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Sun, 21 Apr 2024 20:18:33 +0100
Message-ID: <CAFvNmHSCsb37HmKom0GCezfTnNF6dnoVT6c_A-bVB4or2t+6oA@mail.gmail.com>
Subject: Re: [bitcoindev] Re: Adding New BIP Editors
To: Ava Chow <lists@achow101.com>
Cc: bitcoindev@googlegroups.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

> I did not say that they can write anything, do not put words in my
mouth.

Your statement was "If a BIP author proposes or agrees with a change
to their BIP and those
changes are formatted correctly, it is not the BIP editors' rights nor
responsibilities to refuse to merge that change." I'm not putting
words into your mouth, those are your words.

> I suggest that you read the BIP process thread split from this one for
opinions on how to refine the BIPs process to make it clearer as to what
BIP editors should be merging.

Indeed. I would rather that BIP process refinement had been completed
before we went from 1 BIP editor to 6 BIP editors, most of which have
barely participated in the BIP process in the past and will have very
different perspectives on what should or should not be merged. But
that is apparently "concern trolling" so agreed there is no point
continuing this.

On Sun, Apr 21, 2024 at 7:47=E2=80=AFPM Ava Chow <lists@achow101.com> wrote=
:
>
> On 04/21/2024 01:57 PM, Michael Folkson wrote:
> > So once a BIP number is allocated (or before) the BIP author can write
> > whatever they like on that BIP? Including false and misleading
> > statements? And the BIP editors have to merge it as long as it meets
> > formatting requirements?
>
> I did not say that they can write anything, do not put words in my
> mouth. Modifications to a BIP are held to the same standard as when it
> is initially proposed. This standard is largely about formatting, but
> also about keeping BIPs as actual technical specifications. So long as
> the BIP after those modifications meet those requirements, then BIP
> editors should merge them.
>
> > A misleading statement like "This soft fork will definitely activate
> > at block X as it has been merged into implementation Y. It hasn't been
> > merged into Bitcoin Core yet but Bitcoin Core will merge the soft fork
> > after the activation"
>
> BIPs are specifications. They are not blog posts. They are not the place
> for opining about whether or not something will activate. Such
> statements would be off topic for a BIP and do not meet the standard for
> merging, so no, I do not think that should be merged, and I do not think
> any of the proposed BIP editors would merge such a PR.
>
> >
> > This is a step change from before. If we aren't relying on *any*
> > judgment then there might as well be 100 BIP editors. Because the
> > editors aren't doing anything, each BIP author (or champion) has total
> > license to write whatever they like on their BIP.
> >
> >> They are not arbiters of what is activated on Bitcoin. They are not ga=
tekeepers of soft forks.
> >
> > Of course not. The BIP editors do not decide what is activated on
> > Bitcoin. But they are gatekeepers on ensuring BIPs are high quality
> > and don't include false and misleading statements. Because false and
> > misleading statements can impact the evolution of an activation
> > process.
> >
> > I tried. Based on your perspective all we need is one malicious BIP
> > author (or champion) and they'll make the entire BIP process a joke
> > and the BIP editors won't be able to do anything.
>
> You are being deliberately obtuse and strawmanning. I did not say that
> the BIP editors won't be able to do anything; I did not say that that a
> BIP author can put whatever they want once they get a BIP number.
>
> I suggest that you read the BIP process thread split from this one for
> opinions on how to refine the BIPs process to make it clearer as to what
> BIP editors should be merging.
>
> Frankly, I don't understand what it is your are arguing for or trying to
> achieve. You make absurd claims, use strawman arguments, and throw out
> whataboutisms. This all seems to me to be concern trolling, and as such,
> I see no reason to continue responding to you.
>
> Ava
>
> >
> > Michael
> >
> >
> >
> > On Sun, Apr 21, 2024 at 5:39=E2=80=AFPM Ava Chow <lists@achow101.com> w=
rote:
> >>
> >> You are misunderstanding the role of BIP editors. They are not arbiter=
s
> >> of what is activated on Bitcoin. They are not gatekeepers of soft fork=
s.
> >> If a BIP author proposes or agrees with a change to their BIP and thos=
e
> >> changes are formatted correctly, it is not the BIP editors' rights nor
> >> responsibilities to refuse to merge that change. As with Bitcoin Core
> >> maintainers, BIP editing is a largely janitorial role.
> >>
> >> Just because something is a BIP does not mean it is a good idea. Just
> >> because a BIP specifying a fork contains deployment parameters does no=
t
> >> mean it will actually be deployed. There are several BIPs for both har=
d
> >> and soft forks that are rejected or withdrawn that have deployment
> >> parameters.
> >>
> >> Furthermore, for myself, I would actually prefer that contentious soft
> >> forks for which some people are legitimately attempting to activate ha=
ve
> >> their deployment parameters be specified in a/the BIP. Having competin=
g
> >> activation parameters in different BIPs is preferable over the
> >> documentation being spread around in many different places. It makes i=
t
> >> much easier for implementations to inform users what they've actually
> >> implemented so that users can make a more informed decision.
> >>
> >> On 04/21/2024 07:43 AM, Michael Folkson wrote:
> >>> Ava
> >>>
> >>> Thanks for the detailed response, I appreciate the insight.
> >>>
> >>>>> I'm even more concerned about future soft fork activation attempts.
> >>>>> These don't necessarily need to be attempted via a Bitcoin Core mer=
ged
> >>>>> pull request hence the BIPs repo could be a key source of informati=
on
> >>>>> and guidance on this.
> >>>
> >>>> This concern doesn't make any sense. There are already multiple soft=
 and
> >>>> hard fork BIPs that are not active nor good ideas. A BIP does not ne=
ed
> >>>> to be a good idea.
> >>>
> >>> I would hope that a contentious soft fork and activation params for
> >>> that contentious soft fork would not be merged into the Bitcoin Core
> >>> codebase and up until now it hasn't been. I would hope all the Bitcoi=
n
> >>> Core maintainers understand that even if they personally think a soft
> >>> fork is a good idea (apparently there is nothing to stop them merging
> >>> it without discussing it with the other maintainers) that they
> >>> shouldn't independently merge it if it is contentious.
> >>>
> >>> Similarly I would hope that all BIP editors would be careful about
> >>> what information gets merged around soft fork activation *attempts*
> >>> whether that be activation details on a particular soft fork BIP or o=
n
> >>> a separate activation BIP. With Taproot there were very strong
> >>> disagreements over activation parameters for a non-contentious soft
> >>> fork. It would be much messier for a contentious soft fork activation
> >>> attempt. I'm not sure all these new BIP editors understand that or
> >>> would perhaps even agree with that. For example Laolu is listed as a
> >>> supporter of a CTV activation attempt back in 2022 [0] which was
> >>> clearly contentious. That doesn't inspire me with confidence that as
> >>> soon as he is a BIP editor he won't start merging details on
> >>> contentious soft fork activation attempts in BIPs and merging that
> >>> soft fork in say btcd. He would need to be removed as a BIP editor if
> >>> he were to do something like that.
> >>>
> >>> Thanks
> >>> Michael
> >>>
> >>> [0]: https://utxos.org/signals/
> >>>
> >>>
> >>>
> >>> On Sun, Apr 21, 2024 at 12:05=E2=80=AFAM Ava Chow <lists@achow101.com=
> wrote:
> >>>>
> >>>>
> >>>> On 04/20/2024 06:21 PM, Michael Folkson wrote:
> >>>>> It is inevitable there will be a "revert war" unless they all have =
to
> >>>>> agree on merge decisions or communicate prior to merging. It is jus=
t a
> >>>>> matter of time. Does for example Ordinal Numbers get a BIP number? =
I
> >>>>> suspect all the new BIP editors won't agree on that.
> >>>>
> >>>> Why do you think that a revert war is inevitable?
> >>>>
> >>>> The Bitcoin Core repo operates in a similar way - the maintainers ar=
e
> >>>> independent and work autonomously. The maintainers do not have to ag=
ree
> >>>> on merge decisions nor do they communicate prior to merging. If ther=
e's
> >>>> disagreement about a merge decision, we talk to each other about it =
like
> >>>> adults and come to a mutually agreeable resolution. I don't think
> >>>> there's ever been a revert war in the history of Bitcoin.
> >>>>
> >>>> I would expect that when there is something that is likely to be
> >>>> controversial or is ambiguous that it should be a BIP that they woul=
d
> >>>> then talk to each other about it. It doesn't have to be all or nothi=
ng -
> >>>> they can do most work without communicating, but when there's questi=
ons
> >>>> or ambiguity, then they communicate.
> >>>>
> >>>>> Who is to blame in a "revert war" if each editor is free to merge
> >>>>> whatever pull request they like? The editor who merged it? Why shou=
ld
> >>>>> they be removed as an editor for merging a pull request when they f=
ind
> >>>>> out later a different editor disagreed with that merge decision and
> >>>>> wants to revert the merge?
> >>>>
> >>>> A revert war would be someone merging a PR that reverts another, the=
n
> >>>> someone else (opening then) merging a PR that reverts that, and it g=
oes
> >>>> back and forth. It would not be limited to PRs only. This would like=
ly
> >>>> be super obvious too that they are controversially merging things as=
 I
> >>>> would be surprised if other BIP editors didn't comment on any of tho=
se
> >>>> actions, besides the fact that many people do also watch the BIPs re=
po.
> >>>> Regardless, the blame is on those who are doing the reverting, and w=
ould
> >>>> be both sides.
> >>>>
> >>>>> I'm even more concerned about future soft fork activation attempts.
> >>>>> These don't necessarily need to be attempted via a Bitcoin Core mer=
ged
> >>>>> pull request hence the BIPs repo could be a key source of informati=
on
> >>>>> and guidance on this.
> >>>>
> >>>> This concern doesn't make any sense. There are already multiple soft=
 and
> >>>> hard fork BIPs that are not active nor good ideas. A BIP does not ne=
ed
> >>>> to be a good idea.
> >>>>
> >>>>> I've seen Wladimir is contributing again to Core. Is there a plan t=
o
> >>>>> give him commit access again?
> >>>>
> >>>> It would have to be through the typical maintainer process, although=
 I
> >>>> doubt that he even wants it. But that's completely orthogonal to the
> >>>> BIPs repo discussion.
> >>>>
> >>>>> I'd be more comfortable with him
> >>>>> overseeing things in the various repos under the Bitcoin Core
> >>>>> (/bitcoin) GitHub org as it sounds like you don't really care if th=
e
> >>>>> BIPs repo degenerates into a free for all.
> >>>>
> >>>> I don't understand why you assume that.
> >>>>
> >>>> I've said this before, but if I see a revert war going on in the BIP=
s
> >>>> repo, I will remove those involved immediately and make a thread on =
the
> >>>> list to discuss what to do about them. But I doubt that's a scenario
> >>>> that will actually come to pass.
> >>>>
> >>>> Ava
> >>>>
> >>>>>
> >>>>> Thanks
> >>>>> Michael
> >>>>>
> >>>>> On Sat, Apr 20, 2024 at 10:15=E2=80=AFPM 'Ava Chow' via Bitcoin Dev=
elopment
> >>>>> Mailing List <bitcoindev@googlegroups.com> wrote:
> >>>>>>
> >>>>>> On 04/20/2024 04:46 PM, Steve Lee wrote:
> >>>>>>> Wasn't there evidence provided that Kanzure does not want this
> >>>>>>> responsibility without being paid?
> >>>>>>
> >>>>>> I am not aware of that, and it hasn't come up when I've talked to =
him
> >>>>>> about being a BIPs editor.
> >>>>>>
> >>>>>>> I'm confused by this process that we don't even ask the people if=
 they
> >>>>>>> want the responsibility? I think only Laolu has chimed in to comm=
it to it?
> >>>>>>
> >>>>>> Personally, I've spoken to all 5 privately and they've all confirm=
ed to
> >>>>>> me that they are willing to be BIPs editors. Jonatack[1] and Murch=
[2]
> >>>>>> have also replied to this thread about this.
> >>>>>>
> >>>>>> Ava
> >>>>>>
> >>>>>> [1]:
> >>>>>> https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac=
0bbn@googlegroups.com/
> >>>>>> [2]:
> >>>>>> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e=
778@murch.one/
> >>>>>>
> >>>>>>>
> >>>>>>> On Sat, Apr 20, 2024 at 12:30=E2=80=AFPM 'Ava Chow' via Bitcoin D=
evelopment
> >>>>>>> Mailing List <bitcoindev@googlegroups.com
> >>>>>>> <mailto:bitcoindev@googlegroups.com>> wrote:
> >>>>>>>
> >>>>>>>        Since we're now past the deadline of April 19th, I'd like =
to inform
> >>>>>>>        everyone of what will happen on Monday.
> >>>>>>>
> >>>>>>>        There has not been any actual objections to the nominees n=
or have there
> >>>>>>>        been any suggestions on choosing a subset of them since my=
 last email.
> >>>>>>>        As such, there is rough consensus on adding Kanzure, Murch=
, Jonatack,
> >>>>>>>        Ruben, and Roasbeef as BIP editors, and they will be added=
 on Monday
> >>>>>>>        April 22nd.
> >>>>>>>
> >>>>>>>        Ava
> >>>>>>>
> >>>>>>>        On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development=
 Mailing List
> >>>>>>>        wrote:
> >>>>>>>         > While I don't disagree that 5 or 6 people seems like a =
lot to add at
> >>>>>>>         > once, it's not clear to me how we should decide which s=
ubset of the
> >>>>>>>         > nominees should be added. As it is now, I have only see=
n an actual
> >>>>>>>         > objection to Kanzure and Ruben from /dev/fd0, and no ex=
plicit
> >>>>>>>        objections
> >>>>>>>         > to anyone else. It seems like the vast majority of peop=
le don't share
> >>>>>>>         > their concerns either as both Kanzure and Ruben continu=
e to be
> >>>>>>>        endorsed
> >>>>>>>         > by many others.
> >>>>>>>         >
> >>>>>>>         > Looking at the endorsements each candidate has received=
, the current
> >>>>>>>         > counts are:
> >>>>>>>         > * Kanzure - 17 for, 1 against
> >>>>>>>         > * Murch - 13 for
> >>>>>>>         > * Jonatack - 13 for
> >>>>>>>         > * Ruben - 12 for, 1 against
> >>>>>>>         > * Roasbeef - 9 for
> >>>>>>>         > * Michael Folkson - none
> >>>>>>>         >
> >>>>>>>         > However, I don't want this process to become a populari=
ty contest and
> >>>>>>>         > require some kind of formal voting. Rather I'd prefer t=
hat this
> >>>>>>>        process
> >>>>>>>         > be something more like how Bitcoin Core maintainers are=
 added - by
> >>>>>>>         > achieving rough consensus. Without any explicit objecti=
ons to any of
> >>>>>>>         > these candidates, I'm inclined to move forward with add=
ing the 5 who
> >>>>>>>         > have received endorsements. Having to pick "winners" fr=
om this list
> >>>>>>>         > seems like a quick way to stir up drama that I don't th=
ink anyone
> >>>>>>>        really
> >>>>>>>         > wants to deal with.
> >>>>>>>         >
> >>>>>>>         > I do want to note that neither Kanzure, Ruben, nor Roas=
beef have
> >>>>>>>        posted
> >>>>>>>         > on this list that they are willing to be BIP editors. I=
 have
> >>>>>>>        reached out
> >>>>>>>         > to all 3 of them privately, and received responses from=
 Kanzure and
> >>>>>>>         > Ruben that indicate that they probably are willing, but=
 public
> >>>>>>>         > confirmation from them on this list would also be nice.=
 I have not
> >>>>>>>         > received a response from Roasbeef.
> >>>>>>>         >
> >>>>>>>         > Ava
> >>>>>>>         >
> >>>>>>>         > On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
> >>>>>>>         >>   > I would prefer having more (9+?) than less folks o=
n this
> >>>>>>>        task, so
> >>>>>>>         >> personal preferences are easily ignored and overwritte=
n by the group
> >>>>>>>         >> majority.
> >>>>>>>         >>
> >>>>>>>         >> I disagree with that, the more doesn't really the bett=
er here.
> >>>>>>>        Having
> >>>>>>>         >> too many editors may result in a tragedy of the common=
s, in
> >>>>>>>        which people
> >>>>>>>         >> just commit to the job because many others do, and the=
y do not
> >>>>>>>        end up
> >>>>>>>         >> doing as much because they expect others to do the it.=
 This does not
> >>>>>>>         >> only make the process look bad but may burnout the one=
s that end up
> >>>>>>>         >> doing the job, given their time commitment ends up bei=
ng too far
> >>>>>>>        from
> >>>>>>>         >> their expectations.
> >>>>>>>         >>
> >>>>>>>         >> I think being more moderate with the amount of people =
is better, and
> >>>>>>>         >> gives us leeway in case the workload ends up being exc=
essive and
> >>>>>>>        we need
> >>>>>>>         >> to add more people (plus discourage people from joinin=
g and
> >>>>>>>        slacking off).
> >>>>>>>         >>
> >>>>>>>         >> I think 3 more people should be a good number to start=
 from.
> >>>>>>>         >> I'd personally vouch for Murch, Kanzure, and Ruben bas=
ed on
> >>>>>>>        their track
> >>>>>>>         >> record in the space
> >>>>>>>         >>
> >>>>>>>         >> On Tue, Apr 2, 2024 at 4:30=E2=80=AFPM nvk <rdlfnvk@gm=
ail.com
> >>>>>>>        <mailto:rdlfnvk@gmail.com>
> >>>>>>>         >> <mailto:rdlfnvk@gmail.com <mailto:rdlfnvk@gmail.com>>>=
 wrote:
> >>>>>>>         >>
> >>>>>>>         >> +1 for
> >>>>>>>         >> Kanzure
> >>>>>>>         >> RubenSomsen
> >>>>>>>         >> Seccour
> >>>>>>>         >> Jon Atack
> >>>>>>>         >> Roasbeef
> >>>>>>>         >>
> >>>>>>>         >> I would prefer having more (9+?) than less folks on th=
is task, so
> >>>>>>>         >> personal preferences are easily ignored and overwritte=
n by the group
> >>>>>>>         >> majority.
> >>>>>>>         >>
> >>>>>>>         >> BIPs were intended as a means to collect ideas, not en=
force ideas.
> >>>>>>>         >>
> >>>>>>>         >> I'd like to return to that.
> >>>>>>>         >>
> >>>>>>>         >> - NVK (temp gmail account)
> >>>>>>>         >>
> >>>>>>>         >>      On Monday, April 1, 2024 at 5:16:54=E2=80=AFPM UT=
C-4 David A.
> >>>>>>>        Harding wrote:
> >>>>>>>         >>
> >>>>>>>         >>          On 2024-03-28 10:04, Matt Corallo wrote:
> >>>>>>>         >>           > Please provide justification rather than s=
imply
> >>>>>>>        saying "I
> >>>>>>>         >>          like Bob!".
> >>>>>>>         >>
> >>>>>>>         >>          Using only comments from the mailing list, th=
e
> >>>>>>>        following appears
> >>>>>>>         >>          to be
> >>>>>>>         >>          the candidate list along with the current sup=
port.
> >>>>>>>        Asterisks denote
> >>>>>>>         >>          candidates who indicated their willingness to=
 accept
> >>>>>>>        the role.
> >>>>>>>         >>
> >>>>>>>         >>          - Bryan "Kanzure" Bishop, recommended by Ava =
Chow[1], Chris
> >>>>>>>         >>          Stewart[3],
> >>>>>>>         >>          Michael Folkson[6], Peter Todd[9], Matt Coral=
lo[10],
> >>>>>>>        Brandon
> >>>>>>>         >>          Black[11],
> >>>>>>>         >>          Antoine Riard[12], Murch[13], Antoine Poinsot=
[15], John
> >>>>>>>         >>          Carvalho[16]
> >>>>>>>         >>
> >>>>>>>         >>          - Ruben Somsen, recommended by Ava Chow[1], C=
hris
> >>>>>>>        Stewart[3],
> >>>>>>>         >>          Michael
> >>>>>>>         >>          Folkson[6], Antoine Riard[12], Murch[13], Ant=
oine
> >>>>>>>        Poinsot[15], John
> >>>>>>>         >>          Carvalho[16]
> >>>>>>>         >>
> >>>>>>>         >>          - Jon Atack*, recommended by Luke Dashjr[2], =
Chris
> >>>>>>>        Stewart[3],
> >>>>>>>         >>          /dev/fd0[5][7],
> >>>>>>>         >>          Brandon Black[11], Antoine Riard[12], Ava Cho=
w[14], John
> >>>>>>>         >>          Carvalho[16]
> >>>>>>>         >>
> >>>>>>>         >>          - Olaoluwa "Roasbeef" Osuntokun, recommended =
by Chris
> >>>>>>>         >>          Stewart[3], John
> >>>>>>>         >>          C. Vernaleo[4], /dev/fd0[5][7], Keagan McClel=
land[8],
> >>>>>>>        Antoine
> >>>>>>>         >>          Riard[12], Ava Chow[14]
> >>>>>>>         >>
> >>>>>>>         >>          - Mark "Murch" Erhardt*, recommended by Micha=
el
> >>>>>>>        Folkson[6], Keagan
> >>>>>>>         >>          McClelland[8], Matt Corallo[10], Brandon Blac=
k[11], Antoine
> >>>>>>>         >>          Riard[12],
> >>>>>>>         >>          Ava Chow[14]
> >>>>>>>         >>
> >>>>>>>         >>          - Michael Folkson*
> >>>>>>>         >>
> >>>>>>>         >>          Note: Luke Dashjr proposed[17] Seccour and Gr=
eg Tonoski for
> >>>>>>>         >>          "non-dev
> >>>>>>>         >>          triaging", Tonoski proposed himself[18] for "=
BIP
> >>>>>>>        editor", and
> >>>>>>>         >>          Antoine
> >>>>>>>         >>          Riard[12] proposed Seccour for "decentralized=
 PM".
> >>>>>>>         >>
> >>>>>>>         >>          I searched the BIPs repo by commenter to see =
if any of
> >>>>>>>        the above
> >>>>>>>         >>          candidates had been especially active there, =
which is
> >>>>>>>        listed
> >>>>>>>         >>          below as:
> >>>>>>>         >>          total PRs they commented on (number still ope=
n/number
> >>>>>>>        closed).
> >>>>>>>         >>
> >>>>>>>         >>          - 21 (1/20) commenter:kanzure
> >>>>>>>         >>          - 3 (2/1) commenter:rubensomsen
> >>>>>>>         >>          - 15 (0/15) commenter:jonatack
> >>>>>>>         >>          - 18 (2/16) commenter:roasbeef
> >>>>>>>         >>          - 10 (6/4) commenter:Murchandamus
> >>>>>>>         >>          - 57 (6/51) commenter:michaelfolkson
> >>>>>>>         >>
> >>>>>>>         >>          I'll also note that Osuntokun is the only mem=
ber of the
> >>>>>>>        set to
> >>>>>>>         >>          have a
> >>>>>>>         >>          merged BIP that they co-authored, although I =
believe
> >>>>>>>        there are
> >>>>>>>         >>          far-along
> >>>>>>>         >>          draft BIPs for both Murch (terminology) and S=
omsen (Silent
> >>>>>>>         >>          Payments). I
> >>>>>>>         >>          don't think this should be a requirement, but=
 I do think it
> >>>>>>>         >>          demonstrates
> >>>>>>>         >>          familiarity with the process.
> >>>>>>>         >>
> >>>>>>>         >>          Speaking only for myself, I think all of the =
candidates
> >>>>>>>        above with
> >>>>>>>         >>          multiple recommendations from other community
> >>>>>>>        participants are
> >>>>>>>         >>          fully
> >>>>>>>         >>          qualified for the role, so I'll only provide =
a detailed
> >>>>>>>         >>          justification
> >>>>>>>         >>          for the person who would be my first pick: Mu=
rch is not
> >>>>>>>        only a
> >>>>>>>         >>          longstanding and broadly liked Bitcoin contri=
butor, but
> >>>>>>>        (as Corallo
> >>>>>>>         >>          mentioned) he has worked on standardizing ter=
minology
> >>>>>>>        through a
> >>>>>>>         >>          draft
> >>>>>>>         >>          BIP. In addition, he provided an extremely de=
tailed
> >>>>>>>        review of
> >>>>>>>         >>          all 300
> >>>>>>>         >>          pages of a draft of Mastering Bitcoin (3rd ed=
ition) and has
> >>>>>>>         >>          reviewed
> >>>>>>>         >>          drafts of over 200 weekly Optech newsletters,=
 in both cases
> >>>>>>>         >>          significantly improving the accuracy and
> >>>>>>>        comprehensibility of the
> >>>>>>>         >>          documentation. To me, that seems very similar=
 to the
> >>>>>>>        work we'd
> >>>>>>>         >>          ask him
> >>>>>>>         >>          to perform as a BIPs editor and it's somethin=
g that
> >>>>>>>        he's already
> >>>>>>>         >>          doing,
> >>>>>>>         >>          so I think there's an excellent fit of person=
 to role.
> >>>>>>>         >>
> >>>>>>>         >>          -Dave
> >>>>>>>         >>
> >>>>>>>         >>          [1]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@ach=
ow101.com/
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@ac=
how101.com/> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d9=
7927551e@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8=
-ba1a-c9d97927551e@achow101.com/>>
> >>>>>>>         >>          [2]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@das=
hjr.org/
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@da=
shjr.org/>
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-=
c1ff8f8a62a3@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-41=
06-b843-c1ff8f8a62a3@dashjr.org/>>
> >>>>>>>         >>          [3]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@goo=
glegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@goog=
legroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cd=
dc46f129a2n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30=
e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>>
> >>>>>>>         >>          [4]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@net=
purgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netp=
urgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bd=
d55899b713@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e84=
8-d333-fd28-bdd55899b713@netpurgatory.com/>>
> >>>>>>>         >>          [5]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@goo=
glegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@goog=
legroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c=
3719157fabn@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea=
1c-4a36-be81-7c3719157fabn@googlegroups.com/>>
> >>>>>>>         >>          [6]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@goo=
glegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@goog=
legroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-63=
9a3564d006n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-59=
48-48d2-a787-639a3564d006n@googlegroups.com/>>
> >>>>>>>         >>          [7]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@goo=
glegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@goog=
legroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55=
d346efbea1n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-83=
86-4869-a3b1-55d346efbea1n@googlegroups.com/>>
> >>>>>>>         >>          [8]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8t=
X=3DwruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeF=
GL1-LKPWd7YRS110ut8tX=3DwruqgLEazRA5...@mail.gmail.com/> <https://gnusha.or=
g/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=3DwruqgLEazRA5nVw9siYCPj4A@mail.=
gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=3Dw=
ruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>>
> >>>>>>>         >>          [9]
> >>>>>>>        https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org=
/
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.or=
g/>
> >>>>>>>         >>
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@peterto=
dd.org/
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@peterto=
dd.org/>>
> >>>>>>>         >>          [10]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mat=
tcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattc=
orallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0=
336a9bf2@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-4=
6b5-86e2-7ba0336a9bf2@mattcorallo.com/>>
> >>>>>>>         >>          [11]
> >>>>>>>        https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console=
/>
> >>>>>>>         >>
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console=
/
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console=
/>>
> >>>>>>>         >>          [12]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E=
...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+Fi=
F6+E...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9=
aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/ <https://gnusha.org/pi/=
bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.c=
om/>>
> >>>>>>>         >>          [13]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@mur=
ch.one/
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@mu=
rch.one/>
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-=
32bd88d5e778@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441=
a-920b-32bd88d5e778@murch.one/>>
> >>>>>>>         >>          [14]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@ach=
ow101.com/
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@ac=
how101.com/> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555=
b80b0644@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f=
-866d-c555b80b0644@achow101.com/>>
> >>>>>>>         >>          [15]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0Wp=
T5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2=
jS4xojo=3D@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX8=
5kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7=
bXOH4gwU1c2jS4xojo=3D@protonmail.com/> <https://gnusha.org/pi/bitcoindev/pp=
BS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZW=
awf8IDApPqF7bXOH4gwU1c2jS4xojo=3D@protonmail.com/ <https://gnusha.org/pi/bi=
tcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E6=
9qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=3D@protonmail.com/>>
> >>>>>>>         >>          [16]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@goo=
glegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@goog=
legroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11=
b9ed340661n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e9=
9c-4552-88ca-11b9ed340661n@googlegroups.com/>>
> >>>>>>>         >>          [17]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJ=
U=3D=3DYJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAM=
HHROw9mZJRnTbUo76PdqwJU=3D=3DYJMvd9Qrst+...@mail.gmail.com/> <https://gnush=
a.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU=3D=3DYJMvd9Qrst+nmyypaedYZgg=
@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76Pdqw=
JU=3D=3DYJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/>>
> >>>>>>>         >>
> >>>>>>>         >>      --
> >>>>>>>         >>      You received this message because you are subscri=
bed to the
> >>>>>>>        Google
> >>>>>>>         >>      Groups "Bitcoin Development Mailing List" group.
> >>>>>>>         >>      To unsubscribe from this group and stop receiving=
 emails
> >>>>>>>        from it,
> >>>>>>>         >>      send an email to bitcoindev+unsubscribe@googlegro=
ups.com
> >>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups.com>
> >>>>>>>         >>      <mailto:bitcoindev+unsubscribe@googlegroups.com
> >>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups.com>>.
> >>>>>>>         >>      To view this discussion on the web visit
> >>>>>>>         >>
> >>>>>>>        https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96=
-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/ms=
gid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com> <h=
ttps://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7=
b0bben%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter <https://g=
roups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%4=
0googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>>.
> >>>>>>>         >>
> >>>>>>>         >>
> >>>>>>>         >>
> >>>>>>>         >> --
> >>>>>>>         >> Sergi.
> >>>>>>>         >>
> >>>>>>>         >> --
> >>>>>>>         >> You received this message because you are subscribed t=
o the Google
> >>>>>>>         >> Groups "Bitcoin Development Mailing List" group.
> >>>>>>>         >> To unsubscribe from this group and stop receiving emai=
ls from
> >>>>>>>        it, send
> >>>>>>>         >> an email to bitcoindev+unsubscribe@googlegroups.com
> >>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups.com>
> >>>>>>>         >> <mailto:bitcoindev+unsubscribe@googlegroups.com
> >>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups.com>>.
> >>>>>>>         >> To view this discussion on the web visit
> >>>>>>>         >>
> >>>>>>>        https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw=
61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups=
.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCg=
m%2B-4WxT9w%40mail.gmail.com> <https://groups.google.com/d/msgid/bitcoindev=
/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?u=
tm_medium=3Demail&utm_source=3Dfooter <https://groups.google.com/d/msgid/bi=
tcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter>>.
> >>>>>>>         >
> >>>>>>>         > --
> >>>>>>>         > You received this message because you are subscribed to=
 the
> >>>>>>>        Google Groups "Bitcoin Development Mailing List" group.
> >>>>>>>         > To unsubscribe from this group and stop receiving email=
s from it,
> >>>>>>>        send an email to bitcoindev+unsubscribe@googlegroups.com
> >>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups.com>.
> >>>>>>>         > To view this discussion on the web visit
> >>>>>>>        https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942=
-4db8-b880-3c06ebc47cd1%40achow101.com <https://groups.google.com/d/msgid/b=
itcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com>.
> >>>>>>>
> >>>>>>>        --
> >>>>>>>        You received this message because you are subscribed to th=
e Google
> >>>>>>>        Groups "Bitcoin Development Mailing List" group.
> >>>>>>>        To unsubscribe from this group and stop receiving emails f=
rom it,
> >>>>>>>        send an email to bitcoindev+unsubscribe@googlegroups.com
> >>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups.com>.
> >>>>>>>        To view this discussion on the web visit
> >>>>>>>        https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9=
-4903-9524-dd8ef98c1c8b%40achow101.com <https://groups.google.com/d/msgid/b=
itcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com>.
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> You received this message because you are subscribed to the Google=
 Groups "Bitcoin Development Mailing List" group.
> >>>>>> To unsubscribe from this group and stop receiving emails from it, =
send an email to bitcoindev+unsubscribe@googlegroups.com.
> >>>>>> To view this discussion on the web visit https://groups.google.com=
/d/msgid/bitcoindev/0d4d85e3-9fbb-4bd4-af0f-92225e699b63%40achow101.com.
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Michael Folkson
> >>>>> Personal email: michaelfolkson@gmail.com
> >>>>
> >>>
> >>>
> >>> --
> >>> Michael Folkson
> >>> Personal email: michaelfolkson@gmail.com
> >>
> >
> >
> > --
> > Michael Folkson
> > Personal email: michaelfolkson@gmail.com
>


--=20
Michael Folkson
Personal email: michaelfolkson@gmail.com

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/CAFvNmHSCsb37HmKom0GCezfTnNF6dnoVT6c_A-bVB4or2t%2B6oA%40mail.gma=
il.com.