Resolve Markdown ordered lists not conforming to styleguide

doc/development/fe_guide/vuex.md

@@ -114,19 +114,21 @@ When a request is made we often want to show a loading state to the user.
 Instead of creating an action to toggle the loading state and dispatch it in the component,
 create:
+
 1. An action `requestSomething`, to toggle the loading state
 1. An action `receiveSomethingSuccess`, to handle the success callback
 1. An action `receiveSomethingError`, to handle the error callback
 1. An action `fetchSomething` to make the request.
     1. In case your application does more than a `GET` request you can use these as examples:
-        1. `PUT`: `createSomething`
-        2. `POST`: `updateSomething`
-        3. `DELETE`: `deleteSomething`
+        - `PUT`: `createSomething`
+        - `POST`: `updateSomething`
+        - `DELETE`: `deleteSomething`
 The component MUST only dispatch the `fetchNamespace` action. Actions namespaced with `request` or `receive` should not be called from the component
 The `fetch` action will be responsible to dispatch `requestNamespace`, `receiveNamespaceSuccess` and `receiveNamespaceError`
 By following this pattern we guarantee:
+
 1. All applications follow the same pattern, making it easier for anyone to maintain the code
 1. All data in the application follows the same lifecycle pattern
 1. Actions are contained and human friendly
@@ -297,12 +299,12 @@ export default {
     ```javascript
       // component.vue
-  
+
       // bad
       created() {
         this.$store.commit('mutation');
       }
-  
+
       // good
       created() {
         this.$store.dispatch('action');

doc/development/github_importer.md

@@ -99,8 +99,8 @@ This worker will wrap up the import process by performing some housekeeping
 Advancing stages is done in one of two ways:
-1. Scheduling the worker for the next stage directly.
-2. Scheduling a job for `Gitlab::GithubImport::AdvanceStageWorker` which will
+- Scheduling the worker for the next stage directly.
+- Scheduling a job for `Gitlab::GithubImport::AdvanceStageWorker` which will
    advance the stage when all work of the current stage has been completed.
 The first approach should only be used by workers that perform all their work in
@@ -147,7 +147,7 @@ We handle this by doing the following:
 1. Once we hit the rate limit all jobs will automatically reschedule themselves
    in such a way that they are not executed until the rate limit has been reset.
-2. We cache the mapping of GitHub users to GitLab users in Redis.
+1. We cache the mapping of GitHub users to GitLab users in Redis.
 More information on user caching can be found below.
@@ -157,21 +157,21 @@ When mapping GitHub users to GitLab users we need to (in the worst case)
 perform:
 1. One API call to get the user's Email address.
-2. Two database queries to see if a corresponding GitLab user exists. One query
+1. Two database queries to see if a corresponding GitLab user exists. One query
    will try to find the user based on the GitHub user ID, while the second query
    is used to find the user using their GitHub Email address.
 Because this process is quite expensive we cache the result of these lookups in
 Redis. For every user looked up we store three keys:
-1. A Redis key mapping GitHub usernames to their Email addresses.
-2. A Redis key mapping a GitHub Email addresses to a GitLab user ID.
-3. A Redis key mapping a GitHub user ID to GitLab user ID.
+- A Redis key mapping GitHub usernames to their Email addresses.
+- A Redis key mapping a GitHub Email addresses to a GitLab user ID.
+- A Redis key mapping a GitHub user ID to GitLab user ID.
 There are two types of lookups we cache:
-1. A positive lookup, meaning we found a GitLab user ID.
-2. A negative lookup, meaning we didn't find a GitLab user ID. Caching this
+- A positive lookup, meaning we found a GitLab user ID.
+- A negative lookup, meaning we didn't find a GitLab user ID. Caching this
    prevents us from performing the same work for users that we know don't exist
    in our GitLab database.

doc/development/instrumentation.md

@@ -117,11 +117,11 @@ The block is executed and the execution time is stored as a set of fields in the
 currently running transaction. If no transaction is present the block is yielded
 without measuring anything.
-3 values are measured for a block:
-1. The real time elapsed, stored in NAME_real_time.
-2. The CPU time elapsed, stored in NAME_cpu_time.
-3. The call count, stored in NAME_call_count.
+Three values are measured for a block:
+- The real time elapsed, stored in NAME_real_time.
+- The CPU time elapsed, stored in NAME_cpu_time.
+- The call count, stored in NAME_call_count.
 Both the real and CPU timings are measured in milliseconds.

doc/development/new_fe_guide/development/testing.md

@@ -140,20 +140,21 @@ Some regressions only affect a specific browser version. We can install and test
 ### Browserstack
-[Browserstack](https://www.browserstack.com/) allows you to test more than 1200 mobile devices and browsers. 
+[Browserstack](https://www.browserstack.com/) allows you to test more than 1200 mobile devices and browsers.
 You can use it directly through the [live app](https://www.browserstack.com/live) or you can install the [chrome extension](https://chrome.google.com/webstore/detail/browserstack/nkihdmlheodkdfojglpcjjmioefjahjb) for easy access.
 You can find the credentials on 1Password, under `frontendteam@gitlab.com`.
 ### Firefox
 #### macOS
+
 You can download any older version of Firefox from the releases FTP server, https://ftp.mozilla.org/pub/firefox/releases/
 1. From the website, select a version, in this case `50.0.1`.
-2. Go to the mac folder.
-3. Select your preferred language, you will find the dmg package inside, download it.
-4. Drag and drop the application to any other folder but the `Applications` folder.
-5. Rename the application to something like `Firefox_Old`.
-6. Move the application to the `Applications` folder.
-7. Open up a terminal and run `/Applications/Firefox_Old.app/Contents/MacOS/firefox-bin -profilemanager` to create a new profile specific to that Firefox version.
-8. Once the profile has been created, quit the app, and run it again like normal. You now have a working older Firefox version.
+1. Go to the mac folder.
+1. Select your preferred language, you will find the dmg package inside, download it.
+1. Drag and drop the application to any other folder but the `Applications` folder.
+1. Rename the application to something like `Firefox_Old`.
+1. Move the application to the `Applications` folder.
+1. Open up a terminal and run `/Applications/Firefox_Old.app/Contents/MacOS/firefox-bin -profilemanager` to create a new profile specific to that Firefox version.
+1. Once the profile has been created, quit the app, and run it again like normal. You now have a working older Firefox version.

doc/development/performance.md

@@ -9,17 +9,17 @@ The process of solving performance problems is roughly as follows:
 1. Make sure there's an issue open somewhere (e.g., on the GitLab CE issue
    tracker), create one if there isn't. See [#15607][#15607] for an example.
-2. Measure the performance of the code in a production environment such as
+1. Measure the performance of the code in a production environment such as
    GitLab.com (see the [Tooling](#tooling) section below). Performance should be
    measured over a period of _at least_ 24 hours.
-3. Add your findings based on the measurement period (screenshots of graphs,
+1. Add your findings based on the measurement period (screenshots of graphs,
    timings, etc) to the issue mentioned in step 1.
-4. Solve the problem.
-5. Create a merge request, assign the "Performance" label and assign it to
+1. Solve the problem.
+1. Create a merge request, assign the "Performance" label and assign it to
    [@yorickpeterse][yorickpeterse] for reviewing.
-6. Once a change has been deployed make sure to _again_ measure for at least 24
+1. Once a change has been deployed make sure to _again_ measure for at least 24
    hours to see if your changes have any impact on the production environment.
-7. Repeat until you're done.
+1. Repeat until you're done.
 When providing timings make sure to provide:
@@ -94,14 +94,14 @@ result of this should be used instead of the `Benchmark` module.
 In short:
-1. Don't trust benchmarks you find on the internet.
-2. Never make claims based on just benchmarks, always measure in production to
+- Don't trust benchmarks you find on the internet.
+- Never make claims based on just benchmarks, always measure in production to
    confirm your findings.
-3. X being N times faster than Y is meaningless if you don't know what impact it
+- X being N times faster than Y is meaningless if you don't know what impact it
    will actually have on your production environment.
-4. A production environment is the _only_ benchmark that always tells the truth
+- A production environment is the _only_ benchmark that always tells the truth
    (unless your performance monitoring systems are not set up correctly).
-5. If you must write a benchmark use the benchmark-ips Gem instead of Ruby's
+- If you must write a benchmark use the benchmark-ips Gem instead of Ruby's
    `Benchmark` module.
 ## Profiling

doc/development/post_deployment_migrations.md

@@ -57,13 +57,13 @@ depends on this column being present while it's running. Normally you'd follow
 these steps in such a case:
 1. Stop the GitLab instance
-2. Run the migration removing the column
-3. Start the GitLab instance again
+1. Run the migration removing the column
+1. Start the GitLab instance again
 Using post deployment migrations we can instead follow these steps:
 1. Deploy a new version of GitLab while ignoring post deployment migrations
-2. Re-run `rake db:migrate` but without the environment variable set
+1. Re-run `rake db:migrate` but without the environment variable set
 Here we don't need any downtime as the migration takes place _after_ a new
 version (which doesn't depend on the column anymore) has been deployed.

doc/development/query_count_limits.md

@@ -8,8 +8,8 @@ in test environments we'll raise an error when this threshold is exceeded.
 When a test fails because it executes more than 100 SQL queries there are two
 solutions to this problem:
-1. Reduce the number of SQL queries that are executed.
-2. Whitelist the controller or API endpoint.
+- Reduce the number of SQL queries that are executed.
+- Whitelist the controller or API endpoint.
 You should only resort to whitelisting when an existing controller or endpoint
 is to blame as in this case reducing the number of SQL queries can take a lot of

doc/development/swapping_tables.md

@@ -8,8 +8,8 @@ Let's say you want to swap the table "events" with "events_for_migration". In
 this case you need to follow 3 steps:
 1. Rename "events" to "events_temporary"
-2. Rename "events_for_migration" to "events"
-3. Rename "events_temporary" to "events_for_migration"
+1. Rename "events_for_migration" to "events"
+1. Rename "events_temporary" to "events_for_migration"
 Rails allows you to do this using the `rename_table` method:

doc/development/ui_guide.md

@@ -54,12 +54,12 @@ information from database or file system
 When exporting SVGs, be sure to follow the following guidelines:
-1. Convert all strokes to outlines.
-2. Use pathfinder tools to combine overlapping paths and create compound paths.
-3. SVGs that are limited to one color should be exported without a fill color so the color can be set using CSS.
-4. Ensure that exported SVGs have been run through an [SVG cleaner](https://github.com/RazrFalcon/SVGCleaner) to remove unused elements and attributes.
-You can open your svg in a text editor to ensure that it is clean. 
+- Convert all strokes to outlines.
+- Use pathfinder tools to combine overlapping paths and create compound paths.
+- SVGs that are limited to one color should be exported without a fill color so the color can be set using CSS.
+- Ensure that exported SVGs have been run through an [SVG cleaner](https://github.com/RazrFalcon/SVGCleaner) to remove unused elements and attributes.
+You can open your svg in a text editor to ensure that it is clean.
 Incorrect files will look like this:
 ```xml

doc/development/ux_guide/users.md

@@ -101,7 +101,7 @@ GitLab's interface initially attracted Nazim when he was comparing version contr
 ### Demographics
 **Age**
- 
+
 42 years old
 **Location**
@@ -148,11 +148,11 @@ Matthieu describes GitLab as:
 >"the only tool that offers the real feeling of having everything you need in one place."
-He credits himself as being entirely responsible for moving his company to GitLab. 
+He credits himself as being entirely responsible for moving his company to GitLab.
 ### Frustrations
 #### Updating to the latest release
-Matthieu introduced his company to GitLab. He is responsible for maintaining and managing the company's installation in addition to his day job. He feels updates are too frequent and he doesn't always have sufficient time to update GitLab. As a result, he's not up to date with releases. 
+Matthieu introduced his company to GitLab. He is responsible for maintaining and managing the company's installation in addition to his day job. He feels updates are too frequent and he doesn't always have sufficient time to update GitLab. As a result, he's not up to date with releases.
 Matthieu tried to set up automatic updates, however, as he isn't a Systems Administrator, he wasn't confident in his setup. He feels he should be able to "upgrade without users even noticing" but hasn't figured out how to do this yet. Matthieu would like the "update process to be triggered from the Admin Panel, perhaps accompanied with a changelog and the option to skip updates."
@@ -173,11 +173,11 @@ It's Matthieu's responsibility to get teams across his organization up and runni
 He states that there has been: "a sluggishness of others to adapt" and it's "a low-effort adaptation at that."
 ### Goals
-* To save time. One of the reasons Matthieu moved his company to GitLab was to reduce the effort it took him to manage and configure multiple tools, thus saving him time. He has to balance his day job in addition to managing the company's GitLab installation and onboarding new teams to GitLab. 
-* To use a platform which is easy to manage. Matthieu isn't a Systems Administrator, and when updating GitLab, creating backups, etc. He would prefer to work within GitLab's UI. Explanations / guided instructions when configuring settings in GitLab's interface would really help Matthieu. He needs reassurance that what he is about to change is 
-1. the right setting
-2. will provide him with the desired result he wants.
+* To save time. One of the reasons Matthieu moved his company to GitLab was to reduce the effort it took him to manage and configure multiple tools, thus saving him time. He has to balance his day job in addition to managing the company's GitLab installation and onboarding new teams to GitLab.
+* To use a platform which is easy to manage. Matthieu isn't a Systems Administrator, and when updating GitLab, creating backups, etc. He would prefer to work within GitLab's UI. Explanations / guided instructions when configuring settings in GitLab's interface would really help Matthieu. He needs reassurance that what he is about to change is
+- The right setting.
+- Will provide him with the desired result he wants.
 * Matthieu needs to educate his colleagues about GitLab. Matthieu's colleagues won't adopt GitLab as they're unaware of its capabilities and the positive impact it could have on their work. Matthieu needs support in getting this message across to them.
@@ -307,4 +307,4 @@ Karolina has an interest in UX and therefore has strong opinions about how GitLa
 ### Goals
 * To develop her programming experience and to learn from other developers.
 * To contribute to both her own and other open source projects.
-* To use a fast and intuitive version control platform.
\ No newline at end of file
+* To use a fast and intuitive version control platform.

doc/development/what_requires_downtime.md

@@ -300,7 +300,7 @@ The same applies to `rename_column_using_background_migration`:
 1. Create a migration using the helper, which will schedule background
    migrations to spread the writes over a longer period of time.
-2. In the next monthly release, create a clean-up migration to steal from the
+1. In the next monthly release, create a clean-up migration to steal from the
    Sidekiq queues, migrate any missing rows, and cleanup the rename. This
    migration should skip the steps after stealing from the Sidekiq queues if the
    column has already been renamed.

doc/gitlab-basics/create-your-ssh-keys.md

@@ -12,7 +12,7 @@
     ![SSH Keys](img/profile_settings_ssh_keys.png)
-3. Paste your **public** key that you generated in the first step in the 'Key'
+1. Paste your **public** key that you generated in the first step in the 'Key'
    box.
     ![Paste SSH public key](img/profile_settings_ssh_keys_paste_pub.png)

doc/integration/akismet.md

@@ -20,17 +20,17 @@ To use Akismet:
 1. Go to the URL: https://akismet.com/account/
-2. Sign-in or create a new account.
-3. Click on **Show** to reveal the API key.
-4. Go to Applications Settings on Admin Area (`admin/application_settings`)
-5. Check the **Enable Akismet** checkbox
-6. Fill in the API key from step 3.
-7. Save the configuration.
+1. Sign-in or create a new account.
+1. Click on **Show** to reveal the API key.
+1. Go to Applications Settings on Admin Area (`admin/application_settings`)
+1. Check the **Enable Akismet** checkbox
+1. Fill in the API key from step 3.
+1. Save the configuration.
 ![Screenshot of Akismet settings](img/akismet_settings.png)
@@ -42,9 +42,9 @@ To use Akismet:
 As a way to better recognize between spam and ham, you can train the Akismet
 filter whenever there is a false positive or false negative.
-When an entry is recognized as spam, it is rejected and added to the Spam Logs. 
+When an entry is recognized as spam, it is rejected and added to the Spam Logs.
 From here you can review if they are really spam. If one of them is not really
-spam, you can use the **Submit as ham** button to tell Akismet that it falsely 
+spam, you can use the **Submit as ham** button to tell Akismet that it falsely
 recognized an entry as spam.
 ![Screenshot of Spam Logs](img/spam_log.png)

doc/integration/recaptcha.md

@@ -8,19 +8,13 @@ to confirm that a real user, not a bot, is attempting to create an account.
 To use reCAPTCHA, first you must create a site and private key.
-1. Go to the URL: https://www.google.com/recaptcha/admin
-
-2. Fill out the form necessary to obtain reCAPTCHA keys.
-
-3. Login to your GitLab server, with administrator credentials.
-
-4. Go to Applications Settings on Admin Area (`admin/application_settings`)
-
-5. Fill all recaptcha fields with keys from previous steps
-
-6. Check the `Enable reCAPTCHA` checkbox
-
-7. Save the configuration.
+1. Go to the URL: <https://www.google.com/recaptcha/admin>.
+1. Fill out the form necessary to obtain reCAPTCHA keys.
+1. Login to your GitLab server, with administrator credentials.
+1. Go to Applications Settings on Admin Area (`admin/application_settings`).
+1. Fill all recaptcha fields with keys from previous steps.
+1. Check the `Enable reCAPTCHA` checkbox.
+1. Save the configuration.
 ## Enabling reCAPTCHA for user logins via passwords

doc/security/rack_attack.md

@@ -10,7 +10,7 @@ Rack Attack offers IP whitelisting, blacklisting, Fail2ban style filtering and
 tracking.
 **Note:** Starting with 11.2, Rack Attack is disabled by default. To continue
-using this feature, please enable it in your `gitlab.rb` by setting 
+using this feature, please enable it in your `gitlab.rb` by setting
 `gitlab_rails['rack_attack_git_basic_auth'] = true`.
 By default, user sign-in, user sign-up (if enabled), and user password reset is
@@ -41,7 +41,7 @@ For more information on how to use these options check out
     }
     ```
-3. Reconfigure GitLab:
+1. Reconfigure GitLab:
     ```
     sudo gitlab-ctl reconfigure
@@ -98,26 +98,26 @@ In case you want to remove a blocked IP, follow these steps:
     grep "Rack_Attack" /var/log/gitlab/gitlab-rails/production.log
     ```
-2. Since the blacklist is stored in Redis, you need to open up `redis-cli`:
+1. Since the blacklist is stored in Redis, you need to open up `redis-cli`:
     ```sh
     /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket
     ```
-3. You can remove the block using the following syntax, replacing `<ip>` with
+1. You can remove the block using the following syntax, replacing `<ip>` with
    the actual IP that is blacklisted:
     ```
     del cache:gitlab:rack::attack:allow2ban:ban:<ip>
     ```
-4. Confirm that the key with the IP no longer shows up:
+1. Confirm that the key with the IP no longer shows up:
     ```
     keys *rack::attack*
     ```
-5. Optionally, add the IP to the whitelist to prevent it from being blacklisted
+1. Optionally, add the IP to the whitelist to prevent it from being blacklisted
    again (see [settings](#settings)).
 ## Troubleshooting
@@ -129,11 +129,11 @@ the load balancer. In that case, you will need to:
 1. [Configure `nginx[real_ip_trusted_addresses]`](https://docs.gitlab.com/omnibus/settings/nginx.html#configuring-gitlab-trusted_proxies-and-the-nginx-real_ip-module).
    This will keep users' IPs from being listed as the load balancer IPs.
-2. Whitelist the load balancer's IP address(es) in the Rack Attack [settings](#settings).
-3. Reconfigure GitLab:
+1. Whitelist the load balancer's IP address(es) in the Rack Attack [settings](#settings).
+1. Reconfigure GitLab:
     ```
     sudo gitlab-ctl reconfigure
     ```
-4. [Remove the block via Redis.](#remove-blocked-ips-from-rack-attack-via-redis)
+1. [Remove the block via Redis.](#remove-blocked-ips-from-rack-attack-via-redis)

doc/security/two_factor_authentication.md

@@ -13,8 +13,8 @@ You can read more about it here:
 Users on GitLab, can enable it without any admin's intervention. If you want to
 enforce everyone to set up 2FA, you can choose from two different ways:
- 1. Enforce on next login
- 2. Suggest on next login, but allow a grace period before enforcing.
+- Enforce on next login.
+- Suggest on next login, but allow a grace period before enforcing.
 In the Admin area under **Settings** (`/admin/application_settings`), look for
 the "Sign-in Restrictions" area, where you can configure both.

doc/university/training/end-user/README.md

@@ -78,7 +78,7 @@ Workshop Time!
 ```bash
 git config --global user.name "Your Name"
 git config --global user.email you@example.com
-```    
+```
 - If you don't use the global flag you can set up a different author for
   each project
@@ -107,14 +107,14 @@ cd ~/development
 -or-
 mkdir ~/workspace
-cd ~/workspace  
+cd ~/workspace
 ```
 ---
 ## Git Basics
----  
+---
 ### Git Workflow
@@ -136,7 +136,7 @@ cd ~/workspace
   issue tracking, Merge Requests, and other features.
 - The hosted version of GitLab is gitlab.com
----  
+---
 ### New Project
@@ -150,12 +150,12 @@ cd ~/workspace
 ### Git and GitLab basics
 1. Edit `edit_this_file.rb` in `training-examples`
-2. See it listed as a changed file (working area)
-3. View the differences
-4. Stage the file
-5. Commit
-6. Push the commit to the remote
-7. View the git log
+1. See it listed as a changed file (working area)
+1. View the differences
+1. Stage the file
+1. Commit
+1. Push the commit to the remote
+1. View the git log
 ---
@@ -169,14 +169,14 @@ git push origin master
 git log
 ```
----  
+---
 ### Feature Branching
 1. Create a new feature branch called `squash_some_bugs`
-2. Edit `bugs.rb` and remove all the bugs.
-3. Commit
-4. Push
+1. Edit `bugs.rb` and remove all the bugs.
+1. Commit
+1. Push
 ---
@@ -250,16 +250,17 @@ git push origin squash_some_bugs
 ---
 ### Example Plan
+
 1. Checkout a new branch and edit conflicts.rb. Add 'Line4' and 'Line5'.
-2. Commit and push
-3. Checkout master and edit conflicts.rb. Add 'Line6' and 'Line7' below 'Line3'.
-4. Commit and push to master
-5. Create a merge request and watch it fail
-6. Rebase our new branch with master
-7. Fix conflicts on the conflicts.rb file.
-8. Stage the file and continue rebasing
-9. Force push the changes
-10. Finally continue with the Merge Request
+1. Commit and push
+1. Checkout master and edit conflicts.rb. Add 'Line6' and 'Line7' below 'Line3'.
+1. Commit and push to master
+1. Create a merge request and watch it fail
+1. Rebase our new branch with master
+1. Fix conflicts on the conflicts.rb file.
+1. Stage the file and continue rebasing
+1. Force push the changes
+1. Finally continue with the Merge Request
 ---
@@ -362,15 +363,15 @@ Don't reset after pushing
 ### Reset Workflow
 1. Edit file again 'edit_this_file.rb'
-2. Check status
-3. Add and commit with wrong message
-4. Check log
-5. Amend commit
-6. Check log
-7. Soft reset
-8. Check log
-9. Pull for updates
-10. Push changes
+1. Check status
+1. Add and commit with wrong message
+1. Check log
+1. Amend commit
+1. Check log
+1. Soft reset
+1. Check log
+1. Pull for updates
+1. Push changes
 ----
@@ -389,9 +390,9 @@ Don't reset after pushing
 ### Note
-git revert vs git reset  
-Reset removes the commit while revert removes the changes but leaves the commit  
-Revert is safer considering we can revert a revert  
+git revert vs git reset
+Reset removes the commit while revert removes the changes but leaves the commit
+Revert is safer considering we can revert a revert
     # Changed file

doc/university/training/topics/bisect.md

@@ -2,7 +2,7 @@
 comments: false
 ---
-# Bisect	  	
+# Bisect
 ----------
@@ -17,11 +17,11 @@ comments: false
 ## Bisect
 1. Start the bisect process
-2. Enter the bad revision (usually latest commit)
-3. Enter a known good revision (commit/branch)
-4. Run code to see if bug still exists
-5. Tell bisect the result
-6. Repeat the previous 2 items until you find the offending commit
+1. Enter the bad revision (usually latest commit)
+1. Enter a known good revision (commit/branch)
+1. Run code to see if bug still exists
+1. Tell bisect the result
+1. Repeat the previous 2 items until you find the offending commit
 ----------

doc/university/training/topics/getting_started.md

@@ -35,11 +35,10 @@ comments: false
 ## Instantiate workflow with clone
-1. Create a project in your user namespace
-   - Choose to import from 'Any Repo by URL' and use
-     https://gitlab.com/gitlab-org/training-examples.git
-2. Create a '`Workspace`' directory in your home directory.
-3. Clone the '`training-examples`' project
+1. Create a project in your user namespace.
+  - Choose to import from 'Any Repo by URL' and use <https://gitlab.com/gitlab-org/training-examples.git>.
+1. Create a '`Workspace`' directory in your home directory.
+1. Clone the '`training-examples`' project.
 ----------

doc/university/training/topics/git_log.md

@@ -46,11 +46,11 @@ Git log lists commit history. It allows searching and filtering.
 ## Git Log Workflow
 1. Change to workspace directory
-2. Clone the multi runner projects
-3. Change to project dir
-4. Search by author
-5. Search by date
-6. Combine
+1. Clone the multi runner projects
+1. Change to project dir
+1. Search by author
+1. Search by date
+1. Combine
 ----------