Skip to main content

$PROJECT Incubation Due Diligence

  • Link to Incubation application issue

Incubation Evaluation Summary for $PROJECT​

Criteria Evaluation​

$TOCMEMBER conducted the due diligence of $PROJECT who applied for $LEVEL. The project [has/has not] completed the criteria that show its maturity at $LEVEL. The following criteria implementations are noteworthy to call out... $NOTABLES. The following actions were provided to the project that were considered blocking but since resolved... $BLOCKERS. The following recommendations were provided to the project that are non-blocking in the TOC's assessment but should be completed by the project to ensure continued viability of the project... $RECOMMENDATIONS.

Adoption Evaluation​

The adopter interviews reflect a project [in use/too early] for the level which the project applied. They show ... $INTERVIEWSUMMARY.

Final Assessment​

[The TOC has found the project to have satisfied the criteria for $LEVEL/ The TOC's evaluation of the project shows a needed focus to complete the outstanding blockers and reapply when the following conditions are met ... $CONDITIONS].

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.
    • If applicable this was completed and occurred on DD-MMM-YYYY, and can be discovered at $LINK.
  • 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 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.
  • 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 requirement may 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.
  • 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 requirement may 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 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.
  • 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.

Adoption​

Adopter 1 - $COMPANY/$INDUSTRY​

If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient. MONTH YEAR

Adopter 2 - $COMPANY/$INDUSTRY​

If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient. MONTH YEAR

Adopter 3 - $COMPANY/$INDUSTRY​

If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient. MONTH YEAR