| name | about | title | labels |
|---|---|---|---|
Project Incubation Application |
This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria. |
[Incubation] $PROJECT Incubation Application |
incubation |
v1.5 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
The project has been adopted by the following organizations in a testing and integration or production capacity: *
N/A
- Give a presentation and engage with the domain specific TAG(s) to increase awareness
- This was completed and occurred on DD-MMM-YYYY, and can be discovered at $LINK.
- TAG provides insight/recommendation of the project in the context of the landscape
- All project metadata and resources are vendor-neutral.
- Review and acknowledgement of expectations for Sandbox 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 satisifies 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.
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
- Clear and discoverable project governance documentation.
- 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.
- Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.
- Governance clearly documents 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.
- 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 agreement that project will adopt CNCF Code of Conduct.
- CNCF Code of Conduct is cross-linked from other governance documents.
- All subprojects, if any, are listed.
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
- Contributor ladder with multiple roles for contributors.
- 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.
- Roadmap change process is documented.
- History of regular, quality releases.
- 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 what the project does, and why it does it - including viable cloud native use cases.
- 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.
- Document the project's release process.
Note: this section may be augemented by a joint-assessment performed by TAG Security.
N/A
- 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.
- Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.
N/A
- 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.