kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Flesh out community membership roles. 

- Reduce bar for org membership
- Summarize and provide additional descriptions for roles
- Refactor membership doc to explicitly define requirements vs responsibilities and make wording consistent
- Delete a bit of the New contributor role that overlaps with org membership
This commit is contained in:
Phillip Wittrock 2017-05-19 14:14:31 -07:00
parent dcd3a84473
commit 19faafdeb3
1 changed files with 196 additions and 68 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

264
community-membership.md
View File

@ -1,77 +1,205 @@
# Community membership
New community members:
**Note:** In progress
- [**New Contributor**](https://github.com/kubernetes/contrib/issues/1090): a
couple of PRs; should be welcomed to the community, helped with PR workflow, and
directed to relevant documentation
- **Active Contributor**: at least 3 merged and/or assigned PRs (which could include documentation
contributions as well as code), including one in the past month; we have
[expectations](contributors/devel/community-expectations.md)
that frequent contributors will assist in our code-review process and with project
maintenance
Established community members:
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.
| Role | Responsibilities | Requirements | Defined by |
| -----| ---------------- | ------------ | -------|
| member | active contributor in the community | sponsored by 2 members. Already active | outside collaborator to [Kubernetes repo](https://github.com/kubernetes/kubernetes) with read access. |
| reviewer | review contribution from other members | history of review and authorship in an area | OWNERS file reviewer entry. Kubernetes GitHub org member. |
| 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 god 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 |
## New contributors
[**New contributors**](https://github.com/kubernetes/contrib/issues/1090) should be welcomed to the community
by existing members, helped with PR 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**: an active contributor for at least 3 months; at least 10 merged and/or assigned PRs; active enough to be useful
to assign issues to them and add them to a github team (e.g., for a SIG) for notification
purposes; trusted enough to run tests on their PRs automatically; can issue "@k8s-bot ok to test"
for other contributors; if they choose public membership, they get a badge on their github profile;
should subscribe to kubernetes-dev@googlegroups.com; expected to be familiar with
project organization, roles, policies, procedures, etc.; should read the [developer
guide](contributors/devel/README.md); must enable
[two-factor authentication](https://help.github.com/articles/about-two-factor-authentication/)
- **Reviewer**: org member for at least 3 months; at least 20 merged and/or assigned PRs, including
at least 3 as the primary reviewer; familiar enough with some part of the codebase to be in some
[OWNERS](contributors/devel/owners.md) file as a reviewer (in repos using the bot),
assigned related PRs, assigned relevant test bugs; responsible for project quality control via
[code reviews](contributors/devel/collab.md); expected to be responsive to
review requests as per [community expectations](contributors/devel/community-expectations.md);
can champion incubator repos; must be nominated by an approver for that part of the codebase,
with no objections from other approvers; should be added to
[`kubernetes-reviewers`](https://github.com/orgs/kubernetes/teams/kubernetes-reviewers);
"read access" to kubernetes repo; get a badge on PR and issue comments; may be asked to
become a reviewer as a precondition for accepting a large code contribution
- **Approver**: in some [OWNERS](contributors/devel/owners.md) file as an approver, which
will be needed to get code merged; previously a reviewer for that part of the
codebase for at least 3 months; at least 30 merged and/or assigned PRs, including at least 10 as
the primary reviewer; expected to be responsive to review requests as per
[community expectations](contributors/devel/community-expectations.md); expected to
mentor contributors and reviewers; demonstrated sound technical judgement; nominated
by an area/component owner, with no objections from other owners; may be asked to
become an approver as a precondition for accepting a large code contribution
- **Area/Component Owner**: in top-level [OWNERS](contributors/devel/owners.md) file for
some area/component as an approver; design/proposal approval authority for some area
of the project, though escalation is still possible; expected to mentor and guide approvers,
reviewers, and other contributors; may be asked to become an area/component owner as a precondition
for accepting the contribution of a new component or other major function
- [**kubernetes-maintainers**](https://github.com/orgs/kubernetes/teams/kubernetes-maintainers):
approver for some part of the codebase for at least 3 months; on project for at least 1 year;
at least 50 merged and/or assigned PRs, including at least 20 as the primary reviewer;
write access to repo (assign issues/PRs, add/remove labels and milestones, edit issues and PRs, edit wiki,
create/delete labels and milestones); technically can lgtm any PR and cause it
to be merged by the submit queue, but expected to respect OWNERS files; expected to review PRs, fix bugs, maintain and
improve health and quality of the project, provide user support, mentor and guide approvers,
reviewers, and other contributors; must apply to `kubernetes-maintainers@googlegroups.com`, with a
[Champion](https://github.com/kubernetes/community/blob/master/incubator.md#faq) from the existing
kubernetes-maintainers members and a Sponsor from Project Approvers, with a summary
of contributions to the project, current project responsibilities, and links to merged and assigned PRs;
at least 3 of the maintainers must approve the application, with no objections; the application
expires after 2 weeks if not enough approvals are granted
- **Project Approvers**: approver in [top-level OWNERS file in kubernetes repo](https://github.com/kubernetes/kubernetes/blob/master/OWNERS);
de-facto project decision makers; technically can
approve virtually any PRs; can sponsor incubator repos; can sponsor maintainers;
maintainer in good standing for at least 1 year; strong technical vision;
committed to project's mission and culture; nomination/application process TBD
- [**API Approver**](https://github.com/orgs/kubernetes/teams/api-approvers):
lead designers of the project, who are familiar with the
design, requirements, mechanics, conventions, style, scope, gotchas, etc.
of the API; most beta/GA API changes are vetted by the API approvers
- [**API Reviewer**](https://github.com/orgs/kubernetes/teams/api-reviewers):
contributors familiar with design, requirements, mechanics, conventions, style,
scope, gotchas, etc. of the API; have written and/or reviewed Kubernetes APIs
## Member
**Note:** The member role is not finalized and there is some debate about whether a member should be a GitHub org member
(with greater requirements and responsibilities), or outside collaborators (with fewer requirements and responsibilities).
Members can have issues and PRs assigned to them and participate in SIGs.
Members are expected to remain active contributors to the community.
**Defined by:** [Kubernetes](https://github.com/kubernetes/kubernetes) repo outside collaborator
(read access) on GitHub
### Requirements
- Enabled [two-factor authentication](https://help.github.com/articles/about-two-factor-authentication/) on their GitHub account
- Have contributed 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, Stackoverflow, meetups)
- Sponsored by 2 members
- TODO: Define the exact process for sponsorship.
- Have read the [developer guide](contributors/devel/README.md)
- Subscribed to [`kubernetes-dev@googlegroups.com`](https://groups.google.com/forum/#!forum/kubernetes-dev)
- Some idea of what they intend to work on
TODO: Define a process for reviewing memberships.
### Responsibilities and privileges
- Responsive to issues and PRs assigned to them
- Active owner of code they have contributed (until ownership is transferred)
- Code is well tested
- Tests consistently pass
- 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.
## Reviewer
Reviewers are able to review code for quality and correctness on some part of the project.
They are knowledgeable about both the codebase and software engineering principles.
**Defined by:** *reviewer* entry in an OWNERS file in the kubernetes codebase. Kubernetes GitHub org member.
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).
- member for at least 3 months
- Responsive to mentions of SIG teams they are members of
- 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
- 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
### 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).
- 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)
- 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)
- Granted "read access" to kubernetes repo
- Can champion incubator repos
- 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:** *approver* entry in an OWNERS file in the kubernetes codebase
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).
- 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
- 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).
- 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/devel/community-expectations.md);
- Mentor contributors and reviewers
- May approve code contributions for acceptance
## 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.
**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.
### Requirements
The following apply to the area / component for which one would be an owner.
- Originally authored or contributed major functionality to an area
- An approver in the **top-level** [OWNERS](contributors/devel/owners.md) files
### Responsibilities and privileges
The following apply to the area / component for which one would be an owner.
- 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.
## Maintainer
[**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.
**Defined by:** *write* access to the kubernetes GitHub repo
TODO: Determine if this role is outdated and needs to be redefined or merged into owner role.
### Requirements
- 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](https://github.com/kubernetes/community/blob/master/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
### Responsibilities and privileges
- 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