GOVERNANCE.md
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.
The Podman project currently consists of the Podman project (the repository containing this file) and two subprojects:
During a Core Maintainers meeting, any Maintainer or Core Maintainer may recommend projects to become a subproject of Podman Container Tools. These projects should have the following characteristics:
Before submitting an application to the Core Maintainers, the project in consideration must hold a consensus vote among all major contributors to join Podman Container Tools. The Core Maintainers will then review the application, and decide whether or not to accept it. If it is accepted, the Core Maintainers will assign at least one person to assist with the new subproject's integration. The definitive list of subprojects is contained above in the Subprojects section above, and the new subproject will be added to that list after its acceptance. The new subproject must map its existing maintainers to the roles defined in the Contributor Ladder upon being accepted. Appointments of Community Managers and Core Maintainers from the new subproject are subject to approval by the existing Core Maintainers; other roles may be assigned freely initially, but the Contributor Ladder advancement process must be followed after the project is accepted.
In some cases, subprojects will become inactive or unmaintainable, or wish to separate from Podman Container Tools. Any Core Maintainer may propose the removal of a subproject on these grounds. Additionally, the Maintainers of any subproject may request removal of their subproject by a publicly visible majority vote (for example, via GitHub issue). The Core Maintainers must confirm removals with a majority vote. The subproject will be removed as from the list of subprojects in the Subprojects section above.
Subprojects which still have contributors will then be moved to a repository in their own namespace. Projects which have ceased all activity will be kept in the same namespace but archived.
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).
Each of the project member roles below is organized into lists of three types of things.
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.
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.
Reviewers have all the rights and responsibilities of a Contributor, plus:
<repo-name>-reviewers team.
They also will be invited to the podman-container-tools GitHub organization as member.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.
A Maintainer must meet the responsibilities and requirements of a Reviewer, plus:
<repo-name>-maintainers team and removed from the <repo-name>-reviewers teams.
If they have a legitimate reason to require Admin privileges (e.g. working on project CI systems), a Maintainer can petition a Core Maintainer to be granted these additional privileges in GitHub.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. It is recognized that fulfilling all responsibilities of a maintainer on all project repositories is an excessive time commitment, so Core Maintainers are encouraged to choose one repository to specialize in and to spend most of their time working in that repository. Core Maintainers are encouraged to assist other repositories that require additional reviews as time allows, and should make an effort to review pull requests in other repositories that will affect multiple repositories (especially ones that will effect the repository they have chosen to specialize in).
podman-container-tools GitHub organization Owner.<repo-name>-maintainers teams. Separate from the permissions granted
above, this ensures that Core Maintainers receive pings meant for repository maintainers, as part of their responsibility to assist in code review
and decision making in all repositories.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.
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.
Emeritus Maintainers have no responsibilities or requirements beyond those of an ordinary Contributor.
The definitive source of truth for maintainers of this repository is the local MAINTAINERS.md file. The MAINTAINERS.md file in the main Podman repository is used for project-spanning roles, including Core Maintainer and Community Manager.
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.
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.
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).
Maintainers and Reviewers should contact the Maintainers about changing to Emeritus status, or reducing your contributor level. Core Maintainers should contact other Core Maintainers.
Updates to this Governance document require approval from a supermajority (66%) vote of the Core Maintainers.