Fix unordered list spacing

Correct the spacing of unordered markdown lists
in docs, to maintain standards of documentation.

doc/administration/repository_checks.md

@@ -33,8 +33,8 @@ in `repocheck.log`:
 
 - in the [admin panel](logs.md#repochecklog)
 - or on disk, see:
-    - `/var/log/gitlab/gitlab-rails` for Omnibus installations
-    - `/home/git/gitlab/log` for installations from source
+  - `/var/log/gitlab/gitlab-rails` for Omnibus installations
+  - `/home/git/gitlab/log` for installations from source
 
 If for some reason the periodic repository check caused a lot of false
 alarms you can choose to clear *all* repository check states by

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,20 +58,20 @@ 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
-      **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
-      **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
-      **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
-      **approved by a [UX team member][team]**.
-   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
-      **approved by a [UX lead][team]**.
-   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.
+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
+   **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
+   **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
+   **approved by a [UX team member][team]**.
+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
+   **approved by a [UX lead][team]**.
+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/diffs.md

@@ -133,4 +133,4 @@ File diff will be suppressed (technically different from collapsed, but behaves
 Diff Viewers, which can be found on `models/diff_viewer/*` are classes used to map metadata about each type of Diff File. It has information
 whether it's a binary, which partial should be used to render it or which File extensions this class accounts for.
 
-`DiffViewer::Base` validates _blobs_ (old and new versions) content, extension and file type in order to check if it can be rendered.
\ No newline at end of file
+`DiffViewer::Base` validates _blobs_ (old and new versions) content, extension and file type in order to check if it can be rendered.

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

@@ -121,27 +121,27 @@ All reviewers can help ensure accuracy, clarity, completeness, and adherence to
 
 - **Prior to merging**, documentation changes committed by the developer must be reviewed by:
 
-   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.
-      - 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.
-      - 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 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.
+  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.
+     - 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.
+     - 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 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 maintainer 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).
+  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/fe_guide/icons.md

@@ -21,10 +21,10 @@ To use a sprite Icon in HAML or Rails we use a specific helper function :
 sprite_icon(icon_name, size: nil, css_class: '')
 ```
 
--   **icon_name** Use the icon_name that you can find in the SVG Sprite
-    ([Overview is available here][svg-preview]).
--   **size (optional)** Use one of the following sizes : 16, 24, 32, 48, 72 (this will be translated into a `s16` class)
--   **css_class (optional)** If you want to add additional css classes
+- **icon_name** Use the icon_name that you can find in the SVG Sprite
+  ([Overview is available here][svg-preview]).
+- **size (optional)** Use one of the following sizes : 16, 24, 32, 48, 72 (this will be translated into a `s16` class)
+- **css_class (optional)** If you want to add additional css classes
 
 **Example**
 
@@ -65,10 +65,10 @@ export default {
 </template>
 ```
 
--   **name** Name of the Icon in the SVG Sprite  ([Overview is available here][svg-preview]).
--   **size (optional)** Number value for the size which is then mapped to a specific CSS class
-    (Available Sizes: 8, 12, 16, 18, 24, 32, 48, 72 are mapped to `sXX` css classes)
--   **css-classes (optional)** Additional CSS Classes to add to the svg tag.
+- **name** Name of the Icon in the SVG Sprite  ([Overview is available here][svg-preview]).
+- **size (optional)** Number value for the size which is then mapped to a specific CSS class
+  (Available Sizes: 8, 12, 16, 18, 24, 32, 48, 72 are mapped to `sXX` css classes)
+- **css-classes (optional)** Additional CSS Classes to add to the svg tag.
 
 ### Usage in HTML/JS
 

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
 
@@ -526,4 +526,4 @@ old method:
 
 - Replication is synchronous and we preserve the order of events.
 - Replication of the events happen at the same time as the changes in the
-   database.
+  database.

doc/development/git_object_deduplication.md

@@ -79,11 +79,11 @@ at the Rails application level in SQL.
 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
-    repository via their respective `objects/info/alternates` files.
-3.  The pool repository must contain Git object data common to the
-    participating project repositories.
+1. A pool repository must exist.
+1. The participating project repositories must be linked to the pool
+   repository via their respective `objects/info/alternates` files.
+1. The pool repository must contain Git object data common to the
+   participating project repositories.
 
 ### Deduplication factor
 
@@ -105,71 +105,71 @@ With pool repositories we made a fresh start. These live in their own
 `pool_repositories` SQL table. The relations between these two tables
 are as follows:
 
--   a `Project` belongs to at most one `PoolRepository`
-    (`project.pool_repository`)
--   as an automatic consequence of the above, a `PoolRepository` has
-    many `Project`s
--   a `PoolRepository` has exactly one "source `Project`"
-    (`pool.source_project`)
+- a `Project` belongs to at most one `PoolRepository`
+  (`project.pool_repository`)
+- as an automatic consequence of the above, a `PoolRepository` has
+  many `Project`s
+- a `PoolRepository` has exactly one "source `Project`"
+  (`pool.source_project`)
 
 > TODO Fix invalid SQL data for pools created prior to GitLab 11.11
 > <https://gitlab.com/gitlab-org/gitaly/issues/1653>.
 
 ### Assumptions
 
--   All repositories in a pool must use [hashed
-    storage](../administration/repository_storage_types.md). This is so
-    that we don't have to ever worry about updating paths in
-    `object/info/alternates` files.
--   All repositories in a pool must be on the same Gitaly storage shard.
-    The Git alternates mechanism relies on direct disk access across
-    multiple repositories, and we can only assume direct disk access to
-    be possible within a Gitaly storage shard.
--   The only two ways to remove a member project from a pool are (1) to
-    delete the project or (2) to move the project to another Gitaly
-    storage shard.
+- All repositories in a pool must use [hashed
+  storage](../administration/repository_storage_types.md). This is so
+  that we don't have to ever worry about updating paths in
+  `object/info/alternates` files.
+- All repositories in a pool must be on the same Gitaly storage shard.
+  The Git alternates mechanism relies on direct disk access across
+  multiple repositories, and we can only assume direct disk access to
+  be possible within a Gitaly storage shard.
+- The only two ways to remove a member project from a pool are (1) to
+  delete the project or (2) to move the project to another Gitaly
+  storage shard.
 
 ### Creating pools and pool memberships
 
--   When a pool gets created, it must have a source project. The initial
-    contents of the pool repository are a Git clone of the source
-    project repository.
--   The occasion for creating a pool is when an existing eligible
-    (public, hashed storage, non-forked) GitLab project gets forked and
-    this project does not belong to a pool repository yet. The fork
-    parent project becomes the source project of the new pool, and both
-    the fork parent and the fork child project become members of the new
-    pool.
--   Once project A has become the source project of a pool, all future
-    eligible forks of A will become pool members.
--   If the fork source is itself a fork, the resulting repository will
-    neither join the repository nor will a new pool repository be
-    seeded.
-
-    eg:
-
-    Suppose fork A is part of a pool repository, any forks created off
-    of fork A *will not* be a part of the pool repository that fork A is
-    a part of.
-
-    Suppose B is a fork of A, and A does not belong to an object pool.
-    Now C gets created as a fork of B. C will not be part of a pool
-    repository.
+- When a pool gets created, it must have a source project. The initial
+  contents of the pool repository are a Git clone of the source
+  project repository.
+- The occasion for creating a pool is when an existing eligible
+  (public, hashed storage, non-forked) GitLab project gets forked and
+  this project does not belong to a pool repository yet. The fork
+  parent project becomes the source project of the new pool, and both
+  the fork parent and the fork child project become members of the new
+  pool.
+- Once project A has become the source project of a pool, all future
+  eligible forks of A will become pool members.
+- If the fork source is itself a fork, the resulting repository will
+  neither join the repository nor will a new pool repository be
+  seeded.
+
+  eg:
+
+  Suppose fork A is part of a pool repository, any forks created off
+  of fork A *will not* be a part of the pool repository that fork A is
+  a part of.
+
+  Suppose B is a fork of A, and A does not belong to an object pool.
+  Now C gets created as a fork of B. C will not be part of a pool
+  repository.
 
 > TODO should forks of forks be deduplicated?
 > <https://gitlab.com/gitlab-org/gitaly/issues/1532>
 
 ### Consequences
 
--   If a normal Project participating in a pool gets moved to another
-    Gitaly storage shard, its "belongs to PoolRepository" relation will
-    be broken. Because of the way moving repositories between shard is
-    implemented, we will automatically get a fresh self-contained copy
-    of the project's repository on the new storage shard.
--   If the source project of a pool gets moved to another Gitaly storage
-    shard or is deleted the "source project" relation is not broken.
-    However, as of GitLab 12.0 a pool will not fetch from a source
-    unless the source is on the same Gitaly shard.
+- If a normal Project participating in a pool gets moved to another
+  Gitaly storage shard, its "belongs to PoolRepository" relation will
+  be broken. Because of the way moving repositories between shard is
+  implemented, we will automatically get a fresh self-contained copy
+  of the project's repository on the new storage shard.
+- If the source project of a pool gets moved to another Gitaly storage
+  shard or is deleted the "source project" relation is not broken.
+  However, as of GitLab 12.0 a pool will not fetch from a source
+  unless the source is on the same Gitaly shard.
 
 ## Consistency between the SQL pool relation and Gitaly
 

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`.
@@ -196,7 +196,7 @@ For the record, the debugging steps to find out this issue were:
 1. `kubectl describe pod <pod name>` & confirm exact error message
 1. Web search for exact error message, following rabbit hole to [a relevant kubernetes bug report](https://github.com/kubernetes/kubernetes/issues/57345)
 1. Access the node over SSH via the GCP console (**Computer Engine > VM
-  instances** then click the "SSH" button for the node where the `dns-gitlab-review-app-external-dns` pod runs)
+   instances** then click the "SSH" button for the node where the `dns-gitlab-review-app-external-dns` pod runs)
 1. In the node: `systemctl --version` => systemd 232
 1. Gather some more information:
    - `mount | grep kube | wc -l` => e.g. 290
@@ -211,7 +211,7 @@ For the record, the debugging steps to find out this issue were:
 To resolve the problem, we needed to (forcibly) drain some nodes:
 
 1. Try a normal drain on the node where the `dns-gitlab-review-app-external-dns`
-  pod runs so that Kubernetes automatically move it to another node: `kubectl drain NODE_NAME`
+   pod runs so that Kubernetes automatically move it to another node: `kubectl drain NODE_NAME`
 1. If that doesn't work, you can also perform a forcible "drain" the node by removing all pods: `kubectl delete pods --field-selector=spec.nodeName=NODE_NAME`
 1. In the node:
    - Perform `systemctl daemon-reload` to remove the dead/inactive units

doc/gitlab-basics/create-project.md

@@ -23,18 +23,18 @@ To create a project in GitLab:
 To create a new blank project on the **New project** page:
 
 1. On the **Blank project** tab, provide the following information:
-    - The name of your project in the **Project name** field. You can't use
-      special characters, but you can use spaces, hyphens, underscores or even
-      emoji.
-    - The **Project description (optional)** field enables you to enter a
-      description for your project's dashboard, which will help others
-      understand what your project is about. Though it's not required, it's a good
-      idea to fill this in.
-    - Changing the **Visibility Level** modifies the project's
-      [viewing and access rights](../public_access/public_access.md) for users.
-    - Selecting the **Initialize repository with a README** option creates a
-      README file so that the Git repository is initialized, has a default branch, and
-      can be cloned.
+   - The name of your project in the **Project name** field. You can't use
+     special characters, but you can use spaces, hyphens, underscores or even
+     emoji.
+   - The **Project description (optional)** field enables you to enter a
+     description for your project's dashboard, which will help others
+     understand what your project is about. Though it's not required, it's a good
+     idea to fill this in.
+   - Changing the **Visibility Level** modifies the project's
+     [viewing and access rights](../public_access/public_access.md) for users.
+   - Selecting the **Initialize repository with a README** option creates a
+     README file so that the Git repository is initialized, has a default branch, and
+     can be cloned.
 1. Click **Create project**.
 
 ## Project templates
@@ -60,8 +60,8 @@ To use a built-in template on the **New project** page:
 
 1. On the **Create from template** tab, select the **Built-in** tab.
 1. From the list of available built-in templates, click the:
-    - **Preview** button to look at the template source itself.
-    - **Use template** button to start creating the project.
+   - **Preview** button to look at the template source itself.
+   - **Use template** button to start creating the project.
 1. Finish creating the project by filling out the project's details. The process is the same as for
    using a [blank project](#blank-projects).
 
@@ -83,8 +83,8 @@ To use a custom project template on the **New project** page:
 
 1. On the **Create from template** tab, select the **Instance** tab or the **Group** tab.
 1. From the list of available custom templates, click the:
-    - **Preview** button to look at the template source itself.
-    - **Use template** button to start creating the project.
+   - **Preview** button to look at the template source itself.
+   - **Use template** button to start creating the project.
 1. Finish creating the project by filling out the project's details. The process is the same as for
    using a [blank project](#blank-projects).
 

doc/university/training/topics/getting_started.md

@@ -8,14 +8,15 @@ comments: false
 
 - Create a new repository by instantiating it through:
 
-    ```bash
-    git init
-    ```
+  ```bash
+  git init
+  ```
+
 - Copy an existing project by cloning the repository through:
 
-    ```bash
-    git clone <url>
-    ```
+  ```bash
+  git clone <url>
+  ```
 
 ## Central Repos
 
@@ -23,9 +24,9 @@ comments: false
 - Bare repositories don't allow file editing or committing changes.
 - Create a bare repo with:
 
-    ```bash
-    git init --bare project-name.git
-    ```
+  ```bash
+  git init --bare project-name.git
+  ```
 
 ## Instantiate workflow with clone