Accepting Projects

Before adopting a project into CLJ Commons, there are some entry criteria that need to be satisfied:

• The project is 'unmaintained'. This is subjective, and there are many libraries which are just 'done'. Indications that a project is unmaintained could be: the library breaking with new Java or Clojure versions, issues and PRs not being addressed for years, no recent releases, no commits for years, or the maintainer is no longer involved with Clojure.
• The project is notable, useful, and currently being used by people. This is inherently subjective, but some evidence for this could be number of stars on GitHub, recent issues/PRs, number of downloads on Clojars, how much work went into creating it, or if any notable projects depend on it. An example of a project that wouldn't be accepted is a small library created by one person that only they use.
• There is at least one person who wants to be a maintainer of the project. These maintainers will be listed in a CODEOWNERS file. We don't want the new home of the project to become unmaintained as well.
• We have attempted to talk to the original owner of the project and they are happy to transfer the project. The goal is not to be forking projects away from people who want to manage the project themselves.

Proposing a Project

If you would like to see a project transferred to CLJ Commons for future maintenance that you believe meets the above criteria, you can create an issue to propose the project, providing relevant information about the project's use, and suggesting a new maintainer (or volunteering to maintain it yourself).

The CLJ Commons team will review the proposal, based on the criteria above, and if at least two members of the team agree that the project should be transferred, we will attempt to contact the original owner of the project to discuss the transfer. Currently, that team is Erik Assum, Daniel Compton, and Sean Corfield.

Transferring a Project

When a project is adopted into the clj-commons organization on GitHub, a transfer of ownership is preferred over forking. There are several reasons for this:

• The adoption is somewhat formalized and friendly, the original authors need to give their blessing for this to happen,
• All GitHub metainfo, stars, issues, PRs, etc are transferred in a transfer, but lost in a fork.

We should resort to forking only if the original maintainers remain unresponsive to our inquiries. Currently, unresponsive means not having replied to our request within two months of repeated outreach.

Project Artifact Coordinates

As with transfer vs forking, artefact coordinates also need consideration. There are limitations to how Clojars works, which makes it hard for a Clojars group to change ownership of a single artefact within a group. This means that for certain organizations/authors, it is impossible to let CLJ Commons continue artefact publication under their original group. Even so, we prefer to keep the artefact coordinates the same because this will let tools like lein-ancient and antq continue to work with projects whose source is moved to the clj-commons organization on GitHub.

Project Maintenance

Once a project has been transferred to CLJ Commons, it will be maintained according to our project maintenance guidelines.