-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
create GOVERNANCE.md default for all repos
Signed-off-by: axel simon <[email protected]>
- Loading branch information
Showing
1 changed file
with
137 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,137 @@ | ||
| # Keylime Governance | ||
|
|
||
| ## Principles | ||
|
|
||
| The Keylime community adheres to the following principles: | ||
|
|
||
| - Open: Keylime is open source. | ||
| - Welcoming and respectful: See [Code of Conduct](CODE_OF_CONDUCT.md). | ||
| - Transparent and accessible: Changes to the Keylime organization, Keylime code repositories, and CNCF related activities (e.g. level, involvement, etc) are done in public. | ||
| - Merit: Ideas and contributions are accepted according to their technical merit and alignment with | ||
| project objectives, scope, and design principles. | ||
|
|
||
|
|
||
| ## Project Lead | ||
|
|
||
| The Keylime project has a project lead. | ||
|
|
||
| A project lead in Keylime is a single person that has a final say in any decision | ||
| concerning the Keylime project. | ||
|
|
||
| The term of the project lead is one year, with no term limit restriction. | ||
|
|
||
| The project lead is elected by Keylime maintainers. | ||
|
|
||
| The current project lead is identified in the [MAINTAINERS.md](https://github.com/keylime/keylime/MAINTAINERS.md) file with the string | ||
| `project lead` and the term behind the name in a comment at the top of the file. | ||
|
|
||
| ## Expectations from Maintainers | ||
|
|
||
| _Every one carries water…_ | ||
|
|
||
| Making a community work requires input/effort from everyone. Maintainers should actively | ||
| participate in Pull Request reviews. Maintainers are expected to respond to assigned Pull Requests | ||
| in a *reasonable* time frame, either providing insights, or assign the Pull Requests to other | ||
| maintainers. | ||
|
|
||
| Every Maintainer is listed in the [MAINTAINERS.md](https://github.com/keylime/keylime/MAINTAINERS.md) file, with their | ||
| Github handle. | ||
|
|
||
| A Maintainer should be active within the CNCF slack [#keylime | ||
| channel](https://cloud-native.slack.com/archives/C01ARE2QUTZ) | ||
|
|
||
| ## Becoming a Maintainer | ||
|
|
||
| On successful merge of a significant pull request any current maintainer can reach | ||
| to the author behind the pull request and ask them if they are willing to become a Keylime | ||
| maintainer. The email of the new maintainer invitation should be cc'ed to `[email protected]` | ||
| as part of the process. | ||
|
|
||
| ## Changes in Maintainership | ||
|
|
||
| If a Maintainer feels she or he can not fulfill the "Expectations from Maintainers", they are free to | ||
| step down. | ||
|
|
||
| The Keylime organization will never forcefully remove a current Maintainer, unless a maintainer | ||
| fails to meet the principles of Keylime community, | ||
| or adhere to the [Code of Conduct](CODE_OF_CONDUCT.md). | ||
|
|
||
| ## Changes in Project Lead | ||
|
|
||
| Changes in project lead or term is initiated by opening a github PR. | ||
|
|
||
| Anyone from Keylime community can vote on the PR with either +1 or -1. | ||
|
|
||
| Only the following votes are binding: | ||
| 1) Any maintainer that has been listed in the [MAINTAINERS.md](https://github.com/keylime/keylime/MAINTAINERS.md) file before the PR is opened. | ||
| 2) Any maintainer from an organization may cast the vote for that organization. However, no organization | ||
| should have more binding votes than 1/5 of the total number of maintainers defined in 1). | ||
|
|
||
| The PR should only be opened no earlier than 6 weeks before the end of the project lead's term. | ||
| The PR should be kept open for no less than 4 weeks. The PR can only be merged after the end of the | ||
| last project lead's term, with more +1 than -1 in the binding votes. | ||
|
|
||
| When there are conflicting PRs about changes in project lead, the PR with the most binding +1 votes is merged. | ||
|
|
||
| The project lead can volunteer to step down. | ||
|
|
||
| ## Changes in Project Governance | ||
|
|
||
| Changes in project governance (GOVERNANCE.md) could be initiated by opening a github PR. | ||
| The PR should only be opened no earlier than 6 weeks before the end of the project lead's term. | ||
| The PR should be kept open for no less than 4 weeks. The PR can only be merged follow the same | ||
| voting process as in [Changes in Project Lead](#Changes_in_Project_Lead) | ||
|
|
||
| ## Decision making process | ||
|
|
||
| Decisions are build on consensus between maintainers. | ||
| Proposals and ideas can either be submitted for agreement via a github issue or PR, | ||
| or by sending an email to `[email protected]`. | ||
|
|
||
| In general, we prefer that technical issues and maintainer membership are amicably worked out between the persons involved. | ||
| If a dispute cannot be decided independently, get a third-party maintainer (e.g. a mutual contact with some background on the issue, but not involved in the conflict) to intercede. | ||
| If a dispute still cannot be decided, the project lead has the final say to | ||
| decide an issue. | ||
|
|
||
| Decision making process should be transparent to adhere to the principles of | ||
| Keylime project. | ||
|
|
||
| All proposals, ideas, and decisions by maintainers or the project lead | ||
| should either be part of a github issue or PR, or be sent to `[email protected]`. | ||
|
|
||
| ## Github Project Administration | ||
|
|
||
| The __Keylime__ GitHub project maintainers team reflects the list of Maintainers. | ||
|
|
||
| ## Other Projects | ||
|
|
||
| The Keylime organization is open to receive new sub-projects under its umbrella. | ||
| To accept a project into the __Keylime__ organization, it has to meet the | ||
| following criteria: | ||
|
|
||
| - Must be licensed under the terms of the Apache License v2.0 | ||
| - Must be related to one or more scopes of the Keylime ecosystem: | ||
| - Security Trust Attestation | ||
| - Keylime project artifacts (website, deployments, CI, etc) | ||
| - Must be supported by a Maintainer not associated or affiliated with the author(s) of the sub-projects | ||
|
|
||
| The submission process starts as an enhancement on the | ||
| [keylime/enhancements](https://github.com/keylime/enhancements) repository with the | ||
| required information mentioned above. Once a project is accepted, it's | ||
| considered a __CNCF sub-project under the umbrella of Keylime__. | ||
|
|
||
| ## Keylime and CNCF | ||
|
|
||
| Keylime is a [CNCF](https://cncf.io) project. As such, Keylime might be involved in CNCF (or other CNCF projects) related | ||
| marketing, events, or activities. Any maintainer could help driving the Keylime involvement, as long as | ||
| they send email to `[email protected]` (or create a GitHub Pull Request) to call for participation | ||
| from other maintainers. The `Call for Participation` should be kept open for no less than a week if time | ||
| permits, or a _reasonable_ time frame to allow maintainers to have a chance to volunteer. | ||
|
|
||
| ## Code of Conduct | ||
|
|
||
| The [Keylime Code of Conduct](CODE_OF_CONDUCT.md) is aligned with the CNCF Code of Conduct. | ||
|
|
||
| ## Credits | ||
|
|
||
| Sections of this documents have been borrowed from [CoreDNS](https://github.com/coredns/coredns/blob/master/GOVERNANCE.md). |