Update community-membership.md (#307)

* Update community-membership.md

This proposal pulls in the maintainer voting process from the `dapr/dapr` repository ([here](https://github.com/dapr/dapr/blob/master/GOVERNANCE.md)]) into the correct section in the community membership document.

In addition, the following changes are included:

1. Approver and maintainer nominations for a repository can be initiated by a maintainer from the relevant repository
2. Objections by maintainers to approver nominations must come from maintainers of the relevant repository
3. Voting for new maintainers happens between the maintainers of the relevant repository

This essentially fixes the current situation where all maintainers vote for all nominations, eliminating the occurrence of non-informed votes. The current guidelines were copied from a project that had the concept of Core Maintainers and this does not apply here; thus it makes sense to limit votes to the relevant repository.

Signed-off-by: Yaron Schneider <schneider.yaron@live.com>

* Update community-membership.md

Signed-off-by: Yaron Schneider <schneider.yaron@live.com>

* Update community-membership.md

Signed-off-by: Yaron Schneider <schneider.yaron@live.com>

* Update community-membership.md

Signed-off-by: Yaron Schneider <schneider.yaron@live.com>

---------

Signed-off-by: Yaron Schneider <schneider.yaron@live.com>
This commit is contained in:
Yaron Schneider 2023-04-07 05:24:30 +03:00 committed by GitHub
parent a2c455f8d9
commit 1a48587b24
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 16 additions and 3 deletions

View File

@ -89,9 +89,11 @@ The following apply to the part of the codebase for which one would be an approv
- Reviewer for, or author of, at least 5 substantial PRs to the codebase,
with the definition of substantial area to the maintainer's discretion
(e.g. refactors/adds new functionality rather than one-line pulls)
- Nominated by a maintainer:
- With no objections from other maintainers
- Done through PR to update the `CODEOWNERS`
- Nominated by a maintainer from the repository in which the nomination is applied to:
- With an approving vote of at least 2 maintainers from the repository maintainers. In the case of a repository with a solo maintainer, a single vote suffices
- With no objections from other repository maintainers for a period of one week
- Steering committee acts as the final resolution to any escalation
- Done through PR to update the `CODEOWNERS`
### Responsibilities and privileges
@ -130,6 +132,15 @@ The following apply to the subproject for which one would be an owner:
- Must have been active for 3 months or more for the given sub-project
- Inactivity for more than 3 months leads to a removal vote by other maintainers and not an automatic removal
### Acceptance
New maintainers can be added to the project by a super-majority (two-thirds / 66.66%) vote. Only the maintainers of the repository in which the nomination is applied to have a binding vote, while maintainers from other repositories are on an informed basis via a separate email thread. A potential maintainer may be nominated by an existing maintainer from the repository in which the nomination is applied to. A vote is conducted in private between the current maintainers over the course of a one week voting period. At the end of the week, votes are counted and a pull request is made on the repo adding the new maintainer to the CODEOWNERS file.
Maintainers for new repositories can be nominated by any member of the steering committee and voted on in a steering committee meeting.
Single maintainers of a repository can nominate a new maintainer and *MUST* inform the steering committee of their intention. The maintainer can be approved if no objections have been raised in a period of one week.
A maintainer may step down by submitting an issue stating their intent.
### Responsibilities and privileges
The following apply to the subproject(repos) for which one would be an owner:
@ -146,3 +157,5 @@ The following apply to the subproject(repos) for which one would be an owner:
- 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
Maintainers *MUST* remain active. If they are unresponsive for >3 months, they will be automatically removed unless a super-majority of the other repository maintainers agrees to extend the period to be greater than 3 months.