(See Project Lifecycle Transitions based on OpenSSF Scorecard for the latest updates on this Task Force’s activities.)

Introduction, Principles & Recommendations

Goals and Approaches

How do we accurately and comprehensively represent the stages of a Hyperledger project's lifecycle in order to make accurate assessments about a project's health and make appropriate decisions on its future trajectory?

Broadly, there are two approaches we can take:

Augment the current project lifecycle with a set of review labels (each associated with a review criteria), and rename or split/merge states as appropriate, so that the process and criteria for each state transition is clear and unambiguous.
Use a badging system whereby each project will be issued a badge (objectively) attesting to a certain set of attributes or criteria that the project is deemed to have met. Each stage in the lifecycle will then be represented by a set of badges, and stage transition criteria will clearly state what badges are needed for a project to progress to the next stage in its life.

(For reference and links, see the Badging/Lifecycle Task Force Issue in the Hyperledger TOC repo.)

Comparison of the Hyperledger and Linux Foundation Networking Lifecycles

As mentioned in the task force proposal, it is instructive to view the Hyperledger project lifecycle with the Linux Foundation Networking project lifecycle (see the "Project State Transitions" section for the latter).

Observations/questions:

The LF Networking lifecycle has well-articulated review criteria for stage transitions, both forward and backward in the lifecycle.
EOL means that the project is archived, right? Though presumably it can be resurrected and can go through the Proposal phase again if there is community interest, just like an Archived project can in the LFN.
Is there a real need for a Deprecated stage? If the project is not being maintained in that stage, isn't it effectively at its EOL?
Should there be a Dormant → Graduated option? Presumably if a Graduated project turned Dormant, it still meets the code and repository organization criteria.
LFN specifies a list of Badges, but unlike the Hyperledger discussion around badging, LFN badges are issued to people (maintainers) and not projects.

Comparisons:

LFN lifecycle seems to accommodate Labs (if we consider an HL Lab to be the equivalent of a Sandbox) which the HL lifecycle does not.
HL stages separate project quality/maturity and frequency of activity (hence, a "Dormant" stage) whereas the LFN lifecycle does not.
HL lifecycle has some automated (i.e., purely based on time or inaction) stage transitions (Graduated → Dormant, Deprecated → EOL) whereas the criteria of every LNF lifecycle stage transition is defined using a review label, criteria, and process.
LFN has both a TAC and a Board, and each review is first conducted by the TAC, which makes a recommendation to the Board.

What Hyperledger can/should borrow from the LFN lifecycle:

Incorporate review labels and processes, both forward and reverse.

Recap of Earlier (2020-21) Discussion and Determinations on Badging

Proposals to assign badges to Hyperledger projects were discussed by the TSC in 2020-21, and recommendations were made.

Badges and the criteria for a project to acquire them were described in an HL Wiki page. Here is the list:

Legal
Decentralized (Diversity)
Release
Testing
Documentation
Alignment
Infrastructure
CII
(We can also add badges for Security Vulnerability compliance. I think we can extract other badges from the current Project Best Practices document.)

The process of acquiring badges was also described in an HL Wiki page. It was recommended that the maintainers self-certify their projects for a given badge, after which there could be an open discussion among Hyperledger contributors and that project's maintainers. Any disagreements would come up before the TOC, which would rule on the appropriateness of the certification (i.e., allow the badge to be retained or have it revoked.) Some badges would have renewal requirements (depending on the continual compliance of the project with the badge's criteria) whereas others could be used in perpetuity.

Discussion/Recommendations

Augmentation of the HL project lifecycle graph: we need to incorporate review labels, criteria, and processes.
We need to specify a list of forward and reverse review criteria and processes.
Badges seem like a good idea to indicate the health of a project, but if we do use them, they ought to co-exist with the (augmented) lifecycle graph and not replace it.
If we do use badges, is self-certification a good idea? Or should badges be requested, and awarded (or rejected) after a TOC review? (The latter will impose a lot of overhead on the TOC)
We need to incorporate Hyperledger Lab projects into the lifecycle chart. The process for a Lab that seeks to become a full project is clear; it must begin at the Proposal stage. But the process for a Lab to join or merge with an existing HL project is unclear. Currently, it is left to the discretion of the maintainers (as happened with the Cactus-Weaver merger). It is also not clear whether a Lab must meet Incubation Exit Criteria before it can join a Gaduated project.
If we use badges, would Lab projects also qualify for them or just full HL projects?

List of deliverables or work products

OpenSSF Scorecard slides

Task Forces

Badging/Lifecycle Task Force

Introduction, Principles & Recommendations

Goals and Approaches

Comparison of the Hyperledger and Linux Foundation Networking Lifecycles

Recap of Earlier (2020-21) Discussion and Determinations on Badging

Discussion/Recommendations

List of deliverables or work products

Time to complete

Leader

Initial participant list

Chat Channel

References