toggle quoted messageShow quoted text
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 like as CNCF has grown, perhaps there is now a desire to be more explicit about the types of governance we want projects to have? This is something those of us on the Governance WG would love to get more direction around so we can help make templates, etc and build programs that would benefit projects.
On Tue, Aug 25, 2020 at 12:46 PM alexis richardson <alexis@...> wrote:
Nobody is suggesting imposing anything. That suggestion is a red herring.
+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 would fit under a steering committee charter.   We even mentioned this in our latest update .
Having a steering committee imposed on the project would just create more process and impair innovation for us. It's not that we are necessarily against the idea, we just aren't there yet as a project. Furthermore I doubt any of the engineers are going to be keen on introducing process to solve a problem that doesn't exist yet for the project. As far as end-users are concerned, we see them engaged in all of the community activities and contributing to the process outlined in the references below. Again -- we just aren't there yet.
I look at a SC like a tool. It's a well-known tool, that obviously works to solve well-known issues for folks. Can we just keep it at that? It's a tool. The tool works well, if you happen to need it and decide to use it. <click here to read more>
TLDR; I thought that the whole point of this was that the CNCF didn't impose rules/regulations on how projects self-govern? Maybe I am mistaken, but I thought that was -- like -- a thing.
On Tue, Aug 25, 2020 at 12:38 PM alexis richardson <alexis@...> wrote:
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. Many projects now have numerous repos and moving parts. The direction may not be clear. End users may want more of a say. Contributors and maintainers should welcome this, and most do.
On Tue, 25 Aug 2020, 20:30 Josh Berkus, <jberkus@...
On 8/25/20 12:20 PM, Alexis Richardson wrote:
> During the summer break it occurred to me that many of the advantages i
> could envisage in adding SCs would be achieved if the notion of
> Maintainer was broadened to include non coding people. But you still
> get benefit from org level direction over the top.
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 benefit --
generally the exact same people are on the SC as are in the other
groups. Unless you add someone from outside the project, in which case
you have different problems.
For a small project, I'd recommend (were I advising them) trying to
broaden their maintainers group to include non-code maintainers (like
docs and advocacy), which is usually a better approach when dealing with
a small pool.
Of course, it's really up to what the project wants.
> Fwiw, i don't believe in imposing or forcing things either. Apologies
> if I have given that impression.
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 one.
BTW, in this thread I am speaking as a single member of SIG-Contributor
Strategy, and not for the whole committee. Other members of the SIG may
well disagree with me. I am also not speaking for Red Hat.
Red Hat OSPO
Chief Open Source Advocate
85 2nd Street
San Francisco, CA 94105