New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify membership ladder #1861

Merged
merged 3 commits into from Mar 6, 2018
Jump to file or symbol
Failed to load files and symbols.
+84 −86
Diff settings

Always

Just for now

Copy path View file
@@ -3,21 +3,19 @@
**Note:** This document is in progress
This doc outlines the various responsibilities of contributor roles in Kubernetes. The Kubernetes
project is subdivided into various sub-areas. Responsibilities for many contributor roles are
scoped by these sub-areas.
project is subdivided into subprojects under SIGs. Responsibilities for most roles is scoped to these subprojects.
| Role | Responsibilities | Requirements | Defined by |
| -----| ---------------- | ------------ | -------|
| member | active contributor in the community | sponsored by 2 reviewers. multiple contributions to the project. | Kubernetes GitHub org member. |
| reviewer | review contribution from other members | history of review and authorship in an area | OWNERS file reviewer entry. |
| approver | approve accepting contributions | highly experienced and active reviewer + contributor to an area | OWNERS file approver entry|
| owner | set priorities and approve proposals | demonstrated responsibility and good judgement for entire area | OWNERS file approver entries for entire area. "# owner" comment next to entry. |
| maintainer | cross area ownership of project health | highly experienced contributor active in multiple areas and roles. | GitHub repo write access |
| 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 judgement for the subproject | [sigs.yaml] subproject [OWNERS] file *owners* entry |
## New contributors
[**New contributors**](https://github.com/kubernetes/community/blob/master/CONTRIBUTING.md) should be welcomed to the community
by existing members, helped with PR workflow, and directed to relevant documentation and communication channels.
[New contributors] should be welcomed to the community by existing members, helped with PR workflow, and directed to
relevant documentation and communication channels.
## Established community members
@@ -36,26 +34,30 @@ Members are expected to remain active contributors to the community.
### Requirements
- Enabled [two-factor authentication](https://help.github.com/articles/about-two-factor-authentication/) on their GitHub account
- 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 commenting on issues on GitHub
- Contributing to SIG or community discussions (e.g. meetings, Slack, email discussion forums, Stack Overflow)
- Subscribed to [`kubernetes-dev@googlegroups.com`](https://groups.google.com/forum/#!forum/kubernetes-dev)
- Are actively contributing to 1 or more areas.
- Contributing to SIG, subproject, or community discussions (e.g. meetings, Slack, email discussion
forums, Stack Overflow)
- Subscribed to [kubernetes-dev@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 (in any repo in the Kubernetes GitHub organization)
- 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 (in any repo in the Kubernetes GitHub
organization)
- Sponsors must be from multiple member companies to demonstrate integration across community.
- Send an email to *kubernetes-membership@googlegroups.com* with:
- CC: your sponsors on the message
- Subject: `REQUEST: New membership for <your-GH-handle>`
- Body: Confirm that you have joined kubernetes-dev@googlegroups.com (e.g. `I have joined kubernetes-dev@googlegroups.com`)
- Body: Confirm that you have joined kubernetes-dev@googlegroups.com (e.g. `I have joined
kubernetes-dev@googlegroups.com`)
- Body: GitHub handles of sponsors
- Body: List of contributions (PRs authored / reviewed, Issues responded to, etc)
- Have your sponsoring reviewers reply confirmation of sponsorship: `+1`
- Wait for response to the message
- Have read the [developer guide](contributors/devel/README.md)
- Have read the [developer guide]
Example message:
@@ -90,49 +92,47 @@ List of contributions:
- Addresses bugs or issues discovered after code is accepted
**Note:** members who frequently contribute code are expected to proactively perform code reviews and work towards
becoming a primary *reviewer* for the area that they are active in.
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 the project.
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:** *reviewer* entry in an OWNERS file in the Kubernetes codebase.
**Defined by:** *reviewers* entry in an OWNERS file in a repo owned by the Kubernetes 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](contributors/devel/owners.md) file (for repos using the bot).
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 an area approver
- 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 area, or be nominated by a robot
- 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](contributors/devel/owners.md) file (for repos using the bot).
The following apply to the part of codebase for which one would be a reviewer in an [OWNERS] file
(for repos using the bot).
- Tests are automatically run for PullRequests from members of the Kubernetes GitHub organization
- Code reviewer status may be a precondition to accepting large code contributions
- Responsible for project quality control via [code reviews](contributors/devel/collab.md)
- 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](contributors/devel/community-expectations.md)
- Assigned PRs to review related to area of expertise
- Assigned test bugs related to area of expertise
- Added to [`kubernetes-reviewers`](https://github.com/orgs/kubernetes/teams/kubernetes-reviewers)
- Expected to be responsive to review requests as per [community expectations]
- Assigned PRs to review related to subproject of expertise

This comment has been minimized.

@bgrant0607

bgrant0607 Mar 1, 2018

Member

I think this was a search&replace snafu. Revert subproject to area here and on the next line.

- Assigned test bugs related to subproject of expertise
- Granted "read access" to kubernetes repo
- Can champion incubator repos
- May get a badge on PR and issue comments
## Approver
@@ -142,91 +142,89 @@ code quality and correctness, approval is focused on holistic acceptance of a co
backwards / forwards compatibility, adhering to API and flag conventions, subtle performance and correctness issues,
interactions with other parts of the system, etc.
**Defined by:** *approver* entry in an OWNERS file in the kubernetes codebase
**Defined by:** *approvers* entry in an OWNERS file in a repo owned by the Kubernetes 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](contributors/devel/owners.md) file (for repos using the bot).
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 an area/component owner
- With no objections from other owners
- 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](contributors/devel/owners.md) file (for repos using the bot).
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 judgement
- Responsible for project quality control via [code reviews](contributors/devel/collab.md)
- 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](contributors/guide/community-expectations.md);
- 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
## Owner
## Subproject Owner
Owners of an area / component are approvers of an entire area that have demonstrated good judgement and
responsibility. Owners accept design proposals and approve design decisions for their area of ownership.
**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 SIGs or subprojects.
**Defined by:** *approver* entry in the top-level OWNERS file for the area in the kubernetes codebase.
May have a comment (e.g. `# owner`) next to the approver entry indicating that the individual is an owner.
Subproject Owners are the technical authority for a subproject in the Kubernetes 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.
### Requirements
The following apply to the area / component for which one would be an owner.
**Defined by:** *owners* entry in subproject [OWNERS] files as defined by [sigs.yaml] *subproject.owners*
- Originally authored or contributed major functionality to an area
- An approver in the **top-level** [OWNERS](contributors/devel/owners.md) files
### Responsibilities and privileges
### Requirements
The following apply to the area / component for which one would be an owner.
The process for becoming an subproject Owner should be defined in the SIG charter of the SIG owning
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.
- Owner status may be a precondition to accepting a new component or piece of major functionality
- Design/proposal approval authority over the area / component, though escalation to [`kubernetes-maintainers`](https://groups.google.com/forum/#!forum/kubernetes-maintainers) is possible.
- Mentor and guide approvers, reviewers, and members.
The following apply to the subproject for which one would be an owner.
## Maintainer
- 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
[**Kubernetes project maintainers**](https://github.com/orgs/kubernetes/teams/kubernetes-maintainers) work holistically
across the project to maintain its health and success. They are typically involved in multiple different areas, and
have made substantial contributions both through code and broader organizational efforts.
### Responsibilities and privileges
**Defined by:** *write* access to the kubernetes GitHub repo
The following apply to the subproject for which one would be an owner.
TODO: Determine if this role is outdated and needs to be redefined or merged into owner role.
- 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
### Requirements
## ~~Maintainer~~
- Approver for some part of the codebase for at least 3 months
- Member for at least 1 year
- Primary reviewer for 20 substantial PRs
- Reviewed or merged at least 50 PRs
- Apply to [`kubernetes-maintainers`](https://github.com/orgs/kubernetes/teams/kubernetes-maintainers), with:
- A [Champion](/incubator.md#faq) from the existing
kubernetes-maintainers members
- A Sponsor from Project Approvers
- Summary of contributions to the project
- Current project responsibilities
- Links to merged and assigned PRs
- At least 3 of the maintainers must approve the application, with no objections
- Application expires after 2 weeks if not enough approvals are granted
**Status:** Removed
### Responsibilities and privileges
The Maintainer role has been removed and replaced with a greater focus on [owner](#owner)s.
- Write access to repo (assign issues/PRs, add/remove labels and milestones, edit issues and PRs, edit wiki, create/delete labels and milestones)
- Capable of directly applying lgtm + approve labels for any PR, causing it to be merged by the submit queue - but permitted only in rare instances
- Expected to respect OWNERS files approvals and use standard procedure for merging code
- Expected to work to holistically maintain the health of the project through:
- Reviewing PRs
- Fixing bugs
- Providing user support
- Mentoring and guiding approvers, reviewers, and other contributors
[code reviews]: contributors/devel/collab.md
[community expectations]: contributors/devel/community-expectations.md
[developer guide]: contributors/devel/README.md
[two-factor authentication]: https://help.github.com/articles/about-two-factor-authentication
[kubernetes-dev@googlegroups.com]: https://groups.google.com/forum/#!forum/kubernetes-dev
[sigs.yaml]: community/sigs.yaml
[New contributors]: https://github.com/kubernetes/community/blob/master/CONTRIBUTING.md
[OWNERS]: contributors/guide/owners.md
ProTip! Use n and p to navigate between commits in a pull request.