cncf
/
toc
mirror of https://github.com/cncf/toc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

SIGs to TAGs (#654) 

* SIGs to TAGs

SIGs have changed names to TAGs as of 5/5/2021

Co-authored-by: Đặng Minh Dũng <dungdm93@live.com>
This commit is contained in:
Amye Scavarda Perrin 2021-05-06 07:30:27 -07:00 committed by GitHub
parent b399749f4f
commit 57d9b177f4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
18 changed files with 243 additions and 243 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
CONTRIBUTING.md
View File

@ -8,14 +8,14 @@ The full project proposal process is located [here](https://github.com/cncf/toc/
## TOC Contributors
There has been a call from CNCF’s Technical Oversight Committee (TOC) for additional contributors and expertise to help evaluate potential projects and contribute to [CNCF SIGs](https://github.com/cncf/toc/blob/main/sigs/cncf-sigs.md) and [working groups](https://github.com/cncf/toc#working-groups). With the metaphor of the TOC as an open source project and the TOC [members](https://github.com/cncf/toc#members) as the maintainers, we are making a call for new **TOC Contributors**.
There has been a call from CNCF’s Technical Oversight Committee (TOC) for additional contributors and expertise to help evaluate potential projects and contribute to [CNCF TAGs](https://github.com/cncf/toc/blob/main/tags/cncf-tags.md) and [working groups](https://github.com/cncf/toc#working-groups). With the metaphor of the TOC as an open source project and the TOC [members](https://github.com/cncf/toc#members) as the maintainers, we are making a call for new **TOC Contributors**.
Possible ways to contribute:
* Tech due diligence for projects
* Time spent helping projects
* Liaison with GB
* CNCF SIGs & working groups (various tasks)
* CNCF TAGs & working groups (various tasks)
* Technical content for website
If you are interested in engaging in this way, we would encourage you to issue a pull request to [TOC Contributors](https://github.com/cncf/toc/blob/main/CONTRIBUTORS.md) that you desire to become a TOC Contributor. Although there is not an actual limit of having one Contributor per company, we would encourage CNCF member companies to designate an official TOC Contributor who is tasked with consulting internal experts and expressing a semi-official view on a given project. We will list current TOC Contributors on a page similar to https://www.cncf.io/people/ambassadors/.

10
FAQ.md
View File

@ -10,14 +10,14 @@ https://github.com/cncf/toc/blob/main/process/election-schedule.md
The best way to get involved is to start attending TOC meetings and become an official TOC Contributor:
https://github.com/cncf/toc/blob/main/CONTRIBUTORS.md
If you have specific focus areas, CNCF SIG meetings are good opportunity to dive in:
https://github.com/cncf/toc/tree/main/sigs
If you have specific focus areas, CNCF TAG meetings are good opportunity to dive in:
https://github.com/cncf/toc/tree/main/tags
## What are CNCF SIGs?
## What are CNCF TAGs?
The CNCF Special Interest Groups (SIGs) scale contributions by the CNCF technical and user community, while retaining integrity and increasing quality in support of our mission.
The CNCF Technical Advisory Groups (TAGs) scale contributions by the CNCF technical and user community, while retaining integrity and increasing quality in support of our mission.
https://github.com/cncf/toc/tree/main/sigs
https://github.com/cncf/toc/tree/main/tags
## What type of governance is my CNCF project expected to follow?

18
README.md
View File

@ -75,18 +75,18 @@ To join: https://lists.cncf.io/mailman/listinfo/cncf-toc
This is our [voting policy](docs/voting.md).
## SIGs
## Technical Advisory Groups
The TOC has approved the formation of [SIGs](sigs/cncf-sigs.md).
The TOC has approved the formation of [TAGs](tags/cncf-tags.md).
Currently, the following Special Interest Groups are active:
* [SIG-Security](https://github.com/cncf/sig-security)
* [SIG-Storage](https://github.com/cncf/sig-storage)
* [SIG-App-Delivery](https://github.com/cncf/sig-app-delivery)
* [SIG-Network](https://github.com/cncf/sig-network)
* [SIG-Runtime](https://github.com/cncf/sig-runtime)
* [SIG Contributor Strategy](https://github.com/cncf/sig-contributor-strategy)
* [SIG Observability](https://github.com/cncf/sig-observability)
* [TAG-Security](https://github.com/cncf/tag-security)
* [TAG-Storage](https://github.com/cncf/tag-storage)
* [TAG-App-Delivery](https://github.com/cncf/tag-app-delivery)
* [TAG-Network](https://github.com/cncf/tag-network)
* [TAG-Runtime](https://github.com/cncf/tag-runtime)
* [TAG Contributor Strategy](https://github.com/cncf/tag-contributor-strategy)
* [TAG Observability](https://github.com/cncf/tag-observability)
## Working Groups

2
process/due-diligence-guidelines.md
View File

@ -125,7 +125,7 @@ Some details that might inform the above include:
* Is it easy to contribute to the project as an external contributor? If not, what are the main obstacles?
* Are there any especially difficult personalities to deal with? How is this done? Is it a problem?
* Getting interviews with 2-3 external contributors is advisable for DD process, both from the community and technical perspective. It can help to identify technical depth in areas like extensibility, API design and general code architecture.
* For more in-depth review of the contributor experience, consulting with [sig-contributor-strategy](https://github.com/cncf/sig-contributor-strategy) is always a good idea.
* For more in-depth review of the contributor experience, consulting with [tag-contributor-strategy](https://github.com/cncf/tag-contributor-strategy) is always a good idea.
#### Context

2
process/graduation-proposal-template.md
View File

@ -20,4 +20,4 @@ _**Project should address each area listed below**_
### * Link to Incubation Due Diligence(DD) Document
### * Address any concerns or recommendations from the SIG and/or TOC sponsor(s) from the DD Document
### * Address any concerns or recommendations from the TAG and/or TOC sponsor(s) from the DD Document

18
process/project_proposals.adoc
View File

@ -43,17 +43,17 @@ image::incubation-process.png[Incubation process]
* A potential sponsor can indicate that they are interested but don't have capacity to work on DD at this time, to set a project's expectations.
* The TOC may agree that the project does not (yet) meet the https://github.com/cncf/toc/blob/main/process/graduation_criteria.adoc#incubation-stage[Incubation requirements] and give feedback on why this is the case. If the project is not already in the CNCF, the TOC may suggest that project apply for Sandbox instead.
* If a TOC Incubation Sponsor has not stepped forward within two months after the proposal PR is submitted, projects may request that their project proposal is discussed at a forthcoming TOC meeting by adding it to the https://docs.google.com/document/d/1jpoKT12jf2jTf-2EJSAl4iTdA7Aoj_uiI19qIaECNFc/edit[Working Doc]. The outcome of this is discussion is either that a sponsor steps forward, or that the TOC votes to admit the project to Sandbox, or the proposal is rejected (projects may reapply after six months). If, even after all those steps, a sponsor does not step forward, the proposal is rejected.
* DD will usually involve a presentation to a SIG, but an interested SIG is welcome to schedule a project presentation at any time. SIGs can discuss their recommendations or concerns about a project with their TOC liaison(s) if there isn't already a TOC Incubation Sponsor in place.
* DD will usually involve a presentation to a TAG, but an interested TAG is welcome to schedule a project presentation at any time. TAGs can discuss their recommendations or concerns about a project with their TOC liaison(s) if there isn't already a TOC Incubation Sponsor in place.
* Although it is not necessary, projects are allowed to informally reach out to TOC members for advice, including asking about potential sponsorship. TOC members should keep each other informed about these approaches so that we can avoid falling prey to "lobbying". There is a fine line between a project asking for help to make a successful application, and a project shopping around looking to pressurize a TOC member into sponsorship.
. *TOC Incubation Sponsor*
* TOC Incubation Sponsor is responsible for driving the process, and co-ordinating with SIGs for review and input as they see fit.
* TOC Incubation Sponsor is responsible for driving the process, and co-ordinating with TAGs for review and input as they see fit.
* TOC Incubation Sponsor is a point of contact for the project throughout the process.
* TOC members may not sponsor a project for which they have a clear conflict of interest (for example, originating primarily from their organization). This doesn't mean that they can't have any involvement at all - for example, contributing pull requests, or being an end user of that project, can signal a healthy interest in and knowledge of a worthwhile project.
. *Due Diligence* _2-3 months_
* TOC Incubation Sponsor drives due diligence (see the https://github.com/cncf/toc/blob/main/process/dd-review-template.md[template] and https://github.com/cncf/toc/blob/main/process/due-diligence-guidelines.md[guidelines]).
* TOC Incubation Sponsor can delegate DD work to CNCF SIGs and/or other TOC members.
* Typically DD includes a presentation to a CNCF SIG, as identified by the TOC Sponsor. This step may be omitted if the TOC Sponsor feels there are readily-available and suitable presentations on video - for example, because the SIG has already recently held a presentation. (We do not want unnecessary levels of process or bureaucracy to delay a widely-known and adopted project from joining the CNCF). TOC Sponsor has discretion to arrange alternatives (for example, arranging a Q&A session at a TOC meeting) to ensure there is ample opportunity to ask questions.
* TOC Incubation Sponsor can ask project maintainers to complete the DD template. (In practice project maintainers sometimes choose to make a start on this in advance of the official DD process, or even in advance of the initial proposal as it may help them ensure they meet all the requirements.) The TOC Incubation Sponsor should carefully review and ask questions about the DD as prepared by the project maintainers, and may also call on SIGs to help with this.
* TOC Incubation Sponsor can delegate DD work to CNCF TAGs and/or other TOC members.
* Typically DD includes a presentation to a CNCF TAG, as identified by the TOC Sponsor. This step may be omitted if the TOC Sponsor feels there are readily-available and suitable presentations on video - for example, because the TAG has already recently held a presentation. (We do not want unnecessary levels of process or bureaucracy to delay a widely-known and adopted project from joining the CNCF). TOC Sponsor has discretion to arrange alternatives (for example, arranging a Q&A session at a TOC meeting) to ensure there is ample opportunity to ask questions.
* TOC Incubation Sponsor can ask project maintainers to complete the DD template. (In practice project maintainers sometimes choose to make a start on this in advance of the official DD process, or even in advance of the initial proposal as it may help them ensure they meet all the requirements.) The TOC Incubation Sponsor should carefully review and ask questions about the DD as prepared by the project maintainers, and may also call on TAGs to help with this.
* CNCF staff do governance and legal DD.
* During DD some conversations may be held in private (e.g. user interviews where the user wishes to remain anonymous) and are documented using discretion.
* TOC Incubation Sponsor confirms that project meets the https://github.com/cncf/toc/blob/main/process/graduation_criteria.adoc#incubation-stage[Incubation requirements].
@ -74,7 +74,7 @@ image::incubation-process.png[Incubation process]
* The proposal addresses how the project has grown since incubation and any concerns from incubation DD in addition to the standard graduation requirements.
. *TOC member kicks off two week period of time for public comment on the TOC mailing list*
* The email should contain a link to the proposal pull request and incubation DD document.
* All SIGs, end users, TOC members, and community members are welcome to comment at this time on the mailing list.
* All TAGs, end users, TOC members, and community members are welcome to comment at this time on the mailing list.
* Historically, projects have done a TOC presentation as part of the graduation process. The TOC has gotten rid of the presentation requirement. Instead, if the TOC wants to have a deeper discussion about the project with the maintainers, they may schedule an ad hoc meeting to do so before the vote.
. *TOC vote*
* TOC members assess whether project meets the https://github.com/cncf/toc/blob/main/process/graduation_criteria.adoc#graduation-stage[Graduation criteria]
@ -83,10 +83,10 @@ image::incubation-process.png[Incubation process]
=== Notes
* TOC always has final discretion
* TOC doesn’t have to accept SIG recommendation
* TOC doesn’t have to accept TAG recommendation
* Outcome may be “no” simply because sponsors don’t step forward within the timeframe
* Outcome from TOC Triage or SIG recommendation could be that we want to wait for some reason e.g. project backlogs; batching similar projects together. We should give the project an explanation and set time expectations in these cases.
* All “no” outcomes and other exceptions are discussed by the TOC, and then with project and SIG representatives. We will try to give feedback but it may simply be a lack of conviction in the project.
* Outcome from TOC Triage or TAG recommendation could be that we want to wait for some reason e.g. project backlogs; batching similar projects together. We should give the project an explanation and set time expectations in these cases.
* All “no” outcomes and other exceptions are discussed by the TOC, and then with project and TAG representatives. We will try to give feedback but it may simply be a lack of conviction in the project.
=== Project Proposal Requirements

2
process/sandbox-annual-review.md
View File

@ -2,7 +2,7 @@
Sandbox projects are subject to an annual review by the TOC. This is intended to be a lightweight process to ensure that projects are on track, and getting the support they need.
To keep it lightweight, it is a single phase process - the review doesn't first pass through SIGs and then the TOC. The review document is shared with the community and SIG members can comment on each review, as can any other TOC contributor. The intention is to quickly reach a position where TOC members agree to continue sponsorship.
To keep it lightweight, it is a single phase process - the review doesn't first pass through TAGs and then the TOC. The review document is shared with the community and TAG members can comment on each review, as can any other TOC contributor. The intention is to quickly reach a position where TOC members agree to continue sponsorship.
## How to file your annual review

48
sigs/README.md → tags/README.md
View File

@ -1,65 +1,65 @@
# CNCF Special Interest Groups ("SIGs")
# CNCF Technical Advisory Groups ("TAGs")
The CNCF TOC Special Interest Groups scale contributions by the CNCF
The CNCF TOC Technical Advisory Groups 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).
TOC and TOC Contributors have fulfilled SIG duties in the past and will continue to do so until a specific SIG takes on that responsibility.
TOC and TOC Contributors have fulfilled TAG duties in the past and will continue to do so until a specific TAG takes on that responsibility.
## SIG Formation Process
## TAG Formation Process
TOC will identify at least one voting member as TOC Liason for each [proposed SIG](proposed.md). The SIG TOC Liason will work with TOC contributors identify prospective chairs and draft the initial charter (see [worked example](https://docs.google.com/document/d/18ufx6TjPavfZubwrpyMwz6KkU-YA_aHaHmBBQkplnr0/edit?usp=sharing), then submit
a pull request with document referencing the roles and charter, updating the list of current SIGs below.
TOC will identify at least one voting member as TOC Liason for each [proposed TAG](proposed.md). The TAG TOC Liason will work with TOC contributors identify prospective chairs and draft the initial charter (see [worked example](https://docs.google.com/document/d/18ufx6TjPavfZubwrpyMwz6KkU-YA_aHaHmBBQkplnr0/edit?usp=sharing), then submit
a pull request with document referencing the roles and charter, updating the list of current TAGs below.
## Current SIGS
## Current TAGS
| Name | TOC Liaisons |
|------|--------------|
| [SIG Security](https://github.com/cncf/sig-security) | Liz Rice, Justin Cormack |
| [SIG Storage](https://github.com/cncf/sig-storage) | Erin Boyd, Saad Ali |
| [SIG App Delivery](https://github.com/cncf/sig-app-delivery) | Davanum Srinivas, Lei Zhang, Cornelia Davis |
| [SIG Network](https://github.com/cncf/sig-network) | Dave Zolotusky, Liz Rice |
| [SIG Runtime](https://github.com/cncf/sig-runtime) | Richardo Rocha, Alena Prokharchyk, Davanum Srinivas |
| [SIG Contributor Strategy](https://github.com/cncf/sig-contributor-strategy) | Saad Ali, Alena Prokharchyk |
| [SIG Observability](https://github.com/cncf/sig-observability) | Lei Zhang, Cornelia Davis |
| [TAG Security](https://github.com/cncf/tag-security) | Liz Rice, Justin Cormack |
| [TAG Storage](https://github.com/cncf/tag-storage) | Erin Boyd, Saad Ali |
| [TAG App Delivery](https://github.com/cncf/tag-app-delivery) | Davanum Srinivas, Lei Zhang, Cornelia Davis |
| [TAG Network](https://github.com/cncf/tag-network) | Dave Zolotusky, Liz Rice |
| [TAG Runtime](https://github.com/cncf/tag-runtime) | Richardo Rocha, Alena Prokharchyk, Davanum Srinivas |
| [TAG Contributor Strategy](https://github.com/cncf/tag-contributor-strategy) | Saad Ali, Alena Prokharchyk |
| [TAG Observability](https://github.com/cncf/tag-observability) | Lei Zhang, Cornelia Davis |
## SIG Chairs as of July 2020
## TAG Chairs as of July 2020
### SIG Storage
### TAG Storage
* [Erin Boyd](https://github.com/erinboyd)
* [Quinton Hoole](https://github.com/quinton-hoole)
* [Alex Chircop](https://github.com/chira001)
### SIG Security
### TAG Security
* [Sarah Allen](https://github.com/ultrasaurus)
* [Jeyappragash Jeyakeerthi](https://github.com/pragashj)
* [Dan Shaw](https://github.com/dshaw)
### SIG App-Delivery
### TAG App-Delivery
* [Bryan Liles](https://github.com/bryanl)
* [Lei Zhang](https://github.com/resouer)
* [Alois Reitbauer](https://github.com/AloisReitbauer)
### SIG Network
### TAG Network
* [Lee Calcote](https://github.com/leecalcote)
* [Ken Owens](https://github.com/kenowens12)
### SIG Runtime
### TAG Runtime
* [Diane Feddema](https://github.com/dfeddema)
* [Quinton Hoole](https://github.com/quinton-hoole)
* [Ricardo Aravena](https://github.com/raravena80)
### SIG Contributor Strategy
### TAG Contributor Strategy
* [Paris Pittman](https://github.com/parispittman)
* [Josh Berkus](https://github.com/jberkus)
* [Stephen Augustus](https://github.com/justaugustus)
### SIG Observability
### TAG Observability
* [Matt Young](https://github.com/halcyondude)
* [Richard Hartmann](https://github.com/RichiH)
## Emeritus Chairs
| SIG | Emeritus Chair |
| TAG | Emeritus Chair |
|---|---|
| SIG Contributor Strategy | [Gerred Dillon](https://github.com/gerred) |
| TAG Contributor Strategy | [Gerred Dillon](https://github.com/gerred) |

30
sigs/app-delivery.md → tags/app-delivery.md
View File

@ -27,11 +27,11 @@ Reviewed and contributed to by:
## **Introduction**
The charter describes the operations of the CNCF SIG Application Delivery. The Application Delivery SIG focuses on delivering cloud native applications which involves multiple phases including building, deploying, managing, and operating. Additionally, the SIG produces supporting material and best practices for end-users, and provide guidance and coordination for CNCF projects working within the SIG’s scope.
The charter describes the operations of the CNCF TAG Application Delivery. The Application Delivery TAG focuses on delivering cloud native applications which involves multiple phases including building, deploying, managing, and operating. Additionally, the TAG produces supporting material and best practices for end-users, and provide guidance and coordination for CNCF projects working within the TAG’s scope.
## **Mission**
Consistent with the [CNCF SIG definition](https://github.com/cncf/toc/blob/main/sigs/cncf-sigs.md), the mission of CNCF SIG App Delivery is:
Consistent with the [CNCF TAG definition](https://github.com/cncf/toc/blob/main/tags/cncf-tags.md), the mission of CNCF TAG App Delivery is:
* To collaborate on areas related to developing, distributing, deploying, managing and operating secure cloud-native applications with the target of delivering application in manner of cloud native.
* To develop informational resources including guides, tutorials and white papers to give the community an understanding of best practices, trade-offs, and value-adds regarding to application delivery.
@ -39,7 +39,7 @@ Consistent with the [CNCF SIG definition](https://github.com/cncf/toc/blob/main/
## **Areas considered in Scope**
SIG Application Delivery focuses on the following topics of the lifecycle of cloud-native applications:
TAG Application Delivery focuses on the following topics of the lifecycle of cloud-native applications:
* Application definition, including description, parameter and configuration
* Guidance and practice for application design and development
@ -49,9 +49,9 @@ SIG Application Delivery focuses on the following topics of the lifecycle of clo
* Configuration source driven workflow
* Release management
The SIG will work on developing best practices, fostering collaboration between related projects, working on improving tool interoperability as well as proposing new initiatives and projects when blank spots in the current landscape are identified.
The TAG will work on developing best practices, fostering collaboration between related projects, working on improving tool interoperability as well as proposing new initiatives and projects when blank spots in the current landscape are identified.
For CNCF projects, the scope of application delivery SIG engages, amongst others, with the application management focused ones, for example:
For CNCF projects, the scope of application delivery TAG engages, amongst others, with the application management focused ones, for example:
* Brigade
* Buildpacks
@ -60,7 +60,7 @@ For CNCF projects, the scope of application delivery SIG engages, amongst others
* Helm
* Kubernetes
The following, non exhaustive, sample list of activities and deliverables are in-scope for the SIG:
The following, non exhaustive, sample list of activities and deliverables are in-scope for the TAG:
* Education material to help provide guidance for the community
* Summary and overview of projects available in the community
@ -85,7 +85,7 @@ The following, non exhaustive, sample list of activities and deliverables are in
* Debugging and monitoring
* Hosting environments and interoperability (e.g. PaaS, FaaS, CaaS,...)
* CI/CD
* Serverless - Serverless applications are a core part of cloud-native application development and the Serverless WG will migrate to live under this SIG.
* Serverless - Serverless applications are a core part of cloud-native application development and the Serverless WG will migrate to live under this TAG.
## **Areas considered out of Scope**
@ -103,7 +103,7 @@ Anything not explicitly considered in the scope above. Example include:
* **Clarify the terminology** currently in use in the cloud native application space, and the relationships between the various terms.
* Figure out patterns and practices of application definition, distribution, and delivery in the manner of "cloud native" in current community, it may include areas like application development, but it mainly focuses around how to deliver application to cloud.
* Provide some general examples of **how these patterns and practices are currently being used in production** in public or private or hybrid cloud environments.
* Creating an application delivery landscape based on the outputs from the white paper. The SIG will help to reduce confusion and educate users by identifying finer-grained problems and implementation choices. Eg "project X focuses on application level rollout strategy", “project Y focuses on GitOps”.
* Creating an application delivery landscape based on the outputs from the white paper. The TAG will help to reduce confusion and educate users by identifying finer-grained problems and implementation choices. Eg "project X focuses on application level rollout strategy", “project Y focuses on GitOps”.
* Define and standardize generic rollout models covering typical app delivery patterns with concrete use cases and practices.
* The models include but are not limited to Blue-Green Deployment, A/B Testing, Canary Deployment and Analysis, Progressive Traffic Shifting and GitOps.
* The models are not expected to be bound to any specific runtime or execution engine. If one has to, it may not be a good candidate for this part.
@ -112,19 +112,19 @@ Anything not explicitly considered in the scope above. Example include:
### Cross-group relationships
Lifecycle management of applications is a broad and mainstream topic of Cloud Native computing; therefore this SIG may collaborate with most of the other CNCF SIGs and projects. However, the following groups might have the largest potential interactions:
Lifecycle management of applications is a broad and mainstream topic of Cloud Native computing; therefore this TAG may collaborate with most of the other CNCF TAGs and projects. However, the following groups might have the largest potential interactions:
* **SIG Security** - The publication of guidance or tutorials by the SIG could see the adoption of insecure practices if security isn’t considered as a prerequisite for publication. Collaborating with SIG Security on reviews should help to ensure guidance doesn’t lead to propagating insecure patterns of usage.
* **Kubernetes SIG Apps** - Many projects currently under Kubernetes SIG Apps may overlap with CNCF SIG App Delivery. The application delivery SIG will focus on end-to-end aspects of these projects, including non-Kubernetes platforms and projects where applicable; while Kubernetes SIG Apps will focus on Kubernetes-specific runtime-level concerns. Close collaboration is expected to happen within these two SIGs around different phases for application delivery.
* **TAG Security** - The publication of guidance or tutorials by the TAG could see the adoption of insecure practices if security isn’t considered as a prerequisite for publication. Collaborating with TAG Security on reviews should help to ensure guidance doesn’t lead to propagating insecure patterns of usage.
* **Kubernetes SIG Apps** - Many projects currently under Kubernetes SIG Apps may overlap with CNCF TAG App Delivery. The application delivery TAG will focus on end-to-end aspects of these projects, including non-Kubernetes platforms and projects where applicable; while Kubernetes SIG Apps will focus on Kubernetes-specific runtime-level concerns. Close collaboration is expected to happen within these two groups around different phases for application delivery.
## **Operations**
* TOC Liaisons: Davanum Srinivas, Lei Zhang, Cornelia Davis
* SIG chairs: [Alois Reitbauer](https://github.com/AloisReitbauer), [Bryan Liles]((https://github.com/bryanl)), [Lei Zhang (Harry)](https://github.com/resouer)
* See [roles](https://github.com/cncf/sig-security/blob/main/governance/roles.md#role-of-chairs) for more information
* Slack channel: #sig-app-delivery in CNCF workspace - [https://cloud-native.slack.com/messages/CL3SL0CP5](https://cloud-native.slack.com/messages/CL3SL0CP5)
* See [roles](https://github.com/cncf/tag-security/blob/main/governance/roles.md#role-of-chairs) for more information
* Slack channel: #tag-app-delivery in CNCF workspace - [https://cloud-native.slack.com/messages/CL3SL0CP5](https://cloud-native.slack.com/messages/CL3SL0CP5)
## **Contact**
* [Slack Channel (#sig-app-delivery)](https://cloud-native.slack.com/messages/CL3SL0CP5 )
* Join SIG-App-Delivery at [lists.cncf.io](http://lists.cncf.io)
* [Slack Channel (#tag-app-delivery)](https://cloud-native.slack.com/messages/CL3SL0CP5 )
* Join TAG-App-Delivery at [lists.cncf.io](http://lists.cncf.io)

94
sigs/cncf-sigs.md → tags/cncf-sigs.md
View File

@ -1,5 +1,5 @@
# CNCF Special Interest Groups ("SIGs")
# CNCF Technical Advisory Groups ("TAGs")
Primary Authors: Alexis Richardson, Quinton Hoole
@ -21,31 +21,31 @@ Scale contributions by the CNCF technical and user community, while retaining in
* 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.
* Provide a ladder for community members to get involved with the technical oversight of CNCF projects. As part of this, SIGs are expected to actively nurture diverse participation.
* Provide a ladder for community members to get involved with the technical oversight of CNCF projects. As part of this, TAGs are expected to actively nurture diverse participation.
## 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:
A CNCF TAG 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 TAG 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). TAG’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).
CNCF TAGs 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
## Responsibilities & Empowerment of TAGs
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/main/charter.md) goal that "Projects.. will be ‘lightly’ subject to the Technical Oversight Committee".
It is the desire of the TOC that the CNCF TAGs, 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. TAGs explicitly have no direct authority over CNCF projects. In particular, the creation of CNCF TAG’s does not change the existing, successfully practiced [charter](https://github.com/cncf/foundation/blob/main/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/main/process/due-diligence-guidelines.md)[due diligence](https://github.com/cncf/toc/blob/main/process/due-diligence-guidelines.md)[ investigation](https://github.com/cncf/toc/blob/main/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.
The TAGs 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/main/process/due-diligence-guidelines.md)[due diligence](https://github.com/cncf/toc/blob/main/process/due-diligence-guidelines.md)[ investigation](https://github.com/cncf/toc/blob/main/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 TAGs 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.
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.
* The TAGs 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.
TAGs may choose to spawn focused 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
### Specific TAG Responsibilities
#### Project Handling:
@ -53,11 +53,11 @@ SIGs may choose to spawn focussed and time-limited working groups to achieve som
* 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.
* Every CNCF project will be assigned to one suitable TAG 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:
* 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 TAG’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.
* As far as possible, information should be based on research and fact gathering, rather than pure marketing or speculation.
@ -68,70 +68,70 @@ SIGs may choose to spawn focussed and time-limited working groups to achieve som
#### 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
* TAGs are open organizations with meetings, meeting agendas and notes, mailing lists, and other communications in the open
* The mailing list, TAG meeting calendar, and other communication documents of the TAG 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:
#### TAG 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.
* what is in and out of scope of the TAG,
* whether and how it overlaps and interfaces with other CNCF TAG’s or other relevant groups, and
* how it operates and is governed, and specifically whether and how it deviates from standard TAG 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).
See [Example Responsibilities of a CNCF TAG](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.
Important: Each TAG 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 TAG, 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
### TAG Formation, Leadership and Membership Composition
1. SIGs are formed by the TOC. Initial SIGs are listed in [proposed SIGs](/sigs/proposed.md), 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.
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 as shown in [sig member roles](/sigs/cncf-sigs.md#SIG-Member-Roles).
5. Participant diversity is strongly encouraged within SIGs, and SIG chairs are expected to actively encourage a diverse range of community members to take up named roles (see point 7).
6. A variety of perspectives 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 related companies, market segment, etc will be actively discouraged by the TOC.
7. 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. SIGs roles should have active mentoring and shadowing programs to encourage sustainability of the SIG.
1. TAGs are formed by the TOC. Initial TAGs are listed in [proposed TAGs](/tags/proposed.md), and will be adapted over time as required. If members of the community believe that additional TAGs are desired, they should propose these to the TOC, with clear justification, and ideally volunteers to lead the TAG. The TOC wishes to have the smallest viable number of TAGs, and for all of them to be highly effective (as opposed to a "TAG sprawl" with large numbers of relatively ineffective TAGS).
2. TAG has three co-chairs, who are TOC Contributors, recognized as experts in that area, and for their ability to co-lead the TAG to produce the required unbiased outputs.
3. TAG 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 TAG chairs.
4. TAG has multiple tech leads who are recognized as (1) experts in the TAG area, (2) leaders of projects in the TAG’s area (3) demonstrating the ability to provide the balanced technical leadership required to produce the required unbiased outputs of the TAG. 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 as shown in [TAG member roles](/tags/cncf-tags.md#TAG-Member-Roles).
5. Participant diversity is strongly encouraged within TAGs, and TAG chairs are expected to actively encourage a diverse range of community members to take up named roles (see point 7).
6. A variety of perspectives is strongly encouraged within TAGs. To this end, a supermajority (⅔ or more) of chairs or a supermajority of tech leads from a single group of related companies, market segment, etc will be actively discouraged by the TOC.
7. TAG members are self-declared, so that some TAG work is done by volunteers from the TOC Contributors and community. To recognise members who make sustained and valuable contributions to a TAG over time, TAG-defined and assigned roles may be created (e.g. scribe, training or documentation coordinator etc). TAG’s should document what these roles and responsibilities are, and who performs them, and have them approved by TAG leads. TAGs roles should have active mentoring and shadowing programs to encourage sustainability of the TAG.
### SIG Member Roles
### TAG 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.
* 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 TAG 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.
* Leads projects in the TAG’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 TAG.
#### TOC Liaison
* Streamlines communications between TOC and SIG chairs, and helps SIG to set priorities.
* Communicates performance of the SIG to TOC.
* Helps with growth and development of the SIG.
* Attends SIG meetings, as needed/requested.
* Streamlines communications between TOC and TAG chairs, and helps TAG to set priorities.
* Communicates performance of the TAG to TOC.
* Helps with growth and development of the TAG.
* Attends TAG meetings, as needed/requested.
#### Other named roles
* Named and defined by the SIG (e.g. scribe, PR lead, docs/training lead, etc)
* Named and defined by the TAG (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.
* May not create the impression that they have any authority or formal responsibilities in the TAG other than assigned roles.
### Elections
@ -139,13 +139,13 @@ As a starting point let’s be inspired by CNCF OSS Projects and by K8s SIGs. T
* 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
* Tech leads are assigned following a 2/3 majority vote of the TOC and a 2/3 majority vote of TAG Chairs
* TAG Chairs and Tech Leads may be unassigned from the TAG 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.
* All TAGs inherit and follow the CNCF TOC Operating Principles.
* TAGs 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
@ -153,12 +153,12 @@ As a starting point let’s be inspired by CNCF OSS Projects and by K8s SIGs. T
### 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.
* Just as CNCF Projects may have "help" offered by CNCF and may ask for things via the [ServiceDesk](https://github.com/cncf/servicedesk), the TAGs 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:
* Consider retiring the SIG after 3 months
* Must retire the SIG after 6 months
* In the event that a TAG is unable to regularly establish quorum, or fulfill the responsibilities and/or regularly report to the TOC, the TOC will:
* Consider retiring the TAG after 3 months
* Must retire the TAG 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.
* The TOC may, by means of a 2/3 majority vote, declare "no confidence" in the TAG. In this event, the TOC may then vote to retire or reconstitute the TAG.

50
sigs/contributor-strategy.md → tags/contributor-strategy.md
View File

@ -1,4 +1,4 @@
# CNCF SIG Contributor Strategy Charter
# CNCF TAG Contributor Strategy Charter
Primary Authors: Paris Pittman, Josh Berkus
@ -17,8 +17,8 @@ Reviewed and/or contributed to by:
* Sarah Allen
## Introduction
This charter describes the operations of the CNCF Special Interest Group (SIG)
Contributor Strategy. This SIG is responsible for contributor experience,
This charter describes the operations of the CNCF Special Interest Group (TAG)
Contributor Strategy. This TAG is responsible for contributor experience,
sustainability, governance, and openness guidance to help CNCF community groups
and projects with their own contributor strategies for a healthy project.
@ -28,7 +28,7 @@ Our initial three stakeholders:
3 - TOC
## Mission
Consistent with the CNCF SIG definition, the mission of CNCF SIG Contributor
Consistent with the CNCF TAG definition, the mission of CNCF TAG Contributor
Strategy is to collaborate on strategies related to building, scaling, and
retaining contributor communities, including (people) governance,
communications, operations, and tools. We want to help grow flourishing,
@ -49,7 +49,7 @@ points for rolling feedback and guidance.
#### In scope:
The following, non exhaustive list of activities and deliverables are
in-scope for the SIG:
in-scope for the TAG:
* Definition of a contributor. This is helpful across projects for metrics and
establishing guidelines, programs, and workflows.
* Contributor and goverance related proposed/suggested/modified project
@ -65,9 +65,9 @@ via surveys, GB reps, and Maintainers Circle (Example: what is the project doing
now, challenges, gaps)
#### Out of scope
* The day to day operations of CNCF SIGs, Kubernetes SIGs, or any community
* The day to day operations of CNCF TAGs, Kubernetes TAGs, or any community
group of CNCF or its respective projects of any graduation level.
* The creation and approval of CNCF SIGs or other community groups; we will
* The creation and approval of CNCF TAGs or other community groups; we will
offer advice but the responsibility lies on the TOC for those matters.
* CNCF operations and marketing initiatives such as: product review/demo
webinars, kubecon event planning, branding, stickers, swag, etc
@ -93,12 +93,12 @@ If you see something here that interests you, join us and start it:
* Automation and self service for contributors, community GitOps
## Governance
This SIGs topic requires cross collaboration between end users, CNCF SIGs, and
This TAGs topic requires cross collaboration between end users, CNCF TAGs, and
CNCF projects of all graduation levels.
This SIG should be populated and governed by reps from CNCF projects that want
This TAG should be populated and governed by reps from CNCF projects that want
to create and run intentional contributor experience programs, a rep(s) from the
end user committee, and the TOC liaison(s). While the SIG reps do not need to be
end user committee, and the TOC liaison(s). While the TAG reps do not need to be
core maintainers, they do need to have a drive for making things better for
contributors and end users. We welcome industry experts and academics in
relevant working groups!
@ -111,24 +111,24 @@ during a public TOC meeting.
### Members
Members are active participants in the work of the SIG who are entitled to vote
in any SIG decisions that require a vote. Any contributor to the SIG is
eligible to become a member after participating in the work of the SIG for at
Members are active participants in the work of the TAG who are entitled to vote
in any TAG decisions that require a vote. Any contributor to the TAG is
eligible to become a member after participating in the work of the TAG for at
least three months.
In order to prevent the SIG from becoming unbalanced, it will have the following
In order to prevent the TAG from becoming unbalanced, it will have the following
limits on who can be a voting member:
Up to one from each participating Incubating or Sandbox CNCF project
Up to two from each Graduated CNCF project
One from each SIG-ContribStrat Working Group, generally the lead for that WG
One from each TAG-ContribStrat Working Group, generally the lead for that WG
No more than ⅓ of members from the same employer
If a contributor would be entitled to be a member, but are restricted because of
the above limits, they are a non-voting member who may participate in meetings
but cannot vote.
Members who are no longer participating actively in the SIG (including both WG
Members who are no longer participating actively in the TAG (including both WG
work and the regular meetings) will step down from membership.
#### Chairs and TOC Liaison
@ -139,14 +139,14 @@ Dillon)
- Tech Leads: None at this time but can change with need at a later time with
charter ratification
In accordance with the terms and roles laid out in [cncf-sigs.md](https://github.com/cncf/toc/blob/master/sigs/cncf-sigs.md)
In accordance with the terms and roles laid out in [cncf-tags.md](https://github.com/cncf/toc/blob/master/tags/cncf-tags.md)
The TOC will also appoint 3 [Chairs](https://github.com/cncf/toc/blob/master/sigs/cncf-sigs.md#chair)
The TOC will also appoint 3 [Chairs](https://github.com/cncf/toc/blob/master/tags/cncf-tags.md#chair)
### Meetings and Decisions
Most SIG work will be carried out without requiring any kind of regular meeting
or vote. The SIG will have a regular meeting, bi-weekly, at which the
Most TAG work will be carried out without requiring any kind of regular meeting
or vote. The TAG will have a regular meeting, bi-weekly, at which the
membership may vote on the following items as the come up:
* Addition of new members or removal of inactive ones
@ -158,17 +158,17 @@ the TOC
### Bootstrapping
Initially, the TOC shall appoint three members in order to launch the SIG
Initially, the TOC shall appoint three members in order to launch the TAG
## Reach out!
Mailing List: [sig-contributor-strategy](mailto:sig-contributor-strategy@lists.cncf.io)
Mailing List: [TAG-contributor-strategy](mailto:tag-contributor-strategy@lists.cncf.io)
mailer at [lists.cncf.io](https://lists.cncf.io)
[Meeting Notes](https://docs.google.com/document/d/1Xjw-yAqidQW67zv7OfMRErsfCotc-mfQ_248Te_YL0g/edit#heading=h.252i9x89qe0d)
Slack channel: [#sig-contributor-strategy]
Slack channel: [#tag-contributor-strategy]
Public Meetings: Bi-weekly on Thursday at 5:30pm UTC. Join our mailing list for
[cncf-sigs.md]: https://github.com/cncf/toc/blob/master/sigs/cncf-sigs.md
[sig-contributor-strategy]: mailto:sig-contributor-strategy@lists.cncf.io
[cncf-tags.md]: https://github.com/cncf/toc/blob/master/TAGs/cncf-tags.md
[TAG-contributor-strategy]: mailto:tag-contributor-strategy@lists.cncf.io
[lists.cncf.io]: https://lists.cncf.io
[Meeting Notes]: https://docs.google.com/document/d/1Xjw-yAqidQW67zv7OfMRErsfCotc-mfQ_248Te_YL0g/edit#heading=h.252i9x89qe0d

42
sigs/network.md → tags/network.md
View File

@ -1,4 +1,4 @@
# CNCF SIG Network
# CNCF TAG Network
Primary Authors: Lee Calcote
@ -10,7 +10,7 @@ With the increased prevalence of microservice-based distributed systems, network
# Mission Statement
SIG Network&#39;s charter is inspired from the [CNCF Networking WG](https://github.com/cncf/wg-networking). With an ever steady eye to the needs of workloads and developers who create them and operators who run them, SIG Network&#39;s mission is to enable widespread and successful development, deployment and operation of resilient and intelligent network systems in cloud native environments through these activities to:
TAG Network&#39;s charter is inspired from the [CNCF Networking WG](https://github.com/cncf/wg-networking). With an ever steady eye to the needs of workloads and developers who create them and operators who run them, TAG Network&#39;s mission is to enable widespread and successful development, deployment and operation of resilient and intelligent network systems in cloud native environments through these activities to:
1. **Clarify and inform.** Provide valuable and objective information to the TOC, End Users and Projects of the CNCF regarding areas considered in-scope. Strengthen the project ecosystem to meet the needs of end users and project contributors. Educate and inform users with unbiased, effective, and practically useful information.
2. **Collaborate and interrelate.** Effectively interface with other related groups internal and external to the CNCF and connect the dots to facilitate meaningful collaborative progression of relevant topics. Engage more communities and create an on-ramp to effective TOC contribution &amp; recognition.
@ -24,16 +24,16 @@ We strive to understand the fundamental characteristics of different networking
- Especially where these differ significantly from network systems and approaches previously commonly used in traditional enterprise data center environments.
- Consideration for public, private, and hybrid cloud environments.
- Network functions and services, including but not limited to, the discovery, monitoring, management, routing, load balancing, firewalling, quality of service, provided by service proxy, API gateway, service mesh, remote procedure call, coordination &amp; service discovery.
- Provide an umbrella SIG for Networking WG and Universal Data Plane API Working Group (UDPA-WG).
- [Networking WG](https://github.com/cncf/wg-networking) will fold directly into SIG Network.
- Provide an umbrella TAG for Networking WG and Universal Data Plane API Working Group (UDPA-WG).
- [Networking WG](https://github.com/cncf/wg-networking) will fold directly into TAG Network.
- UDPA-WG will continue with existing calls and mailing list.
- Facilitating an understanding of network abstraction APIs for meshes, proxies and other network services.
- Influence and provide guidance on the definition of network abstraction specifications. Network SIG may review and recommend adoption.
- Networking extends to services and workloads not running on Kubernetes. Network SIG focuses on the integration and interoperability of networking running those workloads, not on those (physical) networking systems themselves unto their own.
- Influence and provide guidance on the definition of network abstraction specifications. Network TAG may review and recommend adoption.
- Networking extends to services and workloads not running on Kubernetes. Network TAG focuses on the integration and interoperability of networking running those workloads, not on those (physical) networking systems themselves unto their own.
### Current CNCF Network-centric Projects
Generally, projects listed in the [CNCF Landscape](https://l.cncf.io) under the categories of Service Mesh, API Gateway, Coordination &amp; Service Discovery, Service Proxy, Remote Procedure Call, and Cloud Native Network are considered in-scope of this SIG.
Generally, projects listed in the [CNCF Landscape](https://l.cncf.io) under the categories of Service Mesh, API Gateway, Coordination &amp; Service Discovery, Service Proxy, Remote Procedure Call, and Cloud Native Network are considered in-scope of this TAG.
- CNI
- CoreDNS
@ -45,7 +45,7 @@ Generally, projects listed in the [CNCF Landscape](https://l.cncf.io) under the
## Out of Scope
Generally anything not considered in scope. The SIG may touch on physical networking hardware as it relates to the running of or interoperability of cloud native networking, but is not a stated focus of the SIG unto its own. See also Overlap and Relations with other Related Groups.
Generally anything not considered in scope. The TAG may touch on physical networking hardware as it relates to the running of or interoperability of cloud native networking, but is not a stated focus of the TAG unto its own. See also Overlap and Relations with other Related Groups.
# Overlap and Relations with other Groups and Projects
@ -53,10 +53,10 @@ The area of networking interfaces with essentially all areas of the cloud native
- Current CNCF Network-centric Projects - we maintain close communication with these projects and their communities to avoid unnecessary duplication of effort and inconsistent messaging wherever possible.
- Kubernetes Network SIG - is focused towards Kubernetes-specific network abstractions, interfaces, and implementations of these interfaces. We maintain close communication with this Kubernetes SIG, with several individuals actively involved in both. Our aim is to avoid unnecessary duplication of effort by the two groups, and maintain clear and consistent messaging by the two groups to our end user community and projects.
- CNCF Security SIG - works on the more general area of cloud-native security including authentication, authorization, encryption, accounting, auditing and related topics. Each of these topics are directly applicable and often implemented as network services. We defer as much as possible to this group to deal with general security-related issues, and liaise closely with them on how to deal with network-specific security as these are a continual area of concern.
- CNCF App Delivery SIG - will be focussed on the development, deployment, operation and testing of cloud-native applications. We collaborate with this SIG where this pertains to Networking and Traffic, particularly around application deployment, debugging, and monitoring.
- CNCF Storage SIG - primarily with respect to service discovery as cloud native name services as related etcd.
- Workload Profile Definition and Measurement Project - this project aims to define an industry standard definition for workload profiles and a standard set of measures and metrics that represent those profiles with the goal of developing an open source standard benchmarking to validate these. The CNCF Network SIG will engage as and when a network-related specification or set of benchmarks is presented.
- CNCF Security TAG - works on the more general area of cloud-native security including authentication, authorization, encryption, accounting, auditing and related topics. Each of these topics are directly applicable and often implemented as network services. We defer as much as possible to this group to deal with general security-related issues, and liaise closely with them on how to deal with network-specific security as these are a continual area of concern.
- CNCF App Delivery TAG - will be focussed on the development, deployment, operation and testing of cloud-native applications. We collaborate with this TAG where this pertains to Networking and Traffic, particularly around application deployment, debugging, and monitoring.
- CNCF Storage TAG - primarily with respect to service discovery as cloud native name services as related etcd.
- Workload Profile Definition and Measurement Project - this project aims to define an industry standard definition for workload profiles and a standard set of measures and metrics that represent those profiles with the goal of developing an open source standard benchmarking to validate these. The CNCF Network TAG will engage as and when a network-related specification or set of benchmarks is presented.
- Service Mesh Interface (SMI) - is a standard interface for service meshes on Kubernetes.
- Multi-Vendor Service Mesh Interoperation - specifies a set of API standards for enabling service mesh federation.
@ -80,7 +80,7 @@ Clarify and further concepts of cloud native networking, traffic management and
- **Proposed project review** - a pre-review of upcoming project proposed for adoption, allowing projects to have a soft review, gauge and garner CNCF interest.
- Provide recommendations for new CNCF projects.
- **New projects** - recommendation of sandbox projects where exploration is needed.
- **SIG reports to TOC** - scheduled regular reporting to ToC on ongoing and completed work.
- **TAG reports to TOC** - scheduled regular reporting to ToC on ongoing and completed work.
- **Cloud Native networking whitepaper(s)** - framework document for the cloud native traffic and networking space.
- Cloud Native Networking Patterns
- **Network Landscape** - a deeper and category-specific project landscape (e.g. [service mesh landscape](https://layer5.io/landscape)).
@ -88,23 +88,23 @@ Clarify and further concepts of cloud native networking, traffic management and
# Governance &amp; Operations
This SIG follows the [standard operating model](https://github.com/cncf/toc/blob/main/sigs/cncf-sigs.md#operating-model) provided by the TOC unless otherwise stated here.
This TAG follows the [standard operating model](https://github.com/cncf/toc/blob/main/tags/cncf-tags.md#operating-model) provided by the TOC unless otherwise stated here.
# Operating Model
## Chairs:
- TOC Liaison: [Dave Zolotusky](https://twitter.com/dzolotusky), [Liz Rice](https://twitter.com/lizrice)
- SIG Chairs: [Lee Calcote](https://twitter.com/lcalcote), [Ken Owens](https://twitter.com/kenowens12)
- TAG Chairs: [Lee Calcote](https://twitter.com/lcalcote), [Ken Owens](https://twitter.com/kenowens12)
In accordance with the [elections and terms](https://github.com/cncf/toc/blob/main/sigs/cncf-sigs.md#elections) follow the [CNCF SIG definition](https://github.com/cncf/toc/blob/main/sigs/cncf-sigs.md#elections).
In accordance with the [elections and terms](https://github.com/cncf/toc/blob/main/tags/cncf-tags.md#elections) follow the [CNCF TAG definition](https://github.com/cncf/toc/blob/main/tags/cncf-tags.md#elections).
## Communications
- Slack Channel ([#sig-network](https://app.slack.com/client/T08PSQ7BQ/CMG237Z5Z))
- Join [SIG-Network](mailto:sig-network@lists.cncf.io) mailer at [lists.cncf.io](https://lists.cncf.io)
- Repo: [https://github.com/cncf/sig-network](https://github.com/cncf/sig-network)
- Slack Channel ([#tag-network](https://app.slack.com/client/T08PSQ7BQ/CMG237Z5Z))
- Join [TAG-Network](mailto:tag-network@lists.cncf.io) mailer at [lists.cncf.io](https://lists.cncf.io)
- Repo: [https://github.com/cncf/tag-network](https://github.com/cncf/tag-network)
- Meetings:
- Time: Network SIG meets the 1st and 3rd Thursday of every month at 11am Pacific (here's [a link](https://goo.gl/eyutah) to a public Google calendar that you can subscribe to).
- Location: Zoom - [https://zoom.us/my/cncfsignetwork](https://zoom.us/my/cncfsignetwork)
- Time: Network TAG meets the 1st and 3rd Thursday of every month at 11am Pacific (here's [a link](https://goo.gl/eyutah) to a public Google calendar that you can subscribe to).
- Location: Zoom - [https://zoom.us/my/cncftagnetwork](https://zoom.us/my/cncftagnetwork)
- [Meeting Minutes](https://docs.google.com/document/d/18hYemFKK_PC_KbT_TDBUgb0rknOuIhikkRxer4_bv4Q/edit#)

56
sigs/observability.md → tags/observability.md
View File

@ -1,6 +1,6 @@
# CNCF SIG Observability Charter
# CNCF TAG Observability Charter
- [CNCF SIG Observability Charter](#cncf-sig-observability-charter)
- [CNCF TAG Observability Charter](#cncf-tag-observability-charter)
- [Introduction](#introduction)
- [Mission](#mission)
- [Areas considered in Scope](#areas-considered-in-scope)
@ -50,24 +50,24 @@ and [Umair Ishaq][Umair Ishaq].*
## Introduction
This document describes the purpose and operations of the Cloud Native
Computing Foundation ([CNCF]) Special Interest Group ([SIG]) on Observability.
Computing Foundation ([CNCF]) Technical Advisory Group([TAG]) on Observability.
This [SIG] focuses on topics pertaining to the observation
This [TAG] focuses on topics pertaining to the observation
of [cloud native][cn-def] workloads. Additionally, it produces supporting
material and best practices for end-users and provides guidance and
coordination for CNCF projects working within the SIG’s scope.
coordination for CNCF projects working within the TAG’s scope.
A full list of [CNCF projects][projs] can be found at [landscape.cncf.io].
[cncf]: https://www.cncf.io
[projs]: https://www.cncf.io/projects
[landscape.cncf.io]: https://landscape.cncf.io
[sig]: https://github.com/cncf/toc/blob/main/sigs/cncf-sigs.md
[tag]: https://github.com/cncf/toc/blob/main/tags/cncf-tags.md
[cn-def]: https://github.com/cncf/toc/blob/main/DEFINITION.md
## Mission
Consistent with the CNCF [SIG] definition, the mission of SIG Observability
Consistent with the CNCF [TAG] definition, the mission of TAG Observability
is to:
- Foster and grow the ecosystem of observability related projects, users, and
@ -83,7 +83,7 @@ is to:
- Provide and maintain a vendor-neutral venue for relevant thought validation,
discussion, and project feedback.
- Provide a ladder for community members to become involved with the technical
oversight of projects within the SIG's scope in an open, transparent, and
oversight of projects within the TAG's scope in an open, transparent, and
inclusive way.
## Areas considered in Scope
@ -122,7 +122,7 @@ topics such as:
like SLI/KPI, service objectives, and internal/external commitments.
The following is a non-exhaustive sample list of activities and deliverables
that are in-scope for this SIG
that are in-scope for this TAG
- Summary and overview of projects available in the community.
- Catalog of reference architectures that draw from CNCF projects, combining
@ -132,7 +132,7 @@ that are in-scope for this SIG
- Tooling composition and tool chain creation based on existing projects.
- Best practices for operations and monitoring workflows using CNCF Projects.
- Organizing and helping to provide visibility to Meetups, Blogs, and Podcasts
related to the scope of the SIG.
related to the scope of the TAG.
- Guidance for application development and architecture that is observable.
- Replicatable reference architectures.
- Patterns for observing application delivery pipelines.
@ -152,51 +152,51 @@ Anything not explicitly considered in the scope above.
Examples include:
- Datastores that are not primarily used for observability. Those datastores
might be in the scope of SIG Storage.
might be in the scope of TAG Storage.
- Security aspects that need to be present when setting up cloud native
infrastructure, these might be more relevant for SIG Security.
infrastructure, these might be more relevant for TAG Security.
- How cloud native applications that need observability are deployed; this would
fall in the scope of SIG App Delivery
fall in the scope of TAG App Delivery
- Tools and projects that are used to run cloud native workloads that in some
cases need observability would fall under the scope of SIG-Runtime.
cases need observability would fall under the scope of TAG-Runtime.
## Roadmap & Initial Efforts
- Contribute to [due diligence reports][ddr] to assist the CNCF TOC for projects
in the scope of the SIG.
in the scope of the TAG.
- Facilitate webinars and presentations from CNCF projects and domain experts in
the scope of the SIG.
- Formation of [SIG working group(s)][sigwg] as resource capacity and member
the scope of the TAG.
- Formation of [TAG working group(s)][tagwg] as resource capacity and member
contribution allows.
> _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._
[ddr]: https://github.com/cncf/toc/blob/main/process/due-diligence-guidelines.md
[sigwg]: https://github.com/cncf/toc/blob/main/sigs/cncf-sigs.md#responsibilities--empowerment-of-sigs
[tagwg]: https://github.com/cncf/toc/blob/main/tags/cncf-tags.md#responsibilities--empowerment-of-tags
## Governance
- This SIG follows the [standard operating model][som] provided by the TOC
- This TAG follows the [standard operating model][som] provided by the TOC
unless otherwise stated here.
[som]: https://github.com/cncf/toc/blob/main/sigs/cncf-sigs.md#operating-model
[som]: https://github.com/cncf/toc/blob/main/tags/cncf-tags.md#operating-model
## Operations
- Formation of the SIG follows the [documented process][sigform].
- [Roles][sigroles] for SIG Observability
- Formation of the TAG follows the [documented process][tagform].
- [Roles][tagroles] for TAG Observability
- TOC Liaison: Lei Zhang, Cornelia Davis
- SIG Chairs: [Matt Young](https://github.com/halcyondude), [Richard Hartmann](https://github.com/RichiH)
- TAG Chairs: [Matt Young](https://github.com/halcyondude), [Richard Hartmann](https://github.com/RichiH)
- Tech Leads: [Michael Hausenblas](https://github.com/mhausenblas), [Bartłomiej Płotka](https://github.com/bwplotka),
\*_**(TODO: need confirmation)**_
[sigform]: https://github.com/cncf/toc/tree/main/sigs#sig-formation-process
[sigroles]: https://github.com/cncf/toc/blob/main/sigs/cncf-sigs.md#sig-member-roles
[tagform]: https://github.com/cncf/toc/tree/main/tags#tag-formation-process
[tagroles]: https://github.com/cncf/toc/blob/main/tags/cncf-tags.md#tag-member-roles
- Contact
- Slack channel: #sig-observability @ [https://cloud-native.slack.com](https://cloud-native.slack.com)
- Email List: [cncf-sig-observability@lists.cncf.io](mailto:cncf-sig-observability@lists.cncf.io)
- Slack channel: #tag-observability @ [https://cloud-native.slack.com](https://cloud-native.slack.com)
- Email List: [cncf-tag-observability@lists.cncf.io](mailto:cncf-tag-observability@lists.cncf.io)
- Meeting Schedule:
- TBD - pending feedback from SIG members
- TBD - pending feedback from TAG members
- [https://www.cncf.io/community/calendar](https://www.cncf.io/community/calendar/)

0
sigs/proposed.md → tags/proposed.md
View File

52
sigs/runtime-charter.md → tags/runtime-charter.md
View File

@ -1,4 +1,4 @@
## CNCF Runtime SIG Charter
## CNCF Runtime TAG Charter
### Primary Author: Quinton Hoole
@ -13,9 +13,9 @@ Also reviewed and contributed to by:
## Introduction
This is the charter referred to in “[CNCF
SIGs](https://github.com/cncf/toc/blob/main/sigs/cncf-sigs.md#sig-charter)”
by the CNCF TOC, and consistent with the [proposed SIG
definition](https://github.com/cncf/toc/blob/main/sigs/proposed.md).
TAGs](https://github.com/cncf/toc/blob/main/tags/cncf-tags.md#tag-charter)”
by the CNCF TOC, and consistent with the [proposed TAG
definition](https://github.com/cncf/toc/blob/main/tags/proposed.md).
## Areas Considered In Scope
@ -43,15 +43,15 @@ Anything not considered in scope above is out of scope. See also “Interfaces
Examples include:
* General authentication, authorization, accounting, auditing, etc (even though these clearly apply to several of the areas in the scope of this SIG)
- because AAA, etc is clearly the domain of the [CNCF Security SIG](https://github.com/cncf/sig-security).
* General authentication, authorization, accounting, auditing, etc (even though these clearly apply to several of the areas in the scope of this TAG)
- because AAA, etc is clearly the domain of the [CNCF Security TAG](https://github.com/cncf/tag-security).
* Getting network traffic into and out of workloads, or any of the interfaces related to that (e.g. CNI)
- these are the domain of the ([proposed](https://github.com/cncf/toc/blob/main/sigs/proposed.md)) CNCF Traffic SIG, and other related network-centric groups.
- these are the domain of the [CNCF Network TAG](https://github.com/cncf/tag-network), and other related network-centric groups.
* Local or remote storage associated with workloads
- this is the domain of the [CNCF Storage SIG](https://github.com/cncf/sig-storage) and related groups.
- this is the domain of the [CNCF Storage TAG](https://github.com/cncf/tag-storage) and related groups.
## SIG Mission Statement
## TAG Mission Statement
To enable widespread and successful execution of the full spectrum of workload types,
including both general latency-sensitive and batch, as well as more specialized
@ -63,11 +63,11 @@ categories listed as in scope, in cloud-native environments through:
End Users and Projects of the CNCF regarding areas considered in scope (see above).
2. Collaborating effectively with other related groups (see below).
3. Helping to maintain the continued health of the CNCF Projects deemed
to be within the scope of this SIG (see below)
to be within the scope of this TAG (see below)
4. Identifying and filling gaps in the landscape of CNCF Projects within scope.
Specific SIG deliverables are as per the above, and the [general SIG responsibilities
set out by the CNCF TOC](https://github.com/cncf/toc/blob/main/sigs/cncf-sigs.md#responsibilities--empowerment-of-sigs).
Specific TAG deliverables are as per the above, and the [general TAG responsibilities
set out by the CNCF TOC](https://github.com/cncf/toc/blob/main/tags/cncf-tags.md#responsibilities--empowerment-of-tags).
## Current CNCF Projects considered to be within the Scope of this SIG
@ -95,40 +95,40 @@ set out by the CNCF TOC](https://github.com/cncf/toc/blob/main/sigs/cncf-sigs.md
SIGs where needed. Our aim is to avoid unnecessary duplication of
effort by the two groups and maintain clear and consistent messaging
to our end user community and projects.
* **[CNCF Security SIG](https://github.com/cncf/sig-security)**
* **[CNCF Security TAG](https://github.com/cncf/tag-security)**
- works on the more general area of cloud-native security including
authentication, authorization, encryption, accounting, auditing, and
related topics. We defer as much as possible to this group to deal
with general security-related issues and liaise closely with them on
how to deal with security areas where these arise.
* **[CNCF App Delivery SIG](https://github.com/cncf/sig-app-delivery)**
* **[CNCF App Delivery TAG](https://github.com/cncf/tag-app-delivery)**
is focussed on the development, deployment, operation and testing of
cloud-native applications. We collaborate with this SIG where it
cloud-native applications. We collaborate with this TAG where it
pertains to helping to ensure that the required underlying workload
execution abstractions and mechanisms are suitably provided to support
these application-level delivery needs.
* **[OCI Open Container Initiative](https://www.opencontainers.org/)**
is an open governance structure focussed on creating industry standards
around container formats and runtime. CNCF projects in the scope of
this SIG-Runtime will typically engage directly with OCI, with SIG-Runtime
this TAG-Runtime will typically engage directly with OCI, with TAG-Runtime
being involved as needed.
* **Note regarding Container Registries/Repositories** and the like:
While image packaging and distribution (and hence container
registries/repositories in general) fall within the scope of this
Runtime SIG, many of their common features and use cases are better
dealt with by other CNCF SIGS. For example:
* image storage, caching, etc - Storage SIG
* Image encryption, signing etc - Security SIG
Runtime TAG, many of their common features and use cases are better
dealt with by other CNCF TAGS. For example:
* image storage, caching, etc - Storage TAG
* Image encryption, signing etc - Security TAG
* use of image registries to store and distribute many other types
of artifacts, and in particular the format of these artifacts,
including helm charts, OPA policies, public security certificates,
data sets, machine learning models, etc, etc - the SIG relevant to
those artifact types, e.g. Apps SIG, Security SIG, etc.
data sets, machine learning models, etc, etc - the TAG relevant to
those artifact types, e.g. Apps TAG, Security TAG, etc.
## **Operations**
This SIG follows the [standard operating guidelines](https://github.com/cncf/toc/blob/main/sigs/cncf-sigs.md#operating-model)
This TAG follows the [standard operating guidelines](https://github.com/cncf/toc/blob/main/tags/cncf-tags.md#operating-model)
provided by the TOC unless otherwise stated here.
@ -146,11 +146,11 @@ provided by the TOC unless otherwise stated here.
## Meeting Schedule
The CNCF SIG-Runtime group meets twice a month on the 1st and 3rd Thu of
The CNCF TAG-Runtime group meets twice a month on the 1st and 3rd Thu of
each month at 8am Pacific, 11am Eastern.
Zoom: [https://zoom.us/my/cncfsigruntime](https://zoom.us/my/cncfsigruntime)
Zoom: [https://zoom.us/my/cncftagruntime](https://zoom.us/my/cncftagruntime)
Mailing list: Join SIG-Runtime mailing list at [lists.cncf.io](https://lists.cncf.io)
Mailing list: Join TAG-Runtime mailing list at [lists.cncf.io](https://lists.cncf.io)
Slack channel: [https://cloud-native.slack.com/messages/CPBE97SMU](https://cloud-native.slack.com/messages/CPBE97SMU)

26
sigs/security-charter.md → tags/security-charter.md
View File

@ -1,6 +1,6 @@
# SIG-Security Charter
# TAG-Security Charter
This charter describes operations as a [CNCF SIG](https://github.com/cncf/toc/blob/master/sigs/). The [Focus](#focus) section below describes what is in and out of scope,
This charter describes operations as a [CNCF TAG](https://github.com/cncf/toc/blob/master/tags/). The [Focus](#focus) section below describes what is in and out of scope,
and [Governance](#governance) section describes how our operations are consistent with CNCF policies with links to more detailed documents.
**Mission:** to reduce risk that cloud native
@ -36,7 +36,7 @@ improve overall security in cloud native systems.
## Focus
In addition to the [CNCF security-related projects](https://github.com/cncf/sig-security/blob/master/governance/cncf-projects.md), there
In addition to the [CNCF security-related projects](https://github.com/cncf/tag-security/blob/master/governance/cncf-projects.md), there
are three key focus areas:
* Protection of heterogeneous, distributed and fast changing systems, while
providing needed access
@ -47,7 +47,7 @@ requirements
### In scope
Terminology note: SIG-Security uses the term "end user" to describe the humans
Terminology note: TAG-Security uses the term "end user" to describe the humans
who use cloud native applications, whereas CNCF refers to companies that operate
cloud native systems as CNCF End Users. In the context of security, we often
need to discuss how a particular control affects the people who use the software
@ -59,7 +59,7 @@ system or the privacy of its users, specifically how to enable secure
access, policy control and safety for operators, administrators,
developers, and end-users across the cloud native ecosystem.
SIG-Security will consider [proposals](https://github.com/cncf/sig-security/blob/master/governance/process.md) from its members or delegated
TAG-Security will consider [proposals](https://github.com/cncf/tag-security/blob/master/governance/process.md) from its members or delegated
tasks from the CNCF TOC that are consistent with the mission, including
the following activities:
@ -79,12 +79,12 @@ the following activities:
* Best practices and anti-patterns (potentially highlighting where there is disagreement on these)
* Security assessments of specific proposals or projects
* Identify projects for consideration for CNCF
* Cross-pollinate knowledge by participating and inviting people from other projects and SIGs to share security practices
* Integrate relevant external standards, such as from CII or NIST, as part of educational resources and/or SIG processes
* Cross-pollinate knowledge by participating and inviting people from other projects and TAGs to share security practices
* Integrate relevant external standards, such as from CII or NIST, as part of educational resources and/or TAG processes
Given that the group is comprised of volunteers, specific requests from the TOC
may be queued according to the bandwidth of the group. The co-chairs will
facilitate prioritization under the guidance of the SIG-Security TOC liaison.
facilitate prioritization under the guidance of the TAG-Security TOC liaison.
### Out of scope
* Not a standards body: We won't be creating standards.
@ -115,16 +115,16 @@ other groups that
focus on a particular technology (such as Kubernetes SIGs) or have a broader
mandate (such as government organizations).
As a guide to visitors, we maintain the list of groups in the SIG
[README](https://github.com/cncf/sig-security#related-groups).
As a guide to visitors, we maintain the list of groups in the TAG
[README](https://github.com/cncf/tag-security#related-groups).
Co-chairs are responsible to ensure periodic cross-group knowledge sharing,
which is accomplished by cross-group membership, invitation to present at
a SIG meeting and/or offering to present to the related group.
a TAG meeting and/or offering to present to the related group.
## Operations
SIG-Security operations are consistent with standard SIG operating guidelines
TAG-Security operations are consistent with standard TAG operating guidelines
provided by the CNCF Technical Oversight Committee
[TOC](https://github.com/cncf/toc).
Full details of process and roles are linked in the SIG Security [governance README](https://github.com/cncf/sig-security/tree/master/governance).
Full details of process and roles are linked in the TAG Security [governance README](https://github.com/cncf/tag-security/tree/master/governance).

10
sigs/security.md → tags/security.md
View File

@ -1,16 +1,16 @@
# CNCF SIG-Security: Special Interest Group on Security
# CNCF TAG-Security: Special Interest Group on Security
* [Charter](security-charter.md) - reviewed by and contributed to by Jeyappragash JJ, Sarah Allen,
Dan Shaw, Brandon Lum, with additional contributions by Alexis Richardson,
Quinton Hoole and members of SIG-Security (formerly known as SAFE WG), with
Quinton Hoole and members of TAG-Security (formerly known as SAFE WG), with
final review by Liz Rice, Joe Beda and Zhipeng Huang.
* [Current CNCF Projects](https://github.com/cncf/sig-security/blob/master/governance/cncf-projects.md)
* [Current CNCF Projects](https://github.com/cncf/tag-security/blob/master/governance/cncf-projects.md)
## **Operations**
**TOC Liaisons:** [Liz Rice](https://github.com/lizrice), [Justin Cormack](https://github.com/justincormack)
**SIG Chairs:** [Sarah Allen](https://github.com/ultrasaurus), [Emily Fox](https://github.com/TheFoxAtWork), [Jeyappragash JJ](https://github.com/pragashj)
**TAG Chairs:** [Sarah Allen](https://github.com/ultrasaurus), [Emily Fox](https://github.com/TheFoxAtWork), [Jeyappragash JJ](https://github.com/pragashj)
**Tech Leads:**
* Brandon Lum ([@lumjjb](https://github.com/lumjjb)), IBM
@ -19,4 +19,4 @@ final review by Liz Rice, Joe Beda and Zhipeng Huang.
* Andres Vega ([@anvega](https://github.com/anvega), VMWare
* Aradhana Chetal ([@achetal01](https://github.com/achetal01), TIAA
For complete details on process and elaboration of rules, see [SIG-Security governance](https://github.com/cncf/sig-security/tree/master/governance)
For complete details on process and elaboration of rules, see [TAG-Security governance](https://github.com/cncf/tag-security/tree/master/governance)

22
sigs/storage-charter.md → tags/storage-charter.md
View File

@ -1,4 +1,4 @@
# CNCF Storage SIG Charter
# CNCF Storage TAG Charter
Primary Author: Quinton Hoole
@ -11,7 +11,7 @@ Group and community.
# Introduction
This is the charter referred to in [CNCF
SIGs](https://github.com/cncf/toc/blob/main/sigs/cncf-sigs.md#sig-charter)
TAGs](https://github.com/cncf/toc/blob/main/tags/cncf-tags.md#tag-charter)
by the CNCF TOC.
# Areas Considered In Scope
@ -47,13 +47,13 @@ Examples include:
not they’re being used in a cloud-native environment).
* General authentication, authorization, accounting, auditing etc
(even though these clearly apply to storage systems too) - because
AAA etc is clearly the domain of the CNCF Security SIG.
AAA etc is clearly the domain of the CNCF Security TAG.
* Standardizing container storage interfaces - this is the domain of CSI.
* Defining storage abstraction APIs for container orchestrators -
these are the domains of the Storage SIGs specific to each
these are the domains of the Storage TAGs or SIGs specific to each
orchestrator, e.g. Kubernetes Storage SIG.
# SIG Mission Statement
# TAG Mission Statement
To enable widespread and successful storage of persistent state in
cloud-native environments through:
@ -91,15 +91,15 @@ cloud-native environments through:
container orchestration systems. Again, we maintain close
communication with this group, and avoid unnecessary duplication
of effort and inconsistent messaging wherever possible.
* **CNCF Security SIG** - works on the more general area of
* **CNCF Security TAG** - works on the more general area of
cloud-native security including authentication, authorization,
encryption, accounting, auditing and related topics. We defer as
much as possible to this group to deal with general
security-related issues, and liaise closely with them on how to
deal with storage-specific security areas where these arise.
* **CNCF Apps SIG** (not yet fully formed) - will be focussed on the
* **CNCF App-Delivery TAG** - be focussed on the
development, deployment, operation and testing of cloud-native
applications. We collaborate with this SIG where this pertains to
applications. We collaborate with this TAG where this pertains to
Storage.
* **K8s Apps SIG** - has done some work on how Kubernetes apps use
storage, as well as how storage systems (including databases) may
@ -112,13 +112,13 @@ cloud-native environments through:
# Operating Model
This SIG follows the [standard operating
guidelines](https://github.com/cncf/toc/blob/main/sigs/cncf-sigs.md#operating-model)
This TAG follows the [standard operating
guidelines](https://github.com/cncf/toc/blob/main/tags/cncf-tags.md#operating-model)
provided by the TOC unless otherwise stated here.
**TOC Liaison:** [Erin Boyd](https://github.com/erinboyd), [Saad Ali](https://github.com/saad-ali)
**SIG Chairs:** [Alex Chircop](https://github.com/chira001), [Quinton Hoole](https://github.com/quinton-hoole)
**TAG Chairs:** [Alex Chircop](https://github.com/chira001), [Quinton Hoole](https://github.com/quinton-hoole)
**Tech Leads:** Xing Yang, Sugu Sougoumarane, Luis Pabon