Adding New BIP Editors

[Ava Chow]

Hi All,

Following on the recent [discussion][1] about BIP process friction, and
admissions from Luke that he has not had the time to actively work on
the BIPs repo ([2], [3]), I think it is prudent for us to look at adding
more BIPs editors. These people would have the same permissions and
responsibilities that Luke has, i.e. can assign BIP numbers, merge PRs
adding new BIPs, merge PRs to fix existing BIPs,and all other
responsibilities as described in [BIP 2][4]. I think this would
significantly help get through the backlog of BIPs PRs, and responding
to them in a timely manner to significantly reduce the friction of
getting BIPs changes merged. Of course, this would require that all BIP
editors agree on the numbering scheme so that BIPs continue to be
numbered consistently.

Considering the responsibilities of these tasks, I think any new BIP
editors should be people who have a history of following and being
involved in Bitcoin development, as well as being known to evaluate
proposals objectively, and of course, are willing to do the job. With
that in mind, I think both Kanzure and RubenSomsen are very good
candidates to be BIP editors, and having both of them working on the
BIPs repo would greatly benefit all of us.

Thanks,
Ava

[1]:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2024-January/022289.html
[2]:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2024-January/022291.html
[3]: https://twitter.com/LukeDashjr/status/1761127972302459000
[4]:
https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#user-content-BIP_Editor_Responsibilities__Workflow

[Léo Haf]

Luke should choose the new editors himself, especially since he has already made a call for applications.

[Antoine Poinsot]

I think this would be helpful, thanks for bringing it up.

I agree Kanzure and RubenSomsen are good candidates for this role.

Antoine

> --
> 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/2092f7ff-4860-47f8-ba1a-c9d97927551e%40achow101.com.

[Greg Tonoski]

I am proposing my candidacy for BIP editor.

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo%3D%40protonmail.com.

[Luke Dashjr]

On 2/27/24 15:11, 'Léo Haf' via Bitcoin Development Mailing List wrote:
> Luke should choose the new editors himself, especially since he has
> already made a call for applications.

Thanks, but this is for the broader development community to decide, not
just any one person.

My tweet got many people volunteering in response, and while I agree
another dev reviewing new BIPs would be helpful, I do think it would be
best to have non-devs contribute by triaging what doesn't require dev
skills.

Of those who actually put their names forward, Jon Atack and Roasbeef
stand out as long-time devs to consider (though I have reservations
about Roasbeef for this role). (Kanzure and Ruben both seem undecided if
they're even available to help at this time.) For non-dev triaging, I
would suggest we consider testing out the idea with perhaps Seccour
and/or Greg Tonoski.

Assigning BIP numbers itself is easy enough. The hard part is evaluating
if the new proposal meets the criteria - which definitely needs dev
skills (mainly for technical soundness). So IMO we should move forward
with more editors ASAP without waiting for a new way to coordinate the
numbering (we can deal with that later/in parallel to solving the
immediate need).

Luke

[Steve Lee]

I am unfamiliar with Seccour and Greg Tonoski. Is there a place to look at their history of bitcoin contributions?

--
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/9288df7b-f2e9-4106-b843-c1ff8f8a62a3%40dashjr.org.

[Ava Chow]

On 02/27/24 05:40 PM, Luke Dashjr wrote:

I do think it would be best to have non-devs contribute by triaging what doesn't require dev

skills.

Can you clarify what the non-dev triagers would be doing?

Assigning BIP numbers itself is easy enough. The hard part is evaluating
if the new proposal meets the criteria - which definitely needs dev
skills (mainly for technical soundness). So IMO we should move forward
with more editors ASAP without waiting for a new way to coordinate the
numbering (we can deal with that later/in parallel to solving the
immediate need).

While I think having BIP editors who can go through the backlog of PRs that modify BIPs would be useful, I think the primary complaint recently has really been on the assigning of numbers and subsequently getting those proposed BIPs merged. AJ's original email began with a discussion of open proposed BIPs that were (presumably) waiting on numbers. So I think adding editors who can assign numbers should be something we do sooner rather than later.

Ava

[bitcoin-dev...@slmail.me]

Why does non-dev triaging require any permissions? For BIP
modifications of existing BIPs, the list of authors is in the header,
so anyone can get this list and ping the corresponding GitHub account.
Once at least one author has approved the changes, the editor(s) can
be notified.

Given that the BIP process is documented, for simple issues arising in
newly proposed BIPs, anyone with good understanding of the process
should be able to help without permission. For example, leaving a
comment that a required section is missing (c.f.
https://github.com/bitcoin/bips/pull/1500#pullrequestreview-1796550166).

So if there is anyone out there with good understanding of the
process, willing to help, they could start right away with non-dev
triage?

Regardless, I agree that there is a need for another BIP editor, given
the backlog for number assignment and backlog on merges of approved
changes to existing BIPs. The proposed candidates seem like a good
fit.

Best, void867

[/dev /fd0]

Hi Ava,

Even though it would be better if the BIPs repository was archived and everyone maintained different repositories for BIPs. However, if it still remains relevant I would not want mailing list moderators to be same as BIP editors. So I disagree with the 2 names suggested.

/dev/fd0

floppy disk guy

[Tim Ruffing]

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.
[...]"

[Antoine Riard]

Hi,

> For non-dev triaging, I 
would suggest we consider testing out the idea with perhaps Seccour

I can vet for Seccour.

Already met IRL, he's organizing bitcoin meetups somewhere in the world.

Best,

Antoine

[Keagan McClelland]

NACK on Tonoski. He's so far shown far too little interest in understanding the history of technical decisions and has been rather extreme in rhetoric. These are not qualities I want in a BIP Editor whose job should be a facilitator rather than an advocate. While I don't expect any BIP Editor to be devoid of their own opinions, I do not trust that he won't use the seat as a means of pushing his own agenda.

Keags

On Tue, Feb 27, 2024 at 2:45 PM Luke Dashjr <lu...@dashjr.org> wrote:

[Michael Folkson]

+1 on Kanzure and RubenSomsen

I would put my name forward if Kanzure, RubenSomsen weren't willing to do it and I was concerned about who it might be. I don't think it should be someone the Bitcoin dev community isn't familiar with and hasn't proven themselves over a long period of time like Kanzure, RubenSomsen have. There is the opportunity for a new BIP editor to cause chaos if they were of the wrong temperament and weren't willing to acknowledge opposing views and perspectives. Both Kanzure and RubenSomsen have proved over a long period of time that although they have their own personal views (like anyone else) they won't censor transcripts of presentations or emails to the bitcoin-dev mailing list that contain opposing views to their own. I'm not sure if any of the other candidates putting themselves forward here tick the same boxes as Kanzure and RubenSomsen. I also don't think BIP editors should be Luke Dashjr's personal fiefdom even though overall I personally think Luke has done an excellent job over many years as BIP editor in sometimes difficult circumstances.

Thanks

Michael

[Jon A]

> Of those who actually put their names forward, Jon Atack and Roasbeef
stand out as long-time devs to consider

Thanks. I am willing to help if doing so can be of service. Have been working on Bitcoin development since five years (March 2019) and interested in bitcoin since 2016.  Prior to that was an open source maintainer of a popular search engine for several years and tech lead for various globocorps software projects. Before that, as a teen I wrote professional games in 6502 assembly. Current status and role as described in https://jonatack.github.io/. Have been on temporary hiatus recently. Am unaligned with any particular group, no particular agenda or strong viewpoint regarding, for instance, future soft-fork activations. I see the BIP editor role as about being of service to bitcoin and reckon would follow BIP 2, e.g. its "BIP Editor Responsibilities & Workflow" section.  Cheers, best to all.

[Bitcoin Error Log]

I'd support Atak, Bishop, or Somsen, fwiw. 

[Chris Stewart]

I agree with Tim's thoughts here.

I think Jon Atack, Reuben Somsen, Kanzure or Roasbeef would all make great candidates.

[Murch]

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

[John C. Vernaleo]

For what it's worth, I strongly support Roasbeef as a candidate.

That said, I would find it helpful if someone could go through the thread
and list all the people who've been proposed so people know who they
should be thinking about.

-------------------------------------------------------
John C. Vernaleo, Ph.D.
www.netpurgatory.com
j...@netpurgatory.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.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/bitcoindev/52a0d792-d99f-4360-ba34-0b12de183fef%40murch.one.
>

[Keagan McClelland]

I support this as a go forward plan.

[Matt Corallo]

Seems reasonable to me.

While there are plenty of competent technical folks who would make fine BIP editors, I'd suggest
Kanzure and Murch as clear candidates over others:

* Kanzure has been around for longer than any other candidate as far as I can tell, and has
certainly seen more proposals for changes to Bitcoin than anyone. This makes him a great candidate
to point new BIP authors to appropriate citations. Similarly, he has a long history of being very
responsive, which I believe is part of the goal in appointing new editors here.
* Murch similarly has lots of experience dealing with lots of various ideas around Bitcoin, but
importantly here also has worked extensively to document appropriate terminology for all things
Bitcoin [1]. This makes him an excellent copy editor of Bitcoin technical proposals, which is
basically the only thing the BIP editors are supposed to do.

While there are a handful of other candidates mentioned in this thread who are technically quite
competent, that isn't really the relevant criteria for BIP editors.

Matt

[1] https://github.com/murchandamus/bips/pull/1/files

[Murch]

I just went through the thread, previously mentioned were:

- Kanzure
- Ruben Somsen
- Greg Tonoski
- Jon Atack
- Roasbeef
- Seccour

And Matt just suggested me for the role. Hope I didn’t overlook anyone.

[/dev /fd0]

I support Jon Atack and Roasbeef from this list.

[Brandon Black]

I agree with Matt's suggestions, and also support Jon Atack as a BIP
editor.

* Jon's work in bitcoin has focused on practical concerns of users of
the bitcoin software, a valuable perspective for the BIP process as
well. He's been a steady contributor to the bitcoin node software for 4
continuous years, this steadiness would be a boon to the BIP process.

Best,

--Brandon

[Matt Corallo]

Nothing against Jon specifically, but I don't see how this is relevant to a BIP editor. BIP editors
are not responsible for opining on the merit of a proposal. Their job is to assign numbers and
occasionally suggest copy edits to ensure the documents are of high quality and readability.

Matt

[Matt Corallo]

Please provide justification rather than simply saying "I like Bob!".

Matt

> --
> 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/4c1462b7-ea1c-4a36-be81-7c3719157fabn%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Antoine Riard]

Hi all,

On the timeframe of the new appointment of new BIP editors, I would suggest to postpone the effective date to the 1st May or after.

There is a CoreDev edition happening in April and it's better to not conflict the appointment of new BIP editors with any of the CoreDev dates by transparency towards the wider community.

This avoids last-minute "Hong-Kong Agreement" decision-making-style and anyone present in the room with the GH administrative rights on the BIP repository making the change in a "fait accompli".

On all the other concerns, I think it's still better to split the administrative rights between 1) editors who can merge and 2) "product-management" style privileges for PR / issues sorting.

I think it's good to let technical relevance of the proposal be appreciated by the wider community, marking them as "rejected" if necessary.

As new BIP editors, I'm supporting the following list:

- Kanzure (great responsiveness in my experience)

- Ruben (very knowledgeable in all part of Bitcoin stack)

- Roasbeef (i think it's good to have someone for all inter-compatibility clients things)

- Murch (top bitcoin stackoverflow contributor)

- Jon Atack (much experience with bitcoin core codebase and great responsiveness too)

As new BIP "decentralized PM", I'm supporting the following list:

- Seccour 

I don't know the Bitcoin technical credentials of Greg Tonoski.

I think a good thing is to have not-only US-based BIP editors for higher timezones coverage and BIP process responsiveness.

Best,

Antoine 

--
You received this message because you are subscribed to a topic in the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoindev/cuMZ77KEQAA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcoindev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZgWRu32FXzqqg69V%40console.

[Antoine Riard]

>  Their job is to assign numbers and 
occasionally suggest copy edits to ensure the documents are of high quality and readability.

How can you efficiently suggest copy edit if you don't know the terminology to suggest from years of technical experience ?

Including when the technical concept is novel and isn't well-defined in the English language.

You received this message because you are subscribed to a topic in the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoindev/cuMZ77KEQAA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcoindev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/6806b22d-043d-4201-841a-95e17cd8d542%40mattcorallo.com.

[Matt Corallo]

Right, so again I'm not sure why this is relevant to the BIPs repo. I love Roasbeef and he's a super
smart cookie, but that's not really a relevant criteria for the BIP editor, I don't thin. Indeed,
the editors need to understand Bitcoin fairly well, but there's tons of candidates who meet that
criteria. Rather, the BIP editor(s) should have demonstrated competence at copy-editing, have a long
track record in Bitcoin, and be reliably available.

Matt

On 3/28/24 4:59 PM, John C. Vernaleo wrote:
> Fair enough, that was a less than useful comment of mine.
>
> Roasbeef's work on alternative clients and lightning make him technically useful plus I've worked
> with him personally and know he is responive and careful enough for the role.
>
> Can't speak directly about anyone else so no comment on the rest of them.

>
> -------------------------------------------------------
> John C. Vernaleo, Ph.D.
> www.netpurgatory.com
> j...@netpurgatory.com
> -------------------------------------------------------
>

>> bitcoindev+...@googlegroups.com.

>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/bitcoindev/6806b22d-043d-4201-841a-95e17cd8d542%40mattcorallo.com.
>>

[John C. Vernaleo]

Fair enough, that was a less than useful comment of mine.

Roasbeef's work on alternative clients and lightning make him technically
useful plus I've worked with him personally and know he is responive and
careful enough for the role.

Can't speak directly about anyone else so no comment on the rest of them.

-------------------------------------------------------
John C. Vernaleo, Ph.D.
www.netpurgatory.com
j...@netpurgatory.com
-------------------------------------------------------

On Thu, 28 Mar 2024, Matt Corallo wrote:

> email to bitcoindev+...@googlegroups.com.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/bitcoindev/6806b22d-043d-4201-841a-95e17cd8d542%40mattcorallo.com.
>

[Michael Folkson]

This is getting messier than I initially thought it would. I was happy to +1 Kanzure and RubenSomsen and Murch would also get my +1 but some of these other names seem a touch peculiar to me.

For example I think Jon Atack would make a great Core maintainer at some point in the future and I'm not sure a BIP editor should also be a Core maintainer given the independence sometimes required between Core and the BIP process. Also given Luke is struggling for time I'm not sure making Roasbeef a BIP editor makes sense given he is the maintainer of LND, maintainer of btcd and CTO of Lightning Labs unless he is winding down some of his other responsibilities. This is obviously not a criticism of either as they more than qualified to be maintainers of Core and LND/btcd.

GIven the unexpected messiness I'll throw my hat into the ring. I was debating whether to initially as I've given a lot of thought to a BIP process update (BIP 3), closely followed Luke work through some of the frictions and tension points in the past and I disagree it is entirely an administrative task although it broadly is.

Thanks

Michael

[/dev /fd0]

Justification:

1. Jon Atack: Good at avoiding controversies and technical documentation.

2. Roasbeef: Since BIPs are not just related to bitcoin core, it's good to have btcd maintainer as a BIP editor.

[Antoine Riard]

> Roasbeef's work on alternative clients and lightning make him technically 
useful

I think one of the aim of the BIP process is to harmonize common mechanisms among Bitcoin clients of different langages breeds or at different layers (wallet / full-node).

Having someone among BIP editors with a proven track record of contributing to other full-node codebase beyond C++ can be valuable in that sense.

Especially for all matters related to compatibility and deployment.

> For example I think Jon Atack would make a great Core maintainer at some point in the future and I'm not sure a BIP editor should also be a Core maintainer given the

> independence sometimes required between Core and the BIP process

In a world where both Core and BIP repository are living under a single Github organization, I don't think in matters that much as the highest privilege account will be able to 

override any BIP merging decision, or even remove on the flight BIP editors rights in case of conflicts or controversies. If you're raising the issue that the BIP repository should be moved to its own GH repository I think it's a valuable point.

Beyond, I still think we should ensure we have a wider crowd of geographically and culturally diverse BIP editors. As if the role is ensuring high-quality and readability of the terminology of the standards, we might have highly-skilled technical BIP champions which are not English native. With the current set of proposed BIP editors, to the best of my knowledge, at least we have few langages spoken by the candidates: Dutch, French, German, Spanish. This can be very helpful to translate concepts devised in language A to technical english.

Best,

Antoine

[Keagan McClelland]

My top preferences for the role are Murch and Roasbeef.

Both have demonstrated a permissive and curious attitude towards experimentation on Bitcoin and for the role of BIP editor, I would want more quality proposals to be admitted *even if I may personally disagree with them*. It is for me to decide whether or not I like a proposal. The editor should not be making that choice for me.

It was also mentioned that having a "non-Core" perspective would be beneficial to the process and I'm inclined to agree.

Keags

--
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/9baa15e4-062d-478f-8c87-8ff19ab79989%40murch.one.

[Peter Todd]

On Thu, Mar 28, 2024 at 09:02:26AM -0400, Murch wrote:
> I just went through the thread, previously mentioned were:
>
> - Kanzure

Kanzure is the obvious choice for me. Sufficiently technical to make good
decisions. But, importantly, independent enough for the role:

user@dev-btc:~/bitcoin$ git log | grep -C 2 kanzure

commit a7af9839d688bee9b0b15add61259140b3c00014
Author: Bryan Bishop <kan...@gmail.com>
Date: Fri Nov 14 09:12:41 2014 -0600

--

commit b881100aabee7c8d71cf616ff61a526d0afa9450
Author: Bryan Bishop <kan...@gmail.com>
Date: Wed Feb 26 10:40:18 2014 -0600

--
https://petertodd.org 'peter'[:-1]@petertodd.org

[Michael Folkson]

> In a world where both Core and BIP repository are living under a single Github organization, I don't think in matters that much as the highest privilege account will be able to
override any BIP merging decision, or even remove on the flight BIP
editors rights in case of conflicts or controversies. If you're
raising the issue that the BIP repository should be moved to its own
GH repository I think it's a valuable point.

In the past there have been disagreements between Core maintainers and
BIP editors (e.g. Luke with Taproot activation params) and those Core
maintainers haven't merged pull requests in the BIPs repo or removed
him as a BIP editor. As long as that continues it isn't necessary to
create a new GitHub organization for the BIPs repo. They are separate
repos with different maintainers/editors but under the same
organization and everyone knows where it is located.

> Beyond, I still think we should ensure we have a wider crowd of geographically and culturally diverse BIP editors. As if the role is ensuring high-quality and readability of the terminology of the standards, we might have highly-skilled technical BIP champions which are not English native. With the current set of proposed BIP editors, to the best of my knowledge, at least we have few langages spoken by the candidates: Dutch, French, German, Spanish. This can be very helpful to translate concepts devised in language A to technical english.

It seems like you want to create some kind of United Nations for the
BIP process. As I said previously this is almost entirely an
administrative task. Going to a committee of 10 people with different
nationalities and languages to decide whether something should get a
BIP number is absurd. If you think Luke is slow to respond wait until
your United Nations of the BIP process has to all agree to assign a
BIP number. Please don't try to make this unnecessarily bureaucratic
and political for no reason. There's enough of that outside of
Bitcoin.

> 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/f8fa1a55-644f-4cf1-b8c1-4fdef22d1869n%40googlegroups.com.



--
Michael Folkson
Personal email: michael...@gmail.com

[Antoine Riard]

Hi Michael,

> In the past there have been disagreements between Core maintainers and
> BIP editors (e.g. Luke with Taproot activation params) and those Core
> maintainers haven't merged pull requests in the BIPs repo or removed
> him as a BIP editor. As long as that continues it isn't necessary to
> create a new GitHub organization for the BIPs repo. They are separate
> repos with different maintainers/editors but under the same
> organization and everyone knows where it is located.

Indeed, avoiding new conflicts like we have seen with Luke with Taproot activation params is a good reason to separate repositories in my opinion.

Beyond, "security through distrusting" [0] is a very legitimate security philosophy including for communication space infrastructure.

[0] https://www.qubes-os.org/news/2017/12/11/joanna-rutkowska-black-hat-europe-2017/

> It seems like you want to create some kind of United Nations for the
> BIP process. As I said previously this is almost entirely an
> administrative task. Going to a committee of 10 people with different
> nationalities and languages to decide whether something should get a
> BIP number is absurd. If you think Luke is slow to respond wait until
> your United Nations of the BIP process has to all agree to assign a
> BIP number. Please don't try to make this unnecessarily bureaucratic
> and political for no reason. There's enough of that outside of
> Bitcoin.

No, I wish to ensure that if the aim of the BIP is ensuring high-quality and readability of standards those ones are well-written, including when the original standard is contributed by someone non-native.

I can only remember numerous times when my english technical texts have been kindly corrected by other contributors. Having editors understanding multiple languages helps in quality redaction.

Beyond, from reading conversations it sounds there is a disagreement if it's an administrative task (i.e "assigning numbers") or editorial one (i.e "high-quality, well-written standards").

If we wish to make things less bureaucratic, we might actually separate the two tasks with different groups of BIP process maintainers :

- assign temporary numbers for experimentation

- wait for more-or-less finalized drafts written in a quality fashion

- assign final numbers for standard candidate deployment

If you see other ways to dissociate the roles and make things less bureaucratic ? E.g having people only in charge of triage.

If I remember correctly the IETF does not assign RFC numbers for draft proposals, and you generally have years of experimentation.

Best,

Antoine

PS: By the way, even at the United Nations, unanimity is not the rule, it's two-third of the general assembly. I think your analogy is not valid.