Mirrors/coredns
1
0
Fork 0
mirror of https://github.com/coredns/coredns.git synced 2025-10-27 16:24:19 -04:00
Code Issues Packages Projects Releases Wiki Activity

Governance: Replace project lead role with a steering committee (#5531)

Browse Source 
* replace project lead with steering committee

Signed-off-by: Chris O'Haver <cohaver@infoblox.com>

* align CODEOWNERS

Signed-off-by: Chris O'Haver <cohaver@infoblox.com>

* grow committee size to 5; add committee decision restrictions and vote detail

Signed-off-by: Chris O'Haver <cohaver@infoblox.com>

* add scm voting details and restrictions

Signed-off-by: Chris O'Haver <cohaver@infoblox.com>

* 5 placeholders in codeowners

Signed-off-by: Chris O'Haver <cohaver@infoblox.com>

Signed-off-by: Chris O'Haver <cohaver@infoblox.com>
This commit is contained in:
Chris O'Haver
2022-09-08 19:45:15 -04:00
committed by GitHub
parent b56b080a7c
commit 786ee691be
2 changed files with 45 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
CODEOWNERS
View File

@@ -1,4 +1,9 @@
# @miekg, miek@miek.nl, project lead: 11/11/2022 # 5 steering committee members
# steering committee member: <github handle>, <email>, term ends <term end date>
# steering committee member: <github handle>, <email>, term ends <term end date>
# steering committee member: <github handle>, <email>, term ends <term end date>
# steering committee member: <github handle>, <email>, term ends <term end date>
# steering committee member: <github handle>, <email>, term ends <term end date>
* @bradbeam @chrisohaver @dilyevsky @jameshartig @greenpau @isolus @johnbelamaric @miekg @pmoroney @rajansandeep @stp-ip @superq @yongtang @Tantalor93 * @bradbeam @chrisohaver @dilyevsky @jameshartig @greenpau @isolus @johnbelamaric @miekg @pmoroney @rajansandeep @stp-ip @superq @yongtang @Tantalor93

71
GOVERNANCE.md
View File

@@ -10,21 +10,20 @@ The CoreDNS community adheres to the following principles:
- Merit: Ideas and contributions are accepted according to their technical merit and alignment with - Merit: Ideas and contributions are accepted according to their technical merit and alignment with
project objectives, scope, and design principles. project objectives, scope, and design principles.
## Project Lead ## Project Steering Committee
The CoreDNS project has a project lead. The CoreDNS project has a project steering committee consisting of 5 members, with a maximum of 1 member from any single organization.
The steering committee in CoreDNS has a final say in any decision concerning the CoreDNS project, with the exceptions of
deciding steering committe membership, and changes to project governance. See `Changes in Project Steeting Committee Membership`
and `Changes in Project Governance`.
A project lead in CoreDNS is Any decision made must not conflict with CNCF policy.
a single person that has a final say in any decision concerning the CoreDNS project.
The term of the project lead is one year, with no term limit restriction. The maximum term length of each steering committee member is one year, with no term limit restriction.
The project lead is elected by CoreDNS maintainers Steering committee member are elected by CoreDNS maintainers.
according to an individual's technical merit to CoreDNS project.
The current project lead is identified in the [CODEOWNERS](CODEOWNERS) file with the string
`project lead` and the term behind the name in a comment at the top of the file.
The steering committee members are identified in the [CODEOWNERS](CODEOWNERS) file.
## Expectations from Maintainers ## Expectations from Maintainers
@@ -54,51 +53,59 @@ If a Maintainer feels she/he can not fulfill the "Expectations from Maintainers"
step down. step down.
The CoreDNS organization will never forcefully remove a current Maintainer, unless a maintainer The CoreDNS organization will never forcefully remove a current Maintainer, unless a maintainer
fails to meet the principles of CoreDNS community, fails to meet the principles of CoreDNS community, or adhere to the [Code of Conduct](CODE-OF-CONDUCT.md).
or adhere to the [Code of Conduct](CODE-OF-CONDUCT.md).
## Changes in Project Lead ## Changes in Project Steering Committee Membership
Changes in project lead or term is initiated by opening a github PR. Changes to the project steering committee membership are initiated by opening a separate GitHub PR updating
the [CODEOWNERS](CODEOWNERS) file for each steering committee member candidate.
Anyone from CoreDNS community can vote on the PR with either +1 or -1. Anyone from the CoreDNS community can vote on the PR with either +1 or -1.
Only the following votes are binding: Only the following votes are binding:
1) Any maintainer that has been listed in the [CODEOWNERS](CODEOWNERS) file before the PR is opened. 1) Any maintainer that has been listed in the [CODEOWNERS](CODEOWNERS) file before the PR is opened.
2) Any maintainer from an organization may cast the vote for that organization. However, no organization 2) Any maintainer from an organization may cast the vote for that organization. However, no organization
should have more binding votes than 1/5 of the total number of maintainers defined in 1). should have more binding votes than 1/5 of the total number of maintainers defined in 1).
The PR should only be opened no earlier than 6 weeks before the end of the project lead's term. The PR should be opened no earlier than 6 weeks before the end of affected committee member's term.
The PR should be kept open for no less than 4 weeks. The PR can only be merged after the end of the The PR should be kept open for no less than 4 weeks. The PR can only be merged after the end of the
last project lead's term, with more +1 than -1 in the binding votes. replaced committe member's term, with more +1 than -1 in the binding votes.
When there are conflicting PRs about changes in project lead, the PR with the most binding +1 votes is merged. When there are conflicting PRs for changes to a project committee member, the PR with the most
binding +1 votes is merged.
The project lead can volunteer to step down. During a vote there may be several candidates running for multiple committee seat vacancies. Maintainers and
community members should cast a single vote per vacancy (although this does not need to be enforced). At the end of the
voting period, candidates with the most binding votes will fill the vacancies. In the event of a
multi-way tie for a set of remaining vacancies, the candidates who have been maintainers longest have precedence.
A project steering committee member may volunteer to step down, ending their term early.
## Changes in Project Governance ## Changes in Project Governance
Changes in project governance (GOVERNANCE.md) could be initiated by opening a github PR. Changes in project governance (GOVERNANCE.md) can be initiated by opening a GitHub PR.
The PR should only be opened no earlier than 6 weeks before the end of the project lead's term. The PR should only be opened no earlier than 6 weeks before the end of a comittee member's term.
The PR should be kept open for no less than 4 weeks. The PR can only be merged follow the same The PR should be kept open for no less than 4 weeks. The PR can only be merged following the same
voting process as in `Changes in Project Lead`. voting process as in `Changes in Project Steeting Committee Membership`.
## Decision making process ## Decision-making process
Decisions are build on consensus between maintainers. Decisions are build on consensus between maintainers.
Proposals and ideas can either be submitted for agreement via a github issue or PR, Proposals and ideas can either be submitted for agreement via a GitHub issue or PR,
or by sending an email to `maintainers@coredns.io`. or by sending an email to `maintainers@coredns.io`.
In general, we prefer that technical issues and maintainer membership are amicably worked out between the persons involved. In general, we prefer that technical issues and maintainer membership are amicably worked out between the persons involved.
If a dispute cannot be decided independently, get a third-party maintainer (e.g. a mutual contact with some background If a dispute cannot be resolved independently, get a third-party maintainer (e.g. a mutual contact with some background
on the issue, but not involved in the conflict) to intercede. on the issue, but not involved in the conflict) to intercede.
If a dispute still cannot be decided, the project lead has the final say to decide an issue. If a dispute still cannot be resolved, the project steering committee has the final say to decide an issue.
The project steering committee may reach this decision by consensus or else by a simple majority vote among committee
members if necessary. The steering should committee endeavor to make this decision within a reasonable amount of time,
not to extend longer than two weeks.
Decision making process should be transparent to adhere to The decision-making process should be transparent to adhere to the CoreDNS Code of Conduct.
the principles of CoreDNS project.
All proposals, ideas, and decisions by maintainers or the project lead All proposals, ideas, and decisions by maintainers or the steering committee
should either be part of a github issue or PR, or be sent to `maintainers@coredns.io`. should either be part of a GitHub issue or PR, or be sent to `maintainers@coredns.io`.
## Github Project Administration ## Github Project Administration
@@ -131,7 +138,7 @@ plugin.
## CoreDNS and CNCF ## CoreDNS and CNCF
CoreDNS is a CNCF project. As such, CoreDNS might be involved in CNCF (or other CNCF projects) related CoreDNS is a CNCF project. As such, CoreDNS might be involved in CNCF (or other CNCF projects) related
marketing, events, or activities. Any maintainer could help driving the CoreDNS involvement, as long as marketing, events, or activities. Any maintainer may participate in these activities, as long as
she/he sends email to `maintainers@coredns.io` (or create a GitHub Pull Request) to call for participation she/he sends email to `maintainers@coredns.io` (or create a GitHub Pull Request) to call for participation
from other maintainers. The `Call for Participation` should be kept open for no less than a week if time from other maintainers. The `Call for Participation` should be kept open for no less than a week if time
permits, or a _reasonable_ time frame to allow maintainers to have a chance to volunteer. permits, or a _reasonable_ time frame to allow maintainers to have a chance to volunteer.