Add community membership document
This is largely based on the k8s document, with modifications to add
"platform maintainer" as a title.
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: If33dc13d1810822f319bbc5c8140635ab3d181d9
diff --git a/community-membership.md b/community-membership.md
new file mode 100644
index 0000000..2d858ef
--- /dev/null
+++ b/community-membership.md
@@ -0,0 +1,282 @@
+# Community membership
+
+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 |
+| 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
+
+[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
+
+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.
+
+## Member
+
+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.
+
+### Expectations
+
+- 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]**
+
+## Reviewer
+
+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.
+
+### Expectations
+
+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.
+
+### Responsibilities and privileges
+
+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 Maintainer
+
+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].
+
+### Expectations
+
+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.
+
+### Responsibilities and privileges
+
+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
+
+## Approver
+
+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.
+
+### Expectations
+
+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.
+
+### Responsibilities and privileges
+
+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
+
+## Subproject Owner
+
+**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]
+
+### Expectations
+
+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
+
+### Responsibilities and privileges
+
+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.
+
+## Technical Oversight Forum Member
+
+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
+
+### Expectations
+
+- 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
+
+### Responsibilities and privileges
+
+- 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.
+
+[new contributors]: /CONTRIBUTING.md#starting-out
+[code reviews]: https://gerrit.openbmc.org/
+[mailing list]: https://lists.ozlabs.org/listinfo/openbmc
+[main OpenBMC repository]: https://github.com/openbmc/openbmc
+[community expectations]: /code-of-conduct.md
+[submit a cla]: /CONTRIBUTING.md#starting-out
+[contributor guide]: /CONTRIBUTING.md
+[tof election cycle]: /tof/membership-and-voting.md