Early signals · method
How early signals work
Each rule names the measurement that raised it, the threshold it had to clear, and what would have made it stay quiet. When a flag is wrong we keep it: the ledger counts flags that were right, flags that were wrong and flags whose window has not elapsed, separately.
The rules
A repository can carry more than one flag: each rule is stored as its own row with its own numbers. Repeats of the same rule for the same repository are suppressed for 14 days, so one flag means one prediction with one full 14-day window.
Accelerating
gained at least 200 stars in the last 7 days, at least 5× its own average week over the previous 26 weeks (weeks with no star history are ignored, and the average is floored at 10 stars/week so a repository that was flat does not divide by zero), with at least 8 weeks of history, and it has never appeared on GitHub Trending.
First mover
was mentioned in a Hacker News thread or Reddit post in the last 7 days and has never appeared on GitHub Trending.
Small and hot
has fewer than 5000 stars but gained at least 500 stars in the last 7 days, which is at least 50% growth.
Topic tailwind
carries a topic where at least 3 repositories each gained 100 stars in the last 7 days and those movers are at least 30% of the topic's 20+ tracked repositories (topics read within the last 30 days).
Thresholds, as the code uses them
These are the constants the pipeline runs on, read from the same registry the rules use.
| Accelerating: stars gained in the window | 200 |
|---|---|
| Average-week ratio | 5× |
| Baseline: weeks averaged (most recent) | 26 |
| Baseline: weeks required | 8 |
| Baseline floor (stars per week) | 10 |
| First mover: mention window | 7 days |
| Small and hot: star ceiling | 5000 |
|---|---|
| Stars gained in the window | 500 |
| Relative growth | 50% |
| Topic tailwind: repositories per topic | 20 |
| Moving repositories per topic | 3 |
| Stars per moving repository | 100 |
| Share of the topic that must be moving | 30% |
| Topic seen within | 30 days |
What counts as an outcome
Every flag is checked once, after 14 days. The check runs against the data we had measured by then, and the numbers it used are stored with the flag.
- Right:the repository showed up on GitHub Trending inside the window.
- Right:the repository reached the top 100 of our own 7-day ranking.
- Wrong:the repository nothing happened inside the window.
- Wrong:the repository was already on GitHub Trending before we flagged it.
- The top 100 is measured against our own 7-day ranking over repositories we track that are not archived or forks. It is not the front page of this site, which filters one step further.
The bar this feature has to clear
Written down before any of the numbers below existed, so the decision is not made by whoever is looking at the results.
- Accuracy at 14 days of at least 40% over flags that were decided. Below that, the rules get fixed or the page comes down.
- Median lead time of at least 2 days before GitHub Trending shows the repository. Below that we are only trailing Trending more closely, not leading it.
- At least 10 new flags a week. One or two a month cannot be read as a signal.
- Every number on the ledger traces back to rows we measured, including the top-100 cut used at check time, which is stored with each decided flag.
Our own history has a floor: star snapshots and GitHub Trending records start on 22 Sep 2026, so nothing here claims accuracy before that. The weekly star history is read as a baseline only, which is why the accelerating rule needs 8 weeks of it before it can fire.
Data comes from our own measurements: 100 is the rank threshold used for our ranking outcome, and every rule above is deterministic. There is no machine learning model and no combined score anywhere in this feature.