#+Start Date: (fill me in with today’s date, DD-MM-YYYY) #+RFC MR: (leave this empty)
> One paragraph explanation of the change.
> Why are we doing this? What use cases does it support? What is the expected outcome?
> This is the bulk of the RFC.
> Explain the design in enough detail for somebody familiar with the infrastructure to understand. This should get into specifics and corner-cases, and include examples of how the service is used. Any new terminology should be defined here.
> Why should we not do this? Please consider the impact on users, on the integration of this change with other existing and planned features etc.
> There are tradeoffs to choosing any path, please attempt to identify them here.
> Why is this design the best in the space of possible designs?
> What other designs have been considered and what is the rationale for not choosing them?
> What is the impact of not doing this?
Discuss prior art, both the good and the bad, in relation to this proposal. A few examples of what this can include are:
> How other services / infrastructures in the same domain have solved this problem.
> Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background.
This section is intended to encourage you as an author to think about the lessons from other organisations, provide readers of your RFC with a fuller picture. If there is no prior art, that is fine - your ideas are interesting whether they are brand new or if it is an adaptation from other services.
> What parts of the design do you expect to resolve through the RFC process before this gets merged?
> What parts of the design do you expect to resolve through the implementation of this feature before stabilisation?
> What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?