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
[summary]: #summary

Brief explanation of the feature.

# Motivation
[motivation]: #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
[design]: #detailed-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
[alternatives]: #alternatives

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

## Unresolved questions
[unresolved]: #unresolved-questions

What parts of the design are still TBD?

# Drawbacks
[drawbacks]: #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.
RFC template - Add mention to tests 2018-01-11 22:00:55 +00:00			`- Feature Name: (fill with a unique identifier, ex: my_awesome_feature)`
Add RFC template draft and README file The "RFC" (request for comments) process is intended to provide a consistent and controlled path for new features to enter the project. This is inspired in the RFC processes of React, Yarn, Rust, and Ember. 2017-12-26 12:45:38 +00:00			`- Start Date: (fill with today's date, YYYY-MM-DD)`
			`- RFC PR: (leave this empty)`
			`- Salt Issue: (leave this empty)`

			`# Summary`
			`[summary]: #summary`

			`Brief explanation of the feature.`

			`# Motivation`
			`[motivation]: #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`
			`[design]: #detailed-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`
RFC template - Add mention to tests 2018-01-11 22:00:55 +00:00			`- Outline of a test plan for this feature. How do you plan to test it? Can it be automated?`
Add RFC template draft and README file The "RFC" (request for comments) process is intended to provide a consistent and controlled path for new features to enter the project. This is inspired in the RFC processes of React, Yarn, Rust, and Ember. 2017-12-26 12:45:38 +00:00
			`## Alternatives`
			`[alternatives]: #alternatives`

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

			`## Unresolved questions`
			`[unresolved]: #unresolved-questions`

			`What parts of the design are still TBD?`

			`# Drawbacks`
			`[drawbacks]: #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.`