[WIP] Add initial draft of Podman project Governance #25398
Conversation
openshift-ci
bot
added
release-note-none
do-not-merge/work-in-progress
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mheon 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:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
There was a problem hiding this comment.
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
|
|
||
| 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. |
There was a problem hiding this comment.
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.
GOVERNANCE.md
Outdated
|
|
||
| ## Contact | ||
| * For inquiries, please reach out to: | ||
| * Tom Sweeney, Community Manager |
There was a problem hiding this comment.
might as well add the email address here so people don't have to look up contact info elsewhere
GOVERNANCE.md
Outdated
| * 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Github's "approve" functionality, and/or the /approve function in the bot
mheon
force-pushed
the
add_governance
branch
from
51408e0 to
027818e
Compare
MAINTAINERS.md
Outdated
|
|
||
| ## Maintainers | ||
|
|
||
| | Maintainer | GitHub ID | Project Roles | Affiliation | |
There was a problem hiding this comment.
table seems broken, it is not rendered correctly on github
https://github.com/containers/podman/blob/027818e4e4a610f6587d70fceadc86135aec8750/MAINTAINERS.md
MAINTAINERS.md
Outdated
| | 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/) | |
There was a problem hiding this comment.
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?
MAINTAINERS.md
Outdated
| | 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/) | |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Updated to make Community Manager a separate role.
|
I'm going to push another draft this afternoon which includes changes to the Community Manager role to separate it from maintainer. |
mheon
force-pushed
the
add_governance
branch
2 times, most recently
from
4599a02 to
6da0973
Compare
|
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. |
MAINTAINERS.md
Outdated
| |-------------------|----------------------------------------------------------|----------------------------------|-------------------------------------------| | ||
| | 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/) | |
There was a problem hiding this comment.
The Red Hat GH link here is some random user. The proper link is https://github.com/RedHatOfficial
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 <[email protected]>
|
Cockpit tests failed for commit d7d744f. @martinpitt, @jelly, @mvollmer please check. |
|
|
||
| ## 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). |
There was a problem hiding this comment.
| 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). |
| ### 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: |
There was a problem hiding this comment.
| Reviewers have all the rights and responsibilities of an Contributor, plus: | |
| Reviewers have all the rights and responsibilities of a Contributor, plus: |
| * 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 |
There was a problem hiding this comment.
Can we link to the guideline if there is one?
| #### 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. |
There was a problem hiding this comment.
| 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. |
| 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. |
There was a problem hiding this comment.
| 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. |
| * 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 |
There was a problem hiding this comment.
| * 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 |
There was a problem hiding this comment.
| * 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 |
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?