Reading CONTRIBUTING.md Files: Open Source Contribution English
5 exercises — understanding PR requirements, DCO/CLA clauses, code style rules, review process steps, and issue templates.
0 / 5 completed
1 / 5
A CONTRIBUTING.md states: 'All pull requests must reference an open issue. PRs without a linked issue will be closed without review.' What does this rule require contributors to do?
PR requirements in CONTRIBUTING.md are mandatory steps. 'Must reference' and 'will be closed' are strong modal verbs. This means: first find or open an issue, then submit the PR that addresses it — not the other way around.
2 / 5
A project's CONTRIBUTING.md includes: 'By submitting a pull request, you agree to license your contribution under the project's MIT licence and certify that you have the right to submit the work (see the Developer Certificate of Origin).' What is a DCO?
Developer Certificate of Origin (DCO) is not a copyright assignment — it is a declaration that you have the right to submit the code (you wrote it, or have permission). This differs from a CLA (Contributor Licence Agreement), which may involve copyright transfer.
3 / 5
A CONTRIBUTING.md states: 'We follow the Airbnb JavaScript style guide. Run npm run lint before opening a PR. CI will block merging if lint fails.' What does this mean for a contributor?
Code style enforcement: 'CI will block merging' means the check is automated and mandatory. Running npm run lint locally before pushing catches errors early and avoids a failed CI run. 'We follow' sets the standard; 'CI will block' enforces it.
4 / 5
A CONTRIBUTING.md describes the review process: 'Once your PR passes CI, a maintainer will review within 7 business days. You may be asked to make changes. After approval from two maintainers, the PR will be squash-merged.' How many approvals are needed before merging?
Review process language: 'After approval from two maintainers' clearly states the requirement. CI passing is a prerequisite for review, not a substitute for it. 'Squash-merge' means all commits are collapsed into one — a detail about merge strategy, not approval count.
5 / 5
A GitHub issue template includes required fields: Describe the bug, Steps to reproduce, Expected behaviour, Actual behaviour, Environment (OS, version). A contributor opens an issue with only the 'Describe the bug' field filled. What is likely to happen?
Issue templates are structured to help maintainers reproduce and understand bugs quickly. Missing fields — especially 'Steps to reproduce' and 'Environment' — make an issue very hard to act on. Most projects will ask contributors to complete the template before the issue is addressed.