Contributing Guides and Documentation Language (English)
Practice writing and reading open-source contributing guides: getting started instructions, project conventions, and contribution workflows.
0 / 8 completed
1 / 8
What should a 'Getting Started' section of a contributing guide include first?
A contributor's first obstacle is usually environment setup. Clear prerequisites and exact commands prevent 'it works on my machine' problems. Including verification steps (e.g., 'run npm test — all tests should pass') confirms the setup is correct.
2 / 8
What is 'conventional commits' and why do contributing guides mention it?
Conventional commits (feat: add login, fix: resolve null pointer) standardize commit messages. Tools like semantic-release use these prefixes to automatically determine version bumps and generate changelogs.
3 / 8
What is the purpose of the 'Development Workflow' section in a contributing guide?
The development workflow section guides contributors through the expected process: fork → branch → develop → test → PR → review → merge. This prevents PRs that do not follow the project's conventions.
4 / 8
Why is it important to document 'run the test suite' instructions in a contributing guide?
Contributors should run tests locally before submitting a PR. Without instructions, they may not know the command, the environment required, or what a passing run looks like — leading to PRs that fail CI immediately.
5 / 8
What does 'squash and merge' mean in a PR contributing workflow?
Squash and merge produces one clean commit per PR on main, regardless of how many 'work in progress' commits were in the PR. It keeps the main branch history readable and is common in projects using conventional commits.
6 / 8
What should be included in the 'Project Structure' documentation for contributors?
Project structure docs orient new contributors quickly. Knowing that 'src/ contains source code, tests/ contains tests, packages/ is the monorepo root' saves hours of exploration.
7 / 8
What is a 'draft PR' and when would a contributing guide mention it?
Draft PRs are a signal: 'I am working on this, CI is running, but do not review yet.' Contributing guides often encourage draft PRs for large changes to enable early discussion without blocking others.
8 / 8
How should a contributing guide explain the code style requirements?
Code style requirements should name the tool, give the exact commands, and state what happens in CI. This removes ambiguity and prevents contributors from submitting code that immediately fails CI for formatting reasons.