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