Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: deno.land/x module scoring #4

Closed
kitsonk opened this issue May 5, 2022 · 0 comments
Closed

Proposal: deno.land/x module scoring #4

kitsonk opened this issue May 5, 2022 · 0 comments
Assignees

Comments

@kitsonk
Copy link

kitsonk commented May 5, 2022

One of the biggest challenges for discovery of modules in the Deno eco-system is identifying suitable packages. When browsing modules, modules are currently only listed based on GitHub star count. We need a better scoring metric. Inspired by npms.io here is a work in progress proposal for the metric.

The metric would have three aspects to it, which have several contributing data points:

  • Popularity
    • Documentation views (on doc.deno.land and soon on deno.land/x) - high weighting
      • Should be a sliding window. 30 days?
    • Usage count (from deno.land/x) - medium weighting
      • Should be a sliding window. 30 days?
    • GitHub stars - low weighting
  • Quality - this is a tricky metrics, because there are few absolutes around quality that @crowlKats and I could come up with, this clearly needs more discussion. In almost every case it feels like something where everything starts at 0 and gains quality points as more of the "tick list" is true.
    • Coverage of JSDoc on exported symbols - a high level
    • Has a README and license
    • passes deno fmt and deno lint (the challenge here is what should be considered code to include in this)
    • deno test --coverage high
    • a deno.json/deno.jsonc exists
    • an identifiable entry point ({mod,lib,index}.{ts,tsx,js,jsx,mjs})
  • Maintenance - this is also somewhat subjective too and needs refinement
    • Ratio of open issues vs. total issues
    • The time it takes to close issues
    • direct and indirect usage of std library being "current" or excessive duplication of versions of std library
    • Commit frequency

An overall score would be derived from this to influence the sort order. Currently we think only popularity is easily deliverable, and so the initial weighting would be Popularity 1, Quality 0, Maintenance 0. We would weight these different in the future.

Ref denoland/dotland#2081

@crowlKats crowlKats transferred this issue from denoland/dotland May 31, 2023
@kitsonk kitsonk closed this as not planned Won't fix, can't repro, duplicate, stale Apr 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants