Which list of core developers is authoritative?

(Łukasz Langa) #1

There are a few sets of people that we consider core developers:

We discussed this in some depth on python-committers in early August but in different context. Here I’m interested in something else.


We need a good definition of who a core developer is because we’re approaching a delicate time of discussing governance and eventually voting on a model. Since the question of governance and other current affairs affects those contributors the most who are currently active, it feels natural to me to call committers the people listed in the Python core team on GitHub.


In this context we can assume all inactive core developers as Emeritus committers. This acknowledges their past contributions but at the same time signals they are retired. For example, they would not vote on current affairs. Just like Professor Emeritus, they could resume their activity if interested. It’s as easy as getting the commit bit on GitHub and resuming contribution.

(I think it was @guido who first suggested the term.)

On Discourse

What about Discourse? I don’t want to exclude people who want to participate in the discussion but I feel like splitting hair between the rights to generally discuss and the right to vote is not productive.

So, what do you think? Do I make sense?

(Nathaniel J. Smith) #2

Makes sense to me. NumPy uses the “emeritus” phrasing too: https://docs.scipy.org/doc/numpy/dev/governance/people.html

For most purposes it really shouldn’t matter how exactly we draw the line, since outside contributors are welcome and valued anyway. Hopefully once this governance stuff is sorted out we can go back to using committer-only channels just for administrivia.

But we do need a formal distinction in a few places: committing, voting, giving new folks some hint about who they’re talking to. For the first, the github commit bit is… that. For governance, your point about active developers makes sense. And for giving people hints, if we switch to github for issues then the issue tracker hints will become github’s hints, which are based on the commit bit. So… we might as well keep things simple and use that as the one-and-only-one category everywhere.

Eventually we’ll probably need some mechanism to gently nudge inactive contributors into the emeritus category. (Or we could keep switching platforms every few years, I guess that would work too :stuck_out_tongue_winking_eye:) But we can worry about that later.

(Brett Cannon) #3

The combination of the developer log and b.p.o is probably the closest we have to a list of at least emeritus members.

As for active, a measurement could be if you committed in the last release (and in git terms, that’s just merging a PR and not necessarily authoring a PR). If people wanted a looser definition, time-based measurement then the last 3 years seems reasonable to me as that means you could commit on the first day of the last release and on the last day of the in-dev release and still be considered active. But if you miss two releases then you’re getting disconnected from the momentum of stuff being deprecated or removed and any other such plan as we typically don’t plan anythinore than 2 releases out.

But at minimum if you never bothered to get added to GitHub then I think you’re emeritus.

(Ethan Furman) #4

While the commit bit on GitHub is definitely the easiest metric, and adding a “PRs commited” is not difficult to add, I think those are too narrow – somebody who is present and participating on the mailing lists / forums, or just doing triage, should still be considered an active core dev (assuming they were at one time a core dev).

Perhaps we need a separate form that core devs can validate with once a year to say, “Yeah, I’m still active!” when they are not directly participating in merging PRs.

(Barry Warsaw) #5

We could do that with a commit to a repo :slight_smile:

(Jack Diederich) #6

Changing the rules now and in a way that people couldn’t “top up” their status does not seem sporting (on the mailing list Stefan Krah used the word gerrymandering). Especially since we had this discussion recently and the result was close to comitter-for-life absent any Anastasia scenario.

(Brett Cannon) #7

I don’t know if anyone was really planning to change anything now. I know I was participating because it’s a topic at the forefront of everyone’s mind and so we are all thinking about it at least for the long-term, but I don’t expect this to impact voting based on what we all reached consensus on for the draft voting PEP Raymond said he was going to write up (which was “commit rights on GitHub”).

(Łukasz Langa) #8

Exactly right, @brettcannon. Everybody at the core sprint felt like if a dormant core developer did not bother with setting up GitHub access, it means they are no longer invested in contributing (since they can’t push and they can’t merge pull requests by others). It’s been over 20 months since the move to GitHub.

People have the right to walk away. They have the right to resume their activity at will, too. If any of the dormant core developers asks to be added on GitHub, they will. Limiting the list of core developers to active ones for voting purposes simply allows us to calculate totals realistically.

FWIW I reached out to Raymond and we should have this PEP publicized by end of this week.

(Guido van Rossum) #9

Note that it would be totally fine if some independent group tried to reach all dormant core devs to encourage them to register.

(Marc-André Lemburg) #10

I think you have to differentiate a bit between being a Core Developer and being registered for voting.

Being a Core Developer, as discussed, should be the same as a PSF Fellow - once you reach that status, you can carry that title for live.

If a Core Developer wants to vote, they should be able to say so and then be eligible to vote.

As for the list of all Core Developers, I believe we should do some research into this and combine the lists we mentioned on the committers mailing list. Again, with an option for anyone who did not end up on the list to request addition.

(Victor Stinner) #11

Today I checked if Chris Angelico is a core developer, I found him at https://devguide.python.org/developers/

Chris Angelico was given push privileges on December 1, 2014 by GFB, as a new PEP editor.

I was confused since this list of usually for core developers, not “PEP editors”. I checked in the bug tracker, no, he isn’t a core developer.

On the opposite, a few weeks ago, I checked how many core developers are in the PSF Board Directors, and I counted 1:

But I was wrong, I missed Thomas Wouters. In fact, I wasn’t sure about Thomas Wouters, I checked https://devguide.python.org/developers/ which is my reference and I cannot find him there. It’s confusing since Thomas Wouters was at the Language Summit… Who should I trust? :frowning: (I’m now sure that Thomas Wouters is a core developer, but I’m talking about trusting list of core developers.)

I’m just sharing my experience to show how the current status is confusing :slight_smile:

(Thomas Wouters) #12

FYI, I’m not mentioned on https://devguide.python.org/developers/ because my commit bit predates the start of that list :slight_smile: You don’t find Guido or Barry or Tim on there either :stuck_out_tongue_winking_eye:

(Victor Stinner) #13

I proposed a PR to complete the list: https://github.com/python/devguide/pull/434

(Brett Cannon) #14

As pointed out on that PR, it still isn’t a complete list. I think generating a table/list of core developers with relevant details that is accurate is going to require going through the current list, bugs.python.org, and GitHub and no quick solution is going to work, unfortunately.

(Carol Willing) #15

Who would have the list of subscribers to python-committers? That seems like a good list to combine with the others. Manually deduping or dumping all into pandas may be a reasonable approach.

(Brett Cannon) #16


Unfortunately it’s not that simple. For instance, the Jython folks are on python-committers because of their sharing of hg.python.org back in the day. Same goes for some folks having multiple addresses subscribed for various reasons (e.g. me screwing up by not sending from my python.org email address).