CLJ Commons - (First project): Resurrecting unmaintained projects

Community Center Community Building
1

Hi folks

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-commons would 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
    • Documentation
    • 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.
5 Likes
2

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.