Create Maintainer/Triager guide

[nimbinatus]

Initial push for a maintainer guide per discussion about a need for understanding how fast we should respond and best practices on responding.

[nathan-weinberg]

Can we add this info to https://github.com/instructlab/community/blob/main/CONTRIBUTOR_ROLES.md instead of creating a new doc?

[nimbinatus]

Can we add this info to https://github.com/instructlab/community/blob/main/CONTRIBUTOR_ROLES.md instead of creating a new doc?

I don't think that this document matches that one. The CONTRIBUTOR_ROLES document is about definition of roles and responsibilities from a governance perspective. This is a (transparent/accessible for contributors) guide on how to do the work with tips and tricks, and that's not specific to specific roles. Usually, guides are separated from governance definitions in most open source projects I've encountered:

• Kubernetes roles and responsibilities vs Kubernetes contributor guides, which include the triage guide and the owners (aka the reviewers and approvers) guide,
• Python Governance (PEP13) vs Python Triage Guide,
• Homebrew maintainer guide vs Homebrew governance role definition and responsibilities, or
• for example this Linux kernel maintainer guide vs the related Linux kernel maintainer definition

[nathan-weinberg]

Can we add this info to https://github.com/instructlab/community/blob/main/CONTRIBUTOR_ROLES.md instead of creating a new doc?

I don't think that this document matches that one. The CONTRIBUTOR_ROLES document is about definition of roles and responsibilities from a governance perspective. This is a (transparent/accessible for contributors) guide on how to do the work with tips and tricks, and that's not specific to specific roles.

Usually, guides are separated from governance definitions in most open source projects I've encountered:

* [Kubernetes roles and responsibilities](https://github.com/kubernetes/community/blob/master/community-membership.md) vs [Kubernetes contributor guides](https://github.com/kubernetes/community/tree/master/contributors/guide), which include the triage guide and the owners (aka the reviewers and approvers) guide,

* [Python Governance (PEP13)](https://peps.python.org/pep-0013/#the-core-team) vs [Python Triage Guide](https://devguide.python.org/triage/triaging/),

* [Homebrew maintainer guide](https://docs.brew.sh/Maintainer-Guidelines) vs [Homebrew governance role definition and responsibilities](https://docs.brew.sh/Homebrew-Governance#8-maintainers), or

* for example [this Linux kernel maintainer guide](https://docs.kernel.org/maintainer/modifying-patches.html) vs [the related Linux kernel maintainer definition](https://docs.kernel.org/maintainer/feature-and-driver-maintainers.html#selecting-the-maintainer)

I don't think these are that different from one another - each contributor role has a section for responsibilities and privileges - having an entirely separate document dedicated to "what does that mean" seems like more overhead to me than adding an additional section. Personally, I can't think of any scenarios where folks reading one of these docs and shouldn't be reading the other. At a higher level, I feel the more documents you have in any organization, the less likely any of them will be read.

That being said, I can see your perspective and I'm amenable to otherwise, but at the very least I would need documents to point to one another where appropriate to approve this.