We need a default way to rank elements in queries or just browsing the catalog.
There are a number of metrics we could pull from:
npm downloads
GitHub stars
Last publish date
Catalog page views
Manifest completeness and validation
package.json completeness and validation
Number of dependents in npm
Ratings in the catalog itself
Some of these would require writing back to the catalog database, some would require a log-in. So we may want to avoid those.
npm divides these metrics into popularity, quality, and maintenance, which might be a useful way to think about these. It's probably not that useful to allow custom mixing of those metrics like npm allows, but we could internally group metrics into those categories before mixing to rationalize the weights we give different metrics.
Most of these metrics are also per package, not per element, so we run the risk of over-weighting rarely-used/low-quality elements in otherwise high-quality/popularity packages. The only way to address that is with per-element measures like star ratings in the catalog or manifest completeness per element.
We need a default way to rank elements in queries or just browsing the catalog.
There are a number of metrics we could pull from:
Some of these would require writing back to the catalog database, some would require a log-in. So we may want to avoid those.
npm divides these metrics into popularity, quality, and maintenance, which might be a useful way to think about these. It's probably not that useful to allow custom mixing of those metrics like npm allows, but we could internally group metrics into those categories before mixing to rationalize the weights we give different metrics.
Most of these metrics are also per package, not per element, so we run the risk of over-weighting rarely-used/low-quality elements in otherwise high-quality/popularity packages. The only way to address that is with per-element measures like star ratings in the catalog or manifest completeness per element.