RFC <issue#> - <YYYY-MM-DD> - <title>

One paragraph description of the change.

Context

• Link to any previous issues, RFCs, or briefs (do not repeat that context in this RFC).
• Link to any ongoing or future work relevant to this change.
• List any prior art (from other projects or the broader ecosystem), the good and the bad.

Scope

In scope

• List work being directly addressed with this RFC.

Out of scope

• List work that is completely out of scope. Use this to keep discussions focused. Please note the "future changes" section at the bottom.

Motivation

• What internal or external pain are we solving?
• Why is this change worth it?
• What is the impact of not doing this?
• How does this position us for success in the future?

Proposal

User Experience

• Explain your change as if you were describing it to a Vector user. We should be able to share this section with a Vector user to solicit feedback.
• Does this change break backward compatibility? If so, what should users do to upgrade?

Implementation

• Explain your change as if you were presenting it to the Vector team.
• When possible, demonstrate with pseudo code not text.
• Be specific. Be opinionated. Avoid ambiguity.

Alternatives

• What other approaches have been considered and why did you not choose them?
• What are the drawbacks of the chosen approach?
• How about not doing this at all?

Outstanding Questions

• List any remaining questions.
• Use this to resolve ambiguity and collaborate with your team during the RFC process.
• These must be resolved before the RFC can be merged.

Plan Of Attack

Incremental steps to execute this change. These will be converted to issues after the RFC is approved:

• Submit a PR with spike-level code roughly demonstrating the change.
• Incremental change #1
• Incremental change #2
• ...

Note: This can be filled out during the review process.

Future Improvements

• List any future improvements. Use this to keep your "plan of attack" scope small and project a sound design.