Rankistan: a leaderboard that decides who counts as active, and shows its working

Five numeric gates decide who is on the board at all

The filter is the interesting part of this project, because it is published as numbers rather than described as a vibe.

A developer has to clear all of these. Meaningful contributions, counting pushes, pull requests, issues and releases, must be at least 30 in the last 60 days. The longest inactivity gap, measured between events or since the most recent one, must be no more than 30 days. The account must be at least 30 days old. Public repositories must be more than 3. Followers must be more than 1.

Two of those five are doing the real work. The contribution floor and the inactivity ceiling are together a statement about what counts as an active developer: not someone with a burst of activity followed by silence, but someone with a steady recent record. A developer who shipped heavily in March and nothing since fails the inactivity gate even with thousands of stars, and that is a deliberate choice about what the leaderboard is measuring.

The other three are hygiene gates. They exclude throwaway accounts and profiles that have never been used for anything public, without much discrimination between candidates.

The scoring that runs after the filter is separate and weighted: stars, 30-day activity with diminishing returns applied per UTC day, followers, and public repository count. The daily cap on activity contributions is what stops a single very busy day from dominating a score.

Twenty-four hourly batches, because the search cap is per request

Rankistan does not rebuild once a night. It runs as a rolling scanner, and the reason is an API constraint rather than a design preference.

GitHub's user search returns at most a thousand results per request. To cover accounts created from 2000 to the present, the discovery step splits the search into 24 date ranges, running from the earliest window through to the most recent, each targeting roughly 800 to 950 developers so it stays under the cap. The windows are written out in the documentation as a single line:

PK 2000-Jun2014 → PK Jul2014-Jan2016 → ... → PK Aug2024-Dec2024 → PK 2025+

That is a coarse partition, and the first window covers fourteen years of accounts while the last covers about one, which is a direct consequence of where the population is. The search is filtered by a country term so each window stays inside Pakistan.

One batch runs per hour, triggered through a third-party cron service invoking a workflow dispatch, so a full cycle completes every 24 hours. The stated goal is continuous refresh of the whole ecosystem while keeping API usage inside platform limits.

The first of the two layers scans more than 40,000 profiles and re-evaluates more than 20,000 that show potential score movement, then applies the gates and publishes only what passes. The second layer is the batching itself.

The newest window is a special case worth reading, because it is where the cap is genuinely awkward. That window can grow past a thousand matching accounts, which would silently truncate results if discovered with a single query. So for the last batch index only, the fetch script runs several narrower searches in succession, concatenates the usernames, and continues as normal. The hourly schedule and the twenty-four batch count are unchanged, and rows from that cohort still carry the same batch marker, so the special case is invisible from the data.

Per-batch replacement, so no row is ever stale for a whole day

Every entry in the published data carries the identifier of the batch that produced it, and the update procedure is written out in four steps.

When batch N runs, it fetches and scores the developers in that batch. It then removes only the entries whose batch marker equals N. It inserts the freshly scored batch, also tagged with N. Finally it deduplicates by username with the latest batch winning, re-sorts, re-ranks, and applies the cap.

The consequence is the sentence the documentation uses to describe it: no downtime, no daily wipe.

A leaderboard rebuilt in one shot has a window where the file is either stale or absent, and a developer can appear or vanish depending on when you looked. With per-batch replacement, a row is at most one batch cycle old, and a developer in the last batch stays on the board for a full day until that batch runs again and refreshes them.

The deduplication step is where this design pays off. Because batches are date ranges, the same developer could be discovered by two of them if their account creation date sits near a boundary, and the latest batch wins rather than producing a duplicate row.

The re-rank and cap at the end of every batch is the other part. A leaderboard that only ever grows is a leaderboard that stops being a leaderboard, so each pass recomputes positions for everyone rather than appending, which means a developer's rank can move up when somebody above them is re-evaluated lower, not only when they score higher themselves.

The pipeline token needs no scopes, which is the security story

The environment example file contains the most careful security guidance in the project, and it is worth quoting rather than paraphrasing.

The pipeline needs a GitHub token, and without one the incremental run exits with a message telling you to set the variable. But the file then explains which endpoints are read, and they are all public ones: user search, a single profile, a user's events, a user's repositories, and a user's social accounts.

The consequence is that a classic personal access token with no scopes at all is sufficient, or a fine-grained token with read access to public repositories and nothing else. The file says plainly: never grant write scopes.

That is a better default than most projects document. A pipeline that reads public data has no reason to hold a credential that can modify anything, and telling the user to leave every scope box empty makes the safe configuration the path of least resistance.

The second half of the guidance is about not needing the credential at all. The frontend reads the committed data file, so running the development server requires no token, and the dry-run mode skips GitHub entirely. The token exists for the pipeline, not for the site, and the optional variable for the summary API is left blank by default so the frontend falls back to the deployed worker rather than requiring configuration.

The Evolution tab exists because the scoring changed and people noticed

Version 2.0.0 is described as a scoring revision, and the release notes name the changes: diminishing returns, daily caps, a new Evolution tab, and a breakdown in the Register view.

That combination is the interesting part. A leaderboard whose formula changes will produce rank movements that have nothing to do with anyone's work, and the honest response to that is to make the changes legible. The Evolution tab is a plain-language history of scoring changes from oldest to newest, the current formula, and why the rules were tightened. The Register tab validates a single profile against the same criteria and shows an estimated score breakdown before any batch sync, so you can see where a number comes from.

Two other tabs carry their weight. The badge generator produces a dynamic rank badge for a repository README, in Markdown, HTML or reStructuredText, which means the leaderboard is designed to be cited rather than merely read. The map groups developers by normalised profile location on an interactive map of Pakistan, with hover syncing the map to the list and clicking a place listing everyone in that bucket, backed by a deterministic normalisation strategy that does token-aware country detection and alias matching for local spellings, with a safe fallback for anything unresolved.

One honest limitation is stated in a note near the top: the frontend is optimised for desktop, and mobile design is under development but usable.

Editorial conclusion

Rankistan fits a developer or writer in Pakistan who wants a public, current answer to who is shipping, and who will read the scoring documentation before treating a position as meaningful. Leave it if you are outside Pakistan or want a leaderboard of organisations, since the discovery search is geographic and the map is a map of one country. Verify first that the gate you are being judged against is the gate you assumed, because a position can change from a rule change rather than from anyone's work, and the site keeps an Evolution tab specifically to explain those changes, which is where you should look before reacting to a drop.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes