Hotfix Pull Request Template

Hotfix PR Template

Hotfixes are time-sensitive changes that need expedited review and deployment. This template is intentionally concise, focusing on what reviewers absolutely need to know — the problem, the fix, and the deployment urgency.

Template Structure

## Hotfix Description
<!-- What is broken in production? -->

## Severity
- [ ] Critical (service down, data loss)
- [ ] High (major feature broken, workaround exists)
- [ ] Medium (degraded performance, non-critical bug)

## Fix Description
<!-- What does this change? Keep it brief. -->

## Type of Change
- [x] Bug fix (non-breaking change which fixes an issue)

## Impact Assessment
<!-- What systems/services are affected? Any side effects? -->

## Checklist
- [ ] I have performed a self-review
- [ ] My changes generate no new warnings
- [ ] Existing tests pass locally
- [ ] This fix needs to be cherry-picked to the release branch
- [ ] I have notified the on-call team

## Testing
<!-- How did you verify this fixes the issue? -->

## Related Issues
<!-- Fixes #(issue number) -->

Why a Separate Hotfix Template?

Hotfix PRs have different requirements than regular PRs:

1. Speed over thoroughness — the template is shorter to minimize time-to-merge
2. Severity classification — helps prioritize among multiple hotfixes
3. Impact assessment — critical for production changes
4. Cherry-pick reminder — hotfixes often need to be applied to multiple branches
5. On-call notification — ensures the ops team knows about the change

Using Multiple Templates

If your repository supports multiple PR templates, name this file hotfix.md inside the templates directory. Contributors can select it when creating a PR via GitHub's template query parameter or GitLab's template dropdown.

Post-Merge Follow-Up

After the hotfix is merged and deployed, the team should schedule a follow-up PR with proper tests, documentation, and any refactoring that was deferred for the sake of speed.