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

From: Michael Folkson <[email-masked]>
Date: Mon, 1 Apr 2024 12:58:22 +0100

> f there is no guidance provided by Luke to the new BIP editors when their permissions are granted

I know this isn't how Core maintainers like to operate but perhaps
this guidance to BIPs editors could be public and transparent. There
isn't any need for BIP editors to go the Core maintainer route of
onboarding new maintainers and discussing merge decisions that impact
Core users and the broader community privately and in the shadows. To
the extent that there is disagreement or personal judgment required
that's fine. Say so in public.

On Sun, Mar 31, 2024 at 7:31 PM 'Ava Chow' via Bitcoin Development
Mailing List <[email-masked]> 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 [email-masked].
> > 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 [email-masked].
> To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644%40achow101.com.

-- 
Michael Folkson
Personal email: [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].
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/CAFvNmHRUgF7bD9%2BJO3APBW-y6WRf%3D6tfut4AeFKmVWjR183HTg%40mail.gmail.com.