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.



--

--

Josh Berkus

Kubernetes Community

Red Hat OSPO