Move to community membership model closer to kubernetes one

Based on https://github.com/kubernetes/community/blob/master/community-membership.md

Changes:
* Extracted contributor membership to separate file
* Provide more detailed requirements for each role. Base maintainers on
  kubernetes subproject owners.
* Introduction of member role

Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>

CONTRIBUTING.md

@@ -21,7 +21,7 @@ Before making a change please look through resources below to learn more about e
 
 * Please learn about [Git](https://github.com/git-guides) version control system used in etcd.
 * Read the [etcd learning resources](https://etcd.io/docs/v3.5/learning/)
-* Read the [etcd contributing guides](https://github.com/etcd-io/etcd/tree/main/Documentation/contributor-guide)
+* Read the [etcd community membership](/Documentation/contributor-guide/community-membership.md)
 * Watch [etcd deep dive](https://www.youtube.com/watch?v=D2pm6ufIt98&t=927s)
 * Watch [etcd code walk through](https://www.youtube.com/watch?v=H3XaSF6wF7w)
 

Documentation/contributor-guide/community-membership.md

@@ -0,0 +1,151 @@
+# Community membership
+
+This doc outlines the various responsibilities of contributor roles in etcd. 
+
+| Role       | Responsibilities                             | Requirements                                                  | Defined by                           |
+|------------|----------------------------------------------|---------------------------------------------------------------|--------------------------------------|
+| Member     | Active contributor in the community          | Sponsored by 2 reviewers and multiple contributions           | etcd GitHub org member               |
+| Reviewer   | Review contributions from other members      | History of review and authorship                              | [MAINTAINERS] file reviewer entry    |
+| Maintainer | Set direction and priorities for the project | Demonstrated responsibility and excellent technical judgement | [MAINTAINERS] file maintainers 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.
+
+## 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. Members are expected to remain active 
+contributors to the community.
+
+**Defined by:** Member of the etcd GitHub organization
+
+### Requirements
+
+- Have made multiple contributions to the project or community.  Contribution may include, but is not limited to:
+    - Authoring or reviewing PRs on GitHub. At least one PR must be **merged**.
+    - Filing or commenting on issues on GitHub
+    - Contributing to community discussions (e.g. meetings, Slack, email discussion
+      forums, Stack Overflow)
+- Subscribed to [etcd-dev@googlegroups.com]
+- Have read the [contributor guide]
+- Sponsored by one active maintainer or two reviewers.
+    - Sponsors must be from multiple member companies to demonstrate integration across community.
+    - With no objections from other maintainers
+- Members can be removed by a supermajority of the maintainers or can resign by notifying
+  the maintainers.
+
+### Responsibilities and privileges
+
+- Responsive to issues and PRs assigned to them
+- Granted "triage access" to etcd project
+- 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
+
+**Note:** members who frequently contribute code are expected to proactively
+perform code reviews and work towards becoming a *reviewer*.
+
+## Reviewers
+
+Reviewers are contributors who have demonstrated greater skill in
+reviewing the code from other contributors. They are knowledgeable about both 
+the codebase and software engineering principles. Their LGTM counts towards
+merging a code change into the project. A reviewer is generally on the ladder towards
+maintainership. 
+
+**Defined by:** *reviewers* entry in the [MAINTAINERS] file.
+
+### Requirements
+
+- member for at least 3 months.
+- Primary reviewer for at least 5 PRs to the codebase.
+- Reviewed or contributed at least 20 substantial PRs to the codebase.
+- Knowledgeable about the codebase.
+- Sponsored by two active maintainers.
+    - Sponsors must be from multiple member companies to demonstrate integration across community.
+    - With no objections from other maintainers
+- Reviewers can be removed by a supermajority of the maintainers or can resign by notifying
+  the maintainers.
+
+### Responsibilities and privileges
+
+- 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
+- Assigned PRs to review related to area of expertise
+- Assigned test bugs related to area of expertise
+- Granted "triage access" to etcd project
+
+## Maintainers
+
+Maintainers are first and foremost contributors that have shown they
+are committed to the long term success of a project. Maintainership is about building
+trust with the current maintainers and being a person that they can
+depend on to make decisions in the best interest of the project in a consistent manner.
+
+**Defined by:** *maintainers* entry in the [MAINTAINERS] file.
+
+### Requirements
+
+- Deep understanding of the technical goals and direction of the project
+- Deep understanding of the technical domain of the project
+- 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 project through implementation and / or review
+- Subscribed to [etcd-maintainers@googlegroups.com]
+- Elected by supermajority of active maintainers.
+
+### Responsibilities and privileges
+
+- Make and approve technical design decisions
+- Set technical direction and priorities
+- Define milestones and releases
+- Mentor and guide reviewers, and contributors to the project.
+- Participate when called upon in the [security disclosure and release process]
+- Ensure continued health of the project
+    - 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 maintainers to maintain the project's overall health and success holistically
+
+### Retiring
+
+Life priorities, interests, and passions can change. Maintainers can retire and
+move to [emeritus maintainers]. If a maintainer needs to step down, they should
+inform other maintainers, if possible, help find someone to pick up the related
+work. At the very least, ensure the related work can be continued. Afterward
+they can remove themselves from list of existing maintainers.
+
+If a maintainer has not been performing their duties for period of 12 months,
+they can be removed by other maintainers. In that case inactive maintainer will
+be first notified via an email. If situation doesn't improve, they will be
+removed. If an emeritus maintainer wants to regain an active role, they can do
+so by renewing their contributions. Active maintainers should welcome such a move.
+Retiring of other maintainers or regaining the status should require approval
+of at least two active maintainers.
+
+## Acknowledgements
+
+Contributor roles and responsibilities were written based on [Kubernetes community membership]
+
+[MAINTAINERS]: /MAINTAINERS
+[contributor guide]: /CONTRIBUTING.md
+[Kubernetes community membership]: https://github.com/kubernetes/community/blob/master/community-membership.md
+[emeritus maintainers]: /README.md#etcd-emeritus-maintainers
+[security disclosure and release process]: /security/README.md

GOVERNANCE.md

@@ -5,84 +5,20 @@
 The etcd community adheres to the following principles:
 
 - Open: etcd is open source.
-- Welcoming and respectful: See [Code of Conduct](code-of-conduct.md).
+- Welcoming and respectful: See [Code of Conduct].
 - Transparent and accessible: Changes to the etcd code repository and CNCF related
 activities (e.g. level, involvement, etc) are done in public.
 - Merit: Ideas and contributions are accepted according to their technical merit for
 the betterment of the project. For specific guidance on practical contribution steps
-please see [CONTRIBUTING](./CONTRIBUTING.md) guide.
+please see [contributor guide] guide.
 
-## Maintainers
+## Roles and responsibilities
-
+Etcd project roles along with their requirements and responsibilities are defined
-Maintainers are first and foremost contributors that have shown they
+in [community membership].
-are committed to the long term success of a project. Maintainership is about building
-trust with the current maintainers of the project and being a person that they can
-depend on to make decisions in the best interest of the project in a consistent manner.
-The maintainers role can be a top-level or restricted to certain package/feature
-depending upon their commitment in fulfilling the expected responsibilities as explained
-below.
-
-### Top-level maintainer
-
-- Running the etcd release processes
-- Ownership of test and debug infrastructure
-- Triage GitHub issues to keep the issue count low (goal: under 100)
-- Regularly review GitHub pull requests across all pkgs
-- Providing cross pkg design review
-- Monitor email aliases
-- Participate when called upon in the [security disclosure and release process](security/README.md)
-- General project maintenance
-
-### Package/feature maintainer
-
-- Ownership of test and debug failures in a pkg/feature
-- Resolution of bugs triaged to a package/feature
-- Regularly review pull requests to the pkg subsystem
-
-### Nomination and retiring of maintainers
-
-[Maintainers](./MAINTAINERS) file on the `main` branch reflects the latest
-state of project maintainers. List of existing maintainers should be kept up to
-date by existing maintainers to properly reflect community health and to gain
-better understanding of recruiting need for new maintainers. Changes to list of
-maintainers should be done by opening a pull request and CCing all the existing
-maintainers.
-
-Contributors who are interested in becoming a maintainer, if performing relevant
-responsibilities, should discuss their interest with the existing maintainers.
-New maintainers must be nominated by an existing maintainer and must be elected
-by a supermajority of maintainers with a fallback on lazy consensus after three
-business weeks inactive voting period and as long as two maintainers are on board.
-
-Life priorities, interests, and passions can change. Maintainers can retire and
-move to the [emeritus status](./README.md#etcd-emeritus-maintainers). If a
-maintainer needs to step down, they should inform other maintainers, if possible,
-help find someone to pick up the related work. At the very least, ensure the
-related work can be continued. Afterward they can remove themselves from list of
-existing maintainers.
-
-If a maintainer is not been performing their duties for period of 12 months,
-they can be removed by other maintainers. In that case inactive maintainer will
-be first notified via an email. If situation doesn't improve, they will be
-removed. If an emeritus maintainer wants to regain an active role, they can do
-so by renewing their contributions. Active maintainers should welcome such a move.
-Retiring of other maintainers or regaining the status should require approval
-of at least two active maintainers.
-
-## Reviewers
-
-[Reviewers](./MAINTAINERS) are contributors who have demonstrated greater skill in
-reviewing the code contribution from other contributors. Their LGTM counts towards
-merging a code change into the project. A reviewer is generally on the ladder towards
-maintainership. New reviewers must be nominated by an existing maintainer and must be
-elected by a supermajority of maintainers with a fallback on lazy consensus after three
-business weeks inactive voting period and as long as two maintainers are on board.
-Reviewers can be removed by a supermajority of the  maintainers or can resign by notifying
-the maintainers.
 
 ## Decision making process
 
-Decisions are built on consensus between maintainers publicly. Proposals and ideas
+Decisions are built on consensus between [maintainers] publicly. Proposals and ideas
 can either be submitted for agreement via a GitHub issue or PR, or by sending an email
 to `etcd-maintainers@googlegroups.com`.
 
@@ -99,3 +35,8 @@ weeks inactive voting period and as long as two maintainers are on board.
 ## Changes in Governance
 
 Changes in project governance could be initiated by opening a GitHub PR.
+
+[community membership]: /Documentation/contributor-guide/community-membership.md
+[Code of Conduct]: /code-of-conduct.md
+[contributor guide]: /CONTRIBUTING.md
+[maintainers]: /MAINTAINERS