Introduce framework of maturity levels for different assets within a project organization

[anvega]

As CNCF projects grow, the project can and will be comprised of a handful of software projects and repositories within its GitHub organization. As these projects may vary in their respective levels of maturity, it is important for end users to have a strong sense of what to expect prior to adopting or deploying them.

Based on the model of the SPIFFE Project Maturity Phases on the maturity phases of the various projects that share the same overarching GitHub organization, I'd like to propose for Incubated and Graduated projects to follow the same or similar model for their different code assets.

An added benefit of the phases framework has brought the project team is the framing to holistically reason and the language to discuss deprecating and archiving components that are no longer maintained and have reached their end of life.

For illustration, the baseline of phases of maturity the project team identified indicate the level of reliability and scale at which a particular project or sub-project is known to support:

• Development: The software is still under active development, and many efforts are exploratory. APIs and interfaces may change rapidly and without warning. Use this software for development and proof of concept purposes, but stability and longevity is not guaranteed.

• Pre-Production: The software is relatively stable and being used to solve real problems. APIs and interfaces may change, but effort will be made to consider compatibility. Use this software for integration investigation and technology evaluation. Some early adopters may choose to run this software in production, however it is not recommended. Deprecation of this software is unlikely.

• Production: The software is stable and being used in production at scale. APIs and interfaces have compatibility guarantees. Use of this software is safe for mission critical purposes. Deprecation of this software will be performed on a years-long time scale.

• Deprecated: The software is no longer maintained, and may or may not continue to fill its intended purpose. While API stability is assumed due to lack of development, compatibility with other components is not guaranteed and likely to break in due time. Use of this software is not recommended.

Every stage has an embeddable badge to display on readme files:

With the burgeoning number of projects in the landscape, such initiative across all Incubated and Graduated projects could help yield clarity for contributors and end users alike around varying maturity guarantees.

[dims]

@anvega thanks! yep this is model we started advocating for with open telemetry

• https://opentelemetry.io/docs/reference/specification/status/
• https://github.com/open-telemetry/opentelemetry-collector#stability-levels

[anvega]

Great to see one more project embrace the model.

How do we get more projects to do the same?

Should language be introduced to process to process in the Stages - Definitions & Expectations in Process section describing maturity levels for subprojects as an expectation?

[caniszczyk]

Is there a way we could build a tool to help with this, similar to https://bestpractices.coreinfrastructure.org/en ?

…

On Sat, Feb 11, 2023 at 1:06 PM Andres Vega ***@***.***> wrote: Great to see one more project embrace the model. How do we get more projects to do the same? Should language be introduced to process to process <https://github.com/cncf/toc/tree/main/process> in the Stages - Definitions & Expectations in Process <https://github.com/cncf/toc/tree/main/process#ii-stages---definitions--expectations> section describing maturity levels for subprojects as an expectation? — Reply to this email directly, view it on GitHub <#1009 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAPSIJWW243MVRC2DHBBPDWW7PKRANCNFSM6AAAAAAUYZPHGU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Cheers, Chris Aniszczyk https://aniszczyk.org

[dims]

@anvega let's get folks to start thinking this way for sure. yep as @caniszczyk mentioned, we need to figure a bunch of stuff.

• who gets to label it?
• when do we label things?
• what's the approval process?
• where do we document what they mean?
• do we standardize it?
• what are the levels?
  ...

+1 to get folks to chime in. we can put this on the toc agenda too.

[monadic]

I like this idea. Projects could adopt it voluntarily. I don't think it should be imposed on projects and I don't think there would need to be an external approval process.

[mattfarina]

This reminds me of a project I worked on in the past. Same idea even though the labels were slightly different.

I like the idea of having badges to convey maturity.

I wonder what badges we should have? For example, when Flux v1 was still around and in maintenance mode while Flux v2 was set to take its place. It wasn't deprecated. What badge would have served that?

[monadic]

Paging @hiddeco who may be able to offer a view on this question about flux1

[hiddeco]

I absolutely do recognize that for a non-engineer it may be overwhelming to recognize the stage at which a (sub-)project is at.

On the other hand, if proper SemVer and API versioning is maintained, and release cadence is documented, this should theoretically be sufficient to cover for any of the stages documented here. Which would make this (yet another) "checking the boxes" (bureaucracy) add-on at the cost of time which does not actually go in to developing a project. While decreasing the flexibility a project has to do as they think is best for the project and its users.

Given this, I am in favor of this as a way to help projects to define and advertise their maturity if they feel this need. But would not make this a requirement.

I wonder what badges we should have? For example, when Flux v1 was still around and in maintenance mode while Flux v2 was set to take its place. It wasn't deprecated. What badge would have served that?

When we started working primarily on Flux v2, we first posted a "maintenance mode" issue which was pinned for a long period of time. At a later stage, this got updated with upgrade instructions in the README.md. This was also accompanied with extensive links on our website (e.g. banner in header) to make people aware, and guide them from v1 to v2 documentation.

I think this could be seen as a "sunset" phase, in which the project is going from production into deprecation after a period of time.