text for governance proposal, rev 4 #2220
Conversation
…or as un-affiliated - integrate an "Expectation from Maintainers" - adapt Maintainership with a loose removal event - make OWNER the main source of list of Maintainers - removed the automatic move to "owner" of Github project - added a begin of list of maintainers - based on current list in the 'maintainers' team of Github (2 organization, 2 individuals)
Signed-off-by: Miek Gieben <miek@miek.nl>
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
|
Thank you for your contribution. I've just checked the OWNERS files to find a suitable reviewer. This search was successful and I've asked superq (via If you have questions or suggestions for this bot, please file an issue against the miekg/dreck repository. The bot understands the commands that are listed here. |
yongtang
requested review from
bradbeam,
chrisohaver,
dilyevsky,
jameshartig,
fturib,
greenpau,
grobie,
Isolus,
johnbelamaric,
miekg,
pmoroney,
rajansandeep,
stp-ip and
varyoo
Codecov Report
@@ Coverage Diff @@
## master #2220 +/- ##
==========================================
- Coverage 56.34% 56.28% -0.06%
==========================================
Files 203 203
Lines 10132 10132
==========================================
- Hits 5709 5703 -6
- Misses 3990 3995 +5
- Partials 433 434 +1
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Globally LGTM
Thanks for putting it together.
I have couple remarks thought, but these are not blocking. I mean I will go with majority:
1- I would prefer a one year term.
In current tech world where everything is going fast one year is already a long term.
I see also this election (4 weeks) as a good time to have all together a conversation on what is the direction for the project: what's next ....
2- in the way to present in the governance doc, I would define in a separate chapter the "Formal vote process", and refer to that chapter in "Changes in the Project Lead".
Right now we need to use this formal vote only for change of Leader.
But the Leader himself can call on this process for some decision he does not want to have the last word.
And also, I guess if he proposes to change the governance he will have to trigger this formal vote process.
|
As mentioned in #2152 (comment), overall I am in supportive of BDFL or some variations. I think BDFL is more likely to be followed than other ways, because there is a single person responsible for the governance text enforcement. There are many factors for any contributor to decide if they want to help, e.g., if the project is effectively owned by a person or a company, how conflicts are resolved, how decisions are made, how easy it is to get PR accepted, and so on. At the end, it is who the community trust the most. Since there is already a PR #2152, I am going to close this PR for now, so that discussions can happen in one place. |
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
|
|
||
| - 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.
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.
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.io first 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.
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.
I think public applies 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.
Participation to cncf could change the coredns project.
Do you mean a change in a CNCF membership level?
|
|
||
| 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 the affiliation/association through coredns or cncf. Don't know what is the best phase but happy to take any suggestions.
There was a problem hiding this comment.
How about ...
... should only be approved by a maintainer not in the same company/organization as the author(s) ...
| 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 ..."
|
|
||
| - 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.
I believe in person collaborations does not have any impact to coredns project/repo itself, as it does not change coredns repo or organization.
Should we instead say:
| - Transparent and accessible: Work and collaboration are done in public. | |
| - Transparent and accessible: Changes to the CoreDNS organization and CoreDNS code repositories are done in public. |
|
@miekg , @johnbelamaric , @dilyevsky , @greenpau : can you review / approve this document as soon as possible. The target is to have it merged by 11/12 which is this Monday. I know that is very short time. |
|
/lgtm |
![corbot[bot]](https://avatars.githubusercontent.com/u/21110084?s=60&v=4){kind=small}
|
/lgtm |
|
/lgtm |
|
@miekg : do you think we have enough approvals to go ahead ? Are you ok to merge this PR ? |
|
[ Quoting <notifications@github.com> in "Re: [coredns/coredns] text for gove..." ]
@miekg : do you think we have enough approvals to go ahead ?
NOTE: would be good to take into account the 2 changes proposed by @chrisohaver, but @yongtang is traveling (KubeCon Shangai is this week), and we need the merge asap.
Are you ok to merge this PR ?
/lgtm
/merge
|
Automatically submitted.
Automatically submitted.
This proposal is based on conversations in #2112, #2152, #2203.
Maintainers vote for project lead. Project lead has the final say on anything else. The process should always be transparent and accessible to public.
A maintainer has to be listed before the PR is opened, to have a binding vote for project lead.
There are restrictions on affiliated maintainer votes for a company. If a company has more than 1/5 of the total maintainers, only no more than 1/5 of the total maintainers count are considered as binding.
A company certainly could recruit more non-affiliated maintainers to allow more votes for this company. That has to happen before the PR is open. Adding maintainers should also adhere to the policy about new maintainers.
Example: Since there are 16 maintainers in total now, any company can cast
16 / 5 = 3votes for the project lead. If, in the future, a company adds one affiliated maintainer and recruits 3 more non-affiliated maintainers, then this company could cast(16 + 1 + 3) / 5 = 4votes.It is not clear to me if there is an immediately need to have a governance document now (or soon). But since this is a proposal, I guess it does not hurt to open a PR for discussion.