# The Repo-Sourced Candidate Standard: Pipeline, Park, or Discard

*You can grade any one repo-sourced GitHub profile as Pipeline, Park, or Discard so that two sourcers reach the same verdict.*

- Canonical URL: https://www.refolk.ai/guides/repo-sourced-candidate-standard
- Pillar: Recruiting and sourcing
- Format: Standard
- Published: 2026-09-22
- Last reviewed: 2026-09-22
- Reading time: 16 min
- Keywords: is this github contributor worth sourcing, qualify github candidate for pipeline, filter repo contributors for recruiting, spot github bot vs real contributor, when is a github contributor drive-by

## Key takeaways

- GitHub credits a typo fix and a merged feature identically, and squash-merges strip credit from real authors, so grading on contribution-graph density alone both over-ranks drive-bys and discards strong engineers.
- In Rust, 7.0% of developers wrote 80% of the commits, and a 2016 study found nearly half of contributors committed only once, so the modal repo-sourced profile is statistically a casual contributor headed for Discard or Park.
- A Verified badge proves key possession, not personhood: git does not validate author fields by default, so a signed commit still needs a cross-platform match before outreach.
- Bots are catchable deterministically at the account layer through [bot] logins and fixed noreply email patterns; behavioural classifiers reaching 0.77 to 0.80 precision are only for the residue.
- Under GDPR legitimate interest you must intend to contact a sourced candidate and inform them within one month, so a Park verdict with no contact plan is a compliance risk, not a neutral hold.
- A study of 174 GitHub projects found a median 36.14% of contributors gave insufficient contribution, which sets the size of the tail your Discard bar must absorb.

You just pulled a name off a repository's contributor list. Before it enters your pipeline, it needs a verdict, and the verdict needs to be one another sourcer on your team would reach from the same evidence. This is a definition of done for a single repo-sourced profile: three grades, the criteria that separate them, and the checklist to sign off. It is for in-house recruiters, sourcers, talent leaders, and founders sourcing their own engineers.

Every other repo-recruiting guide either scores whether a whole repository is worth mining or walks an entire contributor list down to a shortlist. Neither gives you a pass/fail bar for one mined contributor at a time. That gap is where most sourcing errors live, because a repo hands you hundreds of logins and most of them are noise. This standard sets the bar.

## What Pipeline, Park, and Discard each mean

The three grades are a decision about what happens next, not a rating of the engineer. Pipeline means the profile is a real, reachable, substantive contributor and you may contact them under a lawful basis now. Park means the person is promising but a specific gate is unmet, and you have a plan to close it. Discard means the profile fails a hard bar and gets no storage.

The distinction that matters most is between Park and Discard, because that is where volume goes. In Refolk's terms, a repo-sourced profile is not a candidate until it clears the substance and identity gates; it is a login attached to a commit.

| Grade | What it means | What you do next |
| --- | --- | --- |
| Pipeline | Human, substantive, resolved to one person, lawful basis exists | Contact now, log the one-month transparency deadline |
| Park | Promising but one named gate unmet | Close the gate on a plan, or convert to Discard if it cannot be closed |
| Discard | Fails a hard bar: bot, non-substantive, unresolvable, or no lawful basis | No storage, no outreach |

A grade is only defensible if the gate that produced it is named. "Discard, non-substantive: single typo fix on a fork" survives a second reader. "Discard, felt weak" does not.

> **Rule:** Name the gate, not the feeling
>
> Every verdict records the specific gate that decided it: bot, substance, recency, identity, or lawful basis. A verdict without a named gate is not gradeable and two sourcers will not reproduce it.

## Why most repo contributors are noise for sourcing

Most names on a contributor list are casual or one-time contributors, so your Discard and Park bars carry most of the volume by design. This is not a flaw in the repo; it is the shape of open-source participation, and the standard has to absorb it.

The concentration is stark. In Rust, 7.0% of developers classified as core were responsible for 80% of commits. A 2016 study found nearly half of the contributors in its sample contributed once, at under 2% of total commits. A separate study of 174 projects found a median 36.14% of contributors gave insufficient contribution. So the modal profile you pull off a repo is statistically a drive-by.

**7.0% - Share of Rust developers who wrote 80% of commits**

Core contributors are roughly 11x more commit-productive per capita than their headcount share, a derived ratio from 80 over 7.0.

That has a direct operational consequence: if you Pipeline everyone with a green square, you fill your pipeline with people who touched the repo once. The casual share below is your calibration for how aggressive the substance bar needs to be.

| Project | Casual contributions | Share of total |
| --- | --- | --- |
| Linux | 5,626 | 39.28% |
| Rails | 1,860 | 54.21% |
| Sample-wide (2016 study) | not stated | ~50% contributed once |

Read these as expected base rates. When a repo hands you fifty logins, plan for roughly half to be one-time contributors before you open a single diff.

#### Where a repo's contributor list narrows

| Stage | Figure | Note |
| --- | --- | --- |
| Listed contributors | 100% | everyone the repo attributes a contribution to |
| Human accounts | after bot screen | [bot] logins and automation emails removed |
| Substantive contributors | ~50% or fewer | casual and one-time contributors drop out |
| Resolved to one person | subset | verified badge plus cross-platform match |
| Pipeline | smallest | lawful basis and contact intent confirmed |

*Most listed contributors fall out before the substance gate on volume alone.*

## The signals, and what each one proves

Each screen tests one thing and lies in one predictable way. Knowing the lie is what makes two sourcers agree, because it tells them what to open and read rather than what to assume.

### Bot signals

A bot screen proves the account is automation, and it does so deterministically at the account layer before any machine learning. The GitHub Actions bot commits under email `41898282+github-actions[bot]@users.noreply.github.com`, and GitHub App commits use the format `USERID+APP-NAME[bot]@users.noreply.github.com` to attribute to the app. A `[bot]` suffix in the login and the account Type: Bot flag are the account-level tells. In the 174-project study, most of the 103 bots identified were GitHub Dependabot.

The lie: a human who set a privacy noreply email of the form `username@users.noreply.github.com` looks bot-like. That plain username noreply, with no `[bot]` suffix and no app ID, is a human. Do not reject it.

Behavioural detectors exist for the residue the deterministic screen cannot settle. They read commit messages or PR and issue comments, and their precision tops out modestly.

| Model input | Precision | Dataset |
| --- | --- | --- |
| PR/issue comments (BoDeGHa) | 0.77 | 6,922 contributors |
| Commit messages (BoDeGiC) | 0.80 | 6,922 contributors |

Retraining on commit messages added about 0.03 absolute precision, a derived figure from the two rows. The point for a sourcer: a 0.80-precision classifier still mislabels one in five, so run it only after the free deterministic screen, and never as your first move.

### Substance signals

A substance signal proves the contribution counts as work, not just as attribution. GitHub's own rule is that commits appear on the contribution graph only if the email is account-linked, the repo is standalone rather than a fork, and the commit is on the default or gh-pages branch. Issues, pull requests, and discussions count only in a standalone repo.

The lie is severe and cuts both ways. GitHub credits a typo fix and a sustained feature identically, so contribution count does not encode substance. And when a PR is squash-merged, only the merger and the PR opener receive credit, so a strong engineer who authored real work on a squashed PR shows as inactive. Read the diff and the PR participants, never the graph density alone.

| Project/source | Core share of devs | Share of commits |
| --- | --- | --- |
| Rust | 7.0% | 80% |
| Fastlane (2018) | 4 developers | over 70% |
| 174-project insufficient cohort | median 36.14% | low-value tail |

### Identity signals

An identity signal proves the commit resolves to one reachable person. Git does not validate the author of commits by default, so anyone with write access can push code as any valid repo user. Signature verification is the documented control: a signed commit carries a cryptographic signature whose key is registered in the author's account, producing a Verified badge.

The lie is the one that costs the most in outreach: a signature proves the key was used, not that the account owner is who they claim. It proves the ink came from that pen, not that the pen's holder owned the account. So a Verified badge is necessary but not sufficient. Confirm it alongside a complete profile, an email domain, and a match on a second platform before you treat the person as reachable.

> A verified badge proves the ink came from that pen, not that the pen's holder owned the account.

## Grade one profile, end to end

This is the procedure a single sourcer runs on one profile, in order, in roughly twenty minutes. Each step ends with a stated done-condition so the grade is reproducible. Where research and compliance disagree on ordering, I note it after the block.

#### The seven-step grading pass

1. **Capture the raw profile** - Record the login, the account Type flag, the commit author name and email, the repo, the branch, and the contribution type. Done when you hold every field the checks below consume.
2. **Run the bot screen** - Reject any login ending in [bot], any account flagged Type: Bot, and any commit email matching the automation noreply patterns. Done when the account is confirmed human or explicitly rejected as automation.
3. **Run the substance screen** - Confirm the contribution sits on a standalone repo's default or gh-pages branch and is a merged PR or sustained commits, not a single typo fix or a fork-only commit. Done when the work meets GitHub's counted-contribution rules and clears your substance bar.
4. **Run the recency and volume screen** - Classify the profile against your trailing window and against the one-time, casual, or core role bands. Done when the profile carries a clear active or dormant label.
5. **Resolve identity** - Check for a Verified badge, a complete profile, a usable email domain, and a match on a second platform. Done when the commit resolves to one reachable person or is flagged as spoofable or shared.
6. **Clear the lawful-basis gate** - Confirm a genuine open role, an intent to contact promptly, retention of only role-relevant fields, and a logged one-month transparency deadline. Done when a legitimate-interest record exists for this profile.
7. **Assign the verdict** - Apply Pipeline, Park, or Discard using the grade table. Done when the profile carries a defensible verdict two sourcers would reach identically.

Order disagreement, stated plainly so you can adopt a local rule: research bot-detection tools such as BoDeGHa and BoDeGiC treat identity resolution and bot detection as one behavioural-analysis step, whereas this workflow separates them because the account-layer bot screen is free and the identity resolution is expensive. And some GDPR sources put the lawful-basis check first, before any storage, rather than at step six. If your team stores a profile the moment it is captured, move the lawful-basis gate to step two. The safest reading is that the lawful-basis clock starts at first processing, so the earlier you gate it, the less exposure you carry.

The recency screen has no published constant, so set it as policy. Research gives you role bands rather than a number: one-time contributors have exactly one accepted patch, casual contributors sit under 2% of total commits, and core contributors carry the concentration shown above. Pick a trailing window - commits or merged PRs in the last N months - write it into your standard, and apply it identically to every profile.

I ran this search: `Active maintainers of Python machine-learning libraries with commits in the last six months, excluding bot and automation accounts.` - [see the full result list](https://www.refolk.ai/s/d1tnyh34qk).

*Returns resolved human maintainers with recent activity, with the bot and drive-by tail already filtered, so you grade a shorter, higher-substance list.*

Running the bot and substance screens by hand on a fifty-name list is the friction this standard creates. [Refolk](/) removes it by taking the screen as the query: you ask for the substantive, recent, human contributors and get back the residue this procedure is designed to grade, rather than the raw list.

## How this goes wrong: failure modes and false positives

The most valuable part of a standard is the list of ways it fails, because that is where two sourcers silently diverge. Each row below is a documented trap, the direction of the error, and the check that resolves it.

| Failure mode | Error | Check that resolves it |
| --- | --- | --- |
| Noreply pattern misread | False positive bot | Bot pattern needs [bot] suffix and app ID; plain username noreply is human |
| Verified badge over-trusted | False positive person | Match signing account to a complete profile and a second platform |
| Contribution-count inflation | False positive substance | Open the PR and diff; read LOC and file types |
| Squash blindness | False negative (real author dropped) | Read PR participants, not just the graph |
| Fork mistaken for origin | False positive ownership | Confirm standalone repo and default/gh-pages branch |
| Automation in contributor list | False positive person | Check Type flag and [bot] login |
| Save-for-later storage | Unlawful under GDPR | Require a live role and logged one-month deadline before storage |
| Shared/role identity | False positive reachability | Cross-platform match to one individual before outreach |

Three of these deserve extra weight because they produce the costliest verdicts.

Squash blindness is the one that discards good people. A senior engineer whose feature landed as a squash-merged PR gets no graph credit unless they opened or merged the PR, so their profile reads as dormant. The one-time volunteers' median commit size was 6 lines of code against 15 for paid developers in Rust, which tells you effort concentrates unevenly, but the graph will not show it. Always open the PR and read who participated.

Talent-pool storage is the one that creates legal exposure while looking like caution. Under GDPR the lawful basis for sourcing public data is legitimate interest, which requires that you actually intend to contact the person. Building a database in case you need it later is not lawful. So a Park verdict with no contact plan is not a neutral hold; it is a stored profile with no basis. The regulatory teeth are real: the Irish DPC fined LinkedIn EUR 310 million in October 2024 over invalid consent and unlawful legitimate-interest claims for profiling.

Shared identity is the quiet outreach failure. A commit email on a company or team domain can map to many people, so a message you think is addressed to one engineer may be read by a distribution list or nobody. Resolve to one individual on a second platform before you send.

> **Watch out:** The graph over-ranks drive-bys and hides squashed authors
>
> Grading on contribution-graph density fails in both directions at once. It inflates one-line typo fixes to the level of merged features and it erases the credit of anyone whose PR was squash-merged. Read diffs and PR participants, never the green squares alone.

## The lawful-basis gate, made concrete

The lawful-basis clock, not the grade, is the real deadline for an EU-based person. Legitimate interest permits sourcing public data, but it forces you to intend contact, to inform the person within one month of first processing, and to hold only role-relevant fields. Miss the one-month window and you must delete the data.

Retention has a published ceiling to work within. ICO and EDPS guidance recommends retaining unsuccessful candidate data no longer than 6 to 12 months, and anything longer, such as a standing talent pool, requires explicit consent. Data minimisation under Article 5(1)(c) requires the data you keep be adequate, relevant, and limited to what is necessary for the recruitment decision, so strip anything the hiring decision does not need.

**Legitimate-interest record for one repo-sourced profile**

```
Role this profile is sourced for: <live open req ID>
Source: public GitHub graph, repo and PR link
Fields retained: name, GitHub login, reachable email, role-relevant skills
Fields discarded: everything not needed for the hiring decision
Contact intent: yes / no  (if no -> Discard, do not store)
First processing date: <date>
One-month transparency deadline: <date + 1 month>
Retention review date: <date + 6 to 12 months>
Grade: Pipeline / Park / Discard
Gate that decided it: <bot / substance / recency / identity / lawful basis>
```

*Attach one per Pipeline or Park verdict; delete the record and data if the one-month box cannot be ticked.*

If you cannot name a live role and tick contact intent, the correct grade is Discard, because storage without either is the failure mode above.

## The sign-off checklist

Run this before you record any verdict. It is the definition of done: a profile is graded only when every item is either checked or explicitly marked not applicable with a reason.

#### Before you assign the grade

- [ ] Login does not end in [bot] and the account is not flagged Type: Bot
- [ ] Commit email does not match the github-actions[bot] or USERID+APP-NAME[bot] automation patterns
- [ ] A plain username noreply email was treated as human, not as a bot
- [ ] The contribution is on a standalone repo's default or gh-pages branch, not a fork
- [ ] The actual PR and diff were opened and read for LOC and file types, not just the contribution graph
- [ ] PR participants were checked for squash-merge credit loss before labelling the profile dormant
- [ ] The profile was classified against a written trailing window and a role band
- [ ] Any Verified badge was corroborated with a complete profile and a second-platform match
- [ ] The commit email resolves to one individual, not a shared or role address
- [ ] A live open role exists and contact intent is confirmed, or the grade is Discard
- [ ] The one-month transparency deadline and a 6 to 12 month retention review date are logged
- [ ] The verdict records the specific gate that decided it

> **Tip:** Grade in the order that fails cheapest
>
> Run the free deterministic screens first: bot login, fork check, squash check. Most Discards fall out here in under five minutes, so you spend the expensive identity and lawful-basis work only on profiles that already cleared the cheap bars.

## Keeping the standard current

Adopt this as written, then calibrate two things to your own hiring and re-check them on a schedule, because they are the parts with no published constant. First, the recency window: pick a trailing month count, apply it to every profile, and revisit it if your accept rate drifts. Second, the substance bar: the casual-contribution shares above are base rates from Linux, Rails, and a broad 2016 sample, so if your target repos skew smaller or younger, sample twenty recent Discards and confirm the bar is catching drive-bys without dropping squashed authors.

The mechanics that this standard leans on can change under you. GitHub's counted-contribution rules, its bot noreply formats, and its signature-verification behaviour are all documented by GitHub and shift over time; SSH-based commit signing, for instance, only arrived in Git v2.34 in November 2021, so tooling assumptions age. Re-read GitHub's own contribution and signature-verification reference pages when you notice a screen misfiring, rather than trusting a memorised rule. And treat the GDPR figures - the one-month transparency window and the 6 to 12 month retention ceiling - as guidance to confirm with your own counsel, because enforcement, as the EUR 310 million LinkedIn fine shows, is where the cost actually lands.

What you should not change is the shape: name the gate, read the diff not the graph, corroborate the badge, and gate the lawful basis before you store. Those four hold regardless of the window you pick.

## Frequently asked questions

### When is a GitHub contributor a drive-by I should discard?

Treat a contributor as a drive-by when their footprint on the repo is a single accepted patch, a typo or README fix, or a fork-only commit, with no sustained recent activity. Research calls these one-time and casual contributors, and a 2016 study found nearly half of contributors committed only once at under 2% of total commits. A drive-by is Discard unless a strong identity and a live role turn it into Park.

### How do I spot a GitHub bot versus a real contributor?

Screen the account layer first. Reject any login ending in [bot], any account flagged Type: Bot, and any commit email matching automation noreply patterns such as the github-actions[bot] address or the USERID+APP-NAME[bot] format. These catch Dependabot and Actions deterministically. Behavioural classifiers that read commit messages or PR comments reach only 0.77 to 0.80 precision, so save them for accounts the deterministic screen cannot resolve.

### Does a Verified badge prove the contributor is a real, reachable person?

No. A Verified badge proves a signing key registered to that account was used, not that the account owner is who they claim. Git does not validate author fields by default, so anyone with write access can push as another user. Before outreach, confirm the badge alongside a complete profile, a usable email domain, and a match on a second platform such as a personal site or LinkedIn.

### Can I save a mined GitHub profile in my pipeline for later?

Not for an EU-based person under GDPR. The lawful basis for sourcing public data is legitimate interest, which requires that you actually intend to contact the person; building a database in case you need it later is not lawful. You must inform a sourced candidate within one month of first processing or delete their data. Guidance recommends retaining unsuccessful candidate data no longer than 6 to 12 months without explicit consent.

### Why does the contribution graph mislead me about substance?

GitHub's contribution graph measures attribution, not effort. It credits a one-line typo fix and a sustained feature identically, and when a pull request is squash-merged only the merger and the PR opener receive credit, so real co-authors show as inactive. Grade on the actual diff, the lines of code, and the files touched, and read PR participants rather than trusting graph density.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/repo-sourced-candidate-standard*