Open Source Contributions as Evidence

Real collaboration in public

Open source contributions show skills that solo projects cannot: reading an unfamiliar codebase, following a project's conventions, communicating in issues and pull requests, and responding to code review. Start small: documentation fixes, reproducing bugs, improving tests, or issues labelled for newcomers (labels such as "good first issue" are common). Read the project's CONTRIBUTING guide and code of conduct first, and ask before starting large changes. On your resume, describe contributions honestly: link the merged pull requests and say what they did. A typo fix is fine to make, but do not present it as a major feature; a few substantive contributions are worth more than many trivial ones.

Describing contributions honestly

Fictional project names.

Open Source
- tinyhttp-example (HTTP client library): added retry with exponential backoff
  for idempotent requests, with tests; merged after two review rounds.
  github.com/example-org/tinyhttp-example/pull/000
- docs-site-example: fixed broken code samples in the getting-started guide.

Avoid:
- "Core contributor to tinyhttp" (after one merged pull request)
- Listing pull requests that were closed without merging as contributions

Workflow: read CONTRIBUTING.md -> comment on the issue -> fork -> branch ->
          small focused change + tests -> pull request -> respond to review

Communication counts too

Clear, polite issue reports with reproduction steps are real contributions and show skills teams value. You can link to them as evidence.

Quick check: You had one small pull request merged into a library. How should you describe it?

• Call yourself a core maintainer
• Describe exactly what the pull request did and link to it
• List the whole library as your own project
• Leave it out because it is too small