Change reference links to inline

Change ref links to inline in administration
docs

doc/administration/auditor_users.md

 # Auditor users **(PREMIUM ONLY)**
 
->[Introduced][ee-998] in [GitLab Premium][eep] 8.17.
+>[Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/998) in [GitLab Premium](https://about.gitlab.com/pricing/) 8.17.
 
 Auditor users are given read-only access to all projects, groups, and other
 resources on the GitLab instance.
@@ -12,7 +12,7 @@ snippets, etc.), and read-only access to **all** other resources, except the
 Admin Area. To put another way, they are just regular users (who can be added
 to projects, create personal snippets, create milestones on their groups, etc.)
 who also happen to have read-only access to all projects on the system that
-they haven't been explicitly [given access][permissions] to.
+they haven't been explicitly [given access](../user/permissions.md) to.
 
 The Auditor role is _not_ a read-only version of the Admin role. Auditor users
 will not be able to access the project/group settings pages, or the Admin Area.
@@ -25,7 +25,7 @@ To sum up, assuming you have logged-in as an Auditor user:
 - For a project the Auditor owns, the Auditor should have full access to
   everything.
 - For a project the Auditor has been added to as a member, the Auditor should
-  have the same access as the [permissions] they were given to. For example, if
+  have the same access as the [permissions](../user/permissions.md) they were given to. For example, if
   they were added as a Developer, they could then push commits or comment on
   issues.
 - The Auditor cannot view the Admin Area, or perform any admin actions.
@@ -82,7 +82,3 @@ instance, with the following permissions/restrictions:
   - Cannot create/modify files from the Web UI
   - Cannot merge a merge request
   - Cannot create project snippets
-
-[ee-998]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/998
-[eep]: https://about.gitlab.com/pricing/
-[permissions]: ../user/permissions.md

doc/administration/auth/crowd.md

@@ -66,14 +66,11 @@ Authenticate to GitLab using the Atlassian Crowd OmniAuth provider.
 1. Change `YOUR_APP_NAME` to the application name from Crowd applications page.
 1. Change `YOUR_APP_PASSWORD` to the application password you've set.
 1. Save the configuration file.
-1. [Reconfigure][] or [restart][] for the changes to take effect if you
+1. [Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart](../restart_gitlab.md#installations-from-source) for the changes to take effect if you
    installed GitLab via Omnibus or from source respectively.
 
 On the sign in page there should now be a Crowd tab in the sign in form.
 
-[reconfigure]: ../restart_gitlab.md#omnibus-gitlab-reconfigure
-[restart]: ../restart_gitlab.md#installations-from-source
-
 ## Troubleshooting
 
 If you see an error message like the one below when you sign in after Crowd authentication is configured, you may want to consult the Crowd administrator for the Crowd log file to know the exact cause:

doc/administration/auth/google_secure_ldap.md

@@ -133,7 +133,7 @@ values obtained during the LDAP client configuration earlier:
    EOS
    ```
 
-1. Save the file and [reconfigure] GitLab for the changes to take effect.
+1. Save the file and [reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab for the changes to take effect.
 
 ---
 
@@ -204,10 +204,7 @@ values obtained during the LDAP client configuration earlier:
              -----END PRIVATE KEY-----
    ```
 
-1. Save the file and [restart] GitLab for the changes to take effect.
-
-[reconfigure]: ../restart_gitlab.md#omnibus-gitlab-reconfigure
-[restart]: ../restart_gitlab.md#installations-from-source
+1. Save the file and [restart](../restart_gitlab.md#installations-from-source) GitLab for the changes to take effect.
 
 <!-- ## Troubleshooting
 

doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md

@@ -45,10 +45,7 @@ Configuring organizational units (**OU**s) is an important part of setting up Ac
 
 | GitLab **OU** Design           |  GitLab AD Structure             |
 | :----------------------------: | :------------------------------: |
-| ![GitLab OU Design][gitlab_ou] |  ![GitLab AD Structure][ldap_ou] |
-
-[gitlab_ou]: img/gitlab_ou.png
-[ldap_ou]: img/ldap_ou.gif
+| ![GitLab OU Design](img/gitlab_ou.png) |  ![GitLab AD Structure](img/ldap_ou.gif) |
 
 Using PowerShell you can output the **OU** structure as a table (_all names are examples only_):
 

doc/administration/auth/jwt.md

@@ -64,7 +64,7 @@ JWT will provide you with a secret key for you to use.
 
 1. Change `YOUR_APP_SECRET` to the client secret and set `auth_url` to your redirect URL.
 1. Save the configuration file.
-1. [Reconfigure][] or [restart GitLab][] for the changes to take effect if you
+1. [Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect if you
    installed GitLab via Omnibus or from source respectively.
 
 On the sign in page there should now be a JWT icon below the regular sign in form.
@@ -72,9 +72,6 @@ Click the icon to begin the authentication process. JWT will ask the user to
 sign in and authorize the GitLab application. If everything goes well, the user
 will be redirected to GitLab and will be signed in.
 
-[reconfigure]: ../restart_gitlab.md#omnibus-gitlab-reconfigure
-[restart GitLab]: ../restart_gitlab.md#installations-from-source
-
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues

doc/administration/file_hooks.md

@@ -14,12 +14,12 @@ ensure functionality is preserved across versions and covered by tests.
 NOTE: **Note:**
 File hooks must be configured on the filesystem of the GitLab server. Only GitLab
 server administrators will be able to complete these tasks. Explore
-[system hooks] or [webhooks] as an option if you do not have filesystem access.
+[system hooks](../system_hooks/system_hooks.md) or [webhooks](../user/project/integrations/webhooks.md) as an option if you do not have filesystem access.
 
 A file hook will run on each event so it's up to you to filter events or projects
 within a file hook code. You can have as many file hooks as you want. Each file hook will
 be triggered by GitLab asynchronously in case of an event. For a list of events
-see the [system hooks] documentation.
+see the [system hooks](../system_hooks/system_hooks.md) documentation.
 
 ## Setup
 
@@ -35,7 +35,7 @@ Follow the steps below to set up a custom hook:
    `/home/git/gitlab/file_hooks/`. For Omnibus installs the path is
    usually `/opt/gitlab/embedded/service/gitlab-rails/file_hooks`.
 
-    For [highly available] configurations, your hook file should exist on each
+    For [highly available](availability/index.md) configurations, your hook file should exist on each
     application server.
 
 1. Inside the `file_hooks` directory, create a file with a name of your choice,
@@ -46,7 +46,7 @@ Follow the steps below to set up a custom hook:
    language type. For example, if the script is in Ruby the shebang will
    probably be `#!/usr/bin/env ruby`.
 1. The data to the file hook will be provided as JSON on STDIN. It will be exactly
-   same as for [system hooks]
+   same as for [system hooks](../system_hooks/system_hooks.md).
 
 That's it! Assuming the file hook code is properly implemented, the hook will fire
 as appropriate. The file hooks file list is updated for each event, there is no
@@ -110,7 +110,3 @@ Validating file hooks from /file_hooks directory
 * /home/git/gitlab/file_hooks/save_to_file.clj succeed (zero exit code)
 * /home/git/gitlab/file_hooks/save_to_file.rb failure (non-zero exit code)
 ```
-
-[system hooks]: ../system_hooks/system_hooks.md
-[webhooks]: ../user/project/integrations/webhooks.md
-[highly available]: ./availability/index.md

doc/administration/geo/replication/using_a_geo_server.md

-[//]: # (Please update EE::GitLab::GeoGitAccess::GEO_SERVER_DOCS_URL if this file is moved)
+<!-- Please update EE::GitLab::GeoGitAccess::GEO_SERVER_DOCS_URL if this file is moved) -->
 
 # Using a Geo Server **(PREMIUM ONLY)**
 

doc/administration/git_annex.md

@@ -5,8 +5,8 @@ disqus_identifier: 'https://docs.gitlab.com/ee/workflow/git_annex.html'
 # Git annex
 
 > **Warning:** GitLab has [completely
-removed][deprecate-annex-issue] in GitLab 9.0 (2017/03/22).
-Read through the [migration guide from git-annex to Git LFS][guide].
+removed](https://gitlab.com/gitlab-org/gitlab/issues/1648) in GitLab 9.0 (2017/03/22).
+Read through the [migration guide from git-annex to Git LFS](../topics/git/lfs/migrate_from_git_annex_to_git_lfs.md).
 
 The biggest limitation of Git, compared to some older centralized version
 control systems, has been the maximum size of the repositories.
@@ -24,7 +24,7 @@ only check in the final result. This results in using outdated files, not
 having a complete history and increases the risk of losing work.
 
 This problem is solved in GitLab Enterprise Edition by integrating the
-[git-annex] application.
+[git-annex](https://git-annex.branchable.com/) application.
 
 `git-annex` allows managing large binaries with Git without checking the
 contents into Git.
@@ -64,7 +64,7 @@ The Omnibus package will internally set the correct options in all locations.
    gitlab_shell['git_annex_enabled'] = true
    ```
 
-1. Save the file and [reconfigure GitLab][] for the changes to take effect.
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
 ### Configuration for installations from source
 
@@ -86,7 +86,7 @@ one is located in `config.yml` of GitLab Shell.
    git_annex_enabled: true
    ```
 
-1. Save the files and [restart GitLab][] for the changes to take effect.
+1. Save the files and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
 
 ## Using GitLab git-annex
 
@@ -186,7 +186,7 @@ access files of projects you have access to (developer, maintainer, or owner rol
 
 ## How it works
 
-Internally GitLab uses [GitLab Shell] to handle SSH access and this was a great
+Internally GitLab uses [GitLab Shell](https://gitlab.com/gitlab-org/gitlab-shell) to handle SSH access and this was a great
 integration point for `git-annex`.
 There is a setting in GitLab Shell so you can disable GitLab Annex support
 if you want to.
@@ -196,7 +196,7 @@ if you want to.
 Differences in version of `git-annex` on the GitLab server and on local machines
 can cause `git-annex` to raise unpredicted warnings and errors.
 
-Consult the [Annex upgrade page][annex-upgrade] for more information about
+Consult the [Annex upgrade page](https://git-annex.branchable.com/upgrades/) for more information about
 the differences between versions. You can find out which version is installed
 on your server by navigating to <https://pkgs.org/download/git-annex> and
 searching for your distribution.
@@ -208,7 +208,7 @@ on how to go around the warnings.
 
 This warning can appear on the initial `git annex sync --content` and is caused
 by differences in `git-annex-shell`. You can read more about it
-[in this git-annex issue][issue].
+[in this git-annex issue](https://git-annex.branchable.com/forum/Error_from_git-annex-shell_on_creation_of_gcrypt_special_remote/).
 
 One important thing to note is that despite the warning, the `sync` succeeds
 and the files are pushed to the GitLab repository.
@@ -231,12 +231,3 @@ pull origin
 ok
 push origin
 ```
-
-[annex-upgrade]: https://git-annex.branchable.com/upgrades/
-[deprecate-annex-issue]: https://gitlab.com/gitlab-org/gitlab/issues/1648
-[git-annex]: https://git-annex.branchable.com/ "git-annex website"
-[gitlab shell]: https://gitlab.com/gitlab-org/gitlab-shell "GitLab Shell repository"
-[guide]: ../topics/git/lfs/migrate_from_git_annex_to_git_lfs.md
-[issue]: https://git-annex.branchable.com/forum/Error_from_git-annex-shell_on_creation_of_gcrypt_special_remote/ "git-annex issue"
-[reconfigure GitLab]: restart_gitlab.md#omnibus-gitlab-reconfigure
-[restart GitLab]: restart_gitlab.md#installations-from-source

doc/administration/lfs/index.md

@@ -50,7 +50,7 @@ In `config/gitlab.yml`:
 
 ## Storing LFS objects in remote object storage
 
-> [Introduced][ee-2760] in [GitLab Premium][eep] 10.0. Brought to GitLab Core in 10.7.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2760) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.0. Brought to GitLab Core in 10.7.
 
 It is possible to store LFS objects in remote object storage which allows you
 to offload local hard disk R/W operations, and free up disk space significantly.
@@ -177,7 +177,7 @@ On Omnibus installations, the settings are prefixed by `lfs_object_store_`:
    }
    ```
 
-1. Save the file and [reconfigure GitLab]s for the changes to take effect.
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 1. Migrate any existing local LFS objects to the object storage:
 
    ```shell
@@ -213,7 +213,7 @@ For source installations the settings are nested under `lfs:` and then
        path_style: true
    ```
 
-1. Save the file and [restart GitLab][] for the changes to take effect.
+1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
 1. Migrate any existing local LFS objects to the object storage:
 
    ```shell
@@ -268,8 +268,3 @@ See more information in [!19581](https://gitlab.com/gitlab-org/gitlab-foss/-/mer
 - Only compatible with the Git LFS client versions 1.1.0 and up, or 1.0.2.
 - The storage statistics currently count each LFS object multiple times for
   every project linking to it.
-
-[reconfigure gitlab]: ../restart_gitlab.md#omnibus-gitlab-reconfigure "How to reconfigure Omnibus GitLab"
-[restart gitlab]: ../restart_gitlab.md#installations-from-source "How to restart GitLab"
-[eep]: https://about.gitlab.com/pricing/ "GitLab Premium"
-[ee-2760]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2760

doc/administration/logs.md

@@ -484,7 +484,7 @@ This file lives in `/var/log/gitlab/gitlab-rails/repocheck.log` for
 Omnibus GitLab packages or in `/home/git/gitlab/log/repocheck.log` for
 installations from source.
 
-It logs information whenever a [repository check is run][repocheck] on a project.
+It logs information whenever a [repository check is run](repository_checks.md) on a project.
 
 ## `importer.log`
 
@@ -504,9 +504,9 @@ installations from source.
 
 This log records:
 
-- Information whenever [Rack Attack] registers an abusive request.
-- Requests over the [Rate Limit] on raw endpoints.
-- [Protected paths] abusive requests.
+- Information whenever [Rack Attack](../security/rack_attack.md) registers an abusive request.
+- Requests over the [Rate Limit](../user/admin_area/settings/rate_limits_on_raw_endpoints.md) on raw endpoints.
+- [Protected paths](../user/admin_area/settings/protected_paths.md) abusive requests.
 
 NOTE: **Note:**
 From [%12.1](https://gitlab.com/gitlab-org/gitlab-foss/issues/62756), user ID and username are also
@@ -684,8 +684,3 @@ Below is the default GitLab NGINX access log format:
 ```plaintext
 $remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"
 ```
-
-[repocheck]: repository_checks.md
-[Rack Attack]: ../security/rack_attack.md
-[Rate Limit]: ../user/admin_area/settings/rate_limits_on_raw_endpoints.md
-[Protected paths]: ../user/admin_area/settings/protected_paths.md

doc/administration/pages/index.md

@@ -80,7 +80,7 @@ added `gitlab.io` [in 2016](https://gitlab.com/gitlab-com/infrastructure/issues/
 ### DNS configuration
 
 GitLab Pages expect to run on their own virtual host. In your DNS server/provider
-you need to add a [wildcard DNS A record][wiki-wildcard-dns] pointing to the
+you need to add a [wildcard DNS A record](https://en.wikipedia.org/wiki/Wildcard_DNS_record) pointing to the
 host that GitLab runs. For example, an entry would look like this:
 
 ```plaintext
@@ -95,8 +95,6 @@ IPv6 address. If you don't have IPv6, you can omit the AAAA record.
 NOTE: **Note:**
 You should not use the GitLab domain to serve user pages. For more information see the [security section](#security).
 
-[wiki-wildcard-dns]: https://en.wikipedia.org/wiki/Wildcard_DNS_record
-
 ## Configuration
 
 Depending on your needs, you can set up GitLab Pages in 4 different ways.

doc/administration/pages/source.md

@@ -61,7 +61,7 @@ Before proceeding with the Pages configuration, make sure that:
 ### DNS configuration
 
 GitLab Pages expect to run on their own virtual host. In your DNS server/provider
-you need to add a [wildcard DNS A record][wiki-wildcard-dns] pointing to the
+you need to add a [wildcard DNS A record](https://en.wikipedia.org/wiki/Wildcard_DNS_record) pointing to the
 host that GitLab runs. For example, an entry would look like this:
 
 ```plaintext
@@ -75,8 +75,6 @@ and `192.0.2.1` is the IP address of your GitLab instance.
 You should not use the GitLab domain to serve user pages. For more information
 see the [security section](#security).
 
-[wiki-wildcard-dns]: https://en.wikipedia.org/wiki/Wildcard_DNS_record
-
 ## Configuration
 
 Depending on your needs, you can set up GitLab Pages in 4 different ways.

doc/administration/terraform_state.md

@@ -30,7 +30,7 @@ below.
    gitlab_rails['terraform_state_storage_path'] = "/mnt/storage/terraform_state"
    ```
 
-1. Save the file and [reconfigure GitLab][] for the changes to take effect.
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
 **In installations from source:**
 
@@ -43,7 +43,7 @@ below.
      storage_path: /mnt/storage/terraform_state
    ```
 
-1. Save the file and [restart GitLab][] for the changes to take effect.
+1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
 
 ## Using object storage **(CORE ONLY)**
 
@@ -111,7 +111,7 @@ The connection settings match those provided by [Fog](https://github.com/fog), a
    }
    ```
 
-1. Save the file and [reconfigure GitLab][] for the changes to take effect.
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
 **In installations from source:**
 
@@ -131,7 +131,4 @@ The connection settings match those provided by [Fog](https://github.com/fog), a
          region: eu-central-1
    ```
 
-1. Save the file and [restart GitLab][] for the changes to take effect.
-
-[reconfigure gitlab]: restart_gitlab.md#omnibus-gitlab-reconfigure "How to reconfigure Omnibus GitLab"
-[restart gitlab]: restart_gitlab.md#installations-from-source "How to restart GitLab"
+1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.

doc/user/admin_area/license.md

@@ -10,8 +10,8 @@ by **signing into your GitLab instance as an admin** or add it at
 installation time.
 
 The license has the form of a base64 encoded ASCII text with a `.gitlab-license`
-extension and can be obtained when you [purchase one][pricing] or when you sign
-up for a [free trial].
+extension and can be obtained when you [purchase one](https://about.gitlab.com/pricing/) or when you sign
+up for a [free trial](https://about.gitlab.com/free-trial/).
 
 NOTE: **Note:**
 As of GitLab Enterprise Edition 9.4.0, a newly-installed instance without an
@@ -104,9 +104,6 @@ expired license(s).
 It's possible to upload and view more than one license,
 but only the latest license will be used as the active license.
 
-[free trial]: https://about.gitlab.com/free-trial/
-[pricing]: https://about.gitlab.com/pricing/
-
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues

doc/user/admin_area/monitoring/health_check.md

@@ -4,8 +4,8 @@ type: concepts, howto
 
 # Health Check **(CORE ONLY)**
 
-> - Liveness and readiness probes were [introduced][ce-10416] in GitLab 9.1.
-> - The `health_check` endpoint was [introduced][ce-3888] in GitLab 8.8 and was
+> - Liveness and readiness probes were [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/10416) in GitLab 9.1.
+> - The `health_check` endpoint was [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/3888) in GitLab 8.8 and was
 >   deprecated in GitLab 9.1.
 > - [Access token](#access-token-deprecated) has been deprecated in GitLab 9.4
 >   in favor of [IP whitelist](#ip-whitelist).
@@ -163,9 +163,3 @@ questions that you know someone might ask.
 Each scenario can be a third-level heading, e.g. `### Getting error message X`.
 If you have none to add when creating a doc, leave this section in place
 but commented out to help encourage others to add to it in the future. -->
-
-[ce-10416]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/10416
-[ce-3888]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/3888
-[pingdom]: https://www.pingdom.com
-[nagios-health]: https://nagios-plugins.org/doc/man/check_http.html
-[newrelic-health]: https://docs.newrelic.com/docs/alerts/alert-policies/downtime-alerts/availability-monitoring

doc/user/admin_area/settings/email.md

@@ -12,7 +12,7 @@ The logo in the header of some emails can be customized, see the [logo customiza
 
 ## Custom additional text **(PREMIUM ONLY)**
 
-> [Introduced][ee-5031] in [GitLab Premium][eep] 10.7.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/5031) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.7.
 
 The additional text will appear at the bottom of any email and can be used for
 legal/auditing/compliance reasons.
@@ -22,9 +22,6 @@ legal/auditing/compliance reasons.
 1. Enter your text in the **Additional text** field.
 1. Click **Save**.
 
-[ee-5031]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/5031
-[eep]: https://about.gitlab.com/pricing/
-
 ## Custom hostname for private commit emails
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22560) in GitLab 11.5.

doc/user/admin_area/settings/external_authorization.md

@@ -33,7 +33,7 @@ authorization service.
 
 Whenever access is granted or denied this is logged in a logfile called
 `external-policy-access-control.log`.
-Read more about logs GitLab keeps in the [omnibus documentation][omnibus-log-docs].
+Read more about logs GitLab keeps in the [omnibus documentation](https://docs.gitlab.com/omnibus/settings/logs.html).
 
 ## Configuration
 
@@ -62,7 +62,7 @@ The available required properties are:
 When using TLS Authentication with a self signed certificate, the CA certificate
 needs to be trusted by the openssl installation. When using GitLab installed using
 Omnibus, learn to install a custom CA in the
-[omnibus documentation][omnibus-ssl-docs]. Alternatively learn where to install
+[omnibus documentation](https://docs.gitlab.com/omnibus/settings/ssl.html). Alternatively learn where to install
 custom certificates using `openssl version -d`.
 
 ## How it works
@@ -127,6 +127,3 @@ questions that you know someone might ask.
 Each scenario can be a third-level heading, e.g. `### Getting error message X`.
 If you have none to add when creating a doc, leave this section in place
 but commented out to help encourage others to add to it in the future. -->
-
-[omnibus-ssl-docs]: https://docs.gitlab.com/omnibus/settings/ssl.html
-[omnibus-log-docs]: https://docs.gitlab.com/omnibus/settings/logs.html

doc/user/admin_area/settings/sign_up_restrictions.md

@@ -50,14 +50,14 @@ the minimum number of characters a user must have in their password using the Gi
 
 ## Whitelist email domains
 
-> [Introduced][ce-598] in GitLab 7.11.0
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/598) in GitLab 7.11.0
 
 You can restrict users to only sign up using email addresses matching the given
 domains list.
 
 ## Blacklist email domains
 
-> [Introduced][ce-5259] in GitLab 8.10.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/5259) in GitLab 8.10.
 
 With this feature enabled, you can block email addresses of a specific domain
 from creating an account on your GitLab server. This is particularly useful
@@ -94,6 +94,3 @@ questions that you know someone might ask.
 Each scenario can be a third-level heading, e.g. `### Getting error message X`.
 If you have none to add when creating a doc, leave this section in place
 but commented out to help encourage others to add to it in the future. -->
-
-[ce-5259]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/5259
-[ce-598]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/598

doc/user/admin_area/settings/usage_statistics.md

@@ -58,10 +58,10 @@ sequenceDiagram
 
 ## Usage Ping **(CORE ONLY)**
 
-> - [Introduced][ee-557] in GitLab Enterprise Edition 8.10.
-> - More statistics [were added][ee-735] in GitLab Enterprise Edition 8.12.
-> - [Moved to GitLab Core][ce-23361] in 9.1.
-> - More statistics [were added][ee-6602] in GitLab Ultimate 11.2.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/557) in GitLab Enterprise Edition 8.10.
+> - More statistics [were added](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/735) in GitLab Enterprise Edition 8.12.
+> - [Moved to GitLab Core](https://gitlab.com/gitlab-org/gitlab-foss/issues/23361) in 9.1.
+> - More statistics [were added](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/6602) in GitLab Ultimate 11.2.
 
 GitLab sends a weekly payload containing usage data to GitLab Inc. The usage
 ping uses high-level data to help our product, support, and sales teams. It does
@@ -149,11 +149,6 @@ Each scenario can be a third-level heading, e.g. `### Getting error message X`.
 If you have none to add when creating a doc, leave this section in place
 but commented out to help encourage others to add to it in the future. -->
 
-[ee-557]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/557
-[ee-735]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/735
-[ce-23361]: https://gitlab.com/gitlab-org/gitlab-foss/issues/23361
-[ee-6602]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/6602
-
 ## Usage Statistics Collected
 
 | Statistic  | Section  | Stage    | Description   |