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

[jdhoffa]

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.

[jdhoffa]

Thanks @cjyetman:

R pkg {lifecycle} has pretty good descriptions of lifecycle stages/states:
https://lifecycle.r-lib.org/articles/stages.html

[AlexAxthelm]

Adding to the lifecycle discussion, I'm also a fan of the repostatus.org badges, which communicate something different than R's lifecycle badges.

The R lifecycle paradigm is useful for talking about the API of an R package (including being able to communicate the lifecycle status of functions and arguments), but seems limiting when talking about a whole repo.

In particular the Concept, WIP, and Active/Inactive repo labels seem useful to indicate an overall status of where we are with a repo, beyond "Stable/not stable"

https://www.repostatus.org/lifecycle

[jdhoffa]

Adding my two cents as well, I wonder if the above may be overly complicated.

e.g. What is the actionable difference between "Concept" and "WIP"? Could "Active" and "Inactive" not just be indicated by if the repository is archived or not?

Let us discuss it in a future DevHangout, but my personal preference is to limit any tags/ badges to those that crucially convey some bit of "actionable" insight while stripping away any unnecessary flourishes.

But perhaps that is "too lean" :-)