Ensure all lists are surrounded by new lines

Markdown renderers find it easier to determine
where lists start and end when lists are surrounded
by new lines.

For consistency, also ensure entries in the list
are aligned when they span multipls lines.

9 files changed, 40 insertions, 38 deletions

diff --git a/doc/administration/auth/authentiq.md b/doc/administration/auth/authentiq.md
index 94a8803fff1..726622d8599 100644
--- a/doc/administration/auth/authentiq.md
+++ b/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.
 
diff --git a/doc/administration/auth/ldap.md b/doc/administration/auth/ldap.md
index 37e596f198f..d5d0d99ac24 100644
--- a/doc/administration/auth/ldap.md
+++ b/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:
diff --git a/doc/administration/monitoring/performance/grafana_configuration.md b/doc/administration/monitoring/performance/grafana_configuration.md
index 1f431f8bd62..ab43ec2cc4f 100644
--- a/doc/administration/monitoring/performance/grafana_configuration.md
+++ b/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)
diff --git a/doc/administration/monitoring/performance/performance_bar.md b/doc/administration/monitoring/performance/performance_bar.md
index 6a55dbe1eb4..95f497a1470 100644
--- a/doc/administration/monitoring/performance/performance_bar.md
+++ b/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
diff --git a/doc/administration/operations/index.md b/doc/administration/operations/index.md
index a16fc7ae74f..32f36d68c50 100644
--- a/doc/administration/operations/index.md
+++ b/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.
diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md
index 5c809f25fbd..279ad018aed 100644
--- a/doc/administration/pages/index.md
+++ b/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
diff --git a/doc/administration/pages/source.md b/doc/administration/pages/source.md
index 9f2b4d9075a..60800d445b8 100644
--- a/doc/administration/pages/source.md
+++ b/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.
diff --git a/doc/administration/polling.md b/doc/administration/polling.md
index 35aaa20df2c..a1077614677 100644
--- a/doc/administration/polling.md
+++ b/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.)
diff --git a/doc/administration/raketasks/maintenance.md b/doc/administration/raketasks/maintenance.md
index 0d863594fc7..b295b7d5dc4 100644
--- a/doc/administration/raketasks/maintenance.md
+++ b/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)