How do you verify an open source contribution claim?

How do you verify an open source contribution claim?

Open the project on GitHub and look for the candidate's merged pull requests. A merged pull request is a change the project's maintainers reviewed and accepted, and every one is public, dated, and attached to a username. The whole check takes about ninety seconds.

This works because of how open source operates. The work happens in public because reputation is part of the reward, so the record was built to be seen. A resume line like "contributed to Kubernetes" resolves into a specific list of accepted changes, each with a date, a size, and the conversation that got it in. Few claims on any resume come with a paper trail this complete.

The sections below cover what the trail contains: what counts as a contribution in the first place, where the merged pull requests live, and what their size, reception, and pattern say about the person who made them.

What counts as a contribution?

A contribution is any accepted addition to a public project: code, documentation, translations, bug reports, or reviews of other people's work. The phrase "contributed to open source" covers all of it, from a one-line typo fix in a README to years of maintaining a repository that other companies depend on.

That range is why the phrase alone carries so little information. Two candidates can both write it truthfully while describing work that differs by a factor of a thousand. The specific contributions turn the phrase into a fact, and the specifics sit one click away.

Small contributions still say something real. A typo fix means the person read the documentation closely, learned the whole submission process, and followed it through to acceptance. That is a genuine unit of engagement with how public software gets built. It sits at a different scale from sustained code contribution, and the record lets you see exactly which scale you are looking at.

Where do merged pull requests appear?

Every public repository has a Pull requests tab, and it holds the full history of proposed changes: open, closed, and merged. The tab has a search box, and typing is:merged author:username filters the list down to the changes one person got accepted. That single search is the verification.

The results are also reachable from the other direction. A person's profile page and contribution graph link back to the repositories they have worked in, which is useful when the resume names the ecosystem without naming the project.

What does the size of a pull request tell you?

Every pull request page shows its size: how many files changed, how many lines were added, and how many were removed. Size tells you the scope of the change, and scope reads differently than most numbers on a resume.

Small is normal and often preferred. Experienced contributors split work into small pull requests on purpose, because a reviewer can check a focused change carefully and a sprawling one only loosely. Code review works best on changes a reviewer can hold in their head. A history of many small, steadily merged pull requests is the shape sustained contribution usually takes.

A one-line change can also be deep work. Some of the hardest fixes in software end as a single changed line, found after days of tracing a bug through a large codebase. The line count records the destination and says nothing about the journey. Size pairs with the review conversation: a tiny change that drew long, careful discussion from maintainers was a consequential change, whatever the line count says.

What does the review conversation show?

Every pull request carries its full discussion: maintainer comments, requested changes, the contributor's replies, and each revision until the work was approved. The conversation is the part of the page that shows how the person works with other people.

Reading it takes a minute and answers questions no line count can. Did a maintainer request changes, and did the contributor revise gracefully? Did they explain their reasoning when questioned? Did the exchange stay professional across several rounds? These threads are unrehearsed collaboration, recorded in public, often with strangers holding higher standards than any employer would.

The approval itself names names. Whoever approved and merged the change appears on the page, so acceptance traces to a specific person applying a specific project's bar. On well-known projects that bar is high, and clearing it is third-party evidence about code quality that no self-description can match. The profile-reading anchor places this signal among the others a profile offers.

What is the difference between an issue and a pull request?

An issue is a written report or request with no code attached: a bug description, a feature suggestion, a question about behavior. A pull request contains actual code changes submitted for review. Both live on the repository, in adjacent tabs, and both count as participation.

The distinction matters when reading a claim, because "contributed to" sometimes means filed issues rather than submitted code. A well-written bug report is a real contribution: a clear one includes steps to reproduce the problem, the expected behavior, and the actual behavior, and maintainers treasure reporters who write them. It demonstrates careful thinking and clear technical writing. It is a different kind of evidence from a merged pull request, and the tabs make it easy to see which kind a candidate's activity is.

Many strong contributors do both, and the pairing has a common shape: an issue describing a problem, then a pull request from the same person fixing it. Finding a bug, reporting it clearly, and repairing it is a complete piece of engineering, visible end to end.

How do you tell a maintainer from a one-time contributor?

Look at which side of the review a person's name appears on. A contributor's name sits on the submitting side of their own pull requests. A maintainer's name appears on the reviewing side of other people's: commenting, requesting changes, approving, and merging. That reversal is the visible mark of the role.

A maintainer holds ongoing responsibility for the project. They set direction, review incoming work, decide what gets merged, and answer to every user when something breaks. Projects usually name them in the repository's documentation, in a file like MAINTAINERS or on the contributors page, so the role can be confirmed in one more click.

The two patterns also differ in shape over time. A one-time contributor shows one or two merged pull requests on a project, which is a real and common way to engage. A maintainer shows years of activity on the same repository: their own changes, reviews of everyone else's, and releases carrying their name. Maintaining a project that other companies rely on is unpaid infrastructure stewardship, and the gift economy explains why people take it on. When that experience appears on a resume, the repository holds the entire record, and ninety seconds of reading confirms every word of it.