This document defines governance policies for the Kyverno and its sub-projects:
The Kyverno community adheres to the following principles:
- Open: The Kyverno community strives to be open, accessible and welcoming to everyone. Anyone may contribute, and contributions are available to all users according to open-source values and licenses.
- Transparent and accessible: Any changes to the Kyverno source code and collaborations on the project are publicly accessible (GitHub issues, PRs, and discussions).
- Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, scope, and design principles.
Kyverno follows the Code of Conduct, which is aligned with the CNCF Code of Conduct.
Kyverno follows the CNCF vendor neutrality guidelines documented at:
https://contribute.cncf.io/maintainers/community/vendor-neutrality/
Kyverno community meetings follow a defined schedule.
The maintainers may also have closed meetings to discuss security reports or Code of Conduct violations. Such meetings should be scheduled by any maintainer on receipt of a security issue or CoC report. All current Maintainers must be invited to such closed meetings, except for any maintainer who is accused of a CoC violation.
The Kyverno community welcomes all contributors and has well-defined roles detailed below.
This document highlights the roles and responsibilities for the Kyverno community members. It also outlines the requirements for anyone who is looking to take on leadership roles in the Kyverno project. The following governance applies to all Kyverno subprojects.
Note: Please make sure to read the CNCF Code of Conduct.
The table below summarizes project roles and responsibilities. Details are provided in the sections following the table:
| Role | Requirements | Ongoing Responsibilities | Defined by |
|---|---|---|---|
| Contributors | At least five (5) contributions to any sub-project. | None | CONTRIBUTORS.md |
| Maintainer | At least five (10) contributions to a sub-project + Highly experienced and active contributor + Voted in by Kyverno maintainers. | Monitor project growth, set direction and priorities for a subproject. | Voted in by the Kyverno maintainers, listing in MAINTAINERS.md, GitHub organization member, and repository owner. |
Contributors are individuals who have made at least five (5) contributions to the project; by authoring PRs, commenting on issues and pull requests, and participating in community discussions on Slack or the mailing list.
Checklist before becoming a Contributor
- Have at least five (5) PRs successfully merged for any repositories under the Kyverno organization
- Member of the kyverno channel on Kubernetes and/or CNCF Slack
- Attended one (1) Contributors Meeting as documented
- Registered for the Kyverno mailing list
Privileges of a Contributor
- Listed in the file in at least one (1) organization repository
- Kyverno contributor badge issued
To join the Kyverno project as a Contributor create a Pull Request (PR) in the Kyverno repository with the following:
- Changes to add yourself to the CONTRIBUTORS.md file.
- Links to your prior contributions (at least five).
- Links to slack discussions, issue comments, etc.
Maintainers are individuals who have shown good technical judgement in feature design/development in the past. Maintainers have overall knowledge of the project and features in the project. They can read, clone, and push to the repository. They can also manage issues, pull requests, and some repository settings.
Maintainers are the technical authority for a subproject and are considered leaders for the organization as a whole. They must have demonstrated both good judgement and responsibility towards the health of the subproject. Maintainers must set technical direction and make or approve design decisions for their subproject, either directly or through delegation of these responsibilities. Unlike contributors, maintainers have the highest degree of responsibility and ownership for the project. Maintainer status may be subject to a vote and, if the minimum level of activity is not maintained, may be moved to an emeritus status.
Checklist before becoming a Maintainer:
- Have at least ten (10) significant PRs successfully merged for any combination of repositories under the Kyverno organization
- Member of the
#kyvernoand#kyverno-devchannels on Kubernetes Slack workspace and the#kyvernochannel on the CNCF Slack workspace - Regularly attends Kyverno Maintainers and Community Meetings
- Registered for the Kyverno mailing list
- Create a pull request to add self to
CODEOWNERSfile in at least one (1) repository - Attained a minimum of two (3) positive votes from maintainers
- Respond to reviews from maintainers on pull requests
- Proficient in GitHub, YAML, Markdown, and Git
- Exhibits strong attention to detail when reviewing commits and provides generous guidance and feedback
- Helps others achieve their goals with open-source and community contributions
- Understands the workflow of the Issues and Pull Requests
- Makes consistent contributions to the Kyverno project
- Consistently initiates and participates in Kyverno discussions
- Has knowledge and interest that aligns with the overall project goals, specifications, and design principles of the Kyverno project
- Makes contributions that are considered notable
- Demonstrates ability to help troubleshoot and resolve user issues
- Has achieved the Kyverno Certification or demonstrated an equivalent mastery of Kyverno
- Maintains a consistent level of activity with contributions to the project
Responsibilities of a Maintainer
- Tracks and ensures adequate health of the modules and subprojects they are in charge of
- Ensures adequate test coverage to confidently release new features and fixes
- Ensures that tests are passing reliably (i.e. not flaky) and are fixed when they fail
- Mentors and guides code owners, reviewers, and contributors
- Actively participates in the processes for discussion and decision making in the project
- Merges Pull Requests and helps prepare releases
- Makes and approves technical design decisions for the subproject
- Helps define milestones and releases
- Decides on when PRs are merged to control the release scope
- Works with other maintainers to maintain the project's overall health and success holistically
Privileges of a Maintainer
- Listed as an organization member
- Listed in
CODEOWNERSin at least one (1) repository - Member of the https://lists.cncf.io/g/cncf-kyverno-maintainers mailing list
- Have issues assigned to them
- Have PRs assigned to them
- Receives a Kyverno Maintainer Badge
- Listed in
MAINTAINERS.md
On-boarding Criteria
- Voted in by a majority of current maintainers, raised in a PR by the proposed member to add themselves to
MAINTAINERS.md, during a voting period lasting at least three (3) working days
Off-boarding Criteria
An off-boarding vote may be called by any maintainer if any of the following criteria are met:
- A maintainer has made less than 30 contributions over a span of 6 months.
- Contributions can be tracked using the DevStats dashboard.
- Other relevant data will be collected and evaluated to assess the maintainer's contributions. This includes their involvement in discussions, conversations on Slack, and any other relevant interactions.
The off-boarding process includes the following steps:
- The off-boarding process is initiated by any currently active maintainer who conducts a review of the maintainers list and proceeds to initialize the off-boarding process if the above criteria are met.
- The plans of off-boarding process is sent in a private Slack message or email to the candidate.
- If the candidate for removal states plans to continue participating, another 6 months will be granted to the candidate to make contributions and the new cycle starts. No action is taken and this process terminates.
- If the candidate fails to meet the criteria during the second attempt to make contributions, the off-boarding process continues.
- A pull request (PR) proposing movement of the candidate is sent, initiating the public voting phase.
- The vote passes if a majority of current maintainers vote yes during a voting period lasting five (5) working days.
- A positive vote will result in movement to an emeritus status within
MAINTAINERS.mdand removal from organization membership.
The roles used in this document are custom roles mapped according to the GitHub roles and responsibilities.
| Project Role | GitHub Role |
|---|---|
| Contributor | Triage |
| Maintainer | Maintain |
If any of the above roles hasn't contributed in any phases (including, but not limited to: code changes, doc updates, issue discussions) in 3 months, the administrator needs to inform the member and remove one's roles and GitHub permissions.
The Kyverno projects code base cover many areas and project maintainers are not required to know everything about a project. For this reason, maintainers can be specific to one (or more) area of the code base, every area representing a specific aspect.
- Kyverno
- Kyverno Website
- Kyverno Policies
- Kyverno JSON
- Kyverno Chainsaw
- Kyverno Playground
- Kyverno Policy Reporter
- Kyverno Reports Server
This list is not exhaustive and is subject to modifications as the project evolves over time.
| Project | Area | Description |
|---|---|---|
| Kyverno | website |
Kyverno projects website and docs |
| Kyverno | policies-catalog |
Kyverno currated policies |
| Kyverno | helm-chart |
Kyverno Helm chart |
| Kyverno | engine |
Kyverno policy engine |
| Kyverno | cli |
Kyverno CLI |
| Kyverno | report-system |
Kyverno reporting system |
| Kyverno JSON | -- | Kyverno JSON project |
| Kyverno Chainsaw | -- | Kyverno Chainsaw project |
| Kyverno Playground | frontend |
Kyverno Playground frontend |
| Kyverno Playground | backend |
Kyverno Playground backend |
| Kyverno Playground | helm-chart |
Kyverno Playground Helm chart |
| Kyverno Policy Reporter | frontend |
Kyverno Policy Reporter frontend |
| Kyverno Policy Reporter | backend |
Kyverno Policy Reporter backend |
| Kyverno Policy Reporter | helm-chart |
Kyverno Policy Reporter Helm chart |
| Kyverno Reports Server | -- | Kyverno Reports Server project |
Typically, it is assumed that disputes will be resolved amicably by those involved. However, if the situation becomes more serious, conflicts will be resolved through a voting process. A supermajority of votes from project maintainers is required to make a decision, and the project lead has the final say in the ruling.
This Project Governance is a living document. All key project changes including changes in project governance can be proposed by a GitHub PR and then reviewed and voted on by project maintainers.
Sections of this document have been borrowed from the CoreDNS and fluxcd projects.