diff --git a/INCUBATION_CHECKLIST.md b/INCUBATION_CHECKLIST.md new file mode 100644 index 00000000..148fa881 --- /dev/null +++ b/INCUBATION_CHECKLIST.md @@ -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. + + + +- [ ] **All project metadata and resources are [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).** + + + +- [ ] **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. + + + +- [ ] **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.** + + + +## 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.** + + + +- [ ] **Clear and discoverable project governance documentation.** + + + +- [ ] **Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.** + + + +- [ ] **Governance clearly documents [vendor-neutrality](https://contribute.cncf.io/maintainers/community/vendor-neutrality/) of project direction.** + + + +- [ ] **Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.** + + + +- [ ] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).** + + + +- [ ] **Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).** + + + +- [ ] **Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.** + + + +- [ ] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.** + + + +### Required + +- [ ] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** + + + +- [ ] **A number of active maintainers which is appropriate to the size and scope of the project.** + + + +- [ ] **Code and Doc ownership in Github and elsewhere matches documented governance roles.** + + + +- [ ] **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.** + + + +- [ ] **CNCF Code of Conduct is cross-linked from other governance documents.** + + + +- [ ] **All subprojects, if any, are listed.** + + + +## 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.** + + + +### Required + +- [ ] **Clearly defined and discoverable process to submit issues or changes.** + + + +- [ ] **Project must have, and document, at least one public communications channel for users and/or contributors.** + + + +- [ ] **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.** + + + +- [ ] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.** + + + +- [ ] **Documentation of how to contribute, with increasing detail as the project matures.** + + + +- [ ] **Demonstrate contributor activity and recruitment.** + + + +## Engineering Principles + +### Suggested + +- [ ] **Roadmap change process is documented.** + + + +- [ ] **History of regular, quality releases.** + + + +### 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. _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. + + + +- [ ] **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.** + + + +- [ ] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.** + + + +- [ ] **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. + + + +- [ ] **Document the project's release process.** + + + +## 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.** + + + +- [ ] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)** + + + +- [ ] **Document assignment of security response roles and how reports are handled.** + + + +- [ ] **Document [Security Self-Assessment](https://tag-security.cncf.io/community/assessments/guide/self-assessment/).** + + + +- [ ] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.** + + + +## Ecosystem + +### Suggested + +N/A + +### Required + +- [ ] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)** + + + +- [ ] **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)** + + + +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.** + + + +Refer to the Adoption portion of this document. + +- [ ] **Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.** + + + +## Additional Information + + \ No newline at end of file