- Feature Name: (fill with a unique identifier, ex: my-awesome-feature)
- Start Date: (fill with today's date, YYYY-MM-DD)
- SEP Status: Draft
- SEP PR: (leave this empty)
- Salt Issue: (leave this empty)
Brief explanation of the feature.
Why are we doing this? What use cases does it support? What is the expected outcome?
If this SEP is not accepted, the motivation could be used to develop alternative solutions. Enumerate the constraints you are trying to solve without coupling them too closely to the solution you have in mind.
This is the bulk of the SEP. Explain the design in enough detail for somebody familiar with the product to understand, and for somebody familiar with the internals to implement. It should include:
- Definition of any new terminology
- Examples of how the feature is used.
- Corner-cases
- A basic code example in case the proposal involves a new or changed API
- Outline of a test plan for this feature. How do you plan to test it? Can it be automated?
What other designs have been considered? What is the impact of not doing this?
What parts of the design are still TBD?
Why should we not do this? Please consider:
- Implementation cost, both in term of code size and complexity
- Integration of this feature with other existing and planned features
- Cost of migrating existing Salt setups (is it a breaking change?)
- Documentation (would Salt documentation need to be re-organized or altered?)
There are tradeoffs to choosing any path. Attempt to identify them here.