forked from etcd-io/etcd
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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 <[email protected]>
- Loading branch information
Showing
3 changed files
with
163 additions
and
71 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
151 changes: 151 additions & 0 deletions
151
Documentation/contributor-guide/community-membership.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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 [[email protected]] | ||
| - 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 [[email protected]] | ||
| - 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 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -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 `[email protected]`. | ||
|
|
||
|
|
@@ -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 | ||