An alternative approach for BIP numbers:

1. A bot assigns a temporary number to each pull request opened with "NEW:" in title based on GitHub pull request number and append B in front of it. Example: B1551
2. BIP editors and others could review to improve the BIP documentation. BIP author can use this number for the BIP until pull request is open.
3. Once the pull request is merged, it is assigned a permanent number which can be used to refer this doc in future.

Both numbers would stay relevant and if someone is not aware of permanent number, they could easily check it by opening pull request.

Other things CI can be used for:
- Automated grammar check when pull request is opened/re-opened
- Publish a copy of BIP as torrent or nostr event etc. when pull request is merged

/dev/fd0
floppy disk guy

On Sunday, March 31, 2024 at 6:31:14 PM UTC 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/4884f5b9-69d5-45be-90d2-7369784ddd72n%40googlegroups.com.