Skip to content
Open
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
29 changes: 29 additions & 0 deletions GOVERNANCE.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,7 @@ The Bootc project is dedicated to providing transactional, in-place operating sy
This governance explains how the project is run.

- [Values](#values)
- [Project Contributors](#project-contributors)
- [Maintainers](#maintainers)
- [Becoming a Maintainer](#becoming-a-maintainer)
- [Meetings](#meetings)
Expand Down Expand Up @@ -35,6 +36,33 @@ The Bootc and its leadership embrace the following values:
participation, and there is a clear path up the contributor ladder into leadership
positions.

## Project Contributors

Project Contributors are active, trusted members of the bootc community who contribute code, documentation, issue triaging, or community support. The current contributors are all [members of the bootc-dev organization](https://github.com/orgs/bootc-dev/people) here on GitHub.

This role is granted to community members who participate regularly in the project. Project Contributors are expected to act in the best interest of the project, follow the Code of Conduct, and help the community by reviewing pull requests, triaging issues, and helping users. In return, they get recognition as official members of the bootc project.

### Becoming a Project Contributor

To become a Project Contributor you need to demonstrate the following:

* active participation in the project for 2 months or more,
* multiple non-trivial contributions (code commits, documentation improvements, issue triaging, or helping users in discussion forums),
* ability to collaborate with the team,
* understanding of how the team works (policies, processes for testing and code review, etc).

A new Project Contributor can be proposed by an existing Maintainer or by the candidate themselves by opening a PR against [MAINTAINERS.md](./MAINTAINERS.md). The nomination will be approved via lazy consensus or a simple majority vote of the Maintainers.

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.

Suggested change
A new Project Contributor can be proposed by an existing Maintainer or by the candidate themselves by opening a PR against [MAINTAINERS.md](./MAINTAINERS.md). The nomination will be approved via lazy consensus or a simple majority vote of the Maintainers.
A new Project Contributor can be proposed by an existing Maintainer or by the candidate themselves by [opening an issue in the community repo](https://github.com/bootc-dev/community/issues/new/choose). After detailing their activity that meets the criteria above, two or more Maintainers who have worked with the candidate on the project in the named activities must sponsor the candidate by commenting on the issue. Then the new contributor can be added to the org and welcomed on the issue before closing it as completed.

Not sure I exactly like this wording, but this is the vague version. There's a number of examples I linked to in the other comment if you want to reword this :)

@hone hone Jul 1, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

@nimbinatus what's interesting here is contributors have a lower criteria bar, but there's a requirement that a candidate has to show their activity which is not true for maintainers.


Project Contributors who are approved will be invited to the bootc GitHub organization and granted Triage permissions on the project repositories.

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.

This is a pretty low permission level. I'd personally like to add a finer grain here in the future; like one thing I can imagine here is for "low risk PRs" a project contributor could approve/merge too e.g.

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.

(Nonblocking for here, just brainstorming)

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

How do you determine if something is "low risk"? Is it just a "trust" thing?

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.

I'm kind of just making things up here but I think it's a combination of basic things like CODEOWNERS plus LLM risk analysis

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.

Or to say it a different way, I would personally like to also require "large" PRs to be reviewed by two maintainers say (or at least 1 maintainer and 1 contributor) etc.


### Removing a Project Contributor

Project Contributors may resign at any time if they feel that they will not be able to continue fulfilling their duties.

Contributors may also be removed after being inactive, failure to fulfill their responsibilities, violating the Code of Conduct, or other reasons. Inactivity is defined as a period of very low or no activity in the project for a year or more.

A Project Contributor may be removed at any time by a 2/3 vote of the Maintainers.

## Maintainers

Bootc Maintainers have "gated" write access to the [project GitHub repository](https://github.com/bootc-dev/bootc).
Expand Down Expand Up @@ -63,6 +91,7 @@ is the governing body for the project.

To become a Maintainer you need to demonstrate the following:

* active status as a Project Contributor (typically for at least 3 months),
* 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,
Expand Down