A contribution policy for your own open source project should say how to report bugs, how to submit changes, what tests are required, how review works, which sign-off or agreement applies, and where security reports go. Put it in a CONTRIBUTING file in the repository so GitHub shows it to every new contributor.
Definition
A contribution policy (the contributing guidelines) is a file that tells people how to take part in your project. GitHub documents that you can add it to the repository root, the docs folder or the .github folder, and that when someone opens a pull request or issue they see a link to it. If more than one exists, GitHub uses the .github folder first, then the root, then docs.
What to include
The Open Source Guides section on starting a project says the file should explain how to report bugs or file issues and any technical requirements, such as tests, and that early on it can be simple. The GitHub docs suggest steps for creating good issues or pull requests, links to external documentation and a code of conduct, and community expectations.
A fuller checklist for a company-led project:
| Section | What to write |
|---|---|
| Reporting issues | Where, what details to include, what not to post publicly |
| Security reports | A private route and a note that vulnerabilities must not go in public issues |
| Submitting changes | Branch and pull request steps, test expectations, style rules |
| Review | Who reviews, how long it usually takes, what makes a change likely to be accepted |
| Inbound terms | The license of contributions and the sign-off or agreement, see below |
| Behavior | Link to your code of conduct |
| Scope | What kinds of change you are unlikely to accept |
Inbound terms
Decide whether contributors need a DCO sign-off, an agreement, or just the project license. See do we need a CLA and the DCO explained.
The company angle
If a company launches the project, the Open Source Guides suggest an internal discussion before launch about how the company expects to maintain and make decisions, and that you may want to explain publicly anything particular about the company's role. Cover this in a short governance note alongside the contribution file.
State clearly whether employees of other companies are welcome, how a contributor becomes a maintainer, and that paid contributors are judged on technical merit like everyone else. The Guides make that last point directly.
Security-specific lines
- Tell contributors never to include secrets, customer data or proprietary code.
- Require review by someone other than the author for any change touching authentication, dependency updates or build scripts.
- Ask for the project's SECURITY file to be read before reporting. See write a SECURITY.md for your open source repo.
Keep it living
Add answers as questions repeat. The Guides note that writing down frequent answers means fewer people ask them again. Review the file when you change tooling or governance.
Where Safeguard fits
Safeguard's policies, gates and guardrails can run checks on incoming pull requests, and its dependency scanning flags newly added components. A free scan is available at gold.safeguard.sh/scan.
Quick check
Where does CONTRIBUTING.md go?
In the repository root, the docs folder or the .github folder. GitHub checks .github first, then the root, then docs.
Can one file cover all our repositories?
GitHub lets you create default community health files for an organization, so repositories without their own file inherit the default.
Sources
- GitHub Docs: Setting guidelines for repository contributors
- Open Source Guides: Starting an Open Source Project
- Open Source Guides: Leadership and Governance
Last reviewed: 19 October 2026.
