added incubation checklist

Signed-off-by: Tullio Sebastiani <tsebasti@redhat.com>
This commit is contained in:
Tullio Sebastiani
2025-11-24 16:02:15 +01:00
parent 6da7c9dec6
commit 4f44cbb55a

270
INCUBATION_CHECKLIST.md Normal file
View File

@@ -0,0 +1,270 @@
---
name: Project Incubation Application
about: This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria.
title: "[Incubation] $PROJECT Incubation Application"
labels:
- dd/triage/needs-triage
- level/incubation
- kind/dd
- toc
---
# Review Project Moving Level Evaluation
[ ] I have reviewed the TOC's [moving level readiness triage guide](https://github.com/cncf/toc/blob/main/operations/dd-toc-guide.md#initial-triageevaluation-prior-to-assignment), ensured the criteria for my project are met before opening this issue, and understand that unmet criteria will result in the project's application being closed.
# $PROJECT Incubation Application
v1.6
This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria.
Project Repo(s): $URL
Project Site: $URL
Sub-Projects: $LIST
Communication: $SLACK
Project points of contacts: $NAME, $EMAIL
- [ ] (Post Incubation only) [Book a meeting with CNCF staff](http://project-meetings.cncf.io) to understand project benefits and event resources.
## Incubation Criteria Summary for $PROJECT
### Application Level Assertion
- [ ] This project is currently Sandbox, accepted on YYYYMMDD, and applying to Incubation.
- [ ] This project is applying to join the CNCF at the Incubation level.
### Adoption Assertion
_The project has been adopted by the following organizations in a testing and integration or production capacity:_
*
## Application Process Principles
### Suggested
N/A
### Required
- [ ] **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) -->
- [ ] **All project metadata and resources are [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).**
<!-- (Project assertion goes here) -->
- [ ] **Review and acknowledgement of expectations for [Sandbox](https://sandbox.cncf.io) projects and requirements for moving forward through the CNCF Maturity levels.**
- Met during Project's application on DD-MMM-YYYY.
<!-- (Project assertion goes here) -->
- [ ] **Due Diligence Review.**
Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.
- [ ] **Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.**
<!-- (Project assertion goes here) -->
## Governance and Maintainers
Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject.
### Suggested
- [ ] **Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.**
<!-- (Project assertion goes here) -->
- [ ] **Clear and discoverable project governance documentation.**
<!-- (Project assertion goes here) -->
- [ ] **Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.**
<!-- (Project assertion goes here) -->
- [ ] **Governance clearly documents [vendor-neutrality](https://contribute.cncf.io/maintainers/community/vendor-neutrality/) of project direction.**
<!-- (Project assertion goes here) -->
- [ ] **Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.**
<!-- (Project assertion goes here) -->
- [ ] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).**
<!-- (Project assertion goes here) -->
- [ ] **Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).**
<!-- (Project assertion goes here) -->
- [ ] **Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.**
<!-- (Project assertion goes here) -->
- [ ] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.**
<!-- (Project assertion goes here) -->
### Required
- [ ] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.**
<!-- (Project assertion goes here) -->
- [ ] **A number of active maintainers which is appropriate to the size and scope of the project.**
<!-- (Project assertion goes here) -->
- [ ] **Code and Doc ownership in Github and elsewhere matches documented governance roles.**
<!-- (Project assertion goes here) -->
- [ ] **Document adoption and adherence to the CNCF Code of Conduct or the project's CoC which is based off the CNCF CoC and not in conflict with it.**
<!-- (Project assertion goes here) -->
- [ ] **CNCF Code of Conduct is cross-linked from other governance documents.**
<!-- (Project assertion goes here) -->
- [ ] **All subprojects, if any, are listed.**
<!-- (Project assertion goes here) -->
## Contributors and Community
Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject.
### Suggested
- [ ] **Contributor ladder with multiple roles for contributors.**
<!-- (Project assertion goes here) -->
### Required
- [ ] **Clearly defined and discoverable process to submit issues or changes.**
<!-- (Project assertion goes here) -->
- [ ] **Project must have, and document, at least one public communications channel for users and/or contributors.**
<!-- (Project assertion goes here) -->
- [ ] **List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.**
<!-- (Project assertion goes here) -->
- [ ] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.**
<!-- (Project assertion goes here) -->
- [ ] **Documentation of how to contribute, with increasing detail as the project matures.**
<!-- (Project assertion goes here) -->
- [ ] **Demonstrate contributor activity and recruitment.**
<!-- (Project assertion goes here) -->
## Engineering Principles
### Suggested
- [ ] **Roadmap change process is documented.**
<!-- (Project assertion goes here) -->
- [ ] **History of regular, quality releases.**
<!-- (Project assertion goes here) -->
### Required
- [ ] **Document project goals and objectives that illustrate the projects 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._**
- _If applicable_ 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. This can also be satisfied by completing a General Technical Review.**
<!-- (Project assertion goes here) -->
- [ ] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.**
<!-- (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. _This can also be satisfied by completing a General Technical Review and capturing the output in the project's documentation._**
- _If applicable_ a General Technical Review was completed/updated on DD-MMM-YYYY, and can be discovered at $LINK.
<!-- (Project assertion goes here) -->
- [ ] **Document the project's release process.**
<!-- (Project assertion goes here) -->
## Security
### Suggested
N/A
### Required
Note: this section may be augmented by a joint-assessment performed by TAG Security and Compliance.
- [ ] **Clearly defined and discoverable process to report security issues.**
<!-- (Project assertion goes here) -->
- [ ] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)**
<!-- (Project assertion goes here) -->
- [ ] **Document assignment of security response roles and how reports are handled.**
<!-- (Project assertion goes here) -->
- [ ] **Document [Security Self-Assessment](https://tag-security.cncf.io/community/assessments/guide/self-assessment/).**
<!-- (Project assertion goes here) -->
- [ ] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.**
<!-- (Project assertion goes here) -->
## Ecosystem
### Suggested
N/A
### Required
- [ ] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)**
<!-- (Project assertion goes here) -->
- [ ] **Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)**
<!-- (Project assertion goes here) -->
The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation.
- [ ] **TOC verification of adopters.**
<!-- (Project assertion goes here) -->
Refer to the Adoption portion of this document.
- [ ] **Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.**
<!-- (Project assertion goes here) -->
## Additional Information
<!-- Provide any additional information you feel is relevant for the TOC in conducting due diligence on this project. -->