Created
December 5, 2023 20:36
-
-
Save castrojo/0dc60e6f73a6d49302e2f24a38cdd817 to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Due Diligence Template | |
This template provides the TOC with the outline for completing due diligence of a project to move levels. This universal template is designed to capture all criteria so the TOC may ensure prior level criteria do not regress. As part of completing the due diligence, the TOC member should update the template to convey the level the project applied for the criteria by bolding the level indicated where the criteria is relevant. | |
For example, a graduation level evalution of this criteria would appear like: | |
**Give a presentation and engage with the domain specific TAG(s) to increase awareness** | |
* Sandbox - Suggested | |
## $LEVEL 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]._ | |
### Criteria | |
--- | |
### Application Process Principles | |
#### Suggested | |
- [ ] **Give a presentation and engage with the domain specific TAG(s) to increase awareness** | |
- [ ] Completed on DD-MMM-YYYY via $LINK | |
- [ ] **TAG provides insight/recommendation of the project in the context of the landscape** | |
- [ ] (Evaluation goes here in a GitHub Form) | |
- [ ] **All project metadata and resources are [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).** | |
- [ ] (Evaluation goes here in a GitHub Form) | |
#### Required | |
- [ ] **Review and acknowledgement of expectations for [Sandbox](sandbox.cncf.io) projects and requirements for moving forward through the CNCF Maturity levels.** | |
- [ ] Met during Project's application on DD-MMM-YYYY. | |
### Governance and Maintainers | |
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy. | |
#### Suggested | |
- [ ] **Clear and discoverable project governance documentation.** | |
- [ ] (Evaluation goes here in a GitHub Form) | |
- [ ] **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.** | |
- [ ] (Evaluation goes here in a GitHub Form) | |
- [ ] - **Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.** | |
- [ ] (Evaluation goes here in a GitHub Form) | |
- [ ] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee). | |
- [ ] (Evaluation goes here in a GitHub Form) | |
- [ ] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** | |
- [ ] (Evaluation goes here in a GitHub Form) | |
- [ ] **A number of active maintainers which is appropriate to the size and scope of the project.** | |
- [ ] (Evaluation goes here in a GitHub Form) | |
- [ ] **All subprojects, if any, are listed.** | |
- [ ] (Evaluation goes here in a GitHub Form) | |
#### Required | |
- [ ] **Document agreement that project will adopt CNCF Code of Conduct.** | |
- [ ] $LINK to project CoC | |
### Contributors and Community | |
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy. | |
#### Suggested | |
- [ ] **Project must have, and document, at least one public communications channel for users and/or contributors.** | |
- [ ] (Evaluation goes here in a GitHub Form) | |
- [ ] **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.** | |
- [ ] (Evaluation goes here in a GitHub Form) | |
- [ ] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.** | |
- [ ] (Evaluation goes here in a GitHub Form) | |
- [ ] **Documentation of how to contribute, with increasing detail as the project matures.** | |
- [ ] (Evaluation goes here in a GitHub Form) | |
### Engineering Principles | |
#### Suggested | |
- [ ] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.** | |
- [ ] (Evaluation goes here in a GitHub Form) | |
- [ ] **Document the project's release process.** | |
- [ ] (Evaluation goes here in a GitHub Form) | |
#### 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.** | |
- [ ] (Evaluation goes here in a GitHub Form) | |
- [ ] **Document what the project does, and why it does it - including viable cloud native use cases.** | |
- [ ] (Evaluation goes here in a GitHub Form) | |
### Security | |
Note: this section may be augemented by a joint-assessment performed by TAG Security. | |
#### Suggested | |
- [ ] **Document assignment of security response roles and how reports are handled.** | |
- [ ] (Evaluation goes here in a GitHub Form) | |
- [ ] **Document Security Self-Assessment.** | |
- [ ] (Evaluation goes here in a GitHub Form) | |
#### Required | |
- [ ] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)** | |
- [ ] (Evaluation goes here in a GitHub Form) | |
#### 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 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment