Steering committee establishment

[david-martin]

Supercedes #4

The goal of this change is to lay the rules for the establishment of a steering committee.
It is based on the guidelines and template from https://contribute.cncf.io/maintainers/templates/governance-elections/
as well as the voting process from kubernetes at https://github.com/kubernetes/community/tree/master/elections

That steering committee will, among other responsibilities, make future decisions on project goals, strategic direction, governanace and setting up other committees like a technical committee, if desired.

Nothing is set in stone here. I would encourage feedback on all aspects of the changes here.
Some things can be arbitrary or subjective, like the rules for becoming a contributor, maintainer or who can vote.
Also, some areas, like how the first vote will be carried out, has not been decided yet.

[david-martin]

Suggested change

	Each elected member will serve a two year term.
	As we are starting from scratch with a bootstrapped committee, will will need a transition period, but plan to have staggered 2-year terms.
	2 members will be elected for a 2 year term, and 1 member for a 1 year term.
	This is to ensure continuity of the committee.
	After year 1, that 1 seat will be up for reelection and span a 2 year term.
	After year 2, the other 2 seats will be up for reelecation and span a 2 year term... and so on.

[jasonmadigan]

Given our nascence, would it be fair to assume we will have more than one seat from an individual company given the project's roots?

Is the 1 seat per company usual? Feels like a SPOF

[david-martin]

Yes. Unavoidable at present. I think that's fine.

The limit depends on the overall size of the group.
So if there's 5 in the group, no more than 2 would make sense so that no 1 company can control the project.
If we went with 3 (as is suggested at present), having a limit of 1 would prevent that.
This isn't set in stone, and more of an intent at this time.

[jasonmadigan]

Makes sense, yeah I think that's fine.

[jberkus]

Do y'all have 3 different folks from different employers who are otherwise eligible and willing?

[david-martin]

I would say this is a 'no' right now.

[alexsnaps]

So, I have... questions.
Given the nature of work for the Steering Committee (see ## Charter section of this PR), and I think I'm mostly focusing on two sorts of responsibilities here:

• The tech part: ownership & vision of the project
• CoC & other "managerial tasks"...

I think having a "wider" (i.e. including users of the project) voting base, while requiring candidates to be tech savvy (i.e. having committed code) would be a good thing for the project. Plus, having a public track record of how "candidates behave" here on GH would be good input to voters to make a call as well.

Anyways, suggesting...

[alexsnaps]

Any pointers as to how these threshold were decided upon?
My question is actually mostly: do we really need these? Also, what's a contributor anyways? Isn't anyone who contributes, a contributor? Something that tangibly would probably result in a PR to "something"? i.e all of these people for all our repos?

Also, tho I'd generally be against such a large PR/code change, couldn't a single (or two) PRs grant a user with the request to become a contributor "with a lower threshold" based of the work that represents?

[david-martin]

Any pointers as to how these threshold were decided upon?

Based on the template.

do we really need these
Entirely up to us.

Also, what's a contributor anyways? Isn't anyone who contributes, a contributor?

Grammatically, sure.
It's up to us to define what's the threshold for being able to have some official power (like voting).

couldn't a single (or two) PRs grant a user with the request to become a contributor "with a lower threshold" based of the work that represents?

Sure. Do you want to suggest some modification that captures that?

[alexsnaps]

contributor, not maintainers...?! I think the ROLES.md starts to make more a little more sense.

[david-martin]

Suggested change

	open to any project contributor. See
	open to any project maintainer. See

?

[alexsnaps]

So somewhat rules out "users", is this on purpose? Desirable?

[david-martin]

I'm not against users having a say.
Is it feasible to keep a record of users though.
How would you see that playing out for voting.

[alexsnaps]

Given we have a solution that probably mostly targets developers (even if YAML ones), would it be crazy to require users wanting to vote to "record" as users of any of our components? Or just "star" one of the repo? I guess the problem is needing a way to track individual votes... so a platform that would let users link to their GH account, and that's it? Thinking out loud here, I might well be missing a big part of the problem to be solved.

Again, given the responsibilities of steering committee members being both technical but also "community" ones, being more inclusive in the way they are elected seems desirable... And I feel having "only contributors", given the criteria above, being the voters, seems a little like a close feedback loop to me. But again, maybe I'm missing some aspect of this and could also well be a little too much of a dreamer 😜

[jberkus]

I don't know any project that allows "users" to vote, simply because there isn't any good way to verify a user's eligibility. The closest I've seen is that some projects, like Cert-Manager, allow representatives of the organizations in their Adopters.md file to vote on an end user seat.

[alexsnaps]

Suggested change

	* Delegate ownership of, responsibility for and authority over areas of the
	* Delegate ownership of responsibility for and authority over areas of the

[david-martin]

I think the comma is needed here.
Otherwise it's 'ownership of responsibility', when I think it's meant to be the combination of 'ownership, responsibility and authority' of 'areas of the project to specific entities..`

[didierofrivia]

I'd exclude "financial planning" from this sentence and everywhere in the document, in order to avoid misconceptions for the OS community

[didierofrivia]

Unless we really want to be the ones managing any kind of budget related to anything Kuadrant (upstream) related.

[david-martin]

Suggested change

	sub-organizations, and financial planning. The Steering Committee also defines
	and sub-organizations. The Steering Committee also defines

@didierofrivia just removing this seem reasonable?

[jberkus]

Do note that, as part of the CNCF, the project may have financial resources of its own. If those are not managed by the Steering Committee, who will manage them?

[david-martin]

project may have financial resources of its own

Got an example of how that might come about?

who will manage them

Good question. Sounds like we need some clause for it here. If not, would it be delegated to some CNCF people?

[jberkus]

It can't. The CNCF expects the project to make requests for any money it needs, and to lead any activities which require financing. The staff won't do it for you. If nobody in the project does this, they'll just assume you don't need any resources.

[didierofrivia]

Suggested change

	* Fairness: All stakeholders have the opportunity to provide feedback and submit
	* Fairness: All collaborators have the opportunity to provide feedback and submit

[david-martin]

This is an interesting change.
I wonder if stakeholders implies 'users' as well, while collaborators wouldn't?
cc @alexsnaps as you mentioned users in the context of voting elsewhere in the doc

[didierofrivia]

I reckon we should be cautious about these 2 points... Maybe we need guidance on how to proceed (?)

[david-martin]

I wonder if we can get some guidance from @jberkus (or someone else in CNCF) on what the implications of these point from the template actually mean, and if they are needed.

[jberkus]

Those are both things that the CNCF asks the project to decide on. In the absence of other governance, they ask the "maintainers".

As a CNCF project, Kuadrant is entitled to, with the approval of the TOC/GB (depending), spend CNCF funds on needed things. As an example, the CNCF pays for Buttondown and Boost subscriptions for Kubernetes. Someone has to have the authority to request this funding.

[jberkus]

For that matter, if a vendor wants to have an "official Kuadrant distribution" then that would depend on a program of certification owned by the steering committee.

[david-martin]

having a public track record of how "candidates behave" here on GH would be good input to voters to make a call as well.

@alexsnaps Is there something objective in what you're thinking here, or more a way for people to point to specific comments and say a person seems like they'd act 'good' in the community?

[jberkus]

What about people moving from a contributor role to a component maintainer role? That is, someone who isn't a general maintainer, but wants to move up to a component maintainer?

[jberkus]

This says 10 contributions, but the threshold for "contributors" is 50 contributions. It'll make your life easier if both have the same threshold.

[david-martin]

Good catch.
I'll leave this comment thread open as a reminder to sanity check numbers across the doc before anything gets merged

[jberkus]

So, one question to answer here: why a steering committee rather than a maintainer council? What outcome do you want from having a steering committee, instead of a governing council of all maintainers?

Asking because that's very important for deciding if this is the right governance for you.

[david-martin]

So, one question to answer here: why a steering committee rather than a maintainer council? What outcome do you want from having a steering committee, instead of a governing council of all maintainers?

@jberkus My reason for driving this is to make it very clear what roles people have in the project, how they can transition between roles, and how people coming from outside the project can see a way of getting more involved in the project.
I also wanted to make it clearer to everyone how important decisions are made, and who generally makes those decisions. Right now, we don't really vote on things. There's opportunity on community calls and PRs (like in an RFC PR) for discussion, and ultimately if there's no major objections, things are agreed and proceeded. There's a few key people (sometimes depending on the area) that people tend to look for an ultimate yes/no on decisions. These people haven't officially been voted for, but they're generally agreed to be like the main decision makers.

steering committee rather than a maintainer council
Is the main difference here startegy and goals vs. technical decisions and codebase?

[jberkus]

@david-martin right, but you should be contemplating two separate structures (at least):

Maintainer Council: A named group of maintainers, with defined processes and membership, makes all technical and nontechnical decisions for the project.

Steering Committee: A named group of maintainers, with defined processes, makes technical decisions for the project. Another committee, the SC, elected by project members, makes (mostly) nontechnical decisions for the project.

Generally, the reasons projects have for moving to a Steering Committee includes one or more of the following: (a) too many maintainers for reasonable decision-making (b) lots of semi-autonomous subprojects (c) need to represent specific non-technical interests (like sponsors or adopters) (d) the presence of several strong, leading technical maintainers who don't care about "project management stuff".

So I'm asking what's your specific reason to move to an elected SC structure as opposed to a different well-defined governance structure? And I'm asking this because a lot of the questions on this PR are arising because I suspect that the current maintainers aren't sure what that reason is.

[david-martin]

@alexsnaps @jasonmadigan @didierofrivia @guicassolato what are your thoughts on going with a maintainers council rather than a steering committee?
From reading Josh's comment above, it sounds like it might be a better fit for how things currently work.

@alexsnaps in terms of contributions to become a 'maintainer' or 'contributor', the wording is a lot less strict (albeit more subjective, but I think that's fine and more inline with what you mentioned above in your comment).
Also, the maintainers council (which sounds like it would be everyone that's more or less involved in the project) would cover both the strategic and technical direction of the project, without any delegation to a specific small group of people.

@didierofrivia There is no mention of financial things in the maintainers council template. There is mention of 'CNCF resources' which could cover that side of things though if they arise?

@jasonmadigan In terms of voting, there's a section on voting and following a 'lazy consensus' model (which I tend to like). If there's a need for more formal voting, that's possible too. Both these things sound like what we've already been doing inherently.

[guicassolato]

I wonder if the 50%+ quorum couldn't be increased (e.g. min 2/3, though I personally would prefer "unanimous"), and decisions made possible to happen async/offline, with a minimum voting period (e.g. couple days).

Additionally, I wonder if there should be veto power established for some cases.

[guicassolato]

[…] decisions made possible to happen async/offline, with a minimum voting period (e.g. couple days).

Additionally, I wonder if there should be veto power established for some cases.

I think there's an element of the "Lazy consensus" thing here in what I meant.

[guicassolato]

@alexsnaps @jasonmadigan @didierofrivia @guicassolato what are your thoughts on going with a maintainers council rather than a steering committee? From reading Josh's comment above, it sounds like it might be a better fit for how things currently work.

I suppose the structure of a Maintainers Council is relatively simpler compared to Steering Committee – more flexible composition, no need to hold elections, looser requirement regarding employer representation, no fixed duration terms for the member in the council. Are these all fair assumptions?

[didierofrivia]

I agree with you @guicassolato, much simpler, flexible and with enough room for improvement without lacking compromise :)

[jasonmadigan]

@jasonmadigan In terms of voting, there's a section on voting and following a 'lazy consensus' model (which I tend to like). If there's a need for more formal voting, that's possible too. Both these things sound like what we've already been doing inherently.

@david-martin yes, I think I had lazy consensus in mind

[thomasmaas]

+1 on Maintainers Council & lazy consensus.