Merge branch 'docs/fix-lists-surrounded-by-new-lines' into 'master'

Ensure all lists are surrounded by new lines

See merge request gitlab-org/gitlab-ce!25479

doc/administration/auth/authentiq.md

@@ -51,7 +51,7 @@ Authentiq will generate a Client ID and the accompanying Client Secret for you t
     ```
 
 1. The `scope` is set to request the user's name, email (required and signed), and permission to send push notifications to sign in on subsequent visits.
-See [OmniAuth Authentiq strategy](https://github.com/AuthentiqID/omniauth-authentiq/wiki/Scopes,-callback-url-configuration-and-responses) for more information on scopes and modifiers.
+   See [OmniAuth Authentiq strategy](https://github.com/AuthentiqID/omniauth-authentiq/wiki/Scopes,-callback-url-configuration-and-responses) for more information on scopes and modifiers.
 
 1. Change `YOUR_CLIENT_ID` and `YOUR_CLIENT_SECRET` to the Client credentials you received in step 1.
 

doc/administration/auth/ldap.md

@@ -451,7 +451,7 @@ ldapsearch -H ldaps://$host:$port -D "$bind_dn" -y bind_dn_password.txt  -b "$ba
 ### Invalid credentials when logging in
 
 - Make sure the user you are binding with has enough permissions to read the user's
-tree and traverse it.
+  tree and traverse it.
 - Check that the `user_filter` is not blocking otherwise valid users.
 - Run the following check command to make sure that the LDAP settings are
   correct and GitLab can see your users:

doc/administration/monitoring/performance/grafana_configuration.md

@@ -34,7 +34,7 @@ Test Connection to ensure the configuration is correct.
 - **Default**: Checked
 - **Type**: InfluxDB 0.9.x (Even if you're using InfluxDB 0.10.x)
 - **Url**: `https://localhost:8086` (Or the remote URL if you've installed InfluxDB
-on a separate server)
+  on a separate server)
 - **Access**: proxy
 - **Database**: gitlab
 - **User**: admin (Or the username configured when setting up InfluxDB)

doc/administration/monitoring/performance/performance_bar.md

@@ -10,11 +10,11 @@ It allows you to see (from left to right):
 - the current host serving the page
 - the timing of the page (backend, frontend)
 - time taken and number of DB queries, click through for details of these queries
-![SQL profiling using the Performance Bar](img/performance_bar_sql_queries.png)
+  ![SQL profiling using the Performance Bar](img/performance_bar_sql_queries.png)
 - time taken and number of [Gitaly] calls, click through for details of these calls
-![Gitaly profiling using the Performance Bar](img/performance_bar_gitaly_calls.png)
+  ![Gitaly profiling using the Performance Bar](img/performance_bar_gitaly_calls.png)
 - profile of the code used to generate the page, line by line. In the profile view, the numbers in the left panel represent wall time, cpu time, and number of calls (based on [rblineprof](https://github.com/tmm1/rblineprof)).
-![Line profiling using the Performance Bar](img/performance_bar_line_profiling.png)
+  ![Line profiling using the Performance Bar](img/performance_bar_line_profiling.png)
 - time taken and number of calls to Redis
 - time taken and number of background jobs created by Sidekiq
 - time taken and number of Ruby GC calls

doc/administration/operations/index.md

@@ -3,20 +3,20 @@
 Keep your GitLab instance up and running smoothly.
 
 - [Clean up Redis sessions](cleaning_up_redis_sessions.md): Prior to GitLab 7.3,
-user sessions did not automatically expire from Redis. If
-you have been running a large GitLab server (thousands of users) since before
-GitLab 7.3 we recommend cleaning up stale sessions to compact the Redis
-database after you upgrade to GitLab 7.3.
+  user sessions did not automatically expire from Redis. If
+  you have been running a large GitLab server (thousands of users) since before
+  GitLab 7.3 we recommend cleaning up stale sessions to compact the Redis
+  database after you upgrade to GitLab 7.3.
 - [Moving repositories](moving_repositories.md): Moving all repositories managed
-by GitLab to another file system or another server.
+  by GitLab to another file system or another server.
 - [Sidekiq MemoryKiller](sidekiq_memory_killer.md): Configure Sidekiq MemoryKiller
-to restart Sidekiq.
+  to restart Sidekiq.
 - [Unicorn](unicorn.md): Understand Unicorn and unicorn-worker-killer.
 - Speed up SSH operations by [Authorizing SSH users via a fast,
-indexed lookup to the GitLab database](fast_ssh_key_lookup.md), and/or
-by [doing away with user SSH keys stored on GitLab entirely in favor
-of SSH certificates](ssh_certificates.md).
+  indexed lookup to the GitLab database](fast_ssh_key_lookup.md), and/or
+  by [doing away with user SSH keys stored on GitLab entirely in favor
+  of SSH certificates](ssh_certificates.md).
 - [Filesystem Performance Benchmarking](filesystem_benchmarking.md): Filesystem
-performance can have a big impact on GitLab performance, especially for actions
-that read or write Git repositories. This information will help benchmark
-filesystem performance against known good and bad real-world systems.
+  performance can have a big impact on GitLab performance, especially for actions
+  that read or write Git repositories. This information will help benchmark
+  filesystem performance against known good and bad real-world systems.

doc/administration/pages/index.md

@@ -338,9 +338,9 @@ You may want to run GitLab Pages daemon on a separate server in order to decreas
 Follow the steps below to configure GitLab Pages in a separate server.
 
 1. Suppose you have the main GitLab application server named `app1`. Prepare
-new Linux server (let's call it `app2`), create NFS share there and configure access to 
-this share from `app1`. Let's use the default GitLab Pages folder `/var/opt/gitlab/gitlab-rails/shared/pages` 
-as the shared folder on `app2` and mount it to `/mnt/pages` on `app1`.
+   new Linux server (let's call it `app2`), create NFS share there and configure access to
+   this share from `app1`. Let's use the default GitLab Pages folder `/var/opt/gitlab/gitlab-rails/shared/pages`
+   as the shared folder on `app2` and mount it to `/mnt/pages` on `app1`.
 
 1. On `app2` install GitLab omnibus and modify `/etc/gitlab/gitlab.rb` this way:
 

doc/administration/pages/source.md

@@ -88,12 +88,13 @@ since that is needed in all configurations.
 
 ### Wildcard domains
 
->**Requirements:**
-> - [Wildcard DNS setup](#dns-configuration)
->
-> ---
->
-> URL scheme: `http://page.example.io`
+**Requirements:**
+
+- [Wildcard DNS setup](#dns-configuration)
+
+---
+
+URL scheme: `http://page.example.io`
 
 This is the minimum setup that you can use Pages with. It is the base for all
 other setups as described below. Nginx will proxy all requests to the daemon.

doc/administration/polling.md

@@ -10,15 +10,15 @@ say that issue notes poll every 2 seconds, and issue titles poll every 5
 seconds; these are _not_ the actual values.
 
 - 1 is the default, and recommended for most installations. (Issue notes poll
-every 2 seconds, and issue titles poll every 5 seconds.)
+  every 2 seconds, and issue titles poll every 5 seconds.)
 - 0 will disable UI polling completely. (On the next poll, clients will stop
-polling for updates.)
+  polling for updates.)
 - A value greater than 1 will slow polling down. If you see issues with
-database load from lots of clients polling for updates, increasing the
-multiplier from 1 can be a good compromise, rather than disabling polling
-completely. (For example: If this is set to 2, then issue notes poll every 4
-seconds, and issue titles poll every 10 seconds.)
+  database load from lots of clients polling for updates, increasing the
+  multiplier from 1 can be a good compromise, rather than disabling polling
+  completely. (For example: If this is set to 2, then issue notes poll every 4
+  seconds, and issue titles poll every 10 seconds.)
 - A value between 0 and 1 will make the UI poll more frequently (so updates
-will show in other sessions faster), but is **not recommended**. 1 should be
-fast enough. (For example, if this is set to 0.5, then issue notes poll every
-1 second, and issue titles poll every 2.5 seconds.)
+  will show in other sessions faster), but is **not recommended**. 1 should be
+  fast enough. (For example, if this is set to 0.5, then issue notes poll every
+  1 second, and issue titles poll every 2.5 seconds.)

doc/administration/raketasks/maintenance.md

@@ -60,6 +60,7 @@ Runs the following rake tasks:
 It will check that each component was set up according to the installation guide and suggest fixes for issues found.
 
 You may also have a look at our Troubleshooting Guides:
+
 - [Troubleshooting Guide (GitLab)](http://docs.gitlab.com/ee/README.html#troubleshooting)
 - [Troubleshooting Guide (Omnibus Gitlab)](http://docs.gitlab.com/omnibus/README.html#troubleshooting)
 

doc/api/repository_files.md

@@ -171,6 +171,7 @@ Parameters:
 
 If the commit fails for any reason we return a 400 error with a non-specific
 error message. Possible causes for a failed commit include:
+
 - the `file_path` contained `/../` (attempted directory traversal);
 - the new file contents were identical to the current file contents, i.e. the
   user tried to make an empty commit;

doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md

@@ -75,7 +75,7 @@ When we call `mix` command, we'll pass two arguments:
 
 - The task we want it to run: `phoenix.new`
 - And the parameter `phoenix.new` requires, which is the name of the new project. In this case,
-we're calling it `hello_gitlab_ci`, but you're free to set your own name:
+  we're calling it `hello_gitlab_ci`, but you're free to set your own name:
 
 ```bash
 mix phoenix.new hello_gitlab_ci
@@ -249,7 +249,7 @@ project.
     ![Set up CI](img/setup-ci.png)
 
 - On next screen, we can select a template ready to go. Click on **Apply a GitLab CI/CD Yaml
-template** and select **Elixir**:
+  template** and select **Elixir**:
 
     ![Select template](img/select-template.png)
 

doc/ci/merge_request_pipelines/index.md

@@ -106,10 +106,10 @@ flow, external contributors follow the following steps:
 
 1. Fork a parent project.
 1. Create a merge request from the forked project that targets the `master` branch
-in the parent project.
+   in the parent project.
 1. A pipeline runs on the merge request.
 1. A maintainer from the parent project checks the pipeline result, and merge
-into a target branch if the latest pipeline has passed.
+   into a target branch if the latest pipeline has passed.
 
 Currently, those pipelines are created in a **forked** project, not in the
 parent project. This means you cannot completely trust the pipeline result,

doc/development/automatic_ce_ee_merge.md

@@ -115,16 +115,16 @@ Now, every time you create an MR for CE and EE:
    1. Continue cherry-picking: `git cherry-pick --continue`
    1. Push to EE: `git push origin branch-example-ee`
 1. Create the EE-equivalent MR and link to the CE MR from the
-description "Ports [CE-MR-LINK] to EE"
+   description "Ports [CE-MR-LINK] to EE"
 1. Once all the jobs are passing in both CE and EE, you've addressed the
-feedback from your own team, and got them approved, the merge requests can be merged.
+   feedback from your own team, and got them approved, the merge requests can be merged.
 1. When both MRs are ready, the EE merge request will be merged first, and the
-CE-equivalent will be merged next.
+   CE-equivalent will be merged next.
 
 **Important notes:**
 
 - The commit SHA can be easily found from the GitLab UI. From a merge request,
-open the tab **Commits** and click the copy icon to copy the commit SHA.
+  open the tab **Commits** and click the copy icon to copy the commit SHA.
 - To cherry-pick a **commit range**, such as [A > B > C > D] use:
 
     ```shell
@@ -140,7 +140,7 @@ open the tab **Commits** and click the copy icon to copy the commit SHA.
     ```
 
 - To cherry-pick a **merge commit**, use the flag `-m 1`. For example, suppose that the
-merge commit SHA is `138f5e2f20289bb376caffa0303adb0cac859ce1`:
+  merge commit SHA is `138f5e2f20289bb376caffa0303adb0cac859ce1`:
 
     ```shell
     git cherry-pick -m 1 138f5e2f20289bb376caffa0303adb0cac859ce1
@@ -163,12 +163,12 @@ merge commit SHA is `138f5e2f20289bb376caffa0303adb0cac859ce1`:
     commits and you want to cherry-pick all but the merge commit.
 
 - If you push more commits to the CE branch, you can safely repeat the procedure
-to cherry-pick them to the EE-equivalent branch. You can do that as many times as
-necessary, using the same CE and EE branches.
+  to cherry-pick them to the EE-equivalent branch. You can do that as many times as
+  necessary, using the same CE and EE branches.
 - If you submitted the merge request to the CE repo and the `ee-compat-check` job passed,
-you are not required to submit the EE-equivalent MR, but it's still recommended. If the
-job failed, you are required to submit the EE MR so that you can fix the conflicts in EE
-before merging your changes into CE.
+  you are not required to submit the EE-equivalent MR, but it's still recommended. If the
+  job failed, you are required to submit the EE MR so that you can fix the conflicts in EE
+  before merging your changes into CE.
 
 ## FAQ
 

doc/development/contributing/issue_workflow.md

@@ -199,7 +199,7 @@ different way.
 We add the ~"Accepting merge requests" label to:
 
 - Low priority ~bug issues (i.e. we do not add it to the bugs that we want to
-solve in the ~"Next Patch Release")
+  solve in the ~"Next Patch Release")
 - Small ~feature
 - Small ~"technical debt" issues
 
@@ -300,17 +300,17 @@ below will make it easy to manage this, without unnecessary overhead.
 
 1. Set weight for any issue at the earliest possible convenience
 1. If you don't agree with a set weight, discuss with other developers until
-consensus is reached about the weight
+   consensus is reached about the weight
 1. Issue weights are an abstract measurement of complexity of the issue. Do not
-relate issue weight directly to time. This is called [anchoring](https://en.wikipedia.org/wiki/Anchoring)
-and something you want to avoid.
+   relate issue weight directly to time. This is called [anchoring](https://en.wikipedia.org/wiki/Anchoring)
+   and something you want to avoid.
 1. Something that has a weight of 1 (or no weight) is really small and simple.
-Something that is 9 is rewriting a large fundamental part of GitLab,
-which might lead to many hard problems to solve. Changing some text in GitLab
-is probably 1, adding a new Git Hook maybe 4 or 5, big features 7-9.
+   Something that is 9 is rewriting a large fundamental part of GitLab,
+   which might lead to many hard problems to solve. Changing some text in GitLab
+   is probably 1, adding a new Git Hook maybe 4 or 5, big features 7-9.
 1. If something is very large, it should probably be split up in multiple
-issues or chunks. You can simply not set the weight of a parent issue and set
-weights to children issues.
+   issues or chunks. You can simply not set the weight of a parent issue and set
+   weights to children issues.
 
 ## Regression issues
 

doc/development/documentation/feature-change-workflow.md

@@ -7,16 +7,16 @@ description: How to add docs for new or enhanced GitLab features.
 At GitLab, developers contribute new or updated documentation along with their code, but product managers and technical writers also have essential roles in the process.
 
 - **Developers**: Author/update documentation in the same MR as their code, and
-merge it by the feature freeze for the assigned milestone. Request technical writer
-assistance if needed. Other developers typically act as reviewers.
+  merge it by the feature freeze for the assigned milestone. Request technical writer
+  assistance if needed. Other developers typically act as reviewers.
 - **Product Managers** (PMs): In the issue for all new and enhanced features,
-confirm the documentation requirements, plus the mentioned feature description
-and use cases, which can be reused in docs. They can bring in a technical
-writer for discussion or collaboration, and can be called upon themselves as a doc reviewer.
+  confirm the documentation requirements, plus the mentioned feature description
+  and use cases, which can be reused in docs. They can bring in a technical
+  writer for discussion or collaboration, and can be called upon themselves as a doc reviewer.
 - **Technical Writers**: Review doc requirements in issues, track issues and MRs
-that contain docs changes, help with any questions throughout the authoring/editing process,
-work on special projects related to the documentation, and review all new and updated
-docs content, whether before or after it is merged.
+  that contain docs changes, help with any questions throughout the authoring/editing process,
+  work on special projects related to the documentation, and review all new and updated
+  docs content, whether before or after it is merged.
 
 Beyond this process, any member of the GitLab community can also author or request documentation
 improvements that are not associated with a new or changed feature. See the [Documentation improvement workflow](improvement-workflow.md).
@@ -80,7 +80,7 @@ must:
 - Add the `Documentation` label.
 - Confirm or add the [documentation requirements](#documentation-requirements).
 - Ensure the issue contains any new or updated feature name, overview/description,
-and use cases, as required per the [documentation structure and template](structure.md), when applicable.
+  and use cases, as required per the [documentation structure and template](structure.md), when applicable.
 
 Everyone is encouraged to draft the requirements in the issue, but a product manager will
 do the following:
@@ -100,20 +100,20 @@ Follow the process below unless otherwise agreed with the product manager and te
 
 - Include any new and edited docs in the MR introducing the code.
 - Use the Documentation requirements confirmed by the Product Manager in the
-issue and discuss any further doc plans or ideas as needed.
+  issue and discuss any further doc plans or ideas as needed.
   - If the new or changed doc requires extensive collaboration or conversation, a separate,
-linked issue can be used for the planning process.
+  linked issue can be used for the planning process.
   - We are trying to avoid using a separate MR, so that the docs stay with the code, but the
-Technical Writing team is interested in discussing any potential exceptions that may be suggested.
+  Technical Writing team is interested in discussing any potential exceptions that may be suggested.
 - Use the [Documentation guidelines](index.md), as well as other resources linked from there,
-including the Documentation [Structure and template](structure.md) page, [Style Guide](styleguide.md), and [Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/). 
+  including the Documentation [Structure and template](structure.md) page, [Style Guide](styleguide.md), and [Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/).
 - If you need any help to choose the correct place for a doc, discuss a documentation
-idea or outline, or request any other help, ping the Technical Writer for the relevant
-[DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages)
-in your issue or MR, or write within `#docs` on the GitLab Slack.
+  idea or outline, or request any other help, ping the Technical Writer for the relevant
+  [DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages)
+  in your issue or MR, or write within `#docs` on the GitLab Slack.
 - The docs must be merged with the code **by the feature freeze date**, otherwise
-the feature cannot be included with the release. A policy for documenting feature-flagged
-issues is forthcoming and you are welcome to join the [discussion](https://gitlab.com/gitlab-org/gitlab-ce/issues/56813).
+  the feature cannot be included with the release. A policy for documenting feature-flagged
+  issues is forthcoming and you are welcome to join the [discussion](https://gitlab.com/gitlab-org/gitlab-ce/issues/56813).
 
 #### Reviews and merging
 
@@ -124,35 +124,35 @@ All reviewers can help ensure accuracy, clarity, completeness, and adherence to
    1. **The code reviewer** for the MR, to confirm accuracy, clarity, and completeness.
    1. Optionally: Others involved in the work, such as other devs or the PM.
    1. Optionally: The technical writer for the DevOps stage. If not prior to merging, the technical writer will review after the merge.
-This helps us ensure that the developer has time to merge good content by the freeze, and that it can be further refined by the release, if needed.
+      This helps us ensure that the developer has time to merge good content by the freeze, and that it can be further refined by the release, if needed.
       - To decide whether to request this review before the merge, consider the amount of time left before the code freeze, the size of the change,
-and your degree of confidence in having users of an RC use your docs as written.
+        and your degree of confidence in having users of an RC use your docs as written.
       - Pre-merge tech writer reviews should be most common when the code is complete well in advance of the freeze and/or for larger documentation changes.
       - You can request a review and if there is not sufficient time to complete it prior to the freeze,
-the maintainer can merge the current doc changes (if complete) and create a follow-up doc review issue.
+        the maintainer can merge the current doc changes (if complete) and create a follow-up doc review issue.
       - The technical writer can also help decide what docs to merge before the freeze and whether to work on further changes in a follow up MR.
       - **To request a pre-merge technical writer review**, assign the writer listed for the applicable [DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages).
       - **To request a post-merge technical writer review**, [create an issue for one using the Doc Review template](https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issuable_template=Doc%20Review) and link it from the MR that makes the doc change.
    1. **The maintainer** who is assigned to merge the MR, to verify clarity, completeness, and quality, to the best of their ability.
 
 - Upon merging, if a technical writer review has not been performed and there is not yet a linked issue for a follow-up review, the maintainer should [create an issue using the Doc Review template](https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issuable_template=Doc%20Review), link it from the MR, and
-mention the original MR author in the new issue. Alternatively, the mainitainer can ask the MR author to create and link this issue before the MR is merged.
+  mention the original MR author in the new issue. Alternatively, the mainitainer can ask the MR author to create and link this issue before the MR is merged.
 
 - After merging, documentation changes are reviewed by:
 
    1. The technical writer--**if** their review was not performed prior to the merge.
    2. Optionally: by the PM (for accuracy and to ensure it's consistent with the vision for how the product will be used).
-Any party can raise the item to the PM for review at any point: the dev, the technical writer, or the PM, who can request/plan a review at the outset.
+      Any party can raise the item to the PM for review at any point: the dev, the technical writer, or the PM, who can request/plan a review at the outset.
 
 ### Technical Writer role
 
 #### Planning
 
 - The technical writer monitors the documentation needs of issues assigned to the current and next milestone
-for their DevOps stage(s), and participates in any needed discussion on docs planning and requirements refinement
-with the dev, PM, and others.
+  for their DevOps stage(s), and participates in any needed discussion on docs planning and requirements refinement
+  with the dev, PM, and others.
 - The technical writer will review these requirements again upon the kickoff and provide feedback, as needed.
-This is not a blocking review and developers should not wait to work on docs.
+  This is not a blocking review and developers should not wait to work on docs.
 
 #### Collaboration
 
@@ -165,12 +165,12 @@ Additionally, technical writers are available for questions at any time.
 #### Review
 
 - Techncial writers provide non-blocking reviews of all documentation changes,
-before or after the change is merged. However, if the docs are ready in the MR while
-there's time before the freeze, the technical writer's review can commence early, on request.
+  before or after the change is merged. However, if the docs are ready in the MR while
+  there's time before the freeze, the technical writer's review can commence early, on request.
 - The technical writer will confirm that the doc is clear, grammatically correct,
-and discoverable, while avoiding redundancy, bad file locations, typos, broken links,
-etc. The technical writer will review the documentation for the following, which
-the developer and code reviewer should have already made a good-faith effort to ensure:
+  and discoverable, while avoiding redundancy, bad file locations, typos, broken links,
+  etc. The technical writer will review the documentation for the following, which
+  the developer and code reviewer should have already made a good-faith effort to ensure:
   - Clarity.
   - Adherence to the plans and goals in the issue.
   - Location (make sure the docs are in the correct directorkes and has the correct name).

doc/development/documentation/improvement-workflow.md

@@ -21,10 +21,10 @@ to accomplish their work with GitLab.
 ## How to update the docs
 
 1. Click "Edit this Page" at the bottom of any page on docs.gitlab.com, or navigate to
-one of the repositories and doc paths listed on the [GitLab Documentation guidelines](index.md) page.
-Work in a fork if you do not have developer access to the GitLab project.
+   one of the repositories and doc paths listed on the [GitLab Documentation guidelines](index.md) page.
+   Work in a fork if you do not have developer access to the GitLab project.
 1. Follow the described standards and processes listed on that Guidelines page,
-including the linked resources: the [Structure and template](structure.md) page, [Style Guide](styleguide.md), and [Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/). 
+   including the linked resources: the [Structure and template](structure.md) page, [Style Guide](styleguide.md), and [Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/).
 1. Follow GitLab's [Merge Request Guidelines](../contributing/merge_request_workflow.md#merge-request-guidelines).
 
 If you need any help to choose the correct place for a doc, discuss a documentation

doc/development/documentation/structure.md

@@ -20,7 +20,7 @@ Every feature or use case document should include the following content in the f
 with exceptions and details noted below and in the template included on this page.
 
 - **Title**: Top-level heading with the feature name, or a use case name, which would start with
-a verb, like Configuring, Enabling, etc.
+  a verb, like Configuring, Enabling, etc.
 - **Introduction**: A couple sentences about the subject matter and what's to be found on this page.
 - **Overview** Describe what it is, what it does, and in what context it should be used.
 - **Use cases**: describes real use case scenarios for that feature/configuration.

doc/development/fe_guide/development_process.md

@@ -61,17 +61,19 @@ Please use your best judgement when to use it and please contribute new points t
 ---
 
 ### Share your work early
+
 1. Before writing code, ensure your vision of the architecture is aligned with
-GitLab's architecture.
+   GitLab's architecture.
 1. Add a diagram to the issue and ask a frontend architect in the slack channel `#fe_architectural` about it.
 
   ![Diagram of Issue Boards Architecture](img/boards_diagram.png)
 
 1. Don't take more than one week between starting work on a feature and
-sharing a Merge Request with a reviewer or a maintainer.
+   sharing a Merge Request with a reviewer or a maintainer.
 
 ### Vue features
+
 1. Follow the steps in [Vue.js Best Practices](vue.md)
 1. Follow the style guide.
 1. Only a handful of people are allowed to merge Vue related features.
-Reach out to one of Vue experts early in this process.
+   Reach out to one of Vue experts early in this process.

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

@@ -9,7 +9,7 @@ Add the `Filter` object to the plugins array of a `DropLab.prototype.init` or `D
 
 - `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.
+  to the user input string, for filtering.
 
 ```html
 <input href="#" id="trigger" data-dropdown-trigger="#list">

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

@@ -9,7 +9,7 @@ Add the `InputSetter` object to the plugins array of a `DropLab.prototype.init`
 - `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.
+  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/performance.md

@@ -5,6 +5,7 @@
 ### Realtime Components
 
 When writing code for realtime features we have to keep a couple of things in mind:
+
 1. Do not overload the server with requests.
 1. It should feel realtime.
 
@@ -12,16 +13,16 @@ Thus, we must strike a balance between sending requests and the feeling of realt
 Use the following rules when creating realtime solutions.
 
 1. The server will tell you how much to poll by sending `Poll-Interval` in the header.
-Use that as your polling interval. This way it is [easy for system administrators to change the
-polling rate](../../administration/polling.md).
-A `Poll-Interval: -1` means you should disable polling, and this must be implemented.
+   Use that as your polling interval. This way it is [easy for system administrators to change the
+   polling rate](../../administration/polling.md).
+   A `Poll-Interval: -1` means you should disable polling, and this must be implemented.
 1. A response with HTTP status different from 2XX should disable polling as well.
 1. Use a common library for polling.
 1. Poll on active tabs only. Please use [Visibility](https://github.com/ai/visibilityjs).
 1. Use regular polling intervals, do not use backoff polling, or jitter, as the interval will be
-controlled by the server.
+   controlled by the server.
 1. The backend code will most likely be using etags. You do not and should not check for status
-`304 Not Modified`. The browser will transform it for you.
+   `304 Not Modified`. The browser will transform it for you.
 
 ### Lazy Loading Images
 

doc/development/fe_guide/style_guide_js.md

@@ -14,9 +14,9 @@ See [our current .eslintrc](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/
 #### ESlint
 
 1. **Never** disable eslint rules unless you have a good reason.
-You may see a lot of legacy files with `/* eslint-disable some-rule, some-other-rule */`
-at the top, but legacy files are a special case.  Any time you develop a new feature or
-refactor an existing one, you should abide by the eslint rules.
+   You may see a lot of legacy files with `/* eslint-disable some-rule, some-other-rule */`
+   at the top, but legacy files are a special case.  Any time you develop a new feature or
+   refactor an existing one, you should abide by the eslint rules.
 
 1. **Never Ever EVER** disable eslint globally for a file
 
@@ -53,7 +53,7 @@ refactor an existing one, you should abide by the eslint rules.
    1. [class-methods-use-this][eslint-this]
 
 1. When they are needed _always_ place ESlint directive comment blocks on the first line of a script,
-followed by any global declarations, then a blank newline prior to any imports or code.
+   followed by any global declarations, then a blank newline prior to any imports or code.
 
     ```javascript
       // bad
@@ -125,8 +125,8 @@ followed by any global declarations, then a blank newline prior to any imports o
     ```
 
 1. Relative paths: when importing a module in the same directory, a child
-directory, or an immediate parent directory prefer relative paths.  When
-importing a module which is two or more levels up, prefer either `~/` or `ee/`.
+   directory, or an immediate parent directory prefer relative paths.  When
+   importing a module which is two or more levels up, prefer either `~/` or `ee/`.
 
     In **app/assets/javascripts/my-feature/subdir**:
 
@@ -163,9 +163,9 @@ importing a module which is two or more levels up, prefer either `~/` or `ee/`.
     ```
 
 1. Avoid using IIFE. Although we have a lot of examples of files which wrap their
-contents in IIFEs (immediately-invoked function expressions),
-this is no longer necessary after the transition from Sprockets to webpack.
-Do not use them anymore and feel free to remove them when refactoring legacy code.
+   contents in IIFEs (immediately-invoked function expressions),
+   this is no longer necessary after the transition from Sprockets to webpack.
+   Do not use them anymore and feel free to remove them when refactoring legacy code.
 
 1. Avoid adding to the global namespace.
     ```javascript
@@ -484,8 +484,8 @@ Please check this [rules][eslint-plugin-vue-rules] for more documentation.
     ```
 
 1. Default key should be provided if the prop is not required.
-_Note:_ There are some scenarios where we need to check for the existence of the property.
-On those a default key should not be provided.
+   _Note:_ There are some scenarios where we need to check for the existence of the property.
+   On those a default key should not be provided.
 
     ```javascript
       // good

doc/development/fe_guide/vue.md

@@ -223,6 +223,7 @@ need to test the rendered output. [Vue][vue-test] guide's to unit test show us e
 
 ## Vue.js Expert Role
 One should apply to be a Vue.js expert by opening an MR when the Merge Request's they create and review show:
+
 - Deep understanding of Vue and Vuex reactivy
 - Vue and Vuex code are structured according to both official and our guidelines
 - Full understanding of testing a Vue and Vuex application

doc/development/logging.md

@@ -32,8 +32,8 @@ These logs suffer from a number of problems:
 1. They often lack timestamps or other contextual information (e.g. project ID, user)
 2. They may span multiple lines, which make them hard to find via Elasticsearch.
 3. They lack a common structure, which make them hard to parse by log
-forwarders, such as Logstash or Fluentd. This also makes them hard to
-search.
+   forwarders, such as Logstash or Fluentd. This also makes them hard to
+   search.
 
 Note that currently on GitLab.com, any messages in `production.log` will
 NOT get indexed by Elasticsearch due to the sheer volume and noise. They
@@ -61,12 +61,12 @@ importer. You want to log issues created, merge requests, etc. as the
 importer progresses. Here's what to do:
 
 1. Look at [the list of GitLab Logs](../administration/logs.md) to see
-if your log message might belong with one of the existing log files.
+   if your log message might belong with one of the existing log files.
 1. If there isn't a good place, consider creating a new filename, but
-check with a maintainer if it makes sense to do so. A log file should
-make it easy for people to search pertinent logs in one place. For
-example, `geo.log` contains all logs pertaining to GitLab Geo.
-To create a new file:
+   check with a maintainer if it makes sense to do so. A log file should
+   make it easy for people to search pertinent logs in one place. For
+   example, `geo.log` contains all logs pertaining to GitLab Geo.
+   To create a new file:
     1. Choose a filename (e.g. `importer_json.log`).
     1. Create a new subclass of `Gitlab::JsonLogger`:
 
@@ -130,15 +130,15 @@ To create a new file:
 ## Additional steps with new log files
 
 1. Consider log retention settings. By default, Omnibus will rotate any
-logs in `/var/log/gitlab/gitlab-rails/*.log` every hour and [keep at
-most 30 compressed files](https://docs.gitlab.com/omnibus/settings/logs.html#logrotate).
-On GitLab.com, that setting is only 6 compressed files. These settings should suffice
-for most users, but you may need to tweak them in [omnibus-gitlab](https://gitlab.com/gitlab-org/omnibus-gitlab).
+   logs in `/var/log/gitlab/gitlab-rails/*.log` every hour and [keep at
+   most 30 compressed files](https://docs.gitlab.com/omnibus/settings/logs.html#logrotate).
+   On GitLab.com, that setting is only 6 compressed files. These settings should suffice
+   for most users, but you may need to tweak them in [omnibus-gitlab](https://gitlab.com/gitlab-org/omnibus-gitlab).
 
 1. If you add a new file, submit an issue to the [production
-tracker](https://gitlab.com/gitlab-com/gl-infra/production/issues) or
-a merge request to the [gitlab_fluentd](https://gitlab.com/gitlab-cookbooks/gitlab_fluentd)
-project. See [this example](https://gitlab.com/gitlab-cookbooks/gitlab_fluentd/merge_requests/51/diffs).
+   tracker](https://gitlab.com/gitlab-com/gl-infra/production/issues) or
+   a merge request to the [gitlab_fluentd](https://gitlab.com/gitlab-cookbooks/gitlab_fluentd)
+   project. See [this example](https://gitlab.com/gitlab-cookbooks/gitlab_fluentd/merge_requests/51/diffs).
 
 1. Be sure to update the [GitLab CE/EE documentation](../administration/logs.md) and the [GitLab.com
-runbooks](https://gitlab.com/gitlab-com/runbooks/blob/master/howto/logging.md).
+   runbooks](https://gitlab.com/gitlab-com/runbooks/blob/master/howto/logging.md).

doc/development/new_fe_guide/development/accessibility.md

@@ -15,6 +15,7 @@ Check the list of WAI-ARIA roles [here][roles]
 When using icons or images that aren't absolutely needed to understand the context, we should use `aria-hidden="true"`.
 
 On the other hand, if an icon is crucial to understand the context we should do one of the following:
+
 1. Use `aria-label` in the element with a meaningful description
 1. Use `aria-labelledby` to point to an element that contains the explanation for that icon
 

doc/development/new_fe_guide/style/html.md

@@ -3,6 +3,7 @@
 ## Buttons
 
 <a name="button-type"></a><a name="1.1"></a>
+
 - [1.1](#button-type) **Use button type** Button tags requires a `type` attribute according to the [W3C HTML specification][button-type-spec].
 
 ```
@@ -14,6 +15,7 @@
 ```
 
 <a name="button-role"></a><a name="1.2"></a>
+
 - [1.2](#button-role) **Use button role for non buttons** If an HTML element has an onClick handler but is not a button, it should have `role="button"`. This is more [accessible][button-role-accessible].
 
 ```
@@ -27,6 +29,7 @@
 ## Links
 
 <a name="blank-links"></a><a name="2.1"></a>
+
 - [2.1](#blank-links) **Use rel for target blank** Use `rel="noopener noreferrer"` whenever your links open in a new window i.e. `target="_blank"`. This prevents [the following][jitbit-target-blank] security vulnerability documented by JitBit
 
 ```
@@ -38,6 +41,7 @@
 ```
 
 <a name="fake-links"></a><a name="2.2"></a>
+
 - [2.2](#fake-links) **Do not use fake links** Use a button tag if a link only invokes JavaScript click event handlers. This is more semantic.
 
 ```

doc/development/new_fe_guide/style/javascript.md

@@ -10,6 +10,7 @@ You can run eslint locally by running `yarn eslint`
 ## Arrays
 
 <a name="avoid-foreach"></a><a name="1.1"></a>
+
 - [1.1](#avoid-foreach) **Avoid ForEach when mutating data** Use `map`, `reduce` or `filter` instead of `forEach` when mutating data. This will minimize mutations in functions ([which is aligned with Airbnb's style guide][airbnb-minimize-mutations])
 
     ```
@@ -27,6 +28,7 @@ You can run eslint locally by running `yarn eslint`
 ## Functions
 
 <a name="limit-params"></a><a name="2.1"></a>
+
 - [2.1](#limit-params) **Limit number of parameters** If your function or method has more than 3 parameters, use an object as a parameter instead.
 
     ```
@@ -44,6 +46,7 @@ You can run eslint locally by running `yarn eslint`
 ## Classes & constructors
 
 <a name="avoid-constructor-side-effects"></a><a name="3.1"></a>
+
 - [3.1](#avoid-constructor-side-effects) **Avoid side effects in constructors** Avoid making some operations in the `constructor`, such as asynchronous calls, API requests and DOM manipulations. Prefer moving them into separate functions. This will make tests easier to write and code easier to maintain.
 
     ```javascript
@@ -71,6 +74,7 @@ You can run eslint locally by running `yarn eslint`
     ```
 
 <a name="avoid-classes-to-handle-dom-events"></a><a name="3.2"></a>
+
 - [3.2](#avoid-classes-to-handle-dom-events) **Avoid classes to handle DOM events** If the only purpose of the class is to bind a DOM event and handle the callback, prefer using a function.
 
     ```
@@ -95,8 +99,9 @@ You can run eslint locally by running `yarn eslint`
     ```
 
 <a name="element-container"></a><a name="3.3"></a>
+
 - [3.3](#element-container) **Pass element container to constructor** When your class manipulates the DOM, receive the element container as a parameter.
-This is more maintainable and performant.
+  This is more maintainable and performant.
 
     ```
     // bad
@@ -117,6 +122,7 @@ This is more maintainable and performant.
 ## Type Casting & Coercion
 
 <a name="use-parseint"></a><a name="4.1"></a>
+
 - [4.1](#use-parseint) **Use ParseInt** Use `ParseInt` when converting a numeric string into a number.
 
     ```
@@ -130,6 +136,7 @@ This is more maintainable and performant.
 ## CSS Selectors
 
 <a name="use-js-prefix"></a><a name="5.1"></a>
+
 - [5.1](#use-js-prefix) **Use js prefix** If a CSS class is only being used in JavaScript as a reference to the element, prefix the class name with `js-`
 
     ```
@@ -143,6 +150,7 @@ This is more maintainable and performant.
 ## Modules
 
 <a name="use-absolute-paths"></a><a name="6.1"></a>
+
 - [6.1](#use-absolute-paths) **Use absolute paths for nearby modules** Use absolute paths if the module you are importing is less than two levels up.
 
     ```
@@ -154,6 +162,7 @@ This is more maintainable and performant.
     ```
 
 <a name="use-relative-paths"></a><a name="6.2"></a>
+
 - [6.2](#use-relative-paths) **Use relative paths for distant modules** If the module you are importing is two or more levels up, use a relative path instead of an absolute path.
 
     ```
@@ -165,22 +174,27 @@ This is more maintainable and performant.
     ```
 
 <a name="global-namespace"></a><a name="6.3"></a>
+
 - [6.3](#global-namespace) **Do not add to global namespace**
 
 <a name="domcontentloaded"></a><a name="6.4"></a>
+
 - [6.4](#domcontentloaded) **Do not use DOMContentLoaded in non-page modules** Imported modules should act the same each time they are loaded. `DOMContentLoaded` events are only allowed on modules loaded in the `/pages/*` directory because those are loaded dynamically with webpack.
 
 ## Security
 
 <a name="avoid-xss"></a><a name="7.1"></a>
+
 - [7.1](#avoid-xss) **Avoid XSS** Do not use `innerHTML`, `append()` or `html()` to set content. It opens up too many vulnerabilities.
 
 ## ESLint
 
 <a name="disable-eslint-file"></a><a name="8.1"></a>
+
 - [8.1](#disable-eslint-file) **Disabling ESLint in new files** Do not disable ESLint when creating new files. Existing files may have existing rules disabled due to legacy compatibility reasons but they are in the process of being refactored.
 
 <a name="disable-eslint-rule"></a><a name="8.2"></a>
+
 - [8.2](#disable-eslint-rule) **Disabling ESLint rule** Do not disable specific ESLint rules. Due to technical debt, you may disable the following rules only if you are invoking/instantiating existing code modules
 
   - [no-new][no-new]

doc/development/policies.md

@@ -88,10 +88,10 @@ An example debug output would look as follows:
 Each line represents a rule that was evaluated. There are a few things to note:
 
 1. The `-` or `+` symbol indicates whether the rule block was evaluated to be
-`false` or `true`, respectively.
+   `false` or `true`, respectively.
 2. The number inside the brackets indicates the score.
 3. The last part of the line (e.g. `@john : Issue/1`) shows the username
-and subject for that rule.
+   and subject for that rule.
 
 Here you can see that the first four rules were evaluated `false` for
 which user and subject. For example, you can see in the last line that

doc/development/polling.md

@@ -51,6 +51,7 @@ request path. By doing this we avoid query parameter ordering problems and make
 route matching easier.
 
 For more information see:
+
 - [`Poll-Interval` header](fe_guide/performance.md#realtime-components)
 - [RFC 7232](https://tools.ietf.org/html/rfc7232)
 - [ETag proposal](https://gitlab.com/gitlab-org/gitlab-ce/issues/26926)

doc/development/rake_tasks.md

@@ -73,6 +73,7 @@ To make sure that indices still fit. You could find great details in:
 ## Run tests
 
 In order to run the test you can use the following commands:
+
 - `rake spec` to run the rspec suite
 - `rake karma` to run the karma test suite
 - `rake gitlab:test` to run all the tests

doc/development/testing_guide/end_to_end_tests.md

@@ -41,24 +41,24 @@ Currently, we are using _multi-project pipeline_-like approach to run QA
 pipelines.
 
 1. Developer triggers a manual action, that can be found in CE / EE merge
-requests. This starts a chain of pipelines in multiple projects.
+   requests. This starts a chain of pipelines in multiple projects.
 
 1. The script being executed triggers a pipeline in [Omnibus GitLab][omnibus-gitlab]
-and waits for the resulting status. We call this a _status attribution_.
+   and waits for the resulting status. We call this a _status attribution_.
 
 1. GitLab packages are being built in the [Omnibus GitLab][omnibus-gitlab]
-pipeline. Packages are then pushed to its Container Registry.
+   pipeline. Packages are then pushed to its Container Registry.
 
 1. When packages are ready, and available in the registry, a final step in the
-[Omnibus GitLab][omnibus-gitlab] pipeline, triggers a new
-[GitLab QA pipeline][gitlab-qa-pipelines]. It also waits for a resulting status.
+   [Omnibus GitLab][omnibus-gitlab] pipeline, triggers a new
+   [GitLab QA pipeline][gitlab-qa-pipelines]. It also waits for a resulting status.
 
 1. GitLab QA pulls images from the registry, spins-up containers and runs tests
-against a test environment that has been just orchestrated by the `gitlab-qa`
-tool.
+   against a test environment that has been just orchestrated by the `gitlab-qa`
+   tool.
 
 1. The result of the [GitLab QA pipeline][gitlab-qa-pipelines] is being
-propagated upstream, through Omnibus, back to the CE / EE merge request.
+   propagated upstream, through Omnibus, back to the CE / EE merge request.
 
 #### How do I write tests?
 

doc/install/azure/index.md

@@ -21,14 +21,14 @@ First, you'll need an account on Azure. There are three ways to do this:
 
 - If your company (or you) already has an account, then you are ready to go!
 - You can also open your own Azure account for free. _At time of writing_, you get $200
-of credit to spend on Azure services for 30 days. You can use this credit to try out paid Azure
-services, exploring Microsoft's cloud for free. Even after the first 30 days, you never have to pay
-anything unless you decide to transition to paid services with a Pay-As-You-Go Azure subscription.
-This is a great way to try out Azure and cloud computing, and you can
-[read more in their comprehensive FAQ][Azure-Free-Account-FAQ].
+  of credit to spend on Azure services for 30 days. You can use this credit to try out paid Azure
+  services, exploring Microsoft's cloud for free. Even after the first 30 days, you never have to pay
+  anything unless you decide to transition to paid services with a Pay-As-You-Go Azure subscription.
+  This is a great way to try out Azure and cloud computing, and you can
+  [read more in their comprehensive FAQ][Azure-Free-Account-FAQ].
 - If you have an MSDN subscription, you can activate your Azure subscriber benefits. Your MSDN
-subscription gives you recurring Azure credits every month, so why not put those credits to use and
-try out GitLab right now?
+  subscription gives you recurring Azure credits every month, so why not put those credits to use and
+  try out GitLab right now?
 
 ## Working with Azure
 
@@ -216,10 +216,10 @@ Like all servers, our VM will be running many services. However, we want to open
 ports to enable public internet access to two services in particular:
 
 1. **HTTP** (port 80) - opening port 80 will enable our VM to respond to HTTP requests, allowing
-public access to the instance of GitLab running on our VM.
+   public access to the instance of GitLab running on our VM.
 1. **SSH** (port 22) - opening port 22 will enable our VM to respond to SSH connection requests,
-allowing public access (with authentication) to remote terminal sessions
-_(you'll see why we need [SSH] access to our VM [later on in this tutorial](#maintaining-your-gitlab-instance))_
+   allowing public access (with authentication) to remote terminal sessions
+   _(you'll see why we need [SSH] access to our VM [later on in this tutorial](#maintaining-your-gitlab-instance))_
 
 ### Open HTTP on Port 80
 

doc/install/kubernetes/preparation/eks.md

@@ -5,6 +5,7 @@ There are a few nuances to Amazon EKS which are important to be aware of, when d
 ## Persistent volume management
 
 There are two methods to manage volume claims on Kubernetes:
+
 1. Manually creating each persistent volume (recommended on EKS)
 1. Utilizing dynamic provisioning to automatically create the persistent volumes
 

doc/integration/README.md

@@ -12,7 +12,7 @@ See the documentation below for details on how to configure these services.
 - [Akismet](akismet.md) Configure Akismet to stop spam
 - [Auth0 OmniAuth](auth0.md) Enable the Auth0 OmniAuth provider
 - [Bitbucket](bitbucket.md) Import projects from Bitbucket.org and login to your GitLab instance with your
-Bitbucket.org account
+  Bitbucket.org account
 - [CAS](cas.md) Configure GitLab to sign in using CAS
 - [External issue tracker](external-issue-tracker.md) Redmine, JIRA, etc.
 - [Gmail actions buttons](gmail_action_buttons_for_gitlab.md) Adds GitLab actions to messages

doc/integration/auth0.md

@@ -4,18 +4,18 @@ To enable the Auth0 OmniAuth provider, you must create an Auth0 account, and an
 application.
 
 1. Sign in to the [Auth0 Console](https://auth0.com/auth/login). If you need to
-create an account, you can do so at the same link.
+   create an account, you can do so at the same link.
 
 1. Select "New App/API".
 
 1. Provide the Application Name ('GitLab' works fine).
 
 1. Once created, you should see the Quick Start options. Disregard them and
-select 'Settings' above the Quick Start options.
+   select 'Settings' above the Quick Start options.
 
 1. At the top of the Settings screen, you should see your Domain, Client ID and
-Client Secret. Take note of these as you'll need to put them in the
-configuration file. For example:
+   Client Secret. Take note of these as you'll need to put them in the
+   configuration file. For example:
     - Domain: `test1234.auth0.com`
     - Client ID: `t6X8L2465bNePWLOvt9yi41i`
     - Client Secret: `KbveM3nqfjwCbrhaUy_gDu2dss8TIlHIdzlyf33pB7dEK5u_NyQdp65O_o02hXs2`
@@ -44,7 +44,7 @@ configuration file. For example:
     ```
 
 1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration)
-for initial settings.
+   for initial settings.
 
 1. Add the provider configuration:
 
@@ -76,10 +76,10 @@ for initial settings.
     ```
 
 1. Change `YOUR_AUTH0_CLIENT_ID` to the client ID from the Auth0 Console page
-from step 5.
+   from step 5.
 
 1. Change `YOUR_AUTH0_CLIENT_SECRET` to the client secret from the Auth0 Console
-page from step 5.
+   page from step 5.
 
 1.  [Reconfigure][] or [restart GitLab][] for the changes to take effect if you
     installed GitLab via Omnibus or from source respectively.

doc/integration/facebook.md

@@ -9,7 +9,7 @@ To enable the Facebook OmniAuth provider you must register your application with
 1. Select the type "Website"
 
 1. Enter a name for your app. This can be anything. Consider something like "<Organization>'s GitLab" or "<Your Name>'s GitLab" or
-something else descriptive.
+   something else descriptive.
 
 1. Choose "Create New Facebook App ID"
 

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

@@ -125,10 +125,10 @@ image below we have the settings for this article but note the
 following two options which are of particular interest for HA:
 
 1. Multi-AZ-Deployment is recommended as redundancy. Read more at
-[High Availability (Multi-AZ)](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+   [High Availability (Multi-AZ)](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
 1. While we chose a General Purpose (SSD) for this article a Provisioned
-IOPS (SSD) is best suited for HA. Read more about it at
-[Storage for Amazon RDS](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html)
+   IOPS (SSD) is best suited for HA. Read more about it at
+   [Storage for Amazon RDS](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html)
 
 ![RDS Instance Specs](img/instance_specs.png)
 

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

@@ -86,6 +86,7 @@ git config --global user.email you@example.com
 ```bash
 git config --global --list
 ```
+
 - You might want or be required to use an SSH key.
     - Instructions: [SSH](http://doc.gitlab.com/ce/ssh/README.html)
 
@@ -413,6 +414,7 @@ Revert is safer considering we can revert a revert
 ---
 
 ### Version Control
+
  - Local VCS was used with a filesystem or a simple db.
  - Centralized VCS such as Subversion includes collaboration but
    still is prone to data loss as the main server is the single point of

doc/university/training/topics/stash.md

@@ -30,7 +30,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
-stashes.
+  stashes.
 
     ```
     git stash list

doc/update/mysql_to_postgresql.md

@@ -95,7 +95,7 @@ Now, you can use pgloader to migrate the data from MySQL to PostgreSQL:
     ```
 
 1. Once the migration finishes, you should see a summary table that looks like
-the following:
+   the following:
 
     ```
                                      table name       read   imported     errors      total time
@@ -242,7 +242,7 @@ Now, you can use pgloader to migrate the data from MySQL to PostgreSQL:
     ```
 
 1. Once the migration finishes, you should see a summary table that looks like
-the following:
+   the following:
 
     ```
                                      table name       read   imported     errors      total time

doc/user/discussions/index.md

@@ -248,10 +248,10 @@ For large projects with many contributors, it may be useful to stop discussions
 in issues or merge requests in these scenarios:
 
 - The project maintainer has already resolved the discussion and it is not helpful
-for continued feedback. The project maintainer has already directed new conversation
-to newer issues or merge requests.
+  for continued feedback. The project maintainer has already directed new conversation
+  to newer issues or merge requests.
 - The people participating in the discussion are trolling, abusive, or otherwise
-being unproductive.
+  being unproductive.
 
 In these cases, a user with Developer permissions or higher in the project can lock (and unlock)
 an issue or a merge request, using the "Lock" section in the sidebar. For issues,
@@ -284,7 +284,7 @@ finding useful information can be hard. There is a way to filter comments from s
 From a merge request's **Discussion** tab, or from an epic/issue overview, find the filter's dropdown menu on the right side of the page, from which you can choose one of the following options:
 
 - **Show all activity**: displays all user comments and system notes
-(issue updates, mentions from other issues, changes to the description, etc).
+  (issue updates, mentions from other issues, changes to the description, etc).
 - **Show comments only**: only displays user comments in the list.
 - **Show history only**: only displays activity notes.
 
@@ -306,7 +306,7 @@ suggestions with a click, which will generate a commit in
 the Merge Request authored by the user that applied them.
 
 1. Choose a line of code to be changed, add a new comment, then click
-on the **Insert suggestion** icon in the toolbar:
+   on the **Insert suggestion** icon in the toolbar:
 
     ![Add a new comment](img/insert_suggestion.png)
 

doc/user/group/index.md

@@ -18,9 +18,9 @@ a link to the group settings. By clicking the last button you can leave that gro
 You can create groups for numerous reasons. To name a few:
 
 - Organize related projects under the same [namespace](#namespaces), add members to that
-group and grant access to all their projects at once
+  group and grant access to all their projects at once
 - Create a group, include members of your team, and make it easier to
-`@mention` all the team at once in issues and merge requests
+  `@mention` all the team at once in issues and merge requests
   - Create a group for your company members, and create [subgroups](subgroups/index.md)
     for each individual team. Let's say you create a group called `company-team`, and among others,
     you created subgroups in this group for each individual team `backend-team`,
@@ -43,11 +43,11 @@ In GitLab, a namespace is a unique name to be used as a user name, a group name,
 For example, consider a user named Alex:
 
 1. Alex creates an account on GitLab.com with the username `alex`;
-their profile will be accessed under `https://gitlab.example.com/alex`
+   their profile will be accessed under `https://gitlab.example.com/alex`
 1. Alex creates a group for their team with the groupname `alex-team`;
-the group and its projects will be accessed under `https://gitlab.example.com/alex-team`
+   the group and its projects will be accessed under `https://gitlab.example.com/alex-team`
 1. Alex creates a subgroup of `alex-team` with the subgroup name `marketing`;
-this subgroup and its projects will be accessed under `https://gitlab.example.com/alex-team/marketing`
+   this subgroup and its projects will be accessed under `https://gitlab.example.com/alex-team/marketing`
 
 By doing so:
 
@@ -107,7 +107,7 @@ Consider we have a group with two projects:
 
 - On the **Group Members** page we can now add a new user to the group.
 - Now because this user is a **Developer** member of the group, he automatically
-gets **Developer** access to **all projects** within that group.
+  gets **Developer** access to **all projects** within that group.
 
 If necessary, you can increase the access level of an individual user for a specific project,
 by adding them again as a new member to the project with the new permission levels.
@@ -267,9 +267,9 @@ Define project templates at a group-level by setting a group as a template sourc
 ### Advanced settings
 
 - **Projects**: view all projects within that group, add members to each project,
-access each project's settings, and remove any project from the same screen.
+  access each project's settings, and remove any project from the same screen.
 - **Webhooks**: configure [webhooks](../project/integrations/webhooks.md) to your group.
 - **Kubernetes cluster integration**: connect your GitLab group with [Kubernetes clusters](clusters/index.md).
 - **Audit Events**: view [Audit Events](https://docs.gitlab.com/ee/administration/audit_events.html#audit-events)
-for the group. **[STARTER ONLY]**
+  for the group. **[STARTER ONLY]**
 - **Pipelines quota**: keep track of the [pipeline quota](../admin_area/settings/continuous_integration.md) for the group.

doc/user/index.md

@@ -38,10 +38,10 @@ GitLab is a Git-based platform that integrates a great number of essential tools
 
 - Hosting code in repositories with version control
 - Tracking proposals for new implementations, bug reports, and feedback with a
-fully featured [Issue Tracker](project/issues/index.md#issue-tracker)
+  fully featured [Issue Tracker](project/issues/index.md#issue-tracker)
 - Organizing and prioritizing with [Issue Boards](project/issues/index.md#issue-boards)
 - Reviewing code in [Merge Requests](project/merge_requests/index.md) with live-preview changes per
-branch with [Review Apps](../ci/review_apps/index.md)
+  branch with [Review Apps](../ci/review_apps/index.md)
 - Building, testing and deploying with built-in [Continuous Integration](../ci/README.md)
 - Deploying personal and professional static websites with [GitLab Pages](project/pages/index.md)
 - Integrating with Docker by using [GitLab Container Registry](project/container_registry.md)
@@ -51,9 +51,9 @@ With GitLab Enterprise Edition, you can also:
 
 - Provide support with [Service Desk](https://docs.gitlab.com/ee/user/project/service_desk.html)
 - Improve collaboration with
-[Merge Request Approvals](https://docs.gitlab.com/ee/user/project/merge_requests/index.html#merge-request-approvals),
-[Multiple Assignees for Issues](https://docs.gitlab.com/ee/user/project/issues/multiple_assignees_for_issues.html),
-and [Multiple Issue Boards](https://docs.gitlab.com/ee/user/project/issue_board.html#multiple-issue-boards)
+  [Merge Request Approvals](https://docs.gitlab.com/ee/user/project/merge_requests/index.html#merge-request-approvals),
+  [Multiple Assignees for Issues](https://docs.gitlab.com/ee/user/project/issues/multiple_assignees_for_issues.html),
+  and [Multiple Issue Boards](https://docs.gitlab.com/ee/user/project/issue_board.html#multiple-issue-boards)
 - Create formal relationships between issues with [Related Issues](https://docs.gitlab.com/ee/user/project/issues/related_issues.html)
 - Use [Burndown Charts](https://docs.gitlab.com/ee/user/project/milestones/burndown_charts.html) to track progress during a sprint or while working on a new version of their software.
 - Leverage [Elasticsearch](https://docs.gitlab.com/ee/integration/elasticsearch.html) with [Advanced Global Search](https://docs.gitlab.com/ee/user/search/advanced_global_search.html) and [Advanced Syntax Search](https://docs.gitlab.com/ee/user/search/advanced_search_syntax.html) for faster, more advanced code search across your entire GitLab instance
@@ -77,12 +77,12 @@ build, test, and deploy your app with built-in GitLab CI/CD. Or, you can do
 it all at once, from one single project.
 
 - [Repositories](project/repository/index.md): Host your codebase in
-repositories with version control and as part of a fully integrated platform.
+  repositories with version control and as part of a fully integrated platform.
 - [Issues](project/issues/index.md): Explore the best of GitLab Issues' features.
 - [Merge Requests](project/merge_requests/index.md): Collaborate on code,
-reviews, live preview changes per branch, and request approvals with Merge Requests.
+  reviews, live preview changes per branch, and request approvals with Merge Requests.
 - [Milestones](project/milestones/index.md): Work on multiple issues and merge
-requests towards the same target date with Milestones.
+  requests towards the same target date with Milestones.
 
 ## GitLab CI/CD
 
@@ -92,9 +92,9 @@ directly from GitLab. No third-party integrations needed.
 - [GitLab Auto Deploy](../ci/autodeploy/index.md): Deploy your application out-of-the-box with GitLab Auto Deploy.
 - [Review Apps](../ci/review_apps/index.md): Live-preview the changes introduced by a merge request with Review Apps.
 - [GitLab Pages](project/pages/index.md): Publish your static site directly from
-GitLab with GitLab Pages. You can build, test, and deploy any Static Site Generator with Pages.
+  GitLab with GitLab Pages. You can build, test, and deploy any Static Site Generator with Pages.
 - [GitLab Container Registry](project/container_registry.md): Build and deploy Docker
-images with Container Registry.
+  images with Container Registry.
 
 ## Account
 
@@ -102,13 +102,13 @@ There is a lot you can customize and configure
 to enjoy the best of GitLab.
 
 - [Settings](profile/index.md): Manage your user settings to change your personal info,
-personal access tokens, authorized applications, etc.
+  personal access tokens, authorized applications, etc.
 - [Authentication](../topics/authentication/index.md): Read through the authentication
-methods available in GitLab.
+  methods available in GitLab.
 - [Permissions](permissions.md): Learn the different set of permissions levels for each
-user type (guest, reporter, developer, maintainer, owner).
+  user type (guest, reporter, developer, maintainer, owner).
 - [Feature highlight](feature_highlight.md): Learn more about the little blue dots
-around the app that explain certain features
+  around the app that explain certain features
 - [Abuse reports](abuse_reports.md): Report abuse from users to GitLab administrators
 
 ## Groups

doc/user/profile/account/two_factor_authentication.md

@@ -41,7 +41,7 @@ or a U2F device.
 **On your phone:**
 
 1. Install a compatible application. We recommend [Google Authenticator]
-\(proprietary\) or [FreeOTP] \(open source\).
+   \(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.

doc/user/profile/index.md

@@ -35,13 +35,13 @@ From there, you can:
 - Manage [2FA](account/two_factor_authentication.md)
 - Change your username and [delete your account](account/delete_account.md)
 - Manage applications that can
-[use GitLab as an OAuth provider](../../integration/oauth_provider.md#introduction-to-oauth)
+  [use GitLab as an OAuth provider](../../integration/oauth_provider.md#introduction-to-oauth)
 - Manage [personal access tokens](personal_access_tokens.md) to access your account via API and authorized applications
 - Add and delete emails linked to your account
 - Choose which email to use for notifications, web-based commits, and display on your public profile
 - Manage [SSH keys](../../ssh/README.md#ssh) to access your account via SSH
 - Manage your [preferences](preferences.md#syntax-highlighting-theme)
-to customize your own GitLab experience
+  to customize your own GitLab experience
 - [View your active sessions](active_sessions.md) and revoke any of them if necessary
 - Access your audit log, a security log of important events involving your account
 

doc/user/project/cycle_analytics.md

@@ -80,6 +80,7 @@ Here's a little explanation of how this works behind the scenes:
 
 To sum up, anything that doesn't follow the [GitLab flow] won't be tracked at all.
 So, the Cycle Analytics dashboard won't present any data:
+
 - For merge requests that do not close an issue.
 - For issues not labeled with a label present in the Issue Board.
 - For issues not assigned a milestone.

doc/user/project/import/bitbucket_server.md

@@ -22,14 +22,14 @@ Import your projects from Bitbucket Server to GitLab with minimal effort.
 ## Limitations
 
 1. Currently GitLab doesn't allow comments on arbitrary lines of code, so any
-Bitbucket comments out of bounds will be inserted as comments in the merge
-request.
+   Bitbucket comments out of bounds will be inserted as comments in the merge
+   request.
 1. Bitbucket Server allows multiple levels of threading. GitLab
-import will collapse this into one discussion and quote part of the original
-comment.
+   import will collapse this into one discussion and quote part of the original
+   comment.
 1. Declined pull requests have unreachable commits, which prevents the GitLab
-importer from generating a proper diff. These pull requests will show up as
-empty changes.
+   importer from generating a proper diff. These pull requests will show up as
+   empty changes.
 1. Attachments in Markdown are currently not imported.
 1. Task lists are not imported.
 1. Emoji reactions are not imported

doc/user/project/import/fogbugz.md

@@ -23,6 +23,6 @@ users to GitLab users.
   ![Import Project](img/fogbugz_import_select_project.png)
 
 1. Once the import has finished click the link to take you to the project
-dashboard. Follow the directions to push your existing repository.
+   dashboard. Follow the directions to push your existing repository.
 
   ![Finished](img/fogbugz_import_finished.png)

doc/user/project/import/github.md

@@ -67,7 +67,7 @@ developer documentation.
 Before you begin, ensure that any GitHub users who you want to map to GitLab users have either:
 
 - A GitLab account that has logged in using the GitHub icon
-\- or -
+  \- or -
 - A GitLab account with an email address that matches the [public email address](https://help.github.com/articles/setting-your-commit-email-address-on-github/) of the GitHub user
 
 User-matching attempts occur in that order, and if a user is not identified either way, the activity is associated with

doc/user/project/index.md

@@ -19,7 +19,7 @@ When you create a project in GitLab, you'll have access to a large number of
   - [Issue Boards](issue_board.md): Organize and prioritize your workflow
   - [Multiple Issue Boards](https://docs.gitlab.com/ee/user/project/issue_board.html#multiple-issue-boards): Allow your teams to create their own workflows (Issue Boards) for the same project **[STARTER]**
 - [Repositories](repository/index.md): Host your code in a fully
-integrated platform
+  integrated platform
   - [Branches](repository/branches/index.md): use Git branching strategies to
   collaborate on code
   - [Protected branches](protected_branches.md): Prevent collaborators
@@ -29,7 +29,7 @@ integrated platform
   - [Signing commits](gpg_signed_commits/index.md): use GPG to sign your commits
   - [Deploy tokens](deploy_tokens/index.md): Manage project-based deploy tokens that allow permanent access to the repository and Container Registry.
 - [Merge Requests](merge_requests/index.md): Apply your branching
-strategy and get reviewed by your team
+  strategy and get reviewed by your team
   - [Merge Request Approvals](https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html): Ask for approval before
   implementing a change **[STARTER]**
   - [Fix merge conflicts from the UI](merge_requests/resolve_conflicts.md):
@@ -38,13 +38,13 @@ strategy and get reviewed by your team
   of the changes proposed in a merge request in a per-branch basis
 - [Labels](labels.md): Organize issues and merge requests by labels
 - [Time Tracking](../../workflow/time_tracking.md): Track estimate time
-and time spent on
+  and time spent on
   the conclusion of an issue or merge request
 - [Milestones](milestones/index.md): Work towards a target date
 - [Description templates](description_templates.md): Define context-specific
-templates for issue and merge request description fields for your project
+  templates for issue and merge request description fields for your project
 - [Slash commands (quick actions)](quick_actions.md): Textual shortcuts for
-common actions on issues or merge requests
+  common actions on issues or merge requests
 - [Web IDE](web_ide/index.md)
 
 **GitLab CI/CD:**
@@ -68,7 +68,7 @@ common actions on issues or merge requests
   - [Kubernetes cluster integration](clusters/index.md): Connecting your GitLab project
     with a Kubernetes cluster
 - [GitLab Pages](pages/index.md): Build, test, and deploy your static
-website with GitLab Pages
+  website with GitLab Pages
 
 **Other features:**
 
@@ -76,11 +76,11 @@ website with GitLab Pages
 - [Snippets](../snippets.md): store, share and collaborate on code snippets.
 - [Cycle Analytics](cycle_analytics.md): review your development lifecycle.
 - [Syntax highlighting](highlighting.md): an alternative to customize
-your code blocks, overriding GitLab's default choice of language.
+  your code blocks, overriding GitLab's default choice of language.
 - [Badges](badges.md): badges for the project overview.
 - [Releases](releases/index.md): a way to track deliverables in your project as snapshot in time of
-the source, build output, and other metadata or artifacts
-associated with a released version of your code.
+  the source, build output, and other metadata or artifacts
+  associated with a released version of your code.
 
 ### Project's integrations
 
@@ -96,7 +96,7 @@ Learn how to [create a new project](../../gitlab-basics/create-project.md) in Gi
 You can [fork a project](../../gitlab-basics/fork-project.md) in order to:
 
 - Collaborate on code by forking a project and creating a merge request
-from your fork to the upstream project
+  from your fork to the upstream project
 - Fork a sample project to work on the top of that
 
 ## Project settings

doc/user/project/integrations/irker.md

@@ -30,12 +30,12 @@ need to follow the firsts steps of the next section.
 1. Click "Irker".
 1. Select the "Active" checkbox.
 1. Enter the server host address where `irkerd` runs (defaults to `localhost`)
-in the `Server host` field on the Web page
+   in the `Server host` field on the Web page
 1. Enter the server port of `irkerd` (e.g. defaults to 6659) in the
-`Server port` field on the Web page.
+   `Server port` field on the Web page.
 1. Optional: if `Default IRC URI` is set, it has to be in the format
-`irc[s]://domain.name` and will be prepend to each and every channel provided
-by the user which is not a full URI.
+   `irc[s]://domain.name` and will be prepend to each and every channel provided
+   by the user which is not a full URI.
 1. Specify the recipients (e.g. #channel1, user1, etc.)
 1. Save or optionally click "Test Settings".
 

doc/user/project/integrations/redmine.md

 # Redmine Service
 
 1. To enable the Redmine integration in a project, navigate to the
-[Integrations page](project_services.md#accessing-the-project-services), click
-the **Redmine** service, and fill in the required details on the page as described
-in the table below.
+   [Integrations page](project_services.md#accessing-the-project-services), click
+   the **Redmine** service, and fill in the required details on the page as described
+   in the table below.
 
     | Field | Description |
     | ----- | ----------- |

doc/user/project/integrations/webhooks.md

@@ -48,9 +48,9 @@ Navigate to the webhooks page by going to your project's
 ## Use-cases
 
 - You can set up a webhook in GitLab to send a notification to
-[Slack](https://api.slack.com/incoming-webhooks) every time a build fails, for example
+  [Slack](https://api.slack.com/incoming-webhooks) every time a build fails, for example
 - You can [integrate with Twilio to be notified via SMS](https://www.datadoghq.com/blog/send-alerts-sms-customizable-webhooks-twilio/)
-every time an issue is created for a specific project or group within GitLab
+  every time an issue is created for a specific project or group within GitLab
 - You can use them to [automatically assign labels to merge requests](https://about.gitlab.com/2016/08/19/applying-gitlab-labels-automatically/).
 
 ## Webhook endpoint tips

doc/user/project/issue_board.md

@@ -78,9 +78,9 @@ with labels, and from there organize and prioritize them with Issue Boards.
 For example, let's consider this simplified development workflow:
 
 1. You have a repository hosting your app's codebase
-and your team actively contributing to code
+   and your team actively contributing to code
 1. Your **backend** team starts working a new
-implementation, gathers feedback and approval, and pass it over to **frontend**
+   implementation, gathers feedback and approval, and pass it over to **frontend**
 1. When frontend is complete, the new feature is deployed to **staging** to be tested
 1. When successful, it is deployed to **production**
 
@@ -88,7 +88,7 @@ If we have the labels "**backend**", "**frontend**", "**staging**", and
 "**production**", and an Issue Board with a list for each, we can:
 
 - Visualize the entire flow of implementations since the
-beginning of the development lifecycle until deployed to production
+  beginning of the development lifecycle until deployed to production
 - Prioritize the issues in a list by moving them vertically
 - Move issues between lists to organize them according to the labels you've set
 - Add multiple issues to lists in the board by selecting one or more existing issues

doc/user/project/issues/automatic_issue_closing.md

 # Automatic issue closing
 
 >**Notes:**
+>
 > - This is the user docs. In order to change the default issue closing pattern,
 >   follow the steps in the [administration docs].
 > - For performance reasons, automatic issue closing is disabled for the very

doc/user/project/issues/create_new_issue.md

@@ -79,6 +79,6 @@ in the same URL (since a description template just populates the description fie
 Follow these examples to form your new issue URL with prefilled fields.
 
 - For a new issue in the GitLab Community Edition project with a pre-entered title
-and a pre-entered description, the URL would be `https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issue[title]=Validate%20new%20concept&issue[description]=Research%20idea`
+  and a pre-entered description, the URL would be `https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issue[title]=Validate%20new%20concept&issue[description]=Research%20idea`
 - For a new issue in the GitLab Community Edition project with a pre-entered title
-and a pre-entered description template, the URL would be `https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issue[title]=Validate%20new%20concept&issuable_template=Research%20proposal`
+  and a pre-entered description template, the URL would be `https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issue[title]=Validate%20new%20concept&issuable_template=Research%20proposal`

doc/user/project/issues/due_dates.md

@@ -42,6 +42,7 @@ server's timezone.
 Issues with due dates can also be exported as an iCalendar feed. The URL of the
 feed can be added to calendar applications. The feed is accessible by clicking
 on the _Subscribe to calendar_ button on the following pages:
+
 - on the **Assigned Issues** page that is linked on the right-hand side of the
   GitLab header
 - on the **Project Issues** page

doc/user/project/issues/issues_functionalities.md

@@ -99,16 +99,16 @@ Learn more in the [Issue Weight documentation](https://docs.gitlab.com/ee/workfl
 #### 10. Notifications
 
 - Subscribe: if you are not a participant of the discussion on that issue, but
-want to receive notifications on each new input, subscribe to it.
+  want to receive notifications on each new input, subscribe to it.
 - Unsubscribe: if you are receiving notifications on that issue but no
-longer want to receive them, unsubscribe from it.
+  longer want to receive them, unsubscribe from it.
 
 Read more in the [notifications documentation](../../../workflow/notifications.md#issue--merge-request-events).
 
 #### 11. Reference
 
 - A quick "copy to clipboard" button for that issue's reference, `foo/bar#xxx`, where `foo` is the `username` or `groupname`, `bar`
-is the `project-name`, and `xxx` is the issue number.
+  is the `project-name`, and `xxx` is the issue number.
 
 #### 12. Title and description
 
@@ -138,7 +138,7 @@ interpreted as spam.
 #### 14. Related Merge Requests
 
 - Any merge requests mentioned in that issue's description
-or in the issue discussion thread.
+  or in the issue discussion thread.
 
 #### 15. Award emoji
 
@@ -152,8 +152,8 @@ know you like it without spamming them.
 #### 16. Thread
 
 - Comments: collaborate to that issue by posting comments in its thread.
-These text fields also fully support
-[GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown-gfm).
+  These text fields also fully support
+  [GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown-gfm).
 
 #### 17. Comment, start a discussion, or comment and close
 
@@ -166,7 +166,7 @@ Once you write a comment, you can either:
 #### 18. New Merge Request
 
 - Create a new merge request (with a new source branch named after the issue) in one action.
-The merge request will automatically inherit the milestone and labels of the issue. The merge
-request will automatically close that issue when it is merged.
+  The merge request will automatically inherit the milestone and labels of the issue. The merge
+  request will automatically close that issue when it is merged.
 - Optionally, you can just create a [new branch](../repository/web_editor.md#create-a-new-branch-from-an-issue)
-named after that issue.
+  named after that issue.

doc/user/project/operations/error_tracking.md

@@ -21,7 +21,7 @@ GitLab provides an easy way to connect Sentry to your project:
 
 1. Sign up to Sentry.io or [deploy your own](#deploying-sentry) Sentry instance.
 1. [Find or generate](https://docs.sentry.io/api/auth/) a Sentry auth token for your Sentry project.
-Make sure to give the token at least the following scopes: `event:read` and `project:read`.
+   Make sure to give the token at least the following scopes: `event:read` and `project:read`.
 1. Navigate to your project’s **Settings > Operations** and provide the Sentry API URL and auth token.
 1. Ensure that the 'Active' checkbox is set.
 1. Click **Save changes** for the changes to take effect.

doc/user/project/pages/getting_started_part_four.md

@@ -376,11 +376,11 @@ manually in the past. Read through the
 to understand how to go even further on your scripts.
 
 - On this blog post, understand the concept of
-[using GitLab CI `environments` to deploy your
-web app to staging and production](https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/).
+  [using GitLab CI `environments` to deploy your
+  web app to staging and production](https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/).
 - On this post, learn [how to run jobs sequentially,
-in parallel, or build a custom pipeline](https://about.gitlab.com/2016/07/29/the-basics-of-gitlab-ci/)
+  in parallel, or build a custom pipeline](https://about.gitlab.com/2016/07/29/the-basics-of-gitlab-ci/)
 - On this blog post, we go through the process of
-[pulling specific directories from different projects](https://about.gitlab.com/2016/12/07/building-a-new-gitlab-docs-site-with-nanoc-gitlab-ci-and-gitlab-pages/)
-to deploy this website you're looking at, docs.gitlab.com.
+  [pulling specific directories from different projects](https://about.gitlab.com/2016/12/07/building-a-new-gitlab-docs-site-with-nanoc-gitlab-ci-and-gitlab-pages/)
+  to deploy this website you're looking at, docs.gitlab.com.
 - On this blog post, we teach you [how to use GitLab Pages to produce a code coverage report](https://about.gitlab.com/2016/11/03/publish-code-coverage-report-with-gitlab-pages/).

doc/user/project/pages/getting_started_part_one.md

@@ -77,41 +77,41 @@ Learn more about [namespaces](../../group/index.md#namespaces).
 #### Project Websites
 
 - You created a project called `blog` under your username `john`,
-therefore your project URL is `https://gitlab.com/john/blog/`.
-Once you enable GitLab Pages for this project, and build your site,
-it will be available under `https://john.gitlab.io/blog/`.
+  therefore your project URL is `https://gitlab.com/john/blog/`.
+  Once you enable GitLab Pages for this project, and build your site,
+  it will be available under `https://john.gitlab.io/blog/`.
 - You created a group for all your websites called `websites`,
-and a project within this group is called `blog`. Your project
-URL is `https://gitlab.com/websites/blog/`. Once you enable
-GitLab Pages for this project, the site will live under
-`https://websites.gitlab.io/blog/`.
+  and a project within this group is called `blog`. Your project
+  URL is `https://gitlab.com/websites/blog/`. Once you enable
+  GitLab Pages for this project, the site will live under
+  `https://websites.gitlab.io/blog/`.
 - You created a group for your engineering department called `engineering`,
-a subgroup for all your documentation websites called `docs`,
-and a project within this subgroup is called `workflows`. Your project
-URL is `https://gitlab.com/engineering/docs/workflows/`. Once you enable
-GitLab Pages for this project, the site will live under
-`https://engineering.gitlab.io/docs/workflows`.
+  a subgroup for all your documentation websites called `docs`,
+  and a project within this subgroup is called `workflows`. Your project
+  URL is `https://gitlab.com/engineering/docs/workflows/`. Once you enable
+  GitLab Pages for this project, the site will live under
+  `https://engineering.gitlab.io/docs/workflows`.
 
 #### User and Group Websites
 
 - Under your username, `john`, you created a project called
-`john.gitlab.io`. Your project URL will be `https://gitlab.com/john/john.gitlab.io`.
-Once you enable GitLab Pages for your project, your website
-will be published under `https://john.gitlab.io`.
+  `john.gitlab.io`. Your project URL will be `https://gitlab.com/john/john.gitlab.io`.
+  Once you enable GitLab Pages for your project, your website
+  will be published under `https://john.gitlab.io`.
 - Under your group `websites`, you created a project called
-`websites.gitlab.io`. your project's URL will be `https://gitlab.com/websites/websites.gitlab.io`.
-Once you enable GitLab Pages for your project,
-your website will be published under `https://websites.gitlab.io`.
+  `websites.gitlab.io`. your project's URL will be `https://gitlab.com/websites/websites.gitlab.io`.
+  Once you enable GitLab Pages for your project,
+  your website will be published under `https://websites.gitlab.io`.
 
 > Support for subgroup project's websites was [introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/30548) in GitLab 11.8.
 
 **General example:**
 
 - On GitLab.com, a project site will always be available under
-`https://namespace.gitlab.io/project-name`
+  `https://namespace.gitlab.io/project-name`
 - On GitLab.com, a user or group website will be available under
-`https://namespace.gitlab.io/`
+  `https://namespace.gitlab.io/`
 - On your GitLab instance, replace `gitlab.io` above with your
-Pages server domain. Ask your sysadmin for this information.
+  Pages server domain. Ask your sysadmin for this information.
 
 _Read on about [Projects for GitLab Pages and URL structure](getting_started_part_two.md)._

doc/user/project/pages/getting_started_part_three.md

@@ -19,7 +19,7 @@ To use one or more custom domain with your Pages site, there are two things
 you should consider first, which we'll cover in this guide:
 
 1. Either if you're adding a **root domain** or a **subdomain**, for which
-you'll need to set up [DNS records](#dns-records)
+   you'll need to set up [DNS records](#dns-records)
 1. Whether you want to add an [SSL/TLS certificate](#ssl-tls-certificates) or not
 
 To finish the association, you need to [add your domain to your project's Pages settings](#add-your-custom-domain-to-gitlab-pages-settings).
@@ -136,13 +136,13 @@ verify your domain's ownership with a TXT record:
 > **Notes**:
 >
 > - **Do not** use a CNAME record if you want to point your
-`domain.com` to your GitLab Pages site. Use an `A` record instead.
+  `domain.com` to your GitLab Pages site. Use an `A` record instead.
 > - **Do not** add any special chars after the default Pages
-domain. E.g., **do not** point your `subdomain.domain.com` to
-`namespace.gitlab.io.` or `namespace.gitlab.io/`.
+  domain. E.g., **do not** point your `subdomain.domain.com` to
+  `namespace.gitlab.io.` or `namespace.gitlab.io/`.
 > - GitLab Pages IP on GitLab.com [was changed](https://about.gitlab.com/2017/03/06/we-are-changing-the-ip-of-gitlab-pages-on-gitlab-com/) in 2017
 > - GitLab Pages IP on GitLab.com [has been changed](https://about.gitlab.com/2018/07/19/gcp-move-update/#gitlab-pages-and-custom-domains)
-from `52.167.214.135` to `35.185.44.232` in 2018
+  from `52.167.214.135` to `35.185.44.232` in 2018
 
 ### Add your custom domain to GitLab Pages settings
 
@@ -278,15 +278,15 @@ These fields are found under your **Project**'s **Settings** > **Pages** > **New
 ### What's what?
 
 - A PEM certificate is the certificate generated by the CA,
-which needs to be added to the field **Certificate (PEM)**.
+  which needs to be added to the field **Certificate (PEM)**.
 - An [intermediate certificate](https://en.wikipedia.org/wiki/Intermediate_certificate_authority) (aka "root certificate") is
-the part of the encryption keychain that identifies the CA.
-Usually it's combined with the PEM certificate, but there are
-some cases in which you need to add them manually.
-[CloudFlare certs](https://about.gitlab.com/2017/02/07/setting-up-gitlab-pages-with-cloudflare-certificates/)
-are one of these cases.
+  the part of the encryption keychain that identifies the CA.
+  Usually it's combined with the PEM certificate, but there are
+  some cases in which you need to add them manually.
+  [CloudFlare certs](https://about.gitlab.com/2017/02/07/setting-up-gitlab-pages-with-cloudflare-certificates/)
+  are one of these cases.
 - A private key is an encrypted key which validates
-your PEM against your domain.
+  your PEM against your domain.
 
 ### Now what?
 
@@ -295,9 +295,9 @@ of this, it's simple:
 
 - Your PEM certificate needs to be added to the first field
 - If your certificate is missing its intermediate, copy
-and paste the root certificate (usually available from your CA website)
-and paste it in the [same field as your PEM certificate](https://about.gitlab.com/2017/02/07/setting-up-gitlab-pages-with-cloudflare-certificates/),
-just jumping a line between them.
+  and paste the root certificate (usually available from your CA website)
+  and paste it in the [same field as your PEM certificate](https://about.gitlab.com/2017/02/07/setting-up-gitlab-pages-with-cloudflare-certificates/),
+  just jumping a line between them.
 - Copy your private key and paste it in the last field
 
 >**Note:**

doc/user/project/pages/getting_started_part_two.md

@@ -16,7 +16,7 @@ To get started with GitLab Pages, you need:
 1. A project
 1. A configuration file (`.gitlab-ci.yml`) to deploy your site
 1. A specific `job` called `pages` in the configuration file
-that will make GitLab aware that you are deploying a GitLab Pages website
+   that will make GitLab aware that you are deploying a GitLab Pages website
 1. A `public` directory with the content of the website
 
 Optional Features:
@@ -85,16 +85,16 @@ is useful for submitting merge requests to the upstream.
 ### Create a project from scratch
 
 1. From your **Project**'s **[Dashboard](https://gitlab.com/dashboard/projects)**,
-click **New project**, and name it considering the
-[practical examples](getting_started_part_one.md#practical-examples).
+   click **New project**, and name it considering the
+   [practical examples](getting_started_part_one.md#practical-examples).
 1. Clone it to your local computer, add your website
-files to your project, add, commit and push to GitLab.
+   files to your project, add, commit and push to GitLab.
 1. From the your **Project**'s page, click **Set up CI/CD**:
 
     ![setup GitLab CI/CD](img/setup_ci.png)
 
 1. Choose one of the templates from the dropbox menu.
-Pick up the template corresponding to the SSG you're using (or plain HTML).
+   Pick up the template corresponding to the SSG you're using (or plain HTML).
 
     ![gitlab-ci templates](img/choose_ci_template.png)
 
@@ -107,20 +107,20 @@ where you'll find its default URL.
 > **Notes:**
 >
 > - GitLab Pages [supports any SSG](https://about.gitlab.com/2016/06/17/ssg-overview-gitlab-pages-part-3-examples-ci/), but,
-if you don't find yours among the templates, you'll need
-to configure your own `.gitlab-ci.yml`. To do that, please
-read through the article [Creating and Tweaking GitLab CI/CD for GitLab Pages](getting_started_part_four.md). New SSGs are very welcome among
-the [example projects](https://gitlab.com/pages). If you set
-up a new one, please
-[contribute](https://gitlab.com/pages/pages.gitlab.io/blob/master/CONTRIBUTING.md)
-to our examples.
+  if you don't find yours among the templates, you'll need
+  to configure your own `.gitlab-ci.yml`. To do that, please
+  read through the article [Creating and Tweaking GitLab CI/CD for GitLab Pages](getting_started_part_four.md). New SSGs are very welcome among
+  the [example projects](https://gitlab.com/pages). If you set
+  up a new one, please
+  [contribute](https://gitlab.com/pages/pages.gitlab.io/blob/master/CONTRIBUTING.md)
+  to our examples.
 >
 > - The second step _"Clone it to your local computer"_, can be done
-differently, achieving the same results: instead of cloning the bare
-repository to you local computer and moving your site files into it,
-you can run `git init` in your local website directory, add the
-remote URL: `git remote add origin git@gitlab.com:namespace/project-name.git`,
-then add, commit, and push.
+  differently, achieving the same results: instead of cloning the bare
+  repository to you local computer and moving your site files into it,
+  you can run `git init` in your local website directory, add the
+  remote URL: `git remote add origin git@gitlab.com:namespace/project-name.git`,
+  then add, commit, and push.
 
 ## URLs and Baseurls
 

doc/user/project/pages/index.md

@@ -97,7 +97,7 @@ use a [bundled template](getting_started_part_two.md#use-one-of-the-popular-page
 1. Choose an [example project](https://gitlab.com/pages) to [fork](../../../gitlab-basics/fork-project.md#how-to-fork-a-project):
    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.
 1. From the left sidebar, navigate to your project's **CI/CD > Pipelines** and click
-**Run pipeline** so that GitLab CI/CD will build and deploy your site to the server.
+   **Run pipeline** so that GitLab CI/CD will build and deploy your site to the server.
 1. Once the pipeline has finished successfully, find the link to visit your website from your
    project's **Settings > Pages**.
 

doc/user/project/repository/index.md

@@ -146,9 +146,9 @@ you are introducing those changes to your branch.
 Via command line, you can commit multiple times before pushing.
 
 - **Commit message:**
-A commit message is important to identity what is being changed and,
-more importantly, why. In GitLab, you can add keywords to the commit
-message that will perform one of the actions below:
+  A commit message is important to identity what is being changed and,
+  more importantly, why. In GitLab, you can add keywords to the commit
+  message that will perform one of the actions below:
   - **Trigger a GitLab CI/CD pipeline:**
   If you have your project configured with [GitLab CI/CD](../../../ci/README.md),
   you will trigger a pipeline per push, not per commit.
@@ -162,14 +162,14 @@ message that will perform one of the actions below:
   If you mention an issue or a merge request in a commit message, they will be shown
   on their respective thread.
 - **Cherry-pick a commit:**
-In GitLab, you can
-[cherry-pick a commit](../merge_requests/cherry_pick_changes.md#cherry-picking-a-commit)
-right from the UI.
+  In GitLab, you can
+  [cherry-pick a commit](../merge_requests/cherry_pick_changes.md#cherry-picking-a-commit)
+  right from the UI.
 - **Revert a commit:**
-Easily [revert a commit](../merge_requests/revert_changes.md#reverting-a-commit)
-from the UI to a selected branch.
+  Easily [revert a commit](../merge_requests/revert_changes.md#reverting-a-commit)
+  from the UI to a selected branch.
 - **Sign a commit:**
-Use GPG to [sign your commits](gpg_signed_commits/index.md).
+  Use GPG to [sign your commits](gpg_signed_commits/index.md).
 
 ## Repository size
 

doc/user/project/web_ide/index.md

@@ -30,10 +30,10 @@ the Web IDE will make your direct editing even easier.
 The Web IDE currently provides:
 
 - Basic syntax colorization for a variety of programming, scripting and markup
-languages such as XML, PHP, C#, C++, Markdown, Java, VB, Batch, Python, Ruby 
-and Objective-C.  
+  languages such as XML, PHP, C#, C++, Markdown, Java, VB, Batch, Python, Ruby
+  and Objective-C.
 - IntelliSense and validation support (displaying errors and warnings, providing
-smart completions, formatting, and outlining) for some languages. For example: 
+  smart completions, formatting, and outlining) for some languages. For example:
 TypeScript, JavaScript, CSS, LESS, SCSS, JSON and HTML.
 
 Because the Web IDE is based on the [Monaco Editor](https://microsoft.github.io/monaco-editor/),

doc/user/reserved_names.md

@@ -5,6 +5,7 @@ existing routes used by GitLab.
 
 For a list of words that are not allowed to be used as group or project names, see the
 [`path_regex.rb` file][reserved] under the `TOP_LEVEL_ROUTES`, `PROJECT_WILDCARD_ROUTES` and `GROUP_ROUTES` lists:
+
 - `TOP_LEVEL_ROUTES`: are names that are reserved as usernames or top level groups
 - `PROJECT_WILDCARD_ROUTES`: are names that are reserved for child groups or projects.
 - `GROUP_ROUTES`: are names that are reserved for all groups or projects.

doc/workflow/time_tracking.md

@@ -11,7 +11,7 @@ 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
-request.
+  request.
 
 You don't have to indicate an estimate to enter the time spent, and vice versa.