Define what `lifecycle` stages are, and how we want to use them

Summary of a discussion had between myself and @Antoine-Lalechere @cjyetman @MonikaFu @jacobvjk

Lifecycle Stages

Maintainers need to understand and flag the lifecycle stage of a repository (experimental, stable, superseded, deprecated) and manage changes accordingly.

Stability and Change Management:

Repositories should have clear indications of their stability status. Maintainers must communicate significant changes, especially when those changes may impact the stability or expected behavior of the repository (and especially if it is known that that repository has many downstream dependencies/ is in production).

Retroactive Implementation:

There's a recognition that implementing lifecycle stages and maintainer roles is retroactive for many existing repositories, which requires careful consideration to avoid disrupting established workflows. e.g. Some of our code we may want to call "experimental" even though it is currently very much used in production.

Impact on Other Projects:

⁠Any changes in one repository should be made with an awareness of how they impact other related projects or repositories. Lifecycle states may help mitigate this, as we can aim to not have strong dependencies on code marked experimental.

Experimental Features in Stable Repositories

It's acceptable to have experimental functions within a stable repository as long as it's communicated in the documentation.

Input and Output Stability:

For repositories in production, it's especially important to maintain stable inputs and outputs, as changes could break downstream dependencies.