|
| 1 | +# Kube Resource Orchestrator Project Governance |
| 2 | + |
| 3 | +[Instructions](https://contribute.cncf.io/maintainers/github/templates/required/governance-maintainer/) |
| 4 | + |
| 5 | +<!-- template begins here--> |
| 6 | + |
| 7 | +This governance document explains how the Kube Resource Orchestratory project is run. |
| 8 | + |
| 9 | +- [Kube Resource Orchestrator Project Governance](#kube-resource-orchestrator-project-governance) |
| 10 | + - [Values](#values) |
| 11 | + - [Maintainers](#maintainers) |
| 12 | + - [Becoming a Maintainer](#becoming-a-maintainer) |
| 13 | + - [Removing a Maintainer](#removing-a-maintainer) |
| 14 | + - [Meetings](#meetings) |
| 15 | + - [Code of Conduct](#code-of-conduct) |
| 16 | + - [Security Response Team](#security-response-team) |
| 17 | + - [Voting](#voting) |
| 18 | + - [Modifying this Charter](#modifying-this-charter) |
| 19 | + |
| 20 | +## Values |
| 21 | + |
| 22 | +The Kube Resource Orchestrator project and its leadership embrace the following values: |
| 23 | + |
| 24 | +* Openness: Communication and decision-making happens in the open and is discoverable for future |
| 25 | + reference. As much as possible, all discussions and work take place in public |
| 26 | + forums and open repositories. |
| 27 | + |
| 28 | +* Fairness: All stakeholders have the opportunity to provide feedback and submit |
| 29 | + contributions, which will be considered on their merits. |
| 30 | + |
| 31 | +* Community over Product or Company: Sustaining and growing our community takes |
| 32 | + priority over shipping code or sponsors' organizational goals. Each |
| 33 | + contributor participates in the project as an individual. |
| 34 | + |
| 35 | +* Inclusivity: We innovate through different perspectives and skill sets, which |
| 36 | + can only be accomplished in a welcoming and respectful environment. |
| 37 | + |
| 38 | +* Participation: Responsibilities within the project are earned through |
| 39 | + participation, and there is a clear path up the contributor ladder into leadership |
| 40 | + positions. |
| 41 | + |
| 42 | +## Maintainers |
| 43 | + |
| 44 | +Kube Resource Orchestrator Maintainers have write access to the project GitHub repository. |
| 45 | +They can merge their own patches or patches from others. The current maintainers |
| 46 | +can be found in [MAINTAINERS.md](./MAINTAINERS.md). Maintainers collectively manage the project's |
| 47 | +resources and contributors. |
| 48 | + |
| 49 | +This privilege is granted with some expectation of responsibility: maintainers |
| 50 | +are people who care about the Kube Resource Orchestrator project and want to help it grow and |
| 51 | +improve. A maintainer is not just someone who can make changes, but someone who |
| 52 | +has demonstrated their ability to collaborate with the team, get the most |
| 53 | +knowledgeable people to review code and docs, contribute high-quality code, and |
| 54 | +follow through to fix issues (in code or tests). |
| 55 | + |
| 56 | +A maintainer is a contributor to the project's success and a citizen helping |
| 57 | +the project succeed. |
| 58 | + |
| 59 | +The collective team of all Maintainers is known as the Maintainer Council, which |
| 60 | +is the governing body for the project. |
| 61 | + |
| 62 | +### Becoming a Maintainer |
| 63 | + |
| 64 | +To become a Maintainer you need to demonstrate the following: |
| 65 | + |
| 66 | + * commitment to the project: |
| 67 | + * participate in discussions, contributions, code and documentation reviews |
| 68 | + for [TODO: Time Period] or more, |
| 69 | + * perform reviews for [TODO:Number] non-trivial pull requests, |
| 70 | + * contribute [TODO:Number] non-trivial pull requests and have them merged, |
| 71 | + * ability to write quality code and/or documentation, |
| 72 | + * ability to collaborate with the team, |
| 73 | + * understanding of how the team works (policies, processes for testing and code review, etc), |
| 74 | + * understanding of the project's code base and coding and documentation style. |
| 75 | + <!-- add any additional Maintainer requirements here --> |
| 76 | + |
| 77 | +A new Maintainer must be proposed by an existing maintainer by sending a message to the |
| 78 | +[developer mailing list](TODO: List Link). A simple majority vote of existing Maintainers |
| 79 | +approves the application. Maintainers nominations will be evaluated without prejudice |
| 80 | +to employer or demographics. |
| 81 | + |
| 82 | +Maintainers who are selected will be granted the necessary GitHub rights, |
| 83 | +and invited to the [private maintainer mailing list](TODO). |
| 84 | + |
| 85 | +### Removing a Maintainer |
| 86 | + |
| 87 | +Maintainers may resign at any time if they feel that they will not be able to |
| 88 | +continue fulfilling their project duties. |
| 89 | + |
| 90 | +Maintainers may also be removed after being inactive, failure to fulfill their |
| 91 | +Maintainer responsibilities, violating the Code of Conduct, or other reasons. |
| 92 | +Inactivity is defined as a period of very low or no activity in the project |
| 93 | +for a year or more, with no definite schedule to return to full Maintainer |
| 94 | +activity. |
| 95 | + |
| 96 | +A Maintainer may be removed at any time by a 2/3 vote of the remaining maintainers. |
| 97 | + |
| 98 | +Depending on the reason for removal, a Maintainer may be converted to Emeritus |
| 99 | +status. Emeritus Maintainers will still be consulted on some project matters, |
| 100 | +and can be rapidly returned to Maintainer status if their availability changes. |
| 101 | + |
| 102 | +## Meetings |
| 103 | + |
| 104 | +Time zones permitting, Maintainers are expected to participate in the public |
| 105 | +developer meeting, which occurs |
| 106 | +[TODO: Details of regular developer or maintainer meeting here]. |
| 107 | + |
| 108 | +Maintainers will also have closed meetings in order to discuss security reports |
| 109 | +or Code of Conduct violations. Such meetings should be scheduled by any |
| 110 | +Maintainer on receipt of a security issue or CoC report. All current Maintainers |
| 111 | +must be invited to such closed meetings, except for any Maintainer who is |
| 112 | +accused of a CoC violation. |
| 113 | + |
| 114 | +## Code of Conduct |
| 115 | + |
| 116 | +[Code of Conduct](./code-of-conduct.md) |
| 117 | +violations by community members will be discussed and resolved |
| 118 | +on the [private Maintainer mailing list](TODO). |
| 119 | + |
| 120 | +## Security Response Team |
| 121 | + |
| 122 | +The Maintainers will appoint a Security Response Team to handle security reports. |
| 123 | +This committee may simply consist of the Maintainer Council themselves. If this |
| 124 | +responsibility is delegated, the Maintainers will appoint a team of at least two |
| 125 | +contributors to handle it. The Maintainers will review who is assigned to this |
| 126 | +at least once a year. |
| 127 | + |
| 128 | +The Security Response Team is responsible for handling all reports of security |
| 129 | +holes and breaches according to the [security policy](TODO:Link to security.md). |
| 130 | + |
| 131 | +## Voting |
| 132 | + |
| 133 | +While most business in Kube Resource Orchestrator is conducted by "[lazy consensus](https://community.apache.org/committers/lazyConsensus.html)", |
| 134 | +periodically the Maintainers may need to vote on specific actions or changes. |
| 135 | +A vote can be taken on [the developer mailing list](TODO) or |
| 136 | +[the private Maintainer mailing list](TODO) for security or conduct matters. |
| 137 | +Votes may also be taken at [the developer meeting](TODO). Any Maintainer may |
| 138 | +demand a vote be taken. |
| 139 | + |
| 140 | +Most votes require a simple majority of all Maintainers to succeed, except where |
| 141 | +otherwise noted. Two-thirds majority votes mean at least two-thirds of all |
| 142 | +existing maintainers. |
| 143 | + |
| 144 | +## Modifying this Charter |
| 145 | + |
| 146 | +Changes to this Governance and its supporting documents may be approved by |
| 147 | +a 2/3 vote of the Maintainers. |
0 commit comments