Skip to content
Methodology v1.0 · Effective 2026-04-30

How GitShowcase verifies reviews.

Every reviewer is a real developer who signed in with GitHub and cleared a public credibility threshold. This page documents every rule the platform uses to score, weight, and aggregate their reviews. Any reviewer or vendor can audit how their data was processed.

TL;DR — 4 principles
01
Reviewers must clear a public GitHub credibility threshold. Sign-in alone is not enough.
02
Each review is weighted by reviewer credibility, use-case match, and disclosed conflicts.
03
Aggregate scores apply a recency decay so rankings reflect current behavior, not stale impressions.
04
Every rule is public, versioned, and challengeable through a public dispute log.
01
Step one

Identity verification

GitShowcase issues a reviewer credential only after a GitHub account passes five public signals. Each one is independently verifiable. AI-generated review accounts cannot pass these checks because they cannot conjure a years-long GitHub history.

≥ 6 mo
Account age

From GitHub account creation date.

≥ 3
Public repositories

With non-trivial commit history, not stub repos.

≥ 30
Commits / 12 months

Sustained activity in the prior year.

1+
Profile completeness

Display name OR bio OR linked URL.

opt
Public org membership

Optional. When present, grants higher trust weight.

read
OAuth scope

read:user only. No private repos, emails, or any private data.

AI can generate a review in seconds. AI cannot generate a 6-month commit graph across multiple repositories with believable language patterns and cross-references to real projects.
02
Step two

Review structure

Each verified review is a structured object — not free-form text. Seven required fields capture the context that determines how heavily the review counts.

Field 1

Score (1.0–5.0)

Whole or half points. Aggregates display as 1–10 (a 2× transform).

Field 2

Use-case context

"Production agent loop." "Side-project prototype." "Internal tool." Specific.

Field 3

Stack signal

Primary language(s) and runtime the reviewer was operating in.

Field 4

Team-size band

Solo, startup, mid, or enterprise. Determines context-fit weighting.

Field 5

Time on tool

Days, weeks, months, or years. Reviews under 30 days carry reduced weight.

Field 6

Quote + prose

A one-line distillation and a 100–300 word body. Both public.

Field 7 · MANDATORY

Conflict disclosure

Vendor employees, contractors, paid relationships, and competing-product employees must declare. Undisclosed conflicts trigger removal and a 12-month review ban.

03
Step three

Review weighting

Each review carries a credibility weight between 0.5× and 2.0×, applied multiplicatively. Stronger signals get more voice.

Recency decay curve

Reviews older than 18 months decay 25% per year.

1.1× 1.0× 0.5× 0d 30d 6mo 18mo 3yr 5yr 0.7× new decay starts at 18mo

Reviews newer than 30 days carry 0.7× until the reviewer can confirm sustained use. Reviews from 6–18 months carry full weight. Beyond 18 months, weight decays at 25% per year — so a 5-year-old review is worth roughly half a recent one. Public-disclosure paid sponsorships are not eligible to be reviews; they become labeled testimonials.

04
Step four

Aggregate scoring

The headline 1–10 score on each tool page is a weighted mean of reviewer scores after the multipliers above are applied, rounded to one decimal.

We require a minimum of 5 verified reviews before a score is publicly displayed. Below 5, the tool is "Tracked, not yet scored" — the page exists, the reviews are visible, but no aggregate appears.

Tools with a publicly disclosed material outage in the past 90 days carry a methodology footnote on their detail page. Outage windows do not subtract from the score, but reviews submitted during or about the outage carry full weight.

The score formula
SUM( score · weight )
SUM( weight )
Reviewer score range1.0 – 5.0
Weight range0.5× – 2.0×
Min reviews to publish5
Display range1.0 – 10.0
05
Step five

Manipulation defense

Four layered defenses, each tuned to a different attack pattern. None alone is sufficient. Together they make review-spam structurally unaffordable.

Sock-puppet detection

GitHub-graph analysis flags clusters of accounts with shared org membership, shared repo contributors, simultaneous creation, or near-identical bios. Flagged clusters route to manual review.

Vote-brigade detection

Surge detection on review submissions per tool per 72-hour window. Surges trigger a temporary score-display hold while moderators inspect the submitting cohort.

Vendor outreach disclosure

Vendors may notify their developer community that GitShowcase exists, but cannot offer compensation, gifts, or any consideration. Documented violations trigger a 90-day score freeze.

Public removed-review log

Removed reviews appear in a public log keyed by anonymized review-id, with the removal reason and decision date. The reviewer is notified and may appeal.

06
Step six

Versioning + disputes

This page is the canonical methodology and is versioned. Any rule change creates a new version with a public diff. Current version: v1.0 effective 2026-04-30.

If you believe a review of yours, your team's, or your tool's was mishandled — incorrectly removed, incorrectly weighted, or in violation of these rules — file a methodology dispute. We log every dispute and respond within 5 business days.

5
Business days to first response
100%
Disputes logged publicly
v1.0
Current methodology version
The open-methodology pledge

Every rule on this page is challengeable. If a vendor or reviewer can show, with public evidence, that a rule produces an unfair outcome — we publish the evidence, the dispute, and the resolution.