Subject: Re: [bitcoindev] Re: Adding New BIP Editors

From: Luke Dashjr <[email-masked]>
Date: Tue, 02 Apr 2024 09:39:25 -0600

On the timeline, there has already been a very reasonable objection raised by Antoine. I'm also unlikely to be available around that time (and through the weekend) to actually do it. So it'll need to be next week at the earliest, but I don't see a problem with closer to May if that's important to some.

Luke

On April 2, 2024 9:13:46 AM CST, Gloria Zhao <[email-masked]> wrote:
>> If we are all just in a holding pattern, perhaps we could timebox this 
>> decision process: how about we invite arguments for and against any 
>> candidates in this thread until next Friday EOD (April 5th). If any 
>> candidates find broad support, those candidates could be added as new 
>> editors to the repository on the following Monday (April 8th).
>
>Thanks, ACK this timeline for moving forward.
>
>Assuming they are willing, I am in favor of adding Murch, Ruben, and 
>Kanzure as BIP editors. They have all demonstrated through years of 
>experience contributing to / moderating {the mailing list, stack exchange, 
>Optech} that they have the technical expertise, skills in technical 
>documentation, and track record of good judgement appropriate for this role.
>
>Best,
>Gloria
>
>On Tuesday, April 2, 2024 at 3:30:58 PM UTC+1 Luke Dashjr wrote:
>
>> No, there was no such refusal. The ONLY issue at hand with regard to more 
>> BIP editors is that I don't have time to keep up with it by myself. If your 
>> goal is anything else, please sit this discussion out (aside from perhaps 
>> reasonable objections to new editors). BIP number assignments are trivial 
>> and not a concern.
>>
>> It seems there's an attempt to take advantage of the need for more BIP 
>> editors to change or bypass the BIP process without proper procedures 
>> followed. While there may be arguments for improving the BIP process, that 
>> is unrelated and would need to go through a BIP, not simply fiat of a new 
>> editor. Any potential new editor will need to follow the BIP process as it 
>> currently is defined until such a new BIP is accepted.
>>
>> Luke
>>
>>
>> On April 2, 2024 7:49:22 AM CST, /dev /fd0 <[email-masked]> wrote:
>>
>>> >  Does it matter? The number that a proposal gets has no impact on
>>> > literally anything else. They could do it sequentially and it wouldn't
>>> > actually make a difference as long as there are no collisions.
>>>
>>> Process followed to assign the number started this whole debate recently 
>>> and creation of BINANA. Previous BIP editor refused to assign numbers to 
>>> some BIPs. Kanzure had [tweeted][0] asking users on twitter if a BIP should 
>>> be assigned number. So I am curious what process exactly would be followed 
>>> by new BIP editors.
>>>
>>> > For example, this was done when Luke was hacked -
>>> > all of his permissions were immediately removed as soon as the news came
>>> > out, and were only returned several months later once verified
>>> > communication with Luke were established and he was certain that his
>>> > GitHub account was no longer (at risk of being) compromised.
>>>
>>> Thanks for sharing. I wasn't aware of this.
>>>
>>> [0]: https://x.com/kanzure/status/1752663903715168280
>>>
>>> /dev/fd0
>>> floppy disk guy
>>>
>>> On Tuesday, April 2, 2024 at 8:22:16 AM UTC Ava Chow wrote:
>>>
>>>>
>>>>
>>>> On 04/01/2024 07:55 PM, /dev /fd0 wrote: 
>>>> > I think before we decide new BIP editors its important to discuss some 
>>>> > things about the process itself: 
>>>> > 
>>>> > 1. Quoting first paragraph from BIPs repo README: "People wishing to 
>>>> > submit BIPs, first should propose their idea or document to the 
>>>> > [email-masked] mailing list (do not assign a 
>>>> > number - read BIP 2 for the full process). After discussion, please 
>>>> open 
>>>> > a PR. After copy-editing and acceptance, it will be published here." 
>>>> > 
>>>> > If Kanzure and Ruben are BIP editors, does it mean they can censor 
>>>> > someone from submitting BIPs? This question makes sense because they 
>>>> > will have control over the whole improvement process for "bitcoin" by 
>>>> > being moderators for mailing list and BIP editors. 
>>>>
>>>> If the only requirement is that a BIP shows up on the mailing list 
>>>> first, then they can already censor them. Having them as BIP editors 
>>>> wouldn't change that. It's not clear to me that this requirement is 
>>>> strictly enforced anyways. 
>>>>
>>>> Furthermore, they would not have the permissions to delete PRs or 
>>>> issues, so once a PR is opened, even if closed, would still be there. 
>>>> The status quo w.r.t that would not be any different. At worst, they 
>>>> could refuse to assign a BIP a number, but that's no different than what 
>>>> already happens today. In fact, the situation would likely be better 
>>>> because there would be multiple BIP editors and so what goes into the 
>>>> repo is not at the whim of a single person. 
>>>>
>>>> > 2. How are numbers going to be assigned to BIPs? 
>>>>
>>>> Does it matter? The number that a proposal gets has no impact on 
>>>> literally anything else. They could do it sequentially and it wouldn't 
>>>> actually make a difference as long as there are no collisions. 
>>>>
>>>> > 3. Will there be copy of BIPs and pull requests maintained elsewhere 
>>>> > like bitcoin core? 
>>>>
>>>> I'm not sure why this is relevant to this discussion, but presumably 
>>>> there already are, and if there aren't, you can do it yourself. It's 
>>>> just like any other repo on GitHub. 
>>>>
>>>> > 4. What are the expectations from new BIP editors? In what situation 
>>>> do 
>>>> > we look for next BIP editors or in other words, what will be the 
>>>> process 
>>>> > to remove an editor if lot of people are unhappy with their work? 
>>>>
>>>> The expectations are as outlined to BIP 2, and that they are actually 
>>>> active. The situation for looking for new BIP editors in the future is 
>>>> presumably similar to the one we are in currently - people who write 
>>>> BIPs are frustrated with things taking a long time to be merged with the 
>>>> root cause being slow response times from the current editor. The 
>>>> process would likely be very similar: names are proposed, there is 
>>>> discussion about those people, and eventually some are added. 
>>>>
>>>> As for removal, this has not been something we've ever done before, so 
>>>> the process for this is undefined. However, it would presumably be a 
>>>> similar procedure as for adding someone. It begins with someone raising 
>>>> a complaint about one of the editors on this mailing list or some other 
>>>> place a discussion, and a community discussion commences about whether 
>>>> or not to remove them. 
>>>>
>>>> There are certainly situations where one of the GitHub org owners may 
>>>> take emergency action and remove a maintainer's privileges. This is only 
>>>> done when there is a clear danger than the account may do something 
>>>> malicious, and the privileges would be returned if there is clarity that 
>>>> it is safe to do so. For example, this was done when Luke was hacked - 
>>>> all of his permissions were immediately removed as soon as the news came 
>>>> out, and were only returned several months later once verified 
>>>> communication with Luke were established and he was certain that his 
>>>> GitHub account was no longer (at risk of being) compromised. 
>>>>
>>>> Ava 
>>>>
>>>> > 
>>>> > /dev/fd0 
>>>> > floppy disk guy 
>>>> > 
>>>> > On Monday, April 1, 2024 at 9:16:54 PM UTC David A. Harding wrote: 
>>>> > 
>>>> > On 2024-03-28 10:04, Matt Corallo wrote: 
>>>> > > Please provide justification rather than simply saying "I like 
>>>> > Bob!". 
>>>> > 
>>>> > Using only comments from the mailing list, the following appears to be 
>>>> > the candidate list along with the current support. 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 Corallo[10], Brandon 
>>>> > Black[11], 
>>>> > Antoine Riard[12], Murch[13], Antoine Poinsot[15], John Carvalho[16] 
>>>> > 
>>>> > - Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3], Michael 
>>>> > Folkson[6], Antoine Riard[12], Murch[13], Antoine 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 Chow[14], John Carvalho[16] 
>>>> > 
>>>> > - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris Stewart[3], John 
>>>> > C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine 
>>>> > Riard[12], Ava Chow[14] 
>>>> > 
>>>> > - Mark "Murch" Erhardt*, recommended by Michael Folkson[6], Keagan 
>>>> > McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine Riard[12], 
>>>> > Ava Chow[14] 
>>>> > 
>>>> > - Michael Folkson* 
>>>> > 
>>>> > Note: Luke Dashjr proposed[17] Seccour and Greg 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 open/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 member 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 Somsen (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: Murch is not only a 
>>>> > longstanding and broadly liked Bitcoin contributor, but (as Corallo 
>>>> > mentioned) he has worked on standardizing terminology through a draft 
>>>> > BIP. In addition, he provided an extremely detailed review of all 300 
>>>> > pages of a draft of Mastering Bitcoin (3rd edition) 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 something that he's already 
>>>> doing, 
>>>> > so I think there's an excellent fit of person to role. 
>>>> > 
>>>> > -Dave 
>>>> > 
>>>> > [1] 
>>>> > https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> > <https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <https://gnusha.org/pi/bitcoindev/[email-masked]/>> 
>>>>
>>>> > [2] 
>>>> > https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> > <https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <https://gnusha.org/pi/bitcoindev/[email-masked]/>> 
>>>>
>>>> > [3] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <
>>>> https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <https://gnusha.org/pi/bitcoindev/[email-masked]/>> 
>>>>
>>>> > [4] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <
>>>> https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <https://gnusha.org/pi/bitcoindev/[email-masked]/>> 
>>>>
>>>> > [5] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <
>>>> https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <https://gnusha.org/pi/bitcoindev/[email-masked]/>> 
>>>>
>>>> > [6] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <
>>>> https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <https://gnusha.org/pi/bitcoindev/[email-masked]/>> 
>>>>
>>>> > [7] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <
>>>> https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <https://gnusha.org/pi/bitcoindev/[email-masked]/>> 
>>>>
>>>> > [8] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=[email-masked]/ 
>>>> <
>>>> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=[email-masked]/ 
>>>> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=[email-masked]/>> 
>>>>
>>>> > [9] https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> > <https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <https://gnusha.org/pi/bitcoindev/[email-masked]/>> 
>>>> > [10] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <https://gnusha.org/pi/bitcoindev/[email-masked]/>> 
>>>>
>>>> > [11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/ 
>>>> > <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/> 
>>>> > [12] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <
>>>> https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <https://gnusha.org/pi/bitcoindev/[email-masked]/>> 
>>>>
>>>> > [13] 
>>>> > https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> > <https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <https://gnusha.org/pi/bitcoindev/[email-masked]/>> 
>>>>
>>>> > [14] 
>>>> > https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> > <https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <https://gnusha.org/pi/bitcoindev/[email-masked]/>> 
>>>>
>>>> > [15] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ 
>>>> <
>>>> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/> 
>>>>
>>>> > [16] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <
>>>> https://gnusha.org/pi/bitcoindev/[email-masked]/ 
>>>> <https://gnusha.org/pi/bitcoindev/[email-masked]/>> 
>>>>
>>>> > [17] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==[email-masked]/ 
>>>> <
>>>> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==[email-masked]/ 
>>>> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==[email-masked]/>> 
>>>>
>>>> > 
>>>> > -- 
>>>> > 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 [email-masked] 
>>>> > <mailto:[email-masked]>. 
>>>> > To view this discussion on the web visit 
>>>> > 
>>>> https://groups.google.com/d/msgid/bitcoindev/cbb0b74f-c60b-4c8a-9e97-9b1c0e0eb047n%40googlegroups.com 
>>>> <
>>>> https://groups.google.com/d/msgid/bitcoindev/cbb0b74f-c60b-4c8a-9e97-9b1c0e0eb047n%40googlegroups.com?utm_medium=email&utm_source=footer>. 
>>>>
>>>>
>>>>
>
>-- 
>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 [email-masked].
>To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/a18850ec-4659-4683-8e50-9758a7f431can%40googlegroups.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 [email-masked].
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/847D8B06-9F61-4515-B6B2-6093E7F7A80D%40dashjr.org.