WIP: Add first draft of governance and contributor ladder documentation. #72

jberkus · 2021-07-09T00:52:01Z

Draft of Contributor Ladder and Governance docs for the community repo based on the federated subproject structure written for Konveyor and adopted as a template by the CNCF.

Note that there's some new process involved in adopting this structure, but it's what we'll eventually need if we're successful in recruiting new contributors and sponsors. Worth discussing if we want to phase in some parts like the elections.

Please discuss. Open questions:

Contributor Ladder

Per discussion in issue Contributor ladder - draft data for review #53, this is designed as a group of subprojects, where each subproject advances its own contributors, and the Maintainers of OCM are the collected Maintainers of all of the subprojects. Just making sure that's what everyone wants.
I've set the initial thresholds for numerical contributions (like, how many reviews to become a reviewer) rather low, because OCM is a young project.
The roles we're making use of are Contributor, Organization Member, Reviewer, and Maintainer

Governance

This is federated governance, with an overall steering committee. The SC consists of two maintainers from each subproject (to be lowered to one later when we get more subprojects) and two elected members from the overall project.
Right now, I've left in the block about a code of conduct committee, even though it's probably not what we want. Do we plan to just forward all CoC reports to the CNCF until the project gets bigger? Right now they go to Red Hat management, and that will need to change.

Please mark this up so we can get to the set of rules we all want!

@mdelder @qiujian16 @juliana-hsu

Signed-off-by: Josh Berkus josh@agliodbs.com

Very WIP. Signed-off-by: Josh Berkus <josh@agliodbs.com>

qiujian16 · 2021-07-12T01:25:45Z

GOVERNANCE.md

+The overall Open Cluster Management umbrella project is governed by a Steering
+Committee, which is selected as follows:
+
+* Two Maintainer representatives from each member Subproject


should we have a total number of Steering Committee? Currently there are 17 repos, which I think belongs to 4 sub projects.

Oh, I thought there were only two subprojects. In that case, does it make more sense to have one rep per subproject?

create a PR #75 to define the subproject clearer

The subprojects are now defined in https://github.com/open-cluster-management-io/ocm

Foundation / Cluster Lifecycle

Application Lifecycle

GRC: Governance, Risk and Compliance across Kubernetes clusters

Additional External Integrations

CC @juliana-hsu

juliana-hsu · 2021-09-28T20:18:42Z

CONTRIBUTOR_LADDER.md

+
+Each of the contributor roles below is organized into lists of three types of things. "Responsibilities" are things that contributor is expected to do. "Requirements" are qualifications a person needs to meet to be in that role, and "Privileges" are things contributors on that level are entitled to.
+
+Open Cluster Management is a project made up of several Subprojects, such as Foundation and Policy.  This contributor ladder applies to each Subproject.  As such, a contributor advances in each Subproject separately, and may be a Member in one Subproject while being a Maintainer in another.  For the Open Cluster Management project overall, the contributor is considered to be the highest level they have reached in any Subproject.  Thus, someone who is a Project Member in one Subproject is a Project Member of OCM overall.


Not quite sure what this sentence is trying to say: "For the Open Cluster Management project overall, the contributor is considered to be the highest level they have reached in any Subproject."?

So, if you're a Maintainer in Policy Manager, then you're considered a Maintainer in Open Cluster Management, even if you don't contribute to API at all.

It is probably good to use the example in the comment instead of the one now to illustrate this idea.

Agreed. Can you suggest two appropriate subprojects for the example?

Two sub-projects can be https://github.com/open-cluster-management-io/registration and https://github.com/open-cluster-management-io/placement

CONTRIBUTOR_LADDER.md

juliana-hsu · 2021-09-28T20:24:13Z

CONTRIBUTOR_LADDER.md

+    * May give commands to CI/CD automation
+    * Entitled to vote in the [TODO: appropriate election]
+    * Can be added to GitHub teams in the Open Cluster Management org
+    * Can recommend other contributors to become Org Member


typo: an Org member

deads2k · 2021-10-12T01:21:36Z

CONTRIBUTOR_LADDER.md

+* Responsibilities include:
+    * Continues to contribute regularly, as demonstrated by having at least 25 contributions a year, as demonstrated by Devstats project metrics. 
+* Requirements:
+    * Must have successful contributions to the project, including at least one of the following:


Is there a script showing the current potential pool of members that match the explicit criteria, versus equivalent combination?

not yet. This is annoyingly one of the things that will be easier to answer if we get accepted to CNCF and gain access to devstats.

deads2k · 2021-10-12T01:25:23Z

CONTRIBUTOR_LADDER.md

+    * Commits to being responsible for that specific area
+    * Is supportive of new and occasional contributors and helps get useful PRs in shape to commit
+* Additional privileges:
+    * Has GitHub or CI/CD rights to approve pull requests in specific directories


At least some of the open-cluster-management repos have separate lgtm and approve. Is it intentional that this Reviewer role holds approving power?

Yes. Org members have the right to LGTM. Note the "in specific directories" they idea is that Reviewer is an expert on one particularly piece of code/docs, as opposed to having root approval.

deads2k · 2021-10-12T01:29:36Z

CONTRIBUTOR_LADDER.md

+It is important for contributors to be and stay active to set an example and show commitment to the project. Inactivity is harmful to the project as it may lead to unexpected delays, contributor attrition, and a loss of trust in the project.
+
+* Inactivity is measured by:
+    * Periods of no contributions for longer than 12 months


If memory serves, kube uses a longer period to account for parental leave policies in some countries.

Oh! Good point, change to 18months?

https://github.com/kubernetes/community/blob/master/community-membership.md#how-inactivity-is-measured

18 months sounds good based on what k8s community has.

ryanzhang-oss · 2021-10-22T06:50:19Z

CONTRIBUTOR_LADDER.md

+
+Each of the contributor roles below is organized into lists of three types of things. "Responsibilities" are things that contributor is expected to do. "Requirements" are qualifications a person needs to meet to be in that role, and "Privileges" are things contributors on that level are entitled to.
+
+Open Cluster Management is a project made up of several Subprojects, such as Foundation and Policy.  This contributor ladder applies to each Subproject.  As such, a contributor advances in each Subproject separately, and may be a Member in one Subproject while being a Maintainer in another.  For the Open Cluster Management project overall, the contributor is considered to be the highest level they have reached in any Subproject.  Thus, someone who is a Project Member in one Subproject is a Project Member of OCM overall.


It is probably good to use the example in the comment instead of the one now to illustrate this idea.

ryanzhang-oss · 2021-10-22T06:54:41Z

CONTRIBUTOR_LADDER.md

+The process of becoming a Reviewer is:
+<!-- TODO: define your exact process here.  What's below is given as an example process for a project that uses Owners files and has defined teams for each project area -->
+1. The contributor is nominated by opening a PR against the appropriate repository, which adds their GitHub username to the OWNERS file for one or more directories.
+2. At least two members of the team that owns that repository or main directory, who are already Approvers, approve the PR.


what about a new repository that has no contributors/members yet?

How could you have repository with no contributors? Someone had to write the code.

... does suggest that having a "bootstrapping" para for new projects might be a good idea, though.

How could you have repository with no contributors? Someone had to write the code.

"Member" status takes 3 months and the team that owns that repository may not have any approvers.

* Must have been contributing for at least 3 months

yeah, this comes down to Bootstrapping again.

ryanzhang-oss · 2021-10-22T22:34:18Z

CONTRIBUTOR_LADDER.md

+    * Determining strategy and policy for the project
+    * Participating in, and leading, community meetings
+* Requirements
+    * Experience as a Reviewer for at least 3 months


What about a new repository that is less than 3 months old?

My suggestion would be that any project less than 3 months old is unlikely to be promoting folks aside from the original founding team.

ryanzhang-oss · 2021-10-22T22:34:39Z

CONTRIBUTOR_LADDER.md

+    * Reviewing at least 10 PRs per year
+    * Helping other contributors become reviewers
+* Requirements:
+    * Experience as a Contributor for at least 3 months


What about a new repository that is less than 3 months old?

How likely is it that a new subproject would want to elevate people to Organization Member or Reviewer based on their contributions solely to that subproject in its first three months of existence, but after bootstrapping?

The reason for the time requirement, btw, is to avoid a lot of assignment of higher-level permissions based on "X has just been hired". In other projects, the assignment of community permissions on hiring to people who have not yet contributed anything at all has resulted in huge bloated lists of users with privileges that someone else then needs to audit and purge. A time requirement also makes things fairer to freelance contributors.

ryanzhang-oss · 2021-10-22T22:40:12Z

GOVERNANCE.md

+Committee, which is selected as follows:
+
+* Two Maintainer representatives from each member Subproject
+* Two general "Community Representatives"


Is there any guidance on the TOC organization distribution? I think CNCF has some bar on the number of organizations on the maintainer/TOC list

It doesn't. Nor does it have a limit on the number of maintainers per project; grpc has 40+ because of their system.

mikeshng · 2021-11-11T19:34:18Z

GOVERNANCE.md

+
+Open Cluster Management and its leadership embrace the following values:
+
+* [TODO: List of Values]


Openness: Open Cluster Management is an open source community driven project. Distributed design: Distributed asynchronous ownership, collaboration, communication and decision making are the cornerstones of our world-wide community. Fairness: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, scope, and design principles. Diversity and inclusion: Everyone are welcome to participate in the Open Cluster Management project regardless of gender, gender identity, sexual orientation, disability, race, ethnicity, age, religion or economic status.

CC @juliana-hsu

ryanzhang-oss · 2021-11-17T17:54:28Z

CONTRIBUTOR_LADDER.md

+### Maintainer
+Description: Maintainers are very established contributors who are responsible for one or more Subprojects. As such, they have the ability to approve PRs against any area of that Subproject, and are expected to participate in making decisions about the strategy and priorities of that Subproject and Open Cluster Management as a whole.
+
+A Maintainer must meet the responsibilities and requirements of a Reviewer, plus:


Our community is still very small and super concentrated. I wonder if we can have some exceptions such as 2 TOC members can nominate a new member to be a reviewer?

ryanzhang-oss · 2021-11-17T22:30:04Z

GOVERNANCE.md

+The overall Open Cluster Management umbrella project is governed by a Steering
+Committee, which is selected as follows:
+
+* Two Maintainer representatives from each member Subproject


As we discussed in the meeting, does it make sense to have a bootstrap TOC?

Yes. Do we need to spell that out in this charter?

deads2k · 2021-11-22T20:39:04Z

What about a new repository that is less than 3 months old?

from #72 (comment)

I think this is a good point. While I'm in favor of having some manner of sustained effort over time as a requirement to avoid drive-by contributions and ensure familiarity with organization standards, in a new organization this can place a person in the position of starting a new project and not having direct control over how it evolves. Could we consider a different mechanism as we get started?

Perhaps instead of a duration requirement for the first year, we work based on a strict referral/approval system where existing members (we'll have enough to at least get started) make the decision. This is how I remember the early days of kube when the community was very small and we mostly knew each other: when you thought you had the credibility and experience, you asked for rights and you got them (or didn't). While the project is small, it's less likely to have disruptive actors and a request could be paired with, "show me what you've done here". And since most concerns are likely concerns about a company losing control of its own technology, perhaps waiving the contribution duration could always require multiple member company "+1" votes from the beginning to avoid spamming. After a year, we could require the contribution duration without less concern about excluding the early projects we need to foster.

openshift-ci · 2021-11-23T21:04:37Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: jberkus
To complete the pull request process, please assign luckyfengyong after the PR has been reviewed.
You can assign the PR to them by writing /assign @luckyfengyong in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

jberkus · 2021-11-23T21:17:56Z

@deads2k this all sounds like optimizing around a problem that is highly unlikely to every actually occur.

The originators of any new subproject would be "grandfathered" into their roles for that subproject, and I wouldn't expect additional promotion activity around new contributors in the 90 days after a new subproject is accepted.

- added Values section per Mike Ng - added bootstrap section for new subprojects - changed no contribution period Signed-off-by: Josh Berkus <josh@agliodbs.com>

jberkus · 2021-11-23T21:29:04Z

New version. Changes made:

added Values statement per @mikeshng
changed "no contributions" period to 18 months
added clear "new subproject boostrap section" to make it clear how a new subproject brings its own people
changed SC reps per subproject to 1, per discussion

Please review!

openshift-merge-robot · 2022-12-02T15:21:54Z

@jberkus: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Add first draft of governance and contributor ladder documentation.

bf88519

Very WIP. Signed-off-by: Josh Berkus <josh@agliodbs.com>

openshift-ci bot added the do-not-merge/work-in-progress label Jul 9, 2021

openshift-ci bot requested review from deads2k and qiujian16 July 9, 2021 00:52

qiujian16 reviewed Jul 12, 2021

View reviewed changes

juliana-hsu reviewed Sep 28, 2021

View reviewed changes

CONTRIBUTOR_LADDER.md Show resolved Hide resolved

juliana-hsu reviewed Sep 28, 2021

View reviewed changes

deads2k reviewed Oct 12, 2021

View reviewed changes

ryanzhang-oss reviewed Oct 22, 2021

View reviewed changes

mikeshng reviewed Nov 11, 2021

View reviewed changes

mikeshng mentioned this pull request Nov 16, 2021

[SANDBOX PROJECT ONBOARDING] Open Cluster Management cncf/sandbox#227

Closed

28 tasks

ryanzhang-oss reviewed Nov 17, 2021

View reviewed changes

Changes per discussion:

793e3c4

- added Values section per Mike Ng - added bootstrap section for new subprojects - changed no contribution period Signed-off-by: Josh Berkus <josh@agliodbs.com>

jberkus force-pushed the governance branch from 98483d2 to 793e3c4 Compare November 23, 2021 21:24

openshift-merge-robot added the needs-rebase label Dec 2, 2022


		Each of the contributor roles below is organized into lists of three types of things. "Responsibilities" are things that contributor is expected to do. "Requirements" are qualifications a person needs to meet to be in that role, and "Privileges" are things contributors on that level are entitled to.

		Open Cluster Management is a project made up of several Subprojects, such as Foundation and Policy. This contributor ladder applies to each Subproject. As such, a contributor advances in each Subproject separately, and may be a Member in one Subproject while being a Maintainer in another. For the Open Cluster Management project overall, the contributor is considered to be the highest level they have reached in any Subproject. Thus, someone who is a Project Member in one Subproject is a Project Member of OCM overall.


		Open Cluster Management and its leadership embrace the following values:

		* [TODO: List of Values]

WIP: Add first draft of governance and contributor ladder documentation. #72

Are you sure you want to change the base?

WIP: Add first draft of governance and contributor ladder documentation. #72

Conversation

jberkus commented Jul 9, 2021

Contributor Ladder

Governance

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

juliana-hsu Sep 28, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikeshng Nov 11, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

deads2k commented Nov 22, 2021

openshift-ci bot commented Nov 23, 2021

jberkus commented Nov 23, 2021 • edited Loading

jberkus commented Nov 23, 2021

openshift-merge-robot commented Dec 2, 2022

juliana-hsu Sep 28, 2021 •

edited

Loading

mikeshng Nov 11, 2021 •

edited

Loading

jberkus commented Nov 23, 2021 •

edited

Loading