This doc outlines the various expectations of contributor roles in OpenBMC. The OpenBMC project is subdivided into subrepositories. Responsibilities for most roles are scoped to these subrepos.
| Role | Expectations | Requirements | Defined by |
|---|---|---|---|
| Code Contributor | Abide by the code of conduct | Executed Contributor License Agreement | Merged Code |
| Designated Reviewer | Review contributions from other members | History of review in a subproject | [OWNERS] file reviewer entry |
| 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 |
| 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 |
| 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 |
| TOF Member | Set direction and priorities for the project | Elected via TOF election cycle | Entry in TOF documentation in docs repository |
New contributors should be welcomed to the community by existing members, helped with review workflow, and directed to relevant documentation and communication channels.
Established community members are expected to demonstrate their adherence to the principles in this document, familiarity with project organization, roles, policies, procedures, conventions, etc., and technical and/or writing ability. Role-specific expectations, responsibilities, and requirements are enumerated below.
Members are continuously active contributors in the community. They can have issues and reviews assigned to them, participate in design reviews through Gerrit, and pre-submit tests are automatically run for their reviews. Members are expected to remain active contributors to the community.
Defined by: Listed on a current contributor license agreement.
- Have made multiple contributions to the project or community. Contribution may
include, but is not limited to:
- Authoring or reviewing code reviews on Gerrit
- Filing or commenting on issues on GitHub
- Contributing to design review, subproject, or community discussions (e.g. meetings, Discord, mailing list discussions)
- Subscribed to the mailing list
- Have read the contributor guide
- Actively contributing to 1 or more subprojects.
- Submit a CLA
Designated Reviewers are capable of reviewing code for quality and correctness on some part of a subproject. They are knowledgeable about both the codebase and software engineering principles.
Defined by: reviewers entry in an OWNERS file in a repo owned by the OpenBMC project.
Reviewer status is scoped to a part of the codebase.
Note: Acceptance of code contributions requires at least one approver in addition to the assigned reviewers.
The following apply to the part of the codebase for which one would be a reviewer in an [OWNERS] file.
- Member for at least 3 months
- Primary reviewer for at least 5 changes to the codebase
- Reviewed or merged at least 5 substantial changes to the codebase
- Knowledgeable about the codebase
- Sponsored by a subproject approver
- With no objections from other approvers
- Done through PR to update the OWNERS file
- May either self-nominate or be nominated by an approver in this subproject.
The following apply to the part of codebase for which one would be a reviewer in an [OWNERS] file.
- Code reviewer status may be a precondition to accepting large code contributions
- Responsible for project quality control via code reviews
- Focus on code quality and correctness, including testing and factoring
- May also review for more holistic issues, but not a requirement
- Expected to be responsive to review requests as per community expectations
- Assigned changes to review related to subproject of expertise
- Assigned test bugs related to subproject of expertise
Platform maintainers are able to review configuration changes for quality and correctness on meta layers and subsystems that apply to a single platform. They are knowledgeable about the specific constraints on a given platform, and have access to an instance of said platform to test.
Defined by: owners entry in an OWNERS file in a machine meta layer in the main OpenBMC repository.
The following apply to the part of codebase for which one would be a platform owner in an [OWNERS] file.
- Member for at least 3 months
- Primary reviewer for at least 5 reviews to the codebase
- Knowledgeable about the specific platforms constraints
- Access to a platform to test and run code
- Demonstrated knowledge of bitbake metadata
- Sponsored by a root approver from openbmc/openbmc OWNERS file
- With no objections from other approvers
- Done through PR to update the OWNERS file
- May either self-nominate or be nominated by an approver in this subproject.
The following apply to the part of codebase for which one would be a reviewer in an [OWNERS] file.
- Having an owner with platform maintainer status may be a precondition to accepting a new platform
- Responsible for platform stability
- Testing on a regular cadence (base expectation is every quarter)
- Providing results and insight to the community on platform-specific issues.
- Expected to be responsive to review requests as per community expectations
- Assigned changes to review and test related to the platform
- Communicating with the technical-oversight-forum any long-term (> 1 month) absences, or resignation of these responsibilities, through a change to the [OWNERS] file.
Code approvers are able to both review and approve code contributions. While code review is focused on code quality and correctness, approval is focused on holistic acceptance of a contribution including: backwards / forwards compatibility, adhering to API conventions, subtle performance and correctness issues, interactions with other parts of the system, etc.
Defined by: owners entry in an OWNERS file in a repo owned by the OpenBMC project.
Approver status is scoped to a part of the codebase.
The following apply to the part of the codebase for which one would be an approver in an [OWNERS] file.
- Reviewer of the codebase for at least 9 months
- Primary reviewer for at least 10 substantial changes to the codebase
- Reviewed or merged at least 30 changes to the codebase
- Access to a suitable platform environment
- Nominated by two subproject or TOF root owner sponsors
- With no objections from other subproject owners
- Done through PR to update the subprojects top-level OWNERS file
- Note the following expectations for sponsors:
- Sponsors must have close interactions with the prospective member - e.g. code/design/proposal review, coordinating on issues, etc.
- Sponsors must be approver in at least one subproject.
- Sponsors must be from multiple member companies to demonstrate integration across community.
The following apply to the part of the codebase for which one would be an approver in an [OWNERS] file.
- Approver status may be a precondition to accepting large code contributions
- Demonstrate sound technical judgement
- Responsible for project quality control via code reviews
- Focus on holistic acceptance of contribution such as dependencies with other features, backwards / forwards compatibility, API and flag definitions, etc
- Maintain a codebase that is free from unnecessary or unused code, and remove previous contributions that are no longer used and/or maintained.
- Expected to be responsive to review requests as per community expectations
- Mentor contributors and reviewers
- May approve code contributions for acceptance
Note: This is a generalized high-level description of the role, and the specifics of the subproject owner role's responsibilities and related processes may be more specific for individual subprojects, as defined in their respective OWNERS files.
Subproject Owners are the technical authority for a subproject in the OpenBMC project. They MUST have demonstrated both good judgement and responsibility towards the health of that subproject. Subproject Owners MUST set technical direction and make or approve design decisions for their subproject - either directly or through delegation of these responsibilities.
Defined by: owners entry in subproject [OWNERS]
The per-repository requirements for becoming an subproject Owner should be defined in the OWNERS file of the subproject. Unlike the roles outlined above, the Owners of a subproject are typically limited to a relatively small group of decision makers and updated as fits the needs of the subproject.
The following apply to the subproject for which one would be an owner.
- Deep understanding of the technical goals and direction of the subproject
- Deep understanding of the technical domain of the subproject
- Sustained contributions to design and direction by doing all of:
- Authoring and reviewing proposals
- Initiating, contributing and resolving discussions (emails, GitHub issues, meetings)
- Identifying subtle or complex issues in designs and implementation reviews
- Ensure through testing that the subproject is functional on one or more platforms
- Directly contributed to the subproject through implementation and/or review
- Meet all subproject specific requirements outlined in the OWNERS file
The following apply to the subproject for which one would be an owner.
- Make and approve technical design decisions for the subproject.
- Set technical direction and priorities for the subproject.
- Mentor and guide approvers, reviewers, and contributors to the subproject.
- Ensure continued health of subproject
- Adequate test coverage to confidently release
- Tests are present and passing reliably (i.e. not flaky) and are fixed when they fail
- Ensure a healthy process for discussion and decision making is in place.
- Work with other subproject owners to maintain the project's overall health and success holistically.
- Keep abreast of technical changes to the overall project and maintain and/or delegate maintenance of the subproject to keep it aligned with the overall project.
The Technical Oversight Forum is the technical authority for the OpenBMC project. They MUST have demonstrated both good judgement and responsibility towards the health of the OpenBMC project and be elected by the community. TOF Members MUST set technical direction and make or approve design decisions for the project, ensure adherence to the rules in this document and others, and promote engagement with the open source community at large.
Defined by: TOF membership in docs repository
- Deep understanding of the technical goals and direction of the project
- Knowledge of community members, technical experts within and outside the project, along with a history of engagement.
- Deep understanding of the technical domain of OpenBMC and BMCs in general.
- Sustained contributions to design and direction by doing all of:
- Authoring, reviewing, and voting on proposals to the technical-oversight-forum repository
- Initiating, contributing and resolving discussions that involve project-wide changes and expectations (emails, GitHub issues, meetings)
- Identifying subtle or complex issues in designs and implementation that occur cross-project.
- Ensure through testing that the project is functional (to the extent possible) for all platforms
- Ensure that coding standards, project norms, and community guidelines are documented and adhered to throughout the project.
- Directly contributed to the project through implementation and/or review
- Make and approve technical design decisions for OpenBMC.
- Define milestones and releases.
- Mentor and guide approvers, reviewers, and contributors to the project.
- Create new subprojects, and ensure their addition continues the growth and health of the project.
- Define and maintain a healthy process for discussion and decision making.
- Work with subproject owners and platform maintainers to maintain the project's overall health and success holistically.