---
name: Request for comments
about: Request for comments around the community.
title: '[RFC] {{RFC name}}'
labels: good first issue, question
assignees: jun-sheaf
---

## Summary<sup>\*</sup>

{{One paragraph explanation of the change}}

## Motivation<sup>\*</sup>

{{
Why are we doing this? What use cases does it support? What is the expected
outcome?
}}

## Design Detail<sup>\*</sup>

{{
 Explain the design in enough detail for somebody familiar with the
infrastructure to understand. This should get into specifics and corner-cases,
and can include examples of how the service is used. Any new terminology should
be defined here.
}}

## Drawbacks<sup>\*</sup>

{{
 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<sup>\*</sup>

{{ 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<sup>\*</sup>

{{ 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<sup>\*</sup>

{{ 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? }}

\* means required.