This directory contains the "RFCs" for the devbase project. An RFC is a "Request for Comments". These are documents that describe the design and implementation of features in the devbase project.
An RFC is a document that describes a design and implementation of a feature or large change in the devbase project. It is intended to be a living document, and is updated as the scope of the feature/fix evolves over time.
An RFC is created when a feature or fix is deemed to be large enough to warrant a more detailed discussion. This is to ensure that the design and implementation of the feature/fix is well thought out, documented, and given time for feedback from the community.
The "Draft" status is used when an RFC is in the process of being drafted. This is the initial state of an RFC, and is in the form of a "draft" pull request.
A RFC is "Proposed" when it is ready for review. This is the state of an RFC when it is ready for review by the community. The author of the RFC should be prepared to answer questions and make changes to the RFC as needed.
Once an RFC is merged, it is considered "accepted" and may be implemented with the goal of eventual inclusion into the devbase project. Being "accepted" is not a rubber stamp, and in particular still does not mean the feature will ultimately be merged; it does mean that in principle all the major stakeholders have agreed to the feature and are amenable to merging it.
An RFC will be updated as development progresses, as it's considered to be a living document that will be updated as the feature evolves. The author, or implementor, of the RFC should update it as needed.
If, during the development of an RFC, the implementation changes significantly, the author should update the RFC to reflect the changes. This will help keep the RFC up to date, and will help the community to understand the changes. If the changes void the original RFC, the author should create a new RFC to supersede the original RFC and note that accordingly.
An RFC can also be "Rejected". The possible reasons for rejection include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the goals and direction of the devbase project.
Once an RFC is implemented, it is considered "Completed". This means that the RFC is no longer a living document, and the feature is considered to be complete. The RFC will reflect that it is completed, and contain information about how the process went, and any lessons learned.
- Copy the
0000-template.mdfile torfcs/0000-my-feature.md,0000will be replaced with the PR number later. - Fill in the RFC. Put care into the details: RFCs that do not present convincing motivation, demonstrate understanding of the impact of the design, or are disingenuous about the drawbacks or alternatives tend to be poorly-received. You might want to create a Draft Pull Request to make this process easier and more effective.
- Submit a pull request. As a pull request the RFC will receive design feedback from the larger community, and the author should be prepared to revise it in response.
- Update the RFC with the PR number once it is created.
Updating an RFC follows the same process as creating a new RFC. The author should create a PR updating the current document, as it is considered "living", and pull request the changes into the RFC.
Once an RFC has reached the "Completed" stage (the functionality has been implemented), the same process as updating an RFC should be followed. The author should create a PR updating the current document and pull request the changes into the RFC. The RFC should be updated to reflect that it is completed, and contain information about how the process went, and any lessons learned.
This is also the opportunity to fine-tune the RFC process itself. If there are changes that could be made to the RFC process, consider creating a new RFC to propose those changes to the RFC process itself.