I have some projects which are actively developed but would benefit from a better home. They are currently hosted under an ex-employer's which keeps them maintained. I also plan to keep contributing. Likely we'd be all more comfortable with a 'neutral' GH org (e.g. not ex-employer's, current employer's, or an individual's) Does this fit the clj-commons use case?
I think so yes
@vemv https://github.com/clj-commons/meta#entry-criteria specifically “The project is ‘unmaintained’.” /cc @borkdude
TL;DR: for a project to move into clj-commons it should be currently unmaintained, in use by enough people that maintenance is important, and have someone who is willing to become the maintainer going forward.
I know there were some projects that were maintained by their original author but moved into clj-commons anyway, since they wanted a more neutral place (at least, this is how I remember it, I think it was some terminal library, this one: https://github.com/clj-commons/spinner Maybe that's not how it went though, @slipset do you remember?
Those libraries did not satisfy the entry criteria — and in my opinion should never have been moved into clj-commons.
(they are not unmaintained and they are not widely used)
Maybe the criteria weren't that clear back then
Thanks for reminding me of these criteria
Do we have criteria for "widely used"? If so, which?
I went through the list of repos and I think most of them now fit the criteria. Except these: - https://github.com/clj-commons/formatter (a new unfinished project) - https://github.com/clj-commons/multigrep - https://github.com/clj-commons/CLJ-2253 (both pmonks)
“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.” — as it says, “inherently subjective”.
I think those are well phrased criteria, makes a lot of sense.
thank you both for sharing/verifying the rationale :) it makes sense and it's fair enough that not every project can make it into clj-commons
Well, it’s more that clj-commons exists for projects that might otherwise die off for lack of maintenance, so it’s not so much that “not every project can make it into clj-commons” as “not every project needs to be ‘saved’ by clj-commons”…
@vemv another way to make it more "neutral" is to make a github org for the project. e.g. clj-kondo/clj-kondo
yeah sounds like we'll end up doing that 👍
And remembered the Verified Group Names policy on Clojars when you are doing that.
Won't clojars remember you of this? ;)
I’m just raising visibility of the policy change hoping to help some folks before they start pushing new libraries to Clojars 🙂
Very good