I can only make the governance meeting - we have our meetings with the EU during the TOC meetings unfortunately. If we push the TOC discussion back until the next call I can make it. -- Kris

+1 NB

I'm keen to discuss this in the TOC, and then work out details in the various WGs and community. When is everyone back?

+1 binding Katie Gamanji

Hey, all: If you want to continue this discussion, I wanted to invite anyone interested to attend the Governance WG meeting on Tuesday at

+1 binding

Just a heads up, Jeff will be stepping down from the TOC next month and we will run an election within the end user community: https://www.cncf.io/people/end-user-community Please see GitHub for

+1 binding

There's going to be a huge gap between the governance structures we *recommend* and the ones that are *acceptable to CNCF*. The CNCF was founded on having considerable autonmy for projects in

+1 binding Great addition to the graduated suite of CNCF projects!

Not trying to create a fallacy - apologies - these threads seem to be glamorizing steering committees more and more - and I just wanted to advocate that not every project needs one. -- Kris

+1 to Josh Speaking as a Falco maintainer here, our community just re-vamped our model for how we manage sub projects, official support, and decision making in the open. All of these seem like they

Thanks for bringing this up Stephen. I would suggest that the structure (which includes SC or not) can't fix problems that may be cultural. For example, knowing ones audience is important. Taking the

Agree. The underlying issues are set out here https://docs.google.com/document/d/11Hiz1dGYRS7GcjedpRVnSlDjIj0AVjeTa0-Td7aW-Lk/edit?usp=drivesdk

I think we can all agree that there is no one way to do open source, and that every project has different needs. I do echo Kris' comment about CNCF having an opinion on how projects govern. It seems

> We have to recognize that if we make an SC an alternative for other governance requirements, that will result in an SC being imposed on a few projects where the contributors otherwise don't want

Nobody is suggesting imposing anything. That suggestion is a red herring.

(+ SIG ContribStrat) I could see the overarching theme as "distilling what it could mean to be a 'good maintainer'". SIG Contributor Strategy is exactly the kind of venue to have this discussion and

Agree that SC should (if suggested) remain a known good option, and Not Compulsory. Agree that some projects are "small" - but i would have said Helm is small! My belief is that SCs can help growth.

And for large projects like Helm, an SC has these benefits. Just like Kubernetes. But in smaller projects, where you're looking at a couple dozen regular contributors period, there's not a lot o