Hello there! I'm not an active contributor but I've been following the mailing list for years, and try to keep a close eye on the most important aspects of Bitcoin. Throwing in my support for Jon Atack and Kanzure, who's work I follow more closely. The others I am less familiar with. Nevertheless I agree with NVK that the more editors this process has, the better. No need for this to be a bottleneck. Jon in particular I know has years of experience with copy editing, documentation and review of Bitcoin core code. Cheers! Juan Galt On Sunday, March 31, 2024 at 1:31:14 PM UTC-5 Ava Chow wrote: > Thanks for bringing this back up again. I agree that we should try to > move forward on this, and this timeline seems reasonable to me. > > Kanzure, Ruben, Roasbeef, Murch, and Jonatack all have my support to be > BIP editors with all privileges and responsibilities as laid out in BIP 2. > > Regarding guidance on assigning BIP numbers, if there is no guidance > provided by Luke to the new BIP editors when their permissions are > granted, I would also support simply creating their own numbering scheme > and begin assigning new BIP numbers. It's ridiculous that we should be > bottlenecked on simply what number a proposal should have. > > Ava > > On 03/27/2024 05:25 PM, Murch wrote: > > Hey everyone, > > > > I wanted to check in on the topic adding BIP Editors. There seem to be a > > number of candidates that are willing and able, and there seems to be > > broad agreement among the current editor, the readers of the repository, > > and the contributors to the repository that additional help is desirable. > > > > I have seen some support and reservations raised for pretty much every > > candidate. A few weeks have passed since this topic was last active. So > > far, there seems no clear path forward. > > > > 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). If none > > get broad support, at least we’d be able to move on and try something > else. > > > > I propose that all editors share the same privileges, especially that > > any editor may assign numbers to BIPs. If there is guidance to be > > provided on the process of assigning numbers and number ranges for > > specific topics, it should be provided by then. If the editors decide on > > a single number authority among themselves, that would also be fine as > > long as it doesn’t become a bottleneck. > > > > As Tim and Chris have suggested, it seems reasonable to me that > > assessment of the technical soundness can be left to the audience. BIPs > > have been published in the repository and set to the "rejected" status > > before, so it’s not as if adding a BIP to the repository is treated as > > an unequivocal endorsement or implementation recommendation. > > > > Cheers, > > Murch > > > > > > On 3/14/24 07:56, Chris Stewart wrote: > >> I agree with Tim's thoughts here. > >> > >> I think Jon Atack, Reuben Somsen, Kanzure or Roasbeef would all make > great > >> candidates. > >> > >> On Thursday, February 29, 2024 at 10:55:52 AM UTC-6 Tim Ruffing wrote: > >> > >>> On Tue, 2024-02-27 at 17:40 -0500, Luke Dashjr wrote: > >>>> The hard part is evaluating > >>>> if the new proposal meets the criteria - which definitely needs dev > >>>> skills (mainly for technical soundness). > >>> > >>> I'm aware that checking technical soundness is in accordance with BIP2 > >>> [1], but I believe that this is one of the main problems of the current > >>> process, and I can imagine that this is what eats the time of editors. > >>> > >>> I'd prefer a BIP process in which the editors merely check that the > >>> proposal is related to the Bitcoin ecosystem and meets some minimal > >>> formal criteria that we already enforce now (i.e., is a full self- > >>> contained document, has the required sections, etc...). This relieves > >>> the editors not just from the effort, but also from the responsibility > >>> to do so. Technical soundness should be evaluated by the audience of a > >>> BIP, not by the editor. > >>> > >>> Best, > >>> Tim > >>> > >>> > >>> [1] BIP2 says: > >>> "For each new BIP that comes in an editor does the following: > >>> > >>> - Read the BIP to check if it is ready: sound and complete. The ideas > >>> must make technical sense, even if they don't seem likely to be > >>> accepted. > >>> [...]" > > > > -- > > 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. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/bitcoindev/52a0d792-d99f-4360-ba34-0b12de183fef%40murch.one > . > > -- 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/fb4b32a9-f7c2-4ab7-b194-6f153cd8ef2en%40googlegroups.com.