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:

1. 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.
2. 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).

                      Image Added

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.

List of deliverables or work products

...