Re: [bitcoindev] New BIP Editors: 1 Year Later

[Anthony Towns <aj@erisian.com.au>]

On Tue, Jul 15, 2025 at 01:01:55AM +0000, 'Ava Chow' via Bitcoin Development Mailing List wrote:
> In the 15 months since adding the new BIP Editors, the BIP Editors have:
> - Left 1272 comments
> - Merged 261 PRs
> - Closed 122 PRs
> - Assigned 22 BIP numbers
>
> This improvement is very much welcome and the BIPs process no longer
> feels stuck.

I had a look at this via commits to the bips repo a while ago, and came up
with these numers:

  - 2021: ~111 merges
  - 2022: ~58 merges
  - 2023: ~49 merges
  - 2024(a): ~2 merges (jan-mar, prior to the new editors)
  - 2024(b): ~162 merges (apr-dec, after the new editors were added)
  - 2025: ~98 commits (to date)

To me, that seems to back up the impression that things were getting
increasingly stuck, and that that's no longer the case.

> That being said, there is significant variance in the activity of the
> Editors, with only a couple Editors accounting for the vast majority of
> the aforementioned activity.

This is also reflected in the commit history. For the 2025 commits,
I see 38 merges by Murch, and 60 by Jon Atack, leaving 0 by the other
editors. (Going by "git log --merges --first-parent")

For 2024(b), I see 83 by Jon Atack, 56 by Murch, 4 by laolu, 1 by Luke Dashjr,
1 by Bryan Bishop and none by Ruben Somsen. Those latter 6 merges were:

  - laolu:
    * merged https://github.com/bitcoin/bips/pull/1411 [2024-05-08]
    * merged https://github.com/bitcoin/bips/pull/733 [2024-04-23]
    * merged https://github.com/bitcoin/bips/pull/1530 [2024-04-22]
    * merged https://github.com/bitcoin/bips/pull/1564 [2024-04-22]

  - luke:
    * merged https://github.com/bitcoin/bips/pull/1598 [2024-05-31]
    * also had a direct commit (not a PR) to fix the README after BIP
      47 was marked final via PR#1068 [2024-04-24]

  - bryan:
    * merged https://github.com/bitcoin/bips/pull/596 [2024-04-24]

Adding 5 new editors and having essentially a 60% attrition rate a month
or two later doesn't actually seem that bad to me; but I don't think
it's a good idea to stop there and leave people who aren't particularly
active filling the roles indefinitely.

My guess is that it would be closer to ideal to have the load distributed
across perhaps three or four active editors at any one time rather than
just two, and that over the course of twelve months the three or four
most active editors should change as individuals take time for vacation,
or find themselves having to more intensively focus on work/family/etc
for a period.

It can be pretty hard to voluntarily step down from volunteer positions
(and when that's the primary means for changeover, it tends to lead
to the positions being permanently filled by people who'll simply
never voluntarily step down), so it might be worth considering more
objective/automatic ways to move inactive members.

One straightforward approach is to have term limits, eg "we want six
editors; we'll add two editors each year, and have a three year term
limit. if you were an editor as recently as year X, you're not eligible
to be appointed as an editor again until year X+3". To get the transition
started, you could have Luke (as the longest serving editor, at ~9 years)
and Ruben (as the editor with least merges) have their terms end this
year, Laolu and Bryan in 2026, and Murch and Jon in 2027, eg.

In some circumstances, I think it makes sense to retain past/inactive
contributors in an advisory/oversight/backup role -- so that if something
goes badly wrong, there's not very much friction for those people with
past experience to step up and get things back on track. I'm not sure
how much that applies here, and the github org admins also serve in that
role to some extent, but maybe it's a helpful option to have in mind.
Advisors aren't much of a replacement for active co-contributors, however.

Figuring out how to add two editors a year might seem hard. One way to
make that easier is having some sort of "apprenticeship" role -- one that
demonstrates some of the skills required of an editor, but that doesn't
require extra permissions. Perhaps it could work to let people volunteer
to do early triage/review of bips repo PRs during the first few days after
they're opened, so that authors get a quick response, without editors
having to be constantly on-call, and track their contributions on a wiki
or similar. Alternatively inviting the people who've proposed/reviewed
bips heavily (and helpfully) over the past year or two might work okay.

Cheers,
aj

-- 
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/aJrSEOImKAa9NEB9%40erisian.com.au.