How to write a good feature request for an open source project
RFC format, problem vs solution framing, use case specificity, avoiding solution anchoring, community feedback, proposal discussion etiquette, when feature requests get rejected
Sell the Problem, Not the Feature
Maintainers reject feature requests that arrive as solution demands. They accept requests that clearly describe an unmet need and let the team decide the best way to address it.
The Problem-First Format
## Feature Request
### Problem
Users who export large datasets (10k+ rows) to CSV cannot track
progress -- the UI appears frozen during the 30-60s export.
Support tickets for this are common.
### Proposed Solution
A progress indicator or async export with notification would
communicate that work is happening. Open to either approach.
### Alternatives Considered
- Chunked streaming (complex backend change)
- Simple spinner with estimated time (simpler, solves perception)
### Use Case
BI analysts exporting weekly reports in our org.What Gets Rejected
Feature requests get declined when: the problem is niche and does not affect most users, the solution conflicts with the project roadmap or architecture, or the team already tried and rejected the same approach. Check closed issues before filing -- your idea may have history.
After filing, give the community time to respond. Do not bump within 48 hours. If discussion stalls after two weeks, a polite bump is appropriate.