Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 10 commits into from
3 changes: 2 additions & 1 deletion process/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
2 changes: 1 addition & 1 deletion process/archiving.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
64 changes: 64 additions & 0 deletions process/project_milestones.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
# Cloud Native Milestones

Milestones are intended to outline checkpoints for projects, that have assisted past projects as they grew and mature 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.
TheFoxAtWork marked this conversation as resolved.
Show resolved Hide resolved

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 works with an angel adopter
TheFoxAtWork marked this conversation as resolved.
Show resolved Hide resolved
* Partners closely with the project to address organizational needs of the project early on
* Project has a second organization contributing
* May begin path to maintainership
* Project begins solidifying a versioning schema and release cadence
* A roadmap or other document clearly defines project direct 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 and how to earn permissions to approve pull request, sometimes referred to as "the commit bit"
TheFoxAtWork marked this conversation as resolved.
Show resolved Hide resolved
* Project has an angel adopter that assists in stability and production runtime or deployment
* Project has 3 angel adopters
* May be from different industry verticals
TheFoxAtWork marked this conversation as resolved.
Show resolved Hide resolved
* May have differing use cases
* TBD - add more!
TheFoxAtWork marked this conversation as resolved.
Show resolved Hide resolved

## 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 has a robust set of governance documentation that defines how the direction of the project is decided upon and managed which considers company diversity in decision making. [TAG Contributor Strategy](https://github.com/cncf/tag-contributor-strategy) has many great [governance templates](https://github.com/cncf/project-template).
TheFoxAtWork marked this conversation as resolved.
Show resolved Hide resolved
* 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 **a** OpenSSF Best Practice Badge is [a requirement for graduation](https://github.com/cncf/toc/blob/main/process/graduation_criteria.md#graduation-stage)
TheFoxAtWork marked this conversation as resolved.
Show resolved Hide resolved
* 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 roadmap planning with a reasonable cadence
* 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
* 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 reviews it's governance process annually for improvements to improve clarity, consistency, and inclusivity
TheFoxAtWork marked this conversation as resolved.
Show resolved Hide resolved
* Project has a well established and exercised contributor growth ladder or other community construct to "build the bench" of maintainers or project leaders
TheFoxAtWork marked this conversation as resolved.
Show resolved Hide resolved
* [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
* TBD - add more!
15 changes: 14 additions & 1 deletion process/sandbox.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down Expand Up @@ -91,3 +91,16 @@ Frequency of reviews can be found on the [repo's README under "Frequency"](https
### 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).

### Sandbox archival
TheFoxAtWork marked this conversation as resolved.
Show resolved Hide resolved

Upon entering sandbox, projects are very early and often experimental. Not all projects that enter the sandbox will leave the sandbox to move on to incubation. Some projects may enter the sandbox and not grow or see widespread adoption or interest. This could be the result of a number of factors, such as being too early in the market, the problem targeted is being addressed in other ways, etc.

The following criteria are leveraged by the TOC to identify when a Sandbox project is no longer viable and is not expected to move to incubation. The TOC will consider any of the criteria or a combination of them for Archival evaluation.
* Missed Annual review by more than two months
* Stale contributions over the course of 18 months - stale contributions include non-significant contributions (minor changes like color in the UI, or grammar corrections), lack of contributions, little discussion or activity on issues, etc.
* Missed reasonable [milestones] - subject to the nature of the project, project may miss milestones a reasonable person would assume to have been completed considering other factors about the project.
* Project has existed in sandbox for 4 years with little traction by adopters

Sandbox projects identified for archival will adhere to the project [archival process](https://github.com/cncf/toc/blob/master/process/archiving.md) with the defined criteria listed in the issue when filed.