Repository navigation
Retire collaborators who have been inactive for a year? #18879
Description
Following the TSC decision to retire some inactive collaborators here. I think we should have a clearer process for removing collaborators who have been inactive for a period of time.
I'm not really sure what prior work is going on - but I'm going to throw around a proposal to iterate on:
Once a month:
- look for people who have been inactive* for a year, email them asking if they're still interested in being a collaborator and participating.
- If they say "yes", do not remove them.
- If they say "no", move them to "Collaborator Emeritus" status and remove them from the nodejs/collaborators team.
- If they do not answer, do not remove them, if they do not answer 2 months in a row - that is like saying "no".
- If they ever become active again - they may self nominate for collaborator. Adding them back is at the discretion of the TSC (like regular nominations) but likely won't be too problematic.
Note that the main concern in keeping people collaborators is that they have access to run CI jobs, land PRs, read moderation discussions ETC - so this is more about security than anything else. It's also about creating a smaller up-to-date approachable group of people to ping about issues. My main concern with this proposal is excluding people.
- comments, PRs, other org repos, reviews and active WG membership count as participation for this proposal's purpose.
Pinging @nodejs/tsc and @nodejs/moderation to get the discussion going.
Activity
joyeecheung commentedon Feb 20, 2018
SGTM. I remember there is another issue in the build repo talking about revoking CI access from people who have not been active for three months?
bnoordhuis commentedon Feb 20, 2018
Yes, that's nodejs/build#744.
mcollina commentedon Feb 20, 2018
maclover7 commentedon Feb 20, 2018
+1 as long as criteria used will be very similar to that for being added in the first place -- comments in issues, helping out with the different WGs, etc.
bnoordhuis commentedon Feb 20, 2018
I wouldn't say that's the right way to look at it. Inactive CI accounts are security breaches in waiting. If you're not using your account, it's better to disable it.
Trott commentedon Feb 20, 2018
My personal plan was to do this once a year. Basically, find all Collaborators with no commits since the release of the oldest supported release line of Node.js. (So, last year, it was since Node.js 4.0. Later this year, I was going to do it for people who haven't contributed since Node.js 6.0.) In practice, that tends to mean no commits for two years.
I appreciate wanting to document this process, but I think it should allow for a lot of messiness. Like, this was a ton of work last year, and I didn't even bother checking other repositories, comments, stuff like that. Just straight up commits. In theory, someone might be landing other people's commits but not have commits of their own, but in practice, that seems to never happen. Anyway, I ran the list by the TSC first. And emailed the Collaborators. And then moved them.
Doing something like this monthly sounds exhausting and time-consuming unless someone intends to automate large portions of the process.
I'm OK with this criteria not being documented (or documented as guidelines only, not hard rules) and leaving it to whatever engaged person wants to make it happen to do the work and consult with the TSC.
devsnek commentedon Feb 20, 2018
@joyeecheung maybe this can be yet another thing in ncu?
joyeecheung commentedon Feb 20, 2018
@devsnek Well I already half-implemented something locally for the collaborator nomination template thing (and accidentally committed one of the GraphQL queries in another unrelated PR...), just need to find some time to flesh it out..
Edit: right, I also have a working but totally unmergable branch that walk through the collaborator list and list their latest comments in this issue tracker...that's written like, before or ~the same time
get-metadatawas born..benjamingr commentedon Feb 21, 2018
@joyeecheung awesome, can you also check for
Reviewed-Bywith their email in the commit log?Edit: I see this already works
hashseed commentedon Feb 21, 2018
Some companies offer 12 weeks or more parental leave. I personally have had 10 weeks in a row. So... get child, come back to committer status gone.
bnoordhuis commentedon Feb 21, 2018
I got two days... privileges are easy to reinstate though, I don't think it'll be a big deal in practice.
BridgeAR commentedon Feb 21, 2018
I guess right now most inactive people are either inactive for a long term or they are at least active from time to time. So even if we set a period of six month it would probably almost be identical to a three month period.
Does someone know if we can verify my hypothesis easily?
joyeecheung commentedon Feb 22, 2018
I think in that case the people who need to be absent for a long time can just say that in, say, the private discussion page before they start their leaves. Another upside about that is other people would know not to ping them or request reviews from them when unnecessary, and not to put something on hold until they show up.
joyeecheung commentedon Feb 22, 2018
My findings using the
ncu-contribtool was:I prefer not to show the lists in public because that looks too confronting, although the tools is public (a PR though) and the Github API is public too.
4 remaining items
joyeecheung commentedon Feb 24, 2018
Here is a poll:
If a collaborator have not shown up in the whole organization for [time span], reconfirm if they still want to stay, if they do not reply or say they do not wish to stay, move them to "Collaborator Emeritus". If they still want to stay, revisit after another [time span]:
Or:
apapirovski commentedon Feb 24, 2018
Being a collaborator seems to me mostly about CI access. If someone hasn't made a single PR or a commit in a year, I don't really see a good reason for them to remain a collaborator. They can always be reinstated if they decide to come back...
Also, if someone hasn't even made a comment (let alone a more substantial involvement) in 6 months, I see no reason for them to remain a collaborator.
So I guess that's two separate criteria... ? Probably not helpful, I know.
addaleax commentedon Feb 24, 2018
I have to say, I’m not a fan of removing existing collaborators periodically to keep access restrictions somewhat tight.
If that’s the goal, then let’s create a team for collaborators with CI access, use that for controlling access to it, and make moving in or out of that team really easy (just go to IRC or contact a TSC member directly & ask them to flip the bit).
I’m not too worried about the ability to land PRs, it’s not like that happens without anybody noticing, and especially not if it’s a collaborator that’s usually more or less inactive.
I think it’s important to show appreciation for people who’ve put work into Node in a prominent place. That doesn’t have to happen in the current format or be restricted to collaborators, though.
joyeecheung commentedon Feb 24, 2018
I think we already cover that with AUTHORS? Also that's more like what everybody uses...IMO putting a list like that in the README is OK if the list contains < 10 people, but it does not really help if the list has > 100 entires (off-topic: even less helpful when the "Contributing to Node.js" section is after the super long lists).
joyeecheung commentedon Feb 24, 2018
Sounds like a good idea to me. Maybe we can create a child team of @nodejs/collaborators ? We can give the privileges to the child team, and moves people out automatically after [time span] of inactivity. If they ever need access again, just say something in the team discussions and will be moved back.
I am curious if we ping the parent team, will everybody in the hierarchy get the notifications?They do, see: https://github.com/blog/2378-nested-teams-add-depth-to-your-team-structuremcollina commentedon Feb 25, 2018
We are tackling two separate concerns here:
Trying to find a good solution for both at the same time is not the best approach.
As there is 2FA across the whole org now, I think 2 is less of a problem. We need more people helping out in landing PRs, not reducing the number of people that can do it. I'm not opposing this.
That being said, a year+ absence can be seen as a reason to ask if somebody would still want to be involved. Side note, the collaborator can "say no" and stay a collaborator. There should be a "fast path" document for a collaborator emeritus that becomes active again.
I am really 👎 on removing the list of people from the README.md.
benjamingr commentedon Feb 25, 2018
@addaleax
I agree with this - the proposal being bikeshedded is to ask them if they're still interested in being a collaborator or not. This is only after a year of complete inactivity and as said they can simply say "no".
@mcollina
I definitely agree with that.
Also agreed, I don't think removing them from README really helps with anything (unless shorter readme is a goal) and I think acknowledging past contribution is important and meaningful. I know if I ever become inactive I'd appreciate it.
I'm not sure, but that can be solved in a different way (emailing them they're still a collaborator and listed in the README but their GitHub access is frozen until they become active again, at which point we just add them again).
I think this is also meaningful. I'd like to completely avoid cases where this causes friction with collaborators - this is why contacting the individual in private first and offering them a simple opt out (and over a month to think about it) is good.
joyeecheung commentedon Feb 25, 2018
I agree past contribution should be acknowledged, but I don't think putting a list of > 100 entries in the README is the best way to do it - half of the length of the current README comes from the lists, but I don't see why it cannot be put into a separate file being linked from README. Also I do think the README is longer than it should be, much like our CONTRIBUTING.md before it got split into different documents. Most popular repositories on GitHub have much shorter README with only succinct descriptions and links there - and I don't think I have seen any that lists these many people in the front page, they usually just put things like that in a AUTHORS file or on their website. That's probably a separate topic though, I'll draft some proposal in another issue later.
jasnell commentedon Feb 25, 2018
+1 to everything @mcollina said. For those contributors who are no longer actively contributing, I would take another step beyond asking them if they intend to contribute more and ask them also why they've chosen to be inactive. Knowing the answer to that may help inform the discussion further.
BridgeAR commentedon Apr 22, 2018
Is there any conclusion here?
benjamingr commentedon Apr 22, 2018
@BridgeAR not sure - @nodejs/tsc would anyone be willing to bring this up for discussion at some future meeting?
Trott commentedon Apr 23, 2018
I personally think it's important that the TSC meetings avoid open-ended discussions as much as possible. So I'd prefer that there be a specific narrow proposal. And I'd prefer that the specific narrow proposal be opened as a PR and the conversation happen in the PR first before moving to a TSC meeting.
That said, as you probably know, anyone can put something on the TSC agenda. It doesn't have to be a TSC member. (But it's useful to get a TSC member to be a champion like you're trying to do!)
Speaking for myself only, my opinion hasn't changed since my original comment in #18879 (comment). I'm getting ready to do the second annual audit of Collaborator membership at the start of May. Maybe I can document the criteria/process then, although I have mixed-at-best feelings about writing anything that makes it sound like this thing I just happen to do once a year on my own is something the project is required to do or is part of some official something-or-other...
benjamingr commentedon Apr 23, 2018
I'll go ahead and close this then. I'll let you do your thing and let's revisit this again if anyone feels strongly about it.
benjamingr commentedon Apr 23, 2018
To clarify: I am aware that I can ask to put something on the TSC agenda (thanks for making sure I'm aware of it though). I was just wondering if any TSC member would like to pick this up and champion it.