Repository navigation
Review Build and Jenkins-Admins membership #2140
Description
As per the discussion in the last build working group meeting, the build working group would like to audit its membership to both the working group and the jenkins-admin teams.
We need to define a schedule to regular run this audit and remove any inactive members.
And we also should define a policy and checklist similar to Node cores offboarding.md
Im opening this issue to serve as a discussion before we begin the audit so we get in place what guidelines we go by but my initial ideas are:
- Member is inactive for 3/6 months (is this too long)
- When pinged member doesn't respond for 2 weeks (maybe too short)
- Moved to emeritus section of the README
- If the member wishes to come back they are reinstated back to the working group (They PR themselves and the BuildWG)
As part of the regular audit process we should also check to ensure we have enough people coverage of all areas of knowledge inside build and decide on which areas we need to increase the people coverage
@nodejs/build
Activity
mhdawson commentedon Jan 22, 2020
In order to avoid having to figure out what makes somebody inactive in reviews in some other teams/Working Groups we simply ask everybody if they plan to active going forward. If the answer is yes they stay. Most often those who are inactive will say that, those that don't respond after 2 weeks get a reminder and then if there is no response after 2 more weeks are assumed in active and moved. I know 4 weeks may seem like a long time but it gives people on vacation/busy to notice and respond.
sam-github commentedon Jan 22, 2020
Perhaps PR this into the README (or some other appropriate place). PRs are easier to comment on.
I agree with #2140 (comment), just ask people if they can be moved to Emiritus. If they say no, then we don't, there is no need to try to evaluate their contributions.
Maybe just add a line to the membership criteria saying that Emiritus members can request to be added back? Or say nothing about this at all, the current criteria for membership is fairly clear, anyone who wants to get added back probably matches the criteria still, as they used to. And if they do not match the criteria anymore, maybe they shouldn't be rubber stamped back in?
richardlau commentedon Jan 22, 2020
Usually for other groups this type of thing goes in
GOVERNANCE.mdbut we don't currently have one (#1319) as this working group was set up before the guidelines for working groups were written.rvagg commentedon Jan 23, 2020
I don't mind having some number of months documented as "inactive" if it's in general terms, not strict. Having a number that prompts someone in this group to go looking and asking would be helpful. If we don't define it then what's the trigger for assessing inactivity and running a cleanup? Even as simple as "members who appear to be inactive for a period of at least 6 months may be asked whether they wish to continue their membership". Then the process-oriented folks among us will take that as their lead to go pruning. Alternatively, it could be stated something like "At the beginning of each year, the team should ask each member whether they wish to continue their membership". The key being that we state a trigger for this actually happening.
Not too strict is the key here, we're happy to have help, we just don't really want too much cruft because we already have a lot of that.
Also, an offboarding checklist seems like something we probably should have by now!
AshCripps commentedon Jan 23, 2020
Ill PR in a draft
GOVERNANCE.mdtoday and we can use that to finalise the process. (ill use examples from other WG's to start it)I agree with @rvagg that having a trigger once or twice a year for us to activley go out check everyone still wants to be involved with build. - maybe putting something in the foundation calender to act as this trigger?
Trott commentedon Jan 23, 2020
Information only, use or disregard as you see fit: Not codified or anything, but over in core, I do a Collaborator audit after every major release, so every six months. This is informal, though. Any other TSC member can choose to do their own audit at any time. (They don't, but they theoretically could.)
doc: add GOVERNANCE.md
sam-github commentedon Jan 23, 2020
I suggest GOVERNANCE just say that we will do reviews "periodically", do one now (well, once GOVERNANCE lands), and then try for somewhere between once and twice a year.
doc: add GOVERNANCE.md and clean up docs (#2141)
sam-github commentedon Jan 29, 2020
Now that there is a GOVERNANCE and an OFFBOARDING, I guess this can go ahead?
AshCripps commentedon Jun 5, 2020
With #2339 this has come back round to my attention.
@nodejs/build any thoughts on execution? I think posting an issue with a ping to the members and allowing 4 weeks (reping after 2 for those who have not replied) asking for a thumbs up or down as to whether they plan to stay part of the working group. After this time any -1s or people who havent responded will be moved to emeritus in line with our GOVERNANCE.md
richardlau commentedon Jun 5, 2020
SGTM. Might be better to ask for a comment rather than a thumbs up/down as it's more permanent?
AshCripps commentedon Oct 15, 2020
Closing as audit was completed.