| Status | (Proposed / Accepted / Implemented / Obsolete) |
|---|---|
| Author(s) | My Name ([email protected]), AN Other ([email protected]) |
| Sponsor | A N Expert ([email protected]) |
| Updated | YYYY-MM-DD |
| Obsoletes | RFC it replaces, else remove this header |
What are we doing and why? What problem will this solve? What are the goals and non-goals? This is your executive summary; keep it short, elaborate below.
Why this is a valuable problem to solve? What background information is needed to show how this design addresses the problem?
Which users are affected by the problem? Why is it a problem? What data supports this? What related work exists?
How will users (or other contributors) benefit from this work? What would be the headline in the release notes or blog post?
This is the meat of the document, where you explain your proposal. If you have multiple alternatives, be sure to use sub-sections for better separation of the idea, and list pros/cons to each approach. If there are alternatives that you have eliminated, you should also list those here, and explain why you believe your chosen approach is superior.
Factors to consider include:
- UX and usability
- How will this change impact users, and how will that be managed?
- Performance implications
- Dependencies
- Maintenance
- Backwards compatibility
This section is optional. Elaborate on details if they’re important to understanding the design, but would make it hard to read the proposal section above.
Seed this with open questions you require feedback on from the RFC process.