[WIP] What: Cloud Native Guide Posts Issue #961

process/README.md

@@ -127,5 +127,6 @@ Additionally, the TOC might recommend that you apply for Incubation stage. This
 
 It is fine for a project to stay in the Sandbox indefinitely while it is still active, but if a project has genuinely stalled we can save everyone’s effort by archiving it.
 
+# Maturity resources for projects at all levels
 
-
+The [CNCF Technical Advisory Groups](/tags/README.md) have a wide variety of resources available to assist projects in building communities, securing their projects, and applying best practices across a variety of domains like networking, app-delivery, and much more! In addition to these resources, the TOC has a collection of [Cloud Native Milestones](project_milestones.md) which projects may leverage as guiding points along their journey — from sandbox to beyond graduation.

process/archiving.md

@@ -10,7 +10,7 @@ When voting on a proposal to archive a project, TOC members may wish to consider
 
 To archive a project:
 
-* A proposal must be put forth to the TOC repo
+* A proposal must be put forth to the TOC repo in the [form of an issue](https://github.com/cncf/toc/issues/new?assignees=caniszczyk%2C+amye%2C+idvoretskyi%2C+jeefy&labels=archive&template=archived.md&title=%5BARCHIVE%5D+project)
 * 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

process/project_milestones.md

@@ -0,0 +1,73 @@
+# Cloud Native Milestones
+
+Milestones are intended to outline checkpoints for projects, that have assisted past projects as they grew and matured in the cloud native ecosystem. They are NOT requirements for moving between levels, please refer to [the graduation criteria](https://github.com/cncf/toc/blob/main/process/graduation_criteria.md) for requirements. 
+
+When leveraged, projects may find their path towards Graduation is more structured, clear, achievable, and allows them to reach maturity in a more robust and well understood manner. Milestones do not guarantee a project’s graduation within the CNCF, rather, they are a collection of key activities that have helped other projects achieve maturity, stability, and adoption. Even after projects are graduated, they may leverage milestones as a mechanism to continue sustaining their project in a manner expected by their community and adopters particularly as they experience change and turnover. The community is welcome to submit PRs to improve and add additional milestones based on their experiences in maturing their projects.
+
+## Sandbox
+
+Some milestones may not apply to all projects and should be leveraged as guiding points. Milestones are described as the desired state with examples for how to achieve this. They are not requirements.
+* Project has the basics of security underway
+  * Completion of the [self-assessment](https://github.com/cncf/tag-security/blob/main/assessments/guide/self-assessment.md)
+* Project holds community meetings or active discussions
+  * Zoom with meeting notes occurring more than twice a quarter (or community.cncf.io!) 
+  * Use of GitHub discussions, issues, or a group messaging service (slack, wechat, etc.)
+* Project guides community contributions
+  * PRs from community members receive timely feedback and discussion from the maintainers
+* Project has a second organization contributing
+  * May begin path to maintainership
+* Project begins solidifying a versioning schema and release cadence
+  * A roadmap, long term planner, GitHub project board, or other document clearly defines project direction or initiatives that may align with releases
+  * Releases begin to establish a pattern of regularity
+* Project has engaged a [Technical Advisory Group](/tags/README.md) for feedback on some portion of the project relevant to the domain
+* Project has a clearly discoverable governance doc that covers the basics of decision making, including who approves PRs and how committers/maintainers are chosen
+* Project has an angel adopter that assists in stability and production use or deployment
+  * An angel adopter is a very early adopter of a cloud native project. They are invaluable to a projects growth and first experience in interacting with adopters. They often are characterized helping the project reach momentum towards incubation through:
+    * higher level of engagement with the project 
+    * ongoing injection of feedback and support via issues and contributions
+    * expertise or experience on traditionally difficult challenges for early stage technical development, performance, etc.
+* Project has 3 angel adopters
+  * May be from different industry verticals
+  * May have differing use cases
+* TBD - add more!
+
+## Incubation
+
+Incubation milestones are guiding points to highlight success areas a maturing project can accomplish before Graduation. They are not requirements. Not all Incubating projects will achieve every milestone, however many successful graduated projects have demonstrated these milestones prior to their Graduation. How each project achieves some or all of these milestones will vary widely. Projects do not need to meet this in order to graduate, rather these assist projects in meeting the Graduation criteria.
+* Project is evolving and developing a robust set of governance documentation that defines how the project is managed, and its roadmap is determined, which considers maintainer turnover and company diversity. [TAG Contributor Strategy](https://github.com/cncf/tag-contributor-strategy) has many great [governance templates](https://github.com/cncf/project-template).
+* Project can demonstrate its application, practice, and adjustments to its governance documentation as a result of regular project operations
+* Project has a robust and mature security posture which could be achieved by one or more of the following:
+  * Threat model
+  * [Joint review](https://github.com/cncf/tag-security/tree/main/assessments#components-of-the-security-review-package)
+  * [Passing level](https://bestpractices.coreinfrastructure.org/en/criteria/0) of the [OpenSSF Best Practice Badge](https://bestpractices.coreinfrastructure.org/)
+    * Note: Completion and maintenance of **an** OpenSSF Best Practice Badge is [a requirement for graduation](https://github.com/cncf/toc/blob/main/process/graduation_criteria.md#graduation-stage)
+* Project documentation includes getting started guides, operating/administration instruction, security call-outs, and other core elements necessary to ease adoption.
+* Project provides information on performance and scalability for deployment options/configurations, autoscaling, or may provide benchmarks in these areas for comparison or evaluation
+* Project captures use cases to showcase how it can be best used to solve common problems.
+  * These may leverage observations and concerns from adopters
+* Project contribution and community documentation clearly defines expectations when contributing (to include non-code contributions).
+* Project defines a process to “build the bench” of maintainers and project leaders such as a Contribution Ladder which considers succession planning and getting maintainers from multiple organizations
+* Project ensures all sub-projects are clearly defined in their maturity level, whether they ship with the core project or can be used independently but is subject to the same governance processes
+* Project refreshes their long term planning with a reasonable cadence
+  * Long term planning can be a roadmap, vision/feature goals, GitHub project board, etc.
+  * Long term planning is an open and transparent effort by the project to describe their intended future work and is subject to change
+  * Long term planning is leveraged as part of the evaluation for moving levels, it is often leveraged by potential adopters to schedule or plan for adoption if a particular feature is wanted, and also helps communitiy members identify where they can contribture or align their interests.
+* Project has engaged with a few Technical Advisory Groups to ensure they are considering best practices across multiple technical and governance facets
+* Project has defined a process for managing the conduct of its community, either establishing its own group to do this, leveraging the existing leadership, or deferring to the CNCF
+* Project maintains a dependency graph so adopters fully understand the complexity and risk of use
+* Project has 3 or more adopters using the project in production to support completion of Due Diligence and adopter interviews
+* Project plans activities to increase project adoption trajectory 3 adopters
+* Project has more than 5 regular contributors, more than half of which are from different organizations
+* TBD - add more!
+
+## Graduation
+
+Graduation milestones are guiding points to highlight continuing success areas for highly mature project after they graduate. They are not requirements. Not all Graduated projects will achieve or perform these milestones, however many robust and mature projects will adopt these milestones as "regular business" to maintain the health and growth of the project and its community.
+* Project regularly updates its governance documentation to accurately reflect changes to processes, staffing, roles, and activities
+* Project has a well established and exercised contributor growth ladder or other community construct to "build the bench" of maintainers or project leaders
+* [Silver level](https://bestpractices.coreinfrastructure.org/en/criteria/1) of the [OpenSSF Best Practice Badge](https://bestpractices.coreinfrastructure.org/)
+* Project has an Adopters file and may record public production users and use cases
+* Project periodically evaluates their project health and practices.
+  * Projects may leverage [CLOMonitor](https://clomonitor.io/) for this information
+* Project has demonstrated turnover in its leadership that showcases adherence to their governance
+* TBD - add more!

process/sandbox.md

@@ -35,7 +35,7 @@ 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)
+* 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). See [sandbox departures](#sandbox-departures) for more information.
 
 ## Sandbox Governance and Benefits