(RFC title goes here)

Summary

One paragraph explanation of the change.

Motivation

Why are we doing this? What use scenario does it support? What is the expected outcome?

Design Detail

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.

Drawbacks

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.

Rationale and Alternatives

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?

Prior Art

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.

Unresolved questions

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?

2.3 KiB Raw Permalink Blame History