cert-manager Governance (proposal) [OLD, FOR REFERENCE ONLY]

⚠️ This HackMD document was moved to https://github.com/cert-manager/cert-manager/pull/6260 on 9 August 2023 ⚠️. I will keep this HackMD page for future references, but the canonical content will now be in the PR 6260.

cert-manager Governance

This document defines project governance for the cert-manager project. Its purpose is to describe how decisions are made on the project and how anyone can influence these decisions. We have six levels of responsability, each one building on the previous:

• Contributor,
• GitHub Member,
• Reviewer,
• Approver,
• Maintainer,
• Admin.

Contributors

cert-manager is for everyone. Anyone can become a cert-manager contributor simply by contributing to the project, whether through code, documentation, blog posts, community management, or other means. As with all cert-manager community members, contributors are expected to follow the cert-manager Code of Conduct.

All contributions to cert-manager code, documentation, or other components in the cert-manager GitHub org must follow the guidelines in the contributing page. Whether these contributions are merged into the project is the prerogative of the reviewers, approvers and/or maintainers.

GitHub Members

GitHub Members are active contributors to the cert-manager project.

A contributor is considered to be active when they have had at least one interaction (comment on an issue or PR or message in the #cert-manager or #cert- manager-dev channels) within the last 18 months.

Members that have been inactive over the past 18 months may be removed from the GitHub organization.

Defined by: Member of the cert-manager GitHub organization.

Becoming a GitHub Member

To be added as a GitHub member of the cert-manager organization, you will need to look for two sponsors with at least the reviewer role. These two sponsors must have had some meaningful interaction with you on an issue on GitHub or on the cert-manager or cert-manager-dev channels on Slack.

Then, open an issue on the cert-manager repository and mention your sponsors as well as links to the meaningful interations (Slack threads, GitHub issues). Ask your sponsors to confirm their sponsorship by commenting on your PR. After that, your request will be reviewed by a cert-manager admin, in accordance with their SLO.

To be added as a GitHub member, you will also need to enable two-factor authentication on your GitHub account.

GitHub members are encouraged to engage with the cert-manager-dev mailing list as well as the cert-manager and cert-manager-dev Slack channels.

Reviewers

The mission of the reviewer is to read through PRs for quality and correctness on all or some part of cert-manager. Reviewers are knowledgeable about the codebase as well as software engineering principles.

Defined by: the reviewers section in the file OWNERS.

Becoming a Reviewer

To become a reviewer, you will need to look for a sponsor with at least the approver role. Your sponsor must have had close interactions with you: he must have been closely reviewed one of your PRs or worked with you on a thorny issue.

Then, create a PR to add your name to the list of reviewers in the OWNERS file. The PR description should list your significant contributions and should mention your sponsor. Your sponsor is expected to give his approval as a comment on your PR.

Responsibilities

• When possible, review pull requests, triage issues, and fix bugs in their areas of expertise.
• Ensure that all changes go through the project's code review and integration processes.

Privileges

• Able to /lgtm on pull requests.

Approver

Note: some projects call this role "committer".

As an approver, your role is to make sure the right people reviewed the PRs. The approver's focus isn't to review the code; instead, they put a stamp of approval on an existing review with the command /approve. Note that it is always possible to review a PR as an approver with /lgtm, in which case the PR will be automatically approved.

Defined by: the approver section in the OWNERS file.

Becoming an Approver

To become an approver and start merging PRs, you must have reviewed 5 PRs.

You will then need to get sponsorship from one of the maintainers. The maintainer sponsoring you must have had close work interactions with you and be knowledgeable of some of your work.

To apply, open a PR to update the OWNERS file and mention your sponsor in the description. The PR description should also list the PRs you have reviewed.

Responsibilities

• Expected to be responsive to review requests.
• Stay up to date with the project's direction and goals, e.g., by attending some of the bi-weekly meetings, standups, or being around in the cert-manager-dev Slack channel.

Privileges

• Can /approve on pull requests.

Maintainer

A maintainer is someone who can communicate with the CNCF on behalf of the project and who can participate in lazy consensus and votes.

Defined by: MAINTAINERS.md.

Becoming a Maintainer

Anyone can become a cert-manager maintainer. Maintainers should be proficient in Go; have expertise in at least one of the domains (Kubernetes, PKI, ACME); have the time and ability to meet the maintainer expectations above; and demonstrate the ability to work with the existing maintainers and project processes.

To become a maintainer, start by expressing interest to existing maintainers. Existing maintainers will then ask you to demonstrate the qualifications above by contributing PRs, doing code reviews, and other such tasks under their guidance. After several months of working together, maintainers will decide whether to grant maintainer status.

Privileges

• Can communicate with the CNCF on behalf of the project.
• Can participate in lazy consensus and votes.

Responsibilities

• Monitor cncf-cert-manager-* emails and help out when possible.
• Respond to time-sensitive security release processes.
• Create and attend meetings with the cert-manager Steering Committee (not less than once a quarter).
• Attend "maintainers vote" meetings when one is scheduled.

Maintainer Decision-Making

Substantial changes to the project require a "maintainers decision". This includes, but is not limited to, changes to the project's roadmap, changes to the project's scope, fundamental design decisions, and changes to the project's governance.

A "maintainers decision" is made using lazy consensus. Email or Slack can be used to reach lazy consensus as long as the deliberation date and time are specified and the maintainers are CC'ed. You may use the following message template:

Dear maintainers, I'd like us to reach an agreement on the following matter using lazy consensus: […]

• 🧑‍💻 Participants: @cert-manager-maintainers
• 📢 Deadline: April 3rd, 2023 23:59 UTC
• 🚨 Note: to speed up the process, you may answer with a or a comment stating that your are lazy to help reach consensus before the deadline.

Any non-agreements with regards to the decision can be posted as comments on the Slack message or to the email thread.

Stepping Down as a Maintainer

If a maintainer is no longer interested in or cannot perform the duties listed above, they should move themselves to emeritus status. If necessary, this can also occur through the decision-making process outlined above.

A review of the MAINTAINERS.md file is performed every year by the current maintainers. During this review, the maintainers that have not been active in the last 18 months are asked whether they would like to become an emeritus maintainer, they are expected to respond within 30 days. If they do not respond, they will automatically be moved to emeritus status.

Admin

An admin is a maintainer who has admin privileges on the cert-manager infrastructure.

The admins aren't defined in any public file. The admins are the GitHub members on the cert-manager org that are set as "Owner". Additionally, admins have their email listed in GCP so that they can perform releases.

Becoming an Admin

To become an admin, you must already be a maintainer for a time and have some understanding of the technologies used in the cert-manager infrastructure (e.g., Prow). Then, create an issue on the cert-manager project and mention each maintainer. Each maintainer will need to comment on the issue to express their approval.

Privileges

• Can change settings in the GitHub organization (e.g., remove protected branches, add GitHub members, etc.)
• Can run the Google Cloud Build playbooks to release new versions of cert-manager.

Responsibilities

• Must have availability to allocate time to perform cert-manager releases.
• Must be available to perform admin-related tasks (add a GitHub member, promote a GitHub user to "Owner", add someone to the GCP projects, etc.)
• Must be responsible with the privileges granted to them.