mirror of https://github.com/cncf/toc.git
Merge pull request #1441 from angellk/angellk-dtr-1
What: Formalize Domain Technical Review (DTR) process
This commit is contained in:
Emily Fox
GitHub
commit
58e96d0eb8
|
|
@ -35,7 +35,8 @@ N/A
|
|||
|
||||
### Required
|
||||
|
||||
- [ ] **Give a presentation and engage with the domain specific TAG(s) to increase awareness**
|
||||
- [ ] **Engage with the domain specific TAG(s) to increase awareness through a presentation or completing a General Technical Review.**
|
||||
- This was completed and occurred on DD-MMM-YYYY, and can be discovered at $LINK.
|
||||
|
||||
<!-- (Project assertion goes here) -->
|
||||
|
||||
|
|
@ -169,11 +170,13 @@ Note: this section may be augmented by the completion of a Governance Review fro
|
|||
|
||||
## Engineering Principles
|
||||
|
||||
- [ ] **Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently.**
|
||||
- [ ] **Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. *This requirement may also be satisfied by completing a General Technical Review.***
|
||||
- A General Technical Review was completed/updated on DD-MMM-YYYY, and can be discovered at $LINK.
|
||||
|
||||
<!-- (Project assertion goes here) -->
|
||||
|
||||
- [ ] **Document what the project does, and why it does it - including viable cloud native use cases.**
|
||||
- [ ] **Document what the project does, and why it does it - including viable cloud native use cases. *This requirement may also be satisfied by completing a General Technical Review.***
|
||||
- A General Technical Review was completed/updated on DD-MMM-YYYY, and can be discovered at $LINK.
|
||||
|
||||
<!-- (Project assertion goes here) -->
|
||||
|
||||
|
|
@ -185,7 +188,8 @@ Note: this section may be augmented by the completion of a Governance Review fro
|
|||
|
||||
<!-- (Project assertion goes here) -->
|
||||
|
||||
- [ ] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.**
|
||||
- [ ] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. *This requirement may also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.***
|
||||
- A General Technical Review was completed/updated on DD-MMM-YYYY, and can be discovered at $LINK.
|
||||
|
||||
<!-- (Project assertion goes here) -->
|
||||
|
||||
|
|
@ -206,7 +210,7 @@ Note: this section may be augmented by the completion of a Governance Review fro
|
|||
|
||||
## Security
|
||||
|
||||
Note: this section may be augemented by a joint-assessment performed by TAG Security.
|
||||
Note: this section may be augmented by a joint-assessment performed by TAG Security.
|
||||
|
||||
### Suggested
|
||||
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ N/A
|
|||
|
||||
### Required
|
||||
|
||||
- [ ] **Give a presentation and engage with the domain specific TAG(s) to increase awareness**
|
||||
- [ ] **Engage with the domain specific TAG(s) to increase awareness through a presentation or completing a General Technical Review.**
|
||||
- This was completed and occurred on DD-MMM-YYYY, and can be discovered at $LINK.
|
||||
|
||||
<!-- (Project assertion goes here) -->
|
||||
|
|
@ -177,11 +177,11 @@ Note: this section may be augmented by the completion of a Governance Review fro
|
|||
|
||||
### Required
|
||||
|
||||
- [ ] **Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently.**
|
||||
- [ ] **Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. This can also be satisfied by completing a General Technical Review.**
|
||||
|
||||
<!-- (Project assertion goes here) -->
|
||||
|
||||
- [ ] **Document what the project does, and why it does it - including viable cloud native use cases.**
|
||||
- [ ] **Document what the project does, and why it does it - including viable cloud native use cases. This can also be satisfied by completing a General Technical Review.**
|
||||
|
||||
<!-- (Project assertion goes here) -->
|
||||
|
||||
|
|
@ -189,7 +189,7 @@ Note: this section may be augmented by the completion of a Governance Review fro
|
|||
|
||||
<!-- (Project assertion goes here) -->
|
||||
|
||||
- [ ] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.**
|
||||
- [ ] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. This can also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.**
|
||||
|
||||
<!-- (Project assertion goes here) -->
|
||||
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
|
||||
# CNCF Technical Advisory Groups ("TAGs")
|
||||
|
||||
<!-- Primary Authors: Alexis Richardson, Quinton Hoole
|
||||
|
||||
with contributions by TOC Contributors, November 2018 - January 2019
|
||||
|
||||
v1.0
|
||||
v1.1
|
||||
|
||||
Starting an update and revisit of the TAG folder, files and document content - Dec 2023 >
|
||||
-->
|
||||
v1.1
|
||||
## Introduction
|
||||
|
||||
The purpose of this document is to provide insight into the objectives and life cycle of Technical Advisory Groups (TAGs) within the CNCF. Various TAGs exist, each within in the CNCF. More information about each TAG can found on the [TAG List](cncf-tags.md) and by following the links to the TAG's respective repositories.
|
||||
|
|
@ -40,9 +40,26 @@ CNCF TAGs are modelled on Kubernetes SIGs. Differences are intended to be minim
|
|||
|
||||
## Responsibilities & Empowerment of TAGs
|
||||
|
||||
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".
|
||||
CNCF TAGs should, under guidance from the TOC, provide high-quality technical expertise, unbiased information and proactive leadership within their domain. 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.
|
||||
|
||||
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 due diligence investigation](https://github.com/cncf/toc/blob/main/process#due-diligence-creation-or-refresh)”, 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.
|
||||
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".
|
||||
|
||||
### Project Engagement
|
||||
|
||||
Projects themselves may engage with the TAGs:
|
||||
|
||||
* when exploring engagement within the cloud native ecosystem
|
||||
* prior to submitting their application for CNCF consideration
|
||||
* after submitting their application for CNCF consideration
|
||||
* for guidance in moving levels within the CNCF
|
||||
* upon direction by the CNCF Technical Oversight Committee (TOC) or Linux Foundation staff
|
||||
|
||||
Project engagement within the Cloud Native ecosystem is a vital way to raise project visibility as well as gain insights from technical leaders in the CNCF community for project maintainers.
|
||||
|
||||
As the Technical Advisory Groups (TAGs) are an entry point for many projects to engage with the Cloud Native ecosystem, TAGs are encouraged to guide projects to join the TAGs, Working Groups, collaborate with other projects for development of specifications or promote interoperability as well as explore various avenues to further engage with the greater community.
|
||||
|
||||
### Technical Leadership
|
||||
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 ..." or “to approve this landscape document under its clear goals and the 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:
|
||||
|
||||
|
|
@ -55,11 +72,11 @@ TAGs may choose to spawn focused and time-limited working groups to achieve some
|
|||
|
||||
#### Project Handling:
|
||||
|
||||
* Conduct [Domain Technical Reviews](resources/toc-supporting-guides/project-reviews.md) of projects to inform the TOC for Sandbox Review or as requested for projects moving levels (by projects, or by TOC members if deemed beneficial)
|
||||
* Understand and document a high level roadmap of projects within this space, including CNCF and non-CNCF projects. Identify gaps in project landscape.
|
||||
* 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 TAG by the TOC.
|
||||
* Every CNCF project will be assigned to at least one suitable TAG by the TOC.
|
||||
|
||||
#### End User Education (Outbound Communication)
|
||||
|
||||
|
|
@ -79,7 +96,7 @@ TAGs may choose to spawn focused and time-limited working groups to achieve some
|
|||
|
||||
#### As Trusted Expert Advisors to the TOC
|
||||
|
||||
* Perform technical due diligence on new and graduating projects, and advise TOC on findings.
|
||||
* Perform [Domain Technical Reviews](resources/toc-supporting-guides/project-reviews.md) on upcoming Sandbox projects for review as well as projects moving levels as requested by the TOC, following the project reviews guidance.
|
||||
* 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.
|
||||
|
||||
#### TAG Charter:
|
||||
|
|
@ -123,7 +140,7 @@ As a starting point let’s be inspired by CNCF OSS Projects and by K8s SIGs. T
|
|||
#### Working Group Lead
|
||||
* Lead the activities of the working group under the TAG.
|
||||
* Have the domain knowledge to lead the working group.
|
||||
* Approved by supermajority of the chairs and approved by the TAG liaison
|
||||
* Approved by supermajority of the chairs, the TAG liaison, and the TOC liaisons to the TAG.
|
||||
|
||||
#### Other named roles
|
||||
|
||||
|
|
@ -138,7 +155,7 @@ As a starting point let’s be inspired by CNCF OSS Projects and by K8s SIGs. T
|
|||
|
||||
### TOC Liaisons
|
||||
|
||||
TOC is the technical governing body of the CNCF. It’s important that we ensure a good flow of governance information and feedback loops to and from the TAGs. With several TAGs, it can be hard to connect for community wide consensus therefore each group is assigned at least one TOC liaison.
|
||||
TOC is the technical governing body of the CNCF. It’s important that we ensure a good flow of governance information and feedback loops to and from the TAGs. With several TAGs, it can be hard to connect for community wide consensus, therefore, each group is assigned at least one TOC liaison.
|
||||
|
||||
TAG leads may call on liaisons to act as a point of contact from the TOC, be an advisor for governance or community health matters, or help the TAG prioritize what they’re doing to be in line with TOC needs.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,5 +4,7 @@ The TOC has a number of [tasks](https://github.com/cncf/toc/tree/main/process) t
|
|||
This folder contains guides on how TAGs can support the TOC.
|
||||
|
||||
**Guides**:
|
||||
- [Project reviews](project-reviews.md)
|
||||
- [Technical Paper process](tech-papers.md)
|
||||
* [Project Reviews and Engagement](project-reviews.md)
|
||||
* [Domain Technical Review template](tag-domain-technical-review.md)
|
||||
* [General Technical Review questions](general-technical-questions.md)
|
||||
* [Technical Paper process](tech-papers.md)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,188 @@
|
|||
# General Technical Review questions
|
||||
v1.0
|
||||
## Introduction
|
||||
|
||||
The General Technical Review questions can be completed by a project in lieu of a presentation to a Technical Advisory Group (TAG) as well as to satisfy the Engineering Principle requirements of a Sandbox application or Due Dillegence for moving levels.
|
||||
|
||||
The questions are designed to prompt **_design thinking_** for projects that would like to one day be a graduated project.
|
||||
|
||||
The intent is to understand how the project has adopted and aligned with the CNCF maturation levels as well as encourage good design & security best practices.
|
||||
|
||||
|
||||
<!--
|
||||
The General Technical Review questions can be completed by a project team in lieu of a presentation to a Technical Advisory Group (TAG) as well as to satisfy several of the Engineering Principle requirements for applying to CNCF Sandbox as well as applying to move to Incubation and Graduation.
|
||||
|
||||
For the purposes of the general technical review and further domain reviews, the questions are designed to prompt design thinking for ready-for-production projects and architecture. The intent is to understand and validate the cloud native software lifecycle of the project and whether it is in line with the CNCF Maturation process and levels.
|
||||
|
||||
Project maintainers are expected to have designed the project for cloud native use cases and workloads, as well as taking a ‘secure by design and secure by default’ approach that enables adopters and consumers of the project the ability to ‘loosen’ the defaults in a manner that suits their environment, requirements and risk tolerance.
|
||||
|
||||
These questions are to gather knowledge about the project. Project maintainers are expected to answer to the best of their ability. **_Not every question will be addressable by every project._**
|
||||
|
||||
**Suggestion:** A recorded demo or diagram(s) may be easier to convey some of the concepts in the questions below. The project maintainers may provide a link to a recorded demo or add architectural diagrams along with your GTR questionnaire.
|
||||
|
||||
-->
|
||||
|
||||
### General Technical Review questions
|
||||
|
||||
The questions follow the cloud native software lifecycle day schemas:
|
||||
|
||||
**Day 0 - Planning Phase. (Sandbox)** - This phase covers design and architecture of the cloud native project.
|
||||
|
||||
**Day 1 - Installation and Deployment Phase (Incubation)** - This phase covers initial installation and deployment of the design developed during Day 0 - Planning Phase.
|
||||
|
||||
**Day 2 - Day-to-Day Operations Phase (Graduated)** - This phase covers post-deployment operations in production-ready environments to include monitoring, maintenance, auditing and troubleshooting.
|
||||
|
||||
|
||||
### How to use this template
|
||||
|
||||
Make a copy of the template below and answer questions related to your project level to the best of your ability.
|
||||
_**Not every question will be addressable or relevant to every project.**_
|
||||
If this is the case for your project, please mark it as not-applicable (N/A) and provide a brief explanation.
|
||||
|
||||
**NOTE:** The questions are cumulative e.g. if you are applying for incubation or graduation, you should answer both day 0 and day 1 questions etc.
|
||||
|
||||
#### Tips
|
||||
|
||||
* Treat the GTR questionnaire as a living document and keep a copy of it in your project's own repo. The GTR questions are helpful to both contributors and users and will make updating it in the future less work when you want to apply to move levels.
|
||||
* Answer more questions than the requirement for your level if it _makes sense for your project_. e.g. if you have documentaiton covering the different forms of observability in the Day-2 requirements.
|
||||
* You **CAN** link out to your own project's documentation, but be sure to link to it in a _versioned_ form. e.g. link to it at a specific commit instead of the `main` branch, or versioned website.
|
||||
* A recorded demo or diagram(s) may be easier to convey some of the concepts in the questions below. You may provide a link to a recorded demo or add architectural diagrams along with your GTR questionnaire.
|
||||
* If you are unsure or have a question about any section below, **please ask**. Chances are you're not the only one with a question and the template should be updated with additional guidance.
|
||||
|
||||
---
|
||||
|
||||
# General Technical Review - [Project Name] / [Level]
|
||||
|
||||
- **Project:**
|
||||
- **Project Version:**
|
||||
- **Website:**
|
||||
- **Date Updated:** YYYY-MM-DD
|
||||
- **Template Version:** v1.0
|
||||
- **Description:** <!-- Short project description -->
|
||||
|
||||
|
||||
|
||||
## Day 0 - Planning Phase
|
||||
|
||||
### Scope
|
||||
|
||||
* Describe the roadmap process, how scope is determined for mid to long term features, as well as how the roadmap maps back to current contributions and maintainer ladder?
|
||||
* Describe the target persona or user(s) for the project?
|
||||
* Explain the primary use case for the project. What additional use cases are supported by the project?
|
||||
* Explain which use cases have been identified as unsupported by the project.
|
||||
* Describe the intended types of organizations who would benefit from adopting this project. (i.e. financial services, any software manufacturer, organizations providing platform engineering services)?
|
||||
* Please describe any completed end user research and link to any reports.
|
||||
|
||||
### Usability
|
||||
|
||||
* How should the target personas interact with your project?
|
||||
* Describe the user experience (UX) and user interface (UI) of the project.
|
||||
* Describe how this project integrates with other projects in a production environment.
|
||||
|
||||
### Design
|
||||
|
||||
* Explain the design principles and best practices the project is following.
|
||||
* Outline or link to the project’s architecture requirements? Describe how they differ for Proof of Concept, Development, Test and Production environments, as applicable.
|
||||
* Define any specific service dependencies the project relies on in the cluster.
|
||||
* Describe how the project implements Identity and Access Management.
|
||||
* Describe how the project has addressed sovereignty.
|
||||
* Describe any compliance requirements addressed by the project.
|
||||
* Describe the project’s High Availability requirements.
|
||||
* Describe the project’s resource requirements, including CPU, Network and Memory.
|
||||
* Describe the project’s storage requirements, including its use of ephemeral and/or persistent storage.
|
||||
* Please outline the project’s API Design:
|
||||
* Describe the project’s API topology and conventions
|
||||
* Describe the project defaults
|
||||
* Outline any additional configurations from default to make reasonable use of the project
|
||||
* Describe any new or changed API types and calls \- including to cloud providers \- that will result from this project being enabled and used
|
||||
* Describe compatibility of any new or changed APIs with API servers, including the Kubernetes API server
|
||||
* Describe versioning of any new or changed APIs, including how breaking changes are handled
|
||||
* Describe the project’s release processes, including major, minor and patch releases.
|
||||
|
||||
### Installation
|
||||
|
||||
* Describe how the project is installed and initialized, e.g. a minimal install with a few lines of code or does it require more complex integration and configuration?
|
||||
* How does an adopter test and validate the installation?
|
||||
|
||||
### Security
|
||||
|
||||
* Please provide a link to the project’s cloud native [security self assessment](https://tag-security.cncf.io/community/assessments/).
|
||||
* Please review the [Cloud Native Security Tenets](https://github.com/cncf/tag-security/blob/main/security-whitepaper/secure-defaults-cloud-native-8.md) from TAG Security.
|
||||
* How are you satisfying the tenets of cloud native security projects?
|
||||
* Describe how each of the cloud native principles apply to your project.
|
||||
* How do you recommend users alter security defaults in order to "loosen" the security of the project? Please link to any documentation the project has written concerning these use cases.
|
||||
* Security Hygiene
|
||||
* Please describe the frameworks, practices and procedures the project uses to maintain the basic health and security of the project.
|
||||
* Describe how the project has evaluated which features will be a security risk to users if they are not maintained by the project?
|
||||
* Cloud Native Threat Modeling
|
||||
* Explain the least minimal privileges required by the project and reasons for additional privileges.
|
||||
* Describe how the project is handling certificate rotation and mitigates any issues with certificates.
|
||||
* Describe how the project is following and implementing [secure software supply chain best practices](https://project.linuxfoundation.org/hubfs/CNCF\_SSCP\_v1.pdf)
|
||||
|
||||
## Day 1 \- Installation and Deployment Phase
|
||||
|
||||
### Project Installation and Configuration
|
||||
|
||||
* Describe what project installation and configuration look like.
|
||||
|
||||
### Project Enablement and Rollback
|
||||
|
||||
* How can this project be enabled or disabled in a live cluster? Please describe any downtime required of the control plane or nodes.
|
||||
* Describe how enabling the project changes any default behavior of the cluster or running workloads.
|
||||
* Describe how the project tests enablement and disablement.
|
||||
* How does the project clean up any resources created, including CRDs?
|
||||
|
||||
### Rollout, Upgrade and Rollback Planning
|
||||
|
||||
* How does the project intend to provide and maintain compatibility with infrastructure and orchestration management tools like Kubernetes and with what frequency?
|
||||
* Describe how the project handles rollback procedures.
|
||||
* How can a rollout or rollback fail? Describe any impact to already running workloads.
|
||||
* Describe any specific metrics that should inform a rollback.
|
||||
* Explain how upgrades and rollbacks were tested and how the upgrade-\>downgrade-\>upgrade path was tested.
|
||||
* Explain how the project informs users of deprecations and removals of features and APIs.
|
||||
* Explain how the project permits utilization of alpha and beta capabilities as part of a rollout.
|
||||
|
||||
## Day 2 \- Day-to-Day Operations Phase
|
||||
|
||||
### Scalability/Reliability
|
||||
|
||||
* Describe how the project increases the size or count of existing API objects.
|
||||
* Describe how the project defines Service Level Objectives (SLOs) and Service Level Indicators (SLIs).
|
||||
* Describe any operations that will increase in time covered by existing SLIs/SLOs.
|
||||
* Describe the increase in resource usage in any components as a result of enabling this project, to include CPU, Memory, Storage, Throughput.
|
||||
* Describe which conditions enabling / using this project would result in resource exhaustion of some node resources (PIDs, sockets, inodes, etc.)
|
||||
* Describe the load testing that has been performed on the project and the results.
|
||||
* Describe the recommended limits of users, requests, system resources, etc. and how they were obtained.
|
||||
* Describe which resilience pattern the project uses and how, including the circuit breaker pattern.
|
||||
|
||||
### Observability Requirements
|
||||
|
||||
* Describe the signals the project is using or producing, including logs, metrics, profiles and traces. Please include supported formats, recommended configurations and data storage.
|
||||
* Describe how the project captures audit logging.
|
||||
* Describe any dashboards the project uses or implements as well as any dashboard requirements.
|
||||
* Describe how the project surfaces project resource requirements for adopters to monitor cloud and infrastructure costs, e.g. FinOps
|
||||
* Which parameters is the project covering to ensure the health of the application/service and its workloads?
|
||||
* How can an operator determine if the project is in use by workloads?
|
||||
* How can someone using this project know that it is working for their instance?
|
||||
* Describe the SLOs (Service Level Objectives) for this project.
|
||||
* What are the SLIs (Service Level Indicators) an operator can use to determine the health of the service?
|
||||
|
||||
### Dependencies
|
||||
|
||||
* Describe the specific running services the project depends on in the cluster.
|
||||
* Describe the project’s dependency lifecycle policy.
|
||||
* How does the project incorporate and consider source composition analysis as part of its development and security hygiene? Describe how this source composition analysis (SCA) is tracked.
|
||||
* Describe how the project implements changes based on source composition analysis (SCA) and the timescale.
|
||||
|
||||
### Troubleshooting
|
||||
|
||||
* How does this project recover if a key component or feature becomes unavailable? e.g Kubernetes API server, etcd, database, leader node, etc.
|
||||
* Describe the known failure modes.
|
||||
|
||||
### Security
|
||||
|
||||
* Security Hygiene
|
||||
* How is the project executing access control?
|
||||
* Cloud Native Threat Modeling
|
||||
* How does the project ensure its security reporting and response team is representative of its community diversity (organizational and individual)?
|
||||
* How does the project invite and rotate security reporting team members?
|
||||
|
|
@ -1,3 +1,112 @@
|
|||
# How TAGs help with project reviews
|
||||
# TAG Project Reviews
|
||||
|
||||
v1.0
|
||||
|
||||
CNCF Technical Advisory Groups (TAGs) help with Project Reviews for new projects interested in joining the CNCF, as well as projects moving between maturity levels.
|
||||
|
||||
## Project Reviews
|
||||
|
||||
To assist in evaluating projects applying to enter or moving levels within the CNCF, projects are encouraged to do one of the following:
|
||||
- Present an overview and demo of the project to the CNCF (TAGs) or TAG Working Group(s) that their project aligns with.
|
||||
|
||||
**or**
|
||||
|
||||
- Complete the [General Technical Review][gtrq] (GTR) questions and open a PR to the project's directory in the TOC repo for the TAG and/or TOC to review instead of scheduling a project presentation.
|
||||
|
||||
_**Suggestion:** The GTR questions may be kept in the project's GitHub organization as a living document and updated as needed. When applying to move levels, a PR with a copy of the GTR can then be opened to record the project's state at that point-in-time._
|
||||
|
||||
|
||||
#### What to do if multiple TAGs are suggested
|
||||
|
||||
At times, project maintainers will be encouraged to interact with multiple TAGs, Working Groups and/or Kubernetes SIGs. In these instances, the project may complete the GTR questions and request reviews from the different groups or work with TAG leadership to coordinate a shared project presentation to present to all requested parties.
|
||||
|
||||
### Scheduling
|
||||
|
||||
TAG leadership should proactively reach out to the project maintainers to schedule a project presentation, if warranted.
|
||||
|
||||
If a project review issue is created in the TAG repo the expectation is that the TAG will assign someone to the issue as well as find a suitable time for the project to present.
|
||||
The TAG may suggest the project complete the [General Technical Review questions][gtrq] if the TAG does not have availability within 60 days.
|
||||
|
||||
## Presentation Guidance
|
||||
|
||||
Project maintainers interested in applying to join the CNCF - or move levels within the CNCF - should be prepared with slides or the General Technical Review questions and a short demo, while also reserving time for community engagement.
|
||||
|
||||
Project maintainers may ask the TAG leadership for additional time. Projects may also record the presentation and demo separately for async discussion with the TAG if there are timezone and/or TAG resource conflicts. The presentation and demo should then be shared on the Project's application, if applicable.
|
||||
|
||||
#### Suggested Presentation Timing Guidance
|
||||
|
||||
Please see the table below for timing guidance.
|
||||
|
||||
| Application Level | Presentation + Short Demo Time | TAG Questions and Discussion |
|
||||
| -------- | -------- | -------- |
|
||||
| Sandbox | 20 Minutes | 10 Minutes |
|
||||
| Incubation | 40 Minutes | 15 Minutes |
|
||||
| Graduation | 40 Minutes | 15 Minutes |
|
||||
|
||||
### Presentation Agenda
|
||||
|
||||
The presentation being delivered to the TAG should be focused on technical specifics using the [General Technical Review questions][gtrq] as the basis.
|
||||
The General Technical Review questions follow the cloud native software lifecycle day schemas and the TAG may ask for additional questions to be answered for the project presentation. *Please see the [GTR questions][gtrq] for more information.*
|
||||
|
||||
Please see the table below for questions that should be addressed per level to satisfy the Sandbox, Incubation and Graduation TAG presentation requirements as well as the Incubation and Graduation engineering principles requirements.
|
||||
|
||||
**REMINDER:** Not all questions are relevant to all projects.
|
||||
It's fully expected that projects will mark some as not-applicable.
|
||||
|
||||
| General Technical Review Questions | Sandbox | Incubation | Graduation |
|
||||
| -------- | -------- | -------- | -------- |
|
||||
| Day 0 - Scope | required | required | required |
|
||||
| Day 0 - Usability | required | required | required |
|
||||
| Day 0 - Design | required | required | required |
|
||||
| Day 0 - Installation | required | required | required |
|
||||
| Day 0 - Security | required | required | required |
|
||||
| Day 1 - Project Configuration and Activation | optional | required | required |
|
||||
| Day 1 - Project Enablement and Rollback | optional | required | required |
|
||||
| Day 1 - Rollout, Upgrade and Rollback Planning | optional | required | required |
|
||||
| Day 2 - Scalability/Reliability | optional | required | required |
|
||||
| Day 2 - Observability | optional | required | required |
|
||||
| Day 2 - Dependencies | optional | required | required |
|
||||
| Day 2 - Troubleshooting | optional | required | required |
|
||||
| Day 2 - Security | optional | required | required |
|
||||
|
||||
## Domain Technical Review
|
||||
|
||||
After the project has completed a presentation to the TAG, or completed the General Technical Review questions, the assigned TAG lead should complete a domain technical review.
|
||||
|
||||
Sandbox Project Review Assignments: https://github.com/orgs/cncf/projects/14/views/5
|
||||
|
||||
Incubation and Graduation Project Review Assignments: tbd
|
||||
|
||||
### Who should conduct project reviews?
|
||||
|
||||
A TAG or WG lead can either self-assign or be assigned by the TOC to conduct a project review.
|
||||
They **MAY** delegate the review to a community member with domain expertise.
|
||||
|
||||
### How long should a review take?
|
||||
|
||||
It should take no longer than an hour to complete a review.
|
||||
The review should be a brief synopsis of the project that captures key highlights as well as any **glaring** gaps that the project may have.
|
||||
|
||||
### When are domain project reviews requested?
|
||||
|
||||
A TAG domain project review should be completed when:
|
||||
* Sandbox projects in the upcoming queue for TOC Sandbox Review
|
||||
* when the TOC requests a domain technical review of a project applying for Incubation or Graduation
|
||||
|
||||
### What is needed to complete a review
|
||||
|
||||
The TAG member assigned to complete the domain technical review references:
|
||||
* the [original General Technical Review questions][gtrq]
|
||||
* the project's presentation or the completed GTR questions
|
||||
* the [TAG Domain Technical Review template](tag-domain-technical-review-template.md)
|
||||
* TAG Security [self or joint assessment](https://tag-security.cncf.io/community/assessments/) (if applicable)
|
||||
|
||||
### Where is a review submitted?
|
||||
|
||||
The TAG project reviewer should submit the review as a comment on the project's application.
|
||||
If the project is in the upcoming queue when applying for Sandbox, the TAG is requested to submit a review no later than two (2) weeks to allow for TOC review/clarification and to allow projects time to respond.
|
||||
|
||||
|
||||
|
||||
[gtrq]: general-technical-questions.md
|
||||
|
||||
*tbd* - contributions are welcome!
|
||||
|
|
|
|||
|
|
@ -0,0 +1,86 @@
|
|||
# $PROJECT Domain Technical Review
|
||||
|
||||
v1.0
|
||||
|
||||
**Info:** The Domain Technical Review template follows the [General Technical Review questions][gtrq] from the context of the reviewing Technical Advisory Group (TAG) domain. A project may be requested to have multiple domain reviews. For more information, please review [How TAGs Help with Project Reviews and Engagement][pr].
|
||||
|
||||
**Depending on CNCF maturity application level, not every section may be answered by the reviewing TAG and the TAG review should take no more than an hour of a reviewer's time to complete.**
|
||||
|
||||
[gtrq]: general-technical-questions.md
|
||||
[pr]: project-reviews.md
|
||||
|
||||
---
|
||||
|
||||
**Project Application Level:** Sandbox/Incubation/Graduation
|
||||
|
||||
**Reviewing TAG:**
|
||||
|
||||
**TAG Reviewer(s):**
|
||||
|
||||
**Review Materials:** <presentation to TAG or General Technical Review questionnaire>
|
||||
|
||||
**Review Materials URL:**
|
||||
|
||||
**Review Materials Date:** DD-MMM-YYYY
|
||||
|
||||
|
||||
## Community and Growth
|
||||
|
||||
*Please refer to the TAG Contributor Strategy summary on the project issue. If there are additional considerations TAG Contributor Strategy is not aware of, please include those here.*
|
||||
|
||||
|
||||
<!-- (TAG assertion goes here) -->
|
||||
|
||||
## Day 0 Assessment - Planning Phase
|
||||
|
||||
*Please include key highlights of the project’s scope, usability, design, installation and security.*
|
||||
* _What gap(s) in the ecosystem does this project fulfill?_
|
||||
* _What, if anything, could make this project better?_
|
||||
* _Are there any glaring gaps in the design process that the project should consider reviewing?_
|
||||
|
||||
|
||||
<!-- (TAG assertion goes here) -->
|
||||
|
||||
|
||||
## Day 1 Assessment - Installation and Deployment Phase
|
||||
|
||||
Please include key highlights of the project’s installation and deployment:
|
||||
* _Has this project considered what the project’s installation and configuration looks like?_
|
||||
* _Has the project thought through enablement, rollback, rollout and upgrade planning?_
|
||||
* _Are there any gaps the project’s maintainers should consider to make this project more production ready?_
|
||||
|
||||
<!-- (TAG assertion goes here) -->
|
||||
|
||||
## Day 2 Assessment - Operations Phase
|
||||
|
||||
*Please include key highlights of the project’s day-to-day operations:*
|
||||
* _Has this project considered adopter scalability and reliability requirements?_
|
||||
* _Has this project considered how adopters should observe project resources and workloads?_
|
||||
* _Has this project thought through dependencies and lifecycle policies or how to troubleshoot any component failures?_
|
||||
* _Are there any gaps the project should consider?_
|
||||
|
||||
<!-- (TAG assertion goes here) -->
|
||||
|
||||
## Cloud Native Summary
|
||||
|
||||
*Please include key current collaboration as well as potential collaboration opportunities in the cloud native ecosystem, including: TAGs, Working Groups, Kubernetes SIGs, other CNCF projects, and other Foundation projects.*
|
||||
|
||||
<!-- (TAG assertion goes here) -->
|
||||
|
||||
# TAG Recommendations
|
||||
|
||||
## TAG Recommendation to $Project
|
||||
|
||||
*Please include steps the project is recommended to take from the TAG’s review of the presentation or General Technical Review questions. Include any gaps or areas of concern along with brief recommendations on how to overcome them.*
|
||||
|
||||
<!-- (TAG assertion goes here) -->
|
||||
|
||||
## TAG Recommendation to TOC
|
||||
|
||||
**Recommendation:** yes/no
|
||||
|
||||
**Summary:**
|
||||
*Please briefly outline why or why not the TAG leads recommend this project to be admitted to CNCF Sandbox or move levels within the CNCF.*
|
||||
|
||||
<!-- (TAG assertion goes here) -->
|
||||
|
||||
Loading…
Reference in New Issue