Contributing to Open Source
Contribution is a social process with formal gates. This domain tests whether you can land a change in someone else's project without wasting maintainer time or creating legal exposure.
Before you write code
Read CONTRIBUTING, the code of conduct, the issue and pull-request templates, and the CI configuration. For anything non-trivial, open or comment on an issue first and agree on the approach; a large surprise pull request is the most common reason changes are rejected. Check how the project handles contribution rights: a DCO requires a Signed-off-by trailer asserting you have the right to submit under the project license, while a CLA assigns or licenses rights to a foundation or company. They are different instruments, and satisfying one does not satisfy the other.
The mechanics
- Fork, branch from the current default branch, keep commits small and focused, and follow the project's commit-message convention.
- Add tests for new behavior and update docs and the changelog in the same pull request.
- Respect the compatibility policy: under SemVer, no breaking change in a MINOR or PATCH release without a deprecation cycle.
- Respond to review with additional commits, then squash if the project asks for it.
Worked example
A CI job fails with a DCO check error. The commit is authored by a developer but carries no Signed-off-by trailer, or the trailer name and email do not match the author identity. The fix is git commit --amend -s with a corrected identity followed by a force-push; for several commits use git rebase --signoff. Signing a CLA in the web UI does not repair a DCO failure.
Traps
- Pasting code from a blog or a differently licensed project into a patch.
- Reformatting an entire file so the real change is unreviewable.
- Arguing about style instead of running the project's linter.
- Force-pushing over review comments without explanation.