The Python Steering Council (PSC) has had an open issue based on discussions last year to improve our project’s security posture. We’re going to move forward with disabling GitHub commit privileges for inactive core team members. This has no impact on “core team” or “Python Steering Council (PSC) voting” status. It is merely a good security practice to not leave unused credentials laying around. Seth (Security Developer-in-Residence) lays out the rationale here.
How do we define “inactive”? Per the same discuss thread - quoting Hugo: ‘‘‘check yearly, and use the same “no commits in 2 years” to trigger inactive’’’ - our annual core team voter affirmation is the obvious good time to do so. After post-election PSC review, anyone deemed inactive by that automation (in the voters repo) who has an active commit bit will have their GitHub commit bit disabled for the cpython repo and be sent a separate email as a FYI about that with a pointer to instructions on how to have it re-activated.
The post-election newly elected PSC every year is in charge of making sure this gets done and validating that the results of any proposed commit-bit changes are sensible. They can confer with people if anything appears unexpected.
Anyone on the core team with an inactive Github commit-bit who wishes to have it re-enabled may do so by reaching out with a post in the private Inquisition category, or by filing an issue with the steering council.
For now, we will only consider the /python/cpython repo itself, meaning that we’ll only consider activity within this repo for “active” consideration, and only the commit bit on that repo will potentially be removed. Once we have some experience with this process, we can consider expanding this to other repos within the /python organization, and evaluating broader activity in other /python repos. Some of that may require additional automation, and some prioritization of the repos to consider.
Posted on behalf of the Python Steering Council, 2025 vintage
| Gregory P. Smith gpshead Steering Council Member November 24 |
| - |
The Python Steering Council (PSC) has had an open issue based on discussions last year to improve our project’s security posture. We’re going to move forward with disabling GitHub commit privileges for inactive core team members.
I voluntarily gave up commit privileges several years ago (I was no longer actively involved and the complexity of the commit system seemed to have increased significantly and was a bit overwhelming). There are probably other people in the same boat I was in. Might be a nice idea to ask people if they’d like to give up commit privileges before simply removing them. In a practical sense it might well make no difference (privileges still get revoked), but some people might have reasons why they haven’t committed anything recently, or at least appreciate being asked first.
Thanks, it’s good that we’re moving forward with this.
Technical detail: The voters script we’re planning to use considers only people who have committed to the repo, not those who merged changes. @malemburg opened an issue about this: https://github.com/python/voters/issues/112 . I’m not sure whether this would frequently make a difference as to who gets the commit bit removed, but I feel someone who merges PRs should not be considered “inactive”, even if they haven’t authored any commits themselves.
Unfortunately, that’s currently not the case with the script that’s being used to seed the list of voters for elections. The main reason appears to be that merges or other actions like reviews on Github don’t show up in the git logs and the script only talks to the git repo, rather than also reaching out to GIthub APIs.
Support for “co-authors” was recently added, but I, for example, normally don’t add myself to the commit messages as a “co-author”, when I’m mostly reviewing, commenting and doing the final merge.
All this is more of an annoying problem than anything else for the elections, though, since we do have an email process of asking committers to affirm whether they want to be considered active or not.
The same should happen with the git repo access, IMO, since scripts for these things aren’t perfect. And since we’re having yearly elections of the SC, the activity question could easily be combined with the question of keeping the git repo access.
I agree, reviewing and merging PRs should count towards being active, and we have this issue to track adding this to the script, which will help here.
I believe the definition of “inactive” in PEP 13 is intentionally vague, which says:
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.
(Going the other way, one could argue that the script also includes “trivial contributions” as active, but let’s not worry about that.)
The PEP also details “an incomplete list of areas where contributions may be considered for joining the core team”:
Working on community management and outreach
Providing support on the mailing lists and on IRC
Triaging tickets
Writing patches (code, docs, or tests)
Reviewing patches (code, docs, or tests)
Participating in design decisions
Providing expertise in a particular domain (security, i18n, etc.)
Managing the continuous integration infrastructure
Managing the servers (website, tracker, documentation, etc.)
Maintaining related projects (alternative interpreters, core infrastructure like packaging, etc.)
Creating visual designs
And a script will never cover many of these. (The script initially considered Barry as inactive, despite all those hours on the steering council!)
So the scripts aren’t perfect, but the idea is that it’s easy to be re-added to either the voting and commit-bit lists if and when you need it.
Is “easy” the same as “quick”, though? People are busy, and there’s only a few people who can add committers. PRs for ensurepip can often be time-sensitive if we align with the CPython release timetable, so having a pip maintainer who’s also a core dev with commit access is useful.
I’d be fine with having to say “yes, please keep my commit bit active” as part of the annual review of active core devs when the SC election happens, but less so if it’s something that could happen automatically, requiring me to request reinstatement when I discover (probably by trying to do a merge) that I’ve lost the commit bit.
|