Adding New BIP Editors

Adding New BIP Editors
2024-02-27 20:11 ` [bitcoindev] " 'Léo Haf' via Bitcoin Development Mailing List
                   ` (5 more replies)
  
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2024-02-27 18:53 UTC (permalink / raw)
  To: bitcoindev

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

-- 



 permalink raw reply	[|nested]
2024-02-27 20:11 `  " 'Léo Haf' via Bitcoin Development Mailing List
                   ` 
  
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2024-02-27 18:53 UTC (permalink / raw)
  To: bitcoindev

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

-- 



 permalink raw reply	[|nested]
* 
  2024-02-27 18:53 [bitcoindev] Adding New BIP Editors 'Ava Chow' via Bitcoin Development Mailing List

  2024-02-27 22:40   ` Luke Dashjr
  2024-02-27 21:33 `  " 'Antoine Poinsot' via Bitcoin Development Mailing List
                   ` 
  5 siblings, 1 reply; 100+ messages in thread
From: 'Léo Haf' via Bitcoin Development Mailing List @ 2024-02-27 20:11 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 2309 bytes --]

Luke should choose the new editors himself, especially since he has already 
made a call for applications.
Le mardi 27 février 2024 à 20:27:57 UTC+1, Ava Chow a écrit :

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

-- 
2: Type: text/html, Size: 4249 bytes --]

^ permalink raw reply	[|nested] 100+ messages in thread
2024-02-27 21:33 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List

  
From: Greg Tonoski @ 2024-02-27 21:48 UTC (permalink / raw)
  To: bitcoindev

[-- Attachment #1: Type: text/plain, Size: 3485 bytes --]

I am proposing my candidacy for BIP editor.

On Tue, 27 Feb 2024, 22:36 'Antoine Poinsot' via Bitcoin Development
Mailing List, <bitcoindev@googlegroups.com> wrote:

> I think this would be helpful, thanks for bringing it up.
>
> I agree Kanzure and RubenSomsen are good candidates for this role.
>
> Antoine
>
> On Tuesday, February 27th, 2024 at 7:53 PM, 'Ava Chow' via Bitcoin
> Development Mailing List <bitcoindev@googlegroups.com> wrote:
>
> > 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
> >
> > --
> > 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/2092f7ff-4860-47f8-ba1a-c9d97927551e%40achow101.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/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo%3D%40protonmail.com
> .
>

-- 


[-- Attachment #2: Type: text/html, Size: 5567 bytes --]

 permalink raw reply	[|nested]
2024-02-27 20:11 ` [bitcoindev] " 'Léo Haf' via Bitcoin Development Mailing List

  2024-02-27 22:57     ` 'Ava Chow' via Bitcoin Development Mailing List
                       ` (4 more replies)
  
From: Luke Dashjr @ 2024-02-27 22:40 UTC (permalink / raw)
  To: bitcoindev

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

-- 



 permalink raw reply	[|nested]
2024-02-27 20:11 ` [bitcoindev] " 'Léo Haf' via Bitcoin Development Mailing List

  2024-02-27 22:57     ` 
                       ` 
  
From: Luke Dashjr @ 2024-02-27 22:40 UTC (permalink / raw)
  To: bitcoindev

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

-- 



 permalink raw reply	[|nested]
* 
  2024-02-27 18:53 [bitcoindev] Adding New BIP Editors 'Ava Chow' via Bitcoin Development Mailing List
  2024-02-27 20:11 ` [bitcoindev] " 'Léo Haf' via Bitcoin Development Mailing List

  2024-02-27 21:48   ` Greg Tonoski
  2024-02-27 23:10 `  " /dev /fd0
                   ` 
  5 siblings, 1 reply; 100+ messages in thread
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2024-02-27 21:33 UTC (permalink / raw)
  To: Ava Chow;  bitcoindev

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

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

Antoine

On Tuesday, February 27th, 2024 at 7:53 PM, 'Ava Chow' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote:

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


^ permalink raw reply	[|nested] 100+ messages in thread
* 
  2024-02-27 22:40   ` Luke Dashjr

  2024-02-27 23:26     ` 
                       ` 
  4 siblings, 0 replies; 100+ messages in thread
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2024-02-27 22:57 UTC (permalink / raw)
  To: bitcoindev

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

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

-- 


[-- Attachment #2: Type: text/html, Size: 2327 bytes --]

^ permalink raw reply	[|nested] 100+ messages in thread
* 
  2024-02-27 18:53 [bitcoindev] Adding New BIP Editors 'Ava Chow' via Bitcoin Development Mailing List
  2024-02-27 20:11 ` [bitcoindev] " 'Léo Haf' via Bitcoin Development Mailing List
  2024-02-27 21:33 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List

  2024-02-28  4:22 ` 
                   ` 
  5 siblings, 0 replies; 100+ messages in thread
From: /dev /fd0 @ 2024-02-27 23:10 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 2525 bytes --]

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 agree with the 2 names suggested.

/dev/fd0
floppy disk guy
On Wednesday, February 28, 2024 at 12:57:57 AM UTC+5:30 Ava Chow wrote:

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

-- 
2: Type: text/html, Size: 4517 bytes --]

^ permalink raw reply	[|nested] 100+ messages in thread
* 
  2024-02-27 22:40   ` Luke Dashjr
  2024-02-27 22:57     ` 'Ava Chow' via Bitcoin Development Mailing List

  2024-02-28 11:12     ` 
                       ` 
  4 siblings, 0 replies; 100+ messages in thread
From: Steve Lee @ 2024-02-27 23:26 UTC (permalink / raw)
  To: Luke Dashjr;  bitcoindev

[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]

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

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

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

-- 


[-- Attachment #2: Type: text/html, Size: 3194 bytes --]

^ permalink raw reply	[|nested] 100+ messages in thread
2024-02-27 22:40   ` Luke Dashjr
                       ` (2 preceding siblings ...)
  2024-02-28 11:12     ` bitcoin-dev-ml.void867 via Bitcoin Development Mailing List

  2024-03-07 20:56       ` Antoine Riard
  2024-03-14 11:56       ` Chris Stewart
  2024-03-07 22:39     ` Keagan McClelland
  
From: Tim Ruffing @ 2024-02-28 16:31 UTC (permalink / raw)
  To: Luke Dashjr, bitcoindev

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

-- 



 permalink raw reply	[|nested]
2024-02-28 16:31     ` Tim Ruffing

  2024-03-14 11:56       ` Chris Stewart
  
From: Antoine Riard @ 2024-03-07 20:56 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 1867 bytes --]

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

Le jeudi 29 février 2024 à 16:55:52 UTC, Tim Ruffing a écrit :

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

-- 
2: Type: text/html, Size: 2533 bytes --]

 permalink raw reply	[|nested]
2024-02-27 22:40   ` Luke Dashjr
                       ` (3 preceding siblings ...)
  2024-02-28 16:31     ` Tim Ruffing

  
From: Keagan McClelland @ 2024-03-07 22:39 UTC (permalink / raw)
  To: Luke Dashjr;  bitcoindev

[-- Attachment #1: Type: text/plain, Size: 2642 bytes --]

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 <luke@dashjr•org> wrote:

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

-- 


[-- Attachment #2: Type: text/html, Size: 3540 bytes --]

 permalink raw reply	[|nested]
2024-02-27 18:53 [bitcoindev] Adding New BIP Editors 'Ava Chow' via Bitcoin Development Mailing List
                   ` (3 preceding siblings ...)
  2024-02-28  4:22 ` /dev /fd0

  2024-03-10 17:27   ` Bitcoin Error Log
  2024-03-11 16:48   ` Jon A
  2024-04-05 19:18 ` Larry Ruane
  
From: Michael Folkson @ 2024-03-09 10:46 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 3341 bytes --]

+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

On Tuesday, February 27, 2024 at 7:27:57 PM UTC Ava Chow wrote:

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

-- 
2: Type: text/html, Size: 5321 bytes --]

 permalink raw reply	[|nested]
2024-03-09 10:46 ` Michael Folkson

  2024-03-11 16:48   ` Jon A
  
From: Bitcoin Error Log @ 2024-03-10 17:27 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 3549 bytes --]

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

On Sunday, March 10, 2024 at 5:12:16 PM UTC Michael Folkson wrote:

> +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
>
> On Tuesday, February 27, 2024 at 7:27:57 PM UTC Ava Chow wrote:
>
>> 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 
>>
>>

-- 
2: Type: text/html, Size: 5682 bytes --]

 permalink raw reply	[|nested]
2024-03-09 10:46 ` Michael Folkson
  2024-03-10 17:27   ` Bitcoin Error Log

  
From: Jon A @ 2024-03-11 16:48 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 1317 bytes --]

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

-- 
2: Type: text/html, Size: 1613 bytes --]

 permalink raw reply	[|nested]
2024-02-28 16:31     ` Tim Ruffing
  2024-03-07 20:56       ` Antoine Riard

  2024-03-27 21:25         ` Murch
  
From: Chris Stewart @ 2024-03-14 11:56 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 1779 bytes --]

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

-- 
2: Type: text/html, Size: 2379 bytes --]

 permalink raw reply	[|nested]
2024-03-14 11:56       ` Chris Stewart

  2024-03-27 23:36           ` Keagan McClelland
                             ` (3 more replies)
  
From: Murch @ 2024-03-27 21:25 UTC (permalink / raw)
  To: bitcoindev

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

-- 



 permalink raw reply	[|nested]
2024-03-14 11:56       ` Chris Stewart

  2024-03-27 23:36           ` 
                             ` 
  
From: Murch @ 2024-03-27 21:25 UTC (permalink / raw)
  To: bitcoindev

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

-- 



 permalink raw reply	[|nested]
* 
  2024-03-27 21:25         ` Murch

  2024-03-27 23:39           ` 
                             ` 
  3 siblings, 0 replies; 100+ messages in thread
From: Keagan McClelland @ 2024-03-27 23:36 UTC (permalink / raw)
  To: Murch;  bitcoindev

[-- Attachment #1: Type: text/plain, Size: 4215 bytes --]

I support this as a go forward plan.

On Wed, Mar 27, 2024 at 2:56 PM Murch <murch@murch•one> 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+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
> .
>

-- 


[-- Attachment #2: Type: text/html, Size: 5353 bytes --]

^ permalink raw reply	[|nested] 100+ messages in thread
2024-03-27 21:25         ` Murch
  2024-03-27 23:36           ` Keagan McClelland
  2024-03-27 23:39           ` John C. Vernaleo

  2024-03-28 15:50             ` Brandon Black
  2024-04-01 18:41             ` [bitcoindev] Re: Adding New BIP Editors Murch
  2024-03-31 17:01           ` 'Ava Chow' via Bitcoin Development Mailing List
  
From: Matt Corallo @ 2024-03-27 23:54 UTC (permalink / raw)
  To: Murch, bitcoindev

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

On 3/27/24 5: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.
>>> [...]"
> 

-- 



 permalink raw reply	[|nested]
2024-03-27 23:39           ` John C. Vernaleo

  2024-03-28 16:09               ` /dev /fd0
                                 ` (3 more replies)
  
From: Murch @ 2024-03-28 13:02 UTC (permalink / raw)
  To: jcv;  bitcoindev

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.

-- 



 permalink raw reply	[|nested]
2024-03-27 23:54           ` Matt Corallo

  2024-03-28 19:42               ` Antoine Riard
  2024-03-28 20:04               ` Matt Corallo
  2024-04-01 18:41             ` [bitcoindev] Re: Adding New BIP Editors Murch
  
From: Brandon Black @ 2024-03-28 15:50 UTC (permalink / raw)
  To: Matt Corallo;  Murch, bitcoindev

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

On 2024-03-27 (Wed) at 19:54:53 -0400, Matt Corallo wrote:
> 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

-- 



 permalink raw reply	[|nested]
2024-03-27 23:39           ` John C. Vernaleo

  2024-03-28 16:09               ` 
                                 ` 
  
From: Murch @ 2024-03-28 13:02 UTC (permalink / raw)
  To: jcv;  bitcoindev

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.

-- 



 permalink raw reply	[|nested]
2024-03-28 15:50             ` Brandon Black

  2024-03-28 20:04               ` Matt Corallo
  
From: Antoine Riard @ 2024-03-28 19:42 UTC (permalink / raw)
  To: Brandon Black;  Matt Corallo, Murch, bitcoindev

[-- Attachment #1: Type: text/plain, Size: 4290 bytes --]

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


Le jeu. 28 mars 2024 à 16:16, Brandon Black <freedom@reardencode•com> a
écrit :

> 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
>
> On 2024-03-27 (Wed) at 19:54:53 -0400, Matt Corallo wrote:
> > 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
>
> --
> 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+unsubscribe@googlegroups•com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/bitcoindev/ZgWRu32FXzqqg69V%40console.
>

-- 


[-- Attachment #2: Type: text/html, Size: 5812 bytes --]

 permalink raw reply	[|nested]
2024-03-28 16:09               ` /dev /fd0

  2024-03-28 20:31                   ` Antoine Riard
                                     ` (3 more replies)
  
From: Matt Corallo @ 2024-03-28 20:04 UTC (permalink / raw)
  To: /dev /fd0, Bitcoin Development Mailing List

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


 permalink raw reply	[|nested]
2024-03-28 15:50             ` Brandon Black
  2024-03-28 19:42               ` Antoine Riard

  2024-04-02 13:17                 ` [bitcoindev] Time for an update to BIP2? Tim Ruffing
  
From: Matt Corallo @ 2024-03-28 20:04 UTC (permalink / raw)
  To: Brandon Black;  Murch, bitcoindev

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

On 3/28/24 11:50 AM, Brandon Black wrote:
> 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
> 
> On 2024-03-27 (Wed) at 19:54:53 -0400, Matt Corallo wrote:
>> 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

-- 



 permalink raw reply	[|nested]
2024-03-28 16:09               ` /dev /fd0

  2024-03-28 20:31                   ` 
                                     ` 
  
From: Matt Corallo @ 2024-03-28 20:04 UTC (permalink / raw)
  To: /dev /fd0, Bitcoin Development Mailing List

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


 permalink raw reply	[|nested]
* 
  2024-03-28 20:04                 ` Matt Corallo

  2024-03-28 20:59                   ` 
                                     ` 
  3 siblings, 0 replies; 100+ messages in thread
From: Antoine Riard @ 2024-03-28 20:31 UTC (permalink / raw)
  To: Matt Corallo;  /dev /fd0, Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 2839 bytes --]

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

Le jeu. 28 mars 2024 à 20:17, Matt Corallo <lf-lists@mattcorallo•com> a
écrit :

> 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+unsubscribe@googlegroups•com <mailto:
> bitcoindev+unsubscribe@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 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+unsubscribe@googlegroups•com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/bitcoindev/6806b22d-043d-4201-841a-95e17cd8d542%40mattcorallo.com
> .
>

-- 


[-- Attachment #2: Type: text/html, Size: 4634 bytes --]

^ permalink raw reply	[|nested] 100+ messages in thread
2024-03-28 20:59                   ` John C. Vernaleo

  2024-03-29  2:34                     ` Michael Folkson
  
From: Matt Corallo @ 2024-03-28 21:19 UTC (permalink / raw)
  To: jcv;  /dev /fd0, Bitcoin Development Mailing List

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
> jcv@netpurgatory•com
> -------------------------------------------------------
> 
> On Thu, 28 Mar 2024, 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.
>>>
>>> -- 
>>> 


 permalink raw reply	[|nested]
2024-03-28 20:59                   ` John C. Vernaleo
  2024-03-28 21:19                     ` Matt Corallo

  
From: Michael Folkson @ 2024-03-29  2:34 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 4084 bytes --]

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

On Friday, March 29, 2024 at 1:14:29 AM UTC 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
> -------------------------------------------------------
>
> On Thu, 28 Mar 2024, 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+...@googlegroups•com.
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/bitcoindev/6806b22d-043d-4201-841a-95e17cd8d542%40mattcorallo.com
> .
> >

-- 
2: Type: text/html, Size: 6716 bytes --]

 permalink raw reply	[|nested]
2024-03-28 20:04                 ` Matt Corallo
  2024-03-28 20:31                   ` Antoine Riard
  2024-03-28 20:59                   ` John C. Vernaleo

  2024-03-29 21:08                     ` Antoine Riard
  2024-04-01 21:13                   ` David A. Harding
  
From: /dev /fd0 @ 2024-03-29  5:24 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 2080 bytes --]

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

-- 
2: Type: text/html, Size: 3757 bytes --]

 permalink raw reply	[|nested]
2024-03-29  5:24                   ` /dev /fd0

  2024-03-30 11:51                       ` Michael Folkson
  
From: Antoine Riard @ 2024-03-29 21:08 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 3973 bytes --]

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

-- 
2: Type: text/html, Size: 6656 bytes --]

 permalink raw reply	[|nested]
* 
  2024-03-28 13:02             ` Murch

  2024-03-28 20:04                 ` Matt Corallo
  2024-03-29 22:17               ` 
                                 ` 
  3 siblings, 1 reply; 100+ messages in thread
From: /dev /fd0 @ 2024-03-28 16:09 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 991 bytes --]

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

-- 
2: Type: text/html, Size: 1513 bytes --]

^ permalink raw reply	[|nested] 100+ messages in thread
2024-03-28 13:02             ` Murch
  2024-03-28 16:09               ` /dev /fd0
  2024-03-29 22:17               ` Keagan McClelland

  2024-04-01 18:42               ` Jonas Nick
  
From: Peter Todd @ 2024-03-30  4:04 UTC (permalink / raw)
  To: Murch;  jcv, bitcoindev

[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]

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 <kanzure@gmail•com>
	Date:   Fri Nov 14 09:12:41 2014 -0600

	--

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

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

-- 
asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2024-03-29 21:08                     ` Antoine Riard

  2024-03-30 20:01                         ` Antoine Riard
  
From: Michael Folkson @ 2024-03-30 11:51 UTC (permalink / raw)
  To: Antoine Riard;  Bitcoin Development Mailing List

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


 permalink raw reply	[|nested]
2024-03-30 11:51                       ` Michael Folkson

  2024-03-31 16:01                           ` Michael Folkson
  
From: Antoine Riard @ 2024-03-30 20:01 UTC (permalink / raw)
  To: Michael Folkson;  Bitcoin Development Mailing List

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

-- 


[-- Attachment #2: Type: text/html, Size: 12386 bytes --]

 permalink raw reply	[|nested]
2024-03-30 20:01                         ` Antoine Riard

  2024-04-01 20:14                             ` Antoine Riard
  2024-04-07 10:11                             ` Ali Sherief
  
From: Michael Folkson @ 2024-03-31 16:01 UTC (permalink / raw)
  To: Antoine Riard;  Bitcoin Development Mailing List

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

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 it's an administrative task (i.e "assigning numbers") or 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 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

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't
demonstrated a strong understanding of how Bitcoin works.

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

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 PM Antoine Riard <antoine.riard@gmail•com> wrote:
>
> 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.
>> >>> >
>> >>> > --
>> >>> > 


 permalink raw reply	[|nested]
2024-03-27 21:25         ` Murch
                             ` (2 preceding siblings ...)
  2024-03-27 23:54           ` Matt Corallo

  2024-04-01  6:21             ` /dev /fd0
                               ` (2 more replies)
  
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2024-03-31 17:01 UTC (permalink / raw)
  To: bitcoindev

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


 permalink raw reply	[|nested]
2024-03-27 21:25         ` Murch
                             ` (2 preceding siblings ...)
  2024-03-27 23:54           ` Matt Corallo

  2024-04-01  6:21             ` 
                               ` 
  
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2024-03-31 17:01 UTC (permalink / raw)
  To: bitcoindev

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


 permalink raw reply	[|nested]
2024-03-31 17:01           ` 'Ava Chow' via Bitcoin Development Mailing List
  2024-04-01  6:21             ` /dev /fd0

  2024-04-03 16:58             ` Juan Galt
  
From: Michael Folkson @ 2024-04-01 11:58 UTC (permalink / raw)
  To: Ava Chow;  bitcoindev

> f there is no guidance provided by Luke to the new BIP editors when their permissions are granted

I know this isn't how Core maintainers like to operate but perhaps
this guidance to BIPs editors could be public and transparent. There
isn't any need for BIP editors to go the Core maintainer route of
onboarding new maintainers and discussing merge decisions that impact
Core users and the broader community privately and in the shadows. To
the extent that there is disagreement or personal judgment required
that's fine. Say so in public.

On Sun, Mar 31, 2024 at 7:31 PM 'Ava Chow' via Bitcoin Development
Mailing List <bitcoindev@googlegroups.com> 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.
> >>> [...]"
> >
> > --
> > 


 permalink raw reply	[|nested]
2024-03-27 23:54           ` Matt Corallo
  2024-03-28 15:50             ` Brandon Black

  
From: Murch @ 2024-04-01 18:41 UTC (permalink / raw)
  To: bitcoindev

On 3/27/24 19:54, Matt Corallo wrote:
> 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
Thanks Matt. After mulling it over for a bit, I have decided to accept 
the nomination and announce my candidacy for the BIP Editor role under 
the assumptions that 1) all editors will share the same privileges, and 
2) there will be at least three active editors at the end of this process.

My first choice for BIP Editor additions would be Kanzure for his 
encyclopedic knowledge of development discussions and his track record 
of reliably performing a similarly janitorial role for many years.
My second choice would be Ruben who has a similar track record and who I 
imagine might be the person who has perused the BIPs repository most in 
the recent years among the proposed candidates. I consider them both 
levelheaded, open-minded enough to assess proposals beyond their own 
predilections, but also capable of applying uniformly the standards set 
out in the BIP process. I’d be happy to collaborate with them to chip 
away at those 137 open pull requests, if the community expresses support 
for that outcome.

Cheers,
Murch

-- 



 permalink raw reply	[|nested]
2024-03-28 13:02             ` Murch
                                 ` (2 preceding siblings ...)
  2024-03-30  4:04               ` Peter Todd

  
From: Jonas Nick @ 2024-04-01 18:42 UTC (permalink / raw)
  To: bitcoindev

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

It also seems important that candidates confirm their availability for the role
and associated responsibilities. To the best of my knowledge, based on the list
of candidates you posted, only Jon Atack and Greg Tonoski have done so in this
thread so far.

-- 



 permalink raw reply	[|nested]
2024-03-31 16:01                           ` Michael Folkson

  2024-04-07 10:11                             ` Ali Sherief
  
From: Antoine Riard @ 2024-04-01 20:14 UTC (permalink / raw)
  To: Michael Folkson;  Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 20420 bytes --]

Hi Michael,

Thanks for the thoughtful answer.

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

Fair point, though I think it's more a one-time migration cost for
long-term returns.
I still believe we shall apply the principle of least privilege when we can.
This blog article is a good one to meditate:
https://laanwj.github.io/2016/05/06/hostility-scams-and-moving-forward.html

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

That's a fair point too, terminology / high-quality review can be provided
by non-editors.
The worthiness of having non-English editors it's up if we see this as an
administrative task or editorial one in my opinion.

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

On the experience of the inheritance rule in bip125, I would say it's not
so bad if there is a minimum of editorial checks.
At least when the proposal starts to be "proposed" / "final". You don't
need at first how standards are aging with time.
It's not specific to BIP, we have this issue with the BOLTs which have been
amended many times to make things more robust.

I don't know if the BIP process should be more proactive "deprecating" /
"obsolating" / "cleaning-up" standards like done by the IETF.
(It's clearly another set of tasks far beyond the focus of this
discussion...).

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

That "fast-track" numbers assignment experiment might work with time. Let'
see.

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

On the contrary, the BIP process should clearly bound BIP editors personal
judgement, especially at a time of lack of clear community consensus.
If there is one lesson of consensus activation or policy changes over the
last few years, it's better to "wait-and-proactively-build-more-consensus"
rather than "force-through".
Even if the "force-through" is coming from appointed editors or whatever,
practice and respect of the process matters over titles and roles in my
opinion.

For sure, anyone who has already championed a change in Bitcoin has fallen
short of impatience, myself included (e.g with mempoolfullrbf).
Yet, it's good to remember that a bit of technical conservatism,
over-reviewing and feedback collection is always welcome on the delicate
changes.

All that said, I said my opinion on the list of BIP candidates already and
I have nothing more to say.
I won't express myself further on this subject, too much code to write and
review.

Best,
Antoine



Le dim. 31 mars 2024 à 17:01, Michael Folkson <michaelfolkson@gmail•com> a
écrit :

> 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
> 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-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.
>
> 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
> it's an administrative task (i.e "assigning numbers") or 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 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
>
> 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't
> demonstrated a strong understanding of how Bitcoin works.
>
> > 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.
>
> 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 PM Antoine Riard <antoine.riard@gmail•com>
> wrote:
> >
> > 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
>
>
>
> --
> Michael Folkson
> Personal email: michaelfolkson@gmail•com
>

-- 


[-- Attachment #2: Type: text/html, Size: 25097 bytes --]

 permalink raw reply	[|nested]
2024-03-28 20:04                 ` Matt Corallo
                                     ` (2 preceding siblings ...)
  2024-03-29  5:24                   ` /dev /fd0

  2024-04-01 23:55                     ` /dev /fd0
                                       ` (2 more replies)
  
From: David A. Harding @ 2024-04-01 21:13 UTC (permalink / raw)
  To: Matt Corallo;  Bitcoin Development Mailing List

On 2024-03-28 10:04, Matt Corallo wrote:
> Please provide justification rather than simply saying "I like Bob!".

Using only comments from the mailing list, the following appears to be
the candidate list along with the current support.  Asterisks denote
candidates who indicated their willingness to accept the role.

- Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris Stewart[3],
   Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon 
Black[11],
   Antoine Riard[12], Murch[13], Antoine Poinsot[15], John Carvalho[16]

- Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3], Michael
   Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
   Carvalho[16]

- Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3], 
/dev/fd0[5][7],
   Brandon Black[11], Antoine Riard[12], Ava Chow[14], John Carvalho[16]

- Olaoluwa "Roasbeef" Osuntokun, recommended by Chris Stewart[3], John
   C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine
   Riard[12], Ava Chow[14]

- Mark "Murch" Erhardt*, recommended by Michael Folkson[6], Keagan
   McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine Riard[12],
   Ava Chow[14]

- Michael Folkson*

Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for "non-dev
triaging", Tonoski proposed himself[18] for "BIP editor", and Antoine
Riard[12] proposed Seccour for "decentralized PM".

I searched the BIPs repo by commenter to see if any of the above
candidates had been especially active there, which is listed below as:
total PRs they commented on (number still open/number closed).

- 21 (1/20) commenter:kanzure
- 3 (2/1) commenter:rubensomsen
- 15 (0/15) commenter:jonatack
- 18 (2/16) commenter:roasbeef
- 10 (6/4) commenter:Murchandamus
- 57 (6/51) commenter:michaelfolkson

I'll also note that Osuntokun is the only member of the set to have a
merged BIP that they co-authored, although I believe there are far-along
draft BIPs for both Murch (terminology) and Somsen (Silent Payments).  I
don't think this should be a requirement, but I do think it demonstrates
familiarity with the process.

Speaking only for myself, I think all of the candidates above with
multiple recommendations from other community participants are fully
qualified for the role, so I'll only provide a detailed justification
for the person who would be my first pick: Murch is not only a
longstanding and broadly liked Bitcoin contributor, but (as Corallo
mentioned) he has worked on standardizing terminology through a draft
BIP.  In addition, he provided an extremely detailed review of all 300
pages of a draft of Mastering Bitcoin (3rd edition) and has reviewed
drafts of over 200 weekly Optech newsletters, in both cases
significantly improving the accuracy and comprehensibility of the
documentation.  To me, that seems very similar to the work we'd ask him
to perform as a BIPs editor and it's something that he's already doing,
so I think there's an excellent fit of person to role.

-Dave

[1] 
https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/
[2] 
https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/
[3] 
https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/
[4] 
https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/
[5] 
https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/
[6] 
https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/
[7] 
https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/
[8] 
https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/
[9] https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
[10] 
https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/
[11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
[12] 
https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/
[13] 
https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
[14] 
https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/
[15] 
https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
[16] 
https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/
[17] 
https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/

-- 



 permalink raw reply	[|nested]
2024-03-28 20:04                 ` Matt Corallo
                                     ` (2 preceding siblings ...)
  2024-03-29  5:24                   ` /dev /fd0

  2024-04-01 23:55                     ` 
                                       ` 
  
From: David A. Harding @ 2024-04-01 21:13 UTC (permalink / raw)
  To: Matt Corallo;  Bitcoin Development Mailing List

On 2024-03-28 10:04, Matt Corallo wrote:
> Please provide justification rather than simply saying "I like Bob!".

Using only comments from the mailing list, the following appears to be
the candidate list along with the current support.  Asterisks denote
candidates who indicated their willingness to accept the role.

- Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris Stewart[3],
   Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon 
Black[11],
   Antoine Riard[12], Murch[13], Antoine Poinsot[15], John Carvalho[16]

- Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3], Michael
   Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
   Carvalho[16]

- Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3], 
/dev/fd0[5][7],
   Brandon Black[11], Antoine Riard[12], Ava Chow[14], John Carvalho[16]

- Olaoluwa "Roasbeef" Osuntokun, recommended by Chris Stewart[3], John
   C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine
   Riard[12], Ava Chow[14]

- Mark "Murch" Erhardt*, recommended by Michael Folkson[6], Keagan
   McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine Riard[12],
   Ava Chow[14]

- Michael Folkson*

Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for "non-dev
triaging", Tonoski proposed himself[18] for "BIP editor", and Antoine
Riard[12] proposed Seccour for "decentralized PM".

I searched the BIPs repo by commenter to see if any of the above
candidates had been especially active there, which is listed below as:
total PRs they commented on (number still open/number closed).

- 21 (1/20) commenter:kanzure
- 3 (2/1) commenter:rubensomsen
- 15 (0/15) commenter:jonatack
- 18 (2/16) commenter:roasbeef
- 10 (6/4) commenter:Murchandamus
- 57 (6/51) commenter:michaelfolkson

I'll also note that Osuntokun is the only member of the set to have a
merged BIP that they co-authored, although I believe there are far-along
draft BIPs for both Murch (terminology) and Somsen (Silent Payments).  I
don't think this should be a requirement, but I do think it demonstrates
familiarity with the process.

Speaking only for myself, I think all of the candidates above with
multiple recommendations from other community participants are fully
qualified for the role, so I'll only provide a detailed justification
for the person who would be my first pick: Murch is not only a
longstanding and broadly liked Bitcoin contributor, but (as Corallo
mentioned) he has worked on standardizing terminology through a draft
BIP.  In addition, he provided an extremely detailed review of all 300
pages of a draft of Mastering Bitcoin (3rd edition) and has reviewed
drafts of over 200 weekly Optech newsletters, in both cases
significantly improving the accuracy and comprehensibility of the
documentation.  To me, that seems very similar to the work we'd ask him
to perform as a BIPs editor and it's something that he's already doing,
so I think there's an excellent fit of person to role.

-Dave

[1] 
https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/
[2] 
https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/
[3] 
https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/
[4] 
https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/
[5] 
https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/
[6] 
https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/
[7] 
https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/
[8] 
https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/
[9] https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
[10] 
https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/
[11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
[12] 
https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/
[13] 
https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
[14] 
https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/
[15] 
https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
[16] 
https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/
[17] 
https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/

-- 



 permalink raw reply	[|nested]
2024-04-01 23:55                     ` /dev /fd0

  2024-04-02 13:49                         ` /dev /fd0
  
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2024-04-02  0:37 UTC (permalink / raw)
  To: bitcoindev



On 04/01/2024 07:55 PM, /dev /fd0 wrote:
> I think before we decide new BIP editors its important to discuss some 
> things about the process itself:
> 
> 1. Quoting first paragraph from BIPs repo README: "People wishing to 
> submit BIPs, first should propose their idea or document to the 
> bitcoin-dev@lists•linuxfoundation.org mailing list (do not assign a 
> number - read BIP 2 for the full process). After discussion, please open 
> a PR. After copy-editing and acceptance, it will be published here."
> 
> If Kanzure and Ruben are BIP editors, does it mean they can censor 
> someone from submitting BIPs? This question makes sense because they 
> will have control over the whole improvement process for "bitcoin" by 
> being moderators for mailing list and BIP editors.

If the only requirement is that a BIP shows up on the mailing list 
first, then they can already censor them. Having them as BIP editors 
wouldn't change that. It's not clear to me that this requirement is 
strictly enforced anyways.

Furthermore, they would not have the permissions to delete PRs or 
issues, so once a PR is opened, even if closed, would still be there. 
The status quo w.r.t that would not be any different. At worst, they 
could refuse to assign a BIP a number, but that's no different than what 
already happens today. In fact, the situation would likely be better 
because there would be multiple BIP editors and so what goes into the 
repo is not at the whim of a single person.

> 2. How are numbers going to be assigned to BIPs?

Does it matter? The number that a proposal gets has no impact on 
literally anything else. They could do it sequentially and it wouldn't 
actually make a difference as long as there are no collisions.

> 3. Will there be copy of BIPs and pull requests maintained elsewhere 
> like bitcoin core?

I'm not sure why this is relevant to this discussion, but presumably 
there already are, and if there aren't, you can do it yourself. It's 
just like any other repo on GitHub.

> 4. What are the expectations from new BIP editors? In what situation do 
> we look for next BIP editors or in other words, what will be the process 
> to remove an editor if lot of people are unhappy with their work?

The expectations are as outlined to BIP 2, and that they are actually 
active. The situation for looking for new BIP editors in the future is 
presumably similar to the one we are in currently - people who write 
BIPs are frustrated with things taking a long time to be merged with the 
root cause being slow response times from the current editor. The 
process would likely be very similar: names are proposed, there is 
discussion about those people, and eventually some are added.

As for removal, this has not been something we've ever done before, so 
the process for this is undefined. However, it would presumably be a 
similar procedure as for adding someone. It begins with someone raising 
a complaint about one of the editors on this mailing list or some other 
place a discussion, and a community discussion commences about whether 
or not to remove them.

There are certainly situations where one of the GitHub org owners may 
take emergency action and remove a maintainer's privileges. This is only 
done when there is a clear danger than the account may do something 
malicious, and the privileges would be returned if there is clarity that 
it is safe to do so. For example, this was done when Luke was hacked - 
all of his permissions were immediately removed as soon as the news came 
out, and were only returned several months later once verified 
communication with Luke were established and he was certain that his 
GitHub account was no longer (at risk of being) compromised.

Ava

> 
> /dev/fd0
> floppy disk guy
> 
> On Monday, April 1, 2024 at 9:16:54 PM UTC David A. Harding wrote:
> 
>     On 2024-03-28 10:04, Matt Corallo wrote:
>      > Please provide justification rather than simply saying "I like
>     Bob!".
> 
>     Using only comments from the mailing list, the following appears to be
>     the candidate list along with the current support. Asterisks denote
>     candidates who indicated their willingness to accept the role.
> 
>     - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris Stewart[3],
>     Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon
>     Black[11],
>     Antoine Riard[12], Murch[13], Antoine Poinsot[15], John Carvalho[16]
> 
>     - Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3], Michael
>     Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>     Carvalho[16]
> 
>     - Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3],
>     /dev/fd0[5][7],
>     Brandon Black[11], Antoine Riard[12], Ava Chow[14], John Carvalho[16]
> 
>     - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris Stewart[3], John
>     C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine
>     Riard[12], Ava Chow[14]
> 
>     - Mark "Murch" Erhardt*, recommended by Michael Folkson[6], Keagan
>     McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine Riard[12],
>     Ava Chow[14]
> 
>     - Michael Folkson*
> 
>     Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for "non-dev
>     triaging", Tonoski proposed himself[18] for "BIP editor", and Antoine
>     Riard[12] proposed Seccour for "decentralized PM".
> 
>     I searched the BIPs repo by commenter to see if any of the above
>     candidates had been especially active there, which is listed below as:
>     total PRs they commented on (number still open/number closed).
> 
>     - 21 (1/20) commenter:kanzure
>     - 3 (2/1) commenter:rubensomsen
>     - 15 (0/15) commenter:jonatack
>     - 18 (2/16) commenter:roasbeef
>     - 10 (6/4) commenter:Murchandamus
>     - 57 (6/51) commenter:michaelfolkson
> 
>     I'll also note that Osuntokun is the only member of the set to have a
>     merged BIP that they co-authored, although I believe there are
>     far-along
>     draft BIPs for both Murch (terminology) and Somsen (Silent Payments). I
>     don't think this should be a requirement, but I do think it
>     demonstrates
>     familiarity with the process.
> 
>     Speaking only for myself, I think all of the candidates above with
>     multiple recommendations from other community participants are fully
>     qualified for the role, so I'll only provide a detailed justification
>     for the person who would be my first pick: Murch is not only a
>     longstanding and broadly liked Bitcoin contributor, but (as Corallo
>     mentioned) he has worked on standardizing terminology through a draft
>     BIP. In addition, he provided an extremely detailed review of all 300
>     pages of a draft of Mastering Bitcoin (3rd edition) and has reviewed
>     drafts of over 200 weekly Optech newsletters, in both cases
>     significantly improving the accuracy and comprehensibility of the
>     documentation. To me, that seems very similar to the work we'd ask him
>     to perform as a BIPs editor and it's something that he's already doing,
>     so I think there's an excellent fit of person to role.
> 
>     -Dave
> 
>     [1]
>     https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
>     <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>
>     [2]
>     https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
>     <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>
>     [3]
>     https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>
>     [4]
>     https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>
>     [5]
>     https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>
>     [6]
>     https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>
>     [7]
>     https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>
>     [8]
>     https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>
>     [9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>     <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
>     [10]
>     https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>
>     [11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>     [12]
>     https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>
>     [13]
>     https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
>     <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>
>     [14]
>     https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
>     <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>
>     [15]
>     https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>
>     [16]
>     https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>
>     [17]
>     https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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 
> <mailto:bitcoindev+unsubscribe@googlegroups•com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/bitcoindev/cbb0b74f-c60b-4c8a-9e97-9b1c0e0eb047n%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/cbb0b74f-c60b-4c8a-9e97-9b1c0e0eb047n%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 



 permalink raw reply	[|nested]
2024-04-01 21:13                   ` David A. Harding
  2024-04-01 23:55                     ` /dev /fd0

  2024-04-02 14:24                     ` nvk
  
From: Michael Folkson @ 2024-04-02  8:18 UTC (permalink / raw)
  To: David A. Harding;  Matt Corallo, Bitcoin Development Mailing List

> - 21 (1/20) commenter:kanzure
- 3 (2/1) commenter:rubensomsen
- 15 (0/15) commenter:jonatack
- 18 (2/16) commenter:roasbeef
- 10 (6/4) commenter:Murchandamus
- 57 (6/51) commenter:michaelfolkson
>
> I'll also note that Osuntokun is the only member of the set to have a
merged BIP that they co-authored, although I believe there are far-along
draft BIPs for both Murch (terminology) and Somsen (Silent Payments).  I
don't think this should be a requirement, but I do think it demonstrates
familiarity with the process.

Thanks for this analysis Dave. A minor correction, I've also
co-authored a merged BIP (BIP 343) though it was a rather short BIP
and Taproot activation related.

On Mon, Apr 1, 2024 at 10:16 PM David A. Harding <dave@dtrt•org> wrote:
>
> On 2024-03-28 10:04, Matt Corallo wrote:
> > Please provide justification rather than simply saying "I like Bob!".
>
> Using only comments from the mailing list, the following appears to be
> the candidate list along with the current support.  Asterisks denote
> candidates who indicated their willingness to accept the role.
>
> - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris Stewart[3],
>    Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon
> Black[11],
>    Antoine Riard[12], Murch[13], Antoine Poinsot[15], John Carvalho[16]
>
> - Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3], Michael
>    Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>    Carvalho[16]
>
> - Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3],
> /dev/fd0[5][7],
>    Brandon Black[11], Antoine Riard[12], Ava Chow[14], John Carvalho[16]
>
> - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris Stewart[3], John
>    C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine
>    Riard[12], Ava Chow[14]
>
> - Mark "Murch" Erhardt*, recommended by Michael Folkson[6], Keagan
>    McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine Riard[12],
>    Ava Chow[14]
>
> - Michael Folkson*
>
> Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for "non-dev
> triaging", Tonoski proposed himself[18] for "BIP editor", and Antoine
> Riard[12] proposed Seccour for "decentralized PM".
>
> I searched the BIPs repo by commenter to see if any of the above
> candidates had been especially active there, which is listed below as:
> total PRs they commented on (number still open/number closed).
>
> - 21 (1/20) commenter:kanzure
> - 3 (2/1) commenter:rubensomsen
> - 15 (0/15) commenter:jonatack
> - 18 (2/16) commenter:roasbeef
> - 10 (6/4) commenter:Murchandamus
> - 57 (6/51) commenter:michaelfolkson
>
> I'll also note that Osuntokun is the only member of the set to have a
> merged BIP that they co-authored, although I believe there are far-along
> draft BIPs for both Murch (terminology) and Somsen (Silent Payments).  I
> don't think this should be a requirement, but I do think it demonstrates
> familiarity with the process.
>
> Speaking only for myself, I think all of the candidates above with
> multiple recommendations from other community participants are fully
> qualified for the role, so I'll only provide a detailed justification
> for the person who would be my first pick: Murch is not only a
> longstanding and broadly liked Bitcoin contributor, but (as Corallo
> mentioned) he has worked on standardizing terminology through a draft
> BIP.  In addition, he provided an extremely detailed review of all 300
> pages of a draft of Mastering Bitcoin (3rd edition) and has reviewed
> drafts of over 200 weekly Optech newsletters, in both cases
> significantly improving the accuracy and comprehensibility of the
> documentation.  To me, that seems very similar to the work we'd ask him
> to perform as a BIPs editor and it's something that he's already doing,
> so I think there's an excellent fit of person to role.
>
> -Dave
>
> [1]
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/
> [2]
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/
> [3]
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/
> [4]
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/
> [5]
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/
> [6]
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/
> [7]
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/
> [8]
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/
> [9] https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
> [10]
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/
> [11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> [12]
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/
> [13]
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> [14]
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/
> [15]
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> [16]
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/
> [17]
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/
>
> --
> 


 permalink raw reply	[|nested]
2024-03-28 20:04               ` Matt Corallo

  2024-04-03 19:44                   ` Pieter Wuille
  
From: Tim Ruffing @ 2024-04-02 13:17 UTC (permalink / raw)
  To: Matt Corallo, Brandon Black;  Murch, bitcoindev

(Changing the subject line as this is mostly orthogonal to adding BIP
editors.)

On Thu, 2024-03-28 at 16:04 -0400, Matt Corallo wrote:
> 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.

As I said my previous email, this is what I'd prefer, but the current
BIP2, Section "BIP workflow" says this:

"The BIP editors will not unreasonably reject a BIP. Reasons for
rejecting BIPs include duplication of effort, disregard for formatting
rules, being too unfocused or too broad, being technically unsound, not
providing proper motivation or addressing backwards compatibility, or
not in keeping with the Bitcoin philosophy. For a BIP to be accepted it
must meet certain minimum criteria. It must be a clear and complete
description of the proposed enhancement. The enhancement must represent
a net improvement. The proposed implementation, if applicable, must be
solid and must not complicate the protocol unduly."

This is a lot of criteria for a simple editorial rule, hm? How could
any editor judge if an enhancement represents a net improvement without
opining on its merit? What's the Bitcoin philosophy? 


By the way, Section "BIP Editor Responsibilities & Workflow" says this:

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

Note how this is is (seemingly?) in conflict with the paragraph cited
further above. What is "acceptance"? Acceptance by the editor, by the
community (whoever that is), or by anyone else?

BIP2 has other problems (a lot of which date back to BIP1):
 * It recommends licensing BIPs under BSD-2 or BSD-3, which are
   software licenses. It's not even clear if they're applicable to
   plain text. (The CC0 recommendation makes much more sense.)
 * The Comments-URI thing is outdated and everyone seems to ignore it.
   Comments-Summary is even weirder.
 * "Informational BIPs do not necessarily represent a Bitcoin community
   consensus or recommendation". Aha, does this imply that Standards
   Track BIPs need to represent a Bitcoin community consensus or
   recommendation?
 * Ever tried to write pseudocode or LaTeX in mediawiki format? It's
   more than annoying, believe me.

Moreover, the entire "BIP status field" section is an attempt at
formalizing and describing the process of changing Bitcoin. That leads
to statements like these that specify when a BIP should be "Final" 

 * "A soft-fork BIP strictly requires a clear miner majority expressed
   by blockchain voting (eg, using BIP 9)." That statement is highly
   controversial. The point is that it simply doesn't belong in BIP2.
 * "API/RPC and application layer BIPs must be implemented by at least
   two independent and compatible software applications." same here
 * Peer services BIPs should be observed to be adopted by at least 1%
   of public listening nodes for one month.  

The problems are similar to the Comments-Summary field whose purpose is
to represent a community judgment of the BIP. It can have these values:
 * No comments yet.
 * Unanimously Recommended for implementation
 * Unanimously Discourage for implementation
 * Mostly Recommended for implementation, with some Discouragement
 * Mostly Discouraged for implementation, with some Recommendation

There's a reason why noone really uses this. Like the Status field, it
requires that someone (the editor? BIP2 doesn't specify this) makes a
judgement that looks somewhat authoritative, because it will end up in
the BIP header/metadata. 

I think we should simply drop anything that requires an examination of
the meat of the BIP, e.g., the Status and Comments-* fields, and the
requirement to check the meat of a BIP. Instead, we should work on a
new process BIP that merely describes a simple process of publishing
BIPs, in which the editors focus on purely formal and editorial issues
(e.g., formatting, license, readability, filtering spam, ...). It's
great when they guide BIP authors by providing feedback on the
presentation of an idea, or even on the idea itself, but they shouldn't
be required to make decisions based on the technical or philosophical
merit of a BIP.

I ask everyone to read BIP2 carefully before replying here:
https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki

Best,
Tim

-- 



 permalink raw reply	[|nested]
2024-04-02  0:37                       ` 'Ava Chow' via Bitcoin Development Mailing List

  2024-04-02 14:28                           ` Luke Dashjr
  
From: /dev /fd0 @ 2024-04-02 13:49 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 13946 bytes --]

>  Does it matter? The number that a proposal gets has no impact on
> literally anything else. They could do it sequentially and it wouldn't
> actually make a difference as long as there are no collisions.

Process followed to assign the number started this whole debate recently 
and creation of BINANA. Previous BIP editor refused to assign numbers to 
some BIPs. Kanzure had [tweeted][0] asking users on twitter if a BIP should 
be assigned number. So I am curious what process exactly would be followed 
by new BIP editors.

> For example, this was done when Luke was hacked -
> all of his permissions were immediately removed as soon as the news came
> out, and were only returned several months later once verified
> communication with Luke were established and he was certain that his
> GitHub account was no longer (at risk of being) compromised.

Thanks for sharing. I wasn't aware of this.

[0]: https://x.com/kanzure/status/1752663903715168280

/dev/fd0
floppy disk guy

On Tuesday, April 2, 2024 at 8:22:16 AM UTC Ava Chow wrote:

>
>
> On 04/01/2024 07:55 PM, /dev /fd0 wrote:
> > I think before we decide new BIP editors its important to discuss some 
> > things about the process itself:
> > 
> > 1. Quoting first paragraph from BIPs repo README: "People wishing to 
> > submit BIPs, first should propose their idea or document to the 
> > bitco...@lists•linuxfoundation.org mailing list (do not assign a 
> > number - read BIP 2 for the full process). After discussion, please open 
> > a PR. After copy-editing and acceptance, it will be published here."
> > 
> > If Kanzure and Ruben are BIP editors, does it mean they can censor 
> > someone from submitting BIPs? This question makes sense because they 
> > will have control over the whole improvement process for "bitcoin" by 
> > being moderators for mailing list and BIP editors.
>
> If the only requirement is that a BIP shows up on the mailing list 
> first, then they can already censor them. Having them as BIP editors 
> wouldn't change that. It's not clear to me that this requirement is 
> strictly enforced anyways.
>
> Furthermore, they would not have the permissions to delete PRs or 
> issues, so once a PR is opened, even if closed, would still be there. 
> The status quo w.r.t that would not be any different. At worst, they 
> could refuse to assign a BIP a number, but that's no different than what 
> already happens today. In fact, the situation would likely be better 
> because there would be multiple BIP editors and so what goes into the 
> repo is not at the whim of a single person.
>
> > 2. How are numbers going to be assigned to BIPs?
>
> Does it matter? The number that a proposal gets has no impact on 
> literally anything else. They could do it sequentially and it wouldn't 
> actually make a difference as long as there are no collisions.
>
> > 3. Will there be copy of BIPs and pull requests maintained elsewhere 
> > like bitcoin core?
>
> I'm not sure why this is relevant to this discussion, but presumably 
> there already are, and if there aren't, you can do it yourself. It's 
> just like any other repo on GitHub.
>
> > 4. What are the expectations from new BIP editors? In what situation do 
> > we look for next BIP editors or in other words, what will be the process 
> > to remove an editor if lot of people are unhappy with their work?
>
> The expectations are as outlined to BIP 2, and that they are actually 
> active. The situation for looking for new BIP editors in the future is 
> presumably similar to the one we are in currently - people who write 
> BIPs are frustrated with things taking a long time to be merged with the 
> root cause being slow response times from the current editor. The 
> process would likely be very similar: names are proposed, there is 
> discussion about those people, and eventually some are added.
>
> As for removal, this has not been something we've ever done before, so 
> the process for this is undefined. However, it would presumably be a 
> similar procedure as for adding someone. It begins with someone raising 
> a complaint about one of the editors on this mailing list or some other 
> place a discussion, and a community discussion commences about whether 
> or not to remove them.
>
> There are certainly situations where one of the GitHub org owners may 
> take emergency action and remove a maintainer's privileges. This is only 
> done when there is a clear danger than the account may do something 
> malicious, and the privileges would be returned if there is clarity that 
> it is safe to do so. For example, this was done when Luke was hacked - 
> all of his permissions were immediately removed as soon as the news came 
> out, and were only returned several months later once verified 
> communication with Luke were established and he was certain that his 
> GitHub account was no longer (at risk of being) compromised.
>
> Ava
>
> > 
> > /dev/fd0
> > floppy disk guy
> > 
> > On Monday, April 1, 2024 at 9:16:54 PM UTC David A. Harding wrote:
> > 
> > On 2024-03-28 10:04, Matt Corallo wrote:
> > > Please provide justification rather than simply saying "I like
> > Bob!".
> > 
> > Using only comments from the mailing list, the following appears to be
> > the candidate list along with the current support. Asterisks denote
> > candidates who indicated their willingness to accept the role.
> > 
> > - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris Stewart[3],
> > Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon
> > Black[11],
> > Antoine Riard[12], Murch[13], Antoine Poinsot[15], John Carvalho[16]
> > 
> > - Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3], Michael
> > Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
> > Carvalho[16]
> > 
> > - Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3],
> > /dev/fd0[5][7],
> > Brandon Black[11], Antoine Riard[12], Ava Chow[14], John Carvalho[16]
> > 
> > - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris Stewart[3], John
> > C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine
> > Riard[12], Ava Chow[14]
> > 
> > - Mark "Murch" Erhardt*, recommended by Michael Folkson[6], Keagan
> > McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine Riard[12],
> > Ava Chow[14]
> > 
> > - Michael Folkson*
> > 
> > Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for "non-dev
> > triaging", Tonoski proposed himself[18] for "BIP editor", and Antoine
> > Riard[12] proposed Seccour for "decentralized PM".
> > 
> > I searched the BIPs repo by commenter to see if any of the above
> > candidates had been especially active there, which is listed below as:
> > total PRs they commented on (number still open/number closed).
> > 
> > - 21 (1/20) commenter:kanzure
> > - 3 (2/1) commenter:rubensomsen
> > - 15 (0/15) commenter:jonatack
> > - 18 (2/16) commenter:roasbeef
> > - 10 (6/4) commenter:Murchandamus
> > - 57 (6/51) commenter:michaelfolkson
> > 
> > I'll also note that Osuntokun is the only member of the set to have a
> > merged BIP that they co-authored, although I believe there are
> > far-along
> > draft BIPs for both Murch (terminology) and Somsen (Silent Payments). I
> > don't think this should be a requirement, but I do think it
> > demonstrates
> > familiarity with the process.
> > 
> > Speaking only for myself, I think all of the candidates above with
> > multiple recommendations from other community participants are fully
> > qualified for the role, so I'll only provide a detailed justification
> > for the person who would be my first pick: Murch is not only a
> > longstanding and broadly liked Bitcoin contributor, but (as Corallo
> > mentioned) he has worked on standardizing terminology through a draft
> > BIP. In addition, he provided an extremely detailed review of all 300
> > pages of a draft of Mastering Bitcoin (3rd edition) and has reviewed
> > drafts of over 200 weekly Optech newsletters, in both cases
> > significantly improving the accuracy and comprehensibility of the
> > documentation. To me, that seems very similar to the work we'd ask him
> > to perform as a BIPs editor and it's something that he's already doing,
> > so I think there's an excellent fit of person to role.
> > 
> > -Dave
> > 
> > [1]
> > https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
> > <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ 
> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>
> >
> > [2]
> > https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
> > <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ 
> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>
> >
> > [3]
> > https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ 
> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ 
> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>
> >
> > [4]
> > https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ 
> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ 
> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>
> >
> > [5]
> > https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ 
> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ 
> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>
> >
> > [6]
> > https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ 
> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ 
> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>
> >
> > [7]
> > https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ 
> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ 
> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>
> >
> > [8]
> > 
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ 
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ 
> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>
> >
> > [9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> > <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/ 
> <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>>
> > [10]
> > https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ 
> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ 
> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>
> >
> > [11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> > <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
> > [12]
> > 
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ 
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ 
> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>
> >
> > [13]
> > https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
> > <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/ 
> <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>
> >
> > [14]
> > https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
> > <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ 
> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>
> >
> > [15]
> > 
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ 
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> >
> > [16]
> > https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ 
> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ 
> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>
> >
> > [17]
> > 
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ 
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ 
> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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+...@googlegroups•com 
> > <mailto:bitcoindev+...@googlegroups•com>.
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/bitcoindev/cbb0b74f-c60b-4c8a-9e97-9b1c0e0eb047n%40googlegroups.com 
> <
> https://groups.google.com/d/msgid/bitcoindev/cbb0b74f-c60b-4c8a-9e97-9b1c0e0eb047n%40googlegroups.com?utm_medium=email&utm_source=footer
> >.
>
>

-- 
2: Type: text/html, Size: 27598 bytes --]

 permalink raw reply	[|nested]
2024-04-01 21:13                   ` David A. Harding
  2024-04-01 23:55                     ` /dev /fd0
  2024-04-02  8:18                     ` Michael Folkson

  2024-04-11 14:22                       ` Sergi Delgado Segura
  
From: nvk @ 2024-04-02 14:24 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 7431 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

+1 for
Kanzure
RubenSomsen
Seccour
Jon Atack
Roasbeef

I would prefer having more (9+?) than less folks on this task, so personal 
preferences are easily ignored and overwritten by the group majority.

BIPs were intended as a means to collect ideas, not enforce ideas.

I'd like to return to that.

- - NVK (temp gmail account)
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmKAukUZni40sZANzHN2toLREzdoFAmYMFPwACgkQHN2toLRE
zdqjqQgAsCLjBbVF505RJvIo2ZZqjWDjc0kn3pCs2+d9BHJNbd104CHUlb/TlbGL
+P1yTDTP9IJoDH833SaLlohtVFBUQbWZmBSav/rSi/4ricXg8XXXDoYb+wPgcdSo
243qh43kjMzL6gU6f4aslCS1fHVL/LDUHiRdarLekKfPsWWEE1BR+qdk+WUJiEkU
09pcZsGG+6osVDP3/oTCkkMH9/vzY+l8zwy8I3rtMByjlhk90t37YUi1dn5vrvhF
cSFkys+Um15Wnngb8W1yi4i/gfFYvHapn7KA1WaoeivbMtiJVL8XVWQiWf3Uzy+s
w3Tl+sQ3S69fIajI9StfO60Qe5dSJQ==
=w5DC
-----END PGP SIGNATURE-----

On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A. Harding wrote:

> On 2024-03-28 10:04, Matt Corallo wrote:
> > Please provide justification rather than simply saying "I like Bob!".
>
> Using only comments from the mailing list, the following appears to be
> the candidate list along with the current support. Asterisks denote
> candidates who indicated their willingness to accept the role.
>
> - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris Stewart[3],
> Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon 
> Black[11],
> Antoine Riard[12], Murch[13], Antoine Poinsot[15], John Carvalho[16]
>
> - Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3], Michael
> Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
> Carvalho[16]
>
> - Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3], 
> /dev/fd0[5][7],
> Brandon Black[11], Antoine Riard[12], Ava Chow[14], John Carvalho[16]
>
> - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris Stewart[3], John
> C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine
> Riard[12], Ava Chow[14]
>
> - Mark "Murch" Erhardt*, recommended by Michael Folkson[6], Keagan
> McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine Riard[12],
> Ava Chow[14]
>
> - Michael Folkson*
>
> Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for "non-dev
> triaging", Tonoski proposed himself[18] for "BIP editor", and Antoine
> Riard[12] proposed Seccour for "decentralized PM".
>
> I searched the BIPs repo by commenter to see if any of the above
> candidates had been especially active there, which is listed below as:
> total PRs they commented on (number still open/number closed).
>
> - 21 (1/20) commenter:kanzure
> - 3 (2/1) commenter:rubensomsen
> - 15 (0/15) commenter:jonatack
> - 18 (2/16) commenter:roasbeef
> - 10 (6/4) commenter:Murchandamus
> - 57 (6/51) commenter:michaelfolkson
>
> I'll also note that Osuntokun is the only member of the set to have a
> merged BIP that they co-authored, although I believe there are far-along
> draft BIPs for both Murch (terminology) and Somsen (Silent Payments). I
> don't think this should be a requirement, but I do think it demonstrates
> familiarity with the process.
>
> Speaking only for myself, I think all of the candidates above with
> multiple recommendations from other community participants are fully
> qualified for the role, so I'll only provide a detailed justification
> for the person who would be my first pick: Murch is not only a
> longstanding and broadly liked Bitcoin contributor, but (as Corallo
> mentioned) he has worked on standardizing terminology through a draft
> BIP. In addition, he provided an extremely detailed review of all 300
> pages of a draft of Mastering Bitcoin (3rd edition) and has reviewed
> drafts of over 200 weekly Optech newsletters, in both cases
> significantly improving the accuracy and comprehensibility of the
> documentation. To me, that seems very similar to the work we'd ask him
> to perform as a BIPs editor and it's something that he's already doing,
> so I think there's an excellent fit of person to role.
>
> -Dave
>
> [1] 
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ 
> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>
> [2] 
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ 
> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>
> [3] 
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ 
> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>
> [4] 
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ 
> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>
> [5] 
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ 
> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>
> [6] 
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ 
> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>
> [7] 
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ 
> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>
> [8] 
>
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ 
> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>
> [9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/ 
> <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
> [10] 
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ 
> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>
> [11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> [12] 
>
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ 
> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>
> [13] 
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/ 
> <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>
> [14] 
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ 
> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>
> [15] 
>
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> [16] 
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ 
> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>
> [17] 
>
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ 
> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/>
>

-- 
2: Type: text/html, Size: 13194 bytes --]

 permalink raw reply	[|nested]
2024-04-02 13:49                         ` /dev /fd0

  2024-04-02 15:13                             ` Gloria Zhao
  
From: Luke Dashjr @ 2024-04-02 14:28 UTC (permalink / raw)
  To: bitcoindev, /dev /fd0, Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 15441 bytes --]

No, there was no such refusal. The ONLY issue at hand with regard to more BIP editors is that I don't have time to keep up with it by myself. If your goal is anything else, please sit this discussion out (aside from perhaps reasonable objections to new editors). BIP number assignments are trivial and not a concern.

It seems there's an attempt to take advantage of the need for more BIP editors to change or bypass the BIP process without proper procedures followed. While there may be arguments for improving the BIP process, that is unrelated and would need to go through a BIP, not simply fiat of a new editor. Any potential new editor will need to follow the BIP process as it currently is defined until such a new BIP is accepted.

Luke

On April 2, 2024 7:49:22 AM CST, /dev /fd0 <alicexbtong@gmail•com> wrote:
>>  Does it matter? The number that a proposal gets has no impact on
>> literally anything else. They could do it sequentially and it wouldn't
>> actually make a difference as long as there are no collisions.
>
>Process followed to assign the number started this whole debate recently 
>and creation of BINANA. Previous BIP editor refused to assign numbers to 
>some BIPs. Kanzure had [tweeted][0] asking users on twitter if a BIP should 
>be assigned number. So I am curious what process exactly would be followed 
>by new BIP editors.
>
>> For example, this was done when Luke was hacked -
>> all of his permissions were immediately removed as soon as the news came
>> out, and were only returned several months later once verified
>> communication with Luke were established and he was certain that his
>> GitHub account was no longer (at risk of being) compromised.
>
>Thanks for sharing. I wasn't aware of this.
>
>[0]: https://x.com/kanzure/status/1752663903715168280
>
>/dev/fd0
>floppy disk guy
>
>On Tuesday, April 2, 2024 at 8:22:16 AM UTC Ava Chow wrote:
>
>>
>>
>> On 04/01/2024 07:55 PM, /dev /fd0 wrote:
>> > I think before we decide new BIP editors its important to discuss some 
>> > things about the process itself:
>> > 
>> > 1. Quoting first paragraph from BIPs repo README: "People wishing to 
>> > submit BIPs, first should propose their idea or document to the 
>> > bitco...@lists•linuxfoundation.org mailing list (do not assign a 
>> > number - read BIP 2 for the full process). After discussion, please open 
>> > a PR. After copy-editing and acceptance, it will be published here."
>> > 
>> > If Kanzure and Ruben are BIP editors, does it mean they can censor 
>> > someone from submitting BIPs? This question makes sense because they 
>> > will have control over the whole improvement process for "bitcoin" by 
>> > being moderators for mailing list and BIP editors.
>>
>> If the only requirement is that a BIP shows up on the mailing list 
>> first, then they can already censor them. Having them as BIP editors 
>> wouldn't change that. It's not clear to me that this requirement is 
>> strictly enforced anyways.
>>
>> Furthermore, they would not have the permissions to delete PRs or 
>> issues, so once a PR is opened, even if closed, would still be there. 
>> The status quo w.r.t that would not be any different. At worst, they 
>> could refuse to assign a BIP a number, but that's no different than what 
>> already happens today. In fact, the situation would likely be better 
>> because there would be multiple BIP editors and so what goes into the 
>> repo is not at the whim of a single person.
>>
>> > 2. How are numbers going to be assigned to BIPs?
>>
>> Does it matter? The number that a proposal gets has no impact on 
>> literally anything else. They could do it sequentially and it wouldn't 
>> actually make a difference as long as there are no collisions.
>>
>> > 3. Will there be copy of BIPs and pull requests maintained elsewhere 
>> > like bitcoin core?
>>
>> I'm not sure why this is relevant to this discussion, but presumably 
>> there already are, and if there aren't, you can do it yourself. It's 
>> just like any other repo on GitHub.
>>
>> > 4. What are the expectations from new BIP editors? In what situation do 
>> > we look for next BIP editors or in other words, what will be the process 
>> > to remove an editor if lot of people are unhappy with their work?
>>
>> The expectations are as outlined to BIP 2, and that they are actually 
>> active. The situation for looking for new BIP editors in the future is 
>> presumably similar to the one we are in currently - people who write 
>> BIPs are frustrated with things taking a long time to be merged with the 
>> root cause being slow response times from the current editor. The 
>> process would likely be very similar: names are proposed, there is 
>> discussion about those people, and eventually some are added.
>>
>> As for removal, this has not been something we've ever done before, so 
>> the process for this is undefined. However, it would presumably be a 
>> similar procedure as for adding someone. It begins with someone raising 
>> a complaint about one of the editors on this mailing list or some other 
>> place a discussion, and a community discussion commences about whether 
>> or not to remove them.
>>
>> There are certainly situations where one of the GitHub org owners may 
>> take emergency action and remove a maintainer's privileges. This is only 
>> done when there is a clear danger than the account may do something 
>> malicious, and the privileges would be returned if there is clarity that 
>> it is safe to do so. For example, this was done when Luke was hacked - 
>> all of his permissions were immediately removed as soon as the news came 
>> out, and were only returned several months later once verified 
>> communication with Luke were established and he was certain that his 
>> GitHub account was no longer (at risk of being) compromised.
>>
>> Ava
>>
>> > 
>> > /dev/fd0
>> > floppy disk guy
>> > 
>> > On Monday, April 1, 2024 at 9:16:54 PM UTC David A. Harding wrote:
>> > 
>> > On 2024-03-28 10:04, Matt Corallo wrote:
>> > > Please provide justification rather than simply saying "I like
>> > Bob!".
>> > 
>> > Using only comments from the mailing list, the following appears to be
>> > the candidate list along with the current support. Asterisks denote
>> > candidates who indicated their willingness to accept the role.
>> > 
>> > - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris Stewart[3],
>> > Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon
>> > Black[11],
>> > Antoine Riard[12], Murch[13], Antoine Poinsot[15], John Carvalho[16]
>> > 
>> > - Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3], Michael
>> > Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>> > Carvalho[16]
>> > 
>> > - Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3],
>> > /dev/fd0[5][7],
>> > Brandon Black[11], Antoine Riard[12], Ava Chow[14], John Carvalho[16]
>> > 
>> > - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris Stewart[3], John
>> > C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine
>> > Riard[12], Ava Chow[14]
>> > 
>> > - Mark "Murch" Erhardt*, recommended by Michael Folkson[6], Keagan
>> > McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine Riard[12],
>> > Ava Chow[14]
>> > 
>> > - Michael Folkson*
>> > 
>> > Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for "non-dev
>> > triaging", Tonoski proposed himself[18] for "BIP editor", and Antoine
>> > Riard[12] proposed Seccour for "decentralized PM".
>> > 
>> > I searched the BIPs repo by commenter to see if any of the above
>> > candidates had been especially active there, which is listed below as:
>> > total PRs they commented on (number still open/number closed).
>> > 
>> > - 21 (1/20) commenter:kanzure
>> > - 3 (2/1) commenter:rubensomsen
>> > - 15 (0/15) commenter:jonatack
>> > - 18 (2/16) commenter:roasbeef
>> > - 10 (6/4) commenter:Murchandamus
>> > - 57 (6/51) commenter:michaelfolkson
>> > 
>> > I'll also note that Osuntokun is the only member of the set to have a
>> > merged BIP that they co-authored, although I believe there are
>> > far-along
>> > draft BIPs for both Murch (terminology) and Somsen (Silent Payments). I
>> > don't think this should be a requirement, but I do think it
>> > demonstrates
>> > familiarity with the process.
>> > 
>> > Speaking only for myself, I think all of the candidates above with
>> > multiple recommendations from other community participants are fully
>> > qualified for the role, so I'll only provide a detailed justification
>> > for the person who would be my first pick: Murch is not only a
>> > longstanding and broadly liked Bitcoin contributor, but (as Corallo
>> > mentioned) he has worked on standardizing terminology through a draft
>> > BIP. In addition, he provided an extremely detailed review of all 300
>> > pages of a draft of Mastering Bitcoin (3rd edition) and has reviewed
>> > drafts of over 200 weekly Optech newsletters, in both cases
>> > significantly improving the accuracy and comprehensibility of the
>> > documentation. To me, that seems very similar to the work we'd ask him
>> > to perform as a BIPs editor and it's something that he's already doing,
>> > so I think there's an excellent fit of person to role.
>> > 
>> > -Dave
>> > 
>> > [1]
>> > https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
>> > <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ 
>> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>
>> >
>> > [2]
>> > https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
>> > <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ 
>> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>
>> >
>> > [3]
>> > https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ 
>> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ 
>> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>
>> >
>> > [4]
>> > https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ 
>> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ 
>> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>
>> >
>> > [5]
>> > https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ 
>> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ 
>> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>
>> >
>> > [6]
>> > https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ 
>> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ 
>> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>
>> >
>> > [7]
>> > https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ 
>> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ 
>> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>
>> >
>> > [8]
>> > 
>> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ 
>> <
>> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ 
>> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>
>> >
>> > [9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>> > <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/ 
>> <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>>
>> > [10]
>> > https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ 
>> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ 
>> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>
>> >
>> > [11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>> > <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>> > [12]
>> > 
>> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ 
>> <
>> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ 
>> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>
>> >
>> > [13]
>> > https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
>> > <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/ 
>> <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>
>> >
>> > [14]
>> > https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
>> > <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ 
>> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>
>> >
>> > [15]
>> > 
>> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ 
>> <
>> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
>> >
>> > [16]
>> > https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ 
>> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ 
>> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>
>> >
>> > [17]
>> > 
>> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ 
>> <
>> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ 
>> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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+...@googlegroups•com 
>> > <mailto:bitcoindev+...@googlegroups•com>.
>> > To view this discussion on the web visit 
>> > 
>> https://groups.google.com/d/msgid/bitcoindev/cbb0b74f-c60b-4c8a-9e97-9b1c0e0eb047n%40googlegroups.com 
>> <
>> https://groups.google.com/d/msgid/bitcoindev/cbb0b74f-c60b-4c8a-9e97-9b1c0e0eb047n%40googlegroups.com?utm_medium=email&utm_source=footer
>> >.
>>
>>
>
>-- 
>

[-- Attachment #2: Type: text/html, Size: 28512 bytes --]

 permalink raw reply	[|nested]
2024-04-02 14:28                           ` Luke Dashjr

  2024-04-02 15:39                               ` Luke Dashjr
  
From: Gloria Zhao @ 2024-04-02 15:13 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 16472 bytes --]

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

Thanks, ACK this timeline for moving forward.

Assuming they are willing, I am in favor of adding Murch, Ruben, and 
Kanzure as BIP editors. They have all demonstrated through years of 
experience contributing to / moderating {the mailing list, stack exchange, 
Optech} that they have the technical expertise, skills in technical 
documentation, and track record of good judgement appropriate for this role.

Best,
Gloria

On Tuesday, April 2, 2024 at 3:30:58 PM UTC+1 Luke Dashjr wrote:

> No, there was no such refusal. The ONLY issue at hand with regard to more 
> BIP editors is that I don't have time to keep up with it by myself. If your 
> goal is anything else, please sit this discussion out (aside from perhaps 
> reasonable objections to new editors). BIP number assignments are trivial 
> and not a concern.
>
> It seems there's an attempt to take advantage of the need for more BIP 
> editors to change or bypass the BIP process without proper procedures 
> followed. While there may be arguments for improving the BIP process, that 
> is unrelated and would need to go through a BIP, not simply fiat of a new 
> editor. Any potential new editor will need to follow the BIP process as it 
> currently is defined until such a new BIP is accepted.
>
> Luke
>
>
> On April 2, 2024 7:49:22 AM CST, /dev /fd0 <alice...@gmail•com> wrote:
>
>> >  Does it matter? The number that a proposal gets has no impact on
>> > literally anything else. They could do it sequentially and it wouldn't
>> > actually make a difference as long as there are no collisions.
>>
>> Process followed to assign the number started this whole debate recently 
>> and creation of BINANA. Previous BIP editor refused to assign numbers to 
>> some BIPs. Kanzure had [tweeted][0] asking users on twitter if a BIP should 
>> be assigned number. So I am curious what process exactly would be followed 
>> by new BIP editors.
>>
>> > For example, this was done when Luke was hacked -
>> > all of his permissions were immediately removed as soon as the news came
>> > out, and were only returned several months later once verified
>> > communication with Luke were established and he was certain that his
>> > GitHub account was no longer (at risk of being) compromised.
>>
>> Thanks for sharing. I wasn't aware of this.
>>
>> [0]: https://x.com/kanzure/status/1752663903715168280
>>
>> /dev/fd0
>> floppy disk guy
>>
>> On Tuesday, April 2, 2024 at 8:22:16 AM UTC Ava Chow wrote:
>>
>>>
>>>
>>> On 04/01/2024 07:55 PM, /dev /fd0 wrote: 
>>> > I think before we decide new BIP editors its important to discuss some 
>>> > things about the process itself: 
>>> > 
>>> > 1. Quoting first paragraph from BIPs repo README: "People wishing to 
>>> > submit BIPs, first should propose their idea or document to the 
>>> > bitco...@lists•linuxfoundation.org mailing list (do not assign a 
>>> > number - read BIP 2 for the full process). After discussion, please 
>>> open 
>>> > a PR. After copy-editing and acceptance, it will be published here." 
>>> > 
>>> > If Kanzure and Ruben are BIP editors, does it mean they can censor 
>>> > someone from submitting BIPs? This question makes sense because they 
>>> > will have control over the whole improvement process for "bitcoin" by 
>>> > being moderators for mailing list and BIP editors. 
>>>
>>> If the only requirement is that a BIP shows up on the mailing list 
>>> first, then they can already censor them. Having them as BIP editors 
>>> wouldn't change that. It's not clear to me that this requirement is 
>>> strictly enforced anyways. 
>>>
>>> Furthermore, they would not have the permissions to delete PRs or 
>>> issues, so once a PR is opened, even if closed, would still be there. 
>>> The status quo w.r.t that would not be any different. At worst, they 
>>> could refuse to assign a BIP a number, but that's no different than what 
>>> already happens today. In fact, the situation would likely be better 
>>> because there would be multiple BIP editors and so what goes into the 
>>> repo is not at the whim of a single person. 
>>>
>>> > 2. How are numbers going to be assigned to BIPs? 
>>>
>>> Does it matter? The number that a proposal gets has no impact on 
>>> literally anything else. They could do it sequentially and it wouldn't 
>>> actually make a difference as long as there are no collisions. 
>>>
>>> > 3. Will there be copy of BIPs and pull requests maintained elsewhere 
>>> > like bitcoin core? 
>>>
>>> I'm not sure why this is relevant to this discussion, but presumably 
>>> there already are, and if there aren't, you can do it yourself. It's 
>>> just like any other repo on GitHub. 
>>>
>>> > 4. What are the expectations from new BIP editors? In what situation 
>>> do 
>>> > we look for next BIP editors or in other words, what will be the 
>>> process 
>>> > to remove an editor if lot of people are unhappy with their work? 
>>>
>>> The expectations are as outlined to BIP 2, and that they are actually 
>>> active. The situation for looking for new BIP editors in the future is 
>>> presumably similar to the one we are in currently - people who write 
>>> BIPs are frustrated with things taking a long time to be merged with the 
>>> root cause being slow response times from the current editor. The 
>>> process would likely be very similar: names are proposed, there is 
>>> discussion about those people, and eventually some are added. 
>>>
>>> As for removal, this has not been something we've ever done before, so 
>>> the process for this is undefined. However, it would presumably be a 
>>> similar procedure as for adding someone. It begins with someone raising 
>>> a complaint about one of the editors on this mailing list or some other 
>>> place a discussion, and a community discussion commences about whether 
>>> or not to remove them. 
>>>
>>> There are certainly situations where one of the GitHub org owners may 
>>> take emergency action and remove a maintainer's privileges. This is only 
>>> done when there is a clear danger than the account may do something 
>>> malicious, and the privileges would be returned if there is clarity that 
>>> it is safe to do so. For example, this was done when Luke was hacked - 
>>> all of his permissions were immediately removed as soon as the news came 
>>> out, and were only returned several months later once verified 
>>> communication with Luke were established and he was certain that his 
>>> GitHub account was no longer (at risk of being) compromised. 
>>>
>>> Ava 
>>>
>>> > 
>>> > /dev/fd0 
>>> > floppy disk guy 
>>> > 
>>> > On Monday, April 1, 2024 at 9:16:54 PM UTC David A. Harding wrote: 
>>> > 
>>> > On 2024-03-28 10:04, Matt Corallo wrote: 
>>> > > Please provide justification rather than simply saying "I like 
>>> > Bob!". 
>>> > 
>>> > Using only comments from the mailing list, the following appears to be 
>>> > the candidate list along with the current support. Asterisks denote 
>>> > candidates who indicated their willingness to accept the role. 
>>> > 
>>> > - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris 
>>> Stewart[3], 
>>> > Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon 
>>> > Black[11], 
>>> > Antoine Riard[12], Murch[13], Antoine Poinsot[15], John Carvalho[16] 
>>> > 
>>> > - Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3], Michael 
>>> > Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15], John 
>>> > Carvalho[16] 
>>> > 
>>> > - Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3], 
>>> > /dev/fd0[5][7], 
>>> > Brandon Black[11], Antoine Riard[12], Ava Chow[14], John Carvalho[16] 
>>> > 
>>> > - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris Stewart[3], John 
>>> > C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine 
>>> > Riard[12], Ava Chow[14] 
>>> > 
>>> > - Mark "Murch" Erhardt*, recommended by Michael Folkson[6], Keagan 
>>> > McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine Riard[12], 
>>> > Ava Chow[14] 
>>> > 
>>> > - Michael Folkson* 
>>> > 
>>> > Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for "non-dev 
>>> > triaging", Tonoski proposed himself[18] for "BIP editor", and Antoine 
>>> > Riard[12] proposed Seccour for "decentralized PM". 
>>> > 
>>> > I searched the BIPs repo by commenter to see if any of the above 
>>> > candidates had been especially active there, which is listed below as: 
>>> > total PRs they commented on (number still open/number closed). 
>>> > 
>>> > - 21 (1/20) commenter:kanzure 
>>> > - 3 (2/1) commenter:rubensomsen 
>>> > - 15 (0/15) commenter:jonatack 
>>> > - 18 (2/16) commenter:roasbeef 
>>> > - 10 (6/4) commenter:Murchandamus 
>>> > - 57 (6/51) commenter:michaelfolkson 
>>> > 
>>> > I'll also note that Osuntokun is the only member of the set to have a 
>>> > merged BIP that they co-authored, although I believe there are 
>>> > far-along 
>>> > draft BIPs for both Murch (terminology) and Somsen (Silent Payments). 
>>> I 
>>> > don't think this should be a requirement, but I do think it 
>>> > demonstrates 
>>> > familiarity with the process. 
>>> > 
>>> > Speaking only for myself, I think all of the candidates above with 
>>> > multiple recommendations from other community participants are fully 
>>> > qualified for the role, so I'll only provide a detailed justification 
>>> > for the person who would be my first pick: Murch is not only a 
>>> > longstanding and broadly liked Bitcoin contributor, but (as Corallo 
>>> > mentioned) he has worked on standardizing terminology through a draft 
>>> > BIP. In addition, he provided an extremely detailed review of all 300 
>>> > pages of a draft of Mastering Bitcoin (3rd edition) and has reviewed 
>>> > drafts of over 200 weekly Optech newsletters, in both cases 
>>> > significantly improving the accuracy and comprehensibility of the 
>>> > documentation. To me, that seems very similar to the work we'd ask him 
>>> > to perform as a BIPs editor and it's something that he's already 
>>> doing, 
>>> > so I think there's an excellent fit of person to role. 
>>> > 
>>> > -Dave 
>>> > 
>>> > [1] 
>>> > https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ 
>>> > <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ 
>>> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>> 
>>>
>>> > [2] 
>>> > https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ 
>>> > <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ 
>>> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>> 
>>>
>>> > [3] 
>>> > 
>>> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ 
>>> <
>>> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ 
>>> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>> 
>>>
>>> > [4] 
>>> > 
>>> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ 
>>> <
>>> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ 
>>> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>> 
>>>
>>> > [5] 
>>> > 
>>> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ 
>>> <
>>> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ 
>>> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>> 
>>>
>>> > [6] 
>>> > 
>>> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ 
>>> <
>>> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ 
>>> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>> 
>>>
>>> > [7] 
>>> > 
>>> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ 
>>> <
>>> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ 
>>> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>> 
>>>
>>> > [8] 
>>> > 
>>> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ 
>>> <
>>> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ 
>>> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>> 
>>>
>>> > [9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/ 
>>> > <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/ 
>>> <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>> 
>>> > [10] 
>>> > 
>>> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ 
>>> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ 
>>> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>> 
>>>
>>> > [11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/ 
>>> > <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/> 
>>> > [12] 
>>> > 
>>> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ 
>>> <
>>> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ 
>>> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>> 
>>>
>>> > [13] 
>>> > https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/ 
>>> > <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/ 
>>> <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>> 
>>>
>>> > [14] 
>>> > https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ 
>>> > <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ 
>>> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>> 
>>>
>>> > [15] 
>>> > 
>>> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ 
>>> <
>>> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/> 
>>>
>>> > [16] 
>>> > 
>>> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ 
>>> <
>>> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ 
>>> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>> 
>>>
>>> > [17] 
>>> > 
>>> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ 
>>> <
>>> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ 
>>> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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+...@googlegroups•com 
>>> > <mailto:bitcoindev+...@googlegroups•com>. 
>>> > To view this discussion on the web visit 
>>> > 
>>> https://groups.google.com/d/msgid/bitcoindev/cbb0b74f-c60b-4c8a-9e97-9b1c0e0eb047n%40googlegroups.com 
>>> <
>>> https://groups.google.com/d/msgid/bitcoindev/cbb0b74f-c60b-4c8a-9e97-9b1c0e0eb047n%40googlegroups.com?utm_medium=email&utm_source=footer>. 
>>>
>>>
>>>

-- 
2: Type: text/html, Size: 30139 bytes --]

 permalink raw reply	[|nested]
2024-04-02 15:13                             ` Gloria Zhao

  2024-04-03 15:03                                 ` Murch
  
From: Luke Dashjr @ 2024-04-02 15:39 UTC (permalink / raw)
  To: bitcoindev, Gloria Zhao, Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 17586 bytes --]

On the timeline, there has already been a very reasonable objection raised by Antoine. I'm also unlikely to be available around that time (and through the weekend) to actually do it. So it'll need to be next week at the earliest, but I don't see a problem with closer to May if that's important to some.

Luke


On April 2, 2024 9:13:46 AM CST, Gloria Zhao <gloria@brink•dev> wrote:
>> 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).
>
>Thanks, ACK this timeline for moving forward.
>
>Assuming they are willing, I am in favor of adding Murch, Ruben, and 
>Kanzure as BIP editors. They have all demonstrated through years of 
>experience contributing to / moderating {the mailing list, stack exchange, 
>Optech} that they have the technical expertise, skills in technical 
>documentation, and track record of good judgement appropriate for this role.
>
>Best,
>Gloria
>
>On Tuesday, April 2, 2024 at 3:30:58 PM UTC+1 Luke Dashjr wrote:
>
>> No, there was no such refusal. The ONLY issue at hand with regard to more 
>> BIP editors is that I don't have time to keep up with it by myself. If your 
>> goal is anything else, please sit this discussion out (aside from perhaps 
>> reasonable objections to new editors). BIP number assignments are trivial 
>> and not a concern.
>>
>> It seems there's an attempt to take advantage of the need for more BIP 
>> editors to change or bypass the BIP process without proper procedures 
>> followed. While there may be arguments for improving the BIP process, that 
>> is unrelated and would need to go through a BIP, not simply fiat of a new 
>> editor. Any potential new editor will need to follow the BIP process as it 
>> currently is defined until such a new BIP is accepted.
>>
>> Luke
>>
>>
>> On April 2, 2024 7:49:22 AM CST, /dev /fd0 <alice...@gmail•com> wrote:
>>
>>> >  Does it matter? The number that a proposal gets has no impact on
>>> > literally anything else. They could do it sequentially and it wouldn't
>>> > actually make a difference as long as there are no collisions.
>>>
>>> Process followed to assign the number started this whole debate recently 
>>> and creation of BINANA. Previous BIP editor refused to assign numbers to 
>>> some BIPs. Kanzure had [tweeted][0] asking users on twitter if a BIP should 
>>> be assigned number. So I am curious what process exactly would be followed 
>>> by new BIP editors.
>>>
>>> > For example, this was done when Luke was hacked -
>>> > all of his permissions were immediately removed as soon as the news came
>>> > out, and were only returned several months later once verified
>>> > communication with Luke were established and he was certain that his
>>> > GitHub account was no longer (at risk of being) compromised.
>>>
>>> Thanks for sharing. I wasn't aware of this.
>>>
>>> [0]: https://x.com/kanzure/status/1752663903715168280
>>>
>>> /dev/fd0
>>> floppy disk guy
>>>
>>> On Tuesday, April 2, 2024 at 8:22:16 AM UTC Ava Chow wrote:
>>>
>>>>
>>>>
>>>> On 04/01/2024 07:55 PM, /dev /fd0 wrote: 
>>>> > I think before we decide new BIP editors its important to discuss some 
>>>> > things about the process itself: 
>>>> > 
>>>> > 1. Quoting first paragraph from BIPs repo README: "People wishing to 
>>>> > submit BIPs, first should propose their idea or document to the 
>>>> > bitco...@lists•linuxfoundation.org mailing list (do not assign a 
>>>> > number - read BIP 2 for the full process). After discussion, please 
>>>> open 
>>>> > a PR. After copy-editing and acceptance, it will be published here." 
>>>> > 
>>>> > If Kanzure and Ruben are BIP editors, does it mean they can censor 
>>>> > someone from submitting BIPs? This question makes sense because they 
>>>> > will have control over the whole improvement process for "bitcoin" by 
>>>> > being moderators for mailing list and BIP editors. 
>>>>
>>>> If the only requirement is that a BIP shows up on the mailing list 
>>>> first, then they can already censor them. Having them as BIP editors 
>>>> wouldn't change that. It's not clear to me that this requirement is 
>>>> strictly enforced anyways. 
>>>>
>>>> Furthermore, they would not have the permissions to delete PRs or 
>>>> issues, so once a PR is opened, even if closed, would still be there. 
>>>> The status quo w.r.t that would not be any different. At worst, they 
>>>> could refuse to assign a BIP a number, but that's no different than what 
>>>> already happens today. In fact, the situation would likely be better 
>>>> because there would be multiple BIP editors and so what goes into the 
>>>> repo is not at the whim of a single person. 
>>>>
>>>> > 2. How are numbers going to be assigned to BIPs? 
>>>>
>>>> Does it matter? The number that a proposal gets has no impact on 
>>>> literally anything else. They could do it sequentially and it wouldn't 
>>>> actually make a difference as long as there are no collisions. 
>>>>
>>>> > 3. Will there be copy of BIPs and pull requests maintained elsewhere 
>>>> > like bitcoin core? 
>>>>
>>>> I'm not sure why this is relevant to this discussion, but presumably 
>>>> there already are, and if there aren't, you can do it yourself. It's 
>>>> just like any other repo on GitHub. 
>>>>
>>>> > 4. What are the expectations from new BIP editors? In what situation 
>>>> do 
>>>> > we look for next BIP editors or in other words, what will be the 
>>>> process 
>>>> > to remove an editor if lot of people are unhappy with their work? 
>>>>
>>>> The expectations are as outlined to BIP 2, and that they are actually 
>>>> active. The situation for looking for new BIP editors in the future is 
>>>> presumably similar to the one we are in currently - people who write 
>>>> BIPs are frustrated with things taking a long time to be merged with the 
>>>> root cause being slow response times from the current editor. The 
>>>> process would likely be very similar: names are proposed, there is 
>>>> discussion about those people, and eventually some are added. 
>>>>
>>>> As for removal, this has not been something we've ever done before, so 
>>>> the process for this is undefined. However, it would presumably be a 
>>>> similar procedure as for adding someone. It begins with someone raising 
>>>> a complaint about one of the editors on this mailing list or some other 
>>>> place a discussion, and a community discussion commences about whether 
>>>> or not to remove them. 
>>>>
>>>> There are certainly situations where one of the GitHub org owners may 
>>>> take emergency action and remove a maintainer's privileges. This is only 
>>>> done when there is a clear danger than the account may do something 
>>>> malicious, and the privileges would be returned if there is clarity that 
>>>> it is safe to do so. For example, this was done when Luke was hacked - 
>>>> all of his permissions were immediately removed as soon as the news came 
>>>> out, and were only returned several months later once verified 
>>>> communication with Luke were established and he was certain that his 
>>>> GitHub account was no longer (at risk of being) compromised. 
>>>>
>>>> Ava 
>>>>
>>>> > 
>>>> > /dev/fd0 
>>>> > floppy disk guy 
>>>> > 
>>>> > On Monday, April 1, 2024 at 9:16:54 PM UTC David A. Harding wrote: 
>>>> > 
>>>> > On 2024-03-28 10:04, Matt Corallo wrote: 
>>>> > > Please provide justification rather than simply saying "I like 
>>>> > Bob!". 
>>>> > 
>>>> > Using only comments from the mailing list, the following appears to be 
>>>> > the candidate list along with the current support. Asterisks denote 
>>>> > candidates who indicated their willingness to accept the role. 
>>>> > 
>>>> > - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris 
>>>> Stewart[3], 
>>>> > Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon 
>>>> > Black[11], 
>>>> > Antoine Riard[12], Murch[13], Antoine Poinsot[15], John Carvalho[16] 
>>>> > 
>>>> > - Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3], Michael 
>>>> > Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15], John 
>>>> > Carvalho[16] 
>>>> > 
>>>> > - Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3], 
>>>> > /dev/fd0[5][7], 
>>>> > Brandon Black[11], Antoine Riard[12], Ava Chow[14], John Carvalho[16] 
>>>> > 
>>>> > - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris Stewart[3], John 
>>>> > C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine 
>>>> > Riard[12], Ava Chow[14] 
>>>> > 
>>>> > - Mark "Murch" Erhardt*, recommended by Michael Folkson[6], Keagan 
>>>> > McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine Riard[12], 
>>>> > Ava Chow[14] 
>>>> > 
>>>> > - Michael Folkson* 
>>>> > 
>>>> > Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for "non-dev 
>>>> > triaging", Tonoski proposed himself[18] for "BIP editor", and Antoine 
>>>> > Riard[12] proposed Seccour for "decentralized PM". 
>>>> > 
>>>> > I searched the BIPs repo by commenter to see if any of the above 
>>>> > candidates had been especially active there, which is listed below as: 
>>>> > total PRs they commented on (number still open/number closed). 
>>>> > 
>>>> > - 21 (1/20) commenter:kanzure 
>>>> > - 3 (2/1) commenter:rubensomsen 
>>>> > - 15 (0/15) commenter:jonatack 
>>>> > - 18 (2/16) commenter:roasbeef 
>>>> > - 10 (6/4) commenter:Murchandamus 
>>>> > - 57 (6/51) commenter:michaelfolkson 
>>>> > 
>>>> > I'll also note that Osuntokun is the only member of the set to have a 
>>>> > merged BIP that they co-authored, although I believe there are 
>>>> > far-along 
>>>> > draft BIPs for both Murch (terminology) and Somsen (Silent Payments). 
>>>> I 
>>>> > don't think this should be a requirement, but I do think it 
>>>> > demonstrates 
>>>> > familiarity with the process. 
>>>> > 
>>>> > Speaking only for myself, I think all of the candidates above with 
>>>> > multiple recommendations from other community participants are fully 
>>>> > qualified for the role, so I'll only provide a detailed justification 
>>>> > for the person who would be my first pick: Murch is not only a 
>>>> > longstanding and broadly liked Bitcoin contributor, but (as Corallo 
>>>> > mentioned) he has worked on standardizing terminology through a draft 
>>>> > BIP. In addition, he provided an extremely detailed review of all 300 
>>>> > pages of a draft of Mastering Bitcoin (3rd edition) and has reviewed 
>>>> > drafts of over 200 weekly Optech newsletters, in both cases 
>>>> > significantly improving the accuracy and comprehensibility of the 
>>>> > documentation. To me, that seems very similar to the work we'd ask him 
>>>> > to perform as a BIPs editor and it's something that he's already 
>>>> doing, 
>>>> > so I think there's an excellent fit of person to role. 
>>>> > 
>>>> > -Dave 
>>>> > 
>>>> > [1] 
>>>> > https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ 
>>>> > <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ 
>>>> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>> 
>>>>
>>>> > [2] 
>>>> > https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ 
>>>> > <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ 
>>>> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>> 
>>>>
>>>> > [3] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ 
>>>> <
>>>> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ 
>>>> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>> 
>>>>
>>>> > [4] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ 
>>>> <
>>>> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ 
>>>> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>> 
>>>>
>>>> > [5] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ 
>>>> <
>>>> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ 
>>>> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>> 
>>>>
>>>> > [6] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ 
>>>> <
>>>> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ 
>>>> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>> 
>>>>
>>>> > [7] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ 
>>>> <
>>>> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ 
>>>> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>> 
>>>>
>>>> > [8] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ 
>>>> <
>>>> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ 
>>>> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>> 
>>>>
>>>> > [9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/ 
>>>> > <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/ 
>>>> <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>> 
>>>> > [10] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ 
>>>> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ 
>>>> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>> 
>>>>
>>>> > [11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/ 
>>>> > <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/> 
>>>> > [12] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ 
>>>> <
>>>> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ 
>>>> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>> 
>>>>
>>>> > [13] 
>>>> > https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/ 
>>>> > <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/ 
>>>> <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>> 
>>>>
>>>> > [14] 
>>>> > https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ 
>>>> > <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ 
>>>> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>> 
>>>>
>>>> > [15] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ 
>>>> <
>>>> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/> 
>>>>
>>>> > [16] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ 
>>>> <
>>>> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ 
>>>> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>> 
>>>>
>>>> > [17] 
>>>> > 
>>>> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ 
>>>> <
>>>> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ 
>>>> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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+...@googlegroups•com 
>>>> > <mailto:bitcoindev+...@googlegroups•com>. 
>>>> > To view this discussion on the web visit 
>>>> > 
>>>> https://groups.google.com/d/msgid/bitcoindev/cbb0b74f-c60b-4c8a-9e97-9b1c0e0eb047n%40googlegroups.com 
>>>> <
>>>> https://groups.google.com/d/msgid/bitcoindev/cbb0b74f-c60b-4c8a-9e97-9b1c0e0eb047n%40googlegroups.com?utm_medium=email&utm_source=footer>. 
>>>>
>>>>
>>>>
>
>-- 
>

[-- Attachment #2: Type: text/html, Size: 30602 bytes --]

 permalink raw reply	[|nested]
2024-04-02 15:39                               ` Luke Dashjr

  
From: Murch @ 2024-04-03 15:03 UTC (permalink / raw)
  To: bitcoindev

The BIP repository situation has been an on-going source of frustration 
for an extended period of time, leading e.g. to Kalle being added as an 
additional editor three years ago, and AJ created the BINANA repository 
almost three months ago. Hence, I am not in a particular rush or 
invested in the timeline of my casual proposal. My main goal was to 
restart progress on the topic. However, I would prefer if objections 
were accompanied by a concrete actionable alternatives as we will 
otherwise just get bogged down again.

Given the concerns with the timeline, I propose that we extend the 
timebox by another two weeks to solicit comments on editor candidates 
until the 19th of April and aim to add more editors around the 22nd. 
These dates would put the end of the comment period well after the Core 
Dev meeting. If you have other concrete reasons why this timeline is 
unreasonable, please state your reasons _and provide an alternative 
proposal.

I agree though, that the discussion of adding additional editors and the 
discussion of changing the process are two separate topics and should 
not be intermingled.

Best,

Murch

On 4/2/24 11:39, Luke Dashjr wrote:
> On the timeline, there has already been a very reasonable objection raised by Antoine. I'm also unlikely to be available around that time (and through the weekend) to actually do it. So it'll need to be next week at the earliest, but I don't see a problem with closer to May if that's important to some.
> 
> Luke

-- 



 permalink raw reply	[|nested]
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 17:24               ` Vasil Dimov
  
From: Juan Galt @ 2024-04-03 16:58 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 5569 bytes --]

Hello there! I'm not an active contributor but I've been following the 
mailing list for years, and try to keep a close eye on the most important 
aspects of Bitcoin. 

Throwing in my support for Jon Atack and Kanzure, who's work I follow more 
closely. The others I am less familiar with. 

Nevertheless I agree with NVK that the more editors this process has, the 
better. No need for this to be a bottleneck. 

Jon in particular I know has years of experience with copy editing, 
documentation and review of Bitcoin core code.

Cheers!

Juan Galt

On Sunday, March 31, 2024 at 1:31:14 PM UTC-5 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
> .
>
>

-- 
2: Type: text/html, Size: 7136 bytes --]

 permalink raw reply	[|nested]
2024-04-03 16:58             ` Juan Galt

  2024-04-03 18:34                 ` 'Fabian' via Bitcoin Development Mailing List
  
From: Vasil Dimov @ 2024-04-03 17:24 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 576 bytes --]

+1 on Jon Atack - he is familiar with the development process, has done 
excellent documentation before and his English is superb.

I do not know the others well enough.

Just my 2 sats.

-- 
2: Type: text/html, Size: 913 bytes --]

 permalink raw reply	[|nested]
2024-04-03 17:24               ` Vasil Dimov

  
From: 'Fabian' via Bitcoin Development Mailing List @ 2024-04-03 18:34 UTC (permalink / raw)
  To: Vasil Dimov;  Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]

Hi,

I support the following candidates:

- Jon Atack: Jon has been a valuable contributor to Bitcoin Core for many years and has been particularly active as a reviewer there.
- Murch: Murch has been a valuable contributor to Bitcoin Core even longer and is a moderator and contributor to Bitcoin Stack Exchange as well as contributor to Bitcoin Optech.
- Kanzure and Ruben Somsen: Both have been contributing to the ecosystem overall for a long time and have also done a great job maintaining the mailing list.

I want to add that I particularly like that Jon does not have any other comparable administrative function in the Bitcoin ecosystem yet afaik. I think it's in everyone's interest that we distribute such workload to more shoulders and allow newer contributors to step into such tasks. If we only look at past references we will give all the administrative tasks to the same people. This means they will not be able to contribute as much to Bitcoin outside of those functions and could also be at higher risk of burnout.

For the others, I am either not familiar with them at all or I haven't followed their work enough lately to make a decision.

I also think it would be good to add more than one additional editor so that we have some redundancy, 2-3 sounds ideal to me.

Cheers,Fabian
On Wednesday, April 3rd, 2024 at 7:24 PM, Vasil Dimov <vasild@gmail•com> wrote:

> +1 on Jon Atack - he is familiar with the development process, has done excellent documentation before and his English is superb.
>
> I do not know the others well enough.
>
> Just my 2 sats.
>
> --
> 

[-- Attachment #2: Type: text/html, Size: 3651 bytes --]

 permalink raw reply	[|nested]
2024-04-02 13:17                 ` [bitcoindev] Time for an update to BIP2? Tim Ruffing

  2024-04-04  5:00                     ` Anthony Towns
  
From: Pieter Wuille @ 2024-04-03 19:44 UTC (permalink / raw)
  To: Tim Ruffing;  Matt Corallo, Brandon Black, Murch, bitcoindev

[-- Attachment #1: Type: text/plain, Size: 10958 bytes --]

Thank you for splitting off this discussion. I believe that lots of commentators who see problems with the BIPs process fail to distinguish between the editor being overloaded, and unclarity or disagreement about what the editor's job is supposed to be in the first place.

In particular, I've seen some comments akin to "assigning numbers shouldn't take that much work", while the BIP2 sections you highlight do show that the process does involve a lot more than that. Discussion about what the process is supposed to be should be separate from a discussion about who will facilitate that process.

More comments inline below.

>

On Tuesday, April 2nd, 2024 at 9:17 AM, Tim Ruffing crypto@timruffing•de wrote:

> BIP2, Section "BIP workflow" says this:
>
> "The BIP editors will not unreasonably reject a BIP. Reasons for
> rejecting BIPs include duplication of effort, disregard for formatting
> rules, being too unfocused or too broad, being technically unsound, not
> providing proper motivation or addressing backwards compatibility, or
> not in keeping with the Bitcoin philosophy. For a BIP to be accepted it
> must meet certain minimum criteria. It must be a clear and complete
> description of the proposed enhancement. The enhancement must represent
> a net improvement. The proposed implementation, if applicable, must be
> solid and must not complicate the protocol unduly."
>
> This is a lot of criteria for a simple editorial rule, hm? How could
> any editor judge if an enhancement represents a net improvement without
> opining on its merit? What's the Bitcoin philosophy?

Good point, this does seem to imply some value judgements. If we're open to making changes to what the criteria for a BIP are supposed to be, I think it ought to include:

- Formatting: contains necessary sections/headers, license, ...
- Editorial qualities: proper English, organized, ...
- Discussion: must have been presented on the ML or other common fora, received interest/discussion, ...
- Need for standardization: not every idea is worth publishing; if it isn't likely to affect multiple projects/pieces of software, it can just be software documentation instead.
- Scope: related to technology that supports the bitcoin currency.

This last one may be controversial, but I feel that some of the discussion the past months about the process has shown that there is unclarity/disagreement here, and it would be good to have some guideline written out here. I think scope will inevitably be somewhat of a grey zone, but I feel some limits (whether spelled out or not) will exist regardless (nobody would consider including the HTTP spec in scope for a BIP, I think?). One suggestion I have seen (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022072.html) is limiting to "extremely widespread standards used by the entire Bitcoin community", but I feel that suffers from a "no true Scotsman" fallacy (who gets to define what the "Bitcoin community" is, in a technology that to me seems designed for distrusting parties?), but would also under reasonable interpretations exclude several very useful BIPs today (some wallet standards are useful for some software and not others) and likely contribute to process friction (where do they move to?). I don't think that's a desirable situation.

I also don't think scope should be tied to specific technologies (e.g. it shouldn't just be about on-chain transactions, as e.g. that would exclude address formats), but if not that, what scoping is useful? And to me, restricting to technology that supports the bitcoin currency is fairly clear, reasonable, and avoids a circular definition. As an example, that would exclude OpenTimestamps from scope (which was suggested in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022077.html). I see that as an unrelated application which happens to make use of the Bitcoin blockchain, which on itself is one of the technologies that supports bitcoin - but is an indirection too far to be in scope.

Note that however none of the criteria I list above are quality assessments; I think it is essential that BIP editors can accept BIPs they themselves find abhorrent. People can strongly disagree about whether a proposed standard is a good idea, or even whether it falls within the "Bitcoin philosophy", without disagreeing whether it is at all related to bitcoin (the currency).

> By the way, Section "BIP Editor Responsibilities & Workflow" says this:
>
> "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.
> - [...]"
>
> Note how this is is (seemingly?) in conflict with the paragraph cited
> further above. What is "acceptance"? Acceptance by the editor, by the
> community (whoever that is), or by anyone else?

I don't see a problem here; my interpretation is that this is exactly about excluding certain value judgements from what the editor is supposed to do: they must judge soundness and completeness, without​ trying to guess whether the community is likely to accept the idea. "sound and complete" is perhaps too vague as a criterion, but I'm in support of explicitly excluding guessing of acceptance.

> BIP2 has other problems (a lot of which date back to BIP1):
>
> * It recommends licensing BIPs under BSD-2 or BSD-3, which are
> software licenses. It's not even clear if they're applicable to
>
> plain text. (The CC0 recommendation makes much more sense.)

No strong opinion about this, but that sounds reasonable.

> * The Comments-URI thing is outdated and everyone seems to ignore it.
>
> Comments-Summary is even weirder.

Agreed. It's unused, and sometimes misinterpreted. I think we should get rid of it.

> * "Informational BIPs do not necessarily represent a Bitcoin community
> consensus or recommendation". Aha, does this imply that Standards
> Track BIPs need to represent a Bitcoin community consensus or
>
> recommendation?

Indeed. I don't think BIPs should be representing community consensus or recommendations. But perhaps they can document individual pieces of evidence of acceptance; see further?

> * Ever tried to write pseudocode or LaTeX in mediawiki format? It's
>
> more than annoying, believe me.

I'd like permitting BIPs to be written in markdown.

> Moreover, the entire "BIP status field" section is an attempt at
> formalizing and describing the process of changing Bitcoin. That leads
> to statements like these that specify when a BIP should be "Final"
>
> * "A soft-fork BIP strictly requires a clear miner majority expressed
> by blockchain voting (eg, using BIP 9)." That statement is highly
> controversial. The point is that it simply doesn't belong in BIP2.
> * "API/RPC and application layer BIPs must be implemented by at least
> two independent and compatible software applications." same here
> * Peer services BIPs should be observed to be adopted by at least 1%
>
> of public listening nodes for one month.

Some forms of Status are useful I think, but they ought to reflect the author's intent, not the community's perception. E.g. "Draft", "Proposed", and "Withdrawn" make sense to me for any kind of standard. In Draft stage more substantial changes could be permitted, but would convey the idea isn't yet intended for adoption. Of course, the BIP1 status fields weren't really used, and the BIP2 status fields don't seem to be doing much better. If we assume that BIP3 status fields aren't going to be used either this is all for nought, but perhaps it's still worth trying with a significantly simplified assortment of statuses.

Things like "Active / Final" and "Rejected" relate to community acceptance, and I agree those don't belong in BIPs. Instead, could we perhaps have a field that indicates objective evidence of acceptance, such as listing which software projects have implemented/adopted it?

As far as judging consensus goes, perhaps actual consensus changes are an exception? I feel that for those, an "Accepted" status may actually make sense, because they actually require the ecosystem to have agreement about. But even then, it could be restricted to be an after-the-fact piece of evidence (whatever its activation rules are, they are met), rather than a judgement of community perception.

Regarding the "at least two independent and compatible software applications", I don't think this is a bad principle: good standards should be implementable by many, and having multiple implementations is an objective way of assessing that. I'm not sure that means being a requirement for its status, but at least an intent to have multiple implementations is a useful condition for the "Need for standardization" rule I suggest above.

> The problems are similar to the Comments-Summary field whose purpose is
> to represent a community judgment of the BIP. It can have these values:
> * No comments yet.
> * Unanimously Recommended for implementation
> * Unanimously Discourage for implementation
> * Mostly Recommended for implementation, with some Discouragement
> * Mostly Discouraged for implementation, with some Recommendation
>
> There's a reason why noone really uses this. Like the Status field, it
> requires that someone (the editor? BIP2 doesn't specify this) makes a
> judgement that looks somewhat authoritative, because it will end up in
>
> the BIP header/metadata.

Agreed.

> I think we should simply drop anything that requires an examination of
> the meat of the BIP, e.g., the Status and Comments-* fields, and the
> requirement to check the meat of a BIP. Instead, we should work on a
> new process BIP that merely describes a simple process of publishing
> BIPs, in which the editors focus on purely formal and editorial issues
> (e.g., formatting, license, readability, filtering spam, ...). It's
> great when they guide BIP authors by providing feedback on the
> presentation of an idea, or even on the idea itself, but they shouldn't
> be required to make decisions based on the technical or philosophical
>
> merit of a BIP

I think my view is somewhat more restrictive than yours, e.g. that BIPs ought to satisfy some scope and need for standardization criteria, but I agree that as written in BIP2 today, Editors have too many judgement calls to make.

--
Pieter

-- 


[-- Attachment #2: Type: text/html, Size: 13297 bytes --]

 permalink raw reply	[|nested]
2024-04-03 19:44                   ` Pieter Wuille

  2024-04-04  9:09                       ` Niklas Goegge
  2024-05-13 18:33                       ` [bitcoindev] Time for an update to BIP2? Murch
  
From: Anthony Towns @ 2024-04-04  5:00 UTC (permalink / raw)
  To: Pieter Wuille;  bitcoindev

On Wed, Apr 03, 2024 at 07:44:00PM +0000, Pieter Wuille wrote:
> - Scope: related to technology that supports the bitcoin currency.

> This last one may be controversial, but I feel that some of the discussion the past months about the process has shown that there is unclarity/disagreement here, and it would be good to have some guideline written out here. I think scope will inevitably be somewhat of a grey zone, but I feel some limits (whether spelled out or not) will exist regardless (nobody would consider including the HTTP spec in scope for a BIP, I think?).

> I also don't think scope should be tied to specific technologies (e.g. it shouldn't just be about on-chain transactions, as e.g. that would exclude address formats), but if not that, what scoping is useful? And to me, restricting to technology that supports the bitcoin currency is fairly clear, reasonable, and avoids a circular definition. As an example, that would exclude OpenTimestamps from scope (which was suggested in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022077.html). I see that as an unrelated application which happens to make use of the Bitcoin blockchain, which on itself is one of the technologies that supports bitcoin - but is an indirection too far to be in scope.

For BINANA I phrased that as "proposals only being rejected if they are
... unrelated to Bitcoin", on the basis that deciding some BIP/BIN is
dumb and ignoring it wastes a lot less time than arguing about whether
it's a good thing for the monetary properties of Bitcoin (which is what
I'm interested in helping people work on).

For example, would adding script opcodes whose only purpose is to better
support moving BTC to/from sidechains like Liquid or WBTC on Eth, where
they can be used as collateral in market makers for trading other tokens
count as "supporting the bitcoin currency"? This might include such
things like Drivechains (BIP 300, 301), eg. Is such a feature more about
supporting asset trading, or is anything that involves buying/selling
things with Bitcoin count as supporting bitcoin as a currency?

Does it make a difference that a script opcode would be consensus
critical? Another way of allowing trading between BTC and other assets is
the "Taproot Assets" proposal (BIPs PR#1489), which anchor trades between
BTC and tokenized assets on the Bitcoin blockchain, but don't require
consensus changes. If the BIPS repo includes docs on Drivechains, is
excluding proposals about Taproot Assets or RGB or similar that valuable?

Those all seems arguable to me; but why force people to have those
arguments over making up a number and hosting a document in a git repo?

> > * The Comments-URI thing is outdated and everyone seems to ignore it.
> > Comments-Summary is even weirder.
> Agreed. It's unused, and sometimes misinterpreted. I think we should get rid of it.

For BINANA I added a "Discussion" header where the BIN author can point to
locations where discussion has/can take place -- it seemed like a useful
thing to have beyond just links in the "rationale", both for researching
background into the proposals development, and as a pointer to somewhere
people can leave additional feedback. I don't think there's much value in
having a dedicated discussion area in the BINANA/BIP repo itself though.

> > * "Informational BIPs do not necessarily represent a Bitcoin community
> > consensus or recommendation". Aha, does this imply that Standards
> > Track BIPs need to represent a Bitcoin community consensus or
> > recommendation?
> Indeed. I don't think BIPs should be representing community consensus or recommendations. But perhaps they can document individual pieces of evidence of acceptance; see further?

Documenting consensus change activation seems useful if nothing else,
eg as in BIP 90.

> > * Ever tried to write pseudocode or LaTeX in mediawiki format? It's
> > more than annoying, believe me.
> I'd like permitting BIPs to be written in markdown.

This is already permitted, see https://github.com/bitcoin/bips/pull/1504

> Some forms of Status are useful I think, but they ought to reflect the author's intent, not the community's perception. E.g. "Draft", "Proposed", and "Withdrawn" make sense to me for any kind of standard. In Draft stage more substantial changes could be permitted, but would convey the idea isn't yet intended for adoption. Of course, the BIP1 status fields weren't really used, and the BIP2 status fields don't seem to be doing much better. If we assume that BIP3 status fields aren't going to be used either this is all for nought, but perhaps it's still worth trying with a significantly simplified assortment of statuses.
> 
> Things like "Active / Final" and "Rejected" relate to community acceptance, and I agree those don't belong in BIPs.

I think "Proposed" is much more related to community acceptance than
"Active" -- you can reasonably say something is "Active" once a single
implementation has a released version that actively supports it, for
example; but describing a standard as "Proposed" seems to be pretty
clearly trying to achieve so form of community acceptance? Who else
would you be proposing it to?

I'd look at the lifecycle more as something like:

 * Draft: author expects further changes, don't deploy this
 * Proposed: author is hoping for multiple implementations to adopt this;
    author thinks it's complete, but there may be objections and it may
    need to go back to Draft state to resolve those objections
 * Active: one or more implementations have deployed this feature as
    specced. changes will usually be specified in a new proposal/standard.
    acceptable changes might be fixing ambiguities, adding extra rationale
    or test cases, etc.
 * Withdrawn: no current implementations support this, author doesn't
    think it should be adopted, author isn't planning on making further
    changes to it

For comparison, BINANA currently has BINs marked Draft, Active and Info:
https://github.com/bitcoin-inquisition/binana

(Note that adding a consensus change in inquisition and doing a heretical
activation of that change on signet would still leave the spec in "Draft"
-- further changes are expected)

(As far as BIP 2's list goes, I think Deferred should just be Draft;
Rejected/Obsolete should just be Withdrawn; Final should just be Active;
and Replaced should either be Withdrawn or Active depending on whether
the replacement is backwards compatible, accompanied by Superseded-By)

> As far as judging consensus goes, perhaps actual consensus changes are an exception? I feel that for those, an "Accepted" status may actually make sense, because they actually require the ecosystem to have agreement about.

How about BIP 148 or BIP 91? I think it's fair to call both of those
"Active" and would have been fair to mark them Active sometime in
April-July 2017 -- that doesn't mean there was necessarily community
consensus behind them: merely that there was software implementing
those standards active on the network, and that if someone wanted to do
something similar but different, that would warrant being a different
standard. If it had turned out there wasn't consensus behind either
proposal, and no one was mining a blockchain that those implementations
would accept, at most that would warrant the author marking the BIPs as
"Withdrawn" IMO.

The same argument applies to BIP 343 I think. I believe only one
implementation adopted it [0], and I don't believe any actively maintained
software implements that BIP as written, but if you did implement it
you'd continue to track the bitcoin blockchain, so I think it would
be fair to have marked that BIP as "Active" once it was adopted by an
implementation, and to have left it marked that way.

[0] "Bitcoin Core-based Taproot Client" which doesn't even seem to exist
    in web.archive.org.
    https://github.com/BitcoinActivation/BitcoinTaproot.org/blob/master/taproot.html

If the segwit2x fork had ever had a written spec, I likewise think it
would have been appropriate for it to be a BIP, perhaps being marked as
Proposed on 2017-07-01 [1], Active on 2017-07-22 [2], and Withdrawn on
either 2017-11-08 [3] or 2019-10-09 (when the btc1/bitcoin github repo
was marked as archived).

[1] https://github.com/btc1/bitcoin/pull/50
[2] https://github.com/btc1/bitcoin/releases/tag/v1.14.5
[3] https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-November/000685.html

Cheers,
aj

-- 



 permalink raw reply	[|nested]
2024-04-04  5:00                     ` Anthony Towns

  2024-04-04 12:58                         ` [bitcoindev] Adding New BIP Editors 0xB10C
  2024-05-13 18:33                       ` [bitcoindev] Time for an update to BIP2? Murch
  
From: Niklas Goegge @ 2024-04-04  9:09 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 9321 bytes --]

Hi,

Assuming they are willing, I am supportive of Kanzure, Ruben, Laolu and 
Murch as BIP editors.

Best
Niklas

Anthony Towns schrieb am Donnerstag, 4. April 2024 um 06:33:05 UTC+1:

> On Wed, Apr 03, 2024 at 07:44:00PM +0000, Pieter Wuille wrote:
> > - Scope: related to technology that supports the bitcoin currency.
>
> > This last one may be controversial, but I feel that some of the 
> discussion the past months about the process has shown that there is 
> unclarity/disagreement here, and it would be good to have some guideline 
> written out here. I think scope will inevitably be somewhat of a grey zone, 
> but I feel some limits (whether spelled out or not) will exist regardless 
> (nobody would consider including the HTTP spec in scope for a BIP, I 
> think?).
>
> > I also don't think scope should be tied to specific technologies (e.g. 
> it shouldn't just be about on-chain transactions, as e.g. that would 
> exclude address formats), but if not that, what scoping is useful? And to 
> me, restricting to technology that supports the bitcoin currency is fairly 
> clear, reasonable, and avoids a circular definition. As an example, that 
> would exclude OpenTimestamps from scope (which was suggested in 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022077.html). 
> I see that as an unrelated application which happens to make use of the 
> Bitcoin blockchain, which on itself is one of the technologies that 
> supports bitcoin - but is an indirection too far to be in scope.
>
> For BINANA I phrased that as "proposals only being rejected if they are
> ... unrelated to Bitcoin", on the basis that deciding some BIP/BIN is
> dumb and ignoring it wastes a lot less time than arguing about whether
> it's a good thing for the monetary properties of Bitcoin (which is what
> I'm interested in helping people work on).
>
> For example, would adding script opcodes whose only purpose is to better
> support moving BTC to/from sidechains like Liquid or WBTC on Eth, where
> they can be used as collateral in market makers for trading other tokens
> count as "supporting the bitcoin currency"? This might include such
> things like Drivechains (BIP 300, 301), eg. Is such a feature more about
> supporting asset trading, or is anything that involves buying/selling
> things with Bitcoin count as supporting bitcoin as a currency?
>
> Does it make a difference that a script opcode would be consensus
> critical? Another way of allowing trading between BTC and other assets is
> the "Taproot Assets" proposal (BIPs PR#1489), which anchor trades between
> BTC and tokenized assets on the Bitcoin blockchain, but don't require
> consensus changes. If the BIPS repo includes docs on Drivechains, is
> excluding proposals about Taproot Assets or RGB or similar that valuable?
>
> Those all seems arguable to me; but why force people to have those
> arguments over making up a number and hosting a document in a git repo?
>
> > > * The Comments-URI thing is outdated and everyone seems to ignore it.
> > > Comments-Summary is even weirder.
> > Agreed. It's unused, and sometimes misinterpreted. I think we should get 
> rid of it.
>
> For BINANA I added a "Discussion" header where the BIN author can point to
> locations where discussion has/can take place -- it seemed like a useful
> thing to have beyond just links in the "rationale", both for researching
> background into the proposals development, and as a pointer to somewhere
> people can leave additional feedback. I don't think there's much value in
> having a dedicated discussion area in the BINANA/BIP repo itself though.
>
> > > * "Informational BIPs do not necessarily represent a Bitcoin community
> > > consensus or recommendation". Aha, does this imply that Standards
> > > Track BIPs need to represent a Bitcoin community consensus or
> > > recommendation?
> > Indeed. I don't think BIPs should be representing community consensus or 
> recommendations. But perhaps they can document individual pieces of 
> evidence of acceptance; see further?
>
> Documenting consensus change activation seems useful if nothing else,
> eg as in BIP 90.
>
> > > * Ever tried to write pseudocode or LaTeX in mediawiki format? It's
> > > more than annoying, believe me.
> > I'd like permitting BIPs to be written in markdown.
>
> This is already permitted, see https://github.com/bitcoin/bips/pull/1504
>
> > Some forms of Status are useful I think, but they ought to reflect the 
> author's intent, not the community's perception. E.g. "Draft", "Proposed", 
> and "Withdrawn" make sense to me for any kind of standard. In Draft stage 
> more substantial changes could be permitted, but would convey the idea 
> isn't yet intended for adoption. Of course, the BIP1 status fields weren't 
> really used, and the BIP2 status fields don't seem to be doing much better. 
> If we assume that BIP3 status fields aren't going to be used either this is 
> all for nought, but perhaps it's still worth trying with a significantly 
> simplified assortment of statuses.
> > 
> > Things like "Active / Final" and "Rejected" relate to community 
> acceptance, and I agree those don't belong in BIPs.
>
> I think "Proposed" is much more related to community acceptance than
> "Active" -- you can reasonably say something is "Active" once a single
> implementation has a released version that actively supports it, for
> example; but describing a standard as "Proposed" seems to be pretty
> clearly trying to achieve so form of community acceptance? Who else
> would you be proposing it to?
>
> I'd look at the lifecycle more as something like:
>
> * Draft: author expects further changes, don't deploy this
> * Proposed: author is hoping for multiple implementations to adopt this;
> author thinks it's complete, but there may be objections and it may
> need to go back to Draft state to resolve those objections
> * Active: one or more implementations have deployed this feature as
> specced. changes will usually be specified in a new proposal/standard.
> acceptable changes might be fixing ambiguities, adding extra rationale
> or test cases, etc.
> * Withdrawn: no current implementations support this, author doesn't
> think it should be adopted, author isn't planning on making further
> changes to it
>
> For comparison, BINANA currently has BINs marked Draft, Active and Info:
> https://github.com/bitcoin-inquisition/binana
>
> (Note that adding a consensus change in inquisition and doing a heretical
> activation of that change on signet would still leave the spec in "Draft"
> -- further changes are expected)
>
> (As far as BIP 2's list goes, I think Deferred should just be Draft;
> Rejected/Obsolete should just be Withdrawn; Final should just be Active;
> and Replaced should either be Withdrawn or Active depending on whether
> the replacement is backwards compatible, accompanied by Superseded-By)
>
> > As far as judging consensus goes, perhaps actual consensus changes are 
> an exception? I feel that for those, an "Accepted" status may actually make 
> sense, because they actually require the ecosystem to have agreement about.
>
> How about BIP 148 or BIP 91? I think it's fair to call both of those
> "Active" and would have been fair to mark them Active sometime in
> April-July 2017 -- that doesn't mean there was necessarily community
> consensus behind them: merely that there was software implementing
> those standards active on the network, and that if someone wanted to do
> something similar but different, that would warrant being a different
> standard. If it had turned out there wasn't consensus behind either
> proposal, and no one was mining a blockchain that those implementations
> would accept, at most that would warrant the author marking the BIPs as
> "Withdrawn" IMO.
>
> The same argument applies to BIP 343 I think. I believe only one
> implementation adopted it [0], and I don't believe any actively maintained
> software implements that BIP as written, but if you did implement it
> you'd continue to track the bitcoin blockchain, so I think it would
> be fair to have marked that BIP as "Active" once it was adopted by an
> implementation, and to have left it marked that way.
>
> [0] "Bitcoin Core-based Taproot Client" which doesn't even seem to exist
> in web.archive.org.
>
> https://github.com/BitcoinActivation/BitcoinTaproot.org/blob/master/taproot.html
>
> If the segwit2x fork had ever had a written spec, I likewise think it
> would have been appropriate for it to be a BIP, perhaps being marked as
> Proposed on 2017-07-01 [1], Active on 2017-07-22 [2], and Withdrawn on
> either 2017-11-08 [3] or 2019-10-09 (when the btc1/bitcoin github repo
> was marked as archived).
>
> [1] https://github.com/btc1/bitcoin/pull/50
> [2] https://github.com/btc1/bitcoin/releases/tag/v1.14.5
> [3] 
> https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-November/000685.html
>
> Cheers,
> aj
>

-- 
2: Type: text/html, Size: 13020 bytes --]

 permalink raw reply	[|nested]
2024-04-04  9:09                       ` Niklas Goegge

  
From: 0xB10C @ 2024-04-04 12:58 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 9752 bytes --]

I support Kanzure, Ruben, Atack, and Murch as new BIP editors. 

Niklas Goegge schrieb am Donnerstag, 4. April 2024 um 11:12:46 UTC+2:

> Hi,
>
> Assuming they are willing, I am supportive of Kanzure, Ruben, Laolu and 
> Murch as BIP editors.
>
> Best
> Niklas
>
> Anthony Towns schrieb am Donnerstag, 4. April 2024 um 06:33:05 UTC+1:
>
>> On Wed, Apr 03, 2024 at 07:44:00PM +0000, Pieter Wuille wrote: 
>> > - Scope: related to technology that supports the bitcoin currency. 
>>
>> > This last one may be controversial, but I feel that some of the 
>> discussion the past months about the process has shown that there is 
>> unclarity/disagreement here, and it would be good to have some guideline 
>> written out here. I think scope will inevitably be somewhat of a grey zone, 
>> but I feel some limits (whether spelled out or not) will exist regardless 
>> (nobody would consider including the HTTP spec in scope for a BIP, I 
>> think?). 
>>
>> > I also don't think scope should be tied to specific technologies (e.g. 
>> it shouldn't just be about on-chain transactions, as e.g. that would 
>> exclude address formats), but if not that, what scoping is useful? And to 
>> me, restricting to technology that supports the bitcoin currency is fairly 
>> clear, reasonable, and avoids a circular definition. As an example, that 
>> would exclude OpenTimestamps from scope (which was suggested in 
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022077.html). 
>> I see that as an unrelated application which happens to make use of the 
>> Bitcoin blockchain, which on itself is one of the technologies that 
>> supports bitcoin - but is an indirection too far to be in scope. 
>>
>> For BINANA I phrased that as "proposals only being rejected if they are 
>> ... unrelated to Bitcoin", on the basis that deciding some BIP/BIN is 
>> dumb and ignoring it wastes a lot less time than arguing about whether 
>> it's a good thing for the monetary properties of Bitcoin (which is what 
>> I'm interested in helping people work on). 
>>
>> For example, would adding script opcodes whose only purpose is to better 
>> support moving BTC to/from sidechains like Liquid or WBTC on Eth, where 
>> they can be used as collateral in market makers for trading other tokens 
>> count as "supporting the bitcoin currency"? This might include such 
>> things like Drivechains (BIP 300, 301), eg. Is such a feature more about 
>> supporting asset trading, or is anything that involves buying/selling 
>> things with Bitcoin count as supporting bitcoin as a currency? 
>>
>> Does it make a difference that a script opcode would be consensus 
>> critical? Another way of allowing trading between BTC and other assets is 
>> the "Taproot Assets" proposal (BIPs PR#1489), which anchor trades between 
>> BTC and tokenized assets on the Bitcoin blockchain, but don't require 
>> consensus changes. If the BIPS repo includes docs on Drivechains, is 
>> excluding proposals about Taproot Assets or RGB or similar that valuable? 
>>
>> Those all seems arguable to me; but why force people to have those 
>> arguments over making up a number and hosting a document in a git repo? 
>>
>> > > * The Comments-URI thing is outdated and everyone seems to ignore it. 
>> > > Comments-Summary is even weirder. 
>> > Agreed. It's unused, and sometimes misinterpreted. I think we should 
>> get rid of it. 
>>
>> For BINANA I added a "Discussion" header where the BIN author can point 
>> to 
>> locations where discussion has/can take place -- it seemed like a useful 
>> thing to have beyond just links in the "rationale", both for researching 
>> background into the proposals development, and as a pointer to somewhere 
>> people can leave additional feedback. I don't think there's much value in 
>> having a dedicated discussion area in the BINANA/BIP repo itself though. 
>>
>> > > * "Informational BIPs do not necessarily represent a Bitcoin 
>> community 
>> > > consensus or recommendation". Aha, does this imply that Standards 
>> > > Track BIPs need to represent a Bitcoin community consensus or 
>> > > recommendation? 
>> > Indeed. I don't think BIPs should be representing community consensus 
>> or recommendations. But perhaps they can document individual pieces of 
>> evidence of acceptance; see further? 
>>
>> Documenting consensus change activation seems useful if nothing else, 
>> eg as in BIP 90. 
>>
>> > > * Ever tried to write pseudocode or LaTeX in mediawiki format? It's 
>> > > more than annoying, believe me. 
>> > I'd like permitting BIPs to be written in markdown. 
>>
>> This is already permitted, see https://github.com/bitcoin/bips/pull/1504 
>>
>> > Some forms of Status are useful I think, but they ought to reflect the 
>> author's intent, not the community's perception. E.g. "Draft", "Proposed", 
>> and "Withdrawn" make sense to me for any kind of standard. In Draft stage 
>> more substantial changes could be permitted, but would convey the idea 
>> isn't yet intended for adoption. Of course, the BIP1 status fields weren't 
>> really used, and the BIP2 status fields don't seem to be doing much better. 
>> If we assume that BIP3 status fields aren't going to be used either this is 
>> all for nought, but perhaps it's still worth trying with a significantly 
>> simplified assortment of statuses. 
>> > 
>> > Things like "Active / Final" and "Rejected" relate to community 
>> acceptance, and I agree those don't belong in BIPs. 
>>
>> I think "Proposed" is much more related to community acceptance than 
>> "Active" -- you can reasonably say something is "Active" once a single 
>> implementation has a released version that actively supports it, for 
>> example; but describing a standard as "Proposed" seems to be pretty 
>> clearly trying to achieve so form of community acceptance? Who else 
>> would you be proposing it to? 
>>
>> I'd look at the lifecycle more as something like: 
>>
>> * Draft: author expects further changes, don't deploy this 
>> * Proposed: author is hoping for multiple implementations to adopt this; 
>> author thinks it's complete, but there may be objections and it may 
>> need to go back to Draft state to resolve those objections 
>> * Active: one or more implementations have deployed this feature as 
>> specced. changes will usually be specified in a new proposal/standard. 
>> acceptable changes might be fixing ambiguities, adding extra rationale 
>> or test cases, etc. 
>> * Withdrawn: no current implementations support this, author doesn't 
>> think it should be adopted, author isn't planning on making further 
>> changes to it 
>>
>> For comparison, BINANA currently has BINs marked Draft, Active and Info: 
>> https://github.com/bitcoin-inquisition/binana 
>>
>> (Note that adding a consensus change in inquisition and doing a heretical 
>> activation of that change on signet would still leave the spec in "Draft" 
>> -- further changes are expected) 
>>
>> (As far as BIP 2's list goes, I think Deferred should just be Draft; 
>> Rejected/Obsolete should just be Withdrawn; Final should just be Active; 
>> and Replaced should either be Withdrawn or Active depending on whether 
>> the replacement is backwards compatible, accompanied by Superseded-By) 
>>
>> > As far as judging consensus goes, perhaps actual consensus changes are 
>> an exception? I feel that for those, an "Accepted" status may actually make 
>> sense, because they actually require the ecosystem to have agreement about. 
>>
>> How about BIP 148 or BIP 91? I think it's fair to call both of those 
>> "Active" and would have been fair to mark them Active sometime in 
>> April-July 2017 -- that doesn't mean there was necessarily community 
>> consensus behind them: merely that there was software implementing 
>> those standards active on the network, and that if someone wanted to do 
>> something similar but different, that would warrant being a different 
>> standard. If it had turned out there wasn't consensus behind either 
>> proposal, and no one was mining a blockchain that those implementations 
>> would accept, at most that would warrant the author marking the BIPs as 
>> "Withdrawn" IMO. 
>>
>> The same argument applies to BIP 343 I think. I believe only one 
>> implementation adopted it [0], and I don't believe any actively 
>> maintained 
>> software implements that BIP as written, but if you did implement it 
>> you'd continue to track the bitcoin blockchain, so I think it would 
>> be fair to have marked that BIP as "Active" once it was adopted by an 
>> implementation, and to have left it marked that way. 
>>
>> [0] "Bitcoin Core-based Taproot Client" which doesn't even seem to exist 
>> in web.archive.org. 
>>
>> https://github.com/BitcoinActivation/BitcoinTaproot.org/blob/master/taproot.html 
>>
>> If the segwit2x fork had ever had a written spec, I likewise think it 
>> would have been appropriate for it to be a BIP, perhaps being marked as 
>> Proposed on 2017-07-01 [1], Active on 2017-07-22 [2], and Withdrawn on 
>> either 2017-11-08 [3] or 2019-10-09 (when the btc1/bitcoin github repo 
>> was marked as archived). 
>>
>> [1] https://github.com/btc1/bitcoin/pull/50 
>> [2] https://github.com/btc1/bitcoin/releases/tag/v1.14.5 
>> [3] 
>> https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-November/000685.html 
>>
>> Cheers, 
>> aj 
>>
>

-- 
2: Type: text/html, Size: 13355 bytes --]

 permalink raw reply	[|nested]
2024-02-27 18:53 [bitcoindev] Adding New BIP Editors 'Ava Chow' via Bitcoin Development Mailing List
                   ` (4 preceding siblings ...)
  2024-03-09 10:46 ` Michael Folkson

  
From: Larry Ruane @ 2024-04-05 19:18 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 1748 bytes --]

I support Atack and Murch as BIP editors. I know both personally; I don't 
know Kanzure, Ruben, or Roasbeef, but from my general impression and what I 
read here, they would be good choices too.

I'll mention some reasons for support for Jon Atack.

   - He's neutral and independent; he does not align himself with factions
   - He's written many excellent PR review comments, demonstrating good 
   writing skills. Being a BIP editor doesn't involve (much) writing, but good 
   writing skill allows one to evaluate others' writing
   - His articles on https://jonatack.github.io/articles have been helpful 
   to me; he's contributed to Optech and PR Review Club
   - He's been highly committed to bitcoin and bitcoin core for many years, 
   even living the bitcoin life in El Salvador
   - He has many relationships in the bitcoin community and seems to get 
   along well with everyone

My reasons for supporting Murch can be briefer because he's so well-known, 
and I agree with what others have written.

   - He's contributed to bitcoin and core in myriad ways, too many to 
   mention
   - Many of his contributions have revolved around writing (Optech, 
   StackExchange, conference presentations)
   - He has a good "big picture" view of all of the bitcoin ecosystem while 
   simultaneously having a deep technical understanding of several areas

-- 
2: Type: text/html, Size: 2075 bytes --]

 permalink raw reply	[|nested]
2024-03-31 16:01                           ` Michael Folkson
  2024-04-01 20:14                             ` Antoine Riard

  
From: Ali Sherief @ 2024-04-07 10:11 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 16323 bytes --]

> 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 
better to keep the main repository of BIPs in english, and then have a 
translations subdirectory for each language. Then you can have the BIPs 
translated on a volunteer basis, either 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 easier to collaboratively review drafts like BIP322.
---
Ali

On Sunday, March 31, 2024 at 4:24:57 PM 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 
> 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-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.
>
> 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 
> it's an administrative task (i.e "assigning numbers") or 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 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
>
> 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't
> demonstrated a strong understanding of how Bitcoin works.
>
> > 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.
>
> 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 PM Antoine Riard <antoin...@gmail•com> wrote:
> >
> > 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 <michael...@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 <antoin...@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+...@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
>
>
>
> -- 
> Michael Folkson
> Personal email: michael...@gmail•com
>

-- 
2: Type: text/html, Size: 20860 bytes --]

 permalink raw reply	[|nested]
2024-04-02 14:24                     ` nvk

  2024-04-15 17:50                         ` Matt Corallo
  2024-04-16 17:08                         ` 'Ava Chow' via Bitcoin Development Mailing List
  
From: Sergi Delgado Segura @ 2024-04-11 14:22 UTC (permalink / raw)
  To: nvk;  Bitcoin Development Mailing List

[-- Attachment #1: Type: text/plain, Size: 9209 bytes --]

> I would prefer having more (9+?) than less folks on this task, so
personal preferences are easily ignored and overwritten by the group
majority.

I disagree with that, the more doesn't really the better here. Having too
many editors may result in a tragedy of the commons, in which people just
commit to the job because many others do, and they do not end up doing as
much because they expect others to do the it. This does not only make the
process look bad but may burnout the ones that end up doing the job, given
their time commitment ends up being too far from their expectations.

I think being more moderate with the amount of people is better, and gives
us leeway in case the workload ends up being excessive and we need to add
more people (plus discourage people from joining and slacking off).

I think 3 more people should be a good number to start from. I'd personally
vouch for Murch, Kanzure, and Ruben based on their track record in the space

On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> +1 for
> Kanzure
> RubenSomsen
> Seccour
> Jon Atack
> Roasbeef
>
> I would prefer having more (9+?) than less folks on this task, so personal
> preferences are easily ignored and overwritten by the group majority.
>
> BIPs were intended as a means to collect ideas, not enforce ideas.
>
> I'd like to return to that.
>
> - - NVK (temp gmail account)
> -----BEGIN PGP SIGNATURE-----
>
> iQEzBAEBCAAdFiEEmKAukUZni40sZANzHN2toLREzdoFAmYMFPwACgkQHN2toLRE
> zdqjqQgAsCLjBbVF505RJvIo2ZZqjWDjc0kn3pCs2+d9BHJNbd104CHUlb/TlbGL
> +P1yTDTP9IJoDH833SaLlohtVFBUQbWZmBSav/rSi/4ricXg8XXXDoYb+wPgcdSo
> 243qh43kjMzL6gU6f4aslCS1fHVL/LDUHiRdarLekKfPsWWEE1BR+qdk+WUJiEkU
> 09pcZsGG+6osVDP3/oTCkkMH9/vzY+l8zwy8I3rtMByjlhk90t37YUi1dn5vrvhF
> cSFkys+Um15Wnngb8W1yi4i/gfFYvHapn7KA1WaoeivbMtiJVL8XVWQiWf3Uzy+s
> w3Tl+sQ3S69fIajI9StfO60Qe5dSJQ==
> =w5DC
> -----END PGP SIGNATURE-----
>
> On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A. Harding wrote:
>
>> On 2024-03-28 10:04, Matt Corallo wrote:
>> > Please provide justification rather than simply saying "I like Bob!".
>>
>> Using only comments from the mailing list, the following appears to be
>> the candidate list along with the current support. Asterisks denote
>> candidates who indicated their willingness to accept the role.
>>
>> - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris Stewart[3],
>> Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon
>> Black[11],
>> Antoine Riard[12], Murch[13], Antoine Poinsot[15], John Carvalho[16]
>>
>> - Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3], Michael
>> Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>> Carvalho[16]
>>
>> - Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3],
>> /dev/fd0[5][7],
>> Brandon Black[11], Antoine Riard[12], Ava Chow[14], John Carvalho[16]
>>
>> - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris Stewart[3], John
>> C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine
>> Riard[12], Ava Chow[14]
>>
>> - Mark "Murch" Erhardt*, recommended by Michael Folkson[6], Keagan
>> McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine Riard[12],
>> Ava Chow[14]
>>
>> - Michael Folkson*
>>
>> Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for "non-dev
>> triaging", Tonoski proposed himself[18] for "BIP editor", and Antoine
>> Riard[12] proposed Seccour for "decentralized PM".
>>
>> I searched the BIPs repo by commenter to see if any of the above
>> candidates had been especially active there, which is listed below as:
>> total PRs they commented on (number still open/number closed).
>>
>> - 21 (1/20) commenter:kanzure
>> - 3 (2/1) commenter:rubensomsen
>> - 15 (0/15) commenter:jonatack
>> - 18 (2/16) commenter:roasbeef
>> - 10 (6/4) commenter:Murchandamus
>> - 57 (6/51) commenter:michaelfolkson
>>
>> I'll also note that Osuntokun is the only member of the set to have a
>> merged BIP that they co-authored, although I believe there are far-along
>> draft BIPs for both Murch (terminology) and Somsen (Silent Payments). I
>> don't think this should be a requirement, but I do think it demonstrates
>> familiarity with the process.
>>
>> Speaking only for myself, I think all of the candidates above with
>> multiple recommendations from other community participants are fully
>> qualified for the role, so I'll only provide a detailed justification
>> for the person who would be my first pick: Murch is not only a
>> longstanding and broadly liked Bitcoin contributor, but (as Corallo
>> mentioned) he has worked on standardizing terminology through a draft
>> BIP. In addition, he provided an extremely detailed review of all 300
>> pages of a draft of Mastering Bitcoin (3rd edition) and has reviewed
>> drafts of over 200 weekly Optech newsletters, in both cases
>> significantly improving the accuracy and comprehensibility of the
>> documentation. To me, that seems very similar to the work we'd ask him
>> to perform as a BIPs editor and it's something that he's already doing,
>> so I think there's an excellent fit of person to role.
>>
>> -Dave
>>
>> [1]
>> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
>> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>
>> [2]
>> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
>> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>
>> [3]
>> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/
>> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>
>> [4]
>> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/
>> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>
>> [5]
>> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/
>> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>
>> [6]
>> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/
>> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>
>> [7]
>> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/
>> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>
>> [8]
>>
>> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/
>> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>
>> [9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>> <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
>> [10]
>> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/
>> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>
>> [11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>> [12]
>>
>> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/
>> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>
>> [13]
>> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
>> <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>
>> [14]
>> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
>> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>
>> [15]
>>
>> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
>> [16]
>> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/
>> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>
>> [17]
>>
>> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/
>> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
Sergi.

-- 


[-- Attachment #2: Type: text/html, Size: 11454 bytes --]

 permalink raw reply	[|nested]
2024-04-11 14:22                       ` Sergi Delgado Segura

  2024-04-16 12:34                           ` Tim Ruffing
  2024-04-16 17:08                         ` 'Ava Chow' via Bitcoin Development Mailing List
  
From: Matt Corallo @ 2024-04-15 17:50 UTC (permalink / raw)
  To: Sergi Delgado Segura, nvk;  Bitcoin Development Mailing List

Strongly agree with Sergi here,

I'd suggest 2-3 BIP editors who are actually responsible for things is more useful than 5 BIP 
editors where no one is responsible for anything.

Again, I'm not convinced dumping this on more people is useful, folks like Roasbeef are great but 
clearly don't have time to keep up with yet more things, and not sure why folks are on the list here 
who haven't been active on the Bitcoin-dev ML and in BIPs for many years (eg no idea who Seccour is).

Matt

On 4/11/24 10:22 AM, Sergi Delgado Segura wrote:
>  > I would prefer having more (9+?) than less folks on this task, so personal preferences are easily 
> ignored and overwritten by the group majority.
> 
> I disagree with that, the more doesn't really the better here. Having too many editors may result in 
> a tragedy of the commons, in which people just commit to the job because many others do, and they do 
> not end up doing as much because they expect others to do the it. This does not only make the 
> process look bad but may burnout the ones that end up doing the job, given their time commitment 
> ends up being too far from their expectations.
> 
> I think being more moderate with the amount of people is better, and gives us leeway in case the 
> workload ends up being excessive and we need to add more people (plus discourage people from joining 
> and slacking off).
> 
> I think 3 more people should be a good number to start from. I'd personally vouch for Murch, 
> Kanzure, and Ruben based on their track record in the space
> 
> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>> wrote:
> 
> +1 for
> Kanzure
> RubenSomsen
> Seccour
> Jon Atack
> Roasbeef
> 
> I would prefer having more (9+?) than less folks on this task, so personal preferences are
> easily ignored and overwritten by the group majority.
> 
> BIPs were intended as a means to collect ideas, not enforce ideas.
> 
> I'd like to return to that.
> 
> - NVK (temp gmail account)
> 
>     On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A. Harding wrote:
> 
>         On 2024-03-28 10:04, Matt Corallo wrote:
>          > Please provide justification rather than simply saying "I like Bob!".
> 
>         Using only comments from the mailing list, the following appears to be
>         the candidate list along with the current support. Asterisks denote
>         candidates who indicated their willingness to accept the role.
> 
>         - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris Stewart[3],
>         Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon
>         Black[11],
>         Antoine Riard[12], Murch[13], Antoine Poinsot[15], John Carvalho[16]
> 
>         - Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3], Michael
>         Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>         Carvalho[16]
> 
>         - Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3],
>         /dev/fd0[5][7],
>         Brandon Black[11], Antoine Riard[12], Ava Chow[14], John Carvalho[16]
> 
>         - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris Stewart[3], John
>         C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine
>         Riard[12], Ava Chow[14]
> 
>         - Mark "Murch" Erhardt*, recommended by Michael Folkson[6], Keagan
>         McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine Riard[12],
>         Ava Chow[14]
> 
>         - Michael Folkson*
> 
>         Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for "non-dev
>         triaging", Tonoski proposed himself[18] for "BIP editor", and Antoine
>         Riard[12] proposed Seccour for "decentralized PM".
> 
>         I searched the BIPs repo by commenter to see if any of the above
>         candidates had been especially active there, which is listed below as:
>         total PRs they commented on (number still open/number closed).
> 
>         - 21 (1/20) commenter:kanzure
>         - 3 (2/1) commenter:rubensomsen
>         - 15 (0/15) commenter:jonatack
>         - 18 (2/16) commenter:roasbeef
>         - 10 (6/4) commenter:Murchandamus
>         - 57 (6/51) commenter:michaelfolkson
> 
>         I'll also note that Osuntokun is the only member of the set to have a
>         merged BIP that they co-authored, although I believe there are far-along
>         draft BIPs for both Murch (terminology) and Somsen (Silent Payments). I
>         don't think this should be a requirement, but I do think it demonstrates
>         familiarity with the process.
> 
>         Speaking only for myself, I think all of the candidates above with
>         multiple recommendations from other community participants are fully
>         qualified for the role, so I'll only provide a detailed justification
>         for the person who would be my first pick: Murch is not only a
>         longstanding and broadly liked Bitcoin contributor, but (as Corallo
>         mentioned) he has worked on standardizing terminology through a draft
>         BIP. In addition, he provided an extremely detailed review of all 300
>         pages of a draft of Mastering Bitcoin (3rd edition) and has reviewed
>         drafts of over 200 weekly Optech newsletters, in both cases
>         significantly improving the accuracy and comprehensibility of the
>         documentation. To me, that seems very similar to the work we'd ask him
>         to perform as a BIPs editor and it's something that he's already doing,
>         so I think there's an excellent fit of person to role.
> 
>         -Dave
> 
>         [1]
>         https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
>         <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>
>         [2]
>         https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
>         <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>
>         [3]
>         https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/
>         <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>
>         [4]
>         https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/
>         <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>
>         [5]
>         https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/
>         <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>
>         [6]
>         https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/
>         <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>
>         [7]
>         https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/
>         <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>
>         [8]
>         https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/
>         <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>
>         [9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>         <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
>         [10]
>         https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/
>         <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>
>         [11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>         <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>         [12]
>         https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/
>         <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>
>         [13]
>         https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
>         <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>
>         [14]
>         https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
>         <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>
>         [15]
>         https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>
>         [16]
>         https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/
>         <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>
>         [17]
>         https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/
>         <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/>
> 
>     -- 
>     


 permalink raw reply	[|nested]
2024-04-15 17:50                         ` Matt Corallo

  2024-04-16 13:32                             ` NVK
  
From: Tim Ruffing @ 2024-04-16 12:34 UTC (permalink / raw)
  To: Matt Corallo, Sergi Delgado Segura, nvk;  Bitcoin Development Mailing List

I fully agree with Sergi and Matt here. 

(Sorry, this is just a +1 message, but I really don't have anything
meaningful to add to their arguments.)

Tim

On Mon, 2024-04-15 at 13:50 -0400, Matt Corallo wrote:
> Strongly agree with Sergi here,
> 
> I'd suggest 2-3 BIP editors who are actually responsible for things
> is more useful than 5 BIP 
> editors where no one is responsible for anything.
> 
> Again, I'm not convinced dumping this on more people is useful, folks
> like Roasbeef are great but 
> clearly don't have time to keep up with yet more things, and not sure
> why folks are on the list here 
> who haven't been active on the Bitcoin-dev ML and in BIPs for many
> years (eg no idea who Seccour is).
> 
> Matt
> 
> On 4/11/24 10:22 AM, Sergi Delgado Segura wrote:
> >  > I would prefer having more (9+?) than less folks on this task,
> > so personal preferences are easily 
> > ignored and overwritten by the group majority.
> > 
> > I disagree with that, the more doesn't really the better here.
> > Having too many editors may result in 
> > a tragedy of the commons, in which people just commit to the job
> > because many others do, and they do 
> > not end up doing as much because they expect others to do the it.
> > This does not only make the 
> > process look bad but may burnout the ones that end up doing the
> > job, given their time commitment 
> > ends up being too far from their expectations.
> > 
> > I think being more moderate with the amount of people is better,
> > and gives us leeway in case the 
> > workload ends up being excessive and we need to add more people
> > (plus discourage people from joining 
> > and slacking off).
> > 
> > I think 3 more people should be a good number to start from. I'd
> > personally vouch for Murch, 
> > Kanzure, and Ruben based on their track record in the space
> > 
> > On Tue, Apr 2, 2024 at 4:30 PM nvk
> > <rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>> wrote:
> > 
> > +1 for
> > Kanzure
> > RubenSomsen
> > Seccour
> > Jon Atack
> > Roasbeef
> > 
> > I would prefer having more (9+?) than less folks on this task, so
> > personal preferences are
> > easily ignored and overwritten by the group majority.
> > 
> > BIPs were intended as a means to collect ideas, not enforce ideas.
> > 
> > I'd like to return to that.
> > 
> > - NVK (temp gmail account)
> > 
> >     On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A. Harding
> > wrote:
> > 
> >         On 2024-03-28 10:04, Matt Corallo wrote:
> >          > Please provide justification rather than simply saying
> > "I like Bob!".
> > 
> >         Using only comments from the mailing list, the following
> > appears to be
> >         the candidate list along with the current support.
> > Asterisks denote
> >         candidates who indicated their willingness to accept the
> > role.
> > 
> >         - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris
> > Stewart[3],
> >         Michael Folkson[6], Peter Todd[9], Matt Corallo[10],
> > Brandon
> >         Black[11],
> >         Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
> > Carvalho[16]
> > 
> >         - Ruben Somsen, recommended by Ava Chow[1], Chris
> > Stewart[3], Michael
> >         Folkson[6], Antoine Riard[12], Murch[13], Antoine
> > Poinsot[15], John
> >         Carvalho[16]
> > 
> >         - Jon Atack*, recommended by Luke Dashjr[2], Chris
> > Stewart[3],
> >         /dev/fd0[5][7],
> >         Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
> > Carvalho[16]
> > 
> >         - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
> > Stewart[3], John
> >         C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8],
> > Antoine
> >         Riard[12], Ava Chow[14]
> > 
> >         - Mark "Murch" Erhardt*, recommended by Michael Folkson[6],
> > Keagan
> >         McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine
> > Riard[12],
> >         Ava Chow[14]
> > 
> >         - Michael Folkson*
> > 
> >         Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for
> > "non-dev
> >         triaging", Tonoski proposed himself[18] for "BIP editor",
> > and Antoine
> >         Riard[12] proposed Seccour for "decentralized PM".
> > 
> >         I searched the BIPs repo by commenter to see if any of the
> > above
> >         candidates had been especially active there, which is
> > listed below as:
> >         total PRs they commented on (number still open/number
> > closed).
> > 
> >         - 21 (1/20) commenter:kanzure
> >         - 3 (2/1) commenter:rubensomsen
> >         - 15 (0/15) commenter:jonatack
> >         - 18 (2/16) commenter:roasbeef
> >         - 10 (6/4) commenter:Murchandamus
> >         - 57 (6/51) commenter:michaelfolkson
> > 
> >         I'll also note that Osuntokun is the only member of the set
> > to have a
> >         merged BIP that they co-authored, although I believe there
> > are far-along
> >         draft BIPs for both Murch (terminology) and Somsen (Silent
> > Payments). I
> >         don't think this should be a requirement, but I do think it
> > demonstrates
> >         familiarity with the process.
> > 
> >         Speaking only for myself, I think all of the candidates
> > above with
> >         multiple recommendations from other community participants
> > are fully
> >         qualified for the role, so I'll only provide a detailed
> > justification
> >         for the person who would be my first pick: Murch is not
> > only a
> >         longstanding and broadly liked Bitcoin contributor, but (as
> > Corallo
> >         mentioned) he has worked on standardizing terminology
> > through a draft
> >         BIP. In addition, he provided an extremely detailed review
> > of all 300
> >         pages of a draft of Mastering Bitcoin (3rd edition) and has
> > reviewed
> >         drafts of over 200 weekly Optech newsletters, in both cases
> >         significantly improving the accuracy and comprehensibility
> > of the
> >         documentation. To me, that seems very similar to the work
> > we'd ask him
> >         to perform as a BIPs editor and it's something that he's
> > already doing,
> >         so I think there's an excellent fit of person to role.
> > 
> >         -Dave
> > 
> >         [1]
> >        
> > https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
> >        
> > <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d979275
> > 51e@achow101•com/>
> >         [2]
> >        
> > https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
> >        
> > <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a6
> > 2a3@dashjr•org/>
> >         [3]
> >        
> > https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/
> >        
> > <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f12
> > 9a2n@googlegroups•com/>
> >         [4]
> >        
> > https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/
> >        
> > <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b
> > 713@netpurgatory•com/>
> >         [5]
> >        
> > https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/
> >        
> > <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157
> > fabn@googlegroups•com/>
> >         [6]
> >        
> > https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/
> >        
> > <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d
> > 006n@googlegroups•com/>
> >         [7]
> >        
> > https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/
> >        
> > <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efb
> > ea1n@googlegroups•com/>
> >         [8]
> >        
> > https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/
> >        
> > <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgL
> > EazRA5nVw9siYCPj4A@mail•gmail.com/>
> >         [9]
> > https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> >        
> > <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
> >         [10]
> >        
> > https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/
> >        
> > <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9
> > bf2@mattcorallo•com/>
> >         [11]
> > https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >        
> > <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
> >         [12]
> >        
> > https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/
> >        
> > <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEb
> > HSKSXpq0VKVBhJLhrw@mail•gmail.com/>
> >         [13]
> >        
> > https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
> >        
> > <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e
> > 778@murch•one/>
> >         [14]
> >        
> > https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
> >        
> > <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0
> > 644@achow101•com/>
> >         [15]
> >        
> > https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> >  <
> > https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> > >
> >         [16]
> >        
> > https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/
> >        
> > <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340
> > 661n@googlegroups•com/>
> >         [17]
> >        
> > https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/
> >        
> > <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd
> > 9Qrst+nmyypaedYZgg@mail•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 <mailto:bitcoindev+unsubscribe@googlegroups•com
> > >.
> >     To view this discussion on the web visit
> >    
> > https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com
> >  <
> > https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer
> > >.
> > 
> > 
> > 
> > -- 
> > Sergi.
> > 
> > -- 
> > 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 <mailto:
> > bitcoindev+unsubscribe@googlegroups•com>.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com
> >  <
> > https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer
> > >.
> 

-- 



 permalink raw reply	[|nested]
2024-04-16 12:34                           ` Tim Ruffing

  
From: NVK @ 2024-04-16 13:32 UTC (permalink / raw)
  To: Tim Ruffing
  Cc: Matt Corallo, Sergi Delgado Segura, nvk,
	Bitcoin Development Mailing List

I understand the skepticism with more people. I was also skeptical about having larger committees, but after doing working on the open stats board which is 9 people and it being extremely efficient and practical I've changed my outlook on the numbers.

What do you do gain is more people to be available to review applications. Which is often the bottleneck. I doubt there would be much contention on the opinions of the group.

Just my two 2 cents.

(mobile)

> On Apr 16, 2024, at 08:16, Tim Ruffing <crypto@timruffing•de> wrote:
> 
> ﻿I fully agree with Sergi and Matt here. 
> 
> (Sorry, this is just a +1 message, but I really don't have anything
> meaningful to add to their arguments.)
> 
> Tim
> 
>> On Mon, 2024-04-15 at 13:50 -0400, Matt Corallo wrote:
>> Strongly agree with Sergi here,
>> 
>> I'd suggest 2-3 BIP editors who are actually responsible for things
>> is more useful than 5 BIP
>> editors where no one is responsible for anything.
>> 
>> Again, I'm not convinced dumping this on more people is useful, folks
>> like Roasbeef are great but
>> clearly don't have time to keep up with yet more things, and not sure
>> why folks are on the list here
>> who haven't been active on the Bitcoin-dev ML and in BIPs for many
>> years (eg no idea who Seccour is).
>> 
>> Matt
>> 
>>> On 4/11/24 10:22 AM, Sergi Delgado Segura wrote:
>>>  > I would prefer having more (9+?) than less folks on this task,
>>> so personal preferences are easily
>>> ignored and overwritten by the group majority.
>>> 
>>> I disagree with that, the more doesn't really the better here.
>>> Having too many editors may result in
>>> a tragedy of the commons, in which people just commit to the job
>>> because many others do, and they do
>>> not end up doing as much because they expect others to do the it.
>>> This does not only make the
>>> process look bad but may burnout the ones that end up doing the
>>> job, given their time commitment
>>> ends up being too far from their expectations.
>>> 
>>> I think being more moderate with the amount of people is better,
>>> and gives us leeway in case the
>>> workload ends up being excessive and we need to add more people
>>> (plus discourage people from joining
>>> and slacking off).
>>> 
>>> I think 3 more people should be a good number to start from. I'd
>>> personally vouch for Murch,
>>> Kanzure, and Ruben based on their track record in the space
>>> 
>>> On Tue, Apr 2, 2024 at 4:30 PM nvk
>>> <rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>> wrote:
>>> 
>>> +1 for
>>> Kanzure
>>> RubenSomsen
>>> Seccour
>>> Jon Atack
>>> Roasbeef
>>> 
>>> I would prefer having more (9+?) than less folks on this task, so
>>> personal preferences are
>>> easily ignored and overwritten by the group majority.
>>> 
>>> BIPs were intended as a means to collect ideas, not enforce ideas.
>>> 
>>> I'd like to return to that.
>>> 
>>> - NVK (temp gmail account)
>>> 
>>>     On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A. Harding
>>> wrote:
>>> 
>>>>         On 2024-03-28 10:04, Matt Corallo wrote:
>>>          > Please provide justification rather than simply saying
>>> "I like Bob!".
>>> 
>>>         Using only comments from the mailing list, the following
>>> appears to be
>>>         the candidate list along with the current support.
>>> Asterisks denote
>>>         candidates who indicated their willingness to accept the
>>> role.
>>> 
>>>         - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris
>>> Stewart[3],
>>>         Michael Folkson[6], Peter Todd[9], Matt Corallo[10],
>>> Brandon
>>>         Black[11],
>>>         Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>>> Carvalho[16]
>>> 
>>>         - Ruben Somsen, recommended by Ava Chow[1], Chris
>>> Stewart[3], Michael
>>>         Folkson[6], Antoine Riard[12], Murch[13], Antoine
>>> Poinsot[15], John
>>>         Carvalho[16]
>>> 
>>>         - Jon Atack*, recommended by Luke Dashjr[2], Chris
>>> Stewart[3],
>>>         /dev/fd0[5][7],
>>>         Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
>>> Carvalho[16]
>>> 
>>>         - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
>>> Stewart[3], John
>>>         C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8],
>>> Antoine
>>>         Riard[12], Ava Chow[14]
>>> 
>>>         - Mark "Murch" Erhardt*, recommended by Michael Folkson[6],
>>> Keagan
>>>         McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine
>>> Riard[12],
>>>         Ava Chow[14]
>>> 
>>>         - Michael Folkson*
>>> 
>>>         Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for
>>> "non-dev
>>>         triaging", Tonoski proposed himself[18] for "BIP editor",
>>> and Antoine
>>>         Riard[12] proposed Seccour for "decentralized PM".
>>> 
>>>         I searched the BIPs repo by commenter to see if any of the
>>> above
>>>         candidates had been especially active there, which is
>>> listed below as:
>>>         total PRs they commented on (number still open/number
>>> closed).
>>> 
>>>         - 21 (1/20) commenter:kanzure
>>>         - 3 (2/1) commenter:rubensomsen
>>>         - 15 (0/15) commenter:jonatack
>>>         - 18 (2/16) commenter:roasbeef
>>>         - 10 (6/4) commenter:Murchandamus
>>>         - 57 (6/51) commenter:michaelfolkson
>>> 
>>>         I'll also note that Osuntokun is the only member of the set
>>> to have a
>>>         merged BIP that they co-authored, although I believe there
>>> are far-along
>>>         draft BIPs for both Murch (terminology) and Somsen (Silent
>>> Payments). I
>>>         don't think this should be a requirement, but I do think it
>>> demonstrates
>>>         familiarity with the process.
>>> 
>>>         Speaking only for myself, I think all of the candidates
>>> above with
>>>         multiple recommendations from other community participants
>>> are fully
>>>         qualified for the role, so I'll only provide a detailed
>>> justification
>>>         for the person who would be my first pick: Murch is not
>>> only a
>>>         longstanding and broadly liked Bitcoin contributor, but (as
>>> Corallo
>>>         mentioned) he has worked on standardizing terminology
>>> through a draft
>>>         BIP. In addition, he provided an extremely detailed review
>>> of all 300
>>>         pages of a draft of Mastering Bitcoin (3rd edition) and has
>>> reviewed
>>>         drafts of over 200 weekly Optech newsletters, in both cases
>>>         significantly improving the accuracy and comprehensibility
>>> of the
>>>         documentation. To me, that seems very similar to the work
>>> we'd ask him
>>>         to perform as a BIPs editor and it's something that he's
>>> already doing,
>>>         so I think there's an excellent fit of person to role.
>>> 
>>>         -Dave
>>> 
>>>         [1]
>>>        
>>> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
>>>        
>>> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d979275
>>> 51e@achow101•com/>
>>>         [2]
>>>        
>>> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
>>>        
>>> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a6
>>> 2a3@dashjr•org/>
>>>         [3]
>>>        
>>> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/
>>>        
>>> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f12
>>> 9a2n@googlegroups•com/>
>>>         [4]
>>>        
>>> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/
>>>        
>>> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b
>>> 713@netpurgatory•com/>
>>>         [5]
>>>        
>>> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/
>>>        
>>> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157
>>> fabn@googlegroups•com/>
>>>         [6]
>>>        
>>> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/
>>>        
>>> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d
>>> 006n@googlegroups•com/>
>>>         [7]
>>>        
>>> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/
>>>        
>>> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efb
>>> ea1n@googlegroups•com/>
>>>         [8]
>>>        
>>> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/
>>>        
>>> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgL
>>> EazRA5nVw9siYCPj4A@mail•gmail.com/>
>>>         [9]
>>> https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>>>        
>>> <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
>>>         [10]
>>>        
>>> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/
>>>        
>>> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9
>>> bf2@mattcorallo•com/>
>>>         [11]
>>> https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>>>        
>>> <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>>>         [12]
>>>        
>>> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/
>>>        
>>> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEb
>>> HSKSXpq0VKVBhJLhrw@mail•gmail.com/>
>>>         [13]
>>>        
>>> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
>>>        
>>> <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e
>>> 778@murch•one/>
>>>         [14]
>>>        
>>> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
>>>        
>>> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0
>>> 644@achow101•com/>
>>>         [15]
>>>        
>>> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
>>>  <
>>> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
>>>> 
>>>         [16]
>>>        
>>> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/
>>>        
>>> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340
>>> 661n@googlegroups•com/>
>>>         [17]
>>>        
>>> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/
>>>        
>>> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd
>>> 9Qrst+nmyypaedYZgg@mail•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 <mailto:bitcoindev+unsubscribe@googlegroups•com
>>>> .
>>>     To view this discussion on the web visit
>>>    
>>> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com
>>>  <
>>> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer
>>>> .
>>> 
>>> 
>>> 
>>> --
>>> Sergi.
>>> 
>>> --
>>> 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 <mailto:
>>> bitcoindev+unsubscribe@googlegroups•com>.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com
>>>  <
>>> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer
>>>> .
>> 
> 
> --
> 


 permalink raw reply	[|nested]
2024-04-11 14:22                       ` Sergi Delgado Segura
  2024-04-15 17:50                         ` Matt Corallo

  2024-04-17 23:58                           ` 'nsvrn' via Bitcoin Development Mailing List
                                             ` (2 more replies)
  
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2024-04-16 17:08 UTC (permalink / raw)
  To: bitcoindev

While I don't disagree that 5 or 6 people seems like a lot to add at 
once, it's not clear to me how we should decide which subset of the 
nominees should be added. As it is now, I have only seen an actual 
objection to Kanzure and Ruben from /dev/fd0, and no explicit objections 
to anyone else. It seems like the vast majority of people don't share 
their concerns either as both Kanzure and Ruben continue to be endorsed 
by many others.

Looking at the endorsements each candidate has received, the current 
counts are:
* Kanzure - 17 for, 1 against
* Murch - 13 for
* Jonatack - 13 for
* Ruben - 12 for, 1 against
* Roasbeef - 9 for
* Michael Folkson - none

However, I don't want this process to become a popularity contest and 
require some kind of formal voting. Rather I'd prefer that this process 
be something more like how Bitcoin Core maintainers are added - by 
achieving rough consensus. Without any explicit objections to any of 
these candidates, I'm inclined to move forward with adding the 5 who 
have received endorsements. Having to pick "winners" from this list 
seems like a quick way to stir up drama that I don't think anyone really 
wants to deal with.

I do want to note that neither Kanzure, Ruben, nor Roasbeef have posted 
on this list that they are willing to be BIP editors. I have reached out 
to all 3 of them privately, and received responses from Kanzure and 
Ruben that indicate that they probably are willing, but public 
confirmation from them on this list would also be nice. I have not 
received a response from Roasbeef.

Ava

On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
>  > I would prefer having more (9+?) than less folks on this task, so 
> personal preferences are easily ignored and overwritten by the group 
> majority.
> 
> I disagree with that, the more doesn't really the better here. Having 
> too many editors may result in a tragedy of the commons, in which people 
> just commit to the job because many others do, and they do not end up 
> doing as much because they expect others to do the it. This does not 
> only make the process look bad but may burnout the ones that end up 
> doing the job, given their time commitment ends up being too far from 
> their expectations.
> 
> I think being more moderate with the amount of people is better, and 
> gives us leeway in case the workload ends up being excessive and we need 
> to add more people (plus discourage people from joining and slacking off).
> 
> I think 3 more people should be a good number to start from. 
> I'd personally vouch for Murch, Kanzure, and Ruben based on their track 
> record in the space
> 
> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com 
> <mailto:rdlfnvk@gmail•com>> wrote:
> 
> +1 for
> Kanzure
> RubenSomsen
> Seccour
> Jon Atack
> Roasbeef
> 
> I would prefer having more (9+?) than less folks on this task, so
> personal preferences are easily ignored and overwritten by the group
> majority.
> 
> BIPs were intended as a means to collect ideas, not enforce ideas.
> 
> I'd like to return to that.
> 
> - NVK (temp gmail account)
> 
>     On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A. Harding wrote:
> 
>         On 2024-03-28 10:04, Matt Corallo wrote:
>          > Please provide justification rather than simply saying "I
>         like Bob!".
> 
>         Using only comments from the mailing list, the following appears
>         to be
>         the candidate list along with the current support. Asterisks denote
>         candidates who indicated their willingness to accept the role.
> 
>         - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris
>         Stewart[3],
>         Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon
>         Black[11],
>         Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>         Carvalho[16]
> 
>         - Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3],
>         Michael
>         Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>         Carvalho[16]
> 
>         - Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3],
>         /dev/fd0[5][7],
>         Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
>         Carvalho[16]
> 
>         - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
>         Stewart[3], John
>         C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine
>         Riard[12], Ava Chow[14]
> 
>         - Mark "Murch" Erhardt*, recommended by Michael Folkson[6], Keagan
>         McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine
>         Riard[12],
>         Ava Chow[14]
> 
>         - Michael Folkson*
> 
>         Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for
>         "non-dev
>         triaging", Tonoski proposed himself[18] for "BIP editor", and
>         Antoine
>         Riard[12] proposed Seccour for "decentralized PM".
> 
>         I searched the BIPs repo by commenter to see if any of the above
>         candidates had been especially active there, which is listed
>         below as:
>         total PRs they commented on (number still open/number closed).
> 
>         - 21 (1/20) commenter:kanzure
>         - 3 (2/1) commenter:rubensomsen
>         - 15 (0/15) commenter:jonatack
>         - 18 (2/16) commenter:roasbeef
>         - 10 (6/4) commenter:Murchandamus
>         - 57 (6/51) commenter:michaelfolkson
> 
>         I'll also note that Osuntokun is the only member of the set to
>         have a
>         merged BIP that they co-authored, although I believe there are
>         far-along
>         draft BIPs for both Murch (terminology) and Somsen (Silent
>         Payments). I
>         don't think this should be a requirement, but I do think it
>         demonstrates
>         familiarity with the process.
> 
>         Speaking only for myself, I think all of the candidates above with
>         multiple recommendations from other community participants are
>         fully
>         qualified for the role, so I'll only provide a detailed
>         justification
>         for the person who would be my first pick: Murch is not only a
>         longstanding and broadly liked Bitcoin contributor, but (as Corallo
>         mentioned) he has worked on standardizing terminology through a
>         draft
>         BIP. In addition, he provided an extremely detailed review of
>         all 300
>         pages of a draft of Mastering Bitcoin (3rd edition) and has
>         reviewed
>         drafts of over 200 weekly Optech newsletters, in both cases
>         significantly improving the accuracy and comprehensibility of the
>         documentation. To me, that seems very similar to the work we'd
>         ask him
>         to perform as a BIPs editor and it's something that he's already
>         doing,
>         so I think there's an excellent fit of person to role.
> 
>         -Dave
> 
>         [1]
>         https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>
>         [2]
>         https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>
>         [3]
>         https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>
>         [4]
>         https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>
>         [5]
>         https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>
>         [6]
>         https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>
>         [7]
>         https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>
>         [8]
>         https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>
>         [9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>         <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
>         [10]
>         https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>
>         [11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>         <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>         [12]
>         https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>
>         [13]
>         https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>
>         [14]
>         https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>
>         [15]
>         https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>
>         [16]
>         https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>
>         [17]
>         https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
>     <mailto:bitcoindev+unsubscribe@googlegroups•com>.
>     To view this discussion on the web visit
>     https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>.
> 
> 
> 
> -- 
> Sergi.
> 
> -- 
> 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 
> <mailto:bitcoindev+unsubscribe@googlegroups•com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer>.

-- 



 permalink raw reply	[|nested]
2024-04-11 14:22                       ` Sergi Delgado Segura
  2024-04-15 17:50                         ` Matt Corallo

  2024-04-17 23:58                           ` 
                                             ` 
  
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2024-04-16 17:08 UTC (permalink / raw)
  To: bitcoindev

While I don't disagree that 5 or 6 people seems like a lot to add at 
once, it's not clear to me how we should decide which subset of the 
nominees should be added. As it is now, I have only seen an actual 
objection to Kanzure and Ruben from /dev/fd0, and no explicit objections 
to anyone else. It seems like the vast majority of people don't share 
their concerns either as both Kanzure and Ruben continue to be endorsed 
by many others.

Looking at the endorsements each candidate has received, the current 
counts are:
* Kanzure - 17 for, 1 against
* Murch - 13 for
* Jonatack - 13 for
* Ruben - 12 for, 1 against
* Roasbeef - 9 for
* Michael Folkson - none

However, I don't want this process to become a popularity contest and 
require some kind of formal voting. Rather I'd prefer that this process 
be something more like how Bitcoin Core maintainers are added - by 
achieving rough consensus. Without any explicit objections to any of 
these candidates, I'm inclined to move forward with adding the 5 who 
have received endorsements. Having to pick "winners" from this list 
seems like a quick way to stir up drama that I don't think anyone really 
wants to deal with.

I do want to note that neither Kanzure, Ruben, nor Roasbeef have posted 
on this list that they are willing to be BIP editors. I have reached out 
to all 3 of them privately, and received responses from Kanzure and 
Ruben that indicate that they probably are willing, but public 
confirmation from them on this list would also be nice. I have not 
received a response from Roasbeef.

Ava

On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
>  > I would prefer having more (9+?) than less folks on this task, so 
> personal preferences are easily ignored and overwritten by the group 
> majority.
> 
> I disagree with that, the more doesn't really the better here. Having 
> too many editors may result in a tragedy of the commons, in which people 
> just commit to the job because many others do, and they do not end up 
> doing as much because they expect others to do the it. This does not 
> only make the process look bad but may burnout the ones that end up 
> doing the job, given their time commitment ends up being too far from 
> their expectations.
> 
> I think being more moderate with the amount of people is better, and 
> gives us leeway in case the workload ends up being excessive and we need 
> to add more people (plus discourage people from joining and slacking off).
> 
> I think 3 more people should be a good number to start from. 
> I'd personally vouch for Murch, Kanzure, and Ruben based on their track 
> record in the space
> 
> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com 
> <mailto:rdlfnvk@gmail•com>> wrote:
> 
> +1 for
> Kanzure
> RubenSomsen
> Seccour
> Jon Atack
> Roasbeef
> 
> I would prefer having more (9+?) than less folks on this task, so
> personal preferences are easily ignored and overwritten by the group
> majority.
> 
> BIPs were intended as a means to collect ideas, not enforce ideas.
> 
> I'd like to return to that.
> 
> - NVK (temp gmail account)
> 
>     On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A. Harding wrote:
> 
>         On 2024-03-28 10:04, Matt Corallo wrote:
>          > Please provide justification rather than simply saying "I
>         like Bob!".
> 
>         Using only comments from the mailing list, the following appears
>         to be
>         the candidate list along with the current support. Asterisks denote
>         candidates who indicated their willingness to accept the role.
> 
>         - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris
>         Stewart[3],
>         Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon
>         Black[11],
>         Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>         Carvalho[16]
> 
>         - Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3],
>         Michael
>         Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>         Carvalho[16]
> 
>         - Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3],
>         /dev/fd0[5][7],
>         Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
>         Carvalho[16]
> 
>         - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
>         Stewart[3], John
>         C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine
>         Riard[12], Ava Chow[14]
> 
>         - Mark "Murch" Erhardt*, recommended by Michael Folkson[6], Keagan
>         McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine
>         Riard[12],
>         Ava Chow[14]
> 
>         - Michael Folkson*
> 
>         Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for
>         "non-dev
>         triaging", Tonoski proposed himself[18] for "BIP editor", and
>         Antoine
>         Riard[12] proposed Seccour for "decentralized PM".
> 
>         I searched the BIPs repo by commenter to see if any of the above
>         candidates had been especially active there, which is listed
>         below as:
>         total PRs they commented on (number still open/number closed).
> 
>         - 21 (1/20) commenter:kanzure
>         - 3 (2/1) commenter:rubensomsen
>         - 15 (0/15) commenter:jonatack
>         - 18 (2/16) commenter:roasbeef
>         - 10 (6/4) commenter:Murchandamus
>         - 57 (6/51) commenter:michaelfolkson
> 
>         I'll also note that Osuntokun is the only member of the set to
>         have a
>         merged BIP that they co-authored, although I believe there are
>         far-along
>         draft BIPs for both Murch (terminology) and Somsen (Silent
>         Payments). I
>         don't think this should be a requirement, but I do think it
>         demonstrates
>         familiarity with the process.
> 
>         Speaking only for myself, I think all of the candidates above with
>         multiple recommendations from other community participants are
>         fully
>         qualified for the role, so I'll only provide a detailed
>         justification
>         for the person who would be my first pick: Murch is not only a
>         longstanding and broadly liked Bitcoin contributor, but (as Corallo
>         mentioned) he has worked on standardizing terminology through a
>         draft
>         BIP. In addition, he provided an extremely detailed review of
>         all 300
>         pages of a draft of Mastering Bitcoin (3rd edition) and has
>         reviewed
>         drafts of over 200 weekly Optech newsletters, in both cases
>         significantly improving the accuracy and comprehensibility of the
>         documentation. To me, that seems very similar to the work we'd
>         ask him
>         to perform as a BIPs editor and it's something that he's already
>         doing,
>         so I think there's an excellent fit of person to role.
> 
>         -Dave
> 
>         [1]
>         https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>
>         [2]
>         https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>
>         [3]
>         https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>
>         [4]
>         https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>
>         [5]
>         https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>
>         [6]
>         https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>
>         [7]
>         https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>
>         [8]
>         https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>
>         [9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>         <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
>         [10]
>         https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>
>         [11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>         <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>         [12]
>         https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>
>         [13]
>         https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>
>         [14]
>         https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>
>         [15]
>         https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>
>         [16]
>         https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>
>         [17]
>         https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
>     <mailto:bitcoindev+unsubscribe@googlegroups•com>.
>     To view this discussion on the web visit
>     https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>.
> 
> 
> 
> -- 
> Sergi.
> 
> -- 
> 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 
> <mailto:bitcoindev+unsubscribe@googlegroups•com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer>.

-- 



 permalink raw reply	[|nested]
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-20 19:14                           ` 'Ava Chow' via Bitcoin Development Mailing List
  
From: Olaoluwa Osuntokun @ 2024-04-19 22:32 UTC (permalink / raw)
  To: Ava Chow;  bitcoindev

[-- Attachment #1: Type: text/plain, Size: 14201 bytes --]

Hi y'all,

> I have reached out to all 3 of them privately, and received responses from
> Kanzure and Ruben that indicate that they probably are willing, but public
> confirmation from them on this list would also be nice. I have not
> received a response from Roasbeef.

I followed up on this with achow directly and realized that she reached out
to me via a DM on IRC. I haven't lurked on IRC for many many months now (but
this prompted me to lurk once again!), so I missed the original message.

After DM'ing on X back and forth a bit to get some clarity on the proposed
role, I'd be comfortable with being added as one of the (3?) new BIP
editors. I think it's unfortunate that the BIP process has decayed over the
past year or so (particularly with all the new dev activity), so if I can
lend my time to help restore the process, then I'd be happy to do so 🫡.

In terms of load, if I were to be added, given that we'd now have 4 (?)
total BIP editors, I don't envision the load would be concentrated on any
one individual.

-- Laolu


On Tue, Apr 16, 2024 at 10:24 AM 'Ava Chow' via Bitcoin Development Mailing
List <bitcoindev@googlegroups.com> wrote:

> While I don't disagree that 5 or 6 people seems like a lot to add at
> once, it's not clear to me how we should decide which subset of the
> nominees should be added. As it is now, I have only seen an actual
> objection to Kanzure and Ruben from /dev/fd0, and no explicit objections
> to anyone else. It seems like the vast majority of people don't share
> their concerns either as both Kanzure and Ruben continue to be endorsed
> by many others.
>
> Looking at the endorsements each candidate has received, the current
> counts are:
> * Kanzure - 17 for, 1 against
> * Murch - 13 for
> * Jonatack - 13 for
> * Ruben - 12 for, 1 against
> * Roasbeef - 9 for
> * Michael Folkson - none
>
> However, I don't want this process to become a popularity contest and
> require some kind of formal voting. Rather I'd prefer that this process
> be something more like how Bitcoin Core maintainers are added - by
> achieving rough consensus. Without any explicit objections to any of
> these candidates, I'm inclined to move forward with adding the 5 who
> have received endorsements. Having to pick "winners" from this list
> seems like a quick way to stir up drama that I don't think anyone really
> wants to deal with.
>
> I do want to note that neither Kanzure, Ruben, nor Roasbeef have posted
> on this list that they are willing to be BIP editors. I have reached out
> to all 3 of them privately, and received responses from Kanzure and
> Ruben that indicate that they probably are willing, but public
> confirmation from them on this list would also be nice. I have not
> received a response from Roasbeef.
>
> Ava
>
> On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
> >  > I would prefer having more (9+?) than less folks on this task, so
> > personal preferences are easily ignored and overwritten by the group
> > majority.
> >
> > I disagree with that, the more doesn't really the better here. Having
> > too many editors may result in a tragedy of the commons, in which people
> > just commit to the job because many others do, and they do not end up
> > doing as much because they expect others to do the it. This does not
> > only make the process look bad but may burnout the ones that end up
> > doing the job, given their time commitment ends up being too far from
> > their expectations.
> >
> > I think being more moderate with the amount of people is better, and
> > gives us leeway in case the workload ends up being excessive and we need
> > to add more people (plus discourage people from joining and slacking
> off).
> >
> > I think 3 more people should be a good number to start from.
> > I'd personally vouch for Murch, Kanzure, and Ruben based on their track
> > record in the space
> >
> > On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com
> > <mailto:rdlfnvk@gmail•com>> wrote:
> >
> > +1 for
> > Kanzure
> > RubenSomsen
> > Seccour
> > Jon Atack
> > Roasbeef
> >
> > I would prefer having more (9+?) than less folks on this task, so
> > personal preferences are easily ignored and overwritten by the group
> > majority.
> >
> > BIPs were intended as a means to collect ideas, not enforce ideas.
> >
> > I'd like to return to that.
> >
> > - NVK (temp gmail account)
> >
> >     On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A. Harding wrote:
> >
> >         On 2024-03-28 10:04, Matt Corallo wrote:
> >          > Please provide justification rather than simply saying "I
> >         like Bob!".
> >
> >         Using only comments from the mailing list, the following appears
> >         to be
> >         the candidate list along with the current support. Asterisks
> denote
> >         candidates who indicated their willingness to accept the role.
> >
> >         - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris
> >         Stewart[3],
> >         Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon
> >         Black[11],
> >         Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
> >         Carvalho[16]
> >
> >         - Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3],
> >         Michael
> >         Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15],
> John
> >         Carvalho[16]
> >
> >         - Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3],
> >         /dev/fd0[5][7],
> >         Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
> >         Carvalho[16]
> >
> >         - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
> >         Stewart[3], John
> >         C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine
> >         Riard[12], Ava Chow[14]
> >
> >         - Mark "Murch" Erhardt*, recommended by Michael Folkson[6],
> Keagan
> >         McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine
> >         Riard[12],
> >         Ava Chow[14]
> >
> >         - Michael Folkson*
> >
> >         Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for
> >         "non-dev
> >         triaging", Tonoski proposed himself[18] for "BIP editor", and
> >         Antoine
> >         Riard[12] proposed Seccour for "decentralized PM".
> >
> >         I searched the BIPs repo by commenter to see if any of the above
> >         candidates had been especially active there, which is listed
> >         below as:
> >         total PRs they commented on (number still open/number closed).
> >
> >         - 21 (1/20) commenter:kanzure
> >         - 3 (2/1) commenter:rubensomsen
> >         - 15 (0/15) commenter:jonatack
> >         - 18 (2/16) commenter:roasbeef
> >         - 10 (6/4) commenter:Murchandamus
> >         - 57 (6/51) commenter:michaelfolkson
> >
> >         I'll also note that Osuntokun is the only member of the set to
> >         have a
> >         merged BIP that they co-authored, although I believe there are
> >         far-along
> >         draft BIPs for both Murch (terminology) and Somsen (Silent
> >         Payments). I
> >         don't think this should be a requirement, but I do think it
> >         demonstrates
> >         familiarity with the process.
> >
> >         Speaking only for myself, I think all of the candidates above
> with
> >         multiple recommendations from other community participants are
> >         fully
> >         qualified for the role, so I'll only provide a detailed
> >         justification
> >         for the person who would be my first pick: Murch is not only a
> >         longstanding and broadly liked Bitcoin contributor, but (as
> Corallo
> >         mentioned) he has worked on standardizing terminology through a
> >         draft
> >         BIP. In addition, he provided an extremely detailed review of
> >         all 300
> >         pages of a draft of Mastering Bitcoin (3rd edition) and has
> >         reviewed
> >         drafts of over 200 weekly Optech newsletters, in both cases
> >         significantly improving the accuracy and comprehensibility of the
> >         documentation. To me, that seems very similar to the work we'd
> >         ask him
> >         to perform as a BIPs editor and it's something that he's already
> >         doing,
> >         so I think there's an excellent fit of person to role.
> >
> >         -Dave
> >
> >         [1]
> >
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/
> >
> >         [2]
> >
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/
> >
> >         [3]
> >
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/
> >
> >         [4]
> >
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/
> >
> >         [5]
> >
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/
> >
> >         [6]
> >
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/
> >
> >         [7]
> >
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/
> >
> >         [8]
> >
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/
> >
> >         [9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> >         <
> https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
> >         [10]
> >
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/
> >
> >         [11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >         <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
> >         [12]
> >
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/
> >
> >         [13]
> >
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/ <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> >
> >         [14]
> >
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/
> >
> >         [15]
> >
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> >
> >         [16]
> >
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/
> >
> >         [17]
> >
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
> >     <mailto:bitcoindev+unsubscribe@googlegroups•com>.
> >     To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer
> >.
> >
> >
> >
> > --
> > Sergi.
> >
> > --
> > 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
> > <mailto:bitcoindev+unsubscribe@googlegroups•com>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.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/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com
> .
>

-- 


[-- Attachment #2: Type: text/html, Size: 22546 bytes --]

 permalink raw reply	[|nested]
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:48                             ` NVK
                                               ` (5 more replies)
  
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2024-04-20 19:14 UTC (permalink / raw)
  To: bitcoindev

Since we're now past the deadline of April 19th, I'd like to inform 
everyone of what will happen on Monday.

There has not been any actual objections to the nominees nor have there 
been any suggestions on choosing a subset of them since my last email. 
As such, there is rough consensus on adding Kanzure, Murch, Jonatack, 
Ruben, and Roasbeef as BIP editors, and they will be added on Monday 
April 22nd.

Ava

On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development Mailing List 
wrote:
> While I don't disagree that 5 or 6 people seems like a lot to add at
> once, it's not clear to me how we should decide which subset of the
> nominees should be added. As it is now, I have only seen an actual
> objection to Kanzure and Ruben from /dev/fd0, and no explicit objections
> to anyone else. It seems like the vast majority of people don't share
> their concerns either as both Kanzure and Ruben continue to be endorsed
> by many others.
> 
> Looking at the endorsements each candidate has received, the current
> counts are:
> * Kanzure - 17 for, 1 against
> * Murch - 13 for
> * Jonatack - 13 for
> * Ruben - 12 for, 1 against
> * Roasbeef - 9 for
> * Michael Folkson - none
> 
> However, I don't want this process to become a popularity contest and
> require some kind of formal voting. Rather I'd prefer that this process
> be something more like how Bitcoin Core maintainers are added - by
> achieving rough consensus. Without any explicit objections to any of
> these candidates, I'm inclined to move forward with adding the 5 who
> have received endorsements. Having to pick "winners" from this list
> seems like a quick way to stir up drama that I don't think anyone really
> wants to deal with.
> 
> I do want to note that neither Kanzure, Ruben, nor Roasbeef have posted
> on this list that they are willing to be BIP editors. I have reached out
> to all 3 of them privately, and received responses from Kanzure and
> Ruben that indicate that they probably are willing, but public
> confirmation from them on this list would also be nice. I have not
> received a response from Roasbeef.
> 
> Ava
> 
> On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
>>   > I would prefer having more (9+?) than less folks on this task, so
>> personal preferences are easily ignored and overwritten by the group
>> majority.
>>
>> I disagree with that, the more doesn't really the better here. Having
>> too many editors may result in a tragedy of the commons, in which people
>> just commit to the job because many others do, and they do not end up
>> doing as much because they expect others to do the it. This does not
>> only make the process look bad but may burnout the ones that end up
>> doing the job, given their time commitment ends up being too far from
>> their expectations.
>>
>> I think being more moderate with the amount of people is better, and
>> gives us leeway in case the workload ends up being excessive and we need
>> to add more people (plus discourage people from joining and slacking off).
>>
>> I think 3 more people should be a good number to start from.
>> I'd personally vouch for Murch, Kanzure, and Ruben based on their track
>> record in the space
>>
>> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com
>> <mailto:rdlfnvk@gmail•com>> wrote:
>>
>> +1 for
>> Kanzure
>> RubenSomsen
>> Seccour
>> Jon Atack
>> Roasbeef
>>
>> I would prefer having more (9+?) than less folks on this task, so
>> personal preferences are easily ignored and overwritten by the group
>> majority.
>>
>> BIPs were intended as a means to collect ideas, not enforce ideas.
>>
>> I'd like to return to that.
>>
>> - NVK (temp gmail account)
>>
>>      On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A. Harding wrote:
>>
>>          On 2024-03-28 10:04, Matt Corallo wrote:
>>           > Please provide justification rather than simply saying "I
>>          like Bob!".
>>
>>          Using only comments from the mailing list, the following appears
>>          to be
>>          the candidate list along with the current support. Asterisks denote
>>          candidates who indicated their willingness to accept the role.
>>
>>          - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris
>>          Stewart[3],
>>          Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon
>>          Black[11],
>>          Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>>          Carvalho[16]
>>
>>          - Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3],
>>          Michael
>>          Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>>          Carvalho[16]
>>
>>          - Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3],
>>          /dev/fd0[5][7],
>>          Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
>>          Carvalho[16]
>>
>>          - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
>>          Stewart[3], John
>>          C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine
>>          Riard[12], Ava Chow[14]
>>
>>          - Mark "Murch" Erhardt*, recommended by Michael Folkson[6], Keagan
>>          McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine
>>          Riard[12],
>>          Ava Chow[14]
>>
>>          - Michael Folkson*
>>
>>          Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for
>>          "non-dev
>>          triaging", Tonoski proposed himself[18] for "BIP editor", and
>>          Antoine
>>          Riard[12] proposed Seccour for "decentralized PM".
>>
>>          I searched the BIPs repo by commenter to see if any of the above
>>          candidates had been especially active there, which is listed
>>          below as:
>>          total PRs they commented on (number still open/number closed).
>>
>>          - 21 (1/20) commenter:kanzure
>>          - 3 (2/1) commenter:rubensomsen
>>          - 15 (0/15) commenter:jonatack
>>          - 18 (2/16) commenter:roasbeef
>>          - 10 (6/4) commenter:Murchandamus
>>          - 57 (6/51) commenter:michaelfolkson
>>
>>          I'll also note that Osuntokun is the only member of the set to
>>          have a
>>          merged BIP that they co-authored, although I believe there are
>>          far-along
>>          draft BIPs for both Murch (terminology) and Somsen (Silent
>>          Payments). I
>>          don't think this should be a requirement, but I do think it
>>          demonstrates
>>          familiarity with the process.
>>
>>          Speaking only for myself, I think all of the candidates above with
>>          multiple recommendations from other community participants are
>>          fully
>>          qualified for the role, so I'll only provide a detailed
>>          justification
>>          for the person who would be my first pick: Murch is not only a
>>          longstanding and broadly liked Bitcoin contributor, but (as Corallo
>>          mentioned) he has worked on standardizing terminology through a
>>          draft
>>          BIP. In addition, he provided an extremely detailed review of
>>          all 300
>>          pages of a draft of Mastering Bitcoin (3rd edition) and has
>>          reviewed
>>          drafts of over 200 weekly Optech newsletters, in both cases
>>          significantly improving the accuracy and comprehensibility of the
>>          documentation. To me, that seems very similar to the work we'd
>>          ask him
>>          to perform as a BIPs editor and it's something that he's already
>>          doing,
>>          so I think there's an excellent fit of person to role.
>>
>>          -Dave
>>
>>          [1]
>>          https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>
>>          [2]
>>          https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>
>>          [3]
>>          https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>
>>          [4]
>>          https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>
>>          [5]
>>          https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>
>>          [6]
>>          https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>
>>          [7]
>>          https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>
>>          [8]
>>          https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>
>>          [9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>>          <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
>>          [10]
>>          https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>
>>          [11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>>          <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>>          [12]
>>          https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>
>>          [13]
>>          https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>
>>          [14]
>>          https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>
>>          [15]
>>          https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>
>>          [16]
>>          https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>
>>          [17]
>>          https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
>>      <mailto:bitcoindev+unsubscribe@googlegroups•com>.
>>      To view this discussion on the web visit
>>      https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>
>>
>>
>> --
>> Sergi.
>>
>> --
>> 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
>> <mailto:bitcoindev+unsubscribe@googlegroups•com>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> 
> --
> 


 permalink raw reply	[|nested]
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:48                             ` 
                                               ` 
  
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2024-04-20 19:14 UTC (permalink / raw)
  To: bitcoindev

Since we're now past the deadline of April 19th, I'd like to inform 
everyone of what will happen on Monday.

There has not been any actual objections to the nominees nor have there 
been any suggestions on choosing a subset of them since my last email. 
As such, there is rough consensus on adding Kanzure, Murch, Jonatack, 
Ruben, and Roasbeef as BIP editors, and they will be added on Monday 
April 22nd.

Ava

On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development Mailing List 
wrote:
> While I don't disagree that 5 or 6 people seems like a lot to add at
> once, it's not clear to me how we should decide which subset of the
> nominees should be added. As it is now, I have only seen an actual
> objection to Kanzure and Ruben from /dev/fd0, and no explicit objections
> to anyone else. It seems like the vast majority of people don't share
> their concerns either as both Kanzure and Ruben continue to be endorsed
> by many others.
> 
> Looking at the endorsements each candidate has received, the current
> counts are:
> * Kanzure - 17 for, 1 against
> * Murch - 13 for
> * Jonatack - 13 for
> * Ruben - 12 for, 1 against
> * Roasbeef - 9 for
> * Michael Folkson - none
> 
> However, I don't want this process to become a popularity contest and
> require some kind of formal voting. Rather I'd prefer that this process
> be something more like how Bitcoin Core maintainers are added - by
> achieving rough consensus. Without any explicit objections to any of
> these candidates, I'm inclined to move forward with adding the 5 who
> have received endorsements. Having to pick "winners" from this list
> seems like a quick way to stir up drama that I don't think anyone really
> wants to deal with.
> 
> I do want to note that neither Kanzure, Ruben, nor Roasbeef have posted
> on this list that they are willing to be BIP editors. I have reached out
> to all 3 of them privately, and received responses from Kanzure and
> Ruben that indicate that they probably are willing, but public
> confirmation from them on this list would also be nice. I have not
> received a response from Roasbeef.
> 
> Ava
> 
> On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
>>   > I would prefer having more (9+?) than less folks on this task, so
>> personal preferences are easily ignored and overwritten by the group
>> majority.
>>
>> I disagree with that, the more doesn't really the better here. Having
>> too many editors may result in a tragedy of the commons, in which people
>> just commit to the job because many others do, and they do not end up
>> doing as much because they expect others to do the it. This does not
>> only make the process look bad but may burnout the ones that end up
>> doing the job, given their time commitment ends up being too far from
>> their expectations.
>>
>> I think being more moderate with the amount of people is better, and
>> gives us leeway in case the workload ends up being excessive and we need
>> to add more people (plus discourage people from joining and slacking off).
>>
>> I think 3 more people should be a good number to start from.
>> I'd personally vouch for Murch, Kanzure, and Ruben based on their track
>> record in the space
>>
>> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com
>> <mailto:rdlfnvk@gmail•com>> wrote:
>>
>> +1 for
>> Kanzure
>> RubenSomsen
>> Seccour
>> Jon Atack
>> Roasbeef
>>
>> I would prefer having more (9+?) than less folks on this task, so
>> personal preferences are easily ignored and overwritten by the group
>> majority.
>>
>> BIPs were intended as a means to collect ideas, not enforce ideas.
>>
>> I'd like to return to that.
>>
>> - NVK (temp gmail account)
>>
>>      On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A. Harding wrote:
>>
>>          On 2024-03-28 10:04, Matt Corallo wrote:
>>           > Please provide justification rather than simply saying "I
>>          like Bob!".
>>
>>          Using only comments from the mailing list, the following appears
>>          to be
>>          the candidate list along with the current support. Asterisks denote
>>          candidates who indicated their willingness to accept the role.
>>
>>          - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris
>>          Stewart[3],
>>          Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon
>>          Black[11],
>>          Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>>          Carvalho[16]
>>
>>          - Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3],
>>          Michael
>>          Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>>          Carvalho[16]
>>
>>          - Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3],
>>          /dev/fd0[5][7],
>>          Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
>>          Carvalho[16]
>>
>>          - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
>>          Stewart[3], John
>>          C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine
>>          Riard[12], Ava Chow[14]
>>
>>          - Mark "Murch" Erhardt*, recommended by Michael Folkson[6], Keagan
>>          McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine
>>          Riard[12],
>>          Ava Chow[14]
>>
>>          - Michael Folkson*
>>
>>          Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for
>>          "non-dev
>>          triaging", Tonoski proposed himself[18] for "BIP editor", and
>>          Antoine
>>          Riard[12] proposed Seccour for "decentralized PM".
>>
>>          I searched the BIPs repo by commenter to see if any of the above
>>          candidates had been especially active there, which is listed
>>          below as:
>>          total PRs they commented on (number still open/number closed).
>>
>>          - 21 (1/20) commenter:kanzure
>>          - 3 (2/1) commenter:rubensomsen
>>          - 15 (0/15) commenter:jonatack
>>          - 18 (2/16) commenter:roasbeef
>>          - 10 (6/4) commenter:Murchandamus
>>          - 57 (6/51) commenter:michaelfolkson
>>
>>          I'll also note that Osuntokun is the only member of the set to
>>          have a
>>          merged BIP that they co-authored, although I believe there are
>>          far-along
>>          draft BIPs for both Murch (terminology) and Somsen (Silent
>>          Payments). I
>>          don't think this should be a requirement, but I do think it
>>          demonstrates
>>          familiarity with the process.
>>
>>          Speaking only for myself, I think all of the candidates above with
>>          multiple recommendations from other community participants are
>>          fully
>>          qualified for the role, so I'll only provide a detailed
>>          justification
>>          for the person who would be my first pick: Murch is not only a
>>          longstanding and broadly liked Bitcoin contributor, but (as Corallo
>>          mentioned) he has worked on standardizing terminology through a
>>          draft
>>          BIP. In addition, he provided an extremely detailed review of
>>          all 300
>>          pages of a draft of Mastering Bitcoin (3rd edition) and has
>>          reviewed
>>          drafts of over 200 weekly Optech newsletters, in both cases
>>          significantly improving the accuracy and comprehensibility of the
>>          documentation. To me, that seems very similar to the work we'd
>>          ask him
>>          to perform as a BIPs editor and it's something that he's already
>>          doing,
>>          so I think there's an excellent fit of person to role.
>>
>>          -Dave
>>
>>          [1]
>>          https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>
>>          [2]
>>          https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>
>>          [3]
>>          https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>
>>          [4]
>>          https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>
>>          [5]
>>          https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>
>>          [6]
>>          https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>
>>          [7]
>>          https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>
>>          [8]
>>          https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>
>>          [9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>>          <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
>>          [10]
>>          https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>
>>          [11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>>          <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>>          [12]
>>          https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>
>>          [13]
>>          https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>
>>          [14]
>>          https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>
>>          [15]
>>          https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>
>>          [16]
>>          https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>
>>          [17]
>>          https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
>>      <mailto:bitcoindev+unsubscribe@googlegroups•com>.
>>      To view this discussion on the web visit
>>      https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>
>>
>>
>> --
>> Sergi.
>>
>> --
>> 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
>> <mailto:bitcoindev+unsubscribe@googlegroups•com>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> 
> --
> 


 permalink raw reply	[|nested]
* 
  2024-04-20 19:14                           ` 'Ava Chow' via Bitcoin Development Mailing List

  2024-04-20 19:59                             ` 
                                               ` 
  5 siblings, 0 replies; 100+ messages in thread
From: NVK @ 2024-04-20 19:48 UTC (permalink / raw)
  To: Ava Chow;  bitcoindev

Good number of people.

Looking forward and congrats.

> On Apr 20, 2024, at 14:30, 'Ava Chow' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote:
> 
> ﻿Since we're now past the deadline of April 19th, I'd like to inform
> everyone of what will happen on Monday.
> 
> There has not been any actual objections to the nominees nor have there
> been any suggestions on choosing a subset of them since my last email.
> As such, there is rough consensus on adding Kanzure, Murch, Jonatack,
> Ruben, and Roasbeef as BIP editors, and they will be added on Monday
> April 22nd.
> 
> Ava
> 
>> On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development Mailing List
>> wrote:
>> While I don't disagree that 5 or 6 people seems like a lot to add at
>> once, it's not clear to me how we should decide which subset of the
>> nominees should be added. As it is now, I have only seen an actual
>> objection to Kanzure and Ruben from /dev/fd0, and no explicit objections
>> to anyone else. It seems like the vast majority of people don't share
>> their concerns either as both Kanzure and Ruben continue to be endorsed
>> by many others.
>> 
>> Looking at the endorsements each candidate has received, the current
>> counts are:
>> * Kanzure - 17 for, 1 against
>> * Murch - 13 for
>> * Jonatack - 13 for
>> * Ruben - 12 for, 1 against
>> * Roasbeef - 9 for
>> * Michael Folkson - none
>> 
>> However, I don't want this process to become a popularity contest and
>> require some kind of formal voting. Rather I'd prefer that this process
>> be something more like how Bitcoin Core maintainers are added - by
>> achieving rough consensus. Without any explicit objections to any of
>> these candidates, I'm inclined to move forward with adding the 5 who
>> have received endorsements. Having to pick "winners" from this list
>> seems like a quick way to stir up drama that I don't think anyone really
>> wants to deal with.
>> 
>> I do want to note that neither Kanzure, Ruben, nor Roasbeef have posted
>> on this list that they are willing to be BIP editors. I have reached out
>> to all 3 of them privately, and received responses from Kanzure and
>> Ruben that indicate that they probably are willing, but public
>> confirmation from them on this list would also be nice. I have not
>> received a response from Roasbeef.
>> 
>> Ava
>> 
>> On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
>>>> I would prefer having more (9+?) than less folks on this task, so
>>> personal preferences are easily ignored and overwritten by the group
>>> majority.
>>> 
>>> I disagree with that, the more doesn't really the better here. Having
>>> too many editors may result in a tragedy of the commons, in which people
>>> just commit to the job because many others do, and they do not end up
>>> doing as much because they expect others to do the it. This does not
>>> only make the process look bad but may burnout the ones that end up
>>> doing the job, given their time commitment ends up being too far from
>>> their expectations.
>>> 
>>> I think being more moderate with the amount of people is better, and
>>> gives us leeway in case the workload ends up being excessive and we need
>>> to add more people (plus discourage people from joining and slacking off).
>>> 
>>> I think 3 more people should be a good number to start from.
>>> I'd personally vouch for Murch, Kanzure, and Ruben based on their track
>>> record in the space
>>> 
>>> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com
>>> <mailto:rdlfnvk@gmail•com>> wrote:
>>> 
>>> +1 for
>>> Kanzure
>>> RubenSomsen
>>> Seccour
>>> Jon Atack
>>> Roasbeef
>>> 
>>> I would prefer having more (9+?) than less folks on this task, so
>>> personal preferences are easily ignored and overwritten by the group
>>> majority.
>>> 
>>> BIPs were intended as a means to collect ideas, not enforce ideas.
>>> 
>>> I'd like to return to that.
>>> 
>>> - NVK (temp gmail account)
>>> 
>>>>     On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A. Harding wrote:
>>> 
>>>         On 2024-03-28 10:04, Matt Corallo wrote:
>>>> Please provide justification rather than simply saying "I
>>>         like Bob!".
>>> 
>>>         Using only comments from the mailing list, the following appears
>>>         to be
>>>         the candidate list along with the current support. Asterisks denote
>>>         candidates who indicated their willingness to accept the role.
>>> 
>>>         - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris
>>>         Stewart[3],
>>>         Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon
>>>         Black[11],
>>>         Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>>>         Carvalho[16]
>>> 
>>>         - Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3],
>>>         Michael
>>>         Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>>>         Carvalho[16]
>>> 
>>>         - Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3],
>>>         /dev/fd0[5][7],
>>>         Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
>>>         Carvalho[16]
>>> 
>>>         - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
>>>         Stewart[3], John
>>>         C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine
>>>         Riard[12], Ava Chow[14]
>>> 
>>>         - Mark "Murch" Erhardt*, recommended by Michael Folkson[6], Keagan
>>>         McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine
>>>         Riard[12],
>>>         Ava Chow[14]
>>> 
>>>         - Michael Folkson*
>>> 
>>>         Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for
>>>         "non-dev
>>>         triaging", Tonoski proposed himself[18] for "BIP editor", and
>>>         Antoine
>>>         Riard[12] proposed Seccour for "decentralized PM".
>>> 
>>>         I searched the BIPs repo by commenter to see if any of the above
>>>         candidates had been especially active there, which is listed
>>>         below as:
>>>         total PRs they commented on (number still open/number closed).
>>> 
>>>         - 21 (1/20) commenter:kanzure
>>>         - 3 (2/1) commenter:rubensomsen
>>>         - 15 (0/15) commenter:jonatack
>>>         - 18 (2/16) commenter:roasbeef
>>>         - 10 (6/4) commenter:Murchandamus
>>>         - 57 (6/51) commenter:michaelfolkson
>>> 
>>>         I'll also note that Osuntokun is the only member of the set to
>>>         have a
>>>         merged BIP that they co-authored, although I believe there are
>>>         far-along
>>>         draft BIPs for both Murch (terminology) and Somsen (Silent
>>>         Payments). I
>>>         don't think this should be a requirement, but I do think it
>>>         demonstrates
>>>         familiarity with the process.
>>> 
>>>         Speaking only for myself, I think all of the candidates above with
>>>         multiple recommendations from other community participants are
>>>         fully
>>>         qualified for the role, so I'll only provide a detailed
>>>         justification
>>>         for the person who would be my first pick: Murch is not only a
>>>         longstanding and broadly liked Bitcoin contributor, but (as Corallo
>>>         mentioned) he has worked on standardizing terminology through a
>>>         draft
>>>         BIP. In addition, he provided an extremely detailed review of
>>>         all 300
>>>         pages of a draft of Mastering Bitcoin (3rd edition) and has
>>>         reviewed
>>>         drafts of over 200 weekly Optech newsletters, in both cases
>>>         significantly improving the accuracy and comprehensibility of the
>>>         documentation. To me, that seems very similar to the work we'd
>>>         ask him
>>>         to perform as a BIPs editor and it's something that he's already
>>>         doing,
>>>         so I think there's an excellent fit of person to role.
>>> 
>>>         -Dave
>>> 
>>>         [1]
>>>         https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>
>>>         [2]
>>>         https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>
>>>         [3]
>>>         https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>
>>>         [4]
>>>         https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>
>>>         [5]
>>>         https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>
>>>         [6]
>>>         https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>
>>>         [7]
>>>         https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>
>>>         [8]
>>>         https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>
>>>         [9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>>>         <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
>>>         [10]
>>>         https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>
>>>         [11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>>>         <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>>>         [12]
>>>         https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>
>>>         [13]
>>>         https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>
>>>         [14]
>>>         https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>
>>>         [15]
>>>         https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>
>>>         [16]
>>>         https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>
>>>         [17]
>>>         https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
>>>     <mailto:bitcoindev+unsubscribe@googlegroups•com>.
>>>     To view this discussion on the web visit
>>>     https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>> 
>>> 
>>> 
>>> --
>>> Sergi.
>>> 
>>> --
>>> 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
>>> <mailto:bitcoindev+unsubscribe@googlegroups•com>.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>> 
>> --
>> 


^ permalink raw reply	[|nested] 100+ messages in thread
* 
  2024-04-20 19:14                           ` 'Ava Chow' via Bitcoin Development Mailing List
  2024-04-20 19:48                             ` NVK

  2024-04-20 20:59                               ` 'Ava Chow' via Bitcoin Development Mailing List
  2024-04-20 20:46                             ` 
                                               ` 
  5 siblings, 1 reply; 100+ messages in thread
From: Michael Folkson @ 2024-04-20 19:59 UTC (permalink / raw)
  To: Ava Chow, luke;  bitcoindev

Ava

> As such, there is rough consensus on adding Kanzure, Murch, Jonatack,
Ruben, and Roasbeef as BIP editors, and they will be added on Monday
April 22nd.

Is Luke happy with this? That is a lot of new editors to onboard. I
suspect you'd push back against adding 5 maintainers overnight to
Bitcoin Core and I'm not sure why this is any different. What happens
if there is disagreement between these now 6 BIP editors on merge
decisions? If Luke is fine with this ok but it seems like the BIPs
repo is going to be a free for all from now on.

Thanks
Michael

On Sat, Apr 20, 2024 at 8:30 PM 'Ava Chow' via Bitcoin Development
Mailing List <bitcoindev@googlegroups.com> wrote:
>
> Since we're now past the deadline of April 19th, I'd like to inform
> everyone of what will happen on Monday.
>
> There has not been any actual objections to the nominees nor have there
> been any suggestions on choosing a subset of them since my last email.
> As such, there is rough consensus on adding Kanzure, Murch, Jonatack,
> Ruben, and Roasbeef as BIP editors, and they will be added on Monday
> April 22nd.
>
> Ava
>
> On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development Mailing List
> wrote:
> > While I don't disagree that 5 or 6 people seems like a lot to add at
> > once, it's not clear to me how we should decide which subset of the
> > nominees should be added. As it is now, I have only seen an actual
> > objection to Kanzure and Ruben from /dev/fd0, and no explicit objections
> > to anyone else. It seems like the vast majority of people don't share
> > their concerns either as both Kanzure and Ruben continue to be endorsed
> > by many others.
> >
> > Looking at the endorsements each candidate has received, the current
> > counts are:
> > * Kanzure - 17 for, 1 against
> > * Murch - 13 for
> > * Jonatack - 13 for
> > * Ruben - 12 for, 1 against
> > * Roasbeef - 9 for
> > * Michael Folkson - none
> >
> > However, I don't want this process to become a popularity contest and
> > require some kind of formal voting. Rather I'd prefer that this process
> > be something more like how Bitcoin Core maintainers are added - by
> > achieving rough consensus. Without any explicit objections to any of
> > these candidates, I'm inclined to move forward with adding the 5 who
> > have received endorsements. Having to pick "winners" from this list
> > seems like a quick way to stir up drama that I don't think anyone really
> > wants to deal with.
> >
> > I do want to note that neither Kanzure, Ruben, nor Roasbeef have posted
> > on this list that they are willing to be BIP editors. I have reached out
> > to all 3 of them privately, and received responses from Kanzure and
> > Ruben that indicate that they probably are willing, but public
> > confirmation from them on this list would also be nice. I have not
> > received a response from Roasbeef.
> >
> > Ava
> >
> > On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
> >>   > I would prefer having more (9+?) than less folks on this task, so
> >> personal preferences are easily ignored and overwritten by the group
> >> majority.
> >>
> >> I disagree with that, the more doesn't really the better here. Having
> >> too many editors may result in a tragedy of the commons, in which people
> >> just commit to the job because many others do, and they do not end up
> >> doing as much because they expect others to do the it. This does not
> >> only make the process look bad but may burnout the ones that end up
> >> doing the job, given their time commitment ends up being too far from
> >> their expectations.
> >>
> >> I think being more moderate with the amount of people is better, and
> >> gives us leeway in case the workload ends up being excessive and we need
> >> to add more people (plus discourage people from joining and slacking off).
> >>
> >> I think 3 more people should be a good number to start from.
> >> I'd personally vouch for Murch, Kanzure, and Ruben based on their track
> >> record in the space
> >>
> >> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com
> >> <mailto:rdlfnvk@gmail•com>> wrote:
> >>
> >> +1 for
> >> Kanzure
> >> RubenSomsen
> >> Seccour
> >> Jon Atack
> >> Roasbeef
> >>
> >> I would prefer having more (9+?) than less folks on this task, so
> >> personal preferences are easily ignored and overwritten by the group
> >> majority.
> >>
> >> BIPs were intended as a means to collect ideas, not enforce ideas.
> >>
> >> I'd like to return to that.
> >>
> >> - NVK (temp gmail account)
> >>
> >>      On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A. Harding wrote:
> >>
> >>          On 2024-03-28 10:04, Matt Corallo wrote:
> >>           > Please provide justification rather than simply saying "I
> >>          like Bob!".
> >>
> >>          Using only comments from the mailing list, the following appears
> >>          to be
> >>          the candidate list along with the current support. Asterisks denote
> >>          candidates who indicated their willingness to accept the role.
> >>
> >>          - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris
> >>          Stewart[3],
> >>          Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon
> >>          Black[11],
> >>          Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
> >>          Carvalho[16]
> >>
> >>          - Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3],
> >>          Michael
> >>          Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
> >>          Carvalho[16]
> >>
> >>          - Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3],
> >>          /dev/fd0[5][7],
> >>          Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
> >>          Carvalho[16]
> >>
> >>          - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
> >>          Stewart[3], John
> >>          C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine
> >>          Riard[12], Ava Chow[14]
> >>
> >>          - Mark "Murch" Erhardt*, recommended by Michael Folkson[6], Keagan
> >>          McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine
> >>          Riard[12],
> >>          Ava Chow[14]
> >>
> >>          - Michael Folkson*
> >>
> >>          Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for
> >>          "non-dev
> >>          triaging", Tonoski proposed himself[18] for "BIP editor", and
> >>          Antoine
> >>          Riard[12] proposed Seccour for "decentralized PM".
> >>
> >>          I searched the BIPs repo by commenter to see if any of the above
> >>          candidates had been especially active there, which is listed
> >>          below as:
> >>          total PRs they commented on (number still open/number closed).
> >>
> >>          - 21 (1/20) commenter:kanzure
> >>          - 3 (2/1) commenter:rubensomsen
> >>          - 15 (0/15) commenter:jonatack
> >>          - 18 (2/16) commenter:roasbeef
> >>          - 10 (6/4) commenter:Murchandamus
> >>          - 57 (6/51) commenter:michaelfolkson
> >>
> >>          I'll also note that Osuntokun is the only member of the set to
> >>          have a
> >>          merged BIP that they co-authored, although I believe there are
> >>          far-along
> >>          draft BIPs for both Murch (terminology) and Somsen (Silent
> >>          Payments). I
> >>          don't think this should be a requirement, but I do think it
> >>          demonstrates
> >>          familiarity with the process.
> >>
> >>          Speaking only for myself, I think all of the candidates above with
> >>          multiple recommendations from other community participants are
> >>          fully
> >>          qualified for the role, so I'll only provide a detailed
> >>          justification
> >>          for the person who would be my first pick: Murch is not only a
> >>          longstanding and broadly liked Bitcoin contributor, but (as Corallo
> >>          mentioned) he has worked on standardizing terminology through a
> >>          draft
> >>          BIP. In addition, he provided an extremely detailed review of
> >>          all 300
> >>          pages of a draft of Mastering Bitcoin (3rd edition) and has
> >>          reviewed
> >>          drafts of over 200 weekly Optech newsletters, in both cases
> >>          significantly improving the accuracy and comprehensibility of the
> >>          documentation. To me, that seems very similar to the work we'd
> >>          ask him
> >>          to perform as a BIPs editor and it's something that he's already
> >>          doing,
> >>          so I think there's an excellent fit of person to role.
> >>
> >>          -Dave
> >>
> >>          [1]
> >>          https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>
> >>          [2]
> >>          https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>
> >>          [3]
> >>          https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>
> >>          [4]
> >>          https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>
> >>          [5]
> >>          https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>
> >>          [6]
> >>          https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>
> >>          [7]
> >>          https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>
> >>          [8]
> >>          https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>
> >>          [9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> >>          <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
> >>          [10]
> >>          https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>
> >>          [11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >>          <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
> >>          [12]
> >>          https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>
> >>          [13]
> >>          https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>
> >>          [14]
> >>          https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>
> >>          [15]
> >>          https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>
> >>          [16]
> >>          https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>
> >>          [17]
> >>          https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
> >>      <mailto:bitcoindev+unsubscribe@googlegroups•com>.
> >>      To view this discussion on the web visit
> >>      https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>.
> >>
> >>
> >>
> >> --
> >> Sergi.
> >>
> >> --
> >> 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
> >> <mailto:bitcoindev+unsubscribe@googlegroups•com>.
> >> To view this discussion on the web visit
> >> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> >
> > --
> > 


^ permalink raw reply	[|nested] 100+ messages in thread
2024-04-20 19:59                             ` Michael Folkson

  
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2024-04-20 20:59 UTC (permalink / raw)
  To: Michael Folkson, luke;  bitcoindev


On 04/20/2024 03:59 PM, Michael Folkson wrote:
> Is Luke happy with this? That is a lot of new editors to onboard. I
> suspect you'd push back against adding 5 maintainers overnight to
> Bitcoin Core and I'm not sure why this is any different. What happens
> if there is disagreement between these now 6 BIP editors on merge
> decisions? If Luke is fine with this ok but it seems like the BIPs
> repo is going to be a free for all from now on.

My understanding is that he is okay with it, and I've talked to him 
privately numerous times about this since this thread was started.

This is different from Bitcoin Core in that there is currently only one 
BIP editor who has clearly stated more editors are needed. BIPs is also 
a fairly low risk repo as it's just documentation.

The expectation is that each editor will be able to work independently; 
obviously they should be communicating, but it's not a committee. I'm 
sure there will be some disagreement eventually, but ultimately, I think 
all of the candidates are professionals who can handle that maturely. 
Obviously a revert war would be a problem, but I don't think it would 
come down to that, and in that case, participants in that should be 
promptly removed.

Ava

> 
> Thanks
> Michael
> 
> On Sat, Apr 20, 2024 at 8:30 PM 'Ava Chow' via Bitcoin Development
> Mailing List <bitcoindev@googlegroups.com> wrote:
>>
>> Since we're now past the deadline of April 19th, I'd like to inform
>> everyone of what will happen on Monday.
>>
>> There has not been any actual objections to the nominees nor have there
>> been any suggestions on choosing a subset of them since my last email.
>> As such, there is rough consensus on adding Kanzure, Murch, Jonatack,
>> Ruben, and Roasbeef as BIP editors, and they will be added on Monday
>> April 22nd.
>>
>> Ava
>>
>> On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development Mailing List
>> wrote:
>>> While I don't disagree that 5 or 6 people seems like a lot to add at
>>> once, it's not clear to me how we should decide which subset of the
>>> nominees should be added. As it is now, I have only seen an actual
>>> objection to Kanzure and Ruben from /dev/fd0, and no explicit objections
>>> to anyone else. It seems like the vast majority of people don't share
>>> their concerns either as both Kanzure and Ruben continue to be endorsed
>>> by many others.
>>>
>>> Looking at the endorsements each candidate has received, the current
>>> counts are:
>>> * Kanzure - 17 for, 1 against
>>> * Murch - 13 for
>>> * Jonatack - 13 for
>>> * Ruben - 12 for, 1 against
>>> * Roasbeef - 9 for
>>> * Michael Folkson - none
>>>
>>> However, I don't want this process to become a popularity contest and
>>> require some kind of formal voting. Rather I'd prefer that this process
>>> be something more like how Bitcoin Core maintainers are added - by
>>> achieving rough consensus. Without any explicit objections to any of
>>> these candidates, I'm inclined to move forward with adding the 5 who
>>> have received endorsements. Having to pick "winners" from this list
>>> seems like a quick way to stir up drama that I don't think anyone really
>>> wants to deal with.
>>>
>>> I do want to note that neither Kanzure, Ruben, nor Roasbeef have posted
>>> on this list that they are willing to be BIP editors. I have reached out
>>> to all 3 of them privately, and received responses from Kanzure and
>>> Ruben that indicate that they probably are willing, but public
>>> confirmation from them on this list would also be nice. I have not
>>> received a response from Roasbeef.
>>>
>>> Ava
>>>
>>> On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
>>>>    > I would prefer having more (9+?) than less folks on this task, so
>>>> personal preferences are easily ignored and overwritten by the group
>>>> majority.
>>>>
>>>> I disagree with that, the more doesn't really the better here. Having
>>>> too many editors may result in a tragedy of the commons, in which people
>>>> just commit to the job because many others do, and they do not end up
>>>> doing as much because they expect others to do the it. This does not
>>>> only make the process look bad but may burnout the ones that end up
>>>> doing the job, given their time commitment ends up being too far from
>>>> their expectations.
>>>>
>>>> I think being more moderate with the amount of people is better, and
>>>> gives us leeway in case the workload ends up being excessive and we need
>>>> to add more people (plus discourage people from joining and slacking off).
>>>>
>>>> I think 3 more people should be a good number to start from.
>>>> I'd personally vouch for Murch, Kanzure, and Ruben based on their track
>>>> record in the space
>>>>
>>>> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com
>>>> <mailto:rdlfnvk@gmail•com>> wrote:
>>>>
>>>> +1 for
>>>> Kanzure
>>>> RubenSomsen
>>>> Seccour
>>>> Jon Atack
>>>> Roasbeef
>>>>
>>>> I would prefer having more (9+?) than less folks on this task, so
>>>> personal preferences are easily ignored and overwritten by the group
>>>> majority.
>>>>
>>>> BIPs were intended as a means to collect ideas, not enforce ideas.
>>>>
>>>> I'd like to return to that.
>>>>
>>>> - NVK (temp gmail account)
>>>>
>>>>       On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A. Harding wrote:
>>>>
>>>>           On 2024-03-28 10:04, Matt Corallo wrote:
>>>>            > Please provide justification rather than simply saying "I
>>>>           like Bob!".
>>>>
>>>>           Using only comments from the mailing list, the following appears
>>>>           to be
>>>>           the candidate list along with the current support. Asterisks denote
>>>>           candidates who indicated their willingness to accept the role.
>>>>
>>>>           - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris
>>>>           Stewart[3],
>>>>           Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon
>>>>           Black[11],
>>>>           Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>>>>           Carvalho[16]
>>>>
>>>>           - Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3],
>>>>           Michael
>>>>           Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>>>>           Carvalho[16]
>>>>
>>>>           - Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3],
>>>>           /dev/fd0[5][7],
>>>>           Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
>>>>           Carvalho[16]
>>>>
>>>>           - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
>>>>           Stewart[3], John
>>>>           C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine
>>>>           Riard[12], Ava Chow[14]
>>>>
>>>>           - Mark "Murch" Erhardt*, recommended by Michael Folkson[6], Keagan
>>>>           McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine
>>>>           Riard[12],
>>>>           Ava Chow[14]
>>>>
>>>>           - Michael Folkson*
>>>>
>>>>           Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for
>>>>           "non-dev
>>>>           triaging", Tonoski proposed himself[18] for "BIP editor", and
>>>>           Antoine
>>>>           Riard[12] proposed Seccour for "decentralized PM".
>>>>
>>>>           I searched the BIPs repo by commenter to see if any of the above
>>>>           candidates had been especially active there, which is listed
>>>>           below as:
>>>>           total PRs they commented on (number still open/number closed).
>>>>
>>>>           - 21 (1/20) commenter:kanzure
>>>>           - 3 (2/1) commenter:rubensomsen
>>>>           - 15 (0/15) commenter:jonatack
>>>>           - 18 (2/16) commenter:roasbeef
>>>>           - 10 (6/4) commenter:Murchandamus
>>>>           - 57 (6/51) commenter:michaelfolkson
>>>>
>>>>           I'll also note that Osuntokun is the only member of the set to
>>>>           have a
>>>>           merged BIP that they co-authored, although I believe there are
>>>>           far-along
>>>>           draft BIPs for both Murch (terminology) and Somsen (Silent
>>>>           Payments). I
>>>>           don't think this should be a requirement, but I do think it
>>>>           demonstrates
>>>>           familiarity with the process.
>>>>
>>>>           Speaking only for myself, I think all of the candidates above with
>>>>           multiple recommendations from other community participants are
>>>>           fully
>>>>           qualified for the role, so I'll only provide a detailed
>>>>           justification
>>>>           for the person who would be my first pick: Murch is not only a
>>>>           longstanding and broadly liked Bitcoin contributor, but (as Corallo
>>>>           mentioned) he has worked on standardizing terminology through a
>>>>           draft
>>>>           BIP. In addition, he provided an extremely detailed review of
>>>>           all 300
>>>>           pages of a draft of Mastering Bitcoin (3rd edition) and has
>>>>           reviewed
>>>>           drafts of over 200 weekly Optech newsletters, in both cases
>>>>           significantly improving the accuracy and comprehensibility of the
>>>>           documentation. To me, that seems very similar to the work we'd
>>>>           ask him
>>>>           to perform as a BIPs editor and it's something that he's already
>>>>           doing,
>>>>           so I think there's an excellent fit of person to role.
>>>>
>>>>           -Dave
>>>>
>>>>           [1]
>>>>           https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>
>>>>           [2]
>>>>           https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>
>>>>           [3]
>>>>           https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>
>>>>           [4]
>>>>           https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>
>>>>           [5]
>>>>           https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>
>>>>           [6]
>>>>           https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>
>>>>           [7]
>>>>           https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>
>>>>           [8]
>>>>           https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>
>>>>           [9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>>>>           <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
>>>>           [10]
>>>>           https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>
>>>>           [11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>>>>           <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>>>>           [12]
>>>>           https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>
>>>>           [13]
>>>>           https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>
>>>>           [14]
>>>>           https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>
>>>>           [15]
>>>>           https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>
>>>>           [16]
>>>>           https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>
>>>>           [17]
>>>>           https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
>>>>       <mailto:bitcoindev+unsubscribe@googlegroups•com>.
>>>>       To view this discussion on the web visit
>>>>       https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>>>
>>>>
>>>>
>>>> --
>>>> Sergi.
>>>>
>>>> --
>>>> 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
>>>> <mailto:bitcoindev+unsubscribe@googlegroups•com>.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>>>
>>> --
>>> 


 permalink raw reply	[|nested]
2024-04-20 20:46                             ` Steve Lee

  2024-04-20 21:11                                 ` Steve Lee
  2024-04-20 22:21                                 ` Michael Folkson
  
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2024-04-20 21:08 UTC (permalink / raw)
  To: Steve Lee;  bitcoindev

On 04/20/2024 04:46 PM, Steve Lee wrote:
> Wasn't there evidence provided that Kanzure does not want this 
> responsibility without being paid?

I am not aware of that, and it hasn't come up when I've talked to him 
about being a BIPs editor.

> I'm confused by this process that we don't even ask the people if they 
> want the responsibility? I think only Laolu has chimed in to commit to it?

Personally, I've spoken to all 5 privately and they've all confirmed to 
me that they are willing to be BIPs editors. Jonatack[1] and Murch[2] 
have also replied to this thread about this.

Ava

[1]: 
https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/
[2]: 
https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/

> 
> On Sat, Apr 20, 2024 at 12:30 PM 'Ava Chow' via Bitcoin Development 
> Mailing List <bitcoindev@googlegroups.com 
> <mailto:bitcoindev@googlegroups.com>> wrote:
> 
>     Since we're now past the deadline of April 19th, I'd like to inform
>     everyone of what will happen on Monday.
> 
>     There has not been any actual objections to the nominees nor have there
>     been any suggestions on choosing a subset of them since my last email.
>     As such, there is rough consensus on adding Kanzure, Murch, Jonatack,
>     Ruben, and Roasbeef as BIP editors, and they will be added on Monday
>     April 22nd.
> 
>     Ava
> 
>     On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development Mailing List
>     wrote:
>      > While I don't disagree that 5 or 6 people seems like a lot to add at
>      > once, it's not clear to me how we should decide which subset of the
>      > nominees should be added. As it is now, I have only seen an actual
>      > objection to Kanzure and Ruben from /dev/fd0, and no explicit
>     objections
>      > to anyone else. It seems like the vast majority of people don't share
>      > their concerns either as both Kanzure and Ruben continue to be
>     endorsed
>      > by many others.
>      >
>      > Looking at the endorsements each candidate has received, the current
>      > counts are:
>      > * Kanzure - 17 for, 1 against
>      > * Murch - 13 for
>      > * Jonatack - 13 for
>      > * Ruben - 12 for, 1 against
>      > * Roasbeef - 9 for
>      > * Michael Folkson - none
>      >
>      > However, I don't want this process to become a popularity contest and
>      > require some kind of formal voting. Rather I'd prefer that this
>     process
>      > be something more like how Bitcoin Core maintainers are added - by
>      > achieving rough consensus. Without any explicit objections to any of
>      > these candidates, I'm inclined to move forward with adding the 5 who
>      > have received endorsements. Having to pick "winners" from this list
>      > seems like a quick way to stir up drama that I don't think anyone
>     really
>      > wants to deal with.
>      >
>      > I do want to note that neither Kanzure, Ruben, nor Roasbeef have
>     posted
>      > on this list that they are willing to be BIP editors. I have
>     reached out
>      > to all 3 of them privately, and received responses from Kanzure and
>      > Ruben that indicate that they probably are willing, but public
>      > confirmation from them on this list would also be nice. I have not
>      > received a response from Roasbeef.
>      >
>      > Ava
>      >
>      > On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
>      >>   > I would prefer having more (9+?) than less folks on this
>     task, so
>      >> personal preferences are easily ignored and overwritten by the group
>      >> majority.
>      >>
>      >> I disagree with that, the more doesn't really the better here.
>     Having
>      >> too many editors may result in a tragedy of the commons, in
>     which people
>      >> just commit to the job because many others do, and they do not
>     end up
>      >> doing as much because they expect others to do the it. This does not
>      >> only make the process look bad but may burnout the ones that end up
>      >> doing the job, given their time commitment ends up being too far
>     from
>      >> their expectations.
>      >>
>      >> I think being more moderate with the amount of people is better, and
>      >> gives us leeway in case the workload ends up being excessive and
>     we need
>      >> to add more people (plus discourage people from joining and
>     slacking off).
>      >>
>      >> I think 3 more people should be a good number to start from.
>      >> I'd personally vouch for Murch, Kanzure, and Ruben based on
>     their track
>      >> record in the space
>      >>
>      >> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com
>     <mailto:rdlfnvk@gmail•com>
>      >> <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>>> wrote:
>      >>
>      >> +1 for
>      >> Kanzure
>      >> RubenSomsen
>      >> Seccour
>      >> Jon Atack
>      >> Roasbeef
>      >>
>      >> I would prefer having more (9+?) than less folks on this task, so
>      >> personal preferences are easily ignored and overwritten by the group
>      >> majority.
>      >>
>      >> BIPs were intended as a means to collect ideas, not enforce ideas.
>      >>
>      >> I'd like to return to that.
>      >>
>      >> - NVK (temp gmail account)
>      >>
>      >>      On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A.
>     Harding wrote:
>      >>
>      >>          On 2024-03-28 10:04, Matt Corallo wrote:
>      >>           > Please provide justification rather than simply
>     saying "I
>      >>          like Bob!".
>      >>
>      >>          Using only comments from the mailing list, the
>     following appears
>      >>          to be
>      >>          the candidate list along with the current support.
>     Asterisks denote
>      >>          candidates who indicated their willingness to accept
>     the role.
>      >>
>      >>          - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris
>      >>          Stewart[3],
>      >>          Michael Folkson[6], Peter Todd[9], Matt Corallo[10],
>     Brandon
>      >>          Black[11],
>      >>          Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>      >>          Carvalho[16]
>      >>
>      >>          - Ruben Somsen, recommended by Ava Chow[1], Chris
>     Stewart[3],
>      >>          Michael
>      >>          Folkson[6], Antoine Riard[12], Murch[13], Antoine
>     Poinsot[15], John
>      >>          Carvalho[16]
>      >>
>      >>          - Jon Atack*, recommended by Luke Dashjr[2], Chris
>     Stewart[3],
>      >>          /dev/fd0[5][7],
>      >>          Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
>      >>          Carvalho[16]
>      >>
>      >>          - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
>      >>          Stewart[3], John
>      >>          C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8],
>     Antoine
>      >>          Riard[12], Ava Chow[14]
>      >>
>      >>          - Mark "Murch" Erhardt*, recommended by Michael
>     Folkson[6], Keagan
>      >>          McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine
>      >>          Riard[12],
>      >>          Ava Chow[14]
>      >>
>      >>          - Michael Folkson*
>      >>
>      >>          Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for
>      >>          "non-dev
>      >>          triaging", Tonoski proposed himself[18] for "BIP
>     editor", and
>      >>          Antoine
>      >>          Riard[12] proposed Seccour for "decentralized PM".
>      >>
>      >>          I searched the BIPs repo by commenter to see if any of
>     the above
>      >>          candidates had been especially active there, which is
>     listed
>      >>          below as:
>      >>          total PRs they commented on (number still open/number
>     closed).
>      >>
>      >>          - 21 (1/20) commenter:kanzure
>      >>          - 3 (2/1) commenter:rubensomsen
>      >>          - 15 (0/15) commenter:jonatack
>      >>          - 18 (2/16) commenter:roasbeef
>      >>          - 10 (6/4) commenter:Murchandamus
>      >>          - 57 (6/51) commenter:michaelfolkson
>      >>
>      >>          I'll also note that Osuntokun is the only member of the
>     set to
>      >>          have a
>      >>          merged BIP that they co-authored, although I believe
>     there are
>      >>          far-along
>      >>          draft BIPs for both Murch (terminology) and Somsen (Silent
>      >>          Payments). I
>      >>          don't think this should be a requirement, but I do think it
>      >>          demonstrates
>      >>          familiarity with the process.
>      >>
>      >>          Speaking only for myself, I think all of the candidates
>     above with
>      >>          multiple recommendations from other community
>     participants are
>      >>          fully
>      >>          qualified for the role, so I'll only provide a detailed
>      >>          justification
>      >>          for the person who would be my first pick: Murch is not
>     only a
>      >>          longstanding and broadly liked Bitcoin contributor, but
>     (as Corallo
>      >>          mentioned) he has worked on standardizing terminology
>     through a
>      >>          draft
>      >>          BIP. In addition, he provided an extremely detailed
>     review of
>      >>          all 300
>      >>          pages of a draft of Mastering Bitcoin (3rd edition) and has
>      >>          reviewed
>      >>          drafts of over 200 weekly Optech newsletters, in both cases
>      >>          significantly improving the accuracy and
>     comprehensibility of the
>      >>          documentation. To me, that seems very similar to the
>     work we'd
>      >>          ask him
>      >>          to perform as a BIPs editor and it's something that
>     he's already
>      >>          doing,
>      >>          so I think there's an excellent fit of person to role.
>      >>
>      >>          -Dave
>      >>
>      >>          [1]
>      >>
>     https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
>     <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>>
>      >>          [2]
>      >>
>     https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
>     <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>
>     <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>>
>      >>          [3]
>      >>
>     https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>>
>      >>          [4]
>      >>
>     https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>>
>      >>          [5]
>      >>
>     https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>>
>      >>          [6]
>      >>
>     https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>>
>      >>          [7]
>      >>
>     https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>>
>      >>          [8]
>      >>
>     https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>>
>      >>          [9]
>     https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
>      >>         
>     <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
>     <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>>
>      >>          [10]
>      >>
>     https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>>
>      >>          [11]
>     https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>      >>         
>     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>
>      >>          [12]
>      >>
>     https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>>
>      >>          [13]
>      >>
>     https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
>     <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>
>     <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>>
>      >>          [14]
>      >>
>     https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
>     <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>>
>      >>          [15]
>      >>
>     https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/> <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>>
>      >>          [16]
>      >>
>     https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>>
>      >>          [17]
>      >>
>     https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
>     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
>      >>      <mailto:bitcoindev+unsubscribe@googlegroups•com
>     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>>.
>      >>      To view this discussion on the web visit
>      >>
>     https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com> <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>      >>
>      >>
>      >>
>      >> --
>      >> Sergi.
>      >>
>      >> --
>      >> 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
>     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
>      >> <mailto:bitcoindev+unsubscribe@googlegroups•com
>     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>>.
>      >> To view this discussion on the web visit
>      >>
>     https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com> <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.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
>     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
>      > To view this discussion on the web visit
>     https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.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
>     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
>     To view this discussion on the web visit
>     https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com>.
> 

-- 



 permalink raw reply	[|nested]
2024-04-20 21:08                               ` 'Ava Chow' via Bitcoin Development Mailing List

  2024-04-20 21:37                                   ` 'Ava Chow' via Bitcoin Development Mailing List
  2024-04-20 22:21                                 ` Michael Folkson
  
From: Steve Lee @ 2024-04-20 21:11 UTC (permalink / raw)
  To: Ava Chow;  bitcoindev

[-- Attachment #1: Type: text/plain, Size: 22230 bytes --]

On Sat, Apr 20, 2024 at 2:08 PM Ava Chow <lists@achow101•com> wrote:

> On 04/20/2024 04:46 PM, Steve Lee wrote:
> > Wasn't there evidence provided that Kanzure does not want this
> > responsibility without being paid?
>
> I am not aware of that, and it hasn't come up when I've talked to him
> about being a BIPs editor.
>

You should read this thread then before making a decision.

>
> > I'm confused by this process that we don't even ask the people if they
> > want the responsibility? I think only Laolu has chimed in to commit to
> it?
>
> Personally, I've spoken to all 5 privately and they've all confirmed to
> me that they are willing to be BIPs editors. Jonatack[1] and Murch[2]
> have also replied to this thread about this.


Ok good to know. Would've been nice to share this here so everyone was
aware.


>
> Ava
>
> [1]:
>
> https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/
> [2]:
>
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
>
> >
> > On Sat, Apr 20, 2024 at 12:30 PM 'Ava Chow' via Bitcoin Development
> > Mailing List <bitcoindev@googlegroups.com
> > <mailto:bitcoindev@googlegroups.com>> wrote:
> >
> >     Since we're now past the deadline of April 19th, I'd like to inform
> >     everyone of what will happen on Monday.
> >
> >     There has not been any actual objections to the nominees nor have
> there
> >     been any suggestions on choosing a subset of them since my last
> email.
> >     As such, there is rough consensus on adding Kanzure, Murch, Jonatack,
> >     Ruben, and Roasbeef as BIP editors, and they will be added on Monday
> >     April 22nd.
> >
> >     Ava
> >
> >     On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development Mailing
> List
> >     wrote:
> >      > While I don't disagree that 5 or 6 people seems like a lot to add
> at
> >      > once, it's not clear to me how we should decide which subset of
> the
> >      > nominees should be added. As it is now, I have only seen an actual
> >      > objection to Kanzure and Ruben from /dev/fd0, and no explicit
> >     objections
> >      > to anyone else. It seems like the vast majority of people don't
> share
> >      > their concerns either as both Kanzure and Ruben continue to be
> >     endorsed
> >      > by many others.
> >      >
> >      > Looking at the endorsements each candidate has received, the
> current
> >      > counts are:
> >      > * Kanzure - 17 for, 1 against
> >      > * Murch - 13 for
> >      > * Jonatack - 13 for
> >      > * Ruben - 12 for, 1 against
> >      > * Roasbeef - 9 for
> >      > * Michael Folkson - none
> >      >
> >      > However, I don't want this process to become a popularity contest
> and
> >      > require some kind of formal voting. Rather I'd prefer that this
> >     process
> >      > be something more like how Bitcoin Core maintainers are added - by
> >      > achieving rough consensus. Without any explicit objections to any
> of
> >      > these candidates, I'm inclined to move forward with adding the 5
> who
> >      > have received endorsements. Having to pick "winners" from this
> list
> >      > seems like a quick way to stir up drama that I don't think anyone
> >     really
> >      > wants to deal with.
> >      >
> >      > I do want to note that neither Kanzure, Ruben, nor Roasbeef have
> >     posted
> >      > on this list that they are willing to be BIP editors. I have
> >     reached out
> >      > to all 3 of them privately, and received responses from Kanzure
> and
> >      > Ruben that indicate that they probably are willing, but public
> >      > confirmation from them on this list would also be nice. I have not
> >      > received a response from Roasbeef.
> >      >
> >      > Ava
> >      >
> >      > On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
> >      >>   > I would prefer having more (9+?) than less folks on this
> >     task, so
> >      >> personal preferences are easily ignored and overwritten by the
> group
> >      >> majority.
> >      >>
> >      >> I disagree with that, the more doesn't really the better here.
> >     Having
> >      >> too many editors may result in a tragedy of the commons, in
> >     which people
> >      >> just commit to the job because many others do, and they do not
> >     end up
> >      >> doing as much because they expect others to do the it. This does
> not
> >      >> only make the process look bad but may burnout the ones that end
> up
> >      >> doing the job, given their time commitment ends up being too far
> >     from
> >      >> their expectations.
> >      >>
> >      >> I think being more moderate with the amount of people is better,
> and
> >      >> gives us leeway in case the workload ends up being excessive and
> >     we need
> >      >> to add more people (plus discourage people from joining and
> >     slacking off).
> >      >>
> >      >> I think 3 more people should be a good number to start from.
> >      >> I'd personally vouch for Murch, Kanzure, and Ruben based on
> >     their track
> >      >> record in the space
> >      >>
> >      >> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com
> >     <mailto:rdlfnvk@gmail•com>
> >      >> <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>>> wrote:
> >      >>
> >      >> +1 for
> >      >> Kanzure
> >      >> RubenSomsen
> >      >> Seccour
> >      >> Jon Atack
> >      >> Roasbeef
> >      >>
> >      >> I would prefer having more (9+?) than less folks on this task, so
> >      >> personal preferences are easily ignored and overwritten by the
> group
> >      >> majority.
> >      >>
> >      >> BIPs were intended as a means to collect ideas, not enforce
> ideas.
> >      >>
> >      >> I'd like to return to that.
> >      >>
> >      >> - NVK (temp gmail account)
> >      >>
> >      >>      On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A.
> >     Harding wrote:
> >      >>
> >      >>          On 2024-03-28 10:04, Matt Corallo wrote:
> >      >>           > Please provide justification rather than simply
> >     saying "I
> >      >>          like Bob!".
> >      >>
> >      >>          Using only comments from the mailing list, the
> >     following appears
> >      >>          to be
> >      >>          the candidate list along with the current support.
> >     Asterisks denote
> >      >>          candidates who indicated their willingness to accept
> >     the role.
> >      >>
> >      >>          - Bryan "Kanzure" Bishop, recommended by Ava Chow[1],
> Chris
> >      >>          Stewart[3],
> >      >>          Michael Folkson[6], Peter Todd[9], Matt Corallo[10],
> >     Brandon
> >      >>          Black[11],
> >      >>          Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
> >      >>          Carvalho[16]
> >      >>
> >      >>          - Ruben Somsen, recommended by Ava Chow[1], Chris
> >     Stewart[3],
> >      >>          Michael
> >      >>          Folkson[6], Antoine Riard[12], Murch[13], Antoine
> >     Poinsot[15], John
> >      >>          Carvalho[16]
> >      >>
> >      >>          - Jon Atack*, recommended by Luke Dashjr[2], Chris
> >     Stewart[3],
> >      >>          /dev/fd0[5][7],
> >      >>          Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
> >      >>          Carvalho[16]
> >      >>
> >      >>          - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
> >      >>          Stewart[3], John
> >      >>          C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8],
> >     Antoine
> >      >>          Riard[12], Ava Chow[14]
> >      >>
> >      >>          - Mark "Murch" Erhardt*, recommended by Michael
> >     Folkson[6], Keagan
> >      >>          McClelland[8], Matt Corallo[10], Brandon Black[11],
> Antoine
> >      >>          Riard[12],
> >      >>          Ava Chow[14]
> >      >>
> >      >>          - Michael Folkson*
> >      >>
> >      >>          Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski
> for
> >      >>          "non-dev
> >      >>          triaging", Tonoski proposed himself[18] for "BIP
> >     editor", and
> >      >>          Antoine
> >      >>          Riard[12] proposed Seccour for "decentralized PM".
> >      >>
> >      >>          I searched the BIPs repo by commenter to see if any of
> >     the above
> >      >>          candidates had been especially active there, which is
> >     listed
> >      >>          below as:
> >      >>          total PRs they commented on (number still open/number
> >     closed).
> >      >>
> >      >>          - 21 (1/20) commenter:kanzure
> >      >>          - 3 (2/1) commenter:rubensomsen
> >      >>          - 15 (0/15) commenter:jonatack
> >      >>          - 18 (2/16) commenter:roasbeef
> >      >>          - 10 (6/4) commenter:Murchandamus
> >      >>          - 57 (6/51) commenter:michaelfolkson
> >      >>
> >      >>          I'll also note that Osuntokun is the only member of the
> >     set to
> >      >>          have a
> >      >>          merged BIP that they co-authored, although I believe
> >     there are
> >      >>          far-along
> >      >>          draft BIPs for both Murch (terminology) and Somsen
> (Silent
> >      >>          Payments). I
> >      >>          don't think this should be a requirement, but I do
> think it
> >      >>          demonstrates
> >      >>          familiarity with the process.
> >      >>
> >      >>          Speaking only for myself, I think all of the candidates
> >     above with
> >      >>          multiple recommendations from other community
> >     participants are
> >      >>          fully
> >      >>          qualified for the role, so I'll only provide a detailed
> >      >>          justification
> >      >>          for the person who would be my first pick: Murch is not
> >     only a
> >      >>          longstanding and broadly liked Bitcoin contributor, but
> >     (as Corallo
> >      >>          mentioned) he has worked on standardizing terminology
> >     through a
> >      >>          draft
> >      >>          BIP. In addition, he provided an extremely detailed
> >     review of
> >      >>          all 300
> >      >>          pages of a draft of Mastering Bitcoin (3rd edition) and
> has
> >      >>          reviewed
> >      >>          drafts of over 200 weekly Optech newsletters, in both
> cases
> >      >>          significantly improving the accuracy and
> >     comprehensibility of the
> >      >>          documentation. To me, that seems very similar to the
> >     work we'd
> >      >>          ask him
> >      >>          to perform as a BIPs editor and it's something that
> >     he's already
> >      >>          doing,
> >      >>          so I think there's an excellent fit of person to role.
> >      >>
> >      >>          -Dave
> >      >>
> >      >>          [1]
> >      >>
> >     https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
> >     <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/> <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/
> <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/
> >>
> >      >>          [2]
> >      >>
> >     https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
> >     <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>
> >     <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/
> <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/
> >>
> >      >>          [3]
> >      >>
> >
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/
> >>
> >      >>          [4]
> >      >>
> >
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>
> <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/
> <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/
> >>
> >      >>          [5]
> >      >>
> >
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/
> >>
> >      >>          [6]
> >      >>
> >
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/
> >>
> >      >>          [7]
> >      >>
> >
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/
> >>
> >      >>          [8]
> >      >>
> >
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/
> >>
> >      >>          [9]
> >     https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> >     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
> >      >>
> >     <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
> >     <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>>
> >      >>          [10]
> >      >>
> >
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/
> <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/
> >>
> >      >>          [11]
> >     https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
> >      >>
> >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>
> >      >>          [12]
> >      >>
> >
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/
> >>
> >      >>          [13]
> >      >>
> >     https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
> >     <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>
> >     <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> >>
> >      >>          [14]
> >      >>
> >     https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
> >     <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/> <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/
> <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/
> >>
> >      >>          [15]
> >      >>
> >
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> >>
> >      >>          [16]
> >      >>
> >
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/
> >>
> >      >>          [17]
> >      >>
> >
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >      >>      <mailto:bitcoindev+unsubscribe@googlegroups•com
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>>.
> >      >>      To view this discussion on the web visit
> >      >>
> >
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com>
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer
> >>.
> >      >>
> >      >>
> >      >>
> >      >> --
> >      >> Sergi.
> >      >>
> >      >> --
> >      >> 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
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >      >> <mailto:bitcoindev+unsubscribe@googlegroups•com
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>>.
> >      >> To view this discussion on the web visit
> >      >>
> >
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com>
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.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
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
> >      > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com
> <
> https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.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
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
> >     To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com
> <
> https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com
> >.
> >
>
>

-- 


[-- Attachment #2: Type: text/html, Size: 40539 bytes --]

 permalink raw reply	[|nested]
2024-04-20 21:11                                 ` Steve Lee

  2024-04-20 22:03                                     ` Steve Lee
  
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2024-04-20 21:37 UTC (permalink / raw)
  To: Steve Lee;  bitcoindev

On 04/20/2024 05:11 PM, Steve Lee wrote:
> 
>     I am not aware of that, and it hasn't come up when I've talked to him
>     about being a BIPs editor.
> 
> 
> You should read this thread then before making a decision.

Thank you for your snarky reply.

I have, in fact, read every email in this thread. But there's 80+ emails 
in this thread and it's spread over 2 months, so it's possible I've 
missed something. With that in mind, I've just spent the last 10 minutes 
searching through the archive and cannot find any mention of Kanzure or 
anyone else saying that he would only be a BIP editor for payment. If 
you think I'm mistaken, I ask that you please provide a link to this 
evidence.

>     Personally, I've spoken to all 5 privately and they've all confirmed to
>     me that they are willing to be BIPs editors. Jonatack[1] and Murch[2]
>     have also replied to this thread about this.
> 
> 
> Ok good to know. Would've been nice to share this here so everyone was 
> aware.

You should read this thread before making such assumptions.

I informed the list[1] 4 days ago that I reached out privately to and 
got responses from Kanzure and Ruben. While I did the same with Jonatack 
and Murch, I did not feel the need to mention that because, if you've 
read this thread, they had already publicly confirmed their willingness.

Ava

[1]: 
https://gnusha.org/pi/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1@achow101.com/

> 
> 
> 
>     Ava
> 
>     [1]:
>     https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/>
>     [2]:
>     https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>
> 
>      >
>      > On Sat, Apr 20, 2024 at 12:30 PM 'Ava Chow' via Bitcoin Development
>      > Mailing List <bitcoindev@googlegroups.com
>     <mailto:bitcoindev@googlegroups.com>
>      > <mailto:bitcoindev@googlegroups.com
>     <mailto:bitcoindev@googlegroups.com>>> wrote:
>      >
>      >     Since we're now past the deadline of April 19th, I'd like to
>     inform
>      >     everyone of what will happen on Monday.
>      >
>      >     There has not been any actual objections to the nominees nor
>     have there
>      >     been any suggestions on choosing a subset of them since my
>     last email.
>      >     As such, there is rough consensus on adding Kanzure, Murch,
>     Jonatack,
>      >     Ruben, and Roasbeef as BIP editors, and they will be added on
>     Monday
>      >     April 22nd.
>      >
>      >     Ava
>      >
>      >     On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development
>     Mailing List
>      >     wrote:
>      >      > While I don't disagree that 5 or 6 people seems like a lot
>     to add at
>      >      > once, it's not clear to me how we should decide which
>     subset of the
>      >      > nominees should be added. As it is now, I have only seen
>     an actual
>      >      > objection to Kanzure and Ruben from /dev/fd0, and no explicit
>      >     objections
>      >      > to anyone else. It seems like the vast majority of people
>     don't share
>      >      > their concerns either as both Kanzure and Ruben continue to be
>      >     endorsed
>      >      > by many others.
>      >      >
>      >      > Looking at the endorsements each candidate has received,
>     the current
>      >      > counts are:
>      >      > * Kanzure - 17 for, 1 against
>      >      > * Murch - 13 for
>      >      > * Jonatack - 13 for
>      >      > * Ruben - 12 for, 1 against
>      >      > * Roasbeef - 9 for
>      >      > * Michael Folkson - none
>      >      >
>      >      > However, I don't want this process to become a popularity
>     contest and
>      >      > require some kind of formal voting. Rather I'd prefer that
>     this
>      >     process
>      >      > be something more like how Bitcoin Core maintainers are
>     added - by
>      >      > achieving rough consensus. Without any explicit objections
>     to any of
>      >      > these candidates, I'm inclined to move forward with adding
>     the 5 who
>      >      > have received endorsements. Having to pick "winners" from
>     this list
>      >      > seems like a quick way to stir up drama that I don't think
>     anyone
>      >     really
>      >      > wants to deal with.
>      >      >
>      >      > I do want to note that neither Kanzure, Ruben, nor
>     Roasbeef have
>      >     posted
>      >      > on this list that they are willing to be BIP editors. I have
>      >     reached out
>      >      > to all 3 of them privately, and received responses from
>     Kanzure and
>      >      > Ruben that indicate that they probably are willing, but public
>      >      > confirmation from them on this list would also be nice. I
>     have not
>      >      > received a response from Roasbeef.
>      >      >
>      >      > Ava
>      >      >
>      >      > On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
>      >      >>   > I would prefer having more (9+?) than less folks on this
>      >     task, so
>      >      >> personal preferences are easily ignored and overwritten
>     by the group
>      >      >> majority.
>      >      >>
>      >      >> I disagree with that, the more doesn't really the better
>     here.
>      >     Having
>      >      >> too many editors may result in a tragedy of the commons, in
>      >     which people
>      >      >> just commit to the job because many others do, and they
>     do not
>      >     end up
>      >      >> doing as much because they expect others to do the it.
>     This does not
>      >      >> only make the process look bad but may burnout the ones
>     that end up
>      >      >> doing the job, given their time commitment ends up being
>     too far
>      >     from
>      >      >> their expectations.
>      >      >>
>      >      >> I think being more moderate with the amount of people is
>     better, and
>      >      >> gives us leeway in case the workload ends up being
>     excessive and
>      >     we need
>      >      >> to add more people (plus discourage people from joining and
>      >     slacking off).
>      >      >>
>      >      >> I think 3 more people should be a good number to start from.
>      >      >> I'd personally vouch for Murch, Kanzure, and Ruben based on
>      >     their track
>      >      >> record in the space
>      >      >>
>      >      >> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com
>     <mailto:rdlfnvk@gmail•com>
>      >     <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>>
>      >      >> <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>
>     <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>>>> wrote:
>      >      >>
>      >      >> +1 for
>      >      >> Kanzure
>      >      >> RubenSomsen
>      >      >> Seccour
>      >      >> Jon Atack
>      >      >> Roasbeef
>      >      >>
>      >      >> I would prefer having more (9+?) than less folks on this
>     task, so
>      >      >> personal preferences are easily ignored and overwritten
>     by the group
>      >      >> majority.
>      >      >>
>      >      >> BIPs were intended as a means to collect ideas, not
>     enforce ideas.
>      >      >>
>      >      >> I'd like to return to that.
>      >      >>
>      >      >> - NVK (temp gmail account)
>      >      >>
>      >      >>      On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A.
>      >     Harding wrote:
>      >      >>
>      >      >>          On 2024-03-28 10:04, Matt Corallo wrote:
>      >      >>           > Please provide justification rather than simply
>      >     saying "I
>      >      >>          like Bob!".
>      >      >>
>      >      >>          Using only comments from the mailing list, the
>      >     following appears
>      >      >>          to be
>      >      >>          the candidate list along with the current support.
>      >     Asterisks denote
>      >      >>          candidates who indicated their willingness to accept
>      >     the role.
>      >      >>
>      >      >>          - Bryan "Kanzure" Bishop, recommended by Ava
>     Chow[1], Chris
>      >      >>          Stewart[3],
>      >      >>          Michael Folkson[6], Peter Todd[9], Matt Corallo[10],
>      >     Brandon
>      >      >>          Black[11],
>      >      >>          Antoine Riard[12], Murch[13], Antoine
>     Poinsot[15], John
>      >      >>          Carvalho[16]
>      >      >>
>      >      >>          - Ruben Somsen, recommended by Ava Chow[1], Chris
>      >     Stewart[3],
>      >      >>          Michael
>      >      >>          Folkson[6], Antoine Riard[12], Murch[13], Antoine
>      >     Poinsot[15], John
>      >      >>          Carvalho[16]
>      >      >>
>      >      >>          - Jon Atack*, recommended by Luke Dashjr[2], Chris
>      >     Stewart[3],
>      >      >>          /dev/fd0[5][7],
>      >      >>          Brandon Black[11], Antoine Riard[12], Ava
>     Chow[14], John
>      >      >>          Carvalho[16]
>      >      >>
>      >      >>          - Olaoluwa "Roasbeef" Osuntokun, recommended by
>     Chris
>      >      >>          Stewart[3], John
>      >      >>          C. Vernaleo[4], /dev/fd0[5][7], Keagan
>     McClelland[8],
>      >     Antoine
>      >      >>          Riard[12], Ava Chow[14]
>      >      >>
>      >      >>          - Mark "Murch" Erhardt*, recommended by Michael
>      >     Folkson[6], Keagan
>      >      >>          McClelland[8], Matt Corallo[10], Brandon
>     Black[11], Antoine
>      >      >>          Riard[12],
>      >      >>          Ava Chow[14]
>      >      >>
>      >      >>          - Michael Folkson*
>      >      >>
>      >      >>          Note: Luke Dashjr proposed[17] Seccour and Greg
>     Tonoski for
>      >      >>          "non-dev
>      >      >>          triaging", Tonoski proposed himself[18] for "BIP
>      >     editor", and
>      >      >>          Antoine
>      >      >>          Riard[12] proposed Seccour for "decentralized PM".
>      >      >>
>      >      >>          I searched the BIPs repo by commenter to see if
>     any of
>      >     the above
>      >      >>          candidates had been especially active there,
>     which is
>      >     listed
>      >      >>          below as:
>      >      >>          total PRs they commented on (number still
>     open/number
>      >     closed).
>      >      >>
>      >      >>          - 21 (1/20) commenter:kanzure
>      >      >>          - 3 (2/1) commenter:rubensomsen
>      >      >>          - 15 (0/15) commenter:jonatack
>      >      >>          - 18 (2/16) commenter:roasbeef
>      >      >>          - 10 (6/4) commenter:Murchandamus
>      >      >>          - 57 (6/51) commenter:michaelfolkson
>      >      >>
>      >      >>          I'll also note that Osuntokun is the only member
>     of the
>      >     set to
>      >      >>          have a
>      >      >>          merged BIP that they co-authored, although I believe
>      >     there are
>      >      >>          far-along
>      >      >>          draft BIPs for both Murch (terminology) and
>     Somsen (Silent
>      >      >>          Payments). I
>      >      >>          don't think this should be a requirement, but I
>     do think it
>      >      >>          demonstrates
>      >      >>          familiarity with the process.
>      >      >>
>      >      >>          Speaking only for myself, I think all of the
>     candidates
>      >     above with
>      >      >>          multiple recommendations from other community
>      >     participants are
>      >      >>          fully
>      >      >>          qualified for the role, so I'll only provide a
>     detailed
>      >      >>          justification
>      >      >>          for the person who would be my first pick: Murch
>     is not
>      >     only a
>      >      >>          longstanding and broadly liked Bitcoin
>     contributor, but
>      >     (as Corallo
>      >      >>          mentioned) he has worked on standardizing
>     terminology
>      >     through a
>      >      >>          draft
>      >      >>          BIP. In addition, he provided an extremely detailed
>      >     review of
>      >      >>          all 300
>      >      >>          pages of a draft of Mastering Bitcoin (3rd
>     edition) and has
>      >      >>          reviewed
>      >      >>          drafts of over 200 weekly Optech newsletters, in
>     both cases
>      >      >>          significantly improving the accuracy and
>      >     comprehensibility of the
>      >      >>          documentation. To me, that seems very similar to the
>      >     work we'd
>      >      >>          ask him
>      >      >>          to perform as a BIPs editor and it's something that
>      >     he's already
>      >      >>          doing,
>      >      >>          so I think there's an excellent fit of person to
>     role.
>      >      >>
>      >      >>          -Dave
>      >      >>
>      >      >>          [1]
>      >      >>
>      >
>     https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
>     <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/>
>      >   
>       <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/>> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>>>
>      >      >>          [2]
>      >      >>
>      >
>     https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
>     <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>
>      >   
>       <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>>
>      >   
>       <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>>>
>      >      >>          [3]
>      >      >>
>      >
>     https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>>>
>      >      >>          [4]
>      >      >>
>      >
>     https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>>>
>      >      >>          [5]
>      >      >>
>      >
>     https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>>>
>      >      >>          [6]
>      >      >>
>      >
>     https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>>>
>      >      >>          [7]
>      >      >>
>      >
>     https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>>>
>      >      >>          [8]
>      >      >>
>      >
>     https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/>> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>>>
>      >      >>          [9]
>      > https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
>      >     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>>
>      >      >>
>      >   
>       <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
>     <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
>      >   
>       <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
>     <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>>>
>      >      >>          [10]
>      >      >>
>      >
>     https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/>> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>>>
>      >      >>          [11]
>      > https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>      >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>
>      >      >>
>      >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>      >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>>
>      >      >>          [12]
>      >      >>
>      >
>     https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/>> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>>>
>      >      >>          [13]
>      >      >>
>      > https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
>     <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>
>      >   
>       <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
>     <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>>
>      >   
>       <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/> <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>>>
>      >      >>          [14]
>      >      >>
>      >
>     https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
>     <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>
>      >   
>       <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>>>
>      >      >>          [15]
>      >      >>
>      >
>     https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/> <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>> <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/> <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>>>
>      >      >>          [16]
>      >      >>
>      >
>     https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>>>
>      >      >>          [17]
>      >      >>
>      >
>     https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/>> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
>     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
>      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>
>      >      >>      <mailto:bitcoindev+unsubscribe@googlegroups•com
>     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
>      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>>.
>      >      >>      To view this discussion on the web visit
>      >      >>
>      >
>     https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com> <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com>> <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>>>.
>      >      >>
>      >      >>
>      >      >>
>      >      >> --
>      >      >> Sergi.
>      >      >>
>      >      >> --
>      >      >> 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
>     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
>      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>
>      >      >> <mailto:bitcoindev+unsubscribe@googlegroups•com
>     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
>      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>>.
>      >      >> To view this discussion on the web visit
>      >      >>
>      >
>     https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com> <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com>> <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.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
>     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
>      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>.
>      >      > To view this discussion on the web visit
>      >
>     https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com> <https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.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
>     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
>      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>.
>      >     To view this discussion on the web visit
>      >
>     https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com> <https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com>>.
>      >
> 

-- 



 permalink raw reply	[|nested]
2024-04-20 21:37                                   ` 'Ava Chow' via Bitcoin Development Mailing List

  2024-04-20 22:47                                       ` 'Ava Chow' via Bitcoin Development Mailing List
  
From: Steve Lee @ 2024-04-20 22:03 UTC (permalink / raw)
  To: Ava Chow;  bitcoindev

[-- Attachment #1: Type: text/plain, Size: 35232 bytes --]

nsvrn posted a days ago. Here's the tweet
https://x.com/kanzure/status/1766888650069967053

Ava, I'm just requesting people acknowledge legitimate concerns raised and
be transparent. Do you disagree?

On Sat, Apr 20, 2024 at 2:37 PM Ava Chow <lists@achow101•com> wrote:

> On 04/20/2024 05:11 PM, Steve Lee wrote:
> >
> >     I am not aware of that, and it hasn't come up when I've talked to him
> >     about being a BIPs editor.
> >
> >
> > You should read this thread then before making a decision.
>
> Thank you for your snarky reply.
>
> I have, in fact, read every email in this thread. But there's 80+ emails
> in this thread and it's spread over 2 months, so it's possible I've
> missed something. With that in mind, I've just spent the last 10 minutes
> searching through the archive and cannot find any mention of Kanzure or
> anyone else saying that he would only be a BIP editor for payment. If
> you think I'm mistaken, I ask that you please provide a link to this
> evidence.
>
> >     Personally, I've spoken to all 5 privately and they've all confirmed
> to
> >     me that they are willing to be BIPs editors. Jonatack[1] and Murch[2]
> >     have also replied to this thread about this.
> >
> >
> > Ok good to know. Would've been nice to share this here so everyone was
> > aware.
>
> You should read this thread before making such assumptions.
>
> I informed the list[1] 4 days ago that I reached out privately to and
> got responses from Kanzure and Ruben. While I did the same with Jonatack
> and Murch, I did not feel the need to mention that because, if you've
> read this thread, they had already publicly confirmed their willingness.
>
> Ava
>
> [1]:
>
> https://gnusha.org/pi/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1@achow101.com/
>
> >
> >
> >
> >     Ava
> >
> >     [1]:
> >
> https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/
> >
> >     [2]:
> >
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> >
> >
> >      >
> >      > On Sat, Apr 20, 2024 at 12:30 PM 'Ava Chow' via Bitcoin
> Development
> >      > Mailing List <bitcoindev@googlegroups.com
> >     <mailto:bitcoindev@googlegroups.com>
> >      > <mailto:bitcoindev@googlegroups.com
> >     <mailto:bitcoindev@googlegroups.com>>> wrote:
> >      >
> >      >     Since we're now past the deadline of April 19th, I'd like to
> >     inform
> >      >     everyone of what will happen on Monday.
> >      >
> >      >     There has not been any actual objections to the nominees nor
> >     have there
> >      >     been any suggestions on choosing a subset of them since my
> >     last email.
> >      >     As such, there is rough consensus on adding Kanzure, Murch,
> >     Jonatack,
> >      >     Ruben, and Roasbeef as BIP editors, and they will be added on
> >     Monday
> >      >     April 22nd.
> >      >
> >      >     Ava
> >      >
> >      >     On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development
> >     Mailing List
> >      >     wrote:
> >      >      > While I don't disagree that 5 or 6 people seems like a lot
> >     to add at
> >      >      > once, it's not clear to me how we should decide which
> >     subset of the
> >      >      > nominees should be added. As it is now, I have only seen
> >     an actual
> >      >      > objection to Kanzure and Ruben from /dev/fd0, and no
> explicit
> >      >     objections
> >      >      > to anyone else. It seems like the vast majority of people
> >     don't share
> >      >      > their concerns either as both Kanzure and Ruben continue
> to be
> >      >     endorsed
> >      >      > by many others.
> >      >      >
> >      >      > Looking at the endorsements each candidate has received,
> >     the current
> >      >      > counts are:
> >      >      > * Kanzure - 17 for, 1 against
> >      >      > * Murch - 13 for
> >      >      > * Jonatack - 13 for
> >      >      > * Ruben - 12 for, 1 against
> >      >      > * Roasbeef - 9 for
> >      >      > * Michael Folkson - none
> >      >      >
> >      >      > However, I don't want this process to become a popularity
> >     contest and
> >      >      > require some kind of formal voting. Rather I'd prefer that
> >     this
> >      >     process
> >      >      > be something more like how Bitcoin Core maintainers are
> >     added - by
> >      >      > achieving rough consensus. Without any explicit objections
> >     to any of
> >      >      > these candidates, I'm inclined to move forward with adding
> >     the 5 who
> >      >      > have received endorsements. Having to pick "winners" from
> >     this list
> >      >      > seems like a quick way to stir up drama that I don't think
> >     anyone
> >      >     really
> >      >      > wants to deal with.
> >      >      >
> >      >      > I do want to note that neither Kanzure, Ruben, nor
> >     Roasbeef have
> >      >     posted
> >      >      > on this list that they are willing to be BIP editors. I
> have
> >      >     reached out
> >      >      > to all 3 of them privately, and received responses from
> >     Kanzure and
> >      >      > Ruben that indicate that they probably are willing, but
> public
> >      >      > confirmation from them on this list would also be nice. I
> >     have not
> >      >      > received a response from Roasbeef.
> >      >      >
> >      >      > Ava
> >      >      >
> >      >      > On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
> >      >      >>   > I would prefer having more (9+?) than less folks on
> this
> >      >     task, so
> >      >      >> personal preferences are easily ignored and overwritten
> >     by the group
> >      >      >> majority.
> >      >      >>
> >      >      >> I disagree with that, the more doesn't really the better
> >     here.
> >      >     Having
> >      >      >> too many editors may result in a tragedy of the commons,
> in
> >      >     which people
> >      >      >> just commit to the job because many others do, and they
> >     do not
> >      >     end up
> >      >      >> doing as much because they expect others to do the it.
> >     This does not
> >      >      >> only make the process look bad but may burnout the ones
> >     that end up
> >      >      >> doing the job, given their time commitment ends up being
> >     too far
> >      >     from
> >      >      >> their expectations.
> >      >      >>
> >      >      >> I think being more moderate with the amount of people is
> >     better, and
> >      >      >> gives us leeway in case the workload ends up being
> >     excessive and
> >      >     we need
> >      >      >> to add more people (plus discourage people from joining
> and
> >      >     slacking off).
> >      >      >>
> >      >      >> I think 3 more people should be a good number to start
> from.
> >      >      >> I'd personally vouch for Murch, Kanzure, and Ruben based
> on
> >      >     their track
> >      >      >> record in the space
> >      >      >>
> >      >      >> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com
> >     <mailto:rdlfnvk@gmail•com>
> >      >     <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>>
> >      >      >> <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>
> >     <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>>>> wrote:
> >      >      >>
> >      >      >> +1 for
> >      >      >> Kanzure
> >      >      >> RubenSomsen
> >      >      >> Seccour
> >      >      >> Jon Atack
> >      >      >> Roasbeef
> >      >      >>
> >      >      >> I would prefer having more (9+?) than less folks on this
> >     task, so
> >      >      >> personal preferences are easily ignored and overwritten
> >     by the group
> >      >      >> majority.
> >      >      >>
> >      >      >> BIPs were intended as a means to collect ideas, not
> >     enforce ideas.
> >      >      >>
> >      >      >> I'd like to return to that.
> >      >      >>
> >      >      >> - NVK (temp gmail account)
> >      >      >>
> >      >      >>      On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A.
> >      >     Harding wrote:
> >      >      >>
> >      >      >>          On 2024-03-28 10:04, Matt Corallo wrote:
> >      >      >>           > Please provide justification rather than
> simply
> >      >     saying "I
> >      >      >>          like Bob!".
> >      >      >>
> >      >      >>          Using only comments from the mailing list, the
> >      >     following appears
> >      >      >>          to be
> >      >      >>          the candidate list along with the current
> support.
> >      >     Asterisks denote
> >      >      >>          candidates who indicated their willingness to
> accept
> >      >     the role.
> >      >      >>
> >      >      >>          - Bryan "Kanzure" Bishop, recommended by Ava
> >     Chow[1], Chris
> >      >      >>          Stewart[3],
> >      >      >>          Michael Folkson[6], Peter Todd[9], Matt
> Corallo[10],
> >      >     Brandon
> >      >      >>          Black[11],
> >      >      >>          Antoine Riard[12], Murch[13], Antoine
> >     Poinsot[15], John
> >      >      >>          Carvalho[16]
> >      >      >>
> >      >      >>          - Ruben Somsen, recommended by Ava Chow[1], Chris
> >      >     Stewart[3],
> >      >      >>          Michael
> >      >      >>          Folkson[6], Antoine Riard[12], Murch[13], Antoine
> >      >     Poinsot[15], John
> >      >      >>          Carvalho[16]
> >      >      >>
> >      >      >>          - Jon Atack*, recommended by Luke Dashjr[2],
> Chris
> >      >     Stewart[3],
> >      >      >>          /dev/fd0[5][7],
> >      >      >>          Brandon Black[11], Antoine Riard[12], Ava
> >     Chow[14], John
> >      >      >>          Carvalho[16]
> >      >      >>
> >      >      >>          - Olaoluwa "Roasbeef" Osuntokun, recommended by
> >     Chris
> >      >      >>          Stewart[3], John
> >      >      >>          C. Vernaleo[4], /dev/fd0[5][7], Keagan
> >     McClelland[8],
> >      >     Antoine
> >      >      >>          Riard[12], Ava Chow[14]
> >      >      >>
> >      >      >>          - Mark "Murch" Erhardt*, recommended by Michael
> >      >     Folkson[6], Keagan
> >      >      >>          McClelland[8], Matt Corallo[10], Brandon
> >     Black[11], Antoine
> >      >      >>          Riard[12],
> >      >      >>          Ava Chow[14]
> >      >      >>
> >      >      >>          - Michael Folkson*
> >      >      >>
> >      >      >>          Note: Luke Dashjr proposed[17] Seccour and Greg
> >     Tonoski for
> >      >      >>          "non-dev
> >      >      >>          triaging", Tonoski proposed himself[18] for "BIP
> >      >     editor", and
> >      >      >>          Antoine
> >      >      >>          Riard[12] proposed Seccour for "decentralized
> PM".
> >      >      >>
> >      >      >>          I searched the BIPs repo by commenter to see if
> >     any of
> >      >     the above
> >      >      >>          candidates had been especially active there,
> >     which is
> >      >     listed
> >      >      >>          below as:
> >      >      >>          total PRs they commented on (number still
> >     open/number
> >      >     closed).
> >      >      >>
> >      >      >>          - 21 (1/20) commenter:kanzure
> >      >      >>          - 3 (2/1) commenter:rubensomsen
> >      >      >>          - 15 (0/15) commenter:jonatack
> >      >      >>          - 18 (2/16) commenter:roasbeef
> >      >      >>          - 10 (6/4) commenter:Murchandamus
> >      >      >>          - 57 (6/51) commenter:michaelfolkson
> >      >      >>
> >      >      >>          I'll also note that Osuntokun is the only member
> >     of the
> >      >     set to
> >      >      >>          have a
> >      >      >>          merged BIP that they co-authored, although I
> believe
> >      >     there are
> >      >      >>          far-along
> >      >      >>          draft BIPs for both Murch (terminology) and
> >     Somsen (Silent
> >      >      >>          Payments). I
> >      >      >>          don't think this should be a requirement, but I
> >     do think it
> >      >      >>          demonstrates
> >      >      >>          familiarity with the process.
> >      >      >>
> >      >      >>          Speaking only for myself, I think all of the
> >     candidates
> >      >     above with
> >      >      >>          multiple recommendations from other community
> >      >     participants are
> >      >      >>          fully
> >      >      >>          qualified for the role, so I'll only provide a
> >     detailed
> >      >      >>          justification
> >      >      >>          for the person who would be my first pick: Murch
> >     is not
> >      >     only a
> >      >      >>          longstanding and broadly liked Bitcoin
> >     contributor, but
> >      >     (as Corallo
> >      >      >>          mentioned) he has worked on standardizing
> >     terminology
> >      >     through a
> >      >      >>          draft
> >      >      >>          BIP. In addition, he provided an extremely
> detailed
> >      >     review of
> >      >      >>          all 300
> >      >      >>          pages of a draft of Mastering Bitcoin (3rd
> >     edition) and has
> >      >      >>          reviewed
> >      >      >>          drafts of over 200 weekly Optech newsletters, in
> >     both cases
> >      >      >>          significantly improving the accuracy and
> >      >     comprehensibility of the
> >      >      >>          documentation. To me, that seems very similar to
> the
> >      >     work we'd
> >      >      >>          ask him
> >      >      >>          to perform as a BIPs editor and it's something
> that
> >      >     he's already
> >      >      >>          doing,
> >      >      >>          so I think there's an excellent fit of person to
> >     role.
> >      >      >>
> >      >      >>          -Dave
> >      >      >>
> >      >      >>          [1]
> >      >      >>
> >      >
> >     https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
> >     <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/>
> >      >
> >       <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/>> <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/
> <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>
> <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/
> <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/
> >>>
> >      >      >>          [2]
> >      >      >>
> >      >
> >     https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
> >     <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>
> >      >
> >       <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>>
> >      >
> >       <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/
> <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>
> <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/
> <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/
> >>>
> >      >      >>          [3]
> >      >      >>
> >      >
> >
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>
> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>>
> <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/
> >>>
> >      >      >>          [4]
> >      >      >>
> >      >
> >
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>
> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/
> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>>
> <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/
> <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>
> <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/
> <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/
> >>>
> >      >      >>          [5]
> >      >      >>
> >      >
> >
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>
> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>>
> <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/
> >>>
> >      >      >>          [6]
> >      >      >>
> >      >
> >
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>
> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>>
> <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/
> >>>
> >      >      >>          [7]
> >      >      >>
> >      >
> >
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>
> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>>
> <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/
> >>>
> >      >      >>          [8]
> >      >      >>
> >      >
> >
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/>>
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/
> >>>
> >      >      >>          [9]
> >      > https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> >     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
> >      >     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> >     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>>
> >      >      >>
> >      >
> >       <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
> >     <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
> >      >
> >       <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
> >     <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>>>
> >      >      >>          [10]
> >      >      >>
> >      >
> >
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/>>
> <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/
> <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>
> <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/
> <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/
> >>>
> >      >      >>          [11]
> >      > https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
> >      >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>
> >      >      >>
> >      >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
> >      >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>>
> >      >      >>          [12]
> >      >      >>
> >      >
> >
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/>>
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/
> >>>
> >      >      >>          [13]
> >      >      >>
> >      > https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
> >     <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>
> >      >
> >       <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
> >     <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>>
> >      >
> >       <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>
> <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> >>>
> >      >      >>          [14]
> >      >      >>
> >      >
> >     https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
> >     <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>
> >      >
> >       <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>> <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/
> <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>
> <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/
> <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/
> >>>
> >      >      >>          [15]
> >      >      >>
> >      >
> >
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>>
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> >>>
> >      >      >>          [16]
> >      >      >>
> >      >
> >
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>
> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>>
> <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/
> >>>
> >      >      >>          [17]
> >      >      >>
> >      >
> >
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/>>
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>
> >      >      >>      <mailto:bitcoindev+unsubscribe@googlegroups•com
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>>.
> >      >      >>      To view this discussion on the web visit
> >      >      >>
> >      >
> >
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com>
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com>>
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer
> >>>.
> >      >      >>
> >      >      >>
> >      >      >>
> >      >      >> --
> >      >      >> Sergi.
> >      >      >>
> >      >      >> --
> >      >      >> 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
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>
> >      >      >> <mailto:bitcoindev+unsubscribe@googlegroups•com
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>>.
> >      >      >> To view this discussion on the web visit
> >      >      >>
> >      >
> >
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com>
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com>>
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.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
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>.
> >      >      > To view this discussion on the web visit
> >      >
> >
> https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com
> <
> https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com>
> <
> https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com
> <
> https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.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
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>.
> >      >     To view this discussion on the web visit
> >      >
> >
> https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com
> <
> https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com>
> <
> https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com
> <
> https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com
> >>.
> >      >
> >
>
>

-- 


[-- Attachment #2: Type: text/html, Size: 69058 bytes --]

 permalink raw reply	[|nested]
2024-04-20 21:08                               ` 'Ava Chow' via Bitcoin Development Mailing List
  2024-04-20 21:11                                 ` Steve Lee

  2024-04-20 23:05                                   ` 'Ava Chow' via Bitcoin Development Mailing List
  
From: Michael Folkson @ 2024-04-20 22:21 UTC (permalink / raw)
  To: Ava Chow;  Steve Lee, bitcoindev

Ava

> Obviously a revert war would be a problem, but I don't think it would
come down to that, and in that case, participants in that should be
promptly removed.

It is inevitable there will be a "revert war" unless they all have to
agree on merge decisions or communicate prior to merging. It is just a
matter of time. Does for example Ordinal Numbers get a BIP number? I
suspect all the new BIP editors won't agree on that.

Who is to blame in a "revert war" if each editor is free to merge
whatever pull request they like? The editor who merged it? Why should
they be removed as an editor for merging a pull request when they find
out later a different editor disagreed with that merge decision and
wants to revert the merge?

I'm even more concerned about future soft fork activation attempts.
These don't necessarily need to be attempted via a Bitcoin Core merged
pull request hence the BIPs repo could be a key source of information
and guidance on this.

> BIPs is also a fairly low risk repo as it's just documentation.

Lower risk than say the Bitcoin Core repo sure but just throwing a
large number of new editors at it makes it seem like you don't care
what happens there.

I've seen Wladimir is contributing again to Core. Is there a plan to
give him commit access again? I'd be more comfortable with him
overseeing things in the various repos under the Bitcoin Core
(/bitcoin) GitHub org as it sounds like you don't really care if the
BIPs repo degenerates into a free for all.

Thanks
Michael

On Sat, Apr 20, 2024 at 10:15 PM 'Ava Chow' via Bitcoin Development
Mailing List <bitcoindev@googlegroups.com> wrote:
>
> On 04/20/2024 04:46 PM, Steve Lee wrote:
> > Wasn't there evidence provided that Kanzure does not want this
> > responsibility without being paid?
>
> I am not aware of that, and it hasn't come up when I've talked to him
> about being a BIPs editor.
>
> > I'm confused by this process that we don't even ask the people if they
> > want the responsibility? I think only Laolu has chimed in to commit to it?
>
> Personally, I've spoken to all 5 privately and they've all confirmed to
> me that they are willing to be BIPs editors. Jonatack[1] and Murch[2]
> have also replied to this thread about this.
>
> Ava
>
> [1]:
> https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/
> [2]:
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
>
> >
> > On Sat, Apr 20, 2024 at 12:30 PM 'Ava Chow' via Bitcoin Development
> > Mailing List <bitcoindev@googlegroups.com
> > <mailto:bitcoindev@googlegroups.com>> wrote:
> >
> >     Since we're now past the deadline of April 19th, I'd like to inform
> >     everyone of what will happen on Monday.
> >
> >     There has not been any actual objections to the nominees nor have there
> >     been any suggestions on choosing a subset of them since my last email.
> >     As such, there is rough consensus on adding Kanzure, Murch, Jonatack,
> >     Ruben, and Roasbeef as BIP editors, and they will be added on Monday
> >     April 22nd.
> >
> >     Ava
> >
> >     On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development Mailing List
> >     wrote:
> >      > While I don't disagree that 5 or 6 people seems like a lot to add at
> >      > once, it's not clear to me how we should decide which subset of the
> >      > nominees should be added. As it is now, I have only seen an actual
> >      > objection to Kanzure and Ruben from /dev/fd0, and no explicit
> >     objections
> >      > to anyone else. It seems like the vast majority of people don't share
> >      > their concerns either as both Kanzure and Ruben continue to be
> >     endorsed
> >      > by many others.
> >      >
> >      > Looking at the endorsements each candidate has received, the current
> >      > counts are:
> >      > * Kanzure - 17 for, 1 against
> >      > * Murch - 13 for
> >      > * Jonatack - 13 for
> >      > * Ruben - 12 for, 1 against
> >      > * Roasbeef - 9 for
> >      > * Michael Folkson - none
> >      >
> >      > However, I don't want this process to become a popularity contest and
> >      > require some kind of formal voting. Rather I'd prefer that this
> >     process
> >      > be something more like how Bitcoin Core maintainers are added - by
> >      > achieving rough consensus. Without any explicit objections to any of
> >      > these candidates, I'm inclined to move forward with adding the 5 who
> >      > have received endorsements. Having to pick "winners" from this list
> >      > seems like a quick way to stir up drama that I don't think anyone
> >     really
> >      > wants to deal with.
> >      >
> >      > I do want to note that neither Kanzure, Ruben, nor Roasbeef have
> >     posted
> >      > on this list that they are willing to be BIP editors. I have
> >     reached out
> >      > to all 3 of them privately, and received responses from Kanzure and
> >      > Ruben that indicate that they probably are willing, but public
> >      > confirmation from them on this list would also be nice. I have not
> >      > received a response from Roasbeef.
> >      >
> >      > Ava
> >      >
> >      > On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
> >      >>   > I would prefer having more (9+?) than less folks on this
> >     task, so
> >      >> personal preferences are easily ignored and overwritten by the group
> >      >> majority.
> >      >>
> >      >> I disagree with that, the more doesn't really the better here.
> >     Having
> >      >> too many editors may result in a tragedy of the commons, in
> >     which people
> >      >> just commit to the job because many others do, and they do not
> >     end up
> >      >> doing as much because they expect others to do the it. This does not
> >      >> only make the process look bad but may burnout the ones that end up
> >      >> doing the job, given their time commitment ends up being too far
> >     from
> >      >> their expectations.
> >      >>
> >      >> I think being more moderate with the amount of people is better, and
> >      >> gives us leeway in case the workload ends up being excessive and
> >     we need
> >      >> to add more people (plus discourage people from joining and
> >     slacking off).
> >      >>
> >      >> I think 3 more people should be a good number to start from.
> >      >> I'd personally vouch for Murch, Kanzure, and Ruben based on
> >     their track
> >      >> record in the space
> >      >>
> >      >> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com
> >     <mailto:rdlfnvk@gmail•com>
> >      >> <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>>> wrote:
> >      >>
> >      >> +1 for
> >      >> Kanzure
> >      >> RubenSomsen
> >      >> Seccour
> >      >> Jon Atack
> >      >> Roasbeef
> >      >>
> >      >> I would prefer having more (9+?) than less folks on this task, so
> >      >> personal preferences are easily ignored and overwritten by the group
> >      >> majority.
> >      >>
> >      >> BIPs were intended as a means to collect ideas, not enforce ideas.
> >      >>
> >      >> I'd like to return to that.
> >      >>
> >      >> - NVK (temp gmail account)
> >      >>
> >      >>      On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A.
> >     Harding wrote:
> >      >>
> >      >>          On 2024-03-28 10:04, Matt Corallo wrote:
> >      >>           > Please provide justification rather than simply
> >     saying "I
> >      >>          like Bob!".
> >      >>
> >      >>          Using only comments from the mailing list, the
> >     following appears
> >      >>          to be
> >      >>          the candidate list along with the current support.
> >     Asterisks denote
> >      >>          candidates who indicated their willingness to accept
> >     the role.
> >      >>
> >      >>          - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris
> >      >>          Stewart[3],
> >      >>          Michael Folkson[6], Peter Todd[9], Matt Corallo[10],
> >     Brandon
> >      >>          Black[11],
> >      >>          Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
> >      >>          Carvalho[16]
> >      >>
> >      >>          - Ruben Somsen, recommended by Ava Chow[1], Chris
> >     Stewart[3],
> >      >>          Michael
> >      >>          Folkson[6], Antoine Riard[12], Murch[13], Antoine
> >     Poinsot[15], John
> >      >>          Carvalho[16]
> >      >>
> >      >>          - Jon Atack*, recommended by Luke Dashjr[2], Chris
> >     Stewart[3],
> >      >>          /dev/fd0[5][7],
> >      >>          Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
> >      >>          Carvalho[16]
> >      >>
> >      >>          - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
> >      >>          Stewart[3], John
> >      >>          C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8],
> >     Antoine
> >      >>          Riard[12], Ava Chow[14]
> >      >>
> >      >>          - Mark "Murch" Erhardt*, recommended by Michael
> >     Folkson[6], Keagan
> >      >>          McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine
> >      >>          Riard[12],
> >      >>          Ava Chow[14]
> >      >>
> >      >>          - Michael Folkson*
> >      >>
> >      >>          Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for
> >      >>          "non-dev
> >      >>          triaging", Tonoski proposed himself[18] for "BIP
> >     editor", and
> >      >>          Antoine
> >      >>          Riard[12] proposed Seccour for "decentralized PM".
> >      >>
> >      >>          I searched the BIPs repo by commenter to see if any of
> >     the above
> >      >>          candidates had been especially active there, which is
> >     listed
> >      >>          below as:
> >      >>          total PRs they commented on (number still open/number
> >     closed).
> >      >>
> >      >>          - 21 (1/20) commenter:kanzure
> >      >>          - 3 (2/1) commenter:rubensomsen
> >      >>          - 15 (0/15) commenter:jonatack
> >      >>          - 18 (2/16) commenter:roasbeef
> >      >>          - 10 (6/4) commenter:Murchandamus
> >      >>          - 57 (6/51) commenter:michaelfolkson
> >      >>
> >      >>          I'll also note that Osuntokun is the only member of the
> >     set to
> >      >>          have a
> >      >>          merged BIP that they co-authored, although I believe
> >     there are
> >      >>          far-along
> >      >>          draft BIPs for both Murch (terminology) and Somsen (Silent
> >      >>          Payments). I
> >      >>          don't think this should be a requirement, but I do think it
> >      >>          demonstrates
> >      >>          familiarity with the process.
> >      >>
> >      >>          Speaking only for myself, I think all of the candidates
> >     above with
> >      >>          multiple recommendations from other community
> >     participants are
> >      >>          fully
> >      >>          qualified for the role, so I'll only provide a detailed
> >      >>          justification
> >      >>          for the person who would be my first pick: Murch is not
> >     only a
> >      >>          longstanding and broadly liked Bitcoin contributor, but
> >     (as Corallo
> >      >>          mentioned) he has worked on standardizing terminology
> >     through a
> >      >>          draft
> >      >>          BIP. In addition, he provided an extremely detailed
> >     review of
> >      >>          all 300
> >      >>          pages of a draft of Mastering Bitcoin (3rd edition) and has
> >      >>          reviewed
> >      >>          drafts of over 200 weekly Optech newsletters, in both cases
> >      >>          significantly improving the accuracy and
> >     comprehensibility of the
> >      >>          documentation. To me, that seems very similar to the
> >     work we'd
> >      >>          ask him
> >      >>          to perform as a BIPs editor and it's something that
> >     he's already
> >      >>          doing,
> >      >>          so I think there's an excellent fit of person to role.
> >      >>
> >      >>          -Dave
> >      >>
> >      >>          [1]
> >      >>
> >     https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
> >     <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>>
> >      >>          [2]
> >      >>
> >     https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
> >     <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>
> >     <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>>
> >      >>          [3]
> >      >>
> >     https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>>
> >      >>          [4]
> >      >>
> >     https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>>
> >      >>          [5]
> >      >>
> >     https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>>
> >      >>          [6]
> >      >>
> >     https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>>
> >      >>          [7]
> >      >>
> >     https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>>
> >      >>          [8]
> >      >>
> >     https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>>
> >      >>          [9]
> >     https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> >     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
> >      >>
> >     <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
> >     <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>>
> >      >>          [10]
> >      >>
> >     https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>>
> >      >>          [11]
> >     https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
> >      >>
> >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>
> >      >>          [12]
> >      >>
> >     https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>>
> >      >>          [13]
> >      >>
> >     https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
> >     <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>
> >     <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>>
> >      >>          [14]
> >      >>
> >     https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
> >     <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>>
> >      >>          [15]
> >      >>
> >     https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/> <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>>
> >      >>          [16]
> >      >>
> >     https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>>
> >      >>          [17]
> >      >>
> >     https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >      >>      <mailto:bitcoindev+unsubscribe@googlegroups•com
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>>.
> >      >>      To view this discussion on the web visit
> >      >>
> >     https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com> <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> >      >>
> >      >>
> >      >>
> >      >> --
> >      >> Sergi.
> >      >>
> >      >> --
> >      >> 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
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >      >> <mailto:bitcoindev+unsubscribe@googlegroups•com
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>>.
> >      >> To view this discussion on the web visit
> >      >>
> >     https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com> <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.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
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
> >      > To view this discussion on the web visit
> >     https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.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
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
> >     To view this discussion on the web visit
> >     https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com>.
> >
>
> --
> 


 permalink raw reply	[|nested]
2024-04-20 22:03                                     ` Steve Lee

  2024-04-22  2:44                                         ` Steve Lee
  
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2024-04-20 22:47 UTC (permalink / raw)
  To: Steve Lee;  bitcoindev

I saw that email and read the tweet. It doesn't seem to me that nsvrn 
was raising an objection to Kanzure, just pointing out something for 
people to consider. No one else has said anything, so I'm assuming that 
no minds have changed considering this information. It'd be ridiculous 
if every time new information was presented that we went to everyone and 
ask them whether their stance has changed. It's all the same email 
thread, if their mind has changed, then they can inform us as a reply.

Furthermore, I fail to see how this tweet matches your claim that he 
"does not want this responsibility without being paid". Saying that he 
has better things to do with his time doesn't necessarily mean that he 
won't do it, and other such tweets, including his own replies to this 
one, indicate the he is.

If your concern is about his reply to the suggestion that being paid 
would change things substantially, I still don't see how that matches 
the statement you made earlier. Being paid to do any task would change 
the calculus on whether someone wants to do something, but that doesn't 
mean they won't do it even if unpaid.

Ava

On 04/20/2024 06:03 PM, Steve Lee wrote:
> nsvrn posted a days ago. Here's the tweet
> https://x.com/kanzure/status/1766888650069967053 
> <https://x.com/kanzure/status/1766888650069967053>
> 
> Ava, I'm just requesting people acknowledge legitimate concerns raised 
> and be transparent. Do you disagree?
> 
> On Sat, Apr 20, 2024 at 2:37 PM Ava Chow <lists@achow101•com 
> <mailto:lists@achow101•com>> wrote:
> 
>     On 04/20/2024 05:11 PM, Steve Lee wrote:
>      >
>      >     I am not aware of that, and it hasn't come up when I've
>     talked to him
>      >     about being a BIPs editor.
>      >
>      >
>      > You should read this thread then before making a decision.
> 
>     Thank you for your snarky reply.
> 
>     I have, in fact, read every email in this thread. But there's 80+
>     emails
>     in this thread and it's spread over 2 months, so it's possible I've
>     missed something. With that in mind, I've just spent the last 10
>     minutes
>     searching through the archive and cannot find any mention of Kanzure or
>     anyone else saying that he would only be a BIP editor for payment. If
>     you think I'm mistaken, I ask that you please provide a link to this
>     evidence.
> 
>      >     Personally, I've spoken to all 5 privately and they've all
>     confirmed to
>      >     me that they are willing to be BIPs editors. Jonatack[1] and
>     Murch[2]
>      >     have also replied to this thread about this.
>      >
>      >
>      > Ok good to know. Would've been nice to share this here so
>     everyone was
>      > aware.
> 
>     You should read this thread before making such assumptions.
> 
>     I informed the list[1] 4 days ago that I reached out privately to and
>     got responses from Kanzure and Ruben. While I did the same with
>     Jonatack
>     and Murch, I did not feel the need to mention that because, if you've
>     read this thread, they had already publicly confirmed their willingness.
> 
>     Ava
> 
>     [1]:
>     https://gnusha.org/pi/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1@achow101.com/ <https://gnusha.org/pi/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1@achow101.com/>
> 
>      >
>      >
>      >
>      >     Ava
>      >
>      >     [1]:
>      >
>     https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/>>
>      >     [2]:
>      >
>     https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/> <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>>
>      >
>      >      >
>      >      > On Sat, Apr 20, 2024 at 12:30 PM 'Ava Chow' via Bitcoin
>     Development
>      >      > Mailing List <bitcoindev@googlegroups.com
>     <mailto:bitcoindev@googlegroups.com>
>      >     <mailto:bitcoindev@googlegroups.com
>     <mailto:bitcoindev@googlegroups.com>>
>      >      > <mailto:bitcoindev@googlegroups.com
>     <mailto:bitcoindev@googlegroups.com>
>      >     <mailto:bitcoindev@googlegroups.com
>     <mailto:bitcoindev@googlegroups.com>>>> wrote:
>      >      >
>      >      >     Since we're now past the deadline of April 19th, I'd
>     like to
>      >     inform
>      >      >     everyone of what will happen on Monday.
>      >      >
>      >      >     There has not been any actual objections to the
>     nominees nor
>      >     have there
>      >      >     been any suggestions on choosing a subset of them since my
>      >     last email.
>      >      >     As such, there is rough consensus on adding Kanzure,
>     Murch,
>      >     Jonatack,
>      >      >     Ruben, and Roasbeef as BIP editors, and they will be
>     added on
>      >     Monday
>      >      >     April 22nd.
>      >      >
>      >      >     Ava
>      >      >
>      >      >     On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development
>      >     Mailing List
>      >      >     wrote:
>      >      >      > While I don't disagree that 5 or 6 people seems
>     like a lot
>      >     to add at
>      >      >      > once, it's not clear to me how we should decide which
>      >     subset of the
>      >      >      > nominees should be added. As it is now, I have only
>     seen
>      >     an actual
>      >      >      > objection to Kanzure and Ruben from /dev/fd0, and
>     no explicit
>      >      >     objections
>      >      >      > to anyone else. It seems like the vast majority of
>     people
>      >     don't share
>      >      >      > their concerns either as both Kanzure and Ruben
>     continue to be
>      >      >     endorsed
>      >      >      > by many others.
>      >      >      >
>      >      >      > Looking at the endorsements each candidate has
>     received,
>      >     the current
>      >      >      > counts are:
>      >      >      > * Kanzure - 17 for, 1 against
>      >      >      > * Murch - 13 for
>      >      >      > * Jonatack - 13 for
>      >      >      > * Ruben - 12 for, 1 against
>      >      >      > * Roasbeef - 9 for
>      >      >      > * Michael Folkson - none
>      >      >      >
>      >      >      > However, I don't want this process to become a
>     popularity
>      >     contest and
>      >      >      > require some kind of formal voting. Rather I'd
>     prefer that
>      >     this
>      >      >     process
>      >      >      > be something more like how Bitcoin Core maintainers are
>      >     added - by
>      >      >      > achieving rough consensus. Without any explicit
>     objections
>      >     to any of
>      >      >      > these candidates, I'm inclined to move forward with
>     adding
>      >     the 5 who
>      >      >      > have received endorsements. Having to pick
>     "winners" from
>      >     this list
>      >      >      > seems like a quick way to stir up drama that I
>     don't think
>      >     anyone
>      >      >     really
>      >      >      > wants to deal with.
>      >      >      >
>      >      >      > I do want to note that neither Kanzure, Ruben, nor
>      >     Roasbeef have
>      >      >     posted
>      >      >      > on this list that they are willing to be BIP
>     editors. I have
>      >      >     reached out
>      >      >      > to all 3 of them privately, and received responses from
>      >     Kanzure and
>      >      >      > Ruben that indicate that they probably are willing,
>     but public
>      >      >      > confirmation from them on this list would also be
>     nice. I
>      >     have not
>      >      >      > received a response from Roasbeef.
>      >      >      >
>      >      >      > Ava
>      >      >      >
>      >      >      > On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
>      >      >      >>   > I would prefer having more (9+?) than less
>     folks on this
>      >      >     task, so
>      >      >      >> personal preferences are easily ignored and
>     overwritten
>      >     by the group
>      >      >      >> majority.
>      >      >      >>
>      >      >      >> I disagree with that, the more doesn't really the
>     better
>      >     here.
>      >      >     Having
>      >      >      >> too many editors may result in a tragedy of the
>     commons, in
>      >      >     which people
>      >      >      >> just commit to the job because many others do, and
>     they
>      >     do not
>      >      >     end up
>      >      >      >> doing as much because they expect others to do the it.
>      >     This does not
>      >      >      >> only make the process look bad but may burnout the
>     ones
>      >     that end up
>      >      >      >> doing the job, given their time commitment ends up
>     being
>      >     too far
>      >      >     from
>      >      >      >> their expectations.
>      >      >      >>
>      >      >      >> I think being more moderate with the amount of
>     people is
>      >     better, and
>      >      >      >> gives us leeway in case the workload ends up being
>      >     excessive and
>      >      >     we need
>      >      >      >> to add more people (plus discourage people from
>     joining and
>      >      >     slacking off).
>      >      >      >>
>      >      >      >> I think 3 more people should be a good number to
>     start from.
>      >      >      >> I'd personally vouch for Murch, Kanzure, and Ruben
>     based on
>      >      >     their track
>      >      >      >> record in the space
>      >      >      >>
>      >      >      >> On Tue, Apr 2, 2024 at 4:30 PM nvk
>     <rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>
>      >     <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>>
>      >      >     <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>
>     <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>>>
>      >      >      >> <mailto:rdlfnvk@gmail•com
>     <mailto:rdlfnvk@gmail•com> <mailto:rdlfnvk@gmail•com
>     <mailto:rdlfnvk@gmail•com>>
>      >     <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>
>     <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>>>>> wrote:
>      >      >      >>
>      >      >      >> +1 for
>      >      >      >> Kanzure
>      >      >      >> RubenSomsen
>      >      >      >> Seccour
>      >      >      >> Jon Atack
>      >      >      >> Roasbeef
>      >      >      >>
>      >      >      >> I would prefer having more (9+?) than less folks
>     on this
>      >     task, so
>      >      >      >> personal preferences are easily ignored and
>     overwritten
>      >     by the group
>      >      >      >> majority.
>      >      >      >>
>      >      >      >> BIPs were intended as a means to collect ideas, not
>      >     enforce ideas.
>      >      >      >>
>      >      >      >> I'd like to return to that.
>      >      >      >>
>      >      >      >> - NVK (temp gmail account)
>      >      >      >>
>      >      >      >>      On Monday, April 1, 2024 at 5:16:54 PM UTC-4
>     David A.
>      >      >     Harding wrote:
>      >      >      >>
>      >      >      >>          On 2024-03-28 10:04, Matt Corallo wrote:
>      >      >      >>           > Please provide justification rather
>     than simply
>      >      >     saying "I
>      >      >      >>          like Bob!".
>      >      >      >>
>      >      >      >>          Using only comments from the mailing
>     list, the
>      >      >     following appears
>      >      >      >>          to be
>      >      >      >>          the candidate list along with the current
>     support.
>      >      >     Asterisks denote
>      >      >      >>          candidates who indicated their
>     willingness to accept
>      >      >     the role.
>      >      >      >>
>      >      >      >>          - Bryan "Kanzure" Bishop, recommended by Ava
>      >     Chow[1], Chris
>      >      >      >>          Stewart[3],
>      >      >      >>          Michael Folkson[6], Peter Todd[9], Matt
>     Corallo[10],
>      >      >     Brandon
>      >      >      >>          Black[11],
>      >      >      >>          Antoine Riard[12], Murch[13], Antoine
>      >     Poinsot[15], John
>      >      >      >>          Carvalho[16]
>      >      >      >>
>      >      >      >>          - Ruben Somsen, recommended by Ava
>     Chow[1], Chris
>      >      >     Stewart[3],
>      >      >      >>          Michael
>      >      >      >>          Folkson[6], Antoine Riard[12], Murch[13],
>     Antoine
>      >      >     Poinsot[15], John
>      >      >      >>          Carvalho[16]
>      >      >      >>
>      >      >      >>          - Jon Atack*, recommended by Luke
>     Dashjr[2], Chris
>      >      >     Stewart[3],
>      >      >      >>          /dev/fd0[5][7],
>      >      >      >>          Brandon Black[11], Antoine Riard[12], Ava
>      >     Chow[14], John
>      >      >      >>          Carvalho[16]
>      >      >      >>
>      >      >      >>          - Olaoluwa "Roasbeef" Osuntokun,
>     recommended by
>      >     Chris
>      >      >      >>          Stewart[3], John
>      >      >      >>          C. Vernaleo[4], /dev/fd0[5][7], Keagan
>      >     McClelland[8],
>      >      >     Antoine
>      >      >      >>          Riard[12], Ava Chow[14]
>      >      >      >>
>      >      >      >>          - Mark "Murch" Erhardt*, recommended by
>     Michael
>      >      >     Folkson[6], Keagan
>      >      >      >>          McClelland[8], Matt Corallo[10], Brandon
>      >     Black[11], Antoine
>      >      >      >>          Riard[12],
>      >      >      >>          Ava Chow[14]
>      >      >      >>
>      >      >      >>          - Michael Folkson*
>      >      >      >>
>      >      >      >>          Note: Luke Dashjr proposed[17] Seccour
>     and Greg
>      >     Tonoski for
>      >      >      >>          "non-dev
>      >      >      >>          triaging", Tonoski proposed himself[18]
>     for "BIP
>      >      >     editor", and
>      >      >      >>          Antoine
>      >      >      >>          Riard[12] proposed Seccour for
>     "decentralized PM".
>      >      >      >>
>      >      >      >>          I searched the BIPs repo by commenter to
>     see if
>      >     any of
>      >      >     the above
>      >      >      >>          candidates had been especially active there,
>      >     which is
>      >      >     listed
>      >      >      >>          below as:
>      >      >      >>          total PRs they commented on (number still
>      >     open/number
>      >      >     closed).
>      >      >      >>
>      >      >      >>          - 21 (1/20) commenter:kanzure
>      >      >      >>          - 3 (2/1) commenter:rubensomsen
>      >      >      >>          - 15 (0/15) commenter:jonatack
>      >      >      >>          - 18 (2/16) commenter:roasbeef
>      >      >      >>          - 10 (6/4) commenter:Murchandamus
>      >      >      >>          - 57 (6/51) commenter:michaelfolkson
>      >      >      >>
>      >      >      >>          I'll also note that Osuntokun is the only
>     member
>      >     of the
>      >      >     set to
>      >      >      >>          have a
>      >      >      >>          merged BIP that they co-authored,
>     although I believe
>      >      >     there are
>      >      >      >>          far-along
>      >      >      >>          draft BIPs for both Murch (terminology) and
>      >     Somsen (Silent
>      >      >      >>          Payments). I
>      >      >      >>          don't think this should be a requirement,
>     but I
>      >     do think it
>      >      >      >>          demonstrates
>      >      >      >>          familiarity with the process.
>      >      >      >>
>      >      >      >>          Speaking only for myself, I think all of the
>      >     candidates
>      >      >     above with
>      >      >      >>          multiple recommendations from other community
>      >      >     participants are
>      >      >      >>          fully
>      >      >      >>          qualified for the role, so I'll only
>     provide a
>      >     detailed
>      >      >      >>          justification
>      >      >      >>          for the person who would be my first
>     pick: Murch
>      >     is not
>      >      >     only a
>      >      >      >>          longstanding and broadly liked Bitcoin
>      >     contributor, but
>      >      >     (as Corallo
>      >      >      >>          mentioned) he has worked on standardizing
>      >     terminology
>      >      >     through a
>      >      >      >>          draft
>      >      >      >>          BIP. In addition, he provided an
>     extremely detailed
>      >      >     review of
>      >      >      >>          all 300
>      >      >      >>          pages of a draft of Mastering Bitcoin (3rd
>      >     edition) and has
>      >      >      >>          reviewed
>      >      >      >>          drafts of over 200 weekly Optech
>     newsletters, in
>      >     both cases
>      >      >      >>          significantly improving the accuracy and
>      >      >     comprehensibility of the
>      >      >      >>          documentation. To me, that seems very
>     similar to the
>      >      >     work we'd
>      >      >      >>          ask him
>      >      >      >>          to perform as a BIPs editor and it's
>     something that
>      >      >     he's already
>      >      >      >>          doing,
>      >      >      >>          so I think there's an excellent fit of
>     person to
>      >     role.
>      >      >      >>
>      >      >      >>          -Dave
>      >      >      >>
>      >      >      >>          [1]
>      >      >      >>
>      >      >
>      >
>     https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
>     <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/>
>      >   
>       <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/>>
>      >      >
>      >     
>       <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/>>> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>>>>
>      >      >      >>          [2]
>      >      >      >>
>      >      >
>      >
>     https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
>     <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>
>      >   
>       <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>>
>      >      >
>      >     
>       <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>>>
>      >      >
>      >     
>       <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/> <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>>>>
>      >      >      >>          [3]
>      >      >      >>
>      >      >
>      >
>     https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>>> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>>>>
>      >      >      >>          [4]
>      >      >      >>
>      >      >
>      >
>     https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>>> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>>>>
>      >      >      >>          [5]
>      >      >      >>
>      >      >
>      >
>     https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>>> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>>>>
>      >      >      >>          [6]
>      >      >      >>
>      >      >
>      >
>     https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>>> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>>>>
>      >      >      >>          [7]
>      >      >      >>
>      >      >
>      >
>     https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>>> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>>>>
>      >      >      >>          [8]
>      >      >      >>
>      >      >
>      >
>     https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/>> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/>>> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>>>>
>      >      >      >>          [9]
>      >      >
>     https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
>      >     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>>
>      >      >   
>       <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
>      >     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>>>
>      >      >      >>
>      >      >
>      >     
>       <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
>     <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
>      >   
>       <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
>     <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>>
>      >      >
>      >     
>       <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
>     <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
>      >   
>       <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
>     <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>>>>
>      >      >      >>          [10]
>      >      >      >>
>      >      >
>      >
>     https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/>> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/>>> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>>>>
>      >      >      >>          [11]
>      >      > https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>      >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>
>      >      >   
>       <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>      >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>>
>      >      >      >>
>      >      >   
>       <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>      >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>
>      >      >   
>       <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>      >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>>>
>      >      >      >>          [12]
>      >      >      >>
>      >      >
>      >
>     https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/>> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/>>> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>>>>
>      >      >      >>          [13]
>      >      >      >>
>      >      >
>     https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
>     <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>
>      >   
>       <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
>     <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>>
>      >      >
>      >     
>       <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
>     <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>
>      >   
>       <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
>     <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>>>
>      >      >
>      >     
>       <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/> <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>> <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/> <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>>>>
>      >      >      >>          [14]
>      >      >      >>
>      >      >
>      >
>     https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
>     <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>
>      >   
>       <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>>
>      >      >
>      >     
>       <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>>> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>>>>
>      >      >      >>          [15]
>      >      >      >>
>      >      >
>      >
>     https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/> <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>> <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/> <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>>> <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/> <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>> <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/> <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>>>>
>      >      >      >>          [16]
>      >      >      >>
>      >      >
>      >
>     https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>>> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>>>>
>      >      >      >>          [17]
>      >      >      >>
>      >      >
>      >
>     https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/>> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/>>> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/>> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
>     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
>      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>
>      >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>
>      >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%25252Bunsubscribe@googlegroups•com>>>
>      >      >      >>     
>     <mailto:bitcoindev+unsubscribe@googlegroups•com
>     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
>      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>
>      >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>
>      >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%25252Bunsubscribe@googlegroups•com>>>>.
>      >      >      >>      To view this discussion on the web visit
>      >      >      >>
>      >      >
>      >
>     https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com> <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com>> <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com> <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com>>> <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>> <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>>>>.
>      >      >      >>
>      >      >      >>
>      >      >      >>
>      >      >      >> --
>      >      >      >> Sergi.
>      >      >      >>
>      >      >      >> --
>      >      >      >> 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
>     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
>      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>
>      >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>
>      >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%25252Bunsubscribe@googlegroups•com>>>
>      >      >      >> <mailto:bitcoindev+unsubscribe@googlegroups•com
>     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
>      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>
>      >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>
>      >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%25252Bunsubscribe@googlegroups•com>>>>.
>      >      >      >> To view this discussion on the web visit
>      >      >      >>
>      >      >
>      >
>     https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com> <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com>> <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com> <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com>>> <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer>> <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.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
>     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
>      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>
>      >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>
>      >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%25252Bunsubscribe@googlegroups•com>>>.
>      >      >      > To view this discussion on the web visit
>      >      >
>      >
>     https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com> <https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com>> <https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com> <https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.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
>     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
>      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>
>      >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>
>      >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com
>     <mailto:bitcoindev%25252Bunsubscribe@googlegroups•com>>>.
>      >      >     To view this discussion on the web visit
>      >      >
>      >
>     https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com> <https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com>> <https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com> <https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com>>>.
>      >      >
>      >
> 

-- 



 permalink raw reply	[|nested]
2024-04-20 22:21                                 ` Michael Folkson

  2024-04-21 11:43                                     ` Michael Folkson
  
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2024-04-20 23:05 UTC (permalink / raw)
  To: Michael Folkson;  bitcoindev


On 04/20/2024 06:21 PM, Michael Folkson wrote:
> It is inevitable there will be a "revert war" unless they all have to
> agree on merge decisions or communicate prior to merging. It is just a
> matter of time. Does for example Ordinal Numbers get a BIP number? I
> suspect all the new BIP editors won't agree on that.

Why do you think that a revert war is inevitable?

The Bitcoin Core repo operates in a similar way - the maintainers are 
independent and work autonomously. The maintainers do not have to agree 
on merge decisions nor do they communicate prior to merging. If there's 
disagreement about a merge decision, we talk to each other about it like 
adults and come to a mutually agreeable resolution. I don't think 
there's ever been a revert war in the history of Bitcoin.

I would expect that when there is something that is likely to be 
controversial or is ambiguous that it should be a BIP that they would 
then talk to each other about it. It doesn't have to be all or nothing - 
they can do most work without communicating, but when there's questions 
or ambiguity, then they communicate.

> Who is to blame in a "revert war" if each editor is free to merge
> whatever pull request they like? The editor who merged it? Why should
> they be removed as an editor for merging a pull request when they find
> out later a different editor disagreed with that merge decision and
> wants to revert the merge?

A revert war would be someone merging a PR that reverts another, then 
someone else (opening then) merging a PR that reverts that, and it goes 
back and forth. It would not be limited to PRs only. This would likely 
be super obvious too that they are controversially merging things as I 
would be surprised if other BIP editors didn't comment on any of those 
actions, besides the fact that many people do also watch the BIPs repo. 
Regardless, the blame is on those who are doing the reverting, and would 
be both sides.

> I'm even more concerned about future soft fork activation attempts.
> These don't necessarily need to be attempted via a Bitcoin Core merged
> pull request hence the BIPs repo could be a key source of information
> and guidance on this.

This concern doesn't make any sense. There are already multiple soft and 
hard fork BIPs that are not active nor good ideas. A BIP does not need 
to be a good idea.

> I've seen Wladimir is contributing again to Core. Is there a plan to
> give him commit access again?

It would have to be through the typical maintainer process, although I 
doubt that he even wants it. But that's completely orthogonal to the 
BIPs repo discussion.

> I'd be more comfortable with him
> overseeing things in the various repos under the Bitcoin Core
> (/bitcoin) GitHub org as it sounds like you don't really care if the
> BIPs repo degenerates into a free for all.

I don't understand why you assume that.

I've said this before, but if I see a revert war going on in the BIPs 
repo, I will remove those involved immediately and make a thread on the 
list to discuss what to do about them. But I doubt that's a scenario 
that will actually come to pass.

Ava

> 
> Thanks
> Michael
> 
> On Sat, Apr 20, 2024 at 10:15 PM 'Ava Chow' via Bitcoin Development
> Mailing List <bitcoindev@googlegroups.com> wrote:
>>
>> On 04/20/2024 04:46 PM, Steve Lee wrote:
>>> Wasn't there evidence provided that Kanzure does not want this
>>> responsibility without being paid?
>>
>> I am not aware of that, and it hasn't come up when I've talked to him
>> about being a BIPs editor.
>>
>>> I'm confused by this process that we don't even ask the people if they
>>> want the responsibility? I think only Laolu has chimed in to commit to it?
>>
>> Personally, I've spoken to all 5 privately and they've all confirmed to
>> me that they are willing to be BIPs editors. Jonatack[1] and Murch[2]
>> have also replied to this thread about this.
>>
>> Ava
>>
>> [1]:
>> https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/
>> [2]:
>> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
>>
>>>
>>> On Sat, Apr 20, 2024 at 12:30 PM 'Ava Chow' via Bitcoin Development
>>> Mailing List <bitcoindev@googlegroups.com
>>> <mailto:bitcoindev@googlegroups.com>> wrote:
>>>
>>>      Since we're now past the deadline of April 19th, I'd like to inform
>>>      everyone of what will happen on Monday.
>>>
>>>      There has not been any actual objections to the nominees nor have there
>>>      been any suggestions on choosing a subset of them since my last email.
>>>      As such, there is rough consensus on adding Kanzure, Murch, Jonatack,
>>>      Ruben, and Roasbeef as BIP editors, and they will be added on Monday
>>>      April 22nd.
>>>
>>>      Ava
>>>
>>>      On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development Mailing List
>>>      wrote:
>>>       > While I don't disagree that 5 or 6 people seems like a lot to add at
>>>       > once, it's not clear to me how we should decide which subset of the
>>>       > nominees should be added. As it is now, I have only seen an actual
>>>       > objection to Kanzure and Ruben from /dev/fd0, and no explicit
>>>      objections
>>>       > to anyone else. It seems like the vast majority of people don't share
>>>       > their concerns either as both Kanzure and Ruben continue to be
>>>      endorsed
>>>       > by many others.
>>>       >
>>>       > Looking at the endorsements each candidate has received, the current
>>>       > counts are:
>>>       > * Kanzure - 17 for, 1 against
>>>       > * Murch - 13 for
>>>       > * Jonatack - 13 for
>>>       > * Ruben - 12 for, 1 against
>>>       > * Roasbeef - 9 for
>>>       > * Michael Folkson - none
>>>       >
>>>       > However, I don't want this process to become a popularity contest and
>>>       > require some kind of formal voting. Rather I'd prefer that this
>>>      process
>>>       > be something more like how Bitcoin Core maintainers are added - by
>>>       > achieving rough consensus. Without any explicit objections to any of
>>>       > these candidates, I'm inclined to move forward with adding the 5 who
>>>       > have received endorsements. Having to pick "winners" from this list
>>>       > seems like a quick way to stir up drama that I don't think anyone
>>>      really
>>>       > wants to deal with.
>>>       >
>>>       > I do want to note that neither Kanzure, Ruben, nor Roasbeef have
>>>      posted
>>>       > on this list that they are willing to be BIP editors. I have
>>>      reached out
>>>       > to all 3 of them privately, and received responses from Kanzure and
>>>       > Ruben that indicate that they probably are willing, but public
>>>       > confirmation from them on this list would also be nice. I have not
>>>       > received a response from Roasbeef.
>>>       >
>>>       > Ava
>>>       >
>>>       > On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
>>>       >>   > I would prefer having more (9+?) than less folks on this
>>>      task, so
>>>       >> personal preferences are easily ignored and overwritten by the group
>>>       >> majority.
>>>       >>
>>>       >> I disagree with that, the more doesn't really the better here.
>>>      Having
>>>       >> too many editors may result in a tragedy of the commons, in
>>>      which people
>>>       >> just commit to the job because many others do, and they do not
>>>      end up
>>>       >> doing as much because they expect others to do the it. This does not
>>>       >> only make the process look bad but may burnout the ones that end up
>>>       >> doing the job, given their time commitment ends up being too far
>>>      from
>>>       >> their expectations.
>>>       >>
>>>       >> I think being more moderate with the amount of people is better, and
>>>       >> gives us leeway in case the workload ends up being excessive and
>>>      we need
>>>       >> to add more people (plus discourage people from joining and
>>>      slacking off).
>>>       >>
>>>       >> I think 3 more people should be a good number to start from.
>>>       >> I'd personally vouch for Murch, Kanzure, and Ruben based on
>>>      their track
>>>       >> record in the space
>>>       >>
>>>       >> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com
>>>      <mailto:rdlfnvk@gmail•com>
>>>       >> <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>>> wrote:
>>>       >>
>>>       >> +1 for
>>>       >> Kanzure
>>>       >> RubenSomsen
>>>       >> Seccour
>>>       >> Jon Atack
>>>       >> Roasbeef
>>>       >>
>>>       >> I would prefer having more (9+?) than less folks on this task, so
>>>       >> personal preferences are easily ignored and overwritten by the group
>>>       >> majority.
>>>       >>
>>>       >> BIPs were intended as a means to collect ideas, not enforce ideas.
>>>       >>
>>>       >> I'd like to return to that.
>>>       >>
>>>       >> - NVK (temp gmail account)
>>>       >>
>>>       >>      On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A.
>>>      Harding wrote:
>>>       >>
>>>       >>          On 2024-03-28 10:04, Matt Corallo wrote:
>>>       >>           > Please provide justification rather than simply
>>>      saying "I
>>>       >>          like Bob!".
>>>       >>
>>>       >>          Using only comments from the mailing list, the
>>>      following appears
>>>       >>          to be
>>>       >>          the candidate list along with the current support.
>>>      Asterisks denote
>>>       >>          candidates who indicated their willingness to accept
>>>      the role.
>>>       >>
>>>       >>          - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris
>>>       >>          Stewart[3],
>>>       >>          Michael Folkson[6], Peter Todd[9], Matt Corallo[10],
>>>      Brandon
>>>       >>          Black[11],
>>>       >>          Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>>>       >>          Carvalho[16]
>>>       >>
>>>       >>          - Ruben Somsen, recommended by Ava Chow[1], Chris
>>>      Stewart[3],
>>>       >>          Michael
>>>       >>          Folkson[6], Antoine Riard[12], Murch[13], Antoine
>>>      Poinsot[15], John
>>>       >>          Carvalho[16]
>>>       >>
>>>       >>          - Jon Atack*, recommended by Luke Dashjr[2], Chris
>>>      Stewart[3],
>>>       >>          /dev/fd0[5][7],
>>>       >>          Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
>>>       >>          Carvalho[16]
>>>       >>
>>>       >>          - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
>>>       >>          Stewart[3], John
>>>       >>          C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8],
>>>      Antoine
>>>       >>          Riard[12], Ava Chow[14]
>>>       >>
>>>       >>          - Mark "Murch" Erhardt*, recommended by Michael
>>>      Folkson[6], Keagan
>>>       >>          McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine
>>>       >>          Riard[12],
>>>       >>          Ava Chow[14]
>>>       >>
>>>       >>          - Michael Folkson*
>>>       >>
>>>       >>          Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for
>>>       >>          "non-dev
>>>       >>          triaging", Tonoski proposed himself[18] for "BIP
>>>      editor", and
>>>       >>          Antoine
>>>       >>          Riard[12] proposed Seccour for "decentralized PM".
>>>       >>
>>>       >>          I searched the BIPs repo by commenter to see if any of
>>>      the above
>>>       >>          candidates had been especially active there, which is
>>>      listed
>>>       >>          below as:
>>>       >>          total PRs they commented on (number still open/number
>>>      closed).
>>>       >>
>>>       >>          - 21 (1/20) commenter:kanzure
>>>       >>          - 3 (2/1) commenter:rubensomsen
>>>       >>          - 15 (0/15) commenter:jonatack
>>>       >>          - 18 (2/16) commenter:roasbeef
>>>       >>          - 10 (6/4) commenter:Murchandamus
>>>       >>          - 57 (6/51) commenter:michaelfolkson
>>>       >>
>>>       >>          I'll also note that Osuntokun is the only member of the
>>>      set to
>>>       >>          have a
>>>       >>          merged BIP that they co-authored, although I believe
>>>      there are
>>>       >>          far-along
>>>       >>          draft BIPs for both Murch (terminology) and Somsen (Silent
>>>       >>          Payments). I
>>>       >>          don't think this should be a requirement, but I do think it
>>>       >>          demonstrates
>>>       >>          familiarity with the process.
>>>       >>
>>>       >>          Speaking only for myself, I think all of the candidates
>>>      above with
>>>       >>          multiple recommendations from other community
>>>      participants are
>>>       >>          fully
>>>       >>          qualified for the role, so I'll only provide a detailed
>>>       >>          justification
>>>       >>          for the person who would be my first pick: Murch is not
>>>      only a
>>>       >>          longstanding and broadly liked Bitcoin contributor, but
>>>      (as Corallo
>>>       >>          mentioned) he has worked on standardizing terminology
>>>      through a
>>>       >>          draft
>>>       >>          BIP. In addition, he provided an extremely detailed
>>>      review of
>>>       >>          all 300
>>>       >>          pages of a draft of Mastering Bitcoin (3rd edition) and has
>>>       >>          reviewed
>>>       >>          drafts of over 200 weekly Optech newsletters, in both cases
>>>       >>          significantly improving the accuracy and
>>>      comprehensibility of the
>>>       >>          documentation. To me, that seems very similar to the
>>>      work we'd
>>>       >>          ask him
>>>       >>          to perform as a BIPs editor and it's something that
>>>      he's already
>>>       >>          doing,
>>>       >>          so I think there's an excellent fit of person to role.
>>>       >>
>>>       >>          -Dave
>>>       >>
>>>       >>          [1]
>>>       >>
>>>      https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
>>>      <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>>
>>>       >>          [2]
>>>       >>
>>>      https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
>>>      <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>
>>>      <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>>
>>>       >>          [3]
>>>       >>
>>>      https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>>
>>>       >>          [4]
>>>       >>
>>>      https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>>
>>>       >>          [5]
>>>       >>
>>>      https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>>
>>>       >>          [6]
>>>       >>
>>>      https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>>
>>>       >>          [7]
>>>       >>
>>>      https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>>
>>>       >>          [8]
>>>       >>
>>>      https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>>
>>>       >>          [9]
>>>      https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>>>      <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
>>>       >>
>>>      <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
>>>      <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>>
>>>       >>          [10]
>>>       >>
>>>      https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>>
>>>       >>          [11]
>>>      https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>>>      <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>>>       >>
>>>      <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>>>      <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>
>>>       >>          [12]
>>>       >>
>>>      https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>>
>>>       >>          [13]
>>>       >>
>>>      https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
>>>      <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>
>>>      <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>>
>>>       >>          [14]
>>>       >>
>>>      https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
>>>      <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>>
>>>       >>          [15]
>>>       >>
>>>      https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/> <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>>
>>>       >>          [16]
>>>       >>
>>>      https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>>
>>>       >>          [17]
>>>       >>
>>>      https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
>>>      <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
>>>       >>      <mailto:bitcoindev+unsubscribe@googlegroups•com
>>>      <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>>.
>>>       >>      To view this discussion on the web visit
>>>       >>
>>>      https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com> <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>>>       >>
>>>       >>
>>>       >>
>>>       >> --
>>>       >> Sergi.
>>>       >>
>>>       >> --
>>>       >> 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
>>>      <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
>>>       >> <mailto:bitcoindev+unsubscribe@googlegroups•com
>>>      <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>>.
>>>       >> To view this discussion on the web visit
>>>       >>
>>>      https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com> <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.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
>>>      <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
>>>       > To view this discussion on the web visit
>>>      https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.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
>>>      <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
>>>      To view this discussion on the web visit
>>>      https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com>.
>>>
>>
>> --
>> 


 permalink raw reply	[|nested]
2024-04-20 23:05                                   ` 'Ava Chow' via Bitcoin Development Mailing List

  2024-04-21 16:39                                       ` 'Ava Chow' via Bitcoin Development Mailing List
  
From: Michael Folkson @ 2024-04-21 11:43 UTC (permalink / raw)
  To: Ava Chow;  bitcoindev

Ava

Thanks for the detailed response, I appreciate the insight.

>> I'm even more concerned about future soft fork activation attempts.
>> These don't necessarily need to be attempted via a Bitcoin Core merged
>> pull request hence the BIPs repo could be a key source of information
>> and guidance on this.

> This concern doesn't make any sense. There are already multiple soft and
> hard fork BIPs that are not active nor good ideas. A BIP does not need
> to be a good idea.

I would hope that a contentious soft fork and activation params for
that contentious soft fork would not be merged into the Bitcoin Core
codebase and up until now it hasn't been. I would hope all the Bitcoin
Core maintainers understand that even if they personally think a soft
fork is a good idea (apparently there is nothing to stop them merging
it without discussing it with the other maintainers) that they
shouldn't independently merge it if it is contentious.

Similarly I would hope that all BIP editors would be careful about
what information gets merged around soft fork activation *attempts*
whether that be activation details on a particular soft fork BIP or on
a separate activation BIP. With Taproot there were very strong
disagreements over activation parameters for a non-contentious soft
fork. It would be much messier for a contentious soft fork activation
attempt. I'm not sure all these new BIP editors understand that or
would perhaps even agree with that. For example Laolu is listed as a
supporter of a CTV activation attempt back in 2022 [0] which was
clearly contentious. That doesn't inspire me with confidence that as
soon as he is a BIP editor he won't start merging details on
contentious soft fork activation attempts in BIPs and merging that
soft fork in say btcd. He would need to be removed as a BIP editor if
he were to do something like that.

Thanks
Michael

[0]: https://utxos.org/signals/



On Sun, Apr 21, 2024 at 12:05 AM Ava Chow <lists@achow101•com> wrote:
>
>
> On 04/20/2024 06:21 PM, Michael Folkson wrote:
> > It is inevitable there will be a "revert war" unless they all have to
> > agree on merge decisions or communicate prior to merging. It is just a
> > matter of time. Does for example Ordinal Numbers get a BIP number? I
> > suspect all the new BIP editors won't agree on that.
>
> Why do you think that a revert war is inevitable?
>
> The Bitcoin Core repo operates in a similar way - the maintainers are
> independent and work autonomously. The maintainers do not have to agree
> on merge decisions nor do they communicate prior to merging. If there's
> disagreement about a merge decision, we talk to each other about it like
> adults and come to a mutually agreeable resolution. I don't think
> there's ever been a revert war in the history of Bitcoin.
>
> I would expect that when there is something that is likely to be
> controversial or is ambiguous that it should be a BIP that they would
> then talk to each other about it. It doesn't have to be all or nothing -
> they can do most work without communicating, but when there's questions
> or ambiguity, then they communicate.
>
> > Who is to blame in a "revert war" if each editor is free to merge
> > whatever pull request they like? The editor who merged it? Why should
> > they be removed as an editor for merging a pull request when they find
> > out later a different editor disagreed with that merge decision and
> > wants to revert the merge?
>
> A revert war would be someone merging a PR that reverts another, then
> someone else (opening then) merging a PR that reverts that, and it goes
> back and forth. It would not be limited to PRs only. This would likely
> be super obvious too that they are controversially merging things as I
> would be surprised if other BIP editors didn't comment on any of those
> actions, besides the fact that many people do also watch the BIPs repo.
> Regardless, the blame is on those who are doing the reverting, and would
> be both sides.
>
> > I'm even more concerned about future soft fork activation attempts.
> > These don't necessarily need to be attempted via a Bitcoin Core merged
> > pull request hence the BIPs repo could be a key source of information
> > and guidance on this.
>
> This concern doesn't make any sense. There are already multiple soft and
> hard fork BIPs that are not active nor good ideas. A BIP does not need
> to be a good idea.
>
> > I've seen Wladimir is contributing again to Core. Is there a plan to
> > give him commit access again?
>
> It would have to be through the typical maintainer process, although I
> doubt that he even wants it. But that's completely orthogonal to the
> BIPs repo discussion.
>
> > I'd be more comfortable with him
> > overseeing things in the various repos under the Bitcoin Core
> > (/bitcoin) GitHub org as it sounds like you don't really care if the
> > BIPs repo degenerates into a free for all.
>
> I don't understand why you assume that.
>
> I've said this before, but if I see a revert war going on in the BIPs
> repo, I will remove those involved immediately and make a thread on the
> list to discuss what to do about them. But I doubt that's a scenario
> that will actually come to pass.
>
> Ava
>
> >
> > Thanks
> > Michael
> >
> > On Sat, Apr 20, 2024 at 10:15 PM 'Ava Chow' via Bitcoin Development
> > Mailing List <bitcoindev@googlegroups.com> wrote:
> >>
> >> On 04/20/2024 04:46 PM, Steve Lee wrote:
> >>> Wasn't there evidence provided that Kanzure does not want this
> >>> responsibility without being paid?
> >>
> >> I am not aware of that, and it hasn't come up when I've talked to him
> >> about being a BIPs editor.
> >>
> >>> I'm confused by this process that we don't even ask the people if they
> >>> want the responsibility? I think only Laolu has chimed in to commit to it?
> >>
> >> Personally, I've spoken to all 5 privately and they've all confirmed to
> >> me that they are willing to be BIPs editors. Jonatack[1] and Murch[2]
> >> have also replied to this thread about this.
> >>
> >> Ava
> >>
> >> [1]:
> >> https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/
> >> [2]:
> >> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> >>
> >>>
> >>> On Sat, Apr 20, 2024 at 12:30 PM 'Ava Chow' via Bitcoin Development
> >>> Mailing List <bitcoindev@googlegroups.com
> >>> <mailto:bitcoindev@googlegroups.com>> wrote:
> >>>
> >>>      Since we're now past the deadline of April 19th, I'd like to inform
> >>>      everyone of what will happen on Monday.
> >>>
> >>>      There has not been any actual objections to the nominees nor have there
> >>>      been any suggestions on choosing a subset of them since my last email.
> >>>      As such, there is rough consensus on adding Kanzure, Murch, Jonatack,
> >>>      Ruben, and Roasbeef as BIP editors, and they will be added on Monday
> >>>      April 22nd.
> >>>
> >>>      Ava
> >>>
> >>>      On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development Mailing List
> >>>      wrote:
> >>>       > While I don't disagree that 5 or 6 people seems like a lot to add at
> >>>       > once, it's not clear to me how we should decide which subset of the
> >>>       > nominees should be added. As it is now, I have only seen an actual
> >>>       > objection to Kanzure and Ruben from /dev/fd0, and no explicit
> >>>      objections
> >>>       > to anyone else. It seems like the vast majority of people don't share
> >>>       > their concerns either as both Kanzure and Ruben continue to be
> >>>      endorsed
> >>>       > by many others.
> >>>       >
> >>>       > Looking at the endorsements each candidate has received, the current
> >>>       > counts are:
> >>>       > * Kanzure - 17 for, 1 against
> >>>       > * Murch - 13 for
> >>>       > * Jonatack - 13 for
> >>>       > * Ruben - 12 for, 1 against
> >>>       > * Roasbeef - 9 for
> >>>       > * Michael Folkson - none
> >>>       >
> >>>       > However, I don't want this process to become a popularity contest and
> >>>       > require some kind of formal voting. Rather I'd prefer that this
> >>>      process
> >>>       > be something more like how Bitcoin Core maintainers are added - by
> >>>       > achieving rough consensus. Without any explicit objections to any of
> >>>       > these candidates, I'm inclined to move forward with adding the 5 who
> >>>       > have received endorsements. Having to pick "winners" from this list
> >>>       > seems like a quick way to stir up drama that I don't think anyone
> >>>      really
> >>>       > wants to deal with.
> >>>       >
> >>>       > I do want to note that neither Kanzure, Ruben, nor Roasbeef have
> >>>      posted
> >>>       > on this list that they are willing to be BIP editors. I have
> >>>      reached out
> >>>       > to all 3 of them privately, and received responses from Kanzure and
> >>>       > Ruben that indicate that they probably are willing, but public
> >>>       > confirmation from them on this list would also be nice. I have not
> >>>       > received a response from Roasbeef.
> >>>       >
> >>>       > Ava
> >>>       >
> >>>       > On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
> >>>       >>   > I would prefer having more (9+?) than less folks on this
> >>>      task, so
> >>>       >> personal preferences are easily ignored and overwritten by the group
> >>>       >> majority.
> >>>       >>
> >>>       >> I disagree with that, the more doesn't really the better here.
> >>>      Having
> >>>       >> too many editors may result in a tragedy of the commons, in
> >>>      which people
> >>>       >> just commit to the job because many others do, and they do not
> >>>      end up
> >>>       >> doing as much because they expect others to do the it. This does not
> >>>       >> only make the process look bad but may burnout the ones that end up
> >>>       >> doing the job, given their time commitment ends up being too far
> >>>      from
> >>>       >> their expectations.
> >>>       >>
> >>>       >> I think being more moderate with the amount of people is better, and
> >>>       >> gives us leeway in case the workload ends up being excessive and
> >>>      we need
> >>>       >> to add more people (plus discourage people from joining and
> >>>      slacking off).
> >>>       >>
> >>>       >> I think 3 more people should be a good number to start from.
> >>>       >> I'd personally vouch for Murch, Kanzure, and Ruben based on
> >>>      their track
> >>>       >> record in the space
> >>>       >>
> >>>       >> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com
> >>>      <mailto:rdlfnvk@gmail•com>
> >>>       >> <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>>> wrote:
> >>>       >>
> >>>       >> +1 for
> >>>       >> Kanzure
> >>>       >> RubenSomsen
> >>>       >> Seccour
> >>>       >> Jon Atack
> >>>       >> Roasbeef
> >>>       >>
> >>>       >> I would prefer having more (9+?) than less folks on this task, so
> >>>       >> personal preferences are easily ignored and overwritten by the group
> >>>       >> majority.
> >>>       >>
> >>>       >> BIPs were intended as a means to collect ideas, not enforce ideas.
> >>>       >>
> >>>       >> I'd like to return to that.
> >>>       >>
> >>>       >> - NVK (temp gmail account)
> >>>       >>
> >>>       >>      On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A.
> >>>      Harding wrote:
> >>>       >>
> >>>       >>          On 2024-03-28 10:04, Matt Corallo wrote:
> >>>       >>           > Please provide justification rather than simply
> >>>      saying "I
> >>>       >>          like Bob!".
> >>>       >>
> >>>       >>          Using only comments from the mailing list, the
> >>>      following appears
> >>>       >>          to be
> >>>       >>          the candidate list along with the current support.
> >>>      Asterisks denote
> >>>       >>          candidates who indicated their willingness to accept
> >>>      the role.
> >>>       >>
> >>>       >>          - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris
> >>>       >>          Stewart[3],
> >>>       >>          Michael Folkson[6], Peter Todd[9], Matt Corallo[10],
> >>>      Brandon
> >>>       >>          Black[11],
> >>>       >>          Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
> >>>       >>          Carvalho[16]
> >>>       >>
> >>>       >>          - Ruben Somsen, recommended by Ava Chow[1], Chris
> >>>      Stewart[3],
> >>>       >>          Michael
> >>>       >>          Folkson[6], Antoine Riard[12], Murch[13], Antoine
> >>>      Poinsot[15], John
> >>>       >>          Carvalho[16]
> >>>       >>
> >>>       >>          - Jon Atack*, recommended by Luke Dashjr[2], Chris
> >>>      Stewart[3],
> >>>       >>          /dev/fd0[5][7],
> >>>       >>          Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
> >>>       >>          Carvalho[16]
> >>>       >>
> >>>       >>          - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
> >>>       >>          Stewart[3], John
> >>>       >>          C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8],
> >>>      Antoine
> >>>       >>          Riard[12], Ava Chow[14]
> >>>       >>
> >>>       >>          - Mark "Murch" Erhardt*, recommended by Michael
> >>>      Folkson[6], Keagan
> >>>       >>          McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine
> >>>       >>          Riard[12],
> >>>       >>          Ava Chow[14]
> >>>       >>
> >>>       >>          - Michael Folkson*
> >>>       >>
> >>>       >>          Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for
> >>>       >>          "non-dev
> >>>       >>          triaging", Tonoski proposed himself[18] for "BIP
> >>>      editor", and
> >>>       >>          Antoine
> >>>       >>          Riard[12] proposed Seccour for "decentralized PM".
> >>>       >>
> >>>       >>          I searched the BIPs repo by commenter to see if any of
> >>>      the above
> >>>       >>          candidates had been especially active there, which is
> >>>      listed
> >>>       >>          below as:
> >>>       >>          total PRs they commented on (number still open/number
> >>>      closed).
> >>>       >>
> >>>       >>          - 21 (1/20) commenter:kanzure
> >>>       >>          - 3 (2/1) commenter:rubensomsen
> >>>       >>          - 15 (0/15) commenter:jonatack
> >>>       >>          - 18 (2/16) commenter:roasbeef
> >>>       >>          - 10 (6/4) commenter:Murchandamus
> >>>       >>          - 57 (6/51) commenter:michaelfolkson
> >>>       >>
> >>>       >>          I'll also note that Osuntokun is the only member of the
> >>>      set to
> >>>       >>          have a
> >>>       >>          merged BIP that they co-authored, although I believe
> >>>      there are
> >>>       >>          far-along
> >>>       >>          draft BIPs for both Murch (terminology) and Somsen (Silent
> >>>       >>          Payments). I
> >>>       >>          don't think this should be a requirement, but I do think it
> >>>       >>          demonstrates
> >>>       >>          familiarity with the process.
> >>>       >>
> >>>       >>          Speaking only for myself, I think all of the candidates
> >>>      above with
> >>>       >>          multiple recommendations from other community
> >>>      participants are
> >>>       >>          fully
> >>>       >>          qualified for the role, so I'll only provide a detailed
> >>>       >>          justification
> >>>       >>          for the person who would be my first pick: Murch is not
> >>>      only a
> >>>       >>          longstanding and broadly liked Bitcoin contributor, but
> >>>      (as Corallo
> >>>       >>          mentioned) he has worked on standardizing terminology
> >>>      through a
> >>>       >>          draft
> >>>       >>          BIP. In addition, he provided an extremely detailed
> >>>      review of
> >>>       >>          all 300
> >>>       >>          pages of a draft of Mastering Bitcoin (3rd edition) and has
> >>>       >>          reviewed
> >>>       >>          drafts of over 200 weekly Optech newsletters, in both cases
> >>>       >>          significantly improving the accuracy and
> >>>      comprehensibility of the
> >>>       >>          documentation. To me, that seems very similar to the
> >>>      work we'd
> >>>       >>          ask him
> >>>       >>          to perform as a BIPs editor and it's something that
> >>>      he's already
> >>>       >>          doing,
> >>>       >>          so I think there's an excellent fit of person to role.
> >>>       >>
> >>>       >>          -Dave
> >>>       >>
> >>>       >>          [1]
> >>>       >>
> >>>      https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
> >>>      <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>>
> >>>       >>          [2]
> >>>       >>
> >>>      https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
> >>>      <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>
> >>>      <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>>
> >>>       >>          [3]
> >>>       >>
> >>>      https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>>
> >>>       >>          [4]
> >>>       >>
> >>>      https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>>
> >>>       >>          [5]
> >>>       >>
> >>>      https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>>
> >>>       >>          [6]
> >>>       >>
> >>>      https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>>
> >>>       >>          [7]
> >>>       >>
> >>>      https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>>
> >>>       >>          [8]
> >>>       >>
> >>>      https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>>
> >>>       >>          [9]
> >>>      https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> >>>      <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
> >>>       >>
> >>>      <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
> >>>      <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>>
> >>>       >>          [10]
> >>>       >>
> >>>      https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>>
> >>>       >>          [11]
> >>>      https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >>>      <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
> >>>       >>
> >>>      <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >>>      <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>
> >>>       >>          [12]
> >>>       >>
> >>>      https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>>
> >>>       >>          [13]
> >>>       >>
> >>>      https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
> >>>      <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>
> >>>      <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>>
> >>>       >>          [14]
> >>>       >>
> >>>      https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
> >>>      <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>>
> >>>       >>          [15]
> >>>       >>
> >>>      https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/> <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>>
> >>>       >>          [16]
> >>>       >>
> >>>      https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>>
> >>>       >>          [17]
> >>>       >>
> >>>      https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
> >>>      <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >>>       >>      <mailto:bitcoindev+unsubscribe@googlegroups•com
> >>>      <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>>.
> >>>       >>      To view this discussion on the web visit
> >>>       >>
> >>>      https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com> <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> >>>       >>
> >>>       >>
> >>>       >>
> >>>       >> --
> >>>       >> Sergi.
> >>>       >>
> >>>       >> --
> >>>       >> 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
> >>>      <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >>>       >> <mailto:bitcoindev+unsubscribe@googlegroups•com
> >>>      <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>>.
> >>>       >> To view this discussion on the web visit
> >>>       >>
> >>>      https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com> <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.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
> >>>      <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
> >>>       > To view this discussion on the web visit
> >>>      https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.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
> >>>      <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
> >>>      To view this discussion on the web visit
> >>>      https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com>.
> >>>
> >>
> >> --
> >> 


 permalink raw reply	[|nested]
2024-04-21 11:43                                     ` Michael Folkson

  2024-04-21 17:57                                         ` Michael Folkson
  
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2024-04-21 16:39 UTC (permalink / raw)
  To: Michael Folkson;  bitcoindev

You are misunderstanding the role of BIP editors. They are not arbiters 
of what is activated on Bitcoin. They are not gatekeepers of soft forks. 
If a BIP author proposes or agrees with a change to their BIP and those 
changes are formatted correctly, it is not the BIP editors' rights nor 
responsibilities to refuse to merge that change. As with Bitcoin Core 
maintainers, BIP editing is a largely janitorial role.

Just because something is a BIP does not mean it is a good idea. Just 
because a BIP specifying a fork contains deployment parameters does not 
mean it will actually be deployed. There are several BIPs for both hard 
and soft forks that are rejected or withdrawn that have deployment 
parameters.

Furthermore, for myself, I would actually prefer that contentious soft 
forks for which some people are legitimately attempting to activate have 
their deployment parameters be specified in a/the BIP. Having competing 
activation parameters in different BIPs is preferable over the 
documentation being spread around in many different places. It makes it 
much easier for implementations to inform users what they've actually 
implemented so that users can make a more informed decision.

On 04/21/2024 07:43 AM, Michael Folkson wrote:
> Ava
> 
> Thanks for the detailed response, I appreciate the insight.
> 
>>> I'm even more concerned about future soft fork activation attempts.
>>> These don't necessarily need to be attempted via a Bitcoin Core merged
>>> pull request hence the BIPs repo could be a key source of information
>>> and guidance on this.
> 
>> This concern doesn't make any sense. There are already multiple soft and
>> hard fork BIPs that are not active nor good ideas. A BIP does not need
>> to be a good idea.
> 
> I would hope that a contentious soft fork and activation params for
> that contentious soft fork would not be merged into the Bitcoin Core
> codebase and up until now it hasn't been. I would hope all the Bitcoin
> Core maintainers understand that even if they personally think a soft
> fork is a good idea (apparently there is nothing to stop them merging
> it without discussing it with the other maintainers) that they
> shouldn't independently merge it if it is contentious.
> 
> Similarly I would hope that all BIP editors would be careful about
> what information gets merged around soft fork activation *attempts*
> whether that be activation details on a particular soft fork BIP or on
> a separate activation BIP. With Taproot there were very strong
> disagreements over activation parameters for a non-contentious soft
> fork. It would be much messier for a contentious soft fork activation
> attempt. I'm not sure all these new BIP editors understand that or
> would perhaps even agree with that. For example Laolu is listed as a
> supporter of a CTV activation attempt back in 2022 [0] which was
> clearly contentious. That doesn't inspire me with confidence that as
> soon as he is a BIP editor he won't start merging details on
> contentious soft fork activation attempts in BIPs and merging that
> soft fork in say btcd. He would need to be removed as a BIP editor if
> he were to do something like that.
> 
> Thanks
> Michael
> 
> [0]: https://utxos.org/signals/
> 
> 
> 
> On Sun, Apr 21, 2024 at 12:05 AM Ava Chow <lists@achow101•com> wrote:
>>
>>
>> On 04/20/2024 06:21 PM, Michael Folkson wrote:
>>> It is inevitable there will be a "revert war" unless they all have to
>>> agree on merge decisions or communicate prior to merging. It is just a
>>> matter of time. Does for example Ordinal Numbers get a BIP number? I
>>> suspect all the new BIP editors won't agree on that.
>>
>> Why do you think that a revert war is inevitable?
>>
>> The Bitcoin Core repo operates in a similar way - the maintainers are
>> independent and work autonomously. The maintainers do not have to agree
>> on merge decisions nor do they communicate prior to merging. If there's
>> disagreement about a merge decision, we talk to each other about it like
>> adults and come to a mutually agreeable resolution. I don't think
>> there's ever been a revert war in the history of Bitcoin.
>>
>> I would expect that when there is something that is likely to be
>> controversial or is ambiguous that it should be a BIP that they would
>> then talk to each other about it. It doesn't have to be all or nothing -
>> they can do most work without communicating, but when there's questions
>> or ambiguity, then they communicate.
>>
>>> Who is to blame in a "revert war" if each editor is free to merge
>>> whatever pull request they like? The editor who merged it? Why should
>>> they be removed as an editor for merging a pull request when they find
>>> out later a different editor disagreed with that merge decision and
>>> wants to revert the merge?
>>
>> A revert war would be someone merging a PR that reverts another, then
>> someone else (opening then) merging a PR that reverts that, and it goes
>> back and forth. It would not be limited to PRs only. This would likely
>> be super obvious too that they are controversially merging things as I
>> would be surprised if other BIP editors didn't comment on any of those
>> actions, besides the fact that many people do also watch the BIPs repo.
>> Regardless, the blame is on those who are doing the reverting, and would
>> be both sides.
>>
>>> I'm even more concerned about future soft fork activation attempts.
>>> These don't necessarily need to be attempted via a Bitcoin Core merged
>>> pull request hence the BIPs repo could be a key source of information
>>> and guidance on this.
>>
>> This concern doesn't make any sense. There are already multiple soft and
>> hard fork BIPs that are not active nor good ideas. A BIP does not need
>> to be a good idea.
>>
>>> I've seen Wladimir is contributing again to Core. Is there a plan to
>>> give him commit access again?
>>
>> It would have to be through the typical maintainer process, although I
>> doubt that he even wants it. But that's completely orthogonal to the
>> BIPs repo discussion.
>>
>>> I'd be more comfortable with him
>>> overseeing things in the various repos under the Bitcoin Core
>>> (/bitcoin) GitHub org as it sounds like you don't really care if the
>>> BIPs repo degenerates into a free for all.
>>
>> I don't understand why you assume that.
>>
>> I've said this before, but if I see a revert war going on in the BIPs
>> repo, I will remove those involved immediately and make a thread on the
>> list to discuss what to do about them. But I doubt that's a scenario
>> that will actually come to pass.
>>
>> Ava
>>
>>>
>>> Thanks
>>> Michael
>>>
>>> On Sat, Apr 20, 2024 at 10:15 PM 'Ava Chow' via Bitcoin Development
>>> Mailing List <bitcoindev@googlegroups.com> wrote:
>>>>
>>>> On 04/20/2024 04:46 PM, Steve Lee wrote:
>>>>> Wasn't there evidence provided that Kanzure does not want this
>>>>> responsibility without being paid?
>>>>
>>>> I am not aware of that, and it hasn't come up when I've talked to him
>>>> about being a BIPs editor.
>>>>
>>>>> I'm confused by this process that we don't even ask the people if they
>>>>> want the responsibility? I think only Laolu has chimed in to commit to it?
>>>>
>>>> Personally, I've spoken to all 5 privately and they've all confirmed to
>>>> me that they are willing to be BIPs editors. Jonatack[1] and Murch[2]
>>>> have also replied to this thread about this.
>>>>
>>>> Ava
>>>>
>>>> [1]:
>>>> https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/
>>>> [2]:
>>>> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
>>>>
>>>>>
>>>>> On Sat, Apr 20, 2024 at 12:30 PM 'Ava Chow' via Bitcoin Development
>>>>> Mailing List <bitcoindev@googlegroups.com
>>>>> <mailto:bitcoindev@googlegroups.com>> wrote:
>>>>>
>>>>>       Since we're now past the deadline of April 19th, I'd like to inform
>>>>>       everyone of what will happen on Monday.
>>>>>
>>>>>       There has not been any actual objections to the nominees nor have there
>>>>>       been any suggestions on choosing a subset of them since my last email.
>>>>>       As such, there is rough consensus on adding Kanzure, Murch, Jonatack,
>>>>>       Ruben, and Roasbeef as BIP editors, and they will be added on Monday
>>>>>       April 22nd.
>>>>>
>>>>>       Ava
>>>>>
>>>>>       On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development Mailing List
>>>>>       wrote:
>>>>>        > While I don't disagree that 5 or 6 people seems like a lot to add at
>>>>>        > once, it's not clear to me how we should decide which subset of the
>>>>>        > nominees should be added. As it is now, I have only seen an actual
>>>>>        > objection to Kanzure and Ruben from /dev/fd0, and no explicit
>>>>>       objections
>>>>>        > to anyone else. It seems like the vast majority of people don't share
>>>>>        > their concerns either as both Kanzure and Ruben continue to be
>>>>>       endorsed
>>>>>        > by many others.
>>>>>        >
>>>>>        > Looking at the endorsements each candidate has received, the current
>>>>>        > counts are:
>>>>>        > * Kanzure - 17 for, 1 against
>>>>>        > * Murch - 13 for
>>>>>        > * Jonatack - 13 for
>>>>>        > * Ruben - 12 for, 1 against
>>>>>        > * Roasbeef - 9 for
>>>>>        > * Michael Folkson - none
>>>>>        >
>>>>>        > However, I don't want this process to become a popularity contest and
>>>>>        > require some kind of formal voting. Rather I'd prefer that this
>>>>>       process
>>>>>        > be something more like how Bitcoin Core maintainers are added - by
>>>>>        > achieving rough consensus. Without any explicit objections to any of
>>>>>        > these candidates, I'm inclined to move forward with adding the 5 who
>>>>>        > have received endorsements. Having to pick "winners" from this list
>>>>>        > seems like a quick way to stir up drama that I don't think anyone
>>>>>       really
>>>>>        > wants to deal with.
>>>>>        >
>>>>>        > I do want to note that neither Kanzure, Ruben, nor Roasbeef have
>>>>>       posted
>>>>>        > on this list that they are willing to be BIP editors. I have
>>>>>       reached out
>>>>>        > to all 3 of them privately, and received responses from Kanzure and
>>>>>        > Ruben that indicate that they probably are willing, but public
>>>>>        > confirmation from them on this list would also be nice. I have not
>>>>>        > received a response from Roasbeef.
>>>>>        >
>>>>>        > Ava
>>>>>        >
>>>>>        > On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
>>>>>        >>   > I would prefer having more (9+?) than less folks on this
>>>>>       task, so
>>>>>        >> personal preferences are easily ignored and overwritten by the group
>>>>>        >> majority.
>>>>>        >>
>>>>>        >> I disagree with that, the more doesn't really the better here.
>>>>>       Having
>>>>>        >> too many editors may result in a tragedy of the commons, in
>>>>>       which people
>>>>>        >> just commit to the job because many others do, and they do not
>>>>>       end up
>>>>>        >> doing as much because they expect others to do the it. This does not
>>>>>        >> only make the process look bad but may burnout the ones that end up
>>>>>        >> doing the job, given their time commitment ends up being too far
>>>>>       from
>>>>>        >> their expectations.
>>>>>        >>
>>>>>        >> I think being more moderate with the amount of people is better, and
>>>>>        >> gives us leeway in case the workload ends up being excessive and
>>>>>       we need
>>>>>        >> to add more people (plus discourage people from joining and
>>>>>       slacking off).
>>>>>        >>
>>>>>        >> I think 3 more people should be a good number to start from.
>>>>>        >> I'd personally vouch for Murch, Kanzure, and Ruben based on
>>>>>       their track
>>>>>        >> record in the space
>>>>>        >>
>>>>>        >> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com
>>>>>       <mailto:rdlfnvk@gmail•com>
>>>>>        >> <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>>> wrote:
>>>>>        >>
>>>>>        >> +1 for
>>>>>        >> Kanzure
>>>>>        >> RubenSomsen
>>>>>        >> Seccour
>>>>>        >> Jon Atack
>>>>>        >> Roasbeef
>>>>>        >>
>>>>>        >> I would prefer having more (9+?) than less folks on this task, so
>>>>>        >> personal preferences are easily ignored and overwritten by the group
>>>>>        >> majority.
>>>>>        >>
>>>>>        >> BIPs were intended as a means to collect ideas, not enforce ideas.
>>>>>        >>
>>>>>        >> I'd like to return to that.
>>>>>        >>
>>>>>        >> - NVK (temp gmail account)
>>>>>        >>
>>>>>        >>      On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A.
>>>>>       Harding wrote:
>>>>>        >>
>>>>>        >>          On 2024-03-28 10:04, Matt Corallo wrote:
>>>>>        >>           > Please provide justification rather than simply
>>>>>       saying "I
>>>>>        >>          like Bob!".
>>>>>        >>
>>>>>        >>          Using only comments from the mailing list, the
>>>>>       following appears
>>>>>        >>          to be
>>>>>        >>          the candidate list along with the current support.
>>>>>       Asterisks denote
>>>>>        >>          candidates who indicated their willingness to accept
>>>>>       the role.
>>>>>        >>
>>>>>        >>          - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris
>>>>>        >>          Stewart[3],
>>>>>        >>          Michael Folkson[6], Peter Todd[9], Matt Corallo[10],
>>>>>       Brandon
>>>>>        >>          Black[11],
>>>>>        >>          Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>>>>>        >>          Carvalho[16]
>>>>>        >>
>>>>>        >>          - Ruben Somsen, recommended by Ava Chow[1], Chris
>>>>>       Stewart[3],
>>>>>        >>          Michael
>>>>>        >>          Folkson[6], Antoine Riard[12], Murch[13], Antoine
>>>>>       Poinsot[15], John
>>>>>        >>          Carvalho[16]
>>>>>        >>
>>>>>        >>          - Jon Atack*, recommended by Luke Dashjr[2], Chris
>>>>>       Stewart[3],
>>>>>        >>          /dev/fd0[5][7],
>>>>>        >>          Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
>>>>>        >>          Carvalho[16]
>>>>>        >>
>>>>>        >>          - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
>>>>>        >>          Stewart[3], John
>>>>>        >>          C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8],
>>>>>       Antoine
>>>>>        >>          Riard[12], Ava Chow[14]
>>>>>        >>
>>>>>        >>          - Mark "Murch" Erhardt*, recommended by Michael
>>>>>       Folkson[6], Keagan
>>>>>        >>          McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine
>>>>>        >>          Riard[12],
>>>>>        >>          Ava Chow[14]
>>>>>        >>
>>>>>        >>          - Michael Folkson*
>>>>>        >>
>>>>>        >>          Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for
>>>>>        >>          "non-dev
>>>>>        >>          triaging", Tonoski proposed himself[18] for "BIP
>>>>>       editor", and
>>>>>        >>          Antoine
>>>>>        >>          Riard[12] proposed Seccour for "decentralized PM".
>>>>>        >>
>>>>>        >>          I searched the BIPs repo by commenter to see if any of
>>>>>       the above
>>>>>        >>          candidates had been especially active there, which is
>>>>>       listed
>>>>>        >>          below as:
>>>>>        >>          total PRs they commented on (number still open/number
>>>>>       closed).
>>>>>        >>
>>>>>        >>          - 21 (1/20) commenter:kanzure
>>>>>        >>          - 3 (2/1) commenter:rubensomsen
>>>>>        >>          - 15 (0/15) commenter:jonatack
>>>>>        >>          - 18 (2/16) commenter:roasbeef
>>>>>        >>          - 10 (6/4) commenter:Murchandamus
>>>>>        >>          - 57 (6/51) commenter:michaelfolkson
>>>>>        >>
>>>>>        >>          I'll also note that Osuntokun is the only member of the
>>>>>       set to
>>>>>        >>          have a
>>>>>        >>          merged BIP that they co-authored, although I believe
>>>>>       there are
>>>>>        >>          far-along
>>>>>        >>          draft BIPs for both Murch (terminology) and Somsen (Silent
>>>>>        >>          Payments). I
>>>>>        >>          don't think this should be a requirement, but I do think it
>>>>>        >>          demonstrates
>>>>>        >>          familiarity with the process.
>>>>>        >>
>>>>>        >>          Speaking only for myself, I think all of the candidates
>>>>>       above with
>>>>>        >>          multiple recommendations from other community
>>>>>       participants are
>>>>>        >>          fully
>>>>>        >>          qualified for the role, so I'll only provide a detailed
>>>>>        >>          justification
>>>>>        >>          for the person who would be my first pick: Murch is not
>>>>>       only a
>>>>>        >>          longstanding and broadly liked Bitcoin contributor, but
>>>>>       (as Corallo
>>>>>        >>          mentioned) he has worked on standardizing terminology
>>>>>       through a
>>>>>        >>          draft
>>>>>        >>          BIP. In addition, he provided an extremely detailed
>>>>>       review of
>>>>>        >>          all 300
>>>>>        >>          pages of a draft of Mastering Bitcoin (3rd edition) and has
>>>>>        >>          reviewed
>>>>>        >>          drafts of over 200 weekly Optech newsletters, in both cases
>>>>>        >>          significantly improving the accuracy and
>>>>>       comprehensibility of the
>>>>>        >>          documentation. To me, that seems very similar to the
>>>>>       work we'd
>>>>>        >>          ask him
>>>>>        >>          to perform as a BIPs editor and it's something that
>>>>>       he's already
>>>>>        >>          doing,
>>>>>        >>          so I think there's an excellent fit of person to role.
>>>>>        >>
>>>>>        >>          -Dave
>>>>>        >>
>>>>>        >>          [1]
>>>>>        >>
>>>>>       https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
>>>>>       <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>>
>>>>>        >>          [2]
>>>>>        >>
>>>>>       https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
>>>>>       <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>
>>>>>       <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>>
>>>>>        >>          [3]
>>>>>        >>
>>>>>       https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>>
>>>>>        >>          [4]
>>>>>        >>
>>>>>       https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>>
>>>>>        >>          [5]
>>>>>        >>
>>>>>       https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>>
>>>>>        >>          [6]
>>>>>        >>
>>>>>       https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>>
>>>>>        >>          [7]
>>>>>        >>
>>>>>       https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>>
>>>>>        >>          [8]
>>>>>        >>
>>>>>       https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>>
>>>>>        >>          [9]
>>>>>       https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>>>>>       <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
>>>>>        >>
>>>>>       <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
>>>>>       <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>>
>>>>>        >>          [10]
>>>>>        >>
>>>>>       https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>>
>>>>>        >>          [11]
>>>>>       https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>>>>>       <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>>>>>        >>
>>>>>       <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>>>>>       <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>
>>>>>        >>          [12]
>>>>>        >>
>>>>>       https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>>
>>>>>        >>          [13]
>>>>>        >>
>>>>>       https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
>>>>>       <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>
>>>>>       <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>>
>>>>>        >>          [14]
>>>>>        >>
>>>>>       https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
>>>>>       <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>>
>>>>>        >>          [15]
>>>>>        >>
>>>>>       https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/> <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>>
>>>>>        >>          [16]
>>>>>        >>
>>>>>       https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>>
>>>>>        >>          [17]
>>>>>        >>
>>>>>       https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
>>>>>       <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
>>>>>        >>      <mailto:bitcoindev+unsubscribe@googlegroups•com
>>>>>       <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>>.
>>>>>        >>      To view this discussion on the web visit
>>>>>        >>
>>>>>       https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com> <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>>>>>        >>
>>>>>        >>
>>>>>        >>
>>>>>        >> --
>>>>>        >> Sergi.
>>>>>        >>
>>>>>        >> --
>>>>>        >> 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
>>>>>       <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
>>>>>        >> <mailto:bitcoindev+unsubscribe@googlegroups•com
>>>>>       <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>>.
>>>>>        >> To view this discussion on the web visit
>>>>>        >>
>>>>>       https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com> <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.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
>>>>>       <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
>>>>>        > To view this discussion on the web visit
>>>>>       https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.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
>>>>>       <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
>>>>>       To view this discussion on the web visit
>>>>>       https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com>.
>>>>>
>>>>
>>>> --
>>>> 


 permalink raw reply	[|nested]
2024-04-21 16:39                                       ` 'Ava Chow' via Bitcoin Development Mailing List

  2024-04-21 18:47                                           ` 'Ava Chow' via Bitcoin Development Mailing List
  
From: Michael Folkson @ 2024-04-21 17:57 UTC (permalink / raw)
  To: Ava Chow;  bitcoindev

> You are misunderstanding the role of BIP editors. They are not arbiters
of what is activated on Bitcoin. They are not gatekeepers of soft forks.
If a BIP author proposes or agrees with a change to their BIP and those
changes are formatted correctly, it is not the BIP editors' rights nor
responsibilities to refuse to merge that change. As with Bitcoin Core
maintainers, BIP editing is a largely janitorial role.

So once a BIP number is allocated (or before) the BIP author can write
whatever they like on that BIP? Including false and misleading
statements? And the BIP editors have to merge it as long as it meets
formatting requirements?

A misleading statement like "This soft fork will definitely activate
at block X as it has been merged into implementation Y. It hasn't been
merged into Bitcoin Core yet but Bitcoin Core will merge the soft fork
after the activation"

This is a step change from before. If we aren't relying on *any*
judgment then there might as well be 100 BIP editors. Because the
editors aren't doing anything, each BIP author (or champion) has total
license to write whatever they like on their BIP.

> They are not arbiters of what is activated on Bitcoin. They are not gatekeepers of soft forks.

Of course not. The BIP editors do not decide what is activated on
Bitcoin. But they are gatekeepers on ensuring BIPs are high quality
and don't include false and misleading statements. Because false and
misleading statements can impact the evolution of an activation
process.

I tried. Based on your perspective all we need is one malicious BIP
author (or champion) and they'll make the entire BIP process a joke
and the BIP editors won't be able to do anything.

Michael



On Sun, Apr 21, 2024 at 5:39 PM Ava Chow <lists@achow101•com> wrote:
>
> You are misunderstanding the role of BIP editors. They are not arbiters
> of what is activated on Bitcoin. They are not gatekeepers of soft forks.
> If a BIP author proposes or agrees with a change to their BIP and those
> changes are formatted correctly, it is not the BIP editors' rights nor
> responsibilities to refuse to merge that change. As with Bitcoin Core
> maintainers, BIP editing is a largely janitorial role.
>
> Just because something is a BIP does not mean it is a good idea. Just
> because a BIP specifying a fork contains deployment parameters does not
> mean it will actually be deployed. There are several BIPs for both hard
> and soft forks that are rejected or withdrawn that have deployment
> parameters.
>
> Furthermore, for myself, I would actually prefer that contentious soft
> forks for which some people are legitimately attempting to activate have
> their deployment parameters be specified in a/the BIP. Having competing
> activation parameters in different BIPs is preferable over the
> documentation being spread around in many different places. It makes it
> much easier for implementations to inform users what they've actually
> implemented so that users can make a more informed decision.
>
> On 04/21/2024 07:43 AM, Michael Folkson wrote:
> > Ava
> >
> > Thanks for the detailed response, I appreciate the insight.
> >
> >>> I'm even more concerned about future soft fork activation attempts.
> >>> These don't necessarily need to be attempted via a Bitcoin Core merged
> >>> pull request hence the BIPs repo could be a key source of information
> >>> and guidance on this.
> >
> >> This concern doesn't make any sense. There are already multiple soft and
> >> hard fork BIPs that are not active nor good ideas. A BIP does not need
> >> to be a good idea.
> >
> > I would hope that a contentious soft fork and activation params for
> > that contentious soft fork would not be merged into the Bitcoin Core
> > codebase and up until now it hasn't been. I would hope all the Bitcoin
> > Core maintainers understand that even if they personally think a soft
> > fork is a good idea (apparently there is nothing to stop them merging
> > it without discussing it with the other maintainers) that they
> > shouldn't independently merge it if it is contentious.
> >
> > Similarly I would hope that all BIP editors would be careful about
> > what information gets merged around soft fork activation *attempts*
> > whether that be activation details on a particular soft fork BIP or on
> > a separate activation BIP. With Taproot there were very strong
> > disagreements over activation parameters for a non-contentious soft
> > fork. It would be much messier for a contentious soft fork activation
> > attempt. I'm not sure all these new BIP editors understand that or
> > would perhaps even agree with that. For example Laolu is listed as a
> > supporter of a CTV activation attempt back in 2022 [0] which was
> > clearly contentious. That doesn't inspire me with confidence that as
> > soon as he is a BIP editor he won't start merging details on
> > contentious soft fork activation attempts in BIPs and merging that
> > soft fork in say btcd. He would need to be removed as a BIP editor if
> > he were to do something like that.
> >
> > Thanks
> > Michael
> >
> > [0]: https://utxos.org/signals/
> >
> >
> >
> > On Sun, Apr 21, 2024 at 12:05 AM Ava Chow <lists@achow101•com> wrote:
> >>
> >>
> >> On 04/20/2024 06:21 PM, Michael Folkson wrote:
> >>> It is inevitable there will be a "revert war" unless they all have to
> >>> agree on merge decisions or communicate prior to merging. It is just a
> >>> matter of time. Does for example Ordinal Numbers get a BIP number? I
> >>> suspect all the new BIP editors won't agree on that.
> >>
> >> Why do you think that a revert war is inevitable?
> >>
> >> The Bitcoin Core repo operates in a similar way - the maintainers are
> >> independent and work autonomously. The maintainers do not have to agree
> >> on merge decisions nor do they communicate prior to merging. If there's
> >> disagreement about a merge decision, we talk to each other about it like
> >> adults and come to a mutually agreeable resolution. I don't think
> >> there's ever been a revert war in the history of Bitcoin.
> >>
> >> I would expect that when there is something that is likely to be
> >> controversial or is ambiguous that it should be a BIP that they would
> >> then talk to each other about it. It doesn't have to be all or nothing -
> >> they can do most work without communicating, but when there's questions
> >> or ambiguity, then they communicate.
> >>
> >>> Who is to blame in a "revert war" if each editor is free to merge
> >>> whatever pull request they like? The editor who merged it? Why should
> >>> they be removed as an editor for merging a pull request when they find
> >>> out later a different editor disagreed with that merge decision and
> >>> wants to revert the merge?
> >>
> >> A revert war would be someone merging a PR that reverts another, then
> >> someone else (opening then) merging a PR that reverts that, and it goes
> >> back and forth. It would not be limited to PRs only. This would likely
> >> be super obvious too that they are controversially merging things as I
> >> would be surprised if other BIP editors didn't comment on any of those
> >> actions, besides the fact that many people do also watch the BIPs repo.
> >> Regardless, the blame is on those who are doing the reverting, and would
> >> be both sides.
> >>
> >>> I'm even more concerned about future soft fork activation attempts.
> >>> These don't necessarily need to be attempted via a Bitcoin Core merged
> >>> pull request hence the BIPs repo could be a key source of information
> >>> and guidance on this.
> >>
> >> This concern doesn't make any sense. There are already multiple soft and
> >> hard fork BIPs that are not active nor good ideas. A BIP does not need
> >> to be a good idea.
> >>
> >>> I've seen Wladimir is contributing again to Core. Is there a plan to
> >>> give him commit access again?
> >>
> >> It would have to be through the typical maintainer process, although I
> >> doubt that he even wants it. But that's completely orthogonal to the
> >> BIPs repo discussion.
> >>
> >>> I'd be more comfortable with him
> >>> overseeing things in the various repos under the Bitcoin Core
> >>> (/bitcoin) GitHub org as it sounds like you don't really care if the
> >>> BIPs repo degenerates into a free for all.
> >>
> >> I don't understand why you assume that.
> >>
> >> I've said this before, but if I see a revert war going on in the BIPs
> >> repo, I will remove those involved immediately and make a thread on the
> >> list to discuss what to do about them. But I doubt that's a scenario
> >> that will actually come to pass.
> >>
> >> Ava
> >>
> >>>
> >>> Thanks
> >>> Michael
> >>>
> >>> On Sat, Apr 20, 2024 at 10:15 PM 'Ava Chow' via Bitcoin Development
> >>> Mailing List <bitcoindev@googlegroups.com> wrote:
> >>>>
> >>>> On 04/20/2024 04:46 PM, Steve Lee wrote:
> >>>>> Wasn't there evidence provided that Kanzure does not want this
> >>>>> responsibility without being paid?
> >>>>
> >>>> I am not aware of that, and it hasn't come up when I've talked to him
> >>>> about being a BIPs editor.
> >>>>
> >>>>> I'm confused by this process that we don't even ask the people if they
> >>>>> want the responsibility? I think only Laolu has chimed in to commit to it?
> >>>>
> >>>> Personally, I've spoken to all 5 privately and they've all confirmed to
> >>>> me that they are willing to be BIPs editors. Jonatack[1] and Murch[2]
> >>>> have also replied to this thread about this.
> >>>>
> >>>> Ava
> >>>>
> >>>> [1]:
> >>>> https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/
> >>>> [2]:
> >>>> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> >>>>
> >>>>>
> >>>>> On Sat, Apr 20, 2024 at 12:30 PM 'Ava Chow' via Bitcoin Development
> >>>>> Mailing List <bitcoindev@googlegroups.com
> >>>>> <mailto:bitcoindev@googlegroups.com>> wrote:
> >>>>>
> >>>>>       Since we're now past the deadline of April 19th, I'd like to inform
> >>>>>       everyone of what will happen on Monday.
> >>>>>
> >>>>>       There has not been any actual objections to the nominees nor have there
> >>>>>       been any suggestions on choosing a subset of them since my last email.
> >>>>>       As such, there is rough consensus on adding Kanzure, Murch, Jonatack,
> >>>>>       Ruben, and Roasbeef as BIP editors, and they will be added on Monday
> >>>>>       April 22nd.
> >>>>>
> >>>>>       Ava
> >>>>>
> >>>>>       On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development Mailing List
> >>>>>       wrote:
> >>>>>        > While I don't disagree that 5 or 6 people seems like a lot to add at
> >>>>>        > once, it's not clear to me how we should decide which subset of the
> >>>>>        > nominees should be added. As it is now, I have only seen an actual
> >>>>>        > objection to Kanzure and Ruben from /dev/fd0, and no explicit
> >>>>>       objections
> >>>>>        > to anyone else. It seems like the vast majority of people don't share
> >>>>>        > their concerns either as both Kanzure and Ruben continue to be
> >>>>>       endorsed
> >>>>>        > by many others.
> >>>>>        >
> >>>>>        > Looking at the endorsements each candidate has received, the current
> >>>>>        > counts are:
> >>>>>        > * Kanzure - 17 for, 1 against
> >>>>>        > * Murch - 13 for
> >>>>>        > * Jonatack - 13 for
> >>>>>        > * Ruben - 12 for, 1 against
> >>>>>        > * Roasbeef - 9 for
> >>>>>        > * Michael Folkson - none
> >>>>>        >
> >>>>>        > However, I don't want this process to become a popularity contest and
> >>>>>        > require some kind of formal voting. Rather I'd prefer that this
> >>>>>       process
> >>>>>        > be something more like how Bitcoin Core maintainers are added - by
> >>>>>        > achieving rough consensus. Without any explicit objections to any of
> >>>>>        > these candidates, I'm inclined to move forward with adding the 5 who
> >>>>>        > have received endorsements. Having to pick "winners" from this list
> >>>>>        > seems like a quick way to stir up drama that I don't think anyone
> >>>>>       really
> >>>>>        > wants to deal with.
> >>>>>        >
> >>>>>        > I do want to note that neither Kanzure, Ruben, nor Roasbeef have
> >>>>>       posted
> >>>>>        > on this list that they are willing to be BIP editors. I have
> >>>>>       reached out
> >>>>>        > to all 3 of them privately, and received responses from Kanzure and
> >>>>>        > Ruben that indicate that they probably are willing, but public
> >>>>>        > confirmation from them on this list would also be nice. I have not
> >>>>>        > received a response from Roasbeef.
> >>>>>        >
> >>>>>        > Ava
> >>>>>        >
> >>>>>        > On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
> >>>>>        >>   > I would prefer having more (9+?) than less folks on this
> >>>>>       task, so
> >>>>>        >> personal preferences are easily ignored and overwritten by the group
> >>>>>        >> majority.
> >>>>>        >>
> >>>>>        >> I disagree with that, the more doesn't really the better here.
> >>>>>       Having
> >>>>>        >> too many editors may result in a tragedy of the commons, in
> >>>>>       which people
> >>>>>        >> just commit to the job because many others do, and they do not
> >>>>>       end up
> >>>>>        >> doing as much because they expect others to do the it. This does not
> >>>>>        >> only make the process look bad but may burnout the ones that end up
> >>>>>        >> doing the job, given their time commitment ends up being too far
> >>>>>       from
> >>>>>        >> their expectations.
> >>>>>        >>
> >>>>>        >> I think being more moderate with the amount of people is better, and
> >>>>>        >> gives us leeway in case the workload ends up being excessive and
> >>>>>       we need
> >>>>>        >> to add more people (plus discourage people from joining and
> >>>>>       slacking off).
> >>>>>        >>
> >>>>>        >> I think 3 more people should be a good number to start from.
> >>>>>        >> I'd personally vouch for Murch, Kanzure, and Ruben based on
> >>>>>       their track
> >>>>>        >> record in the space
> >>>>>        >>
> >>>>>        >> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com
> >>>>>       <mailto:rdlfnvk@gmail•com>
> >>>>>        >> <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>>> wrote:
> >>>>>        >>
> >>>>>        >> +1 for
> >>>>>        >> Kanzure
> >>>>>        >> RubenSomsen
> >>>>>        >> Seccour
> >>>>>        >> Jon Atack
> >>>>>        >> Roasbeef
> >>>>>        >>
> >>>>>        >> I would prefer having more (9+?) than less folks on this task, so
> >>>>>        >> personal preferences are easily ignored and overwritten by the group
> >>>>>        >> majority.
> >>>>>        >>
> >>>>>        >> BIPs were intended as a means to collect ideas, not enforce ideas.
> >>>>>        >>
> >>>>>        >> I'd like to return to that.
> >>>>>        >>
> >>>>>        >> - NVK (temp gmail account)
> >>>>>        >>
> >>>>>        >>      On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A.
> >>>>>       Harding wrote:
> >>>>>        >>
> >>>>>        >>          On 2024-03-28 10:04, Matt Corallo wrote:
> >>>>>        >>           > Please provide justification rather than simply
> >>>>>       saying "I
> >>>>>        >>          like Bob!".
> >>>>>        >>
> >>>>>        >>          Using only comments from the mailing list, the
> >>>>>       following appears
> >>>>>        >>          to be
> >>>>>        >>          the candidate list along with the current support.
> >>>>>       Asterisks denote
> >>>>>        >>          candidates who indicated their willingness to accept
> >>>>>       the role.
> >>>>>        >>
> >>>>>        >>          - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris
> >>>>>        >>          Stewart[3],
> >>>>>        >>          Michael Folkson[6], Peter Todd[9], Matt Corallo[10],
> >>>>>       Brandon
> >>>>>        >>          Black[11],
> >>>>>        >>          Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
> >>>>>        >>          Carvalho[16]
> >>>>>        >>
> >>>>>        >>          - Ruben Somsen, recommended by Ava Chow[1], Chris
> >>>>>       Stewart[3],
> >>>>>        >>          Michael
> >>>>>        >>          Folkson[6], Antoine Riard[12], Murch[13], Antoine
> >>>>>       Poinsot[15], John
> >>>>>        >>          Carvalho[16]
> >>>>>        >>
> >>>>>        >>          - Jon Atack*, recommended by Luke Dashjr[2], Chris
> >>>>>       Stewart[3],
> >>>>>        >>          /dev/fd0[5][7],
> >>>>>        >>          Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
> >>>>>        >>          Carvalho[16]
> >>>>>        >>
> >>>>>        >>          - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
> >>>>>        >>          Stewart[3], John
> >>>>>        >>          C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8],
> >>>>>       Antoine
> >>>>>        >>          Riard[12], Ava Chow[14]
> >>>>>        >>
> >>>>>        >>          - Mark "Murch" Erhardt*, recommended by Michael
> >>>>>       Folkson[6], Keagan
> >>>>>        >>          McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine
> >>>>>        >>          Riard[12],
> >>>>>        >>          Ava Chow[14]
> >>>>>        >>
> >>>>>        >>          - Michael Folkson*
> >>>>>        >>
> >>>>>        >>          Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for
> >>>>>        >>          "non-dev
> >>>>>        >>          triaging", Tonoski proposed himself[18] for "BIP
> >>>>>       editor", and
> >>>>>        >>          Antoine
> >>>>>        >>          Riard[12] proposed Seccour for "decentralized PM".
> >>>>>        >>
> >>>>>        >>          I searched the BIPs repo by commenter to see if any of
> >>>>>       the above
> >>>>>        >>          candidates had been especially active there, which is
> >>>>>       listed
> >>>>>        >>          below as:
> >>>>>        >>          total PRs they commented on (number still open/number
> >>>>>       closed).
> >>>>>        >>
> >>>>>        >>          - 21 (1/20) commenter:kanzure
> >>>>>        >>          - 3 (2/1) commenter:rubensomsen
> >>>>>        >>          - 15 (0/15) commenter:jonatack
> >>>>>        >>          - 18 (2/16) commenter:roasbeef
> >>>>>        >>          - 10 (6/4) commenter:Murchandamus
> >>>>>        >>          - 57 (6/51) commenter:michaelfolkson
> >>>>>        >>
> >>>>>        >>          I'll also note that Osuntokun is the only member of the
> >>>>>       set to
> >>>>>        >>          have a
> >>>>>        >>          merged BIP that they co-authored, although I believe
> >>>>>       there are
> >>>>>        >>          far-along
> >>>>>        >>          draft BIPs for both Murch (terminology) and Somsen (Silent
> >>>>>        >>          Payments). I
> >>>>>        >>          don't think this should be a requirement, but I do think it
> >>>>>        >>          demonstrates
> >>>>>        >>          familiarity with the process.
> >>>>>        >>
> >>>>>        >>          Speaking only for myself, I think all of the candidates
> >>>>>       above with
> >>>>>        >>          multiple recommendations from other community
> >>>>>       participants are
> >>>>>        >>          fully
> >>>>>        >>          qualified for the role, so I'll only provide a detailed
> >>>>>        >>          justification
> >>>>>        >>          for the person who would be my first pick: Murch is not
> >>>>>       only a
> >>>>>        >>          longstanding and broadly liked Bitcoin contributor, but
> >>>>>       (as Corallo
> >>>>>        >>          mentioned) he has worked on standardizing terminology
> >>>>>       through a
> >>>>>        >>          draft
> >>>>>        >>          BIP. In addition, he provided an extremely detailed
> >>>>>       review of
> >>>>>        >>          all 300
> >>>>>        >>          pages of a draft of Mastering Bitcoin (3rd edition) and has
> >>>>>        >>          reviewed
> >>>>>        >>          drafts of over 200 weekly Optech newsletters, in both cases
> >>>>>        >>          significantly improving the accuracy and
> >>>>>       comprehensibility of the
> >>>>>        >>          documentation. To me, that seems very similar to the
> >>>>>       work we'd
> >>>>>        >>          ask him
> >>>>>        >>          to perform as a BIPs editor and it's something that
> >>>>>       he's already
> >>>>>        >>          doing,
> >>>>>        >>          so I think there's an excellent fit of person to role.
> >>>>>        >>
> >>>>>        >>          -Dave
> >>>>>        >>
> >>>>>        >>          [1]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
> >>>>>       <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>>
> >>>>>        >>          [2]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
> >>>>>       <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>
> >>>>>       <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>>
> >>>>>        >>          [3]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>>
> >>>>>        >>          [4]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>>
> >>>>>        >>          [5]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>>
> >>>>>        >>          [6]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>>
> >>>>>        >>          [7]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>>
> >>>>>        >>          [8]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>>
> >>>>>        >>          [9]
> >>>>>       https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> >>>>>       <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
> >>>>>        >>
> >>>>>       <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
> >>>>>       <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>>
> >>>>>        >>          [10]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>>
> >>>>>        >>          [11]
> >>>>>       https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >>>>>       <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
> >>>>>        >>
> >>>>>       <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >>>>>       <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>
> >>>>>        >>          [12]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>>
> >>>>>        >>          [13]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
> >>>>>       <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>
> >>>>>       <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>>
> >>>>>        >>          [14]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
> >>>>>       <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>>
> >>>>>        >>          [15]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/> <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>>
> >>>>>        >>          [16]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>>
> >>>>>        >>          [17]
> >>>>>        >>
> >>>>>       https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
> >>>>>       <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >>>>>        >>      <mailto:bitcoindev+unsubscribe@googlegroups•com
> >>>>>       <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>>.
> >>>>>        >>      To view this discussion on the web visit
> >>>>>        >>
> >>>>>       https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com> <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> >>>>>        >>
> >>>>>        >>
> >>>>>        >>
> >>>>>        >> --
> >>>>>        >> Sergi.
> >>>>>        >>
> >>>>>        >> --
> >>>>>        >> 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
> >>>>>       <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >>>>>        >> <mailto:bitcoindev+unsubscribe@googlegroups•com
> >>>>>       <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>>.
> >>>>>        >> To view this discussion on the web visit
> >>>>>        >>
> >>>>>       https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com> <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.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
> >>>>>       <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
> >>>>>        > To view this discussion on the web visit
> >>>>>       https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.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
> >>>>>       <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
> >>>>>       To view this discussion on the web visit
> >>>>>       https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com>.
> >>>>>
> >>>>
> >>>> --
> >>>> 


 permalink raw reply	[|nested]
2024-04-21 17:57                                         ` Michael Folkson

  2024-04-21 19:18                                             ` Michael Folkson
  2024-04-21 20:48                                             ` Antoine Riard
  
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2024-04-21 18:47 UTC (permalink / raw)
  To: Michael Folkson;  bitcoindev

On 04/21/2024 01:57 PM, Michael Folkson wrote:
> So once a BIP number is allocated (or before) the BIP author can write
> whatever they like on that BIP? Including false and misleading
> statements? And the BIP editors have to merge it as long as it meets
> formatting requirements?

I did not say that they can write anything, do not put words in my 
mouth. Modifications to a BIP are held to the same standard as when it 
is initially proposed. This standard is largely about formatting, but 
also about keeping BIPs as actual technical specifications. So long as 
the BIP after those modifications meet those requirements, then BIP 
editors should merge them.

> A misleading statement like "This soft fork will definitely activate
> at block X as it has been merged into implementation Y. It hasn't been
> merged into Bitcoin Core yet but Bitcoin Core will merge the soft fork
> after the activation"

BIPs are specifications. They are not blog posts. They are not the place 
for opining about whether or not something will activate. Such 
statements would be off topic for a BIP and do not meet the standard for 
merging, so no, I do not think that should be merged, and I do not think 
any of the proposed BIP editors would merge such a PR.

> 
> This is a step change from before. If we aren't relying on *any*
> judgment then there might as well be 100 BIP editors. Because the
> editors aren't doing anything, each BIP author (or champion) has total
> license to write whatever they like on their BIP.
> 
>> They are not arbiters of what is activated on Bitcoin. They are not gatekeepers of soft forks.
> 
> Of course not. The BIP editors do not decide what is activated on
> Bitcoin. But they are gatekeepers on ensuring BIPs are high quality
> and don't include false and misleading statements. Because false and
> misleading statements can impact the evolution of an activation
> process.
> 
> I tried. Based on your perspective all we need is one malicious BIP
> author (or champion) and they'll make the entire BIP process a joke
> and the BIP editors won't be able to do anything.

You are being deliberately obtuse and strawmanning. I did not say that 
the BIP editors won't be able to do anything; I did not say that that a 
BIP author can put whatever they want once they get a BIP number.

I suggest that you read the BIP process thread split from this one for 
opinions on how to refine the BIPs process to make it clearer as to what 
BIP editors should be merging.

Frankly, I don't understand what it is your are arguing for or trying to 
achieve. You make absurd claims, use strawman arguments, and throw out 
whataboutisms. This all seems to me to be concern trolling, and as such, 
I see no reason to continue responding to you.

Ava

> 
> Michael
> 
> 
> 
> On Sun, Apr 21, 2024 at 5:39 PM Ava Chow <lists@achow101•com> wrote:
>>
>> You are misunderstanding the role of BIP editors. They are not arbiters
>> of what is activated on Bitcoin. They are not gatekeepers of soft forks.
>> If a BIP author proposes or agrees with a change to their BIP and those
>> changes are formatted correctly, it is not the BIP editors' rights nor
>> responsibilities to refuse to merge that change. As with Bitcoin Core
>> maintainers, BIP editing is a largely janitorial role.
>>
>> Just because something is a BIP does not mean it is a good idea. Just
>> because a BIP specifying a fork contains deployment parameters does not
>> mean it will actually be deployed. There are several BIPs for both hard
>> and soft forks that are rejected or withdrawn that have deployment
>> parameters.
>>
>> Furthermore, for myself, I would actually prefer that contentious soft
>> forks for which some people are legitimately attempting to activate have
>> their deployment parameters be specified in a/the BIP. Having competing
>> activation parameters in different BIPs is preferable over the
>> documentation being spread around in many different places. It makes it
>> much easier for implementations to inform users what they've actually
>> implemented so that users can make a more informed decision.
>>
>> On 04/21/2024 07:43 AM, Michael Folkson wrote:
>>> Ava
>>>
>>> Thanks for the detailed response, I appreciate the insight.
>>>
>>>>> I'm even more concerned about future soft fork activation attempts.
>>>>> These don't necessarily need to be attempted via a Bitcoin Core merged
>>>>> pull request hence the BIPs repo could be a key source of information
>>>>> and guidance on this.
>>>
>>>> This concern doesn't make any sense. There are already multiple soft and
>>>> hard fork BIPs that are not active nor good ideas. A BIP does not need
>>>> to be a good idea.
>>>
>>> I would hope that a contentious soft fork and activation params for
>>> that contentious soft fork would not be merged into the Bitcoin Core
>>> codebase and up until now it hasn't been. I would hope all the Bitcoin
>>> Core maintainers understand that even if they personally think a soft
>>> fork is a good idea (apparently there is nothing to stop them merging
>>> it without discussing it with the other maintainers) that they
>>> shouldn't independently merge it if it is contentious.
>>>
>>> Similarly I would hope that all BIP editors would be careful about
>>> what information gets merged around soft fork activation *attempts*
>>> whether that be activation details on a particular soft fork BIP or on
>>> a separate activation BIP. With Taproot there were very strong
>>> disagreements over activation parameters for a non-contentious soft
>>> fork. It would be much messier for a contentious soft fork activation
>>> attempt. I'm not sure all these new BIP editors understand that or
>>> would perhaps even agree with that. For example Laolu is listed as a
>>> supporter of a CTV activation attempt back in 2022 [0] which was
>>> clearly contentious. That doesn't inspire me with confidence that as
>>> soon as he is a BIP editor he won't start merging details on
>>> contentious soft fork activation attempts in BIPs and merging that
>>> soft fork in say btcd. He would need to be removed as a BIP editor if
>>> he were to do something like that.
>>>
>>> Thanks
>>> Michael
>>>
>>> [0]: https://utxos.org/signals/
>>>
>>>
>>>
>>> On Sun, Apr 21, 2024 at 12:05 AM Ava Chow <lists@achow101•com> wrote:
>>>>
>>>>
>>>> On 04/20/2024 06:21 PM, Michael Folkson wrote:
>>>>> It is inevitable there will be a "revert war" unless they all have to
>>>>> agree on merge decisions or communicate prior to merging. It is just a
>>>>> matter of time. Does for example Ordinal Numbers get a BIP number? I
>>>>> suspect all the new BIP editors won't agree on that.
>>>>
>>>> Why do you think that a revert war is inevitable?
>>>>
>>>> The Bitcoin Core repo operates in a similar way - the maintainers are
>>>> independent and work autonomously. The maintainers do not have to agree
>>>> on merge decisions nor do they communicate prior to merging. If there's
>>>> disagreement about a merge decision, we talk to each other about it like
>>>> adults and come to a mutually agreeable resolution. I don't think
>>>> there's ever been a revert war in the history of Bitcoin.
>>>>
>>>> I would expect that when there is something that is likely to be
>>>> controversial or is ambiguous that it should be a BIP that they would
>>>> then talk to each other about it. It doesn't have to be all or nothing -
>>>> they can do most work without communicating, but when there's questions
>>>> or ambiguity, then they communicate.
>>>>
>>>>> Who is to blame in a "revert war" if each editor is free to merge
>>>>> whatever pull request they like? The editor who merged it? Why should
>>>>> they be removed as an editor for merging a pull request when they find
>>>>> out later a different editor disagreed with that merge decision and
>>>>> wants to revert the merge?
>>>>
>>>> A revert war would be someone merging a PR that reverts another, then
>>>> someone else (opening then) merging a PR that reverts that, and it goes
>>>> back and forth. It would not be limited to PRs only. This would likely
>>>> be super obvious too that they are controversially merging things as I
>>>> would be surprised if other BIP editors didn't comment on any of those
>>>> actions, besides the fact that many people do also watch the BIPs repo.
>>>> Regardless, the blame is on those who are doing the reverting, and would
>>>> be both sides.
>>>>
>>>>> I'm even more concerned about future soft fork activation attempts.
>>>>> These don't necessarily need to be attempted via a Bitcoin Core merged
>>>>> pull request hence the BIPs repo could be a key source of information
>>>>> and guidance on this.
>>>>
>>>> This concern doesn't make any sense. There are already multiple soft and
>>>> hard fork BIPs that are not active nor good ideas. A BIP does not need
>>>> to be a good idea.
>>>>
>>>>> I've seen Wladimir is contributing again to Core. Is there a plan to
>>>>> give him commit access again?
>>>>
>>>> It would have to be through the typical maintainer process, although I
>>>> doubt that he even wants it. But that's completely orthogonal to the
>>>> BIPs repo discussion.
>>>>
>>>>> I'd be more comfortable with him
>>>>> overseeing things in the various repos under the Bitcoin Core
>>>>> (/bitcoin) GitHub org as it sounds like you don't really care if the
>>>>> BIPs repo degenerates into a free for all.
>>>>
>>>> I don't understand why you assume that.
>>>>
>>>> I've said this before, but if I see a revert war going on in the BIPs
>>>> repo, I will remove those involved immediately and make a thread on the
>>>> list to discuss what to do about them. But I doubt that's a scenario
>>>> that will actually come to pass.
>>>>
>>>> Ava
>>>>
>>>>>
>>>>> Thanks
>>>>> Michael
>>>>>
>>>>> On Sat, Apr 20, 2024 at 10:15 PM 'Ava Chow' via Bitcoin Development
>>>>> Mailing List <bitcoindev@googlegroups.com> wrote:
>>>>>>
>>>>>> On 04/20/2024 04:46 PM, Steve Lee wrote:
>>>>>>> Wasn't there evidence provided that Kanzure does not want this
>>>>>>> responsibility without being paid?
>>>>>>
>>>>>> I am not aware of that, and it hasn't come up when I've talked to him
>>>>>> about being a BIPs editor.
>>>>>>
>>>>>>> I'm confused by this process that we don't even ask the people if they
>>>>>>> want the responsibility? I think only Laolu has chimed in to commit to it?
>>>>>>
>>>>>> Personally, I've spoken to all 5 privately and they've all confirmed to
>>>>>> me that they are willing to be BIPs editors. Jonatack[1] and Murch[2]
>>>>>> have also replied to this thread about this.
>>>>>>
>>>>>> Ava
>>>>>>
>>>>>> [1]:
>>>>>> https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/
>>>>>> [2]:
>>>>>> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
>>>>>>
>>>>>>>
>>>>>>> On Sat, Apr 20, 2024 at 12:30 PM 'Ava Chow' via Bitcoin Development
>>>>>>> Mailing List <bitcoindev@googlegroups.com
>>>>>>> <mailto:bitcoindev@googlegroups.com>> wrote:
>>>>>>>
>>>>>>>        Since we're now past the deadline of April 19th, I'd like to inform
>>>>>>>        everyone of what will happen on Monday.
>>>>>>>
>>>>>>>        There has not been any actual objections to the nominees nor have there
>>>>>>>        been any suggestions on choosing a subset of them since my last email.
>>>>>>>        As such, there is rough consensus on adding Kanzure, Murch, Jonatack,
>>>>>>>        Ruben, and Roasbeef as BIP editors, and they will be added on Monday
>>>>>>>        April 22nd.
>>>>>>>
>>>>>>>        Ava
>>>>>>>
>>>>>>>        On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development Mailing List
>>>>>>>        wrote:
>>>>>>>         > While I don't disagree that 5 or 6 people seems like a lot to add at
>>>>>>>         > once, it's not clear to me how we should decide which subset of the
>>>>>>>         > nominees should be added. As it is now, I have only seen an actual
>>>>>>>         > objection to Kanzure and Ruben from /dev/fd0, and no explicit
>>>>>>>        objections
>>>>>>>         > to anyone else. It seems like the vast majority of people don't share
>>>>>>>         > their concerns either as both Kanzure and Ruben continue to be
>>>>>>>        endorsed
>>>>>>>         > by many others.
>>>>>>>         >
>>>>>>>         > Looking at the endorsements each candidate has received, the current
>>>>>>>         > counts are:
>>>>>>>         > * Kanzure - 17 for, 1 against
>>>>>>>         > * Murch - 13 for
>>>>>>>         > * Jonatack - 13 for
>>>>>>>         > * Ruben - 12 for, 1 against
>>>>>>>         > * Roasbeef - 9 for
>>>>>>>         > * Michael Folkson - none
>>>>>>>         >
>>>>>>>         > However, I don't want this process to become a popularity contest and
>>>>>>>         > require some kind of formal voting. Rather I'd prefer that this
>>>>>>>        process
>>>>>>>         > be something more like how Bitcoin Core maintainers are added - by
>>>>>>>         > achieving rough consensus. Without any explicit objections to any of
>>>>>>>         > these candidates, I'm inclined to move forward with adding the 5 who
>>>>>>>         > have received endorsements. Having to pick "winners" from this list
>>>>>>>         > seems like a quick way to stir up drama that I don't think anyone
>>>>>>>        really
>>>>>>>         > wants to deal with.
>>>>>>>         >
>>>>>>>         > I do want to note that neither Kanzure, Ruben, nor Roasbeef have
>>>>>>>        posted
>>>>>>>         > on this list that they are willing to be BIP editors. I have
>>>>>>>        reached out
>>>>>>>         > to all 3 of them privately, and received responses from Kanzure and
>>>>>>>         > Ruben that indicate that they probably are willing, but public
>>>>>>>         > confirmation from them on this list would also be nice. I have not
>>>>>>>         > received a response from Roasbeef.
>>>>>>>         >
>>>>>>>         > Ava
>>>>>>>         >
>>>>>>>         > On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
>>>>>>>         >>   > I would prefer having more (9+?) than less folks on this
>>>>>>>        task, so
>>>>>>>         >> personal preferences are easily ignored and overwritten by the group
>>>>>>>         >> majority.
>>>>>>>         >>
>>>>>>>         >> I disagree with that, the more doesn't really the better here.
>>>>>>>        Having
>>>>>>>         >> too many editors may result in a tragedy of the commons, in
>>>>>>>        which people
>>>>>>>         >> just commit to the job because many others do, and they do not
>>>>>>>        end up
>>>>>>>         >> doing as much because they expect others to do the it. This does not
>>>>>>>         >> only make the process look bad but may burnout the ones that end up
>>>>>>>         >> doing the job, given their time commitment ends up being too far
>>>>>>>        from
>>>>>>>         >> their expectations.
>>>>>>>         >>
>>>>>>>         >> I think being more moderate with the amount of people is better, and
>>>>>>>         >> gives us leeway in case the workload ends up being excessive and
>>>>>>>        we need
>>>>>>>         >> to add more people (plus discourage people from joining and
>>>>>>>        slacking off).
>>>>>>>         >>
>>>>>>>         >> I think 3 more people should be a good number to start from.
>>>>>>>         >> I'd personally vouch for Murch, Kanzure, and Ruben based on
>>>>>>>        their track
>>>>>>>         >> record in the space
>>>>>>>         >>
>>>>>>>         >> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com
>>>>>>>        <mailto:rdlfnvk@gmail•com>
>>>>>>>         >> <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>>> wrote:
>>>>>>>         >>
>>>>>>>         >> +1 for
>>>>>>>         >> Kanzure
>>>>>>>         >> RubenSomsen
>>>>>>>         >> Seccour
>>>>>>>         >> Jon Atack
>>>>>>>         >> Roasbeef
>>>>>>>         >>
>>>>>>>         >> I would prefer having more (9+?) than less folks on this task, so
>>>>>>>         >> personal preferences are easily ignored and overwritten by the group
>>>>>>>         >> majority.
>>>>>>>         >>
>>>>>>>         >> BIPs were intended as a means to collect ideas, not enforce ideas.
>>>>>>>         >>
>>>>>>>         >> I'd like to return to that.
>>>>>>>         >>
>>>>>>>         >> - NVK (temp gmail account)
>>>>>>>         >>
>>>>>>>         >>      On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A.
>>>>>>>        Harding wrote:
>>>>>>>         >>
>>>>>>>         >>          On 2024-03-28 10:04, Matt Corallo wrote:
>>>>>>>         >>           > Please provide justification rather than simply
>>>>>>>        saying "I
>>>>>>>         >>          like Bob!".
>>>>>>>         >>
>>>>>>>         >>          Using only comments from the mailing list, the
>>>>>>>        following appears
>>>>>>>         >>          to be
>>>>>>>         >>          the candidate list along with the current support.
>>>>>>>        Asterisks denote
>>>>>>>         >>          candidates who indicated their willingness to accept
>>>>>>>        the role.
>>>>>>>         >>
>>>>>>>         >>          - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris
>>>>>>>         >>          Stewart[3],
>>>>>>>         >>          Michael Folkson[6], Peter Todd[9], Matt Corallo[10],
>>>>>>>        Brandon
>>>>>>>         >>          Black[11],
>>>>>>>         >>          Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>>>>>>>         >>          Carvalho[16]
>>>>>>>         >>
>>>>>>>         >>          - Ruben Somsen, recommended by Ava Chow[1], Chris
>>>>>>>        Stewart[3],
>>>>>>>         >>          Michael
>>>>>>>         >>          Folkson[6], Antoine Riard[12], Murch[13], Antoine
>>>>>>>        Poinsot[15], John
>>>>>>>         >>          Carvalho[16]
>>>>>>>         >>
>>>>>>>         >>          - Jon Atack*, recommended by Luke Dashjr[2], Chris
>>>>>>>        Stewart[3],
>>>>>>>         >>          /dev/fd0[5][7],
>>>>>>>         >>          Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
>>>>>>>         >>          Carvalho[16]
>>>>>>>         >>
>>>>>>>         >>          - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
>>>>>>>         >>          Stewart[3], John
>>>>>>>         >>          C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8],
>>>>>>>        Antoine
>>>>>>>         >>          Riard[12], Ava Chow[14]
>>>>>>>         >>
>>>>>>>         >>          - Mark "Murch" Erhardt*, recommended by Michael
>>>>>>>        Folkson[6], Keagan
>>>>>>>         >>          McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine
>>>>>>>         >>          Riard[12],
>>>>>>>         >>          Ava Chow[14]
>>>>>>>         >>
>>>>>>>         >>          - Michael Folkson*
>>>>>>>         >>
>>>>>>>         >>          Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for
>>>>>>>         >>          "non-dev
>>>>>>>         >>          triaging", Tonoski proposed himself[18] for "BIP
>>>>>>>        editor", and
>>>>>>>         >>          Antoine
>>>>>>>         >>          Riard[12] proposed Seccour for "decentralized PM".
>>>>>>>         >>
>>>>>>>         >>          I searched the BIPs repo by commenter to see if any of
>>>>>>>        the above
>>>>>>>         >>          candidates had been especially active there, which is
>>>>>>>        listed
>>>>>>>         >>          below as:
>>>>>>>         >>          total PRs they commented on (number still open/number
>>>>>>>        closed).
>>>>>>>         >>
>>>>>>>         >>          - 21 (1/20) commenter:kanzure
>>>>>>>         >>          - 3 (2/1) commenter:rubensomsen
>>>>>>>         >>          - 15 (0/15) commenter:jonatack
>>>>>>>         >>          - 18 (2/16) commenter:roasbeef
>>>>>>>         >>          - 10 (6/4) commenter:Murchandamus
>>>>>>>         >>          - 57 (6/51) commenter:michaelfolkson
>>>>>>>         >>
>>>>>>>         >>          I'll also note that Osuntokun is the only member of the
>>>>>>>        set to
>>>>>>>         >>          have a
>>>>>>>         >>          merged BIP that they co-authored, although I believe
>>>>>>>        there are
>>>>>>>         >>          far-along
>>>>>>>         >>          draft BIPs for both Murch (terminology) and Somsen (Silent
>>>>>>>         >>          Payments). I
>>>>>>>         >>          don't think this should be a requirement, but I do think it
>>>>>>>         >>          demonstrates
>>>>>>>         >>          familiarity with the process.
>>>>>>>         >>
>>>>>>>         >>          Speaking only for myself, I think all of the candidates
>>>>>>>        above with
>>>>>>>         >>          multiple recommendations from other community
>>>>>>>        participants are
>>>>>>>         >>          fully
>>>>>>>         >>          qualified for the role, so I'll only provide a detailed
>>>>>>>         >>          justification
>>>>>>>         >>          for the person who would be my first pick: Murch is not
>>>>>>>        only a
>>>>>>>         >>          longstanding and broadly liked Bitcoin contributor, but
>>>>>>>        (as Corallo
>>>>>>>         >>          mentioned) he has worked on standardizing terminology
>>>>>>>        through a
>>>>>>>         >>          draft
>>>>>>>         >>          BIP. In addition, he provided an extremely detailed
>>>>>>>        review of
>>>>>>>         >>          all 300
>>>>>>>         >>          pages of a draft of Mastering Bitcoin (3rd edition) and has
>>>>>>>         >>          reviewed
>>>>>>>         >>          drafts of over 200 weekly Optech newsletters, in both cases
>>>>>>>         >>          significantly improving the accuracy and
>>>>>>>        comprehensibility of the
>>>>>>>         >>          documentation. To me, that seems very similar to the
>>>>>>>        work we'd
>>>>>>>         >>          ask him
>>>>>>>         >>          to perform as a BIPs editor and it's something that
>>>>>>>        he's already
>>>>>>>         >>          doing,
>>>>>>>         >>          so I think there's an excellent fit of person to role.
>>>>>>>         >>
>>>>>>>         >>          -Dave
>>>>>>>         >>
>>>>>>>         >>          [1]
>>>>>>>         >>
>>>>>>>        https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
>>>>>>>        <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>>
>>>>>>>         >>          [2]
>>>>>>>         >>
>>>>>>>        https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
>>>>>>>        <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>
>>>>>>>        <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>>
>>>>>>>         >>          [3]
>>>>>>>         >>
>>>>>>>        https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>>
>>>>>>>         >>          [4]
>>>>>>>         >>
>>>>>>>        https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>>
>>>>>>>         >>          [5]
>>>>>>>         >>
>>>>>>>        https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>>
>>>>>>>         >>          [6]
>>>>>>>         >>
>>>>>>>        https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>>
>>>>>>>         >>          [7]
>>>>>>>         >>
>>>>>>>        https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>>
>>>>>>>         >>          [8]
>>>>>>>         >>
>>>>>>>        https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>>
>>>>>>>         >>          [9]
>>>>>>>        https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
>>>>>>>         >>
>>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
>>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>>
>>>>>>>         >>          [10]
>>>>>>>         >>
>>>>>>>        https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>>
>>>>>>>         >>          [11]
>>>>>>>        https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>>>>>>>         >>
>>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>
>>>>>>>         >>          [12]
>>>>>>>         >>
>>>>>>>        https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>>
>>>>>>>         >>          [13]
>>>>>>>         >>
>>>>>>>        https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
>>>>>>>        <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>
>>>>>>>        <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>>
>>>>>>>         >>          [14]
>>>>>>>         >>
>>>>>>>        https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
>>>>>>>        <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>>
>>>>>>>         >>          [15]
>>>>>>>         >>
>>>>>>>        https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/> <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>>
>>>>>>>         >>          [16]
>>>>>>>         >>
>>>>>>>        https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>>
>>>>>>>         >>          [17]
>>>>>>>         >>
>>>>>>>        https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
>>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
>>>>>>>         >>      <mailto:bitcoindev+unsubscribe@googlegroups•com
>>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>>.
>>>>>>>         >>      To view this discussion on the web visit
>>>>>>>         >>
>>>>>>>        https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com> <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>>>>>>>         >>
>>>>>>>         >>
>>>>>>>         >>
>>>>>>>         >> --
>>>>>>>         >> Sergi.
>>>>>>>         >>
>>>>>>>         >> --
>>>>>>>         >> 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
>>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
>>>>>>>         >> <mailto:bitcoindev+unsubscribe@googlegroups•com
>>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>>.
>>>>>>>         >> To view this discussion on the web visit
>>>>>>>         >>
>>>>>>>        https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com> <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.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
>>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
>>>>>>>         > To view this discussion on the web visit
>>>>>>>        https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.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
>>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
>>>>>>>        To view this discussion on the web visit
>>>>>>>        https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com>.
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> 


 permalink raw reply	[|nested]
2024-04-21 18:47                                           ` 'Ava Chow' via Bitcoin Development Mailing List

  2024-04-21 20:48                                             ` Antoine Riard
  
From: Michael Folkson @ 2024-04-21 19:18 UTC (permalink / raw)
  To: Ava Chow;  bitcoindev

> I did not say that they can write anything, do not put words in my
mouth.

Your statement was "If a BIP author proposes or agrees with a change
to their BIP and those
changes are formatted correctly, it is not the BIP editors' rights nor
responsibilities to refuse to merge that change." I'm not putting
words into your mouth, those are your words.

> I suggest that you read the BIP process thread split from this one for
opinions on how to refine the BIPs process to make it clearer as to what
BIP editors should be merging.

Indeed. I would rather that BIP process refinement had been completed
before we went from 1 BIP editor to 6 BIP editors, most of which have
barely participated in the BIP process in the past and will have very
different perspectives on what should or should not be merged. But
that is apparently "concern trolling" so agreed there is no point
continuing this.

On Sun, Apr 21, 2024 at 7:47 PM Ava Chow <lists@achow101•com> wrote:
>
> On 04/21/2024 01:57 PM, Michael Folkson wrote:
> > So once a BIP number is allocated (or before) the BIP author can write
> > whatever they like on that BIP? Including false and misleading
> > statements? And the BIP editors have to merge it as long as it meets
> > formatting requirements?
>
> I did not say that they can write anything, do not put words in my
> mouth. Modifications to a BIP are held to the same standard as when it
> is initially proposed. This standard is largely about formatting, but
> also about keeping BIPs as actual technical specifications. So long as
> the BIP after those modifications meet those requirements, then BIP
> editors should merge them.
>
> > A misleading statement like "This soft fork will definitely activate
> > at block X as it has been merged into implementation Y. It hasn't been
> > merged into Bitcoin Core yet but Bitcoin Core will merge the soft fork
> > after the activation"
>
> BIPs are specifications. They are not blog posts. They are not the place
> for opining about whether or not something will activate. Such
> statements would be off topic for a BIP and do not meet the standard for
> merging, so no, I do not think that should be merged, and I do not think
> any of the proposed BIP editors would merge such a PR.
>
> >
> > This is a step change from before. If we aren't relying on *any*
> > judgment then there might as well be 100 BIP editors. Because the
> > editors aren't doing anything, each BIP author (or champion) has total
> > license to write whatever they like on their BIP.
> >
> >> They are not arbiters of what is activated on Bitcoin. They are not gatekeepers of soft forks.
> >
> > Of course not. The BIP editors do not decide what is activated on
> > Bitcoin. But they are gatekeepers on ensuring BIPs are high quality
> > and don't include false and misleading statements. Because false and
> > misleading statements can impact the evolution of an activation
> > process.
> >
> > I tried. Based on your perspective all we need is one malicious BIP
> > author (or champion) and they'll make the entire BIP process a joke
> > and the BIP editors won't be able to do anything.
>
> You are being deliberately obtuse and strawmanning. I did not say that
> the BIP editors won't be able to do anything; I did not say that that a
> BIP author can put whatever they want once they get a BIP number.
>
> I suggest that you read the BIP process thread split from this one for
> opinions on how to refine the BIPs process to make it clearer as to what
> BIP editors should be merging.
>
> Frankly, I don't understand what it is your are arguing for or trying to
> achieve. You make absurd claims, use strawman arguments, and throw out
> whataboutisms. This all seems to me to be concern trolling, and as such,
> I see no reason to continue responding to you.
>
> Ava
>
> >
> > Michael
> >
> >
> >
> > On Sun, Apr 21, 2024 at 5:39 PM Ava Chow <lists@achow101•com> wrote:
> >>
> >> You are misunderstanding the role of BIP editors. They are not arbiters
> >> of what is activated on Bitcoin. They are not gatekeepers of soft forks.
> >> If a BIP author proposes or agrees with a change to their BIP and those
> >> changes are formatted correctly, it is not the BIP editors' rights nor
> >> responsibilities to refuse to merge that change. As with Bitcoin Core
> >> maintainers, BIP editing is a largely janitorial role.
> >>
> >> Just because something is a BIP does not mean it is a good idea. Just
> >> because a BIP specifying a fork contains deployment parameters does not
> >> mean it will actually be deployed. There are several BIPs for both hard
> >> and soft forks that are rejected or withdrawn that have deployment
> >> parameters.
> >>
> >> Furthermore, for myself, I would actually prefer that contentious soft
> >> forks for which some people are legitimately attempting to activate have
> >> their deployment parameters be specified in a/the BIP. Having competing
> >> activation parameters in different BIPs is preferable over the
> >> documentation being spread around in many different places. It makes it
> >> much easier for implementations to inform users what they've actually
> >> implemented so that users can make a more informed decision.
> >>
> >> On 04/21/2024 07:43 AM, Michael Folkson wrote:
> >>> Ava
> >>>
> >>> Thanks for the detailed response, I appreciate the insight.
> >>>
> >>>>> I'm even more concerned about future soft fork activation attempts.
> >>>>> These don't necessarily need to be attempted via a Bitcoin Core merged
> >>>>> pull request hence the BIPs repo could be a key source of information
> >>>>> and guidance on this.
> >>>
> >>>> This concern doesn't make any sense. There are already multiple soft and
> >>>> hard fork BIPs that are not active nor good ideas. A BIP does not need
> >>>> to be a good idea.
> >>>
> >>> I would hope that a contentious soft fork and activation params for
> >>> that contentious soft fork would not be merged into the Bitcoin Core
> >>> codebase and up until now it hasn't been. I would hope all the Bitcoin
> >>> Core maintainers understand that even if they personally think a soft
> >>> fork is a good idea (apparently there is nothing to stop them merging
> >>> it without discussing it with the other maintainers) that they
> >>> shouldn't independently merge it if it is contentious.
> >>>
> >>> Similarly I would hope that all BIP editors would be careful about
> >>> what information gets merged around soft fork activation *attempts*
> >>> whether that be activation details on a particular soft fork BIP or on
> >>> a separate activation BIP. With Taproot there were very strong
> >>> disagreements over activation parameters for a non-contentious soft
> >>> fork. It would be much messier for a contentious soft fork activation
> >>> attempt. I'm not sure all these new BIP editors understand that or
> >>> would perhaps even agree with that. For example Laolu is listed as a
> >>> supporter of a CTV activation attempt back in 2022 [0] which was
> >>> clearly contentious. That doesn't inspire me with confidence that as
> >>> soon as he is a BIP editor he won't start merging details on
> >>> contentious soft fork activation attempts in BIPs and merging that
> >>> soft fork in say btcd. He would need to be removed as a BIP editor if
> >>> he were to do something like that.
> >>>
> >>> Thanks
> >>> Michael
> >>>
> >>> [0]: https://utxos.org/signals/
> >>>
> >>>
> >>>
> >>> On Sun, Apr 21, 2024 at 12:05 AM Ava Chow <lists@achow101•com> wrote:
> >>>>
> >>>>
> >>>> On 04/20/2024 06:21 PM, Michael Folkson wrote:
> >>>>> It is inevitable there will be a "revert war" unless they all have to
> >>>>> agree on merge decisions or communicate prior to merging. It is just a
> >>>>> matter of time. Does for example Ordinal Numbers get a BIP number? I
> >>>>> suspect all the new BIP editors won't agree on that.
> >>>>
> >>>> Why do you think that a revert war is inevitable?
> >>>>
> >>>> The Bitcoin Core repo operates in a similar way - the maintainers are
> >>>> independent and work autonomously. The maintainers do not have to agree
> >>>> on merge decisions nor do they communicate prior to merging. If there's
> >>>> disagreement about a merge decision, we talk to each other about it like
> >>>> adults and come to a mutually agreeable resolution. I don't think
> >>>> there's ever been a revert war in the history of Bitcoin.
> >>>>
> >>>> I would expect that when there is something that is likely to be
> >>>> controversial or is ambiguous that it should be a BIP that they would
> >>>> then talk to each other about it. It doesn't have to be all or nothing -
> >>>> they can do most work without communicating, but when there's questions
> >>>> or ambiguity, then they communicate.
> >>>>
> >>>>> Who is to blame in a "revert war" if each editor is free to merge
> >>>>> whatever pull request they like? The editor who merged it? Why should
> >>>>> they be removed as an editor for merging a pull request when they find
> >>>>> out later a different editor disagreed with that merge decision and
> >>>>> wants to revert the merge?
> >>>>
> >>>> A revert war would be someone merging a PR that reverts another, then
> >>>> someone else (opening then) merging a PR that reverts that, and it goes
> >>>> back and forth. It would not be limited to PRs only. This would likely
> >>>> be super obvious too that they are controversially merging things as I
> >>>> would be surprised if other BIP editors didn't comment on any of those
> >>>> actions, besides the fact that many people do also watch the BIPs repo.
> >>>> Regardless, the blame is on those who are doing the reverting, and would
> >>>> be both sides.
> >>>>
> >>>>> I'm even more concerned about future soft fork activation attempts.
> >>>>> These don't necessarily need to be attempted via a Bitcoin Core merged
> >>>>> pull request hence the BIPs repo could be a key source of information
> >>>>> and guidance on this.
> >>>>
> >>>> This concern doesn't make any sense. There are already multiple soft and
> >>>> hard fork BIPs that are not active nor good ideas. A BIP does not need
> >>>> to be a good idea.
> >>>>
> >>>>> I've seen Wladimir is contributing again to Core. Is there a plan to
> >>>>> give him commit access again?
> >>>>
> >>>> It would have to be through the typical maintainer process, although I
> >>>> doubt that he even wants it. But that's completely orthogonal to the
> >>>> BIPs repo discussion.
> >>>>
> >>>>> I'd be more comfortable with him
> >>>>> overseeing things in the various repos under the Bitcoin Core
> >>>>> (/bitcoin) GitHub org as it sounds like you don't really care if the
> >>>>> BIPs repo degenerates into a free for all.
> >>>>
> >>>> I don't understand why you assume that.
> >>>>
> >>>> I've said this before, but if I see a revert war going on in the BIPs
> >>>> repo, I will remove those involved immediately and make a thread on the
> >>>> list to discuss what to do about them. But I doubt that's a scenario
> >>>> that will actually come to pass.
> >>>>
> >>>> Ava
> >>>>
> >>>>>
> >>>>> Thanks
> >>>>> Michael
> >>>>>
> >>>>> On Sat, Apr 20, 2024 at 10:15 PM 'Ava Chow' via Bitcoin Development
> >>>>> Mailing List <bitcoindev@googlegroups.com> wrote:
> >>>>>>
> >>>>>> On 04/20/2024 04:46 PM, Steve Lee wrote:
> >>>>>>> Wasn't there evidence provided that Kanzure does not want this
> >>>>>>> responsibility without being paid?
> >>>>>>
> >>>>>> I am not aware of that, and it hasn't come up when I've talked to him
> >>>>>> about being a BIPs editor.
> >>>>>>
> >>>>>>> I'm confused by this process that we don't even ask the people if they
> >>>>>>> want the responsibility? I think only Laolu has chimed in to commit to it?
> >>>>>>
> >>>>>> Personally, I've spoken to all 5 privately and they've all confirmed to
> >>>>>> me that they are willing to be BIPs editors. Jonatack[1] and Murch[2]
> >>>>>> have also replied to this thread about this.
> >>>>>>
> >>>>>> Ava
> >>>>>>
> >>>>>> [1]:
> >>>>>> https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/
> >>>>>> [2]:
> >>>>>> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> >>>>>>
> >>>>>>>
> >>>>>>> On Sat, Apr 20, 2024 at 12:30 PM 'Ava Chow' via Bitcoin Development
> >>>>>>> Mailing List <bitcoindev@googlegroups.com
> >>>>>>> <mailto:bitcoindev@googlegroups.com>> wrote:
> >>>>>>>
> >>>>>>>        Since we're now past the deadline of April 19th, I'd like to inform
> >>>>>>>        everyone of what will happen on Monday.
> >>>>>>>
> >>>>>>>        There has not been any actual objections to the nominees nor have there
> >>>>>>>        been any suggestions on choosing a subset of them since my last email.
> >>>>>>>        As such, there is rough consensus on adding Kanzure, Murch, Jonatack,
> >>>>>>>        Ruben, and Roasbeef as BIP editors, and they will be added on Monday
> >>>>>>>        April 22nd.
> >>>>>>>
> >>>>>>>        Ava
> >>>>>>>
> >>>>>>>        On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development Mailing List
> >>>>>>>        wrote:
> >>>>>>>         > While I don't disagree that 5 or 6 people seems like a lot to add at
> >>>>>>>         > once, it's not clear to me how we should decide which subset of the
> >>>>>>>         > nominees should be added. As it is now, I have only seen an actual
> >>>>>>>         > objection to Kanzure and Ruben from /dev/fd0, and no explicit
> >>>>>>>        objections
> >>>>>>>         > to anyone else. It seems like the vast majority of people don't share
> >>>>>>>         > their concerns either as both Kanzure and Ruben continue to be
> >>>>>>>        endorsed
> >>>>>>>         > by many others.
> >>>>>>>         >
> >>>>>>>         > Looking at the endorsements each candidate has received, the current
> >>>>>>>         > counts are:
> >>>>>>>         > * Kanzure - 17 for, 1 against
> >>>>>>>         > * Murch - 13 for
> >>>>>>>         > * Jonatack - 13 for
> >>>>>>>         > * Ruben - 12 for, 1 against
> >>>>>>>         > * Roasbeef - 9 for
> >>>>>>>         > * Michael Folkson - none
> >>>>>>>         >
> >>>>>>>         > However, I don't want this process to become a popularity contest and
> >>>>>>>         > require some kind of formal voting. Rather I'd prefer that this
> >>>>>>>        process
> >>>>>>>         > be something more like how Bitcoin Core maintainers are added - by
> >>>>>>>         > achieving rough consensus. Without any explicit objections to any of
> >>>>>>>         > these candidates, I'm inclined to move forward with adding the 5 who
> >>>>>>>         > have received endorsements. Having to pick "winners" from this list
> >>>>>>>         > seems like a quick way to stir up drama that I don't think anyone
> >>>>>>>        really
> >>>>>>>         > wants to deal with.
> >>>>>>>         >
> >>>>>>>         > I do want to note that neither Kanzure, Ruben, nor Roasbeef have
> >>>>>>>        posted
> >>>>>>>         > on this list that they are willing to be BIP editors. I have
> >>>>>>>        reached out
> >>>>>>>         > to all 3 of them privately, and received responses from Kanzure and
> >>>>>>>         > Ruben that indicate that they probably are willing, but public
> >>>>>>>         > confirmation from them on this list would also be nice. I have not
> >>>>>>>         > received a response from Roasbeef.
> >>>>>>>         >
> >>>>>>>         > Ava
> >>>>>>>         >
> >>>>>>>         > On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
> >>>>>>>         >>   > I would prefer having more (9+?) than less folks on this
> >>>>>>>        task, so
> >>>>>>>         >> personal preferences are easily ignored and overwritten by the group
> >>>>>>>         >> majority.
> >>>>>>>         >>
> >>>>>>>         >> I disagree with that, the more doesn't really the better here.
> >>>>>>>        Having
> >>>>>>>         >> too many editors may result in a tragedy of the commons, in
> >>>>>>>        which people
> >>>>>>>         >> just commit to the job because many others do, and they do not
> >>>>>>>        end up
> >>>>>>>         >> doing as much because they expect others to do the it. This does not
> >>>>>>>         >> only make the process look bad but may burnout the ones that end up
> >>>>>>>         >> doing the job, given their time commitment ends up being too far
> >>>>>>>        from
> >>>>>>>         >> their expectations.
> >>>>>>>         >>
> >>>>>>>         >> I think being more moderate with the amount of people is better, and
> >>>>>>>         >> gives us leeway in case the workload ends up being excessive and
> >>>>>>>        we need
> >>>>>>>         >> to add more people (plus discourage people from joining and
> >>>>>>>        slacking off).
> >>>>>>>         >>
> >>>>>>>         >> I think 3 more people should be a good number to start from.
> >>>>>>>         >> I'd personally vouch for Murch, Kanzure, and Ruben based on
> >>>>>>>        their track
> >>>>>>>         >> record in the space
> >>>>>>>         >>
> >>>>>>>         >> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com
> >>>>>>>        <mailto:rdlfnvk@gmail•com>
> >>>>>>>         >> <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>>> wrote:
> >>>>>>>         >>
> >>>>>>>         >> +1 for
> >>>>>>>         >> Kanzure
> >>>>>>>         >> RubenSomsen
> >>>>>>>         >> Seccour
> >>>>>>>         >> Jon Atack
> >>>>>>>         >> Roasbeef
> >>>>>>>         >>
> >>>>>>>         >> I would prefer having more (9+?) than less folks on this task, so
> >>>>>>>         >> personal preferences are easily ignored and overwritten by the group
> >>>>>>>         >> majority.
> >>>>>>>         >>
> >>>>>>>         >> BIPs were intended as a means to collect ideas, not enforce ideas.
> >>>>>>>         >>
> >>>>>>>         >> I'd like to return to that.
> >>>>>>>         >>
> >>>>>>>         >> - NVK (temp gmail account)
> >>>>>>>         >>
> >>>>>>>         >>      On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A.
> >>>>>>>        Harding wrote:
> >>>>>>>         >>
> >>>>>>>         >>          On 2024-03-28 10:04, Matt Corallo wrote:
> >>>>>>>         >>           > Please provide justification rather than simply
> >>>>>>>        saying "I
> >>>>>>>         >>          like Bob!".
> >>>>>>>         >>
> >>>>>>>         >>          Using only comments from the mailing list, the
> >>>>>>>        following appears
> >>>>>>>         >>          to be
> >>>>>>>         >>          the candidate list along with the current support.
> >>>>>>>        Asterisks denote
> >>>>>>>         >>          candidates who indicated their willingness to accept
> >>>>>>>        the role.
> >>>>>>>         >>
> >>>>>>>         >>          - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris
> >>>>>>>         >>          Stewart[3],
> >>>>>>>         >>          Michael Folkson[6], Peter Todd[9], Matt Corallo[10],
> >>>>>>>        Brandon
> >>>>>>>         >>          Black[11],
> >>>>>>>         >>          Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
> >>>>>>>         >>          Carvalho[16]
> >>>>>>>         >>
> >>>>>>>         >>          - Ruben Somsen, recommended by Ava Chow[1], Chris
> >>>>>>>        Stewart[3],
> >>>>>>>         >>          Michael
> >>>>>>>         >>          Folkson[6], Antoine Riard[12], Murch[13], Antoine
> >>>>>>>        Poinsot[15], John
> >>>>>>>         >>          Carvalho[16]
> >>>>>>>         >>
> >>>>>>>         >>          - Jon Atack*, recommended by Luke Dashjr[2], Chris
> >>>>>>>        Stewart[3],
> >>>>>>>         >>          /dev/fd0[5][7],
> >>>>>>>         >>          Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
> >>>>>>>         >>          Carvalho[16]
> >>>>>>>         >>
> >>>>>>>         >>          - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
> >>>>>>>         >>          Stewart[3], John
> >>>>>>>         >>          C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8],
> >>>>>>>        Antoine
> >>>>>>>         >>          Riard[12], Ava Chow[14]
> >>>>>>>         >>
> >>>>>>>         >>          - Mark "Murch" Erhardt*, recommended by Michael
> >>>>>>>        Folkson[6], Keagan
> >>>>>>>         >>          McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine
> >>>>>>>         >>          Riard[12],
> >>>>>>>         >>          Ava Chow[14]
> >>>>>>>         >>
> >>>>>>>         >>          - Michael Folkson*
> >>>>>>>         >>
> >>>>>>>         >>          Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for
> >>>>>>>         >>          "non-dev
> >>>>>>>         >>          triaging", Tonoski proposed himself[18] for "BIP
> >>>>>>>        editor", and
> >>>>>>>         >>          Antoine
> >>>>>>>         >>          Riard[12] proposed Seccour for "decentralized PM".
> >>>>>>>         >>
> >>>>>>>         >>          I searched the BIPs repo by commenter to see if any of
> >>>>>>>        the above
> >>>>>>>         >>          candidates had been especially active there, which is
> >>>>>>>        listed
> >>>>>>>         >>          below as:
> >>>>>>>         >>          total PRs they commented on (number still open/number
> >>>>>>>        closed).
> >>>>>>>         >>
> >>>>>>>         >>          - 21 (1/20) commenter:kanzure
> >>>>>>>         >>          - 3 (2/1) commenter:rubensomsen
> >>>>>>>         >>          - 15 (0/15) commenter:jonatack
> >>>>>>>         >>          - 18 (2/16) commenter:roasbeef
> >>>>>>>         >>          - 10 (6/4) commenter:Murchandamus
> >>>>>>>         >>          - 57 (6/51) commenter:michaelfolkson
> >>>>>>>         >>
> >>>>>>>         >>          I'll also note that Osuntokun is the only member of the
> >>>>>>>        set to
> >>>>>>>         >>          have a
> >>>>>>>         >>          merged BIP that they co-authored, although I believe
> >>>>>>>        there are
> >>>>>>>         >>          far-along
> >>>>>>>         >>          draft BIPs for both Murch (terminology) and Somsen (Silent
> >>>>>>>         >>          Payments). I
> >>>>>>>         >>          don't think this should be a requirement, but I do think it
> >>>>>>>         >>          demonstrates
> >>>>>>>         >>          familiarity with the process.
> >>>>>>>         >>
> >>>>>>>         >>          Speaking only for myself, I think all of the candidates
> >>>>>>>        above with
> >>>>>>>         >>          multiple recommendations from other community
> >>>>>>>        participants are
> >>>>>>>         >>          fully
> >>>>>>>         >>          qualified for the role, so I'll only provide a detailed
> >>>>>>>         >>          justification
> >>>>>>>         >>          for the person who would be my first pick: Murch is not
> >>>>>>>        only a
> >>>>>>>         >>          longstanding and broadly liked Bitcoin contributor, but
> >>>>>>>        (as Corallo
> >>>>>>>         >>          mentioned) he has worked on standardizing terminology
> >>>>>>>        through a
> >>>>>>>         >>          draft
> >>>>>>>         >>          BIP. In addition, he provided an extremely detailed
> >>>>>>>        review of
> >>>>>>>         >>          all 300
> >>>>>>>         >>          pages of a draft of Mastering Bitcoin (3rd edition) and has
> >>>>>>>         >>          reviewed
> >>>>>>>         >>          drafts of over 200 weekly Optech newsletters, in both cases
> >>>>>>>         >>          significantly improving the accuracy and
> >>>>>>>        comprehensibility of the
> >>>>>>>         >>          documentation. To me, that seems very similar to the
> >>>>>>>        work we'd
> >>>>>>>         >>          ask him
> >>>>>>>         >>          to perform as a BIPs editor and it's something that
> >>>>>>>        he's already
> >>>>>>>         >>          doing,
> >>>>>>>         >>          so I think there's an excellent fit of person to role.
> >>>>>>>         >>
> >>>>>>>         >>          -Dave
> >>>>>>>         >>
> >>>>>>>         >>          [1]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/> <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>>
> >>>>>>>         >>          [2]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>>
> >>>>>>>         >>          [3]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>>
> >>>>>>>         >>          [4]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>>
> >>>>>>>         >>          [5]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>>
> >>>>>>>         >>          [6]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>>
> >>>>>>>         >>          [7]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>>
> >>>>>>>         >>          [8]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>>
> >>>>>>>         >>          [9]
> >>>>>>>        https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
> >>>>>>>         >>
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>>
> >>>>>>>         >>          [10]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>>
> >>>>>>>         >>          [11]
> >>>>>>>        https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
> >>>>>>>         >>
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>
> >>>>>>>         >>          [12]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>>
> >>>>>>>         >>          [13]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>>
> >>>>>>>         >>          [14]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/> <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>>
> >>>>>>>         >>          [15]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/> <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>>
> >>>>>>>         >>          [16]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>>
> >>>>>>>         >>          [17]
> >>>>>>>         >>
> >>>>>>>        https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/> <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
> >>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >>>>>>>         >>      <mailto:bitcoindev+unsubscribe@googlegroups•com
> >>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>>.
> >>>>>>>         >>      To view this discussion on the web visit
> >>>>>>>         >>
> >>>>>>>        https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com> <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>>.
> >>>>>>>         >>
> >>>>>>>         >>
> >>>>>>>         >>
> >>>>>>>         >> --
> >>>>>>>         >> Sergi.
> >>>>>>>         >>
> >>>>>>>         >> --
> >>>>>>>         >> 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
> >>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >>>>>>>         >> <mailto:bitcoindev+unsubscribe@googlegroups•com
> >>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>>.
> >>>>>>>         >> To view this discussion on the web visit
> >>>>>>>         >>
> >>>>>>>        https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com> <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.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
> >>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
> >>>>>>>         > To view this discussion on the web visit
> >>>>>>>        https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.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
> >>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
> >>>>>>>        To view this discussion on the web visit
> >>>>>>>        https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com <https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com>.
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> 


 permalink raw reply	[|nested]
2024-04-21 18:47                                           ` 'Ava Chow' via Bitcoin Development Mailing List
  2024-04-21 19:18                                             ` Michael Folkson

  
From: Antoine Riard @ 2024-04-21 20:48 UTC (permalink / raw)
  To: Ava Chow;  Michael Folkson, bitcoindev

[-- Attachment #1: Type: text/plain, Size: 37971 bytes --]

> There has not been any actual objections to the nominees nor have there
> been any suggestions on choosing a subset of them since my last email.
> As such, there is rough consensus on adding Kanzure, Murch, Jonatack,
> Ruben, and Roasbeef as BIP editors, and they will be added on Monday
> April 22nd.

ACK.

Beyond that, I'll stick to my mail of the 1st April and I won't comment
further on the subject of nominating new BIP editors.
If anyone has thoughts on how to improve the BIP process for the _future_,
I think real-or-random started a new thread called "Time for an update to
BIP2?".
Anyone can express themselves there and then start to champion a new BIP of
type "process".

Best,
Antoine

Le dim. 21 avr. 2024 à 20:08, 'Ava Chow' via Bitcoin Development Mailing
List <bitcoindev@googlegroups.com> a écrit :

> On 04/21/2024 01:57 PM, Michael Folkson wrote:
> > So once a BIP number is allocated (or before) the BIP author can write
> > whatever they like on that BIP? Including false and misleading
> > statements? And the BIP editors have to merge it as long as it meets
> > formatting requirements?
>
> I did not say that they can write anything, do not put words in my
> mouth. Modifications to a BIP are held to the same standard as when it
> is initially proposed. This standard is largely about formatting, but
> also about keeping BIPs as actual technical specifications. So long as
> the BIP after those modifications meet those requirements, then BIP
> editors should merge them.
>
> > A misleading statement like "This soft fork will definitely activate
> > at block X as it has been merged into implementation Y. It hasn't been
> > merged into Bitcoin Core yet but Bitcoin Core will merge the soft fork
> > after the activation"
>
> BIPs are specifications. They are not blog posts. They are not the place
> for opining about whether or not something will activate. Such
> statements would be off topic for a BIP and do not meet the standard for
> merging, so no, I do not think that should be merged, and I do not think
> any of the proposed BIP editors would merge such a PR.
>
> >
> > This is a step change from before. If we aren't relying on *any*
> > judgment then there might as well be 100 BIP editors. Because the
> > editors aren't doing anything, each BIP author (or champion) has total
> > license to write whatever they like on their BIP.
> >
> >> They are not arbiters of what is activated on Bitcoin. They are not
> gatekeepers of soft forks.
> >
> > Of course not. The BIP editors do not decide what is activated on
> > Bitcoin. But they are gatekeepers on ensuring BIPs are high quality
> > and don't include false and misleading statements. Because false and
> > misleading statements can impact the evolution of an activation
> > process.
> >
> > I tried. Based on your perspective all we need is one malicious BIP
> > author (or champion) and they'll make the entire BIP process a joke
> > and the BIP editors won't be able to do anything.
>
> You are being deliberately obtuse and strawmanning. I did not say that
> the BIP editors won't be able to do anything; I did not say that that a
> BIP author can put whatever they want once they get a BIP number.
>
> I suggest that you read the BIP process thread split from this one for
> opinions on how to refine the BIPs process to make it clearer as to what
> BIP editors should be merging.
>
> Frankly, I don't understand what it is your are arguing for or trying to
> achieve. You make absurd claims, use strawman arguments, and throw out
> whataboutisms. This all seems to me to be concern trolling, and as such,
> I see no reason to continue responding to you.
>
> Ava
>
> >
> > Michael
> >
> >
> >
> > On Sun, Apr 21, 2024 at 5:39 PM Ava Chow <lists@achow101•com> wrote:
> >>
> >> You are misunderstanding the role of BIP editors. They are not arbiters
> >> of what is activated on Bitcoin. They are not gatekeepers of soft forks.
> >> If a BIP author proposes or agrees with a change to their BIP and those
> >> changes are formatted correctly, it is not the BIP editors' rights nor
> >> responsibilities to refuse to merge that change. As with Bitcoin Core
> >> maintainers, BIP editing is a largely janitorial role.
> >>
> >> Just because something is a BIP does not mean it is a good idea. Just
> >> because a BIP specifying a fork contains deployment parameters does not
> >> mean it will actually be deployed. There are several BIPs for both hard
> >> and soft forks that are rejected or withdrawn that have deployment
> >> parameters.
> >>
> >> Furthermore, for myself, I would actually prefer that contentious soft
> >> forks for which some people are legitimately attempting to activate have
> >> their deployment parameters be specified in a/the BIP. Having competing
> >> activation parameters in different BIPs is preferable over the
> >> documentation being spread around in many different places. It makes it
> >> much easier for implementations to inform users what they've actually
> >> implemented so that users can make a more informed decision.
> >>
> >> On 04/21/2024 07:43 AM, Michael Folkson wrote:
> >>> Ava
> >>>
> >>> Thanks for the detailed response, I appreciate the insight.
> >>>
> >>>>> I'm even more concerned about future soft fork activation attempts.
> >>>>> These don't necessarily need to be attempted via a Bitcoin Core
> merged
> >>>>> pull request hence the BIPs repo could be a key source of information
> >>>>> and guidance on this.
> >>>
> >>>> This concern doesn't make any sense. There are already multiple soft
> and
> >>>> hard fork BIPs that are not active nor good ideas. A BIP does not need
> >>>> to be a good idea.
> >>>
> >>> I would hope that a contentious soft fork and activation params for
> >>> that contentious soft fork would not be merged into the Bitcoin Core
> >>> codebase and up until now it hasn't been. I would hope all the Bitcoin
> >>> Core maintainers understand that even if they personally think a soft
> >>> fork is a good idea (apparently there is nothing to stop them merging
> >>> it without discussing it with the other maintainers) that they
> >>> shouldn't independently merge it if it is contentious.
> >>>
> >>> Similarly I would hope that all BIP editors would be careful about
> >>> what information gets merged around soft fork activation *attempts*
> >>> whether that be activation details on a particular soft fork BIP or on
> >>> a separate activation BIP. With Taproot there were very strong
> >>> disagreements over activation parameters for a non-contentious soft
> >>> fork. It would be much messier for a contentious soft fork activation
> >>> attempt. I'm not sure all these new BIP editors understand that or
> >>> would perhaps even agree with that. For example Laolu is listed as a
> >>> supporter of a CTV activation attempt back in 2022 [0] which was
> >>> clearly contentious. That doesn't inspire me with confidence that as
> >>> soon as he is a BIP editor he won't start merging details on
> >>> contentious soft fork activation attempts in BIPs and merging that
> >>> soft fork in say btcd. He would need to be removed as a BIP editor if
> >>> he were to do something like that.
> >>>
> >>> Thanks
> >>> Michael
> >>>
> >>> [0]: https://utxos.org/signals/
> >>>
> >>>
> >>>
> >>> On Sun, Apr 21, 2024 at 12:05 AM Ava Chow <lists@achow101•com> wrote:
> >>>>
> >>>>
> >>>> On 04/20/2024 06:21 PM, Michael Folkson wrote:
> >>>>> It is inevitable there will be a "revert war" unless they all have to
> >>>>> agree on merge decisions or communicate prior to merging. It is just
> a
> >>>>> matter of time. Does for example Ordinal Numbers get a BIP number? I
> >>>>> suspect all the new BIP editors won't agree on that.
> >>>>
> >>>> Why do you think that a revert war is inevitable?
> >>>>
> >>>> The Bitcoin Core repo operates in a similar way - the maintainers are
> >>>> independent and work autonomously. The maintainers do not have to
> agree
> >>>> on merge decisions nor do they communicate prior to merging. If
> there's
> >>>> disagreement about a merge decision, we talk to each other about it
> like
> >>>> adults and come to a mutually agreeable resolution. I don't think
> >>>> there's ever been a revert war in the history of Bitcoin.
> >>>>
> >>>> I would expect that when there is something that is likely to be
> >>>> controversial or is ambiguous that it should be a BIP that they would
> >>>> then talk to each other about it. It doesn't have to be all or
> nothing -
> >>>> they can do most work without communicating, but when there's
> questions
> >>>> or ambiguity, then they communicate.
> >>>>
> >>>>> Who is to blame in a "revert war" if each editor is free to merge
> >>>>> whatever pull request they like? The editor who merged it? Why should
> >>>>> they be removed as an editor for merging a pull request when they
> find
> >>>>> out later a different editor disagreed with that merge decision and
> >>>>> wants to revert the merge?
> >>>>
> >>>> A revert war would be someone merging a PR that reverts another, then
> >>>> someone else (opening then) merging a PR that reverts that, and it
> goes
> >>>> back and forth. It would not be limited to PRs only. This would likely
> >>>> be super obvious too that they are controversially merging things as I
> >>>> would be surprised if other BIP editors didn't comment on any of those
> >>>> actions, besides the fact that many people do also watch the BIPs
> repo.
> >>>> Regardless, the blame is on those who are doing the reverting, and
> would
> >>>> be both sides.
> >>>>
> >>>>> I'm even more concerned about future soft fork activation attempts.
> >>>>> These don't necessarily need to be attempted via a Bitcoin Core
> merged
> >>>>> pull request hence the BIPs repo could be a key source of information
> >>>>> and guidance on this.
> >>>>
> >>>> This concern doesn't make any sense. There are already multiple soft
> and
> >>>> hard fork BIPs that are not active nor good ideas. A BIP does not need
> >>>> to be a good idea.
> >>>>
> >>>>> I've seen Wladimir is contributing again to Core. Is there a plan to
> >>>>> give him commit access again?
> >>>>
> >>>> It would have to be through the typical maintainer process, although I
> >>>> doubt that he even wants it. But that's completely orthogonal to the
> >>>> BIPs repo discussion.
> >>>>
> >>>>> I'd be more comfortable with him
> >>>>> overseeing things in the various repos under the Bitcoin Core
> >>>>> (/bitcoin) GitHub org as it sounds like you don't really care if the
> >>>>> BIPs repo degenerates into a free for all.
> >>>>
> >>>> I don't understand why you assume that.
> >>>>
> >>>> I've said this before, but if I see a revert war going on in the BIPs
> >>>> repo, I will remove those involved immediately and make a thread on
> the
> >>>> list to discuss what to do about them. But I doubt that's a scenario
> >>>> that will actually come to pass.
> >>>>
> >>>> Ava
> >>>>
> >>>>>
> >>>>> Thanks
> >>>>> Michael
> >>>>>
> >>>>> On Sat, Apr 20, 2024 at 10:15 PM 'Ava Chow' via Bitcoin Development
> >>>>> Mailing List <bitcoindev@googlegroups.com> wrote:
> >>>>>>
> >>>>>> On 04/20/2024 04:46 PM, Steve Lee wrote:
> >>>>>>> Wasn't there evidence provided that Kanzure does not want this
> >>>>>>> responsibility without being paid?
> >>>>>>
> >>>>>> I am not aware of that, and it hasn't come up when I've talked to
> him
> >>>>>> about being a BIPs editor.
> >>>>>>
> >>>>>>> I'm confused by this process that we don't even ask the people if
> they
> >>>>>>> want the responsibility? I think only Laolu has chimed in to
> commit to it?
> >>>>>>
> >>>>>> Personally, I've spoken to all 5 privately and they've all
> confirmed to
> >>>>>> me that they are willing to be BIPs editors. Jonatack[1] and
> Murch[2]
> >>>>>> have also replied to this thread about this.
> >>>>>>
> >>>>>> Ava
> >>>>>>
> >>>>>> [1]:
> >>>>>>
> https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/
> >>>>>> [2]:
> >>>>>>
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> >>>>>>
> >>>>>>>
> >>>>>>> On Sat, Apr 20, 2024 at 12:30 PM 'Ava Chow' via Bitcoin Development
> >>>>>>> Mailing List <bitcoindev@googlegroups.com
> >>>>>>> <mailto:bitcoindev@googlegroups.com>> wrote:
> >>>>>>>
> >>>>>>>        Since we're now past the deadline of April 19th, I'd like
> to inform
> >>>>>>>        everyone of what will happen on Monday.
> >>>>>>>
> >>>>>>>        There has not been any actual objections to the nominees
> nor have there
> >>>>>>>        been any suggestions on choosing a subset of them since my
> last email.
> >>>>>>>        As such, there is rough consensus on adding Kanzure, Murch,
> Jonatack,
> >>>>>>>        Ruben, and Roasbeef as BIP editors, and they will be added
> on Monday
> >>>>>>>        April 22nd.
> >>>>>>>
> >>>>>>>        Ava
> >>>>>>>
> >>>>>>>        On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development
> Mailing List
> >>>>>>>        wrote:
> >>>>>>>         > While I don't disagree that 5 or 6 people seems like a
> lot to add at
> >>>>>>>         > once, it's not clear to me how we should decide which
> subset of the
> >>>>>>>         > nominees should be added. As it is now, I have only seen
> an actual
> >>>>>>>         > objection to Kanzure and Ruben from /dev/fd0, and no
> explicit
> >>>>>>>        objections
> >>>>>>>         > to anyone else. It seems like the vast majority of
> people don't share
> >>>>>>>         > their concerns either as both Kanzure and Ruben continue
> to be
> >>>>>>>        endorsed
> >>>>>>>         > by many others.
> >>>>>>>         >
> >>>>>>>         > Looking at the endorsements each candidate has received,
> the current
> >>>>>>>         > counts are:
> >>>>>>>         > * Kanzure - 17 for, 1 against
> >>>>>>>         > * Murch - 13 for
> >>>>>>>         > * Jonatack - 13 for
> >>>>>>>         > * Ruben - 12 for, 1 against
> >>>>>>>         > * Roasbeef - 9 for
> >>>>>>>         > * Michael Folkson - none
> >>>>>>>         >
> >>>>>>>         > However, I don't want this process to become a
> popularity contest and
> >>>>>>>         > require some kind of formal voting. Rather I'd prefer
> that this
> >>>>>>>        process
> >>>>>>>         > be something more like how Bitcoin Core maintainers are
> added - by
> >>>>>>>         > achieving rough consensus. Without any explicit
> objections to any of
> >>>>>>>         > these candidates, I'm inclined to move forward with
> adding the 5 who
> >>>>>>>         > have received endorsements. Having to pick "winners"
> from this list
> >>>>>>>         > seems like a quick way to stir up drama that I don't
> think anyone
> >>>>>>>        really
> >>>>>>>         > wants to deal with.
> >>>>>>>         >
> >>>>>>>         > I do want to note that neither Kanzure, Ruben, nor
> Roasbeef have
> >>>>>>>        posted
> >>>>>>>         > on this list that they are willing to be BIP editors. I
> have
> >>>>>>>        reached out
> >>>>>>>         > to all 3 of them privately, and received responses from
> Kanzure and
> >>>>>>>         > Ruben that indicate that they probably are willing, but
> public
> >>>>>>>         > confirmation from them on this list would also be nice.
> I have not
> >>>>>>>         > received a response from Roasbeef.
> >>>>>>>         >
> >>>>>>>         > Ava
> >>>>>>>         >
> >>>>>>>         > On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
> >>>>>>>         >>   > I would prefer having more (9+?) than less folks on
> this
> >>>>>>>        task, so
> >>>>>>>         >> personal preferences are easily ignored and overwritten
> by the group
> >>>>>>>         >> majority.
> >>>>>>>         >>
> >>>>>>>         >> I disagree with that, the more doesn't really the
> better here.
> >>>>>>>        Having
> >>>>>>>         >> too many editors may result in a tragedy of the
> commons, in
> >>>>>>>        which people
> >>>>>>>         >> just commit to the job because many others do, and they
> do not
> >>>>>>>        end up
> >>>>>>>         >> doing as much because they expect others to do the it.
> This does not
> >>>>>>>         >> only make the process look bad but may burnout the ones
> that end up
> >>>>>>>         >> doing the job, given their time commitment ends up
> being too far
> >>>>>>>        from
> >>>>>>>         >> their expectations.
> >>>>>>>         >>
> >>>>>>>         >> I think being more moderate with the amount of people
> is better, and
> >>>>>>>         >> gives us leeway in case the workload ends up being
> excessive and
> >>>>>>>        we need
> >>>>>>>         >> to add more people (plus discourage people from joining
> and
> >>>>>>>        slacking off).
> >>>>>>>         >>
> >>>>>>>         >> I think 3 more people should be a good number to start
> from.
> >>>>>>>         >> I'd personally vouch for Murch, Kanzure, and Ruben
> based on
> >>>>>>>        their track
> >>>>>>>         >> record in the space
> >>>>>>>         >>
> >>>>>>>         >> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com
> >>>>>>>        <mailto:rdlfnvk@gmail•com>
> >>>>>>>         >> <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>>>
> wrote:
> >>>>>>>         >>
> >>>>>>>         >> +1 for
> >>>>>>>         >> Kanzure
> >>>>>>>         >> RubenSomsen
> >>>>>>>         >> Seccour
> >>>>>>>         >> Jon Atack
> >>>>>>>         >> Roasbeef
> >>>>>>>         >>
> >>>>>>>         >> I would prefer having more (9+?) than less folks on
> this task, so
> >>>>>>>         >> personal preferences are easily ignored and overwritten
> by the group
> >>>>>>>         >> majority.
> >>>>>>>         >>
> >>>>>>>         >> BIPs were intended as a means to collect ideas, not
> enforce ideas.
> >>>>>>>         >>
> >>>>>>>         >> I'd like to return to that.
> >>>>>>>         >>
> >>>>>>>         >> - NVK (temp gmail account)
> >>>>>>>         >>
> >>>>>>>         >>      On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David
> A.
> >>>>>>>        Harding wrote:
> >>>>>>>         >>
> >>>>>>>         >>          On 2024-03-28 10:04, Matt Corallo wrote:
> >>>>>>>         >>           > Please provide justification rather than
> simply
> >>>>>>>        saying "I
> >>>>>>>         >>          like Bob!".
> >>>>>>>         >>
> >>>>>>>         >>          Using only comments from the mailing list, the
> >>>>>>>        following appears
> >>>>>>>         >>          to be
> >>>>>>>         >>          the candidate list along with the current
> support.
> >>>>>>>        Asterisks denote
> >>>>>>>         >>          candidates who indicated their willingness to
> accept
> >>>>>>>        the role.
> >>>>>>>         >>
> >>>>>>>         >>          - Bryan "Kanzure" Bishop, recommended by Ava
> Chow[1], Chris
> >>>>>>>         >>          Stewart[3],
> >>>>>>>         >>          Michael Folkson[6], Peter Todd[9], Matt
> Corallo[10],
> >>>>>>>        Brandon
> >>>>>>>         >>          Black[11],
> >>>>>>>         >>          Antoine Riard[12], Murch[13], Antoine
> Poinsot[15], John
> >>>>>>>         >>          Carvalho[16]
> >>>>>>>         >>
> >>>>>>>         >>          - Ruben Somsen, recommended by Ava Chow[1],
> Chris
> >>>>>>>        Stewart[3],
> >>>>>>>         >>          Michael
> >>>>>>>         >>          Folkson[6], Antoine Riard[12], Murch[13],
> Antoine
> >>>>>>>        Poinsot[15], John
> >>>>>>>         >>          Carvalho[16]
> >>>>>>>         >>
> >>>>>>>         >>          - Jon Atack*, recommended by Luke Dashjr[2],
> Chris
> >>>>>>>        Stewart[3],
> >>>>>>>         >>          /dev/fd0[5][7],
> >>>>>>>         >>          Brandon Black[11], Antoine Riard[12], Ava
> Chow[14], John
> >>>>>>>         >>          Carvalho[16]
> >>>>>>>         >>
> >>>>>>>         >>          - Olaoluwa "Roasbeef" Osuntokun, recommended
> by Chris
> >>>>>>>         >>          Stewart[3], John
> >>>>>>>         >>          C. Vernaleo[4], /dev/fd0[5][7], Keagan
> McClelland[8],
> >>>>>>>        Antoine
> >>>>>>>         >>          Riard[12], Ava Chow[14]
> >>>>>>>         >>
> >>>>>>>         >>          - Mark "Murch" Erhardt*, recommended by Michael
> >>>>>>>        Folkson[6], Keagan
> >>>>>>>         >>          McClelland[8], Matt Corallo[10], Brandon
> Black[11], Antoine
> >>>>>>>         >>          Riard[12],
> >>>>>>>         >>          Ava Chow[14]
> >>>>>>>         >>
> >>>>>>>         >>          - Michael Folkson*
> >>>>>>>         >>
> >>>>>>>         >>          Note: Luke Dashjr proposed[17] Seccour and
> Greg Tonoski for
> >>>>>>>         >>          "non-dev
> >>>>>>>         >>          triaging", Tonoski proposed himself[18] for
> "BIP
> >>>>>>>        editor", and
> >>>>>>>         >>          Antoine
> >>>>>>>         >>          Riard[12] proposed Seccour for "decentralized
> PM".
> >>>>>>>         >>
> >>>>>>>         >>          I searched the BIPs repo by commenter to see
> if any of
> >>>>>>>        the above
> >>>>>>>         >>          candidates had been especially active there,
> which is
> >>>>>>>        listed
> >>>>>>>         >>          below as:
> >>>>>>>         >>          total PRs they commented on (number still
> open/number
> >>>>>>>        closed).
> >>>>>>>         >>
> >>>>>>>         >>          - 21 (1/20) commenter:kanzure
> >>>>>>>         >>          - 3 (2/1) commenter:rubensomsen
> >>>>>>>         >>          - 15 (0/15) commenter:jonatack
> >>>>>>>         >>          - 18 (2/16) commenter:roasbeef
> >>>>>>>         >>          - 10 (6/4) commenter:Murchandamus
> >>>>>>>         >>          - 57 (6/51) commenter:michaelfolkson
> >>>>>>>         >>
> >>>>>>>         >>          I'll also note that Osuntokun is the only
> member of the
> >>>>>>>        set to
> >>>>>>>         >>          have a
> >>>>>>>         >>          merged BIP that they co-authored, although I
> believe
> >>>>>>>        there are
> >>>>>>>         >>          far-along
> >>>>>>>         >>          draft BIPs for both Murch (terminology) and
> Somsen (Silent
> >>>>>>>         >>          Payments). I
> >>>>>>>         >>          don't think this should be a requirement, but
> I do think it
> >>>>>>>         >>          demonstrates
> >>>>>>>         >>          familiarity with the process.
> >>>>>>>         >>
> >>>>>>>         >>          Speaking only for myself, I think all of the
> candidates
> >>>>>>>        above with
> >>>>>>>         >>          multiple recommendations from other community
> >>>>>>>        participants are
> >>>>>>>         >>          fully
> >>>>>>>         >>          qualified for the role, so I'll only provide a
> detailed
> >>>>>>>         >>          justification
> >>>>>>>         >>          for the person who would be my first pick:
> Murch is not
> >>>>>>>        only a
> >>>>>>>         >>          longstanding and broadly liked Bitcoin
> contributor, but
> >>>>>>>        (as Corallo
> >>>>>>>         >>          mentioned) he has worked on standardizing
> terminology
> >>>>>>>        through a
> >>>>>>>         >>          draft
> >>>>>>>         >>          BIP. In addition, he provided an extremely
> detailed
> >>>>>>>        review of
> >>>>>>>         >>          all 300
> >>>>>>>         >>          pages of a draft of Mastering Bitcoin (3rd
> edition) and has
> >>>>>>>         >>          reviewed
> >>>>>>>         >>          drafts of over 200 weekly Optech newsletters,
> in both cases
> >>>>>>>         >>          significantly improving the accuracy and
> >>>>>>>        comprehensibility of the
> >>>>>>>         >>          documentation. To me, that seems very similar
> to the
> >>>>>>>        work we'd
> >>>>>>>         >>          ask him
> >>>>>>>         >>          to perform as a BIPs editor and it's something
> that
> >>>>>>>        he's already
> >>>>>>>         >>          doing,
> >>>>>>>         >>          so I think there's an excellent fit of person
> to role.
> >>>>>>>         >>
> >>>>>>>         >>          -Dave
> >>>>>>>         >>
> >>>>>>>         >>          [1]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
> >>>>>>>        <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/> <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/
> <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/
> >>
> >>>>>>>         >>          [2]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
> >>>>>>>        <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>
> >>>>>>>        <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/
> <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/
> >>
> >>>>>>>         >>          [3]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/
> >>
> >>>>>>>         >>          [4]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>
> <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/
> <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/
> >>
> >>>>>>>         >>          [5]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/
> >>
> >>>>>>>         >>          [6]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/
> >>
> >>>>>>>         >>          [7]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/
> >>
> >>>>>>>         >>          [8]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/
> >>
> >>>>>>>         >>          [9]
> >>>>>>>        https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> >>>>>>>        <
> https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
> >>>>>>>         >>
> >>>>>>>        <
> https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
> >>>>>>>        <
> https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>>
> >>>>>>>         >>          [10]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/
> <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/
> >>
> >>>>>>>         >>          [11]
> >>>>>>>        https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >
> >>>>>>>         >>
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >>>>>>>        <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >>
> >>>>>>>         >>          [12]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/
> >>
> >>>>>>>         >>          [13]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
> >>>>>>>        <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>
> >>>>>>>        <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> >>
> >>>>>>>         >>          [14]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
> >>>>>>>        <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/> <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/
> <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/
> >>
> >>>>>>>         >>          [15]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> >>
> >>>>>>>         >>          [16]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/
> >>
> >>>>>>>         >>          [17]
> >>>>>>>         >>
> >>>>>>>
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
> >>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >>>>>>>         >>      <mailto:bitcoindev+unsubscribe@googlegroups•com
> >>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>>.
> >>>>>>>         >>      To view this discussion on the web visit
> >>>>>>>         >>
> >>>>>>>
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com>
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer
> >>.
> >>>>>>>         >>
> >>>>>>>         >>
> >>>>>>>         >>
> >>>>>>>         >> --
> >>>>>>>         >> Sergi.
> >>>>>>>         >>
> >>>>>>>         >> --
> >>>>>>>         >> 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
> >>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >>>>>>>         >> <mailto:bitcoindev+unsubscribe@googlegroups•com
> >>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>>.
> >>>>>>>         >> To view this discussion on the web visit
> >>>>>>>         >>
> >>>>>>>
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com>
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.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
> >>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
> >>>>>>>         > To view this discussion on the web visit
> >>>>>>>
> https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com
> <
> https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.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
> >>>>>>>        <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>.
> >>>>>>>        To view this discussion on the web visit
> >>>>>>>
> https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com
> <
> https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.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/0d4d85e3-9fbb-4bd4-af0f-92225e699b63%40achow101.com
> .
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Michael Folkson
> >>>>> Personal email: michaelfolkson@gmail•com
> >>>>
> >>>
> >>>
> >>> --
> >>> Michael Folkson
> >>> Personal email: michaelfolkson@gmail•com
> >>
> >
> >
> > --
> > Michael Folkson
> > Personal email: michaelfolkson@gmail•com
>
> --
> 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+unsubscribe@googlegroups•com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/bitcoindev/84bb3ca1-a18e-48c8-a934-6fcef5470a36%40achow101.com
> .
>

-- 


[-- Attachment #2: Type: text/html, Size: 66556 bytes --]

 permalink raw reply	[|nested]
* 
  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 21:08                               ` 'Ava Chow' via Bitcoin Development Mailing List
  2024-04-21 23:01                             ` 
                                               ` 
  5 siblings, 1 reply; 100+ messages in thread
From: Steve Lee @ 2024-04-20 20:46 UTC (permalink / raw)
  To: Ava Chow;  bitcoindev

[-- Attachment #1: Type: text/plain, Size: 14712 bytes --]

Wasn't there evidence provided that Kanzure does not want this
responsibility without being paid?

I'm confused by this process that we don't even ask the people if they want
the responsibility? I think only Laolu has chimed in to commit to it?

On Sat, Apr 20, 2024 at 12:30 PM 'Ava Chow' via Bitcoin Development Mailing
List <bitcoindev@googlegroups.com> wrote:

> Since we're now past the deadline of April 19th, I'd like to inform
> everyone of what will happen on Monday.
>
> There has not been any actual objections to the nominees nor have there
> been any suggestions on choosing a subset of them since my last email.
> As such, there is rough consensus on adding Kanzure, Murch, Jonatack,
> Ruben, and Roasbeef as BIP editors, and they will be added on Monday
> April 22nd.
>
> Ava
>
> On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development Mailing List
> wrote:
> > While I don't disagree that 5 or 6 people seems like a lot to add at
> > once, it's not clear to me how we should decide which subset of the
> > nominees should be added. As it is now, I have only seen an actual
> > objection to Kanzure and Ruben from /dev/fd0, and no explicit objections
> > to anyone else. It seems like the vast majority of people don't share
> > their concerns either as both Kanzure and Ruben continue to be endorsed
> > by many others.
> >
> > Looking at the endorsements each candidate has received, the current
> > counts are:
> > * Kanzure - 17 for, 1 against
> > * Murch - 13 for
> > * Jonatack - 13 for
> > * Ruben - 12 for, 1 against
> > * Roasbeef - 9 for
> > * Michael Folkson - none
> >
> > However, I don't want this process to become a popularity contest and
> > require some kind of formal voting. Rather I'd prefer that this process
> > be something more like how Bitcoin Core maintainers are added - by
> > achieving rough consensus. Without any explicit objections to any of
> > these candidates, I'm inclined to move forward with adding the 5 who
> > have received endorsements. Having to pick "winners" from this list
> > seems like a quick way to stir up drama that I don't think anyone really
> > wants to deal with.
> >
> > I do want to note that neither Kanzure, Ruben, nor Roasbeef have posted
> > on this list that they are willing to be BIP editors. I have reached out
> > to all 3 of them privately, and received responses from Kanzure and
> > Ruben that indicate that they probably are willing, but public
> > confirmation from them on this list would also be nice. I have not
> > received a response from Roasbeef.
> >
> > Ava
> >
> > On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
> >>   > I would prefer having more (9+?) than less folks on this task, so
> >> personal preferences are easily ignored and overwritten by the group
> >> majority.
> >>
> >> I disagree with that, the more doesn't really the better here. Having
> >> too many editors may result in a tragedy of the commons, in which people
> >> just commit to the job because many others do, and they do not end up
> >> doing as much because they expect others to do the it. This does not
> >> only make the process look bad but may burnout the ones that end up
> >> doing the job, given their time commitment ends up being too far from
> >> their expectations.
> >>
> >> I think being more moderate with the amount of people is better, and
> >> gives us leeway in case the workload ends up being excessive and we need
> >> to add more people (plus discourage people from joining and slacking
> off).
> >>
> >> I think 3 more people should be a good number to start from.
> >> I'd personally vouch for Murch, Kanzure, and Ruben based on their track
> >> record in the space
> >>
> >> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com
> >> <mailto:rdlfnvk@gmail•com>> wrote:
> >>
> >> +1 for
> >> Kanzure
> >> RubenSomsen
> >> Seccour
> >> Jon Atack
> >> Roasbeef
> >>
> >> I would prefer having more (9+?) than less folks on this task, so
> >> personal preferences are easily ignored and overwritten by the group
> >> majority.
> >>
> >> BIPs were intended as a means to collect ideas, not enforce ideas.
> >>
> >> I'd like to return to that.
> >>
> >> - NVK (temp gmail account)
> >>
> >>      On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A. Harding
> wrote:
> >>
> >>          On 2024-03-28 10:04, Matt Corallo wrote:
> >>           > Please provide justification rather than simply saying "I
> >>          like Bob!".
> >>
> >>          Using only comments from the mailing list, the following
> appears
> >>          to be
> >>          the candidate list along with the current support. Asterisks
> denote
> >>          candidates who indicated their willingness to accept the role.
> >>
> >>          - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris
> >>          Stewart[3],
> >>          Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon
> >>          Black[11],
> >>          Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
> >>          Carvalho[16]
> >>
> >>          - Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3],
> >>          Michael
> >>          Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15],
> John
> >>          Carvalho[16]
> >>
> >>          - Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3],
> >>          /dev/fd0[5][7],
> >>          Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
> >>          Carvalho[16]
> >>
> >>          - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
> >>          Stewart[3], John
> >>          C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine
> >>          Riard[12], Ava Chow[14]
> >>
> >>          - Mark "Murch" Erhardt*, recommended by Michael Folkson[6],
> Keagan
> >>          McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine
> >>          Riard[12],
> >>          Ava Chow[14]
> >>
> >>          - Michael Folkson*
> >>
> >>          Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for
> >>          "non-dev
> >>          triaging", Tonoski proposed himself[18] for "BIP editor", and
> >>          Antoine
> >>          Riard[12] proposed Seccour for "decentralized PM".
> >>
> >>          I searched the BIPs repo by commenter to see if any of the
> above
> >>          candidates had been especially active there, which is listed
> >>          below as:
> >>          total PRs they commented on (number still open/number closed).
> >>
> >>          - 21 (1/20) commenter:kanzure
> >>          - 3 (2/1) commenter:rubensomsen
> >>          - 15 (0/15) commenter:jonatack
> >>          - 18 (2/16) commenter:roasbeef
> >>          - 10 (6/4) commenter:Murchandamus
> >>          - 57 (6/51) commenter:michaelfolkson
> >>
> >>          I'll also note that Osuntokun is the only member of the set to
> >>          have a
> >>          merged BIP that they co-authored, although I believe there are
> >>          far-along
> >>          draft BIPs for both Murch (terminology) and Somsen (Silent
> >>          Payments). I
> >>          don't think this should be a requirement, but I do think it
> >>          demonstrates
> >>          familiarity with the process.
> >>
> >>          Speaking only for myself, I think all of the candidates above
> with
> >>          multiple recommendations from other community participants are
> >>          fully
> >>          qualified for the role, so I'll only provide a detailed
> >>          justification
> >>          for the person who would be my first pick: Murch is not only a
> >>          longstanding and broadly liked Bitcoin contributor, but (as
> Corallo
> >>          mentioned) he has worked on standardizing terminology through a
> >>          draft
> >>          BIP. In addition, he provided an extremely detailed review of
> >>          all 300
> >>          pages of a draft of Mastering Bitcoin (3rd edition) and has
> >>          reviewed
> >>          drafts of over 200 weekly Optech newsletters, in both cases
> >>          significantly improving the accuracy and comprehensibility of
> the
> >>          documentation. To me, that seems very similar to the work we'd
> >>          ask him
> >>          to perform as a BIPs editor and it's something that he's
> already
> >>          doing,
> >>          so I think there's an excellent fit of person to role.
> >>
> >>          -Dave
> >>
> >>          [1]
> >>
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/
> >
> >>          [2]
> >>
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/
> >
> >>          [3]
> >>
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/
> >
> >>          [4]
> >>
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/
> >
> >>          [5]
> >>
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/
> >
> >>          [6]
> >>
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/
> >
> >>          [7]
> >>
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/
> >
> >>          [8]
> >>
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/
> >
> >>          [9]
> https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> >>          <
> https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
> >>          [10]
> >>
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/
> >
> >>          [11]
> https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >>          <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
> >>          [12]
> >>
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/
> >
> >>          [13]
> >>
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/ <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> >
> >>          [14]
> >>
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/
> >
> >>          [15]
> >>
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> >
> >>          [16]
> >>
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/
> >
> >>          [17]
> >>
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
> >>      <mailto:bitcoindev+unsubscribe@googlegroups•com>.
> >>      To view this discussion on the web visit
> >>
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer
> >.
> >>
> >>
> >>
> >> --
> >> Sergi.
> >>
> >> --
> >> 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
> >> <mailto:bitcoindev+unsubscribe@googlegroups•com>.
> >> To view this discussion on the web visit
> >>
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.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/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.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/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com
> .
>

-- 


[-- Attachment #2: Type: text/html, Size: 23967 bytes --]

^ permalink raw reply	[|nested] 100+ messages in thread
2024-04-21 23:01                             ` Matt Corallo

  
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2024-04-22  0:06 UTC (permalink / raw)
  To: Matt Corallo, bitcoindev

Okay, it was not clear to me that the questions about whether he had the 
time were actually objections. However, his response[1] indicates that 
he does not think that time will be an issue, so I think that complaint 
is sufficiently addressed.

As for Ruben and Jon, I think it's clear that others on this list think 
that they are well suited for the role.

Ava

[1]: 
https://gnusha.org/pi/bitcoindev/CAO3Pvs8B+NVWFUxg6zfNXYrAfX9mhqpj9ZpNSEr4HWUbJKnNmw@mail.gmail.com/

On 04/21/2024 07:01 PM, Matt Corallo wrote:
> I'm a bit confused, several people have suggested that Roasbeef clearly doesn't have the time
> commitment to be added as a BIP editor, and I previously noted that of the list of people, only
> Kanzure and Murch have been around for a long period of time and demonstrated depth in the kind of
> Bitcoin technical nomenclature and copy-editing required for this role, largely via Kanzure's long
> history of Bitcoin technical transcriptions and Murch's work on stack exchange and the nomenclature
> BIP at https://github.com/murchandamus/bips/pull/1/files.
> 
> For the avoidance of doubt, this is an objection to the rest of the list.
> 
> Matt
> 
> On 4/20/24 3:14 PM, 'Ava Chow' via Bitcoin Development Mailing List wrote:
>> Since we're now past the deadline of April 19th, I'd like to inform
>> everyone of what will happen on Monday.
>>
>> There has not been any actual objections to the nominees nor have there
>> been any suggestions on choosing a subset of them since my last email.
>> As such, there is rough consensus on adding Kanzure, Murch, Jonatack,
>> Ruben, and Roasbeef as BIP editors, and they will be added on Monday
>> April 22nd.
>>
>> Ava
>>
>> On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development Mailing List
>> wrote:
>>> While I don't disagree that 5 or 6 people seems like a lot to add at
>>> once, it's not clear to me how we should decide which subset of the
>>> nominees should be added. As it is now, I have only seen an actual
>>> objection to Kanzure and Ruben from /dev/fd0, and no explicit objections
>>> to anyone else. It seems like the vast majority of people don't share
>>> their concerns either as both Kanzure and Ruben continue to be endorsed
>>> by many others.
>>>
>>> Looking at the endorsements each candidate has received, the current
>>> counts are:
>>> * Kanzure - 17 for, 1 against
>>> * Murch - 13 for
>>> * Jonatack - 13 for
>>> * Ruben - 12 for, 1 against
>>> * Roasbeef - 9 for
>>> * Michael Folkson - none
>>>
>>> However, I don't want this process to become a popularity contest and
>>> require some kind of formal voting. Rather I'd prefer that this process
>>> be something more like how Bitcoin Core maintainers are added - by
>>> achieving rough consensus. Without any explicit objections to any of
>>> these candidates, I'm inclined to move forward with adding the 5 who
>>> have received endorsements. Having to pick "winners" from this list
>>> seems like a quick way to stir up drama that I don't think anyone really
>>> wants to deal with.
>>>
>>> I do want to note that neither Kanzure, Ruben, nor Roasbeef have posted
>>> on this list that they are willing to be BIP editors. I have reached out
>>> to all 3 of them privately, and received responses from Kanzure and
>>> Ruben that indicate that they probably are willing, but public
>>> confirmation from them on this list would also be nice. I have not
>>> received a response from Roasbeef.
>>>
>>> Ava
>>>
>>> On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
>>>>     > I would prefer having more (9+?) than less folks on this task, so
>>>> personal preferences are easily ignored and overwritten by the group
>>>> majority.
>>>>
>>>> I disagree with that, the more doesn't really the better here. Having
>>>> too many editors may result in a tragedy of the commons, in which people
>>>> just commit to the job because many others do, and they do not end up
>>>> doing as much because they expect others to do the it. This does not
>>>> only make the process look bad but may burnout the ones that end up
>>>> doing the job, given their time commitment ends up being too far from
>>>> their expectations.
>>>>
>>>> I think being more moderate with the amount of people is better, and
>>>> gives us leeway in case the workload ends up being excessive and we need
>>>> to add more people (plus discourage people from joining and slacking off).
>>>>
>>>> I think 3 more people should be a good number to start from.
>>>> I'd personally vouch for Murch, Kanzure, and Ruben based on their track
>>>> record in the space
>>>>
>>>> On Tue, Apr 2, 2024 at 4:30 PM nvk <rdlfnvk@gmail•com
>>>> <mailto:rdlfnvk@gmail•com>> wrote:
>>>>
>>>> +1 for
>>>> Kanzure
>>>> RubenSomsen
>>>> Seccour
>>>> Jon Atack
>>>> Roasbeef
>>>>
>>>> I would prefer having more (9+?) than less folks on this task, so
>>>> personal preferences are easily ignored and overwritten by the group
>>>> majority.
>>>>
>>>> BIPs were intended as a means to collect ideas, not enforce ideas.
>>>>
>>>> I'd like to return to that.
>>>>
>>>> - NVK (temp gmail account)
>>>>
>>>>        On Monday, April 1, 2024 at 5:16:54 PM UTC-4 David A. Harding wrote:
>>>>
>>>>            On 2024-03-28 10:04, Matt Corallo wrote:
>>>>             > Please provide justification rather than simply saying "I
>>>>            like Bob!".
>>>>
>>>>            Using only comments from the mailing list, the following appears
>>>>            to be
>>>>            the candidate list along with the current support. Asterisks denote
>>>>            candidates who indicated their willingness to accept the role.
>>>>
>>>>            - Bryan "Kanzure" Bishop, recommended by Ava Chow[1], Chris
>>>>            Stewart[3],
>>>>            Michael Folkson[6], Peter Todd[9], Matt Corallo[10], Brandon
>>>>            Black[11],
>>>>            Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>>>>            Carvalho[16]
>>>>
>>>>            - Ruben Somsen, recommended by Ava Chow[1], Chris Stewart[3],
>>>>            Michael
>>>>            Folkson[6], Antoine Riard[12], Murch[13], Antoine Poinsot[15], John
>>>>            Carvalho[16]
>>>>
>>>>            - Jon Atack*, recommended by Luke Dashjr[2], Chris Stewart[3],
>>>>            /dev/fd0[5][7],
>>>>            Brandon Black[11], Antoine Riard[12], Ava Chow[14], John
>>>>            Carvalho[16]
>>>>
>>>>            - Olaoluwa "Roasbeef" Osuntokun, recommended by Chris
>>>>            Stewart[3], John
>>>>            C. Vernaleo[4], /dev/fd0[5][7], Keagan McClelland[8], Antoine
>>>>            Riard[12], Ava Chow[14]
>>>>
>>>>            - Mark "Murch" Erhardt*, recommended by Michael Folkson[6], Keagan
>>>>            McClelland[8], Matt Corallo[10], Brandon Black[11], Antoine
>>>>            Riard[12],
>>>>            Ava Chow[14]
>>>>
>>>>            - Michael Folkson*
>>>>
>>>>            Note: Luke Dashjr proposed[17] Seccour and Greg Tonoski for
>>>>            "non-dev
>>>>            triaging", Tonoski proposed himself[18] for "BIP editor", and
>>>>            Antoine
>>>>            Riard[12] proposed Seccour for "decentralized PM".
>>>>
>>>>            I searched the BIPs repo by commenter to see if any of the above
>>>>            candidates had been especially active there, which is listed
>>>>            below as:
>>>>            total PRs they commented on (number still open/number closed).
>>>>
>>>>            - 21 (1/20) commenter:kanzure
>>>>            - 3 (2/1) commenter:rubensomsen
>>>>            - 15 (0/15) commenter:jonatack
>>>>            - 18 (2/16) commenter:roasbeef
>>>>            - 10 (6/4) commenter:Murchandamus
>>>>            - 57 (6/51) commenter:michaelfolkson
>>>>
>>>>            I'll also note that Osuntokun is the only member of the set to
>>>>            have a
>>>>            merged BIP that they co-authored, although I believe there are
>>>>            far-along
>>>>            draft BIPs for both Murch (terminology) and Somsen (Silent
>>>>            Payments). I
>>>>            don't think this should be a requirement, but I do think it
>>>>            demonstrates
>>>>            familiarity with the process.
>>>>
>>>>            Speaking only for myself, I think all of the candidates above with
>>>>            multiple recommendations from other community participants are
>>>>            fully
>>>>            qualified for the role, so I'll only provide a detailed
>>>>            justification
>>>>            for the person who would be my first pick: Murch is not only a
>>>>            longstanding and broadly liked Bitcoin contributor, but (as Corallo
>>>>            mentioned) he has worked on standardizing terminology through a
>>>>            draft
>>>>            BIP. In addition, he provided an extremely detailed review of
>>>>            all 300
>>>>            pages of a draft of Mastering Bitcoin (3rd edition) and has
>>>>            reviewed
>>>>            drafts of over 200 weekly Optech newsletters, in both cases
>>>>            significantly improving the accuracy and comprehensibility of the
>>>>            documentation. To me, that seems very similar to the work we'd
>>>>            ask him
>>>>            to perform as a BIPs editor and it's something that he's already
>>>>            doing,
>>>>            so I think there's an excellent fit of person to role.
>>>>
>>>>            -Dave
>>>>
>>>>            [1]
>>>>            https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>
>>>>            [2]
>>>>            https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>
>>>>            [3]
>>>>            https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>
>>>>            [4]
>>>>            https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>
>>>>            [5]
>>>>            https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>
>>>>            [6]
>>>>            https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>
>>>>            [7]
>>>>            https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>
>>>>            [8]
>>>>            https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>
>>>>            [9] https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
>>>>            <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
>>>>            [10]
>>>>            https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>
>>>>            [11] https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
>>>>            <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
>>>>            [12]
>>>>            https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>
>>>>            [13]
>>>>            https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/ <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>
>>>>            [14]
>>>>            https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>
>>>>            [15]
>>>>            https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/ <https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>
>>>>            [16]
>>>>            https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>
>>>>            [17]
>>>>            https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/ <https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
>>>>        <mailto:bitcoindev+unsubscribe@googlegroups•com>.
>>>>        To view this discussion on the web visit
>>>>        https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>>>
>>>>
>>>>
>>>> --
>>>> Sergi.
>>>>
>>>> --
>>>> 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
>>>> <mailto:bitcoindev+unsubscribe@googlegroups•com>.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com <https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>>>
>>> --
>>> 


 permalink raw reply	[|nested]
2024-04-20 22:47                                       ` 'Ava Chow' via Bitcoin Development Mailing List

  
From: Steve Lee @ 2024-04-22  2:44 UTC (permalink / raw)
  To: Ava Chow;  bitcoindev

[-- Attachment #1: Type: text/plain, Size: 59750 bytes --]

Hi Ava,

I hadn't seen until just now your post prior to nsvrn's post which stated:
"I do want to note that neither Kanzure, Ruben, nor Roasbeef have posted on
this list that they are willing to be BIP editors. I have reached out to
all 3 of them privately, and received responses from Kanzure and Ruben that
indicate that they probably are willing, but public confirmation from them
on this list would also be nice. I have not received a response from
Roasbeef."

This is exactly what I had a concern about, and I unfortunately hadn't seen
it before replying to this thread. I apologize for the unnecessary
responses from me.

Thanks for dealing with all of this and helping us drive to a conclusion.

Steve

On Sat, Apr 20, 2024 at 3:47 PM Ava Chow <lists@achow101•com> wrote:

> I saw that email and read the tweet. It doesn't seem to me that nsvrn
> was raising an objection to Kanzure, just pointing out something for
> people to consider. No one else has said anything, so I'm assuming that
> no minds have changed considering this information. It'd be ridiculous
> if every time new information was presented that we went to everyone and
> ask them whether their stance has changed. It's all the same email
> thread, if their mind has changed, then they can inform us as a reply.
>
> Furthermore, I fail to see how this tweet matches your claim that he
> "does not want this responsibility without being paid". Saying that he
> has better things to do with his time doesn't necessarily mean that he
> won't do it, and other such tweets, including his own replies to this
> one, indicate the he is.
>
> If your concern is about his reply to the suggestion that being paid
> would change things substantially, I still don't see how that matches
> the statement you made earlier. Being paid to do any task would change
> the calculus on whether someone wants to do something, but that doesn't
> mean they won't do it even if unpaid.
>
> Ava
>
> On 04/20/2024 06:03 PM, Steve Lee wrote:
> > nsvrn posted a days ago. Here's the tweet
> > https://x.com/kanzure/status/1766888650069967053
> > <https://x.com/kanzure/status/1766888650069967053>
> >
> > Ava, I'm just requesting people acknowledge legitimate concerns raised
> > and be transparent. Do you disagree?
> >
> > On Sat, Apr 20, 2024 at 2:37 PM Ava Chow <lists@achow101•com
> > <mailto:lists@achow101•com>> wrote:
> >
> >     On 04/20/2024 05:11 PM, Steve Lee wrote:
> >      >
> >      >     I am not aware of that, and it hasn't come up when I've
> >     talked to him
> >      >     about being a BIPs editor.
> >      >
> >      >
> >      > You should read this thread then before making a decision.
> >
> >     Thank you for your snarky reply.
> >
> >     I have, in fact, read every email in this thread. But there's 80+
> >     emails
> >     in this thread and it's spread over 2 months, so it's possible I've
> >     missed something. With that in mind, I've just spent the last 10
> >     minutes
> >     searching through the archive and cannot find any mention of Kanzure
> or
> >     anyone else saying that he would only be a BIP editor for payment. If
> >     you think I'm mistaken, I ask that you please provide a link to this
> >     evidence.
> >
> >      >     Personally, I've spoken to all 5 privately and they've all
> >     confirmed to
> >      >     me that they are willing to be BIPs editors. Jonatack[1] and
> >     Murch[2]
> >      >     have also replied to this thread about this.
> >      >
> >      >
> >      > Ok good to know. Would've been nice to share this here so
> >     everyone was
> >      > aware.
> >
> >     You should read this thread before making such assumptions.
> >
> >     I informed the list[1] 4 days ago that I reached out privately to and
> >     got responses from Kanzure and Ruben. While I did the same with
> >     Jonatack
> >     and Murch, I did not feel the need to mention that because, if you've
> >     read this thread, they had already publicly confirmed their
> willingness.
> >
> >     Ava
> >
> >     [1]:
> >
> https://gnusha.org/pi/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1@achow101.com/
> <
> https://gnusha.org/pi/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1@achow101.com/
> >
> >
> >      >
> >      >
> >      >
> >      >     Ava
> >      >
> >      >     [1]:
> >      >
> >
> https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0bbn@googlegroups.com/
> >>
> >      >     [2]:
> >      >
> >
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>
> <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> >>
> >      >
> >      >      >
> >      >      > On Sat, Apr 20, 2024 at 12:30 PM 'Ava Chow' via Bitcoin
> >     Development
> >      >      > Mailing List <bitcoindev@googlegroups.com
> >     <mailto:bitcoindev@googlegroups.com>
> >      >     <mailto:bitcoindev@googlegroups.com
> >     <mailto:bitcoindev@googlegroups.com>>
> >      >      > <mailto:bitcoindev@googlegroups.com
> >     <mailto:bitcoindev@googlegroups.com>
> >      >     <mailto:bitcoindev@googlegroups.com
> >     <mailto:bitcoindev@googlegroups.com>>>> wrote:
> >      >      >
> >      >      >     Since we're now past the deadline of April 19th, I'd
> >     like to
> >      >     inform
> >      >      >     everyone of what will happen on Monday.
> >      >      >
> >      >      >     There has not been any actual objections to the
> >     nominees nor
> >      >     have there
> >      >      >     been any suggestions on choosing a subset of them
> since my
> >      >     last email.
> >      >      >     As such, there is rough consensus on adding Kanzure,
> >     Murch,
> >      >     Jonatack,
> >      >      >     Ruben, and Roasbeef as BIP editors, and they will be
> >     added on
> >      >     Monday
> >      >      >     April 22nd.
> >      >      >
> >      >      >     Ava
> >      >      >
> >      >      >     On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin
> Development
> >      >     Mailing List
> >      >      >     wrote:
> >      >      >      > While I don't disagree that 5 or 6 people seems
> >     like a lot
> >      >     to add at
> >      >      >      > once, it's not clear to me how we should decide
> which
> >      >     subset of the
> >      >      >      > nominees should be added. As it is now, I have only
> >     seen
> >      >     an actual
> >      >      >      > objection to Kanzure and Ruben from /dev/fd0, and
> >     no explicit
> >      >      >     objections
> >      >      >      > to anyone else. It seems like the vast majority of
> >     people
> >      >     don't share
> >      >      >      > their concerns either as both Kanzure and Ruben
> >     continue to be
> >      >      >     endorsed
> >      >      >      > by many others.
> >      >      >      >
> >      >      >      > Looking at the endorsements each candidate has
> >     received,
> >      >     the current
> >      >      >      > counts are:
> >      >      >      > * Kanzure - 17 for, 1 against
> >      >      >      > * Murch - 13 for
> >      >      >      > * Jonatack - 13 for
> >      >      >      > * Ruben - 12 for, 1 against
> >      >      >      > * Roasbeef - 9 for
> >      >      >      > * Michael Folkson - none
> >      >      >      >
> >      >      >      > However, I don't want this process to become a
> >     popularity
> >      >     contest and
> >      >      >      > require some kind of formal voting. Rather I'd
> >     prefer that
> >      >     this
> >      >      >     process
> >      >      >      > be something more like how Bitcoin Core maintainers
> are
> >      >     added - by
> >      >      >      > achieving rough consensus. Without any explicit
> >     objections
> >      >     to any of
> >      >      >      > these candidates, I'm inclined to move forward with
> >     adding
> >      >     the 5 who
> >      >      >      > have received endorsements. Having to pick
> >     "winners" from
> >      >     this list
> >      >      >      > seems like a quick way to stir up drama that I
> >     don't think
> >      >     anyone
> >      >      >     really
> >      >      >      > wants to deal with.
> >      >      >      >
> >      >      >      > I do want to note that neither Kanzure, Ruben, nor
> >      >     Roasbeef have
> >      >      >     posted
> >      >      >      > on this list that they are willing to be BIP
> >     editors. I have
> >      >      >     reached out
> >      >      >      > to all 3 of them privately, and received responses
> from
> >      >     Kanzure and
> >      >      >      > Ruben that indicate that they probably are willing,
> >     but public
> >      >      >      > confirmation from them on this list would also be
> >     nice. I
> >      >     have not
> >      >      >      > received a response from Roasbeef.
> >      >      >      >
> >      >      >      > Ava
> >      >      >      >
> >      >      >      > On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote:
> >      >      >      >>   > I would prefer having more (9+?) than less
> >     folks on this
> >      >      >     task, so
> >      >      >      >> personal preferences are easily ignored and
> >     overwritten
> >      >     by the group
> >      >      >      >> majority.
> >      >      >      >>
> >      >      >      >> I disagree with that, the more doesn't really the
> >     better
> >      >     here.
> >      >      >     Having
> >      >      >      >> too many editors may result in a tragedy of the
> >     commons, in
> >      >      >     which people
> >      >      >      >> just commit to the job because many others do, and
> >     they
> >      >     do not
> >      >      >     end up
> >      >      >      >> doing as much because they expect others to do the
> it.
> >      >     This does not
> >      >      >      >> only make the process look bad but may burnout the
> >     ones
> >      >     that end up
> >      >      >      >> doing the job, given their time commitment ends up
> >     being
> >      >     too far
> >      >      >     from
> >      >      >      >> their expectations.
> >      >      >      >>
> >      >      >      >> I think being more moderate with the amount of
> >     people is
> >      >     better, and
> >      >      >      >> gives us leeway in case the workload ends up being
> >      >     excessive and
> >      >      >     we need
> >      >      >      >> to add more people (plus discourage people from
> >     joining and
> >      >      >     slacking off).
> >      >      >      >>
> >      >      >      >> I think 3 more people should be a good number to
> >     start from.
> >      >      >      >> I'd personally vouch for Murch, Kanzure, and Ruben
> >     based on
> >      >      >     their track
> >      >      >      >> record in the space
> >      >      >      >>
> >      >      >      >> On Tue, Apr 2, 2024 at 4:30 PM nvk
> >     <rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>
> >      >     <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>>
> >      >      >     <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>
> >     <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>>>
> >      >      >      >> <mailto:rdlfnvk@gmail•com
> >     <mailto:rdlfnvk@gmail•com> <mailto:rdlfnvk@gmail•com
> >     <mailto:rdlfnvk@gmail•com>>
> >      >     <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>
> >     <mailto:rdlfnvk@gmail•com <mailto:rdlfnvk@gmail•com>>>>> wrote:
> >      >      >      >>
> >      >      >      >> +1 for
> >      >      >      >> Kanzure
> >      >      >      >> RubenSomsen
> >      >      >      >> Seccour
> >      >      >      >> Jon Atack
> >      >      >      >> Roasbeef
> >      >      >      >>
> >      >      >      >> I would prefer having more (9+?) than less folks
> >     on this
> >      >     task, so
> >      >      >      >> personal preferences are easily ignored and
> >     overwritten
> >      >     by the group
> >      >      >      >> majority.
> >      >      >      >>
> >      >      >      >> BIPs were intended as a means to collect ideas, not
> >      >     enforce ideas.
> >      >      >      >>
> >      >      >      >> I'd like to return to that.
> >      >      >      >>
> >      >      >      >> - NVK (temp gmail account)
> >      >      >      >>
> >      >      >      >>      On Monday, April 1, 2024 at 5:16:54 PM UTC-4
> >     David A.
> >      >      >     Harding wrote:
> >      >      >      >>
> >      >      >      >>          On 2024-03-28 10:04, Matt Corallo wrote:
> >      >      >      >>           > Please provide justification rather
> >     than simply
> >      >      >     saying "I
> >      >      >      >>          like Bob!".
> >      >      >      >>
> >      >      >      >>          Using only comments from the mailing
> >     list, the
> >      >      >     following appears
> >      >      >      >>          to be
> >      >      >      >>          the candidate list along with the current
> >     support.
> >      >      >     Asterisks denote
> >      >      >      >>          candidates who indicated their
> >     willingness to accept
> >      >      >     the role.
> >      >      >      >>
> >      >      >      >>          - Bryan "Kanzure" Bishop, recommended by
> Ava
> >      >     Chow[1], Chris
> >      >      >      >>          Stewart[3],
> >      >      >      >>          Michael Folkson[6], Peter Todd[9], Matt
> >     Corallo[10],
> >      >      >     Brandon
> >      >      >      >>          Black[11],
> >      >      >      >>          Antoine Riard[12], Murch[13], Antoine
> >      >     Poinsot[15], John
> >      >      >      >>          Carvalho[16]
> >      >      >      >>
> >      >      >      >>          - Ruben Somsen, recommended by Ava
> >     Chow[1], Chris
> >      >      >     Stewart[3],
> >      >      >      >>          Michael
> >      >      >      >>          Folkson[6], Antoine Riard[12], Murch[13],
> >     Antoine
> >      >      >     Poinsot[15], John
> >      >      >      >>          Carvalho[16]
> >      >      >      >>
> >      >      >      >>          - Jon Atack*, recommended by Luke
> >     Dashjr[2], Chris
> >      >      >     Stewart[3],
> >      >      >      >>          /dev/fd0[5][7],
> >      >      >      >>          Brandon Black[11], Antoine Riard[12], Ava
> >      >     Chow[14], John
> >      >      >      >>          Carvalho[16]
> >      >      >      >>
> >      >      >      >>          - Olaoluwa "Roasbeef" Osuntokun,
> >     recommended by
> >      >     Chris
> >      >      >      >>          Stewart[3], John
> >      >      >      >>          C. Vernaleo[4], /dev/fd0[5][7], Keagan
> >      >     McClelland[8],
> >      >      >     Antoine
> >      >      >      >>          Riard[12], Ava Chow[14]
> >      >      >      >>
> >      >      >      >>          - Mark "Murch" Erhardt*, recommended by
> >     Michael
> >      >      >     Folkson[6], Keagan
> >      >      >      >>          McClelland[8], Matt Corallo[10], Brandon
> >      >     Black[11], Antoine
> >      >      >      >>          Riard[12],
> >      >      >      >>          Ava Chow[14]
> >      >      >      >>
> >      >      >      >>          - Michael Folkson*
> >      >      >      >>
> >      >      >      >>          Note: Luke Dashjr proposed[17] Seccour
> >     and Greg
> >      >     Tonoski for
> >      >      >      >>          "non-dev
> >      >      >      >>          triaging", Tonoski proposed himself[18]
> >     for "BIP
> >      >      >     editor", and
> >      >      >      >>          Antoine
> >      >      >      >>          Riard[12] proposed Seccour for
> >     "decentralized PM".
> >      >      >      >>
> >      >      >      >>          I searched the BIPs repo by commenter to
> >     see if
> >      >     any of
> >      >      >     the above
> >      >      >      >>          candidates had been especially active
> there,
> >      >     which is
> >      >      >     listed
> >      >      >      >>          below as:
> >      >      >      >>          total PRs they commented on (number still
> >      >     open/number
> >      >      >     closed).
> >      >      >      >>
> >      >      >      >>          - 21 (1/20) commenter:kanzure
> >      >      >      >>          - 3 (2/1) commenter:rubensomsen
> >      >      >      >>          - 15 (0/15) commenter:jonatack
> >      >      >      >>          - 18 (2/16) commenter:roasbeef
> >      >      >      >>          - 10 (6/4) commenter:Murchandamus
> >      >      >      >>          - 57 (6/51) commenter:michaelfolkson
> >      >      >      >>
> >      >      >      >>          I'll also note that Osuntokun is the only
> >     member
> >      >     of the
> >      >      >     set to
> >      >      >      >>          have a
> >      >      >      >>          merged BIP that they co-authored,
> >     although I believe
> >      >      >     there are
> >      >      >      >>          far-along
> >      >      >      >>          draft BIPs for both Murch (terminology)
> and
> >      >     Somsen (Silent
> >      >      >      >>          Payments). I
> >      >      >      >>          don't think this should be a requirement,
> >     but I
> >      >     do think it
> >      >      >      >>          demonstrates
> >      >      >      >>          familiarity with the process.
> >      >      >      >>
> >      >      >      >>          Speaking only for myself, I think all of
> the
> >      >     candidates
> >      >      >     above with
> >      >      >      >>          multiple recommendations from other
> community
> >      >      >     participants are
> >      >      >      >>          fully
> >      >      >      >>          qualified for the role, so I'll only
> >     provide a
> >      >     detailed
> >      >      >      >>          justification
> >      >      >      >>          for the person who would be my first
> >     pick: Murch
> >      >     is not
> >      >      >     only a
> >      >      >      >>          longstanding and broadly liked Bitcoin
> >      >     contributor, but
> >      >      >     (as Corallo
> >      >      >      >>          mentioned) he has worked on standardizing
> >      >     terminology
> >      >      >     through a
> >      >      >      >>          draft
> >      >      >      >>          BIP. In addition, he provided an
> >     extremely detailed
> >      >      >     review of
> >      >      >      >>          all 300
> >      >      >      >>          pages of a draft of Mastering Bitcoin (3rd
> >      >     edition) and has
> >      >      >      >>          reviewed
> >      >      >      >>          drafts of over 200 weekly Optech
> >     newsletters, in
> >      >     both cases
> >      >      >      >>          significantly improving the accuracy and
> >      >      >     comprehensibility of the
> >      >      >      >>          documentation. To me, that seems very
> >     similar to the
> >      >      >     work we'd
> >      >      >      >>          ask him
> >      >      >      >>          to perform as a BIPs editor and it's
> >     something that
> >      >      >     he's already
> >      >      >      >>          doing,
> >      >      >      >>          so I think there's an excellent fit of
> >     person to
> >      >     role.
> >      >      >      >>
> >      >      >      >>          -Dave
> >      >      >      >>
> >      >      >      >>          [1]
> >      >      >      >>
> >      >      >
> >      >
> >     https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/
> >     <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/>
> >      >
> >       <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/>>
> >      >      >
> >      >
> >       <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/> <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/ <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow101.com/>>> <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/
> <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>
> <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/
> <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>>
> <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/
> <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/>
> <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/
> <
> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com/
> >>>>
> >      >      >      >>          [2]
> >      >      >      >>
> >      >      >
> >      >
> >     https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/
> >     <https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>
> >      >
> >       <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>>
> >      >      >
> >      >
> >       <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/> <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/ <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr.org/>>>
> >      >      >
> >      >
> >       <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/
> <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>
> <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/
> <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>>
> <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/
> <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/>
> <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/
> <
> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org/
> >>>>
> >      >      >      >>          [3]
> >      >      >      >>
> >      >      >
> >      >
> >
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>
> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>>
> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>
> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googlegroups.com/>>>
> <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>>
> <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com/
> >>>>
> >      >      >      >>          [4]
> >      >      >      >>
> >      >      >
> >      >
> >
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/ <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>
> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/
> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>>
> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/
> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>
> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/
> <https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpurgatory.com/>>>
> <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/
> <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>
> <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/
> <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>>
> <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/
> <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/>
> <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/
> <
> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com/
> >>>>
> >      >      >      >>          [5]
> >      >      >      >>
> >      >      >
> >      >
> >
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>
> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>>
> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>
> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googlegroups.com/>>>
> <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>>
> <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com/
> >>>>
> >      >      >      >>          [6]
> >      >      >      >>
> >      >      >
> >      >
> >
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>
> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>>
> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>
> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googlegroups.com/>>>
> <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>>
> <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2-a787-639a3564d006n@googlegroups.com/
> >>>>
> >      >      >      >>          [7]
> >      >      >      >>
> >      >      >
> >      >
> >
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>
> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>>
> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>
> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googlegroups.com/>>>
> <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>>
> <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com/
> >>>>
> >      >      >      >>          [8]
> >      >      >      >>
> >      >      >
> >      >
> >
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/>>
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5...@mail.gmail.com/>>>
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>>
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX=wruqgLEazRA5nVw9siYCPj4A@mail.gmail.com/
> >>>>
> >      >      >      >>          [9]
> >      >      >
> >     https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> >     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
> >      >     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> >     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>>
> >      >      >
> >       <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> >     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>
> >      >     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/
> >     <https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/>>>
> >      >      >      >>
> >      >      >
> >      >
> >       <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
> >     <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
> >      >
> >       <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
> >     <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>>
> >      >      >
> >      >
> >       <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
> >     <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/>
> >      >
> >       <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
> >     <https://gnusha.org/pi/bitcoindev/ZgePPvbfrr4wZG7k@petertodd.org/
> >>>>
> >      >      >      >>          [10]
> >      >      >      >>
> >      >      >
> >      >
> >
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/>>
> <https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/> <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/ <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattcorallo.com/>>>
> <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/
> <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>
> <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/
> <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>>
> <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/
> <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/>
> <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/
> <
> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5-86e2-7ba0336a9bf2@mattcorallo.com/
> >>>>
> >      >      >      >>          [11]
> >      >      > https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
> >      >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>
> >      >      >
> >       <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
> >      >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>>
> >      >      >      >>
> >      >      >
> >       <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
> >      >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>
> >      >      >
> >       <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>
> >      >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/
> >     <https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/>>>>
> >      >      >      >>          [12]
> >      >      >      >>
> >      >      >
> >      >
> >
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/>>
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E...@mail.gmail.com/>>>
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>>
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+EKMCP5oEbHSKSXpq0VKVBhJLhrw@mail.gmail.com/
> >>>>
> >      >      >      >>          [13]
> >      >      >      >>
> >      >      >
> >     https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
> >     <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>
> >      >
> >       <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
> >     <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>>
> >      >      >
> >      >
> >       <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
> >     <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/>
> >      >
> >       <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
> >     <https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch.one/
> >>>
> >      >      >
> >      >
> >       <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>
> <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>>
> <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/>
> <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> <
> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e778@murch.one/
> >>>>
> >      >      >      >>          [14]
> >      >      >      >>
> >      >      >
> >      >
> >     https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/
> >     <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>
> >      >
> >       <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>>
> >      >      >
> >      >
> >       <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/> <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/ <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow101.com/>>> <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/
> <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>
> <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/
> <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>>
> <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/
> <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/>
> <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/
> <
> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f-866d-c555b80b0644@achow101.com/
> >>>>
> >      >      >      >>          [15]
> >      >      >      >>
> >      >      >
> >      >
> >
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>>
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>>>
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>>
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> <
> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4xojo=@protonmail.com/
> >>>>
> >      >      >      >>          [16]
> >      >      >      >>
> >      >      >
> >      >
> >
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/ <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>
> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>>
> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>
> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/
> <https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googlegroups.com/>>>
> <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>>
> <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/>
> <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/
> <
> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552-88ca-11b9ed340661n@googlegroups.com/
> >>>>
> >      >      >      >>          [17]
> >      >      >      >>
> >      >      >
> >      >
> >
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/>>
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+...@mail.gmail.com/>>>
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/>>
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/>
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.gmail.com/
> <
> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU==YJMvd9Qrst+nmyypaedYZgg@mail.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
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>
> >      >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>
> >      >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%25252Bunsubscribe@googlegroups•com>>>
> >      >      >      >>
> >     <mailto:bitcoindev+unsubscribe@googlegroups•com
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>
> >      >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>
> >      >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%25252Bunsubscribe@googlegroups•com>>>>.
> >      >      >      >>      To view this discussion on the web visit
> >      >      >      >>
> >      >      >
> >      >
> >
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com>
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com>>
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com>
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com>>>
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>>
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer>
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer
> <
> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com?utm_medium=email&utm_source=footer
> >>>>.
> >      >      >      >>
> >      >      >      >>
> >      >      >      >>
> >      >      >      >> --
> >      >      >      >> Sergi.
> >      >      >      >>
> >      >      >      >> --
> >      >      >      >> 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
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>
> >      >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>
> >      >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%25252Bunsubscribe@googlegroups•com>>>
> >      >      >      >> <mailto:bitcoindev+unsubscribe@googlegroups•com
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>
> >      >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>
> >      >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%25252Bunsubscribe@googlegroups•com>>>>.
> >      >      >      >> To view this discussion on the web visit
> >      >      >      >>
> >      >      >
> >      >
> >
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com>
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com>>
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com>
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com>>>
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer>>
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com?utm_medium=email&utm_source=footer
> <
> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.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
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>
> >      >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>
> >      >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%25252Bunsubscribe@googlegroups•com>>>.
> >      >      >      > To view this discussion on the web visit
> >      >      >
> >      >
> >
> https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com
> <
> https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com>
> <
> https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com
> <
> https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com>>
> <
> https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com
> <
> https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com>
> <
> https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com
> <
> https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.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
> >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com>
> >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>>
> >      >      >     <mailto:bitcoindev%2Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com>
> >      >     <mailto:bitcoindev%252Bunsubscribe@googlegroups•com
> >     <mailto:bitcoindev%25252Bunsubscribe@googlegroups•com>>>.
> >      >      >     To view this discussion on the web visit
> >      >      >
> >      >
> >
> https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com
> <
> https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com>
> <
> https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com
> <
> https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com>>
> <
> https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com
> <
> https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com>
> <
> https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com
> <
> https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com
> >>>.
> >      >      >
> >      >
> >
>
>

-- 


[-- Attachment #2: Type: text/html, Size: 123884 bytes --]

 permalink raw reply	[|nested]
2024-04-20 19:14                           ` 'Ava Chow' via Bitcoin Development Mailing List
                                               ` (3 preceding siblings ...)
  2024-04-21 23:01                             ` Matt Corallo

  2024-04-23 22:15                             ` Anthony Towns
  
From: Ali Sherief @ 2024-04-22  4:28 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 1513 bytes --]

Very good and hopefully this makes the BIPs repository more active.

I just have one suggestion though. Considering the backlog of BIP 
modification PRs on github, It is quite inconvenient to hold a discussion 
about one when there aren't other participants, particularly for the pull 
requests that are several months old. Perhaps the new editors could also 
facilitate clearing the backlog by means of discussion on these old pull 
requests? I don't see anyone else participating in the evaluation process 
for them except maybe the BIP author(s), but it takes more than one person 
to hold a discussion.

-Ali

On Saturday, April 20, 2024 at 7:30:35 PM UTC Ava Chow wrote:

Since we're now past the deadline of April 19th, I'd like to inform 
everyone of what will happen on Monday. 

There has not been any actual objections to the nominees nor have there 
been any suggestions on choosing a subset of them since my last email. 
As such, there is rough consensus on adding Kanzure, Murch, Jonatack, 
Ruben, and Roasbeef as BIP editors, and they will be added on Monday 
April 22nd. 

Ava

-- 
2: Type: text/html, Size: 2035 bytes --]

 permalink raw reply	[|nested]
2024-04-20 19:14                           ` 'Ava Chow' via Bitcoin Development Mailing List
                                               ` (4 preceding siblings ...)
  2024-04-22  4:28                             ` Ali Sherief

  2024-04-25  6:42                               ` Antoine Riard
  
From: Anthony Towns @ 2024-04-23 22:15 UTC (permalink / raw)
  To: Ava Chow;  bitcoindev

On Sat, Apr 20, 2024 at 07:14:34PM +0000, 'Ava Chow' via Bitcoin Development Mailing List wrote:
> Since we're now past the deadline of April 19th, I'd like to inform
> everyone of what will happen on Monday.
>
> There has not been any actual objections to the nominees nor have there
> been any suggestions on choosing a subset of them since my last email.
> As such, there is rough consensus on adding Kanzure, Murch, Jonatack,
> Ruben, and Roasbeef as BIP editors, and they will be added on Monday
> April 22nd.

Thanks for pushing this forward, Ava!

One thing though:

> There has not been any actual objections to the nominees nor have there

When choosing personnel, asking for public objections is probably a
pretty bad approach. It's hurtful to the person being objected to, both
when the objections are accurate and when they aren't, and, especially
if the objections end up being ignored, it's harmful to the working
environment when the person who objected has to work with the person
they objected to in future.

Personally, I'd suggest focussing more on "are they demonstrably doing
useful work? yes, then they keep or increase their perms; no, then
decrease their perms". (Probably couldn't have done anything different
this time around, but maybe something to keep in mind for the future)

Along those lines, it might be worth having a review in six months or
so to see which of the editors and processes have been effective, and
which ones haven't, and see if there's anything worth changing further
to increase the wins and diminish the losses. Could be worth making
something like that a regular thing (once a year?); for the Debian
Technical Committee, we had somewhat similar problems with inactivity
and a lack of renewal, which (IMO) was fixed in a big part just by
having a policy of saying "okay, longest serving member gets booted,
remaining folks should invite someone new" once a year.

Anyway, it's easy to quibble about what the best process might be,
but actual results are more important, so thanks again Ava!

Cheers,
aj

-- 



 permalink raw reply	[|nested]
2024-04-23 22:15                             ` Anthony Towns

  
From: Antoine Riard @ 2024-04-25  6:42 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 5477 bytes --]

Hi AJ,

> When choosing personnel, asking for public objections is probably a
> pretty bad approach. It's hurtful to the person being objected to, both
> when the objections are accurate and when they aren't, and, especially
> if the objections end up being ignored, it's harmful to the working
> environment when the person who objected has to work with the person
> they objected to in future.
>
> Personally, I'd suggest focussing more on "are they demonstrably doing
> useful work? yes, then they keep or increase their perms; no, then
> decrease their perms". (Probably couldn't have done anything different
> this time around, but maybe something to keep in mind for the future)

> Along those lines, it might be worth having a review in six months or
> so to see which of the editors and processes have been effective, and
> which ones haven't, and see if there's anything worth changing further
> to increase the wins and diminish the losses. Could be worth making
> something like that a regular thing (once a year?); for the Debian
> Technical Committee, we had somewhat similar problems with inactivity
> and a lack of renewal, which (IMO) was fixed in a big part just by
> having a policy of saying "okay, longest serving member gets booted,
> remaining folks should invite someone new" once a year.

I'm respectfully dissenting here. Decade(s)-old IETF / BIP standards
are kinda open-source commons after-all, and this is very expected than
someone who is aspiring to get perms in their maintenance have to answer
objections from the non-permissioned people enjoying  usage of the
commons.

Yes, it can hurt to have to answers public objections on your person
when you're aspiring to open-source perms. I think that's part of the
process, if you wish a comfortable job you can always go to work at
$YOUR_LOCAL_BIG_TECH (tm). Additionally, one can wish to be sure
that the candidate have sufficient level of ethics / personal integrity.
Especially, to serve as a check-and-balance when one has to conduct
privileged actions in the execution of permissions.

W.r.t, I can only invite anyone to read the ACM Code of Ethics:
https://www.acm.org/code-of-ethics

(Far from perfect as ethics is a dynamic concept after-all, though can
provide guidelines if you're entitled with perms in this space, and you
don't know how to act in a given instance).

Apart of that, I think the idea of the longest serving members in a
set of maintainers / editors without substantial activity getting booted
every X and remaining folks can invite someone new can serve as a not
so bad rule of thumb.

To conclude, I'm rejoicing too on seeing concrete results in the nomination
of BIP editors, which doesn't forbid ulterior discussions on improving its
process.

Best,
Antoine

Le mercredi 24 avril 2024 à 16:36:38 UTC+1, Anthony Towns a écrit :

> On Sat, Apr 20, 2024 at 07:14:34PM +0000, 'Ava Chow' via Bitcoin 
> Development Mailing List wrote:
> > Since we're now past the deadline of April 19th, I'd like to inform
> > everyone of what will happen on Monday.
> >
> > There has not been any actual objections to the nominees nor have there
> > been any suggestions on choosing a subset of them since my last email.
> > As such, there is rough consensus on adding Kanzure, Murch, Jonatack,
> > Ruben, and Roasbeef as BIP editors, and they will be added on Monday
> > April 22nd.
>
> Thanks for pushing this forward, Ava!
>
> One thing though:
>
> > There has not been any actual objections to the nominees nor have there
>
> When choosing personnel, asking for public objections is probably a
> pretty bad approach. It's hurtful to the person being objected to, both
> when the objections are accurate and when they aren't, and, especially
> if the objections end up being ignored, it's harmful to the working
> environment when the person who objected has to work with the person
> they objected to in future.
>
> Personally, I'd suggest focussing more on "are they demonstrably doing
> useful work? yes, then they keep or increase their perms; no, then
> decrease their perms". (Probably couldn't have done anything different
> this time around, but maybe something to keep in mind for the future)
>
> Along those lines, it might be worth having a review in six months or
> so to see which of the editors and processes have been effective, and
> which ones haven't, and see if there's anything worth changing further
> to increase the wins and diminish the losses. Could be worth making
> something like that a regular thing (once a year?); for the Debian
> Technical Committee, we had somewhat similar problems with inactivity
> and a lack of renewal, which (IMO) was fixed in a big part just by
> having a policy of saying "okay, longest serving member gets booted,
> remaining folks should invite someone new" once a year.
>
> Anyway, it's easy to quibble about what the best process might be,
> but actual results are more important, so thanks again Ava!
>
> Cheers,
> aj
>
>

-- 
2: Type: text/html, Size: 6648 bytes --]

 permalink raw reply	[|nested]
2024-04-04  5:00                     ` Anthony Towns
  2024-04-04  9:09                       ` Niklas Goegge

  2024-09-18 18:25                         ` Murch
  
From: Murch @ 2024-05-13 18:33 UTC (permalink / raw)
  To: bitcoindev

Hey everyone,

I have spent some time going over comments about the BIP process in this 
thread and a few open pull requests in the BIPs repository. Thank you 
all for sharing your thoughts.

Below I summarized suggestions from those conversations. I started work 
on drafting a proposal to succeed BIP-2 and will consider all these 
suggestions with the intention of incorporating many of them.

If you are interested in collaborating on an updated Process BIP, I am 
open to one or two co-authors. I will also consider any further comments 
here on the mailing list, and look forward to the eventual review from 
any interested parties. I will start a first draft in my own BIPs 
repository after this email. Once the proposal is a bit more mature, I 
will open a pull request against the main BIPs repository.

These are my take-aways and open questions so far:

1. Process

What should the role of the editors be?

- The process should minimize judgment calls from editors
- Editors should focus on formal criteria and editorial qualities
- The audience rather than editors should evaluate technical soundness

What criteria distinguish Standards Track and Informational type BIPs?

- If deviation breaks compatibility, it should be "Standards Track"

Open questions:

- What changes to BIPs are acceptable at what stage of the process?
- Which changes need sign-off from the Champion?
- How can we make the process more robust in face of an absent Champion?

2. BIP Statuses

- Excessive count of statuses
- Meaning of statuses should be more clearly defined
- Criteria for status transitions should be clarified
- There have been multiple recommendations to reduce the statuses to:
DRAFT, PROPOSED, WITHDRAWN, with some disagreement on whether ACTIVE or 
FINAL would be useful in addition
- Get rid of the REJECTED status and drop the rule to move proposals to 
REJECTED due to time passing

Open questions:

- Is it a problem if a BIP is stuck in "DRAFT" or "PROPOSED" indefinitely?

3. Other format issues

- Comments and Comment Summary are largely being ignored, they do not 
seem to fulfill their intended purpose
- Backwards compatibility section is often forgotten
- Remove "Other Implementations" sections from documents
- Some suggested licenses may not be acceptable to license plain text

4. Scope of the Repository

- Only accept proposals that pass some bar of interest
- Require "a need for standardization", it must be relevant to multiple 
implementations or a broader audience
- Clarify purpose of repository; it is often misunderstand in how far 
BIPs "represent community consensus or recommendations"
- Focus on the proposals, explicitly stop guessing at acceptance and 
tracking of adoption

Open questions:

- Both a tightening and a broadening of the scope have been suggested:
Do BIPs need to be "related to the Bitcoin ecosystem", "related to 
technology that supports the bitcoin currency", or some other criterion?
- What does "keeping with the Bitcoin philosophy" mean?
- Where should adoption of BIPs be tracked? Should the BIPs repository 
offer an overview of BIP implementations separate from the author documents?

If you have input on open questions, or alternative suggestions to the 
summarized points, please let me know. As Tim before me, I would 
appreciate that you read BIP-2¹ carefully before replying.

¹ https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki

Best,
Murch

-- 



 permalink raw reply	[|nested]
2024-05-13 18:33                       ` [bitcoindev] Time for an update to BIP2? Murch

  2024-09-19  7:47                           ` Antoine Riard
  2024-12-10 22:37                           ` Murch
  
From: Murch @ 2024-09-18 18:25 UTC (permalink / raw)
  To: bitcoindev

Hey y’all,

Continuing the conversation about an update to the BIP process, I have 
clobbered together a draft proposal.

It aims to make determinations on all the topics that were covered by 
BIP 2, but tries to address many of the pain points brought up in the 
discussion earlier this year, the BIP Process Wishlist, and issues 
surfaced by sighting the open pull requests.

The main changes compared to BIP 2 are:

- Sunset the comments system
- Rework the workflow
- Use only four Status values (Preliminary, Ready, Active, and 
Abandoned) instead of nine, clarify the meaning of statuses
- Replace the "Standards Track" BIP type with the "Specification" BIP 
type, and update definitions for all BIP types
- Declare Process BIPs to be living documents
- Discourage adoption tracking in the BIPs repository
- Introduce Revision header and Change Log to record changes to BIPs 
after they have been recommended for adoption
- Update description of repository’s scope
- Reduce BIP Editor role to checking editorial and formal criteria, 
reassigning judgment calls to authors and audience

I’m open to reconsider most aspects of this proposal, provided 
convincing arguments and tenable alternatives. Please consider relevant 
rationale provided in the footnotes when suggesting changes.

Please especially take note of the description of the repository’s scope.

You can find the draft here:
https://github.com/murchandamus/bips/pull/2

I may also open a pull request to the main BIPs repository later this 
week assuming this draft is well-received.

Best,
Murch

-- 



 permalink raw reply	[|nested]
2024-09-18 18:25                         ` Murch

  2024-09-19 18:48                             ` Murch
  2024-12-10 22:37                           ` Murch
  
From: Antoine Riard @ 2024-09-19  7:47 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 6354 bytes --]

Hi Murch,

I had a full review on the updatses to BIP 2, and overall it sounds 
reasonable.

I have only 3 observations, to be addressed or not.

About the "What is the scope of the BIPs repository ?"

"The BIPs repository is focused on information and technologies that aim to 
support and expand the utility of the bitcoin
currency. Related topics that are of interest to the Bitcoin community may 
be acceptable. Proposals that are in direct
contradiction to this mission, e.g. by undermining fungibility, 
facilitating unrelated protocols, using Bitcoin for data
storage, or hobbling mining decentralization, may be considered 
out-of-scope."

There is no need to strictly define bitcoin mission in any fashion...Even 
if you go back to Satoshi's writings far more than
the currency aspect of bitcoin was designed for with the inclusion of a 
wide bitcoin script programming languages, rather
than just signature verification [0]. Even historically, if you go back to 
all the BIPs which have been discussed during
the block size wars (bip 103, bip 104, bip 105, etc) some of those BIPs in 
themselves are ways to articulate the technical
debate about scalability, and the impact or not on mining decentralization.

Same if you take fungibility, is BIP 431 good for fungibility ? No words 
inside this BIP about the impact to have policy
only semantics encoded in the nVersion field, forever marked in the 
transaction logs, and as such eventual protocol
semantics leaked by the bit setting as such affecting the fungibility of 
the coins. Should have all the BIPs in the future
to have a mandatory privacy section ? I don't know, it's a question worthy 
to be raised.

If I have a suggestion it would be to remove the "mission" term. It is 
implying that Bitcoin has some kind of eschatologic
mission, and sooner or latter, we'll be back to what did happen during the 
block size war, people doing whitepaper
fundamentalism and someone like CSW or a faction pretending to be "Satoshi 
Vision", while being to have been proven
a fraud so far in front of a public court of justice [1].

Bitcoin has a rich enough technical and cultural history in itself in case 
of community's lack of consensus.

"Off-list BIP-related correspondence should be sent (or CC'd) to the BIP 
editors."

I can see why you could reach out off-list to the BIP editors, e.g for 
security reasons if you wish some clarification
on an old BIP, and you don't have the level of experience to know who to 
reach out in the ecosystem to ask more.

Though apart of that, I would discourage off-list BIP-related 
correspondence with the BIP editors.

Is there any other good reason ? I cannot see any, if it's for complaining 
that BIP editors are not taking fast
enough administrative and editorial tasks, I think it should be done on 
some public communication channels.

About the "BIP Editors" workflow.

I think there should be explicitely a public process detailed to nominate 
new BIP editors in the presence of some
fragment of the community being unsatisfied with the current way of BIP 
editors work is done.

Let's learn from what did happen with the taproot activation years ago, 
when there was only one BIP editor, and
it was claimed by some he was too slow in assigning a BIP number to the 
activation logic [2].

Finally, I think it could be good to have a historical note pointing that 
the BIP process was originally authored
by Amir Taaki in September 2011, at a time he was working on a 
consensus-compatible re-implementation of a bitcoin
full node, which has become libbitcoin and which was not necessarily 
affected by all the sec issues of core over
the recent years.

Best,
Antoine
ots hash: a3efafd1b7a49306a7f7683ae142af088f9f31955a2eaa9bf1d8fd6fcae1c372

[0] https://bitcointalk.org/index.php?topic=195.msg1611#msg1611
[1] Indeed, there has been an appeal of the justice decision by CSW. If in 
appeal there is a need to have more
    technical experts in defense of the historical devs quoted / against 
CSW, I'm here.
[2] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018835.html
Le mercredi 18 septembre 2024 à 19:30:16 UTC+1, Murch a écrit :

> Hey y’all,
>
> Continuing the conversation about an update to the BIP process, I have 
> clobbered together a draft proposal.
>
> It aims to make determinations on all the topics that were covered by 
> BIP 2, but tries to address many of the pain points brought up in the 
> discussion earlier this year, the BIP Process Wishlist, and issues 
> surfaced by sighting the open pull requests.
>
> The main changes compared to BIP 2 are:
>
> - Sunset the comments system
> - Rework the workflow
> - Use only four Status values (Preliminary, Ready, Active, and 
> Abandoned) instead of nine, clarify the meaning of statuses
> - Replace the "Standards Track" BIP type with the "Specification" BIP 
> type, and update definitions for all BIP types
> - Declare Process BIPs to be living documents
> - Discourage adoption tracking in the BIPs repository
> - Introduce Revision header and Change Log to record changes to BIPs 
> after they have been recommended for adoption
> - Update description of repository’s scope
> - Reduce BIP Editor role to checking editorial and formal criteria, 
> reassigning judgment calls to authors and audience
>
> I’m open to reconsider most aspects of this proposal, provided 
> convincing arguments and tenable alternatives. Please consider relevant 
> rationale provided in the footnotes when suggesting changes.
>
> Please especially take note of the description of the repository’s scope.
>
> You can find the draft here:
> https://github.com/murchandamus/bips/pull/2
>
> I may also open a pull request to the main BIPs repository later this 
> week assuming this draft is well-received.
>
> Best,
> Murch
>

-- 
2: Type: text/html, Size: 7387 bytes --]

 permalink raw reply	[|nested]
2024-09-19  7:47                           ` Antoine Riard

  
From: Murch @ 2024-09-19 18:48 UTC (permalink / raw)
  To: bitcoindev

Hi Antoine,

On 9/19/24 03:47, Antoine Riard wrote:
> I had a full review on the updatses to BIP 2, and overall it sounds
> reasonable.
> 
> I have only 3 observations […] 

Yeah, I was anticipating that the description of the scope would elicit 
suggestions, but also that it will be amended before this process would 
be adopted. I’ll keep your concern regarding mentioning a mission in 
mind. I will also review the section that mentions off-list correspondence.

I considered including a process for nominating BIP Editors, but felt 
that it would bloat the scope of this proposal too much. I would prefer 
that it were covered by a separate BIP.

Thanks for your feedback,
Murch

-- 



 permalink raw reply	[|nested]
2024-09-18 18:25                         ` Murch
  2024-09-19  7:47                           ` Antoine Riard

  
From: Murch @ 2024-12-10 22:37 UTC (permalink / raw)
  To: bitcoindev


[-- Attachment #1.1: Type: text/plain, Size: 3309 bytes --]

Hey y’all,

After going through the review comments following my prior email from 
September and reworking several sections, I finished an initial draft of 
a proposal how to update the BIP Process.

The main changes compared to BIP2 are:

- Sunset the comments system
- Rework the workflow
- Use only four Status values (Draft, Complete, Deployed, and Closed) 
instead of nine, clarify the meaning of statuses
- Replace the "Standards Track" BIP type with the "Specification" BIP 
type, and update definitions for all BIP types
- Declare Process BIPs to be living documents
- Discourage adoption tracking in the BIPs repository
- Introduce Revision header and Changelog to record changes to BIPs 
after they have been recommended for adoption
- Update the description of repository’s scope
- Reduce BIP Editor role to checking editorial and formal criteria, 
reassigning judgment calls to authors and audience
- Introduce the Shepherd role as stand-in for Authors

Due to the length of the proposal, please find the full text in this 
pull request:

   https://github.com/bitcoin/bips/pull/1712

I am looking forward to your review and comments.

Best,
Murch


On 2024-09-18 14:25, Murch wrote:
> Hey y’all,
> 
> Continuing the conversation about an update to the BIP process, I have 
> clobbered together a draft proposal.
> 
> It aims to make determinations on all the topics that were covered by 
> BIP 2, but tries to address many of the pain points brought up in the 
> discussion earlier this year, the BIP Process Wishlist, and issues 
> surfaced by sighting the open pull requests.
> 
> The main changes compared to BIP 2 are:
> 
> - Sunset the comments system
> - Rework the workflow
> - Use only four Status values (Preliminary, Ready, Active, and 
> Abandoned) instead of nine, clarify the meaning of statuses
> - Replace the "Standards Track" BIP type with the "Specification" BIP 
> type, and update definitions for all BIP types
> - Declare Process BIPs to be living documents
> - Discourage adoption tracking in the BIPs repository
> - Introduce Revision header and Change Log to record changes to BIPs 
> after they have been recommended for adoption
> - Update description of repository’s scope
> - Reduce BIP Editor role to checking editorial and formal criteria, 
> reassigning judgment calls to authors and audience
> 
> I’m open to reconsider most aspects of this proposal, provided 
> convincing arguments and tenable alternatives. Please consider relevant 
> rationale provided in the footnotes when suggesting changes.
> 
> Please especially take note of the description of the repository’s scope.
> 
> You can find the draft here:
> https://github.com/murchandamus/bips/pull/2
> 
> I may also open a pull request to the main BIPs repository later this 
> week assuming this draft is well-received.
> 
> Best,
> Murch

-- 
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 visit https://groups.google.com/d/msgid/bitcoindev/147b5bf7-dab0-4180-8ce6-270431e2c5c4%40murch.one.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]