| RFC | Author | Status | Created | Last Modified |
|---|---|---|---|---|
XXXX |
Kyle Fuller |
Draft |
2015-09-21 |
2015-09-21 |
Once you've made a copy of this template, remove this abstract, fill out the metadata above and the sections below, then submit the RFC. Follow the guidelines in RFC 1.
This should be a short (~200 word) description of the technical issue being addressed.
This (and the above metadata) is the only section strictly required to submit a draft RFC; the following sections can be barebones and fleshed out as you work through the RFC process.
This section should explain why this RFC is needed. The motivation is critical for RFCs that want to add substantial new features or materially refactor existing ones. It should clearly explain why the existing solutions are inadequate to address the problem that the RFC solves. RFC submissions without sufficient motivation may be rejected outright.
This section should flesh out out the specification by describing what motivated the specific design design and why particular design decisions were made. It should describe alternate designs that were considered and related work.
The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
If this RFC introduces backwards incompatibilities, you must must include this section. It should describe these incompatibilities and their severity, and what mitigation you plan to take to deal with these incompatibilities.