Reading a Repository: What Each Signal Proves About a Contributor

You are looking at a GitHub profile and a repository, and you have to decide what the activity in front of you actually proves about the person. This reference is for engineering managers, technical founders, developer-relations leads, and technical sourcers who need a defensible read rather than a vibe. It works as a lookup table: jump to the one signal on your screen, learn what it proves about the individual, how it lies, and the single check that settles it.

The mistake that runs through most sourcing advice is collapsing two different questions into one. "Check the README and the green squares" tells you something about the project. It does not tell you what the person did. This guide keeps those two questions apart on every row.

Project signals versus person signals

Most repository-level counts describe the project, not any individual in it. Stars, forks, and watchers measure how much attention a codebase drew; they never appear on a person's contribution graph and cannot be attributed to one contributor. The signals that describe a person are the ones that required a gatekeeper: a merged pull request, a substantive code review, a resolved issue.

The contribution graph itself is narrower than it looks. It counts qualifying activity only. Commits to a fork do not count unless a pull request is merged into the original repository. Stars, watches, and follows never count. Regular issue and pull request comments do not count; only formal code review comments do. Wiki edits and gists do not count. So a busy-looking public presence can sit almost entirely outside what the graph records.

Intensity is relative, not absolute. Color intensity on the graph is normalized per developer: GitHub calculates four thresholds from your own distribution, so one person's dark green square can mean five commits and another's can mean fifty. You cannot compare two people's graphs by eye and conclude anything.

The reason the bottom layer is the strongest is that it required someone else to say yes. A merged pull request in a repository the person does not own survived a maintainer's review. Stars and green squares require no gatekeeper at all. One vendor claims developers with merged pull requests in three or more repositories perform 40% better in reviews; treat that as a vendor claim, not a peer-reviewed finding, but the direction is sound: accepted work is expensive to fake.

The signal-by-signal lookup table

Here is the core reference. Each row names a signal, states what it proves about the individual, names the failure mode that makes it lie, and gives the one check that separates the two.

Two rows deserve emphasis because they are the ones most often read backwards.

A high contributors-tab rank is read as ownership. It is not. It is a commit count, and squash merging can inflate it for the wrong person (see the attribution section below). A large star count is read as quality. It is not even a person signal; it is project attention, and it is the single most manipulated number on the platform.

Author versus committer, and why the tab misleads

Every Git commit stores two identities. The author is who wrote the change; the committer is who applied it. Usually they are the same person, but several ordinary operations pull them apart, and each one can misattribute credit.

The main source of misattribution is the squash or rebase merge. When a maintainer squash-merges a pull request, commits previously attributed to the pull request author can be reattributed to the person who clicked merge. That means the contributors tab, which counts commits, can credit the wrong human. GitHub has mitigated this since December 2019 by automatically crediting every commit author in the pull request as a co-author on the squash commit, but older history and misconfigured repositories still carry the old behavior. Web-UI commits are a smaller trap: when a change is made in the GitHub web interface, the author is the person but the committer is recorded as GitHub itself.

The fix is fast and local. git log --format=fuller shows both the Author and AuthorDate and the Commit and CommitDate. git log --author=<name> filters to what a person actually wrote, and --committer filters by who integrated it, which is useful when you want to see how much of a person's footprint is merging others' work versus writing their own. For raw stored attribution on a single commit, git cat-file commit <hash> prints the author and committer lines exactly as Git saved them. For line-level ownership, git blame or a tool like whodunit identifies who authored the lines in a file or tree.

git log --format=fuller --author="Jane Doe" -n 20
git log --author="jane@example.com" --oneline | wc -l
git shortlog -sn --no-merges
git cat-file commit <hash>
</template>

## Stars are the most manipulated number on the platform

Stars measure project popularity, they are cheap to buy, and they are not attributable to any individual. Treat a raw star count as marketing until you have checked how it was earned.

The scale is documented, not anecdotal. A peer-reviewed study (ICSE 2026, from CMU, NCSU, and Socket) built a detector called StarScout, analyzed 20TB of GitHub events, 6.7 billion events and 326 million stars, and identified 6.0 million fake stars across 18,617 repositories, attributed to roughly 301,000 accounts. The surge is recent: by July 2024, 16.66% of all repositories with 50 or more stars were involved in fake star campaigns, up from near-zero before 2022. Fake stars sell for between $0.03 and $0.85 each.

| Metric | Value | Source |
|---|---|---|
| Fake stars detected 2019 to 2024 | 6.0M | cmustrudel.github.io |
| Repositories with campaigns | 18,617 | cmustrudel.github.io |
| Repos with 50+ stars flagged, Jul 2024 | 16.66% | awesomeagents.ai |
| Flagged repositories later deleted | 90.42% | awesomeagents.ai |

Detection was validated by deletion: flagged repositories and accounts had anomalously high deletion ratios, up to 90%, roughly 16 times higher than random, and 90.42% of flagged repositories plus 57.07% of flagged accounts were gone by January 2025. That is a strong signal that the flags caught real fraud, not noise.

Two mechanisms should shape how you read a count. First, the effect is short-lived: fake stars promote a repository only in the short term, under two months, then become a liability. So a high count on an old repository is weaker evidence than a rising count on a new one, because buyers front-load them. Second, GitHub Trending resists manipulation: only 78 fake-star repositories, 0.42% of the flagged set, ever reached Trending. If a repo made Trending on its own merits, that is a far better filter than raw stars.

callout kind: rule title: Never convert stars into a claim about a person Stars are a project signal and a gameable one. They do not belong in any sentence that begins with the candidate's name. If you catch yourself writing "they built a 10k-star project," stop and check who authored the code.

## Bus factor: do they carry the project or ride it?

The bus factor tells you whether a project depends on one person, and it reframes what a candidate's involvement is worth. CHAOSS formalized and renamed the metric as the Contributor Absence Factor: the smallest number of contributors responsible for 50% of total contributions. You compute it by sorting contributors by contribution in decreasing order and adding them up until you reach the 50% threshold.

A bus factor of 1 means one person carries the project. If your candidate is that person, their involvement is deep and load-bearing. If the project has a bus factor of 1 and your candidate is not that person, then the "team project" on their resume is really someone else's project that they touched.

A stricter, file-based measure catches the same risk at the code level. A Truck Factor smell exists if the departure of two or fewer contributors would abandon more than 40% of files, where a file is abandoned when more than 90% of its lines are owned by engineers who left. This is worth running when a candidate claims ownership of a large codebase: it shows whether their fingerprints are actually on the files.

The fastest read is git shortlog -sn, which ranks contributors by commit count, or a dedicated bus-factor tool. Compare the candidate's share against the 50% threshold and you have your answer in about five minutes.

Public open-source talent is genuinely scarce, which is why verifying these signals beats dismissing them. In Refolk's index of professional profiles, only 514 US-based people titled Software Engineer list an Open Source skill, concentrated at a handful of firms including Meta, Google, Apple, Jane Street, and Signal Messenger. The same query in Germany returns 58. When the pool is this small, a wrong read is expensive in both directions.

The scarcity gets sharper by role. In the same US market, engineers with an open-source footprint outnumber developer-relations people with one by roughly 51 to 1.

Finding the ten, or the right subset of the 514, is exactly the search that plain-English querying is built for. Rather than paging through contributor tabs by hand, you can name the evidence you want and get the people who match.

That is the friction Refolk removes: the search itself is phrased around merged pull requests and named projects, so you skip the popularity signals and land on people whose contributions already cleared a maintainer's review.

The procedure: from repo to defensible read

This is the end-to-end pass, roughly 40 minutes for one candidate against one repository. Each step ends with a definition of done so you know when to move on.

Steps 3 and 4 conflict on purpose, and that conflict is the point. The contributors tab counts commits, but squash and rebase can credit the merger instead of the author. When the tab and git log disagree, the git log wins, because it reads what Git actually stored.

Accepted work survived a gatekeeper; stars and green squares survived nobody.

How this goes wrong: failure modes and false positives

This is the most valuable section, because every signal above has a failure mode that produces a confident wrong answer. Here are the eight that recur, each with the false positive it creates and the check that kills it.

• Star count read as quality. False positive: a 10,000-star repository that is a short-lived phishing shell. Check for a lockstep spike and low-follower stargazers; the promotion effect lasts under two months.
• Contributors-tab placement read as ownership. False positive: someone ranked high because they merged others' work under squash. Check with git log --format=fuller to separate author from committer.
• Green squares read as skill or discipline. False positive: a fully backdated graph, since GIT_AUTHOR_DATE lets anyone place a green square on any date. Check by opening the actual commits and diffs, not the calendar.
• Commit count read as impact. False positive: many one-character commits, which look identical to ten-file commits on the graph. Check with git blame and line ownership.
• Merged PR read without reading it. False positive: a merged typo or docs-only change presented as a feature. Check the diff and the review thread.
• Fork read as original work. False positive: a tutorial fork with no meaningful changes. Check against upstream; tutorial copies signal a lack of initiative.
• Sparse graph read as disqualifying. False positive: a strong engineer working in private monorepos. Check by asking for private-contribution counts or non-GitHub work.
• Bus factor ignored. False positive: a "team project" actually carried by one person. Check git shortlog -sn against the 50% threshold.

Two red flags come up often enough to name directly. Repositories obviously copied from tutorials without meaningful changes are a significant flag, signalling a lack of initiative; compare against upstream to see whether anything real was added. Heavy AI-generated code the author does not understand shows up as uniform style with an absence of tests. Neither is disqualifying on its own, but both should downgrade a pinned repo from evidence to decoration.

One counterweight: documentation is a cheap proxy that survives for a good reason. Developers who write clear documentation tend to write clear code, and employers use docs as a professionalism proxy. It does not prove code skill, but it correlates with the communication that makes code skill usable on a team.

Verify before you call it done

Run this before you write your read. Every item maps to a check above, and each one is either done or not; there is no partial credit for a signal you meant to verify.

Keeping this current

Signals age, and the ways they are gamed change faster than the platform documents them. Two things are worth re-checking on your own cadence rather than trusting the numbers in this guide as fixed.

First, the fake-star baseline moves. The 16.66% figure is a July 2024 measurement, and the market for bought stars responds to detection. Re-run your own eye check on any repo that matters: a spike in a short window, stargazers with no other activity, and a young repository are the durable tells, whatever the current prevalence is. The mechanism, that fake stars promote for under two months then become a liability, will outlast any single statistic.

Second, GitHub's own attribution behavior evolves. Co-author crediting on squash commits arrived in December 2019, and platform defaults keep shifting. The safe habit is to stop trusting the rendered contributors tab entirely and let local Git be your source of truth. git log --format=fuller, git shortlog -sn, and git blame read what was actually stored, so they stay correct even when the web UI changes what it shows. Build your read on those, and the read survives the next platform update.