Open hugovk opened 3 months ago
I think this policy should be added to PEP 13.
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.
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.
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.
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:
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:
inactive_reply = "stay active"
),inactive_reply = "make inactive"
),inactive_reply = "no response"
).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.
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.
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.
Sounds like we're in general agreement.
I suggest a process something along the lines of:
How does this sound? What are the next steps?
I like your plan.
(3) For those that don't reply
After how long?
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.
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:
(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.