dex/enhancements/_title-YYYY-MM-DD-#issue.md

63 lines
1.9 KiB
Markdown
Raw Normal View History

# Enhancement Proposal (EP) <issue#> - <YYYY-MM-DD> - <title>
## Table of Contents
- [Summary](#summary)
- [Motivation](#motivation)
- [Goals/Pain](#goals)
- [Non-Goals](#non-goals)
- [Proposal](#proposal)
- [User Experience](#user-experience)
- [Implementation Details/Notes/Constraints](#implementation-detailsnotesconstraints)
- [Risks and Mitigations](#risks-and-mitigations)
- [Alternatives](#alternatives)
- [Future Improvements](#future-improvements)
## Summary
- Provide a one-paragraph description of the expected change here.
## Context
- Link to any previous issues, RFCs, discussions, or briefs.
- Link to any ongoing or future work relevant to this change.
## Motivation
### Goals/Pain
- List work that is assumed to be done in the scope of this enhancement.
- Mention problems solve by this enhancement.
### Non-goals
- List work that is entirely out of the scope of this enhancement. Use this to define EP borders to keep work focused.
- All planned future enhancements should be listed in one of the following blocks - Future Improvements.
## Proposal
### User Experience
- Explain your change as if you were describing it to end-users.
- Explain the way users are supposed to use Dex with the proposed enhancement.
### Implementation Details/Notes/Constraints
- Explain your change as if you were at a development team meeting (give more technical and implementation details).
- When possible, demonstrate with pseudo-code, not text.
- Be specific. Be opinionated. Avoid ambiguity.
### Risks and Mitigations
- Mention all expected risks and migrations in detail here.
- Do not forget to mention if the proposed enhancement is a breaking change.
### Alternatives
- What other approaches have been considered, and why did you not choose them?
- What happens if this enhancement will never be accepted and implemented?
## Future Improvements
- List any future improvements.