# Open Source Contributions as Evidence — Resume & GitHub Portfolio

Source: https://www.skillbyai.com/en/resume-portfolio/q-oss

> Working in someone else's codebase.

## 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.

```text
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.

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

- [ ] Call yourself a core maintainer
- [x] 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

*Answer:* Describe exactly what the pull request did and link to it. Accurate descriptions build trust.