Merge branch 'docs-lists-cleanup-1' into 'master'

Fix unordered list spacing (part 1)

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

doc/development/code_review.md

@@ -45,9 +45,9 @@ page, with these behaviours:
 
 1. It will not pick people whose [GitLab status](../user/profile/index.md#current-status)
    contains the string 'OOO'.
-2. [Trainee maintainers](https://about.gitlab.com/handbook/engineering/workflow/code-review/#trainee-maintainer)
+1. [Trainee maintainers](https://about.gitlab.com/handbook/engineering/workflow/code-review/#trainee-maintainer)
    are three times as likely to be picked as other reviewers.
-3. It always picks the same reviewers and maintainers for the same
+1. It always picks the same reviewers and maintainers for the same
    branch name (unless their OOO status changes, as in point 1). It
    removes leading `ce-` and `ee-`, and trailing `-ce` and `-ee`, so
    that it can be stable for backport branches.
@@ -58,19 +58,19 @@ As described in the section on the responsibility of the maintainer below, you
 are recommended to get your merge request approved and merged by maintainer(s)
 from teams other than your own.
 
-   1. If your merge request includes backend changes [^1], it must be
+1. If your merge request includes backend changes [^1], it must be
    **approved by a [backend maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab-ce_maintainers_backend)**.
-   1. If your merge request includes database migrations or changes to expensive queries [^2], it must be
+1. If your merge request includes database migrations or changes to expensive queries [^2], it must be
    **approved by a [database maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab-ce_maintainers_database)**.
-   1. If your merge request includes frontend changes [^1], it must be
+1. If your merge request includes frontend changes [^1], it must be
    **approved by a [frontend maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab-ce_maintainers_frontend)**.
-   1. If your merge request includes UX changes [^1], it must be
+1. If your merge request includes UX changes [^1], it must be
    **approved by a [UX team member][team]**.
-   1. If your merge request includes adding a new JavaScript library [^1], it must be
+1. If your merge request includes adding a new JavaScript library [^1], it must be
    **approved by a [frontend lead][team]**.
-   1. If your merge request includes adding a new UI/UX paradigm [^1], it must be
+1. If your merge request includes adding a new UI/UX paradigm [^1], it must be
    **approved by a [UX lead][team]**.
-   1. If your merge request includes a new dependency or a filesystem change, it must be
+1. If your merge request includes a new dependency or a filesystem change, it must be
    **approved by a [Distribution team member][team]**. See how to work with the [Distribution team](https://about.gitlab.com/handbook/engineering/dev-backend/distribution/) for more details.
 
 #### Security requirements

doc/development/database_debugging.md

@@ -9,31 +9,31 @@ An easy first step is to search for your error in Slack or google "GitLab (my er
 
 Available `RAILS_ENV`
 
- - `production` (generally not for your main GDK db, but you may need this for e.g. omnibus)
- - `development` (this is your main GDK db)
- - `test` (used for tests like rspec)
+- `production` (generally not for your main GDK db, but you may need this for e.g. omnibus)
+- `development` (this is your main GDK db)
+- `test` (used for tests like rspec)
 
 ## Nuke everything and start over
 
 If you just want to delete everything and start over with an empty DB (~1 minute):
 
- - `bundle exec rake db:reset RAILS_ENV=development`
+- `bundle exec rake db:reset RAILS_ENV=development`
 
 If you just want to delete everything and start over with dummy data (~40 minutes). This also does `db:reset` and runs DB-specific migrations:
 
- - `bundle exec rake dev:setup RAILS_ENV=development`
+- `bundle exec rake dev:setup RAILS_ENV=development`
 
 If your test DB is giving you problems, it is safe to nuke it because it doesn't contain important data:
 
- - `bundle exec rake db:reset RAILS_ENV=test`
+- `bundle exec rake db:reset RAILS_ENV=test`
 
 ## Migration wrangling
 
- - `bundle exec rake db:migrate RAILS_ENV=development`: Execute any pending migrations that you may have picked up from a MR
- - `bundle exec rake db:migrate:status RAILS_ENV=development`: Check if all migrations are `up` or `down`
- - `bundle exec rake db:migrate:down VERSION=20170926203418 RAILS_ENV=development`: Tear down a migration
- - `bundle exec rake db:migrate:up VERSION=20170926203418 RAILS_ENV=development`: Set up a migration
- - `bundle exec rake db:migrate:redo VERSION=20170926203418 RAILS_ENV=development`: Re-run a specific migration
+- `bundle exec rake db:migrate RAILS_ENV=development`: Execute any pending migrations that you may have picked up from a MR
+- `bundle exec rake db:migrate:status RAILS_ENV=development`: Check if all migrations are `up` or `down`
+- `bundle exec rake db:migrate:down VERSION=20170926203418 RAILS_ENV=development`: Tear down a migration
+- `bundle exec rake db:migrate:up VERSION=20170926203418 RAILS_ENV=development`: Set up a migration
+- `bundle exec rake db:migrate:redo VERSION=20170926203418 RAILS_ENV=development`: Re-run a specific migration
 
 ## Manually access the database
 
@@ -45,12 +45,12 @@ bundle exec rails dbconsole RAILS_ENV=development
 bundle exec rails db RAILS_ENV=development
 ```
 
- - `\q`: Quit/exit
- - `\dt`: List all tables
- - `\d+ issues`: List columns for `issues` table
- - `CREATE TABLE board_labels();`: Create a table called `board_labels`
- - `SELECT * FROM schema_migrations WHERE version = '20170926203418';`: Check if a migration was run
- - `DELETE FROM schema_migrations WHERE version = '20170926203418';`: Manually remove a migration
+- `\q`: Quit/exit
+- `\dt`: List all tables
+- `\d+ issues`: List columns for `issues` table
+- `CREATE TABLE board_labels();`: Create a table called `board_labels`
+- `SELECT * FROM schema_migrations WHERE version = '20170926203418';`: Check if a migration was run
+- `DELETE FROM schema_migrations WHERE version = '20170926203418';`: Manually remove a migration
 
 ## FAQ
 

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

@@ -140,8 +140,8 @@ All reviewers can help ensure accuracy, clarity, completeness, and adherence to
 
 - 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).
+  1. The technical writer -- **if** their review was not performed prior to the merge.
+  1. 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.
 
 ### Technical Writer role

doc/development/file_storage.md

@@ -92,8 +92,8 @@ in your uploader, you need to either 1) include `RecordsUpload::Concern` and pre
 
 The `CarrierWave::Uploader#store_dir` is overridden to
 
- - `GitlabUploader.base_dir` + `GitlabUploader.dynamic_segment` when the store is LOCAL
- - `GitlabUploader.dynamic_segment` when the store is REMOTE (the bucket name is used to namespace)
+- `GitlabUploader.base_dir` + `GitlabUploader.dynamic_segment` when the store is LOCAL
+- `GitlabUploader.dynamic_segment` when the store is REMOTE (the bucket name is used to namespace)
 
 ### Using `ObjectStorage::Extension::RecordsUploads`
 

doc/development/geo.md

@@ -341,9 +341,9 @@ not used, so sessions etc. aren't shared between nodes.
 GitLab can optionally use Object Storage to store data it would
 otherwise store on disk. These things can be:
 
- - LFS Objects
- - CI Job Artifacts
- - Uploads
+- LFS Objects
+- CI Job Artifacts
+- Uploads
 
 Objects that are stored in object storage, are not handled by Geo. Geo
 ignores items in object storage. Either:
@@ -412,15 +412,15 @@ The Geo **primary** stores events in the `geo_event_log` table. Each
 entry in the log contains a specific type of event. These type of
 events include:
 
- - Repository Deleted event
- - Repository Renamed event
- - Repositories Changed event
- - Repository Created event
- - Hashed Storage Migrated event
- - Lfs Object Deleted event
- - Hashed Storage Attachments event
- - Job Artifact Deleted event
- - Upload Deleted event
+- Repository Deleted event
+- Repository Renamed event
+- Repositories Changed event
+- Repository Created event
+- Hashed Storage Migrated event
+- Lfs Object Deleted event
+- Hashed Storage Attachments event
+- Job Artifact Deleted event
+- Upload Deleted event
 
 ### Geo Log Cursor
 

doc/development/git_object_deduplication.md

@@ -80,9 +80,9 @@ In conclusion, we need three things for effective object deduplication
 across a collection of GitLab project repositories at the Git level:
 
 1. A pool repository must exist.
-2.  The participating project repositories must be linked to the pool
+1. The participating project repositories must be linked to the pool
    repository via their respective `objects/info/alternates` files.
-3.  The pool repository must contain Git object data common to the
+1. The pool repository must contain Git object data common to the
    participating project repositories.
 
 ### Deduplication factor

doc/development/new_fe_guide/style/javascript.md

@@ -71,7 +71,6 @@ class myClass {
 }
 const instance = new myClass();
 instance.makeRequest();
-
 ```
 
 ## Avoid classes to handle DOM events
@@ -189,8 +188,8 @@ disabled due to legacy compatibility reasons but they are in the process of bein
 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](http://eslint.org/docs/rules/no-new)
-  - [class-method-use-this](http://eslint.org/docs/rules/class-methods-use-this)
+- [no-new](http://eslint.org/docs/rules/no-new)
+- [class-method-use-this](http://eslint.org/docs/rules/class-methods-use-this)
 
 > Note: Disable these rules on a per line basis. This makes it easier to refactor
   in the future. E.g. use `eslint-disable-next-line` or `eslint-disable-line`.

doc/development/testing_guide/review_apps.md

@@ -137,8 +137,8 @@ secure note named **gitlab-{ce,ee} Review App's root password**.
 
 ### Run a Rails console
 
-1. [Filter Workloads by your Review App slug](https://console.cloud.google.com/kubernetes/workload?project=gitlab-review-apps)
-  , e.g. `review-qa-raise-e-12chm0`.
+1. [Filter Workloads by your Review App slug](https://console.cloud.google.com/kubernetes/workload?project=gitlab-review-apps),
+   e.g. `review-qa-raise-e-12chm0`.
 1. Find and open the `task-runner` Deployment, e.g. `review-qa-raise-e-12chm0-task-runner`.
 1. Click on the Pod in the "Managed pods" section, e.g. `review-qa-raise-e-12chm0-task-runner-d5455cc8-2lsvz`.
 1. Click on the `KUBECTL` dropdown, then `Exec` -> `task-runner`.

doc/university/training/topics/getting_started.md

@@ -11,6 +11,7 @@ comments: false
   ```bash
   git init
   ```
+
 - Copy an existing project by cloning the repository through:
 
   ```bash