| Status | Proposed/Accepted/Deprecated |
|---|---|
| RFC # | #### |
| Authors | First Author (first.author@ibm.com), ... |
| Deprecates | RFC that this RFC deprecates |
| Submitted | YYYY-MM-DD |
| Updated | YYYY-MM-DD |
RFC markdown filename should be of the form ####-rfc-title.md. Where #### will
be set as max(rfc_####) + 1 after the acceptance of the RFC, but before its
merger. If the RFC requires supporting files, a folder may be created with the
same name as the RFC, ####-rfc-title, in which the RFC should reside.
One paragraph explanation of the feature.
- Why are we doing this?
- What will this enable?
- What will be the outcome?
- Who will benefit?
- Who are the target users of this work?
- How will users or contributors benefit from the work proposed?
This is the focus of the document. Explain the proposal from the perspective of educating another user on the proposed features.
This generally means:
- Introducing new concepts and nomenclature
- Using examples to introduce new features
- Implementation and Migration path with associated concerns
- Communication of features and changes to users
Focus on giving an overview of impact of the proposed changes to the target audience.
Factors to consider:
- Performance
- Dependencies
- Maintenance
- Compatibility
Technical reference level design. Elaborate on details such as:
- Implementation procedure
- If spans multiple projects cover these parts individually
- Interaction with other features
- Dissecting corner cases
- Reference definition, eg., formal definitions.
Discuss other approaches to solving this problem and why these were not selected.
Open questions for discussion and an opening for feedback.
Consider what extensions might spawn from this RFC. Discuss the roadmap of related projects and how these might interact. This section is also an opening for discussions and a great place to dump ideas.
If you do not have any future extensions in mind, state that you cannot think of anything. This section should not be left blank.