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

What: resolving existing comments 

Signed-off-by: Emily Fox <themoxiefoxatwork@gmail.com>
This commit is contained in:
Emily Fox 2022-07-05 12:03:57 -04:00
parent 4b898e0dc9
commit 0280db457c
No known key found for this signature in database
GPG Key ID: 2B5E8B9A27758A8C
2 changed files with 7 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
FAQ.md
View File

@ -54,7 +54,9 @@ The CNCF provides a variety of services that are accessible by maintainers via t
## What is the definition of an adopter?
Adopters of a CNCF project are any organization that successfully leverages that project in the manner it was intended or repackages it as a core component of a service offering. To increase understanding of how the project is adopted, we distinguish a direct adopter from a transitive adopter; i.e. a Service Provider using Kubernetes as the underlying container orchestrator for their Knative offering, in this scenario the Service Provider is a direct adopter of Kubernetes and their Knative users are direct adopters of Knative but transitive adopters of Kubernetes.
The TOC’s intent of identifying adopters is to better understand the operational or production-level use of a given project (which can also be a specification) by its operators or users. We do this to ascertain the level of maturity the project has reached, its interactions with adopters, and its likelihood to continue growing within and supporting the ecosystem.
Direct adopters of a project are responsible for the project's development, packaging, configuration, or deployment in their use of it. Transitive adopters of a project are not responsible for the project's development, packaging, configuration, or deployment, however they may receive the benefits that the project provides. In the case of the example above, the Service Provider's use of Kubernetes enables their customers to use Knative, which relies on Kubenertes as part of its architecture. However, if the Service Provider's implementation enables their customers to develop, package, configure, or deploy Kubernetes as part of the Knative offering, those customers are then also direct adopters.
The TOC’s intent in identifying adopters is to better understand the operational or production-level use of a given project (which can also be a specification) by its operators or users. We do this to ascertain the level of maturity the project has reached, its interactions with adopters, and its likelihood to continue growing within and supporting the ecosystem.
[Cloud native](https://github.com/cncf/toc/blob/main/DEFINITION.md) project adopters may be any one of the following. Please note that any single company can fall under several categories at once. If that's the case, it should enumerate all that apply and only be listed once. For the purposes of identifying the adopters of a project, we encourage the use of `adopter` to include all of the below, if a project needs to identify the category of adopter we encourage them to use the convention provided below.
* A CNCF End-User member - Companies and organizations who are End-User members of the CNCF (https://www.cncf.io/enduser/ & https://landscape.cncf.io/card-mode?enduser=yes). TThis group is identified in the written form by the convention `End-User`, capitalizing the `E` in `End`, hyphenating the two words, and captializing the `U` in `User`.
@ -64,10 +66,10 @@ The TOC’s intent of identifying adopters is to better understand the operation
* APIs
* SaaS
* A Service Provider’s customers are considered transitive adopters and should be excluded from identification within the ADOPTERS.md file.
* Examples of Service Providers (and not end users) include cloud providers (e.g., Alibaba Cloud, AWS, Google Cloud, Microsoft Azure), infrastructure software vendors (e.g., SUSE, Red Hat), and telecom operators (e.g., AT&T, China Mobile). Refer to the [vendor category on the landscape](https://landscape.cncf.io/category=cncf-members&enduser=no&format=card-mode&grouping=category) for more examples.
* Consultancy - an entity whose purpose is to assist other organizations in developing a solution leveraging cloud native technology. They may be embedded in the end user team and is responsible for the execution of the service. They may also package cloud native technologies for reuse as part of their offerings. These function as proxies for an end user.
* Examples of Service Providers (and not end users) include cloud providers (e.g., Alibaba Cloud, AWS, Google Cloud, Microsoft Azure), some infrastructure software vendors, and telecom operators (e.g., AT&T, China Mobile). Refer to the [vendor category on the landscape](https://landscape.cncf.io/category=cncf-members&enduser=no&format=card-mode&grouping=category) for more examples.
* Consultancy - an entity whose purpose is to assist other organizations in developing a solution leveraging cloud native technology. They may be embedded in the end user team and is responsible for the execution of the service. Service Providers may also provide consultancy services, they may also package cloud native technologies for reuse as part of their offerings. These function as proxies for an end user.
Projects may leverage the above guidelines to list organizations in their ADOPTERS.md file within their repo.
Projects may leverage the above guidelines to list organizations in their ADOPTERS.md file within their repo, projects are not required to identify the type of adopter in their ADOPTERS.md file.
If you’re not sure if your organization falls into any of these categories you can ask in the #toc slack channel, on the TOC mailing list, or email info@cncf.io and we’ll help you.

2
process/project_proposals.md
View File

@ -70,7 +70,7 @@ All exceptions (and "no" outcomes) are handled by the TOC.
* 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. adopter interviews where the adopter wishes to remain anonymous) and are documented using discretion.
* TOC members are not required to identify the kind of direct adopter an interviewed organization is, rather they should use their discretion and the guidelines defined in the [FAQs](https://github.com/cncf/toc/blob/main/FAQ.md#what-is-the-definition-of-an-adopter) for selected organizations to be interviewed and the nature of the interview as it assists projects.
* TOC members are not required to identify the kind of direct adopter an interviewed organization is, rather they should use their discretion and the guidelines defined in the [FAQs](https://github.com/cncf/toc/blob/main/FAQ.md#what-is-the-definition-of-an-adopter) for selected organizations to be interviewed and the nature of the interview as it best assists projects, this may include conducting a combined interview of direct and transitive adopters to ascertain maturity and interaction.
* TOC Incubation Sponsor confirms that project meets the [Incubation requirements](https://github.com/cncf/toc/blob/main/process/graduation_criteria.md#incubating-stage).
* TOC Incubation Sponsor determines when DD is “done”. DD documentation should then be on GitHub, open to public comment on record.
. *Due Diligence review* _2-6 weeks_