Add Archived badge and state

[cacoco]

Problem

With GitHub's feature to archive a repository into a read-only mode we'd like to have a badge which can clearly and quickly signal that the project is archived. Before hitting the button in GitHub, the responsible party would update the project README accordingly including updating the repostatus badge to the "archived" status.

Solution

Add a new "Archived" badge.

Result

Hopefully a clear signal to users that a project has been archived and that the repository is in a read-only state.

Note: I'm not quite sure how to update your great lifecycle SVG, please let me know if this is a requirement and if you can point me in the direction of a tool that works on OS X to do so, even better. Thanks!

[jantman]

@cacoco I really appreciate the contribution, especially to a project like this that seems to have relatively little interaction.

Regarding the mechanics of the contribution process, that's described in the Contributing section of the README. The only things that need to be in a PR are the fabfile.py update to add or update the badge itself, and updates to the website under gh_pages/. Everything else is programmatically generated when a new release is issued, as described in the README.

As to the Archived badge, on the other hand, I think I'm going to wait on some feedback from the community and other users on this. I have a few specific concerns around it, some technical and some... uh... philosophical?

In terms of my technical concerns, this project was originally intended to provide both human- and machine-readable descriptions of the lifecycle state of repositories. This is a concept that didn't (and still doesn't, aside from the concept of Archiving a repo) exist in GitHub. Archiving is a concept that exists in GitHub, and is presented clearly both in the UI (via a big yellow bar at the top of archived repositories, which is arguably much more visible than these badges) as well as via the GitHub API (i.e. the archived boolean in the GET /repos/owner/repo endpoint. It's also possible to easily search for and filter Archived repos in the GitHub UI, which is something that repostatus badges don't account for.

The philosophical concern, however, is the larger one for me. The repostatus.org specification is explicitly designed to communicate information about the lifecycle of a repository. I'd posit that "Archived" is not a lifecycle state; it's a method of preventing people from changing the repository because it has entered a lifecycle state where it should no longer be changed.

Currently, the repostatus.org statuses include:

• Suspended – Initial development has started, but there has not yet been a stable, usable release; work has been stopped for the time being but the author(s) intend on resuming work.
• Abandoned – Initial development has started, but there has not yet been a stable, usable release; the project has been abandoned and the author(s) do not intend on continuing development.
• Inactive – The project has reached a stable, usable state but is no longer being actively developed; support/maintenance will be provided as time allows.
• Unsupported – The project has reached a stable, usable state but the author(s) have ceased all work on it. A new maintainer may be desired.
• Moved - The project has been moved to a new location, and the version at that location should be considered authoritative. This status should be accompanied by a new URL.

My personal feeling is that those statuses do an adequate job of capturing the reasons that someone would archive a repository, but I'm certainly open to other thoughts...

[bgrainger]

I agree that "Archived" isn't necessary (or desirable) as a separate status. Archiving at GitHub.com is just a mechanism for enforcing a read-only status on the repo and doesn't indicate intent.

When I've archived a repo, I've added a repostatus.org badge that explains why, e.g., "Abandoned" at https://github.com/LogosBible/Logos.Utility.

[cacoco]

@jantman thanks for your thoughts and I definitely appreciate them. I would push back on the notion of archiving merely being simply a feature present on GitHub. We ("Twitter") established "archiving" before it was a GitHub feature by creating a separate organization and moving projects there (see: http://github.com/twitter-archive) -- though we were very happy to finally have the ability to make the repository read-only. While I stated the GitHub feature as part of the problem statement, to me it is a bit more of practice than just a GitHub feature. The reason for the badging is that because of the feature, we no longer need to move repositories to a separate organization and simply wanted something that aligned with the moving of the repository to an archived state (as it seems incongruous to leave a repo status of "Active" in the README). I understand the argument against this from this perspective. FWIW, I still miss the "archive" bar at the top of a project as I'm generally heading directly to the README to learn more about the project.

For the more general lifecycle question, I can see your point and this definitely does not fit well into the model. I will say -- and this also goes to the comment made by @bgrainger, that the term "Abandoned" doesn't effectively speak for projects which did reach a stable and usable state, perhaps served their purpose for some time, and are now effectively being retired (and maybe "retired" is actually the better term instead of "archived"; a term partially inspired by the prior art from NewRelic here).

There seems to be an end state missing for stable projects being put out to pasture -- that is the organization they are under no longer wants to maintain them and is also not looking for any maintainer as the technology is likely no longer relevant. The "Abandoned" lifecycle off-ramp is too early, while "Unsupported" states a maintainer may be desired -- which is explicitly not true here, though we can probably make do with that designation.

Thanks for the conversation, I appreciate it. I'm happy to close this PR as I agree that "archived" is perhaps not a good fit for the model here.

Thanks!

[jantman]

@cacoco Thanks for all of that. I certainly didn't want to imply that GitHub... "invented" the idea of archiving something... only that there's already a way to tell if a GitHub repo is archived (by looking at the API, or UI).

That being said, I do think you may be onto something about "Retired" as having a different connotation than the current Abandoned and Unsupported statuses. If you'd like to cut an issue with those few paragraphs, I'd be interested to see what others think of adding a Retired status.