Delivery-date: Sun, 07 Apr 2024 03:14:20 -0700 Received: from mail-oo1-f57.google.com ([209.85.161.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rtPXW-0001tX-MJ for bitcoindev@gnusha.org; Sun, 07 Apr 2024 03:14:20 -0700 Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-5a4873596e8sf3872983eaf.1 for ; Sun, 07 Apr 2024 03:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1712484852; x=1713089652; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=jDlOHNM1pSU5ZoaD6MzeHAUhTKF+mMdFjvYBjO4rZpE=; b=EWODDaH7shDaeg7wAWj2tw+eOQz5f0cMIo/DpnhdydOrwzQFOxNGnQV1u3GrqPWqR5 kKTA9X121bgztoFNi2coUT2d7S7Kx6lMF58UULwWxGXlsepJ362wnZHcOxj6mtqLUMAe lHUMB9l8R3aofv9GaTqcM0xqJSl3kJ1iSGMgwPUYkqC1c5Tim9VyEJz8VwUGoWtgOaBn JhPLLE29ilLHppUKSL5QEB0ui89tvi/g5l5//S9JFdRNaborB01wsacxTxGIB/YT+Djh 030/iII3uSMLBaq05MUdt0gtltCGogHurLigISyAnR7WuYxmnXmpsJYeDv1v8fYt5ipA 5/3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712484852; x=1713089652; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=jDlOHNM1pSU5ZoaD6MzeHAUhTKF+mMdFjvYBjO4rZpE=; b=P5p5KTh3WhhTaXw+k/VGY3uNeqIvpEXhADm5RjDccg3h5B6Sk35CT5zkdYNoUFAZPi +g0MOtt60aI91pAmUH/DZ3KRO7g/OGP8Vgx85F1c+dJZwRJ+/0IsgH21NKhr+l5rOttP xA2kIoLaj7Td/ooswbp5eb9n/aDVqIr5p8O250uaArf4lskaGG7aO5m94ITQMzvFGU7G bHGGQJDJxblDcndswiITBblYNUqLnhJKu5/Net6VqsoIJkjsYOzWV7+7Vory6H0Cp78x GWh4I1mgN84DD9zCCagNvVJ+ecXBgcScWEMYeLbWcXsNRXfnf1xThn6UADfLZEGtYml5 IQfQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUdoSM1HkcxFulcuBANhKyB1NIRp1s+JX7x7SdgYgyJpTGLv7nyv8ykmUbT/S/+cgb5N8jgeRGMkhQtCd1Pk4rHAZl3w0w= X-Gm-Message-State: AOJu0Yx/Iwuw0AHMNhf3qgTyCAEpKJMOo1GUXl6r8zLjkY6ZEGbRg97D XUsZtMI+YRXMXknFh/12yQbX5DCjske0ZeN9rUP+BzXcfiGYyder X-Google-Smtp-Source: AGHT+IHLqNi5KWNtFdKaLPdvvBWAuI/zkYiJvbVjWj+erGsbenz0u3HFzd769QCwsHv0W/9SJjyVvg== X-Received: by 2002:a4a:ee86:0:b0:5a9:e6e6:123 with SMTP id dk6-20020a4aee86000000b005a9e6e60123mr6432250oob.9.1712484852326; Sun, 07 Apr 2024 03:14:12 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a4a:5517:0:b0:5aa:328b:95c8 with SMTP id e23-20020a4a5517000000b005aa328b95c8ls152690oob.2.-pod-prod-03-us; Sun, 07 Apr 2024 03:14:11 -0700 (PDT) X-Received: by 2002:a05:6820:609:b0:5a5:636b:cdc5 with SMTP id e9-20020a056820060900b005a5636bcdc5mr320475oow.0.1712484850942; Sun, 07 Apr 2024 03:14:10 -0700 (PDT) Received: by 2002:a05:690c:f86:b0:611:9f18:9d1 with SMTP id 00721157ae682-617c7f8b151ms7b3; Sun, 7 Apr 2024 03:11:43 -0700 (PDT) X-Received: by 2002:a25:a2c8:0:b0:dd9:1dc0:b6c5 with SMTP id c8-20020a25a2c8000000b00dd91dc0b6c5mr1736413ybn.6.1712484702469; Sun, 07 Apr 2024 03:11:42 -0700 (PDT) Date: Sun, 7 Apr 2024 03:11:42 -0700 (PDT) From: Ali Sherief To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com> <9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org> <42e6c1d1d39d811e2fe7c4c5ce6e09c705bd3dbb.camel@timruffing.de> <52a0d792-d99f-4360-ba34-0b12de183fef@murch.one> <84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com> <9baa15e4-062d-478f-8c87-8ff19ab79989@murch.one> <4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com> <6806b22d-043d-4201-841a-95e17cd8d542@mattcorallo.com> <846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com> Subject: Re: [bitcoindev] Re: Adding New BIP Editors MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_26938_1868323235.1712484702081" X-Original-Sender: ali@notatether.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.7 (/) ------=_Part_26938_1868323235.1712484702081 Content-Type: multipart/alternative; boundary="----=_Part_26939_735765204.1712484702081" ------=_Part_26939_735765204.1712484702081 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Just as you don't need to be a maintainer to provide high quality pull request review in the Core repo you don't need to be a BIP editor to provide high quality pull request review in the BIPs repo. There is nothing to stop people who aren't BIP editors continuing to provide review of your work in English and a BIPs repo in English only needs BIP editors who are fluent in English. Just thought I might pop in and make a comment about this. I think it's=20 better to keep the main repository of BIPs in english, and then have a=20 translations subdirectory for each language. Then you can have the BIPs=20 translated on a volunteer basis, either with by pull requests or a platform= =20 like Transifex. But only have the english version as the authoritative=20 reference. Although I am in favor of having additional maintainers in general - it=20 would make it easier to collaboratively review drafts like BIP322. --- Ali On Sunday, March 31, 2024 at 4:24:57=E2=80=AFPM UTC Michael Folkson wrote: > Hi Antoine > > Thanks for the challenge. I think we are going to end up disagreeing > on some things but perhaps the discussion is worth having. > > > Indeed, avoiding new conflicts like we have seen with Luke with Taproot= =20 > 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. > > I repeat having the BIPs repo under a different GitHub organization > would *not* have resulted in a different outcome in the Taproot > activation params or avoided that particular conflict. If Core > maintainers had merged a BIPs PR or kicked Luke off as a BIPs editor > that would have been a different outcome. There are costs to moving > the BIPs repo to a different GitHub organization (existing links, > discoverability, two GitHub organizations to worry about rather than > one) and as long as Core maintainers don't overrule BIP editors in the > BIPs repo there are no clear upsides. > > > No, I wish to ensure that if the aim of the BIP is ensuring high-qualit= y=20 > and readability of standards those ones are well-written, including when= =20 > 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. > > Just as you don't need to be a maintainer to provide high quality pull > request review in the Core repo you don't need to be a BIP editor to > provide high quality pull request review in the BIPs repo. There is > nothing to stop people who aren't BIP editors continuing to provide > review of your work in English and a BIPs repo in English only needs > BIP editors who are fluent in English. > > > Beyond, from reading conversations it sounds there is a disagreement if= =20 > it's an administrative task (i.e "assigning numbers") or editorial one (i= .e=20 > "high-quality, well-written standards"). > > I think we'd agree we are somewhere in between these pure extremes and > I'd argue mostly towards the administrative task end. One of the > reasons I think Kanzure, RubenSomsen and Murch are good BIP editor > candidates is that they can also provide high quality pull request > review before potentially merging but unlike the Core repo where bad > ideas should never be merged a BIP editor will end up merging up pull > requests they think are bad ideas that they would never want merged > into Core. A BIP can get a BIP number and end up being rejected by > Core or the broader community for example. > > > If we wish to make things less bureaucratic, we might actually separate= =20 > 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 > > This seems even more bureaucratic to me. Different numbers to track, > more complexity. There is a BINANA repo [0] for Bitcoin Inquisition > for this kind of early experimentation for proposed consensus changes > that aren't advanced enough to be BIPs. > > > If you see other ways to dissociate the roles and make things less=20 > 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. > > Personally I think it is fine as it is. We are discussing the > potential addition of high quality BIP editors as only having one > currently (Luke) is clearly not ideal. That will alleviate Luke as a > single bottleneck. I do think it is time for an update to the BIP > process (BIP 3) too so BIP editors have some guidance on how to treat > bad ideas (how bad are we talking!) and are comfortable merging pull > requests around attempted (successful or failed) soft fork > activations. Ultimately though just like with Core maintainers there > is going to be some personal judgment required especially during those > cases where there isn't clear community consensus either way. Hence > for those cases I'd be much more comfortable with say Kanzure, > RubenSomsen or Murch than someone we know very little about and hasn't > demonstrated a strong understanding of how Bitcoin works. > > > PS: By the way, even at the United Nations, unanimity is not the rule,= =20 > it's two-third of the general assembly. I think your analogy is not valid= . > > Perhaps we can leave discussion of my imperfect analogies to a > different forum :) Hopefully we can agree that this is a direction of > travel that we shouldn't be pursuing for the BIPs repo. > > [0]: https://github.com/bitcoin-inquisition/binana > > On Sat, Mar 30, 2024 at 8:01=E2=80=AFPM Antoine Riard wrote: > > > > Hi Michael, > > > > > In the past there have been disagreements between Core maintainers an= d > > > 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= =20 > activation params is a good reason to separate repositories in my opinion= . > > Beyond, "security through distrusting" [0] is a very legitimate securit= y=20 > philosophy including for communication space infrastructure. > > > > [0]=20 > https://www.qubes-os.org/news/2017/12/11/joanna-rutkowska-black-hat-europ= e-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-qualit= y=20 > and readability of standards those ones are well-written, including when= =20 > the original standard is contributed by someone non-native. > > I can only remember numerous times when my english technical texts have= =20 > been kindly corrected by other contributors. Having editors understanding= =20 > multiple languages helps in quality redaction. > > > > Beyond, from reading conversations it sounds there is a disagreement if= =20 > it's an administrative task (i.e "assigning numbers") or editorial one (i= .e=20 > "high-quality, well-written standards"). > > > > If we wish to make things less bureaucratic, we might actually separate= =20 > 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=20 > bureaucratic ? E.g having people only in charge of triage. > > If I remember correctly the IETF does not assign RFC numbers for draft= =20 > proposals, and you generally have years of experimentation. > > > > Best, > > Antoine > > > > PS: By the way, even at the United Nations, unanimity is not the rule,= =20 > it's two-third of the general assembly. I think your analogy is not valid= . > > > > Le sam. 30 mars 2024 =C3=A0 11:52, Michael Folkson a=20 > =C3=A9crit : > >> > >> > In a world where both Core and BIP repository are living under a=20 > single Github organization, I don't think in matters that much as the=20 > 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=20 > geographically and culturally diverse BIP editors. As if the role is=20 > ensuring high-quality and readability of the terminology of the standards= ,=20 > we might have highly-skilled technical BIP champions which are not Englis= h=20 > native. With the current set of proposed BIP editors, to the best of my= =20 > knowledge, at least we have few langages spoken by the candidates: Dutch,= =20 > French, German, Spanish. This can be very helpful to translate concepts= =20 > 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. > >> > >> On Fri, Mar 29, 2024 at 9:14=E2=80=AFPM Antoine Riard =20 > wrote: > >> > > >> > > Roasbeef's work on alternative clients and lightning make him=20 > technically > >> > useful > >> > > >> > I think one of the aim of the BIP process is to harmonize common=20 > mechanisms among Bitcoin clients of different langages breeds or at=20 > different layers (wallet / full-node). > >> > Having someone among BIP editors with a proven track record of=20 > contributing to other full-node codebase beyond C++ can be valuable in th= at=20 > sense. > >> > Especially for all matters related to compatibility and deployment. > >> > > >> > > For example I think Jon Atack would make a great Core maintainer a= t=20 > some point in the future and I'm not sure a BIP editor should also be a= =20 > 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=20 > single Github organization, I don't think in matters that much as the=20 > highest privilege account will be able to > >> > override any BIP merging decision, or even remove on the flight BIP= =20 > editors rights in case of conflicts or controversies. If you're raising t= he=20 > issue that the BIP repository should be moved to its own GH repository I= =20 > think it's a valuable point. > >> > > >> > Beyond, I still think we should ensure we have a wider crowd of=20 > geographically and culturally diverse BIP editors. As if the role is=20 > ensuring high-quality and readability of the terminology of the standards= ,=20 > we might have highly-skilled technical BIP champions which are not Englis= h=20 > native. With the current set of proposed BIP editors, to the best of my= =20 > knowledge, at least we have few langages spoken by the candidates: Dutch,= =20 > French, German, Spanish. This can be very helpful to translate concepts= =20 > devised in language A to technical english. > >> > > >> > Best, > >> > Antoine > >> > > >> > > >> > Le vendredi 29 mars 2024 =C3=A0 12:33:09 UTC, /dev /fd0 a =C3=A9crit= : > >> >> > >> >> Justification: > >> >> > >> >> 1. Jon Atack: Good at avoiding controversies and technical=20 > documentation. > >> >> 2. Roasbeef: Since BIPs are not just related to bitcoin core, it's= =20 > good to have btcd maintainer as a BIP editor. > >> >> > >> >> On Friday, March 29, 2024 at 1:47:41=E2=80=AFAM UTC+5:30 Matt Coral= lo wrote: > >> >>> > >> >>> Please provide justification rather than simply saying "I like=20 > Bob!". > >> >>> > >> >>> Matt > >> >>> > >> >>> On 3/28/24 12:09 PM, /dev /fd0 wrote: > >> >>> > I support Jon Atack and Roasbeef from this list. > >> >>> > > >> >>> > On Thursday, March 28, 2024 at 6:57:53=E2=80=AFPM UTC+5:30 Murch= wrote: > >> >>> > > >> >>> > 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=E2=80=99t o= verlook=20 > anyone. > >> >>> > > >> >>> > On 3/27/24 19:39, John C. Vernaleo wrote: > >> >>> > > That said, I would find it helpful if someone could go through= =20 > the > >> >>> > > thread and list all the people who've been proposed so people= =20 > know who > >> >>> > > they should be thinking about. > >> >>> > > >> >>> > -- > >> >>> > You received this message because you are subscribed to the=20 > Google Groups "Bitcoin Development > >> >>> > Mailing List" group. > >> >>> > To unsubscribe from this group and stop receiving emails from it= ,=20 > send an email to > >> >>> > bitcoindev+...@googlegroups.com bitcoindev+...@googlegroups.com>. > >> >>> > To view this discussion on the web visit > >> >>> >=20 > https://groups.google.com/d/msgid/bitcoindev/4c1462b7-ea1c-4a36-be81-7c37= 19157fabn%40googlegroups.com=20 > < > https://groups.google.com/d/msgid/bitcoindev/4c1462b7-ea1c-4a36-be81-7c37= 19157fabn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter > >. > >> > > >> > -- > >> > You received this message because you are subscribed to the Google= =20 > Groups "Bitcoin Development Mailing List" group. > >> > To unsubscribe from this group and stop receiving emails from it,=20 > send an email to bitcoindev+...@googlegroups.com. > >> > To view this discussion on the web visit=20 > https://groups.google.com/d/msgid/bitcoindev/f8fa1a55-644f-4cf1-b8c1-4fde= f22d1869n%40googlegroups.com > . > >> > >> > >> > >> -- > >> Michael Folkson > >> Personal email: michael...@gmail.com > > > > --=20 > Michael Folkson > Personal email: michael...@gmail.com > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/= bitcoindev/bed3a056-d937-4562-b030-1c1a08814cffn%40googlegroups.com. ------=_Part_26939_735765204.1712484702081 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Just as you don't need to be a maintainer to provide high quality pull=
request review in the Core repo you don't need to be a BIP editor to<= br />provide high quality pull request review in the BIPs repo. There isnothing to stop people who aren't BIP editors continuing to provide
review of your work in English and a BIPs repo in English only needs
= BIP editors who are fluent in English.

Just thought I might pop = in and make a comment about this. I think it's better to keep the main repo= sitory of BIPs in english, and then have a translations subdirectory for ea= ch language. Then you can have the BIPs translated on a volunteer basis, ei= ther with by pull requests or a platform like Transifex. But only have the = english version as the authoritative reference.

Although I am in= favor of having additional maintainers in general - it would make it easie= r to collaboratively review drafts like BIP322.
---
Ali

On Sund= ay, March 31, 2024 at 4:24:57=E2=80=AFPM UTC Michael Folkson wrote:
Hi Antoine

Thanks for the challenge. I think we are going to end up disagreeing
on some things but perhaps the discussion is worth having.

> Indeed, avoiding new conflicts like we have seen with Luke with Ta= proot activation params is a good reason to separate repositories in my opi= nion.
Beyond, "security through distrusting" [0] is a very legitima= te
security philosophy including for communication space infrastructure.

I repeat having the BIPs repo under a different GitHub organization
would *not* have resulted in a different outcome in the Taproot
activation params or avoided that particular conflict. If Core
maintainers had merged a BIPs PR or kicked Luke off as a BIPs editor
that would have been a different outcome. There are costs to moving
the BIPs repo to a different GitHub organization (existing links,
discoverability, two GitHub organizations to worry about rather than
one) and as long as Core maintainers don't overrule BIP editors in = the
BIPs repo there are no clear upsides.

> No, I wish to ensure that if the aim of the BIP is ensuring high-q= uality 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.

Just as you don't need to be a maintainer to provide high quality p= ull
request review in the Core repo you don't need to be a BIP editor t= o
provide high quality pull request review in the BIPs repo. There is
nothing to stop people who aren't BIP editors continuing to provide
review of your work in English and a BIPs repo in English only needs
BIP editors who are fluent in English.

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

I think we'd agree we are somewhere in between these pure extremes = and
I'd argue mostly towards the administrative task end. One of the
reasons I think Kanzure, RubenSomsen and Murch are good BIP editor
candidates is that they can also provide high quality pull request
review before potentially merging but unlike the Core repo where bad
ideas should never be merged a BIP editor will end up merging up pull
requests they think are bad ideas that they would never want merged
into Core. A BIP can get a BIP number and end up being rejected by
Core or the broader community for example.

> If we wish to make things less bureaucratic, we might actually sep= arate 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

This seems even more bureaucratic to me. Different numbers to track,
more complexity. There is a BINANA repo [0] for Bitcoin Inquisition
for this kind of early experimentation for proposed consensus changes
that aren't advanced enough to be BIPs.

> 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.

Personally I think it is fine as it is. We are discussing the
potential addition of high quality BIP editors as only having one
currently (Luke) is clearly not ideal. That will alleviate Luke as a
single bottleneck. I do think it is time for an update to the BIP
process (BIP 3) too so BIP editors have some guidance on how to treat
bad ideas (how bad are we talking!) and are comfortable merging pull
requests around attempted (successful or failed) soft fork
activations. Ultimately though just like with Core maintainers there
is going to be some personal judgment required especially during those
cases where there isn't clear community consensus either way. Hence
for those cases I'd be much more comfortable with say Kanzure,
RubenSomsen or Murch than someone we know very little about and hasn= 9;t
demonstrated a strong understanding of how Bitcoin works.

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

Perhaps we can leave discussion of my imperfect analogies to a
different forum :) Hopefully we can agree that this is a direction of
travel that we shouldn't be pursuing for the BIPs repo.

[0]: https://github.com/bitcoin-inquisition/binana

On Sat, Mar 30, 2024 at 8:01=E2=80=AFPM Antoine Riard <antoin...@gmail.com> wrote:
>
> Hi Michael,
>
> > In the past there have been disagreements between Core mainta= iners and
> > BIP editors (e.g. Luke with Taproot activation params) and th= ose 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 n= ecessary 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 Ta= proot activation params is a good reason to separate repositories in my opi= nion.
> Beyond, "security through distrusting" [0] is a very leg= itimate security philosophy including for communication space infrastructur= e.
>
> [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 d= ifferent
> > nationalities and languages to decide whether something shoul= d get a
> > BIP number is absurd. If you think Luke is slow to respond wa= it until
> > your United Nations of the BIP process has to all agree to as= sign a
> > BIP number. Please don't try to make this unnecessarily b= ureaucratic
> > and political for no reason. There's enough of that outsi= de of
> > Bitcoin.
>
> No, I wish to ensure that if the aim of the BIP is ensuring high-q= uality 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 understan= ding multiple languages helps in quality redaction.
>
> Beyond, from reading conversations it sounds there is a disagreeme= nt if it's an administrative task (i.e "assigning numbers") o= r editorial one (i.e "high-quality, well-written standards").
>
> If we wish to make things less bureaucratic, we might actually sep= arate 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 fash= ion
> - 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 d= raft proposals, and you generally have years of experimentation.
>
> Best,
> Antoine
>
> PS: By the way, even at the United Nations, unanimity is not the r= ule, it's two-third of the general assembly. I think your analogy is no= t valid.
>
> Le sam. 30 mars 2024 =C3=A0 11:52, Michael Folkson <michael...@gmail.com> a =C3=A9crit :
>>
>> > 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 fligh= t BIP
>> editors rights in case of conflicts or controversies. If you&#= 39;re
>> raising the issue that the BIP repository should be moved to i= ts own
>> GH repository I think it's a valuable point.
>>
>> In the past there have been disagreements between Core maintai= ners and
>> BIP editors (e.g. Luke with Taproot activation params) and tho= se 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 ne= cessary to
>> create a new GitHub organization for the BIPs repo. They are s= eparate
>> 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 cr= owd 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 kn= owledge, at least we have few langages spoken by the candidates: Dutch, Fre= nch, German, Spanish. This can be very helpful to translate concepts devise= d in language A to technical english.
>>
>> It seems like you want to create some kind of United Nations f= or the
>> BIP process. As I said previously this is almost entirely an
>> administrative task. Going to a committee of 10 people with di= fferent
>> nationalities and languages to decide whether something should= get a
>> BIP number is absurd. If you think Luke is slow to respond wai= t until
>> your United Nations of the BIP process has to all agree to ass= ign a
>> BIP number. Please don't try to make this unnecessarily bu= reaucratic
>> and political for no reason. There's enough of that outsid= e of
>> Bitcoin.
>>
>> On Fri, Mar 29, 2024 at 9:14=E2=80=AFPM Antoine Riard <antoin...@gmail.com> wrote:
>> >
>> > > Roasbeef's work on alternative clients and light= ning 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 reco= rd of contributing to other full-node codebase beyond C++ can be valuable i= n that sense.
>> > Especially for all matters related to compatibility and d= eployment.
>> >
>> > > For example I think Jon Atack would make a great Cor= e 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 cr= owd 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 kn= owledge, at least we have few langages spoken by the candidates: Dutch, Fre= nch, German, Spanish. This can be very helpful to translate concepts devise= d in language A to technical english.
>> >
>> > Best,
>> > Antoine
>> >
>> >
>> > Le vendredi 29 mars 2024 =C3=A0 12:33:09 UTC, /dev /fd0 a= =C3=A9crit :
>> >>
>> >> Justification:
>> >>
>> >> 1. Jon Atack: Good at avoiding controversies and tech= nical documentation.
>> >> 2. Roasbeef: Since BIPs are not just related to bitco= in core, it's good to have btcd maintainer as a BIP editor.
>> >>
>> >> On Friday, March 29, 2024 at 1:47:41=E2=80=AFAM UTC+5= :30 Matt Corallo wrote:
>> >>>
>> >>> Please provide justification rather than simply s= aying "I like Bob!".
>> >>>
>> >>> Matt
>> >>>
>> >>> On 3/28/24 12:09 PM, /dev /fd0 wrote:
>> >>> > I support Jon Atack and Roasbeef from this l= ist.
>> >>> >
>> >>> > On Thursday, March 28, 2024 at 6:57:53=E2=80= =AFPM UTC+5:30 Murch wrote:
>> >>> >
>> >>> > I just went through the thread, previously m= entioned were:
>> >>> >
>> >>> > - Kanzure
>> >>> > - Ruben Somsen
>> >>> > - Greg Tonoski
>> >>> > - Jon Atack
>> >>> > - Roasbeef
>> >>> > - Seccour
>> >>> >
>> >>> > And Matt just suggested me for the role. Hop= e I didn=E2=80=99t overlook anyone.
>> >>> >
>> >>> > On 3/27/24 19:39, John C. Vernaleo wrote:
>> >>> > > That said, I would find it helpful if s= omeone could go through the
>> >>> > > thread and list all the people who'= ve been proposed so people know who
>> >>> > > they should be thinking about.
>> >>> >
>> >>> > --
>> >>> > You received this message because you are su= bscribed to the Google Groups "Bitcoin Development
>> >>> > Mailing List" group.
>> >>> > To unsubscribe from this group and stop rece= iving emails from it, send an email to
>> >>> > b= itcoindev+...@googlegroups.com <mailto:bitcoindev+...@googlegroups.com>.
>> >>> > To view this discussion on the web visit
>> >>> > https://group= s.google.com/d/msgid/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn%40goo= glegroups.com <https://group= s.google.com/d/msgid/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn%40goo= glegroups.com?utm_medium=3Demail&utm_source=3Dfooter>.
>> >
>> > --
>> > You received this message because you are subscribed to t= he Google Groups "Bitcoin Development Mailing List" group.
>> > To unsubscribe from this group and stop receiving emails = from it, send an email to bitcoi= ndev+...@googlegroups.com.
>> > To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/f8fa1a55-644f-4= cf1-b8c1-4fdef22d1869n%40googlegroups.com.
>>
>>
>>
>> --
>> Michael Folkson
>> Personal email: mic= hael...@gmail.com



--=20
Michael Folkson
Personal email: michael...@g= mail.com

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/bed3a056-d937-4562-b030-1c1a08814cffn%40googlegroups.com.=
------=_Part_26939_735765204.1712484702081-- ------=_Part_26938_1868323235.1712484702081--