diff --git a/.github/ISSUE_TEMPLATE/membership.md b/.github/ISSUE_TEMPLATE/membership.md new file mode 100644 index 0000000..4ab8c1e --- /dev/null +++ b/.github/ISSUE_TEMPLATE/membership.md @@ -0,0 +1,28 @@ +--- +name: Organization Membership Request +about: Request membership in the Operator Framework Org +title: 'REQUEST: New membership for ' +labels: area/github-membership +assignees: '' + +--- + +### GitHub Username +e.g. (at)example_user + +### Requirements +- [ ] I have reviewed the community membership guidelines (https://github.com/operator-framework/community/blob/master/community-membership.md) +- [ ] I have enabled 2FA on my GitHub account (https://github.com/settings/security) +- [ ] I have subscribed to the operator-framework e-mail list (https://groups.google.com/forum/#!forum/operator-framework) +- [ ] I am actively contributing to 1 or more Operator Framework subprojects +- [ ] I have two sponsors that meet the sponsor requirements listed in the community membership guidelines +- [ ] I have spoken to my sponsors ahead of this application, and they have agreed to sponsor my application + +### Sponsors +- (at)sponsor-1 +- (at)sponsor-2 + +### List of contributions to the Operator Framework org +- PRs reviewed / authored +- Issues responded to +- Subprojects I am involved with diff --git a/community-membership.md b/community-membership.md new file mode 100644 index 0000000..a773353 --- /dev/null +++ b/community-membership.md @@ -0,0 +1,216 @@ +# Community membership + +**Note:** This document is in progress + +This doc outlines the various responsibilities of contributor roles in +Operator Framework. The Operator Framework project is subdivided into subprojects. +Responsibilities for most roles are scoped to these subprojects. + +| Role | Responsibilities | Requirements | Defined by | +| -----| ---------------- | ------------ | -------| +| member | active contributor in the community | sponsored by 2 reviewers, multiple contributions to the project | operator-framework GitHub org member. | +| reviewer | review contributions from other members | history of review and authorship in a subproject | [OWNERS] file reviewer entry. | +| approver | approve accepting contributions | highly experienced and active reviewer + contributor to a subproject | [OWNERS] file approver entry| +| subproject owner | set direction and priorities for a subproject | demonstrated responsibility and excellent technical judgment for the subproject | [sigs.yaml] subproject [OWNERS] file *owners* entry | + +## New contributors + +New contributors should be welcomed to the community by existing members, +helped with PR workflow, and directed to relevant documentation and +communication channels. + +Large code contributions by non-members is acceptable at the discretion of existing PR reviewers. + + + +## 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 PRs assigned to them and pre-submit tests are automatically run for +their PRs. Members are expected to remain active contributors to the community. + +**Defined by:** Member of the operator-framework GitHub organization + +### Requirements + +- Enabled [two-factor authentication] on their GitHub account. +- Have made multiple contributions to the project or community. Contribution may include, but is not limited to: + - Authoring or reviewing PRs on GitHub. + - Filing or helping resolve issues on GitHub. + - Contributing to subproject or community discussions (e.g. meetings, Slack, email discussion + forums, Stack Overflow). +- Subscribed to [operator-framework@googlegroups.com]. +- Actively contributing to 1 or more subprojects. +- Sponsored by 2 reviewers. **Note the following requirements for sponsors**: + - Sponsors must have close interactions with the prospective member - e.g. code/design/proposal review, coordinating + on issues, etc. + - Sponsors must be reviewers or approvers in at least 1 OWNERS file either in any repo in the [Operator Framework org], + or the org they are sponsoring for. + - An approver/reviewer in the [Operator Framework org] may sponsor someone for the [Operator Framework org] + as long as it's a project they're involved with. +- **[Open an issue][membership request] against the operator-framework/org repo** + - Ensure your sponsors are @mentioned on the issue + - Complete every item on the checklist ([preview the current version of the template][membership template]) + - Make sure that the list of contributions included is representative of your work on the project. +- Have your sponsoring reviewers reply confirmation of sponsorship: `+1` or `/lgtm` +- Once your sponsors have responded, your request will be reviewed by a operator-framework GitHub org admin. Any missing information will be requested. + +### Responsibilities and privileges + +- Responsive to issues and PRs assigned to them +- Active owner of code they have contributed (unless ownership is explicitly transferred) + - Code is well tested + - Tests consistently pass + - Addresses bugs or issues discovered after code is accepted +- Members can do `/lgtm` on open PRs. + - The applied `lgtm` label will not count towards the PR's merge-ability. +- They can be assigned to issues and PRs, and people can ask members for reviews with a `/cc @username`. +- Tests can be run against their PRs automatically. No `/ok-to-test` needed. +- Members can do `/ok-to-test` for PRs that have a `needs-ok-to-test` label, and use commands like `/close` to close PRs as well. + +**Note:** members who frequently contribute code are expected to proactively +perform code reviews and work towards becoming a primary *reviewer* for the +subproject that they are active in. + +## Reviewer + +Reviewers are able to review 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 +Operator Framework 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. + +### Requirements + +The following apply to the part of codebase for which one would be a reviewer in +an [OWNERS] file (for repos using the bot). + +- Member for at least 3 months +- Primary reviewer for at least 5 PRs to the codebase +- Reviewed or merged at least 20 substantial PRs 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, be nominated by an approver in this subproject, or be nominated by a robot + +### Responsibilities and privileges + +The following apply to the part of codebase for which one would be a reviewer in +an [OWNERS] file (for repos using the bot). + +- 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 PRs to review related to subproject of expertise +- Assigned test bugs related to subproject of expertise +- Granted "read access" to operator-framework GitHub organization +- May get a badge on PR and issue comments + +## 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 and flag conventions, subtle performance and +correctness issues, interactions with other parts of the system, etc. + +**Defined by:** *approvers* entry in an OWNERS file in a repo owned by the +Operator Framework project. + +Approver status is scoped to a part of the codebase. + +### Requirements + +The following apply to the part of codebase for which one would be an approver +in an [OWNERS] file (for repos using the bot). + +- Reviewer of the codebase for at least 3 months +- Primary reviewer for at least 10 substantial PRs to the codebase +- Reviewed or merged at least 30 PRs to the codebase +- Nominated by a subproject owner + - With no objections from other subproject owners + - Done through PR to update the top-level OWNERS file + +### Responsibilities and privileges + +The following apply to the part of codebase for which one would be an approver +in an [OWNERS] file (for repos using the bot). + +- Approver status may be a precondition to accepting large code contributions +- Demonstrate sound technical judgment +- 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 +- 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 *MUST* be defined for individual subprojects. + +Subproject Owners are the technical authority for a subproject in the Operator Framework +project. They *MUST* have demonstrated both good judgment 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:** _TODO_ + +### Requirements + +The process for becoming an subproject Owner should be defined in: _TODO_ + +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 PRs +- Directly contributed to the subproject through implementation and / or review + +### 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. +- Define milestones and releases. +- Mentor and guide approvers, reviewers, and contributors to the subproject. +- Ensure continued health of subproject + - Adequate test coverage to confidently release + - Tests are 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 + +[Operator Framework org]: https://github.com/operator-framework +[operator-framework@googlegroups.com]: https://groups.google.com/forum/#!forum/operator-framework +[membership request]: https://github.com/operator-framework/org/issues/new?template=membership.md&title=REQUEST%3A%20New%20membership%20for%20%3Cyour-GH-handle%3E +[membership template]: https://github.com/operator-framework/community/blob/master/.github/ISSUE_TEMPLATE/membership.md +[OWNERS]: https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md +[sigs.yaml]: /sigs.yaml +[two-factor authentication]: https://help.github.com/articles/about-two-factor-authentication