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

process/README.md

@@ -127,3 +127,7 @@ Based on this review the TOC will vote on whether to continue to sponsor the pro
 Additionally, the TOC might recommend that you apply for Incubation stage. This requires extra work and due diligence so it’s not a possible outcome to move directly to Incubation from this lightweight annual review.
 
 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 Guide Posts](project_guideposts.md) which projects may leverage as guiding points along their journey.

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_guideposts.md

@@ -0,0 +1,66 @@
+# Cloud Native Guide Posts
+
+Guide Posts are intended to outline guiding points that have assisted past cloud native 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. 
+
+If projects leverage these as steps towards increasing contributors, adopters, maturity, etc. they may find their path towards Graduation is more structured, clear, and achievable _however_ this is subject to each projects implementation, design, and community. Even after projects are Graduated, they may refer back to Guide Posts as a mechanism to continue sustaining their project in a manner anticipated by their community and adopters particularly as they experience change and turnover. The community is welcome to submit PRs to improve and add additional Guide Posts based on their experiences in maturing their projects.
+
+* The basics of security are underway
+  * Such as completion of a [self-assessment](https://github.com/cncf/tag-security/blob/main/assessments/guide/self-assessment.md)
+* Community meetings or active discussions are held
+  * Such as meeting via Zoom, capturing discussion notes, and occurring more than twice a quarter (or community.cncf.io!) 
+  * Such as use of GitHub discussions, issues, or a group messaging service (slack, wechat, etc.)
+* Community contributions are well guided
+  * Such as providing timely feedback on discussion from maintainers on PRs from community members
+* A second organization begins contributing
+  * Those contributions may begin path to maintainership
+* Begins to solidify a versioning schema and release cadence
+  * Such as providing a roadmap, long term planner, GitHub project board, or other document which defines project direction or initiatives that may align with releases
+  * Adopters may experience releases that begin to establish a pattern of regularity
+* Engaging a [Technical Advisory Group](/tags/README.md) for feedback on some portion of the project relevant to the domain the project primarily functions within (Networking, Storage, App Delivery, etc.)
+* A clearly discoverable governance doc exists that covers the basics of decision making, including who approves PRs and how committers/maintainers are chosen
+* An angel adopter 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 as helping the project reach momentum 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.
+* 3 angel adopters are using the project
+  * May be from different industry verticals
+  * May have differing use cases
+* Evolves and develops a robust set of governance documentation that defines how the project is managed, and its roadmap is determined, which considers maintainer turnover and organization/affiliation/company diversity. 
+  * [TAG Contributor Strategy](https://github.com/cncf/tag-contributor-strategy) has many great [governance templates](https://github.com/cncf/project-template).
+* May demonstrate its application, practice, and adjustments to its governance documentation as a result of regular project operations
+* A robust and mature security posture 
+  * Any of the following would assist in achieving this
+    * 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)
+* Documentation includes getting started guides, operating/administration instruction, security call-outs, and other core elements necessary to ease adoption
+* Providing information on performance and scalability for deployment options/configurations, autoscaling, or may provide benchmarks in these areas for comparison or evaluation
+* Captures use cases to showcase how it can be best used to solve common problems.
+  * These may leverage observations and concerns from adopters
+* Contribution and community documentation clearly defines expectations when contributing (to include non-code contributions)
+* Defining 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
+* Ensuring 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
+* Refreshing 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.
+* Engaging with a few Technical Advisory Groups to consider best practices across multiple technical and governance facets
+* 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
+* Maintains a dependency graph so adopters fully understand the complexity and risk of use
+* Has 3 or more adopters using the project in production
+* Planning activities to increase project adoption
+* Increasing regular contributors to the project
+  * Such as identifying potentional contributors from different organizations beyond the current adopters
+  * Setting goals to identify contributors that would be wonderful maintainters, and partnering with them to onboard
+* Regularly update governance documentation to accurately reflect changes to processes, staffing, roles, and activities as they occur
+  * May re-review as new maintainers come in or as other's move to Emeritus
+* Having a well established and exercised contributor growth ladder or other community construct to "build the bench" of maintainers or project leaders
+* Pursuing [Silver level](https://bestpractices.coreinfrastructure.org/en/criteria/1) of the [OpenSSF Best Practice Badge](https://bestpractices.coreinfrastructure.org/)
+* Maintaining an Adopters file which may record public production users and use cases to benefit other potential adopters and contributors
+* Periodically evaluate project health and practices
+  * Such as leveraging [CLOMonitor](https://clomonitor.io/)
+* Experiencing successful turnover in 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).
 
 ## Sandbox Governance and Benefits