Requests for comments (RFCs)

Approved RFCs

Refer to the ‣ database; all approved RFCs should be manually indexed there.

Quickstart

Create a new RFC:
- Automatically, via sg tool
  - Benefits
    1. Ensures unique ID across public and private RFCs
    2. Creates the document and update title and content
    3. (for private RFC) creates a breadcrumb doc in the public RFC folder, to redirect to the private RFC and not leave a gap in the public view
  - Command:
```
sg rfc [--private] create --type <type> "rfc title"
```
    Example:
```
sg rfc --private create --type solution "Cody on Apple Watch"
```
  - More information: Tool reference.
- Manually
  - The default format — View or Duplicate
  - Framing problems, proposing solutions, and making decisions—View or Duplicate
  - Surfacing a tension—View or Duplicate
  - Proposal for adding data to pings — View or Duplicate
  - Proposing process / handbook changes — View or Duplicate
Add approved RFCs to the Approved RFCs Index
View all public RFCs
View all private RFCs
There is also an #rfcs channel you can use to follow along with RFCs as they are created. The bot that updates the channel is a Zapier integration; you can request access in #it-tech-ops but you only need to do this if you want to modify the bot.

We use RFCs to collaborate successfully as an all remote team.

RFCs give us a way to write down ideas and plans so we can communicate, collect thoughtful feedback from others on the team, and make decisions.

An “RFC” literally means a “Request for Comments.” Though RFCs at Sourcegraph can take many forms for different purposes, an RFC is ultimately just a document with a few attributes:

The author’s name(s)
The date it was written
A sequential number
A status label
Is public to the world by default
Is a Google Doc

Our goal is for RFCs to be lightweight, low-process, and effortless to create and use. An RFC can be thought of as an asynchronous conversation. Unlike Slack, email, or other channels, using RFCs helps us because: