The candidate list of badges proposed in Candidate List of Badges and Associated Project Lifecycle Stages are now somewhat obsolete, given the specific health indicators that can be tracked in a quantitative manner using OpenSSF scorecards as shown by David Enyeart in the following meeting (see Meeting Minutes.)
The need for extra badges, along with the additional overhead their maintenance will impose on maintainers as well as the TOC, is not apparent now. But the need for clear-cut criteria for lifecycle transitions (forward or regression) for projects is still necessary.
Based on the new project lifecycle diagram created by the TOC in December 2023, here is an initial set of criteria for discussion.
Transition Criteria Mapping to OpenSSF Scorecard Criteria
Legal → License (10 is pass, anything below is fail)
Diversity → Consider the "Contributors" metric (need to do research on what's an appropriate threshold, and also if we can tweak the parameters), also the diversity of maintainers (try a GitHub action to parse the MAINTAINERS.md file; as a fallback, the TOC will manually inspect.)
Release → Packaging (OpenSSF seems to give a 10 easily here, based on a single publish action, so perhaps we should consider this a soft criteria and mandate the highest score), also timeliness of releases using major and minor version numbers (use a script/action that checks time since last release, then use a threshold). (Consider adding such scripts to the TOC repo so any member can run it when required for reviews and evaluations.)
Testing and CI/CD → CI Tests (think about this one, if 10 is easily attainable, maybe mandate that; perhaps require a code coverage action and pick a threshold to exceed)
Security → Dangerous Workflow (require a 10), Token Permissions (require a 10)
(How do we enforce a particular version of the scorecard? Perhaps mention whenever an upgrade is due on the maintainers' Discord channel and expect that the maintainers of each project will submit a PR to upgrade the scorecard GitHub action.)