Page tree
Skip to end of metadata
Go to start of metadata


OutcomeThis proposal was deprecated in favor of a broader one: What if a top level project does not meet its charter goal?
Minutes Link2020 12 03 TSC Minutes

Overview of Proposal

According to the resolution of Subprojects and project proposals, "A new project proposal that is a feature unique to an existing project will be guided to that existing community to see about joining it." This resolution lets proposals that aim at supporting or being used by several other projects to stand on their own. However, sometimes, for various reasons and possibly despite all the goodwill of the community involved, the project never meets that goal and ends up being tied to a single other project, within Hypeledger and beyond.

There are several costs associated with "top level projects": they are prominently featured on the Hyperledger website, they benefit from communication services, security audits, etc, and the large number of Hyperledger projects and their unobvious dependencies is confusing.

The proposal is therefore to have projects that had the ambition to serve or support several other projects but are effectively only used in conjunction with a single other project be rolled into that related project after 18 months. It should be noted that this is similar to what was done for several Fabric related projects per the resolution of Subprojects house keeping.

Formal Proposal(s)

Projects that have been in Incubation for over 18 months and are effectively tied to a single other project, with no immediate prospect of this situation changing, will be considered by the TSC for a rollover into that other project. The final decision will be made by the TSC after due consideration of the specific case at hand and communication with the maintainers of both projects involved.

Action Items

  • Type your task here, using "@" to assign to a user and "//" to select a due date

Reviewed By


  1. Having seen these concerns for a while now. I feel that the process for moving a project to incubation can consider additional checkpoints

    1. A plan of action with timelines from the proposer of the new project, to get to the goal.
    2. Measurable action items for the 18 months when it moves to incubation. The TSC can debate on the metrics for measuring the action items. Examples of which could be increase in adoption, benefitting at least one other Hyperledger project. These metrics could cover a reusability aspect outside the Hyperledger eco-system as well.
    3. Assign a party (sponsor) for each deliverable. Share the responsibility of deliverables. This also falls in line with that it is a community owned and developed as opposed to maintainers of specific project.

    In addition to these, we can introduce a new project phase called "Under Baking". All the projects will go through this phase when they are proposed. This is a phase where call for collaboration can happen. This can also be a phase until a part of the agreed upon deliverables are met before it can move to "Incubation". It is an indicator to the community on potential new project with proposed features.

    However, if a project fails to meet at least X out of Y number of expected deliverables, then it can be left in "Under Baking" state for an additional period of time (let's say 6 more months). The additional period can be decided through a TSC meeting. Many a times, it could be the external factor not in control of the project maintainers for the delay of expected goal. This is an important topic to be discussed and TSC should consider these for extending the time. TSC can also mediate if a specified action is pending on another party, who initially agreed for a deliverable and did not complete it.

    TSC can also consider a possible transition of Co-Project to a main project. This is much bigger topic and requires more thoughts.

    Setting the context early on the process and taking in account the factors that influenced a project to not reach its goal is also an indicator for the TSC on where the things are going wrong.

    Happy to discuss more.

  2. I think generally the scope/charter of the project should be checked and this is just one possible aspect. Rather than creating policies for specific parts of a charter we should think about just periodically reviewing whether a project is fulfilling its charter.

    Charter fulfillment is captured currently as a criteria for promoted releases:

    1. We don't have a process for changing a project's charter, do we?  This might be especially tricky if a project gradually morphs in a direction to serve a (useful) function outside of its original charter.