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>
This commit is contained in:
Marek Siarkowicz
parent
e11a32366e
commit
b4c1fb14e3
@ -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)
|
||||
|
||||
|
||||
151
Documentation/contributor-guide/community-membership.md
Normal file
151
Documentation/contributor-guide/community-membership.md
Normal file
@ -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
|
||||
@ -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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user