How to verify a candidate's open-source contributions

Look at the project, not the profile

A contributions calendar is a summary the platform draws about a person. The project's own history is the record. Open the repository the claim names and read its commit log, its merged pull requests, its issue and review threads, its release notes and its maintainers or code-owners file. Everything a claim of this kind asserts is written down in one of those places, with a date attached.

The calendar is the weaker artifact for a second reason: it can include work you cannot inspect. GitHub shows activity from public repositories by default and lets a person include private-repository activity as well, and GitLab's contributions calendar likewise records actions in private projects. A dense green square grid may be entirely real and entirely unexaminable.

Match the identity before you count anything

Commits are attributed by the email address in the commit, not by the person. GitHub's own documentation notes that commits appear on a contributions calendar only when the authoring email is connected to the account, so work done under an old employer address, a personal alias or a changed username can be genuinely absent from a profile while sitting in the repository under a different name.

So search the project rather than the person: grep the log for the candidate's names, handles and known email domains, and check the pull request authors and reviewer lists. Two names that look unrelated can be the same contributor, and one handle can be a shared bot account.

Merged, opened, and commented are different claims

The log distinguishes things a résumé usually does not. A merged pull request changed the software. An opened pull request that was closed unmerged did not, whatever work went into it. A review comment, a bug report, a documentation fix and a translation are all real contributions with different weight, and all of them are visible.

"Core contributor" and "maintainer" have a checkable meaning in most projects: who holds the commit bit, who appears in MAINTAINERS or CODEOWNERS, who merges other people's work, who signs releases. Someone with forty merged commits and no merge rights is a frequent contributor, which is worth saying accurately.

Separate the person's claim from the project's

The second half of the example — a library used by two thousand companies — is a fact about the library, not about the candidate, and package registries and dependency graphs will speak to it independently. Check it if it matters, but do not let it transfer.

And when a candidate's best work was in a private repository, an internal fork or under an employer's account, the project record shows nothing, and unverified is the correct and final answer.