Rules
Every number here comes from GitHub. Nothing can be bought, upvoted or launched onto this board.
- 01Only repositories you can push to
GitHub confirms push access before a project is listed. Pasting someone else's repo does not work, and there is no anonymous path - every listing goes through a key tied to an account.
- 02Hours count, not commits
Presence counts distinct hours that contain real commits. Fifty commits in one push is one hour, not fifty. Splitting the same work into more commits changes nothing.
- 03Lines changed are tracked
Depth reads additions and deletions. It saturates, so churning a file to inflate a diff earns almost nothing - and the churn is visible in the record either way.
- 04Automation is not work
Merge commits, bots and generated commits are excluded. Scripted or scheduled commits made to hold a streak are cheating, and the project is removed rather than rescored.
- 05AI counts as work, not as a builder
Commits co-authored by an assistant count toward the total. They do not add a builder, so using one never dilutes your per-builder score.
- 06Timestamps are GitHub's, not yours
Backdated commits gain nothing. The window is fixed, and server-stamped events outrank anything a local clock claims.
What counts as work
A score out of 1000, over the last ninety days, from four parts:
- Presence 400
- Hours that contain real commits, counted once each. This measures showing up, not volume.
- Shipping 250
- Releases and merged pull requests. Work that reached someone.
- Depth 200
- How much actually changed, so a typo fix is not a day’s work.
- Momentum 150
- Recent activity against the ninety-day baseline. Projects fade if they stop.
Each part saturates. Doubling your commits does not double your score, which is what stops the board rewarding noise.
Why per builder
The default ranking divides a project’s score by its effective team size, so a six-person team has to out-work six solo founders per head to sit above them. Effective size is weighted by contribution, not a headcount — one person and a colleague who fixed a typo is not a duo. You can switch to total effort at any time; both are honest, they answer different questions.
What we read
For a public repository, the commit history, exactly as any visitor could — unauthenticated, no permission involved.
For a private one, GitHub’s own repository statistics: commits per day, contributors, and the shape of a working week. That is aggregate data GitHub computes; not a line of code is read, and the key we ask for cannot read one even if we wanted to.
What we never read
The key carries a single permission — Metadata, read-only. It cannot reach file contents, commit diffs or messages, issues, pull request bodies, secrets, or Actions. It cannot write anything, anywhere. GitHub itemises this on its own screen before it issues the key.
For public projects the key is used once to prove you can push to the repo, then discarded. Private projects have no other source of numbers, so their key is kept — encrypted, under a key held outside the database, and dropped the first time GitHub refuses it. Revoke it on GitHub whenever you like.
Proving a project is yours
The product link is verified separately from ownership: it counts as verified when the repository’s own About link points at the same place. Anyone can type a URL; making the repo agree takes repo access. Every row prints the repository its numbers came from, so you can check the pairing yourself rather than taking our word for it.