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

1 files changed, 197 insertions, 69 deletions

diff --git a/community-membership.md b/community-membership.md
index 54ed5514..c3986bf1 100644
--- a/community-membership.md
+++ b/community-membership.md
@@ -1,77 +1,205 @@
 # Community membership
 
-New community members:
-
-- [**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:
+**Note:** 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.
+
+| 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
\ No newline at end of file
+## 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