Introduce a status indicator into the governancemodel

[zorp]

There is no clear way to see the life-cycle status of a product no matter what governance level. We should introduce an indicator making it clear to everyone if a product is active, inactive or deprecated.

I suggest we elaborate on the terms:

• Active
• Inactive
• Deprecated
• Frozen
• Archived

In danish:

• Aktivt: Softwaren er i aktiv udvikling, og der foregår løbende arbejde på den.
• Inaktivt: Softwaren er ikke længere under aktiv udvikling, men den er stadig tilgængelig og kan bruges.
• Forældet: Softwaren er forældet, og det anbefales at bruge alternative løsninger.
• Frosset: Softwaren er midlertidigt stoppet i udvikling, men kan stadig bruges.
• Arkiveret: Softwaren er ikke længere vedligeholdt og bør ikke bruges i nye projekter.

[zorp]

Mayby Inactive (inaktivt) should be called Maintained (vedligeholdes) to use a less negative word.

[janhalen]

@zorp Very relevant, and it would be an important tool in reaching the ambitions of the Board after our discussion about the state of our projets on the Boardmeeting the 24.jun 2024

Instead of inventing (and maintaining) our own we could adopt and contribute to an already maintained standard, like the CNCF.

https://github.com/cncf/toc/tree/main/process

Adopting a more standardized set of life cycle states would potentially bring the benefit of convering with upstream methods of handling applications life cycles at a later stage. E.g. via Keptn or other modern lifecycle toolkits. https://github.com/keptn/lifecycle-toolkit

[zorp]

I agree on adopting an already maintained standard like the CNCF.

My only worry is that the nature of OS2-products will leave us missing a status for that in-between face where a project have left the graduated status and started turning old (legacy) but is not yet archived.

[janhalen]

It does seem like, though that there is space for development and documentation efforts (with focus on transistioning) in the "Archived" status: https://github.com/cncf/toc/blob/main/process/archiving.md

The status, signifies no more official support and no official recommendations to adopt the project.. So it is not the same as an archived repository on GitHub.

But i agree that the title might cause confusion and needs to be very well described. Maybe the danish description could be something along the lines of "Uvedligeholdt"

The Linux Foundation has a "Core" stage that might have a better strategic fit?

https://www.linuxfoundation.org/blog/blog/the-lifecycles-of-open-source-projects

[janhalen]

The LF description of the archiving phase: https://www.linuxfoundation.org/resources/open-source-guides/winding-down-an-open-source-project

[janhalen]

We could revitalize the governance levels 1 - 2 -3 to Sandbox, Incubation and Graduated - Products outside these levels are either archived/in maintenance mode (Called Core in the LF model) or a project without the OS2 name.

[janhalen]

We could introduce som metrics to help place the product in the categories.

Thresholds should be established.

How many github releases pr. year?
How many commits pr. month / week?
How many active contributors?

Maybe even:
Contributor Data: This includes the number of active contributors, the diversity of the contributors, and the growth of the contributor base over time2.

Responsiveness: This measures how quickly the project community responds to questions, issues, or merge requests2.

Release Frequency: The number of releases per year can indicate the project’s activity level2.

Change Request Closure Ratio: This is the ratio of merged change requests to the total number of change requests2.

Commits Frequency: The number of commits per month or week can also be a good indicator of the project’s health2.

This will presumably result in a lot of "false negatives" until the release and commit process is standardized by following our governance model

[janhalen]

Is the https://github.com/coreinfrastructure/best-practices-badge a good strategic fit for these evaluations?
If so a method for badging allready exists: https://shields.io/badges/cii-best-practices

With https://github.com/chaoss/augur to create a way to evaluate the stats

The simple 4 step data model: https://chaoss.community/kb/metrics-model-starter-project-health/

We could start out simple with a "Healthy" and "Active" status indicator divided into "traffic light" buckets..

💚 Green (Active): Regular updates and active maintenance.
🟡 Yellow (Infrequent): Updates are made, but not regularly or often.
🔴 Red (Dormant): No recent updates, but could potentially become active again.
⚫ Black (Abandoned): No updates for a very long period of time, or explicitly abandoned.

[janhalen]

A definition of "Maintained" from the OpenSFF:
https://best.openssf.org/Concise-Guide-for-Evaluating-Open-Source-Software

Is it maintained? Unmaintained software is a risk; most software needs continuous maintenance. If it’s unmaintained, it’s also likely to be insecure.
Has significant recent activity (e.g., commits) occurred within the last year?
When was its last release (was it less than a year ago)?
Is there more than one maintainer, ideally from different organizations?
Are there recent releases or announcements from its maintainer(s)?
Does its version string indicate instability (e.g., begin with “0”, include “alpha” or “beta”, etc.)

[janhalen]

@zorp: Suggestion, we could make at fast, small PoC for evaluating "Activity" in broader sense using a badging solution. Like https://github.com/badges/shields

It could be done in the Project template or in this goverance template?

If it delivers the right value, we can go for a broader implementation?

[zorp]

I think that is a great suggestion and the right approach. How and when can we do it?

[janhalen]

Os2Compliance has volunteered to be a pilot project for this.

https://github.com/OS2compliance/OS2compliance

[janhalen]

This should be added to the product template os2produkt.

Furthermore @zorp, please copy the Markdown code into a tool repo of your choice.

[janhalen]

@zorp: Alternatively we could collaborate here in the sandbox, maybe it could serve as a start for a full product catalog one day?