PEP 13: Python Language Governance
PEP 13 names two privileges that core team members can temporarily lose when inactive: voting or nominating for the steering council, and commit access.
There’s no time limit on core team membership. However, in order to provide the general public with a reasonable idea of how many people maintain Python, core team members who have stopped contributing are encouraged to declare themselves as “inactive”. Those who haven’t made any non-trivial contribution in two years may be asked to move themselves to this category, and moved there if they don’t respond. To record and honor their contributions, inactive team members will continue to be listed alongside active core team members; and, if they later resume contributing, they can switch back to active status at will. While someone is in inactive status, though, they lose their active privileges like voting or nominating for the steering council, and commit access.
Voting
We handle the voting part:
As part of compiling the voter roll for annual SC elections, we start with a list of people who have committed to the CPython repo in the previous two years, and consider these active.
Anyone whose status is pending a change to “inactive” is emailed and asked if they wish to remain marked as “active”. This gives them the chance to still vote even if they’ve not committed recently, and also covers the wide range of important activities that core members perform beyond CPython commits. (See 
python/voters#81 (comment) for an example email.)
Committing
But we don’t currently handle the commit access part.
During the Language Summit 2024 we discussed “Strengthening Python’s Security Model”, including removing the commit bit for inactive core members.
We further discussed this in python/core-workflow#539 and there is broad agreement it would be sensible to remove commit access for inactive members. We could list them as Emeritus committers, and they can easily regain access when they wish to start contributing again.
Practically, it would make sense to perform this annually as part of compiling the voter roll (potentially with an initial run if there’s a long time until the next election).
I proposed this to the SC in python/steering-council#254, who suggested:
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.
Feedback please!
Should we split out a core member’s status to support voting rights but not commit rights?
Would core members, who aren’t actively committing, like the opportunity to vote/nominate in SC elections, but temporarily give up commit rights until they need them again?
Some numbers
For context, running the voters repo scripts, gives 90/198 core members who are active; those who have committed to the CPython repo in the last two years, plus those who’ve declared that they wish to be marked active. Of those, 84 have committed in the past two years.
There’s 128 members in the GitHub python-core team who have commit access.
So perhaps there’s up to ~40 (128-90) people with the commit bit who don’t need it.
So I guess I need to employ some more imagination for why it’s important to keep the title but not the occasional email.
More seriously, I see it as an extension of what is already done checking for active voters: email new inactive people to check if they wish to remain active for voting. At the same time, we would do a similar thing for active committers: email new inactive people to check if they wish to remain active for committing.