Requests for Discussion are documents which describe proposed changes to Hipcheck to enable discussion and careful consideration before changes are implemented. They are inspired by processes such as:
The primary goal of the Hipcheck RFD process is to enable the team and any broader interested parties from the open source software ecosystem to voice concerns, discuss design trade-offs, and reach consensus (or, where consensus is not possible, a decision as determined by the project's leadership) which is well informed and considered.
The RFD process also ensures that important decisions about the design, implementation, and future of Hipcheck are documented for future reference. Too often in software projects, key decisions are made in individual or group discussions but not recorded for posterity, or key considerations are spread across many disparate discussions, making it hard to recover the full history of how decisions were reached.
RFD's also provide a mechanism to signal when important decisions are being made, to gather interest and input when it's neededmost.
Only important changes should be done with an RFD. Of course, this can be a vague and difficult term, so let's try to explain it further.
RFDs should be written for changes which involve important API boundaries or guarantees provided by Hipcheck, to its end users or to plugin authors. RFDs should also be written when involving changes that cut across large parts of the Hipcheck codebase, or which seriously impact features Hipcheck provides for users. If a decision is expected to be contentious, an RFD should generally be written for it. Finally, if a design is technically difficult or involves substantial trade-offs which need to be weighed, an RFD should be written for it.
RFDs don't have an exact template. They're intended to be prose documents built around the needs and context of the changes they're proposing. That said, RFDs should address the following:
For RFDs which are not describing proposed changes to Hipcheck, but are instead describing project goals, values, or other non-technical aspects of the Hipcheck project, any of the above may be ignored as appropriate.
RFDs should be added as Pull Requests to the Hipcheck repository, and will go through the standard Hipcheck contribution process.
Each RFD will be added as a file in the docs/rfds/ folder, prefixed
with a four-digit number, left-padded with zeroes, increasing from 0001.
This is the RFD's "RFD ID".
RFDs can be in one of the following states:
docs/rfds/ folder.Only Accepted RFD's receive RFD IDs. RFDs in the Proposed or Closed state can be referred to by their Pull Request number.
Anyone can write an RFD! RFDs are accepted from all contributors, and the bar for acceptance and incorporation by the project is the same regardless of who has submitted an RFD.