├── .github └── ISSUE_TEMPLATE │ └── membership.md ├── CODEOWNERS ├── GOVERNANCE.md ├── README.md ├── code-of-conduct.md └── contributor-ladder.md /.github/ISSUE_TEMPLATE/membership.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Organization Membership Request 3 | about: Request membership in the Operator Framework Org 4 | title: 'REQUEST: New membership for ' 5 | labels: area/github-membership 6 | assignees: '' 7 | 8 | --- 9 | 10 | ### GitHub Username 11 | e.g. (at)example_user 12 | 13 | ### Requirements 14 | - [ ] I have reviewed the community membership guidelines (https://github.com/operator-framework/community/blob/master/community-membership.md) 15 | - [ ] I have enabled 2FA on my GitHub account (https://github.com/settings/security) 16 | - [ ] I have subscribed to the operator-framework e-mail list (https://groups.google.com/forum/#!forum/operator-framework) 17 | - [ ] I am actively contributing to 1 or more Operator Framework subprojects 18 | - [ ] I have two sponsors that meet the sponsor requirements listed in the community membership guidelines 19 | - [ ] I have spoken to my sponsors ahead of this application, and they have agreed to sponsor my application 20 | 21 | ### Sponsors 22 | - (at)sponsor-1 23 | - (at)sponsor-2 24 | 25 | ### List of contributions to the Operator Framework org 26 | - PRs reviewed / authored 27 | - Issues responded to 28 | - Subprojects I am involved with 29 | -------------------------------------------------------------------------------- /CODEOWNERS: -------------------------------------------------------------------------------- 1 | * @operator-framework/community-repo-maintainers 2 | -------------------------------------------------------------------------------- /GOVERNANCE.md: -------------------------------------------------------------------------------- 1 | # Operator Framework Project Governance 2 | 3 | The Operator Framework umbrella project is composed as a federation of 4 | individual projects, some independent and some interdependent, each of 5 | which focuses on some aspect of the goals of the umbrella project. Our 6 | governance reflects this federated structure. 7 | 8 | - [Values](#values) 9 | - [Mission](#mission) 10 | - [Scope](#scope) 11 | - [Individual Subproject Governance](#individual-subproject-governance) 12 | - [Steering Committee](#steering-committee) 13 | - [Steering Committee Duties](#steering-committee-duties) 14 | - [Steering Committee Elections](#steering-committee-elections) 15 | - [Steering Committee Bootstrapping](#steering-committee-bootstrapping) 16 | - [Governance Amendments](#governance-amendments) 17 | - [Code of Conduct Committee](#code-of-conduct-committee) 18 | - [Adding New Subprojects](#adding-new-subprojects) 19 | - [Removing Projects](#removing-projects) 20 | 21 | ## Values 22 | 23 | The Operator Framework and its leadership embrace the following values: 24 | 25 | * Openness: Communication and decision-making happens in the open and is discoverable for future 26 | reference. As much as possible, all discussions and work take place in public 27 | forums and open repositories. 28 | 29 | * Fairness: All stakeholders have the opportunity to provide feedback and submit 30 | contributions, which will be considered on their merits. 31 | 32 | * Community over Product or Company: Sustaining and growing our community takes 33 | priority over shipping code or sponsors' organizational goals. Each 34 | contributor participates in the project as an individual. 35 | 36 | * Inclusivity: We innovate through different perspectives and skill sets, which 37 | can only be accomplished in a welcoming and respectful environment. 38 | 39 | * Participation: Responsibilities within the project are earned through 40 | participation, and there is a clear path up the contributor ladder into leadership 41 | positions. 42 | 43 | ## Mission 44 | 45 | The mission of the Operator Framework community is: 46 | * To collaborate on areas related to developing, packaging, deploying 47 | and managing the lifecycle of Kubernetes Operators 48 | 49 | * To develop informational resources that give the community an 50 | understanding of best practices, trade-offs, and value adds as it 51 | relates to developing, packaging, deploying and managing the 52 | lifecycle of Kubernetes Operators 53 | 54 | * To identify suitable projects and gaps in the ecosystem for future 55 | collaboration and coordination with those projects. 56 | 57 | ### Scope 58 | 59 | The Operator Framework community focuses on the following 60 | developer-related topics of creating Kubernetes Operators: 61 | * Code scaffolding to create Kubernetes Operators 62 | * Libraries supporting common needs of Operator authors 63 | * Packaging of Kubernetes Operators 64 | * Testing of Kubernetes Operators 65 | 66 | The Operator Framework community focuses on the following admin-related 67 | topics of running Kubernetes Operators on a Kubernetes cluster: 68 | * Maintaining catalogs of Operators 69 | * Discovering and installing Operators from those catalogs 70 | * Managing the lifecycle of continuous updates and eventual removal of Operators 71 | 72 | The Operator Framework community develops best practices, fosters 73 | collaboration, and improves tool interoperability. 74 | 75 | ## Individual Subproject Governance 76 | 77 | All active Approvers of each subproject, as defined in the Contributor 78 | Ladder, are members of that project's Approvers Committee, which governs 79 | that project. The subproject's Approvers Committee is responsible for 80 | the following project governance activities: 81 | 82 | * Ensuring that the subproject creates and publishes regular releases; 83 | * Holding regular and open subproject-wide discussions on feature planning and issues; 84 | * Regular review of project contributors for advancement on the Contributor Ladder; 85 | * Following subproject governance and ensuring that the subproject 86 | functions according to the Operator Framework values. 87 | * Making final decisions on subproject changes that involve controversial trade-offs; 88 | * Responding to security compromise reports; 89 | * Supporting the Code of Conduct within their subproject and referring violations 90 | to the Code of Conduct Committee. 91 | Should a member of the Approvers Committee cease being active in the subproject, 92 | violate the Code Of Conduct, or need to be removed for some other reason, they 93 | may be removed by a 2/3 majority vote of the other Committee members, or a 94 | majority vote of the Steering Committee. 95 | 96 | Should a member of the Approver Committee cease being active in the 97 | project, violate the Code Of Conduct, or need to be removed for some 98 | other reason, they may be removed by a 2/3 majority vote of the other 99 | Committee members, or a 2/3 vote of the Steering Committee. 100 | 101 | #### Subproject Steering Committee Representative 102 | 103 | Additionally, the Approver Committee will select, by an election 104 | conducted by the Operator Framework Election officials, one 105 | representative of the project to the Operator Framework Steering 106 | Committee. This representative need not be a member of the project's 107 | Approver Committee, and will be replaced or renewed by the Committee 108 | annually. If only one Subproject representative is nominated, they are 109 | automatically appointed without an election. 110 | 111 | #### Subproject Governance Ammendments 112 | 113 | If a subproject wishes to update or supplement governance documents, 114 | this will require a 2/3 majority approval from the Operator Framework 115 | steering committee. If a subproject has additional Governance, it must 116 | be in a `GOVERNANCE.md` at the root of the repository. 117 | 118 | ## Steering Committee 119 | 120 | The overall Operator Framework umbrella project is governed by a Steering 121 | Committee, which is selected as follows: 122 | 123 | * One Maintainer representative from each member subproject 124 | * At least 3 community representatives 125 | * The Steering committee should contain at least 7 members, if there are 126 | fewer than 4 subprojects, the remaining seats will be filled by community 127 | representatives. 128 | 129 | ### Steering Committee Duties 130 | 131 | The Steering Committee is responsible for the following tasks, any of 132 | which may be delegated to a person or group selected by the committee: 133 | 134 | * Reviewing and deciding on new projects to add to Operator Framework 135 | * Arbitrating inter-project disagreements 136 | * Selecting the Code of Conduct Committee and ratifying CoC judgements 137 | * Removing projects which have become inactive 138 | * Acting on escalated security or code quality issues 139 | * Resolving issues that individual projects are unable to resolve 140 | * Administering project infrastructure, intellectual property, and resources 141 | * Determining overall direction for advocacy and marketing 142 | * Issuing statements on behalf of Operator Framework and its subprojects 143 | * Reviewing and approving Contributor Ladder advancement for participants who 144 | work on the overall umbrella project 145 | * Facilitate outreach and project participation in CNCF events 146 | 147 | In performance of these duties, the Steering Committee will hold a 148 | monthly meeting that is open to all contributors. The Committee may hold 149 | additional, closed meetings in order to discuss non-public issues such 150 | as security exploits, CoC enforcement, and legal questions. 151 | 152 | Steering Committee members are expected to advocate for all of Operator 153 | Framework, not just certain projects or corporate sponsors, comply with 154 | and support the Code of Conduct, and be professional and compassionate 155 | in all of their dealings with project participants. 156 | 157 | ### Steering Committee Elections 158 | 159 | Once per year, the Steering Committee will select three Election 160 | Officers to run the annual election and set the dates for the election. 161 | Election Officers should be project Members in good standing, not 162 | running for election themselves, and represent more than one project 163 | employer. These officers will update the list of eligible Members according to 164 | project records, send out announcements, and conduct the election. 165 | 166 | The election itself will last for at least one week, and is conducted as 167 | a preference election online, using the Condorcet method. The Election 168 | Officers will announce the selected candidates at the next regular 169 | community meeting. 170 | 171 | #### Steering Committee Election Procedure 172 | 173 | 1. Nominations for Operator Framework Representatives (Subproject Rep 174 | and Community Rep) will be collected for at least 14 days. Interested 175 | individuals should self-nominate, and they may be considered for 176 | Subproject Representative and Community Representative. 177 | 2. For each Subproject, one Subproject Representative is chosen by the 178 | Subproject's Approvers. Each Subproject vote will be conducted by the 179 | OF Election Officials and calculated by the Condorcet Method. 180 | 3. Following the announcement of the Subproject results, the 181 | Community Representatives are chosen by all Members of the Operator 182 | Framework. The vote will be conducted by the OF Election Officials 183 | and calculated by the Condorcet Method. 184 | 185 | If individuals are nominated to be Subproject Representative, the 186 | Subproject elections will be calculated in a random order. No individual 187 | can hold more than one seat on the Steering Committee. 188 | 189 | ### Steering Committee Bootstrapping 190 | 191 | Upon ratification of this document, the 7 elected Chairs of the Operator 192 | Framework will become the Steering Committee for a period of one year, 193 | afterwards Steering Committee elections will proceed as outlined in this 194 | document. 195 | 196 | ## Governance Amendments 197 | 198 | The Operator Framework Community may adopt or amend its Governance 199 | Documents (`GOVERNANCE.md` and `contributor-ladder.md`) according to 200 | the following process: 201 | 202 | 1. Propose a change by opening an issue in the community, and if there 203 | seems to be general agreement, open a pull request to this document. 204 | 2. The change should be announced via the mailing list along with an invitation for discussion on the Pull Request. 205 | 3. A minimum of 7 days must pass between the announcement and the vote, 206 | and the vote must remain open for a minimum of 7 days. The Steering 207 | Committee may extend both periods. 208 | 209 | For a vote to pass, 2/3 majority of the Steering Committee must approve. 210 | 211 | ## Code of Conduct Committee 212 | 213 | In order to review and enforce the Code of Conduct, the Steering 214 | Committee selects 3 people to be on the Code of Conduct Committee. 215 | These individuals will be chosen based on their community management and 216 | code of conduct experience, with diverse representation across the 217 | committee, including employer, gender, race, background, and region of 218 | the world. To avoid fatigue, the Steering Committee will replace at 219 | least 2 members of the CoC Committee each year. Members of 220 | the committee do not need to be members of Operator Framework if they 221 | have sufficient other expertise. 222 | 223 | The CoC Committee will receive reports of conduct violations confidentially, 224 | and will discuss them in closed meetings. If a report is determined to be a 225 | violation, they will recommend action on it appropriate to the scale, nature, 226 | and context of the violation, from requiring an apology, up to expulsion of an 227 | individual from the project. In the event that a contributor is to be demoted 228 | or expelled, the CoC Committee will forward this recommendation to the Steering 229 | Committee who will ratify it in a closed meeting. Should a member of the 230 | Steering Committee be the offender or the reporter, this recommendation will 231 | instead be forwarded to the CNCF staff for final arbitration. 232 | 233 | ## Adding New Subprojects 234 | 235 | During the monthly Steering meeting, any project member may recommend projects 236 | to become part of Operator Framework. These projects should have the following 237 | characteristics: 238 | 239 | * Have a mission that aligns with the Operator Framework goals 240 | * Are appropriately licensed 241 | * Governance structure is fully documented in a GOVERNANCE file 242 | * Governance rules are modifiable by project leaders through a defined process. 243 | * Embrace the Operator Framework and CNCF values 244 | * Are under active development 245 | * Consist of high quality code and designs 246 | * Have at least 3 Approvers (Experimental Subprojects must have at least 1) 247 | 248 | In some cases, promising but incomplete projects may be accepted as 249 | Experimental Subprojects. Such Experimental Subprojects will be 250 | considered part of Operator Framework, but will be marked as 251 | Experimental on the website and in code repositories, in order to inform 252 | users. Experimental Subproject Members are considered Members of 253 | Operator Framework, but the subproject is not entitled to a 254 | representative on the Steering Committee. Experimental Subprojects can 255 | apply for full status by opening an issue, which will be reviewed by the 256 | Steering Committee. 257 | 258 | Before submitting an application to the Steering Committee, the applying 259 | project must hold an internal vote of all major contributors to join 260 | Operator Framework. The Steering Committee will then review and vote on 261 | the application. A 2/3 majority of the Steering Committee members must 262 | approve, and Experimental subprojects require 1/2 of the Steering 263 | Committee to approve. If the application is accepted, the Committee will 264 | assign one person to assist the subproject in their integration. 265 | 266 | ## Removing Projects 267 | 268 | In some cases, projects will become inactive or unmaintainable, or wish to separate 269 | from Operator Framework. Any Steering Committee member may propose removal of a project on 270 | these grounds, and Steering can confirm this with a 2/3 vote. 271 | 272 | Projects which still have contributors will then be moved to a repository in their 273 | own namespace. Projects which have ceased all activity are moved to an archived namespace. 274 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Operator Framework Community 2 | 3 | Welcome to the Operator Framework community repo, which contains the Operator 4 | Framework process, charter, and coordination documents. 5 | 6 | ## Governance 7 | To learn more about how the Operator Framework organization is governed, take a look at our governance documents: 8 | - [Operator Framework Project Governance](GOVERNANCE.md) 9 | - [Operator Framework Contributor Ladder](contributor-ladder.md) 10 | 11 | ## Get involved 12 | 13 | * Kubernetes Slack ([Get invite](https://slack.k8s.io)) 14 | * Users: [#kubernetes-operators](https://kubernetes.slack.com/messages/kubernetes-operators) 15 | * SDK Development: [#operator-sdk-dev](https://kubernetes.slack.com/messages/operator-sdk-dev) 16 | * OLM Development: [#olm-dev](https://kubernetes.slack.com/messages/olm-dev) 17 | * [Operator Framework on Google Groups][of-mailing-list] 18 | * [Operator Lifecycle Manager Development on Google Groups](https://groups.google.com/forum/#!forum/operator-framework-olm-dev) 19 | * [Operator Framework Commons SIG](https://commons.openshift.org/sig/OpenshiftOperators.html) 20 | 21 | ### Operator Framework Meetings 22 | 23 | * Outreach and Community Planning: Fridays (about 1/month) at 12:00 Eastern Time. [Convert to your timezone](https://dateful.com/time-zone-converter?t=12:00&tz=ET%20(Eastern%20Time)) 24 | * [Meeting Link][meeting-link]: Password: 77777 25 | * [Agenda](https://docs.google.com/document/d/1dB6A1JchUUSQxtuVxRJTLDvF8jZN57p1lsq6oKCIPN4/edit) 26 | * [Meeting recordings](https://www.youtube.com/playlist?list=PLEcO8aSeUjeVCRWuqOYwKiEd71-VmOpCN) 27 | 28 | ## Working Groups 29 | 30 | Most Operator Framework community activity is organized into Working Groups; 31 | each may operate a little differently depending on their needs and workflow. 32 | 33 | ## Operator Lifecycle Manager Working Group 34 | 35 | To organize and steer the development of projects that enable teams to manage the lifecycle of operators. These projects include: 36 | - The [Operator Lifecycle Manager project](https://github.com/operator-framework/operator-lifecycle-manager) 37 | - The [Operator Registry project](https://github.com/operator-framework/operator-registry) 38 | 39 | ### Meetings 40 | 41 | * WG and Issue Traige: Tuesdays at 11:00 Eastern Time. [Convert to your timezone](http://www.thetimezoneconverter.com/?t=11:00&tz=ET%20%28Eastern%20Time%29). 42 | * [Meeting Link][olm-meeting-link]: Password: 77777 43 | * [Agenda](https://docs.google.com/document/d/1Zuv-BoNFSwj10_zXPfaS9LWUQUCak2c8l48d0-AhpBw/edit) 44 | * [Meeting recordings](https://www.youtube.com/playlist?list=PLEcO8aSeUjeXDvBtPlaAvPTaknPR0Uwi-). 45 | 46 | ### Organizers 47 | 48 | * Alexander Greene (**[@awgreene](https://github.com/awgreene)**), Red Hat 49 | * Daniel Sover (**[@exdx](https://github.com/exdx)**), Red Hat 50 | * Kevin Rizza (**[@kevinrizza](https://github.com/kevinrizza)**), Red Hat 51 | 52 | ### Contact 53 | 54 | - Slack: [#olm-dev](https://kubernetes.slack.com/messages/olm-dev) 55 | - [Mailing list](https://groups.google.com/forum/#!forum/operator-framework-olm-dev) 56 | 57 | ## Operator SDK Working Group 58 | 59 | To organize and steer the development of the [Operator SDK](https://github.com/operator-framework/operator-sdk) and related projects. 60 | 61 | ### Meetings 62 | 63 | * Community Meeting and Issue Triage Meeting: Mondays (weekly) at 11:00 Western Time. [Convert to your timezone](http://www.thetimezoneconverter.com/?t=11:00&tz=PT%20%28Western%20Time%29). 64 | * [Meeting Link][meeting-link]: Password: 77777 65 | * [Issue Query](https://github.com/operator-framework/operator-sdk/issues?q=is%3Aopen+is%3Aissue+no%3Amilestone+sort%3Acreated-asc) 66 | * [Agenda](https://docs.google.com/document/d/1ujWb-rSJ4JWeHLVxK0WS5ZuSJgeESG42MDeYjSl9Q6U/edit) 67 | * [Meeting recordings](https://www.youtube.com/playlist?list=PLEcO8aSeUjeXxkVh27ExScB_wEmhBLY7g). 68 | * Backlog Grooming Meeting: Wednesdays (every 3 weeks) at 11:00 Western Time. [Convert to your timezone](http://www.thetimezoneconverter.com/?t=11:00&tz=PT%20%28Western%20Time%29). 69 | * [Meeting Link][meeting-link]: Password: 77777 70 | * [Agenda](https://docs.google.com/document/d/1ujWb-rSJ4JWeHLVxK0WS5ZuSJgeESG42MDeYjSl9Q6U/edit) 71 | * [Meeting recordings](https://www.youtube.com/playlist?list=PLEcO8aSeUjeXxkVh27ExScB_wEmhBLY7g). 72 | 73 | ### Organizers 74 | 75 | * Austin Macdonald (**[@asmacdo](https://github.com/asmacdo)**), Red Hat 76 | * Jonathan Berkhahn (**[@jberkhahn](https://github.com/jberkhahn)**), IBM 77 | * Ken Sipe (**[@kensipe](https://github.com/kensipe)**), Code Mentor 78 | * Varsha Prasad Narsing (**[@varshaprasad96](https://github.com/varshaprasad96)**), Red Hat 79 | 80 | ### Contact 81 | 82 | - Slack: [#operator-sdk-dev](https://kubernetes.slack.com/messages/operator-sdk-dev) 83 | - [Mailing list][of-mailing-list] 84 | 85 | ## Java Operator Working Group 86 | 87 | To organize and steer the development of 88 | - [java-operator-plugins](https://github.com/operator-framework/java-operator-plugins) 89 | - [java-operator-sdk](https://github.com/java-operator-sdk/java-operator-sdk) 90 | 91 | ### Meetings 92 | 93 | * Issue Triage and Community Meeting: Thursdays (weekly) at 11:00 ET. [Convert to your timezone](https://dateful.com/time-zone-converter?t=11:00&tz=ET%20(Eastern%20Time)) 94 | * [Meeting Link][meeting-link]: Password: 77777 95 | * [Agenda](https://docs.google.com/document/d/1d_x7JHnjhKh8DgUO9F83kZ43Y3Ladl6sHWzst2ugV84/edit#) 96 | 97 | ### Organizers 98 | 99 | * Jesus M. Rodriguez (**[@jmrodri](https://github.com/jmrodri)**), Red Hat 100 | * Attila Mészáros (**[@csviri](https://github.com/csviri)**), Red Hat 101 | * Adam Sandor (**[@adam-sandor](https://github.com/adam-sandor)**), Styra.com 102 | * Christophe Laprun (**[@metacosm](https://github.com/metacosm)**), Red Hat 103 | 104 | ### Contact 105 | 106 | - Slack: [##operator-sdk-dev](https://kubernetes.slack.com/messages/operator-sdk-dev) 107 | - Discord: [##java-operator-sdk](https://discord.com/invite/K4YEJ3Z5Mw) 108 | - [Mailing list][of-mailing-list] (Subscribe to access the agenda document.) 109 | 110 | ## Ansible Working Group 111 | 112 | To organize and steer the development of Ansible-based Operators and related projects: 113 | * [Ansible-based Operators](https://github.com/operator-framework/operator-sdk) 114 | * [operator_sdk.util Ansible collection](https://github.com/operator-framework/operator-sdk-ansible-util) 115 | * [kubernetes.core Ansible collection](https://github.com/ansible-collections/kubernetes.core) 116 | 117 | ### Meetings 118 | 119 | * Community Meeting and Triage: Third Monday (monthly) at 12:00 Eastern Time. [Convert to your timezone](http://www.thetimezoneconverter.com/?t=12:00&tz=ET%20%28Eastern%20Time%29). 120 | * [Meeting Link][meeting-link]: Password: 77777 121 | * [Agenda](https://docs.google.com/document/d/1Bo68RhJkpr0Nk_JpkBdbkgmi3c2WtfdvFZ0jVSJzvXo/edit?usp=sharing) 122 | * [Recordings](https://www.youtube.com/playlist?list=PLEcO8aSeUjeWicUrCkNjH33zVc7S0QDBv) 123 | 124 | ### Organizers 125 | 126 | * Austin Macdonald (**[@asmacdo](https://github.com/asmacdo/)**), Red Hat 127 | * Fabian von Feilitzsch (**[@fabianvf](https://github.com/fabianvf)**), Red Hat 128 | * Tim Appnel (**[@tima](https://github.com/tima)**), Red Hat 129 | 130 | ### Contact 131 | 132 | - Slack: [##operator-sdk-dev](https://kubernetes.slack.com/messages/operator-sdk-dev) 133 | - [Ansible-k8s-operators Mailing list](https://groups.google.com/forum/#!forum/ansible-k8s-operators) 134 | - [OF Mailing list][of-mailing-list](Subscribe to access the agenda document.) 135 | 136 | [meeting-link]: https://zoom.us/j/8415370125 137 | [olm-meeting-link]: https://zoom.us/j/5511723751 138 | [of-mailing-list]: https://groups.google.com/forum/#!forum/operator-framework 139 | -------------------------------------------------------------------------------- /code-of-conduct.md: -------------------------------------------------------------------------------- 1 | # Operator Framework Community Code of Conduct 2 | 3 | Operator Framework follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). 4 | 5 | Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting 6 | a [community chair](./GOVERNANCE.md#operations) or the CNCF mediator noted in the code of conduct document linked above. 7 | -------------------------------------------------------------------------------- /contributor-ladder.md: -------------------------------------------------------------------------------- 1 | # Operator Framework Contributor Ladder 2 | 3 | ## Member 4 | 5 | Defined by: Member of the Operator Framework Github organization 6 | 7 | Description: A Member is an established contributor who regularly 8 | participates in the project. Organization Members have privileges in 9 | both project repositories and elections, and as such are expected to act 10 | in the interests of the whole project. 11 | 12 | Responsibilities include: 13 | - Members are expected to remain active contributors to the community. 14 | 15 | Requirements: 16 | - Enabled [two-factor authentication] on their GitHub account. 17 | - Must be subscribed to the Operator-Framework mailing list. 18 | - Must have successful contributions to the project, including at least one of the following: 19 | - 2 accepted PRs, 20 | - Reviewed 2 PRs, 21 | - Resolved and closed 2 Issues, 22 | - Become responsible for a key project management area, 23 | - Or some equivalent combination or contribution 24 | - Must be actively contributing to at least one project area 25 | - Sponsored by 2 reviewers. Note the following requirements for sponsors: 26 | - Sponsors must have close interactions with the prospective member - e.g. code/design/proposal review, coordinating on issues, etc. 27 | - Sponsors must be reviewers or approvers in the OWNERS files in operator-framework/community 28 | 29 | Privileges: 30 | - May be assigned Issues and Reviews 31 | - May give commands to CI/CD automation 32 | - Entitled to vote in the appropriate elections such as for at-large CNCF chair, etc. 33 | 34 | The process to become an Organization Member is as follows: 35 | 36 | 1. Open an issue against the operator-framework/community repo 37 | 1. Ensure your sponsors are @mentioned in the issue 38 | 1. Complete every item on the checklist (preview the current version of the template) 39 | 1. Make sure that the list of contributions included is representative of your work on the project. 40 | 1. Have your sponsoring reviewers reply confirmation of sponsorship: +1 or /lgtm 41 | 1. Once your sponsors have responded, your request will be reviewed by a operator-framework GitHub org admin. Any missing information will be requested. 42 | 43 | ## Reviewer 44 | 45 | Defined by: listed as reviewer in owners-aliases in operator-framework/community 46 | 47 | Description: A Reviewer has responsibility for specific code, 48 | documentation, test, or other project areas. They are collectively 49 | responsible, with other Reviewers, for reviewing all changes to those 50 | areas and indicating whether those changes are ready to merge. They have 51 | a track record of contribution and review in the project. **Reviewers are 52 | associated with a specific subproject, such as Operator SDK or OLM.** 53 | 54 | Responsibilities include: 55 | - Expected to be responsive to review requests as per [community expectations] 56 | - Assigned PRs to review related to subproject of expertise 57 | - Helping other contributors become reviewers 58 | 59 | Requirements: 60 | - Has demonstrated an in-depth knowledge of the specific area 61 | - Commits to being responsible for that specific area 62 | - Sponsored by 2 approvers from the same subproject 63 | - With no objections from other approvers 64 | - Done through PR to update the OWNERS file in operator-framework/community 65 | - Sponsors must have close interactions with the prospective member - e.g. code/design/proposal review, coordinating on issues, etc. 66 | - May either self-nominate, be nominated by an approver in this subproject, or be nominated by a robot 67 | 68 | Privileges: 69 | - Granted "read access" to specific area of operator-framework GitHub organization owned by the relevant subproject 70 | - May mark PR’s in specific area as “/lgtm” for PR merging purposes 71 | 72 | ## Approver 73 | 74 | Defined by: listed as approver in owners-aliases in operator-framework/community 75 | 76 | Description: Code approvers are established contributors able to both 77 | review and approve code contributions. While code review is focused on 78 | code quality and correctness, approval is focused on holistic acceptance 79 | of a contribution including: backwards / forwards compatibility, 80 | adhering to API and flag conventions, subtle performance and correctness 81 | issues, interactions with other parts of the system, etc. Approvers are 82 | expected to participate in making decisions about the strategy and 83 | priorities of the project. **Approvers are associated with a specific 84 | subproject, such as Operator SDK or OLM.** 85 | 86 | Responsibilities include: 87 | - Approver status may be a precondition to accepting large code contributions 88 | - Demonstrate sound technical judgment 89 | - Responsible for project quality control via [code reviews] 90 | - Focus on holistic acceptance of contribution such as dependencies with other features, backwards / forwards compatibility, API and flag definitions, etc 91 | - Expected to be responsive to review requests per [community expectations] 92 | - Participating in, and leading, community meetings 93 | - Mentoring new Reviewers 94 | 95 | Requirements: 96 | - Demonstrates a broad knowledge of the project across multiple areas 97 | - Is able to exercise judgment for the good of the project, independent of their employer, friends, or team 98 | - Sponsored by 2 approvers from the same subproject 99 | - With no objections from other approvers 100 | - Done through PR to update the OWNERS file in operator-framework/community 101 | - Sponsors must have close interactions with the prospective member - e.g. code/design/proposal review, coordinating on issues, etc. 102 | - May either self-nominate, be nominated by an approver in this subproject, or be nominated by a robot 103 | 104 | Privileges: 105 | - May approve PRs for acceptance 106 | - May represent the project in public as a maintainer 107 | - Eligible to vote in maintainer decision-making meetings 108 | - Write access to the relevant repositories 109 | 110 | ## Steering Committee Member 111 | 112 | Defined by: listed as steering committee in owners-aliases in operator-framework/community 113 | 114 | Description: Steering committee members are the chairs of Operator Framework as a whole. 115 | They are elected according to the procedures outlined in [the Operator Framework governance documentation.](https://github.com/operator-framework/community/blob/master/GOVERNANCE.md) 116 | Also see those docs for further description of the role of the Steering Committee as a whole. 117 | 118 | Responsibilities include: 119 | - Administering and representing the Operator Framework project as a whole 120 | - Adjudicating disagreements between sub-projects 121 | - Ultimate responsibility for project concerns such as security, code quality, etc. 122 | - Representing the Operator Framework to the CNCF 123 | 124 | Requirements: 125 | - Must be an [Operator Framework Member](#Member) 126 | - Elected per the processes outlined in the governance documentation of Operator Framework. 127 | 128 | Privileges: 129 | - Admin access to repositories and other Operator Framework assets 130 | - CNCF Maintainer status for Operator Framework 131 | 132 | ## Inactive Members 133 | 134 | It is important for contributors to be and stay active to set an example 135 | and show commitment to the project. Inactivity is harmful to the project 136 | as it may lead to unexpected delays, contributor attrition, and a lost 137 | of trust in the project. 138 | 139 | Inactivity is measured by: 140 | - Periods of no contributions for longer than 3 months (except in cases 141 | of communicated inactivity such as medical events) 142 | - Periods of no communication for longer than 3 months 143 | 144 | Consequences of being inactive include: 145 | - Involuntary removal or demotion 146 | - Being asked to move to Emeritus status 147 | 148 | ## Involuntary Removal or Demotion 149 | 150 | Involuntary removal/demotion of a contributor happens when 151 | responsibilities and requirements aren't being met. This may include 152 | repeated patterns of inactivity, extended period of inactivity, a period 153 | of failing to meet the requirements of your role, and/or a violation of 154 | the Code of Conduct. This process is important because it protects the 155 | community and its deliverables while also opens up opportunities for new 156 | contributors to step in. Involuntary removal or demotion is handled 157 | through a vote by a majority of the current Approvers of the relevant 158 | subproject. 159 | 160 | ## Stepping Down/Emeritus Process 161 | 162 | If and when contributors' commitment levels change, contributors can 163 | consider stepping down (moving down the contributor ladder) vs moving to 164 | emeritus status (completely stepping away from the project). Contact 165 | the Approvers about changing to Emeritus status, or reducing your 166 | contributor level. In the event that an emeritus contributor 167 | comes back to the project, directly reapply for their previous 168 | position via the normal application method. 169 | --------------------------------------------------------------------------------