Notion is a popular webapp for managing hierarchies of rich text information shared across an organization. It is essentially a Wiki but with more advanced features that can be embedded within a given page. Much like RFC Hub, some content can be made publicly available, but the default behavior is to make content private.

Since you're reading this page you're probably curious about how to use Notion to not only store technical proposals / Request For Comment (RFC) documents, but to also manage the lifecycle and review process of these documents. Notion is a very malleable tool and so there are many ways to track RFCs in it but if you don't consider all the use-cases you might end up with something that doesn't scale. We care deeply about RFCs and have researched this topic a lot and have put together this document to help out.

What an RFC Needs #

An RFC is the backbone of many software engineering companies. Such documents provide insight and conversation about technical decision, allowing engineers to gain important context when making technical decisions. They also act as important reference docs for code archaeologists in the future who need to find out why a system was "built that way".

Here's a list of important features of an RFC, regardless of the tool used to track it:

• Title
• Unique Identifier
• Timestamps to track date of creation and modifications
• A list of reviewers, their importance, and the status of their review
• Contextual conversation about the RFC and the ability to make updates
• A status of an RFC, like if it's in draft or seeking review or published or obsolete

Notion is first and foremost a tool for editing rich text documents in a hierarchy with a page being a parent and other pages being children. Or in other words, with the traditional filesystem concept, a page can be a file or a folder.

This means you can make an "RFCs" page, then add as many child pages to it as you like, each one representing an RFC, with the RFC title being the page title. Then you can dump all of the information you want inside of the page itself.

Unfortunately this would lead to an unmaintainable disaster. And while Notion allows one to search for content across a Notion Workspace easily, this still doesn't make it easy to sort and filter RFCs. Looking through a massive list of pages in the left column is also difficult. Instead, you'll want to make a Database.

Step-by-Step: Setting Up an RFC Database in Notion #

The first step is to create a page in the Notion Workspace hierarchy to attach the RFC database to. I recommend putting it as high up in the hierarchy as you can. For small to medium sized organizations, or for orgs where only software engineers use the Notion Workspace, create a root "RFCs" or "Technical Proposals" page. For larger organizations it might make sense to put them in a "Teams / Engineering / RFCs" folder. Wherever you create the page it will hereby be referred to as the RFC Page.

In the page, type /database and choose to create an inline database in the page. You have now created a database, which is a table that can be sorted and filtered. A database has a name that is independent of the page that owns it so give it a name like "RFCs" or "Engineering Proposals" or "RFC Database". A database handles large amounts of data better than a table and is akin to a Spreadsheet. Filtering is client side by default but can be saved for others as well.

The URL to view the RFCs will look something like this depending on if you view the page or if you browse to the database directly:

Page:     https://www.notion.so/RFCs-987792247804ffc34ac94c3bf05abc91
Database: https://www.notion.so/87deb1f0cd7d2fee89695b31102721d4?v=62d9fa42e9b2f52d80ab4bec55ed5914

By default a database only has one column to store a name. The name field is useful for tracking the title of an RFC but you'll need additional fields as well. Click the "+" icon in the top right corner of the database to add an additional field.

Here are a set of recommended fields to satisfy the above RFC requirements. When adding the field you can select the type, the context menu allows you to set the field's name, and the "Edit property" submenu allows you to set more specific details.

• Rename the default "Name" column to be "Title"
• Type: "ID", name "ID", Prefix: "RFC"
• Type: "Status", name "Status", add the following fields:
  • Group: "To-do", name "Draft", color: grey
  • Group: "In progress", name "In Review", color: yellow
  • Group: "Complete", name "Obsolete", color: red
  • Group: "Complete", name "Published", color: green
• Type: "Created by", name "Author"
• Type: "Created time", name: "Created"
• Type: "Last edited time", name: "Modified"
• Type: "Person", name: "Reviewers", limit: "No limit"

Once the columns have been added they can be resized by dragging the handle at the top of the database. Columns can also be reordered by dragging their name around. Of course, you won't know what a good width will be until you add a record or two.

Click the "+ New page" link at the bottom to create a new RFC. The first entry will have an ID of "RFC-1" and the cursor will be focused in the title field. The status will default to "Draft". Type in a title and press enter. Once you do that a new "OPEN" button will appear in the title field. It's a little awkward and subtle but that's how you'll go from the RFC list to an RFC. Click it to view the RFC taking up the right half of the screen. This isn't the best way to view the RFC but thankfully you can open the RFC so that it fills the whole screen. Either press Ctrl + Enter or click the fullscreen button at the top of the RFC. That will take you directly to the RFC page.

This is the page that you'll want to share with your co-workers when talking about the RFC. The URL looks something like this:

https://www.notion.so/Flower-Decapitation-Protocol-FDP-7d2f5e84cadc3c99f869a88eb4f834fe

Most of the information will be populated by default: Created, Modified, Author, Status, ID. The Title you already entered before opening the RFC. Click in the Reviewers section and choose a teammate that you would like to be a reviewer.

Below the list of data is where you can actually type in the contents of the RFC. Notion will ask if you would like to choose / create a template or enter freeform data (RFC templates will be the topic of a future post). For now just type a short message and click save. You should see something like this:

Unfortunately, with Notion there isn't an easy way to track review status in a semantic way like the other metadata fields. For example, while it's possible to list the reviewers as metadata (and therefor display it in the main database view) you can't really attach the individual reviewer's review status. For that reason you'll want to add a table at the top of the RFC to track this.

Type @table to create a table in the document. Create four columns and put labels in the first row: Reviewer, Status, Required, and Notes. This table is definitely something you'll want to add to your default RFC template if you get that far.

In the second row add an entry to experiment with. In the reviewer column type @ and it should suggest your name or the name of a teammate. Select it and move to the next column. You can type :cross or :check to easily insert a ✅ or ❌ character. In the required column you can type YES or NO. And the Notes column can contain any high level notes.

Your table might look something like this:

Of course, when it comes to adding comments and feedback to the RFC, the reviewer will want to use the Notion UI to select text and either press Ctrl + Shift + M or select the Comment option in the modal. The RFC Database list view will display the count of comments attached to an RFC.

Notion as an RFC Tracker: Pros and Cons #

There are certainly some benefits and some drawbacks to using Notion as a tool to track RFCs for your org.

First, it only really makes sense to use Notion to track RFCs if your organization is already using Notion for everything else. Notion is a complex product with a lot of features and it would be expensive overkill to adopt it just for tracking RFCs. If your organization already uses Notion then it is very easy to get folks into the habit of creating RFCs in this manner.

Some other benefits of using Notion is that it's easy to get updates when a document is modified. Assuming you're the author or a reviewer of an RFC, click the "..." menu in the upper right, then click "Notify me", then click "All updates". The reviewer should also get a notification when they're first tagged using the @ symbol. Filtering the overall list of RFCs is easy. It's also very malleable; you could add a field representing team name and filter by that. You can make templates for different types of proposals, e.g. frontend, backend, etc.

Here are some of the drawbacks to using Notion. A reviewer will need to manually set up notifications for the document so they know when it's time to review again. The reviewers list isn't semantic so it's possible to publish an RFC even if reviewers have rejected an RFC or have left comments demanding changes. It's not possible to get a list of every RFC that is blocked waiting for you to review.

RFC Hub: The Simpler Alternative to Notion for RFCs #

Using Notion for RFCs means you're building a workflow tool inside of a note-taking app. It can work but it takes hours of setup, manual review tracking, and discipline from everyone involved, and it's still not a perfect experience.

RFC Hub was built specifically for this purpose. No setup. No messy databases. No missed reviews. Just a clean, transparent approval workflow for engineering teams.

Feature	Notion	RFC Hub
Surfacing Reviewer approvals	Manual	Automatic
Publish only once approved	❌	✅
Track RFCs awaiting your review	❌	✅
Setup time	~1 hour	Instant

👉 Try RFC Hub for free and add as many teammates and make as many RFCs as you like.