Skip to main content

ABOUT THE EXTENSION SCORECARD

The scorecard is a quality score attached to every published extension. It answers two questions that anyone installing an extension cares about: can I figure out how to use this, and can I trust where it came from?

What the score is

The score is a number out of 100, a letter grade (A through F), and a per-factor breakdown. The breakdown is the important part — the number on its own does not tell a publisher what to fix, and does not tell a consumer what kind of gap to expect. The factor list makes the score self-explaining: a 70% split as "no README, good types" is different from a 70% split as "great README, no repository link", and the card shows which.

The score renders in two places. On an extension's detail page, the full ring and factor breakdown appear alongside the usual metadata. On the extensions browse page, a small ring and the letter grade sit in the bottom-right corner of each card. Extensions that have not been scored show nothing on the browse page — no placeholder — and display "Not yet scored" on their detail page.

The exact factors, weights, and thresholds are on the rubric reference page. This page is about the shape of the system, not the numbers.

Why it exists

A registry with no quality signal forces consumers to evaluate each extension themselves. That does not scale. The scorecard gives a consistent, automated first pass: is there a README, does it show real usage, is the type surface documented, does the repository resolve to a public source. These are things consumers would check anyway, done up front and rendered the same way for every extension.

It is not a competition. The scorecard does not rank extensions against each other, and high scores do not lock in placement. The intent is trust signalling and self-audit. A publisher can look at their own card and know exactly which documentation gap or missing manifest field is the next thing to fix.

How scoring happens

Every publish kicks off a background scoring job. The analyzer pulls the tarball from object storage, reads the README, runs deno doc --lint over the entry points, and writes the per-version results to a metadata record. Factors that live on the extension itself rather than the version — description, platforms, repository, license — are read live from the extension record. Editing them in the owner panel updates the score immediately; no republish needed.

An owner can trigger a fresh analysis with the "Score this extension" or "Rescore" button on the extension detail page. This is useful after fixing a per-version factor like README content or JSDoc coverage — the per-version meta does not otherwise change until the next publish.

Why verification is a separate badge

An earlier version of the rubric folded a "Verified by Swamp" factor into the score, so a third-party extension capped at 92% regardless of how carefully its publisher filled in everything else. That conflated two different things. The score is a quality signal the publisher controls — ship a README, document your exports, link a public repository. Verification is an editorial signal System Initiative controls — we have looked at this extension and trust what it claims to be.

Tying them together meant the score could not be fully earned by effort, and the scorecard became partly a reflection of which extensions had been curated rather than how much care had been put into the package. Pulling verification out of the rubric lets a third-party extension that earns every factor hit 100%, and keeps "Verified by Swamp" as a separate editorial signal.

The badge appears as a shield pill on the extension detail page whenever System Initiative trusts the extension — either because it was published under the first-party @swamp namespace or because an admin has curated it. An automated rubric can check whether a README exists, whether a license is declared, whether a repository URL resolves to a public source — but it cannot check whether the extension does what it claims to do, whether the author is who they say they are, or whether the code is worth running. The badge is how that editorial judgment is surfaced; the score is everything else.

Rubric stability

The rubric will not shift every quarter. When a factor is added it is added deliberately, and when it changes the reasoning is communicated. Existing extensions are not retroactively re-analysed when the rubric moves — their stored per-version data is composed against the current factor list. A publisher who invests in hitting the current rubric can trust that their improvements will persist through future updates.