From a Stack Requirement to a Repo-Sourced Ranked Shortlist

You have an open role that names a specific, hard-to-find technology stack, and you need a ranked shortlist of the people who actually build in it, not people who have merely used it. This playbook is for in-house recruiters, sourcers, and founders hiring their own engineers. It takes you from a role brief that names a stack to a deduplicated, ranked, outreach-ready shortlist of 20 to 30 real contributors, drawn from across the ecosystem's authoritative repositories rather than one trending repo, without sourcing the same person twice.

Most GitHub-sourcing guides stop at search operators and the contributors tab. The hard parts they skip are the ones that decide whether your shortlist is real: choosing the authoritative repos for a whole ecosystem, mining and merging contributors across them, resolving each masked identity to a reachable person, and ranking the survivors. That is the work here.

Why one trending repo will not give you a shortlist

Contribution to open source is hyper-concentrated, so a single repository names only a handful of genuine builders no matter how many contributors it lists. This is the fact that forces the whole multi-repo method.

The numbers are stark. Fastlane lists over 900 contributors, but four developers produced more than 70 percent of its commits in 2018. Pandas lists over 1,400 contributors, yet four produced nearly half of all commits that year. The pattern holds at the population level: in one analysis of database repositories, 58 percent of active contributors added only one or two commits and vanished, while 69 percent of all commits came from contributors with three or more commits in a target repo.

The consequence for sourcing is direct. If you mine one popular repo, you get four to a dozen real builders and several hundred drive-by committers you will waste time filtering. Coverage of a niche stack is won by selecting many authoritative repos across the ecosystem, each contributing its own small set of core people, and then merging them. The repo list is the single highest-leverage decision in this procedure.

Coverage is won in the repo list, not the query. One repo names a handful of real builders; an ecosystem names a shortlist.

Know your market before you source

Niche-skill talent pools are market-specific, and the relative size of two stacks can flip between countries, so a sourcer who assumes one market's ratios in another will over-resource the wrong stack. Read your target geography before you commit to a repo set.

In Refolk's index of professional profiles, the ranking of two popular niche stacks reverses across the Atlantic. Elixir is the larger pool in the United States, but Rust is the larger pool in Germany.

Niche-skill talent pool by country, from Refolk's index

Skill ranking flips by market

Read the second table before you plan. If your role is Elixir and your location is Germany, you are fishing in a pool of 792, smaller than the German Rust pool, and you should expect to mine harder and reach wider than a US Elixir search would require. There is one lever that improves your odds: niche German pools are metro-concentrated. In a 25-person sample of German Elixir profiles in Refolk's index, Berlin was the top region for 10 of them, so geo-targeted outreach into one metro reaches a large share of the national pool.

Choose the right search surface first

GitHub has three distinct search surfaces that are not interchangeable, and picking the wrong one is the fastest way to miss people. Choose the surface before you write a query.

Repository search uses topic:, language:, stars:, and pushed:, and it is how you find the ecosystem's libraries. Code search uses repo:, language:, and path:. Users search uses language:, location:, followers:, repos:, and created:, and it finds people directly. The qualifiers do not carry across surfaces.

The critical trap lives in users search: its language: filter matches the languages of repositories a person owns, and a framework is not a language. Search language:react and you silently get the whole JavaScript and TypeScript pool. For framework specialists, you must search by concrete repository names instead, which is exactly why this method is repo-first.

Two more surface facts shape the whole workflow. First, the pushed: qualifier returns repositories sorted by the most recent commit on any branch, which is how you filter to maintained projects and to active people. Second, followers: filters by follower count, but followers come from talks, posts, and popular projects, so a high follower minimum mostly removes people who ship without promoting. Do not rank on followers.

Respect the API limits or lose people silently

The GitHub Search API has hard caps that truncate your results without any error, so you must partition broad queries before you run them. This is not a performance concern; it is a correctness concern.

GitHub search hard limits

A broad query returns its first 1,000 results and hides the rest with no exception. A popular language or a high-star repo set cannot be enumerated in one pass. The fix is a range-split: partition by stars: bands or pushed:/created: date ranges into non-overlapping slices, each returning well under 1,000, and page through all of them. A query returning 1,000 results needs 10 paginated requests at 100 per page, and you get 30 such requests per minute authenticated, so budget your time accordingly.

The procedure: brief to ranked shortlist

This is the full method in order. Each step names the owner, a rough duration, and what done looks like. Run it top to bottom; the convergence and identity-resolution steps in the middle are the ones that make the shortlist real.

Framing the repo list (step 1)

Awesome-lists and topic pages enumerate an ecosystem's authoritative libraries by category and give you a selection frame. Awesome Elixir, for example, is a curated list of Elixir and Erlang libraries organised by purpose. The topic namespace is the other input: the elixir-lang topic alone contains 1,711 public repositories, far too many to mine, so you filter within it by stars and recent push.

Applying the core-contributor floor (step 4)

The core-contributor definition is commit-share based, not an absolute number: the smallest subset of developers who collectively contributed more than 80 percent of total commits. One large study added a floor on top of that share, excluding contributors who stayed less than 30 days or made fewer than 10 commits. Apply both: keep the top-80-percent set, then drop anyone below the tenure and commit floor. This is what separates the four Fastlane builders from the 900-person contributor tab.

Resolve masked identities to reachable people

Identity resolution is the step the ranking blogs skip, and it is lossy enough that you must plan for it rather than assume an email will be sitting on each profile. The documented method reads author and committer identity from public commit metadata.

Every Git commit records two identities: the Author who wrote the code and the Committer who applied it. They usually match but can diverge during rebasing, cherry-picking, or merging. You read the author email by appending .patch to a commit URL; the address in the From: field is the one set in that person's local git config. GitHub then attributes the commit by matching that email against current users, and if the email belongs to an account, that account is shown as the author.

The resolution is lossy. The API returns a null email for most users, commit metadata is rewritten to a users.noreply.github.com form by default, and the public events archive obfuscates many addresses with hashes. The recovery trick: a noreply address encodes the login after the plus sign, so even a masked address resolves to the account. Discard noreply addresses for outreach, decode the login, and resolve the person through their profile.

Because the same core contributors recur across an ecosystem's libraries, the person count collapses sharply after you merge on email and login. Treat deduplication and identity resolution as the core cost center of this job, not a cleanup pass.

When the manual path stalls on masked emails and recurring aliases, Refolk does the convergence and identity resolution for you: ask for the people who build in a stack and it returns deduplicated, resolved profiles across the ecosystem's repositories rather than one repo's contributors tab.

How this goes wrong: failure modes and false positives

Most bad shortlists come from a small set of repeatable mistakes, and each has a specific check that catches it. This is the section to re-read before you trust a list.

• Framework-as-language miss. Searching language:react or language:phoenix silently resolves to the host language and returns the whole pool. Check that any qualifier you use is a real GitHub language; for frameworks, search the repository by name instead.
• Location free-text gap. location:"Berlin" drops everyone who typed "Deutschland" or left the field blank, a false negative that shrinks a real pool. Check with several location strings and metro normalization, or resolve geography from profiles after mining.
• 1,000-result silent truncation. A broad query returns the first 1,000 and hides the rest with no error. Check by splitting into star or date ranges and confirming the ranges cover the full span.
• Drive-by false positive. Someone on the contributors tab may have a single typo-fix commit and look like a builder. Check commit count and tenure against the 10-commit, 30-day floor.
• Noreply or null-email dead end. Resolution yields no deliverable address and outreach stalls. Check for the +login pattern in the noreply address to recover the account even when the email is masked.
• Spoofed attribution. Commit attribution is spoofable; with a crafted git config an attacker can push code that appears authored by someone else, and GitHub treats this as a known issue. Check for signed commits and corroborating profile activity before you credit a person.
• Bot and CI pollution. A build bot committing under an engineer's login inflates that person's counts. Check for and exclude known bot names and aliases during deduplication.
• Followers mistaken for skill. Ranking on follower count surfaces promoters, not necessarily shippers. Check by weighting recent commit activity instead of followers.

Score, rank, and verify

No single authoritative scoring rubric is published, but practitioner guidance converges on a consistent set of inputs, and you can defend a ranking built from them. Combine four signals into one composite score.

Fit is read from commit share and core-contributor status per the 80-percent definition, because a long history of sustained contribution to major projects shows someone understands the language deeply rather than merely using it. Recency is a filterable signal: a recent pushed: date confirms the person is still active. Seniority is a proxy drawn from enrichment such as tenure and title. Reachability is the resolved contact from the identity step, because an unreachable top-ranked person is worth less than a reachable second choice.

Fit (0-40): commit share and core-contributor status across the mined repos.
  Core across 2+ repos = 40; core in 1 repo = 30; past floor but not core = 15.
Recency (0-25): last public push.
  Within 3 months = 25; within 12 months = 15; older = 5.
Seniority proxy (0-20): tenure and title from enrichment.
  Staff/lead signal = 20; senior = 12; unclear = 5.
Reachability (0-15): resolved contact quality.
  Deliverable email = 15; login + profile only = 8; masked, no account = 0.
Composite = sum. Sort descending. Cut to the top 20-30.

Run the final verification before you hand the list off. The checklist below is what "done" means for this job.

Keep the shortlist current

A repo-sourced shortlist decays as people change jobs, stop committing, and update their profiles, so re-run the recency and reachability steps rather than the whole procedure when you reopen a role. The expensive parts, repo selection and deduplication, hold up over time; the cheap parts, last-push recency and contact resolution, are what go stale.

Set a stopping rule for repo coverage you can reuse: keep adding authoritative repos until a new one adds no new people after deduplication. That saturation point is empirical, not a published constant, and it is the honest signal that your ecosystem coverage is complete. When you return to the stack later, start from the same repo set, add any libraries that have risen in stars since, and re-mine. And re-read your market read first: because skill rank flips by country, a method that worked for a US Elixir role will mislead you on a German one.