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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/52a0d792-d99f-4360-ba34-0b12de183fef%40murch.one.