diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a91d53d7acc..f519ccf852b 100644 --- a/CONTRIBUTING.md +++ b/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) diff --git a/Documentation/contributor-guide/community-membership.md b/Documentation/contributor-guide/community-membership.md new file mode 100644 index 00000000000..c050e3a3b84 --- /dev/null +++ b/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 \ No newline at end of file diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 8b7cad3b5aa..799d5fd5468 100644 --- a/GOVERNANCE.md +++ b/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 - -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 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. +## Roles and responsibilities +Etcd project roles along with their requirements and responsibilities are defined +in [community membership]. ## 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