Fix unordered list spacing

Correct the spacing of unordered markdown lists
in docs, to maintain standards of documentation,
in /user and others.

8 files changed, 55 insertions, 55 deletions

diff --git a/doc/user/project/badges.md b/doc/user/project/badges.md
index 8849dd2d684..cd3e5f5a63c 100644
--- a/doc/user/project/badges.md
+++ b/doc/user/project/badges.md
@@ -17,10 +17,10 @@ If you find that you have to add the same badges to several projects, you may wa
 
 To add a new badge to a project:
 
-1.  Navigate to your project's **Settings > General > Badges**.
-1.  Under "Link", enter the URL that the badges should point to and under
-    "Badge image URL" the URL of the image that should be displayed.
-1.  Submit the badge by clicking the **Add badge** button.
+1. Navigate to your project's **Settings > General > Badges**.
+1. Under "Link", enter the URL that the badges should point to and under
+   "Badge image URL" the URL of the image that should be displayed.
+1. Submit the badge by clicking the **Add badge** button.
 
 After adding a badge to a project, you can see it in the list below the form.
 You can edit it by clicking on the pen icon next to it or to delete it by
@@ -39,10 +39,10 @@ project, consider adding them on the [project level](#project-badges) or use
 
 To add a new badge to a group:
 
-1.  Navigate to your group's **Settings > General > Badges**.
-1.  Under "Link", enter the URL that the badges should point to and under
-    "Badge image URL" the URL of the image that should be displayed.
-1.  Submit the badge by clicking the **Add badge** button.
+1. Navigate to your group's **Settings > General > Badges**.
+1. Under "Link", enter the URL that the badges should point to and under
+   "Badge image URL" the URL of the image that should be displayed.
+1. Submit the badge by clicking the **Add badge** button.
 
 After adding a badge to a group, you can see it in the list below the form.
 You can edit the badge by clicking on the pen icon next to it or to delete it
diff --git a/doc/user/project/cycle_analytics.md b/doc/user/project/cycle_analytics.md
index 5d36e1d4be3..6707b88c317 100644
--- a/doc/user/project/cycle_analytics.md
+++ b/doc/user/project/cycle_analytics.md
@@ -21,19 +21,19 @@ Analytics** tab.
 There are seven stages that are tracked as part of the Cycle Analytics calculations.
 
 - **Issue** (Tracker)
-    - Time to schedule an issue (by milestone or by adding it to an issue board)
+  - Time to schedule an issue (by milestone or by adding it to an issue board)
 - **Plan** (Board)
-    - Time to first commit
+  - Time to first commit
 - **Code** (IDE)
-    - Time to create a merge request
+  - Time to create a merge request
 - **Test** (CI)
-    - Time it takes GitLab CI/CD to test your code
+  - Time it takes GitLab CI/CD to test your code
 - **Review** (Merge Request/MR)
-    - Time spent on code review
+  - Time spent on code review
 - **Staging** (Continuous Deployment)
-    - Time between merging and deploying to production
+  - Time between merging and deploying to production
 - **Production** (Total)
-    - Total lifecycle time; i.e. the velocity of the project or team
+  - Total lifecycle time; i.e. the velocity of the project or team
 
 ## How the data is measured
 
diff --git a/doc/user/project/import/svn.md b/doc/user/project/import/svn.md
index 7359487e1bf..d175ee87f26 100644
--- a/doc/user/project/import/svn.md
+++ b/doc/user/project/import/svn.md
@@ -9,13 +9,13 @@ between the two, for more information consult your favorite search engine.
 There are two approaches to SVN to Git migration:
 
 1. [Git/SVN Mirror](#smooth-migration-with-a-gitsvn-mirror-using-subgit) which:
-    - Makes the GitLab repository to mirror the SVN project.
-    - Git and SVN repositories are kept in sync; you can use either one.
-    - Smoothens the migration process and allows to manage migration risks.
+   - Makes the GitLab repository to mirror the SVN project.
+   - Git and SVN repositories are kept in sync; you can use either one.
+   - Smoothens the migration process and allows to manage migration risks.
 
 1. [Cut over migration](#cut-over-migration-with-svn2git) which:
-     - Translates and imports the existing data and history from SVN to Git.
-     - Is a fire and forget approach, good for smaller teams.
+   - Translates and imports the existing data and history from SVN to Git.
+   - Is a fire and forget approach, good for smaller teams.
 
 ## Smooth migration with a Git/SVN mirror using SubGit
 
diff --git a/doc/user/project/index.md b/doc/user/project/index.md
index 7307c5b8991..45e96437517 100644
--- a/doc/user/project/index.md
+++ b/doc/user/project/index.md
@@ -66,15 +66,15 @@ When you create a project in GitLab, you'll have access to a large number of
   to automatically set up your app's deployment
   - [Enable and disable GitLab CI](../../ci/enable_or_disable_ci.md)
   - [Pipelines](../../ci/pipelines.md): Configure and visualize
-  your GitLab CI/CD pipelines from the UI
-     - [Scheduled Pipelines](pipelines/schedules.md): Schedule a pipeline
-     to start at a chosen time
-     - [Pipeline Graphs](../../ci/pipelines.md#visualizing-pipelines): View your
-     entire pipeline from the UI
-     - [Job artifacts](pipelines/job_artifacts.md): Define,
-     browse, and download job artifacts
-     - [Pipeline settings](pipelines/settings.md): Set up Git strategy (choose the default way your repository is fetched from GitLab in a job),
-     timeout (defines the maximum amount of time in minutes that a job is able run), custom path for `.gitlab-ci.yml`, test coverage parsing, pipeline's visibility, and much more
+    your GitLab CI/CD pipelines from the UI
+    - [Scheduled Pipelines](pipelines/schedules.md): Schedule a pipeline
+      to start at a chosen time
+    - [Pipeline Graphs](../../ci/pipelines.md#visualizing-pipelines): View your
+      entire pipeline from the UI
+    - [Job artifacts](pipelines/job_artifacts.md): Define,
+      browse, and download job artifacts
+    - [Pipeline settings](pipelines/settings.md): Set up Git strategy (choose the default way your repository is fetched from GitLab in a job),
+      timeout (defines the maximum amount of time in minutes that a job is able run), custom path for `.gitlab-ci.yml`, test coverage parsing, pipeline's visibility, and much more
   - [Kubernetes cluster integration](clusters/index.md): Connecting your GitLab project
     with a Kubernetes cluster
   - [Feature Flags](operations/feature_flags.md): Feature flags allow you to ship a project in
diff --git a/doc/user/project/integrations/mock_ci.md b/doc/user/project/integrations/mock_ci.md
index 1c64b275d6e..886094a6531 100644
--- a/doc/user/project/integrations/mock_ci.md
+++ b/doc/user/project/integrations/mock_ci.md
@@ -5,9 +5,9 @@
 To set up the mock CI service server, respond to the following endpoints
 
 - `commit_status`: `#{project.namespace.path}/#{project.path}/status/#{sha}.json`
-   - Have your service return `200 { status: ['failed'|'canceled'|'running'|'pending'|'success'|'success-with-warnings'|'skipped'|'not_found'] }`
+  - Have your service return `200 { status: ['failed'|'canceled'|'running'|'pending'|'success'|'success-with-warnings'|'skipped'|'not_found'] }`
    - If the service returns a 404, it is interpreted as `pending`
 - `build_page`: `#{project.namespace.path}/#{project.path}/status/#{sha}`
-   - Just where the build is linked to, doesn't matter if implemented
+  - Just where the build is linked to, doesn't matter if implemented
 
 For an example of a mock CI server, see [`gitlab-org/gitlab-mock-ci-service`](https://gitlab.com/gitlab-org/gitlab-mock-ci-service)
diff --git a/doc/user/project/integrations/webhooks.md b/doc/user/project/integrations/webhooks.md
index 30940b65454..84adb9637fc 100644
--- a/doc/user/project/integrations/webhooks.md
+++ b/doc/user/project/integrations/webhooks.md
@@ -58,13 +58,13 @@ Navigate to the webhooks page by going to your project's
 If you are writing your own endpoint (web server) that will receive
 GitLab webhooks keep in mind the following things:
 
--   Your endpoint should send its HTTP response as fast as possible. If
-    you wait too long, GitLab may decide the hook failed and retry it.
--   Your endpoint should ALWAYS return a valid HTTP response. If you do
-    not do this then GitLab will think the hook failed and retry it.
-    Most HTTP libraries take care of this for you automatically but if
-    you are writing a low-level hook this is important to remember.
--   GitLab ignores the HTTP status code returned by your endpoint.
+- Your endpoint should send its HTTP response as fast as possible. If
+  you wait too long, GitLab may decide the hook failed and retry it.
+- Your endpoint should ALWAYS return a valid HTTP response. If you do
+  not do this then GitLab will think the hook failed and retry it.
+  Most HTTP libraries take care of this for you automatically but if
+  you are writing a low-level hook this is important to remember.
+- GitLab ignores the HTTP status code returned by your endpoint.
 
 ## Secret token
 
diff --git a/doc/user/project/issue_board.md b/doc/user/project/issue_board.md
index 422e4b71424..eaca5f8cfb8 100644
--- a/doc/user/project/issue_board.md
+++ b/doc/user/project/issue_board.md
@@ -143,10 +143,10 @@ Create lists for each of your team members and quickly drag-and-drop issues onto
 
 - **Issue Board** - Each board represents a unique view for your issues. It can have multiple lists with each list consisting of issues represented by cards.
 - **List** - A column on the issue board that displays issues matching certain attributes. In addition to the default lists of 'Open' and 'Closed' issue, each additional list will show issues matching your chosen label or assignee. On the top of that list you can see the number of issues that belong to it.
-   - **Label list**: a list based on a label. It shows all opened issues with that label.
-   - **Assignee list**: a list which includes all issues assigned to a user.
-   - **Open** (default): shows all open issues that do not belong to one of the other lists. Always appears as the leftmost list.
-   - **Closed** (default): shows all closed issues. Always appears as the rightmost list.
+  - **Label list**: a list based on a label. It shows all opened issues with that label.
+  - **Assignee list**: a list which includes all issues assigned to a user.
+  - **Open** (default): shows all open issues that do not belong to one of the other lists. Always appears as the leftmost list.
+  - **Closed** (default): shows all closed issues. Always appears as the rightmost list.
 - **Card** - A box in the list that represents an individual issue. The information you can see on a card consists of the issue number, the issue title, the assignee, and the labels associated with the issue. You can drag cards from one list to another to change their label or assignee from that of the source list to that of the destination list.
 
 ## Permissions
diff --git a/doc/user/project/pages/introduction.md b/doc/user/project/pages/introduction.md
index 9451b5349c0..e8984cb8b9f 100644
--- a/doc/user/project/pages/introduction.md
+++ b/doc/user/project/pages/introduction.md
@@ -83,23 +83,23 @@ You can enable Pages access control on your project, so that only
 1. Navigate to your project's **Settings > General > Permissions**.
 1. Toggle the **Pages** button to enable the access control.
 
-    NOTE: **Note:**
-    If you don't see the toggle button, that means that it's not enabled.
-    Ask your administrator to [enable it](../../../administration/pages/index.md#access-control).
+   NOTE: **Note:**
+   If you don't see the toggle button, that means that it's not enabled.
+   Ask your administrator to [enable it](../../../administration/pages/index.md#access-control).
 
 1. The Pages access control dropdown allows you to set who can view pages hosted
    with GitLab Pages, depending on your project's visibility:
 
-    - If your project is private:
-      - **Only project members**: Only project members will be able to browse the website.
-      - **Everyone**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership.
-    - If your project is internal:
-      - **Only project members**: Only project members will be able to browse the website.
-      - **Everyone with access**: Everyone logged into GitLab will be able to browse the website, no matter their project membership.
-      - **Everyone**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership.
-    - If your project is public:
-      - **Only project members**: Only project members will be able to browse the website.
-      - **Everyone with access**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership.
+   - If your project is private:
+     - **Only project members**: Only project members will be able to browse the website.
+     - **Everyone**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership.
+   - If your project is internal:
+     - **Only project members**: Only project members will be able to browse the website.
+     - **Everyone with access**: Everyone logged into GitLab will be able to browse the website, no matter their project membership.
+     - **Everyone**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership.
+   - If your project is public:
+     - **Only project members**: Only project members will be able to browse the website.
+     - **Everyone with access**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership.
 
 1. Click **Save changes**.