Open-Source Contribution
Contributing to open source is a social protocol as much as a technical one. Writing the code is the easy part; reading the project's norms and respecting a maintainer's limited, often unpaid time is what actually gets a PR merged.
The flow itself is mechanical — fork, branch, PR — but the things around it decide the outcome: agreeing on scope before you write, satisfying the project's legal sign-off requirement, and handling review feedback like a guest rather than a customer.
Before You Code
Read CONTRIBUTING.md first, then search existing issues to see whether your change is already planned, rejected, or in flight. For anything non-trivial, open an issue and agree on the approach before writing code.
This protects your own time as much as the maintainer's. A large PR that conflicts with a direction you could not have known about gets rejected no matter how good the code is.
The Contribution Flow
The standard path is to fork the repository, create a branch, and open a small, focused PR against the correct base branch, linked to the issue it addresses. Keeping the PR narrow is what makes it reviewable by someone juggling dozens of others.
CLA vs DCO
Many projects require a legal sign-off before they can accept your code. A Contributor License Agreement is signed once per project, often enforced by a bot that blocks the PR until you sign. A Developer Certificate of Origin is a per-commit attestation, satisfied by git commit -s, which adds a Signed-off-by line.
The distinction matters in practice: a CLA is heavier but a one-time event, while a DCO is lighter but required on every commit, so forgetting -s blocks the PR until you fix the whole branch.
Maintainer Etiquette
Respond to review promptly, do not force-push over a reviewer's in-progress comments without a heads-up, and do not ping daily for a merge. Maintainers owe you nothing; pressure tends to get PRs closed, not merged. Accepting a "no" gracefully is part of the protocol.
Good First Contributions
Look for good first issue and help wanted labels to find work the maintainers have pre-approved as a reasonable entry point. Docs and tests are low-risk first contributions: they teach you a project's norms and tooling without the stakes of changing core behavior.
CLA — a Contributor License Agreement, sometimes assigning or licensing copyright, signed once per project and usually enforced by a bot that blocks the PR until signed. It is common in corporate-backed projects and is the heavier of the two.
DCO — a Developer Certificate of Origin, a lightweight per-commit attestation that you have the right to submit the code, satisfied with git commit -s adding a Signed-off-by line. It is common in Linux-kernel-style projects; lighter than a CLA, but required on every commit rather than once.
- Opening a large PR with no prior issue, so the maintainer rejects it because the approach conflicts with a direction you could not have known.
- Ignoring
CONTRIBUTING.mdand the PR template, so your PR misses required tests or changelog entries and bounces back before review. - Forgetting
git commit -son a DCO project, so the DCO bot blocks the PR until every commit is signed off, forcing a history rewrite. - Force-pushing over a reviewer's in-progress comments without a heads-up, losing their context and looking careless.
- Pinging the maintainer daily for a merge, since unpaid maintainers owe you nothing and pressure gets PRs closed, not merged.
- Open or comment on an issue to agree on scope before writing a large change.
- Read
CONTRIBUTING.mdand fill out the PR template completely before requesting review. - Sign commits with
git commit -son DCO projects, or complete the CLA bot check on CLA projects. - Keep the PR small and respond to review feedback within a day or two without force-pushing silently.
- Start with
good first issueorhelp wantedwork to learn a project's norms before tackling core changes.
Knowledge Check
How is a DCO requirement satisfied on a contribution?
- By signing off each commit with
git commit -s, which adds aSigned-off-byline - By signing a legal agreement once via a bot before the first PR
- By transferring copyright of the change to the project as part of submitting the pull request
- By adding a license header to every changed file so each one carries the project's attribution
How does a CLA differ from a DCO in how often you satisfy it?
- A CLA is signed once per project; a DCO is attested per commit
- A CLA is attested per commit; a DCO is the legal agreement signed once per project
- Both are signed once per organization, covering every project under that org at once
- Both must be re-signed on every individual file changed within a given commit
Why open an issue before writing a large change?
- To agree on the approach so the PR is not rejected for conflicting with a direction you could not have known
- Because GitHub requires an existing issue number before it will let you open any pull request
- Because the issue automatically generates a starting branch and scaffolds the initial code for you to fill in
- There is no reason — opening an issue first only slows the contribution down with extra ceremony and paperwork
Why are docs and tests good first contributions to a project?
- They are low-risk and teach you the project's norms and tooling without the stakes of changing core behavior
- They are the only kind of change that skips the review process entirely and merges straight to the base branch
- They never require a CLA or DCO sign-off because they touch only docs and tests, not executable code
- They are automatically merged without a maintainer reviewing them once the continuous integration suite passes
You got correct