search

python / core-workflow

Issue tracker for CPython's workflow
https://mail.python.org/mailman/listinfo/core-workflow
Apache License 2.0
93 stars 60 forks source link

Remove commit bit from inactive core devs #539

Open hugovk opened 3 months ago

hugovk commented 3 months ago

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 commented 3 months ago

I think this policy should be added to PEP 13.

encukou commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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:

ambv commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 1 month ago

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 commented 1 month ago

I like your plan.

(3) For those that don't reply

After how long?

hugovk commented 1 month ago

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.