How we built the GitPop radar: a behind-the-scenes look

Quick answer. The GitPop radar runs a five-stage pipeline on a scheduled refresh cycle: (1) Topics discovery — curated GitHub topics act as seeds, (2) Candidate expansion — trending pages and community mentions widen the funnel, (3) Data fetch — public GitHub REST + GraphQL APIs, (4) Quality gate — the Noise Filter hard-skips content-only repositories, (5) PopScore compute — the 0-100 score from velocity, engagement, activity, and mentions. This post walks through each stage.

Stage 1: Topics discovery

The first stage is "what projects should we be tracking?" The radar uses GitHub Topics as the seed — a curated list spanning llm, rag, react, rust, kubernetes, devops, mobile, data-engineering, and more.

On each refresh, topics rotate so every category gets regular coverage. For each topic, we pull the top repos by star count from the GitHub Topics API. That produces a steady stream of new candidates every day.

Stage 2: Candidate expansion

The candidates from Stage 1 are not enough — we want to track projects that are gaining momentum before they top any topic list. So we add three more discovery paths:

• GitHub Trending — the trending repos from the public trending page.
• Mention scraping — HN, Reddit, Lobsters. Projects mentioned in the last 7 days get added as candidates.
• Reverse dependency — for every project we already track, we look at its ecosystem neighbors that pass the noise filter.

Stage 3: Data fetch

For each candidate, we pull what we need to compute PopScore:

• Star, fork, and open-issue counts (cumulative)
• Star deltas over 7 days and 24 hours
• Commits, merged PRs, issue open/close over 7 days
• Mentions on HN, Reddit, and Lobsters over 7 days
• README signals, license, topics, contributors

We use both the GitHub REST API and the GraphQL API, respecting rate limits with exponential backoff. Everything comes from public endpoints.

Stage 4: Quality gate (Noise Filter)

Not every project is worth tracking. The Noise Filter evaluates every candidate on several dimensions and produces a 0-100 noise score:

• Name pattern — does the name look like a fork, a mirror, a tutorial, or a curated list?
• Fork / archive status — is the project a copy or abandoned?
• Asset quality — does the README have substance? Is there a license?
• Activity — when was the last commit, release, issue close?

A high noise score is hard-skipped; mid-range candidates are tracked but hidden from the radar by default; clean ones appear everywhere.

Without this gate the radar would be flooded with awesome-lists and tutorial repos. With it, noise stays minimal.

Stage 5: PopScore compute

The PopScore is a 0-100 score computed from five components. The full formula is in the methodology page, but at a high level:

• Star velocity (35%) — acceleration from star delta over 7 days
• Fork engagement (20%) — forks weighted by recency
• Activity (25%) — commits, PRs, issues over 7 days
• Mentions (10%) — HN/Reddit/Lobsters over 7 days
• Noise penalty (10%) — the Stage 4 score, subtracted

Projects above 60 are trending. Projects above 80 are surging. The radar surfaces both, plus the long tail of interesting-but-not-mainstream projects.

Wrapping up

That's the loop: discover candidates daily, fetch their public signals, filter out the noise, compute momentum, and publish. The radar page revalidates continuously, so you always see current data within hours of it changing.

For the broader data behind what the radar surfaces, see State of GitPop H2 2026. For the deeper methodology, see What is PopScore? and the methodology page.