Feature Request Pull Request Template

Feature Request PR Template

New feature PRs benefit from additional context about the motivation, design choices, and rollout plan. This template guides contributors to provide that information upfront, reducing back-and-forth during review.

Template Structure

## Feature Description
<!-- What does this feature do? Who is it for? -->

## Motivation
<!-- Why is this feature needed? Link to the product spec or RFC if available. -->

## Design Decisions
<!-- What alternatives were considered? Why was this approach chosen? -->

## Type of Change
- [x] New feature (non-breaking change which adds functionality)

## Implementation Details
<!-- High-level overview of the implementation approach. -->

## Checklist
- [ ] My code follows the project's style guidelines
- [ ] I have performed a self-review of my code
- [ ] I have commented my code in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [ ] My changes generate no new warnings
- [ ] I have added tests that prove my feature works
- [ ] New and existing unit tests pass locally
- [ ] Feature flag is configured (if applicable)
- [ ] I have updated the API documentation

## Screenshots
| Before | After |
|--------|-------|
|        |       |

## Testing
<!-- How was this feature tested? Include edge cases. -->

## Rollout Plan
<!-- Is this behind a feature flag? Gradual rollout? -->

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

Design Decisions Section

The Design Decisions section is one of the most valuable parts of a feature PR template. It documents the "why" behind architectural choices, which is invaluable for future maintainers who might wonder why a particular approach was taken.

Rollout Plan

For teams practicing progressive delivery, the Rollout Plan section captures how the feature will be released — behind a feature flag, to a percentage of users, or as a full release. This information is critical for release managers and on-call engineers.

API Documentation

The checklist includes an API documentation reminder because new features often introduce or modify API endpoints, and documentation updates are frequently forgotten.