(or what are the criteria for a project to be moved back to Incubation? to a lab?)

Approved Resolution 4 (TSC 07/25/2019):

Until projects are moved to Deprecated or EOL they can stay in Incubation or Active status for an unlimited amount of time.

  • No labels

6 Comments

  1. Proposed/Draft Resolution 4:

    When a project has not managed to graduate to Active status 2 years after having entered Incubation it should be moved to a lab, pending TSC approval.

    Baohua Yang

    Moving back is not a good idea; moving to lab sounds a better way.


    Arnaud J Le Hors

    Can you please elaborate why you don't think it's a good idea?


    Ry Jones

    Is the lab the parking lot of misfit projects? I'd rather have a parking lot within the Hyperledger org itself; one that looks like moving back to incubation


    Arnaud J Le Hors

    I suppose we could leave it to the TSC to decide whether to move the project back to Incubation or to a lab but I think it would be better to set a default even if we allowed for a different move. I favor a lab because there is zero expectation for labs to ever graduate.

    Now, of course, if the project has no activity at all then we should just move it to EOL. But I think that case is covered with the other proposed resolution.


    Ry Jones

    I guess my pushback here is selfish and operational. Moving something from one org to another incurs NRE - branch protections are lost, team members are lost, and the like. Github supports an "archived, read-only" state now, as well.


    Arnaud J Le Hors

    Ah ok. I appreciate the technical pain this might involve but I don't think this should be the driving factor. Rather this may simply mean we need to rethink how lab repos are managed. We might need to be creative.


    Vipin Bharathan

    The lab is a nursery. Let us keep it as such. Do not move it back into labs. The sentiment on this list seems like it is inclined that way (except for Arnaud). What is the cost of keeping the project in incubation?
    If there is a lot of work in the project, but they have not been able to graduate to active due to non-functional reasons (diversity etc.)  they should continue to be in incubation.
    If there is no activity then we should create a different status "inactive" or "somnolent" or some such thing. Relate this to cost, i.e. how can we preserve the resources and the history with the least amount of cost and how can we re-animate the project in case people showed up with interest in doing so.

    1. Shawn Amundson

      Projects should never move backwards in the lifecycle, because it would be hard for companies to rely upon projects if that is the case. It's not clear that pushing a project back to labs wouldn't be similar to declaring EOL.

      Also, labs should be about grooming projects to be proposed, and not a graveyard for older projects.


    2. Arnaud J Le Hors


      Given the lack of consensus on moving projects back in any way I have amended the proposed resolution to essentially leave projects where they are indefinitely.


  2. There might be small-ish projects that never have the momentum to move to active status (maybe the number of contributors isn't high enough, for instance) but that are used by many people in the community.  These would presumably be stuck in incubation forever.

    I'd almost rather scrap the active/incubation status and instead provide some kind of metric of community support behind the project.  This is essentially what active/incubation is attempting to measure.  Do we market active projects any differently from incubated ones?  It seems to me that the only thing we are doing with active/incubation designations is telling people what the TSC thinks of the community support of the project.  There may be more effective and descriptive ways to do this than a rather obtuse binary tag.

    1. Interesting observation! You're right, that is indeed what Incubation vs Active come down to and these may not be fully adequate names for what they mean in our case. I'm not sure what else we'd use though.

      1. We could have less binary metrics.  Things like number of contributors, distribution of contributors across companies, distribution of "major" contributors across companies, etc.  Unless there are marketing rules tied to active/incubation status, I'm just not sure that we gain too much by having it.  Making the public aware of the community effort behind the project in the form of easily accessible metrics would seem to accomplish what the status currently does and save the TSC a lot of headaches.

        1. Active status also requires things like CII. It is a reflection of the maturity of the people and processes.

          I support the current* resolution (which is maybe a no-op) that we do not move projects backwards in the lifecycle.


          *current = "Until projects are moved to EOL they can stay in Incubation or Active status for an unlimited amount of time."

          1. We already display the CII in the wiki (in addition to the active/incubation status).  My point is that displaying other things like this may supplant the need for active/incubation.