mirror of
https://github.com/etcd-io/etcd.git
synced 2024-09-27 06:25:44 +00:00
Merge pull request #11175 from spzala/governance
*: create project governance
This commit is contained in:
commit
236ac2a905
@ -102,6 +102,9 @@ Note that any `etcd_debugging_*` metrics are experimental and subject to change.
|
||||
- Require [*Go 1.13+*](https://github.com/etcd-io/etcd/pull/11110).
|
||||
- Compile with [*Go 1.13*](https://golang.org/doc/devel/release.html#go1.13)
|
||||
|
||||
### Project Governance
|
||||
|
||||
- The etcd team has added, a well defined and openly discussed, project [governance](https://github.com/etcd-io/etcd/pull/11175).
|
||||
|
||||
<hr>
|
||||
|
||||
|
80
GOVERNANCE.md
Normal file
80
GOVERNANCE.md
Normal file
@ -0,0 +1,80 @@
|
||||
# etcd Governance
|
||||
|
||||
## Principles
|
||||
|
||||
The etcd community adheres to the following principles:
|
||||
|
||||
- Open: etcd is open source.
|
||||
- Welcoming and respectful: See [Code of Conduct](code-of-conduct.md).
|
||||
- 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.
|
||||
|
||||
## Maintainers
|
||||
|
||||
[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
|
||||
|
||||
Contributors who are interested in becoming a maintainer, if performing these
|
||||
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. Likewise, maintainers can be removed by a supermajority
|
||||
of the maintainers and moved to emeritus status.
|
||||
|
||||
Life priorities, interests, and passions can change. If a maintainer needs to step
|
||||
down, inform other maintainers about this intention, and if possible, help find someone
|
||||
to pick up the related work. At the very least, ensure the related work can be continued.
|
||||
Afterward, create a pull request to remove yourself from the [MAINTAINERS](./MAINTAINERS)
|
||||
file.
|
||||
|
||||
## 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. Likewise, 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
|
||||
can either be submitted for agreement via a GitHub issue or PR, or by sending an email
|
||||
to `etcd-maintainers@googlegroups.com`.
|
||||
|
||||
## Conflict resolution
|
||||
|
||||
In general, we prefer that technical issues and maintainer membership are amicably
|
||||
worked out between the persons involved. However, any technical dispute that has
|
||||
reached an impasse with a subset of the community, any contributor may open a GitHub
|
||||
issue or PR or send an email to `etcd-maintainers@googlegroups.com`. If the
|
||||
maintainers themselves cannot decide an issue, the issue will be resolved by a
|
||||
supermajority of the maintainers.
|
||||
|
||||
## Changes in Governance
|
||||
|
||||
Changes in project governance could be initiated by opening a GitHub PR.
|
@ -1,4 +1,6 @@
|
||||
# This is the official list of etcd maintainers.
|
||||
# The official list of maintainers and reviewers for the project maintenance.
|
||||
#
|
||||
# Refer to the GOVERNANCE.md for description of the roles.
|
||||
#
|
||||
# Names should be added to this file like so:
|
||||
# Individual's name <submission email address> (@GITHUB_HANDLE) pkg:*
|
||||
@ -6,6 +8,7 @@
|
||||
#
|
||||
# Please keep the list sorted.
|
||||
|
||||
# MAINTAINERS
|
||||
Brandon Philips <bphilips@redhat.com> (@philips) pkg:*
|
||||
Gyuho Lee <gyuhox@gmail.com> <leegyuho@amazon.com> (@gyuho) pkg:*
|
||||
Hitoshi Mitake <h.mitake@gmail.com> (@mitake) pkg:*
|
||||
@ -18,3 +21,5 @@ Xiang Li <xiangli.cs@gmail.com> (@xiang90) pkg:*
|
||||
Ben Darnell <ben@cockroachlabs.com> (@bdarnell) pkg:go.etcd.io/etcd/raft
|
||||
Tobias Grieger <tobias.schottdorf@gmail.com> (@tbg) pkg:go.etcd.io/etcd/raft
|
||||
|
||||
# REVIEWERS
|
||||
Wenjia Zhang <wenjiazhang@google.com> (@wenjiaswe) pkg:*
|
||||
|
@ -1,16 +0,0 @@
|
||||
|
||||
This document describes basic expectations for maintainers. To become a maintainer, start taking on these responsibilities. Consistent contributors then discuss with existing maintainers to become the official [MAINTAINERS](./MAINTAINERS).
|
||||
|
||||
### Top-level maintainer
|
||||
|
||||
- Running the etcd release processes
|
||||
- Ownership of test and debug infrastructure
|
||||
- Resolve or redirect issues to keep the issue count low (goal: under 100)
|
||||
- Regularly review pull requests across all pkgs
|
||||
- Providing cross pkg design review
|
||||
|
||||
### 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
|
Loading…
x
Reference in New Issue
Block a user