The Contribution Weight Read: Core, Substantive, or Cosmetic

A candidate lists a well-known open-source project on their resume and says they "contributed." Before you advance them, you need to know whether that was core engineering work or cosmetic edits, and you need a call you can defend to a hiring panel. This guide gives engineering managers, technical founders, developer-relations leads, and technical sourcers a repeatable rubric that places one person's work inside one codebase into a weight tier - Core, Substantive, Peripheral, or Cosmetic - using git blame ownership share, merge outcomes, and file-centrality tests.

Most advice on this job stops at "look at substance, not stars." That is true and useless. It hands two reviewers the same profile and lets them grade it differently. What follows supplies the missing scoring dimensions with numeric thresholds and observable pull-request states, so the same evidence produces the same tier no matter who reads it.

Why the claim needs a rubric, not a gut check

A self-declared "core contributor" title is common, unpoliced, and cheap to type. The tier you assign has to rest on merge state and blame share, never on the title.

In Refolk's index of professional profiles, 273 US professionals self-title as "core contributor," "open source contributor," or "maintainer." The same self-titles resolve to 38 people in the United Kingdom and 37 in Germany. The US top-titles list for this group also mixes in Founder, CEO, and CTO labels, which tells you the phrase is a positioning choice as much as a description of work.

The rubric exists because the title carries no evidentiary weight on its own. Two reviewers who both "look at substance" will still disagree unless they share thresholds. This framework fixes the thresholds: a 5% ownership cut, a merge-state hierarchy, and a complexity screen, each with a stated failure mode. It is deliberately narrow. It measures the depth and weight of one person's work inside one codebase. It does not tell you whether the profile is a real human, and it does not judge how the project is governed. Those are separate reads.

The four weight tiers and what each one requires

The tiers are Core, Substantive, Peripheral, and Cosmetic, ordered by the depth and acceptance of the work. Each tier is defined by an ownership share, a merge outcome, and a complexity signal, not by a headline claim.

• Core. Major author by blame, clearly above the 5% cut on files that sit at the center of the codebase, with merged work and at least one medium or hard issue resolved. This person shaped the module.
• Substantive. Merged, non-trivial changes that clear the complexity screen but sit below major ownership on central files, or major ownership on peripheral files. Real engineering, not module ownership.
• Peripheral. Merged changes that are small, config-level, or confined to edges of the tree, or activity that is genuine but below the complexity screen.
• Cosmetic. Documentation-only edits, typo fixes, whitespace and lint passes, or work that was closed unmerged or labeled invalid or spam. Effort, but not weight.

The boundary between Core and everything below leans on one empirical number. Bird et al., studying Windows Vista and 7 at Microsoft, defined a contributor as a major author of a component at 5% or more of the commits to that component, and a minor author below 5%. The cut is not sacred: the authors chose 5% because experiments with thresholds from 2% to 10% produced similar results. A 10% minor cutoff is defensible inside that robustness band, but 5% is the canonical figure, so state which you used.

Ownership share: what git blame proves and when it lies

Git blame answers "who last touched this line," not "who wrote this feature." For each line of a file, blame shows the author and commit hash that modified that line most recently. That last-touch behavior is exactly why blame both measures ownership and misleads about it.

Compute per-author line counts with a single command:

git blame --line-porcelain path/to/file | sed -n 's/^author //p' | sort | uniq -c | sort -rn

Divide each author's line count by the file's total lines to get a per-file ownership percentage, then apply the 5% cut. But blame is last-touch, so a whitespace pass or a lint reformat reassigns thousands of lines to whoever ran the tool. Someone can show 40% ownership of a file that is pure cosmetic churn. Rerun with -w -M -C and inspect the underlying diffs before you believe any high number.

The deeper trap is that ownership has two definitions and they disagree. Ownership can be computed commit-based, as Bird did, or line-based, as blame does. Research across large Apache projects found the two approaches identify only 0% to 40% of the same developers per file, and at the median the proportion of common developers is 0% for ActiveMQ, Camel, Groovy, Hive, and JRuby. A candidate can be a major author by commit count and a minor author by line count, or the reverse. If you run only one method, your tier is an accident of which command you happened to type.

There is one more reason ownership share matters beyond depth. Bird found that the number of minor contributors to a Windows binary strongly correlates with defects, even controlling for size, churn, and complexity. Many shallow touches is not neutral. A file dominated by minor authors is a risk signal, so a candidate whose whole footprint is minor touches across many files tells you something about both weight and quality.

Merge outcomes: the states that prove and disprove weight

A merged pull request to the default branch is the strongest public signal you have, because a maintainer with authority looked at the change and accepted it. Closed-unmerged proves activity but not acceptance, and the labels invalid and spam actively disprove substance.

The observable states form a hierarchy. Read them off the PR directly rather than inferring from the contribution graph.

The invalid and spam labels come from a specific enforcement pattern: during Hacktoberfest, maintainers were told to label spammy pull requests as invalid or spam and close them, and PRs with those labels would not count. Treat these labels as disproving weight. But do not collapse them. There is a real difference between the two: invalid flags low effort, while spam flags a bad actor. If you read invalid as spam you turn a depth question into a character judgment the evidence does not support. Read the maintainer's comment before you decide which one applies.

The "Ineligible Repository" state is a false alarm. A PR accepted during a campaign becomes marked ineligible if the repository later removes its participation label. That says nothing about the code. Do not penalize it.

The procedure: from claim to defensible tier

Work the steps in order, but compute both ownership methods before you tier, because the literature disagrees on whether commit-based or line-based is primary. The whole pass runs roughly ninety minutes for one candidate against one repository.

Separating governance from authorship

CODEOWNERS is a governance artifact, not an authorship record. It does not assign reviewers so much as dictate who is automatically requested to review a pull request based on the files changed, and being listed requires write permission on the repository, not authorship. So a name on a path proves review authority, not that the person wrote the lines. Score it separately, and expect it to disagree with blame. A frequent false positive is reading a CODEOWNERS listing as engineering depth when the person's actual blame share on that path is small.

The complexity screen

Once identity and merge state are fixed, size the depth. A published recruiter benchmark is a reasonable baseline: many hiring managers use 6 to 10 issues of varying complexity, including at least one labeled medium or hard, as a screen for moving a candidate forward. The medium-or-hard requirement is the part that matters. Ten typo fixes clear the count and fail the screen.

Running this read by hand is fine for one finalist. When you are sourcing at the top of the funnel and want to start from people whose merged, non-trivial work is already visible, Refolk lets you ask for that population in plain English instead of scraping profiles one at a time.

Squash merges and AI agents: the attribution destroyers

Squash merges are the single biggest destroyer of blame accuracy, and AI agents now sit inside the blame you are reading. Both create the same failure: every line of a change gets attributed to one author who may not have written most of it.

With a normal merge commit, git blame still attributes each change to the right author. With squash and merge, it is all attributed to one author, who may have contributed a single commit with a very small change. In a squash-heavy repository, a maintainer's blame dominance overstates their solo authorship while erasing everyone else who touched the PR. GitHub added co-author attribution on squash merges through a changelog dated December 19, 2019, which helps only when the trailers are present.

AI agents make this worse. When you squash-and-merge a Copilot-created PR, GitHub sets the commit author to Copilot, which can mess up git blame and contribution history. The corrective signal rides on a trailer: Copilot's commits are co-authored by the developer who assigned the issue or requested the change, which lets you attribute the proposed changes to a human. So "who wrote it" becomes a trailer-parsing problem, not a blame-counting one.

Who wrote it is now a trailer-parsing problem, not a blame-counting one.

How this read goes wrong

The framework fails in predictable ways, and every one of them is a false positive that inflates or erases a tier. Know the check for each before you present a verdict.

• Blame inflation via reformatting. A whitespace or lint pass reassigns thousands of lines to the reformatter, producing 40% ownership that is cosmetic churn. Check: rerun with -w -M -C and inspect the underlying diffs.
• Squash single-author illusion. One PR's lines all show one name, creating a false solo Core tier or erasing a real contributor. Check: open the PR and read the pre-squash commits and Co-authored-by trailers.
• AI-agent authorship. Blame or the author field shows Copilot, so you credit a human for agent output or a machine for human work. Check: read the Co-authored-by line naming the assigning developer.
• CODEOWNERS mistaken for authorship. A name on a path reads as "owns this module." Check: compare the CODEOWNERS entry to the blame share; they often disagree.
• Commit-count versus line-count mismatch. Someone is major by commits and minor by lines given the 0% to 40% overlap, so the tier depends on which method you ran. Check: compute both.
• Identity gaps. Commits made with a generic or local email never link, understating a real contributor. Check: match on name plus repo, not just the resolved GitHub handle.
• Green-square theater. A dense contribution graph with thin substance. Check: sample actual merged diffs, not the activity calendar.
• Label ambiguity. Treating invalid, which flags low effort, as spam, which flags a bad actor, over-penalizes. Check: read the maintainer comments; the two labels differ.

The reference tables

Two tables anchor the numeric side of the read: the ownership thresholds from the literature, and the self-title base rates that tell you why verification is mandatory.

The self-title counts are raw current titles from Refolk's index, and the multiple is derived against Germany's 37. The point is not the ranking. It is the volume: hundreds of people carry the label, and the label alone tells you nothing about weight.

Before you call it done

Run the checklist before you write the panel paragraph. A tier that skips any item is not defensible, because someone on the panel will ask exactly the question the skipped step answers.

Keeping the read current

The mechanics of attribution change, so treat two things as moving targets rather than fixed facts. First, agent authorship: GitHub's handling of Copilot-authored pull requests keeps shifting, and author searches now surface PRs opened by the cloud agent on a user's behalf. Re-check how your target repositories set the author field on agent PRs before you trust any blame that names an agent. Second, campaign labels and eligibility states appear and disappear with each season, so confirm what a label means in the specific repo rather than assuming last year's semantics.

The durable core does not move. The 5% major/minor cut, the 0% to 40% overlap between methods, the merge-state hierarchy, and the squash-and-trailer reconstruction will outlast any single platform feature. Anchor the tier to those, name your method, and the call will survive a hiring panel and a re-review months later.