Simplify Working Group and OpenGitOps project Governance

[scottrigby]

Follow-up from #86
Resolves #40
Co-chair election results here
Maintainers list updated #136

We're ready to update the provisional bootstrapped governance now that the
GitOps WG and sandbox project roles and relationships are more clearly defined.

• Attempted to outline known processes as explicitly as possible, while keeping
  as simple as possible given the context. Looking for feedback on this
• Bring initial GitOps WG charter into a charter.md, with some updates
• Simplify GOVERNANCE.md
• Removed stray .gitignore file

To-do:

• Draft PR
• Chairs consensus
• Maintainers consensus 👀
• Announce change on the mailing list after merging PR
• Announce change in next GWG meeting
• Update "Clearly established governance" date and description in README Timeline in a new commit on this PR

Future:

• Keep charter in WG repo (with a section on how the WG is governed), and potentially move governance doc to OpenGitOps project repo, focused just on how the project is governed

Signed-off-by: Scott Rigby scott@r6by.com

[todaywasawesome]

If membership is self-declared, each company can only get two votes, and members can vote how do we deal with conflicts of self-declared membership within a company? And how do we deal with people affiliated with more than one company?

I'm not sure how this is solved in other orgs. In the CNCF, you basically have to pay dues in order to have votes on different committees etc.

[scottrigby]

Good points Dan.

I'm not sure how this is solved in other orgs. In the CNCF, you basically have to pay dues in order to have votes on different committees etc.
If membership is self-declared

The GitOps WG was announced as an "open group". But it also initially asked people to "register" their interest.

I like how CNF WG governance says membership is self-declared. They then circumvent the possible problem of a company "stacking the deck" by limiting to one vote per org (so you can have 50 employees from one company involved, but that doesn't give the company any unfair advantage). To avoid unfair last minute surprises, they also specify a list of "interested parties" who can vote, which must be listed at least one week before any vote. It all sounds pretty fair to me. What do you think?

each company can only get two votes, and members can vote ​how do we deal with conflicts of self-declared membership within a company?

My sketch had 2 votes per org (from other CNCF GOVERNANCE examples, like Cortex), but now that you say this maybe that just confused things. If we follow the above process, we may want only one vote per organization as CNF governance does, to avoid any confusion.

As far as conflicts within a company goes, isn't it up to each org how they wish to cast their org vote? I'd like to offset this responsibility to the employees of that org to know how to properly communicate and decide this internally.

In general I think the idea of limiting number of votes per entity in general allows a WG to maintain independence from the companies and orgs that provide its members, and keep the direction as balanced and neutral as possible.

And how do we deal with people affiliated with more than one company?

I'm not sure, but I'd like us to set up a simple election model that expresses a spirit of fairness and balance, and ask the group (and chairs) to use common sense around this. CNF has an entire section on determining independence, but I didn't think we needed to get that detailed for this WG.

[scottrigby]

PS, the CNF WG interested parties doc is only a list of companies. Whereas I kept the existing GitOps WG list of "interested parties" from the initial charter draft google doc, that also included people's names. I don't think this is necessary for governance, but it is kind of nice that people from various orgs have a way to self-declare their interest. What do you think?

[scottrigby]

Pushed changes to clarify

[rficcaglia]

I'm guessing this is not under CNCF? there is a formal governance process for CNCF WG formation and governance:

https://github.com/cncf/toc/blob/main/workinggroups/README.md

EDIT: Ah sorry I noticed just now someone else had posted a link to this.

another example from Kubernetes TOC:
https://github.com/kubernetes/community/blob/master/committee-steering/governance/wg-governance.md

I'm not saying this group needs to follow either, but...if we want to merge into one of these, then we will need to align at some point.

[murillodigital]

Suggested change

	Before each election, there will be a call for nominiations on the mailing list.
	Before each election, there will be a call for nominations on the mailing list.

[scottrigby]

👍 to changes just made by @todaywasawesome @murillodigital

[csand-msft]

Any thoughts about max # of consecutive terms for an individual?

[scottrigby]

@csand-msft LIFETIME!!! 👑 lol j/k. No strong opinion on this one 🙂

My main concern is to keep this as simple as possible, while learning what we can from other CNCF project governance docs. Ultimately whatever's best for the stability, fairness, and momentum of the group and project.

Personally my gut feeling is setting max terms isn't necessary, since requiring reelection annually should self-govern and weed out anything weird. WDYT?

[scottrigby]

We can also continue to iterate on governance after merging this PR.

[csand-msft]

Approve with one comment.

[csand-msft]

Approved.

[scottrigby]

@rficcaglia Hi yes, thank you!

I'm guessing this is not under CNCF? there is a formal governance process for CNCF WG formation and governance:

https://github.com/cncf/toc/blob/main/workinggroups/README.md

EDIT: Ah sorry I noticed just now someone else had posted a link to this.

another example from Kubernetes TOC:
https://github.com/kubernetes/community/blob/master/committee-steering/governance/wg-governance.md

I'm not saying this group needs to follow either, but...if we want to merge into one of these, then we will need to align at some point.

Yes the GitOps Working Group is already a TOC-approved WG under CNCF App Delivery TAG (formerly SIG).

The historically fun – and initially confusing – thing about this is that the "GitOps Working Group" was also the preliminary name for a CNCF Sandbox project, which was meant to be a home for lasting programs, documents and any code by WG. However, that name was just a placeholder – as discussed in the TOC Sandbox review – and since then the sandbox project has been renamed to OpenGitOps. See this discussion and answer for linked details.

For historical purposes, here was the initial GitOps WG Charter.

And here is the onboarding issue for the CNCF project by the TOC. Even though the issue is still titled [PROJECT ONBOARDING] GitOps WG, it is now really for the OpenGitOps Sandbox Project, which is led by the GitOps WG for as long as the WG is necessary.

I hope that clears some of this up! If still unclear we can either chat more about it here, on Slack, or in one of the upcoming WG meetings 🙂 I'm hoping that once the OpenGitOps project rename is complete and announced, it will be less confusing.

[scottrigby]

We already have a 2/3 supermajority vote among maintainers. But if it doesn't take too long for further change requests or approval, it would be nice to have unanimity 😇 @jlbutler @chrispat WDYT?

[rficcaglia]

my concerns were addressed!

[kmf]

If it counts for something, I approve.

[jlbutler]

Sorry to join the party late. LGTM 👍

[scottrigby]

Thank you all, we have unanimity ❤️

We can iterate on this in follow-up PRs 🚀