From Contributor Graph to Ranked Candidate Shortlist

A repository's contributor list looks like a candidate list. It is not. It is a raw graph full of bots, forks, one-commit drive-bys, and one human split across three emails, ordered by the wrong signal. This guide is for technical sourcers who already have one or more relevant repositories and need the back half of the work: the repeatable procedure that turns a contributor graph into a deduplicated, noise-filtered shortlist ranked by role fit and contactability, where every cut and every rank position is defensible.

Most GitHub-recruiting advice stops at search syntax and "check the pinned repos." That leaves you holding a noisy list and no method. What follows is the method - what to do at each stage, how long it takes, and what a good result looks like.

Why the raw contributor graph is not a shortlist

The contributors graph you see in the GitHub UI is a proxy for typing volume, not seniority, and it is incomplete by design. Two properties make it unsafe to hand to a hiring manager as-is.

First, it ranks by the wrong thing. The graph sorts contributors primarily by the number of commits they made to the default branch. A maintainer who squash-merges 40 pull requests into 40 single commits can rank below a contributor who pushed 200 formatting commits. The order you inherit measures keystrokes, not judgement.

Second, it hides the tail and drops whole categories of work. The graph shows only the top 100 contributors. Contributor insights are available only for repositories with fewer than 10,000 commits. Merge commits and empty commits do not count. And if all of someone's commits sit on a non-default branch - a gh-pages branch, say - they never appear at all. So a project that looks small in the graph can have hundreds of real contributors underneath it.

The job, then, is not to read the graph. It is to rebuild the roster from underneath the graph, clean it, and impose your own ranking. There are seven stages, and each one removes a specific kind of lie the raw list tells.

The scarcity that decides how ruthless to be

Before you touch the list, decide how much the tail is worth cleaning, because supply scarcity - not repository size - is the real ranking pressure. For a scarce skill, every recovered core contributor matters; for an abundant one, you can afford to cut aggressively and still fill the funnel.

The numbers make this concrete. In Refolk's index of professional profiles, the supply of engineers listing a given language varies by several times inside the same market.

Block B - Skill supply within one market (US)

Counts come from Refolk's index; the ratio is derived (2,792 / 606 = 4.6).

Geography multiplies the effect. The same index shows the US holds far more Rust talent than Germany, so a shortlist built from one global repository will skew toward US-resolvable identities and quietly under-serve a Germany-based plan.

Block A - Rust engineer supply, US vs Germany

Counts from Refolk's index; the multiple is derived (606 / 91 = 6.7).

The practical reading: for a Rust repository, being ruthless about the drive-by tail is worth the hour it costs, because substitutes are thin. For a Go repository, the substitutes are abundant, so you can cut faster and lean harder on recency and location. Set your threshold before you start, not after you have fallen in love with a profile.

The procedure, start to finish

Here is the full method in order. Each stage names who does it and roughly how long it takes on a single repository. Done right, the whole pass runs in two to four hours and produces a shortlist you can defend line by line.

The stages below give the detail that makes each one defensible.

Stage 1 and 2: enumerate, then de-automate

Pulling the full set takes 15 to 30 minutes. Cloning the repository and running git shortlog -sne on the default branch enumerates every author with their email, including the tail the UI drops. If you cannot clone, page the commits API. The output is your working roster.

Stripping bots takes 20 to 40 minutes and is more dangerous than it looks, because detection accuracy is weakest exactly where it hurts. None of the standard bot-detection techniques are accurate enough among the 20 most active contributors of a project unless you combine them. So the CI bot you most need to remove sits near the top of your list, wearing a "core contributor" costume.

Combine three signals: the explicit [bot] suffix, a list of known names (Dependabot, Travis, Coveralls, Hound), and behavioural patterns in comments and commit messages. Where the top of the list is ambiguous, run a purpose-built detector.

Block C - Bot-detection ground-truth scale

Scale and labels are from the published BoDeGHa/BoDeGiC and BIMAN datasets. The point of the table is not the tools themselves but the reminder that bot detection is a trained, statistical task - it is not something eyeballing the top 20 reliably solves.

Stage 3: forks and branches

This is a fast check, about 10 minutes, but skipping it credits people for work that never landed. Fork-only contributors never reach the canonical default branch, so they should not appear as committers on it. Confirm you cloned the upstream repository, not a popular fork, and that you enumerated the default branch. A commit on gh-pages or a personal branch is not upstream work and does not earn a spot.

Merging identities without splitting or fusing people

Merge on the account-linked numeric noreply ID first, because it is the only join key that survives a username change; fall back to verified email, then to name only as a tie-breaker. This is a 30-to-60-minute stage and the one where a careless join quietly corrupts the whole shortlist.

Git stores separate author and committer identity fields on every commit, and one person routinely uses several emails across machines and jobs. Left raw, that produces two opposite errors: one human across three emails looks like three weak contributors, or two different people sharing a common name get fused into one. Both distort the ranking.

The noreply ID is the anchor because of how GitHub builds it. For accounts created after July 18, 2017, the private noreply address takes the form ID+USERNAME@users.noreply.github.com, where the numeric ID is tied to the account rather than the changeable username. Commits made with that address link directly to the GitHub account. So the numeric prefix is stable even when someone renames themselves.

The mechanism for recording the merges is Git's own .mailmap file, which tells Git that several author identities are one person.

# Canonical Name <canonical-verified@email>  <alias-email-one>
Jane Doe <jane@company.com>  <jane.doe@personal.com>
Jane Doe <jane@company.com>  <12345+janedoe@users.noreply.github.com>
# Split a shared common name by anchoring on distinct noreply IDs, not the name
Alex Smith <alex.a@work.com>  <67890+alexsmith@users.noreply.github.com>
Alex Smith (other) <alex.b@work.com>  <54321+alex-s@users.noreply.github.com>

Cluster in this order every time: numeric noreply ID, then verified email, then name plus a corroborating profile signal such as a matching linked URL or location. Name is the weakest key. If two rows share only a common name and nothing else, keep them separate and flag them.

This identity-resolution work is where an outside index earns its keep. Once you have a clean per-human row with a name and any linked profile, matching that person to their current employer, location, and reachable contact is a separate lookup - and doing it by hand across a hundred rows is what actually eats the afternoon.

By the end of this stage you have exactly one row per human, and you can say why each merge or split happened.

Ranking on role fit instead of typing volume

Rank on evidence of contribution substance - tenure, recency, merged-PR ratio, and the area of the codebase touched - and record which measure you used, because commit-based and pull-request-based rankings genuinely disagree. This stage takes 30 to 45 minutes and is where the shortlist gets its actual order.

The trap to avoid is inheriting the graph's order. The graph sorts on default-branch commit count, which over-credits volume and under-credits the person who reviews, designs, and squash-merges. Young et al. found that the method used to mine contributor data influences the result, and that using pull requests is more precise than raw commits for determining contributors. So the two rankings are not interchangeable, and an honest shortlist says which one it used.

Score each surviving human on four fit signals. For each, know what it proves and what it looks like when it lies.

Fit is one axis. Contactability is the other, and it is independent - which is why the next stage gets its own column rather than being folded into the ranking.

Resolving contactability as its own column

Score contactability separately from fit, because a perfect core-maintainer match can still be unreachable through GitHub alone. This is a 30-to-60-minute stage, and conflating it with fit is a common way to build a shortlist that looks strong and converts to nothing.

Extract commit-author emails from git log. Then classify each identity into one of three contactability states, because they are not equal.

The two failure states are worth stating plainly. An account-linked noreply address - the ID+USERNAME@users.noreply.github.com form - lets you attribute a commit to a person, but it does not deliver mail, so it is an identity anchor and not a contact. And managed-user accounts created after August 1, 2024 are email-unverified by default, so an address that looks reachable may not be.

Mark contactability as its own column. A core-and-reachable contributor goes to the top; a core-but-unreachable one goes to an intro path or a profile lookup elsewhere before you write them off.

How this goes wrong

The failure modes below are the reason the procedure exists. Each one produces a plausible-looking shortlist that is wrong, and each has a specific check. This is the part worth re-reading before you ship a list.

• Ranking by raw commit count. The graph sorts on default-branch commits, so a squash-merging maintainer looks smaller than a noisy formatter. The false positive is a whitespace-fixer ranked above an architect. Check: read the substance of merged pull requests, not the commit tally.
• Trusting the top-100 graph as complete. Contributors ranked 101 and below vanish from the UI. The false positive is a "small project" that actually has hundreds of contributors. Check: enumerate via the API or git shortlog, never the graph alone.
• Bots in the top 20. Detection is weakest among the most active accounts, so a CI bot can present as a core contributor. Check: combine name, comment-pattern, and commit-message signals rather than trusting one.
• Duplicate identities inflating or splitting a person. One human across three emails looks like three weak contributors; two people with a shared common name get fused. Check: join on the numeric noreply ID before name.
• Fork commits mistaken for upstream work. Commits on a fork or a non-default branch never count upstream. The false positive is crediting someone for work that never merged. Check: confirm commits are on the canonical default branch.
• Assuming a commit email is contactable. Account-linked noreply addresses attribute but do not deliver, and managed-user emails may be unverified. Check: distinguish a noreply ID from a real deliverable address.
• Treating an acknowledgment list as the roster. All Contributors-style models are less generous than commit data and can miss contributors while crediting non-code work. Check: cross-reference the acknowledgment list against the actual commit history.

Before you call the shortlist done

Run this check before the list leaves your hands. Each item corresponds to a way the list lies if you skip it.

Keeping the shortlist current

A contributor shortlist decays the moment you build it, because commit activity, employer, and reachability all move. To keep it useful, re-run the enumeration and recency scoring on the same repository on a cadence that matches your pipeline - monthly for an active search, quarterly for a watchlist - and diff it against your last pass so new core contributors surface and dormant ones drop.

Two fields decay fastest and are worth re-checking every pass: recency of commits, which governs the fit ranking, and contactability, since employer moves change deliverable addresses and a former public email may go stale. The identity merges you did on noreply ID are the stable part - those IDs survive renames, so your .mailmap keeps working across re-runs. Rebuild the perishable columns on top of that stable spine, and the shortlist stays defensible without starting from the raw graph each time.