Define maintainer process

[tas50]

Once we have defined a project in #14 we need to define the process for maintaining each project. This issue will define a process for assigning maintainers to a project and will give a rough idea of the responsibilities of a maintainer.

[tas50]

My thoughts:

• Each project has a maintainer team. The team bit is key here. Projects cannot have a single maintainer.
• The maintainers are responsible for merging code and triaging issues. SLAs for these and how that process will function should be determined in another ticket.
• Maintainers are responsible for the overall project planning and roadmap of their project. How the project roadmaps process will function should be determined in another ticket.
• Maintainer reviews are required on all code and maintainers are the only ones that can merge code into a project. If you need to merge code, then you are a maintainer. Ideally the process for adding / removing maintainers is simple and automated.
• The maintainers need to be publicly available in a real-time communication medium (slack?) so that the community can interact.
• All maintainer team discussion outside of security issues should be done in a public forum of some sort (slack?)

Technical Implementation Details

• The maintainer team needs to be noted in the project readme so that the community knows who is responsible for the project and how they can contact the team.
• Maintainers are setup as groups in Github. This will require a large refactoring our current team setup. This needs to be entirely automated so we don't get the mess of teams we currently have.
• The maintainer team is added as a codeowner on their repository so that they are automatically setup via Github for code reviews
• A tool such as Pullreminders.com is setup to ping maintainers for reviews / triage.
• Somehow we need to manage the list of projects and maintainers. This is pretty key as it allows us to work with management on workloads and makes auditing / reporting easier. Should this be a central repo that we use to setup the groups? For Chef we have the single toml file, but that's gotten to be insane and probably wouldn't scale to 200+ repos.

[eeyun]

100% agreement on all points. WRT management of projects/maintainers - if we had a single tool that could manage CONTRIBUTORS.md or perform other useful activities related to maintainers for N+1 repo's that would be ideal. Might be that tool doesnt exist today.

[tas50]

Some tool or tools are going to be needed to maintain groups, codeowners files, and any other contributing docs that mention the maintainers. It has to be automated or this doesn't work. That might mean we have to create some basic tooling. I hope we can find something that works for us though.

[nellshamrell]

I'd like to push back a bit on "publicly available in a real-time communication medium" - I realize this is the ideal, but it hasn't been sustainable in the past and has resulted in burn out. Additionally, unless we have the paid Slack (which we know is a no go) I think all maintainer and development conversations should be in a durable medium.

How would you feel about communication between maintainers and community members happening through Github?

[nellshamrell]

• Projects have maintainers, not authors
• At least two maintainers must be a current Chef employees
• The maintainers are responsible for merging code and triaging issues.
• Maintainers are responsible for communicating overall project planning and roadmap of their project.
• Roadmaps are planned by Product Management, Engineering Leadership, and maintainers (including external maintainers - who have input, but not veto power)
• Maintainer reviews are required on all code and maintainers are the only ones that can merge code into a project. If you need to merge code, then you are a maintainer.
• All maintainer team discussion outside of security issues should be done in a public forum of some sort
• The maintainer team needs to be noted in the project readme so that the community knows who is responsible for the project and how they can contact the team.
• The maintainer team is added as a codeowner on their repository so that they are automatically setup via Github for code reviews
• A tool is setup to ping maintainers for reviews / triage and enforce SLA.
• All contributions must include Developer Certificate of Origin signoff

TODO:

• Research what other companies who focus on open source do for communication with external community (real time? Async?) - how do they manage this? (@gpeers) Research what other companies who focus on Open Source do for communication with community #18
• Research maintainer access management (Github Groups? Remember we will need external as well as internal maintainers). (Tim, Gina, Eeyun, Miah) Research Maintainer access management #19
• Research tools for pinging maintainers for reviews, PRs, etc. (@nellshamrell) Research tools for pinging maintainers for reviews, PRs, etc #20
• Research automated way to manage the list of projects and maintainers. (Eeyun and Miah) Research automated way to manage the list of projects and maintainers. #21
• Research/discuss DCO bot - do we need enhancements? (@robbkidd) Research/discuss DCO bot #22
• Process for sunsetting maintainership - what do we do when people leave? (@nellshamrell Eeyun) Process for sunsetting maintainership - what do we do when people leave?  #23
• Process for becoming a maintainer (@jerryaldrichiii Eeyun) Process for becoming a project member #24

[tas50]

As far as the overall structure of the maintainers here's what we use in the 3 major Chef managed projects

https://github.com/chef/chef-rfc/blob/master/rfc030-maintenance-policy.md#how-the-project-is-maintained
https://github.com/habitat-sh/habitat/blob/master/maintenance-policy.md
https://github.com/inspec/inspec/blob/master/MAINTAINERS.md