diff --git a/guide-for-tag-members.md b/guide-for-tag-members.md
index 5c23a66..72f0bf9 100644
--- a/guide-for-tag-members.md
+++ b/guide-for-tag-members.md
@@ -52,6 +52,23 @@ We tend to look for issues like:
 
 Design reviews are generally requested by spec authors, spec editors or group chairs.  The goal of a design review is to provide useful review feedback that aids the deisgn of the spec in question and to close the review issue once that feedback has been received and ideally acted upon.  Requestors fill in one fo the templates (early design review, design review, or dispute resolution). These are initially marked as untriaged.  TAG will triage these untriaged issues at least once a week during the regular plenary calls.  Requestors will also be asked to create an explainer, fill in answers to the privacy & security questionnaire, and indicate that they have read the Design Principles document.  The triage process involves assigning ideally 2+ people to work on the issue going forward, assigning labels as appropriate and assigning a **milestone**. In the design review repo we use milestones to indicate which week in the future we will discuss (and ideally try to resolve) this issue.  Once assigned to a milestone (week), that issue will become part of the agenda for that week and will be assigned to a breakout based on who is assigned to the issue.  During the breakout call, the issue will be discussed and progressed towards resolution.  TAG members will write feedback on the issue and review comments and feedback that have been left on the issue, leave feedback on the issues for the spec in question, etc... We will look for signals that the feedback has been received and understood and ideally acted upon.  When the members of a breakout group decide the issue can be closed, the issue is marked as "propose closed" (with a label).  We will then review during the read-outs section of the plenary call for that week and take a decision to close and what resolution label to mark it with (e.g. resolution: satisfied).  One of the owners of the issue will generally write a closing comment and close the issue.  During this process it may sometimes be necessary to have more detailed discussions with the requestors of the review - e.g. by inviting them to a breakout.  
 
+#### Fast Track
+
+Optionally, when a design review comes in, a TAG member may mark it as 
+[Fast track?](https://github.com/w3ctag/design-reviews/issues?q=is%3Aissue+label%3A%22Fast+track%3F%22+) and alert other TAG members. Fast track reviews are reviews
+ that would be proposed to not take up call time. It’s up to the TAG member
+proposing fast track status to indicate what outcome they think the
+review should have and why it should be fast tracked. E.g. “This doesn’t need a review. It’s a small
+change to a spec we’ve already reviewed with no architectural issues.
+Suggested outcome: Resolution: Satisfied”. They should also add
+themselves to the issue and add a “Fast track?” label. If it gets at least 
+2 indications of support (e.g. thumbs up on Slack) (over 1 week from the
+time it has been proposed) from any other TAG members then it can be
+closed. It’s up to whoever proposed this for fast track to close it and to
+write a brief closing note into the issue, summarizing the reason it can be 
+closed, and label it appropriately. If other TAG members object over the 2
+day period, then it goes into the regular review cycle
+
 ### Findings
 
 When we want to make a statement on a particular topical issue, or a trend that we see, we produce a finding.