github/kured
1
0
Fork 0
mirror of https://github.com/kubereboot/kured.git synced 2026-08-23 21:36:33 +00:00
Code Issues Packages Projects Releases Wiki Activity

make the governance ours

Browse Source 
- update obvious pieces: project name, mailing list, etc.
- use GH issues for public voting

Signed-off-by: Daniel Holbach <daniel@weave.works>
This commit is contained in:
Daniel Holbach
2022-11-15 08:41:56 +01:00
parent ae29a90f43
commit 72c234e470
1 changed files with 46 additions and 74 deletions
Download Patch File Download Diff File Expand all files Collapse all files
GOVERNANCE.md
+46 -74
View File
@@ -1,65 +1,47 @@
# Project Governance
This is an example governance document for projects that use the very common
"maintainer council" system of governance. See [GOVERNANCE.md](/GOVERNANCE.md)
for more information. Thanks to the Jaeger Project for portions of the text
below.
This is a template document for CNCF projects that requires editing
before it is ready to use. Read the markdown comments, `<!-- COMMENT -->`, for
additional guidance. The raw markdown uses `TODO` to identify areas that
require customization. Replace [TODO: PROJECTNAME] with the name of your project.
- [Values](#values)
- [Maintainers](#maintainers)
- [Becoming a Maintainer](#becoming-a-maintainer)
- [Meetings](#meetings)
- [CNCF Resources](#cncf-resources)
- [Code of Conduct Enforcement](#code-of-conduct)
- [Voting](#voting)
## Values
<!-- This is where you put the core values or principles of your project, like
openness, distributed design, fairness, diversity, etc.
The Kured project and its leadership embrace the following values:
References and Examples
* https://www.apache.org/theapacheway/
* https://kubernetes.io/community/values/
See https://contribute.cncf.io/maintainers/governance/charter for guidance and
additional examples. The values below are just example values as a jumping-off
point for your project's actual values. -->
The [TODO: PROJECTNAME] and its leadership embrace the following values:
* Openness: Communication and decision-making happens in the open and is discoverable for future
- Openness: Communication and decision-making happens in the open and is discoverable for future
reference. As much as possible, all discussions and work take place in public
forums and open repositories.
* Fairness: All stakeholders have the opportunity to provide feedback and submit
- Fairness: All stakeholders have the opportunity to provide feedback and submit
contributions, which will be considered on their merits.
* Community over Product or Company: Sustaining and growing our community takes
- Community over Product or Company: Sustaining and growing our community takes
priority over shipping code or sponsors' organizational goals. Each
contributor participates in the project as an individual.
* Inclusivity: We innovate through different perspectives and skill sets, which
- Inclusivity: We innovate through different perspectives and skill sets, which
can only be accomplished in a welcoming and respectful environment.
* Participation: Responsibilities within the project are earned through
- Participation: Responsibilities within the project are earned through
participation, and there is a clear path up the contributor ladder into leadership
positions.
- Consensus: Whether or not wider input is required, the Kured community believes that
the best decisions are reached through Consensus
<https://en.wikipedia.org/wiki/Consensus_decision-making>.
## Maintainers
[TODO: PROJECTNAME] Maintainers have write access to the [project GitHub repository](TODO).
They can merge their own patches or patches from others. The current maintainers
can be found in [OWNERS](./OWNERS). Maintainers collectively manage the project's
resources and contributors.
Kured Maintainers have write access to the [project GitHub
organisation](https://github.com/kubereboot). They can merge their own patches or patches
from others. The current maintainers can be found in [MAINTAINERS][maintainers-file].
Maintainers collectively manage the project's resources and contributors.
This privilege is granted with some expectation of responsibility: maintainers
are people who care about the [TODO: PROJECTNAME] project and want to help it grow and
are people who care about the Kured project and want to help it grow and
improve. A maintainer is not just someone who can make changes, but someone who
has demonstrated their ability to collaborate with the team, get the most
knowledgeable people to review code and docs, contribute high-quality code, and
@@ -70,35 +52,33 @@ the project succeed.
## Becoming a Maintainer
<!-- If you have full Contributor Ladder documentation that covers becoming
a Maintainer or Owner, then this section should instead be a reference to that
documentation -->
To become a Maintainer you need to demonstrate the following:
* commitment to the project:
* participate in discussions, contributions, code and documentation reviews
for [TODO: Time Period] or more,
* perform reviews for [TODO:Number] non-trivial pull requests,
* contribute [TODO:Number] 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.
<!-- add any additional Maintainer requirements here -->
- commitment to the project:
- participate in discussions, contributions, code and documentation reviews
for 3 months or more and participate in Slack discussions and meetings
if possible,
- perform reviews for 5 non-trivial pull requests,
- contribute 5 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.
A new Maintainer must be proposed by an existing maintainer by sending a message to the
[developer mailing list](TODO: List Link). A simple majority vote of existing Maintainers
We realise that everybody brings different abilities and qualities to the team, that's
why we are willing to change the rules somewhat depending on the circumstances.
A new Maintainer can apply by proposing a PR to the [MAINTAINERS
file][maintainers-file]. A simple majority vote of existing Maintainers
approves the application.
Maintainers who are selected will be granted the necessary GitHub rights,
and invited to the [private maintainer mailing list](TODO).
and invited to the [private maintainer mailing list][private-list].
## Meetings
Time zones permitting, Maintainers are expected to participate in the public
developer meeting, which occurs
[TODO: Details of regular developer or maintainer meeting here].
developer meeting, details can be found [here][meeting-agenda].
Maintainers will also have closed meetings in order to discuss security reports
or Code of Conduct violations. Such meetings should be scheduled by any
@@ -106,35 +86,27 @@ Maintainer on receipt of a security issue or CoC report. All current Maintainer
must be invited to such closed meetings, except for any Maintainer who is
accused of a CoC violation.
## CNCF Resources
Any Maintainer may suggest a request for CNCF resources, either in the
[mailing list](TODO: link to developer/maintainer mailing list), or during a
meeting. A simple majority of Maintainers approves the request. The Maintainers
may also choose to delegate working with the CNCF to non-Maintainer community
members.
## Code of Conduct
<!-- This assumes that your project does not have a separate Code of Conduct
Committee; most maintainer-run projects do not. Remember to place a link
to the private Maintainer mailing list or alias in the code-of-conduct file.-->
[Code of Conduct](./code-of-conduct.md)
violations by community members will be discussed and resolved
on the [private Maintainer mailing list](TODO). If the reported CoC violator
is a Maintainer, the Maintainers will instead designate two Maintainers to work
with CNCF staff in resolving the report.
[Code of Conduct](./CODE_OF_CONDUCT.md) violations by community members will
be discussed and resolved on the [private Maintainer mailing list][private-list].
If the reported CoC violator is a Maintainer, the Maintainers will instead
designate two Maintainers to work with CNCF staff in resolving the report.
## Voting
While most business in [TODO: PROJECTNAME] is conducted by "lazy consensus", periodically
While most business in Kured is conducted by "lazy consensus", periodically
the Maintainers may need to vote on specific actions or changes.
A vote can be taken on [the developer mailing list](TODO) or
[the private Maintainer mailing list](TODO) for security or conduct matters.
Votes may also be taken at [the developer meeting](TODO). Any Maintainer may
demand a vote be taken.
A vote can be taken in [kured issues labeled 'decision'][decision-issues] or
[the private Maintainer mailing list][private-list] for security or conduct
matters. Votes may also be taken at [the developer meeting][meeting-agenda].
Any Maintainer may demand a vote be taken.
Most votes require a simple majority of all Maintainers to succeed. Maintainers
can be removed by a 2/3 majority vote of all Maintainers, and changes to this
Governance require a 2/3 vote of all Maintainers.
[maintainers-file]: ./MAINTAINERS
[private-list]: cncf-kured-maintainers@lists.cncf.io
[meeting-agenda]: https://docs.google.com/document/d/1bsHTjHhqaaZ7yJnXF6W8c89UB_yn-OoSZEmDnIP34n8/edit#
[decision-issues]: https://github.com/kubereboot/kured/labels/decision