One paragraph description of the change.
- 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 work being directly addressed with this RFC.
- List work that is completely out of scope. Use this to keep discussions focused. Please note the "future changes" section at the bottom.
- What internal or external pain are we solving?
- Do not cover benefits of your change, this is covered in the "Rationale" section.
- 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?
- 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.
- Why is this change worth it?
- What is the impact of not doing this?
- How does this position us for success in the future?
- Why should we not do this?
- What kind on ongoing burden does this place on the team?
- List prior art, the good and bad.
- Why can't we simply use or copy them?
- What other approaches have been considered and why did you not choose them?
- How about not doing this at all?
- 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.
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.
- List any future improvements. Use this to keep your "plan of attack" scope small and project a sound design.