RFD 1 Requests for Discussion

A look inside our internal Requests for Discussion process.

Oxide Computer Company logo
Oxide Computer Company
•
Jessie Frazelle
•13 min read•beginner•
--
•View Original
GolangHTMLKubernetesRustV

Overview

The article discusses the RFD (Requests for Discussion) process implemented by Oxide Computer Company, detailing how ideas are documented, discussed, and iterated upon within the organization. It emphasizes the importance of capturing ideas transparently and provides a structured workflow for creating and managing RFDs, akin to the IETF's Request for Comments.

What You'll Learn

1

How to create and manage Requests for Discussion (RFDs) in a software development environment

2

Why documenting ideas early in the development process can enhance collaboration

3

When to transition RFDs through different states from ideation to published

4

How to utilize Git for version control in the RFD process

5

How to effectively discuss and iterate on RFDs with team members

Key Questions Answered

What is the purpose of Requests for Discussion (RFDs) in software development?
Requests for Discussion (RFDs) serve as a means to document and share ideas transparently within a team. They allow for the rigorous formulation of nascent ideas, encouraging candid discussions and iterative improvements before final decisions are made.
What are the different states an RFD can be in during its lifecycle?
An RFD can exist in one of six states: prediscussion, ideation, discussion, published, committed, and abandoned. Each state represents a different phase in the RFD's development, from initial brainstorming to final implementation.
How can team members contribute to the RFD process?
Team members can contribute by initiating discussions on RFDs, providing feedback during the discussion state, and suggesting changes or improvements. This collaborative approach ensures diverse input and enhances the quality of the final document.
When should an RFD be merged into the master branch?
An RFD should be merged into the master branch after sufficient discussion has occurred, typically allowing 3-5 business days for feedback. This ensures that the document has been reviewed and agreed upon by relevant stakeholders before finalization.

Technologies & Tools

Some links below are affiliate links. We may earn a commission if you make a purchase.

Version Control
Git
Used for managing RFD branches and tracking changes throughout the RFD lifecycle.
Programming Language
Rust
Functions in Rust are used to automate and program tooling with RFD data.

Key Actionable Insights

1
Implementing an RFD process can significantly improve idea management within your team.
By documenting ideas early and allowing for iterative feedback, teams can ensure that all voices are heard and that ideas are refined before implementation.
2
Utilize Git branches effectively to manage the RFD lifecycle.
Creating separate branches for each RFD allows for organized development and discussion without disrupting the main codebase, facilitating smoother collaboration.
3
Encourage team members to engage in the RFD discussion process actively.
Fostering an environment where feedback is welcomed can lead to better ideas and more robust solutions, ultimately enhancing project outcomes.
4
Regularly review and update RFDs even after they are published.
This practice ensures that the documentation remains relevant and reflects any changes or improvements made to the processes or ideas discussed.

Common Pitfalls

1
Failing to engage team members in the RFD discussion can lead to overlooked ideas and poor decisions.
When team members do not participate in discussions, valuable insights may be missed, and the final RFD may not reflect the collective input necessary for success.
2
Not updating RFDs after they are published can result in outdated information.
If RFDs are not regularly reviewed and revised, they may no longer serve their intended purpose, leading to confusion and misalignment within the team.