Repository Maintenance Levels

Repository Maintenance Levels.md

After reading Why I'm Frequently Absent from Open Source by James Long and listening the corresponding The Changelog episode, I dwelt on the idea and believe that open source maintainers...

• ... should never be ashamed if they don't have time for a project.
• ... should be honest with themselves and open with their users so that everybody can be on the same page
• ... are people and they have at one time or another responsibilities or hardships that they need to attend to which reasonably take them away from a project
• ... may also reasonbly decide that they don't like the direction of a project or that they would like to explore other things and may leave a project permanently.

Along this line of thinking I've created a set of descriptions for different levels at which a project might be maintained. A maintainer can use these to announce to their users the current ability that they have to dedicate to a project (no more "Is this project still maintained?" issues!)

Actively Developed

The maintainer(s) of this project are currently writing code for this project as well as responding to issues and integrating code contributions

Actively Maintained

The maintainer(s) of this project are responding to issues and integrating code contributions

Inactively Maintained

The maintainer(s) are around to answer questions, but do not currently have time to respond to issues or integrate code contributions

Not Maintained

The maintainer(s) are not around to work on this project and should offer to hand the project over

Abandoned

The maintainer(s) are not interested in spending any more time on this project. Users are welcome to fork it.

No matter your commitment to a project, it is in your user's interest to know the status of your projects (as well as in your own interest to not have to answer the question over and over). To that end I have created these easy-to-copy badges for your repo's README which can all be linked back to this page.

[![Active Development](https://img.shields.io/badge/Maintenance%20Level-Actively%20Developed-brightgreen.svg)](https://gist.github.com/cheerfulstoic/d107229326a01ff0f333a1d3476e068d)

[![Actively Maintained](https://img.shields.io/badge/Maintenance%20Level-Actively%20Maintained-green.svg)](https://gist.github.com/cheerfulstoic/d107229326a01ff0f333a1d3476e068d)

[![Inactively Maintained](https://img.shields.io/badge/Maintenance%20Level-Inactively%20Maintained-yellowgreen.svg)](https://gist.github.com/cheerfulstoic/d107229326a01ff0f333a1d3476e068d)

[![Not Maintained](https://img.shields.io/badge/Maintenance%20Level-Not%20Maintained-yellow.svg)](https://gist.github.com/cheerfulstoic/d107229326a01ff0f333a1d3476e068d)

[![Not Maintained](https://img.shields.io/badge/Maintenance%20Level-Abandoned-orange.svg)](https://gist.github.com/cheerfulstoic/d107229326a01ff0f333a1d3476e068d)

@Exr0n yes there are a few discrepancies.

Being explicit is good, but I'd prefer a solution which uses metrics to determine this. Is it maintained? ironically is no longer maintained, but it still has a high score because it doesn't have any issues, which is a bit misleading because the project has issues turned off.

Being explicit has the downside of requiring the maintainer to state their intentions. This is a problem when the maintainer is no longer able to be explicit (maybe they don't have time, or lost access, or even passed). Automatic metrics solve for that.