|
| 1 | +--- |
| 2 | +# Valid statuses: draft | proposed | rejected | accepted | superseded |
| 3 | +status: draft |
| 4 | +author: Your Name |
| 5 | +created: YYYY-MM-DD |
| 6 | +updated: YYYY-MM-DD |
| 7 | +--- |
| 8 | + |
| 9 | +# Title |
| 10 | + |
| 11 | +<!-- |
| 12 | +This section should be one or two paragraphs that just explains what the goal of this decision is going to be, but without diving too deeply into the "why", "why now", "how", etc. |
| 13 | +Ensure anyone opening the document will form a clear understanding of the intent from reading this paragraph(s). |
| 14 | +--> |
| 15 | + |
| 16 | +## Background |
| 17 | + |
| 18 | +<!-- |
| 19 | +The next section is the "Background" section. This section should be at least two paragraphs and can take up to a whole page in some cases. |
| 20 | +The guiding goal of the background section is: as a newcomer to this project (new employee, team transfer), can I read the background section and follow any links to get the full context of why this change is necessary? |
| 21 | +
|
| 22 | +If you can't show a random engineer the background section and have them acquire nearly full context on the necessity for the RFC, then the background section is not full enough. To help achieve this, link to prior RFCs, discussions, and more here as necessary to provide context so you don't have to simply repeat yourself. |
| 23 | +--> |
| 24 | + |
| 25 | +## Requirements |
| 26 | + |
| 27 | +<!-- |
| 28 | +This section outlines the requirements that the proposal must meet. |
| 29 | +These requirements should be derived from the background section and should be clear, concise, and actionable. |
| 30 | +This is where you can specify the goals and constraints that the proposal must satisfy. |
| 31 | +This could include performance metrics, security considerations, user experience goals, and any other relevant criteria. |
| 32 | +--> |
| 33 | +* {Requirement 1} |
| 34 | +* {Requirement 2} |
| 35 | +* {Requirement 3} |
| 36 | +* … <!-- numbers of requirements can vary --> |
| 37 | + |
| 38 | +## Considered Options |
| 39 | + |
| 40 | +<!-- |
| 41 | +This section lists all the options that were considered for addressing the need outlined in the background section. |
| 42 | +Each option should be clearly defined with a descriptive title. |
| 43 | +This provides a comprehensive overview of the solution space that was explored before making a decision. |
| 44 | +The options will be evaluated in the proposal section, where the chosen approach is justified. |
| 45 | +--> |
| 46 | + |
| 47 | +* {title of option 1} |
| 48 | +* {title of option 2} |
| 49 | +* {title of option 3} |
| 50 | +* … <!-- numbers of options can vary --> |
| 51 | + |
| 52 | +## Proposal |
| 53 | + |
| 54 | +<!-- |
| 55 | +The next required section is "Proposal" or "Goal". |
| 56 | +Given the background above, this section proposes a solution. |
| 57 | +This should be an overview of the "how" for the solution. |
| 58 | +Include content like diagrams, prototypes, and high-level requirements. |
| 59 | +--> |
| 60 | + |
| 61 | +<!-- This is an optional element. Feel free to remove. --> |
| 62 | +### API changes |
| 63 | + |
| 64 | +<!-- |
| 65 | +This section should describe any API changes that are part of the proposal. |
| 66 | +This includes any new endpoints, changes to existing endpoints, or modifications to the data model. |
| 67 | +It should provide enough detail for developers to understand how the API will evolve and what impact it will have on existing clients. |
| 68 | +--> |
| 69 | + |
| 70 | +<!-- This is an optional element. Feel free to remove. --> |
| 71 | +### Consequences |
| 72 | + |
| 73 | +* Good, because {positive consequence, e.g., improvement of one or more desired qualities, …} |
| 74 | +* Bad, because {negative consequence, e.g., compromising one or more desired qualities, …} |
| 75 | +* … <!-- numbers of consequences can vary --> |
| 76 | + |
| 77 | +### Timeline |
| 78 | + |
| 79 | +<!-- |
| 80 | +This section outlines a high level timeline for implementing the proposal. |
| 81 | +It should include key milestones, deadlines, and any dependencies that need to be addressed. |
| 82 | +This helps to set expectations for the size of the change and the expected timeline for completion. |
| 83 | +--> |
| 84 | + |
| 85 | +<!-- This is an optional element. Feel free to remove. --> |
| 86 | +### Open questions |
| 87 | + |
| 88 | +* {Question 1} |
| 89 | +* … <!-- numbers of question can vary --> |
| 90 | + |
| 91 | +<!-- This is an optional element. Feel free to remove. --> |
| 92 | +## More Information |
| 93 | + |
| 94 | +<!-- |
| 95 | +This section provides additional context, evidence, or documentation to support the decision. |
| 96 | +Use this space to provide any supplementary information that would be helpful for future readers |
| 97 | +to fully understand the decision and its implications. |
| 98 | +--> |
0 commit comments