Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove commit bit from inactive core devs #539

Open
hugovk opened this issue May 31, 2024 · 19 comments
Open

Remove commit bit from inactive core devs #539

hugovk opened this issue May 31, 2024 · 19 comments

Comments

@hugovk
Copy link
Member

hugovk commented May 31, 2024

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
Copy link
Member

I think this policy should be added to PEP 13.

@encukou
Copy link
Member

encukou commented May 31, 2024

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
Copy link
Member

zware commented May 31, 2024

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
Copy link
Member

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
Copy link
Member Author

hugovk commented May 31, 2024

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:

  • voting for the SC
  • nominating the SC
  • the commit bit

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:

  • Some replied to say they wanted to remain active (inactive_reply = "stay active"),
  • some replied to say they wanted to be marked inactive (inactive_reply = "make inactive"),
  • some didn't reply (inactive_reply = "no response").

@ambv
Copy link

ambv commented Jun 6, 2024

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
Copy link
Member

vstinner commented Jun 6, 2024

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
Copy link
Member Author

hugovk commented Jun 6, 2024

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
Copy link
Member Author

hugovk commented Jul 14, 2024

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
Copy link
Member

I like your plan.

(3) For those that don't reply

After how long?

@hugovk
Copy link
Member Author

hugovk commented Jul 14, 2024

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.

@hugovk
Copy link
Member Author

hugovk commented Sep 12, 2024

I see broad agreement here. I've proposed to the SC that we do this beginning with the upcoming 2025 election, as it's just a month or two away.

python/steering-council#254

@encukou
Copy link
Member

encukou commented Sep 12, 2024

Wording-wise: I suggest “inactive” instead of the gendered “emeritus”.

@zware
Copy link
Member

zware commented Sep 12, 2024

I was unaware that "emeritus" is gendered :(. "Inactive" has a different connotation, though; the former says "honored retiree" while the latter says "they don't do anything anymore". Both may be true, but I do think it's important to say the right part "out loud" in the name of the position. I don't have a better suggestion to hand, but agree that an ungendered term would be preferable.

@ethanfurman
Copy link
Member

Looks like "emeriti" (all male or mixed male-female) is as close to gender-neutral as we are going to get. I suggest we use that word.

@picnixz
Copy link

picnixz commented Sep 14, 2024

Not sure if it could be an alternative, but how about "titular"?

@erlend-aasland
Copy link

erlend-aasland commented Sep 19, 2024

I believe both "professor" and "emeritus" have been incorporated from latin into the english language as gender neutral words. I've never heard "profestrix emerita" nor "profestrix"; it would be interesting to know if they are used.

@hugovk
Copy link
Member Author

hugovk commented Oct 17, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants