From: Antoine Riard <antoine.riard@gmail•com>
To: Michael Folkson <michaelfolkson@gmail•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Adding New BIP Editors
Date: Sat, 30 Mar 2024 20:01:28 +0000 [thread overview]
Message-ID: <CALZpt+EU4JzbDepsu4Wz-6e0XB4VuKCqatiRnb1nKXe++jF+Rw@mail.gmail.com> (raw)
In-Reply-To: <CAFvNmHQiXFbjMxHWeWYb4J5TDDpYT0o4CexYdcOjrUAaCt4f6w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 9743 bytes --]
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.
Le sam. 30 mars 2024 à 11:52, Michael Folkson <michaelfolkson@gmail•com> a
écrit :
> > 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.
>
> On Fri, Mar 29, 2024 at 9:14 PM Antoine Riard <antoine.riard@gmail•com>
> wrote:
> >
> > > 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
> >
> >
> > Le vendredi 29 mars 2024 à 12:33:09 UTC, /dev /fd0 a écrit :
> >>
> >> 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.
> >>
> >> On Friday, March 29, 2024 at 1:47:41 AM UTC+5:30 Matt Corallo wrote:
> >>>
> >>> Please provide justification rather than simply saying "I like 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 PM 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’t overlook
> anyone.
> >>> >
> >>> > On 3/27/24 19:39, John C. Vernaleo wrote:
> >>> > > 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.
> >>> >
> >>> > --
> >>> > 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
> >.
> >
> > --
> > 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/f8fa1a55-644f-4cf1-b8c1-4fdef22d1869n%40googlegroups.com
> .
>
>
>
> --
> Michael Folkson
> Personal email: michaelfolkson@gmail•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+unsubscribe@googlegroups•com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/CALZpt%2BEU4JzbDepsu4Wz-6e0XB4VuKCqatiRnb1nKXe%2B%2BjF%2BRw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 12386 bytes --]
next prev parent reply other threads:[~2024-03-30 21:13 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-27 18:53 [bitcoindev] " 'Ava Chow' via Bitcoin Development Mailing List
2024-02-27 20:11 ` [bitcoindev] " 'Léo Haf' via Bitcoin Development Mailing List
2024-02-27 22:40 ` Luke Dashjr
2024-02-27 22:57 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-02-27 23:26 ` Steve Lee
2024-02-28 11:12 ` bitcoin-dev-ml.void867 via Bitcoin Development Mailing List
2024-02-28 16:31 ` Tim Ruffing
2024-03-07 20:56 ` Antoine Riard
2024-03-14 11:56 ` Chris Stewart
2024-03-27 21:25 ` Murch
2024-03-27 23:36 ` Keagan McClelland
2024-03-27 23:39 ` John C. Vernaleo
2024-03-28 13:02 ` Murch
2024-03-28 16:09 ` /dev /fd0
2024-03-28 20:04 ` Matt Corallo
2024-03-28 20:31 ` Antoine Riard
2024-03-28 20:59 ` John C. Vernaleo
2024-03-28 21:19 ` Matt Corallo
2024-03-29 2:34 ` Michael Folkson
2024-03-29 5:24 ` /dev /fd0
2024-03-29 21:08 ` Antoine Riard
2024-03-30 11:51 ` Michael Folkson
2024-03-30 20:01 ` Antoine Riard [this message]
2024-03-31 16:01 ` Michael Folkson
2024-04-01 20:14 ` Antoine Riard
2024-04-07 10:11 ` Ali Sherief
2024-04-01 21:13 ` David A. Harding
2024-04-01 23:55 ` /dev /fd0
2024-04-02 0:37 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-02 13:49 ` /dev /fd0
2024-04-02 14:28 ` Luke Dashjr
2024-04-02 15:13 ` Gloria Zhao
2024-04-02 15:39 ` Luke Dashjr
2024-04-03 15:03 ` Murch
2024-04-02 8:18 ` Michael Folkson
2024-04-02 14:24 ` nvk
2024-04-11 14:22 ` Sergi Delgado Segura
2024-04-15 17:50 ` Matt Corallo
2024-04-16 12:34 ` Tim Ruffing
2024-04-16 13:32 ` NVK
2024-04-16 17:08 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-17 23:58 ` 'nsvrn' via Bitcoin Development Mailing List
2024-04-19 22:32 ` Olaoluwa Osuntokun
2024-04-20 19:14 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-20 19:48 ` NVK
2024-04-20 19:59 ` Michael Folkson
2024-04-20 20:59 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-20 20:46 ` Steve Lee
2024-04-20 21:08 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-20 21:11 ` Steve Lee
2024-04-20 21:37 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-20 22:03 ` Steve Lee
2024-04-20 22:47 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-22 2:44 ` Steve Lee
2024-04-20 22:21 ` Michael Folkson
2024-04-20 23:05 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-21 11:43 ` Michael Folkson
2024-04-21 16:39 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-21 17:57 ` Michael Folkson
2024-04-21 18:47 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-21 19:18 ` Michael Folkson
2024-04-21 20:48 ` Antoine Riard
2024-04-21 23:01 ` Matt Corallo
2024-04-22 0:06 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-22 4:28 ` Ali Sherief
2024-04-23 22:15 ` Anthony Towns
2024-04-25 6:42 ` Antoine Riard
2024-03-29 22:17 ` Keagan McClelland
2024-03-30 4:04 ` Peter Todd
2024-04-01 18:42 ` Jonas Nick
2024-03-27 23:54 ` Matt Corallo
2024-03-28 15:50 ` Brandon Black
2024-03-28 19:42 ` Antoine Riard
2024-03-28 20:04 ` Matt Corallo
2024-04-02 13:17 ` [bitcoindev] Time for an update to BIP2? Tim Ruffing
2024-04-03 19:44 ` Pieter Wuille
2024-04-04 5:00 ` Anthony Towns
2024-04-04 9:09 ` Niklas Goegge
2024-04-04 12:58 ` [bitcoindev] Adding New BIP Editors 0xB10C
2024-05-13 18:33 ` [bitcoindev] Time for an update to BIP2? Murch
2024-04-01 18:41 ` [bitcoindev] Re: Adding New BIP Editors Murch
2024-03-31 17:01 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-01 6:21 ` /dev /fd0
2024-04-01 11:58 ` Michael Folkson
2024-04-03 16:58 ` Juan Galt
2024-04-03 17:24 ` Vasil Dimov
2024-04-03 18:34 ` 'Fabian' via Bitcoin Development Mailing List
2024-03-07 22:39 ` Keagan McClelland
2024-02-27 21:33 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
2024-02-27 21:48 ` Greg Tonoski
2024-02-27 23:10 ` [bitcoindev] " /dev /fd0
2024-02-28 4:22 ` /dev /fd0
2024-03-09 10:46 ` Michael Folkson
2024-03-10 17:27 ` Bitcoin Error Log
2024-03-11 16:48 ` Jon A
2024-04-05 19:18 ` Larry Ruane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALZpt+EU4JzbDepsu4Wz-6e0XB4VuKCqatiRnb1nKXe++jF+Rw@mail.gmail.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=michaelfolkson@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox