Merge branch 'docs/fix-unordered-list-style-ee' into 'master'

Port from CE: Resolve Markdown unordered lists not conforming to styleguide

See merge request gitlab-org/gitlab-ee!8437

doc/administration/high_availability/redis.md

@@ -549,10 +549,10 @@ discussed in [Redis setup overview](#redis-setup-overview) and
 
 Here is a list and description of each **machine** and the assigned **IP**:
 
-* `10.0.0.1`: Redis Master + Sentinel 1
-* `10.0.0.2`: Redis Slave 1 + Sentinel 2
-* `10.0.0.3`: Redis Slave 2 + Sentinel 3
-* `10.0.0.4`: GitLab application
+- `10.0.0.1`: Redis Master + Sentinel 1
+- `10.0.0.2`: Redis Slave 1 + Sentinel 2
+- `10.0.0.3`: Redis Slave 2 + Sentinel 3
+- `10.0.0.4`: GitLab application
 
 Please note that after the initial configuration, if a failover is initiated
 by the Sentinel nodes, the Redis nodes will be reconfigured and the **Master**

doc/administration/high_availability/redis_source.md

@@ -214,10 +214,10 @@ For this example, **Sentinel 1** will be configured in the same machine as the
 
 Here is a list and description of each **machine** and the assigned **IP**:
 
-* `10.0.0.1`: Redis Master + Sentinel 1
-* `10.0.0.2`: Redis Slave 1 + Sentinel 2
-* `10.0.0.3`: Redis Slave 2 + Sentinel 3
-* `10.0.0.4`: GitLab application
+- `10.0.0.1`: Redis Master + Sentinel 1
+- `10.0.0.2`: Redis Slave 1 + Sentinel 2
+- `10.0.0.3`: Redis Slave 2 + Sentinel 3
+- `10.0.0.4`: GitLab application
 
 Please note that after the initial configuration, if a failover is initiated
 by the Sentinel nodes, the Redis nodes will be reconfigured and the **Master**

doc/administration/housekeeping.md

@@ -17,19 +17,18 @@ The housekeeping function will run a `repack` or `gc` depending on the
 
 For example in the following scenario a `git repack -d` will be executed:
 
-+ Project: pushes since gc counter (`pushes_since_gc`) = `10`
-+ Git GC period = `200`
-+ Full repack period = `50`
+- Project: pushes since gc counter (`pushes_since_gc`) = `10`
+- Git GC period = `200`
+- Full repack period = `50`
 
 When the `pushes_since_gc` value is 50 a `repack -A -d --pack-kept-objects` will run, similarly when
 the `pushes_since_gc` value is 200 a `git gc` will be run.
 
-+ `git gc` ([man page][man-gc]) runs a number of housekeeping tasks,
-such as compressing filerevisions (to reduce disk space and increase performance)
-and removing unreachable objects which may have been created from prior invocations of
-`git add`. 
-
-+ `git repack` ([man page][man-repack]) re-organize existing packs into a single, more efficient pack.
+- `git gc` ([man page][man-gc]) runs a number of housekeeping tasks,
+  such as compressing filerevisions (to reduce disk space and increase performance)
+  and removing unreachable objects which may have been created from prior invocations of
+  `git add`.
+- `git repack` ([man page][man-repack]) re-organize existing packs into a single, more efficient pack.
 
 You can find this option under your **[Project] > Edit Project**.
 
@@ -39,4 +38,4 @@ You can find this option under your **[Project] > Edit Project**.
 
 [ce-2371]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2371 "Housekeeping merge request"
 [man-gc]: https://www.kernel.org/pub/software/scm/git/docs/git-gc.html "git gc man page"
-[man-repack]: https://www.kernel.org/pub/software/scm/git/docs/git-repack.html
\ No newline at end of file
+[man-repack]: https://www.kernel.org/pub/software/scm/git/docs/git-repack.html

doc/administration/integration/terminal.md

@@ -14,17 +14,17 @@ A detailed overview of the architecture of web terminals and how they work
 can be found in [this document](https://gitlab.com/gitlab-org/gitlab-workhorse/blob/master/doc/terminal.md).
 In brief:
 
-* GitLab relies on the user to provide their own Kubernetes credentials, and to
+- GitLab relies on the user to provide their own Kubernetes credentials, and to
   appropriately label the pods they create when deploying.
-* When a user navigates to the terminal page for an environment, they are served
+- When a user navigates to the terminal page for an environment, they are served
   a JavaScript application that opens a WebSocket connection back to GitLab.
-* The WebSocket is handled in [Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse),
+- The WebSocket is handled in [Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse),
    rather than the Rails application server.
-* Workhorse queries Rails for connection details and user permissions; Rails
-  queries Kubernetes for them in the background, using [Sidekiq](../troubleshooting/sidekiq.md)
-* Workhorse acts as a proxy server between the user's browser and the Kubernetes
+- Workhorse queries Rails for connection details and user permissions. Rails
+  queries Kubernetes for them in the background using [Sidekiq](../troubleshooting/sidekiq.md).
+- Workhorse acts as a proxy server between the user's browser and the Kubernetes
   API, passing WebSocket frames between the two.
-* Workhorse regularly polls Rails, terminating the WebSocket connection if the
+- Workhorse regularly polls Rails, terminating the WebSocket connection if the
   user no longer has permission to access the terminal, or if the connection
   details have changed.
 
@@ -53,10 +53,10 @@ However, if you run a [load balancer](../high_availability/load_balancer.md) in
 front of GitLab, you may need to make some changes to your configuration. These
 guides document the necessary steps for a selection of popular reverse proxies:
 
-* [Apache](https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html)
-* [NGINX](https://www.nginx.com/blog/websocket-nginx/)
-* [HAProxy](http://blog.haproxy.com/2012/11/07/websockets-load-balancing-with-haproxy/)
-* [Varnish](https://www.varnish-cache.org/docs/4.1/users-guide/vcl-example-websockets.html)
+- [Apache](https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html)
+- [NGINX](https://www.nginx.com/blog/websocket-nginx/)
+- [HAProxy](http://blog.haproxy.com/2012/11/07/websockets-load-balancing-with-haproxy/)
+- [Varnish](https://www.varnish-cache.org/docs/4.1/users-guide/vcl-example-websockets.html)
 
 Workhorse won't let WebSocket requests through to non-WebSocket endpoints, so
 it's safe to enable support for these headers globally. If you'd rather had a
@@ -73,8 +73,8 @@ the `Connection` and `Upgrade` hop-by-hop headers in the *first* HTTP reverse
 proxy in the chain. For most users, this will be the NGINX server bundled with
 Omnibus GitLab, in which case, you need to:
 
-* Find the `nginx['proxy_set_headers']` section of your `gitlab.rb` file
-* Ensure the whole block is uncommented, and then comment out or remove the
+- Find the `nginx['proxy_set_headers']` section of your `gitlab.rb` file
+- Ensure the whole block is uncommented, and then comment out or remove the
   `Connection` and `Upgrade` lines.
 
 For your own load balancer, just reverse the configuration changes recommended

doc/administration/raketasks/check.md

@@ -52,9 +52,9 @@ and these checks will verify them against current files.
 
 Currently, integrity checks are supported for the following types of file:
 
-* CI artifacts (Available from version 10.7.0)
-* LFS objects (Available from version 10.6.0)
-* User uploads (Available from version 10.6.0)
+- CI artifacts (Available from version 10.7.0)
+- LFS objects (Available from version 10.6.0)
+- User uploads (Available from version 10.6.0)
 
 **Omnibus Installation**
 

doc/administration/repository_storage_types.md

@@ -7,8 +7,8 @@
 Legacy Storage is the storage behavior prior to version 10.0. For historical
 reasons, GitLab replicated the same mapping structure from the projects URLs:
 
-* Project's repository: `#{namespace}/#{project_name}.git`
-* Project's wiki: `#{namespace}/#{project_name}.wiki.git`
+- Project's repository: `#{namespace}/#{project_name}.git`
+- Project's wiki: `#{namespace}/#{project_name}.wiki.git`
 
 This structure made it simple to migrate from existing solutions to GitLab and
 easy for Administrators to find where the repository is stored.

doc/administration/troubleshooting/debug.md

@@ -211,5 +211,5 @@ The output in `/tmp/unicorn.txt` may help diagnose the root cause.
 
 # More information
 
-* [Debugging Stuck Ruby Processes](https://blog.newrelic.com/2013/04/29/debugging-stuck-ruby-processes-what-to-do-before-you-kill-9/)
-* [Cheatsheet of using gdb and ruby processes](gdb-stuck-ruby.txt)
+- [Debugging Stuck Ruby Processes](https://blog.newrelic.com/2013/04/29/debugging-stuck-ruby-processes-what-to-do-before-you-kill-9/)
+- [Cheatsheet of using gdb and ruby processes](gdb-stuck-ruby.txt)

doc/api/lint.md

@@ -20,7 +20,7 @@ Be sure to copy paste the exact contents of `.gitlab-ci.yml` as YAML is very pic
 
 Example responses:
 
-* Valid content:
+- Valid content:
 
     ```json
     {
@@ -29,7 +29,7 @@ Example responses:
     }
     ```
 
-* Invalid content:
+- Invalid content:
 
     ```json
     {
@@ -40,7 +40,7 @@ Example responses:
     }
     ```
 
-* Without the content attribute:
+- Without the content attribute:
 
     ```json
     {
@@ -49,4 +49,3 @@ Example responses:
     ```
 
 [ce-5953]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5953
-

doc/api/oauth2.md

 # GitLab as an OAuth2 provider
 
-This document covers using the [OAuth2](https://oauth.net/2/) protocol to allow other services access GitLab resources on user's behalf. 
+This document covers using the [OAuth2](https://oauth.net/2/) protocol to allow other services access GitLab resources on user's behalf.
 
 If you want GitLab to be an OAuth authentication service provider to sign into other services please see the [OAuth2 provider](../integration/oauth_provider.md)
 documentation.
 
-This functionality is based on [doorkeeper gem](https://github.com/doorkeeper-gem/doorkeeper). 
+This functionality is based on [doorkeeper gem](https://github.com/doorkeeper-gem/doorkeeper).
 
 ## Supported OAuth2 Flows
 
-GitLab currently supports following authorization flows: 
+GitLab currently supports following authorization flows:
 
-* *Web Application Flow* - Most secure and common type of flow, designed for the applications with secure server-side.
-* *Implicit Flow* - This flow is designed for user-agent only apps (e.g. single page web application running on GitLab Pages).
-* *Resource Owner Password Credentials Flow* - To be used **only** for securely hosted, first-party services.
+- *Web Application Flow* - Most secure and common type of flow, designed for the applications with secure server-side.
+- *Implicit Flow* - This flow is designed for user-agent only apps (e.g. single page web application running on GitLab Pages).
+- *Resource Owner Password Credentials Flow* - To be used **only** for securely hosted, first-party services.
 
 Please refer to [OAuth RFC](https://tools.ietf.org/html/rfc6749) to find out in details how all those flows work and pick the right one for your use case.
 
-Both *web application* and *implicit* flows require `application` to be registered first via `/profile/applications` page 
-in your user's account. During registration, by enabling proper scopes you can limit the range of resources which the `application` can access. Upon creation 
+Both *web application* and *implicit* flows require `application` to be registered first via `/profile/applications` page
+in your user's account. During registration, by enabling proper scopes you can limit the range of resources which the `application` can access. Upon creation
 you'll obtain `application` credentials: _Application ID_ and _Client Secret_ - **keep them secure**.
 
->**Important:** OAuth specification advises sending `state` parameter with each request to `/oauth/authorize`. We highly recommended to send a unique 
-value with each request and validate it against the one in redirect request. This is important to prevent [CSRF attacks]. The `state` param really should 
+>**Important:** OAuth specification advises sending `state` parameter with each request to `/oauth/authorize`. We highly recommended to send a unique
+value with each request and validate it against the one in redirect request. This is important to prevent [CSRF attacks]. The `state` param really should
 have been a requirement in the standard!
 
-In the following sections you will find detailed instructions on how to obtain authorization with each flow. 
+In the following sections you will find detailed instructions on how to obtain authorization with each flow.
 
-### Web Application Flow 
+### Web Application Flow
 
 Check [RFC spec](http://tools.ietf.org/html/rfc6749#section-4.1) for a detailed flow description
 
@@ -48,7 +48,7 @@ You should then use the `code` to request an access token.
 
 #### 2. Requesting access token
 
-Once you have the authorization code you can request an `access_token` using the code, to do that you can use any HTTP client. In the following example, 
+Once you have the authorization code you can request an `access_token` using the code, to do that you can use any HTTP client. In the following example,
 we are using Ruby's `rest-client`:
 
 ```
@@ -73,13 +73,13 @@ You can now make requests to the API with the access token returned.
 
 Check [RFC spec](http://tools.ietf.org/html/rfc6749#section-4.2) for a detailed flow description.
 
-Unlike the web flow, the client receives an `access token` immediately as a result of the authorization request. The flow does not use client secret 
-or authorization code because all of the application code and storage is easily accessible, therefore __secrets__ can leak easily. 
+Unlike the web flow, the client receives an `access token` immediately as a result of the authorization request. The flow does not use client secret
+or authorization code because all of the application code and storage is easily accessible, therefore __secrets__ can leak easily.
+
+>**Important:** Avoid using this flow for applications that store data outside of the GitLab instance. If you do, make sure to verify `application id`
+associated with access token before granting access to the data
+(see [/oauth/token/info](https://github.com/doorkeeper-gem/doorkeeper/wiki/API-endpoint-descriptions-and-examples#get----oauthtokeninfo)).
 
->**Important:** Avoid using this flow for applications that store data outside of the GitLab instance. If you do, make sure to verify `application id` 
-associated with access token before granting access to the data 
-(see [/oauth/token/info](https://github.com/doorkeeper-gem/doorkeeper/wiki/API-endpoint-descriptions-and-examples#get----oauthtokeninfo)). 
- 
 
 #### 1. Requesting access token
 
@@ -89,7 +89,7 @@ To request the access token, you should redirect the user to the `/oauth/authori
 https://gitlab.example.com/oauth/authorize?client_id=APP_ID&redirect_uri=REDIRECT_URI&response_type=token&state=YOUR_UNIQUE_STATE_HASH
 ```
 
-This will ask the user to approve the applications access to their account and then redirect back to the `REDIRECT_URI` you provided. The redirect 
+This will ask the user to approve the application's access to their account and then redirect back to the `REDIRECT_URI` you provided. The redirect
 will include a fragment with `access_token` as well as token details in GET parameters, for example:
 
 ```
@@ -100,7 +100,7 @@ http://myapp.com/oauth/redirect#access_token=ABCDExyz123&state=YOUR_UNIQUE_STATE
 
 Check [RFC spec](http://tools.ietf.org/html/rfc6749#section-4.3) for a detailed flow description.
 
-> **Deprecation notice:** Starting in GitLab 8.11, the Resource Owner Password Credentials has been *disabled* for users with two-factor authentication 
+> **Deprecation notice:** Starting in GitLab 8.11, the Resource Owner Password Credentials has been *disabled* for users with two-factor authentication
 turned on. These users can access the API using [personal access tokens] instead.
 
 In this flow, a token is requested in exchange for the resource owner credentials (username and password).
@@ -109,7 +109,7 @@ client is part of the device operating system or a highly privileged application
 available (such as an authorization code).
 
 >**Important:**
-Never store the users credentials and only use this grant type when your client is deployed to a trusted environment, in 99% of cases [personal access tokens] 
+Never store the user's credentials and only use this grant type when your client is deployed to a trusted environment, in 99% of cases [personal access tokens]
 are a better choice.
 
 Even though this grant type requires direct client access to the resource owner credentials, the resource owner credentials are used
@@ -148,7 +148,7 @@ puts access_token.token
 
 ##  Access GitLab API with `access token`
 
-The `access token` allows you to make requests to the API on a behalf of a user. You can pass the token either as GET parameter 
+The `access token` allows you to make requests to the API on a behalf of a user. You can pass the token either as GET parameter
 ```
 GET https://gitlab.example.com/api/v4/user?access_token=OAUTH-TOKEN
 ```
@@ -160,4 +160,4 @@ curl --header "Authorization: Bearer OAUTH-TOKEN" https://gitlab.example.com/api
 ```
 
 [personal access tokens]: ../user/profile/personal_access_tokens.md
-[CSRF attacks]: http://www.oauthsecurity.com/#user-content-authorization-code-flow
\ No newline at end of file
+[CSRF attacks]: http://www.oauthsecurity.com/#user-content-authorization-code-flow

doc/api/projects.md

@@ -7,30 +7,29 @@ This is determined by the `visibility` field in the project.
 
 Values for the project visibility level are:
 
-* `private`:
+- `private`:
   Project access must be granted explicitly for each user.
 
-* `internal`:
+- `internal`:
   The project can be cloned by any logged in user.
 
-* `public`:
+- `public`:
   The project can be accessed without any authentication.
 
 ## Project merge method
 
 There are currently three options for `merge_method` to choose from:
 
-* `merge`:
+- `merge`:
   A merge commit is created for every merge, and merging is allowed as long as there are no conflicts.
 
-* `rebase_merge`:
+- `rebase_merge`:
   A merge commit is created for every merge, but merging is only allowed if fast-forward merge is possible.
   This way you could make sure that if this merge request would build, after merging to target branch it would also build.
 
-* `ff`:
+- `ff`:
   No merge commits are created and all merges are fast-forwarded, which means that merging is only allowed if the branch could be fast-forwarded.
 
-
 ## List all projects
 
 Get a list of all visible projects across GitLab for the authenticated user.

doc/ci/pipelines.md

@@ -246,9 +246,9 @@ So each job would be represented as a `Period`, which consists of
 `Period#first` as when the job started and `Period#last` as when the
 job was finished. A simple example here would be:
 
-* A (1, 3)
-* B (2, 4)
-* C (6, 7)
+- A (1, 3)
+- B (2, 4)
+- C (6, 7)
 
 Here A begins from 1, and ends to 3. B begins from 2, and ends to 4.
 C begins from 6, and ends to 7. Visually it could be viewed as:

doc/ci/yaml/README.md

@@ -332,10 +332,10 @@ jobs are created:
 
 There are a few rules that apply to the usage of job policy:
 
-* `only` and `except` are inclusive. If both `only` and `except` are defined
+- `only` and `except` are inclusive. If both `only` and `except` are defined
    in a job specification, the ref is filtered by `only` and `except`.
-* `only` and `except` allow the use of regular expressions (using [Ruby regexp syntax](https://ruby-doc.org/core/Regexp.html)).
-* `only` and `except` allow to specify a repository path to filter jobs for
+- `only` and `except` allow the use of regular expressions (using [Ruby regexp syntax](https://ruby-doc.org/core/Regexp.html)).
+- `only` and `except` allow to specify a repository path to filter jobs for
    forks.
 
 In addition, `only` and `except` allow the use of special keywords:

doc/development/adding_database_indexes.md

@@ -113,9 +113,9 @@ the meaning of the various columns can be found at
 Because the output of this query relies on the actual usage of your database it
 may be affected by factors such as (but not limited to):
 
-* Certain queries never being executed, thus not being able to use certain
+- Certain queries never being executed, thus not being able to use certain
   indexes.
-* Certain tables having little data, resulting in PostgreSQL using sequence
+- Certain tables having little data, resulting in PostgreSQL using sequence
   scans instead of index scans.
 
 In other words, this data is only reliable for a frequently used database with

doc/development/background_migrations.md

@@ -25,9 +25,9 @@ should only be used for data migrations.
 
 Some examples where background migrations can be useful:
 
-* Migrating events from one table to multiple separate tables.
-* Populating one column based on JSON stored in another column.
-* Migrating data that depends on the output of external services (e.g. an API).
+- Migrating events from one table to multiple separate tables.
+- Populating one column based on JSON stored in another column.
+- Migrating data that depends on the output of external services (e.g. an API).
 
 ## Isolation
 

doc/development/contributing/index.md

@@ -97,28 +97,28 @@ When your code contains more than 500 changes, any major breaking changes, or an
 
 This [documentation](issue_workflow.md) outlines the current issue process.
 
-* [Type labels](issue_workflow.md#type-labels)
-* [Subject labels](issue_workflow.md#subject-labels)
-* [Team labels](issue_workflow.md#team-labels)
-* [Release Scoping labels](issue_workflow.md#release-scoping-labels)
-* [Priority labels](issue_workflow.md#priority-labels)
-* [Severity labels](issue_workflow.md#severity-labels)
-* [Label for community contributors](issue_workflow.md#label-for-community-contributors)
-* [Issue triaging](issue_workflow.md#issue-triaging)
-* [Feature proposals](issue_workflow.md#feature-proposals)
-* [Issue tracker guidelines](issue_workflow.md#issue-tracker-guidelines)
-* [Issue weight](issue_workflow.md#issue-weight)
-* [Regression issues](issue_workflow.md#regression-issues)
-* [Technical and UX debt](issue_workflow.md#technical-and-ux-debt)
-* [Stewardship](issue_workflow.md#stewardship)
+- [Type labels](issue_workflow.md#type-labels)
+- [Subject labels](issue_workflow.md#subject-labels)
+- [Team labels](issue_workflow.md#team-labels)
+- [Release Scoping labels](issue_workflow.md#release-scoping-labels)
+- [Priority labels](issue_workflow.md#priority-labels)
+- [Severity labels](issue_workflow.md#severity-labels)
+- [Label for community contributors](issue_workflow.md#label-for-community-contributors)
+- [Issue triaging](issue_workflow.md#issue-triaging)
+- [Feature proposals](issue_workflow.md#feature-proposals)
+- [Issue tracker guidelines](issue_workflow.md#issue-tracker-guidelines)
+- [Issue weight](issue_workflow.md#issue-weight)
+- [Regression issues](issue_workflow.md#regression-issues)
+- [Technical and UX debt](issue_workflow.md#technical-and-ux-debt)
+- [Stewardship](issue_workflow.md#stewardship)
 
 ## Merge requests
 
 This [documentation](merge_request_workflow.md) outlines the current merge request process.
 
-* [Merge request guidelines](merge_request_workflow.md#merge-request-guidelines)
-* [Contribution acceptance criteria](merge_request_workflow.md#contribution-acceptance-criteria)
-* [Definition of done](merge_request_workflow.md#definition-of-done)
+- [Merge request guidelines](merge_request_workflow.md#merge-request-guidelines)
+- [Contribution acceptance criteria](merge_request_workflow.md#contribution-acceptance-criteria)
+- [Definition of done](merge_request_workflow.md#definition-of-done)
 
 ## Style guides
 

doc/development/fe_guide/components.md

 # Components
 
 ## Contents
-* [Dropdowns](#dropdowns)
-* [Modals](#modals)
+
+- [Dropdowns](#dropdowns)
+- [Modals](#modals)
 
 ## Dropdowns
 
 See also the [corresponding UX guide](https://design.gitlab.com/#/components/dropdowns).
 
 ### How to style a bootstrap dropdown
+
 1. Use the HTML structure provided by the [docs][bootstrap-dropdowns]
 1. Add a specific class to the top level `.dropdown` element
 
-
     ```Haml
     .dropdown.my-dropdown
       %button{ type: 'button', data: { toggle: 'dropdown' }, 'aria-haspopup': true, 'aria-expanded': false }

doc/development/fe_guide/droplab/droplab.md

@@ -177,28 +177,28 @@ droplab.init().addData('trigger', [{
 
 DropLab adds some CSS classes to help lower the barrier to integration.
 
-For example,
+For example:
 
-* The `droplab-item-selected` css class is added to items that have been selected
-either by a mouse click or by enter key selection.
-* The `droplab-item-active` css class is added to items that have been selected
-using arrow key navigation.
-* You can add the `droplab-item-ignore` css class to any item that you do not want to be selectable. For example,
-an `<li class="divider"></li>` list divider element that should not be interactive.
+- The `droplab-item-selected` css class is added to items that have been selected
+  either by a mouse click or by enter key selection.
+- The `droplab-item-active` css class is added to items that have been selected
+  using arrow key navigation.
+- You can add the `droplab-item-ignore` css class to any item that you do not want to be selectable. For example,
+  an `<li class="divider"></li>` list divider element that should not be interactive.
 
 ## Internal events
 
 DropLab uses some custom events to help lower the barrier to integration.
 
-For example,
+For example:
 
-* The `click.dl` event is fired when an `li` list item has been clicked. It is also
-fired when a list item has been selected with the keyboard. It is also fired when a
-`HookButton` button is clicked (a registered `button` tag or `a` tag trigger).
-* The `input.dl` event is fired when a `HookInput` (a registered `input` tag trigger) triggers an `input` event.
-* The `mousedown.dl` event is fired when a `HookInput` triggers a `mousedown` event.
-* The `keyup.dl` event is fired when a `HookInput` triggers a `keyup` event.
-* The `keydown.dl` event is fired when a `HookInput` triggers a `keydown` event.
+- The `click.dl` event is fired when an `li` list item has been clicked. It is also
+  fired when a list item has been selected with the keyboard. It is also fired when a
+  `HookButton` button is clicked (a registered `button` tag or `a` tag trigger).
+- The `input.dl` event is fired when a `HookInput` (a registered `input` tag trigger) triggers an `input` event.
+- The `mousedown.dl` event is fired when a `HookInput` triggers a `mousedown` event.
+- The `keyup.dl` event is fired when a `HookInput` triggers a `keyup` event.
+- The `keydown.dl` event is fired when a `HookInput` triggers a `keydown` event.
 
 These custom events add a `detail` object to the vanilla `Event` object that provides some potentially useful data.
 
@@ -233,9 +233,9 @@ droplab.init(trigger, list, [droplabAjax], {
 
 ### Documentation
 
-* [Ajax plugin](plugins/ajax.md)
-* [Filter plugin](plugins/filter.md)
-* [InputSetter plugin](plugins/input_setter.md)
+- [Ajax plugin](plugins/ajax.md)
+- [Filter plugin](plugins/filter.md)
+- [InputSetter plugin](plugins/input_setter.md)
 
 ### Development
 

doc/development/fe_guide/droplab/plugins/ajax.md

@@ -8,10 +8,10 @@ Add the `Ajax` object to the plugins array of a `DropLab.prototype.init` or `Dro
 
 `Ajax` requires 2 config values, the `endpoint` and `method`.
 
-* `endpoint` should be a URL to the request endpoint.
-* `method` should be `setData` or `addData`.
-* `setData` completely replaces the dropdown with the response data.
-* `addData` appends the response data to the current dropdown list.
+- `endpoint` should be a URL to the request endpoint.
+- `method` should be `setData` or `addData`.
+- `setData` completely replaces the dropdown with the response data.
+- `addData` appends the response data to the current dropdown list.
 
 ```html
 <a href="#" id="trigger" data-dropdown-trigger="#list">Toggle</a>

doc/development/fe_guide/droplab/plugins/filter.md

@@ -7,8 +7,8 @@ to the dropdown using a simple fuzzy string search of an input value.
 
 Add the `Filter` object to the plugins array of a `DropLab.prototype.init` or `DropLab.prototype.addHook` call.
 
-* `Filter` requires a config value for `template`.
-* `template` should be the key of the objects within your data array that you want to compare
+- `Filter` requires a config value for `template`.
+- `template` should be the key of the objects within your data array that you want to compare
 to the user input string, for filtering.
 
 ```html

doc/development/fe_guide/droplab/plugins/input_setter.md

@@ -6,9 +6,9 @@
 
 Add the `InputSetter` object to the plugins array of a `DropLab.prototype.init` or `DropLab.prototype.addHook` call.
 
-* `InputSetter` requires a config value for `input` and `valueAttribute`.
-* `input` should be the DOM element that you want to manipulate.
-* `valueAttribute` should be a string that is the name of an attribute on your list items that is used to get the value
+- `InputSetter` requires a config value for `input` and `valueAttribute`.
+- `input` should be the DOM element that you want to manipulate.
+- `valueAttribute` should be a string that is the name of an attribute on your list items that is used to get the value
 to update the `input` element with.
 
 You can also set the `InputSetter` config to an array of objects, which will allow you to update multiple elements.

doc/development/fe_guide/index.md

@@ -118,7 +118,7 @@ The [externalization part of the guide](../i18n/externalization.md) explains the
 ## [DropLab](droplab/droplab.md)
 Our internal `DropLab` dropdown library.
 
-* [DropLab](droplab/droplab.md)
-* [Ajax plugin](droplab/plugins/ajax.md)
-* [Filter plugin](droplab/plugins/filter.md)
-* [InputSetter plugin](droplab/plugins/input_setter.md)
+- [DropLab](droplab/droplab.md)
+- [Ajax plugin](droplab/plugins/ajax.md)
+- [Filter plugin](droplab/plugins/filter.md)
+- [InputSetter plugin](droplab/plugins/input_setter.md)

doc/development/fe_guide/performance.md

@@ -29,8 +29,8 @@ To improve the time to first render we are using lazy loading for images. This w
 the actual image source on the `data-src` attribute. After the HTML is rendered and JavaScript is loaded,
 the value of `data-src` will be moved to `src` automatically if the image is in the current viewport.
 
-*  Prepare images in HTML for lazy loading by renaming the `src` attribute to `data-src` AND adding the class `lazy`
-*  If you are using the Rails `image_tag` helper, all images will be lazy-loaded by default unless `lazy: false` is provided.
+-  Prepare images in HTML for lazy loading by renaming the `src` attribute to `data-src` AND adding the class `lazy`.
+-  If you are using the Rails `image_tag` helper, all images will be lazy-loaded by default unless `lazy: false` is provided.
 
 If you are asynchronously adding content which contains lazy images then you need to call the function
 `gl.lazyLoader.searchLazyImages()` which will search for lazy images and load them if needed.

doc/development/file_storage.md

@@ -4,15 +4,15 @@ We use the [CarrierWave] gem to handle file upload, store and retrieval.
 
 There are many places where file uploading is used, according to contexts:
 
-* System
+- System
   - Instance Logo (logo visible in sign in/sign up pages)
   - Header Logo (one displayed in the navigation bar)
-* Group
+- Group
   - Group avatars
-* User
+- User
   - User avatars
   - User snippet attachments
-* Project
+- Project
   - Project avatars
   - Issues/MR/Notes Markdown attachments
   - Issues/MR/Notes Legacy Markdown attachments
@@ -52,7 +52,7 @@ hash of the project ID instead, if project migrates to the new approach (introdu
 
 ### Path segments
 
-Files are stored at multiple locations and use different path schemes. 
+Files are stored at multiple locations and use different path schemes.
 All the `GitlabUploader` derived classes should comply with this path segment schema:
 
 ```
@@ -61,7 +61,7 @@ All the `GitlabUploader` derived classes should comply with this path segment sc
 | `<gitlab_root>/public/` | `uploads/-/system/`       | `user/avatar/:id/`                | `:filename`                      |
 | ----------------------- + ------------------------- + --------------------------------- + -------------------------------- |
 | `CarrierWave.root`      | `GitlabUploader.base_dir` | `GitlabUploader#dynamic_segment`  | `CarrierWave::Uploader#filename` |
-|                         | `CarrierWave::Uploader#store_dir`                             |                                  | 
+|                         | `CarrierWave::Uploader#store_dir`                             |                                  |
 
 |   FileUploader
 | ----------------------- + ------------------------- + --------------------------------- + -------------------------------- |
@@ -69,7 +69,7 @@ All the `GitlabUploader` derived classes should comply with this path segment sc
 | `<gitlab_root>/shared/` | `snippets/`               | `:secret/`                        | `:filename`                      |
 | ----------------------- + ------------------------- + --------------------------------- + -------------------------------- |
 | `CarrierWave.root`      | `GitlabUploader.base_dir` | `GitlabUploader#dynamic_segment`  | `CarrierWave::Uploader#filename` |
-|                         | `CarrierWave::Uploader#store_dir`                             |                                  | 
+|                         | `CarrierWave::Uploader#store_dir`                             |                                  |
 |                         |                           | `FileUploader#upload_path                                            |
 
 |   ObjectStore::Concern (store = remote)
@@ -77,7 +77,7 @@ All the `GitlabUploader` derived classes should comply with this path segment sc
 | `<bucket_name>`         | <ignored>                 | `user/avatar/:id/`                  | `:filename`                      |
 | ----------------------- + ------------------------- + ----------------------------------- + -------------------------------- |
 | `#fog_dir`              | `GitlabUploader.base_dir` | `GitlabUploader#dynamic_segment`    | `CarrierWave::Uploader#filename` |
-|                         |                           | `ObjectStorage::Concern#store_dir`  |                                  | 
+|                         |                           | `ObjectStorage::Concern#store_dir`  |                                  |
 |                         |                           | `ObjectStorage::Concern#upload_path                                    |
 ```
 

doc/development/github_importer.md

@@ -13,20 +13,20 @@ or Rake tasks. The parallel importer on the other hand uses Sidekiq.
 
 ## Requirements
 
-* GitLab CE 10.2.0 or newer.
-* Sidekiq workers that process the `github_importer` and
+- GitLab CE 10.2.0 or newer.
+- Sidekiq workers that process the `github_importer` and
   `github_importer_advance_stage` queues (this is enabled by default).
-* Octokit (used for interacting with the GitHub API)
+- Octokit (used for interacting with the GitHub API).
 
 ## Code structure
 
 The importer's codebase is broken up into the following directories:
 
-* `lib/gitlab/github_import`: this directory contains most of the code such as
+- `lib/gitlab/github_import`: this directory contains most of the code such as
   the classes used for importing resources.
-* `app/workers/gitlab/github_import`: this directory contains the Sidekiq
+- `app/workers/gitlab/github_import`: this directory contains the Sidekiq
   workers.
-* `app/workers/concerns/gitlab/github_import`: this directory contains a few
+- `app/workers/concerns/gitlab/github_import`: this directory contains a few
   modules reused by the various Sidekiq workers.
 
 ## Architecture overview
@@ -188,8 +188,8 @@ projects get imported the fewer GitHub API calls will be needed.
 
 The code for this resides in:
 
-* `lib/gitlab/github_import/user_finder.rb`
-* `lib/gitlab/github_import/caching.rb`
+- `lib/gitlab/github_import/user_finder.rb`
+- `lib/gitlab/github_import/caching.rb`
 
 ## Mapping labels and milestones
 
@@ -204,6 +204,6 @@ project that is being imported.
 
 The code for this resides in:
 
-* `lib/gitlab/github_import/label_finder.rb`
-* `lib/gitlab/github_import/milestone_finder.rb`
-* `lib/gitlab/github_import/caching.rb`
+- `lib/gitlab/github_import/label_finder.rb`
+- `lib/gitlab/github_import/milestone_finder.rb`
+- `lib/gitlab/github_import/caching.rb`

doc/development/gotchas.md

@@ -96,8 +96,8 @@ end
 
 ### Why
 
-* Because it is not isolated therefore it might be broken at times.
-* Because it doesn't work whenever the method we want to stub was defined
+- Because it is not isolated therefore it might be broken at times.
+- Because it doesn't work whenever the method we want to stub was defined
   in a prepended module, which is very likely the case in EE. We could see
   error like this:
 

doc/development/instrumentation.md

@@ -11,12 +11,12 @@ Instrumenting methods is done by using the `Gitlab::Metrics::Instrumentation`
 module. This module offers a few different methods that can be used to
 instrument code:
 
-* `instrument_method`: instruments a single class method.
-* `instrument_instance_method`: instruments a single instance method.
-* `instrument_class_hierarchy`: given a Class this method will recursively
+- `instrument_method`: instruments a single class method.
+- `instrument_instance_method`: instruments a single instance method.
+- `instrument_class_hierarchy`: given a Class this method will recursively
   instrument all sub-classes (both class and instance methods).
-* `instrument_methods`: instruments all public and private class methods of a Module.
-* `instrument_instance_methods`: instruments all public and private instance methods of a
+- `instrument_methods`: instruments all public and private class methods of a Module.
+- `instrument_instance_methods`: instruments all public and private instance methods of a
   Module.
 
 To remove the need for typing the full `Gitlab::Metrics::Instrumentation`

doc/development/merge_request_performance_guidelines.md

@@ -9,8 +9,8 @@ To measure the impact of a merge request you can use
 [Sherlock](profiling.md#sherlock). It's also highly recommended that you read
 the following guides:
 
-* [Performance Guidelines](performance.md)
-* [What requires downtime?](what_requires_downtime.md)
+- [Performance Guidelines](performance.md)
+- [What requires downtime?](what_requires_downtime.md)
 
 ## Impact Analysis
 

doc/development/migration_style_guide.md

@@ -40,7 +40,7 @@ migrations _unless_ schema changes are absolutely required to solve a problem.
 ## What Requires Downtime?
 
 The document ["What Requires Downtime?"](what_requires_downtime.md) specifies
-various database operations, such as 
+various database operations, such as
 
 - [adding, dropping, and renaming columns](what_requires_downtime.md#adding-columns)
 - [changing column constraints and types](what_requires_downtime.md#changing-column-constraints)
@@ -59,9 +59,9 @@ the migrations that _do_ require downtime.
 To tag a migration, add the following two constants to the migration class'
 body:
 
-* `DOWNTIME`: a boolean that when set to `true` indicates the migration requires
+- `DOWNTIME`: a boolean that when set to `true` indicates the migration requires
   downtime.
-* `DOWNTIME_REASON`: a String containing the reason for the migration requiring
+- `DOWNTIME_REASON`: a String containing the reason for the migration requiring
   downtime. This constant **must** be set when `DOWNTIME` is set to `true`.
 
 For example:
@@ -318,8 +318,8 @@ end
 
 Instead of using these methods one should use the following methods to store timestamps with timezones:
 
-* `add_timestamps_with_timezone`
-* `timestamps_with_timezone`
+- `add_timestamps_with_timezone`
+- `timestamps_with_timezone`
 
 This ensures all timestamps have a time zone specified. This in turn means existing timestamps won't
 suddenly use a different timezone when the system's timezone changes. It also makes it very clear which

doc/development/new_fe_guide/development/components.md

@@ -6,16 +6,16 @@ We have a lot of graphing libraries in our codebase to render graphs. In an effo
 
 We chose D3 as our library going forward because of the following features:
 
-* [Tree shaking webpack capabilities.](https://github.com/d3/d3/blob/master/CHANGES.md#changes-in-d3-40)
-* [Compatible with vue.js as well as vanilla javascript.](https://github.com/d3/d3/blob/master/CHANGES.md#changes-in-d3-40)
+- [Tree shaking webpack capabilities](https://github.com/d3/d3/blob/master/CHANGES.md#changes-in-d3-40).
+- [Compatible with vue.js as well as vanilla javascript](https://github.com/d3/d3/blob/master/CHANGES.md#changes-in-d3-40).
 
 D3 is very popular across many projects outside of GitLab:
 
-* [The New York Times](https://archive.nytimes.com/www.nytimes.com/interactive/2012/02/13/us/politics/2013-budget-proposal-graphic.html)
-* [plot.ly](https://plot.ly/)
-* [Droptask](https://www.droptask.com/)
+- [The New York Times](https://archive.nytimes.com/www.nytimes.com/interactive/2012/02/13/us/politics/2013-budget-proposal-graphic.html)
+- [plot.ly](https://plot.ly/)
+- [Droptask](https://www.droptask.com/)
 
 Within GitLab, D3 has been used for the following notable features
 
-* [Prometheus graphs](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html)
-* Contribution calendars
+- [Prometheus graphs](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html)
+- Contribution calendars

doc/development/new_fe_guide/development/performance.md

@@ -7,10 +7,10 @@ We have a performance dashboard available in one of our [grafana instances](http
 These pages can be found inside a text file in the gitlab-build-images [repository](https://gitlab.com/gitlab-org/gitlab-build-images) called [gitlab.txt](https://gitlab.com/gitlab-org/gitlab-build-images/blob/master/scripts/gitlab.txt)
 Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing urls of pages from this text file. Please have a [frontend monitoring expert](https://about.gitlab.com/team) review your changes before assigning to a maintainer of the `gitlab-build-images` project. The changes will go live on the next scheduled run after the changes are merged into `master`.
 
-There are 3 recommended high impact metrics to review on each page
+There are 3 recommended high impact metrics to review on each page:
 
-* [First visual change](https://developers.google.com/web/tools/lighthouse/audits/first-meaningful-paint)
-* [Speed Index](https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index)
-* [Visual Complete 95%](https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index)
+- [First visual change](https://developers.google.com/web/tools/lighthouse/audits/first-meaningful-paint)
+- [Speed Index](https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index)
+- [Visual Complete 95%](https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index)
 
 For these metrics, lower numbers are better as it means that the website is more performant.

doc/development/new_fe_guide/development/testing.md

@@ -20,8 +20,8 @@ These have been removed from our codebase in May 2018 ([#23036](https://gitlab.c
 
 See also:
 
-- [old testing guide](../../testing_guide/frontend_testing.html)
-- [notes on testing Vue components](../../fe_guide/vue.html#testing-vue-components)
+- [Old testing guide](../../testing_guide/frontend_testing.html).
+- [Notes on testing Vue components](../../fe_guide/vue.html#testing-vue-components).
 
 ## Frontend unit tests
 
@@ -302,8 +302,8 @@ Check an example in [spec/javascripts/ide/stores/actions_spec.jsspec/javascripts
 
 To make mounting a Vue component easier and more readable, we have a few helpers available in `spec/helpers/vue_mount_component_helper`.
 
-* `createComponentWithStore`
-* `mountComponentWithStore`
+- `createComponentWithStore`
+- `mountComponentWithStore`
 
 Examples of usage:
 

doc/development/new_fe_guide/modules/index.md

 # Modules
 
-* [DirtySubmit](dirty_submit.md)
+- [DirtySubmit](dirty_submit.md)
 
-  Disable form submits until there are unsaved changes.
\ No newline at end of file
+  Disable form submits until there are unsaved changes.

doc/development/performance.md

@@ -23,9 +23,9 @@ The process of solving performance problems is roughly as follows:
 
 When providing timings make sure to provide:
 
-* The 95th percentile
-* The 99th percentile
-* The mean
+- The 95th percentile
+- The 99th percentile
+- The mean
 
 When providing screenshots of graphs, make sure that both the X and Y axes and
 the legend are clearly visible. If you happen to have access to GitLab.com's own
@@ -36,12 +36,12 @@ graphs/dashboards.
 
 GitLab provides built-in tools to help improve performance and availability:
 
-* [Profiling](profiling.md)
-  * [Sherlock](profiling.md#sherlock)
-* [GitLab Performance Monitoring](../administration/monitoring/performance/index.md)
-* [Request Profiling](../administration/monitoring/performance/request_profiling.md)
-* [QueryRecoder](query_recorder.md) for preventing `N+1` regressions
-* [Chaos endpoints](chaos_endpoints.md) for testing failure scenarios. Intended mainly for testing availability.
+- [Profiling](profiling.md).
+  - [Sherlock](profiling.md#sherlock).
+- [GitLab Performance Monitoring](../administration/monitoring/performance/index.md).
+- [Request Profiling](../administration/monitoring/performance/request_profiling.md).
+- [QueryRecoder](query_recorder.md) for preventing `N+1` regressions.
+- [Chaos endpoints](chaos_endpoints.md) for testing failure scenarios. Intended mainly for testing availability.
 
 GitLab employees can use GitLab.com's performance monitoring systems located at
 <https://dashboards.gitlab.net>, this requires you to log in using your
@@ -269,11 +269,11 @@ piece of code is worth optimizing. The only two things you can do are:
 
 Some examples of changes that aren't really important/worth the effort:
 
-* Replacing double quotes with single quotes.
-* Replacing usage of Array with Set when the list of values is very small.
-* Replacing library A with library B when both only take up 0.1% of the total
+- Replacing double quotes with single quotes.
+- Replacing usage of Array with Set when the list of values is very small.
+- Replacing library A with library B when both only take up 0.1% of the total
   execution time.
-* Calling `freeze` on every string (see [String Freezing](#string-freezing)).
+- Calling `freeze` on every string (see [String Freezing](#string-freezing)).
 
 ## Slow Operations & Sidekiq
 

doc/development/policies.md

@@ -13,7 +13,7 @@ Permissions are broken into two parts: `conditions` and `rules`. Conditions are
 
 Conditions are defined by the `condition` method, and are given a name and a block. The block will be executed in the context of the policy object - so it can access `@user` and `@subject`, as well as call any methods defined on the policy. Note that `@user` may be nil (in the anonymous case), but `@subject` is guaranteed to be a real instance of the subject class.
 
-``` ruby
+```ruby
 class FooPolicy < BasePolicy
   condition(:is_public) do
     # @subject guaranteed to be an instance of Foo
@@ -37,7 +37,7 @@ Conditions are cached according to their scope. Scope and ordering will be cover
 
 A `rule` is a logical combination of conditions and other rules, that are configured to enable or prevent certain abilities. It is important to note that the rule configuration is static - a rule's logic cannot touch the database or know about `@user` or `@subject`. This allows us to cache only at the condition level. Rules are specified through the `rule` method, which takes a block of DSL configuration, and returns an object that responds to `#enable` or `#prevent`:
 
-``` ruby
+```ruby
 class FooPolicy < BasePolicy
   # ...
 
@@ -57,10 +57,10 @@ end
 
 Within the rule DSL, you can use:
 
-* A regular word mentions a condition by name - a rule that is in effect when that condition is truthy.
-* `~` indicates negation
-* `&` and `|` are logical combinations, also available as `all?(...)` and `any?(...)`
-* `can?(:other_ability)` delegates to the rules that apply to `:other_ability`. Note that this is distinct from the instance method `can?`, which can check dynamically - this only configures a delegation to another ability.
+- A regular word mentions a condition by name - a rule that is in effect when that condition is truthy.
+- `~` indicates negation.
+- `&` and `|` are logical combinations, also available as `all?(...)` and `any?(...)`.
+- `can?(:other_ability)` delegates to the rules that apply to `:other_ability`. Note that this is distinct from the instance method `can?`, which can check dynamically - this only configures a delegation to another ability.
 
 ## Scores, Order, Performance
 
@@ -72,7 +72,7 @@ When a policy is asked whether a particular ability is allowed (`policy.allowed?
 
 Sometimes, a condition will only use data from `@user` or only from `@subject`. In this case, we want to change the scope of the caching, so that we don't recalculate conditions unnecessarily. For example, given:
 
-``` ruby
+```ruby
 class FooPolicy < BasePolicy
   condition(:expensive_condition) { @subject.expensive_query? }
 
@@ -82,7 +82,7 @@ end
 
 Naively, if we call `Ability.can?(user1, :some_ability, foo)` and `Ability.can?(user2, :some_ability, foo)`, we would have to calculate the condition twice - since they are for different users. But if we use the `scope: :subject` option:
 
-``` ruby
+```ruby
   condition(:expensive_condition, scope: :subject) { @subject.expensive_query? }
 ```
 
@@ -93,7 +93,7 @@ both user and subject (including a simple anonymous check!) your result will be
 
 Sometimes we are checking permissions for a lot of users for one subject, or a lot of subjects for one user. In this case, we want to set a *preferred scope* - i.e. tell the system that we prefer rules that can be cached on the repeated parameter. For example, in `Ability.users_that_can_read_project`:
 
-``` ruby
+```ruby
 def users_that_can_read_project(users, project)
   DeclarativePolicy.subject_scope do
     users.select { |u| allowed?(u, :read_project, project) }
@@ -105,9 +105,9 @@ This will, for example, prefer checking `project.public?` to checking `user.admi
 
 ## Delegation
 
-Delegation is the inclusion of rules from another policy, on a different subject. For example,
+Delegation is the inclusion of rules from another policy, on a different subject. For example:
 
-``` ruby
+```ruby
 class FooPolicy < BasePolicy
   delegate { @subject.project }
 end

doc/development/polymorphic_associations.md

@@ -7,9 +7,9 @@ usually works by adding two columns to a table: a target type column, and a
 target id. For example, at the time of writing we have such a setup for
 `members` with the following columns:
 
-* `source_type`: a string defining the model to use, can be either `Project` or
+- `source_type`: a string defining the model to use, can be either `Project` or
   `Namespace`.
-* `source_id`: the ID of the row to retrieve based on `source_type`. For
+- `source_id`: the ID of the row to retrieve based on `source_type`. For
   example, when `source_type` is `Project` then `source_id` will contain a
   project ID.
 
@@ -92,10 +92,10 @@ AND source_id = 4
 Instead such a table should be broken up into separate tables. For example, you
 may end up with 4 tables in this case:
 
-* project_members
-* group_members
-* pending_project_members
-* pending_group_members
+- project_members
+- group_members
+- pending_project_members
+- pending_group_members
 
 This makes querying data trivial. For example, to get the members of a group
 you'd run:

doc/development/post_deployment_migrations.md

@@ -70,6 +70,6 @@ version (which doesn't depend on the column anymore) has been deployed.
 
 Some other examples where these migrations are useful:
 
-* Cleaning up data generated due to a bug in GitLab
-* Removing tables
-* Migrating jobs from one Sidekiq queue to another
+- Cleaning up data generated due to a bug in GitLab
+- Removing tables
+- Migrating jobs from one Sidekiq queue to another

doc/development/reusing_abstractions.md

@@ -149,11 +149,11 @@ typically in JSON.
 These are class methods defined by _GitLab itself_, including the following
 methods provided by Active Record:
 
-* `find`
-* `find_by_id`
-* `delete_all`
-* `destroy`
-* `destroy_all`
+- `find`
+- `find_by_id`
+- `delete_all`
+- `destroy`
+- `destroy_all`
 
 Any other methods such as `find_by(some_column: X)` are not included, and
 instead fall under the "Active Record" abstraction.
@@ -163,10 +163,10 @@ instead fall under the "Active Record" abstraction.
 Instance methods defined on Active Record models by _GitLab itself_. Methods
 provided by Active Record are not included, except for the following methods:
 
-* `save`
-* `update`
-* `destroy`
-* `delete`
+- `save`
+- `update`
+- `destroy`
+- `delete`
 
 ### Active Record
 

doc/development/rolling_out_changes_using_feature_flags.md

@@ -10,12 +10,12 @@ disable those changes, without having to revert an entire release.
 Starting with GitLab 11.4, developers are required to use feature flags for
 non-trivial changes. Such changes include:
 
-* New features (e.g. a new merge request widget, epics, etc).
-* Complex performance improvements that may require additional testing in
+- New features (e.g. a new merge request widget, epics, etc).
+- Complex performance improvements that may require additional testing in
   production, such as rewriting complex queries.
-* Invasive changes to the user interface, such as a new navigation bar or the
+- Invasive changes to the user interface, such as a new navigation bar or the
   removal of a sidebar.
-* Adding support for importing projects from a third-party service.
+- Adding support for importing projects from a third-party service.
 
 In all cases, those working on the changes can best decide if a feature flag is
 necessary. For example, changing the color of a button doesn't need a feature

doc/development/testing_guide/frontend_testing.md

@@ -185,8 +185,8 @@ See this [section][vue-test].
 `rake karma` runs the frontend-only (JavaScript) tests.
 It consists of two subtasks:
 
-* `rake karma:fixtures` (re-)generates fixtures
-* `rake karma:tests` actually executes the tests
+- `rake karma:fixtures` (re-)generates fixtures
+- `rake karma:tests` actually executes the tests
 
 As long as the fixtures don't change, `rake karma:tests` (or `yarn karma`)
 is sufficient (and saves you some time).
@@ -243,14 +243,14 @@ supported by the PhantomJS test runner which is used for both Karma and RSpec
 tests. We polyfill some JavaScript objects for older browsers, but some
 features are still unavailable:
 
-* Array.from
-* Array.first
-* Async functions
-* Generators
-* Array destructuring
-* For..Of
-* Symbol/Symbol.iterator
-* Spread
+- Array.from
+- Array.first
+- Async functions
+- Generators
+- Array destructuring
+- For..Of
+- Symbol/Symbol.iterator
+- Spread
 
 Until these are polyfilled appropriately, they should not be used. Please
 update this list with additional unsupported features.

doc/development/understanding_explain_plans.md

@@ -625,9 +625,9 @@ This is a bit of a difficult question to answer, because the definition of "bad"
 is relative to the problem you are trying to solve. However, some patterns are
 best avoided in most cases, such as:
 
-* Sequential scans on large tables
-* Filters that remove a lot of rows
-* Performing a certain step (e.g. an index scan) that requires _a lot_ of
+- Sequential scans on large tables
+- Filters that remove a lot of rows
+- Performing a certain step (e.g. an index scan) that requires _a lot_ of
   buffers (e.g. more than 512 MB for GitLab.com).
 
 As a general guideline, aim for a query that:
@@ -650,8 +650,8 @@ different queries. The only _rule_ is that you _must always measure_ your query
 (preferably using a production-like database) using `EXPLAIN (ANALYZE, BUFFERS)`
 and related tools such as:
 
-* <https://explain.depesz.com/>
-* <http://tatiyants.com/postgres-query-plan-visualization/>
+- <https://explain.depesz.com/>
+- <http://tatiyants.com/postgres-query-plan-visualization/>
 
 GitLab employees can also use our chatops solution, available in Slack using the
 `/chatops` slash command. You can use chatops to get a query plan by running the

doc/development/utilities.md

@@ -4,7 +4,7 @@ We developed a number of utilities to ease development.
 
 ## [`MergeHash`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/utils/merge_hash.rb)
 
-* Deep merges an array of hashes:
+- Deep merges an array of hashes:
 
     ``` ruby
     Gitlab::Utils::MergeHash.merge(
@@ -31,7 +31,7 @@ We developed a number of utilities to ease development.
     ]
     ```
 
-* Extracts all keys and values from a hash into an array:
+- Extracts all keys and values from a hash into an array:
 
     ``` ruby
     Gitlab::Utils::MergeHash.crush(
@@ -47,14 +47,14 @@ We developed a number of utilities to ease development.
 
 ## [`Override`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/utils/override.rb)
 
-* This utility could help us check if a particular method would override
+- This utility could help us check if a particular method would override
   another method or not. It has the same idea of Java's `@Override` annotation
   or Scala's `override` keyword. However we only do this check when
   `ENV['STATIC_VERIFICATION']` is set to avoid production runtime overhead.
   This is useful to check:
 
-    * If we have typos in overriding methods.
-    * If we renamed the overridden methods, making original overriding methods
+    - If we have typos in overriding methods.
+    - If we renamed the overridden methods, making original overriding methods
       overrides nothing.
 
     Here's a simple example:
@@ -92,7 +92,7 @@ We developed a number of utilities to ease development.
 
 ## [`StrongMemoize`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/utils/strong_memoize.rb)
 
-* Memoize the value even if it is `nil` or `false`.
+- Memoize the value even if it is `nil` or `false`.
 
     We often do `@value ||= compute`, however this doesn't work well if
     `compute` might eventually give `nil` and we don't want to compute again.
@@ -126,7 +126,7 @@ We developed a number of utilities to ease development.
     end
     ```
 
-* Clear memoization
+- Clear memoization
 
     ``` ruby
     class Find

doc/development/verifying_database_capabilities.md

@@ -6,9 +6,9 @@ necessary to add database (version) specific behaviour.
 
 To facilitate this we have the following methods that you can use:
 
-* `Gitlab::Database.postgresql?`: returns `true` if PostgreSQL is being used
-* `Gitlab::Database.mysql?`: returns `true` if MySQL is being used
-* `Gitlab::Database.version`: returns the PostgreSQL version number as a string
+- `Gitlab::Database.postgresql?`: returns `true` if PostgreSQL is being used
+- `Gitlab::Database.mysql?`: returns `true` if MySQL is being used
+- `Gitlab::Database.version`: returns the PostgreSQL version number as a string
   in the format `X.Y.Z`. This method does not work for MySQL
 
 This allows you to write code such as:

doc/install/installation.md

@@ -431,9 +431,9 @@ GitLab Shell is an SSH access and repository management software developed speci
 
 **Note:** GitLab Shell application startup time can be greatly reduced by disabling RubyGems. This can be done in several manners:
 
-* Export `RUBYOPT=--disable-gems` environment variable for the processes
-* Compile Ruby with `configure --disable-rubygems` to disable RubyGems by default. Not recommended for system-wide Ruby.
-* Omnibus GitLab [replaces the *shebang* line of the `gitlab-shell/bin/*` scripts](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1707)
+- Export `RUBYOPT=--disable-gems` environment variable for the processes.
+- Compile Ruby with `configure --disable-rubygems` to disable RubyGems by default. Not recommended for system-wide Ruby.
+- Omnibus GitLab [replaces the *shebang* line of the `gitlab-shell/bin/*` scripts](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1707).
 
 ### Install gitlab-workhorse
 

doc/install/structure.md

@@ -9,10 +9,10 @@ This is the directory structure you will end up with following the instructions
     |       |-- gitlab-shell
     |       |-- repositories
 
-* `/home/git/.ssh` - contains openssh settings.  Specifically the `authorized_keys` file managed by gitlab-shell.
-* `/home/git/gitlab` - GitLab core software.
-* `/home/git/gitlab-shell` - Core add-on component of GitLab.  Maintains SSH cloning and other functionality.
-* `/home/git/repositories` - bare repositories for all projects organized by namespace.  This is where the git repositories which are pushed/pulled are maintained for all projects.  **This area is critical data for projects.  [Keep a backup](../raketasks/backup_restore.md)**
+- `/home/git/.ssh` - contains openssh settings.  Specifically the `authorized_keys` file managed by gitlab-shell.
+- `/home/git/gitlab` - GitLab core software.
+- `/home/git/gitlab-shell` - Core add-on component of GitLab.  Maintains SSH cloning and other functionality.
+- `/home/git/repositories` - bare repositories for all projects organized by namespace.  This is where the git repositories which are pushed/pulled are maintained for all projects.  **This area is critical data for projects.  [Keep a backup](../raketasks/backup_restore.md).**
 
 *Note: the default locations for repositories can be configured in `config/gitlab.yml` of GitLab and `config.yml` of gitlab-shell.*
 

doc/integration/gmail_action_buttons_for_gitlab.md

@@ -14,9 +14,9 @@ To get this functioning, you need to be registered with Google.
 
 Pay close attention to:
 
-* Email account used by GitLab to send notification emails needs to have "Consistent history of sending a high volume of mail from your domain (order of hundred emails a day minimum to Gmail) for a few weeks at least".
-* "A very very low rate of spam complaints from users."
-* Emails must be authenticated via DKIM or SPF
-* Before sending the final form("Gmail Schema Whitelist Request"), you must send a real email from your production server. This means that you will have to find a way to send this email from the email address you are registering. You can do this by, for example, forwarding the real email from the email address you are registering or going into the rails console on the GitLab server and triggering the email sending from there.
+- Email account used by GitLab to send notification emails needs to have "Consistent history of sending a high volume of mail from your domain (order of hundred emails a day minimum to Gmail) for a few weeks at least".
+- "A very very low rate of spam complaints from users."
+- Emails must be authenticated via DKIM or SPF.
+- Before sending the final form ("Gmail Schema Whitelist Request"), you must send a real email from your production server. This means that you will have to find a way to send this email from the email address you are registering. You can do this by, for example, forwarding the real email from the email address you are registering or going into the rails console on the GitLab server and triggering the email sending from there.
 
 You can check how it looks going through all the steps laid out in the "Registering with Google" doc in [this GitLab.com issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/1517).

doc/integration/omniauth.md

@@ -66,7 +66,7 @@ that are in common for all providers that we need to consider.
 
 To change these settings:
 
-* **For omnibus package**
+- **For omnibus package**
 
     Open the configuration file:
 
@@ -89,7 +89,7 @@ To change these settings:
     gitlab_rails['omniauth_block_auto_created_users'] = true
     ```
 
-* **For installations from source**
+- **For installations from source**
 
     Open the configuration file:
 

doc/policy/maintenance.md

@@ -15,9 +15,9 @@ GitLab follows the [Semantic Versioning](http://semver.org/) for its releases:
 
 For example, for GitLab version 10.5.7:
 
-* `10` represents major version
-* `5` represents minor version
-* `7` represents patch number
+- `10` represents major version
+- `5` represents minor version
+- `7` represents patch number
 
 ## Patch releases
 
@@ -55,13 +55,13 @@ cases you need to consider.
 It is considered safe to jump between patch versions and minor versions within
 one major version. For example, it is safe to:
 
-* Upgrade the patch version:
-  * `8.9.0` -> `8.9.7`
-  * `8.9.0` -> `8.9.1`
-  * `8.9.2` -> `8.9.6`
-* Upgrade the minor version:
-  * `8.9.4` -> `8.12.3`
-  * `9.2.3` -> `9.5.5`
+- Upgrade the patch version:
+  - `8.9.0` -> `8.9.7`
+  - `8.9.0` -> `8.9.1`
+  - `8.9.2` -> `8.9.6`
+- Upgrade the minor version:
+  - `8.9.4` -> `8.12.3`
+  - `9.2.3` -> `9.5.5`
 
 Upgrading the major version requires more attention.
 We cannot guarantee that upgrading between major versions will be seamless. As previously mentioned, major versions are reserved for backwards incompatible changes.

doc/security/crime_vulnerability.md

@@ -17,8 +17,8 @@ GitLab supports both gzip and [SPDY][ngx-spdy] and mitigates the CRIME
 vulnerability by deactivating gzip when HTTPS is enabled. You can see the
 sources of the files in question:
 
-* [Source installation NGINX file][source-nginx]
-* [Omnibus installation NGINX file][omnibus-nginx]
+- [Source installation NGINX file][source-nginx]
+- [Omnibus installation NGINX file][omnibus-nginx]
 
 Although SPDY is enabled in Omnibus installations, CRIME relies on compression
 (the 'C') and the default compression level in NGINX's SPDY module is 0
@@ -52,9 +52,9 @@ vulnerability.
 
 ### References
 
-* Nginx ["Module ngx_http_spdy_module"][ngx-spdy]
-* Tenable Network Security, Inc. ["Transport Layer Security (TLS) Protocol CRIME Vulnerability"][nessus]
-* Wikipedia contributors, ["CRIME"][wiki-crime] Wikipedia, The Free Encyclopedia
+- Nginx ["Module ngx_http_spdy_module"][ngx-spdy]
+- Tenable Network Security, Inc. ["Transport Layer Security (TLS) Protocol CRIME Vulnerability"][nessus]
+- Wikipedia contributors, ["CRIME"][wiki-crime] Wikipedia, The Free Encyclopedia
 
 [source-nginx]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/support/nginx/gitlab-ssl
 [omnibus-nginx]: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/templates/default/nginx-gitlab-http.conf.erb

doc/topics/autodevops/index.md

@@ -539,9 +539,9 @@ a helm pre-upgrade hook.
 
 For example, in a Rails application:
 
-* `DB_INITIALIZE` can be set to `cd /app && RAILS_ENV=production
+- `DB_INITIALIZE` can be set to `cd /app && RAILS_ENV=production
   bin/setup`
-* `DB_MIGRATE` can be set to `cd /app && RAILS_ENV=production bin/update`
+- `DB_MIGRATE` can be set to `cd /app && RAILS_ENV=production bin/update`
 
 NOTE: **Note:**
 The `/app` path is the directory of your project inside the docker image

doc/university/high-availability/aws/README.md

@@ -66,10 +66,10 @@ RDS instances as well.
 
 The subnets are listed with their name, AZ and CIDR block:
 
-* gitlab-public-10.0.0.0  - us-west-2a - 10.0.0.0
-* gitlab-private-10.0.1.0 - us-west-2a - 10.0.1.0
-* gitlab-public-10.0.2.0  - us-west-2b - 10.0.2.0
-* gitlab-private-10.0.3.0 - us-west-2b - 10.0.3.0
+- gitlab-public-10.0.0.0  - us-west-2a - 10.0.0.0
+- gitlab-private-10.0.1.0 - us-west-2a - 10.0.1.0
+- gitlab-public-10.0.2.0  - us-west-2b - 10.0.2.0
+- gitlab-private-10.0.3.0 - us-west-2b - 10.0.3.0
 
 ### Route Table
 
@@ -395,5 +395,5 @@ some redundancy options but it might also imply Geographic replication.
 There is a lot of ground yet to cover so have a read through these other
 resources and feel free to open an issue to request additional material.
 
-* [GitLab High Availability](http://docs.gitlab.com/ce/administration/high_availability/README.html#sts=High%20Availability)
-* [GitLab Geo](https://docs.gitlab.com/ee/administration/geo/replication/index.html)
+- [GitLab High Availability](http://docs.gitlab.com/ce/administration/high_availability/README.html#sts=High%20Availability)
+- [GitLab Geo](https://docs.gitlab.com/ee/administration/geo/replication/index.html)

doc/university/training/end-user/README.md

@@ -242,10 +242,11 @@ git push origin squash_some_bugs
 ---
 
 ### Merge Conflicts
-* Happen often
-* Learning to fix conflicts is hard
-* Practice makes perfect
-* Force push after fixing conflicts. Be careful!
+
+- Happen often
+- Learning to fix conflicts is hard
+- Practice makes perfect
+- Force push after fixing conflicts. Be careful!
 
 ---
 
@@ -306,10 +307,10 @@ Create a merge request on the GitLab web UI. You'll see a conflict warning.
 
 ### Notes
 
-* When to use `git merge` and when to use `git rebase`
-* Rebase when updating your branch with master
-* Merge when bringing changes from feature to master
-* Reference: https://www.atlassian.com/git/tutorials/merging-vs-rebasing/
+- When to use `git merge` and when to use `git rebase`
+- Rebase when updating your branch with master
+- Merge when bringing changes from feature to master
+- Reference: <https://www.atlassian.com/git/tutorials/merging-vs-rebasing/>
 
 ---
 

doc/university/training/topics/getting_started.md

@@ -8,12 +8,12 @@ comments: false
 
 ## Instantiating Repositories
 
-* Create a new repository by instantiating it through
+- Create a new repository by instantiating it through:
 
     ```bash
     git init
     ```
-* Copy an existing project by cloning the repository through
+- Copy an existing project by cloning the repository through:
 
     ```bash
     git clone <url>
@@ -23,9 +23,9 @@ comments: false
 
 ## Central Repos
 
-* To instantiate a central repository a `--bare` flag is required.
-* Bare repositories don't allow file editing or committing changes.
-* Create a bare repo with
+- To instantiate a central repository a `--bare` flag is required.
+- Bare repositories don't allow file editing or committing changes.
+- Create a bare repo with:
 
     ```bash
     git init --bare project-name.git
@@ -97,5 +97,5 @@ git log
 
 ## Note
 
-* git fetch vs pull
-* Pull is git fetch + git merge
+- git fetch vs pull
+- Pull is git fetch + git merge

doc/university/training/topics/git_add.md

@@ -10,13 +10,13 @@ comments: false
 
 Adds content to the index or staging area.
 
-* Adds a list of file
+- Adds a list of file:
 
     ```bash
     git add <files>
     ```
 
-* Adds all files including deleted ones
+- Adds all files including deleted ones:
 
     ```bash
     git add -A
@@ -26,19 +26,19 @@ Adds content to the index or staging area.
 
 ## Git add continued
 
-* Add all text files in current dir
+- Add all text files in current dir:
 
     ```bash
     git add *.txt
     ```
 
-* Add all text file in the project
+- Add all text file in the project:
 
     ```bash
     git add "*.txt*"
     ```
 
-* Adds all files in directory
+- Adds all files in directory:
 
     ```bash
     git add views/layouts/

doc/university/training/topics/git_log.md

@@ -8,19 +8,19 @@ comments: false
 
 Git log lists commit history. It allows searching and filtering.
 
-* Initiate log
+- Initiate log:
 
     ```
     git log
     ```
 
-* Retrieve set number of records:
+- Retrieve set number of records:
 
     ```
     git log -n 2
     ```
 
-* Search commits by author. Allows user name or a regular expression.
+- Search commits by author. Allows user name or a regular expression.
 
     ```
     git log --author="user_name"
@@ -28,13 +28,13 @@ Git log lists commit history. It allows searching and filtering.
 
 ----------
 
-* Search by comment message.
+- Search by comment message:
 
     ```
     git log --grep="<pattern>"
     ```
 
-* Search by date
+- Search by date:
 
     ```
     git log --since=1.month.ago --until=3.weeks.ago

doc/university/training/topics/merge_conflicts.md

@@ -68,7 +68,8 @@ git push origin conflicts_branch -f
 ----------
 
 ## Note
-* When to use 'git merge' and when to use 'git rebase'
-* Rebase when updating your branch with master
-* Merge when bringing changes from feature to master
-* Reference: https://www.atlassian.com/git/tutorials/merging-vs-rebasing/
+
+- When to use 'git merge' and when to use 'git rebase'
+- Rebase when updating your branch with master
+- Merge when bringing changes from feature to master
+- Reference: <https://www.atlassian.com/git/tutorials/merging-vs-rebasing/>

doc/university/training/topics/rollback_commits.md

@@ -8,13 +8,13 @@ comments: false
 
 ## Undo Commits
 
-* Undo last commit putting everything back into the staging area.
+- Undo last commit putting everything back into the staging area:
 
     ```
     git reset --soft HEAD^
     ```
 
-* Add files and change message with:
+- Add files and change message with:
 
     ```
     git commit --amend -m "New Message"
@@ -22,13 +22,13 @@ comments: false
 
 ----------
 
-* Undo last and remove changes
+- Undo last and remove changes:
 
     ```
     git reset --hard HEAD^
     ```
 
-* Same as last one but for two commits back
+- Same as last one but for two commits back:
 
     ```
     git reset --hard HEAD^^
@@ -73,9 +73,9 @@ git push origin master
 
 ## Note
 
-* git revert vs git reset
-* Reset removes the commit while revert removes the changes but leaves the commit
-* Revert is safer considering we can revert a revert
+- git revert vs git reset
+- Reset removes the commit while revert removes the changes but leaves the commit
+- Revert is safer considering we can revert a revert
 
 ```
 # Changed file

doc/university/training/topics/stash.md

@@ -9,7 +9,7 @@ comments: false
 We use git stash to store our changes when they are not ready to be committed
 and we need to change to a different branch.
 
-* Stash
+- Stash:
 
     ```
     git stash save
@@ -19,7 +19,7 @@ and we need to change to a different branch.
     git stash save "this is a message to display on the list"
     ```
 
-* Apply stash to keep working on it
+- Apply stash to keep working on it:
 
     ```
     git stash apply
@@ -29,7 +29,7 @@ and we need to change to a different branch.
 
 ----------
 
-* Every time we save a stash it gets stacked so by using list we can see all our
+- Every time we save a stash it gets stacked so by using list we can see all our
 stashes.
 
     ```
@@ -38,7 +38,7 @@ stashes.
     git stash list --stat
     ```
 
-* To clean our stack we need to manually remove them.
+- To clean our stack we need to manually remove them:
 
     ```
     # drop top stash
@@ -51,15 +51,14 @@ stashes.
 
 ----------
 
-* Apply and drop on one command
+- Apply and drop on one command:
 
     ```
       git stash pop
     ```
 
-* If we meet conflicts we need to either reset or commit our changes.
-
-* Conflicts through `pop` will not drop a stash afterwards.
+- If we meet conflicts we need to either reset or commit our changes.
+- Conflicts through `pop` will not drop a stash afterwards.
 
 ----------
 

doc/university/training/topics/subtree.md

@@ -4,20 +4,20 @@ comments: false
 
 # Subtree
 
-* Used when there are nested repositories.
-* Not recommended when the amount of dependencies is too large
-* For these cases we need a dependency control system
-* Command are painfully long so aliases are necessary
+- Used when there are nested repositories.
+- Not recommended when the amount of dependencies is too large.
+- For these cases we need a dependency control system.
+- Command are painfully long so aliases are necessary.
 
 ----------
 
 ## Subtree Aliases
 
-* Add: git subtree add --prefix <target-folder> <url> <branch> --squash
-* Pull: git subtree add --prefix <target-folder> <url> <branch> --squash
-* Push: git subtree add --prefix <target-folder> <url> <branch>
-* Ex: git config alias.sbp 'subtree pull --prefix st /
-  git@gitlab.com:balameb/subtree-nested-example.git master --squash'
+- Add: git subtree add --prefix <target-folder> <url> <branch> --squash.
+- Pull: git subtree add --prefix <target-folder> <url> <branch> --squash.
+- Push: git subtree add --prefix <target-folder> <url> <branch>.
+- Ex: git config alias.sbp 'subtree pull --prefix st /
+  git@gitlab.com:balameb/subtree-nested-example.git master --squash'.
 
 ----------
 

doc/university/training/topics/unstage.md

@@ -8,13 +8,13 @@ comments: false
 
 ## Unstage
 
-* To remove files from stage use reset HEAD. Where HEAD is the last commit of the current branch.
+- To remove files from stage use reset HEAD. Where HEAD is the last commit of the current branch.
 
     ```bash
     git reset HEAD <file>
     ```
 
-* This will unstage the file but maintain the modifications. To revert the file back to the state it was in before the changes we can use:
+- This will unstage the file but maintain the modifications. To revert the file back to the state it was in before the changes we can use:
 
     ```bash
     git checkout -- <file>
@@ -22,14 +22,14 @@ comments: false
 
 ----------
 
-* To remove a file from disk and repo use 'git rm' and to rm a dir use the '-r' flag.
+- To remove a file from disk and repo use 'git rm' and to rm a dir use the '-r' flag:
 
     ```
     git rm '*.txt'
     git rm -r <dirname>
     ```
 
-* If we want to remove a file from the repository but keep it on disk, say we forgot to add it to our `.gitignore` file then use `--cache`.
+- If we want to remove a file from the repository but keep it on disk, say we forgot to add it to our `.gitignore` file then use `--cache`:
 
     ```
     git rm <filename> --cache

doc/update/6.9-to-7.0.md

@@ -110,8 +110,8 @@ There are new configuration options available for gitlab.yml. View them with the
 git diff origin/6-9-stable:config/gitlab.yml.example origin/7-0-stable:config/gitlab.yml.example
 ```
 
-* HTTP setups: Make `/etc/nginx/sites-available/nginx` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-0-stable/lib/support/nginx/gitlab but with your settings.
-* HTTPS setups: Make `/etc/nginx/sites-available/nginx-ssl` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-0-stable/lib/support/nginx/gitlab-ssl but with your setting
+- HTTP setups: Make `/etc/nginx/sites-available/nginx` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-0-stable/lib/support/nginx/gitlab but with your settings.
+- HTTPS setups: Make `/etc/nginx/sites-available/nginx-ssl` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-0-stable/lib/support/nginx/gitlab-ssl but with your setting.
 
 ### 7. Start application
 

doc/update/6.x-or-7.x-to-7.14.md

@@ -180,16 +180,16 @@ TIP: to see what changed in `gitlab.yml.example` in this release use next comman
 git diff 6-0-stable:config/gitlab.yml.example 7-14-stable-ee:config/gitlab.yml.example
 ```
 
-* Make `/home/git/gitlab/config/gitlab.yml` the same as https://gitlab.com/gitlab-org/gitlab-ee/blob/7-14-stable-ee/config/gitlab.yml.example but with your settings.
-* Make `/home/git/gitlab/config/unicorn.rb` the same as https://gitlab.com/gitlab-org/gitlab-ee/blob/7-14-stable-ee/config/unicorn.rb.example but with your settings.
-* Make `/home/git/gitlab-shell/config.yml` the same as https://gitlab.com/gitlab-org/gitlab-shell/blob/v2.6.5/config.yml.example but with your settings.
-* Copy rack attack middleware config
+- Make `/home/git/gitlab/config/gitlab.yml` the same as https://gitlab.com/gitlab-org/gitlab-ee/blob/7-14-stable-ee/config/gitlab.yml.example but with your settings.
+- Make `/home/git/gitlab/config/unicorn.rb` the same as https://gitlab.com/gitlab-org/gitlab-ee/blob/7-14-stable-ee/config/unicorn.rb.example but with your settings.
+- Make `/home/git/gitlab-shell/config.yml` the same as https://gitlab.com/gitlab-org/gitlab-shell/blob/v2.6.5/config.yml.example but with your settings.
+- Copy rack attack middleware config
 
 ```bash
 sudo -u git -H cp config/initializers/rack_attack.rb.example config/initializers/rack_attack.rb
 ```
 
-* Set up logrotate
+- Set up logrotate
 
 ```bash
 sudo cp lib/support/logrotate/gitlab /etc/logrotate.d/gitlab
@@ -197,9 +197,9 @@ sudo cp lib/support/logrotate/gitlab /etc/logrotate.d/gitlab
 
 ### Change Nginx settings
 
-* HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as https://gitlab.com/gitlab-org/gitlab-ee/blob/7-14-stable-ee/lib/support/nginx/gitlab but with your settings.
-* HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as https://gitlab.com/gitlab-org/gitlab-ee/blob/7-14-stable-ee/lib/support/nginx/gitlab-ssl but with your settings.
-* A new `location /uploads/` section has been added that needs to have the same content as the existing `location @gitlab` section.
+- HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as https://gitlab.com/gitlab-org/gitlab-ee/blob/7-14-stable-ee/lib/support/nginx/gitlab but with your settings.
+- HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as https://gitlab.com/gitlab-org/gitlab-ee/blob/7-14-stable-ee/lib/support/nginx/gitlab-ssl but with your settings.
+- A new `location /uploads/` section has been added that needs to have the same content as the existing `location @gitlab` section.
 
 ### Check the version of /usr/local/bin/git
 

doc/update/7.1-to-7.2.md

@@ -94,8 +94,8 @@ There are new configuration options available for `gitlab.yml`. View them with t
 git diff 7-1-stable:config/gitlab.yml.example 7-2-stable:config/gitlab.yml.example
 ```
 
-* HTTP setups: Make `/etc/nginx/sites-available/nginx` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-0-stable/lib/support/nginx/gitlab but with your settings.
-* HTTPS setups: Make `/etc/nginx/sites-available/nginx-ssl` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-0-stable/lib/support/nginx/gitlab-ssl but with your setting
+- HTTP setups: Make `/etc/nginx/sites-available/nginx` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-0-stable/lib/support/nginx/gitlab but with your settings.
+- HTTPS setups: Make `/etc/nginx/sites-available/nginx-ssl` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-0-stable/lib/support/nginx/gitlab-ssl but with your setting.
 
 Update rack attack middleware config
 

doc/update/7.2-to-7.3.md

@@ -108,8 +108,8 @@ git diff origin/7-2-stable:config/gitlab.yml.example origin/7-3-stable:config/gi
 sudo -u git -H sed -i 's/:backlog => 64/:backlog => 1024/' config/unicorn.rb
 ```
 
-* HTTP setups: Make `/etc/nginx/sites-available/nginx` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-3-stable/lib/support/nginx/gitlab but with your settings.
-* HTTPS setups: Make `/etc/nginx/sites-available/nginx-ssl` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-3-stable/lib/support/nginx/gitlab-ssl but with your setting
+- HTTP setups: Make `/etc/nginx/sites-available/nginx` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-3-stable/lib/support/nginx/gitlab but with your settings.
+- HTTPS setups: Make `/etc/nginx/sites-available/nginx-ssl` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-3-stable/lib/support/nginx/gitlab-ssl but with your setting.
 
 ### 7. Start application
 

doc/update/7.3-to-7.4.md

@@ -75,11 +75,11 @@ sudo -u git -H editor config/unicorn.rb
 
 #### Change Nginx HTTPS settings
 
-* HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-4-stable/lib/support/nginx/gitlab-ssl but with your setting
+- HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as https://gitlab.com/gitlab-org/gitlab-ce/blob/7-4-stable/lib/support/nginx/gitlab-ssl but with your setting.
 
 #### MySQL Databases: Update database.yml config file
 
-* Add `collation: utf8_general_ci` to `config/database.yml` as seen in [config/database.yml.mysql][mysql]:
+- Add `collation: utf8_general_ci` to `config/database.yml` as seen in [config/database.yml.mysql][mysql]:
 
 ```
 sudo -u git -H editor config/database.yml
@@ -136,7 +136,7 @@ SET foreign_key_checks = 1;
 # Find MySQL users
 mysql> SELECT user FROM mysql.user WHERE user LIKE '%git%';
 
-# If git user exists and gitlab user does not exist 
+# If git user exists and gitlab user does not exist
 # you are done with the database cleanup tasks
 mysql> \q
 

doc/update/7.4-to-7.5.md

@@ -77,8 +77,8 @@ git diff origin/7-4-stable:config/gitlab.yml.example origin/7-5-stable:config/gi
 
 #### Change Nginx settings
 
-* HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings
-* HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your setting
+- HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings.
+- HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your setting.
 
 ### 6. Start application
 

doc/update/7.5-to-7.6.md

@@ -79,8 +79,8 @@ git diff origin/7-5-stable:config/gitlab.yml.example origin/7-6-stable:config/gi
 
 #### Change Nginx settings
 
-* HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings
-* HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your setting
+- HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings.
+- HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your setting.
 
 #### Set up time zone (optional)
 

doc/update/7.6-to-7.7.md

@@ -79,8 +79,8 @@ git diff origin/7-6-stable:config/gitlab.yml.example origin/7-7-stable:config/gi
 
 #### Change Nginx settings
 
-* HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings
-* HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your setting
+- HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings.
+- HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your setting.
 
 #### Set up time zone (optional)
 

doc/update/7.7-to-7.8.md

@@ -79,9 +79,9 @@ git diff origin/7-7-stable:config/gitlab.yml.example origin/7-8-stable:config/gi
 
 #### Change Nginx settings
 
-* HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings.
-* HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your settings.
-* A new `location /uploads/` section has been added that needs to have the same content as the existing `location @gitlab` section.
+- HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings.
+- HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your settings.
+- A new `location /uploads/` section has been added that needs to have the same content as the existing `location @gitlab` section.
 
 #### Set up time zone (optional)
 

doc/update/7.8-to-7.9.md

@@ -81,9 +81,9 @@ git diff origin/7-8-stable:config/gitlab.yml.example origin/7-9-stable:config/gi
 
 #### Change Nginx settings
 
-* HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings.
-* HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your settings.
-* A new `location /uploads/` section has been added that needs to have the same content as the existing `location @gitlab` section.
+- HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings.
+- HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your settings.
+- A new `location /uploads/` section has been added that needs to have the same content as the existing `location @gitlab` section.
 
 #### Set up time zone (optional)
 

doc/update/7.9-to-7.10.md

@@ -77,9 +77,9 @@ git diff origin/7-9-stable:config/gitlab.yml.example origin/7-10-stable:config/g
 
 #### Change Nginx settings
 
-* HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings.
-* HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your settings.
-* A new `location /uploads/` section has been added that needs to have the same content as the existing `location @gitlab` section.
+- HTTP setups: Make `/etc/nginx/sites-available/gitlab` the same as [`lib/support/nginx/gitlab`][nginx] but with your settings.
+- HTTPS setups: Make `/etc/nginx/sites-available/gitlab-ssl` the same as [`lib/support/nginx/gitlab-ssl`][nginx-ssl] but with your settings.
+- A new `location /uploads/` section has been added that needs to have the same content as the existing `location @gitlab` section.
 
 #### Set up time zone (optional)
 

doc/update/upgrading_postgresql_using_slony.md

@@ -176,10 +176,10 @@ if ($ENV{"SLONYSET"}) {
 In this configuration file you should replace a few placeholders before you can
 use it. The following placeholders should be replaced:
 
-* `OLD_HOST`: the address of the old database server.
-* `NEW_HOST`: the address of the new database server.
-* `SLONY_PASSWORD`: the password of the Slony user created earlier.
-* `TABLES`: the tables to replicate.
+- `OLD_HOST`: the address of the old database server.
+- `NEW_HOST`: the address of the new database server.
+- `SLONY_PASSWORD`: the password of the Slony user created earlier.
+- `TABLES`: the tables to replicate.
 
 The list of tables to replicate can be generated by running the following
 command on your old PostgreSQL database:

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)

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
 

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
 

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).

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
 

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).

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

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 |
 | --- | --- |

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.
 

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). You are also able to [add your own metrics](#adding-additional-metrics) as well.
 
@@ -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.
 
@@ -101,18 +102,19 @@ Additional metrics can be monitored by adding them on the Prometheus integration
 ![Add New Metric](img/prometheus_add_metric.png)
 
 A few fields are required:
-* **Name**: Chart title
-* **Type**: Type of metric. Metrics of the same type will be shown together.
-* **Query**: Valid [PromQL query](https://prometheus.io/docs/prometheus/latest/querying/basics/). Note, no validation is performed at this time. If the query is not valid, the dashboard will display an error.
-* **Y-axis label**: Y axis title to display on the dashboard.
-* **Unit label**: Query units, for example `req / sec`. Shown next to the value.
+
+- **Name**: Chart title
+- **Type**: Type of metric. Metrics of the same type will be shown together.
+- **Query**: Valid [PromQL query](https://prometheus.io/docs/prometheus/latest/querying/basics/). Note, no validation is performed at this time. If the query is not valid, the dashboard will display an error.
+- **Y-axis label**: Y axis title to display on the dashboard.
+- **Unit label**: Query units, for example `req / sec`. Shown next to the value.
 
 #### Query Variables
 
 GitLab supports a limited set of [CI variables](../../../ci/variables/README.html) in the Prometheus query. This is particularly useful for identifying a specific environment, for example with `CI_ENVIRONMENT_SLUG`. The supported variables are:
 
-* CI_ENVIRONMENT_SLUG
-* KUBE_NAMESPACE
+- CI_ENVIRONMENT_SLUG
+- KUBE_NAMESPACE
 
 To specify a variable in a query, enclose it in curly braces with a leading percent. For example: `%{ci_environment_slug}`.
 
@@ -120,15 +122,15 @@ To specify a variable in a query, enclose it in curly braces with a leading perc
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6590) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.2 for [custom metrics](#adding-additional-metrics), and 11.3 for [library metrics](prometheus_library/metrics.md).
 
-Alerts can be configured for [metricss](#adding-additional-metrics) directly in the performance dashboard. 
+Alerts can be configured for [metricss](#adding-additional-metrics) directly in the performance dashboard.
 
-To set an alert, click on the alarm icon in the top right corner of the metric you want to create the alert for. A dropdown 
+To set an alert, click on the alarm icon in the top right corner of the metric you want to create the alert for. A dropdown
 will appear, with options to set the threshold and operator. Click **Add** to save and activate the alert.
 
 ![Adding an alert](img/prometheus_alert.png)
 
 If the metric exceeds the threshold of the alert for over 5 minutes, an email
-will be sent to all [Maintainers and Owners](../../permissions.md#project-members-permissions) of the project. 
+will be sent to all [Maintainers and Owners](../../permissions.md#project-members-permissions) of the project.
 
 To remove the alert, click back on the alert icon for the desired metric, and click **Delete**.
 

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).
 

doc/user/project/merge_requests/index.md

@@ -457,8 +457,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
 

doc/user/project/merge_requests/squash_and_merge.md

@@ -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
 

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
 

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)

doc/workflow/lfs/lfs_administration.md

@@ -4,9 +4,9 @@ Documentation on how to use Git LFS are under [Managing large binary files with
 
 ## Requirements
 
-* Git LFS is supported in GitLab starting with version 8.2.
-* Support for object storage, such as AWS S3, was introduced in 10.0.
-* Users need to install [Git LFS client](https://git-lfs.github.com) version 1.0.1 and up.
+- Git LFS is supported in GitLab starting with version 8.2.
+- Support for object storage, such as AWS S3, was introduced in 10.0.
+- Users need to install [Git LFS client](https://git-lfs.github.com) version 1.0.1 and up.
 
 ## Configuration
 
@@ -15,9 +15,9 @@ GitLab is installed on.
 
 There are various configuration options to help GitLab server administrators:
 
-* Enabling/disabling Git LFS support
-* Changing the location of LFS object storage
-* Setting up object storage supported by [Fog](http://fog.io/about/provider_documentation.html)
+- Enabling/disabling Git LFS support
+- Changing the location of LFS object storage
+- Setting up object storage supported by [Fog](http://fog.io/about/provider_documentation.html)
 
 ### Configuration for Omnibus installations
 
@@ -229,11 +229,11 @@ See more information in [!19581](https://gitlab.com/gitlab-org/gitlab-ce/merge_r
 
 ## Known limitations
 
-* Support for removing unreferenced LFS objects was added in 8.14 onwards.
-* LFS authentications via SSH was added with GitLab 8.12
-* Only compatible with the GitLFS client versions 1.1.0 and up, or 1.0.2.
-* The storage statistics currently count each LFS object multiple times for
-  every project linking to it
+- Support for removing unreferenced LFS objects was added in 8.14 onwards.
+- LFS authentications via SSH was added with GitLab 8.12.
+- Only compatible with the GitLFS client versions 1.1.0 and up, or 1.0.2.
+- The storage statistics currently count each LFS object multiple times for
+  every project linking to it.
 
 [reconfigure gitlab]: ../../administration/restart_gitlab.md#omnibus-gitlab-reconfigure "How to reconfigure Omnibus GitLab"
 [restart gitlab]: ../../administration/restart_gitlab.md#installations-from-source "How to restart GitLab"

doc/workflow/lfs/manage_large_binaries_with_git_lfs.md

@@ -21,18 +21,18 @@ Documentation for GitLab instance administrators is under [LFS administration do
 
 ## Requirements
 
-* Git LFS is supported in GitLab starting with version 8.2
-* Git LFS must be enabled under project settings
-* [Git LFS client](https://git-lfs.github.com) version 1.0.1 and up
+- Git LFS is supported in GitLab starting with version 8.2
+- Git LFS must be enabled under project settings
+- [Git LFS client](https://git-lfs.github.com) version 1.0.1 and up
 
 ## Known limitations
 
-* Git LFS v1 original API is not supported since it was deprecated early in LFS
+- Git LFS v1 original API is not supported since it was deprecated early in LFS
   development
-* When SSH is set as a remote, Git LFS objects still go through HTTPS
-* Any Git LFS request will ask for HTTPS credentials to be provided so a good Git
+- When SSH is set as a remote, Git LFS objects still go through HTTPS
+- Any Git LFS request will ask for HTTPS credentials to be provided so a good Git
   credentials store is recommended
-* Git LFS always assumes HTTPS so if you have GitLab server on HTTP you will have
+- Git LFS always assumes HTTPS so if you have GitLab server on HTTP you will have
   to add the URL to Git config manually (see [troubleshooting](#troubleshooting))
 
 >**Note**: With 8.12 GitLab added LFS support to SSH. The Git LFS communication
@@ -158,16 +158,16 @@ git lfs unlock --id=123 --force
 
 There are a couple of reasons why this error can occur:
 
-* You don't have permissions to access certain LFS object
+- You don't have permissions to access certain LFS object
 
 Check if you have permissions to push to the project or fetch from the project.
 
-* Project is not allowed to access the LFS object
+- Project is not allowed to access the LFS object
 
 LFS object you are trying to push to the project or fetch from the project is not
 available to the project anymore. Probably the object was removed from the server.
 
-* Local git repository is using deprecated LFS API
+- Local git repository is using deprecated LFS API
 
 ### Invalid status for `<url>` : 501
 
@@ -180,15 +180,15 @@ git lfs logs last
 
 If the status `error 501` is shown, it is because:
 
-* Git LFS is not enabled in project settings. Check your project settings and
+- Git LFS is not enabled in project settings. Check your project settings and
   enable Git LFS.
 
-* Git LFS support is not enabled on the GitLab server. Check with your GitLab
+- Git LFS support is not enabled on the GitLab server. Check with your GitLab
   administrator why Git LFS is not enabled on the server. See
   [LFS administration documentation](lfs_administration.md) for instructions
   on how to enable LFS support.
 
-* Git LFS client version is not supported by GitLab server. Check your Git LFS
+- Git LFS client version is not supported by GitLab server. Check your Git LFS
   version with `git lfs version`. Check the Git config of the project for traces
   of deprecated API with `git lfs -l`. If `batch = false` is set in the config,
   remove the line and try to update your Git LFS client. Only version 1.0.1 and

doc/workflow/releases.md

@@ -20,4 +20,3 @@ There are several ways to add release notes:
 ## Tags page with button to add or edit release notes for existing git tag
 
 ![tags](releases/tags.png)
-

doc/workflow/time_tracking.md

@@ -8,8 +8,9 @@ requests within GitLab.
 ## Overview
 
 Time Tracking lets you:
-* record the time spent working on an issue or a merge request,
-* add an estimate of the amount of time needed to complete an issue or a merge
+
+- Record the time spent working on an issue or a merge request.
+- Add an estimate of the amount of time needed to complete an issue or a merge
 request.
 
 You don't have to indicate an estimate to enter the time spent, and vice versa.
@@ -63,11 +64,12 @@ To remove all the time spent at once, use `/remove_time_spent`.
 ## Configuration
 
 The following time units are available:
-* months (mo)
-* weeks (w)
-* days (d)
-* hours (h)
-* minutes (m)
+
+- months (mo)
+- weeks (w)
+- days (d)
+- hours (h)
+- minutes (m)
 
 Default conversion rates are 1mo = 4w, 1w = 5d and 1d = 8h.