> 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
>
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.
/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
> bitco...@lists.linuxfoundation.org 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/2092f7ff-4860-47f8...@achow101.com/
> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/>
> [2]
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>
> [3]
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>
> [4]
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>
> [5]
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>
> [6]
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>
> [7]
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>
> [8]
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/>
> [9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
> [10]
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/>
> [11] 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+FiF6+E...@mail.gmail.com/>
> [13]
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
> <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>
> [14]
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>
> [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/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>
> [17]
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.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+...@googlegroups.com
> <mailto:bitcoindev+...@googlegroups.com>.
> 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>.