harbor governance model #1
Conversation
Signed-off-by: Steven Zou <szou@vmware.com>
GOVERNANCE.md
Outdated
| * **Partner** | ||
| * Partner MUST be a Harbor user first. | ||
| * Partner MUST be an organization which is listed in the PARTNER.md document. | ||
| * Partner HAS signed the brand usage authorization contact. |
There was a problem hiding this comment.
I'd drop this, the Harbor trademark is handled by CNCF now
There was a problem hiding this comment.
Thanks a lot for reviewing this PR. We really need good advice to build the governance model.
Agree.
GOVERNANCE.md
Outdated
| * **Maintainer** | ||
| * Member of TMB | ||
| * Maintainer MUST be a active contributor | ||
| * Maintainer SHOULD be senior engineers (>5 service years) |
There was a problem hiding this comment.
no need to mention "senior engineer" imho, you could have maintainers from all different types of experience
There was a problem hiding this comment.
Will remove that bar out of the criteria list
|
great start, made some comments |
GOVERNANCE.md
Outdated
|
|
||
| ## Technical Maintainer Board (TMB) | ||
|
|
||
| Technical maintainer board (TMB) is the top management institutions of the whole harbor community. TMB carries the mission of promoting and strengthening the community, grasps the development direction of the community and maintains the healthy growth of the community. |
There was a problem hiding this comment.
This should say "institution" instead of "institutions".
Should we use "leading the development direction of the project" instead of "grasps the development direction of the community"?
It should be "maintaining" instead of "maintains the".
Also, make sure we we capitalize Harbor correctly in the entire document.
There was a problem hiding this comment.
Sure, thanks @jonasrosland !
GOVERNANCE.md
Outdated
|
|
||
| ### Scale and Structure | ||
|
|
||
| * Formed by `M+N` members |
There was a problem hiding this comment.
Do we want to make this a little clearer?
"M" could be maintainers, and instead of "N" we could use "W" for watcher.
There was a problem hiding this comment.
We're discussing to remove the watcher role out of the TMB to simplify the process.
GOVERNANCE.md
Outdated
| ### Membership | ||
|
|
||
| * New member | ||
| * Nominated by existing member as a `maintainer` or `watcher` candidate |
There was a problem hiding this comment.
I'm not sure if we need watcher role. If we are to be transparent, anyone can be watcher.
There was a problem hiding this comment.
I'm thinking that.
GOVERNANCE.md
Outdated
| * The background of the proposal | ||
| * The main idea of the proposal solution | ||
| * The architecture/design of the proposal solution | ||
| * The development plan of the proposal solution |
There was a problem hiding this comment.
I don't think we need dev/resource plan for the proposal.
GOVERNANCE.md
Outdated
| * The `epic` issue link with number if it is already under development | ||
| * The development team if it is already under development | ||
| * The motivations of or the related problem to the proposal | ||
| * The background of the proposal |
There was a problem hiding this comment.
Isn't motivation /problem part of the backgrouhd?
There was a problem hiding this comment.
I think they have different intentions. Background just provides some related material to help describe the followup solution.
GOVERNANCE.md
Outdated
| If the proposal is successfully implemented and delivered, the related proposal document should be moved to the `delivered` sub folder under the `proposal` folder. Proposal being delivered means: | ||
|
|
||
| * The implemented code is merged to the branches of the governed repositories via PRs | ||
| * Or it is implemented as an independent [community project](#community-project-management) and linked in the official website and README files as additional tools |
There was a problem hiding this comment.
I don't think we need a proposal if the project is an external one that is to be linked from Harbor's repo.
GOVERNANCE.md
Outdated
| * The implemented code is merged to the branches of the governed repositories via PRs | ||
| * Or it is implemented as an independent [community project](#community-project-management) and linked in the official website and README files as additional tools | ||
|
|
||
| If the proposal is failed to deliver for some reasons, the related proposal document should be moved to the `failed` sub folder under the `proposal` folder. |
There was a problem hiding this comment.
If dev is stopped due to some reason, does it mean the proposal does not make sense? I imagine in some cases, it should be put back to "backlog"
There was a problem hiding this comment.
Maybe not! There are many reasons like resource limitations or organization changes of the contributors can cause development failed. Moving them to the failed is mainly to keep the status for querying or statistics. If one day it can be restart, just copy it with new header status.
Signed-off-by: Steven Zou <szou@vmware.com>
GOVERNANCE.md
Outdated
|
|
||
| ## Overview | ||
|
|
||
| Harbor is committed to building an open, evolutionary, high-efficiency and self-governance OSS community to provide cloud-native registry relevant tools and services. The whole community is run and managed by this constitution including the following chapters: |
There was a problem hiding this comment.
What do you think about this?
Harbor, a Cloud Native Computing Foundation (CNCF) project, is committed to building an open, inclusive, productive and self-governing open source community focused on building a high-quality cloud native registry. The community is governed by this document with the goal of defining how community should work together to achieve this goal. This document covers the following topics:
GOVERNANCE.md
Outdated
| @@ -0,0 +1,220 @@ | |||
| # Governance Constitution | |||
There was a problem hiding this comment.
s/Governance Constitution/Harbor Governance/
GOVERNANCE.md
Outdated
|
|
||
| * **Code Repositories:** List the code repositories governed by Harbor community. | ||
| * **Community Roles:** Define roles of Harbor community affiliated parties. | ||
| * **Technical Maintainer Board:** Define how to build and how does the technical maintainer board work, which is the top management institution of the whole community. |
There was a problem hiding this comment.
Projects like Kubernetes have many levels of both contributors and project authority positions, including a Steering Committee that would roughly equate to the Technical Maintainer Board that you've proposed. However, given our project is much, much smaller I feel that creating this sort of hierarchy imposes more challenges than it might solve.
I propose, in lieu of a steering committee, that we approach this problem the way that the NATS folks did. This model presents two levels of maintainership: maintainers and core maintainers. I've defined the two levels in more detail below.
It's worth noting that the ideas and definitions were very much inspired (ahem, copied and pasted 😄 ) from our friends in the NAT project.
tl;dr – let's remove Technical Maintainer Board.
Thoughts?
GOVERNANCE.md
Outdated
| * **Code Repositories:** List the code repositories governed by Harbor community. | ||
| * **Community Roles:** Define roles of Harbor community affiliated parties. | ||
| * **Technical Maintainer Board:** Define how to build and how does the technical maintainer board work, which is the top management institution of the whole community. | ||
| * **Proposal Management:** How to manage the proposals and plan the new release. |
MAINTAINERS.md
Outdated
| * Daniel Jiang <jt@vmware.com> from VMware | ||
| * Nathan Lowe <Nathan.Lowe@hyland.com> from HylandSoftware | ||
| * De Chen <> from CaiCloud | ||
| * xxx <> from Tencent |
There was a problem hiding this comment.
Remove until we have an individual in mind
| @@ -0,0 +1,10 @@ | |||
| # Maintainers | |||
There was a problem hiding this comment.
If we agree on the non-core / core maintainer model we'll have to break this section up as appropriate
There was a problem hiding this comment.
Not fully understand
| * Nathan Lowe <Nathan.Lowe@hyland.com> from HylandSoftware | ||
| * De Chen <> from CaiCloud | ||
| * xxx <> from Tencent | ||
|
|
There was a problem hiding this comment.
Need a section on changing this document:
Updating Governance
All changes in Governance require a supermajority total organizational (non-core + core maintainers) vote.
MAINTAINERS.md
Outdated
| * Steven Zou <szou@vmware.com> from VMware | ||
| * Daniel Jiang <jt@vmware.com> from VMware | ||
| * Nathan Lowe <Nathan.Lowe@hyland.com> from HylandSoftware | ||
| * De Chen <> from CaiCloud |
There was a problem hiding this comment.
GOVERNANCE.md
Outdated
|
|
||
| ## Community Roles | ||
|
|
||
| The participants of Harbor community may have different roles: |
steven-zou
force-pushed
the
build_governance_model
branch
from
ba24f57 to
5971b48
Compare
Signed-off-by: Steven Zou <szou@vmware.com>
steven-zou
force-pushed
the
build_governance_model
branch
from
5971b48 to
e0232f7
Compare
|
Thanks @steven-zou – simple and elegant. I love it! Let's discuss during our next community call; I'd like to open up for community feedback. Lazy consensus: if we do not receive any feedback by October 3rd, let's merge. Feedback welcome! |
ghost
changed the title
|
Hi @nlowe – mind reviewing and sharing your 2¢? Thanks! |
There was a problem hiding this comment.
Great start! Few things I noticed:
- How does voting work? The process isn't explicitly defined as far as I can tell. Do we comment
ack/nackon issues / PR's? Vocal vote in a community call? Something else? - Few formatting suggestions (See Comments)
- I agree with @clouderati The
MAINTAINERS.mddocument should be split up along the lines of Core and Non-Core Maintainers as defined
GOVERNANCE.md
Outdated
|
|
||
| Ideally, all project decisions are resolved by consensus. If impossible, any maintainer may call a vote. Unless otherwise specified in this document, any vote will be decided by a supermajority of the total maintainership, with a requirement of at least one core maintainer voting. | ||
|
|
||
| Votes by maintainers (either core or non-core) belonging to the same company will count as one vote; e.g., 4 maintainers employed by company `${x}` will only have **one** combined vote. |
There was a problem hiding this comment.
Does calculating the number of votes needed to form a supermajority take this into account? For example, If we have
- 3 Maintainers from company
a - 3 Maintainers from company
b - 3 Maintainers from company
c
Is a vote from two different developers from two different companies enough to form a supermajority? Or do we need more external developers to be able to vote?
There was a problem hiding this comment.
What if two developers from the same company don't agree? Do their votes cancel out?
There was a problem hiding this comment.
Sounds reasonable. I suggest each maintainer has 1 vote and the votes from the same company cannot exceed supermajority quota. Thoughts? @clouderati @nlowe
|
voting needs to be done a public forum, mailing list or issue tracker
…On Wed, Sep 26, 2018 at 12:04 PM Nathan Lowe ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In GOVERNANCE.md
<#1 (comment)>:
> +
+Total maintainership is defined as the union of maintainers and core maintainers.
+
+### Maintainers
+
+New maintainers must be nominated by an existing maintainer or core maintainer and must be elected by a supermajority of total maintainership. Likewise, maintainers can be removed by a supermajority of the total maintainership or can resign by notifying the core maintainers.
+
+### Core Maintainers
+
+Nomination for core maintainership requires (a) a nomination by an existing core maintainer, and (b) election by a supermajority of the core maintainer group. Likewise, maintainers can be removed by a supermajority core maintainer vote or can resign by notifying the core maintainers.
+
+### Decision Making
+
+Ideally, all project decisions are resolved by consensus. If impossible, any maintainer may call a vote. Unless otherwise specified in this document, any vote will be decided by a supermajority of the total maintainership, with a requirement of at least one core maintainer voting.
+
+Votes by maintainers (either core or non-core) belonging to the same company will count as one vote; e.g., 4 maintainers employed by company `${x}` will only have **one** combined vote.
What if two developers from the same company don't agree? Do their votes
cancel out?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAD5Iet3JTN_Nt5WZbF2aq-cYyrzpZFGks5ue7OLgaJpZM4WdTYl>
.
--
Cheers,
Chris Aniszczyk
http://aniszczyk.org
+1 512 961 6719
|
|
@caniszczyk Does this mean that the GitHub issue tracker is 👍? |
|
GitHub issue tracker is fine or pull request :)
…On Thu, Sep 27, 2018 at 10:39 AM James Zabala ***@***.***> wrote:
@caniszczyk <https://github.com/caniszczyk> Does this mean that the
GitHub issue tracker is 👍?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAD5IW4hYLTpP2ZNv3giMkTfEVqlsvfLks5ufPElgaJpZM4WdTYl>
.
--
Cheers,
Chris Aniszczyk
http://aniszczyk.org
+1 512 961 6719
|
The next community is 10/10. If we want to discuss this model in the meeting and then get feedback, the merging deadline may need to postpone to the date after 10/10? Thoughts? |
|
Sure, let's leave open and solicit feedback through October 12th. |
|
@steven-zou can you please look at @bradmeiseles's comments and merge into doc appropriately? I considered copying his comments here but it would result in a relatively large review. |
Done! |
Signed-off-by: Steven Zou <szou@vmware.com>
|
lgtm - please merge at your convenience @steven-zou. 😄 |
Signed-off-by: Zach Hill <zach@anchore.com>
Signed-off-by: Zach Hill <zach@anchore.com>
Add the very drafted version of governance model docs
Signed-off-by: Steven Zou szou@vmware.com