Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CNCF SIGs Final Proposal #194

Merged
merged 5 commits into from Apr 1, 2019

Conversation

@quinton-hoole
Copy link
Contributor

commented Feb 6, 2019

This is simply the doc below, which has been under heavy public development and review since early Dec 2018, converted to markdown so that it can be voted upon and merged.

As discussed in the related email thread, and on the TOC call today, precise SIG names, scope definitions and charters will be finalized while bootstrapping each SIG - the names in this doc should not considered final.

https://docs.google.com/document/d/1mt1LH1QJgwA91A6x-DEdjg4ZOXrOnxxc1d2xhq4Hq3I/edit#heading=h.cswy6dl41jv

quinton-hoole added some commits Feb 5, 2019


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 and recognised as unbiased experts in that area.

This comment has been minimized.

Copy link
@yurishkuro

yurishkuro Feb 6, 2019

Contributor

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.

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 8, 2019

Author Contributor

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.

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 19, 2019

Author Contributor

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

</tr>
<tr>
<td>Storage</td>
<td>Block and File Stores, Databases, Key-Value stores etc.</td>

This comment has been minimized.

Copy link
@NicolasT

NicolasT Feb 7, 2019

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

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 8, 2019

Author Contributor

Absolutely! Good catch. Done.


* 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).

This comment has been minimized.

Copy link
@NicolasT

NicolasT Feb 8, 2019

(minor) Kubernetes SIGs.

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 19, 2019

Author Contributor

Done.


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

This comment has been minimized.

Copy link
@NicolasT

NicolasT Feb 8, 2019

SIGs or SIG's?

This comment has been minimized.

Copy link
@cathyhongzhang

cathyhongzhang Feb 13, 2019

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?

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 19, 2019

Author Contributor

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

<td>Prometheus, OpenTracing, Fluentd, Jaeger, Cortex, OpenMetrics, </td>
</tr>
<tr>
<td>Governance</td>

This comment has been minimized.

Copy link
@izgeri

izgeri Feb 8, 2019

Contributor

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

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 19, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@izgeri

izgeri Feb 22, 2019

Contributor

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

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 22, 2019

Author Contributor

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


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

This comment has been minimized.

Copy link
@duglin

duglin Feb 9, 2019

Contributor

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

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 19, 2019

Author Contributor

Done. Added 3 missing periods.


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.

This comment has been minimized.

Copy link
@duglin

duglin Feb 9, 2019

Contributor

remove period

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 19, 2019

Author Contributor

done


Key ideas here:

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

This comment has been minimized.

Copy link
@duglin

duglin Feb 9, 2019

Contributor

Period consistency

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 19, 2019

Author Contributor

Done.


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

This comment has been minimized.

Copy link
@duglin

duglin Feb 9, 2019

Contributor

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 comment has been minimized.

Copy link
@duglin

duglin Mar 19, 2019

Contributor

This one still isn't fixed


#### SIG Charter:

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

This comment has been minimized.

Copy link
@duglin

duglin Feb 9, 2019

Contributor

Cap first letters and check periods

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 19, 2019

Author Contributor

Done.


*Important*

*Each SIG is supported by a named member of the CNCF executive staff who is accountable for liaison with the CNCF Exec, plus communication and performance of the SIG, with quarterly and annual reporting to GB & TOC. *** **

This comment has been minimized.

Copy link
@duglin

duglin Feb 9, 2019

Contributor

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

This comment has been minimized.

Copy link
@duglin

duglin Feb 9, 2019

Contributor

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

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 19, 2019

Author Contributor

Yes, done.


2. SIG has three co-chairs, who are TOC Contributors and recognised as unbiased experts in that area.

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

This comment has been minimized.

Copy link
@duglin

duglin Feb 9, 2019

Contributor

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.

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 19, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@duglin

duglin Feb 19, 2019

Contributor

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.

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 19, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 19, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@duglin

duglin Feb 19, 2019

Contributor

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


4. SIG has multiple tech leads who are recognised as unbiased experts in the SIG area, and are recognised leaders of projects in the SIG’s area. 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 tech leads from a single group of companies, market segment, etc will be actively discouraged by the TOC.

This comment has been minimized.

Copy link
@duglin

duglin Feb 9, 2019

Contributor

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.

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 19, 2019

Author Contributor

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


* The TOC and Chairs nominate Tech leads

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

This comment has been minimized.

Copy link
@duglin

duglin Feb 9, 2019

Contributor

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

This comment has been minimized.

Copy link
@duglin

duglin Feb 9, 2019

Contributor

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.

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 19, 2019

Author Contributor

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.


## 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:

This comment has been minimized.

Copy link
@duglin

duglin Feb 9, 2019

Contributor

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.

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 19, 2019

Author Contributor

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

@JustinCappos

This comment has been minimized.

Copy link
Contributor

commented Feb 9, 2019


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

This comment has been minimized.

Copy link
@cathyhongzhang

cathyhongzhang Feb 13, 2019

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

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 19, 2019

Author Contributor

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

<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, (CNCF CI)</td>
</tr>

This comment has been minimized.

Copy link
@cathyhongzhang

cathyhongzhang Feb 14, 2019

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.

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 19, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@cathyhongzhang

cathyhongzhang Feb 26, 2019

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.

This comment has been minimized.

Copy link
@xiang90

xiang90 Mar 5, 2019

Contributor

+1 on splitting the sigs later.

This comment has been minimized.

Copy link
@ant31

ant31 Mar 20, 2019

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

@ultrasaurus
Copy link
Contributor

left a comment

submitted PR with formatting - quinton-hoole-2#1 to make it so the bulleted lists wrap (and remove extraneous duplicate links)

also, for readability of files as text (if you don't mind extended markdown): quinton-hoole#2 -- converts table at end to markdown


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

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.

This comment has been minimized.

Copy link
@ultrasaurus

ultrasaurus Feb 19, 2019

Contributor

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

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 19, 2019

Author Contributor

Thanks @ultrasaurus . I'll fold those in.


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.

This comment has been minimized.

Copy link
@duglin

duglin Feb 19, 2019

Contributor

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

This comment has been minimized.

Copy link
@duglin

duglin Feb 19, 2019

Contributor

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

This comment has been minimized.

Copy link
@hannibalhuang

hannibalhuang Feb 22, 2019

Contributor

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

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 22, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@hannibalhuang

hannibalhuang Mar 2, 2019

Contributor

@quinton-hoole-2 great :)

<td>Prometheus, OpenTracing, Fluentd, Jaeger, Cortex, OpenMetrics, </td>
</tr>
<tr>
<td>Governance</td>

This comment has been minimized.

Copy link
@izgeri

izgeri Feb 22, 2019

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

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Feb 22, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@izgeri

izgeri Feb 25, 2019

Contributor

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

This comment has been minimized.

Copy link
@lizrice

lizrice Feb 26, 2019

Contributor

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.

This comment has been minimized.

Copy link
@ultrasaurus

ultrasaurus Mar 1, 2019

Contributor

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.

This comment has been minimized.

Copy link
@quinton-hoole

quinton-hoole Mar 5, 2019

Author Contributor

ok

@caniszczyk caniszczyk added this to In progress (due diligence) in TOC Project Backlog Mar 4, 2019

@caniszczyk caniszczyk moved this from In progress (due diligence) to TOC Approved (sponsors/voting) in TOC Project Backlog Mar 19, 2019

<tr>
<td>Traffic</td>
<td>networking, service discovery, load balancing, service mesh, RPC, pubsub, etc.</td>
<td>Envoy, Linkerd, NATS, gRPC, CoreDNS, CNI</td>

This comment has been minimized.

Copy link
@bboreham

bboreham Mar 26, 2019

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

@caniszczyk

This comment has been minimized.

Copy link
Contributor

commented Apr 1, 2019

This has been approved finally.

+1 binding TOC votes (9/9):
Alexis: https://lists.cncf.io/g/cncf-toc/message/3004
Jeff: https://lists.cncf.io/g/cncf-toc/message/3006
Liz: https://lists.cncf.io/g/cncf-toc/message/3007
Joe: https://lists.cncf.io/g/cncf-toc/message/3022
Michelle: https://lists.cncf.io/g/cncf-toc/message/3027
Matt: https://lists.cncf.io/g/cncf-toc/message/3031
Brian: https://lists.cncf.io/g/cncf-toc/message/3033
Brendan: https://lists.cncf.io/g/cncf-toc/message/3034
Xiang: https://lists.cncf.io/g/cncf-toc/message/3068

Here are the initial SIGs planned with TOC liaisons:

  • Matt: Traffic (networking, service discovery, load balancing, service mesh, RPC, pubsub, etc)
  • Jeff: Observability (monitoring, logging, tracing, profiling, etc)
  • Liz + Joe: Security/Governance (auth, authorization, auditing, policy enforcement, compliance, GDPR, cost management, etc)
  • Michelle + Alexis: App Dev, Ops & Testing (PaaS, Serverless, Operators, CI/CD, Conformance, Chaos Eng, Scalability and Reliability measurement etc.)
  • Brendan + Brian: Core and Applied Architectures (orchestration, scheduling, container runtimes, sandboxing technologies, packaging and distribution, specialized architectures thereof (e.g. Edge, IoT, Big Data, AI/ML, etc).
  • Xiang: Storage (Block and File Stores, Databases, Key-Value stores etc)

We will focus on getting the Security/Governance SIG off the ground first to pilot things and then follow with the other SIGs.

@caniszczyk caniszczyk merged commit f8e2a12 into cncf:master Apr 1, 2019

@caniszczyk caniszczyk moved this from TOC Approved (sponsors/voting) to Done in TOC Project Backlog Apr 2, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.