Chapter 2 of 8 · 4 checks · 3 min

Read the rules before you code

Every project writes down how it wants contributions made. Find those rules and set up the project locally before changing anything.

Show

Read the CONTRIBUTING file from top to bottomMust
Why it matters and how to check
The contributing guidelines are where maintainers tell you how to report bugs, propose features, format code, name branches, write commit messages and run tests. GitHub looks for the file in the .github folder, the repository root or the docs folder, and links to it when you open an issue or pull request, on the repository's contribute page and in a Contributing tab.
Skipping it is the most common reason first pull requests are closed or sent back. Some projects want an issue before any pull request, some require a changelog entry, some ask for a specific commit message format.
Check it: write a three line note of the rules that apply to your change, such as branch naming, test command and commit format, before you start.
Do
Look in .github, the root and docs for the file
Follow its rules even where they differ from your habits
Avoid
Opening a pull request before reading the contribution rules
Find out whether the project needs a DCO sign-off or a CLAMust
Why it matters and how to check
Some projects ask you to confirm you have the right to submit your code. The Developer Certificate of Origin (DCO), version 1.1, is a short statement you agree to by adding a Signed-off-by line to each commit, usually with git commit -s. It certifies that you wrote the code or otherwise have the right to submit it under the project's licence, and acknowledges that the contribution and your sign-off are public and kept indefinitely.
Other projects use a Contributor Licence Agreement (CLA) that you sign once, often through a bot that comments on your first pull request. If your employer owns the code you write, check your employment contract before signing anything on their behalf.
Check it: the CONTRIBUTING file tells you which one applies, and every commit in your branch has the required sign-off, or you have signed the CLA.
Do
Use git commit -s when the project requires the DCO
Read a CLA before signing it
Avoid
Signing a CLA for code your employer owns without checking your contract
Build the project and run its tests before you change anythingMust
Why it matters and how to check
Set up the project exactly as the README or CONTRIBUTING file says and run the full test suite on the unchanged code. If tests already fail on a clean checkout, you need to know that before you make changes, or you will waste time thinking you broke them.
This step also proves your environment matches the maintainers'. Use the language and tool versions the project specifies, such as a .nvmrc, rust-toolchain or pyproject.toml setting.
Check it: on a clean branch, the build succeeds and the test command passes, or you have written down which tests fail before your change.
Do
Use the exact versions the project pins
Note any tests that fail before your change
Avoid
Changing code before you can run the tests
Learn who maintains the project and how decisions are madeNice to have
Why it matters and how to check
Larger projects often have a GOVERNANCE.md, a MAINTAINERS or CODEOWNERS file, or a page explaining who reviews which part of the code. Smaller projects may have a single maintainer.
Knowing this helps you set expectations. A one-person project may take weeks to respond. A foundation project may need a design proposal before a large change. A CODEOWNERS file tells you who will be asked to review your pull request.
Check it: you can name the person or team most likely to review your change, and where larger proposals are discussed.
Do
Read CODEOWNERS to see who reviews the files you will touch
Avoid
Messaging maintainers privately to ask for a quicker review