References to "unbiased" (here and in # 4) seem problematic. Do they not automatically exclude project maintainers & tech leads? It is important that the SIG overall is unbiased, through diversity, not the individual members.

Good question. Let me try to rework the wording accordingly. Ideally the individuals would themselves also be capable of being relatively unbiased. As an extreme and contrived counter-example, I don't think that we want a diversity of highly biased and warring co-chairs or leads. I'll try to capture that in words.

I reworded as follows:
"Chairs... recognized as experts in that area, and for their ability to co-lead the SIG to produce the required unbiased outputs."

"Tech leads... demonstrating the ability to provide the balanced technical leadership required to produce the required unbiased outputs of the SIG."

Can this include Object next to Block and File? I mentioned this in the chat of last TOC call, and others approved.

Absolutely! Good catch. Done.

(minor) Kubernetes SIGs.

Done.

SIGs or SIG's?

Need clarification on how to ensure the information is unbiased. Should we publicize the input/information to the project/WG members who are doing the heavy-lifting work if the input/information is related to a project/WG?

@NicolasT Agreed, done.
@cathyhongzhang Agreed. Contributors and their company and project affiliations will be public.

There was some question on the mailing list about whether this is the appropriate name for this group.

Some key concerns:

• The word "governance" is often used to convey human processes of policy (e.g. how decisions are made, roles and responsibilities, etc.)
• The word "governance" is used earlier in this same document to describe how the SIGs should be managed
• The topics for the SIG and list of projects are more about the software used to implement security and privacy, along with ensuring compliance (auditing, etc)
• Some open source projects have a GOVERNANCE.md (or similarly named directory) to define project roles and decision-making process (examples: Node, cloudevents, SAFE, docker, k8s community)

Alternative suggestions that were made:

• Security
• Security & Policy
• Secure Access for Everyone
• Security & Compliance
• RegSec
• Security & Governance
• Oversight

@izgeri Agreed. All SIGs will have the opportunity to wordsmith their names as part of the chartering process. These names are placeholders. The ultimate names will need to be agreed upon by the SIG chairs and TOC. I will note that there have been objections to all of the alternatives listed too.

@quinton-hoole-2 Is the chartering process defined anywhere? I can't seem to find it in this doc.

@izgeri See the "SIG Charter" and "SIG Formation..." sections.

nit: some have periods, some do not - let's be consistent

Done. Added 3 missing periods.

remove period

done

Period consistency

Done.

This list, and the next one, appears as a code snippet - which is kind of odd. I think it's due to the indentation, but not, sure. Either way, we should make it just normal text.

This one still isn't fixed

Cap first letters and check periods

Done.

Check the formatting of this line - the stars might not be doing you expected.

"CNCF Exec" ? Do you mean "CNCF Executive Staff" ? Or do you mean "Executive Director" ? Let's spell out GB since this is the first use of the acronym.

Yes, done.

Are they one of the 3 co-chairs or are they a 4th? What is a "non-exec chair" vs a "normal chair" ? Can we define what we mean by that?

Do we expect them to be very active within the SIG or just act as the liaison to the TOC? I'm asking because if they're more of a liaison then I'm not sure why we're making them a chair - I think chairs need to be very active.

@duglin 4th. I think the second half of the sentence makes the intention sufficiently clear? "on occasions when TOC input is deemed necessary by the TOC or the SIG chairs"?

i.e. the intention is that the 3 co-chairs run the show, with the (4th) TOC liason non-exec chair assisting under specific circumstances when requested to do so.

Do you think we need to add more clarity than what is already there?

Yup I do because I can interpret this as.... we have a 4th chair that could choose to do nothing until TOC input is needed and then they wake up and engage. Why? Answer: To talk to the TOC about some issue that they haven't been paying attention to. :-) Seems odd that the other 3 chairs can't talk directly to the TOC if they need their input. I'm not in favor of roles that appear to serve no real purpose. I'm assuming the other chairs are able to speak for themselves to the TOC.

I still don't know what a "non-exec" chair is.

@duglin To be clear, the intention is that the TOC liason effectively represents the TOC on the SIG. That would require that they be sufficiently engaged. The example you sketch is of an insufficiently engaged TOC liason, who would presumably either not have been appointed by the TOC in the first place, or have been kicked out by the TOC (possibly at the request of the chairs), for not doing their job properly.

@duglin If removing the words "non-exec chair" solves this problem, I think that's fine. The main point is that a TOC member is appointed as point person for each SIG.

I think removing non-exec would be good since I don’t think it’s clear what that means.

As for this TOC rep/chair, you seem to be implying that this person speaks for the TOC which I’m not comfortable with since I don’t think the TOC has a single voice/opinion. I would really prefer that if the SIG wants the TOC’s input that they just ask the TOC directly

Do you mean 2/3 of chairs and 2/3 of tech leads, or 2/3 of chairs+tech leads? It's not clear. If we mean 2/3 of chairs, then it might be easier to just say "no more than one chair from the same company" since that's what it means.

@duglin I avoided using the "no more than one" wording, in case the number of chairs (or tech leads) changes. The key point is to avoid a super-majority, not to avoid more than one, necessarily. I'll change the wording to make it clearer that 2/3 or more chairs, and 2/3 or more tech leads (i.e. each individually) will be actively discouraged.

2/3 majority or just majority? You seem to use 2/3 in other places.

We should be clear on whether 50% is is a majority or not for cases where there are an even # of voters. Also, be clear that people who abstain from voting are not marked as "no" votes - meaning, the tally is based on just those people who voted not over all people that can vote. This is true for the entire doc.

Clarified that 2/3 majority is required. Detailed voting mechanics are covered in the charter. The intention is to follow those established decision-making protocols, rather than define new ones.

We don't define quorum in this doc, nor do we define what it is used for? Meeting attendance? Do SIG meetings have to have a certain # of people attend before they can approve an action? We should be clear on the intent here.

Good point. I think we should cover that in the detailed governance guidelines for the SIG's, rather than in this document.

Some WG/Project teams provide white papers, presentations, etc. What is the difference of SIG ones from those produced by the WG/Project teams?

As previously discussed by Alexis, existing WG's will be shut down and reconstituted under the SIG structure. See above wording:

"SIGs may choose to spawn focussed and time-limited working groups to achieve some of their responsibilities (for example, to produce a specific educational white paper, or portfolio gap analysis report). Working groups should have a clearly documented charter, timeline (typically a few quarters at most), and set of deliverables. Once the timeline has elapsed, or the deliverables delivered, the working group dissolves, or is explicitly re-chartered."

In the meeting, there are comments on separating "Ops and Testing" from "App Dev". I support this separation since they are very different. For example, "Serverless involves very different technologies/topics from Chaos Eng". "Ops and Testing" could span a large scope and many projects in other proposed SIGs will involve Ops and testing. It is worthwhile to have a separate "Ops and Testing" SIG. "App Dev" itself could also span a large scope.

@cathyhongzhang Yes, others have expressed similar concerns. The problem is that we don't yet seem to have a clearly agreed-upon seam along which to split this SIG. I would propose that we start with a single SIG here, and one of their first deliverables will be to survey and document the space, decide whether to split into two SIGs, and if so, exactly where.

An alternative approach might be to start with 2 separate SIGs by name, but in reality they would need to work together very closely in the beginning to define their charters so as to avoid undesirable overlaps. Personally I would prefer to start by calling that group one SIG that's deciding where to split.

I think we should start with 2 separate SIGs: PaaS, Serverless etc. go to one SIG while CI/CD, Conformance, Chaos Eng, Scalability and Reliability measurement etc. go to "Ops and Testing" SIG. Mixing them into one SIG brings more confusion and inefficiency than benefit.

+1 on splitting the sigs later.

I agree with @cathyhongzhang, it's already 'complex' to write a clear and focused charter, and those topics are broad with few relation points.

due-diligence-guidelines link repeated a few times, perhaps a text editor hiccup?

I've attempted to fix this and another minor formatting issue via PR to @quinton-hoole-2 branch: quinton-hoole#1

Thanks @ultrasaurus . I'll fold those in.

@quinton-hoole-2 based on your comments on the TOC call today I wanted to elaborate on where I'm coming from with my concerns about this TOC liaison. Based on my experience with the Serverless WG and CloudEvents, our interaction with the TOC is pretty minimal. Maybe we're odd in that respect, but I think we've only really talked with the TOC to update them on our status - which is pretty infrequent. And I'm interpreting that as a good thing - we're just chugging along and trying to do our job.

I would hope that this is how most SIGs will operate. I'm assuming that the only time a SIG would need to get the TOC involved is when 1) some kind of formal decision needs to be made that requires a TOC vote, 2) a status update from the SIG, or 3) some controversial topic has some up at the SIG and they are unable to resolve it themselves - thus needing the TOC to weigh-in (this one is kind of related to 1). But, in the end, I think all of these should get the entire TOC involved, not just one person's POV.

So, with that, I don't think the TOC will be continually pinged by the SIGs as you seemed to suggest during the TOC call today. If I'm wrong, then I question the effectiveness of that SIG :-)

Now, having said all of that... I do think having some kind of "TOC contact" or "champion" is useful to help provide guidance for what the TOC expects of them - but they're more there to provide "process guidance" rather than to "speak for the TOC". Similar to the champions we have for WGs today.

Hopefully, that clarifies where my head is at on this.

@quinton-hoole ^^^ not sure which ID to use :-)

piggy back on Doug's comment here, does SIG co-chair has to be a TOC Contributor ? Would that leads to some limitation ?

@hannibalhuang Yes, that point occurred to me too. I didn't add that particular workding, but I think it's reasonable to ask SIG co-chairs to sign up as CNCF Contributors if they are not already. The intention is not that anyone would be disqualified from being a SIG lead for not having been a CNCF contributor in the past. On the contrary, one of the aims of this exercise is to increase the number of CNCF Contributors who are actually doing valuable work. There exists a sentiment that many of the individuals currently listed as CNCF Contributors are in fact that in name only.

@quinton-hoole-2 great :)

@izgeri As mentioned in the intro, the names are placeholders. I would prefer the renaming exercise to be undertaken holistically by the chosen SIG Chairs and TOC Liaison, once they have nailed down the scope more precisely through community consultation. One objection I can imagine to the alternative name you've proposed is that the two items you include in it do not adequately cover the intended scope of the SIG (e.g. policy enforcement, which is a lot broader than just security and compliance, and cost management, which similarly is not covered by the proposed name). I suggest that the SIG Chairs and TOC Liaison fully describe the scope during the chartering process, and then engage fully in the debate around a suitable name to cover that scope.

@quinton-hoole-2 I totally understand, and our group does want to reflect on this further during the chartering process. We agreed at our last meeting, however, to put in a request to change it in the initial document to better reflect our current understanding of what the group intends to do.

Pinging group members @dshaw @ultrasaurus @pragashj @deva @kbpawlowski @izgeri @hannibalhuang @jasonmelo @tsandall @sreetummidi @ckemper67 @rcolline @duglin @heavypackets @justincormack @lizrice @erikstmartin @quiqie @ericavonb @knowlengr @rae42 @rachelmyers @evan2645 @anweiss @tk2929 @goldberg10 @sublimino @iteration1 @chasemp @xuanjia @morellonet @alban @schu to add your +1 or -1 to this suggestion.

Personally I'm a lot happier with the proposed change to Security and Compliance - it's a lot closer to my perception of what the group intends to do. Even if it's a placeholder that might be refined in future, it avoids likely confusion with "governance" in what I believe to be the normal open source sense i.e. project governance.

As a way to unstick this a bit, I've taken process described by @quinton-hoole-2 and put it in a README, see quinton-hoole#3

In order to actually write down a process, I needed to fill in a few gaps and attempted to imagine something everyone would find to be reasonable.

ok

As a point of information, Kubernetes has a considerable "traffic" component, implementing service discovery and routing.