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):
| Window | Looks back (L) |
|---|---|
| Today | 1 day |
| This week | 7 days |
| This month | 30 days |
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:
| Window | Min stars gained (A_min) | Min growth (P_min) |
|---|---|---|
| Today | 15 | 1% |
| This week | 75 | 5% |
| This month | 200 | 12% |
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
- Take today's star count for every repo (S_now).
- For each window, find its baseline (S_base) — the latest complete snapshot at or before L days ago.
- Compute the absolute gain A and the percentage gain P.
- Keep only repos where both A ≥ A_min and P ≥ P_min.
- Rank the survivors by score, take the top 50, and show them.