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

When a project, whether in Incubation or Active status, has not had any activities for over 6 months, it will be moved to "Deprecated" status and put on notice (via email to the project list) that it is on the path of being moved to "End of Life" (EOL) status. After an additional 6 months have passed, if no activity has taken place, pending TSC approval, the project will effectively be moved to EOL. Software releases and quarterly TSC reports, as well as significant code enhancements, will be considered as signs of "activities".

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

Project Maintainers may submit to the TSC a request for moving their project to EOL. Pending TSC approval, a notification will be sent out to the project mailing list that the project is being moved to "Deprecated" status and effectively placed on the path to EOL. After 6 months have passed, if no one has objected, pending TSC approval, the project will effectively be moved to EOL.


  • No labels

11 Comments

  1. Arnaud J Le Hors

    Proposed/Draft Resolution 1:

    When a project has not had any new releases for over 6 months, it should be moved out of Active status into "End of Life" status, pending TSC approval.


    Ry Jones

    generally agree, not sure if EOL is the right status - maybe another status between Active and EOL?


    Mic Bowman

    who should be responsible to propose that a project be EOL'd? Given that the burden of managing quiescent projects falls on HL staff, I would suggest that they should propose EOL.


    Ry Jones

    Sure. The costs range from trivial (the waste of printing stickers and marketing collateral), to more substantial (spending face time in booths discussing EOL projects). Retiring projects would also help clean the greenhouse of clutter.


    Baohua Yang

    Suggest: 6 months for TSC warning, and 12 months for end-of-life.


    Arnaud J Le Hors

    Projects are on a schedule to report to the TSC. I think that gives us all we need to figure out when a project has reached the point where it should be changed status.

    1. Dan Middleton

      Another criteria to consider is if a project has not submitted its update to the TSC in 6 months.

      A more subjective criteria is whether over a 6 month period the project has not made progress against its charter. One measure of that progress could be releases. 


    2. Shawn Amundson

      Releases in isolation aren't a good metric, because actively developed projects could have a longer major release cycle, especially if they are making larger architectural changes. A few other ideas: a) Is the project used by other projects within HL?; b) Are users relying/using the project? (It would be bad form to prematurely shut down a project if it's being used - someone might step up if there is user activity). c) What are the opinions of the current/last maintainers? If they feel it's done, that's probably a strong indicator. d) can the project articulate where the project is headed? e) is there discussion in rocketchat or the mailing list that suggests there is a community?


    3. Shawn Amundson

      To Mic's question about who proposes EOL. This should probably be a couple people on the TSC, as the TSC represents the development community.


    4. Arnaud J Le Hors

      I have amended the proposed resolution to take into account all the comments received to date and added another one (request from Maintainers).


      1. Mark Wagner


        We should also provide public notice by placing something on the project (or WG) wiki page that it is EOL, or maybe that we are considering transitioning it to EOL. People could be using it but not on the mailing list.


        Should we measure forks / downloads ?

        btw - do we need to define what happens to EOL projects?

        Does the wiki page go away?

        I assume that the git repo goes read only, but thats an assumption.

  2. Hart Montgomery

    It seems reasonable that the maintainers should be able to decide that a project should be EoL.  If there is disagreement from other contributors, then those that disagree could take over the maintainer role.

    The rules for inactive projects might be more complicated though.  What counts as inactive?  A hard and fast rule might be difficult here.  Maybe every quarter the HL staff issues a recommendation to the TSC of any projects that they think are "inactive" and the TSC decides what to do with the projects?  I'm not sure what the best solution is here.

    1. Arnaud J Le Hors

      The proposed resolution states that: Software releases and quarterly TSC reports will be considered as signs of "activities". Isn't that enough?

      1. Hart Montgomery

        I'm just worried that we might get a case where a project is dead but one holdout continues to fill out TSC quarterly reports or something like that.  Perhaps that's worrying about adversarial behavior that's not likely to happen, but I don't know.

  3. Dan Middleton

    Resolution 1.2: The deprecated status in the current lifecycle seems applicable here.

    "... project is being placed on `deprecated` status ..." 

    1. Arnaud J Le Hors

      You bring up a good point. Thanks for reminding me of the Deprecated status. But this seems to raise another question:

      "A Deprecated project will be maintained for a six month period by its community" What if the community is not willing or capable of maintaining the project?


      1. Arnaud J Le Hors

        And, is Deprecated something projects should always be moved to before they are moved to EOL? This would also affect 1.1.

        1. Dan Middleton

          My initial thought was only 1.2. That is the case where the maintainers are still engaged but explicitly want to be done. They will make best effort support for 6 months and then end the project. In the case of 1.1 there's really no one to do that 6 months of support.
          Now that I think about it, we should also apply it to 1.1 but without implied support. That "path to EOL" would be the project is marked `DEPRECATED` so that the user community has fair warning.

          We may need to update the deprecated definition to either remove the support clause or qualify it as "best effort" or something to that effect. 

  4. Shawn Amundson

    For resolution 1.1, I suggest we include "code enhancements" as "activities":

    'Code enhancements, software releases, and quarterly TSC reports will be considered as signs of "activities".'

    Reasoning: If code enhancements are being merged in, it is a good indication that the project is not dead.

  5. Arnaud J Le Hors

    Ok, I've updated the proposed resolutions to make use of the Deprecated status. I actually think that works well.

    And I think we can leave the fact that in some cases the notion of "best effort" may be moot, as if the project was abandoned by all the maintainers for instance.

  6. Christopher Ferris

    Rather than EOL, I would substitute "Archived" and move the project repositories to the hyperledger-archives org