Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
250 changes: 250 additions & 0 deletions sigs/cncf-sigs.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,250 @@

# CNCF Special Interest Groups ("SIGs")

Proposal by the CNCF TOC and Contributors
Primary Authors: Alexis Richardson, Quinton Hoole
November 2018 - January 2019

Final Draft v1.0

[[TOC]]

## Overall Purpose

Scale contributions by the CNCF technical and user community, while retaining integrity and increasing quality in support of our [mission](https://github.com/cncf/foundation/blob/master/charter.md#1-mission-of-the-cloud-native-computing-foundation).

## Specific Objectives
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Added 3 missing periods.


* Strengthen the project ecosystem to meet the needs of end users and project contributors.

* Identify gaps in the CNCF project portfolio. Find and attract projects to fill these gaps.

* Educate and inform users with unbiased, effective, and practically useful information.

* Focus attention & resources on helping foster project maturity, systematically across CNCF projects.

* Clarify relationship between projects, CNCF project staff, and community volunteers.

* Engage more communities and create an on-ramp to effective TOC contribution & recognition.

* Reduce some project workload on TOC while retaining executive control & tonal integrity with this elected body.

* Avoid creating a platform for politics between vendors.

## Introduction

A CNCF SIG will oversee and coordinate the interests pertaining to a logical area of needs of end users and/or projects. Examples of such areas include security, testing, observability, storage, networking, etc. The area overseen by a SIG is typically met by a set of CNCF projects, and may also represent a cross-cutting feature group shared by several projects (like security and observability). SIG’s are:

* long lived groups that report to the Technical Oversight Committee

* led primarily by recognised experts in the relevant field(s), supported by other contributors

CNCF SIGs are modelled on Kubernetes SIGs. Differences are intended to be minimal to avoid confusion - unavoidable differences are described [here](https://docs.google.com/document/d/1oSGhx5Hw7Hs_qawYB46BvRSPh0ZvFoxvHx-NWaf5Nsc/edit?usp=sharing).

## Responsibilities & Empowerment of SIGs

It is the desire of the TOC that the CNCF SIGs, under guidance from the TOC, provide high-quality technical expertise, unbiased information and proactive leadership within their category. The TOC makes use of this input to act as an informed and effective executive board to select and promote appropriate CNCF projects and practices, and to disseminate high quality information to end users and the cloud-native community in general. SIGs explicitly have no direct authority over CNCF projects. In particular, the creation of CNCF SIG’s does not change the existing, successfully practiced [charter](https://github.com/cncf/foundation/blob/master/charter.md) goal that "Projects.. will be ‘lightly’ subject to the Technical Oversight Committee".
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SIGs or SIG's?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


The SIGs should strive to present the TOC with easily understandable and votable "propositions", each of which is supported by clear written evidence. A proposition may be “to approve this project for incubation based on this [written ](https://github.com/cncf/toc/blob/master/process/due-diligence-guidelines.md)[due diligence](https://github.com/cncf/toc/blob/master/process/due-diligence-guidelines.md)[ investigation](https://github.com/cncf/toc/blob/master/process/due-diligence-guidelines.md)”, or “to approve this landscape document based on these clear goals and evidence that it achieves them”. It is of utmost importance that the information and proposals provided to the TOC by SIGs be highly accurate and unbiased, driven by the goal to improve the CNCF as a whole, rather than benefit one project or company over another. We believe that the rising tide lifts all boats, and that is our goal.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @ultrasaurus . I'll fold those in.


Key ideas here:

* The TOC is the arbiter & editor and may always intervene and overrule.

* The SIGs are the productive talent, and respected as such.

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.

### Specific SIG Responsibilities

#### Project Handling:

* Understand and document a high level roadmap of projects within this space, including CNCF and non-CNCF projects. Identify gaps in project landscape.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one still isn't fixed


* For projects that fall within the CNCF, perform health checks.

* Perform discovery of and outreach to candidate projects

* Help candidate projects prepare for presentation to the TOC

* Every CNCF project will be assigned to one suitable SIG by the TOC.

#### End User Education (Outbound Communication)

* Provide up-to-date, high quality, unbiased and easy-to-consume material to help end users to understand and effectively adopt cloud-native technologies and practises within the SIG’s area, for example:

* White papers, presentations, videos, or other forms of training clarifying terminology, comparisons of different approaches, available projects or products, common or recommended practises, trends, illustrative successes and failures, etc.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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."


* As far as possible, information should be based on research and fact gathering, rather than pure marketing or speculation.

#### End User Input Gathering (Inbound Communication)

* Gather useful end user input and feedback regarding expectations, pain points, primary use cases etc.

* Compile this into easily consumable reports and/or presentations to assist projects with feature design, prioritization, UX etc.

#### Community Enablement

* SIGs are open organizations with meetings, meeting agendas and notes, mailing lists, and other communications in the open

* The mailing list, SIG meeting calendar, and other communication documents of the SIG will be openly published and maintained

#### As Trusted Expert Advisors to the TOC

* Perform technical due diligence on new and graduating projects, and advise TOC on findings.

* Be involved with, or periodically check in with projects in their area, and advise TOC on health, status and proposed actions (if any) as necessary or on request.

#### SIG Charter:

* This is formally reviewed annually, and approved by the TOC. The charter must clearly articulate:

* what is in and out of scope of the SIG,

* whether and how it overlaps and interfaces with other CNCF SIG’s or other relevant groups, and

* how it operates and is governed, and specifically whether and how it deviates from standard SIG operating guidelines provided by the TOC. Deviation from these guidelines is discouraged, unless there are good and well-documented reasons for such divergence, approved by the TOC.

See [Example Responsibilities of a CNCF SIG](https://docs.google.com/document/d/1L9dJl5aBFnN5KEf82J689FY0UtnUawnt9ooCq8SkO_w/edit?usp=sharing).

## Operating Model

Important: Each SIG is supported by a named member of the CNCF executive staff who is accountable for liaison with the CNCF Executive Director, plus communication and performance of the SIG, with quarterly and annual reporting to Governing Board & TOC.

As a starting point let’s be inspired by CNCF OSS Projects and by K8S SIGs. That means minimal viable governance and community-based organisation.

### SIG Formation, Leadership and Membership Composition

1. SIGs are formed by the TOC. Initial SIGs are listed below, and will be adapted over time as required. If members of the community believe that additional SIGs are desired, they should propose these to the TOC, with clear justification, and ideally volunteers to lead the SIG. The TOC wishes to have the smallest viable number of SIGs, and for all of them to be highly effective (as opposed to a "SIG sprawl" with large numbers of relatively ineffective SIGS).

2. SIG has three co-chairs, who are TOC Contributors, recognized as experts in that area, and for their ability to co-lead the SIG to produce the required unbiased outputs.

3. SIG has one TOC liaison who is a voting member of the TOC acting as an additional non-executive chair on occasions when TOC input is deemed necessary by the TOC or the SIG chairs.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@quinton-hoole-2 great :)


4. SIG has multiple tech leads who are recognized as (1) experts in the SIG area, (2) leaders of projects in the SIG’s area (3) demonstrating the ability to provide the balanced technical leadership required to produce the required unbiased outputs of the SIG. The reason for having separate chair and tech lead roles is to allow responsibility for primarily administrative functions to be separated from deep technical functions and associated time commitments and skill sets. Where appropriate, an individual may perform both roles (see below).

5. Thought and interest diversity is strongly encouraged within SIGs. To this end, a supermajority (⅔ or more) of chairs or a supermajority of tech leads from a single group of companies, market segment, etc will be actively discouraged by the TOC.

6. SIG members are self-declared, so that some SIG work is done by volunteers from the TOC Contributors and community. To recognise members who make sustained and valuable contributions to a SIG over time, SIG-defined and assigned roles may be created (e.g. scribe, training or documentation coordinator etc). SIG’s should document what these roles and responsibilities are, and who performs them, and have them approved by SIG leads.

### SIG Member Roles

#### Chair

* Three chairs where the active chair rotates each week/fortnight/month.

* Primarily performs administrative functions including collecting and compiling topics for the (bi)weekly agenda, chairing the meeting, ensuring that quality meeting minutes are published, and follow-up actions tracked and resolved.

* A chair role may be held and performed by a tech lead, in cases where one person has the time and ability to perform both roles to the satisfaction of the TOC and SIG members.

#### Tech Lead

* Leads projects in the SIG’s area.

* Has the time and ability to perform deep technical dives on projects. Projects may include formal CNCF projects or other projects in the area covered by the SIG.

#### Other named roles

* Named and defined by the SIG (e.g. scribe, PR lead, docs/training lead, etc)

* Approved by supermajority of the chairs.

#### Other members

* Self-declared

* May either have no explicit roles or responsibilities, or formally assigned roles (see above).

* May not create the impression that they have any authority or formal responsibilities in the SIG other than assigned roles.

### Elections

* The TOC nominates Chairs

* Chairs are assigned following a 2/3 majority vote of the TOC

* Terms last for 2 years but staggered such that at least 1 of the chairs is able to maintain continuity

* The TOC and Chairs nominate Tech leads

* Tech leads are assigned following a 2/3 majority vote of the TOC and a 2/3 majority vote of SIG Chairs

* SIG Chairs and Tech Leads may be unassigned from the SIG at any time following a 2/3 majority vote of the TOC

### Governance

* All SIGs inherit and follow the CNCF TOC Operating Principles.

* SIGs must have a documented governance process that encourages community participation and clear guidelines to avoid biased decision-making.

* NOTE: aim here is to align with "minimal viable" model of the CNCF projects, and only have such governance as is needed, not anything too burdensome

* They may grow a set of practices over time in the same way as an OSS Project, provided this is consistent with CNCF Operating Principles.

* As with CNCF Projects all exceptions and disputes are handled by TOC with CNCF Staff help

### Budget & Resource

* No formal systematic budget at this time, other than commitment of CNCF executive staff to provide named person as liaison point.

* Just as CNCF Projects may have "help" offered by CNCF and may ask for things via the [ServiceDesk](https://github.com/cncf/servicedesk), the SIGs may do this.

## Retirement

* In the event that a SIG is unable to regularly establish quorum, or fulfill the responsibilities and/or regularly report to the TOC, the TOC will:
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


* Consider retiring the SIG after 3 months

* Must retire the SIG after 6 months

* The TOC may, by means of a 2/3 majority vote, declare "no confidence" in the SIG. In this event, the TOC may then vote to retire or reconstitute the SIG.

## Initial SIGS

To bootstrap the process, the TOC proposes the following SIGs, and projects assigned to each SIG. Clearly all of these SIG’s will not be fully-formed overnight or begin operating immediately, so the TOC itself will fulfill the duties of not-yet-formed SIG’s until they are. We can however, fairly immediately, assign one voting member of the TOC as liason for each SIG, and prioritize the order of formation of the SIGs, starting immediately with the most pressing ones.

<table>
<tr>
<td>Name (to be finalised)</td>
<td>Area</td>
<td>Current CNCF Projects</td>
</tr>
<tr>
<td>Traffic</td>
<td>networking, service discovery, load balancing, service mesh, RPC, pubsub, etc.</td>
<td>Envoy, Linkerd, NATS, gRPC, CoreDNS, CNI</td>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

</tr>
<tr>
<td>Observability</td>
<td>monitoring, logging, tracing, profiling, etc.
</td>
<td>Prometheus, OpenTracing, Fluentd, Jaeger, Cortex, OpenMetrics, </td>
</tr>
<tr>
<td>Governance</td>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor

@izgeri izgeri Feb 22, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<td>Governance</td>
<td>Security & Compliance</td>

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

<td>security, authentication, authorization, auditing, policy enforcement, compliance, GDPR, cost management, etc</td>
<td>SPIFFE, SPIRE, Open Policy Agent, Notary, TUF, Falco, </td>
</tr>
<tr>
<td>App Dev, Ops & Testing</td>
<td>PaaS, Serverless, Operators,... CI/CD, Conformance, Chaos Eng, Scalability and Reliability measurement etc.</td>
<td>Helm, CloudEvents, Telepresence, Buildpacks</td>
</tr>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on splitting the sigs later.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

<tr>
<td>Core and Applied Architectures</td>
<td>orchestration, scheduling, container runtimes, sandboxing technologies, packaging and distribution, specialized architectures thereof (e.g. Edge, IoT, Big Data, AI/ML, etc).</td>
<td>Kubernetes, containerd, rkt, Harbor, Dragonfly, Virtual Kubelet</td>
</tr>
<tr>
<td>Storage</td>
<td>Block, File and Object Stores, Databases, Key-Value stores etc.</td>
<td>TiKV, etcd, Vitess, Rook</td>
</tr>
</table>


The TOC and CNCF Staff will draft an initial set of charters for the above, and solicit/elect suitable chairs.

## Appendix A: Worked Example - CNCF Governance SIG

See [separate document](https://docs.google.com/document/d/18ufx6TjPavfZubwrpyMwz6KkU-YA_aHaHmBBQkplnr0/edit?usp=sharing).