Remove commit bit from inactive core devs

[hugovk]

The short story

For security, remove the commit bit from inactive core devs.

Long version

During the Language Summit 2024 one thing we discussed regarding "Strengthening Python's Security Model" was removing the commit bit for inactive core devs.

We have a policy for GitHub organisation owners and repository administrators:

Inactive or unreachable members may be removed with or without notice. Members who no longer necessitate this level of access will be removed with notice.

(During the summit, I said this was also the policy for core devs, but it's currently only for org owners and repo admins.)

I suggest we also apply this to core devs.

We should make it easy to re-add the commit bit for those become active again and would like it re-enabled.

We can use 🔒 https://github.com/python/voters as a starting point for this, which has a list of active/inactive core devs, updated annually for the purposes of Steering Council elections.

[Mariatta]

I think this policy should be added to PEP 13.

[encukou]

The time machine still works! PEP 13 now already says:

Those who haven’t made any non-trivial contribution in two years may be asked to move themselves to [the “inactive”] category, and moved there if they don’t respond. [...] While someone is in inactive status, though, they lose their active privileges like voting or nominating for the steering council, and commit access.

[zware]

Should we add something like a "python-core-emeritus" group to move such folks to rather than outright removing them? See also this old discussion which basically suggested the same, but wasn't acted upon at the time.

[Mariatta]

The wording on PEP 13: "asked to move themselves to the inactive.." is not the same as "your access will be removed if ..." which what I think this ticket suggests.

[hugovk]

I think it's similar: the "unreachable" in "Inactive or unreachable members may be removed with or without notice" suggests contacting them first.

In any case, I think it's fine to contact them first as a courtesy.

PEP 13 also makes it clear the same active/inactive status applies to "active privileges" like:

• voting for the SC
• nominating the SC
• the commit bit

Which means we can use the inactive list from voters file directly for this as well; those who hadn't made recent commits were contacted during the last election cycle:

• Some replied to say they wanted to remain active (inactive_reply = "stay active"),
• some replied to say they wanted to be marked inactive (inactive_reply = "make inactive"),
• some didn't reply (inactive_reply = "no response").

[ambv]

PyPy has a similar policy, I got kicked out (more than once?) for being inactive for 12 months. Subjectively, it feels a little harsh without a notice, so I agree reaching out with a casual "hey, we noticed you're inactive so we moved you to this group. it's not a big deal, let us know when you restart your activity and we will reinstate you. thanks for your contributions so far!" will smoothen out the blow to ego.

[vstinner]

It would be useful to know the effective number of active core devs to take better decisions. It's not the same if we have 30 or 150 "active" core devs. For example, should we mentor more people and/or promote more active contributors?

Obviously, in terms of security, it's also good to reduce the attack surface. Inactive core devs are more likely to be vulnerable if they don't follow latest Python security best practice.

The Emeritus group is a good idea.

[hugovk]

It would be useful to know the effective number of active core devs to take better decisions. It's not the same if we have 30 or 150 "active" core devs. For example, should we mentor more people and/or promote more active contributors?

Running the voters repo scripts, it's 90/193 active. This is people who have committed to the CPython repo in the last two years, plus those who've declared that they wish to be marked active.

[hugovk]

Sounds like we're in general agreement.

I suggest a process something along the lines of:

1. Run the voters repo scripts to find inactive committers (or use the list from the last SC election from 🔒 python/voters).
2. Contact them and invite them to become Emeritus committers and remove the commit bit for security. Let them know they can have it re-enabled in the future if they wish to become active.
3. For those that don't reply, or those that reply saying they wish to become Emeritus, add them to this group and remove their commit bit.
4. Repeat annually after each SC election voter roll has been compiled.

How does this sound? What are the next steps?

[vstinner]

I like your plan.

(3) For those that don't reply

After how long?

[hugovk]

No strong opinion, perhaps two weeks? That's how long it is between creating an annual voter role (for example, 🔒 https://github.com/python/voters/commit/35e0289969cb8f00fbe7d8e1bc12da37461b3ab8) and the final update after responses (🔒 https://github.com/python/voters/commit/3fe91d4bfedf3f0d5f1435c4db3cd066e168e6a9).

We could do longer for the initial run, but then again we can always re-add people later.

[hugovk]

I see broad agreement here. I've proposed to the SC that we do this beginning with the upcoming 2025 election, as it's just a month or two away.

python/steering-council#254

[encukou]

Wording-wise: I suggest “inactive” instead of the gendered “emeritus”.

[zware]

I was unaware that "emeritus" is gendered :(. "Inactive" has a different connotation, though; the former says "honored retiree" while the latter says "they don't do anything anymore". Both may be true, but I do think it's important to say the right part "out loud" in the name of the position. I don't have a better suggestion to hand, but agree that an ungendered term would be preferable.