Update numbered lists for docs standards

Ensure that all numbered lists use only 1. and no other numbers.
Also ensure that numbered lists use proper spacing.

doc/administration/auth/ldap-ee.md

@@ -193,7 +193,7 @@ group, as opposed to the full DN.
 to lock down user abilities to invite new members to a group. When enabled following happens:
 1. Only administrator can manage memberships of any group including access levels.
-2. Users are not allowed to share project with other groups or invite members to a project created in a group.
+1. Users are not allowed to share project with other groups or invite members to a project created in a group.
 ## Adjusting LDAP user sync schedule

doc/administration/repository_storage_types.md

@@ -105,7 +105,7 @@ question.
 To start a migration, enable Hashed Storage for new projects:
 1. Go to **Admin > Settings > Repository** and expand the **Repository Storage** section.
-2. Select the **Use hashed storage paths for newly created and renamed projects** checkbox.
+1. Select the **Use hashed storage paths for newly created and renamed projects** checkbox.
 Check if the change breaks any existing integration you may have that
 either runs on the same machine as your repositories are located, or may login to that machine
@@ -133,7 +133,7 @@ Similar to the migration, to disable Hashed Storage for new
 projects:
 1. Go to **Admin > Settings > Repository** and expand the **Repository Storage** section.
-2. Uncheck the **Use hashed storage paths for newly created and renamed projects** checkbox.
+1. Uncheck the **Use hashed storage paths for newly created and renamed projects** checkbox.
 To schedule a complete rollback, see the
 [rake task documentation for storage rollback](raketasks/storage.md#rollback-from-hashed-storage-to-legacy-storage) for instructions.

doc/api/container_registry.md

@@ -193,13 +193,13 @@ Examples:
    curl --request DELETE --data 'name_regex=[0-9a-z]{40}' --data 'keep_n=5' --data 'older_than=2d' --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/5/registry/repositories/2/tags"
    ```
-2. Remove all tags, but keep always the latest 5:
+1. Remove all tags, but keep always the latest 5:
    ```bash
    curl --request DELETE --data 'name_regex=.*' --data 'keep_n=5' --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/5/registry/repositories/2/tags"
    ```
-3. Remove all tags that are older than 1 month:
+1. Remove all tags that are older than 1 month:
    ```bash
    curl --request DELETE --data 'name_regex=.*' --data 'older_than=1month' --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/5/registry/repositories/2/tags"

doc/ci/examples/end_to_end_testing_webdriverio/index.md

@@ -143,7 +143,7 @@ Which brings us to the exciting part: how do we run this in GitLab CI/CD? There
 need to do for this:
 1. Set up [CI/CD jobs](../../yaml/README.md#introduction) that actually have a browser available.
-2. Update our WebdriverIO configuration to use those browsers to visit the review apps.
+1. Update our WebdriverIO configuration to use those browsers to visit the review apps.
 For the scope of this article, we've defined an additional [CI/CD stage](../../yaml/README.md#stages)
 `confidence-check` that is executed _after_ the stage that deploys the review app. It uses the `node:latest` [Docker

doc/development/code_review.md

@@ -341,8 +341,7 @@ Enterprise Edition instance. This has some implications:
       - [Background migrations](background_migrations.md) run in Sidekiq, and
         should only be done for migrations that would take an extreme amount of
         time at GitLab.com scale.
-1. **Sidekiq workers**
-   [cannot change in a backwards-incompatible way](sidekiq_style_guide.md#removing-or-renaming-queues):
+1. **Sidekiq workers** [cannot change in a backwards-incompatible way](sidekiq_style_guide.md#removing-or-renaming-queues):
    1. Sidekiq queues are not drained before a deploy happens, so there will be
       workers in the queue from the previous version of GitLab.
    1. If you need to change a method signature, try to do so across two releases,

doc/development/documentation/improvement-workflow.md

@@ -52,9 +52,9 @@ To request a post-merge review, [create an issue for one using the Doc Review te
 **3. Maintainer**
 1. Review by assigned maintainer, who can always request/require the above reviews. Maintainer review can occur before or after a technical writer review.
-2. Ensure a release milestone of the format XX.Y is set. If the freeze for that release has begun, add the label `pick into <XX.Y>` unless this change is not required for the release. In that case, simply change the milestone.
-3. If EE and CE MRs exist, merge the EE MR first, then the CE MR.
-4. After merging, if there has not been a technical writer review and an issue for a follow-up review was not already created and linked from the MR, [create the issue using the Doc Review template](https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issuable_template=Doc%20Review) and link it from the MR.
+1. Ensure a release milestone of the format XX.Y is set. If the freeze for that release has begun, add the label `pick into <XX.Y>` unless this change is not required for the release. In that case, simply change the milestone.
+1. If EE and CE MRs exist, merge the EE MR first, then the CE MR.
+1. After merging, if there has not been a technical writer review and an issue for a follow-up review was not already created and linked from the MR, [create the issue using the Doc Review template](https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issuable_template=Doc%20Review) and link it from the MR.
 ## Other ways to help

doc/development/documentation/styleguide.md

@@ -44,9 +44,9 @@ Include any media types/sources if the content is relevant to readers. You can f
 In the software industry, it is a best practice to organize documentatioin in different types. For example, [Divio recommends](https://www.divio.com/blog/documentation/):
 1. Tutorials
-2. How-to guides
-3. Explanation
-4. Reference (for example, a glossary)
+1. How-to guides
+1. Explanation
+1. Reference (for example, a glossary)
 At GitLab, we have so many product changes in our monthly releases that we can't afford to continually update multiple types of information.
 If we have multiple types, the information will become outdated. Therefore, we have a [single template](structure.md) for documentation.
@@ -142,9 +142,9 @@ The table below shows what kind of documentation goes where.
 ### Working with directories and files
 1. When you create a new directory, always start with an `index.md` file.
-  Do not use another file name and **do not** create `README.md` files.
+   Do not use another file name and **do not** create `README.md` files.
 1. **Do not** use special characters and spaces, or capital letters in file names,
-  directory names, branch names, and anything that generates a path.
+   directory names, branch names, and anything that generates a path.
 1. When creating a new document and it has more than one word in its name,
    make sure to use underscores instead of spaces or dashes (`-`). For example,
    a proper naming would be `import_projects_from_github.md`. The same rule

doc/development/fe_guide/frontend_faq.md

@@ -5,12 +5,12 @@
 1. **You talk about Frontend FAQ.**
    Please share links to it whenever applicable, so more eyes catch when content
    gets outdated.
-2. **Keep it short and simple.**
+1. **Keep it short and simple.**
    Whenever an answer needs more than two sentences it does not belong here.
-3. **Provide background when possible.**
+1. **Provide background when possible.**
    Linking to relevant source code, issue / epic, or other documentation helps
    to understand the answer.
-4. **If you see something, do something.**
+1. **If you see something, do something.**
    Please remove or update any content that is outdated as soon as you see it.
 ## FAQ

doc/development/fe_guide/style_guide_js.md

@@ -548,7 +548,7 @@ Please check this [rules][eslint-plugin-vue-rules] for more documentation.
       <component @click="eventHandler"/>
     ```
-2. Shorthand `:` is preferable over `v-bind`
+1. Shorthand `:` is preferable over `v-bind`
     ```javascript
       // bad
@@ -558,7 +558,7 @@ Please check this [rules][eslint-plugin-vue-rules] for more documentation.
       <component :class="btn"/>
     ```
-3. Shorthand `#` is preferable over `v-slot`
+1. Shorthand `#` is preferable over `v-slot`
     ```javascript
       // bad

doc/development/fe_guide/style_guide_scss.md

@@ -35,7 +35,7 @@ New utility classes should be added to [`utilities.scss`](https://gitlab.com/git
 We recommend a "utility-first" approach.
 1. Start with utility classes.
-2. If composing utility classes into a component class removes code duplication and encapsulates a clear responsibility, do it.
+1. If composing utility classes into a component class removes code duplication and encapsulates a clear responsibility, do it.
 This encourages an organic growth of component classes and prevents the creation of one-off unreusable classes. Also, the kind of classes that emerge from "utility-first" tend to be design-centered (e.g. `.button`, `.alert`, `.card`) rather than domain-centered (e.g. `.security-report-widget`, `.commit-header-icon`).

doc/development/import_export.md

@@ -229,8 +229,8 @@ meaning that we want to bump the version up in the next version (or patch releas
 For example:
 1. Add rename to `RelationRenameService` in X.Y
-2. Remove it from `RelationRenameService` in X.Y + 1
-3. Bump Import/Export version in X.Y + 1
+1. Remove it from `RelationRenameService` in X.Y + 1
+1. Bump Import/Export version in X.Y + 1
 ```ruby
 module Gitlab

doc/development/licensed_feature_availability.md

@@ -14,7 +14,7 @@ it should be restricted on namespace scope.
 1. Add the feature symbol on `EES_FEATURES`, `EEP_FEATURES` or `EEU_FEATURES` constants in
   `ee/app/models/license.rb`. Note on `ee/app/models/ee/namespace.rb` that _Bronze_ GitLab.com
   features maps to on-premise _EES_, _Silver_ to _EEP_ and _Gold_ to _EEU_.
-2. Check using:
+1. Check using:
 ```ruby
 project.feature_available?(:feature_symbol)
@@ -29,8 +29,8 @@ the instance license.
 1. Add the feature symbol on `EES_FEATURES`, `EEP_FEATURES` or `EEU_FEATURES` constants in
   `ee/app/models/license.rb`.
-2. Add the same feature symbol to `GLOBAL_FEATURES`
-3. Check using:
+1. Add the same feature symbol to `GLOBAL_FEATURES`
+1. Check using:
 ```ruby
 License.feature_available?(:feature_symbol)

doc/development/performance.md

@@ -267,7 +267,7 @@ piece of code is worth optimizing. The only two things you can do are:
 1. Think about what the code does, how it's used, how many times it's called and
    how much time is spent in it relative to the total execution time (e.g., the
    total time spent in a web request).
-2. Ask others (preferably in the form of an issue).
+1. Ask others (preferably in the form of an issue).
 Some examples of changes that aren't really important/worth the effort:
@@ -285,10 +285,10 @@ directly in a web request as much as possible. This has numerous benefits such
 as:
 1. An error won't prevent the request from completing.
-2. The process being slow won't affect the loading time of a page.
-3. In case of a failure it's easy to re-try the process (Sidekiq takes care of
+1. The process being slow won't affect the loading time of a page.
+1. In case of a failure it's easy to re-try the process (Sidekiq takes care of
    this automatically).
-4. By isolating the code from a web request it will hopefully be easier to test
+1. By isolating the code from a web request it will hopefully be easier to test
    and maintain.
 It's especially important to use Sidekiq as much as possible when dealing with

doc/development/policies.md

@@ -89,8 +89,8 @@ 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.
-2. The number inside the brackets indicates the score.
-3. The last part of the line (e.g. `@john : Issue/1`) shows the username
+1. The number inside the brackets indicates the score.
+1. The last part of the line (e.g. `@john : Issue/1`) shows the username
    and subject for that rule.
 Here you can see that the first four rules were evaluated `false` for

doc/development/testing_guide/end_to_end/quick_start_guide.md

@@ -116,9 +116,9 @@ end
 Below are the steps that the test covers:
 1. The test finds the 'Edit' link for the labels and clicks on it.
-2. Then it fills in the 'Assign labels' input field with the value 'animal::dolphin' and press enters.
-3. Then it clicks in the content body to apply the label and refreshes the page.
-4. Finally, the expectations check that the previous scoped label was removed and that the new one was added.
+1. Then it fills in the 'Assign labels' input field with the value 'animal::dolphin' and press enters.
+1. Then it clicks in the content body to apply the label and refreshes the page.
+1. Finally, the expectations check that the previous scoped label was removed and that the new one was added.
 Let's now see how the second test case would look.
@@ -144,9 +144,9 @@ end
 Below are the steps that the test covers:
 1. The test finds the 'Edit' link for the labels and clicks on it.
-2. Then it fills in the 'Assign labels' input field with the value 'plant::orchid' and press enters.
-3. Then it clicks in the content body to apply the label and refreshes the page.
-4. Finally, the expectations check that both scoped labels are present.
+1. Then it fills in the 'Assign labels' input field with the value 'plant::orchid' and press enters.
+1. Then it clicks in the content body to apply the label and refreshes the page.
+1. Finally, the expectations check that both scoped labels are present.
 > Similar to the previous test, this one is also very straightforward, but there is some code duplication. Let's address it.
@@ -290,7 +290,7 @@ As already mentioned in the [best practices](best_practices.md) document, end-to
 Some improvements that we could make in our test suite to optimize its time to run are:
 1. Having a single test case (an `it` block) that exercises both scenarios to avoid "wasting" time in the tests' pre-conditions, instead of having two different test cases.
-2. Making the selection of labels more performant by allowing for the selection of more than one label in the same reusable method.
+1. Making the selection of labels more performant by allowing for the selection of more than one label in the same reusable method.
 Let's look at a suggestion that addresses the above points, one by one:
@@ -332,8 +332,8 @@ To address point 1, we changed the test implementation from two `it` blocks into
 > Notice that the implementation of the new and unique `it` block had to change a little bit. Below we describe in details what it does.
 1. It selects two scoped labels simultaneously, one from the same scope of the one already applied in the issue during the setup phase (in the `before` block), and another one from a different scope.
-2. It asserts that the correct labels are visible in the `labels_block`, and that the labels were correctly added and removed;
-3. Finally, the `select_label_and_refresh` method is changed to `select_labels_and_refresh`, which accepts an array of labels instead of a single label, and it iterates on them for faster label selection (this is what is used in step 1 explained above.)
+1. It asserts that the correct labels are visible in the `labels_block`, and that the labels were correctly added and removed;
+1. Finally, the `select_label_and_refresh` method is changed to `select_labels_and_refresh`, which accepts an array of labels instead of a single label, and it iterates on them for faster label selection (this is what is used in step 1 explained above.)
 ### 7. Resources
@@ -542,9 +542,9 @@ end
 Notice that we have not only moved the `select_labels_and_refresh` method, but we have also changed its implementation to:
 1. Click the `:edit_link_labels` element previously defined, instead of using `find('.block.labels .edit-link').click`
-2. Use `within_element(:dropdown_menu_labels, text: label)`, and inside of it, we call `send_keys_to_element(:dropdown_input_field, [label, :enter])`, which is a method that we will implement in the `QA::Page::Base` class to replace `find('.dropdown-menu-labels .dropdown-input-field').send_keys [label, :enter]`
-3. Use `click_body` after iterating on each label, instead of using `find('#content-body').click`
-4. Iterate on every label again, and then we use `has_element?(:labels_block, text: label)` after clicking the page body (which applies the labels), and before refreshing the page, to avoid test flakiness due to refreshing too fast.
+1. Use `within_element(:dropdown_menu_labels, text: label)`, and inside of it, we call `send_keys_to_element(:dropdown_input_field, [label, :enter])`, which is a method that we will implement in the `QA::Page::Base` class to replace `find('.dropdown-menu-labels .dropdown-input-field').send_keys [label, :enter]`
+1. Use `click_body` after iterating on each label, instead of using `find('#content-body').click`
+1. Iterate on every label again, and then we use `has_element?(:labels_block, text: label)` after clicking the page body (which applies the labels), and before refreshing the page, to avoid test flakiness due to refreshing too fast.
 ##### Details of `text_of_labels_block`

doc/integration/jenkins_deprecated.md

@@ -19,7 +19,7 @@ Requirements:
 ## Jenkins
 1. Install [GitLab Hook plugin](https://wiki.jenkins.io/display/JENKINS/GitLab+Hook+Plugin)
-2. Set up jenkins project
+1. Set up jenkins project
 ![screen](img/jenkins_project.png)

doc/integration/jira_development_panel.md

@@ -59,7 +59,7 @@ There are no special requirements if you are using GitLab.com.
     ![GitLab Application setup](img/jira_dev_panel_gl_setup_1.png)
     - Check `api` in the Scopes section.
-2. Click `Save application`. You will see the generated 'Application Id' and 'Secret' values.
+1. Click `Save application`. You will see the generated 'Application Id' and 'Secret' values.
     Copy these values that you will use on the Jira configuration side.
 ## Jira Configuration
@@ -70,7 +70,7 @@ There are no special requirements if you are using GitLab.com.
     ![Jira DVCS from Dashboard](img/jira_dev_panel_jira_setup_1.png)
-2. Complete the form
+1. Complete the form
     Select GitHub Enterprise for the `Host` field.
@@ -92,7 +92,7 @@ There are no special requirements if you are using GitLab.com.
     Ensure that the rest of the checkboxes are checked.
-3. Click `Add` to complete and create the integration.
+1. Click `Add` to complete and create the integration.
     Jira takes up to a few minutes to know about (import behind the scenes) all the commits and branches
     for all the projects in the GitLab group you specified in the previous step. These are refreshed

doc/topics/autodevops/index.md

@@ -789,11 +789,11 @@ To configure your application variables:
 1. Go to your project's **Settings > CI/CD**, then expand the section
    called **Variables**.
-2. Create a CI Variable, ensuring the key is prefixed with
+1. Create a CI Variable, ensuring the key is prefixed with
    `K8S_SECRET_`. For example, you can create a variable with key
 `K8S_SECRET_RAILS_MASTER_KEY`.
-3. Run an Auto Devops pipeline either by manually creating a new
+1. Run an Auto Devops pipeline either by manually creating a new
    pipeline or by pushing a code change to GitLab.
 Auto DevOps pipelines will take your application secret variables to

doc/user/application_security/index.md

@@ -115,9 +115,9 @@ generated by GitLab. To apply the fix:
 1. Click on the vulnerability.
 1. Download and review the patch file `remediation.patch`.
-2. Ensure your local project has the same commit checked out that was used to generate the patch.
-3. Run `git apply remediation.patch`.
-4. Verify and commit the changes to your branch.
+1. Ensure your local project has the same commit checked out that was used to generate the patch.
+1. Run `git apply remediation.patch`.
+1. Verify and commit the changes to your branch.
 ![Apply patch for dependency scanning](img/vulnerability_solution.png)

doc/user/application_security/security_dashboard/index.md

@@ -26,8 +26,8 @@ To use the project or group security dashboard:
 1. At least one project inside a group must be configured with at least one of
    the [supported reports](#supported-reports).
-2. The configured jobs must use the [new `reports` syntax](../../../ci/yaml/README.md#artifactsreports).
-3. [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 or newer must be used.
+1. The configured jobs must use the [new `reports` syntax](../../../ci/yaml/README.md#artifactsreports).
+1. [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 or newer must be used.
    If you're using the shared Runners on GitLab.com, this is already the case.
 ## Project Security Dashboard