| Status | (Proposed/Accepted/Implemented/Obsolete) |
|---|---|
| RFC # | (GENERATED UPON APPROVAL) |
| Author(s) | Your name (me@example.org), and other (you@example.org) |
| Obsoletes | RFCs this replaces. Remove if none. |
| Creation | MM/DD/YYYY |
| Approval | (GENERATED UPON APPROVAL) |
If someone reads this far, what do you want them to know?
Explains where the need mainly comes from for those just joining the team or without as much knowledge. It needs to be as complete as possible with external links if needed for example.
It can contain two paragraphs to a page for example. The important thing is to explain what is necessary to introduce a technical person to why the need exists.
What does it propose and why? What is the objective? What is not the objective of this RFC?
Keep it simple. One or two paragraphs.
What are the real benefits that users, the company or devs will have with this implementation?
This is the core of the document, where you explain your proposal. If you have multiple alternatives, be sure to use sub-sections for better separation of the idea and list the pros and cons of each approach. If there are alternatives that you eliminated, you should also list them here and explain why you believe your approach is better.
Make sure you have thought about and addressed the following sections. If a section is not relevant to your specific proposal, explain why, e.g. your RFC addresses a convention or process, not an API.
- Be sure to discuss the relative merits of alternatives to your proposal.
- Add other RFCs or discussions that add as reference to your proposal.
- Are there any risks involved, such as exposing information in third-party software for example?
- List some usage examples in a language or application