Retire collaborators who have been inactive for a year?

[benjamingr]

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.

[joyeecheung]

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]

Yes, that's nodejs/build#744.

[mcollina]

SGTM, I have a nice template that can be used. Il giorno mar 20 feb 2018 alle 10:55 Ben Noordhuis <notifications@github.com> ha scritto:

…

Yes, that's nodejs/build#744 <nodejs/build#744>. — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#18879 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADL45eG38JzOSrEQjKw0s2MHwE135plks5tWqSZgaJpZM4SLkeq> .

[maclover7]

+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]

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]

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]

Doing something like this monthly sounds exhausting and time-consuming unless someone intends to automate large portions of the process.

@joyeecheung maybe this can be yet another thing in ncu?

[joyeecheung]

@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-metadata was born..

commit d9a52cb5d3a15781c184a79252186da11e74d1cf (HEAD -> check-activity)
Author: Joyee Cheung <joyeec9h3@gmail.com>
Date:   Mon Oct 23 14:05:52 2017 +0800

    check acitivities

commit 2f3843c05b09a70bddf9b4eb7699cffd6688f131
Author: Joyee Cheung <joyeec9h3@gmail.com>
Date:   Mon Oct 23 13:51:55 2017 +0800

    init

[benjamingr]

@joyeecheung awesome, can you also check for Reviewed-By with their email in the commit log?

Edit: I see this already works

[hashseed]

CI access from people who have not been active for three months?

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]

I got two days... privileges are easy to reinstate though, I don't think it'll be a big deal in practice.

[BridgeAR]

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]

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.

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.