RequestForDiscussion
title: Request for Discussion (RFD) type: technique created: 2026-05-16 last_updated: 2026-05-16 related: ["Playradar", "RFD"] sources: ["https://rfd.shared.oxide.computer/rfd/0001"] radar_quadrant: Techniques radar_ring: Assess radar_position: inner
A process for proposing, discussing, and documenting technical and organizational decisions via numbered markdown documents stored in a Git repository. Originated at IETF as the RFC process; adapted by Oxide Computer for internal engineering use.
"Notes are encouraged to be timely rather than polished." The process lowers the barrier to participation by prioritizing early, rough ideas in discussion over waiting for a fully formed proposal. Any team member can initiate an RFD on any topic: architecture decisions, API changes, process improvements, testing strategies.
RFDs move through six states, each representing a stage of maturity:
| State | Meaning |
|---|---|
| prediscussion | Active early drafting; not yet ready for feedback |
| ideation | Topic defined, scope clear, not under active revision |
| discussion | Open pull request; actively receiving feedback |
| published | Merged; represents current consensus or direction |
| committed | Fully implemented; documents how the system actually works |
| abandoned | Deliberately not implemented |
The pull request is the primary discussion mechanism. Discussion continues on a published RFD's original PR; significant divergence warrants a new RFD.
Each RFD lives in its own numbered branch (0042) and subdirectory (rfd/0042/README.md). The branch name and directory number are the RFD's permanent identifier. Metadata (authors, state, discussion link, labels) is stored in frontmatter within the document itself.
A bot enforces consistency: if state is set to discussion without a PR, the bot opens one; if a PR is opened without updating state, the bot corrects it.
RFDs are not limited to software. Oxide applies them to hardware design, company processes, and organizational decisions. The document cites Tesla's Battery Day as a model for integrating technical specifications with economic and customer-impact analysis.
Architectural Decision Records (ADR) cover a similar need but are narrower in scope (architecture decisions only) and lighter in process (no formal states, no bot enforcement). RFDs are more structured and organization-wide. See ADR for the comparison.
See RFD for the step-by-step workflow used in this repository: branch naming, placeholder creation, PR process, and state transitions.
Request for Discussion (RFD) sits in the Assess ring of the Techniques quadrant, at inner position. The process has been used in a personal or side project, confirming it is workable and well-understood at an implementation level. The inner position reflects that production or team use is the only remaining gate before Trial. Organisations such as Oxide Computer run RFDs at scale; the process is mature. One real-team engagement would move this blip to Trial. First recorded on 2026-05-16.
