1# Community membership 2 3This doc outlines the various expectations of contributor roles in OpenBMC. The 4OpenBMC project is subdivided into subrepositories. Responsibilities for most 5roles are scoped to these subrepos. 6 7| Role | Expectations | Requirements | Defined by | 8| ------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------ | 9| Code Contributor | Abide by the code of conduct | Executed Contributor License Agreement | Merged Code | 10| Designated Reviewer | Review contributions from other members | History of review in a subproject | [OWNERS] file reviewer entry | 11| Platform Maintainer | Review and maintain contributions to a single platform | History of testing and ownership of a given single platform | [OWNERS] entry within the meta-\* subfolder for the platform | 12| Approver | Review and maintain contributions to a portion of code | Demonstrated responsibility and excellent technical judgement for the portion of code across platforms | subproject [OWNERS] file _owners_ entry | 13| Subproject owner | Set direction and priorities for a subproject | Demonstrated responsibility and excellent technical judgement for the subproject across platforms | subproject [OWNERS] file _owners_ entry | 14| TOF Member | Set direction and priorities for the project | Elected via [TOF election cycle] | Entry in TOF documentation in docs repository | 15 16## New contributors 17 18[New contributors] should be welcomed to the community by existing members, 19helped with review workflow, and directed to relevant documentation and 20communication channels. 21 22## Established community members 23 24Established community members are expected to demonstrate their adherence to the 25principles in this document, familiarity with project organization, roles, 26policies, procedures, conventions, etc., and technical and/or writing ability. 27Role-specific expectations, responsibilities, and requirements are enumerated 28below. 29 30## Member 31 32Members are continuously active contributors in the community. They can have 33issues and reviews assigned to them, participate in design reviews through 34Gerrit, and pre-submit tests are automatically run for their reviews. Members 35are expected to remain active contributors to the community. 36 37**Defined by:** Listed on a current contributor license agreement. 38 39### Expectations 40 41- Have made multiple contributions to the project or community. Contribution may 42 include, but is not limited to: 43 - Authoring or reviewing code reviews on Gerrit 44 - Filing or commenting on issues on GitHub 45 - Contributing to design review, subproject, or community discussions (e.g. 46 meetings, Discord, mailing list discussions) 47- Subscribed to the [mailing list] 48- Have read the [contributor guide] 49- Actively contributing to 1 or more subprojects. 50- **[Submit a CLA]** 51 52## Designated Reviewer 53 54Designated Reviewers are capable of reviewing code for quality and correctness 55on some part of a subproject. They are knowledgeable about both the codebase and 56software engineering principles. 57 58**Defined by:** _reviewers_ entry in an OWNERS file in a repo owned by the 59OpenBMC project. 60 61Reviewer status is scoped to a part of the codebase. 62 63**Note:** Acceptance of code contributions requires at least one approver in 64addition to the assigned reviewers. 65 66### Expectations 67 68The following apply to the part of the codebase for which one would be a 69reviewer in an [OWNERS] file. 70 71- Member for at least 3 months 72- Primary reviewer for at least 5 changes to the codebase 73- Reviewed or merged at least 5 substantial changes to the codebase 74- Knowledgeable about the codebase 75- Sponsored by a subproject approver 76 - With no objections from other approvers 77 - Done through PR to update the OWNERS file 78- May either self-nominate or be nominated by an approver in this subproject. 79 80### Responsibilities and privileges 81 82The following apply to the part of codebase for which one would be a reviewer in 83an [OWNERS] file. 84 85- Code reviewer status may be a precondition to accepting large code 86 contributions 87- Responsible for project quality control via [code reviews] 88 - Focus on code quality and correctness, including testing and factoring 89 - May also review for more holistic issues, but not a requirement 90- Expected to be responsive to review requests as per [community expectations] 91- Assigned changes to review related to subproject of expertise 92- Assigned test bugs related to subproject of expertise 93 94## Platform Maintainer 95 96Platform maintainers are able to review configuration changes for quality and 97correctness on meta layers and subsystems that apply to a single platform. They 98are knowledgeable about the specific constraints on a given platform, and have 99access to an instance of said platform to test. 100 101**Defined by:** _owners_ entry in an OWNERS file in a machine meta layer in the 102[main OpenBMC repository]. 103 104### Expectations 105 106The following apply to the part of codebase for which one would be a platform 107owner in an [OWNERS] file. 108 109- Member for at least 3 months 110- Primary reviewer for at least 5 reviews to the codebase 111- Knowledgeable about the specific platforms constraints 112- Access to a platform to test and run code 113- Demonstrated knowledge of bitbake metadata 114- Sponsored by a root approver from openbmc/openbmc OWNERS file 115 - With no objections from other approvers 116 - Done through PR to update the OWNERS file 117- May either self-nominate or be nominated by an approver in this subproject. 118 119### Responsibilities and privileges 120 121The following apply to the part of codebase for which one would be a reviewer in 122an [OWNERS] file. 123 124- Having an owner with platform maintainer status may be a precondition to 125 accepting a new platform 126- Responsible for platform stability 127 - Testing on a regular cadence (base expectation is every quarter) 128 - Providing results and insight to the community on platform-specific issues. 129- Expected to be responsive to review requests as per [community expectations] 130- Assigned changes to review and test related to the platform 131- Communicating with the technical-oversight-forum any long-term (> 1 month) 132 absences, or resignation of these responsibilities, through a change to the 133 [OWNERS] file. 134 135## Approver 136 137Code approvers are able to both review and approve code contributions. While 138code review is focused on code quality and correctness, approval is focused on 139holistic acceptance of a contribution including: backwards / forwards 140compatibility, adhering to API conventions, subtle performance and correctness 141issues, interactions with other parts of the system, etc. 142 143**Defined by:** _owners_ entry in an OWNERS file in a repo owned by the OpenBMC 144project. 145 146Approver status is scoped to a part of the codebase. 147 148### Expectations 149 150The following apply to the part of the codebase for which one would be an 151approver in an [OWNERS] file. 152 153- Reviewer of the codebase for at least 9 months 154- Primary reviewer for at least 10 substantial changes to the codebase 155- Reviewed or merged at least 30 changes to the codebase 156- Access to a suitable platform environment 157- Nominated by two subproject or TOF root owner sponsors 158 - With no objections from other subproject owners 159 - Done through PR to update the subprojects top-level OWNERS file 160 - **Note the following expectations for sponsors**: 161 - Sponsors must have close interactions with the prospective member - e.g. 162 code/design/proposal review, coordinating on issues, etc. 163 - Sponsors must be approver in at least one subproject. 164 - Sponsors must be from multiple member companies to demonstrate integration 165 across community. 166 167### Responsibilities and privileges 168 169The following apply to the part of the codebase for which one would be an 170approver in an [OWNERS] file. 171 172- Approver status may be a precondition to accepting large code contributions 173- Demonstrate sound technical judgement 174- Responsible for project quality control via [code reviews] 175 - Focus on holistic acceptance of contribution such as dependencies with other 176 features, backwards / forwards compatibility, API and flag definitions, etc 177 - Maintain a codebase that is free from unnecessary or unused code, and remove 178 previous contributions that are no longer used and/or maintained. 179- Expected to be responsive to review requests as per [community expectations] 180- Mentor contributors and reviewers 181- May approve code contributions for acceptance 182 183## Subproject Owner 184 185**Note:** This is a generalized high-level description of the role, and the 186specifics of the subproject owner role's responsibilities and related processes 187may be more specific for individual subprojects, as defined in their respective 188OWNERS files. 189 190Subproject Owners are the technical authority for a subproject in the OpenBMC 191project. They _MUST_ have demonstrated both good judgement and responsibility 192towards the health of that subproject. Subproject Owners _MUST_ set technical 193direction and make or approve design decisions for their subproject - either 194directly or through delegation of these responsibilities. 195 196**Defined by:** _owners_ entry in subproject [OWNERS] 197 198### Expectations 199 200The per-repository requirements for becoming an subproject Owner should be 201defined in the OWNERS file of the subproject. Unlike the roles outlined above, 202the Owners of a subproject are typically limited to a relatively small group of 203decision makers and updated as fits the needs of the subproject. 204 205The following apply to the subproject for which one would be an owner. 206 207- Deep understanding of the technical goals and direction of the subproject 208- Deep understanding of the technical domain of the subproject 209- Sustained contributions to design and direction by doing all of: 210 - Authoring and reviewing proposals 211 - Initiating, contributing and resolving discussions (emails, GitHub issues, 212 meetings) 213 - Identifying subtle or complex issues in designs and implementation reviews 214 - Ensure through testing that the subproject is functional on one or more 215 platforms 216- Directly contributed to the subproject through implementation and/or review 217- Meet all subproject specific requirements outlined in the OWNERS file 218 219### Responsibilities and privileges 220 221The following apply to the subproject for which one would be an owner. 222 223- Make and approve technical design decisions for the subproject. 224- Set technical direction and priorities for the subproject. 225- Mentor and guide approvers, reviewers, and contributors to the subproject. 226- Ensure continued health of subproject 227 - Adequate test coverage to confidently release 228 - Tests are present and passing reliably (i.e. not flaky) and are fixed when 229 they fail 230- Ensure a healthy process for discussion and decision making is in place. 231- Work with other subproject owners to maintain the project's overall health and 232 success holistically. 233- Keep abreast of technical changes to the overall project and maintain and/or 234 delegate maintenance of the subproject to keep it aligned with the overall 235 project. 236 237## Technical Oversight Forum Member 238 239The Technical Oversight Forum is the technical authority for the OpenBMC 240project. They _MUST_ have demonstrated both good judgement and responsibility 241towards the health of the OpenBMC project and be elected by the community. TOF 242Members _MUST_ set technical direction and make or approve design decisions for 243the project, ensure adherence to the rules in this document and others, and 244promote engagement with the open source community at large. 245 246**Defined by:** TOF membership in docs repository 247 248### Expectations 249 250- Deep understanding of the technical goals and direction of the project 251- Knowledge of community members, technical experts within and outside the 252 project, along with a history of engagement. 253- Deep understanding of the technical domain of OpenBMC and BMCs in general. 254- Sustained contributions to design and direction by doing all of: 255 - Authoring, reviewing, and voting on proposals to the 256 technical-oversight-forum repository 257 - Initiating, contributing and resolving discussions that involve project-wide 258 changes and expectations (emails, GitHub issues, meetings) 259 - Identifying subtle or complex issues in designs and implementation that 260 occur cross-project. 261 - Ensure through testing that the project is functional (to the extent 262 possible) for all platforms 263 - Ensure that coding standards, project norms, and community guidelines are 264 documented and adhered to throughout the project. 265- Directly contributed to the project through implementation and/or review 266 267### Responsibilities and privileges 268 269- Make and approve technical design decisions for OpenBMC. 270- Define milestones and releases. 271- Mentor and guide approvers, reviewers, and contributors to the project. 272- Create new subprojects, and ensure their addition continues the growth and 273 health of the project. 274- Define and maintain a healthy process for discussion and decision making. 275- Work with subproject owners and platform maintainers to maintain the project's 276 overall health and success holistically. 277 278[new contributors]: /CONTRIBUTING.md#starting-out 279[code reviews]: https://gerrit.openbmc.org/ 280[mailing list]: https://lists.ozlabs.org/listinfo/openbmc 281[main OpenBMC repository]: https://github.com/openbmc/openbmc 282[community expectations]: /code-of-conduct.md 283[submit a cla]: /CONTRIBUTING.md#starting-out 284[contributor guide]: /CONTRIBUTING.md 285[tof election cycle]: /tof/membership-and-voting.md 286