salt/rfcs/0000-template.md

• Feature Name: (fill with a unique identifier, ex: my_awesome_feature)
• Start Date: (fill with today's date, YYYY-MM-DD)
• RFC PR: (leave this empty)
• Salt Issue: (leave this empty)

Summary

Brief explanation of the feature.

Motivation

Why are we doing this? What use cases does it support? What is the expected outcome?

If this RFC 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.

Design

This is the bulk of the RFC. 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?

Alternatives

What other designs have been considered? What is the impact of not doing this?

Unresolved questions

What parts of the design are still TBD?

Drawbacks

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.