-
Notifications
You must be signed in to change notification settings - Fork 45
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
Process for sunsetting maintainership - what do we do when people leave? #23
Comments
We need a way to find what projects someone is a maintainer on as part of the offboarding process for if they leave Chef. (Ask Ops) This should be automated if possible. |
This is related to #19 |
It seems like we'll want some sort of pruning bot to handle this. This came up in today's conversation on Slack around the concept of members. If we have members that are added to the org on their second merged PR how do we manage that Github team? It's going to need some sort of bot that recognizes a 2nd PR to a project (or product?) and adds the user as a team member. From there they'll get some time period to contribute twice again to maintain that membership. We might be able to do something similar with maintainers, but that might get problematic on our slower repos that may not have enough issues / PRs. |
I think requiring contribution within a certain time period to maintain maintainership might be a little heavy handed for this overarching process - though I would be open to each project having the option of doing this. For a start, I lean to defining the process to become a maintainer (which we are working on in #15) and defaulting to "you are a maintainer unless a majority of other maintainers say otherwise" |
I think we should have an Alumni list on each README listing people who used to be maintainers but are not anymore |
This is partially resolved by #46. I'm going to expand a section to add an alumni list. |
Resolved by #54 |
No description provided.
The text was updated successfully, but these errors were encountered: