• Assuming it would need to pass Dave's proposed Project Readiness
  • It could be a bad look for a company to donate shipping code and then have it wallow in incubation
  • does it come in at the current shipping version ?

Approved Resolution 8 (TSC 08/08/2019):

All new projects proposed to the TSC start in Incubation upon approval. The Incubation exit criteria do not depend on any specific amount of time having been spent in Incubation. As soon as a project meets the Incubation exit criteria it can move to Active status. However, it is practically impossible for some of the criteria to be met at the time of approval (for one thing the repo and mailing list will need to be created but also it will take some time to establish the project and build a community within Hyperledger). Projects should therefore expect to spend some time in Incubation before being able to graduate to Active status although this does not necessarily need to be very long.

The same goes with the first major release.

  • No labels

21 Comments


    • Vipin Bharathan

      Proposed/Draft Resolution 8:

      Embrace this project if it fulfills most of the important criteria, especially if has a user base and a reputation.


      1. Arnaud J Le Hors

        What does "embrace this project" actually translate to practically speaking?

        In my opinion, the most straightforward way to handle this kind of situation is to actually follow the standard lifecycle, starting with the project in Incubation. If the project happens to already fulfill the criteria to move forward to the next step there is nothing stopping it from doing so very quickly and if it doesn't (fulfill the criteria) then it shouldn't, independently of what any company might be doing with that code.



  1. Does this mean that a project could simultaneously apply for incubation and active status?

    1. Indeed, that's the idea. I will try to make the text clearer.

      The key is that the Incubation exit criteria don't change and they don't depend on any actual amount of time having been spent in Incubation. Whenever a project meets the Incubation exit criteria it can move to Active status. If that happens to be true at the time it is accepted as a HIP it effectively moves through Incubation immediately.


      1. Awesome, that makes perfect sense.

  2. I updated the text of the proposed resolution. Let me know what you think.

    1. Looks great.  Thanks!

  3. If you apply the rules consistently, there is nothing stopping the project from coming in and switching to Active fast. I think we have this resolved as well, since that seems to be what others are saying. 

  4. Per my response to Issue #2: Re: Issue 2: What are the criteria for a "First Major Release"?

    Active status should imply that the project community is well integrated with the rest of the HL community. Objectively that is using the HL tools and infrastructure. 

    I do not think then that a project could immediately become active.

  5. Dan brings up an interesting point and although one could argue that it depends on how you interpret some of the Incubation exit criteria, in practice, it seems actually impossible for a project to meet the criteria at the time a HIP is presented to the TSC.

    For instance, the repo will only be created after the project is approved. The same goes the CI being set up.

    Where it's subject to interpretation is that the exit criteria doesn't specicially state that this is about a Hyperledger repo (as opposed to any repo) and Hyperledger CI (as opposed to any CI infrastructure)...

    But all in all I'd side with Dan's intepretation and clarify the exit criteria if deemed necessary.



  6. Agree w/Dan. This resolution ignores the community-building part of moving to active status. Presumably even if it was production-ready, there is no existing Hyperledger community in place. Recommend removing this resolution or creating the opposite resolution, imposing a minimum time in incubation (6 months or a year) to foster a community building period.

    1. I'm not sure we necessarily need a minimum time for community building.  For instance, if some project (say, for the purposes of discussion, Fabric) spun out its consensus interface as a modular consensus project because other projects already had started using it.  Wouldn't the Hyperledger community already be there in this case?

      1. Also, there may be a pre-existing community that comes over and uses Hyperledger's community tools (RocketChat, mailing list, etc) far quicker than 6 months.

    2. As I explained on the TSC call today I am going to change the proposed resolution along those lines, although along with Hart and Brian I don't think we should impose a specific timeframe.

  7. The more we talk about this, the more I dislike the active/incubation status dichotomy.  Can someone precisely clarify what benefit we gain from having active/incubation status other than letting the broader community know (in a very rough way) what kind of community support a particular project has?  If this is the only benefit, I think that there are more efficient ways we can go about this.

    1. I think there is substantial value to saying "great, the project is approved, code is in, but there's still one more quantum level of community engagement and sincere/correct use of the community tools to achieve".  There is still a useful signal to send when someone is learning more about a project, expectations to set, about whether they can depend upon the code and the community to be responsive and follow best practices, or if the project is still getting started and to set one's expectations a bit lower and err on the side of more empathy or self-sufficiency.

      If we have it, we do need to get back to encouraging projects in incubation to graduate to active, if something lingers in incubation for years and years that's a process or conceptual fail in my opinion.

      1. I think, at this point, we have several projects that have lingered for years in incubation.  What is the failure here?  Clearly there are special cases (i.e. Composer) but there may be projects that just don't need a large contributor base.

    2. I agree with Brian. The name may not be the best but this is currently the way we differentiate projects that have managed to build a community and there is definitely value in that.

      What would be the "more efficient ways" to go at communicating this?

      1. Active/incubation is just a binary thing and doesn't reveal a lot of information.  If we have easily accessible contributor statistics–number of contributors, percentage of lines of code coming from various contributor types, overall project activity (mailing list traffic, etc.), security audit information, etc., then we can just show these statistics and let users decide for themselves.  If I'm a new user or someone on the outside looking at projects, this is much easier than seeing "active" or "incubation" and having to find a document to find out exactly what that means.

        I don't think that getting rid of the active/incubation dichotomy would be a popular opinion, but regardless, I think it would be nice if we made the statistics I mentioned here easily accessible.

  8. If we continue to have multiple stages then I feel that we need to make sure that we have clear and concise exit criteria for each stage. I am very much against any time period on  projects moving "up" the chain. Once a project meets those documented criteria then it should be able to move forward. 

    Note that if we go this route then we should also go back and revisit existing projects and adjust as necessary in order to make sure that we are providing a clear and level playing field.

  9. I have updated the proposed resolution. The discussion of Incubation vs Active should be raised as a separate issue if deemed necessary.