Simplify project lifecycle

[lehors]

This PR replaces the Dormant, Deprecated, and End of Life states with a single Archived state from which a project can possibly move back to Incubation.

[lehors]

Note that one could argue that this is going too far by removing Deprecated but I think the same functionality can be achieved as described and the gain in simplicity outweighs the loss.

[petermetz]

@lehors First of all: LGTM.

Note that one could argue that this is going too far by removing Deprecated but I think the same functionality can be achieved as described and the gain in simplicity outweighs the loss.

We could make it part of the guidelines that there has to be an explanation provided at the very top of the README.md about the state of the project that clears up ambiguities related to not having the 3 distinct states available to chose from anymore. It could even be a set of pre-defined questions like we have it in the quarterly reports, but a sort of exit interview for the maintainers that would seek to locate the position of the project on the spectrum [1].

I'm thinking of questions like:

1. Would you/your organization be interested in rebooting the project if other people/organizations came along to share the burden of maintenance?
2. Are you archiving the project because of fundamental design flaws that aren't feasible to be fixed?
3. Are you archiving the project because of fundamental security flaws that cannot be fixed without a complete redesign? (maybe this is the same question as 2)...)

[1] The spectrum being worst to best case in terms of the subjective feelings of the maintainers, e.g. it could be that a) they archived the project because of critical design failures/security vulnerabilities that are not feasible to be fixed without a complete rewrite and they'd rather just start over as a lab OR b) they are loving the project and they would love to continue working on it but funding has ran out but if someone else were to pick that up the project could chug along nice and healthy.

[tkuhrt]

@lehors : I believe these were the options we discussed in the TOC meeting today.

Option 1 - Arnaud's Version

Option 2 - Option 1 + Graduated back to Incubation

Option 3 - Option 1 + Pre-Archive State

Option 4 - Option 2 + Pre-Archive State

Option 5 - Radical

(*) Note in this option, we would need to implement badges.

[swcurran]

Awesome work, Tracy — thanks. During the meeting I had written in my notebook pretty much exactly version 4, so that’s my choice, with the rational for the “pre-archived” (need a better name! 😄 ) state what I said in the meeting.

[tkuhrt]

“pre-archived” (need a better name! 😄 )

Naming is hard. Open to suggestions.

[swcurran]

“pre-archived” (need a better name! 😄 )

Naming is hard. Open to suggestions.

My suggestions, in order:

“Inactive”, “Dormant”, “Unsponsored”, “Unmaintained”, “Stagnant”

[lehors]

Thanks for doing all the work @tkuhrt ! :-) I don't really know how to interpret the "active stages" box in 2 and 4. Does this mean a proposal can go directly to graduated? For option 5, shouldn't there be a path from Archived back to Project (or Proposal)?

[swcurran]

For option 5, shouldn't there be a path from Archived back to Project (or Proposal)?

I would say it just makes the picture messy to include that. Someone could do that — it’s open source code after all — but I don’t think it’s worth calling out.

[tkuhrt]

I don't really know how to interpret the "active stages" box in 2 and 4. Does this mean a proposal can go directly to graduated?

Oh...this was one of my earlier questions that we did not discuss during the meeting. Yes, this would imply that a proposal could go directly to graduated if it met the incubation exit criteria already.

If you don't like that, then there is always:

Option 6

Option 7

[tkuhrt]

For option 5, shouldn't there be a path from Archived back to Project (or Proposal)?

For this, I think it would go back to proposal. So, I guess I agree with @swcurran on leaving it out as we don't really have the entry arrow into proposal either.

[tkuhrt]

Thanks for doing all the work @tkuhrt ! :-)

Hope you don't mind me jumping in. If anyone thinks there are other options that should be considered, you can click on the picture that you want to build on, and it should take you to mermaid.live where you can edit the picture, copy the markdown into a comment and show your preferred option.

[petermetz]

My preference at this moment (might change later!): option 5 plus badges, but we need to have the badges nailed down first for that to work IMO. If the badges are operational and satisfactory (happy path) then we could move to option 5, but otherwise option 6.

[lehors]

I don't really know how to interpret the "active stages" box in 2 and 4. Does this mean a proposal can go directly to graduated?

Oh...this was one of my earlier questions that we did not discuss during the meeting. Yes, this would imply that a proposal could go directly to graduated if it met the incubation exit criteria already.

I have to admit to be hesitant about this change. Our position has always been that Incubation was the way for any project (even mature ones) to get into the Hyperledger organization and that if a project was mature enough it could quickly move to Gratudated status after that but that Incubation was a necessary first step to establish itself as being part of Hyperledger. Of course the TOC can change its position on this.

[denyeart]

My vote is Option 3 and call pre-archived "Dormant". This leaves things pretty consistent with the existing lifecycle but collapses "Deprecated" into "Dormant" to simplify it.

Option 2 and 4 are good in theory but the diagram hurts my brain, and would require constant TOC re-assessment between Incubated and Graduated.

In my opinion Option 5 "Radical" is too radical. Badges seem too nuanced for people to understand at a quick glance. Whereas "Incubated" to "Graduated" provides intuitive meaning at a glance and a good incentive for new projects to meet the criteria and make the leap. I'm not against badges per se, perhaps once we define the badges well we could say that once a project obtains badges X, Y, Z then they are automatically Graduated. But I don't think we have to decide that for now.

[swcurran]

Noting that Options 3 and 7 are the same. In the Discord Poll I voted for 7, so also 3. :-)

[tkuhrt]

@swcurran : The difference between 3 and 7 is that 7 allows projects to move backwards to incubation from graduated.

[tkuhrt]

My vote is Option 3 and call pre-archived "Dormant". This leaves things pretty consistent with the existing lifecycle but collapses "Deprecated" into "Dormant" to simplify it.

My problem with "Dormant" state (regardless of what we call it) is that projects that have gone dormant have never come back from dormant and in some cases, it is extremely hard to contact the maintainers after it goes into that state. If we have a tool that will automatically move a project to dormant on 3 months of inactivity by the maintainers and then to archived after another 3 months of inactivity, I might be willing to have the extra state. Right now, this state seems like noise. As an example, currently, Transact has been Dormant (officially) since May 4, 2023; however, it was Dormant (unofficially) since before that time. What is the right time to leave the repository un-archived before we finally make the decision to archive it?

[swcurran]

My problem with "Dormant" state (regardless of what we call it) is that projects that have gone dormant have never come back from dormant and in some cases, it is extremely hard to contact the maintainers after it goes into that state. If we have a tool that will automatically move a project to dormant on 3 months of inactivity by the maintainers and then to archived after another 3 months of inactivity, I might be willing to have the extra state. Right now, this state seems like noise. As an example, currently, Transact has been Dormant (officially) since May 4, 2023; however, it was Dormant (unofficially) since before that time. What is the right time to leave the repository un-archived before we finally make the decision to archive it?

Having been through this with Ursa, I definitely disagree with this. The goal of the state is to notify a members of the community that might want alter the direction to take action. In some cases, they will not, and the transition to dormant will follow on to archived without intervention. However, we leave open the opportunity for two things to happen by those not aware of the current state of maintainers in a project:

• Collaborators might step up and take over the project, keeping it alive. Such collaborators might have no idea that the project is need of maintainers.
• Collaborators might step up and get what is useful out of the project moved elsewhere before the official archiving.

The latter would have made the Ursa transition much easier for the community, vs. the messy scramble it became.

I have no problem with a time being set for the transition from Dormant to Archived if nothing changes. That can be set at the time the transition to dormant is made — perhaps a range from 1 week to 3 months. If there is no value in keeping the project, make it super short. If the project is in active use, make it a marketing opportunity to see if there is interest — and to enable a graceful shutdown.

[lehors]

Having been through this with Ursa, I definitely disagree with this. The goal of the state is to notify a members of the community that might want alter the direction to take action. In some cases, they will not, and the transition to dormant will follow on to archived without intervention. However, we leave open the opportunity for two things to happen by those not aware of the current state of maintainers in a project:

* Collaborators might step up and take over the project, keeping it alive. Such collaborators might have no idea that the project is need of maintainers.

* Collaborators might step up and get what is useful out of the project moved elsewhere before the official archiving.

But if that were the case a project can easily be unarchived. This is something that has happened several times in the labs. A lab appears dormant it gets archived and then someone comes out of the woodwork and says "hey, I would actually like to work on this". The lab is unarchived (before the ink is dry in typical @ryjones fashion :-) and the work resumes. No foul.

I think the change from End Of Life to Archived is the reason we don't need any "dormant/pre-archived" state.

Admittedly you might think that archiving a project is quite a harsh way to let the community know they really need to step up if they want the project to go on but it greatly simplifies the management of those projects that otherwise stay in limbo for long period of times.

[denyeart]

In addition to what @swcurran said about alerting members of the community, I think the other purpose of a pre-archived Dormant state is to allow for final pull requests before a project is archived. Even though a project may be generally inactive, it doesn't mean the pull request rate will go straight to zero. Some example pull requests against a Dormant project:

• Maybe somebody wants to update the Readme with transition plans and options as they become available.
• Maybe somebody wants to update a project dependency to fix a vulnerability for remaining users.
• Maybe an external change has caused CI to break and somebody wants to fix it.

So even though the codebase is generally inactive and not moving forward, it doesn't mean we should immediately block all pull requests which is what the archived state would imply. We could state that a Dormant project automatically goes to Archived after N months of no activity, so that TOC doesn't have to re-visit the project decision yet again.

Ultimately I think we will be quicker to mark a project Dormant than we would to completely archive it, giving the community an important signal sooner than we otherwise would that the project is winding down and now is the time for any final pull requests or to step up as new maintainers.

[swcurran]

Admittedly you might think that archiving a project is quite a harsh way to let the community know they really need to step up if they want the project to go on ...

That’s exactly what I’m thinking, and I think it is worth the extra bit of overhead to go through the process in two steps instead of one.

[VRamakrishna]

Sorry for my late entry to the conversation. Can we redraw option 2 so that all stages are vertically stacked but which consists of an Incubation-Graduation cycle?

[VRamakrishna]

Option 4 is ambiguous, as the back arrow from Pre-Archived may lead to Incubated or Graduated. I would replace it with "Option 7 + back-arrow from Pre-Archived to Graduated".

[tkuhrt]

Sorry for my late entry to the conversation. Can we redraw option 2 so that all stages are vertically stacked but which consists of an Incubation-Graduation cycle?

[tkuhrt]

Based on Hart's comments in the TOC meeting:

[tkuhrt]

[tkuhrt]

[vaporos]

It would be helpful to clarify what resources are immediately/eventually removed from the project upon changing states. For example, presumably Archived means to turn the github repos read-only and remove the chat channels (offering no real hope of a project's resurrection). We experienced this with Grid, where there is now no location to even talk about it.

I'd also like to see a "Moved" state, which indicates the project left Hyperledger (presumably because the project expectations couldn't be met, but the project remains viable in a different setting). Project could be de-branded Hyperledger and links could be made to the new location.

[lehors]

It would be helpful to clarify what resources are immediately/eventually removed from the project upon changing states. For example, presumably Archived means to turn the github repos read-only and remove the chat channels (offering no real hope of a project's resurrection). We experienced this with Grid, where there is now no location to even talk about it.

I agree that's unfortunate. I think upon request the chat channel could be left open for a while to address this problem. This doesn't really cost anything.

I'd also like to see a "Moved" state, which indicates the project left Hyperledger (presumably because the project expectations couldn't be met, but the project remains viable in a different setting). Project could be de-branded Hyperledger and links could be made to the new location.

I don't think this warrants adding another state. There are different reasons for which a project can be archived and that's just one of them. When a project is archived its README should be updated to provide appropriate information for people to know what happened and in case the project has moved elsewhere a pointer to it can be provided.

[tkuhrt]

Since the TOC voted and approved this simplification at the last meeting, are we good to merge this? @hyperledger/toc