How a repo becomes "trending"

Starling doesn't guess. Every repository on the board earned its place through the same arithmetic, applied identically to every repo, every day. Here's exactly how it works — the whole calculation, with the math.

The raw material: one snapshot a day

Once a day, Starling records the star count of every public GitHub repository with at least 500 stars — roughly 120,000 of them. Over time this builds a daily history for each repo. "Trending" is entirely a question of how that number changed, so everything below is built from these daily snapshots.

The 500-star floor matters: it filters out tiny repos where a handful of stars would look like explosive percentage growth. Every repo compared is already established.

The symbols

Three windows

The same repo is judged over three time spans, so a slow-burn climber and an overnight sensation both get surfaced. Each window looks back a fixed number of days (L):

Two measures of the rise

For each repo and each window, Starling computes two numbers — how many stars it added, and how fast that is relative to its size:

Percentage is the star of the show. A repo going 500 → 650 (+30%) is more genuinely "trending" than one going 50,000 → 53,000 (+6%), even though the second added more stars. Ranking by percentage surfaces the risers, not the giants.

The eligibility gate

Percentage alone is noisy, so a repo has to clear both a percentage bar and an absolute-stars bar to qualify — a real rate of growth and a real number of stars. The two bars per window:

Ranking the qualifiers

Every repo that clears the gate is ranked, and the top 50 in each window make the board. The ranking score is the percentage gain — with one adjustment for the daily window:

Ties are broken by absolute gain (A), then by current star count (S_now).

A worked example

Take bojieli/ai-agent-book on a recent day — the actual #1 on the daily board:

Handling the messiness of real data

Snapshots aren't always perfectly regular. Three rules keep the math honest:

• Missing days. S_base is defined as "the star count on the most recent complete crawl at or before the window's edge." If a day was skipped, the baseline is simply a little older — and d records the true gap. Nothing breaks.
• Partial crawls. A day where the crawl didn't finish is flagged and never used as a baseline, so an incomplete day can't invent a fake drop.
• Brand-new repos. A repo that only just crossed 500 stars has no earlier snapshot to compare against, so it's held out of a window until it has real history — no phantom "infinite growth."

The whole thing, start to finish

1. Take today's star count for every repo (S_now).
2. For each window, find its baseline (S_base) — the latest complete snapshot at or before L days ago.
3. Compute the absolute gain A and the percentage gain P.
4. Keep only repos where both A ≥ A_min and P ≥ P_min.
5. Rank the survivors by score, take the top 50, and show them.