Reading a Repository: The Maintainer-Signal Reference

A repository is evidence, but it is not testimony. This reference is for engineering managers, technical founders, developer-relations leads, and technical sourcers who need to judge what a GitHub profile and its repositories actually prove about the people behind them. It gives you the signals that hold up, the signals that lie, and a procedure for telling the difference before you credit anyone with work they may not have done.

The short version: the green-square graph is a filtered view, stars are the most faked metric on the platform, authorship is forgeable in half a minute, and most real work is private. Each of those facts changes how you read a profile. Below, each signal gets a definition, what it proves, and what it looks like when it misleads you.

What the contribution graph actually counts

The contribution graph is a filtered summary, not a raw git log. A commit appears on a profile's graph only if the commit's email is associated with the account, the commit was made in a standalone repository rather than a fork, and it landed on the repository's default branch or the gh-pages branch.

That means the graph can understate and overstate at the same time. It understates because fork-only activity and commits on non-default branches do not count unless merged, and because, in GitHub's own reporting, 81.5% of contributions happen in private repositories. It overstates because any green square can be churn in a personal project that nobody else uses. A dense streak proves someone pushed commits that satisfied the display rules. It does not prove the work was open source, collaborative, or substantial.

The contributors view inside a repository has its own rules worth knowing. It shows the top 100 contributors only, and it does not count merge commits or empty commits. So a reviewer who scans the contributors tab is already looking at a truncated, filtered list before they draw any conclusion about who did the work.

The signal catalog: what each metric proves and how it lies

Every metric on a profile carries one honest claim and at least one way to be fooled. Here is the catalog. Read the row you need and leave.

Two signals in that table carry most of the weight, and they point in opposite directions. Stars are the most faked and least informative metric. Forks and external merged pull requests are the cheap truth, because they require someone to actually clone or review code. When you are short on time, weigh forks and external PRs; discount stars until you have inspected them.

figure kind: funnel title: From raw stars to a trustworthy popularity read caption: Each stage strips out a layer of manipulation, leaving a smaller but honest signal. stage: Raw star count :: 1,000 :: What a profile shows at first glance stage: Forks per 1,000 stars :: 235 :: Organic baseline (Flask); below ~50 is suspect stage: Stargazers with real history :: variable :: On faked repos, 36-76% have zero followers and zero repos

## Authorship: why the Verified badge is weaker than it looks

Authorship on GitHub is forgeable, and the Verified badge does not close the gap most reviewers assume it does. Git's author fields, user.name and user.email, are free-form text that any client can set to anything. Spoofing a commit this way takes about 30 seconds.

Cryptographic commit signing binds a commit to a key pair that only the signer controls, which is why a Verified badge matters. But there is a nuance that trips up careful reviewers: commit signing verifies the committer, not the author. When you see a verified commit, the author field has nothing to do with the verified status. So a Verified badge confirms who pushed the commit, not necessarily who wrote the code attributed in the author line.

refolk prompt: Find developers with signed, verified commits to TypeScript libraries that have real external contributors. note: Returns people whose work is cryptographically attributable and whose repositories show genuine outside collaboration, not solo projects. slug: pe54n6pdt1

## The procedure: reading one profile end to end

Work the signals in an order that puts verification before credit. Recruiting blogs often tell you to count activity first; primary and academic sources imply the opposite, that authorship verification should precede any credit. The sequence below follows the stricter path.

Each step has a rough owner and a rough clock. Mapping the signal to the role is a sourcer or hiring-manager task, around fifteen minutes. Reading the graph is about ten. Verifying authorship is about ten and belongs to a technical reviewer. Opening repositories is the longest stretch, twenty to forty minutes, and is the only part that actually tells you what someone built. Collaboration, popularity, and maintenance checks are around ten to fifteen minutes each. Outreach is the final ten.

How this goes wrong: the eight failure modes

The failure modes below are where confident reviewers reach wrong verdicts. Each one names the false positive or false negative, and the single check that defuses it.

Overstated signals

Dense green graph, thin substance. A profile full of green squares can be personal or private-repo churn that never reflects open source work. Check by opening the repositories behind the streak and reading what they contain.

Bought stars. High star count beside few forks is the classic pattern. Check the fork-to-star ratio (Flask 235 versus Shardeum 22) and the stargazers, remembering that 36% to 76% of stargazers on manipulated repos have zero followers and zero public repositories.

Bus-factor illusion. A repo that looks like a thriving community may be one person. In 13 of 35 popular repos the bus factor is 1, and Hugo has 916 committers but its lead authored 89% of files. Check ownership concentration before you credit a "community."

Job-search signaling burst. A recent spike of flashy repositories may be timed for the hunt. OSS activity of job-movers is elevated about 16% during the search period, in projects with lower direct use-value. Check whether the burst predates or coincides with their search.

Spoofed and miscounted signals

Spoofed authorship. A profile photo appears automatically when a commit's email matches a GitHub user, so it proves nothing. Check for the Verified badge, and remember it authenticates the committer, not the author.

Fork miscounted as original. Fork-only activity and commits on non-default branches do not count unless merged. Check whether a repo is a fork before attributing authorship to anyone.

Understated signals

Dead repo as live skill. Stars persist after abandonment. One study notes nvie/gitflow has over 26,000 stars but its last commit was 11 years ago, while the author remains active elsewhere. Check the last-commit date and the age of open issues.

Empty graph, strong engineer. Because 81.5% of work is private, senior and employed developers often show little in public. Check for other evidence rather than penalizing the silence.

stat number: 13 of 35 label: Popular repositories with a bus factor of 1 note: Many "community" projects are effectively one person, which is a risk for the project and a depth signal for that maintainer.

## Writing outreach that proves you read the repo

Cite one concrete, verified piece of work in the first two lines, because that is the only part of a message a maintainer cannot receive from a mass campaign. Reference a specific merged pull request, a file they own, or a decision in a commit message, not the star count.

Subject: your work on {project}

Hi {name},

I read your {project} repo properly, not just the star count. The way you handled {specific thing in a merged PR or a file you clearly own} stood out, especially {one concrete detail from the code or commit message}.

I verified it was your commit, so I am reaching out directly rather than through a list.

{one sentence on the role and why this specific work maps to it}

Worth a short conversation?

Notice what the template forces: if you cannot name a real merged PR or an owned file, you have not completed the read, and the message will sound generic. That constraint is the point. The secondary claim that 83% of technical hiring managers find GitHub profiles more dependable than resumes comes from a recruiting blog and is not verified against a primary survey, so do not lean on it; lean on the specific artifact instead.

Sourcing geography: the pool is lopsided by country

The same query returns very different depth depending on where you run it, so size the pool before you set expectations. In Refolk's index of professional profiles, the United States pool of OSS-skilled engineers in the maintainer title band is 10.6 times the size of Germany's.

The mechanism is market size and employer concentration. A read that works in a deep US pool, where you can afford to filter hard on verified authorship and external PRs, will exhaust a thinner pool quickly. In a smaller market, loosen the popularity filters before you loosen the authorship ones, because authorship is where the fakes live and depth is where the scarcity bites. Refolk makes it easy to run the same plain-English query against each market and compare what comes back, rather than rebuilding the filter by hand for every country.

Before you call the read done

Run this checklist before you record a verdict on a profile. It maps directly to the failure modes above.

Keeping the read current

The signals in this reference shift when the platform and the incentives shift, so re-check the mechanisms rather than memorising values. Fake-star prevalence was near zero before 2022 and reached 16.66% of repos with 50 or more stars by mid-2024; that number will keep moving as GitHub removes campaigns and sellers adapt. The contribution-graph rules are set by GitHub and can change, so when a graph reads strangely, return to the official profile-contributions reference before you conclude anything.

The durable truths are structural: forks cost more to fake than stars, signatures beat badges because signing binds a key you control, file ownership reveals depth that contributor counts hide, and most real work is private. Build your read on those, and you will be judging what a repository actually proves rather than what it advertises.