From ac66b7b68f7dbbb71441555603b0c3dc64062698 Mon Sep 17 00:00:00 2001
From: Russell Dickenson <rdickenson@gitlab.com>
Date: Thu, 6 Jun 2019 07:40:42 +0000
Subject: Edit Group's "Roadmap" for SSOT

---
 doc/user/group/roadmap/index.md | 27 +++++++++++++++++++++++++--
 1 file changed, 25 insertions(+), 2 deletions(-)

(limited to 'doc/user/group/roadmap')

diff --git a/doc/user/group/roadmap/index.md b/doc/user/group/roadmap/index.md
index 310c4bb88d0..683c715c8d5 100644
--- a/doc/user/group/roadmap/index.md
+++ b/doc/user/group/roadmap/index.md
@@ -1,3 +1,7 @@
+---
+type: reference
+---
+
 # Roadmap **[ULTIMATE]**
 
 > Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing) 10.5.
@@ -19,13 +23,20 @@ Epics in the view can be sorted by:
 - **Start date**
 - **Due date**
 
-Each option contains a button that can toggle the order between **ascending** and **descending**. The sort option and order will be persisted to be used wherever epics are browsed including the [epics list view](../epics/index.md).
+Each option contains a button that toggles the sort order between **ascending** and **descending**. The sort option and order will be persisted when browsing Epics,
+including the [epics list view](../epics/index.md).
 
 Roadmaps can also be [visualized inside an epic](../epics/index.md#roadmap-in-epics).
 
 ## Timeline duration
 
-Starting with [GitLab Ultimate][ee] 11.0, Roadmap supports three different date ranges; Quarters, Months (Default) and Weeks.
+> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing) 11.0.
+
+Roadmap supports the following date ranges:
+
+- Quarters
+- Months (Default)
+- Weeks
 
 ### Quarters
 
@@ -62,3 +73,15 @@ and due date. If an epic doesn't have a due date, the timeline bar fades
 away towards the future. Similarly, if an epic doesn't have a start date, the
 timeline bar becomes more visible as it approaches the epic's due date on the
 timeline.
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, e.g. `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
-- 
cgit v1.2.1