Add initial draft of Podman project Governance #25398

mheon · 2025-02-25T19:39:51Z

This is the initial version of the governance model we're looking to implement. It is still very early, and comments and suggestions are very welcome!

DO NOT MERGE THIS until we have a broad agreement that the current version is acceptable.

Does this PR introduce a user-facing change?

NONE

GOVERNANCE.md

Luap99

Overall looks good to me.

One piece that I think is missing is to describe the github user permissions. I think we should likely define that here so that the permissions of each contributor are clearly defined somewhere, e.g. core maintainers will be admin/owner of the github org, maintainers will be admin in their specific repo(s) but not org wide, a reviewer should likely only get triage permissions then as they are not allowed to merge

Luap99 · 2025-02-26T12:38:31Z

GOVERNANCE.md

+
+A Maintainer must meet the responsibilities and requirements of a Reviewer, plus:
+* Responsibilities include:
+    * 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.


looks like cncf added us to their stat tracking, I have not looked into how they count PR reviews but here is the filter I came up with if we consider reviews over the last year per week, on the right it shows the averages for each person.

Nothing unusual in terms of names there, personally I think 1 is a pretty low bar but at the same time I am also not a fan of having "arbitrarily" interactions counts, because then people might start to game the metrics.

Confirm. I think one a week is a bit high for a maintainer; I'd go one a month. However, this is a reasonable level for a core maintainer. I, too, dislike an arbitrary number

and re-reading, it's a goal, not a requirement, so not as bad.

Luap99 · 2025-02-26T12:44:01Z

GOVERNANCE.md

+
+## Contact
+* For inquiries, please reach out to:
+    *  Tom Sweeney, Community Manager


might as well add the email address here so people don't have to look up contact info elsewhere

Luap99 · 2025-02-26T12:52:12Z

GOVERNANCE.md

+    * 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 vote of Maintainers.
+    * Is supportive of new and occasional contributors and helps get useful PRs in shape to merge
+* Additional privileges:
+    * Has rights to approve pull requests in the Podman project or a subproject


I don't think it is defined what approving means? It is not clear to me what it means, is it simply to say it has been reviewed by a reviewer?

Github's "approve" functionality, and/or the /approve function in the bot

Luap99 · 2025-02-27T11:20:47Z

MAINTAINERS.md

+
+## Maintainers
+
+| Maintainer           | GitHub ID                                                | Project Roles     | Affiliation                               |


table seems broken, it is not rendered correctly on github
https://github.com/containers/podman/blob/027818e4e4a610f6587d70fceadc86135aec8750/MAINTAINERS.md

Luap99 · 2025-02-27T11:21:46Z

MAINTAINERS.md

+| Jake Correnti        | [jakecorrenti](https://github.com/jakecorrenti)          | Reviewer          | [Red Hat](https://www.github.com/redhat/) |
+| Ashley Cui           | [ashley-cui](https://github.com/ashley-cui)              | Maintainer        | [Red Hat](https://www.github.com/redhat/) |
+| Nalin Dahyabhai      | [nalind](https://github.com/nalind)                      | Core Maintainer   | [Red Hat](https://www.github.com/redhat/) |
+| Jason Greene         | [n1hility](https://github.com/n1hility)                  | Reviewer          | [Red Hat](https://www.github.com/redhat/) |


Jason has not been active in a while here I think? Does he want to be reviewer? If we assign roles with responsibilities then we should likely ask everyone here if they are good with that but maybe you have done that?

But I guess this question applies to everyone here really?

Luap99 · 2025-02-27T11:35:39Z

MAINTAINERS.md

+| Aditya Rajan         | [flouthoc](https://github.com/flouthoc)                  | Reviewer          | [Red Hat](https://www.github.com/redhat/) |
+| Valentin Rothberg    | [vrothberg](https://github.com/vrothberg)                | Reviewer          | [Red Hat](https://www.github.com/redhat/) |
+| Giuseppe Scrivano    | [giuseppe](https://github.com/giuseppe)                  | Core Maintainer   | [Red Hat](https://www.github.com/redhat/) |
+| Neil Smith           | [Neil-Smith](https://github.com/Neil-Smith)              | Community Manager | [Red Hat](https://www.github.com/redhat/) |


Being "Community Manager" but per the governance a "Community Manager" is also a Maintainer and I think that is not right for Neil as he doesn't fulfil other important Maintainer tasks.

And another thing that is unclear if one is listed as "Community Manager" are they a normal maintainer or core maintainer? Maybe it would be better to define "Community Manager" as a role that is not tied to the maintainer/reviewer roles.
Then someone can only be a Community Manager. And for a Maintainer such as Tom we could just list as Community Manager and Core Maintainer?

I originally had Community Manager as a separate role, but moved it into Maintainer at the suggestion of @baude - I have no issues with separating it again.

I think that is mischaracterized a bit. My opinion is that a community manager should not just be anyone off the street. As such, I would agree that community manager in itself does not entitle you to privileges to the repository. In other words, you can be a community manager and maintainer; but being a community manager does not make you maintainer.

Updated to make Community Manager a separate role.

mheon · 2025-03-04T15:26:43Z

I'm going to push another draft this afternoon which includes changes to the Community Manager role to separate it from maintainer.

mheon · 2025-03-05T13:40:58Z

Updated version pushed with community manager definition changed. I think we can probably go ahead and merge this, in a non-binding, open for changes form, early next week.

jakecorrenti · 2025-03-06T18:57:21Z

MAINTAINERS.md

+|-------------------|----------------------------------------------------------|----------------------------------|-------------------------------------------|
+| Brent Baude       | [baude](https://github.com/baude)                        | Core Maintainer                  | [Red Hat](https://www.github.com/redhat/) |
+| Ygal Blum         | [ygalblum](https://github.com/ygalblum)                  | Maintainer                       | [Red Hat](https://www.github.com/redhat/) |
+| Jake Correnti     | [jakecorrenti](https://github.com/jakecorrenti)          | Reviewer                         | [Red Hat](https://www.github.com/redhat/) |


The Red Hat GH link here is some random user. The proper link is https://github.com/RedHatOfficial

Excellent catch, TY

packit-as-a-service · 2025-03-06T21:51:30Z

Cockpit tests failed for commit d7d744f. @martinpitt, @jelly, @mvollmer please check.

danishprakash · 2025-03-07T05:34:21Z

GOVERNANCE.md

+
+## Contributor Ladder
+
+Hello! We are excited that you want to learn more about our project contributor ladder! This contributor ladder outlines the different contributor roles within the project, along with the responsibilities and privileges that come with them. Community members generally start at the first levels of the "ladder" and advance up it 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).


Suggested change

Hello! We are excited that you want to learn more about our project contributor ladder! This contributor ladder outlines the different contributor roles within the project, along with the responsibilities and privileges that come with them. Community members generally start at the first levels of the "ladder" and advance up it 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).

Hello! We are excited that you want to learn more about our project contributor ladder! This contributor ladder outlines the different contributor roles within the project, along with the responsibilities and privileges that come with them. 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).

danishprakash · 2025-03-07T05:36:23Z

GOVERNANCE.md

+### Reviewer
+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 an Contributor, plus:


Suggested change

Reviewers have all the rights and responsibilities of an Contributor, plus:

Reviewers have all the rights and responsibilities of a Contributor, plus:

danishprakash · 2025-03-07T05:38:26Z

GOVERNANCE.md

+    * Regular contribution of pull requests to the Podman project or its subprojects
+    * Triage of Github issues on the Podman project or its subprojects
+    * Regularly fixing Github issues on the Podman project or its subprojects
+    * Following the reviewing guide


Can we link to the guideline if there is one?

danishprakash · 2025-03-07T05:40:02Z

GOVERNANCE.md

+#### The process of becoming a Reviewer is:
+1. The contributor must be sponsored by a Maintainer. That sponsor will open a PR against the appropriate repository, which adds the contributor to the MAINTAINERS.md file as a reviewer.
+2. The contributor will add a comment to the pull request indicating their willingness to assume the responsibilities of a Reviewer.
+3. At least two members of the team that owns the repository in question, who are already Maintainers, must concur to merge the PR.


Suggested change

3. At least two members of the team that owns the repository in question, who are already Maintainers, must concur to merge the PR.

3. At least two team members that own the repository in question, who are already Maintainers, must concur to merge the PR.

danishprakash · 2025-03-07T05:40:54Z

GOVERNANCE.md

+3. At least two members of the team that owns the repository in question, who are already Maintainers, must concur to merge the PR.
+
+### Maintainer
+Description: Maintainers are very 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.


Suggested change

Description: Maintainers are very 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.

Description: Maintainers are very 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.

danishprakash · 2025-03-07T05:42:52Z

GOVERNANCE.md

+* Additional privileges:
+    * Represent the project in public as a senior project member
+    * Communicate with the CNCF on behalf of the project
+	* Have a voice, but not a vote, in Core Maintainer decision-making meetings


Suggested change

* Have a voice, but not a vote, in Core Maintainer decision-making meetings

* Have a voice, but not a vote, in Core Maintainer decision-making meetings

danishprakash · 2025-03-07T05:46:09Z

GOVERNANCE.md

+	* Communicate with the CNCF on behalf of the project
+	* Have a voice, but not a vote, in Core Maintainer decision-making meetings


Suggested change

* Communicate with the CNCF on behalf of the project

* Have a voice, but not a vote, in Core Maintainer decision-making meetings

* Communicate with the CNCF on behalf of the project

* Have a voice, but not a vote, in Core Maintainer decision-making meetings

packit-as-a-service · 2025-03-13T14:28:38Z

Ephemeral COPR build failed. @containers/packit-build please check.

lsm5 · 2025-03-13T14:39:54Z

REVIEWING.md

+This document contains general principles for how to perform code reviews in the Podman repository.
+It does not aim to be a complete guide to how to perform code review, but rather to provide general guidance on how code reviews should be performed.
+
+This document is aimed at Reviewers, Maintainers, and Core Maintainers (see [GOVERNANCE.md](./GOVERNANCE.md) for definitions of these roles), but these guidelines shpould be followed by all who wish to review code in the Podman project's Github repositories, even those who are not currently a maintainer.


Suggested change

This document is aimed at Reviewers, Maintainers, and Core Maintainers (see [GOVERNANCE.md](./GOVERNANCE.md) for definitions of these roles), but these guidelines shpould be followed by all who wish to review code in the Podman project's Github repositories, even those who are not currently a maintainer.

This document is aimed at Reviewers, Maintainers, and Core Maintainers (see [GOVERNANCE.md](./GOVERNANCE.md) for definitions of these roles), but these guidelines should be followed by all who wish to review code in the Podman project's Github repositories, even those who are not currently a maintainer.

lsm5 · 2025-03-13T14:41:17Z

REVIEWING.md

+If it is not one of those periods, reviewers should be on the lookout for breaking changes.
+PRs with breaking changes should not be merged.
+Please guide the contributor in how to make the change in a non-breaking fashion.
+if this is not possible, deferring the PR to the next breaking change window or closing it entirely is appropriate.


Suggested change

if this is not possible, deferring the PR to the next breaking change window or closing it entirely is appropriate.

If this is not possible, deferring the PR to the next breaking change window or closing it entirely is appropriate.

lsm5 · 2025-03-13T14:42:32Z

REVIEWING.md

+For all branches except the main branch, this should always remain static.
+PRs into a non-main branch which change the supported Go version should be modified to not require such a change, or rejected if that is not possible.
+Changing supported Go version in the main branch is allowed, but not encouraged.
+Doing so will require significant discussion among maintainers, as it can effect on what distributions the main branch can be built.


Suggested change

Doing so will require significant discussion among maintainers, as it can effect on what distributions the main branch can be built.

Doing so will require significant discussion among maintainers, as it can affect on what distributions the main branch can be built.

lsm5 · 2025-03-13T14:43:46Z

REVIEWING.md

+
+Please avoid bikeshedding during reviews.
+
+Trivial changes that do not effect the ultimate functionality of the PR - for example, small grammer or phrasing changes in documentation, unnecessary renaming of variables - should not block merge of a PR.


Suggested change

Trivial changes that do not effect the ultimate functionality of the PR - for example, small grammer or phrasing changes in documentation, unnecessary renaming of variables - should not block merge of a PR.

Trivial changes that do not affect the ultimate functionality of the PR - for example, small grammar or phrasing changes in documentation, unnecessary renaming of variables - should not block merge of a PR.

lsm5 · 2025-03-13T14:51:01Z

REVIEWING.md

+It is acceptable to make such comments, but they should be marked as nice to have changes.
+
+Also, it should not have to be said, but please be polite during code reviews.
+The [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) applies to all reviewers, of course, but in order to encourage repeat contributions, reviewers should be polite and pleasant when performing reviews.


Politeness can be hard to judge given the same language is spoken differently around the world. Can we add assume good intent here? Also, if there's a recommended list of words to avoid that can be linked here, that'd be nice I guess.

ashley-cui · 2025-03-13T17:28:41Z

REVIEWING.md

+### Breaking Changes
+
+The Podman project aims to present a stable API for its users.
+Breaking changes to the project's Command Line Interfaces or public APIs (the Podman REST API) must only be made in approved breaking change releases - Podman 6.0, 7.0, etc.


I think pkg/bindings should be stable as well?

REVIEWING.md

castrojo · 2025-03-17T22:02:24Z

GOVERNANCE.md

+    * Advocates for the community in Maintainer and Core Maintainer meetings
+* Additional privileges:
+    * Represent the project in public
+    * Communicate with the CNCF on behalf of the project


Do you want just "Communicate" with the CNCF or do you want the ability to represent on behalf of the project?

For example do you want this person to be able to ask for resources, do event coordination with us, submit maintainer CFPs, be able to file support tickets on behalf of other maintainers, access to #maintainers-circle, etc.

If so I'd strengthen this a tad so we know to give them the proper rights.

I was aiming for the same rights as maintainers, so I'll use the same wording we use for them. Good catch.

REVIEWING.md

flouthoc

One nit above but LGTM

mtrmac

LGTM — I think the discussions/reviews to date have covered a lot and resulted in a pretty polished document.

(Also, I generally think that over longer periods, there’s a reasonably high likelihood of something unexpected happening no matter what we do [e.g. who could have predicted the CNCF donation?], so I’m not that worried about making the governance rules bulletproof.)

mtrmac · 2025-03-21T19:12:40Z

GOVERNANCE.md

+Each of the project member roles below is organized into lists of three types of things.
+
+* "Responsibilities" – functions of a member
+* "Requirements" –  qualifications of a member
+* "Privileges" –  entitlements of member


Non-blocking, non-substantive:

Consider moving this to a comment. Reading this document, I emotionally feel that starting with a “terminology” section, the way some laws do, says “this was written by a bureaucracy for a bureaucracy, expect the processes to be painfully formalistic”.

I do agree that having some common structure to the ladder entries is useful, but maybe that structure can be understood well enough from context when reading the actual entries.

[I’m even wondering about not describing the ladder at all, but that’s really just a question, not even a weak preference.]

(This is exacerbated in that I’m also wondering what “responsibilities” are; starting with a terminology section I don’t immediately understand worries me. The “responsibilities” are not requirements / expectations, that’s a different section. But then again, the first example says “follow the CNCF CoC”, which is probably a hard requirement. And in the other ladder entries, they are closer to “privileges”. Is it that “requirements are how we quantify responsibilities”? Are “responsibilities” closer to ”typical kinds of contribution”? OTOH sometimes they imply specific access rights on the project.

Maybe the “follow CoC”, part which is already in the paragraph above, can be removed from the “contributor” ladder entry, and then s/Responsibilities/Typical activities/?

Ultimately all of this matters very little.)

mtrmac · 2025-03-21T19:46:28Z

REVIEWING.md

+Some changes are OK to ask for - for example, asking a contributor to refactor existing code very similar to something being added to prevent code duplication.
+However, larger changes that would substantially increase the size of the PR should be avoided.
+Reviewers should use their best judgement to balance respect for the contributor's time and the code hygiene of the project.
+If a change is too large to be reasonably asked for, consider asking the contributor to add a comment with a "TODO" or "FIXME" to the area that needs changing (or making a PR yourself with such a comment).


I’m leaning a bit more towards the “let the PR contributor do all the work” side, at least in the sense that letting a drive-by contributor add a badly-structured workaround or a kludgy minimal implementation of a feature, “succeed”, and disappear, even if accompanied by a FIXME documenting this, is not a good trade for the long-term maintainability of the project.

The only tools to manage maintainer overload we have is:

finding new contributors, and

backpressure: not encouraging/accepting contributions that increase maintainer overload.

And there’s a trade-off between being welcoming and encouraging to new long-term contributors, vs. discouraging drive-by tech debt additions, and it’s hard to tell in advance which one we are dealing with.

Ultimately, I don’t have any specific wording suggestions, no objections to “best judgement” — and, anyway, this PR already includes a process to resolve disagreements between reviewers/maintainers.

E.g. researching a situation, documenting it, and adding a FIXME, without actually fixing it, can certainly be a valuable contribution alone.

Adding a hack that works 40% of the time, and a FIXME to turn that into a production feature, maybe not?

One example that I think happens somewhat regularly, incl. by regular contributors, is adding a Podman feature which doesn’t work podman-remote: just not doing the HTTP work when it is clearly possible, or, in situations where it’s unclear whether it is possible or where it seems difficult, not arriving at a plan and merging the local-only feature anyway.

I think the past practice for this has been “use best judgement”, and that’s fine. Just something to point at / think about.

My basic intent here was to discourage asking drive-by contributors to refactor massive sizable amounts of the program (that they likely have no direct knowledge of) to improve our tech-debt situation. That kind of thing is definitely valuable, but should be done by actual maintainers or willing volunteers; we shouldn't be asking someone trying to submit a trivial patch to do it.

On the other hand, the points you make are quite valid. We should have the ability to reject contributions on grounds they will introduce excessive complexity or tech debt, and asking for a refactor of that is quite fine.

I'll try and think of a better way to phrase this. One thing I might include is that maintainers should be held to a higher standard - I'm a lot more forgiving of asking someone deeply familiar with the project to refactor than I am a drive-by contributor, and I don't think that's controversial.

discourage asking drive-by contributors to refactor massive amounts of the program

Agreed.

Overall I think we are on the same page, and I can’t think of any obvious wording improvement — so maybe it’s not worth spending a lot of effort trying to polish this to perfection. “There are tradeoffs, they are not 100% clear-cut, just be aware of the principal concerns.” is fine.

mheon · 2025-03-25T15:44:05Z

Waiting on two further LGTMs: @nalind and @baude

mheon · 2025-03-27T19:34:10Z

Applying a hold for the moment for potential edits

packit-as-a-service · 2025-04-01T11:59:02Z

[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore.

nalind

LGTM, give or take a tab/space indentation and reconciling a discrepancy between the updated OWNERS and MAINTAINERS.md files.

OWNERS

GOVERNANCE.md

openshift-ci · 2025-04-02T17:56:48Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: flouthoc, giuseppe, Luap99, mheon, nalind

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~OWNERS~~ [Luap99,giuseppe,mheon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

mheon · 2025-04-02T18:00:07Z

/hold cancel

baude · 2025-04-02T18:03:30Z

all core-maintainers have given LGTM

/lgtm

This is the initial version of the governance model we're looking to implement. It is still very early, and comments and suggestions are very welcome! Signed-off-by: Matt Heon <mheon@redhat.com>

baude · 2025-04-02T18:27:24Z

/lgtm

openshift-ci bot added release-note-none do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Feb 25, 2025

baude reviewed Feb 25, 2025

View reviewed changes

GOVERNANCE.md Outdated Show resolved Hide resolved

Luap99 reviewed Feb 26, 2025

View reviewed changes

mheon force-pushed the add_governance branch from 51408e0 to 027818e Compare February 26, 2025 21:25

Luap99 reviewed Feb 27, 2025

View reviewed changes

mheon added the No New Tests Allow PR to proceed without adding regression tests label Mar 4, 2025

mheon force-pushed the add_governance branch 2 times, most recently from 4599a02 to 6da0973 Compare March 4, 2025 20:01

jakecorrenti reviewed Mar 6, 2025

View reviewed changes

mheon force-pushed the add_governance branch from 6da0973 to d7d744f Compare March 6, 2025 19:26

danishprakash reviewed Mar 7, 2025

View reviewed changes

mheon force-pushed the add_governance branch from d7d744f to 59af877 Compare March 13, 2025 14:23

lsm5 reviewed Mar 13, 2025

View reviewed changes

mheon force-pushed the add_governance branch from 59af877 to 14dd3f3 Compare March 13, 2025 14:53

ashley-cui reviewed Mar 13, 2025

View reviewed changes

mheon force-pushed the add_governance branch 2 times, most recently from ad2c0c7 to a02a09a Compare March 14, 2025 18:01

Honny1 reviewed Mar 17, 2025

View reviewed changes

REVIEWING.md Show resolved Hide resolved

castrojo reviewed Mar 17, 2025

View reviewed changes

Luap99 reviewed Mar 18, 2025

View reviewed changes

REVIEWING.md Show resolved Hide resolved

REVIEWING.md Show resolved Hide resolved

REVIEWING.md Show resolved Hide resolved

flouthoc approved these changes Mar 21, 2025

View reviewed changes

mheon force-pushed the add_governance branch 2 times, most recently from 3ac7887 to 5d4656b Compare March 21, 2025 15:47

mtrmac reviewed Mar 21, 2025

View reviewed changes

mheon force-pushed the add_governance branch from 6c5fe7a to 0aa3184 Compare March 25, 2025 01:19

mheon force-pushed the add_governance branch from 0aa3184 to 0273ab3 Compare March 27, 2025 19:23

mheon added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Mar 27, 2025

mheon force-pushed the add_governance branch from 0273ab3 to b89b85c Compare March 27, 2025 19:34

Luap99 mentioned this pull request Mar 31, 2025

CNI Deprecation is a Bad Decision – Request to Retain Support #25730

Closed

mheon force-pushed the add_governance branch from b89b85c to f8f9d05 Compare April 1, 2025 11:53

mheon force-pushed the add_governance branch from f8f9d05 to 4e86f31 Compare April 2, 2025 13:49

nalind approved these changes Apr 2, 2025

View reviewed changes

OWNERS Outdated Show resolved Hide resolved

GOVERNANCE.md Outdated Show resolved Hide resolved

GOVERNANCE.md Outdated Show resolved Hide resolved

mheon force-pushed the add_governance branch from 4e86f31 to 1628c05 Compare April 2, 2025 17:59

openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Apr 2, 2025

openshift-ci bot assigned baude Apr 2, 2025

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Apr 2, 2025

Add initial draft of Podman project Governance

f1f8432

This is the initial version of the governance model we're looking to implement. It is still very early, and comments and suggestions are very welcome! Signed-off-by: Matt Heon <mheon@redhat.com>

mheon force-pushed the add_governance branch from 1628c05 to f1f8432 Compare April 2, 2025 18:04

openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Apr 2, 2025

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Apr 2, 2025

openshift-merge-bot bot merged commit d04783a into containers:main Apr 2, 2025
34 of 35 checks passed

stale-locking-app bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Jul 2, 2025

stale-locking-app bot locked as resolved and limited conversation to collaborators Jul 2, 2025


		## Maintainers

		\| Maintainer \| GitHub ID \| Project Roles \| Affiliation \|


		## Contributor Ladder

		Hello! We are excited that you want to learn more about our project contributor ladder! This contributor ladder outlines the different contributor roles within the project, along with the responsibilities and privileges that come with them. Community members generally start at the first levels of the "ladder" and advance up it 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).

	Reviewers have all the rights and responsibilities of an Contributor, plus:
	Reviewers have all the rights and responsibilities of a Contributor, plus:

	3. At least two members of the team that owns the repository in question, who are already Maintainers, must concur to merge the PR.
	3. At least two team members that own the repository in question, who are already Maintainers, must concur to merge the PR.

	* Have a voice, but not a vote, in Core Maintainer decision-making meetings
	* Have a voice, but not a vote, in Core Maintainer decision-making meetings

		* Communicate with the CNCF on behalf of the project
		* Have a voice, but not a vote, in Core Maintainer decision-making meetings

	This document is aimed at Reviewers, Maintainers, and Core Maintainers (see [GOVERNANCE.md](./GOVERNANCE.md) for definitions of these roles), but these guidelines shpould be followed by all who wish to review code in the Podman project's Github repositories, even those who are not currently a maintainer.
	This document is aimed at Reviewers, Maintainers, and Core Maintainers (see [GOVERNANCE.md](./GOVERNANCE.md) for definitions of these roles), but these guidelines should be followed by all who wish to review code in the Podman project's Github repositories, even those who are not currently a maintainer.

	if this is not possible, deferring the PR to the next breaking change window or closing it entirely is appropriate.
	If this is not possible, deferring the PR to the next breaking change window or closing it entirely is appropriate.

	Doing so will require significant discussion among maintainers, as it can effect on what distributions the main branch can be built.
	Doing so will require significant discussion among maintainers, as it can affect on what distributions the main branch can be built.


		Please avoid bikeshedding during reviews.

		Trivial changes that do not effect the ultimate functionality of the PR - for example, small grammer or phrasing changes in documentation, unnecessary renaming of variables - should not block merge of a PR.

	Trivial changes that do not effect the ultimate functionality of the PR - for example, small grammer or phrasing changes in documentation, unnecessary renaming of variables - should not block merge of a PR.
	Trivial changes that do not affect the ultimate functionality of the PR - for example, small grammar or phrasing changes in documentation, unnecessary renaming of variables - should not block merge of a PR.

Add initial draft of Podman project Governance #25398

Add initial draft of Podman project Governance #25398

Uh oh!

Conversation

mheon commented Feb 25, 2025

Does this PR introduce a user-facing change?

Uh oh!

Uh oh!

Luap99 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mheon commented Mar 4, 2025

Uh oh!

mheon commented Mar 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

packit-as-a-service bot commented Mar 6, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

packit-as-a-service bot commented Mar 13, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mtrmac Mar 21, 2025 •

edited

Loading