The Open-Source Claim Check: Confirmed, Partial, Unverifiable, or Contradicted

This is the check to run when a finalist's resume says something like "core maintainer of X, 40+ merged PRs, contributing since 2021" and the onsite is a few days away. It's for engineering managers, technical founders, developer-relations leads and technical sourcers who need to know which parts are true, which are inflated, and which can't be seen in public records. I carry that one line through every search and git command, including the three wrong turns that make honest candidates look like liars. It ends with a four-grade verdict sheet where every grade has its evidence link next to it.

What does an open-source resume line actually claim?

A line like "core maintainer of X, 40+ merged PRs, contributing since 2021" is four separate claims: authorship, merge count, tenure and role. Each one is proven by a different record and gets its own grade.

Most bad verdicts start by grading the line as a whole. Someone glances at a busy contribution graph, decides the candidate "checks out," and never notices that the maintainer claim was the inflated part. Split the line before you open anything.

The four grades

Every row gets exactly one grade, with a link next to it:

• Confirmed. A record the candidate can't edit (a PR merge record, a push record, the commit that added their handle) directly shows the claim.
• Partial. Some of the claim is true, or the only support is evidence the candidate can set themselves, such as graph squares or author dates.
• Unverifiable. The public record can't reach the claim. Examples: private repos, an expired event window, an email that can't be attributed.
• Contradicted. A record directly conflicts with the claim. Missing evidence never earns this grade, and neither does an odd-looking pattern.

The worked case is one finalist's line, anonymised. The project is called X, and the candidate's own counts appear only relative to the claim ("short of 40") rather than as raw numbers. That keeps the candidate unidentifiable and the method general. The measured figures in this guide come from published single-repo measurements and from Refolk's index, and I attribute each one where it appears.

Which public records can prove each claim, and how strong is each?

Records the platform writes when something happens, such as PR merges and push events, are strong. Records that carry dates the author chose, such as git history and the profile graph, are weak on timing. The graph is the weakest of all, because it is both author-dated and cached.

Author date vs committer date on a GitHub profile

Every Git commit has two timestamps. The author date is when the change was originally written. The committer date is when the commit object was last created or rewritten. Practitioners have documented in community troubleshooting threads that the contribution graph uses the author date, while repository history views can show the committer date. GitHub's own troubleshooting page doesn't say this outright, so treat it as practitioner-documented, not official.

Both dates can be set to anything. Git accepts custom values through the GIT_AUTHOR_DATE and GIT_COMMITTER_DATE environment variables. Ordinary workflow also moves them. Amend and rebase usually reset the committer date to the current time and keep the original author date. So a gap between the two dates is normal in any project that rebases.

The push records, and their windows

The only public records of when a commit reached GitHub are push events, and there are two places to find them.

The Events API returns at most 300 events and only from the past 30 days, which makes it useless for a "since 2021" claim. GH Archive goes back to 2011. GitHub's changelog of 2025-08-08 announced that push events would drop commit summaries and counts. As checked against a public issue tracker, a PushEvent payload now holds only before, head, push_id, ref and repository_id. The ClickHouse GH Archive dataset notes that since the middle of 2025 the feed reports almost only PushEvent events. Payload shapes can change. To re-check the current shape, pull one recent PushEvent from the Events API and look at which fields are present.

What survived the change is enough for timing. The head SHA still places a commit on the earliest date it reached GitHub, provided that commit was the tip of a push.

The procedure: verifying open-source contributions on a resume

Seven steps, in order. Each ends with a written artifact, so a hiring manager, a sourcer and an engineer can split the work and still produce one sheet. The time estimates are rough guesses, not measurements. Nobody has documented a standard order for this job. I run the volume checks first because they produce the emails and SHAs the role check needs, but if the hiring decision depends only on the maintainer claim, step 6 can go first.

These are the commands, in the order the steps use them. Replace the capitalised placeholders.

# Step 2: merged PRs by the candidate (works for any merge strategy)
gh search prs is:merged author:LOGIN repo:OWNER/REPO

# Step 3: get the real author email from any known commit
# open https://github.com/OWNER/REPO/commit/SHA.patch and read the From: line
git clone https://github.com/OWNER/REPO && cd REPO
git log --author="EMAIL" --pretty=fuller
git show --stat SHA          # empty diff = no work in this commit
git cat-file -t SHA          # confirms the SHA still exists in the repo

# Step 4: squash-merge credit
git log -i --grep="Co-authored-by:.*EMAIL" --oneline
git log -i --grep="Co-authored-by:.*EMAIL" --oneline | wc -l

# Step 6: who was added to code ownership, and when
git log --follow -p CODEOWNERS
git log --follow -p MAINTAINERS
gh api repos/OWNER/REPO/codeowners/errors

Worked case, part one: merge count and authorship

In the worked case, the PR search came back short of 40. The commit log showed more work than the PR count did. Authorship came out Confirmed and merge count came out Partial. Two wrong turns along the way nearly produced a Contradicted grade.

Merge count: search PR records, not commits

The first query was gh search prs is:merged author:LOGIN repo:OWNER/REPO. The is:merged qualifier matches only merged pull requests. Because it searches PR records rather than commits, it gives the same answer whether the project squashes, rebases or merges. The search returned fewer than 40 merged PRs, and the earliest merge was in 2021.

The tempting move here is to stop and write "inflated." I didn't. "40+ merged PRs" could be a loose way of describing commits, PRs merged under a second account, or PRs the candidate co-authored on someone else's branch. Counting PRs and commits separately is the whole point of steps 2 and 3. One squash merge produces one commit however much work went into it, and one PR can carry dozens of commits.

Authorship: the first wrong turn

The candidate's GitHub profile showed very little activity in X. The first instinct was that most of the claimed work wasn't theirs. That would have been wrong.

GitHub counts a commit on a profile only when all three of these hold:

• The commit email is linked to the account.
• The commit is in a standalone repository, not a fork.
• The commit landed on the default branch or gh-pages.

Generic addresses such as jane@computer.local can't be linked to an account at all. The docs also list "commit made less than 24 hours ago" as a cause of missing contributions.

Opening the .patch view of one merged PR's commit showed the candidate had authored most of their work under a former employer's email, which wasn't linked to their personal account. Running git log --author with both emails changed the picture. The commits were there in the upstream history, with real diffs, under the candidate's name.

Matching the second email to the same person is where most of the friction sits. When the work email is the only lead, Refolk returns the person's GitHub handle and professional profile together, which tells you whether the commit name and the resume belong to the same human.

Squash-merge Co-authored-by credit: the second wrong turn

Next came the grep for Co-authored-by: trailers carrying the candidate's email. A Co-authored-by trailer is a line at the end of a commit message that credits additional authors. On a squash merge, GitHub adds one for each PR commit whose author differs from the person who clicks merge. The grep found trailer credit on some commits, but many squash commits that matched the candidate's PRs had no trailer at all.

That looks damning until you see the published measurements.

Survival rates work out to 0%, 100%, 100%, 0% and 0%. Authors who merge their own PRs never get a trailer. Passing --body to gh pr merge replaces GitHub's default message, and the trailer goes with it. Every squash commit without a trailer in X turned out to be either a PR the candidate merged themselves, or one merged with a custom body. Both are consistent with honest authorship. I haven't established how rebase-merge records the author, so if X uses rebase merging, rely on the commit author field and the PR record and not on trailers. These rows come from two repositories, and no ecosystem-wide rate has been published.

A missing trailer tells you who clicked merge, not who did the work.

Grades after part one

• Authorship: Confirmed. Linked commits with real diffs under both emails, each tied to a merged PR record.
• Merge count: Partial. Merged PRs authored by the candidate came in short of 40. Authored commits plus trailer-credited commits came close to the claimed volume, but "merged PRs" literally describes PR records, and those fell short. The evidence link is the saved search.

If you want a baseline for what an ordinary multi-year PR record looks like in a large project, look at a cohort of real contributors before you judge one finalist against your own expectations.

Worked case, part two: tenure and maintainer role

Tenure came out Confirmed from the PR merge record. The graph alone would only have supported Partial. The role came out Partial: the handle was in CODEOWNERS, but nothing showed a governance role that would make "core" true.

Tenure: the third wrong turn

The profile graph showed squares in 2021, and the tempting grade was Confirmed. That's the mistake behind most "fake GitHub contribution graph" stories in hiring, in both directions. The graph uses author dates, which can be set to anything. Its squares are also cached at push time, so commits removed by a force-push can stay on the graph after they no longer exist. Graph evidence caps a tenure claim at Partial.

Three checks did the actual work:

1. Earliest merged PR. The step 2 search already had a 2021 merge date. GitHub records that when the PR is merged. The author's clock doesn't set it.
2. Empty commits. git show --stat on the earliest commits showed real diffs, which rules out the --allow-empty backdating pattern.
3. Earliest push. The Events API's 30-day window was no help for 2021. In GH Archive, a lookup of the head SHAs from the earliest pushes found one of the candidate's early commits as a push tip.

A gap between author and committer dates showed up on several later commits. The project rebases, and rebasing moves the committer date by design. A gap is only suspicious when the author date comes before any push to the repository. Here the author dates were close to their pushes.

Tenure: Confirmed. The evidence link is the earliest merged PR, with the GH Archive event as a second source. "Contributing since 2021" claims a start date, not continuous activity, and I graded only what was claimed.

Verifying a candidate is a maintainer of an open-source project

The role claim is the one worth the most care, and the numbers show why. In Refolk's index of professional profiles, 121 US profiles have a headline matching "open source maintainer" and 694 match "open source contributor." The maintainer claim is the rarer one, and it's the one a hiring manager will lean on in the debrief.

The ratios are derived. Visible top employers among the US maintainer headlines include AboutCode.org, CNCF, Docker and Microsoft. In Germany the top regions are Karlsruhe (4) and Berlin (3). The title and employer breakdowns come from a 25-profile sample, so read them as texture, not distribution.

For X, git log --follow -p CODEOWNERS found the commit that added the candidate's handle. It came after their first merged PRs, which is the normal order for someone who earned write access. The two facts that matter about CODEOWNERS:

• What it proves. GitHub requires code owners to have write permission on the repository, and teams listed there must be visible. An entry proves write access at the time of the adding commit.
• What it does not prove. Governance. Write access is how most people end up there, and it doesn't amount to a "core maintainer" role. gh api repos/OWNER/REPO/codeowners/errors lists lines GitHub couldn't resolve, so an entry that looks valid may be inert.

The next check was behavioural. Does the handle review recent PRs? It did, on a steady share of PRs touching the paths they owned. MAINTAINERS and GOVERNANCE files are project conventions the platform doesn't enforce, and X's governance file listed a smaller core group that didn't include the candidate.

To see who the real maintainer set is, it helps to know who else claims the role. A Refolk search for maintainers of that project brings back the other people who say they maintain it, which you can then check against the governance file.

Two things I haven't verified, so check them locally if they matter to the claim:

• Release and registry records. I haven't established how release tags are attributed or how npm and PyPI publisher records work. If the candidate says they "cut releases," open the release page and the registry's own maintainer listing for the package, and treat what you find as supporting evidence only.
• Org membership. I haven't established how visible org membership is. A missing org badge on a profile proves nothing.

Role: Partial. The link goes to the commit that added them to CODEOWNERS, with the governance file noted next to it. They are a code owner who actively reviews. "Core maintainer" isn't supported.

How this check goes wrong: failure modes and false positives

Almost every way this check fails points the same direction: an honest candidate gets graded as a liar because of how GitHub records and displays work. The opposite failure, a fabricated record that passes, is rarer and mostly comes from trusting the graph.

Three more need room to explain:

1. Treating CODEOWNERS presence as maintainership. It only needs write permission. Check whether the handle actually reviewed recent PRs, and read the governance file if there is one.
2. Trusting graph squares after a force-push. The graph caches commit events when they're first pushed, so squares can outlive the commits they stand for. Run git cat-file -t SHA on each in-scope SHA to confirm it still resolves in the repository.
3. Grading on pattern anomalies alone. Bursty activity, odd hours and a sudden run of squares are all patterns, and none of them is proof. Anomalies justify Unverifiable, never Contradicted.

The last point needs context because it's where hiring teams most want a tool. There is no published, vetted detector for commit inflation, and no published count of accounts that fake their contribution graph. The nearest measurement covers stars. The StarScout study found 6.0 million fake stars and 18,617 repositories with fake star campaigns, involving about 301,000 accounts. It caught 81% of repositories and 76% of accounts in one confirmed malware campaign. Its authors still say its evidence alone is insufficient for disciplinary action. If a peer-reviewed detector with a known miss rate isn't enough for that, a hiring team's eyeball read of a graph isn't enough to call a candidate a liar.

Squares can be wrong in the other direction too. GitHub's docs say the graph rebuilds automatically when a new email is added. One user still reported historical commits missing more than two weeks after verifying the email. If a candidate says "I just linked that email," believe the upstream log, not the profile.

Writing the verdict and what to do before the onsite

The deliverable is one sheet: four rows, one grade each, one evidence link each, and a note on what to ask in the interview. Anything graded Partial or Unverifiable becomes an interview question, not a rejection.

For the worked case the sheet read: authorship Confirmed, merge count Partial, tenure Confirmed, role Partial. That's an honest engineer who rounded up twice. Both rounding-ups go to the interviewer as direct questions: "Walk me through how you count the 40 PRs" and "What does core mean in X's governance, and are you in that group?" A candidate who answers both cleanly has told you more than the graph ever could.

Candidate:
Resume line (verbatim):
Repo checked (OWNER/REPO, default branch):
Emails attributed (source: .patch view of SHA):

Claim        | Grade | Evidence link | Note
Authorship   |       |               |
Merge count  |       |               | PRs merged: __  Commits authored: __  Trailer-credited: __
Tenure       |       |               | Earliest merge: __  Earliest push: __ (or unavailable)
Role         |       |               | Added to CODEOWNERS in SHA __ on __; reviews recent PRs: yes/no

Questions for the onsite:
1.
2.
Checked by / date:

On confirming with the project: I know of no published procedure for asking a maintainer to confirm a candidate's contribution that also protects the candidate's confidentiality. Naming a finalist to a third party can expose a job search they haven't told their employer about. Do the record checks, then ask the candidate. If they want a maintainer to vouch for them, let them make the introduction.

The mechanisms behind this guide change from time to time. Before relying on the push-timing step, pull one fresh PushEvent and confirm which fields it carries. Before relying on the email rules, re-read GitHub's "Troubleshooting missing contributions" page. There is an open community feature request to show push dates on the graph. If GitHub ships it, steps 3 and 5 get much shorter.