diff --git a/.github/ISSUE_TEMPLATE/template-graduation-application.md b/.github/ISSUE_TEMPLATE/template-graduation-application.md new file mode 100644 index 000000000..cb5832083 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/template-graduation-application.md @@ -0,0 +1,272 @@ +# $PROJECT Graduation Application +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 + +## Graduation Criteria Summary for $PROJECT + +### Adoption Assertion + +_The project has been adopted by the following organizations in a testing and integration or production capacity:_ + +### Criteria + +## Application Process Principles + +### Suggested + +N/A + +### Required + +- [ ] **Give a presentation and engage with the domain specific TAG(s) to increase awareness** + + + +- [ ] **TAG provides insight/recommendation of the project in the context of the landscape** + + + +- [ ] **All project metadata and resources are [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).** + + + +- [ ] **Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.** + - [ ] Met during Project's application on DD-MMM-YYYY. + + + +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.** + + + +## Governance and Maintainers + +Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy. + +### 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.** + + + +### Required + +- [ ] **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 roles, 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 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.** + + + +- [ ] **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.** + + + +- [ ] **Project maintainers from at least 2 organizations that demonstrates survivability.** + + + +- [ ] **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.** + + + +- [ ] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.** + + + +## Contributors and Community + +Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy. + +### 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 + +- [ ] **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.** + + + +- [ ] **Roadmap change process is documented.** + + + +- [ ] **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.** + + + +- [ ] **History of regular, quality releases.** + + + +## Security + +Note: this section may be augemented by a joint-assessment performed by TAG Security. + +### Suggested + +- [ ] **Achieving OpenSSF Best Practices silver or gold badge.** + + + +### Required + +- [ ] **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.** + + + +- [ ] **Third Party Security Review.** + + - [ ] Moderate and low findings from the Third Party Security Review are planned/tracked for resolution as well as overall thematic findings, such as: improving project contribution guide providing a PR review guide to look for memory leaks and other vulnerabilities the project may be susceptible to by design or language choice ensuring adequate test coverage on all PRs. + + + +- [ ] **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 diff --git a/.github/ISSUE_TEMPLATE/template-incubation-application.md b/.github/ISSUE_TEMPLATE/template-incubation-application.md new file mode 100644 index 000000000..c8b9e5030 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/template-incubation-application.md @@ -0,0 +1,251 @@ +# $PROJECT Incubation Application +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 + +## Incubation Criteria Summary for $PROJECT + +### 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 + +- [ ] **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](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).** + + + +- [ ] **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. + + + +- [ ] **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.** + + + +## 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.** + + + +- [ ] **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](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 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.** + + + +## Contributors and Community + +Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy. + +### 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.** + + + +- [ ] **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.** + + + +## Security + +Note: this section may be augemented by a joint-assessment performed by TAG Security. + +### Suggested + +N/A + +### Required + +- [ ] **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.** + + + +## Additional Information + + diff --git a/docs/voting.md b/docs/voting.md deleted file mode 100644 index e16aa0c40..000000000 --- a/docs/voting.md +++ /dev/null @@ -1,3 +0,0 @@ -# Voting - -In various situations the CNCF TOC shall hold a vote. These votes can happen on the phone, email, or via a voting service, when appropriate. TOC members can either respond "agree, yes, +1", "disagree, no, -1", or "abstain". A vote passes with two-thirds vote of votes cast based on the charter (see [6(c)(viii)](https://www.cncf.io/about/charter)). An abstain vote equals not voting at all. \ No newline at end of file diff --git a/operations/dd-toc-guide.md b/operations/dd-toc-guide.md new file mode 100644 index 000000000..207cee825 --- /dev/null +++ b/operations/dd-toc-guide.md @@ -0,0 +1,206 @@ +# TOC Due Diligence guide + +This document provides the TOC with guidance on how to execute due diligence of CNCF projects for each level of maturity. It complements the Moving Levels process detailed in the [Moving Levels Directory](../moving-levels/). + +## What is due diligence? + +Due diligence is the process by which the TOC performs an independent review of CNCF projects to assess their posture, maturity, and adoption across a variety of technical, governance, and community focuses. The intent of the due diligence is to provide project and adopters with an independent senior technical evaluation of a project's readiness for production. Similar to how organizations have established software development processes and check points prior to software delivery or deployment that ensure the software meets the organization's goals and objectives, the due diligence is a point in time artifact of the project's acheivement for meeting the goals and objectives expected for their maturity level. By performing the due diligence on CNCF projects, the TOC supports our adopters in gaining confidence that the project has been reviewed against documented criteria for their maturity level, can understand any deviations from those criteria, and may not need to repeat this type of evaluation, rather they may incorporate or leverage the contents of the due diligence to guide and information their decision making. It also conveys to adopters the potential level of effort in adopting and integrating the project into their archicture and infrastructure. For projects, the due diligence provides an evaluation of the project against the expectations of adopters across multiple focuses. It can and often will include additional recommendations to the project that may support them in reaching the next level of maturity, improving their documentation or architecture, and in some cases highlight opportunities to distinguish themselves and their features or functionality from other projects within the same area. + +Due Diligence is typically conducted when a project has applied to move levels, after the project completes and asserts their adherence to the criteria for the level they are seeking to move to. For example, an incubating project must complete the graduation criteria before applying to graduate. Part of the TOC's responsiblity is to not only independently verify those assertions, but to understand those assertions in the context of the individual project, its domain, its interoperability, and subsequent alignment with the Foundation, ecosystem, adopters, and overall industry. + +The criteria for moving levels sets the expectations for what projects are to complete prior to applying for the next level. Criteria are outcome oriented and have been developed to provide projects with maximum flexibility in implementation while demonstrating the characteristics and hallmarks of maturing projects. TOC members may exercise their discretion in evaluating conformance to the criteria, however deviations, waivers, and exceptions should be clearly articulated and reasoned such that the desired outcome is still met through compensating mechanisms or demonstrated to not be relevant. + +The process of conducting due diligence is not to create unnecessary work for projects, rather to ensure projects are set up to succeed in a way that works for them against the values, principles, and definitions of cloud native and the expectations adopters carry for scalable, secure, production-ready software. + +It is important to remember that the CNCF is for the benefit of its members. This means the CNCF, through the TOC, defines the technical and community expectations for projects to receive benefits of the foundation. The criteria, due diligence process, security audits, templates, code of conduct, and community management practices are several expectations for projects to receive benefits. Adherence to these, and confirmation of adherence for each project's maturity level is essential to continuously receive those benefits. + +As a matter of balance, it is important to note that while these benefits provide value to projects, the TOC is responsible for continuously assessing the criteria, due diligence process, and overall levels framework to ensure we are adapting to shifts and changes in the landscape and market, as well as responding to the needs and limitations experienced by projects. _The community and projects are our partners in effecting that change, so feedback is crucial._ + +## How to conduct due diligence + +We will not focus on the events that have transpired prior to a project's application to move levels, choosing instead to focus on the point when the TOC is engaged. + +Currently, there exist three levels in the CNCF: +* _Sandbox_ - experimental and early stage projects worth exploring their viability and adoption probability within the ecosystem + * _Sandbox_ projects undergo due diligence when they apply to _Incubation_. + * _Sandbox_ projects do not receive due diligence in order to join the Foundation. +* _Incubating_ - projects that have proven concepts, are receiving market and adopter attention, and increasing their robustness, security, scalability, and maturity + * _Incubation_ projects receive due diligence when they apply for _Graduation_. +* _Graduated_ - projects that are stable, resilient, secure, and highly mature, they are capable of meeting the expectations of production-ready software + * _Graduated_ projects do not receive additional due diligence once they reach this level. + * By the time projects have _graduated_, they will have undergone two rounds of due diligence, once during the application to _incubation_, and a second time when they apply to _graduate_ - often a refresh depending on age since the last due diligence. + +Projects not already in the Foundation may apply directly to Incubation if they feel they are ready. At this point of application, they undergo due diligence that also considers their fit in the CNCF, much the same as the considerations for inclusion of sandbox projects. + +It is critical that TOC members strive to complete due diligence in a reasonable amount of time. The process involves multi-parties that requires coordination and clear communication of expectations. Delays in completing due diligence can create friction with projects and may encounter TOC member term endings, requiring project to start fresh with a new member. It is expected the process will take time, adopter interviews may be difficult to schedule in a timely fashion, so being upfront on these expectations is important. + +Every TOC member is expected to conduct due diligence of CNCF projects. In cases where there may be a perceived conflict of interest, the due diligence must have two TOC members participating in order to dissolve any illusion of bias (for or against). + +TOC members may not take on anymore than two (2) projects for due diligence at a given time unless one of the following conditions is true: +* the TOC member is functioning as a guide to new TOC members learning this process +* the TOC member is has two projects in voting +* the TOC member has one project in voting, and another in progress + +We expect all TOC members to be mindful of their obligations and timelines, whether they be work, cloud native, or personal and manage their workload accordingly. + +### Project has applied to move levels + +**Projects apply to move levels by submitting an Issue on the TOC repo that details their conformance to the criteria.** These Issues go into the [TOC backlog](https://github.com/orgs/cncf/projects/27/views/9) and are worked on a first-in, first-out/started basis to the extent that is reasonably practical - each TOC member has subject matter expertise in one domain or another and each TOC member serves as a liasion to a Technical Advisory Group that may or may not align with that domain. The TOC strives to align their skills and background with the project applying they are assigned to ensure they have the context to understand the project within that domain. + +The issue will contain a limited set of information about the project at the time of its application, commonly asserting its conformance to the stated criteria with links to where or descriptions as to how they are implemented. + +### TOC member(s) step forward to be assigned + +Commonly referred to as the Project's Application Sponsor, TOC members assign themselves to projects to sponsor the application for moving levels. Sponsoring an application ensures a focused point of contact exists for both the project and the TOC in completeing the Due Diligence, public comment, and execution of voting. + +TOC members ready to perform due diligence a project's application will socialize this internally with the TOC to provide opportunity for other members to participate. Once a TOC member or members is determined, those TOC members must assign themselves to the Issue and move the issue's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Assigned". + +TOC members may occassionally be contacted by projects asking the TOC member to sponsor their application to move levels. When this occurs, politely reminder projects of the TOC's first-in, first-started process and let them know it is subject to TOC availability. Follow up internally to the TOC that you were contacted and by which project so we may all be aware of which projects are reaching out as it may identify a backlog, timing, or communication issue. + +#### Conflicts of interest + +The Due Diligence process provides several mechansims that serve as check points for bias or uncomprehensive evaluation. The public comment period is the most open and transparent point at which the community and others may indepedently review the diligence performed by the TOC. Additionally, TOC members conduct an internal review of the due diligence to verify all aspects of the project have been thoroughly reviewed. + +A TOC member will require a co-sponsor for a project if any of the following conflicts apply: +* Hard Conflicts + * a project maintainer, + * direct report to a current maintainer, + * paid to work on the project + * has a significant financial interest directly tied to the success of the project, +* Soft Conflicts + * belongs to the same organization of the project, + * or uses it in their work + + This does not mean they can't have any involvement with a project at all as contributing to pull requests or adopting the project are signals of a healthy interest and knowledge of the project. To ensure appropriate evaluation without bias, a second, unconflicted TOC member must be assigned to co-sponsor the project with them. + +If a conflict of interest is present, the TOC member will state they have a conflict and seek a second sponsor on the project's application issue prior to proceeding. + +### Initial evaluation + +Once the TOC member is assigned the project, they should perform a cursory, light-weight evaluation of the project's completion of the criteria. If some of the criteria are not yet met, or missing, the TOC should notify the project of the issues requiring resolution before re-applying, and once confirmed by the project, comment publicly on the Issue with those recommendations for resolution and close it. TOC members should use their best judgement in determining if the unmet criteria are simple fixes or if they require substantial effort or time to properly complete. For example, a project applying to graduation should have clear and discoverable governance documentation. If the TOC member cannot find any governance documentation at all, they should engage the project to confirm that none exists. If it does exist, but is not readily discoverable, the TOC member may continue to move forward with due diligence as improving discoverable may be resolved through appropriate linking. If it doesn't exist, the TOC should finish the lightweight review, capture all unmet criteria, and engage the project prior to commenting and closing the Issue. + +### Kicking off the due diligence + +Once the project is assigned a TOC member and the initial evaluation looks good to proceed, the TOC member engages the project's maintainers or leadership group to kick off the due diligence. This can be done by commenting on the Issue, starting a slack channel (public or private), slack group direct message, email exchange, or thread in the project's primary communication channel. We strive to keep these discussions transparent and visible but should consider any potential sensitive issues that come about as a result of the review (resolution of vulnerabilities for instance). + +TOC members, with support from CNCF staff, should schedule a meeting with the project to the extent possible given availability and timezones. Asynchrounous kick-offs can occur, but may result in additional back and forth or delays. Each Kick-off meeting should have a central kick-off document that allows the TOC and the project to capture expectations, decisions, timelines, and other pertinent references needed for successful completion of the due diligence. A [kick-off meeting template](toc-templates/template-kickoff-notes.md) is located in the [toc-templates](toc-templates/) folder. + +Once the Kick-off is scheduled, the TOC member should move the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "In Due Diligence". It is *strongly* recommended that you inform the project to verify compliance with the CNCF's licensing policy (set forth in the [Section 11 of the Charter](https://github.com/cncf/foundation/blob/master/charter.md) with [additional information here](https://github.com/cncf/foundation/blob/main/allowed-third-party-license-policy.md)). + +### Completing Due Diligence + +The TOC will use the appropriate Due Diligence for the project's applied level as the basis for a PR ([Incubation template](toc-templates/template-dd-pr-incubation.md), [Graduation template](toc-templates/template-dd-pr-graduation.md)) and will evaluate the project's assertions in the application issue against the discoverable and publically available sites, repos, files, and other artifacts of the project. The TOC's evaluation against each criteria goes in the corresponding area of the PR template. + +Previously, the project was responsible for completing the due diligence such that it allowed the TOC member to review and comment. Due to the extensive back and forth in this prior process and with recent changes to the criteria, the TOC has altered the process leverage a Due Diligence PR as the TOC's assessment of the projects completion of the criteria. Therefore TOC members are expected to complete the Due Diligence PR with support from the project and TAG(s). + +As the TOC member reviews the criteria, any deviations or implementation notes from the review should be recorded within the due diligence PR as part of their evaluation for that specific criteria. The TOC member will provide an overall evaluation statement that summarizes the content of the due diligence once the Adopter Interview Summaries are recorded. For more information on adopter interviews, refer to [Conducting Adopter Interviews](#conducting-adopter-interviews). + +As an example, let's say a project is asserting their sub-projects have leadership, contribution information, maturity statuses, and add/removal processes. The TOC member, in confirming this may determine that the sub-projects share the same contributor file on the org's evolution directory and may change the maturity level in accordance with their documented process, but the process is not clear as to what initiates that change or who. For a sandbox project seeking incubation, this may be non-blocking but the TOC may recommend the project improve the documented process. As such, the TOC member will record their finding and corresponding recommendation. + +Another example, if the TOC member is looking over the project's stated goals and objectives that have not changed since the project was accepted into the CNCF, and they are now applying to Graduate, the TOC member will ask the project to clarify or provide additional information as to why the project hasn't iniatiated any changes and if they still feel those goals and objectives are accurate for the future of the project. The TOC member will then summarize the response and record it in the PR under the corresponding criteria evaluation. + +It is expected that the TOC's evaluation of a project's completion of the criteria may reveal a mismatch in understanding or an unexpected implementation. Documenting the TOC evaluation in the Due Diligence PR provides the project, TAGs, community, adopters, and TOC with a point of reference to understand if the criteria are meeting the outcomes required of a project for a certain maturity level, or if compensating mechanisms that supplement or augment the criteria are in place that work best for that specific project. + +#### Sub-projects + +When reviewing a project, you may find multiple sub-projects within their organization or repositories. It is important that the Due Diligence document reflect the scope of evaluation for a given project and what that includes. Sub-projects are often broken out into two categories: packaged with the project, and independent but related to the project (SDK reference implementations for instance). + +Sub-projects packaged with the main project are within scope of the due diligence evaluation. Any sub-project not packaged is outside the scope of the due diligence evaluation and must be indicated in the due diligence as "un-evalauted" and the reason. TOC members must verify that the main project has sufficient governance of its sub-projects that allows adopters and contributors to understand the stability, maturity, and requirements or criteria to be a sub-project, their relation to the main project, and other information necessary commensurate with the maturity level of the project. + +#### Licensing + +In the course of conducting a project's due diligence, you may become aware of license isues, outstanding exception requests, or other matters concerning the licensing of the project and its dependencies. If in the course of Due Diligence you find the project appears to be missing a license exception for their code or dependencies (dynamic or staticly linked), notify the project to [file a license exception request](https://github.com/cncf/foundation/issues/new/choose). The project's application to move levels may not go to a vote until the exception has been approved, however activities such as adopter interviews and public comment may proceed. It is expected that sandbox projects, when accepted, undergo a licensing review to ensure compliance with [CNCF's licensing policy](https://github.com/cncf/foundation/blob/main/license-exceptions/README.md) and exceptions. Refer to the [allowed third party licensing policy](https://github.com/cncf/foundation/blob/main/allowed-third-party-license-policy.md) for more information. + +#### Graduated project security audits + +TOC members who sponsor projects seeking graduation are expected to review the results of the audit to confirm the project has resolved all critical and high findings at a minimum. Additional findings are expected to be tracked for resolution by the project. In reviewing the audit of the project, you may find additional recommendations or deltas in the project's operational security (incident response, PR reviewer guidelines, lack of regression tests, etc.) that should be addressed. These are typically non-blocking, however the you should take care to note them within the due diligence after conveying their need and importance of completion to the project. You may reach out to TAG Security for assistance in identifying these areas or reach out to a TOC member with a background in Security. + +### Finalizing the Due Diligence + +When the TOC has finished their criteria evaluation, they should move the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Active Review & Discussion" and re-engage the project to elevate and discuss any items neededing clarity, correction, or improvement. This includes notifying the project of any recommendations. Recommendations and discussion points may copied into the kick-off document to faciliate discussion and to provide for additional context and discussion with the project until they are finalized. + +The TOC member may then file the PR and place it in draft until the Adopter Interviews are completed. + +#### Engaging TAGs + +If the project has previously engage with a TAG, the TOC may request an update or summary regarding the engagement and the TAG's assessment of the project in the context of the domain of the project. For instance, a policy-as-code project may present to TAG Security, TAG Security may summarize their recommendations to the project and link to supplemental material (like the project's self-assessment or joint-assessment) which is then added in the Due Diligence PR. + +Feedback by the TAG is encouraged prior to Due diligence being initiated, as requesting feedback when due diligence is occurring may prolong the due diligence process. It is expected that the project will have completed all criteria prior to applying, if this is not the case, due diligence should not commence. + +### Conducting Adopter Interviews + +After the evaluation has incorporated project feedback and discussion, the TOC member may move the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Adopter Interviews" to begin outreach and scheduling with adopters. + +In order to appropriately ascertain the adoption of a project, the TOC interviews a sampling of the project's adopters to understand how it is being used, what problems it is solving, the ease of adoption and integration, the community and contribution experience, and learn how adopters are experiencing the project's maturity level. + +The TOC member should request 5-7 potential adopters to be interviewed and work with the TOC on gathering contact information for them. The TOC, with support from CNCF staff, is responsible for engaging adopters, gathering publication consent, scheduling, conducting, summarizing, gathering final approval, and including the approved summary of the interview within the Due Diligence. + +The TOC maintains a core list of questions intended to initiate discussion with adopters, but may add additional questions, or skip questions depending on the course of the interview and the organization's level of comfort in providing responses. + +Interviews typically do not take more than 30 minutes to complete, and TOC members should anticipate about 1 hour of time dedicated to summarizing adopter responses. + +#### Reaching out to Adopters + +Once a TOC member has a listing of potential interviewees, they should leverage the [Adopter Interview Request email template](toc-templates/adopter-interview-request-template.md) to engage. The email template provides the essential information needed for interviewers to coordinate with their marketing, PR, or other outreach team for approval and allows adopters the opportunity to remain anonymous. It is imperative that the TOC honor any anonymity concerns and work to address them with adopters, the final approval of the summarized response is a mechanism that allows us to confirm with the adopter their comfort and approval of the final content intended for publication and make any corrections they feel are warranted. + +To ease scheduling with Adopters, TOC members are recommended to either include set aside dates/times for adopters as part of the initial email, or to provide a scheduling link to expedite scheduling and avoid delay. + +It is anticipated that a minimum of three adopter interviews are required to appropriately ascertain adoption of a project. However in the course of interviewing, you may find that you need additional adopters to be interviewed. + +For projects moving from Incubation to Graduation, if considerable time has passed since Incubation (according to the TOC's judgement), the TOC should refresh the Adopter interviews. This may be done by reaching out to previous interviewees, by engaging a new group of adopters for interviews, or some combination thereof. If the time period between Incubation and Graduation is fairly recent, the TOC member should exercise their judgement in choosing to pursue additional interviews. That decision should be recorded with justification in the adoption section of the template. + +#### Recording Responses + +Adopter interviews are expected to be interactive. The [adopter questions template](toc-templates/template-adopter-questions.md) should serve as a starting point for questions when interviewing, however TOC members are expected to use their best judgement in asking questions, deep diving on responses, and crafting additional questions or skipping others. + +You may need to record the meeting to fully capture the responses or take sufficient notes that you can summarize the discussion and convey, with enough breadth, how the adopter is using the project, what environments (such as dev, test, prod), their engagement with the project, use, experience, and future plans. + +#### Summary Approval + +TOC members will summarize responses to the questions asked in a separate, non-public document until the Adopter approves the content. + +Once you have summarized the interview, typically about 5 paragraphs in length depending on the detail allowed to be conveyed, share the doc with the Interviewee so they have permissions to make any changes. Provide the Interviewee with the doc, ask them to make any changes and provide approval two weeks from the date of sending. This provides you with a timeframe to follow-up with them so that it does not get lost or overlooked. + +#### Add Interview Summaries to Due Diligence + +Once approval is received, the summarized content is copied into the Due Diligence PR in the appropriate section. Linking to the summary is NOT recommended as it may convey identifying information in the history if not properly access controlled which will circumvent anonymity assurances. + +### Summarizing the Due Diligence Evalution + +Once you have completed evaluating the project's implementation of the criteria and included the Adopter Interviews, you can summarize the overall evalution. + +Evaluation summary is composed of two parts: the Criteria and the Adoption. The evaluation summary should read like an executive summary of the due diligence, conveying any notable areas and the assessment of sufficient adoption for the level the project applied. An example structure is provided below: + +> $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. +> +> The adopter interviews reflect a project [in use/too early] for the level which the project applied. They show ... $INTERVIEWSUMMARY. +> +> [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]. + +## TOC Internal Review + +Once the TOC member has completed the Due Diligence, the TOC member tags the TOC on the PR for an TOC internal review. The TOC member should move the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "TOC Review". + +The TOC member should craft a slack message thread that provides the project name, level applied, links to the PR and issue, and thread any additional call outs, questions, or potential issues warranting further discussion not otherwise captured in the PR. The internal review is expected to last 1 week, assuming no issues are brought up. + +The TOC member is responsible for updating the project with the change in status for internal review. + +### Reapplication + +In the event a project was not ready to move levels after the due diligence was completed and the project has reapplied through an issue, the previous or new TOC member assigned will initiate a new Due Diligence based on the previous one. The TOC should refresh the prior evaluations with corresponding dates to show changes and improvements and ammend the evaluation statements accordingly. + +## Public Comment Period + +Assuming no issues have come up during the TOC internal review, the TOC member may put the due diligence out for public comment. The TOC member should move the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Public Comment". + +TOC members are to leverage the [public comment template](toc-templates/template-dd-public-comment.md) and be mindful of the timeline to consider if a freeze is in effect or soon will be. All public comment messages are to be sent on the [TOC public mailing list](https://lists.cncf.io/g/cncf-toc/topics). Once sent, they should be linked on the PR and the project notified. + +## Voting + +Once the public comment period is complete, the TOC member needs to adjudicate any responses and comments on the PR. Provided no new or blocking information has been shared, the TOC member should request CNCF Staff to initiate voting on the PR, at which point the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Voting". + +TOC members, especially those who filed the PR, need to record their vote by the thumbs up or thumbs down on the PR comment where gitvote was initiated. + +## Press Coordination and Completion + +Once voting has passed, the CNCF Staff take over the remainder of the process, coordinating press releases and announcements for the prokject. CNCF Staff will update the project' card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) accordingly. diff --git a/process/election-schedule.md b/operations/election-schedule.md similarity index 100% rename from process/election-schedule.md rename to operations/election-schedule.md diff --git a/operations/toc-templates/template-adopter-interview-request.md b/operations/toc-templates/template-adopter-interview-request.md new file mode 100644 index 000000000..0f0906072 --- /dev/null +++ b/operations/toc-templates/template-adopter-interview-request.md @@ -0,0 +1,31 @@ +# Adopter Interview Request + +This template is intended to be leveraged by TOC members in the scheduling of adopter interviews for projects moving levels. + +Subject: Adopter Interview Request: CNCF $PROJECT + +Message Body + +$NAME, + +$TOCSPONSORS are the TOC sponsors for $PROJECT's [Graduation / Incubation]. As part of this process, we interview multiple adopters of the project to ascertain the maturity and adoption of the project. These interviews can be anonymous or attributable - whatever you and the $ADOPTERORG are comfortable with. + +Here is a [link](toc-templates/adopter-questions.md) to the questions I'll be asking, in case you need approval to respond. I try to remain on topic with those questions but may deep dive on a few depending on responses. + +We would like these interviews to be as transparent and public as possible, as it provides invaluable information to the project on improving their features, functionality, and engagement with adopters, but understand if you can only participate anonymously. + +If you, your organization, and/or your responses need to remain anonymous, I will endeavor to summarize to the extent possible and anonymize the content. Before finalizing your responses, they will be shared with you for your review, correction, and approval. Once I have your approval, they will be copied into the due diligence document which provides a summary of the TOC's evaluation of the project's readiness for the next level. + +I have the following dates and times available for interviews, these typically run about 30 minutes. + +Alternatively you may use my $SCHEDULINGLINK to schedule some time on my calendar: +$LINK + +I understand some organizations need their marketing, PR, or other such approval to participate. We are happy to coordinate with those individuals or include them in the interview. If you have any questions - please let me know. + + +Thank you in advance for your willingness to support open source through your participation in this interview and sharing your experience. + +$SIGNATUREBLOCK +TOC Sponsor for $PROJECT +Learn more about the [TOC](https://github.com/cncf/toc/tree/main#cncf-technical-oversight-committee-toc), the [CNCF](https://www.cncf.io/about/who-we-are/), and [the moving levels process](https://github.com/cncf/toc/tree/main/moving-levels/README.md). diff --git a/operations/toc-templates/template-adopter-questions.md b/operations/toc-templates/template-adopter-questions.md new file mode 100644 index 000000000..a8f8ee6bb --- /dev/null +++ b/operations/toc-templates/template-adopter-questions.md @@ -0,0 +1,39 @@ +# Adopter Interview Questions + +This template provides the **example set of questions** the TOC leverages in conducting adopter interviews for projects seeking to move levels. The TOC may use all, some, additional questions, or a combination thereof. This template may be linked to for scheduling interviews to that adopters know what to expect. + +TOC members will summarize responses to the questions asked in a separate, non-public document until the Adopter approves the content. Once approval is received, the summarized content is copied into the Due Diligence document. Linking to the summary is NOT recommended as it may convey identifying information in the history if not properly access controlled which will circumvent anonymity assurances. + +## Setting expectations + +The intent of these interviews is to ascertain the maturity and adoption of the project by adopters of the project. They may be public or private. + +Expectations conveyance with interviewers: “I’ll record raw notes here, then the notes will be cleaned up and shared with you for your review, correction, and final approval. Once approved, they’ll go into $PROJECT’s due diligence document.” + +## Questions + +1. How long has your organization used the project? + + +2. What is your update cadence with the project? + + +3. Can you walk me through what your experience was in either adopting it outright or integrating it with your existing services and applications? What challenges did you experience with the project? + + +4. Did you find the information in the repo or the project docs valuable to your implementation? If so, where did you find the information and what specifically was useful? + + +5. Did you need to engage with the community members or maintainers? If so what was the context of the engagement and did it reach an acceptable outcome? + + +6. Compared with other products in this space (proprietary and open) what drew you to the project? + + +7. Has your implementation of the project provided measurable value? Such as reducing manual activities, faster integrations, supported federation/multi-cloud, ease of use, etc. + + +8. Is there something you feel that holds the project back from reaching its ultimate potential? + + +9. Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc. diff --git a/operations/toc-templates/template-dd-pr-graduation.md b/operations/toc-templates/template-dd-pr-graduation.md new file mode 100644 index 000000000..e8f632c18 --- /dev/null +++ b/operations/toc-templates/template-dd-pr-graduation.md @@ -0,0 +1,274 @@ +# $PROJECT Graduation Due Diligence + +- Link to [Graduation application issue]() + + + +## Graduation 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 + +N/A + +### Required + +- [ ] **Give a presentation and engage with the domain specific TAG(s) to increase awareness** + + + +- [ ] **TAG provides insight/recommendation of the project in the context of the landscape** + + + +- [ ] **All project metadata and resources are [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).** + + + +- [ ] **Review and acknowledgement of expectations for [graduated](sandbox.cncf.io) projects and requirements for moving forward through the CNCF Maturity levels.** + - [ ] Met during Project's application on DD-MMM-YYYY. + + + +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.** + + + +## Governance and Maintainers + +Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy. + +### 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.** + + + +### Required + +- [ ] **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-neutral](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 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.** + + + +- [ ] **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.** + + + +- [ ] **Project maintainers from at least 2 organizations that demonstrates survivability.** + + + +- [ ] **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.** + + + +- [ ] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.** + + + +## Contributors and Community + +Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy. + +### 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 + +- [ ] **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.** + + + +- [ ] **Roadmap change process is documented.** + + + +- [ ] **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.** + + + +- [ ] **History of regular, quality releases.** + + + +## Security + +Note: this section may be augemented by a joint-assessment performed by TAG Security. + +### Suggested + +- [ ] **Achieving OpenSSF Best Practices silver or gold badge.** + + + +### Required + +- [ ] **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.** + + + +- [ ] **Third Party Security Review.** + + - [ ] Moderate and low findings from the Third Party Security Review are planned/tracked for resolution as well as overall thematic findings, such as: improving project contribution guide providing a PR review guide to look for memory leaks and other vulnerabilities the project may be susceptible to by design or language choice ensuring adequate test coverage on all PRs. + + + +- [ ] **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 diff --git a/operations/toc-templates/template-dd-pr-incubation.md b/operations/toc-templates/template-dd-pr-incubation.md new file mode 100644 index 000000000..6fc4530da --- /dev/null +++ b/operations/toc-templates/template-dd-pr-incubation.md @@ -0,0 +1,266 @@ +# $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 + +- [ ] **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](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).** + + + +- [ ] **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. + + + +- [ ] **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.** + + + +## 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.** + + + +- [ ] **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-neutral](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 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.** + + + +## Contributors and Community + +Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy. + +### 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.** + + + +- [ ] **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.** + + + +## Security + +Note: this section may be augemented by a joint-assessment performed by TAG Security. + +### Suggested + +N/A + +### Required + +- [ ] **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 diff --git a/operations/toc-templates/template-dd-public-comment.md b/operations/toc-templates/template-dd-public-comment.md new file mode 100644 index 000000000..5b6f3d105 --- /dev/null +++ b/operations/toc-templates/template-dd-public-comment.md @@ -0,0 +1,20 @@ +# Public Comment Message Template + +This template is intended to ensure the TOC Sponsor(s) have all the information needed to open the public comment period for a project moving levels on the [public TOC mailing list](https://lists.cncf.io/g/cncf-toc/topics). Make changes as appropriate. + +Subject: Public Comment for $PROJECT's $LEVEL application until $DATE + +Message Body: + +Community, + +Myself and $TOCSPONSOR are the TOC Sponsors for $PROJECT’s application to move from $FROMLEVEL to $TOLEVEL. + +Application: $LINK +DD PR: $LINK +Additional: [links additional relevant information, TAG recommendation, security audit, etc.] + +The public comment period is now open for 2 weeks, until End-Of-Day (EOD) [$DATE]. All TAGs, Adopters, TOC members, projects, and community members are welcome to review and comment on the PR. + +Thank you. +$SIGNATUREBLOCK diff --git a/operations/toc-templates/template-kickoff-notes.md b/operations/toc-templates/template-kickoff-notes.md new file mode 100644 index 000000000..1ec796e67 --- /dev/null +++ b/operations/toc-templates/template-kickoff-notes.md @@ -0,0 +1,46 @@ +# $PROJECT $APPLICATIONLEVEL Kick-off & Meeting notes + +$PROJECT $APPLICATIONLEVEL Kick-off & Meeting notes + +## Reference Links + +Issue: $LINK +Comms: $SLACK $WHATSAPP +Past DD (if applicable): $LINK +Other: $LINK + +## Adopter Interviews Outreach + +_A list of 5-7 potential interviewees. The TOC member can record status changes of when they reached out, if they got a response, if its scheduled, complete, in summary, waiting for approval, etc. Example below._ +✅ $GOLDIE - sent 8/25, done. +⏰ $ZEE - sent 8/30/2023, scheduled +⏰ $CAPPY - Sent 8/7/2023, emailed again on 8/25 +⏰ $RICKY - Sent 8/7/2023, emailed again on 8/25 +✅ $PHIPPY - Sent 8/7/2023, done. +✅ $TAI - Sent 8/7/2023, done + +## Notes + +_This contains notes, observations, and discussion items. This document is shared_ + +### September check-in +* **DONE(waiting for merge)!** Non-Blocking OpenSSF badging (criteria is for graduation not incubation) - $SUB-PROJECT repo is showing 99%, the only outstanding item: The information on how to contribute SHOULD include the requirements for acceptable contributions (e.g., a reference to any required coding standard). (URL required) [contribution_requirements] . + * Looking over the contributing file (recommend linking this on the community contributor ladder as the initial starting point for potential contributors), it does not specify the requirements for acceptable contributions beyond Developer Certificate of Origin (DCO). You'll need to add a section that defines the top level acceptable contributions and links to the community repos acceptable contributions as appropriate. + + +### Kick off Meeting + +Agenda: +* Set expectations +* General Steps & Timelines +* Due Diligence evaluation +* Adopter Interviews +* Questions + +Discussion: +* Covered recent changes in the TOC repo for expectations and freeze +* Covered adopter list for interviews, looking for 5-7 across multiple industries for a total of 3 final interviews to be conducted (additional on the list ensures lack of availability doesnt delay interviews) + +Actions: +* Share links to other DD for examples +* Share FAQs about adopters diff --git a/process/README.md b/process/README.md index b159a9d91..9279f0ada 100644 --- a/process/README.md +++ b/process/README.md @@ -1,108 +1,154 @@ -# I. Overview -This policy describes the Cloud Native Computing Foundation (CNCF) project life cycle process, from sandbox to archival and more. It describes the stages a project may be admitted under and what the criteria and expectations are for a given stage, as well as the acceptance criteria for a project to move from one stage to another. It also describes the Annual Review Process through which those changes will be evaluated and made. +# CNCF Project Lifecycle & Process +v1.6, previously "project proposal process v1.5" -Project progression, movement from one stage to another, allows projects to participate at the level that is most appropriate for them given where they are in their lifecycle. +## Introduction +This document provides high level information for projects to understand the project lifecycle, criteria, and the moving levels process for to demonstrate their completion of a defined criteria set. -# II. Stages - Definitions & Expectations +CNCF Projects experience a project lifecycle that conveys their completion of a defined set of criteria. These criteria are cumulative, building upon the previous maturity level criteria to enable cloud native projects to become highly maturity, secure, production ready projects for adopters. -CNCF projects have a maturity level of sandbox, incubating, or graduated. Archived is for projects no longer in active development. The maturity level is a signal by CNCF as to what sorts of enterprises should be adopting different projects. Projects increase their maturity by demonstrating their sustainability to CNCF’s Technical Oversight Committee: that they have adoption, a healthy rate of changes, committers from multiple organizations, have adopted the CNCF Code of Conduct, and have achieved and maintained the OpenSSF Best Practices Badge. + The TOC defines 4 stages of the project lifecycle: -![Project Stages](https://github.com/cncf/toc/blob/main/process/project-stages.png) +* **[Sandbox](https://sandbox.cncf.io)** - experimental or innovative projects that are early in their life +* **Incubation** - growing maturity projects that are on the precipice of "crossing the chasm" +* **Graduated** - highly mature, robust projects whose adopters have demonstrated their production-readiness by their deployment to production environments +* **[Archived](archiving.md)** - inactive or low activity projects that are no longer supported by the TOC or are not recommended for use due to a variety of factors (project specific) -## Sandbox: +## Project stages -The CNCF Sandbox is the entry point for early stage projects and has four goals: +![Project stages](project-stages.png) -* Encourage public visibility of experiments or other early work that can add value to the CNCF mission and build the ingredients of a successful Incubation level project -* Facilitate alignment with existing projects if (and only if) this is desired -* Nurture projects (e.g. via CNCF Service Desk requests) -* Remove possible legal and governance obstacles to adoption and contribution by ensuring all projects adhere to CNCF legal, code of conduct and IP Policy requirements +Projects may enter the CNCF either by applying as a sandbox project or applying directly for incubation. As project navigates their maturity journey, their completion of a given level's criteria is evaluated by the TOC in a process called Due Diligence to ensure the project's implementation of the criteria meets the desired outcome, intent, and expectations set forth by the TOC. +Evaluting projects against the criteria does take some time and the TOC has recently modified the Due Diligence process to reduce duplication of work, streamline handoffs, and provide better transparency to the project and its adopters about its conformance and implementation of the criteria. -## Incubating: -Incubating projects have access to all resources listed at https://cncf.io/services-for-projects, and have a presence at CloudNativeCon. +## How to apply to move levels +### Applying to Sandbox -## Graduated: -Graduated projects signal the highest level of maturity for a CNCF project. +**Note: The TOC has changed the sandbox application process to a more transparent and streamlined workflow within the :package: [Sandbox Applications repository](https://github.com/cncf/sandbox) :package:.** +Projects apply for sandbox through the Sandbox Repo's *[Issue Form](https://github.com/cncf/sandbox/issues/new)*. More information on this process is found on the main [Sandbox repo page](https://github.com/cncf/sandbox). +All exceptions and "declined" or "postponed" outcomes are handled by the TOC. Projects may be encouraged to re-apply after addressing areas called out in the application comments on the corresponding issue. Please refer to the instructions in the [Sandbox repo README](https://github.com/cncf/sandbox) for more details on re-application. -## Archived: -Archived projects are no longer in active development and are only archived after a TOC vote. +### Applying to become an Incubating or Graduating project -# III. Project Proposal Process +While the details of the process are described in detail further for Incubating and Graduting proposals, the high level steps that occur when a project moves levels are as follows: -Introduction: -This governance policy sets forth the proposal process for projects to be accepted into the CNCF. -The process is the same for both existing projects which seek to move into the Foundation, and new projects to be formed within the CNCF. +#### Applications to move levels are done by submitting an incubation or graduation [application issue](https://github.com/cncf/toc/issues/new/choose) on the TOC repo +*Who: Project* -## Project Proposal Requirements: +* Projects seeking to move to incubation should submit the Incubation Application issue and detail how they meet the incubation level criteria, existing incubating projects seeking to move to graduation should submit the Graduation Application issue and detail how they meet the graduation level criteria. +* As prior applications are closed, the TOC selects the next project from the backlog. -## Sandbox Projects: +#### A TOC sponsor(s) is assigned and the project is moved to 'Due Diligence' or 'Active Review' on the project boards depending on which level is proposed. +*Who: TOC* -Projects being submitted to the CNCF at the sandbox level are intended to be the entry point for early stage projects and are not required to undergo due diligence. +#### Application Kick off Meeting is scheduled and held +*Who: TOC Sponsor(s) and Project* -Sandbox projects should be early-stage projects that the CNCF TOC believes warrant experimentation. +* The TOC will schedule time with the project to set expectations and layout out the process. The TOC will use the meeting notes document to capture blockers, recommendations, and other findings as they review the issue and the project's respositories, channels, release process, metrics, governance, and other sources of information that support the project's completion of the criteria. The TOC member will refer back to these notes to support their forumlation of the Due Diligence PR. The project is asked to identify 5-7 adopters for interviews. +* If the TOC sponsor(s) finds that the project is not yet ready to move levels, they will re-engage with the project to discuss next steps, detail specific blockers that prevent the project from moving, and any actions that need to be completed but are non-blocking. The Application issue is updated with this summary once the project is discussed. -* New projects that are designed to extend one or more CNCF projects with functionality or interoperability libraries. -* Independent projects that fit the CNCF mission and provide potential for a novel approach to existing functional areas (or are an attempt to meet an unfulfilled need) -* Projects commissioned or sanctioned by the CNCF, including initial code for CNCF WG collaborations, and "experimental" projects -* Any project that realistically intends to join CNCF Incubation in future and wishes to lay the foundations for that +#### Due Diligence creation or refresh +*Who: TOC Sponsor(s)* -To apply for inclusion into the Sandbox, projects should use apply at [sandbox.cncf.io](https://sandbox.cncf.io). -The TOC will review on a rotating basis, currently every two months as of June 2020. +* Once all recommendations, blockers, and other findings are resolved, the TOC member will begin crafting the Due Diligence PR that provides their evaluation of the project's completion of the criteria, any compensating mechanisms in place, or other notables that may influnce the TOC's decision to move the project to the next level. +#### Adopter Interviews are conducted +*Who: TOC Sponsor(s) and Adopters* -## Project Graduation Process: Sandbox to Incubating +* Depending on the freshness of prior interviews the TOC may choose to not conduct further interviews or conduct others to ensure coverage by a variety of adopters to explore all facets of the project. The project is updated on the project board. +* The TOC will reach out to adopters to inform them of how interviews are conducted and to address any anonomity or other concerns they may have. The TOC will ensure adopters have final approval of any published summaries of the interviews that are included in the due diligence PR. +* If multiple TOC members are sponsoring, they will conduct their own individual reviews and then coordinate with each other on overall observations, findings, and next steps. -Incubating projects are required to undergo due diligence as a part of the process to move from Sandbox to Incubation. Due Diligence is driven by a TOC sponsor, with two weeks for public comment before a vote is called. +#### TOC internal comment period +*Who: TOC Sponsor(s) and TOC* -Criteria: -To be accepted to incubating stage, a project must meet the sandbox stage requirements plus: +* Assuming all outstanding issues are resolved, the TOC opens an internal comment period, about 1 week, for other TOC members to perform an independent review and verify all areas of the project have been evaluated. +* The TOC sponsor may choose to share a WIP PR with the TOC for review and comment internally. If no further issues are identified, the TOC sponsor(s) will finalize and submit the PR to open the public comment period. A message is announced on the toc mailing list. -* Document that it is being used successfully in production by at least three independent adopters which, in the TOC’s judgement, are of adequate quality and scope. -* Have a healthy number of committers. A committer is defined as someone with the commit bit; i.e., someone who can accept contributions to some or all of the project. -* Demonstrate a substantial ongoing flow of commits and merged contributions. -* Since these metrics can vary significantly depending on the type, scope and size of a project, the TOC has final judgement over the level of activity that is adequate to meet these criteria -* A clear versioning scheme. -* Specifications must have at least one public reference implementation. +#### The project is updated on the project board to 'Public Comment' and **the public comment period is open for two weeks**. +*Who: TOC Sponsor(s)* -![Incubating](https://github.com/cncf/toc/blob/main/process/incubation-process.png) +#### Voting opens +*Who: Initiate - CNCF Support Staff for the TOC, Voting - TOC and community members* -Projects currently in progress for consideration at the Incubating stage are tracked: https://github.com/orgs/cncf/projects/27/views/9 +* Provided no additional items are identified during the public comment period, the TOC opens voting on the PR using gitvote shortly thereafter (usually about 2 days subject to availability). The project is updated on the project board to 'In Voting'. +* TOC members and the community may cast votes and show support by using emoji voting on the gitvote initiating comment. -## (3) Project Graduation Process: Incubating to Graduation -Projects that wish to move from Incubating to Graduation should open a PR confirming the following criteria: -* Have committers from at least two organizations. -* Have achieved and maintained a [OpenSSF Best Practices Badge](https://bestpractices.coreinfrastructure.org/). -* Have completed an independent and third party security audit with results published of similar scope and quality as [this example](https://github.com/envoyproxy/envoy#security-audit) which includes all critical vulnerabilities and all critical vulnerabilities need to be addressed before graduation. -* Explicitly define a project governance and committer process. The committer process should cover the full committer lifecycle including onboarding and offboarding or emeritus criteria. This preferably is laid out in a GOVERNANCE.md file and references an OWNERS.md file showing the current and emeritus committers. -* Explicitly define the criteria, process and offboarding or emeritus conditions for project maintainers; or those who may interact with the CNCF on behalf of the project. The list of maintainers should be preferably be stored in a MAINTAINERS.md file and audited at a minimum of an annual cadence. -* Have a public list of project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the project website). For a specification, have a list of adopters for the implementation(s) of the spec. -* Please include a short one-page narrative based off the Graduation template, no more than 500 words. +#### Voting is completed +*Who: CNCF Support Staff for the TOC* -Projects moving from incubation to graduation are tracked here: https://github.com/orgs/cncf/projects/27/views/9 +* If the vote passes (2/3 supermajority vote of the TOC), the results are emailed and the project is placed in the 'Done' state on the project board. +* An announcement is made conveying the project name and its new level status. -## (4) Archiving Projects +#### Criteria -Open source projects have a lifecycle and there are times that projects become inactive due to a variety of reasons. There are also cases where a project may no longer want to be supported by the TOC, or the TOC may no longer wish to recommend the use of a project. -Archiving Criteria -When voting on a proposal to archive a project, TOC members may wish to consider whether the project continues to meet the criteria for CNCF acceptance. The TOC may also look at activity levels in the project (https://all.devstats.cncf.io/d/53/projects-health-table?orgId=1), although it is important to note that there is a difference between a mature project that doesn't get much attention any more but is stable, versus a project that is inactive. +Projects can find the criteria for Incubation by reviewing the [Incubation application template](../.github/ISSUE_TEMPLATE/template-incubation-application.md). -### Voting Process +Projects can find the criteria for Graduation by reviewing the [Graduation application template](../.github/ISSUE_TEMPLATE/template-graduation-application.md). -To archive a project: -* A proposal must be put forth to the TOC repo -* The TOC will inform the project maintainers, CNCF End-User community and wider community of all archiving proposals -* The proposal must remain open for at least 2 weeks of discussion after the maintainers are informed. -* A vote must be finalized with 2/3 approval from the TOC +### Timelines -### Archiving Process +#### Expectations -See the [Archiving process](archiving.md). +The TOC makes no guarantees on if or when a project will join the CNCF or move levels. Projects apply for moving levels when they feel they are ready. However, what is ready for one project is not the same for another nor is each project’s adoption and maturity measurable against one another. For some projects it may be a long journey with the TOC to bring them to maturity for the kind of project they are and for others it may be shorter - it all depends on the individual project, their readiness, and the availability of the individuals responsible for various tasks in moving levels. -# IV. Annual Review Process +When projects apply for moving levels, they do not move levels on a first-in first-out (FIFO) basis. Some projects join the Foundation when they are already far along in their journey and others join very early. They will approach maturity guide posts differently - at different times and in ways similar or different from others. We do our best to support projects moving levels, in some cases engaging with them frequently to ensure they are making progress on our initial findings but leaving the application open. In other cases, we review the project and finding nothing disparaging, only needing to refresh the content of the previous due diligence, evaluate against the next level of criteria, and move it forward. -The TOC is deprecating the current annual review process as of September 2023 in favor of a proposed automated review system. \ No newline at end of file +For sandbox proposals, applications are reviewed in the order the TOC chooses, most commonly returning applications first and then from oldest application to newest every two months. The TOC may not have time to get through every application each meeting as different project applications carry varying considerations and discussion topics to ensure enough information is discovered and explored to make an informed decision. The up to date list can be found [here](https://sandbox.cncf.io/) and will be carried over from meeting to meeting if not every project is reviewed. + +For moving levels to incubation or graduation, projects should plan on _at least 3 months_ once a TOC member steps forward to sponsor the project's application (assigns themselves to the issue). + +#### KubeCon+CloudNativeCon Freeze + +Due to the increased community demands around KubeCon + CloudNativeCon (KCCN), the scheduling and production of content, and reduced availability of individuals involved in moving levels, the TOC leverages a freeze for projects in process for moving levels. Even if a project is approved to move levels 3 weeks before this event, projects should _not_ expect to receive benefits beyond those afforded for the level they were previously at. For example, if a sandbox project is approved to move to incubation 3 weeks prior to the event, the project and the event staff will not have enough time to record, edit, and produce an incubating project update to have it included within the keynote stage reel. + +For each KubeCon + CloudNativeCon's (KCCN) standalone event (where KCCN is the focus, not a joint event with OSS Summit or other such conference) — currently Europe and North America — the following freeze is applied: + +__Within 6 weeks of the event__ + +* TOC members will not take on new sponsorship of applications for moving levels +* Many activities occur before, during, and after KCCN. Postponing new sponsorship until after KCCN reduces the likelihood that kicking off the process is overcome by such activities. + +__Within 2 weeks of the event__ + +* Public Comment will not open + * We want to ensure community members, adopters, and other stakeholders have time to participate in the public comment of projects, the 2 weeks leading up to the event are typically very busy for many individuals involved in the moving levels process. +* Voting for projects will not open + * Voting is an opportunity for community members to show support for projects, it is also the time when the TOC determines if the due diligence and state of the project support its promotion to the next level. As such it is essential for TOC members to have time to not only cast votes, but to consider any comments raised during the public comment period. The TOC is just as busy as any other attendee or speaker for KCCN, it is easy to miss the timeframes for voting and we want to ensure projects receive the attention in a vote they deserve. +* Open voting is paused + * While community members may continue to show support for projects, the TOC will officially pause our voting. +* No project announcements + * Even if a project has passed a vote, if they have not announced and officially moved levels, they will not be included as an incubating or graduated project. + +__2nd week following the event__ + +* Voting for projects who completed public comment may open and commence. +* The week immediately following KCCN is commonly reserved as a recovery and digest period for attendees, event staff, community members, and TOC. + +TOC members may choose to continue working with projects on due diligence within the weeks before and after KCCN subject to their and others' availability. Projects should take all of this into account when planning completion of their due diligence. We ask projects to be understanding and considerate of our availability constraints around KCCN and remind everyone that the TOC is not a full-time body, we have primary work commitments in addition to our involvement on the TOC and any projects, TAGs, or community groups we are involved in. + +As the CNCF chooses to create new standalone occurrences of KCCN, this freeze should be reviewed to ensure ample time is available to conduct activities to support project moving levels. It may include restricting to just two freezes a year, or a complete re-evaluation of the freeze in light of whatever changes have transpired. + +#### Additional information + +Q: Why doesn't the TOC get through the sandbox list every meeting? +A: There are currently many projects that want to be a part of the CNCF and it is the TOC's job to carefully consider if they are the right fit for the foundation. This deliberation takes time and there are only so many applications that the TOC can get through each meeting. If anything, a delay from one meeting to the next is a benefit for the project because it allows more time to build community support. + +Q: Exactly how long will it take my project to move levels once my application is in? +A: Just like in open source, it will get done when the work is done. This can range from 5 months to 15 months please coordinate with your TOC sponsor to keep everything on track. + +Q: Can my project still apply to move levels within 6 weeks of KubeCon? +A: Yes, though getting a TOC sponsor, conducting any due diligence, and any other steps of the process will be delayed until after KubeCon. + +Q: Why can't public comment periods or votes launch within 6 weeks of a KubeCon? +A: Undergoing due diligence is a non-insignificant amount of work. Conducting adopter interviews takes time and scheduling becomes increasingly difficult the closer to each KCCN we get. Being able to successfully complete due diligence to launch the public part of the process becomes very difficult as many community members have additional responsibilities related to the conference. By removing KCCN as a goal post for brand new requests to move levels, we hope to not burn out adopters, TOC, maintainers, and other community members. + +Q: I meet the criteria, why am I not graduating? +A: There could be a number of reasons why a project is not yet ready to graduate but appears to meet the criteria. The TOC has increased the clarity and desired outcomes the criteria should achieve for projects but require evaluation on a case-by-case basis for each project to understand the implications of their implementation. The TOC has final discretion but endevours to be transparent and enable projects to successfully and sustatinably achieve Graduation status while balancing the needs and expectations of adopters and CNCF members. + +Q: How can I ensure my project is on the right path to the next level? +A: Projects are strongly encouraged to meet with their TAG to receive feedback on changes, improvements, recommendations to assist the project to the next maturity level. Some of these may be domain specific recommendations to ensure a more robust project, or they may be more high level items and encompass engineering principles that need codified within the project. TOC members sponsoring a project will reach out to the project's TAG to understand more about the project and ensure they incorporate the TAG's recommendations, notes, and observations within the Due Diligence PR. diff --git a/process/dd-review-template.md b/process/dd-review-template.md deleted file mode 100644 index d0828383f..000000000 --- a/process/dd-review-template.md +++ /dev/null @@ -1,101 +0,0 @@ -# Due Diligence Project Review Template -This page provides a template to help those leading or contributing to due diligence exercises performed by or on behalf of the Technical Oversight Committee of the CNCF. Please also read the [Due Diligence Guidelines](https://github.com/cncf/toc/blob/main/process/due-diligence-guidelines.md). - -## Introduction -The decision to graduate or promote a project depends on the TOC sponsors of the project performing and documenting the evaluation process in deciding upon initial or continued inclusion of projects through a Technical Due Diligence ('Tech DD') exercise. Ultimately the voting members of the TOC will, on the basis of this and other information, vote for or against the inclusion of each project at the relevant time. - -## Technical Due Diligence -### Primary Goals -To enable the voting TOC members to cast an informed vote about a project, it is crucial that each member is able to form their own opinion as to whether and to what extent the project meets the agreed upon criteria for sandbox, incubation or graduation. As the leader of a DD, your job is to make sure that they have whatever information they need, succinctly and readily available, to form that opinion. - -As a secondary goal, it is in the interests of the broader CNCF ecosystem that there exists some reasonable degree of consensus across the community regarding the inclusion or otherwise of projects at the various maturity levels. Making sure that the relevant information is available, and any disagreement or misunderstanding as to it's validity are ideally resolved, helps to foster this consensus. - -## Statement of CNCF Alignment to TOC Principles -1. Project is self-governing -2. Is there a documented Code of Conduct that adheres to the CNCF guidelines? -3. Does the project have production deployments that are high quality and high-velocity? (for incubation and graduated projects). -(Sandbox level projects are targeted at earlier-stage projects to cultivate a community/technology) -4. Is the project committed to achieving the CNCF principles and do they have a committed roadmap to address any areas of concern raised by the community? -5. Document that the project has a fundamentally sound design without obvious critical compromises that will inhibit potential widespread adoption -6. Document that the project is useful for cloud native deployments & degree that it's architected in a cloud native style -7. Document that the project has an affinity for how CNCF operates and understand the expectation of being a CNCF project. - -## Review of graduation criteria and desired cloud native properties -/* Use appropriate Section */ - -### Sandbox Graduation (Exit Requirements) -1. Document that it is being used successfully in production by at least three independent direct adopters which with focus on adequate quality and scope defined. -2. Have a healthy number of committers. A committer is defined as someone with the commit bit; i.e., someone who can accept contributions to some or all of the project. -3. Demonstrate a substantial ongoing flow of commits and merged contributions. - -### Incubating Stage Graduation (Exit Requirements) -1. Document that it is being used successfully in production by at least three independent direct adopters which with focus on adequate quality and scope defined. -2. Have a healthy number of committers. A committer is defined as someone with the commit bit; i.e., someone who can accept contributions to some or all of the project. -3. Demonstrate a substantial ongoing flow of commits and merged contributions. -4. Have committers from at least two organizations. -5. Have achieved and maintained a Core Infrastructure Initiative Best Practices Badge. -6. Adopted the CNCF Code of Conduct. -7. Explicitly define a project governance and committer process. The committer process should cover the full committer lifecycle including onboarding and offboarding or emeritus criteria. This preferably is laid out in a GOVERNANCE.md file and references an OWNERS.md file showing the current and emeritus committers. -8. Explicitly define the criteria, process and offboarding or emeritus conditions for project maintainers; or those who may interact with the CNCF on behalf of the project. The list of maintainers should be preferably be stored in a MAINTAINERS.md file and audited at a minimum of an annual cadence. -9. Have a public list of project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the project website), guidelines for identifying adopters can be found in the [FAQs](https://github.com/cncf/toc/blob/main/FAQ.md#what-is-the-definition-of-an-adopter). - -### Documentation of CNCF Alignment (if not addressed above): -* name of project (must be unique within CNCF) -* project description (what it does, why it is valuable, origin and history) -* statement on alignment with CNCF charter mission -* sponsor from TOC (sponsor helps mentor projects) -* license (charter dictates Apache 2 by default) -* source control (GitHub by default) -* external dependencies (including licenses) -* release methodology and mechanics -* community size and any existing sponsorship - -## Technical -* An architectural, design and feature overview should be available. (add link) -* What are the primary target cloud-native use cases? Which of those: - * Can be accomplished now. - * Can be accomplished with reasonable additional effort (and are ideally already on the project roadmap). - * Are in-scope but beyond the current roadmap. - * Are out of scope. -* What are the current performance, scalability and resource consumption bounds of the software? Have these been explicitly tested? Are they appropriate given the intended usage (e.g. agent-per-node or agent-per-container need to be lightweight, etc)? -* What exactly are the failure modes? Are they well understood? Have they been tested? Do they form part of continuous integration testing? Are they appropriate given the intended usage (e.g. cluster-wide shared services need to fail gracefully etc)? -* What trade-offs have been made regarding performance, scalability, complexity, reliability, security etc? Are these trade-offs explicit or implicit? Why? Are they appropriate given the intended usage? Are they user-tunable? -* What are the most important holes? No HA? No flow control? Inadequate integration points? -* Code quality. Does it look good, bad or mediocre to you (based on a spot review). How thorough are the code reviews? Substance over form. Are there explicit coding guidelines for the project? -* Dependencies. What external dependencies exist, do they seem justified? -* What is the release model? Versioning scheme? Evidence of stability or otherwise of past stable released versions? -* What is the CI/CD status? Do explicit code coverage metrics exist? If not, what is the subjective adequacy of automated testing? Do different levels of tests exist (e.g. unit, integration, interface, end-to-end), or is there only partial coverage in this regard? Why? -* What licensing restrictions apply? Again, CNCF staff will handle the full legal due diligence. -* What are the recommended operational models? Specifically, how is it operated in a cloud-native environment, such as on Kubernetes? - -## Project -* Do we believe this is a growing, thriving project with committed contributors? -* Is it aligned with CNCF's values and mission? -* Do we believe it could eventually meet the graduation criteria? -* Should it start at the sandbox level or incubation level? -* Does the project have a sound, documented process for source control, issue tracking, release management etc. -* Does it have a documented process for adding committers? -* Does it have a documented governance model of any kind? -* Does it have committers from multiple organizations? -* Does it have a code of conduct? -* Does it have a license? Which one? Does it have a CLA or DCO? Are the licenses of its dependencies compatible with their usage and CNCF policies? CNCF staff will handle the full legal due diligence. -* What is the general quality of informal communication around the project (slack, github issues, PR reviews, technical blog posts, etc)? -* How much time does the core team commit to the project? -* How big is the team? Who funds them? Why? How much? For how long? -* Who are the clear leaders? Are there any areas lacking clear leadership? Testing? Release? Documentation? These roles sometimes go unfilled. -* Besides the core team, how active is the surrounding community? Bug reports? Assistance to newcomers? Blog posts etc. -* Do they make it easy to contribute to the project? If not, what are the main obstacles? -* Are there any especially difficult personalities to deal with? How is this done? Is it a problem? -* What is the rate of ongoing contributions to the project (typically in the form of merged commits). - -## Users -* Who uses the project? Get a few in-depth references from 2-4 of them who actually know and understand it. -* What do real users consider to be its strengths and weaknesses? Any concrete examples of these? -* Perception vs Reality: Is there lots of buzz, but the software is flaky/untested/unused? Does it have a bad reputation for some flaw that has already been addressed? - -## Context -* What is the origin and history of the project? -* Where does it fit in the market and technical ecosystem? -* Is it growing or shrinking in that space? Is that space growing or shrinking? -* How necessary is it? What do people who don't use this project do? Why exactly is that not adequate, and in what situations? -* Clearly compare and contrast with peers in this space. A summary matrix often helps. Beware of comparisons that are too superficial to be useful, or might have been manipulated so as to favor some projects over others. Most balanced comparisons will include both strengths and weaknesses, require significant detailed research, and usually there is no hands-down winner. Be suspicious if there appears to be one. diff --git a/process/due-diligence-guidelines.md b/process/due-diligence-guidelines.md deleted file mode 100644 index bb5b40532..000000000 --- a/process/due-diligence-guidelines.md +++ /dev/null @@ -1,152 +0,0 @@ -# Due Diligence Guidelines - -This page provides guidelines to those leading or contributing to due -diligence exercises performed by or on behalf of the Technical -Oversight Committee of the CNCF. - -## Introduction - -Part of the evaluation process in deciding upon initial or continued -inclusion of projects into the CNCF is a Technical Due Diligence -('Tech DD') exercise. Ultimately the voting members of the TOC will, -on the basis of this and other information, vote for or against the -inclusion of each project at the relevant time. - -## Leading a Technical Due Diligence - -### Primary Goals - -To enable the voting TOC members to cast an informed vote about a -project, it is crucial that each member is able to form their own -opinion as to whether and to what extent the project meets the agreed -upon [criteria](https://github.com/cncf/toc/blob/main/process/graduation_criteria.md) for -sandbox, incubation, or graduation. As the leader of a DD, your job -is to make sure that they have whatever information they need, -succinctly and readily available, to form that opinion. - -As a secondary goal, it is in the interests of the broader CNCF -ecosystem that there exists some reasonable degree of consensus across -the community regarding the inclusion or otherwise of projects at the -various maturity levels. Making sure that the relevant information is -available, and any disagreement or misunderstanding as to its -validity are ideally resolved, helps to foster this consensus. - -### Where to start - -* Make sure you are clear on the [TOC Principles](https://github.com/cncf/toc/blob/main/PRINCIPLES.md), - the [project proposal process](https://github.com/cncf/toc/blob/main/process/project_proposals.md), - the [graduation criteria](https://github.com/cncf/toc/blob/main/process/graduation_criteria.md), - and the [desired cloud native properties](https://www.cncf.io/about/charter/). The project sponsor (a member - of the TOC) should have assisted in crafting the proposal to explain why it is a good fit for the CNCF. If anything is - unclear to you, reach out to the project sponsor or, failing that, the TOC mailing list for advice. -* Make sure you read, in detail, the relevant [project proposal](https://github.com/cncf/toc/tree/main/proposals). - This will usually be in the form of an [open pull request](https://github.com/cncf/toc/pulls). - Consider holding off on commenting on the PR until you have completed the next three steps. -* Take a look at some [previous submissions](https://github.com/cncf/toc/pulls?utf8=%E2%9C%93&q=is%3Apr) - (both successful and unsuccessful) to help calibrate your expectations. -* Verify that all of the basic [project proposal requirements](https://github.com/cncf/toc/blob/main/process/project_proposals.md) have been provided. -* Do as much reading up as you need to (and consult with experts in the specific field) in order to familiarize yourself with the technology - landscape in the immediate vicinity of the project (and do not only use the proposal and that project's documentation as a guide in this regard). -* At this point, you should have a very clear technical idea of what exactly the project actually does and does not do, roughly how it compares with and differs from - similar projects in its technology area, and/or a set of unanswered questions in those regards. -* Go through the [graduation criteria](https://github.com/cncf/toc/blob/main/process/graduation_criteria.md) and for each item, - decide for yourself whether or not you have enough information to make a strong, informed call on that item. - * If so, write it down, with motivation. - * If not, jot down what information you feel you are missing. - * Also take note of what unanswered questions the community might have posted in the PR review that you consider - to be critically important. - -### Some example questions that will ideally need clear answers - -Most of these should be covered in the project proposal document. The -due diligence exercise involves validating any claims made there, -verifying adequate coverage of the topics, and possibly summarizing -the detail where necessary. - -#### Technical - -* An architectural, design, and feature overview should be available. - ([example](https://github.com/docker/notary/blob/master/docs/service_architecture.md), - [example](https://github.com/docker/notary/blob/master/docs/command_reference.md)) -* What are the primary target cloud native use cases? Which of those: - * Can be accomplished now. - * Can be accomplished with reasonable additional effort (and are ideally already on the project road map). - * Are in-scope but beyond the current road map. - * Are out of scope. -* What are the current performance, scalability, and resource consumption bounds of the software? Have these been explicitly tested? - Are they appropriate given the intended usage (e.g. agent-per-node or agent-per-container need to be lightweight, etc)? -* What exactly are the failure modes? Are they well understood? Have they been tested? Do they form part of continuous integration testing? - Are they appropriate given the intended usage (e.g. cluster-wide shared services need to fail gracefully etc)? -* What trade-offs have been made regarding performance, scalability, complexity, reliability, security etc? Are these trade-offs explicit or implicit? - Why? Are they appropriate given the intended usage? Are they user-tunable? -* What are the most important holes? No high availability? No flow control? Inadequate integration points? -* Code quality. Does it look good, bad, or mediocre to you (based on a spot review). How thorough are the code reviews? Substance over form. - Are there explicit coding guidelines for the project? -* Dependencies. What external dependencies exist; do they seem justified? Note: all core dependencies should be listed in the document along with the details of relevant repositories. -* What is the release model? Versioning scheme? Evidence of stability or otherwise of past stable released versions? -* What is the CI/CD status? Do explicit code coverage metrics exist? If not, what is the subjective adequacy of automated testing? - Do different levels of tests exist (e.g. unit, integration, interface, end-to-end), or is there only partial coverage in this regard? Why? -* What licensing restrictions apply? Again, CNCF staff will handle the full legal due diligence. -* What are the recommended operational models? Specifically, how is it operated in a cloud native environment, such as on Kubernetes? - -#### Project - -The key high-level questions that the voting TOC members will be looking to have answered are (from the [graduation criteria](https://github.com/cncf/toc/blob/main/process/graduation_criteria.md)): - -* Do we believe this is a growing, thriving project with committed contributors? -* Is it aligned with CNCF's values and mission? -* Do we believe it could eventually meet the graduation criteria? -* Should it start at the sandbox level or incubation level? - -Some details that might inform the above include: - -* Does the project have a sound, documented process for source control, issue tracking, release management etc. -* Does it have a documented process for adding committers? -* Does it have a documented governance model of any kind? -* Does it have committers from multiple organizations? -* Does it have a code of conduct? -* Does it have a license? Which one? Does it have a CLA or DCO? Are the licenses of its dependencies compatible with their usage and CNCF policies? - CNCF staff will handle the full legal due diligence. -* What is the general quality of informal communication around the project (Slack, GitHub issues, PR reviews, technical blog posts, etc)? -* How much time does the core team commit to the project? -* How big is the team? Who funds them? Why? How much? For how long? -* Who are the clear leaders? Are there any areas lacking clear leadership? Testing? Release? Documentation? These roles sometimes go unfilled. -* What is the rate of ongoing contributions to the project (typically in the form of merged commits). - -#### Users & Adopters - -* Who uses the project? Get a few in-depth references from 2-4 of them who actually know and understand it. Guidelines on identifying these can be found in the [FAQs](https://github.com/cncf/toc/blob/main/FAQ.md#what-is-the-definition-of-an-adopter). -* What do real users consider to be its strengths and weaknesses? Any concrete examples of these? -* Perception vs Reality: Is there lots of buzz, but the software is flaky/untested/unused? Does it have a bad reputation for some flaw that has already been addressed? - -#### Contributor experience - -* Besides the core team, how active is the surrounding community? Bug reports? Assistance to newcomers? Blog posts etc. -* Is it easy to contribute to the project as an external contributor? If not, what are the main obstacles? -* Are there any especially difficult personalities to deal with? How is this done? Is it a problem? -* Getting interviews with 2-3 external contributors is advisable for DD process, both from the community and technical perspective. It can help to identify technical depth in areas like extensibility, API design, and general code architecture. -* For more in-depth review of the contributor experience, consulting with [tag-contributor-strategy](https://github.com/cncf/tag-contributor-strategy) is always a good idea. - -#### Context - -* What is the origin and history of the project? -* Where does it fit in the market and technical ecosystem? -* Is it growing or shrinking in that space? Is that space growing or shrinking? -* How necessary is it? What do people who do not use this project do? Why exactly is that not adequate, and in what situations? -* Clearly compare and contrast with peers in this space. A summary matrix often helps. - Beware of comparisons that are too superficial to be useful, or might have been manipulated so as to favor some projects over others. - Most balanced comparisons will include both strengths and weaknesses, require significant detailed research, and usually there is no hands-down winner. - Be suspicious if there appears to be one. - -#### Other advice - -* Bring in other people (e.g. from your company) who might be more familiar with a - particular area than you are, to assist where needed. Even if you know the area, - additional perspectives from experts are usually valuable. -* Conduct as much of the investigation in public as is practical. For example, favor explicit comments on the - submission PR over private emails, phone calls etc. By all means, conduct whatever communication might be - necessary to do a thorough job, but always try to summarize these discussions in the PR so that others can follow along. -* Explicitly disclose any vested interest or potential conflict of interest that you, the project sponsor, - the project champion, or any of the reviewers have in the project. If this creates any significant concerns regarding - impartiality, it is usually best for those parties to excuse themselves from the submission and its evaluation. -* Fact check where necessary. If an answer you get to a question does not smell right, check the underlying data, or get a second/third opinion. diff --git a/process/graduation-proposal-template.md b/process/graduation-proposal-template.md deleted file mode 100644 index 225750b9d..000000000 --- a/process/graduation-proposal-template.md +++ /dev/null @@ -1,25 +0,0 @@ -# [Project] Graduation Proposal - -_**Insert introduction. See previous proposals for examples. This section should address from a broad perspective why the project feels they are ready to graduation and can state any major accomplishments or milestones.**_ - -## Graduation State Criteria -_**Project should address each graduation criteria listed below**_ - -### * Have committers from at least two organizations. - -### * Have achieved and maintained a [Core Infrastructure Initiative Best Practices Badge](https://bestpractices.coreinfrastructure.org/). - -### * Have completed an independent and third party security audit with results published of similar scope and quality as [this example](https://github.com/envoyproxy/envoy#security-audit) which includes all critical vulnerabilities and all critical vulnerabilities need to be addressed before graduation. - -### * Explicitly define a project governance and committer process. The committer process should cover the full committer lifecycle including onboarding and offboarding or emeritus criteria. This preferably is laid out in a GOVERNANCE.md file and references an OWNERS.md file showing the current and emeritus committers. - -### * Explicitly define the criteria, process and offboarding or emeritus conditions for project maintainers; or those who may interact with the CNCF on behalf of the project. The list of maintainers should be preferably be stored in a MAINTAINERS.md file and audited at a minimum of an annual cadence. - -### * Have a public list of Project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the Project website). For a specification, have a list of adopters for the implementation(s) of the spec. Refer to [FAQs](https://github.com/cncf/toc/blob/main/FAQ.md#what-is-the-definition-of-an-adopter) for guidelines on identifying adopters. - -## Incubation Details -_**Project should address each area listed below**_ - -### * Link to Incubation Due Diligence(DD) Document - -### * Address any concerns or recommendations from the TAG and/or TOC sponsor(s) from the DD Document diff --git a/process/graduation_criteria.md b/process/graduation_criteria.md deleted file mode 100644 index 38bc47c27..000000000 --- a/process/graduation_criteria.md +++ /dev/null @@ -1,45 +0,0 @@ -## CNCF Graduation Criteria v1.3 - -Every CNCF project has an associated maturity level. Proposed CNCF projects should state their preferred maturity level. A two-thirds supermajority is required for a project to be accepted as incubating or graduated. If there is not a supermajority of votes to enter as a graduated project, then any graduated votes are recounted as votes to enter as an incubating project. If there is not a supermajority of votes to enter as an incubating project, then any graduated or incubating votes are recounted as sponsorship to enter as a sandbox project. If there is not enough sponsorship to enter as a sandbox stage project, the project is rejected. This voting process is called fallback voting. - -The criteria for each stage of maturity are described below, and there is a separate [Project Proposal process](https://github.com/cncf/toc/blob/main/process/project_proposals.md). - -Incubating and graduated projects have access to all resources listed at [cncf.io/projects](https://cncf.io/projects) but if there is contention, more mature projects will generally have priority. - -### Sandbox Stage - -To be accepted in the sandbox a project must - -* Apply to join the sandbox using the [form](https://github.com/cncf/sandbox/issues/new?assignees=&labels=New&projects=&template=application.yml&title=%5BSandbox%5D+%3CProject+Name%3E) -* Adopt the CNCF [Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) -* Adhere to CNCF [IP Policy](https://github.com/cncf/foundation/blob/master/charter.md#11-ip-policy) (including trademark transferred) -* List their sandbox status prominently on website/readme - -See the [CNCF Sandbox Guidelines v1.0](https://github.com/cncf/toc/blob/main/process/sandbox.md) for the detailed process. - -### Incubating Stage - -*Note: The incubation level is the point at which we expect to perform full [due diligence](https://github.com/cncf/toc/blob/main/process/due-diligence-guidelines.md) on projects.* - -To be accepted to incubating stage, a project must meet the sandbox stage requirements plus: - - * Document that it is being used successfully in production by at least three independent direct adopters which, in the TOC’s judgement, are of adequate quality and scope. For the definition of an adopter, see https://github.com/cncf/toc/blob/main/FAQ.md#what-is-the-definition-of-an-adopter. - - * Have a healthy number of committers. A committer is defined as someone with the commit bit; i.e., someone who can accept contributions to some or all of the project. - * Demonstrate a substantial ongoing flow of commits and merged contributions. - * Since these metrics can vary significantly depending on the type, scope and size of a project, the TOC has final judgement over the level of activity that is adequate to meet these criteria - * A clear versioning scheme. - * Clearly documented security processes explaining how to report security issues to the project, and describing how the project provides updated releases or patches to resolve security vulnerabilities - * Specifications must have at least one public reference implementation. - -### Graduation Stage - -To graduate from sandbox or incubating status, or for a new project to join as a graduated project, a project must meet the incubating stage criteria plus: - - * Have committers from at least two organizations. - * Have achieved and maintained a Core Infrastructure Initiative [Best Practices Badge](https://bestpractices.coreinfrastructure.org/). - * Have completed an independent and third party security audit with results published of similar scope and quality as the following example (including critical vulnerabilities addressed): https://github.com/envoyproxy/envoy#security-audit and all critical vulnerabilities need to be addressed before graduation. - * Explicitly define a project governance and committer process. The committer process should cover the full committer lifecycle including onboarding and offboarding or emeritus criteria. This preferably is laid out in a GOVERNANCE.md file and references an OWNERS.md file showing the current and emeritus committers. - * Explicitly define the criteria, process and offboarding or emeritus conditions for project maintainers; or those who may interact with the CNCF on behalf of the project. The list of maintainers should be preferably be stored in a MAINTAINERS.md file and audited at a minimum of an annual cadence. - * Have a public list of project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the project website). For a specification, have a list of adopters for the implementation(s) of the spec. - * Receive a supermajority vote from the TOC to move to graduation stage. Projects can attempt to move directly from sandbox to graduation, if they can demonstrate sufficient maturity. Projects can remain in an incubating state indefinitely, but they are normally expected to graduate within two years. diff --git a/process/incubation-process.png b/process/incubation-process.png deleted file mode 100644 index c1ba7bd63..000000000 Binary files a/process/incubation-process.png and /dev/null differ diff --git a/process/project_proposals.md b/process/project_proposals.md deleted file mode 100644 index f03c131f1..000000000 --- a/process/project_proposals.md +++ /dev/null @@ -1,191 +0,0 @@ - -# CNCF Project Proposal Process v1.5 - -## Introduction - -This governance policy sets forth the proposal process for projects to be accepted into the Cloud Native Computing Foundation (“CNCF”). The process is the same for both existing projects which seek to move into the CNCF, and new projects to be formed within the CNCF. - -## Project stages - -![Project stages](project-stages.png) - -### Timelines - -#### Expectations - -The TOC makes no guarantees on if or when a project will join the CNCF or move levels. Projects apply for moving levels when they feel they are ready. However, what is ready for one project is not the same for another nor is each project’s adoption and maturity measurable against one another. For some projects it may be a long journey with the TOC to bring them to maturity for the kind of project they are and for others it may be shorter - it all depends on the individual project, their readiness, and the availability of the individuals responsible for various tasks in moving levels. - -When projects apply for moving levels, they do not move levels on a first-in first-out (FIFO) basis. Some projects join the Foundation when they are already far along in their journey and others join very early. They will approach maturity guide posts differently - at different times and in ways similar or different from others. We do our best to support projects moving levels, in some cases engaging with them frequently to ensure they are making progress on our initial findings but leaving the application open. In other cases, we review the project and finding nothing disparaging, only needing to refresh the content of the previous due diligence, evaluate against the next level of criteria, and move it forward. - -For sandbox proposals, applications are reviewed in the order the TOC chooses, most commonly returning applications first and then from oldest application to newest every two months. The TOC may not have time to get through every application each meeting as different project applications carry varying considerations and discussion topics to ensure enough information is discovered and explored to make an informed decision. The up to date list can be found [here](https://sandbox.cncf.io/) and will be carried over from meeting to meeting if not every project is reviewed. - -For moving levels to incubation or graduation, projects should plan on _at least 5 months or more_ between the initial application and approval. - -#### KubeCon+CloudNativeCon Freeze - -Due to the increased community demands around KubeCon + CloudNativeCon (KCCN), the scheduling and production of content, and reduced availability of individuals involved in moving levels, the TOC leverages a freeze for projects in process for moving levels. Even if a project is approved to move levels 3 weeks before this event, projects should _not_ expect to receive benefits beyond those afforded for the level they were previously at. For example, if a sandbox project is approved to move to incubation 3 weeks prior to the event, the project and the event staff will not have enough time to record, edit, and produce an incubating project update to have it included within the keynote stage reel. - -For each KubeCon + CloudNativeCon's (KCCN) standalone event (where KCCN is the focus, not a joint event with OSS Summit or other such conference) — currently Europe and North America — the following freeze is applied: - -__Within 6 weeks of the event__ - -* TOC members will not take on new sponsorship of applications for moving levels -* Many activities occur before, during, and after KCCN. Postponing new sponsorship until after KCCN reduces the likelihood that kicking off the process is overcome by such activities. - -__Within 2 weeks of the event__ - -* Public Comment will not open - * We want to ensure community members, adopters, and other stakeholders have time to participate in the public comment of projects, the 2 weeks leading up to the event are typically very busy for many individuals involved in the moving levels process. -* Voting for projects will not open - * Voting is an opportunity for community members to show support for projects, it is also the time when the TOC determines if the due diligence and state of the project support its promotion to the next level. As such it is essential for TOC members to have time to not only cast votes, but to consider any comments raised during the public comment period. The TOC is just as busy as any other attendee or speaker for KCCN, it is easy to miss the timeframes for voting and we want to ensure projects receive the attention in a vote they deserve. -* Open voting is paused - * While community members may continue to show support for projects, the TOC will officially pause our voting. -* No project announcements - * Even if a project has passed a vote, if they have not announced and officially moved levels, they will not be included as an incubating or graduated project. - -__2nd week following the event__ - -* Voting for projects who completed public comment may open and commence. -* The week immediately following KCCN is commonly reserved as a recovery and digest period for attendees, event staff, community members, and TOC. - -TOC members may choose to continue working with projects on due diligence within the weeks before and after KCCN subject to their and others' availability. Projects should take all of this into account when planning completion of their due diligence. We ask projects to be understanding and considerate of our availability constraints around KCCN and remind everyone that the TOC is not a full-time body, we have primary work commitments in addition to our involvement on the TOC and any projects, TAGs, or community groups we are involved in. - -As the CNCF chooses to create new standalone occurrences of KCCN, this freeze should be reviewed to ensure ample time is available to conduct activities to support project moving levels. It may include restricting to just two freezes a year, or a complete re-evaluation of the freeze in light of whatever changes have transpired. - -#### Additional information - -Q: Why doesn't the TOC get through the sandbox list every meeting? -A: There are currently many projects that want to be a part of the CNCF and it is the TOC's job to carefully consider if they are the right fit for the foundation. This deliberation takes time and there are only so many applications that the TOC can get through each meeting. If anything, a delay from one meeting to the next is a benefit for the project because it allows more time to build community support. - -Q: Exactly how long will it take my project to move levels once my application is in? -A: Just like in open source, it will get done when the work is done. This can range from 5 months to 15 months please coordinate with your TOC sponsor to keep everything on track. - -Q: Can my project still apply to move levels within 6 weeks of KubeCon? -A: Yes, though getting a TOC sponsor, conducting any due diligence, and any other steps of the process will be delayed until after KubeCon. - -Q: Why can't public comment periods or votes launch within 6 weeks of a KubeCon? -A: Undergoing due diligence is a non-insignificant amount of work. Conducting adopter interviews takes time and scheduling becomes increasingly difficult the closer to each KCCN we get. Being able to successfully complete due diligence to launch the public part of the process becomes very difficult as many community members have additional responsibilities related to the conference. By removing KCCN as a goal post for brand new requests to move levels, we hope to not burn out adopters, TOC, maintainers, and other community members. - -### Sandbox process - -**Note: The TOC has changed the sandbox application process to a more transparent and streamlined workflow within the :package: [Sandbox Applications repository](https://github.com/cncf/sandbox) :package:.** - -All exceptions and "declined" or "postponed" outcomes are handled by the TOC. Projects may be encouraged to re-apply after addressing areas called out in the application comments on the corresponding issue. Please refer to the instructions in the [Sandbox repo README](https://github.com/cncf/sandbox) for more details on re-application. - -![Sandbox process](sandbox-application-process-2022.png) - -#### Applying for Sandbox - * Projects apply for sandbox through the Sandbox Repo's *[Issue Form](https://github.com/cncf/sandbox/issues/new?assignees=&labels=New&projects=&template=application.yml&title=%5BSandbox%5D+%3CProject+Name%3E)*. More information on this process is found on the main [Sandbox repo page](https://github.com/cncf/sandbox). - -#### Annual Review of Sandbox projects - -Once in the Sandbox, projects are subject to an [Annual Review](https://github.com/cncf/toc/blob/master/process/sandbox-annual-review.md). - -#### Governance / legal issues* - * CNCF staff handle governance / legal issues - * Projects are encouraged to participate/attend TOC meetings and reach out to TAGs for advice or scheduling presentations and discussions. - -See the [Sandbox guidelines](https://github.com/cncf/toc/blob/main/process/sandbox.md) for the definition of and motivation behind the CNCF Sandbox. - -### General steps for moving levels: Incubation and Graduation - -While the details of the process are described in detail further for Incubating and Graduting proposals, the high level steps that occur when a project moves levels are as follows: - -* Applications to move levels is done in the form of a PR on the TOC repo - * Who: Project -* As prior applications are closed, the TOC selects the next project from the backlog. A TOC sponsor(s) is assigned and the project is moved to 'Due Diligence' or 'Active Review' on the project boards depending on which level is proposed. - * Who: TOC -* Coordination with project on Due Diligence creation/refresh - * Who: TOC Sponsor(s) and Project -* Due Diligence creation or refresh - * Who: TOC Sponsor(s), Project, TAG(s) -* Adopter Interviews are conducted, depending on the freshness of prior interviews the TOC may choose to not conduct further interviews or conduct others to ensure coverage by a variety of adopters to explore all facets of the project. The project is updated on the project board. - * Who: TOC Sponsor(s) and Adopters -* If multiple TOC members are sponsoring, they will conduct their own individual reviews and then coordinate with each other on overall observations, findings, and next steps. - * TOC Sponsors -* TOC sponsor(s) re-engages the project to discuss next steps, any blockers that prevent the project from moving, and any actions that need completed but are non-blocking. - * Who: TOC Sponsor(s) and Project -* Assuming all outstanding issues are resolved, the TOC opens an internal comment period, about 1 week, for other TOC members to perform an independent review and verify all areas of the project have been evaluated - * Who: TOC Sponsor(s) and TOC -* If no further issues are identified, the TOC sponsor(s) open the public comment period on the TOC mailing list. The project is updated on the project board to 'Public Comment' and **the public comment period is open for two weeks**. - * Who: TOC Sponsor(s) -* Provided no additional items are identified during the public comment period, the TOC opens voting on the mailing list shortly thereafter (usually about 2 days subject to availability). The project is updated on the project board to 'In Voting'. - * Who: Initiate - CNCF Support Staff for the TOC, Voting - TOC and community members -* If the vote passes, the results are emailed and the project is placed in the 'Done' state on the project board. - * Who: CNCF Support Staff for the TOC -* An announcement is made conveying the project name and its new level status. - * Who: CNCF - -#### Incubation process - -Note: We have [streamlined the Incubation process](https://docs.google.com/presentation/d/1J9nti4JdiwLHxY15KtkmqyfP4OgNfrLAd3vxPvFTzsc/edit?usp=sharing). - -All exceptions (and "no" outcomes) are handled by the TOC. - -![Incubation Process](incubation-process.png) - -##### Project Proposal - * Incubation proposed through a [GitHub pull request](https://github.com/cncf/toc/pulls) - * The proposal moves to Due Diligence when a TOC member steps forward as an Incubation Sponsor - Please avoid contacting TOC members individually to serve as project sponsor. - * The status of outstanding Incubation proposals is reported on a monthly basis in the TOC public meeting. This highlights projects looking for sponsorship, and provides a check-in on DD progress for sponsored projects. - * A potential sponsor can indicate that they are interested but don't have capacity to work on DD at this time, to set a project's expectations. - * The TOC may agree that the project does not (yet) meet the [Incubation requirements](https://github.com/cncf/toc/blob/main/process/graduation_criteria.md#incubation-stage) and give feedback on why this is the case. If the project is not already in the CNCF, the TOC may suggest that project apply for Sandbox instead. - * If a TOC Incubation Sponsor has not stepped forward within two months after the proposal PR is submitted, projects may request that their project proposal is discussed at a forthcoming TOC meeting by adding it to the [Working Doc](https://docs.google.com/document/d/1jpoKT12jf2jTf-2EJSAl4iTdA7Aoj_uiI19qIaECNFc/edit). The outcome of this is discussion is either that a sponsor steps forward, or that the TOC votes to admit the project to Sandbox, or the proposal is rejected (projects may reapply after six months). If, even after all those steps, a sponsor does not step forward, the proposal is rejected. - * DD will usually involve a presentation to a TAG, but an interested TAG is welcome to schedule a project presentation at any time. TAGs can discuss their recommendations or concerns about a project with their TOC liaison(s) if there isn't already a TOC Incubation Sponsor in place. - * Although it is not necessary, projects are allowed to informally reach out to TOC members for advice, including asking about potential sponsorship. TOC members should keep each other informed about these approaches so that we can avoid falling prey to "lobbying" (directly contacting a TOC member to volunteer or manage an action or issue). There is a fine line between a project asking for help to make a successful application, and a project shopping around looking to pressurize a TOC member into sponsorship. - -##### TOC Incubation Sponsor - * TOC Incubation Sponsor is responsible for driving the process, and co-ordinating with TAGs for review and input as they see fit. - * TOC Incubation Sponsor is a point of contact for the project throughout the process. - * TOC members may not sponsor a project for which they have a clear conflict of interest (for example, originating primarily from their organization). This doesn't mean that they can't have any involvement at all - for example, contributing pull requests, or being an [adopter](https://github.com/cncf/toc/blob/main/FAQ.md#what-is-the-definition-of-an-adopter) of that project, can signal a healthy interest in and knowledge of a worthwhile project. - -##### Due Diligence (2-3 months) - * TOC Incubation Sponsor drives due diligence (see the [template](https://github.com/cncf/toc/blob/main/process/dd-review-template.md) and [guidelines](https://github.com/cncf/toc/blob/main/process/due-diligence-guidelines.md)). - * TOC Incubation Sponsor can delegate DD work to CNCF TAGs and/or other TOC members. - * Typically DD includes a presentation to a CNCF TAG, as identified by the TOC Sponsor. This step may be omitted if the TOC Sponsor feels there are readily-available and suitable presentations on video - for example, because the TAG has already recently held a presentation. (We do not want unnecessary levels of process or bureaucracy to delay a widely-known and adopted project from joining the CNCF). TOC Sponsor has discretion to arrange alternatives (for example, arranging a Q&A session at a TOC meeting) to ensure there is ample opportunity to ask questions. - * TOC Incubation Sponsor can ask project maintainers to complete the DD template. (In practice project maintainers sometimes choose to make a start on this in advance of the official DD process, or even in advance of the initial proposal as it may help them ensure they meet all the requirements.) The TOC Incubation Sponsor should carefully review and ask questions about the DD as prepared by the project maintainers, and may also call on TAGs to help with this. - * CNCF staff do governance and legal DD. - * During DD some conversations may be held in private (e.g. adopter interviews where the adopter wishes to remain anonymous) and are documented using discretion. - * TOC members are not required to identify the kind of direct adopter an interviewed organization is, rather they should use their discretion and the guidelines defined in the [FAQs](https://github.com/cncf/toc/blob/main/FAQ.md#what-is-the-definition-of-an-adopter) for selected organizations to be interviewed and the nature of the interview as it best assists projects, this may include conducting a combined interview of direct and transitive adopters to ascertain maturity and interaction. - * TOC Incubation Sponsor confirms that project meets the [Incubation requirements](https://github.com/cncf/toc/blob/main/process/graduation_criteria.md#incubating-stage). - * TOC Incubation Sponsor determines when DD is “done”. DD documentation should then be on GitHub, open to public comment on record. - -##### Due Diligence review (2-6 weeks) - * TOC Incubation Sponsor announces on the TOC mailing list when the DD documents are available for public review and comment, which can take place on GitHub, the TOC mailing list, or at TOC public meetings. - * TOC Incubation sponsor decides when to call TOC vote, allowing at least two weeks for public comment before calling vote - -##### TOC vote (up to 6 weeks) - * TOC members assess whether project meets the [Incubation criteria](https://github.com/cncf/toc/blob/main/process/graduation_criteria.md#incubating-stage) - * Projects get accepted to incubation via a 2/3 supermajority vote of the TOC. - * If the vote is not conclusive after 6 weeks, TOC chair may extend vote, or conclude that silence = abstain - -#### Graduation process - -##### Submit Graduation Proposal Template - * Project fills out and submits the [graduation proposal template](graduation-proposal-template.md) in a pull request in the [cncf/toc GitHub repo](https://github.com/cncf/toc). - * The file containing the proposal should be located in [the graduation proposals directory](https://github.com/cncf/toc/tree/main/proposals/graduation). - * The proposal addresses how the project has grown since incubation and any concerns from incubation DD in addition to the standard graduation requirements. - * Projects will be reviewed on a rolling basis as they apply, instead of two meetings a year. - -##### Public comment -If a TOC member steps forward to support the project as a sponsor and determines the Graduation DD document is finalized, the TOC member kicks off two week period of time for public comment on the TOC mailing list. - * Please avoid contacting TOC members individually to serve as project sponsor. - * The email should contain a link to the proposal pull request and graduation DD document. - * All TAGs, adopters, TOC members, and community members are welcome to comment at this time on the mailing list. - * Historically, projects have done a TOC presentation as part of the graduation process. The TOC has gotten rid of the presentation requirement. -* If the TOC does not sponsor the project to move forward at that time, they will provide feedback to the project and the PR will be closed. -* If the Graduation DD document is not finalized, the TOC sponsor will begin the process to refresh the existing DD document and begin the public comment process. - -##### TOC vote - * TOC members assess whether project meets the [Graduation criteria](https://github.com/cncf/toc/blob/main/process/graduation_criteria.md#graduation-stage) - * Projects must have a 2/3 supermajority vote of the TOC to graduate - -#### Notes - -* TOC always has final discretion -* TOC doesn’t have to accept TAG recommendation -* Outcome may be “no” simply because sponsors don’t step forward within the timeframe -* Outcome from TOC Triage or TAG recommendation could be that we want to wait for some reason e.g. project backlogs; batching similar projects together. We should give the project an explanation and set time expectations in these cases. -* All “no” outcomes and other exceptions are discussed by the TOC, and then with project and TAG representatives. We will try to give feedback but it may simply be a lack of conviction in the project. -* If the project is concerned about the timeline, feels they have waited too long, or needs to reach out, please reach out to the TOC via one of their mailing lists or contact the CNCF Staff. -* Projects are encouraged to participate/attend TOC meetings and reaching out to TAGs for advice or scheduling presentations and discussions. diff --git a/process/sandbox-application-process-2022.png b/process/sandbox-application-process-2022.png deleted file mode 100644 index e552310f8..000000000 Binary files a/process/sandbox-application-process-2022.png and /dev/null differ diff --git a/process/sandbox-process.png b/process/sandbox-process.png deleted file mode 100644 index 5fd3aff4d..000000000 Binary files a/process/sandbox-process.png and /dev/null differ diff --git a/process/sandbox.md b/process/sandbox.md deleted file mode 100644 index a1cf4be8a..000000000 --- a/process/sandbox.md +++ /dev/null @@ -1,99 +0,0 @@ -# CNCF Sandbox Overview - -![CNCF Sandbox](https://raw.githubusercontent.com/cncf/artwork/main/other/cncf-sandbox/horizontal/color/cncf-sandbox-horizontal-color.png) - -The CNCF Sandbox is the entry point for early stage projects and has four goals: - -* Encourage public visibility of experiments or other early work that can add value to the CNCF mission and build the ingredients of a successful Incubation level project -* Facilitate alignment with existing projects if (and only if) this is desired -* Nurture projects (e.g. via CNCF [Service Desk](https://github.com/cncf/servicedesk) requests) -* Remove possible legal and governance obstacles to adoption and contribution by ensuring all projects adhere to CNCF legal, code of conduct and IP Policy requirements - -This document describes the Sandbox and provide clarity on what Sandbox projects stand for. - -## What is the CNCF Sandbox - -Sandbox projects should be early-stage projects that the CNCF TOC believes warrant experimentation. The Sandbox should provide a beneficial, neutral home for such projects, in order to foster collaborative development. We aspire to make the Sandbox the preferred path for early-stage projects to enter the CNCF. More mature projects can continue to jump directly to Incubation, but as the cloud-native ecosystem grows, we expect to see proportionally more early-stage projects. - -## Early Stage - -When we say that Sandbox projects are "early stage" this covers the following examples: - -1. New projects that are designed to extend one or more CNCF projects with functionality or interoperability libraries. -2. Independent projects that fit the CNCF mission and provide potential for a novel approach to existing functional areas (or are an attempt to meet an unfulfilled need) -3. Projects commissioned or sanctioned by the CNCF, including initial code for CNCF WG collaborations, and "experimental" projects -4. Any project that realistically intends to join CNCF Incubation in future and wishes to lay the foundations for that - -## Caveat Utilitor - -The CNCF hopes that all early stage projects will achieve the success they desire. And the organisation will help as appropriate. But certain caveats must be stated nonetheless. - -End users should treat early stage projects with care. It is expected that some Sandbox projects may fail. They may never move to the next maturity level. While many early projects are safe to try out, users must exercise their own judgment. Some projects may be alpha quality software. There is no guarantee of production readiness, users, or professional level support. Where projects enjoy the public support of one or more professional software organisations, those may be seed stage. In short: The CNCF Operating Principle about "no kingmakers" is of special importance in the Sandbox. - -## Routes out of the Sandbox - -There are several possible next steps for a project in Sandbox: - -* If it achieves sufficient momentum and maturity it can [apply for Incubation status](https://github.com/cncf/toc/blob/main/process/project_proposals.md#incubation-process) -* Based on alignment with another project, it might make sense to merge with or become part of another project within the CNCF. This would be done based on a consensus between project maintainers and the TOC that this is best for both projects. -* Some projects and experiments may fail, or otherwise reach a state where they should be moved into the [Archive](https://github.com/cncf/toc/blob/master/process/archiving.md) - -## Sandbox Governance and Benefits - -### Advantages of Sandbox vs non-Sandbox for new projects - -CNCF will remain fair and open to all projects no matter what their initial provenance. Should a project apply for CNCF Incubation, the TOC will use the same criteria regardless of origin. This means the TOC will not discriminate in favour of Sandbox projects vs. non-Sandbox projects. - -Therefore the advantages of being in the Sandbox apply prior to application for Incubation, ie.: - -1. That a project has a legally neutral home that is stable and known - -2. And that a project may attain Incubation-level success faster: - - 1. Due to public visibility and association with the CNCF mission - 2. Through alignment with other CNCF projects (if and only if desired) - 3. Via CNCF Service Desk etc. - -3. The CNCF will help projects adopt good principles of governance - -### Neutral Home - -A neutral home for your project increases the willingness of developers from other companies and independent developers to collaborate, contribute, and become committers. Neutrality requires that projects contribute their trademark to CNCF so that: - -* No company is favored over any other -* CNCF ensures project governance is transparent and fair for everyone. - -### Clarifying Marketing Expectations - -All open source projects in some sense enjoy a level of promotion from community, user enthusiasm, sponsoring organisations and so on. Please note that in this section we discuss marketing as a measurable financial investment into CNCF projects from the CNCF marketing budget and staff. - -To date the CNCF has invested in marketing to educate users and grow awareness of cloud native purpose and benefits, to foster community, and to accelerate production use of projects. These investments fall into at least three types: - -* Developer community support: hangouts, meetups, events and (some) conferences -* Digital marketing: help with online content, interactive tutorials, webinars, and social -* Product marketing: conference promotion, landscape, certification, case studies, AR/PR - -Since the Sandbox is for early stage, sandbox projects will receive minimal marketing support from the foundation. The Sandbox group as a whole may be promoted from time to time. - -The CNCF will lean towards developer community support and the CNCF service desk, to help discovery and initial steps towards CNCF Incubation. There will only be limited CNCF investment in Digital and Product marketing for individual Sandbox projects, and CNCF-funded content should be factual and informative. - -Some key points: - -* Sandbox projects will be listed separately from other CNCF projects (cncf.io/sandbox) -* They will not be prominently listed at our events or issued a press release -* Reviewed on an annual basis; submit a report to the TOC for review -* CNCF Sandbox projects can stay in the sandbox indefinitely - -### Application into Sandbox - -Projects apply through the Sandbox Repo's *[Issue Form](https://github.com/cncf/sandbox/issues/new?assignees=&labels=New&projects=&template=application.yml&title=%5BSandbox%5D+%3CProject+Name%3E)*. More information on this process is found on the main [Sandbox repo page](https://github.com/cncf/sandbox). -Frequency of reviews can be found on the [repo's README under "Frequency"](https://github.com/cncf/sandbox/blob/main/README.md#Frequency). - -### Project onboarding - -Once the TOC decides to accept your project with an official vote, a list of tasks will be generated for submitters to work on. Look for tags `project onboarding` and `sandbox` -to see [examples from previous projects](https://github.com/cncf/toc/issues?q=is%3Aissue+is%3Aopen+label%3A%22project+onboarding%22+label%3Asandbox) - -### Annual review - -Once in the Sandbox, projects are subject to an [Annual Review](https://github.com/cncf/toc/blob/master/process/sandbox-annual-review.md). diff --git a/process/sandbox.png b/process/sandbox.png deleted file mode 100644 index a312cba01..000000000 Binary files a/process/sandbox.png and /dev/null differ diff --git a/proposals/pull_request_template.md b/proposals/pull_request_template.md deleted file mode 100644 index 9586eeeff..000000000 --- a/proposals/pull_request_template.md +++ /dev/null @@ -1,23 +0,0 @@ -Thank you for submitting your project proposal to CNCF! - -Before you submit your project, please ensure that: -- [ ] Understand the project proposal process and reqs: https://github.com/cncf/toc/blob/master/process/project_proposals.md#introduction -- [ ] Understand the services available for your project at CNCF https://www.cncf.io/services-for-projects/ -- [ ] Ensure your project meets the CNCF IP Policy: https://github.com/cncf/foundation/blob/master/charter.md#11-ip-policy -- [ ] Has your project adopted open governing already? see http://opengovernance.dev - -If your project secures enough TOC sponsors or successful vote, you will be onboarded: -- [ ] Domain: transfer domain to CNCF/LF (ITx) -- [ ] Trademarks: transfer any trademark and logo mark assets over to the LF -- [ ] GitHub: ensure 'thelinuxfoundation' and 'caniszczyk' are added as initial org owners -- [ ] Artwork: Ensure logos present on https://github.com/cncf/artwork -- [ ] Website: ensure LF footer is there and website guidelines followed, analytics transferred -- [ ] Create maintainer list + added to aggregated https://maintainers.cncf.io list - OWNERS file needed -- [ ] Devstats: add to devstats https://devstats.cncf.io/ -- [ ] Marketing: update relevant intro + slide decks -- [ ] Trail Map: update CNCF trail map if relevant (incubating projects and above) -- [ ] Update https://landscape.cncf.io -- [ ] Events: update CFP + Registration + CFP Area forms -- [ ] ServiceDesk: confirm maintainers have read https://www.cncf.io/services-for-projects/ -- [ ] CNCF Welcome Email Sent to confirm maintainer list access -- [ ] Schedule monthly project sync with CNCF staff