⚠️ 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.
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:
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 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.
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.
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
.
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.
/lgtm
on pull requests.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.
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.
/approve
on pull requests.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
.
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.
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.Image Not Showing Possible ReasonsLearn More →
- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Any non-agreements with regards to the decision can be posted as comments on the Slack message or to the email thread.
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.
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.
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.