Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
88 changes: 73 additions & 15 deletions GOVERNANCE.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,9 @@ This governance explains how the project is run.
- [Values](#values)
- [Maintainers](#maintainers)
- [Becoming a Maintainer](#becoming-a-maintainer)
- [Members](#members)
- [Reviewers](#reviewers)
- [Committers](#committers)
- [Meetings](#meetings)
- [CNCF Resources](#cncf-resources)
- [Code of Conduct Enforcement](#code-of-conduct)
Expand Down Expand Up @@ -37,7 +40,10 @@ The Bootc and its leadership embrace the following values:

## Maintainers

Bootc Maintainers have "gated" write access to the [project GitHub repository](https://github.com/bootc-dev/bootc).
There are different levels of maintainership in the Bootc project, each with
different responsibilities and expectations. The contributor ladder is:
[Members](#members), [Reviewers](#reviewers), and [Committers](#committers).

The current maintainers can be found in [MAINTAINERS.md](./MAINTAINERS.md).

Direct pushes to the code is never allowed. All pull requests require review by a maintainer
Expand All @@ -56,25 +62,28 @@ follow through to fix issues (in code or tests).
A maintainer is a contributor to the project's success and a citizen helping
the project succeed.

The collective team of all Maintainers is known as the Maintainer Council, which
The collective team of all Committers is known as the Maintainer Council, which
is the governing body for the project.

### Becoming a Maintainer

To become a Maintainer you need to demonstrate the following:
The path to maintainership follows the contributor ladder:

* commitment to the project:
* participate in discussions, contributions, code and documentation reviews for 6 months or more,
* perform reviews for 20 non-trivial pull requests,
* contribute 10 non-trivial pull requests and have them merged,
* ability to write quality code and/or documentation,
* ability to collaborate with the team,
* understanding of how the team works (policies, processes for testing and code review, etc),
* understanding of the project's code base and coding and documentation style.
* **Member**: Sponsored by a reviewer or committer. Approval requires a
simple majority of current committers.
* **Reviewer**: Proposed by an existing maintainer. Approval requires a
simple majority of current committers.
* **Committer**: Proposed by an existing maintainer. Approval requires a
simple majority of current committers.

See the [Members](#members), [Reviewers](#reviewers), and
[Committers](#committers) sections for specific requirements and
responsibilities of each role.

A new Maintainer must be proposed by an existing maintainer by opening a PR against the [MAINTAINERS.md](./MAINTAINERS.md), which will prompt a [gitvote](https://github.com/cncf/gitvote). A simple majority vote of existing Maintainers
approves the application. Maintainers nominations will be evaluated without prejudice
to employer or demographics.
A new maintainer must be proposed by opening a PR against the
[MAINTAINERS.md](./MAINTAINERS.md), which will prompt a
[gitvote](https://github.com/cncf/gitvote). Maintainer nominations will be
evaluated without prejudice to employer or demographics.

Maintainers who are selected will be granted the necessary GitHub rights.

Expand All @@ -89,13 +98,62 @@ Inactivity is defined as a period of very low or no activity in the project
for a year or more, with no definite schedule to return to full Maintainer
activity.

A Maintainer may be removed at any time by a 2/3 vote of the remaining maintainers.
A Maintainer may be removed at any time by a 2/3 vote of the remaining committers.

Depending on the reason for removal, a Maintainer may be converted to Emeritus
status. Emeritus Maintainers will still be consulted on some project matters,
and can be rapidly returned to Maintainer status if their availability changes.
This requires two votes from active maintainers.

## Members

A member is an active participant in the community who has shown consistent
involvement in the project. Members attend community meetings, help answer
questions in discussion forums, assist with issue triage, help organize events
or community activities, and contribute to the overall health of the project.

Members are part of the organization but do not have write access or code
review responsibilities. Membership recognizes sustained community engagement
and is the first step on the contributor ladder. Members are not required to
have made code contributions, though they may have. Becoming a member is a
core aspect in the journey to becoming a reviewer.

A new member must be sponsored by an existing reviewer or committer. The
sponsor will open a pull request to the [MAINTAINERS.md](./MAINTAINERS.md)
file adding the candidate. Approval requires a simple majority of current
committers.

## Reviewers

A reviewer is a core maintainer within the project. They share in reviewing
issues and pull requests, and their LGTM counts towards the required LGTM count
to merge a code change into the project.

Reviewers are part of the organization but do not have write access. Becoming a

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is "write" access equivalent to the Github default? As is today "write" implies the ability to e.g. add labels, close issues etc.

Some custom work will be necessary to implement this "can review but almost nothing else" flow. It also feels weird if they can review and hence merge code but not manage issues.

It seems a lot simpler to not create that distinction unless we say a Reviewer can approve a PR from a maintainer, but not an arbitrary other one. That would itself require some custom logic, but makes a bit more sense to me?


Well, I guess this came from containerd, we should try to see how they implement this

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The agent thinks we can do something like:

- Create two GitHub teams in the bootc-dev org: e.g. committers and reviewers
- Give both teams Write access to repos
- Enable branch protection on main with "Restrict who can push to matching branches" and only add the committers team
- Reviewers can approve PRs and their approval satisfies the "required approvals" check, but only Committers can click merge / add to merge queue

But I need to check this on my own org/repos.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

containerd also uses kubernetes-prow so that might be doing some of the heavy lifting too.

reviewer is a core aspect in the journey to becoming a committer.

## Committers

A committer is a core maintainer who is responsible for the overall quality and
stewardship of the project. They share the same reviewing responsibilities as
reviewers, but are also responsible for upholding the project bylaws as well as
participating in project level votes.

Committers are part of the organization with write access to all repositories.
Committers are expected to remain actively involved in the project and
participate in voting and discussing of proposed project level changes.

To become a Committer you need to demonstrate the following:

* commitment to the project:
* participate in discussions, contributions, code and documentation reviews for 6 months or more,
* perform reviews for 20 non-trivial pull requests,
* contribute 10 non-trivial pull requests and have them merged,
* ability to write quality code and/or documentation,
* ability to collaborate with the team,
* understanding of how the team works (policies, processes for testing and code review, etc),
* understanding of the project's code base and coding and documentation style.

## Meetings

Time zones permitting, Maintainers are expected to participate in the public
Expand Down
31 changes: 22 additions & 9 deletions MAINTAINERS.md
Original file line number Diff line number Diff line change
@@ -1,15 +1,28 @@
# Maintainers

The current Maintainers Group for the bootc Project consists of:
See [GOVERNANCE.md](./GOVERNANCE.md) for a description of the Member, Reviewer
and Committer roles.

| Name | GitHub ID | Employer | Responsibilities |
| ---- | ---- | ---- | ---- |
| Chris Kyrouac | [ckyrouac](https://github.com/orgs/bootc-dev/people/ckyrouac) | Red Hat | Approver |
| Colin Walters | [cgwalters](https://github.com/orgs/bootc-dev/people/cgwalters) | Red Hat | Approver |
| John Eckersberg | [jeckersb](https://github.com/orgs/bootc-dev/people/jeckersb) | Red Hat | Approver |
| Xiaofeng Wang | [henrywang](https://github.com/orgs/bootc-dev/people/henrywang) | Red Hat | Approver |
| Gursewak Mangat | [gursewak1997](https://github.com/orgs/bootc-dev/people/gursewak1997)| Red Hat | Approver |
| Joseph Marrero | [jmarrero](https://github.com/orgs/bootc-dev/people/jmarrero) | Red Hat | Approver |
## Committers

| Name | GitHub ID | Employer |
| ---- | ---- | ---- |
| Chris Kyrouac | [ckyrouac](https://github.com/orgs/bootc-dev/people/ckyrouac) | Red Hat |
| Colin Walters | [cgwalters](https://github.com/orgs/bootc-dev/people/cgwalters) | Red Hat |
| John Eckersberg | [jeckersb](https://github.com/orgs/bootc-dev/people/jeckersb) | Red Hat |
| Xiaofeng Wang | [henrywang](https://github.com/orgs/bootc-dev/people/henrywang) | Red Hat |
| Gursewak Mangat | [gursewak1997](https://github.com/orgs/bootc-dev/people/gursewak1997)| Red Hat |
| Joseph Marrero | [jmarrero](https://github.com/orgs/bootc-dev/people/jmarrero) | Red Hat |

## Reviewers

| Name | GitHub ID | Employer |
| ---- | ---- | ---- |

## Members

| Name | GitHub ID | Employer |
| ---- | ---- | ---- |

# Community Managers

Expand Down