|
| 1 | +# Project Governance |
| 2 | + |
| 3 | +* [Contributor Ladder](#contributor-ladder-template) |
| 4 | + * [Contributor](#contributor) |
| 5 | + * [Reviewer](#reviewer) |
| 6 | + * [Maintainer](#maintainer) |
| 7 | + * [Core Maintainer](#coremaintainer) |
| 8 | + * [Community Manager](#communitymanager) |
| 9 | + * [Emeritus Maintainer](#emeritusmaintainer) |
| 10 | +* [Maintainers File](#maintainersfile) |
| 11 | +* [Inactivity](#inactivity) |
| 12 | +* [Involuntary Removal](#involuntary-removal-or-demotion) |
| 13 | +* [Stepping Down/Emeritus Process](#stepping-downemeritus-process) |
| 14 | +* [Updates to this Document](#updates-to-this-document) |
| 15 | +* [Contact](#contact) |
| 16 | + |
| 17 | +## Podman Project |
| 18 | + |
| 19 | +This document defines the governance of the Podman Project, including its subprojects. It defines the various roles our maintainers fill, how to become a maintainer, and how project-level decisions are made. |
| 20 | + |
| 21 | +## Contributor Ladder |
| 22 | + |
| 23 | +The Podman project has a number of maintainer roles arranged in a ladder. Each role is a rung on the ladder, with different responsibilities and privileges. Community members generally start at the first levels of the "ladder" and advance as their involvement in the project grows. Our project members are happy to help you advance along the contributor ladder. At all levels, contributors are required to follow the CNCF Code of Conduct (COC). |
| 24 | + |
| 25 | +Each of the project member roles below is organized into lists of three types of things. |
| 26 | + |
| 27 | +* "Responsibilities" – functions of a member |
| 28 | +* "Requirements" – qualifications of a member |
| 29 | +* "Privileges" – entitlements of member |
| 30 | + |
| 31 | +### Contributor |
| 32 | +Description: A Contributor supports the project and adds value to it. Contributions need not be code. People at the Contributor level may be new contributors, or they may only contribute occasionally. |
| 33 | + |
| 34 | +* Responsibilities include: |
| 35 | + * Follow the CNCF CoC |
| 36 | + * Follow the project contributing guide |
| 37 | +* Requirements (one or several of the below): |
| 38 | + * Report and sometimes resolve issues against any of the project’s repositories |
| 39 | + * Occasionally submit PRs against any of the project’s repositories |
| 40 | + * Contribute to project documentation, including the manpages, tutorials, and Podman.io |
| 41 | + * Attend community meetings when reasonable |
| 42 | + * Answer questions from other community members on the mailing list, Slack, Matrix, and other communication channels |
| 43 | + * Assist in triaging issues, following the [issue triage guide](./TRIAGE.md) |
| 44 | + * Assist in reviewing pull requests, including testing patches when applicable |
| 45 | + * Test release candidates and provide feedback |
| 46 | + * Promote the project in public |
| 47 | + * Help run the project infrastructure |
| 48 | +* Privileges: |
| 49 | + * Invitations to contributor events |
| 50 | + * Eligible to become a Reviewer |
| 51 | + |
| 52 | +### Reviewer |
| 53 | +Description: A Reviewer has responsibility for the triage of issues and review of pull requests on the Podman project or a subproject, consisting of one or more of the Git repositories that form the project. They are collectively responsible, with other Reviewers, for reviewing changes to the repository or repositories and indicating whether those changes are ready to merge. They have a track record of contribution and review in the project. |
| 54 | + |
| 55 | +Reviewers have all the rights and responsibilities of a Contributor, plus: |
| 56 | + |
| 57 | +* Responsibilities include: |
| 58 | + * Regular contribution of pull requests to the Podman project or its subprojects |
| 59 | + * Triage of GitHub issues on the Podman project or its subprojects |
| 60 | + * Regularly fixing GitHub issues on the Podman project or its subprojects |
| 61 | + * Following the [reviewing guide](./REVIEWING.md) and [issue triage guide](./TRIAGE.md) |
| 62 | + * A sustained high level of pull request reviews on the Podman project or one of its subprojects |
| 63 | + * Assisting new Contributors in their interactions with the project |
| 64 | + * Helping other contributors become reviewers |
| 65 | +* Requirements: |
| 66 | + * Has a proven record of good-faith contributions to the project as a Contributor for a period of at least 6 months. The time requirement may be overridden by a supermajority (66%) vote of Maintainers and Core Maintainers. |
| 67 | + * Has participated in pull request review and/or issue triage on the project for at least 6 months. The time requirement may be overridden by a supermajority (66%) vote of Maintainers and Core Maintainers. |
| 68 | + * Is supportive of new and occasional contributors and helps get useful PRs in shape to merge |
| 69 | +* Additional privileges: |
| 70 | + * Has rights to approve pull requests in the Podman project or a subproject, marking them as ready for a Maintainer to review and merge |
| 71 | + * Can recommend and review other contributors to become Reviewers |
| 72 | + |
| 73 | +In repositories using an OWNERS file, Reviewers are listed as Reviewers in that file. |
| 74 | + |
| 75 | +#### The process of becoming a Reviewer is: |
| 76 | +1. The contributor must be sponsored by a Maintainer. That sponsor will open a PR against the appropriate repository, which adds the nominee to the MAINTAINERS.md file as a reviewer. |
| 77 | +2. The contributor will add a comment to the pull request indicating their willingness to assume the responsibilities of a Reviewer. |
| 78 | +3. At least two Maintainers of the repository must concur to merge the PR. |
| 79 | + |
| 80 | +### Maintainer |
| 81 | +Description: Maintainers are established contributors with deep technical knowledge of the Podman project and/or one of its subprojects. Maintainers are granted the authority to merge pull requests, and are expected to participate in making decisions about the strategy and priorities of the project. Maintainers are responsible for code review and merging in a single repository or subproject. It is possible to become Maintainer of additional repositories or subprojects, but each additional repository or project will require a separate application and vote. They are able to participate in all maintainer activities, including Core Maintainer meetings, but do not have a vote at Core Maintainer meetings. |
| 82 | + |
| 83 | +In repositories using an OWNERS file, Maintainers are listed as Approvers in that file. |
| 84 | + |
| 85 | +A Maintainer must meet the responsibilities and requirements of a Reviewer, plus: |
| 86 | +* Responsibilities include: |
| 87 | + * Sustained high level of reviews of pull requests to the project or subproject, with a goal of one or more a week when averaged across the year. |
| 88 | + * Merging pull requests which pass review |
| 89 | + * Mentoring new Reviewers |
| 90 | + * Participating in CNCF maintainer activities for the projects they are maintainers of |
| 91 | + * Assisting Core Maintainers in determining strategy and policy for the project |
| 92 | + * Participating in, and leading, community meetings |
| 93 | +* Requirements |
| 94 | + * Experience as a Reviewer for at least 6 months, or status as an Emeritus Maintainer. The time requirement may be overridden by a supermajority (66%) vote of Maintainers and Core Maintainers. |
| 95 | + * Demonstrates a broad knowledge of the project or one or more of its subprojects |
| 96 | + * Is able to exercise judgment for the good of the project, independent of their employer, friends, or team |
| 97 | + * Mentors contributors, reviewers, and new maintainers |
| 98 | + * Collaborates with other Maintainers to work on complex contributions |
| 99 | + * Can commit to maintaining a high level of contribution to the project or one of its subprojects |
| 100 | +* Additional privileges: |
| 101 | + * Represent the project in public as a senior project member |
| 102 | + * Represent the project in interactions with the CNCF |
| 103 | + * Have a voice, but not a vote, in Core Maintainer decision-making meetings |
| 104 | + |
| 105 | +#### Process of becoming a maintainer: |
| 106 | +1. A current reviewer must be sponsored by a Maintainer of the repository in question or a Core Maintainer. The Maintainer or Core Maintainer will open a PR against the repository and add the nominee as a Maintainer in the MAINTAINERS.md file. The need for a sponsor is removed for Emeritus Maintainers, who may open this pull request themselves. |
| 107 | +2. The nominee will add a comment to the PR confirming that they agree to all requirements and responsibilities of becoming a Maintainer. |
| 108 | +3. A majority of the current Maintainers of the repository or subproject (including Core Maintainers) must then approve the PR. The need for a majority is removed for Emeritus Maintainers, who require only 2 current Maintainers or Core Maintainers to approve their return. |
| 109 | + |
| 110 | +### Core Maintainer |
| 111 | +Description: As the Podman project is composed of a number of subprojects, most maintainers will not have full knowledge of the full project and all its technical aspects. Those that do are eligible to become Core Maintainers, responsible for decisions affecting the entire project. Core Maintainers may act as a maintainer in all repositories and subprojects of the Podman Project. |
| 112 | + |
| 113 | +* Responsibilities include: |
| 114 | + * All responsibilities of a maintainer, but applied to all repositories that make up the project |
| 115 | + * Determining strategy and policy for the project |
| 116 | +* Requirements |
| 117 | + * Experience as a Maintainer for at least 3 months |
| 118 | + * Demonstrates a broad knowledge of all components, repositories, and subprojects of the Podman project. |
| 119 | + * Is able to exercise judgment for the good of the project, independent of their employer, friends, or team |
| 120 | + * Mentors new Maintainers and Core Maintainers |
| 121 | + * Able to make decisions and contributions affecting the whole project, including multiple subprojects and repositories |
| 122 | + * Can commit to maintaining a high level of contribution to the project as a whole |
| 123 | +* Additional privileges: |
| 124 | + * Represent the project in public as a senior project member |
| 125 | + * Represent the project in interactions with the CNCF |
| 126 | + * Have a vote in Core Maintainer decision-making meetings |
| 127 | + |
| 128 | +#### Process of becoming a Core Maintainer: |
| 129 | +1. A current maintainer must be sponsored by Core Maintainer. The Core Maintainer will open a PR against the main Podman repository and add the nominee as a Core Maintainer in the MAINTAINERS.md file. |
| 130 | +2. The nominee will add a comment to the PR confirming that they agree to all requirements and responsibilities of becoming a Core Maintainer. |
| 131 | +3. A majority of the current Core Maintainers must then approve the PR. |
| 132 | +4. If, for some reason, all existing members are inactive according to the Inactivity policy below or there are no Core Maintainers due to resignations, a supermajority (66%) vote of maintainers can bypass this process and approve new Core Maintainers directly. |
| 133 | + |
| 134 | +### Community Manager |
| 135 | +Description: Community managers are responsible for the project’s community interactions, including project social media, website maintenance, gathering metrics, managing the new contributor process, ensuring documentation is easy to use and welcoming to new users, and managing the project’s interactions with the CNCF. This is a nontechnical role, and as such does not require technical contribution to the project. |
| 136 | + |
| 137 | +* Responsibilities include: |
| 138 | + * Participating in CNCF maintainer activities |
| 139 | + * Arranging, participating in, and leading, community meetings |
| 140 | + * Managing the project website and gathering associated metrics |
| 141 | + * Managing the project’s social media accounts and mailing lists and gathering associated metrics |
| 142 | +* Requirements |
| 143 | + * Sustained high level of contribution to the community, including attending and engaging in community meetings, contributions to the website, and contributions to documentation, for at least six months |
| 144 | + * Is able to exercise judgment for the good of the project, independent of their employer, friends, or team |
| 145 | + * Can commit to maintaining a high level of contribution to the project's community, website, and social media presence |
| 146 | + * Advocates for the community in Maintainer and Core Maintainer meetings |
| 147 | +* Additional privileges: |
| 148 | + * Represent the project in public |
| 149 | + * Represent the project in interactions with the CNCF |
| 150 | + * Have a voice, but not a vote, in Core Maintainer decision-making meetings |
| 151 | + |
| 152 | +#### Process of becoming a Community Manager: |
| 153 | +1. Community Managers must be sponsored by a Core Maintainer. The Core Maintainer will open a PR against the main Podman repository and add the nominee as a Community Manager in the MAINTAINERS.md file. |
| 154 | +2. The nominee will add a comment to the PR confirming that they agree to all requirements and responsibilities of becoming a Community Manager. |
| 155 | +3. A majority of the current Core Maintainers must then approve the PR. |
| 156 | + |
| 157 | +### Emeritus Maintainer |
| 158 | +Emeritus Maintainers are former Maintainers or Core Maintainers whose status has lapsed, either voluntarily or through inactivity. We recognize that these former maintainers still have valuable experience and insights, and maintain Emeritus status as a way of recognizing this. Emeritus Maintainer also offers a fast-tracked path to becoming a Maintainer again, should the contributor wish to return to the project. |
| 159 | + |
| 160 | +Emeritus Maintainers have no responsibilities or requirements beyond those of an ordinary Contributor. |
| 161 | + |
| 162 | +#### Process of becoming an Emeritus Maintainer: |
| 163 | +1. A current Maintainer or Core Maintainer may voluntarily resign from their position by making a pull request changing their role in the OWNERS file. They may choose to remove themselves entirely or to change their role to Emeritus Maintainer. |
| 164 | +2. Maintainers and Core Maintainers removed due to the Inactivity policy below may be moved to Emeritus Status. |
| 165 | + |
| 166 | +--- |
| 167 | + |
| 168 | +## Maintainers File |
| 169 | + |
| 170 | +The definitive source of truth for maintainers of a repository is the MAINTAINERS.md file in that repository. The MAINTAINERS.md file in the main Podman repository is used for project-spanning roles, including Core Maintainer and Community Manager. Some repositories in the project will also have an OWNERS file, used by the CI system to map users to roles. Any changes to the OWNERS file must make a corresponding change to the MAINTAINERS.md file to ensure that file maintains up to date. Most changes to MAINTAINERS.md will require a change to the repository’s OWNERS file (e.g. adding a Reviewer) but some will not (e.g. promoting a Maintainer to a Core Maintainer, which comes with no additional CI-related privileges). |
| 171 | + |
| 172 | +## Inactivity |
| 173 | + |
| 174 | +* Inactivity is measured by one or more of the following: |
| 175 | + * Periods of no contribution of code, pull request review, or participation in issue triage for longer than 12 months |
| 176 | + * Periods of no communication for longer than 3 months |
| 177 | +* Consequences of being inactive include: |
| 178 | + * Involuntary removal or demotion |
| 179 | + * Being asked to move to Emeritus status |
| 180 | + |
| 181 | +## Involuntary Removal or Demotion |
| 182 | + |
| 183 | +Involuntary removal/demotion of a contributor happens when responsibilities and requirements aren't being met. This may include repeated patterns of inactivity, an extended period of inactivity, a period of failing to meet the requirements of your role, and/or a violation of the Code of Conduct. This process is important because it protects the community and its deliverables while also opening up opportunities for new contributors to step in. |
| 184 | + |
| 185 | +Involuntary removal or demotion of Maintainers and Reviewers is handled through a vote by a majority of the current Maintainers. Core Maintainers may be involuntarily removed by a majority vote of current Core Maintainers or, if all Core Maintainers have stepped down or are inactive according to the inactivity policy, by a supermajority (66%) vote of maintainers. |
| 186 | + |
| 187 | +## Stepping Down/Emeritus Process |
| 188 | +If and when contributors' commitment levels change, contributors can consider stepping down (moving down the contributor ladder) vs moving to emeritus status (completely stepping away from the project). |
| 189 | + |
| 190 | +Maintainers and Reviewers should contact the Maintainers about changing to Emeritus status, or reducing your contributor level. Core Maintainers should contact other Core Maintainers. |
| 191 | + |
| 192 | +## Updates to this document |
| 193 | +Updates to this Governance document require approval from a supermajority (66%) vote of the Core Maintainers. |
| 194 | + |
| 195 | +## Contact |
| 196 | +* For inquiries, please reach out to: |
| 197 | + * [Tom Sweeney, Community Manager ]([email protected]) |
0 commit comments