text for governance proposal, rev 4 #2220
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
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,147 @@ | ||||||
| # CoreDNS Governance | ||||||
|
|
||||||
| ## Principles | ||||||
|
|
||||||
| The CoreDNS community adheres to the following principles: | ||||||
|
|
||||||
| - Open: CoreDNS is open source, advertised on [our website](https://coredns.io/community). | ||||||
| - Welcoming and respectful: See [Code of Conduct](CODE-OF-CONDUCT.md). | ||||||
| - Transparent and accessible: Work and collaboration are done in public. | ||||||
|
There was a problem hiding this comment.
Should we instead say:
Suggested change
|
||||||
| - Merit: Ideas and contributions are accepted according to their technical merit and alignment with | ||||||
| project objectives, scope, and design principles. | ||||||
|
|
||||||
| ## Project Lead | ||||||
|
|
||||||
| The CoreDNS project has a project lead. | ||||||
|
|
||||||
| A project lead in CoreDNS is | ||||||
| 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 project lead is elected by CoreDNS maintainers | ||||||
| according to an individual's technical merit to CoreDNS project. | ||||||
|
|
||||||
| The current project lead is identified in the top level [OWNERS](OWNERS) file with the string | ||||||
| `project lead` and the term behind the name. | ||||||
|
|
||||||
|
|
||||||
| ## Expectations from Maintainers | ||||||
|
|
||||||
| Every one carries water... | ||||||
|
|
||||||
| Making a community work requires input/effort from everyone. Maintainers should actively | ||||||
| participate in Pull Request reviews. Maintainers are expected to respond to assigned Pull Requests | ||||||
| in a *reasonable* time frame, either providing insights, or assign the Pull Requests to other | ||||||
| maintainers. | ||||||
|
|
||||||
| Every Maintainer is listed in the top-level [OWNERS](https://github.com/coredns/coredns/blob/master/OWNERS) | ||||||
| file, with their Github handle and a possibly obfuscated email address. Everyone in the | ||||||
| `approvers` list is a Maintainer. | ||||||
|
|
||||||
| A Maintainer is also listed in a plugin specific OWNERS file. | ||||||
|
|
||||||
| A Maintainer should be a member of `maintainers@coredns.io`, although this is not a hard requirement. | ||||||
|
|
||||||
| ## Becoming a Maintainer | ||||||
|
|
||||||
| On successful merge of a significant pull request any current maintainer can reach | ||||||
| to the author behind the pull request and ask them if they are willing to become a CoreDNS | ||||||
| maintainer. The email of the new maintainer invitation should be cc'ed to `maintainers@coredns.io` | ||||||
| as part of the process. | ||||||
|
|
||||||
| ## Changes in Maintainership | ||||||
|
|
||||||
| If a Maintainer feels she/he can not fulfill the "Expectations from Maintainers", they are free to | ||||||
| step down. | ||||||
|
|
||||||
| The CoreDNS organization will never forcefully remove a current Maintainer, unless a maintainer | ||||||
|
There was a problem hiding this comment. How does the decision process of removal work? (e.g. Leader decides, maintainers vote). There was a problem hiding this comment. Ah, never mind. I see below in the decision making process section, it states "... and maintainer membership ..." |
||||||
| fails to meet the principles of CoreDNS community, | ||||||
| or adhere to the [Code of Conduct](CODE-OF-CONDUCT.md). | ||||||
|
|
||||||
| ## Changes in Project Lead | ||||||
|
|
||||||
| Changes in project lead or term is initiated by opening a github PR. | ||||||
|
|
||||||
| Anyone from CoreDNS community can vote on the PR with either +1 or -1. | ||||||
|
|
||||||
| Only the following votes are binding: | ||||||
| 1) Any maintainer that has been listed in the top-level [OWNERS](OWNERS) file before the PR is opened. | ||||||
| 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). | ||||||
|
|
||||||
| The PR should only be opened no earlier than 6 weeks before the end of the project lead'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 | ||||||
| last project lead'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. | ||||||
|
|
||||||
| The project lead can volunteer to step down. | ||||||
|
|
||||||
| ## Changes in Project Governance | ||||||
|
|
||||||
| Changes in project governance (GOVERNANCE.md) could 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 be kept open for no less than 4 weeks. The PR can only be merged follow the same | ||||||
| voting process as in `Changes in Project Lead`. | ||||||
|
|
||||||
| ## Decision making process | ||||||
|
|
||||||
| Decisions are build on consensus between maintainers. | ||||||
| Proposals and ideas can either be submitted for agreement via a github issue or PR, | ||||||
| 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. | ||||||
| If a dispute cannot be decided 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. | ||||||
| If a dispute still cannot be decided, the project lead has the final say to decide an issue. | ||||||
|
|
||||||
| Decision making process should be transparent to adhere to | ||||||
| the principles of CoreDNS project. | ||||||
|
|
||||||
| All proposals, ideas, and decisions by maintainers or the project lead | ||||||
| should either be part of a github issue or PR, or be sent to `maintainers@coredns.io`. | ||||||
|
|
||||||
| ## Github Project Administration | ||||||
|
|
||||||
| The __coredns__ GitHub project maintainers team reflects the list of Maintainers. | ||||||
|
|
||||||
| ## Other Projects | ||||||
|
|
||||||
| The CoreDNS organization is open to receive new sub-projects under its umbrella. To accept a project | ||||||
| into the __CoreDNS__ organization, it has to meet the following criteria: | ||||||
|
|
||||||
| - Must be licensed under the terms of the Apache License v2.0 | ||||||
| - Must be related to one or more scopes of the CoreDNS ecosystem: | ||||||
| - CoreDNS project artifacts (website, deployments, CI, etc) | ||||||
| - External plugins | ||||||
| - Other DNS related processing | ||||||
| - Must be supported by a Maintainer not associated or affiliated with the author(s) of the sub-projects | ||||||
|
|
||||||
| The submission process starts as a Pull Request or Issue on the | ||||||
| [coredns/coredns](https://github.com/coredns/coredns) repository with the required information | ||||||
| mentioned above. Once a project is accepted, it's considered a __CNCF sub-project under the umbrella | ||||||
| of CoreDNS__. | ||||||
|
|
||||||
| ## New Plugins | ||||||
|
|
||||||
| The CoreDNS is open to receive new plugins as part of the CoreDNS repo. The submission process | ||||||
| is the same as a Pull Request submission. Unlike small Pull Requests though, a new plugin submission | ||||||
| should only be approved by a maintainer not associated or affiliated with the author(s) of the | ||||||
|
There was a problem hiding this comment. What precisely is meant by "associated or affiliated"? We are all associated/affiliated via working on CoreDNS. Does this mean "working for the same company/organization" ? There was a problem hiding this comment. I think the idea is to not including There was a problem hiding this comment. How about ...
|
||||||
| plugin. | ||||||
|
|
||||||
| ## CoreDNS and CNCF | ||||||
|
|
||||||
| 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 | ||||||
| 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 | ||||||
| permits, or a _reasonable_ time frame to allow maintainers to have a chance to volunteer. | ||||||
|
|
||||||
| ## Code of Conduct | ||||||
|
|
||||||
| The [CoreDNS Code of Conduct](CODE-OF-CONDUCT.md) is aligned with the CNCF Code of Conduct. | ||||||
|
|
||||||
| ## Credits | ||||||
|
|
||||||
| Sections of this documents have been borrowed from [Fluentd](https://github.com/fluent/fluentd/blob/master/GOVERNANCE.md) and [Envoy](https://github.com/envoyproxy/envoy/blob/master/GOVERNANCE.md) projects. | ||||||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the scope of this? Does it mean that all CoreDNS related discussions should be made known and accessible/open to the public? (e.g. scheduled conference call meetings)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally I think just like the way cncf works, everything could be public. For example, cncf toc meetings are publicly joinable.
I do understand there might be some special situations. For example, let's say I find one contributor who has done a lot to coredns. I want to send an invite to the contributor to be a maintainer. Sometimes I may want to send an email to
maintainers@coredns.iofirst to see if there is any objection, before the invitation email to the contributor is out.This is for curtesy: you really don't want to send an invitation first, then take it back a couple of days later.
I think there are some special scenarios. Though most of the time I think public is not a problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would I be violating the principles if I participate in an ad-hoc whiteboard discussion about CoreDNS with a colleague in person without setting up a public video chat (e.g. Zoom). I would hope no, as it would stifle in-person collaboration. But strictly speaking it does violate the principle as written.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think
publicapplies only if there is an impact to coredns project.I believe in person collaborations does not have any impact to coredns project/repo itself, as it does not change coredns repo or organization.
Participation to cncf could change the coredns project. A PR could also change the coredns repo, but of course a PR is always public.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean a change in a CNCF membership level?