Remove commit bit from inactive core devs as part of SC elections

[hugovk]

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

Indeed, PEP 13 already has provisions for this:

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.

We further discussed this in python/core-workflow#539, and I'd like to suggest we start doing this as part of the annual election process.

I propose a process along the lines of:

1. As part of compiling the voter roll for the annual SC election, find inactive committers.
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 after two weeks, or those that reply saying they wish to become Emeritus, add them to the Emeritus group and remove their commit bit.
4. Repeat annually after each SC election voter roll has been compiled.

When contacting inactive people, it's important to let them know they've not done anything wrong, it can be re-instated if they become active again, and thank them for their contribution (see python/core-workflow#539 (comment)).

Please could the Steering Council consider this, starting with the upcoming 2025 term election?

[sobolevn]

any non-trivial

I think that this needs a bit of more context.
Like: is making a commit a trivial contribution? What about a review / design discussion?

[hugovk]

Like: is making a commit a trivial contribution?

You can see the scripts used for the elections at 🔒 https://github.com/python/voters. It looks for any commit to CPython, which I think is okay for practicality reasons, to avoid having someone sit down and review commits for undefined "triviality".

What about a review / design discussion?

I believe this is captured by the next step, asking pending inactive people if they wish to remain active. It also covers those who have committed to non-CPython https://github.com/python repos, and indeed any of the valuable non-code core team contributions.

[emilyemorehouse]

Thanks for raising this! Overall, the SC feels that this is a good addition to the process but will likely defer this decision to the next SC.

In the meantime, we'd like to suggest opening a discussion on DPO to gather community feedback on whether we should split out a Core Developer's status to support having voting rights but not commit rights. We can see a situation where someone would want to opt-in to being "active" in order to participate in votes, but don't actually need the commit bit.

[hugovk]

Thanks, I've opened a discussion at https://discuss.python.org/t/split-out-voting-rights-from-commit-rights-for-inactive-core-members/68208.

[gpshead]

SC discussion status: internal discussion ongoing - no updates to share yet.

[vstinner]

What can be done to move on on this topic?

[gpshead]

We're going to do it as an after election thing - I just posted the details https://discuss.python.org/t/regularly-disabling-unused-commit-access-to-the-cpython-repo/105010

We can leave this issue open until after the first sweep has been done by the next SC.