Proposal: Update for Knative Governance [WIP]

[rgregg]

I've written up some changes to the governance model for Knative that I'd like to propose to the Steering Committee for their approval. These changes are based on the feedback that was raised during Build 569.

These changes clarify the role of the Knative Steering Committee.

In addition to the changes here, I propose that the Steering Committee take up the following during their next meeting:

• Expand the current Steering Committee to 7 seats, as proposed, with 4 seats held by Google, and 1 seat each for IBM, Pivotal, and Red Hat, based on the overall contribution to the Knative project over the last year. Knative company stats provides the basis for offering additional seats to these three companies, although I do not recommend this be the mechanism through which seats on the committee are decided.
• Committee should elect a chairperson to ensure the committee is orderly and meets on a regular basis, and communicates discussions back to the community (since KSC meetings are not open to the public).
• Request that the Technical Oversight Committee update their charter and governance based on feedback and expand their membership in recognition of other company contributions.

Finally, I would also like to propose that we create a new repo, either named Governance or Community, where we can move the governance / community organization related content. This will provide a single hub for this content, as well as issues related to the content, that is separate from the technical documentation and sample code that lives in the docs repo today.
Moved this to #1018 to track separately so the discussion here can focus on the governance content.

I would suggest that we receive all feedback on this proposal by the end of this week, 3/22, so that it may be considered by the committee during their regular meeting the following week.

[rgregg]

/hold

[rgregg]

/approve cancel

[samodell]

I think moving the content out of the Docs repo and into its own repo may pose a problem if we want to keep that content visible on https://www.knative.dev/contributing/. @RichieEscarez can provide more details on that.

[vbatts]

I think this is a good start, though the quorum ratio does mean that the community (outside of GOOG) could not have majority. I get that there are a majority of contributions coming from Google, but that feels still less than open. On the Open Containers Initiative, we rules of no more than say 2 seats held by the same company, and then a total number of seats like 7 or 9, which allows for a decent quorum decision.

[dewitt]

Noting here that I'm personally supportive of this as-is. Thank you for proposing this, Ryan!

I'll hold my LGTM however until after the broader community has fully weighed in and the doc has incorporated any further refinements or changes.

[jchesterpivotal]

I'd suggest expanding this definition, probably with a lawyer briefed to give the least-lawerly possible wording of "any body corporate recognised under the laws of XYZ". It's foreseeable that not-for-profit organisations, government bodies, education institutions, unincorporated and incorporated associations, partnerships, even more exotic formations (Swiss Vereins, anyone?), etc etc may fall into the orbit of Knative over time.

Also missing is a mechanism for succession. Bodies corporate evolve their identity in a way that individuals generally don't. They can rename themselves, be formed, be replaced by completely different organisations using the same legal name acquired from the previous organisation, be divested from a parent, be merged with or taken over by another organisation, go bankrupt, emerge from bankruptcy, be nationalised, be privatised ... the list goes on and on. I don't propose that we need to cover every single contingency, but it would be worth (again) checking with a lawyer for the shortest possible statement.

This is going to come up before long. Assuming IBM and Red Hat complete their merger, the question will arise of whether Red Hat's vote would pass to IBM, or remain somehow independent, or resumed into Google's pool, or passed to Pivotal, or passed to a another company (eg SAP, Cisco or VMWare), or simply not replaced.

Of course: I am not a lawyer and none of this is legal advice.

[rgregg]

Thanks for pointing this out -- I'll see if we can clarify the language without making this overly complicated or have too much legalese.

[csantanapr]

Red Hat and IBM are two separate companies, and are operating in this mode today.
I would recommend to keep treating them like this for now and not speculate anything about the acquisition.

[pmorie]

Let's avoid speculation about things that haven't happened yet.

[jchesterpivotal]

I would not include this, or I would rework it. The title "Frequently asked questions" suggests a non-binding, informative section. But it's included in the same document as rules and appears to include statements of binding rules (eg about amendments, consensus by lack of objection etc).

[rgregg]

Thanks -- I think there are important details in here however -- I've thought about renaming this as "Clarifications", or should I try to fold these details back into the above points?

[jchesterpivotal]

I think it's worth pushing them back up into the main body of the document. Expressing rules in two different forms makes it harder to understand the document.

It may be that you start from a Q&A format to help you elucidate scenarios you want to cover, but I would not render the binding document that way.

[jchesterpivotal]

This is problematic insofar as committee members are reasonably likely to vote en bloc some of the time. Under the initial allocation, Google would be able to amend the KSC rules unilaterally.

I'd suggest a two-part rule: A majority of members, with votes in favour cast by committee members from at least two separate companies. As the committee grows and becomes more plural, this could be be updated to a stricter rule: a majority of votes and a majority of companies.

[sebgoa]

the problem is not in the quorum and majority vote, the problem is in allocating seats to vendors and not individuals.

You could say: Google, IBM, RH and Pivotal hold "seeding" seats but the committee is elected from community nominations. See maximal representation in Kubernetes steering election process: https://github.com/kubernetes/steering/blob/master/elections.md#maximal-representation

[jchesterpivotal]

I don't object to this idea, though I assume it means there would need to be a some kind of secretariat to manage the elections process. Kubernetes gets this through the CNCF.

[rgregg]

I hear this feedback loud and clear, but we're still in the early days of this project and rely on organizations to provide the majority of support to the project. I also don't see us having the machinery nor human-power that would be necessary to run the full process that k8s uses for managing their project and steering committee elections.

I've based the proposed process here off what's working for Istio today, which is in a similar state to where we are with Knative. As our project matures, I think adopting more of the k8s processes may be worthwhile.

Given the importance of the organization backing for this project during our growth phase, I see it as necessary and appropriate to have the seats held by organizations instead of individuals, but I understand the pushback.

[jchesterpivotal]

I'm a bit unclear about what this is trying to convey. Is it meant to be a rule about who is considered to be absent, or is it a rule about being considered to agree if no objection is given? Or both?

If the former, I am not sure what is gained. An absent person is absent. A rule might be that repeated and/or extended absence triggers the replacement process automatically.

For the latter, I don't think consent by silence is a good rule. If there is an automatic inference, it should be for abstention. Better yet, just record the absence.

[rgregg]

This is unclear in the current iteration, but my intention was to allow for consent by silence.

[jchesterpivotal]

I don't agree at all that silence is consent. Nulls are not a meaningful signal. If the problem is people disagreeing after a vote is closed, that's on them for not being involved. If the problem is inactive members, being able to remove sitting members for failing to attend a certain number properly-noticed meetings without apologies would work.

[RichieEscarez]

I think moving the content out of the Docs repo and into its own repo may pose a problem if we want to keep that content visible on https://www.knative.dev/contributing/. @RichieEscarez can provide more details on that.

A separate Knative repo for Community (including community owned and maintained samples) and also the Contributor guidelines should work just fine with they way the documentation build and publishing works (@rgregg has helped fix some of the SCSS in the site and is familiar with our docs build script).

FWIW: Im on board with this content restructure as it would allow this content to remain in master as the only version (single source of truth). (Otherwise, due to the fact that our documentation is "versioned" (branched) for every release, the Community and Contributing content is unnecessarily duplicated/copied into an "archive branch" each time.)

QUESTION:
@mchmarny , the BLOG content is also another set of documents that do not need to be versioned each release and also more Community related, can that content also move into the new knative/repo (to also live as a single set of "unversioned" files)?

[rgregg]

I opened #1018 to track the creation of the new repo and moving the community governance content there -- that way we can have the conversation take place separately from the underlying governance issue that I wanted this to really be about.

[csantanapr]

Thanks @rgregg I left comments

[csantanapr]

Since this is cover below in the Charter section https://github.com/knative/docs/pull/1017/files#diff-f02a39b268435b05d07ea4fabe284e16R34

I recommend removing the sentence However, the KSC
acts as the final escalation point for any and all decisions within the project.

[csantanapr]

The "the soul" is too vague to quantify or clear definition here. I thing things mentioned in the start of the sentence cover the "spirit" like "vision", "values", "mission", and "scope".

I recommend removing - to establish and maintain the soul of Knative.

[csantanapr]

I believe today we only recognize "working groups", adding "community group" is too vague, either remove "community group" or link to a document that list such groups.

[csantanapr]

Add here also "confirms" new members nominated by a company.

[csantanapr]

Provide more information on why the meetings are not public, I think this will make the community feel better and avoid the assumption of conspiracy, collusion or secrecy :-)

Something like nature of the discussions (ie privacy, private emails to the committee, code of conduct violations, escalations, dispute between members, security reports, etc..)

[csantanapr]

I would add the followings responsibilities to the committee for now, until further process and groups are defined to cover these items:

1. All members would have access to the committee email, any email send to the comittee it's privacy ie maintain by the members.
2. Receive security reports via committee email and work with the appropriate technical leads to respond to the report as rejected or accepted, and oversee that the technical leads handle the report appropriately in private until the CVE is disclosed to the broader community.
3. Receive reports about code of conduct violations, and handle these reports and take actions protecting confidentiality.

[csantanapr]

Do we want to list here the list of "core" repositories for clarity?

[csantanapr]

If the document is "guidelines" then I would avoid the wording "Rules"

[csantanapr]

Change to "must use" same as the docs?

[csantanapr]

Add link to section below "grounds for removal", _see [Grounds for removal] _

[sebgoa]

"one of the members of the TOC or SC "I suppose that's what is meant by "us"

[rgregg]

Yep, I'll make that clear.

[sebgoa]

I don't like the term "control", I would prefer to see "govern"

[sebgoa]

Why "defend" ? Are we under attack ?

How about "promote" ?

[sebgoa]

If there is a nomination process, that means that there is voting process later described ?

[rgregg]

I attempted to outline that process in the section on allocation of seats and how are steering committee decisions reached sections. Do you think there is more clarity to the process I can add?

[sebgoa]

"open to the public". I think members of the org should be able to attend though.

[jchesterpivotal]

This is tricky. There are often legitimate reasons for committees to have private meetings.

A typical compromise from regular meeting law & custom is that under normal circumstances, a committee meeting may be attended by members of the organisation and/or the general public. But when the committee needs to discuss a sensitive matter, it votes to continue "in camera" (though for clarity, these days this is usually "in private" or "board only"). At this point non-committee members leave the meeting and it continues in private until the committee votes to lift the restriction.

[pmorie]

In Kubernetes, I believe that most steering committee meetings are private, but there are regular public meetings that anyone can attend. We should consider adopting that model.

[rgregg]

For this update, I've left the language in that meetings are private, with public meeting notes (this is what k8s does). I'll suggest that the members of the KSC decide, in a future meeting, if they want to do more than this (k8s also posts video recordings of their private meetings).

[sebgoa]

And the "community" as no say to who that person is ? So a company could nominate a totally new person to the project.

[rgregg]

Deciding whether or not a nominee is right for the project would be decided by the existing members of the KSC. While a company could nominate a person completely new to the project, it seems unlikely they would be confirmed by the committee members.

[sebgoa]

That means that a great contributor to the project could get kicked out of the KSC because his/her company changed status. That seems wrong. That means that the project would loose "institutional" knowledge just because of a change of employment.

I really would like to see us/you re-think this concept of allocating seats to a company.

[sebgoa]

And here is the difficult point. The quorum means that Google has full control of the project. Since 4 seats out of 7 are allocated to Google.

[rgregg]

This is true. These changes are mainly focused on taking a first step towards making the steering committee more open -- adding seats for additional non-Googlers, and ensuring that we have better transparency for when, how, and why decisions are made. It does not attempt to change the overall governance of the project, which has been in Google's control from the beginning of the project.

I think that's a reasonable question for the KSC to take up once these new rules are accepted.

[sebgoa]

the problem is not in the quorum and majority vote, the problem is in allocating seats to vendors and not individuals.

You could say: Google, IBM, RH and Pivotal hold "seeding" seats but the committee is elected from community nominations. See maximal representation in Kubernetes steering election process: https://github.com/kubernetes/steering/blob/master/elections.md#maximal-representation

[sebgoa]

The Kubernetes community took a long time to develop their SC and the process to do its election. I would be in favor of a uniform set of governance rules.

Let's just adopt their mechanisms and be consistent within the overall Kubernetes community

[jchesterpivotal]

I don't disagree as a starting point, but I would want to make clear that we can amend the rules independently of Kubernetes and that rule amendments by Kubernetes don't necessarily flow to Knative rules. Put another way: a hard fork, not a tracking branch.

[sebgoa]

I have nothing against Istio, but I believe that the k8s process (which has not been easy) has shown success. It should not be "Istio is using this so let's use the same", when this is still unproven.

[bbrowning]

Thanks for writing this up Ryan! I agree with others that ideally we'd have a governance structure that doesn't retain power within the hands of one company. But, when you look at how much the project relies on Google humans (working group leads, engineers, on-call infra staff) and resources (CI, release artifacts, video conferencing, team drives, etc), the proposal seems like a realistic balance in the near-term.

The steering committee doc explicitly states that seat allocation should be reviewed at least once a year, that we expect to add seats as the project continues to grow, and that the governance will continue to evolve as the project itself does. That along with the addition of 3 non-Google seats to the steering committee feels like a good first step.

So, I support this proposal as written.

I also suggest the steering committee think about what it would look like to move the project from one controlled by Google to one controlled by the community, outside of a single corporate backer. What would need to happen for Knative to continue to thrive if any single corporate backer, including Google, pulled out? Is the long-term plan to end up in a foundation or similar entity? Even more mundane things like how would a non-Google working group lead press whatever button you all press to let people into the working group meetings?

[sebgoa]

The big advantage of foundation is to provide an unbiased common ground for different vendors and independents to work together on a project.

I am definitely a big +1 on moving Knative to CNCF ASAP and benefit from their experience and governance process. We could punt on this document and go straight to CNCF.

As it stands I fear that the project would see a slow adoption from "the community" which will see it as being heavily vendor driven and locked by Google. It is clear that without Google the project would not work, this is not disputed. But we need to have a governance from the get go that shows diversity and openness.

I totally understand and believe the good faith of everyone involved but governance (and bylaws) are about safe guards against unforseen abuse through loop holes, that's why things like quorum and voting rules need to be spelled out.

[csantanapr]

I think the topic of “foundation” establishing a new one or joining an existing one like CNCF or joining under a project already in a foundation like Kubernetes is good goal to be discuss by the comitee.

Perhaps as good faith I would add a bullet under responsibilities that the committee would evaluate and discuss such “foundation” topic and build a proposal to be share with the folks outside the comitee for feedback at some point time in the future.

[vbatts]

(being in CNCF does not mean your project's governance is handled. CNCF just checks that you have an established governance)

[sebgoa]

(being in CNCF does not mean your project's governance is handled. CNCF just checks that you have an established governance)

I think they do need to insure that there is diversity in the steering committee. And I am pretty sure they would help establish a governance structure.

[bbrowning]

I didn't mean to lose focus on this proposal by mentioning long-term plans. But, it does look like there's at least some desire in the community to explore and communicate a longer-term vision about what success looks like for Knative.

To me that feels like something we can ask the members of the steering committee to do, as opposed to something that needs to be written down in the definition of the steering committee itself.

[mchmarny]

/lgtm

[isdal]

/lgtm

[mchmarny]

/approve

[mchmarny]

/ok-to-test

[knative-prow-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mchmarny

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mchmarny]

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

[knative-prow-robot]

New changes are detected. LGTM label has been removed.