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

@@ -337,10 +337,10 @@ The default is 100MB.
 You may want to run GitLab Pages daemon on a separate server in order to decrease the load on your main application server.
 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`.
+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`.
 1. On `app2` install GitLab omnibus and modify `/etc/gitlab/gitlab.rb` this way:
@@ -365,7 +365,7 @@ as the shared folder on `app2` and mount it to `/mnt/pages` on `app1`.
     pages_external_url "http://<your-pages-domain>"
     gitlab_rails['pages_path'] = "/mnt/pages"
     ```
-    
+
 1. Run `sudo gitlab-ctl reconfigure`.
 ## Backup

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).
@@ -35,7 +35,7 @@ documentation updates if screenshots are now needed, or need to be updated.
 Documentation is not required when a feature is changed on the backend
 only and does not directly affect the way that any user or administrator would
-interact with GitLab. 
+interact with GitLab.
 NOTE: **Note:**
 When revamping documentation, if unrelated to the feature change, this should be submitted
@@ -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.
-   - If the new or changed doc requires extensive collaboration or conversation, a separate,
-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.
+  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.
+  - 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.
 - 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
@@ -45,7 +45,7 @@ before merging, mention the writer who is assigned to the relevant [DevOps stage
 The process can involve the following parties/phases, and is replicated in the `Documentation` MR template for GitLab CE and EE, to help with following the process.
 **1. Primary Reviewer** - Review by a [code reviewer](https://about.gitlab.com/handbook/engineering/projects/) or other appropriate colleague to confirm accuracy, clarity, and completeness. This can be skipped for minor fixes without substantive content changes.
- 
+
 **2. Technical Writer** - Optional - If not requested for this MR, must be scheduled post-merge. To request a pre-merge review, assign the writer listed for the applicable [DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages).
 To request a post-merge 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.

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.
@@ -95,7 +95,7 @@ Link each one to an appropriate place for more information.
 "Instructions" is usually not the name of the heading.
 This is the part of the document where you can include one or more sets of instructions, each to accomplish a specific task.
 Headers should describe the task the reader will achieve by following the instructions within, typically starting with a verb.
-Larger instruction sets may have subsections covering specific phases of the process. 
+Larger instruction sets may have subsections covering specific phases of the process.
 - Write a step-by-step guide, with no gaps between the steps.
 - Start with an h2 (`##`), break complex steps into small steps using

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.