It would be nice to have some sort of automation around this as well. Would we be able to create a questionnaire that helps projects understand where they fit best and put the heavy lifting on them to engage? Not that SIGs shouldn't communicate but it would push the responsibility to them as also provide a means to manage their own destiny. Just a thought, Erin
On Fri, Nov 8, 2019, 2:03 PM Quinton Hoole < quinton@...> wrote: Yes, I agree. The model I've been proposing is to select one SIG as the primary caretaker for each project, and have them responsible for engaging other SIGs where appropriate. Here's one nascent example:
If anyone has any better/alternative suggestions, they would be most welcome.
Q
One other angle/comment: We have a model right now a SIG owning some level over oversight over a project. But the mapping may not be that clean. A project may be primarily in a specific space but there may be aspects of that that cross
all the lines. (example is security, but there are others, I’m sure). We need to find the right way to involve the right SIGs at the right times.
Joe
Having gone through some of the debates when we first put the SIG charters together, there are a few other considerations I'd like to add to the debate :-)
In general I think SIGs should bias towards having a broader rather than a narrower scope:
-
A larger/broader SIG community creates critical mass which helps participation and, more importantly, encourages collaboration and information sharing between different projects or initiatives
-
Narrow scopes tend to lead to ambiguity as to where different initiatives should sit - this can cause delays/debate - and this means a lot more "shepherding" by the TOC to help guide and liaise - which might hamper the original
objective to allow the TOC to scale
This was part of the original governance/operating model for the SIGs: Each SIG was to have a number of co-chairs - specifically to allow load sharing and continuity over time. The focus for specific
projects/initiatives is then applied to the tech lead role - of which there can be as many as needed based on the workload/diversity of topics in the SIG scope. This allows the tech leads to be focused on a specific area, whilst the co-chairs help manage
& co-ordinate.
Of course, nothing is static and ideas & orgs evolve over time, so there are always changes that can be applied.
Also, agree with the points about getting content around SIGs on the website (which will help participation), better (and more explicit) management of SIG priorities (which I guess should also
reflect the TOC priorities).
Thanks Liz
This is exactly the discussion I hoped to spark, so I definitely don't mind your debate :-)
Michelle and I happened to have a chat about this today, as she mentioned, and will discuss further with the TOC.
In summary, my personal opinion is that we need to:
1. Agree what the scope of the CNCF is.
2. Partition that scope into bite-sized chunks that cover the entire scope (these were the original 7 proposed SIGs).
3. Make sure that each of the chunks is appropriately taken care of. Over time the details of "appropriately taken care of" will clearly change, as hot spots come and go (FaaS, Service Mesh, Secure Containers, Edge, ..... ), projects come
and go, etc. In the extreme, a chunk may be completely dormant for a period of time, or temporarily focussed on one specific subset. But it's still a chunk of the logical total CNCF scope.
There are many different ways to execute on the above. The 7 originally proposed SIG's and their scopes are one way.
Other ways are fine, as long as they achieve the overall goal over time.
There are several possible ways to implement the above strategy.
On Thu, Nov 7, 2019 at 11:01 AM Liz Rice <liz@...> wrote:
I've been mulling over Quinton's comments on the last TOC call about SIGs reducing their scope.
-
SIGs are there to help the TOC scale, with expertise and/or time that the TOC members don't necessarily have. It would be nice if the whole Cloud Native landscape were neatly divided up amongst SIGs, but I am sure that the landscape is evolving, and we're bound
to end up with things that we didn't anticipate. The TOC remains the decision-making body, and it's also the place where we decide what to do with topics or projects that don't naturally fit in a SIG. So it's OK, and natural, if there are gaps between them.
-
SIGs (and the TOC for that matter) consist of volunteers, who have some finite amount of time to devote to SIG/TOC work. They'll probably achieve more if they stay focussed.
-
The TOC needs to help SIGs prioritize what they're doing. This week Joe and I have been working with SIG Security on exactly this, hopefully it will serve as a template for other TOC-SIG liaisons. I do think that as volunteers, SIG teams (through their chairs)
should be able to influence these priorities.
-
We need to get away from submission-driven prioritization - it would be better to evaluate gaps in the landscape and consider possible alternative projects. So SIGs ideally *should* be focusing on particular areas within their scope
-
SIGs can evolve!
So with all that in mind I've come to the conclusion that actually a SIG reducing their scope could be a healthy sign of focus and enthusiasm. wdyt? Quinton, I hope you don't mind my debate/disagreement :-)
There's not a lot of participation yet in some of the SIGs. I'm hoping there are folks out there who would like to be on the TOC one day, and want to get relevant experience - being meaningfully involved in a SIG should be a great way to
do that (it's one of the goals of the SIGs). So how can we get more folks actively involved?
--
--
|
