|
|
@ -0,0 +1,39 @@ |
|
|
|
# RFC {RFC-NUMBER}: {TITLE} |
|
|
|
|
|
|
|
## Changelog |
|
|
|
|
|
|
|
- {date}: {changelog} |
|
|
|
|
|
|
|
## Author(s) |
|
|
|
|
|
|
|
- {First Name} {github handle} |
|
|
|
|
|
|
|
## Context |
|
|
|
|
|
|
|
> This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high level idea behind the solution. |
|
|
|
|
|
|
|
## Proposal |
|
|
|
|
|
|
|
> It should contain a detailed breakdown of how the problem should be resolved including diagrams and other supporting materials needed to present the case and implementation roadmap for the proposed changes. The reader should be able to fully understand the proposal. This section should be broken up using ## subsections as needed. |
|
|
|
|
|
|
|
## Status |
|
|
|
|
|
|
|
> A decision may be "proposed" if it hasn't been agreed upon yet, or "accepted" once it is agreed upon. If a later RFC changes or reverses a decision, it may be marked as "deprecated" or "superseded" with a reference to its replacement. |
|
|
|
|
|
|
|
{Deprecated|Proposed|Accepted} |
|
|
|
|
|
|
|
## Consequences |
|
|
|
|
|
|
|
> This section describes the consequences, after applying the decision. All consequences should be summarized here, not just the "positive" ones. |
|
|
|
|
|
|
|
### Positive |
|
|
|
|
|
|
|
### Negative |
|
|
|
|
|
|
|
### Neutral |
|
|
|
|
|
|
|
## References |
|
|
|
|
|
|
|
> Are there any relevant PR comments, issues that led up to this, or articles referenced for why we made the given design choice? If so link them here! |
|
|
|
|
|
|
|
- {reference link} |