Document how maintainers are added/removed (e.g., GOVERNANCE.md)

[caniszczyk]

Describe the feature

CNCF requires a project to document its governance process, e.g.,

https://github.com/envoyproxy/envoy/blob/main/GOVERNANCE.md
https://github.com/containernetworking/cni/blob/master/GOVERNANCE.md

This will be required for graduation

Extra information or context

No response

[castrojo]

Ok ready to start working on this, I'd like to PR a draft of what a governance.md would look like, however we should come to a consensus on what we want the process to look like, so taking at a stab at it with some ideas off the bat and then we can adjust over time.

Looking at the existing OWNERS it's clear that there is a separation of roles as far as provider maintainers and a lead. In our quest to un-busfactor ourselves I think it's reasonable to keep this existing structure, but just ensure that we are adding people to it.

Here are some examples of fleshed out member roles, I think these are too big city for us and we don't need most of it, but they do try to define what the role should look like, specifically the requirements of what each role could be:

• https://github.com/knative/community/blob/main/ROLES.md
• https://github.com/kubernetes/community/blob/master/community-membership.md

So off the bat I'm thinking:

• Lead Maintainers: (some set of criteria)
• Maintainers: (some set of criteria)

We could do something like "reviewed at least 10 PRs", "been around for 3 months", and all of those, which would give us an idea of the amount of work/responsibility that is expected of each role, but we also know that metrics like this can be misleading, so a method of peer nomination would be a great supplement to this.

We should also think about codifying what the responsibilities are for both groups. Currently we have an informal process of submitting an issue or bringing up an idea at the community meeting, and I'm leaning towards also landing an enhancement process concurrently with this (maybe even as a prereq). Our last status for an enhancement process was to add a template so that we can start writing specs.

Also not sure what the relationship is with having people in the github org would entail, but we should probably have ideas around what to do there. Thoughts/additions?

[castrojo]

Here is a draft, I'd like to discuss this at the next community meeting, hash out the gist, and then I'll PR it:

This document describes the set of roles individuals might have within the Cloud Custodian (c7n) community, the requirements of each role, and the privileges that each role grants.

• Role Summary
• Member
• Approver
• Lead

Note that most contributions to Cloud Custodian are by drive-by or casual contributions. These general contributions are not listed as a specific role, this document defines contributors that endeavor for more responsibility and maintainership of the project.

Role Summary

The following table lists the roles we use within the Cloud Custodian community. The table describes:

• General responsibilities expected by individuals in each role
• Requirements necessary to join or stay in a given role for repos in the Knative GitHub org
• How the role manifests in terms of permissions and privileges.

Role	Responsibilities	Requirements	Privileges	Scope
Member	Regular active contributor in the community	Has made multiple contributions to the project	Member of the GitHub org Review	GitHub Organization
Maintainer	Approve contributions from other members	Highly experienced and active reviewer and contributor to an area	Write permissions on one or more repos allowing PRs to be merged Additional admin privileges	GitHub Directory
Lead	Set technical direction	Demonstrated responsibility and excellent technical judgement	Drive the direction of the project Act as "tie breaker" for consensus	Represent the project to the CNCF

Note that the GitHub structure is a reflection of the MAINTAINERS. These leads are free to use their judgement to set the bar for what is required to become an approver and/or owner for repos they are responsible for.

Members

Established community members are expected to demonstrate their adherence to the principles in this document, familiarity with project organization, roles, policies, procedures, conventions, etc., and technical and/or writing ability.

Members are continuously active contributors in the community. They can have issues and PRs assigned to them, participate in working group meetings, and pre-submit tests are automatically run for their PRs. Members are expected to remain active contributors to the community.

All members are encouraged to help with the code review burden, although each PR must be reviewed by an official Maintainer.

When reviewing, contributors should focus on code quality and correctness, including testing and factoring. Members might also review for more holistic issues, but this is not a requirement.

Requirements

• Enabled 2FA on their GitHub account
• Member of the Cloud Custodian GitHub org.
• Has made multiple contributions to the project or community. Contributions
  might include, but are not limited to:
  • Authoring and reviewing PRs on GitHub.
  • Filing and commenting on issues on GitHub.
  • Contributing to working group or community discussions.
• Subscribed to
  cloud-custodian@googlegroups.com.
• Actively contributing to 1 or more areas.

Responsibilities and privileges

• Responsive to issues and PRs assigned to them.
• Active owner of code they have contributed (unless ownership is explicitly
  transferred).
  • Code is well tested.
  • Tests consistently pass.
  • Addresses bugs or issues discovered after code is accepted.

Members who frequently contribute code are expected to proactively perform code reviews and work towards becoming an approver for the area that they are active in.

Maintainer

Code maintainers are able to both review and approve code contributions. While code review is focused on code quality and correctness, approval is focused on holistic acceptance of a contribution including: backward / forward compatibility, adhering to API and flag conventions, subtle performance and correctness issues, interactions with other parts of the system, etc. Maintainership status is scoped to a part of the codebase.

Requirements

• Has spent time at least 3 months as a Member
• Reviewer of the codebase for at least 3 months.
• Primary reviewer for at least 10 substantial PRs to the codebase.
  • One path for getting the necessary reviews is to add yourself to the
    reviewers section of the OWNERS file. Note that this does not give you any
    additional privileges. By having yourself listed in this section in OWNERS
    file means that you will get PRs assigned to you for code review. Getting
    added to reviewers section is at the discretion of an approver after
    enough evidence of quality contributions.
• Reviewed at least 30 PRs to the codebase.
• Nominated by another Maintainer
  • Requirements listed here may be waived depending on need and judgement of existing Maintainers

Responsibilities and privileges

• Maintainer status can be a precondition to accepting large code contributions.
• Demonstrate sound technical judgment.
• Responsible for project quality control via code reviews
  • Focus on holistic acceptance of contribution such as dependencies with other
    features, backward / forward compatibility, API and flag definitions, etc.
• Expected to be responsive to review requests as per community expectations.
• Approve code contributions for acceptance.
• Represent Cloud Custodian as an official representative
  • e.g. Maintainer talk at a CNCF Event
• Design/proposal approval authority over the area / component, though
  escalation to the technical oversight committee is possible.
• Perform issue triage on GitHub.
• Apply/remove/create/delete GitHub labels and milestones.
• Write access to repo (assign issues/PRs, add/remove labels and milestones,
  edit issues and PRs, edit wiki, create/delete labels and milestones).
• Mentoring and guiding other maintainers, members, and new contributors.

Lead maintainer

Requirements

• At least 12 months as a Maintainer
• Reviewer of the codebase for at least 12 months
• Nominated by another Lead
• Requirements listed here may be waived depending on need and judgement of existing Leads

Responsibilities and Privileges

• Proven track record of sound technical judgement and mentorship
• Represent Cloud Custodian as an official representative
  • e.g. Can speak to the future direction of the project
• Act as tie-breaker in situations where maintainer quorum is not achieved
• Top level GitHub permissions (shared with CNCF)

Conflict resolution and voting

In general, we prefer that technical issues and maintainer membership are amicably worked out between the persons involved. If a dispute cannot be decided independently, the maintainers can be called in to decide an issue. If the maintainers themselves cannot decide an issue, the issue will be resolved by voting. The voting process is a simple majority in which each lead maintainer receives two votes and each normal maintainer receives one vote.

Applying for membership

• Applicants file a GitHub issue on the cloud-custodian/cloud-custodian repository outlining how they have met or exceeded each of the requirements for a given level.
• Existing members vote, the member needs majority vote to be accepted
  • Lead maintainers get 2 votes
  • All other members get 1 vote
  • Cloud Custodian community members are encouraged to leave feedback with non-binding votes
• If after 30 days of an open voting period and the voting quorum is not met the lead maintainers may accept/reject the application based on existing votes/feedback and the needs of the project.

Inactive members

Members are continuously active contributors in the community. A core principle in maintaining a healthy community is encouraging active participation. It is inevitable that people's focuses will change over time and
they are not expected to be actively contributing forever.

Members/Maintainers with an extended period away from the project with no activity in the past year (12 months) will be placed in "Emeritus" status in the OWNERS.md and will be required to go through the membership process again after re-familiarizing themselves with the current state.

How inactivity is measured

Inactive members are defined as maintainers in the OWNERS.md file with no contributions to the project within 12 months. This is measured by the CNCF DevStats project.

Devstats does not take into account non-code contributions, however since placing a maintainer into "Emeritus" is not automated, it is up to the discretion of the existing maintainers to determine if a person's non-code contributions are significant enough for the person to be considered a maintainer/member.

Become active again

If an "Emeritus" member wishes to become active they may reapply through the process. Existing maintainers may waive some (or all) requirements for reactivation based on consensus and needs of the project.

---

Except as otherwise noted, the content of this page is licensed under the
Creative Commons Attribution 4.0 License,
and code samples are licensed under the
Apache 2.0 License.

[castrojo]

Notes from community meeting from 24 May

TODO: Define a emeritus process (a yearish)
TODO: check out envoy to see if there's anything we can use there.
~6 months feels like a good starting metric for sustained contribution
Continue to make sure we define other contributions that are not code.

[castrojo]

Ok, some updates:

• First attempt at defining what a lead maintainer roles and responsibilities are
• Added an emeritus process
• Added a process on how someone can apply for membership (aka file an issue)
• Added a simple voting structure (majority). Similar to envoy, the leads have +2, maintainers have +1
  • Added explicit community feedback for membership - this is so end users can give feedback on candidates and give them an opportunity to participate, this will also cover instances where someone might have non-code contributions that we can note.
• I've added a "discretion of maintainers" to voting/membership explicitly based on needs of the project.
  • This is to ensure that if an area of the project is underserved and someone is stepping up to maintain it that the existing maintainers have a method to fast-track that person into the role if they are doing a good job. Trying to avoid the "you're doing great but the document says you have to wait another 10 days", if the existing maintainers think someone is rocking it and they have consensus then that's an option.