Open Source Project PR Template

Open Source Project PR Template

Open source projects receive contributions from developers of varying experience levels. A well-designed PR template guides contributors through the submission process and sets clear expectations for what constitutes a complete, reviewable PR.

Template Structure

## Description
<!-- Please describe your changes in detail. -->
<!-- If this is a new feature, explain the use case. -->
<!-- If this is a bug fix, link to the issue. -->

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change (please describe the impact below)
- [ ] Documentation update
- [ ] Performance improvement
- [ ] Code refactoring
- [ ] Test improvement

## Checklist
- [ ] I have read the [CONTRIBUTING.md](CONTRIBUTING.md) guidelines
- [ ] My code follows the project's coding style
- [ ] I have added tests covering my changes
- [ ] All new and existing tests pass
- [ ] I have updated the documentation accordingly
- [ ] My commits are signed off (DCO)

## Breaking Changes
<!-- If this is a breaking change, describe what breaks and the migration path. -->

## Testing
<!-- How can maintainers test your changes? -->
<!-- Include specific commands to run if applicable. -->

## Additional Context
<!-- Any additional information that might help reviewers. -->
<!-- Links to related PRs, discussions, or external resources. -->

CONTRIBUTING.md Reference

The checklist includes a link to CONTRIBUTING.md, which is standard in open source projects. This file typically covers coding standards, commit message format, and the PR review process.

DCO Sign-Off

Many open source projects (especially Linux Foundation projects) require a Developer Certificate of Origin (DCO) sign-off on each commit. The git commit -s flag adds a Signed-off-by line. The checklist reminder helps contributors avoid CI failures.

Community-Friendly Language

Notice the template uses welcoming language and provides clear instructions in HTML comments. For open source projects, the PR template is often a contributor's first interaction with your project's process, so it should be approachable.

Breaking Changes Section

A dedicated Breaking Changes section is important for open source libraries where downstream users need migration guidance. This information often ends up in the changelog or release notes.