Add Retired status and badge

[cacoco]

Problem

Following up on the conversation in https://github.com/jantman/repostatus.org/pull/36; there does not currently seem to be a status which represents the EOL for a project that reached stability and utility for some amount of time but for which is now "abandoned" as the technology or processes have been deemed to be outdated with no plan to update or address as in many cases other, possibly better, alternatives exist.

The current definition of "Abandoned" doesn't effectively speak for projects of this state. This is, projects which did reach a stable and usable state, served their purpose for some time, and are now being shutdown with no new development planned, no new maintainer desired (and very likely will end up "archived" for posterity).

"Unsupported" explicitly states that a new maintainer may be desired, leaving open the possibility that the project may a some point become "active" again. In this case, we want to intentionally signal that this project has reached a terminal state. There will be no support or maintenance. No new maintainer is desired. All work has ceased.

Solution

Add the "retired" status. This is meant to capture projects for which the organization they are under no longer believes the once stable and usable project is viable and wants to signal a terminal state for the project.

[waldyrious]

So the only difference between "Retired" and "Unsupported" is that for the latter a new maintainer may (or may not) be desired, and for the former a new maintainer is explicitly not desired? This makes "Retired" a subset of "Unsupported", IIUC.

If that's accurate, I have two observations:

1. We might want to explicitly set Unsupported to mean that a new maintainer is desired, avoiding the conceptual overlap and potential for confusion;
2. I'm not sure it's a good idea to provide explicit support for locking projects like that; There may be communities of people using old technologies who might wish to continue developing a project even after the original author no longer sees it as viable. This badge effectively legitimizes an author's ability to both stop developing a project, and preventing others from doing so, which I don't thing is a good dynamic to encourage.

[cacoco]

@waldyrious per your point number 2, this is exactly the functionality enabled by GitHub's archive functionality. That is, an author may choose to make a repository read-only such that it is no longer possible to submit changes to it. Also, nothing prevents the manual copying of the code (pending the license) to create something new and maintained by someone else.

If this is a debate about the spirit of that functionality, I can understand but I would not necessarily want to have that conversation here. I think this functionality exists and I disagree with the sentiment that an author or even an organization cannot control what happens to their project(s) and thus use this functionality to no longer allow any further development. I also think having the code remain publicly available is better than the alternative of deletion of the repository.

For point #1, I agree that resolving the ambiguity may be desirable.

[waldyrious]

this is exactly the functionality enabled by GitHub's archive functionality.

this functionality exists

I understand that. My observations were based on the assumption that repostatus.org was meant as a generic representation of project lifecycle, not a 1-to-1 mapping to what GitHub (or any individual platform) specifically allows.

For example, in the Wikimedia Toolforge platform, there's an explicit policy that allows projects to be re-adopted if they're abandoned. I don't think we should model that specific dynamic in repostatus.org, or indeed attempt a comprehensive coverage of all existing dynamics across various forges, since that goal would make the model too complex and go counter to the project's mission to make it easy to understand what state a project is in.

That said, these are just general considerations and food for thought, not a strong disagreement with the premise of this PR. I'm looking forward to see what others think about this.

[cacoco]

I understand that. My observations were based on the assumption that repostatus.org was meant as a generic representation of project lifecycle, not a 1-to-1 mapping to what GitHub (or any individual platform) specifically allows.

My point was not to suggest that we should eschew to a 1-to-1 mapping to what GitHub does, rather to refute the idea that locking down a repository is inherently a bad thing to do or encourage since there is a fairly big precedent.

Digging in on your example from the Wikimedia Toolforge platform, I think we'll be able to find examples and counter-examples in implementations everywhere. So I think the question is, is this useful generally? Is it useful to have a status which signals a stable project now being EOL'd?

[cacoco]

Closing due to inactivity.