Make unordered lists conform to styleguidedocs/fix-unordered-list-style

- Also makes other minor Markdown fixes that were near the main fixes.

15 files changed, 86 insertions, 79 deletions

diff --git a/doc/user/admin_area/settings/usage_statistics.md b/doc/user/admin_area/settings/usage_statistics.md
index bd0155dc712..e165a120162 100644
--- a/doc/user/admin_area/settings/usage_statistics.md
+++ b/doc/user/admin_area/settings/usage_statistics.md
@@ -12,9 +12,9 @@ If enabled, version check will inform you if a new version is available and the
 importance of it through a status. This is shown on the help page (i.e. `/help`)
 for all signed in users, and on the admin pages. The statuses are:
 
-* Green: You are running the latest version of GitLab.
-* Orange: An updated version of GitLab is available.
-* Red: The version of GitLab you are running is vulnerable. You should install
+- Green: You are running the latest version of GitLab.
+- Orange: An updated version of GitLab is available.
+- Red: The version of GitLab you are running is vulnerable. You should install
   the latest version with security fixes as soon as possible.
 
 ![Orange version check example](img/update-available.png)
diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md
index e14e716a5eb..68a0f1a5837 100644
--- a/doc/user/gitlab_com/index.md
+++ b/doc/user/gitlab_com/index.md
@@ -281,12 +281,14 @@ of proposed changes can be found at
 GitLab.com adjusts the memory limits for the [unicorn-worker-killer][unicorn-worker-killer] gem.
 
 Base default:
-* `memory_limit_min` = 750MiB
-* `memory_limit_max` = 1024MiB
+
+- `memory_limit_min` = 750MiB
+- `memory_limit_max` = 1024MiB
 
 Web front-ends:
-* `memory_limit_min` = 1024MiB
-* `memory_limit_max` = 1280MiB
+
+- `memory_limit_min` = 1024MiB
+- `memory_limit_max` = 1280MiB
 
 ## GitLab.com at scale
 
diff --git a/doc/user/group/subgroups/index.md b/doc/user/group/subgroups/index.md
index 943b0c693c0..4d56b33f684 100644
--- a/doc/user/group/subgroups/index.md
+++ b/doc/user/group/subgroups/index.md
@@ -21,8 +21,8 @@ Nested groups are only supported when you use PostgreSQL. Supporting nested
 groups on MySQL in an efficient way is not possible due to MySQL's limitations.
 See the following links for more information:
 
-* <https://gitlab.com/gitlab-org/gitlab-ce/issues/30472>
-* <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10885>
+- <https://gitlab.com/gitlab-org/gitlab-ce/issues/30472>
+- <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10885>
 
 ## Overview
 
diff --git a/doc/user/instance_statistics/user_cohorts.md b/doc/user/instance_statistics/user_cohorts.md
index 70d5912dc4e..f52f24ef5f7 100644
--- a/doc/user/instance_statistics/user_cohorts.md
+++ b/doc/user/instance_statistics/user_cohorts.md
@@ -23,5 +23,5 @@ the month, but who have never actually had any activity in the instance.
 
 How do we measure the activity of users? GitLab considers a user active if:
 
-* the user signs in
-* the user has Git activity (whether push or pull).
+- The user signs in.
+- The user has Git activity (whether push or pull).
diff --git a/doc/user/profile/account/two_factor_authentication.md b/doc/user/profile/account/two_factor_authentication.md
index 76f7e869ff7..83bc79925e1 100644
--- a/doc/user/profile/account/two_factor_authentication.md
+++ b/doc/user/profile/account/two_factor_authentication.md
@@ -43,8 +43,8 @@ or a U2F device.
 1. Install a compatible application. We recommend [Google Authenticator]
 \(proprietary\) or [FreeOTP] \(open source\).
 1. In the application, add a new entry in one of two ways:
-    * Scan the code with your phone's camera to add the entry automatically.
-    * Enter the details provided to add the entry manually.
+    - Scan the code with your phone's camera to add the entry automatically.
+    - Enter the details provided to add the entry manually.
 
 **In GitLab:**
 
@@ -106,7 +106,7 @@ Enter the pin from your one time password authenticator's application or a recov
 
 ### Log in via U2F device
 
-1. Click **Login via U2F Device**
+1. Click **Login via U2F Device**.
 1. A light will start blinking on your device. Activate it by pressing its button.
 
 You will see a message indicating that your device responded to the authentication request.
@@ -135,9 +135,9 @@ authenticate with Git over HTTPS on the command line or when using
 To disable two-factor authentication on your account (for example, if you
 have lost your code generation device) you can:
 
-* [Use a saved recovery code](#use-a-saved-recovery-code)
-* [Generate new recovery codes using SSH](#generate-new-recovery-codes-using-ssh)
-* [Ask a GitLab administrator to disable two-factor authentication on your account](#ask-a-gitlab-administrator-to-disable-two-factor-authentication-on-your-account)
+- [Use a saved recovery code](#use-a-saved-recovery-code).
+- [Generate new recovery codes using SSH](#generate-new-recovery-codes-using-ssh).
+- [Ask a GitLab administrator to disable two-factor authentication on your account](#ask-a-gitlab-administrator-to-disable-two-factor-authentication-on-your-account).
 
 ### Use a saved recovery code
 
diff --git a/doc/user/project/container_registry.md b/doc/user/project/container_registry.md
index cac64fc0cb6..eb9e1cd85cd 100644
--- a/doc/user/project/container_registry.md
+++ b/doc/user/project/container_registry.md
@@ -283,9 +283,9 @@ In the example above, we see the following trace on the mitmproxy window:
 
 The above image shows:
 
-* The initial PUT requests went through fine with a 201 status code.
-* The 201 redirected the client to the S3 bucket.
-* The HEAD request to the AWS bucket reported a 403 Unauthorized.
+- The initial PUT requests went through fine with a 201 status code.
+- The 201 redirected the client to the S3 bucket.
+- The HEAD request to the AWS bucket reported a 403 Unauthorized.
 
 What does this mean? This strongly suggests that the S3 user does not have the right
 [permissions to perform a HEAD request](http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectHEAD.html).
diff --git a/doc/user/project/import/github.md b/doc/user/project/import/github.md
index 42da2210fab..b36373b4830 100644
--- a/doc/user/project/import/github.md
+++ b/doc/user/project/import/github.md
@@ -18,16 +18,16 @@ GitHub without the constraints of a Sidekiq worker.
 
 The following aspects of a project are imported:
 
-  * Repository description (GitLab.com & 7.7+)
-  * Git repository data (GitLab.com & 7.7+)
-  * Issues (GitLab.com & 7.7+)
-  * Pull requests (GitLab.com & 8.4+)
-  * Wiki pages (GitLab.com & 8.4+)
-  * Milestones (GitLab.com & 8.7+)
-  * Labels (GitLab.com & 8.7+)
-  * Release note descriptions (GitLab.com & 8.12+)
-  * Pull request review comments (GitLab.com & 10.2+)
-  * Regular issue and pull request comments
+- Repository description (GitLab.com & 7.7+)
+- Git repository data (GitLab.com & 7.7+)
+- Issues (GitLab.com & 7.7+)
+- Pull requests (GitLab.com & 8.4+)
+- Wiki pages (GitLab.com & 8.4+)
+- Milestones (GitLab.com & 8.7+)
+- Labels (GitLab.com & 8.7+)
+- Release note descriptions (GitLab.com & 8.12+)
+- Pull request review comments (GitLab.com & 10.2+)
+- Regular issue and pull request comments
 
 References to pull requests and issues are preserved (GitLab.com & 8.7+), and
 each imported repository maintains visibility level unless that [visibility
@@ -132,8 +132,8 @@ Admin access to the GitLab server is required.
 For large projects it may take a while to import all data. To reduce the time necessary, you can increase the number of
 Sidekiq workers that process the following queues:
 
-* `github_importer`
-* `github_importer_advance_stage`
+- `github_importer`
+- `github_importer_advance_stage`
 
 For an optimal experience, it's recommended having at least 4 Sidekiq processes (each running a number of threads equal
 to the number of CPU cores) that *only* process these queues. It's also recommended that these processes run on separate
diff --git a/doc/user/project/integrations/emails_on_push.md b/doc/user/project/integrations/emails_on_push.md
index df320de7e16..61359dcaa90 100644
--- a/doc/user/project/integrations/emails_on_push.md
+++ b/doc/user/project/integrations/emails_on_push.md
@@ -10,10 +10,10 @@ In the _Recipients_ area, provide a list of emails separated by spaces or newlin
 
 The following options are available:
 
-+ **Push events** - Email will be triggered when a push event is received
-+ **Tag push events** - Email will be triggered when a tag is created and pushed
-+ **Send from committer** - Send notifications from the committer's email address if the domain is part of the domain GitLab is running on (e.g. `user@gitlab.com`).
-+ **Disable code diffs** - Don't include possibly sensitive code diffs in notification body.
+- **Push events** - Email will be triggered when a push event is received.
+- **Tag push events** - Email will be triggered when a tag is created and pushed.
+- **Send from committer** - Send notifications from the committer's email address if the domain is part of the domain GitLab is running on (e.g. `user@gitlab.com`).
+- **Disable code diffs** - Don't include possibly sensitive code diffs in notification body.
 
 | Settings | Notification |
 | --- | --- |
diff --git a/doc/user/project/integrations/jira.md b/doc/user/project/integrations/jira.md
index bc4bba40e59..754711f5919 100644
--- a/doc/user/project/integrations/jira.md
+++ b/doc/user/project/integrations/jira.md
@@ -31,7 +31,7 @@ directly from GitLab, as covered in the article
 
 Each GitLab project can be configured to connect to an entire Jira instance. That
 means one GitLab project can interact with _all_ Jira projects in that instance, once
-configured. Therefore, you will not have to explicitly associate 
+configured. Therefore, you will not have to explicitly associate
 a GitLab project with any single Jira project.
 
 If you have one Jira instance, you can pre-fill the settings page with a default
@@ -46,10 +46,12 @@ project in Jira and then enter the correct values in GitLab.
 ### Configuring Jira
 
 When connecting to **JIRA Server**, which supports basic authentication, a **username and password** are required. Check the link below and proceed to the next step:
-* [Setting up an user in JIRA server](jira_server_configuration.md)
+
+- [Setting up an user in JIRA server](jira_server_configuration.md)
 
 When connecting to **JIRA Cloud**, which supports authentication via API token, an **email and API token**, are required. Check the link below and proceed to the next step:
-* [Setting up an user in JIRA cloud](jira_cloud_configuration.md)
+
+- [Setting up an user in JIRA cloud](jira_cloud_configuration.md)
 
 ### Configuring GitLab
 
@@ -114,11 +116,11 @@ USER mentioned this issue in RESOURCE_NAME of [PROJECT_NAME|LINK_TO_COMMENT]:
 ENTITY_TITLE
 ```
 
-* `USER` A user that mentioned the issue. This is the link to the user profile in GitLab.
-* `LINK_TO_THE_COMMENT` Link to the origin of mention with a name of the entity where Jira issue was mentioned.
-* `RESOURCE_NAME` Kind of resource which referenced the issue. Can be a commit or merge request.
-* `PROJECT_NAME` GitLab project name.
-* `ENTITY_TITLE` Merge request title or commit message first line.
+- `USER` A user that mentioned the issue. This is the link to the user profile in GitLab.
+- `LINK_TO_THE_COMMENT` Link to the origin of mention with a name of the entity where Jira issue was mentioned.
+- `RESOURCE_NAME` Kind of resource which referenced the issue. Can be a commit or merge request.
+- `PROJECT_NAME` GitLab project name.
+- `ENTITY_TITLE` Merge request title or commit message first line.
 
 ![example of mentioning or closing the Jira issue](img/jira_issue_reference.png)
 
@@ -190,11 +192,11 @@ Make sure that the Jira issue is not already marked as resolved; that is,
 the Jira issue resolution field is not set. (It should not be struck through in
 Jira lists.)
 
-### CAPTCHA 
+### CAPTCHA
 
-CAPTCHA may be triggered after several consecutive failed login attempts 
+CAPTCHA may be triggered after several consecutive failed login attempts
 which may lead to a `401 unauthorized` error when testing your Jira integration.
-If CAPTCHA has been triggered, you will not be able to use Jira's REST API to 
+If CAPTCHA has been triggered, you will not be able to use Jira's REST API to
 authenticate with the Jira site. You will need to log in to your Jira instance
 and complete the CAPTCHA.
 
diff --git a/doc/user/project/integrations/prometheus.md b/doc/user/project/integrations/prometheus.md
index 5de8e66e7eb..d6ee678443f 100644
--- a/doc/user/project/integrations/prometheus.md
+++ b/doc/user/project/integrations/prometheus.md
@@ -9,8 +9,9 @@ within the GitLab interface.
 ![Environment Dashboard](img/prometheus_dashboard.png)
 
 There are two ways to set up Prometheus integration, depending on where your apps are running:
-* For deployments on Kubernetes, GitLab can automatically [deploy and manage Prometheus](#managed-prometheus-on-kubernetes)
-* For other deployment targets, simply [specify the Prometheus server](#manual-configuration-of-prometheus).
+
+- For deployments on Kubernetes, GitLab can automatically [deploy and manage Prometheus](#managed-prometheus-on-kubernetes).
+- For other deployment targets, simply [specify the Prometheus server](#manual-configuration-of-prometheus).
 
 Once enabled, GitLab will automatically detect metrics from known services in the [metric library](#monitoring-ci-cd-environments).
 
@@ -23,8 +24,8 @@ GitLab can seamlessly deploy and manage Prometheus on a [connected Kubernetes cl
 
 #### Requirements
 
-* A [connected Kubernetes cluster](../clusters/index.md)
-* Helm Tiller [installed by GitLab](../clusters/index.md#installing-applications)
+- A [connected Kubernetes cluster](../clusters/index.md)
+- Helm Tiller [installed by GitLab](../clusters/index.md#installing-applications)
 
 #### Getting started
 
@@ -42,9 +43,9 @@ Prometheus is deployed into the `gitlab-managed-apps` namespace, using the [offi
 
 The Prometheus server will [automatically detect and monitor](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3Ckubernetes_sd_config%3E) nodes, pods, and endpoints. To configure a resource to be monitored by Prometheus, simply set the following [Kubernetes annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/):
 
-* `prometheus.io/scrape` to `true` to enable monitoring of the resource.
-* `prometheus.io/port` to define the port of the metrics endpoint.
-* `prometheus.io/path` to define the path of the metrics endpoint. Defaults to `/metrics`.
+- `prometheus.io/scrape` to `true` to enable monitoring of the resource.
+- `prometheus.io/port` to define the port of the metrics endpoint.
+- `prometheus.io/path` to define the path of the metrics endpoint. Defaults to `/metrics`.
 
 CPU and Memory consumption is monitored, but requires [naming conventions](prometheus_library/kubernetes.html#specifying-the-environment) in order to determine the environment. If you are using [Auto DevOps](../../../topics/autodevops/), this is handled automatically.
 
diff --git a/doc/user/project/integrations/prometheus_library/nginx_ingress.md b/doc/user/project/integrations/prometheus_library/nginx_ingress.md
index 40ac855c74f..d5f77d622be 100644
--- a/doc/user/project/integrations/prometheus_library/nginx_ingress.md
+++ b/doc/user/project/integrations/prometheus_library/nginx_ingress.md
@@ -21,18 +21,20 @@ GitLab has support for automatically detecting and monitoring the Kubernetes NGI
 If you have deployed NGINX Ingress using GitLab's [Kubernetes cluster integration](../../clusters/index.md#installing-applications), it will [automatically be monitored](#about-managed-nginx-ingress-deployments) by Prometheus.
 
 For other deployments, there is [some configuration](#manually-setting-up-nginx-ingress-for-prometheus-monitoring) required depending on your installation:
-* NGINX Ingress should be version 0.9.0 or above, with metrics enabled
-* NGINX Ingress should be annotated for Prometheus monitoring
-* Prometheus should be configured to monitor annotated pods
+
+- NGINX Ingress should be version 0.9.0 or above, with metrics enabled
+- NGINX Ingress should be annotated for Prometheus monitoring
+- Prometheus should be configured to monitor annotated pods
 
 ### About managed NGINX Ingress deployments
 
 NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress). NGINX Ingress will be [externally reachable via the Load Balancer's IP](../../clusters/index.md#getting-the-external-ip-address).
 
 NGINX is configured for Prometheus monitoring, by setting:
-* `enable-vts-status: "true"`, to export Prometheus metrics
-* `prometheus.io/scrape: "true"`, to enable automatic discovery
-* `prometheus.io/port: "10254"`, to specify the metrics port
+
+- `enable-vts-status: "true"`, to export Prometheus metrics
+- `prometheus.io/scrape: "true"`, to enable automatic discovery
+- `prometheus.io/port: "10254"`, to specify the metrics port
 
 When used in conjunction with the GitLab deployed Prometheus service, response metrics will be automatically collected.
 
@@ -42,8 +44,8 @@ Version 0.9.0 and above of [NGINX ingress](https://github.com/kubernetes/ingress
 
 Next, the ingress needs to be annotated for Prometheus monitoring. Two new annotations need to be added:
 
-* `prometheus.io/scrape: "true"`
-* `prometheus.io/port: "10254"`
+- `prometheus.io/scrape: "true"`
+- `prometheus.io/port: "10254"`
 
 Managing these settings depends on how NGINX ingress has been deployed. If you have deployed via the [official Helm chart](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress), metrics can be enabled with `controller.stats.enabled` along with the required annotations. Alternatively it is possible edit the NGINX ingress YML directly in the [Kubernetes dashboard](https://github.com/kubernetes/dashboard).
 
diff --git a/doc/user/project/merge_requests/index.md b/doc/user/project/merge_requests/index.md
index a19989afb91..f479f9e4ef6 100644
--- a/doc/user/project/merge_requests/index.md
+++ b/doc/user/project/merge_requests/index.md
@@ -328,8 +328,8 @@ troubleshooting steps.
 
 This can occur for one of two reasons:
 
-* Sidekiq doesn't pick up the changes fast enough
-* Because of the bug described in [#41545](https://gitlab.com/gitlab-org/gitlab-ce/issues/41545)
+- Sidekiq doesn't pick up the changes fast enough
+- Because of the bug described in [#41545](https://gitlab.com/gitlab-org/gitlab-ce/issues/41545)
 
 #### Sidekiq
 
diff --git a/doc/user/project/merge_requests/squash_and_merge.md b/doc/user/project/merge_requests/squash_and_merge.md
index 2ec423dcf70..1b57331dbe7 100644
--- a/doc/user/project/merge_requests/squash_and_merge.md
+++ b/doc/user/project/merge_requests/squash_and_merge.md
@@ -18,7 +18,7 @@ Into a single commit on merge:
 
 ![A squashed commit followed by a merge commit][squashed-commit]
 
-The squashed commit's commit message is the merge request title. And note that 
+The squashed commit's commit message is the merge request title. And note that
 the squashed commit is still followed by a merge commit, as the merge
 method for this example repository uses a merge commit. Squashing also works
 with the fast-forward merge strategy, see
@@ -30,7 +30,7 @@ details.
 When working on a feature branch, you sometimes want to commit your current
 progress, but don't really care about the commit messages. Those 'work in
 progress commits' don't necessarily contain important information and as such
-you'd rather not include them in your target branch. 
+you'd rather not include them in your target branch.
 
 With squash and merge, when the merge request is ready to be merged,
 all you have to do is enable squashing before you press merge to join
@@ -56,9 +56,9 @@ This can then be overridden at the time of accepting the merge request:
 
 The squashed commit has the following metadata:
 
-* Message: the title of the merge request.
-* Author: the author of the merge request.
-* Committer: the user who initiated the squash.
+- Message: the title of the merge request.
+- Author: the author of the merge request.
+- Committer: the user who initiated the squash.
 
 ## Squash and fast-forward merge
 
diff --git a/doc/user/project/pipelines/settings.md b/doc/user/project/pipelines/settings.md
index 15eacc48dfe..88d745b0ce4 100644
--- a/doc/user/project/pipelines/settings.md
+++ b/doc/user/project/pipelines/settings.md
@@ -45,10 +45,10 @@ this filepath should be **relative** to the root.
 
 Here are some valid examples:
 
-> * .gitlab-ci.yml
-> * .my-custom-file.yml
-> * my/path/.gitlab-ci.yml
-> * my/path/.my-custom-file.yml
+- `.gitlab-ci.yml`
+- `.my-custom-file.yml`
+- `my/path/.gitlab-ci.yml`
+- `my/path/.my-custom-file.yml`
 
 ## Test coverage parsing
 
diff --git a/doc/user/search/index.md b/doc/user/search/index.md
index 78c1294346b..770cef42995 100644
--- a/doc/user/search/index.md
+++ b/doc/user/search/index.md
@@ -31,7 +31,7 @@ on the search field on the top-right of your screen:
 
 If you want to search for issues present in a specific project, navigate to
 a project's **Issues** tab, and click on the field **Search or filter results...**. It will
-display a dropdown menu, from which you can add filters per author, assignee, milestone, 
+display a dropdown menu, from which you can add filters per author, assignee, milestone,
 label, weight, and 'my-reaction' (based on your emoji votes). When done, press **Enter** on your keyboard to filter the issues.
 
 ![filter issues in a project](img/issue_search_filter.png)
@@ -54,12 +54,12 @@ Selecting **Any** does the opposite. It returns results that have a non-empty va
 
 You can filter issues and merge requests by specific terms included in titles or descriptions.
 
-* Syntax
-    * Searches look for all the words in a query, in any order. E.g.: searching
+- Syntax
+    - Searches look for all the words in a query, in any order. E.g.: searching
       issues for `display bug` will return all issues matching both those words, in any order.
-    * To find the exact term, use double quotes: `"display bug"`
-* Limitation
-    * For performance reasons, terms shorter than 3 chars are ignored. E.g.: searching
+    - To find the exact term, use double quotes: `"display bug"`
+- Limitation
+    - For performance reasons, terms shorter than 3 chars are ignored. E.g.: searching
       issues for `included in titles` is same as `included titles`
 
 ![filter issues by specific terms](img/issue_search_by_term.png)