RFC number WIP: title
Sourcegraph, a search and navigation tool for developers, uses RFCs (Request for Comments) to offer a structured framework for collaboration amongst its own developers. Using the company's RFC template, the Sourcegraph is able to streamline the process of gathering feedback and making decisions internally.
The RFC begins with crucial information such as the recommender's email, date, status, decider, input providers, and a list of approvers with their respective deadlines for reviewing the RFC. It also includes a concise, one-paragraph summary that provides the necessary context, outlines the problem being addressed, and presents the proposed solution. The background section focuses on providing factual information to frame the rest of the RFC, avoiding subjective opinions. The problem section defines the specific problem the RFC aims to solve, including any constraints and justification for addressing the problem at the present moment. The proposal section outlines the details of the solution up for consideration, and the final definition of success section addresses how to measure results.
This structured approach to product planning allows developer teams to effectively communicate and implement changes, facilitating more collaboration and efficient decision-making.
RFC number WIP: title
Rename this RFC in this format: RFC <number> <status>: <title>
This is a starting point for an RFC for adding new data to pings.
- Recommender: you@sourcegraph.com
- Date:
- Status: WIP
- Decider:
- Input providers: Logan, Alex...
- Approvers (please review by EOD YYYY-MM-DD):
- Approvals:
- Team (follow these conventions so we can search by team):
Summary
A single-paragraph context-problem-solution summary. The goal is to make the purpose click for the reader. (It’s usually best to write this as a final step of writing the RFC.)
Background
Just enough context necessary to frame the rest of the RFC. The content should be indisputable facts, not opinion.
Problem
A description of the problem that this RFC is trying to address, the constraints, and why this problem is worth solving now.
Proposal
What data should be added, including:
- The exact data fields you’re requesting to add
- The exact questions you’re trying to answer with this new data, and why existing data can’t answer those questions
- What the JSON payload looks like once those data fields are added
Definition of success
How do we know if this proposal was successful?
Sourcegraph, a search and navigation tool for developers, uses RFCs (Request for Comments) to offer a structured framework for collaboration amongst its own developers. Using the company's RFC template, the Sourcegraph is able to streamline the process of gathering feedback and making decisions internally.
The RFC begins with crucial information such as the recommender's email, date, status, decider, input providers, and a list of approvers with their respective deadlines for reviewing the RFC. It also includes a concise, one-paragraph summary that provides the necessary context, outlines the problem being addressed, and presents the proposed solution. The background section focuses on providing factual information to frame the rest of the RFC, avoiding subjective opinions. The problem section defines the specific problem the RFC aims to solve, including any constraints and justification for addressing the problem at the present moment. The proposal section outlines the details of the solution up for consideration, and the final definition of success section addresses how to measure results.
This structured approach to product planning allows developer teams to effectively communicate and implement changes, facilitating more collaboration and efficient decision-making.
