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

Introduce a status indicator into the governancemodel #49

Open
zorp opened this issue Jun 19, 2024 · 14 comments
Open

Introduce a status indicator into the governancemodel #49

zorp opened this issue Jun 19, 2024 · 14 comments
Assignees

Comments

@zorp
Copy link
Member

zorp commented Jun 19, 2024

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
Copy link
Member Author

zorp commented Jun 21, 2024

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

@janhalen
Copy link
Member

janhalen commented Jun 25, 2024

@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
Copy link
Member Author

zorp commented Jun 25, 2024

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
Copy link
Member

janhalen commented Jun 25, 2024

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
Copy link
Member

@janhalen
Copy link
Member

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
Copy link
Member

janhalen commented Jun 25, 2024

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
Copy link
Member

janhalen commented Jul 2, 2024

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 janhalen added this to the Template revision 1.2 milestone Jul 2, 2024
@janhalen janhalen self-assigned this Jul 2, 2024
@janhalen
Copy link
Member

janhalen commented Jul 3, 2024

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
Copy link
Member

janhalen commented Jul 4, 2024

@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
Copy link
Member Author

zorp commented Jul 4, 2024

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

@janhalen
Copy link
Member

Os2Compliance has volunteered to be a pilot project for this.

https://github.com/OS2compliance/OS2compliance

@janhalen
Copy link
Member

This should be added to the product template os2produkt.

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

@janhalen
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants