It seems to me that developing code/package quality metrics (like “days since last PR accepted”, etc) is difficult even in private, closely-held organizations; doing the same in a community space like this feels extremely challenging, with potential side effects that might not be easy to predict ahead of time.
(Are there any examples of other language communities having such standards for their package repositories? If not, I think that that’s probably not coincidental.)
One of the main weaknesses of opam’s model is showing here; since there’s no namespacing/scoping (as found with e.g. maven, and optionally in npm), package names become precious commodities. (Hackage has a policy here because it has the same problem.)
It’d be great if multiple parties could concurrently publish packages of the “same” name under different team/group/scope umbrellas; in spaces where this is possible, it can pretty quickly help establish a consensus when a fork is necessary (whether due to maintainer departure, or simply disagreement about project direction), without having to develop and agree on “quality metrics” or any other sort of package control policy ahead of time.
(Ech, somehow noticed only after the fact that @yawaramin mentioned this whole topic upthread already, mea culpa)