The first CLJ Commons project that has been created is a place and set of conventions for taking over/forking maintenance of old libraries that are no longer maintained but that still provide a lot of value to the community.
There are a number of questions that need to be answered for this project, I’m interested in hearing from the community about them:
- What is the popularity threshold for a project over which it is worth taking over maintenance? How do you measure that? You could look at things like GitHub stars, number of recent issues/PRs, Clojars downloads, how highly depended on it is, how much work went in to creating it.
- What does it mean for a project to be ‘unmaintained’? There are lots of Clojure projects which are effectively ‘done’ in the eyes of their maintainers. Trying to fork these projects seems counterproductive.
- What is the mechanics of offering to take over maintenance of these projects?
- Some people may like to keep the project under their GitHub name for many reasons. How could we maintain these projects? This seems mostly workable, if it is under a personal repo, the only things that other people can’t do is update repository settings.
- What do you do if you’d like to maintain a project that is important and unmaintained but the original author doesn’t want that?
- Maintainers offering to transfer the project repository seems ideal as this preserves issues, watchers, stars, Google pagerank, e.t.c. Creating a fork seems generally undesirable if possible to avoid.
- How long do you want to wait after contacting a maintainer about taking over their project?
- Should the Group ID of the project stay the same? This means that tools like lein-ancient will be able to notify people of updated dependencies. Forking the Group ID to
clj-commonswould break that chain, but may be necessary if people don’t/can’t add permissions in Clojars for others to deploy to the original artifact name.
- Do we want to set some entry requirements for people that are willing to be responsible for maintenance?
- Should we set some exit criteria for projects that we adopt but then become superceded or no longer used? Where do those projects go?
- I think it would be quite useful to have some number of people (more than one?) who commit to maintaining this new project under the clj-commons banner. We don’t want the new home of the project to become unmaintained as well.
- What are the minimum requirements for maintenance of a project? Some ideas:
- Passing continuous integration
- Responsive to issues and pull requests
- Regularly creating releases
- Staying up to date with new Clojure and JVM releases
Here are some general principles that I think would be good to keep in mind:
- Respect the wishes of maintainers - If CLJ Commons goes around forking lots of projects, that is bound to create ill-will in the community. The goal of this is not empire building, it’s helping keep the Clojure ecosystem from decaying.
- Provide value to the community - There are lots of unmaintained Clojure projects that are not that important. There are also lots of old libraries which are just stable and run fine. We only have a limited amount of time and attention, we should focus it on places where we can provide the biggest improvements.