Open Source Contribution Workflow & Review Etiquette

Q: What is a DCO sign-off?

A line ("Signed-off-by") added to commits with git commit -s, certifying under the Developer Certificate of Origin that you have the right to submit the contribution under the project's license.

Contribution Workflows and Review Etiquette

Open source maintainers are mostly volunteers or small teams with limited time, and every pull request costs them review effort. Contributions that follow the project's conventions, solve a real problem the project wants solved, and come with tests and a clear explanation are a gift. Contributions that ignore guidelines, arrive unannounced as large rewrites, or leave reviewers to figure out what changed and why are a burden — and often go unmerged.

Contributing well is a craft that combines technical work with communication: finding the right problem, agreeing on the approach before investing heavily, preparing changes that are easy to review, and responding to feedback respectfully. These habits also make you a better collaborator at work.

TL;DR

Choose healthy projects and suitable issues (labels such as "good first issue" or "help wanted").
Read CONTRIBUTING.md, the code of conduct, and recent merged pull requests before starting.
Discuss larger changes first in an issue; for bugs, provide a minimal reproduction.
Use the fork, branch, pull request workflow; keep changes small and focused, with tests and docs.
Follow the project's sign-off (DCO) or CLA requirements and commit conventions.
Write a clear PR description, respond to review graciously and promptly, follow up politely, and accept "no" gracefully.

Quick Example

A typical contribution flow with the GitHub CLI and a DCO sign-off:

A pull request description that makes review easy:

Core Concepts

Finding Suitable Work

Look for projects that are active (recent releases, issues answered, pull requests merged), welcoming (contribution guide, code of conduct, labeled starter issues), and relevant to you — tools you use daily make the best first contributions because you understand the problems. Documentation fixes, bug reproductions, tests, and triage are valuable contributions too. See Contributing to Open Source.

Before Writing Code

Read CONTRIBUTING.md, the code of conduct, and governance docs.
Check whether someone is already working on the issue; comment before starting.
For anything non-trivial, propose the approach in the issue and wait for maintainer agreement — many projects decline unsolicited large changes, new dependencies, or features outside their scope.
For bugs, produce a minimal reproducible example; it often reveals the cause and is useful even if someone else fixes it.

Preparing the Change

Sign-Offs and Agreements

Projects may require a Developer Certificate of Origin sign-off (git commit -s, certifying you have the right to submit the code) or a Contributor License Agreement signed once. Some also ask contributors to disclose or limit AI-generated code; follow each project's policy, and never submit code you do not understand or cannot license.

Responding to Review

Respond to every comment — with a change, a question, or a reasoned disagreement.
Assume good intent; reviewers are protecting the project's long-term maintainability.
Push follow-up commits or force-push according to the project's preference, and summarize what changed.
Wait patiently; a polite follow-up after a week or two is fine, repeated pings are not.
If the maintainers decide not to merge, thank them, ask whether a different approach would work, and move on — or maintain the change in your fork if you need it.

See Code Review and Community Management.

Best Practices

Start Small and Learn the Project

Begin with documentation, tests, or small fixes to learn conventions before larger work.

Agree Before You Build

Discuss non-trivial changes in an issue and get a maintainer's go-ahead.

Make Review Effortless

Small, focused pull requests with tests, passing checks, and a clear description get merged faster.

Be Kind and Patient

Maintainers have limited time; courtesy and patience build long-term relationships.

Common Mistakes

Surprise Rewrites

Ignoring the Contribution Guide

Defensive Responses to Review

FAQ

How do I find my first open source contribution?

Pick a project you use, read its contribution guide, and look for issues labeled "good first issue" or "help wanted" — or start by improving documentation or reproducing reported bugs.

Should I open an issue before a pull request?

For anything beyond a small, obvious fix, yes. Discussing the problem and approach first avoids work the maintainers cannot accept.

What is a DCO sign-off?

A line ("Signed-off-by") added to commits with git commit -s, certifying under the Developer Certificate of Origin that you have the right to submit the contribution under the project's license.

How long should I wait for a review?

It varies by project. After a week or two, a polite comment asking whether anything is needed from you is reasonable; avoid repeated pings.

Can I use AI tools to write contributions?

Check the project's policy; some require disclosure or restrict AI-generated code. Always understand, test, and take responsibility for what you submit.