diff options
author | Russell Dickenson <rdickenson@gitlab.com> | 2019-06-06 10:40:42 +0300 |
---|---|---|
committer | Achilleas Pipinellis <axil@gitlab.com> | 2019-06-06 10:40:42 +0300 |
commit | ac66b7b68f7dbbb71441555603b0c3dc64062698 (patch) | |
tree | 998fb5506f6fe03ef60645798816b190e2778d1e | |
parent | d91612ea0babde24ce9b335832b91dcb7aa50eb6 (diff) |
Edit Group's "Roadmap" for SSOT
-rw-r--r-- | doc/user/group/roadmap/index.md | 27 |
1 files changed, 25 insertions, 2 deletions
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. --> |