[RFC-0055] Retire inactive nixpkgs committers

[tilpner]

Many people were given push access to the nixpkgs repository, which is kept even if these committers become inactive. This RFC proposes moving these contributors to a new team without push access.

Rendered

[Mic92]

I think they should be informed some time before (maybe two months?), that their push access will be removed unless they add a commit. There might be some extreme circumstances like an illness that knock out someone for a year. I think a year is a good threshold.

[grahamc]

An alternative to this alternative is make it very easy to get commit bit back. I don't think there should be any permanence to the commit bit removal. If there is nothing difficult/annoying about getting commit bit back, is there any need to let them know in order to keep it?

[timokau]

But if it is very easy to get the commit bit back, doesn't that kind of negate the security motivation? At least if we assume the accounts/secrets might get compromised.

[grahamc]

Good question, I don't know.

[tilpner]

@Mic92 An email (only required contact information in maintainer-list) two months before the end of the year sounds good.

@grahamc I definitely want a notification, it should not feel unreasonable or be unexpected, but I'm not sure the requirement for re-activation should be subject of this RFC.

If a limit is needed, something with more friction than just dropping a line on IRC, but less than the current initial limit (?) of 50 recent PRs with non-trivial contributions should be acceptable, perhaps a tenth of that.

[worldofpeace]

How about unresponsive maintainers and committer issues?

Hello, x committer has been unresponsive for x days.
They maintain:

List of things
- 
-

If anyone knows how to get in contact with them please let us know.

[Detailed section about the process with moving commit access]

Another issue is what do we do with packages that say they're maintained by them?
We need to be able to move them out of meta.maintainers as well.

[tilpner]

@worldofpeace It's possible to keep maintaining their things without commit access, so I argue that removing them as a maintainer should not be part of this RFC.

Of course that's unlikely to happen, considering they haven't contributed in the past year, but expanding this RFC to affect all maintainers (as opposed to just the committers) and removing maintainers from packages (and potentially removing packages if they become unmaintained) feels very far out of scope for now.

[7c6f434c]

Would we want to take into account any other kinds of projet participation? Write-access-require project participation (Like nontrivial labelling of issues)? Commits to other NixOS organisation repos?

(I recognise that a possible answer is «would be nice, but requires too much fighting GitHub»)

[grahamc]

want to take into account any other kinds of projet participation?

At this time, I'm not sure it is necessary. The list of people to have commit bit revoked is so low. Maybe that list could be shared, to confirm each person is actually inactive?

[tilpner]

@7c6f434c I don't know how commit access to non-nixpkgs repositories is managed. I've so far assumed the team nixpkgs-committers is only used for nixpkgs.

If possible, labelling of issues could be solved with another group, which only grants labelling permissions. That would also be useful for granting labelling rights to people without giving them commit access, but such a team is out-of-scope for this RFC.

[7c6f434c]

Maybe a better version of my question would be: if the committer responds and says they are kind-of-half-active around Nixpkgs, do we cancel the revocation?

[alyssais]

It's worth noting when discussing public announcements of impending removal, etc., that the list of committers isn't currently public. I'm not saying it shouldn't be, but if it's going to be made semi-public through automated(?) announcements anyway, we might as well take the opportunity to properly make it public.

[worldofpeace]

True @alyssais, and I think it's unfair to people who aren't members of the org to figure out who can commit unless they directly interact with them. This is a source of confusion because they can't even tell the team does exist (I can think back on occassion where people are like "what is nixpkgs-committers?).
I'd say if you're a committer your public membership is already prevalent, so default secrecy doesn't make sense to me.

I do believe if people desire privacy in that regard they can make their status non-public?

[tilpner]

@7c6f434c I don't have a good answer to that question, but I would expect the specifics to matter a lot. A vague "I'm still active-ish" should be treated differently to "I didn't have time recently, but I plan to work on X during the next n months". I'm not sure it's necessary (or sensible) to write up rules for this right now. I don't expect it to occur often, and trust whoever ends up being responsible for this to be reasonable.

@alyssais The RFC currently does not propose or require public announcements. While I would welcome nixpkgs-committers becoming public, that is unrelated and I don't want that to block this RFC.

[Zimmi48]

@worldofpeace The nixpkgs-committers team could be made public to other organization members such as the members of nixpkgs-maintainers. However (and quite unfortunately), GitHub does not support making a team public to non-members of the organization. So if this is what is proposed, then it will require another means, such as maintaining a public list in a markdown file somewhere.

[7c6f434c]

@tilpner Yes, with advance notification and explicit lack of attempt to automate removal the plan sounds reasonable.

[Mic92]

I would like propose myself as a shepherd for this RFC.

[edolstra]

I nominate myself as a shepherd as well.

[shlevy]

Any others interested in shepherding? We need one or two more.

[worldofpeace]

I'd like to @shlevy.

There's two main things that I like to see be a part of this RFC for me to be comfortable with it going through.

1. The RFC should propose and require public announcements.
2. A defined way for an emeritus committer to regain commit access.

^ we already have issues and no process for people to even gain access, how does one regain it?

Though I feel these concerns are already shared from the appearances of this discussion, so perhaps me being a shepherd won't contribute much more to the conversation. From a social aspect I think I'm uniquely qualified on certain aspects that could contribute to the reviewing process.

[domenkozar]

We need one more nominations, as there can be only 50% from SC.

[Mic92]

Would you like to shepherd this one as well? @alyssais

[domenkozar]

If we follow the procotol, all three shepherds are now part of RFC steering committee. So we'd need to swap one.

[domenkozar]

I'd like to nominate @grahamc and @zimbatm.

[worldofpeace]

@worldofpeace Can you state your objections in this RFC issue itself? Maybe we can get those solved without requiring a meeting in person.

Eventually yes, but I'm full on travel stuff Mar 6-21.

[worldofpeace]

I'm going to try to find some time hopefully next week to look everything over and we can probably have motion for FCP.

[Mic92]

To address the last two issues:

1. How we doing the removal? (Create an issue + email to notify people)
2. Who is doing the removal?

I would volunteer to run the script, create the issue notifying people over github + email and than notifying the organization administrator to remove inactive accounts.
If somebody also wants to join in the process, please let me know.

Could you please add in the RFC that we handle the notifications over an github issue + email notifications? Thanks!

[Mic92]

Thanks. As far as I can see all the points that we discussed in the RFC meeting were addressed. That means we can proceed with the FCP phase.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/final-comment-period-for-rfc-55-retire-inactive-nixpkgs-member/7239/1

[Mic92]

Unless there are major objections we are merging this RFC on the 24th of May.

[Mic92]

Only two days left until this is merged.

[Mic92]

This is the first batch: NixOS/nixpkgs#88867

[worldofpeace]

It's been brought to my attention by @jtojnar that the team for the honor designation to past contributors has a masculine meaning.

I'll quote our discussion on IRC:

@jtojnar
Mic92: I only took half semester of latin before it was cancelled but committer emeritus does not sound good to me
since emeritus is masculinum singular

@Mic92
Jan Tojnar: I just followed rfc55. Feel free to open a RFC against it.

Taneb
Jan Tojnar: it's accpeted usage as an English adjective, which doesn't change form with gender

@worldofpeace
wikipedia's header for the word "Emeritus (/əˈmɛrɪtəs/; female: Emerita"
the notes " feminine emerita or emeritus; plural emeriti (masc.) or emeritae (fem.); abbreviation emer."

@jtojnar
Taneb I have definitely seen emerita in English being used for female professors

see also https://wmich.edu/writing/rules/alumni

@worldofpeace
Jan Tojnar: reading that makes me not really like the word/s
especially the usage note that like alumni is never wrong for groups that do include women, even though it's a plural male form?
plain weird to me, but I'm not here with a better name suggestion just yet. and it's pretty easy to change team names

@lheckemann
How about "former committers"?

@jtojnar
grammatical genders are weird, I like to think about masculinum as a gender category that also among other things refers to male people
because otherwise I get weird clashes between grammatical genders of different languages

@worldofpeace
hehe, they really are.
sphalerite I mean, former committers would be exactly that. I think this word was chosen because it was like an honor position
like we could say "retired" or really inactive would be exact, it's just it doesn't have that honor indication
So options would then be - Nixpkgs Former Committers Team - Nixpkgs Retired Committers Team - Nixpkgs Inactive Committers Team

@jtojnar also mentioned the existence of Latinx which I responded with

Jan Tojnar: gender-neutral in spanish is so hard. "To capture the complexity of the various terms used the term Latin* (pronounced Latin) was introduced in 2020" I see how that is related to
sphalerite comment
I personally use latinx or X etc. for a lot things

From the logs I'm interesting in creating a slight amendment, and also to the benefit of being a more accessible english word.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-deserves-great-governance/26096/3