Issue 1: When do we know that a project is "done"? What are the end-of-life criteria?
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.
Comments
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.
The proposed resolution states that: Software releases and quarterly TSC reports will be considered as signs of "activities". Isn't that enough?
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.
Resolution 1.2: The deprecated status in the current lifecycle seems applicable here.
"... project is being placed on `deprecated` status ..."
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?
And, is Deprecated something projects should always be moved to before they are moved to EOL? This would also affect 1.1.
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.
Jun 14, 2019
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.
Jun 19, 2019
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?
Jun 20, 2019
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.
Jun 20, 2019
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).
about 7 hours ago
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.