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
- Angelo De Caro
- Arnaud J Le Hors
- Christopher Ferris
- Dan Middleton
- Gari Singh
- Hart Montgomery
- Mark Wagner
- Nathan George
- Swetha Repakula
- Tracy Kuhrt
- Troy Ronda
3 Comments
Arun S M
Having seen these concerns for a while now. I feel that the process for moving a project to incubation can consider additional checkpoints
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.
Dan Middleton
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:
https://github.com/hyperledger/tsc/blob/gh-pages/criteria-for-promoted-release.md
Hart Montgomery
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.