Resolve "CE documentation is not CommonMark compliant"

19 files changed, 156 insertions, 157 deletions

diff --git a/doc/user/project/bulk_editing.md b/doc/user/project/bulk_editing.md
index 4261293b06f..fead99c5e88 100644
--- a/doc/user/project/bulk_editing.md
+++ b/doc/user/project/bulk_editing.md
@@ -1,11 +1,10 @@
 # Bulk editing issues and merge requests
 
->
-**Notes:**
-- A permission level of `Reporter` or higher is required in order to manage
-issues.
-- A permission level of `Developer` or higher is required in order to manage
-merge requests.
+> **Notes:**
+> - A permission level of `Reporter` or higher is required in order to manage
+>   issues.
+> - A permission level of `Developer` or higher is required in order to manage
+>   merge requests.
 
 Attributes can be updated simultaneously across multiple issues or merge requests
 by using the bulk editing feature.
diff --git a/doc/user/project/clusters/eks_and_gitlab/index.md b/doc/user/project/clusters/eks_and_gitlab/index.md
index ec8467da14f..10f0cdb333e 100644
--- a/doc/user/project/clusters/eks_and_gitlab/index.md
+++ b/doc/user/project/clusters/eks_and_gitlab/index.md
@@ -43,9 +43,9 @@ From the left side bar, hover over `Operations` and select `Kubernetes`, then cl
 A few details from the EKS cluster will be required to connect it to GitLab.
 
 1. A valid Kubernetes certificate and token are needed to authenticate to the EKS cluster. A pair is created by default, which can be used. Open a shell and use `kubectl` to retrieve them:
-  * List the secrets with `kubectl get secrets`, and one should named similar to `default-token-xxxxx`. Copy that token name for use below.
-  * Get the certificate with `kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 -D`
-  * Retrieve the token with `kubectl get secret <secret name> -o jsonpath="{['data']['token']}" | base64 -D`.
+   * List the secrets with `kubectl get secrets`, and one should named similar to `default-token-xxxxx`. Copy that token name for use below.
+   * Get the certificate with `kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 -D`
+   * Retrieve the token with `kubectl get secret <secret name> -o jsonpath="{['data']['token']}" | base64 -D`.
 1. The API server endpoint is also required, so GitLab can connect to the cluster. This is displayed on the AWS EKS console, when viewing the EKS cluster details.
 
 You now have all the information needed to connect the EKS cluster:
diff --git a/doc/user/project/clusters/index.md b/doc/user/project/clusters/index.md
index 7c552103412..1edc82ee9ef 100644
--- a/doc/user/project/clusters/index.md
+++ b/doc/user/project/clusters/index.md
@@ -54,16 +54,16 @@ new Kubernetes cluster to your project:
 1. Connect your Google account if you haven't done already by clicking the
    **Sign in with Google** button.
 1. From there on, choose your cluster's settings:
-  - **Kubernetes cluster name** - The name you wish to give the cluster.
-  - **Environment scope** - The [associated environment](#setting-the-environment-scope) to this cluster.
-  - **Google Cloud Platform project** - Choose the project you created in your GCP
-    console that will host the Kubernetes cluster. Learn more about
-    [Google Cloud Platform projects](https://cloud.google.com/resource-manager/docs/creating-managing-projects).
-  - **Zone** - Choose the [region zone](https://cloud.google.com/compute/docs/regions-zones/)
-    under which the cluster will be created.
-  - **Number of nodes** - Enter the number of nodes you wish the cluster to have.
-  - **Machine type** - The [machine type](https://cloud.google.com/compute/docs/machine-types)
-    of the Virtual Machine instance that the cluster will be based on.
+   - **Kubernetes cluster name** - The name you wish to give the cluster.
+   - **Environment scope** - The [associated environment](#setting-the-environment-scope) to this cluster.
+   - **Google Cloud Platform project** - Choose the project you created in your GCP
+     console that will host the Kubernetes cluster. Learn more about
+     [Google Cloud Platform projects](https://cloud.google.com/resource-manager/docs/creating-managing-projects).
+   - **Zone** - Choose the [region zone](https://cloud.google.com/compute/docs/regions-zones/)
+     under which the cluster will be created.
+   - **Number of nodes** - Enter the number of nodes you wish the cluster to have.
+   - **Machine type** - The [machine type](https://cloud.google.com/compute/docs/machine-types)
+     of the Virtual Machine instance that the cluster will be based on.
 1. Finally, click the **Create Kubernetes cluster** button.
 
 After a couple of minutes, your cluster will be ready to go. You can now proceed
diff --git a/doc/user/project/container_registry.md b/doc/user/project/container_registry.md
index 03302b3815d..df850d4f68d 100644
--- a/doc/user/project/container_registry.md
+++ b/doc/user/project/container_registry.md
@@ -1,16 +1,16 @@
 # GitLab Container Registry
 
->**Notes:**
+> **Notes:**
 > [Introduced][ce-4040] in GitLab 8.8.
-- Docker Registry manifest `v1` support was added in GitLab 8.9 to support Docker
-  versions earlier than 1.10.
-- This document is about the user guide. To learn how to enable GitLab Container
-  Registry across your GitLab instance, visit the
-  [administrator documentation](../../administration/container_registry.md).
-- Starting from GitLab 8.12, if you have 2FA enabled in your account, you need
-  to pass a [personal access token][pat] instead of your password in order to
-  login to GitLab's Container Registry.
-- Multiple level image names support was added in GitLab 9.1
+> - Docker Registry manifest `v1` support was added in GitLab 8.9 to support Docker
+>   versions earlier than 1.10.
+> - This document is about the user guide. To learn how to enable GitLab Container
+>   Registry across your GitLab instance, visit the
+>   [administrator documentation](../../administration/container_registry.md).
+> - Starting from GitLab 8.12, if you have 2FA enabled in your account, you need
+>   to pass a [personal access token][pat] instead of your password in order to
+>   login to GitLab's Container Registry.
+> - Multiple level image names support was added in GitLab 9.1
 
 With the Docker Container Registry integrated into GitLab, every project can
 have its own space to store its Docker images.
@@ -40,12 +40,12 @@ to enable it.
 
 ## Build and push images
 
->**Notes:**
-- Moving or renaming existing container registry repositories is not supported
-once you have pushed images because the images are signed, and the
-signature includes the repository name.
-- To move or rename a repository with a container registry you will have to
-delete all existing images.
+> **Notes:**
+> - Moving or renaming existing container registry repositories is not supported
+>   once you have pushed images because the images are signed, and the
+>   signature includes the repository name.
+> - To move or rename a repository with a container registry you will have to
+>   delete all existing images.
 
 
 If you visit the **Registry** link under your project's menu, you can see the
diff --git a/doc/user/project/cycle_analytics.md b/doc/user/project/cycle_analytics.md
index 8f6b530c033..7e788ae6220 100644
--- a/doc/user/project/cycle_analytics.md
+++ b/doc/user/project/cycle_analytics.md
@@ -72,7 +72,7 @@ Here's a little explanation of how this works behind the scenes:
    `<issue, merge request>` pair, the merge request has the [issue closing pattern]
    for the corresponding issue. All other issues and merge requests are **not**
    considered.
-1. Then the <issue, merge request> pairs are filtered out by last XX days (specified
+1. Then the `<issue, merge request>` pairs are filtered out by last XX days (specified
    by the UI - default is 90 days). So it prohibits these pairs from being considered.
 1. For the remaining `<issue, merge request>` pairs, we check the information that
    we need for the stages, like issue creation date, merge request merge time,
diff --git a/doc/user/project/integrations/bamboo.md b/doc/user/project/integrations/bamboo.md
index 9b18eb15599..70c0d434f1f 100644
--- a/doc/user/project/integrations/bamboo.md
+++ b/doc/user/project/integrations/bamboo.md
@@ -57,6 +57,6 @@ service in GitLab.
 If builds are not triggered, ensure you entered the right GitLab IP address in
 Bamboo under 'Trigger IP addresses'.
 
->**Note:**
-- Starting with GitLab 8.14.0, builds are triggered on push events.
+> **Note:**
+> - Starting with GitLab 8.14.0, builds are triggered on push events.
 
diff --git a/doc/user/project/integrations/jira.md b/doc/user/project/integrations/jira.md
index 67c543e00fb..b3821cf8391 100644
--- a/doc/user/project/integrations/jira.md
+++ b/doc/user/project/integrations/jira.md
@@ -92,15 +92,15 @@ password as they will be needed when configuring GitLab in the next section.
 
 ### Configuring GitLab
 
->**Notes:**
-- The currently supported JIRA versions are `v6.x` and `v7.x.`. GitLab 7.8 or
-  higher is required.
-- GitLab 8.14 introduced a new way to integrate with JIRA which greatly simplified
-  the configuration options you have to enter. If you are using an older version,
-  [follow this documentation][jira-repo-old-docs].
-- In order to support Oracle's Access Manager, GitLab will send additional cookies
-  to enable Basic Auth. The cookie being added to each request is `OBBasicAuth` with
-  a value of `fromDialog`.
+> **Notes:**
+> - The currently supported JIRA versions are `v6.x` and `v7.x.`. GitLab 7.8 or
+>   higher is required.
+> - GitLab 8.14 introduced a new way to integrate with JIRA which greatly simplified
+>   the configuration options you have to enter. If you are using an older version,
+>   [follow this documentation][jira-repo-old-docs].
+> - In order to support Oracle's Access Manager, GitLab will send additional cookies
+>   to enable Basic Auth. The cookie being added to each request is `OBBasicAuth` with
+>   a value of `fromDialog`.
 
 To enable JIRA integration in a project, navigate to the
 [Integrations page](project_services.md#accessing-the-project-services), click
@@ -182,11 +182,11 @@ the same goal:
 
 where `PROJECT-1` is the issue ID of the JIRA project.
 
->**Note:**
-- Only commits and merges into the project's default branch (usually **master**) will
-  close an issue in Jira. You can change your projects default branch under
-  [project settings](img/jira_project_settings.png).
-- The JIRA issue will not be transitioned if it has a resolution.
+> **Notes:**
+> - Only commits and merges into the project's default branch (usually **master**) will
+>   close an issue in Jira. You can change your projects default branch under
+>   [project settings](img/jira_project_settings.png).
+> - The JIRA issue will not be transitioned if it has a resolution.
 
 ### JIRA issue closing example
 
diff --git a/doc/user/project/integrations/webhooks.md b/doc/user/project/integrations/webhooks.md
index a64e080d6b7..6104eadde35 100644
--- a/doc/user/project/integrations/webhooks.md
+++ b/doc/user/project/integrations/webhooks.md
@@ -1,21 +1,21 @@
 # Webhooks
 
->**Note:**
-Starting from GitLab 8.5:
-- the `repository` key is deprecated in favor of the `project` key
-- the `project.ssh_url` key is deprecated in favor of the `project.git_ssh_url` key
-- the `project.http_url` key is deprecated in favor of the `project.git_http_url` key
-
->**Note:**
-Starting from GitLab 11.1, the logs of web hooks are automatically removed after
-one month.
-
->**Note**
-Starting from GitLab 11.2:
-- The `description` field for issues, merge requests, comments, and wiki pages
-  is rewritten so that simple Markdown image references (like
-  `![](/uploads/...)`) have their target URL changed to an absolute URL. See
-  [image URL rewriting](#image-url-rewriting) for more details.
+> **Note:**
+> Starting from GitLab 8.5:
+> - the `repository` key is deprecated in favor of the `project` key
+> - the `project.ssh_url` key is deprecated in favor of the `project.git_ssh_url` key
+> - the `project.http_url` key is deprecated in favor of the `project.git_http_url` key
+>
+> **Note:**
+> Starting from GitLab 11.1, the logs of web hooks are automatically removed after
+> one month.
+>
+> **Note:**
+> Starting from GitLab 11.2:
+> - The `description` field for issues, merge requests, comments, and wiki pages
+>   is rewritten so that simple Markdown image references (like
+>   `![](/uploads/...)`) have their target URL changed to an absolute URL. See
+>   [image URL rewriting](#image-url-rewriting) for more details.
 
 Project webhooks allow you to trigger a URL if for example new code is pushed or
 a new issue is created. You can configure webhooks to listen for specific events
@@ -320,7 +320,7 @@ X-Gitlab-Event: Issue Hook
 }
 ```
 
-**Note**: `assignee` and `assignee_id` keys are deprecated and now show the first assignee only.
+> **Note**: `assignee` and `assignee_id` keys are deprecated and now show the first assignee only.
 
 ### Comment events
 
@@ -619,7 +619,7 @@ X-Gitlab-Event: Note Hook
 }
 ```
 
-**Note**: `assignee_id` field is deprecated and now shows the first assignee only.
+> **Note**: `assignee_id` field is deprecated and now shows the first assignee only.
 
 #### Comment on code snippet
 
@@ -1174,7 +1174,7 @@ On this page, you can see data that GitLab sends (request headers and body) and
 
 From this page, you can repeat delivery with the same data by clicking `Resend Request` button.
 
->**Note:** If URL or secret token of the webhook were updated, data will be delivered to the new address.
+> **Note:** If URL or secret token of the webhook were updated, data will be delivered to the new address.
 
 ### Receiving duplicate or multiple web hook requests triggered by one event
 
diff --git a/doc/user/project/issue_board.md b/doc/user/project/issue_board.md
index 0e847be79c2..7c6d547d626 100644
--- a/doc/user/project/issue_board.md
+++ b/doc/user/project/issue_board.md
@@ -353,23 +353,23 @@ To remove an assignee list, just as with a label list, click the trash icon.
 
 When dragging issues between lists, different behavior occurs depending on the source list and the target list.
 
-| | To Open | To Closed | To label `B` list | To assignee `Bob` list |
-| --- | --- | --- | --- | ---  |
-| From Open | - | Issue closed | `B` added | `Bob` assigned |
-| From Closed | Issue reopened | - | Issue reopened<br/>`B` added | Issue reopened<br/>`Bob` assigned |
-| From label `A` list | `A` removed | Issue closed | `A` removed<br/>`B` added | `Bob` assigned |
-| From assignee `Alice` list | `Alice` unassigned | Issue closed | `B` added | `Alice` unassigned<br/>`Bob` assigned |
+|                            | To Open            | To Closed    | To label `B` list            | To assignee `Bob` list                |
+|----------------------------|--------------------|--------------|------------------------------|---------------------------------------|
+| From Open                  | -                  | Issue closed | `B` added                    | `Bob` assigned                        |
+| From Closed                | Issue reopened     | -            | Issue reopened<br/>`B` added | Issue reopened<br/>`Bob` assigned     |
+| From label `A` list        | `A` removed        | Issue closed | `A` removed<br/>`B` added    | `Bob` assigned                        |
+| From assignee `Alice` list | `Alice` unassigned | Issue closed | `B` added                    | `Alice` unassigned<br/>`Bob` assigned |
 
 ## Features per tier
 
 Different issue board features are available in different [GitLab tiers](https://about.gitlab.com/pricing/), as shown in the following table:
 
-| Tier | Number of Project Issue Boards | Number of Group Issue Boards | Configurable Issue Boards | Assignee Lists
-| --- | --- | --- | --- | --- | --- |
-| Core     | 1        | 1        | No  | No  |
-| Starter  | Multiple | 1        | Yes | No  |
-| Premium  | Multiple | Multiple | Yes | Yes |
-| Ultimate | Multiple | Multiple | Yes | Yes |
+| Tier     | Number of Project Issue Boards | Number of Group Issue Boards | Configurable Issue Boards | Assignee Lists |
+|----------|--------------------------------|------------------------------|---------------------------|----------------|
+| Core     | 1                              | 1                            | No                        | No             |
+| Starter  | Multiple                       | 1                            | Yes                       | No             |
+| Premium  | Multiple                       | Multiple                     | Yes                       | Yes            |
+| Ultimate | Multiple                       | Multiple                     | Yes                       | Yes            |
 
 ## Tips
 
diff --git a/doc/user/project/koding.md b/doc/user/project/koding.md
index 86e06a39e59..2c886d7916a 100644
--- a/doc/user/project/koding.md
+++ b/doc/user/project/koding.md
@@ -1,9 +1,9 @@
 # Koding integration
 
->**Notes:**
-- **As of GitLab 10.0, the Koding integration is deprecated and will be removed
-  in a future version.**
-- [Introduced][ce-5909] in GitLab 8.11.
+> **Notes:**
+> - **As of GitLab 10.0, the Koding integration is deprecated and will be removed
+>   in a future version.**
+> - [Introduced][ce-5909] in GitLab 8.11.
 
 This document will guide you through using Koding integration on GitLab in
 detail. For configuring and installing please follow the
diff --git a/doc/user/project/merge_requests/versions.md b/doc/user/project/merge_requests/versions.md
index 610250ccf12..90500fd9c21 100644
--- a/doc/user/project/merge_requests/versions.md
+++ b/doc/user/project/merge_requests/versions.md
@@ -1,12 +1,12 @@
 # Merge requests versions
 
->**Notes:**
-- [Introduced][ce-5467] in GitLab 8.12.
-- Comments are disabled while viewing outdated merge versions or comparing to
-  versions other than base.
-- Merge request versions are based on push not on commit. So, if you pushed 5
-  commits in a single push, it will be a single option in the dropdown. If you
-  pushed 5 times, that will count for 5 options.
+> **Notes:**
+> - [Introduced][ce-5467] in GitLab 8.12.
+> - Comments are disabled while viewing outdated merge versions or comparing to
+>   versions other than base.
+> - Merge request versions are based on push not on commit. So, if you pushed 5
+>   commits in a single push, it will be a single option in the dropdown. If you
+>   pushed 5 times, that will count for 5 options.
 
 Every time you push to a branch that is tied to a merge request, a new version
 of merge request diff is created. When you visit a merge request that contains
diff --git a/doc/user/project/new_ci_build_permissions_model.md b/doc/user/project/new_ci_build_permissions_model.md
index 15455a54627..23d5b34504c 100644
--- a/doc/user/project/new_ci_build_permissions_model.md
+++ b/doc/user/project/new_ci_build_permissions_model.md
@@ -205,16 +205,16 @@ With the update permission model we also extended the support for accessing
 Container Registries for private projects.
 
 > **Notes:**
-- GitLab Runner versions prior to 1.8 don't incorporate the introduced changes
-  for permissions. This makes the `image:` directive to not work with private
-  projects automatically and it needs to be configured manually on Runner's host
-  with a predefined account (for example administrator's personal account with
-  access token created explicitly for this purpose). This issue is resolved with
-  latest changes in GitLab Runner 1.8 which receives GitLab credentials with
-  build data.
-- Starting from GitLab 8.12, if you have [2FA] enabled in your account, you need
-  to pass a [personal access token][pat] instead of your password in order to
-  login to GitLab's Container Registry.
+> - GitLab Runner versions prior to 1.8 don't incorporate the introduced changes
+>   for permissions. This makes the `image:` directive to not work with private
+>   projects automatically and it needs to be configured manually on Runner's host
+>   with a predefined account (for example administrator's personal account with
+>   access token created explicitly for this purpose). This issue is resolved with
+>   latest changes in GitLab Runner 1.8 which receives GitLab credentials with
+>   build data.
+> - Starting from GitLab 8.12, if you have [2FA] enabled in your account, you need
+>   to pass a [personal access token][pat] instead of your password in order to
+>   login to GitLab's Container Registry.
 
 Your jobs can access all container images that you would normally have access
 to. The only implication is that you can push to the Container Registry of the
diff --git a/doc/user/project/pages/index.md b/doc/user/project/pages/index.md
index 205f0283107..4f0774dba5c 100644
--- a/doc/user/project/pages/index.md
+++ b/doc/user/project/pages/index.md
@@ -12,16 +12,16 @@ With GitLab Pages it's easy to publish your project website. GitLab Pages is a h
 to get you started quickly, or,
 alternatively, start from an existing project as follows:
 
-- 1. [Fork](../../../gitlab-basics/fork-project.md#how-to-fork-a-project) an [example project](https://gitlab.com/pages):
-by forking a project, you create a copy of the codebase you're forking from to start from a template instead of starting from scratch.
-- 2. Change a file to trigger a GitLab CI/CD pipeline: GitLab CI/CD will build and deploy your site to GitLab Pages.
-- 3. Visit your project's **Settings > Pages** to see your **website link**, and click on it. Bam! Your website is live! :)
+1. [Fork](../../../gitlab-basics/fork-project.md#how-to-fork-a-project) an [example project](https://gitlab.com/pages):
+   by forking a project, you create a copy of the codebase you're forking from to start from a template instead of starting from scratch.
+2. Change a file to trigger a GitLab CI/CD pipeline: GitLab CI/CD will build and deploy your site to GitLab Pages.
+3. Visit your project's **Settings > Pages** to see your **website link**, and click on it. Bam! Your website is live! :)
 
-_Further steps (optional):_
+    _Further steps (optional):_
 
-- 4. Remove the [fork relationship](getting_started_part_two.md#fork-a-project-to-get-started-from)
-(_You don't need the relationship unless you intent to contribute back to the example project you forked from_).
-- 5. Make it a [user/group website](getting_started_part_one.md#user-and-group-websites)
+4. Remove the [fork relationship](getting_started_part_two.md#fork-a-project-to-get-started-from)
+   (_You don't need the relationship unless you intent to contribute back to the example project you forked from_).
+5. Make it a [user/group website](getting_started_part_one.md#user-and-group-websites)
 
 **Watch a video with the steps above: https://www.youtube.com/watch?v=TWqh9MtT4Bg**
 
diff --git a/doc/user/project/pipelines/job_artifacts.md b/doc/user/project/pipelines/job_artifacts.md
index 402989f4508..fc3970e2014 100644
--- a/doc/user/project/pipelines/job_artifacts.md
+++ b/doc/user/project/pipelines/job_artifacts.md
@@ -1,18 +1,18 @@
 # Introduction to job artifacts
 
->**Notes:**
->- Since GitLab 8.2 and GitLab Runner 0.7.0, job artifacts that are created by
-   GitLab Runner are uploaded to GitLab and are downloadable as a single archive
-   (`tar.gz`) using the GitLab UI.
->- Starting with GitLab 8.4 and GitLab Runner 1.0, the artifacts archive format
-   changed to `ZIP`, and it is now possible to browse its contents, with the added
-   ability of downloading the files separately.
->- Starting with GitLab 8.17, builds are renamed to jobs.
->- The artifacts browser will be available only for new artifacts that are sent
-   to GitLab using GitLab Runner version 1.0 and up. It will not be possible to
-   browse old artifacts already uploaded to GitLab.
+> **Notes:**
+> - Since GitLab 8.2 and GitLab Runner 0.7.0, job artifacts that are created by
+>   GitLab Runner are uploaded to GitLab and are downloadable as a single archive
+>   (`tar.gz`) using the GitLab UI.
+> - Starting with GitLab 8.4 and GitLab Runner 1.0, the artifacts archive format
+>   changed to `ZIP`, and it is now possible to browse its contents, with the added
+>   ability of downloading the files separately.
+> - Starting with GitLab 8.17, builds are renamed to jobs.
+> - The artifacts browser will be available only for new artifacts that are sent
+>   to GitLab using GitLab Runner version 1.0 and up. It will not be possible to
+>   browse old artifacts already uploaded to GitLab.
 >- This is the user documentation. For the administration guide see
-   [administration/job_artifacts](../../../administration/job_artifacts.md).
+>   [administration/job_artifacts](../../../administration/job_artifacts.md).
 
 Artifacts is a list of files and directories which are attached to a job
 after it completes successfully. This feature is enabled by default in all
@@ -46,14 +46,14 @@ For more examples on artifacts, follow the [artifacts reference in
 
 ## Browsing artifacts
 
->**Note:**
-With GitLab 9.2, PDFs, images, videos and other formats can be previewed
-directly in the job artifacts browser without the need to download them.
-
->**Note:**
-With [GitLab 10.1][ce-14399], HTML files in a public project can be previewed
-directly in a new tab without the need to download them when
-[GitLab Pages](../../../administration/pages/index.md) is enabled
+> **Note:**
+> With GitLab 9.2, PDFs, images, videos and other formats can be previewed
+> directly in the job artifacts browser without the need to download them.
+>
+> **Note:**
+> With [GitLab 10.1][ce-14399], HTML files in a public project can be previewed
+> directly in a new tab without the need to download them when
+> [GitLab Pages](../../../administration/pages/index.md) is enabled
 
 After a job finishes, if you visit the job's specific page, there are three
 buttons. You can download the artifacts archive or browse its contents, whereas
diff --git a/doc/user/project/pipelines/schedules.md b/doc/user/project/pipelines/schedules.md
index a13b1b4561c..9daacc37994 100644
--- a/doc/user/project/pipelines/schedules.md
+++ b/doc/user/project/pipelines/schedules.md
@@ -1,9 +1,9 @@
 # Pipeline Schedules
 
 > **Notes**:
-- This feature was introduced in 9.1 as [Trigger Schedule][ce-10533].
-- In 9.2, the feature was [renamed to Pipeline Schedule][ce-10853].
-- Cron notation is parsed by [Rufus-Scheduler](https://github.com/jmettraux/rufus-scheduler).
+> - This feature was introduced in 9.1 as [Trigger Schedule][ce-10533].
+> - In 9.2, the feature was [renamed to Pipeline Schedule][ce-10853].
+> - Cron notation is parsed by [Rufus-Scheduler](https://github.com/jmettraux/rufus-scheduler).
 
 Pipeline schedules can be used to run a pipeline at specific intervals, for example every
 month on the 22nd for a certain branch.
@@ -19,7 +19,7 @@ In order to schedule a pipeline:
 
 ![New Schedule Form](img/pipeline_schedules_new_form.png)
 
->**Attention:**
+> **Attention:**
 The pipelines won't be executed precisely, because schedules are handled by
 Sidekiq, which runs according to its interval.
 See [advanced admin configuration](#advanced-admin-configuration) for more
@@ -83,7 +83,7 @@ The next time a pipeline is scheduled, your credentials will be used.
 
 ![Schedules list](img/pipeline_schedules_ownership.png)
 
->**Note:**
+> **Note:**
 When the owner of the schedule doesn't have the ability to create pipelines
 anymore, due to e.g., being blocked or removed from the project, or lacking
 the permission to run on protected branches or tags. When this happened, the
diff --git a/doc/user/project/protected_branches.md b/doc/user/project/protected_branches.md
index 3bf63a22963..db706e5020e 100644
--- a/doc/user/project/protected_branches.md
+++ b/doc/user/project/protected_branches.md
@@ -76,7 +76,7 @@ You can specify a wildcard protected branch, which will protect all branches
 matching the wildcard. For example:
 
 | Wildcard Protected Branch | Matching Branches                                      |
-|---------------------------+--------------------------------------------------------|
+|---------------------------|--------------------------------------------------------|
 | `*-stable`                | `production-stable`, `staging-stable`                  |
 | `production/*`            | `production/app-server`, `production/load-balancer`    |
 | `*gitlab*`                | `gitlab`, `gitlab/staging`, `master/gitlab/production` |
diff --git a/doc/user/project/protected_tags.md b/doc/user/project/protected_tags.md
index a5eaf2e9835..3d8fff9f733 100644
--- a/doc/user/project/protected_tags.md
+++ b/doc/user/project/protected_tags.md
@@ -37,7 +37,7 @@ You can specify a wildcard protected tag, which will protect all tags
 matching the wildcard. For example:
 
 | Wildcard Protected Tag | Matching Tags                 |
-|------------------------+-------------------------------|
+|------------------------|-------------------------------|
 | `v*`                   | `v1.0.0`, `version-9.1`       |
 | `*-deploy`             | `march-deploy`, `1.0-deploy`  |
 | `*gitlab*`             | `gitlab`, `gitlab/v1`         |
diff --git a/doc/user/project/repository/gpg_signed_commits/index.md b/doc/user/project/repository/gpg_signed_commits/index.md
index a17f911874b..4f076ee01b8 100644
--- a/doc/user/project/repository/gpg_signed_commits/index.md
+++ b/doc/user/project/repository/gpg_signed_commits/index.md
@@ -36,15 +36,16 @@ to be met:
 
 ## Generating a GPG key
 
->**Notes:**
-- If your Operating System has `gpg2` installed, replace `gpg` with `gpg2` in
-  the following commands.
-- If Git is using `gpg` and you get errors like `secret key not available` or
-  `gpg: signing failed: secret key not available`, run the following command to
-  change to `gpg2`:
-    ```
-    git config --global gpg.program gpg2
-    ```
+> **Notes:**
+> - If your Operating System has `gpg2` installed, replace `gpg` with `gpg2` in
+>   the following commands.
+> - If Git is using `gpg` and you get errors like `secret key not available` or
+>   `gpg: signing failed: secret key not available`, run the following command to
+>   change to `gpg2`:
+>
+>     ```
+>     git config --global gpg.program gpg2
+>    ```
 
 If you don't already have a GPG key, the following steps will help you get
 started:
diff --git a/doc/user/project/repository/reducing_the_repo_size_using_git.md b/doc/user/project/repository/reducing_the_repo_size_using_git.md
index a06ecc3220f..d534c8cbe4b 100644
--- a/doc/user/project/repository/reducing_the_repo_size_using_git.md
+++ b/doc/user/project/repository/reducing_the_repo_size_using_git.md
@@ -33,11 +33,10 @@ following method.
 
 ## Using `git filter-branch` to purge files
 
->
-**Warning:**
-Make sure to first make a copy of your repository since rewriting history will
-purge the files and information you are about to delete. Also make sure to
-inform any collaborators to not use `pull` after your changes, but use `rebase`.
+> **Warning:**
+> Make sure to first make a copy of your repository since rewriting history will
+> purge the files and information you are about to delete. Also make sure to
+> inform any collaborators to not use `pull` after your changes, but use `rebase`.
 
 1. Navigate to your repository:
 
@@ -71,10 +70,10 @@ inform any collaborators to not use `pull` after your changes, but use `rebase`.
 
 Your repository should now be below the size limit.
 
->**Note:**
-As an alternative to `filter-branch`, you can use the `bfg` tool with a
-command like: `bfg --delete-files path/to/big_file.mpg`. Read the
-[BFG Repo-Cleaner][bfg] documentation for more information.
+> **Note:**
+> As an alternative to `filter-branch`, you can use the `bfg` tool with a
+> command like: `bfg --delete-files path/to/big_file.mpg`. Read the
+> [BFG Repo-Cleaner][bfg] documentation for more information.
 
 [admin-repo-size]: https://docs.gitlab.com/ee/user/admin_area/settings/account_and_limit_settings.html#repository-size-limit
 [bfg]: https://rtyley.github.io/bfg-repo-cleaner/