From Contributor Graph to Ranked Hiring Shortlist

You have one technical role to fill and a hunch that the right people are already contributing to two or three open-source projects in your stack. This guide is for in-house sourcers, recruiters, and founders doing their own hiring who want to turn a project's contributor list into a deduplicated, ranked, reachable shortlist - with bots, drive-by contributors, and off-target committers already stripped out. It is a fixed-time-box procedure you run start to finish, not a framework you improvise around.

The promise is specific: a two-hour sprint that ends in a tiered shortlist with a one-line evidence note per name, instead of the hour-per-person triage that makes repo sourcing feel like a punishment.

Why repo mining beats keyword search for one role

Repo mining wins when the pool is thin or when quality, not quantity, is the bottleneck. A contributor graph is a list of people who have already proven they can work with your technology, which is a stronger starting signal than a profile that merely mentions it.

Two numbers from Refolk's index set the strategy. When a skill is scarce, the graph stops being a sample and becomes the pool itself.

Counts from Refolk's index; the multiple is 3,500 divided by 966.

Germany has 966 Rust engineers against 3,500 in the US, a market 3.62x thinner. In a pool that small, the GitHub Search API's 1,000-result cap rarely binds, and the contributors to the two or three canonical Rust projects are close to the whole addressable market. Mining the graph directly is not a shortcut here; it is the correct method.

The opposite case is abundance. Go's US pool is 4.62x the size of Rust's.

Counts from Refolk's index; the multiple is 16,168 divided by 3,500.

For an abundant skill like Go, finding people is trivial and filtering is everything. That is exactly where the bot-stripping and depth-ranking steps below pay for themselves, because the raw contributor list is enormous and mostly noise.

What the contributor graph actually tells you, and what it hides

The graph is a ranked list of who committed to a repo, and it is more honest about volume than about quality or completeness. Treat it as a lead list, not a verdict.

Three structural limits shape everything downstream. First, the GitHub Search API returns a maximum of 1,000 results per query, at 100 items per page across ten pages, and gives no error when you hit the cap. Second, the native contributor graph claims to exclude bot accounts but only strips logins recognised as GitHub Apps, meaning those with a [bot] suffix. Third, 82% of GitHub contributions happen in private repositories, so the public graph under-counts senior engineers who ship privately.

That last figure changes how you read a quiet profile. If someone's public window is thin, that is not proof they are inactive; it is proof they may work somewhere that keeps its code private. Rank on the depth you can see and never disqualify on the absence of what you cannot.

Pick the right projects before you pull a single name

Choose repos that match your exact stack, and prefer strong mid-size projects over the largest ones. The mega-repos concentrate stars on a handful of maintainers who are already over-contacted and least likely to reply.

If you find a popular project matching your stack, its contributor list is a goldmine, because those developers have proven they can work with your technology. For a Kubernetes role you look at contributors to the Kubernetes repo. But the biggest project in a language is rarely the best hunting ground for outreach, because the visible top contributors there get bombarded. Aim for the second tier: projects with real adoption and 20-plus stars on original work, where a strong contributor is not yet drowning in recruiter messages.

The judgement call is a two-variable one. Match against your stack on one axis, and contact saturation on the other.

Reading order runs top-left, top-right, bottom-left, bottom-right. The bottom-left quadrant - high stack fit, low saturation - is where a Tuesday sprint should spend most of its time.

The two-hour procedure, stage by stage

Run these eight stages in order. Each has an owner, a time budget, and a definition of done, so you can stop when a stage is finished rather than polishing forever. The whole sprint fits in roughly two hours.

The commands that carry the middle stages

The canonical per-author count that excludes merge commits is one line. Clone the repo, then run it.

# Full history, one row per author, with email, merges excluded
git shortlog -sn -e --no-merges

# Group by email to collapse alias names into one person
git shortlog -e -s

# Re-run over the last six months to separate core from drive-by
git shortlog -sn --no-merges --since="6 months ago"

Prefer cloning over the API when you can. The full local history lets you exclude merges, group by email, and inspect merge strategy - none of which the API contributor graph gives you cleanly, and it arrives bot-polluted. Use the API only when cloning is impractical, and remember the 1,000-result cap and the separate 10-requests-per-minute limit on code search.

When the manual pull is the wrong use of two hours - because the skill is abundant and filtering, not finding, is the whole job - Refolk runs the same intent in plain English and hands back the filtered set. The stages below still matter; you are just skipping the parts a machine does faster.

Strip the bots, or your ranking is fiction

Filtering only [bot] logins is the single most common way a "ranked" list ends up polluted. The native graph strips GitHub Apps and nothing else, so every unsuffixed machine account survives - and a release bot can sit at the very top of your commit count.

Work in two passes. First remove every login ending in [bot], such as dependabot[bot] and github-actions[bot]. Then sort by commit count and inspect your top few names by hand, because the dangerous ones - snyk-bot, pre-commit, all-contributors, and various release accounts - carry no suffix and hide in plain sight near the top of the list.

The volumes in that funnel are illustrative of the shape, not fixed counts; the ceiling of 1,000 is the real cap. What matters is that per-person time only gets spent at the narrow end, after three cheap filters have done their work.

Rank on depth, not on green squares

Rank contributors by evidence of real work, not by the density of their contribution graph. Green squares are easy to manufacture and popularity is a poor predictor of reply rate, so both mislead if you rank on them.

Contribution graphs can be backdated or auto-generated, and a dense graph with no original repos behind it is theater. Read the commits rather than counting them: check whether a person writes original code or just forks, and look for meaningful pull requests, issues, and community engagement. Depth matters more than daily consistency.

Use a four-signal rubric. For each signal, know what it proves and what it looks like when it lies.

The bus factor is a useful cross-check. If one person accounts for 60% or more of a repo's commits, that concentration flags them as the load-bearing maintainer - valuable to know, and also a person who is probably stretched. And contributors with 3 or more weekly commits have been linked to 68% higher retention when hired, so sustained depth in your window is worth weighting.

The ranking you trust most is the one squash merges break first, so confirm the merge strategy before you believe the top of the list.

How this goes wrong

Most of the damage happens silently: the list looks finished and clean while measuring the wrong thing. Here are the seven failure modes to check for, each with a concrete test.

Silent 1,000-result truncation. A full last page looks complete but can hide more results, and GitHub raises no error. Check: if total_count exceeds 1,000, split the query into progressive date ranges and merge the pages.

Bot leakage. Filtering only [bot] logins leaves snyk-bot, pre-commit, and release accounts, none of which carry the suffix. The false positive is a "top contributor" that is a release bot. Check: sort by commit count and inspect the number-one entry by name.

Squash-merge distortion. When a team squashes every PR into one commit, the top of git shortlog is the merge account, not the strongest author. The output can show a merge identity as the most-committed contributor, which is not what you want. Check: confirm the repo's merge strategy and group by author, not committer.

Green-square theater. Contribution graphs can be backdated or auto-generated, so a dense graph is not proof of skill. The false positive is a busy-looking profile with no original repos. Check: the original-vs-fork ratio and merged-PR count.

Masked emails. A privacy-masked address of the form ID+username@users.noreply.github.com blocks direct email but not the person. The false negative is discarding someone as unreachable when the profile links out. Check: open the profile before dropping anyone.

Over-contacted stars. High-follower contributors rarely reply because they are already saturated with outreach. The false positive is ranking the most famous name first. Check: rank by depth, not follower count.

Drive-by inflation. A one-typo-fix contributor ranks as a "contributor" in the all-time list. Check: the 6-month windowed re-run drops them automatically.

Resolving contributors to reachable people

A shortlist is only useful if you can contact the people on it, so resolve every survivor to a live profile and at least one reach path before you rank. Reachability, not ranking, is where most repo-sourcing sprints quietly fail.

By default a commit holds the contributor's email as well as their username, and grouping by email with git shortlog -e -s collapses aliases into one person. But many emails are privacy-masked. GitHub only associates a commit with a profile when the commit email matches a verified account email, so a masked noreply address will not link cleanly. That does not make the person unreachable. Open the profile: it often lists an org, a location, a personal site, or a linked account, any of which is a reach path.

Seniority is the other reason to finish the resolution and scoring rather than stopping at a raw list.

Counts from Refolk's index; the share is 1,234 divided by 3,500.

Only 35.3% of US Rust engineers carry a senior tag, so a specialist pool is still mostly not senior. A shortlist that skips the windowed depth score will over-represent junior drive-by contributors and bury the seniors you actually want, because juniors often out-commit seniors on public repos while seniors ship privately.

Verify before you call it done

Before you hand the shortlist to outreach, run this checklist. It maps directly onto the failure modes above, so a clean pass means the list is measuring what you think it measures.

Keeping the method current

Two things in this procedure will drift, so build a habit of re-checking them rather than trusting a value you cached. The API limits and the bot landscape are both moving targets.

Rate limits and caps change by era and by tier. Enterprise docs currently list 30 requests per minute authenticated and 10 unauthenticated for the Search API, code search sits at a separate 10 per minute, and older mirrors quote different numbers. Before a large pull, re-read the current changelog for the endpoint you are using rather than assuming last quarter's figure. The 1,000-result-per-query cap has been stable, but the throughput around it has not.

The bot list also grows. New automation accounts appear constantly, and few of them adopt the [bot] suffix that the native graph filters. Keep a running pattern list of the machine accounts you have caught - snyk-bot, pre-commit, all-contributors, common release bots - and add to it every time your top-committer inspection turns up a new one. That habit is the difference between a ranking that measures engineers and one that measures automation.

Finally, re-run the whole sprint against a repo you already know well once in a while. If the shortlist it produces matches your intuition about who the real contributors are, your filters are calibrated. If a release bot or a one-commit typo fixer survives to a top tier, one of the cheap filters has slipped, and you will find it faster on a repo where you already know the right answer.