Much spoken about the topic rollover of projects tied to a single other project. It appears to be an extension to the topic of a project's lifecycle (depends how we see it). Like there exists option for amendments in the constitution, my approach would be to look into the opens/concerns and then fix them in place. Please feel free to pitch in as this list covers a variety of topics from different points in time.
Project lifecycle task force has defined different stages a project can be in (Ref: Project Lifecycle Task Force). Also, amount of time a project can be in Incubation or Active is forever (Ref: Unlimited Incubation period). Here's the list of stages that a project can be in
- Lab (not part of the formal stages list - https://github.com/hyperledger/tsc/blob/gh-pages/project-lifecycle.md)
- Proposal
- Incubation
- Active
- Promoted Release
- Inactive (not part of the formal stages list - https://github.com/hyperledger/tsc/blob/gh-pages/project-lifecycle.md)
- Deprecated
- EOL
Opens:
- As per the decision log a similar proposal was abandoned earlier Issue 6: Should we have subprojects (and fewer toplevel projects). This talks about a top level project having dependent on single other project (different wordings maybe?). Reason for abandoning it is unclear.
- [Quote from the Rollover of projects tied to a single other project] "Sharing the benefits of being a top level project such as security audits, communication services and ambiguous dependency between projects". This appears to be a major factor in considering the proposal. It is unclear what is the effort/cost of doing these activities. Because security audits are done either way, irrespective of a project is a top level project or sub-project of another top level project. As far as the other activities/facilities refer to the proposals section.
Proposals:
- Proposal 1: Brian's email captures four proposals in the email thread. It's pivoted around a specific project. But we can take the ideas and generalize them as possible proposals.
- Proposal 2: Possibly consider a different approach for the projects that are already a top level project in Hyperledger (reasons are listed as sub-bullet points). Follow this if the case requires, special TSC may be required.
- There is a possibility that the maintainers still adhere to their original project charter. But a subset of volunteers have backed out.
- Proposal 3: A top level project will not be penalized for the case of a sponsoring/volunteer organization/individual back-out
- If the reason is amount of effort required and the headcount
- Hyperledger can come up with a list of open contribution proposals and put it out for the larger community. Maybe there are other organizations willing to spend these additional efforts and get things done.
- Hyperledger sponsored internships are another way to evaluate these efforts.
- If the reason is obvious business decisions
- Capture this decision information against the project (Open: decide upon best way to capture this information). Note: There is no change to a new organization/individual joining the efforts. Anybody is free to join/join back anytime.
- If the reason for back-out is technical
- Bring up the points up for discussion to the TSC. TSC can be a technical consultant to help out.
- Document these reasons for not involving in a project.
- If the reason is amount of effort required and the headcount
- Proposal 4: No interest in the developer community outside the single other project
- Periodically checking whether the project meets the charter.
- Promoted releases will go through their agreed upon project charter as in https://github.com/hyperledger/tsc/blob/gh-pages/criteria-for-promoted-release.md. Extend this condition for all the following major releases.
- This should not occur if everything was done right.
- Opens:
- Come up with a way to measure this (the measure of interest of the community outside Hyperledger) metric.
- Come up with a mechanism to measure the original charter goals. One possible solution is to assign measurable goals to an organization/individual from the project proposal charter. Measure the progress in quarterly report.
- Opens:
- Extend and introduce a new project stage. A project that will be merged with another project will be put on notice (through Github/documentation/blog/email communication) for about 6 months in this stage before merging with the other top level project.
- Inactivity from the original contributors/maintainers as well. Read more about the proposal at Inactive Projects.
- Periodically checking whether the project meets the charter.
- Proposal 5: Extend the proposal Project maturity metrics to include facilities a top level project can get based on the badges they earn. Solving one of the major concern that few of these projects are earning more than required benefits from the Hyperledger.
Ending note, it is commendable to see these many proposals go in, also it is a great idea of the previous TSC members on documenting each of the decision process. Most of the answers we want are a keyword search away in the confluence. I strongly believe in diversity. Strength lies in how diverse the community is 
. Let's embrace all the ideas and follow the one that works for the most.
36 Comments
Arnaud J Le Hors
1. As per the decision log a similar proposal was abandoned earlier Issue 6: Should we have subprojects (and fewer toplevel projects). This talks about a top level project having dependent on single other project (different wordings maybe?). Reason for abandoning it is unclear.
The proposal that was abandoned was a different one. It was about recognizing a hierarchy of projects. In the end we decided not to go there and leave it to each project to deal with their own internal structure, the TSC only recognizing/managing the top projects.
Practically speaking this means that, for instance, we only deal with Fabric at the TSC level, even though Fabric is made of several components which can have different set of maintainers, release schedule, etc.
In this case, if we rolled a project into another one, we would stop dealing with it as an independent project from a TSC point of view. It would effectively become part of the project it is rolled into.
Arun S M
This text used in the Issue 6 confused me "Projects that are dependent of one of the other projects should be folded under that project. This means Composer becomes Fabric Composer, Explorer becomes Fabric Explorer etc."
It in a way is talking about dependent projects to be folded into one.
Arnaud J Le Hors
2. [Quote from the Rollover of projects tied to a single other project] "Sharing the benefits of being a top level project such as security audits, communication services and ambiguous dependency between projects". This appears to be a major factor in considering the proposal. It is unclear what is the effort/cost of doing these activities. Because security audits are done either way, irrespective of a project is a top level project or sub-project of another top level project. As far as the other activities/facilities refer to the proposals section.
I think we've had mix signals on that front but Brian eventually said that the additional cost wasn't sufficient to justify doing anything.
One motivation that I brought up and has had some level of support is that it makes the greenhouse very confusing. Newcomers have a hard time figuring out the dependencies between the different projects that are presented at the top level.
Tracy Kuhrt
It is important that we discuss what our goal is when we talk about "consolidation of projects". I agree with Arnaud that this topic typically comes up when we are looking to better explain the projects that we have in the greenhouse. This goal sometimes gets superseded by the desire to clean up projects that seem to have become inactive or that have very little activity. We do have a process for "deprecation", but this is driven by the project maintainers and not by the TSC. If we can be clear on what exactly the goal is for "consolidating projects", then they will help us better come to answers on how to achieve that goal. The path to achieving different goals may be (and probably is) different.
Hart Montgomery
I think, regardless of whether or not we decide to change project governance (and maybe we like things the way they are and decide not to do anything), it might be worth it to revisit how we market things with the greenhouse. The greenhouse is large and quite confusing for people just beginning with blockchain to navigate. It might make sense to have an "application" greenhouse that focuses on the projects that users are likely to be interested in, and a "developer" greenhouse that highlights everything. For instance, Ursa probably wouldn't need to be mentioned in an "application" greenhouse since end users are probably not going to notice it. But it should be included in a "developer" greenhouse because it has tools that developers might value. I think our current greenhouse skews more towards the developers in terms of who learns the most from it.
However, fundamentally what we care about as the TSC is governance. I think it's up to the marketing committee to decide how best to market Hyperledger, although we may want to suggest ideas to them (e.g. the current greenhouse is too confusing). They can ultimately make these sorts of decisions better than we can. If we think the projects are governed well, then we don't need to make changes just because we don't agree with how the projects are presented. The greenhouse diagram, in and of itself, is a marketing product, and if we have issues with that, then change should come from the marketing committee rather than us. If it comes down to "fairness" (i.e. some project being featured/marketed more than others), then that is probably a decision for the governing board to deal with. So I don't think we, as a TSC, should take any action if the only complaint is that the greenhouse is confusing.
There are definitely viable issues related to the project lifecycle, but I'm not sure it's worth changing things just so we can have a cleaner marketing diagram.
Tracy Kuhrt
The list of stages above does not match the Project Lifecycle governance document.
Arun S M
Thanks, I updated the missing stages.
Hart Montgomery
To add another point: we want to incentivize projects to move through the pipeline. I'm worried that there aren't enough incentives for projects to move from incubation to active status. It seems like it's a big hurdle that takes a lot of time and effort with the TSC (if you were around, think back to the Besu proposal for active status, and, if you are a Hyperledger dinosaur, think back to the Iroha proposal for active status to recall what this process is like) and there doesn't seem to be a commensurate reward for doing so. Moving from labs to incubation gets you a lot of new stuff as a project: proper repos in the HL directory, a CI/CD pipeline, featuring in the wiki and elsewhere, etc. It makes sense as a project to do this. But we as a TSC have effectively watered down the rewards for active status over the years so that we give pretty much everything to projects in incubation, so there's no real incentive to move to active status. The incubation/active dichotomy is also something that no one outside of Hyperledger seems to understand or know about, even (correct me if I'm wrong–this is just in my limited experience), so projects have an incentive to just sit in incubation status.
And this is what appears to be happening–projects are, in fact, just sitting in incubation status. I think a strong case can be made that Aries could have active status without a ton of effort–just look at their contributor metrics (https://insights.lfx.linuxfoundation.org/projects/hyperledger%2Faries/dashboard). I would be curious to hear from their maintainers why they haven't gone in this direction.
I'm not sure what the right thing to do here is, but I do think we should properly incentivize people to move through the project lifecycle. Does this make sense to people and, if so, does anyone have any suggestions for how we might do this? Thanks for reading.
Tracy Kuhrt
I feel like the discussion originally started because we were more interested in moving projects from incubation/active to deprecation and/or to combine projects. If we want to look at incubation to active this is a different discussion. Let's figure out what we are trying to solve.
Hart Montgomery
Agree–this is a different issue. But given that we were discussing the project lifecycle, I figured it was worth bringing up.
Arun S M
Update: 02 Dec 2020. Breaking down the summary into separate questions to solve.
These were brought up in the context of consolidating top level projects. The topic of consolidation can be dropped. However, this discussion has brought up few of the unanswered questions. They are listed below:
Question to Solve: Few of the projects started as a top level project in Hyperledger umbrella. Ideally they should have started as a Labs project and then acquired the maturity.
Proposed Solution: Introduce "Labs" to the official list of Hyperledger project life-cycle.
1. Any project that is proposed to the Hyperledger umbrella shall start from being a Labs project.
2. Then follow the process as defined https://github.com/hyperledger/tsc/blob/gh-pages/project-lifecycle.md
Question to Solve: Hyperledger Greenhouse is confusing. There is a mix of project that application developers (majority) want to use and core platform developers (minority) want to use.
Proposed Solution: Restructure the Greenhouse to avoid confusions.
1. Work with the LF marketing team: Provide clarity on the libraries that application developers use vs the libraries that the DLT/blockchain framework & protocol developers use.
Question to Solve: A project can be in "Incubation" or "Active" forever. Need a way to tell activeness to the users of the platform.
Proposed Solution: Use "Badging" as a way to identify project's activeness. Detailed proposal about badging can be found at https://wiki.hyperledger.org/display/TSC/Project+maturity+metrics.
Question To Solve: Introduce a mechanism for regular review of a project. This review will include measuring a project (that has acquired a top level project status) against its original charter goals.
Clarification: Quarterly report can be one of the metric.
Proposed Solution:
1. Follow the process of "Promoted Release" for further major release. Ref: https://github.com/hyperledger/tsc/blob/gh-pages/criteria-for-promoted-release.md
2. The design document or the agreed upon RFC becomes the charter goals. A reference for further major release evaluation.
Open: Define a mechanism to measure the projects against their charter goals.
Question to Solve: What if one of the current top level project do not meet the charter goal?
Proposed Solution:
1. No project will be penalized for somebody else's action.
2. With a "badging" criteria, the activeness status would indicate the current scenario.
There can be a provision to allow project maintainers propose a new charter.
Danno Ferrin
I think making all projects start out in labs is a bad idea. Lengthening the path from proposal to full fellowship will reduce the number of people interested in participating and proposing Hyperledger projects. I fear it will create a "not invented here" mentality where only projects that started out as labs can reach full fellowship. This is simply closing the door to mature projects that want to join hyperledger.
I don't think this goes far enough. I think we either need to re-name the three principal stages (labs/incubation/active → sandbox/project/premier project). or put a time limit (2 years?) on incubation status.
If the middle project status didn't imply a one-time event, like incubation, we could use these reviews to move projects up and down the project stages to reflect current health.
If we had a project ladder instead of a DAG we could move the project down to the middle (incubating/plain old project) or lowest (labs/sandbox) state while it re-groups and re-charters. Or if the TSC is satisfied with a re-chartering keep the project at it's current level.
Hart Montgomery
Thanks for the thoughtful comments Danno! I added a huge section below with many points, but I'd like to add some things here as well.
In summary, I pretty much agree with everything you say here, except for your ideas on the project ladder. I'll elaborate on this below.
To me, the project ladder sounds like a torture technique for the TSC. In my opinion, the most contentious, frustrating, and ultimately useless discussions we have are about project status: should we accept a project into incubation, or should we move a project from incubation into active status? These discussions frequently turn into month-long slugfests with lots of angry people, as you are well aware. Some of this cannot be avoided–as when we are accepting a project for incubation that changes the scope of Hyperledger (I'd argue the board should make this decision, but whatever) and some of this discussion is useful (I personally received a lot of useful feedback from Dan Middleton and Chris Ferris, among others, when writing the Ursa proposal for incubation, for example). But a lot of this discussion is just unproductive and substantially more drawn out than it needs to be, particularly the discussions on moving from incubation to active status. The two discussions on the two most recent projects to achieve active status–Iroha and Besu–were some of my least favorite time spent on the TSC.
One of the reasons that I really like the badging/metric idea for project activity levels is that it lets us avoid these discussions, which only determine a few bits on the website that seemingly no one outside Hyperledger knows or cares about.
A ladder seems like a way to constantly have these discussions, and the more rungs we have on the ladder, the more of these discussions we have to have. If we do have such a ladder, I'd prefer to make it as objective as possible, with little room for debate at the TSC level. I also struggle to believe that such a ladder would be useful: would anyone outside HL really care about rungs on an activity ladder? Internally, we know how active projects are–the whole point of this kind of thing is to show the outside world what we think of project activity levels. If no one outside HL cares, why bother?
Anyways, sorry for my long rant, and thanks again for the comments Danno. If you've made it this far, thanks for reading.
Danno Ferrin
A ladder would be unlike any other OSS umbrella group for sure. But if the criteria were all (mostly) objective there wouldn't be the same level of discussion. If it was more subjective criteria it opens up project status to political manipulation, which isn't good for anyone in the end. The idea would also be to tie ladder level to services provided by HyperLedger. For example only Active projects get audits and marketing pushes.
Every year to keep "Premier" status your project would need to re-certify that it meets the requirements (maintainer corporate diversity, being up to date on TSC mandates like Repository Layout, some measure of use outside of development) - basically all or some fixed amount of the badges being discussed. Possibly as part of a fixed quarters report, like Q2. By getting rid of the incubating name and making active a modifier on project the whole moving up or down the top two rungs of the ladder less like a job action (getting PIPed) and more like annual performance reviews (which can still be unpleasant if you get a bad mark).
Really the only lever the TSC has is the "PIP" where we deprecate and end of life projects. Because it's so extreme we are hesitant to provide the real feedback that some projects may need.
Hart Montgomery
I agree with you–if the criteria were mostly objective, then we could avoid the discussion. The difficulty is coming up with objective criteria that are difficult to game. We haven't had any project (to my knowledge) try to game the system in terms of project status yet, but it could be a possibility. Need a more diverse contributor base? Why don't I just create a couple of extra dummy github accounts and send some contributions from those–"John Doe, independent contributor." As it is, the "community diversity" metric is quite subjective, and it's not clear how to make this objective in a good way. Do you have any suggestions?
As far as active/premier projects go, what you've stated was originally in the plan, and I think that if you go back and read the old TSC emails/policies, you will see this. But it gets murky. Sometimes marketing wants to push a non-active project, which has happened before. And as for security audits, what if an active/premier project depends on a project in incubation status and wants the project in incubation to have a security audit? Do we require them to become active first? This is something that we could run into currently–Indy, Aries, and Iroha use Ursa, for instance. What if they want Ursa included in a security audit, despite the fact that it isn't active (and doesn't currently meet the bar for active status)? These kinds of things are seemingly the reason why any advantages of active status have slowly bled away. I guess we could take a firm stance on this, but it might also hurt our efforts for cross-project collaboration.
What do you think? Does this make sense?
Tracy Kuhrt
I was not sure whether to reply to Danno's or Arun's comment. Not all of these apply directly to Danno's comment, but these Decisions have been previously made (hoping to avoid repeating some of the same discussions):
Hart Montgomery
Thanks Tracy for bringing back the previous discussion! It's always good to avoid duplicate discussions.
Hart Montgomery
I'm going to split out each of Arun's points into separate comments so we can discuss them individually.
Hart Montgomery
Question to Solve: Few of the projects started as a top level project in Hyperledger umbrella. Ideally they should have started as a Labs project and then acquired the maturity.
Proposed Solution: Introduce "Labs" to the official list of Hyperledger project life-cycle.
1. Any project that is proposed to the Hyperledger umbrella shall start from being a Labs project.
2. Then follow the process as defined https://github.com/hyperledger/tsc/blob/gh-pages/project-lifecycle.md
Hart Montgomery
I agree with Danno's point here: I don't think this is a good idea. To quote Danno:
"I think making all projects start out in labs is a bad idea. Lengthening the path from proposal to full fellowship will reduce the number of people interested in participating and proposing Hyperledger projects. I fear it will create a "not invented here" mentality where only projects that started out as labs can reach full fellowship. This is simply closing the door to mature projects that want to join hyperledger."
Certainly the most common case should be projects starting in labs, but I don't think we want to make this a hard and fast rule. If some large, existing project wants to join with a large and diverse contributor base, then it doesn't make sense to me to have them start in labs.
Hart Montgomery
Question to Solve: Hyperledger Greenhouse is confusing. There is a mix of project that application developers (majority) want to use and core platform developers (minority) want to use.
Proposed Solution: Restructure the Greenhouse to avoid confusions.
1. Work with the LF marketing team: Provide clarity on the libraries that application developers use vs the libraries that the DLT/blockchain framework & protocol developers use.
Hart Montgomery
Agree. We should probably have an updated greenhouse (or even multiple greenhouses) that clarify the roles/dependencies of proejcts. Even an "application-focused" greenhouse like I believe I suggested earlier here might be a good idea, as people focused on use cases might not care about developer tools or libraries.
We also might want to emphasize projects unequally in some of our diagrams. This will surely be controversial, but we can probably come up with a fair and deterministic way to do it.
Tracy Kuhrt
Is this a proposal that we should address as the TSC? Or is this a proposal that the TSC would like to take to the marketing committee? Based on previous discussions, it seems like this is something for the marketing committee to handle and decide (with potential input from the TSC).
Hart Montgomery
I agree that this should be a marketing committee thing. We could, of course, give input, as you suggest.
Hart Montgomery
Question to Solve: A project can be in "Incubation" or "Active" forever. Need a way to tell activeness to the users of the platform.
Proposed Solution: Use "Badging" as a way to identify project's activeness. Detailed proposal about badging can be found at Project maturity metrics / Badging.
Hart Montgomery
I like giving users/potential users of a project as much information as possible and letting them decide if a project is active enough for their needs.
However, this still doesn't solve the issue that I brought up above: that I believe there aren't enough incentives currently for projects to move from incubation status to active status.
Tracy Kuhrt
As I was reading this comment and Danno's comment, I wondered if we needed to remove "incubation" even though we previously decided not to (Forgo the Project Lifecycle Incubation state). I would only suggest we rehash that decision if there is some way for people to easily identify the status of a project. I added some thoughts under Project maturity metrics / Badging for ways that we could consider "badging" projects. For now, I would support a task force being created to create a proposal for "badging" that we could discuss further.
Danno Ferrin
I think we also need carrots and sticks to encourage projects to leave incubation.
One thing we can do is make people aware. For projects in incubation we could add a separate section to the quarterly report where each exit criteria question is answered. If nothing has changed then it's a cut and paste. But that little bit of effort puts it in the maintainer filling out the reports mind that "we should be building the project to active state" and ideally "our gaps are X Y and Z." The TSC can do their part by asking each quarter "What is being done to improve X (or Y or Z)" to prod them along.
Hart Montgomery
Do you have any suggestions for what would be effective sticks? As far as I can recall, we've never been able to effectively implement sticks at the TSC level, and when we've discussed it (for things like cross-project work), it has been shot down quickly.
Hart Montgomery
Question To Solve: Introduce a mechanism for regular review of a project. This review will include measuring a project (that has acquired a top level project status) against its original charter goals.
Clarification: Quarterly report can be one of the metric.
Proposed Solution:
1. Follow the process of "Promoted Release" for further major release. Ref: https://github.com/hyperledger/tsc/blob/gh-pages/criteria-for-promoted-release.md
2. The design document or the agreed upon RFC becomes the charter goals. A reference for further major release evaluation.
Open: Define a mechanism to measure the projects against their charter goals.
Hart Montgomery
If we want to do this, we will need to actually enforce some rules about a "promoted release." Historically, there have been few differences between "promoted" releases and "regular" releases–in fact, some regular releases have been promoted! So we might want to revisit these guidelines as well.
What design documents or RFCs are being referred to here? I agree that these would be useful for charter goal evaluation. I also agree that we could keep track of charter goals in the quarterly reports. Projects are asked to list what they are working on in the next quarter. If the TSC doesn't like it, then they can reject the report (or take some other action, I guess). But I think the review of the report with the goals should count as endorsement of the project following its charter. Maybe we can add in the quarterly report that, if a project is deviating from its charter or its previous goals, it is important to state in the quarterly report.
Tracy Kuhrt
The quarterly reports is the "official" mechanism for informing the TSC of what is happening within the project. If they are not able to meet the regular review aspect, then I am in favor of modifying the template to request more information. Also, if we as TSC members are not comfortable with the content or we have concerns regarding the project, this is the time for us to ask questions.
Hart Montgomery
Question to Solve: What if one of the current top level project do not meet the charter goal?
Proposed Solution:
1. No project will be penalized for somebody else's action.
2. With a "badging" criteria, the activeness status would indicate the current scenario.
There can be a provision to allow project maintainers propose a new charter.
Hart Montgomery
This is a tricky question. A project could morph into something very useful but unrelated to its original goal. For instance, if some DLT has a great feature, but the overall DLT is falling behind. The project might reorganize to focus explicitly on that feature, and using the software for that feature on other DLTs. Maybe then the other DLTs all pick up this feature and use it in their code as well, so the project that was originally a DLT project becomes a feature project.
This is something that would certainly not be a bad outcome, and we should try to accommodate things like this.
Note that this is orthogonal to activeness, which we can handle separately.
Finally, I'd support allowing project maintainers to propose a new charter whenever. I'd suggest we encourage this as part of quarterly reporting.
Tracy Kuhrt
This question seems to come up mostly with projects whose charter stated that they would support DLT 1, 2, 3, but only support DLT 1. Part of the problem again comes back to people new to Hyperledger not understanding the projects and how they relate to one another. I am not sure that the proposed solution handles this scenario. Specifically, if we allow a project to suggest a new charter, but the TSC does not agree with the new charter, what do we do? Will we tell the project that they cannot change their charter? If so, will the project say okay, but still do what they want? Will we remove the project from the Hyperledger greenhouse? This one is definitely a hot-button topic.
Arnaud J Le Hors
Separate proposals have now been created, please, continue the discussion on the appropriate page:
Restructure the Greenhouse to avoid confusion
Project maturity metrics / Badging
Introduce a mechanism for regular review of a project
What if a top level project does not meet its charter goal?
Note that the proposal to mandate that all projects start as a lab was dropped in light of the previous decision: Projects not required to start as a lab