Merge branch 'docs-anchors9-admin-ee' into 'master'

Docs: (EE Port) Fix all anchors in Admin docs

See merge request gitlab-org/gitlab-ee!9763

doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md

@@ -14,7 +14,7 @@ Managing a large number of users in GitLab can become a burden for system admini
 
 In this guide we will focus on configuring GitLab with Active Directory. [Active Directory](https://en.wikipedia.org/wiki/Active_Directory) is a popular LDAP compatible directory service provided by Microsoft, included in all modern Windows Server operating systems.
 
-GitLab has supported LDAP integration since [version 2.2](https://about.gitlab.com/2012/02/22/gitlab-version-2-2/). With GitLab LDAP [group syncing](#group-syncing-ee) being added to GitLab Enterprise Edition in [version 6.0](https://about.gitlab.com/2013/08/20/gitlab-6-dot-0-released/). LDAP integration has become one of the most popular features in GitLab.
+GitLab has supported LDAP integration since [version 2.2](https://about.gitlab.com/2012/02/22/gitlab-version-2-2/). With GitLab LDAP [group syncing](../how_to_configure_ldap_gitlab_ee/index.html#group-sync) being added to GitLab Enterprise Edition in [version 6.0](https://about.gitlab.com/2013/08/20/gitlab-6-dot-0-released/). LDAP integration has become one of the most popular features in GitLab.
 
 ## Getting started
 
@@ -111,7 +111,7 @@ The initial configuration of LDAP in GitLab requires changes to the `gitlab.rb`
 
 The two Active Directory specific values are `active_directory: true` and `uid: 'sAMAccountName'`. `sAMAccountName` is an attribute returned by Active Directory used for GitLab usernames. See the example output from `ldapsearch` for a full list of attributes a "person" object (user) has in **AD** - [`ldapsearch` example](#using-ldapsearch-unix)
 
-> Both group_base and admin_group configuration options are only available in GitLab Enterprise Edition. See [GitLab EE - LDAP Features](#gitlab-enterprise-edition---ldap-features)
+> Both group_base and admin_group configuration options are only available in GitLab Enterprise Edition. See [GitLab EE - LDAP Features](../how_to_configure_ldap_gitlab_ee/index.html#gitlab-enterprise-edition---ldap-features)
 
 ### Example `gitlab.rb` LDAP
 

doc/administration/auth/how_to_configure_ldap_gitlab_ee/index.md

@@ -16,7 +16,7 @@ The present article follows [How to Configure LDAP with GitLab CE](../how_to_con
 
 [GitLab Enterprise Edition (EE)](https://about.gitlab.com/pricing/) has a number of advantages when it comes to integrating with Active Directory (LDAP):
 
-- [Administrator Sync](#administrator-sync): As an extension of group sync, you can automatically manage your global GitLab administrators. Specify a group CN for `admin_group` and all members of the LDAP group will be given administrator privileges.
+- [Administrator Sync](../ldap-ee.md#administrator-sync): As an extension of group sync, you can automatically manage your global GitLab administrators. Specify a group CN for `admin_group` and all members of the LDAP group will be given administrator privileges.
 - [Group Sync](#group-sync): This allows GitLab group membership to be automatically updated based on LDAP group members.
 - [Multiple LDAP servers](#multiple-ldap-servers): The ability to configure multiple LDAP servers. This is useful if an organization has different LDAP servers within departments. This is not designed for failover. We're working on [supporting LDAP failover](https://gitlab.com/gitlab-org/gitlab-ee/issues/139) in GitLab.
 

doc/administration/auth/ldap.md

@@ -39,7 +39,7 @@ immediately block all access.
 
 NOTE: **Note**:
 GitLab Enterprise Edition Starter supports a
-[configurable sync time](ldap-ee.md#adjusting-ldap-user-and-group-sync-schedules),
+[configurable sync time](ldap-ee.md#adjusting-ldap-user-sync-schedule),
 with a default of one hour.
 
 ## Git password authentication
@@ -338,7 +338,7 @@ group, you can use the following syntax:
 Find more information about this "LDAP_MATCHING_RULE_IN_CHAIN" filter at
 <https://docs.microsoft.com/en-us/windows/desktop/ADSI/search-filter-syntax>. Support for
 nested members in the user filter should not be confused with
-[group sync nested groups support (EE only)](ldap-ee.md#supported-ldap-group-types-attributes).
+[group sync nested groups support (EE only)](ldap-ee.md#supported-ldap-group-typesattributes).
 
 Please note that GitLab does not support the custom filter syntax used by
 omniauth-ldap.

doc/administration/auth/okta.md

 # Okta SSO provider
 
-Okta is a [Single Sign-on provider][okta-sso] that can be used to authenticate
+Okta is a [Single Sign-on provider](https://www.okta.com/products/single-sign-on/) that can be used to authenticate
 with GitLab.
 
 The following documentation enables Okta as a SAML provider.
@@ -140,7 +140,7 @@ Now that the Okta app is configured, it's time to enable it in GitLab.
       }
     ```
 
-1. [Reconfigure][reconf] or [restart] GitLab for Omnibus and installations
+1. [Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart](../restart_gitlab.md#installations-from-source) GitLab for Omnibus and installations
    from source respectively for the changes to take effect.
 
 You might want to try this out on an incognito browser window.
@@ -150,10 +150,5 @@ You might want to try this out on an incognito browser window.
 >**Note:**
 Make sure the groups exist and are assigned to the Okta app.
 
-You can take a look of the [SAML documentation][saml] on external groups since
+You can take a look of the [SAML documentation](../../integration/saml.md#marking-users-as-external-based-on-saml-groups) on external groups since
 it works the same.
-
-[okta-sso]: https://www.okta.com/products/single-sign-on/
-[saml]: ../../integration/saml.md#external-groups
-[reconf]: ../restart_gitlab.md#omnibus-gitlab-reconfigure
-[restart]: ../restart_gitlab.md#installations-from-source

doc/administration/compliance.md

@@ -6,13 +6,13 @@ GitLab’s [security features](../security/README.md) may also help you meet rel
 
 |Feature   |GitLab tier |GitLab.com |
 | ---------| :--------: | :-------: |
-|**[Restrict SSH Keys](../README.html#administrator-documentation)**<br>Control the technology and key length of SSH keys used to access GitLab|Core+||
-|**[Granular user roles and flexible permissions](../user/permissions.html)**<br>Manage access and permissions with five different user roles and settings for external users. Set permissions according to people's role, rather than either read or write access to a repository. Don't share the source code with people that only need access to the issue tracker.|Core+|✓|
-|**[Enforce TOS acceptance](../user/admin_area/settings/terms.html)**<br>Enforce your users accepting new terms of service by blocking GitLab traffic.|Core+||
-|**[Email all users of a project, group, or entire server](../user/admin_area/settings/terms.html)**<br>An admin can email groups of users based on project or group membership, or email everyone using the GitLab instance. This is great for scheduled maintenance or upgrades.|Starter+||
+|**[Restrict SSH Keys](../security/ssh_keys_restrictions.md)**<br>Control the technology and key length of SSH keys used to access GitLab|Core+||
+|**[Granular user roles and flexible permissions](../user/permissions.md)**<br>Manage access and permissions with five different user roles and settings for external users. Set permissions according to people's role, rather than either read or write access to a repository. Don't share the source code with people that only need access to the issue tracker.|Core+|✓|
+|**[Enforce TOS acceptance](../user/admin_area/settings/terms.md)**<br>Enforce your users accepting new terms of service by blocking GitLab traffic.|Core+||
+|**[Email all users of a project, group, or entire server](../user/admin_area/settings/terms.md)**<br>An admin can email groups of users based on project or group membership, or email everyone using the GitLab instance. This is great for scheduled maintenance or upgrades.|Starter+||
 |**[Omnibus package supports log forwarding](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-forwarding)**<br>Forward your logs to a central system.|Starter+||
-|**[Lock project membership to group](../workflow/groups.html#lock-project-membership-to-members-of-this-group)**<br>Group owners can prevent new members from being added to projects within a group.|Starter+|✓|
-|**[LDAP group sync](../administration/auth/ldap-ee.html#group-sync)**<br>GitLab Enterprise Edition gives admins the ability to automatically sync groups and manage SSH keys, permissions, and authentication, so you can focus on building your product, not configuring your tools.|Starter+||
-|**[LDAP group sync filters](../administration/auth/ldap-ee.html#group-sync)**<br>GitLab Enterprise Edition Premium gives more flexibility to synchronize with LDAP based on filters, meaning you can leverage LDAP attributes to map GitLab permissions.|Premium+||
-|**[Audit logs](../administration/audit_events.html)**<br>To maintain the integrity of your code, GitLab Enterprise Edition Premium gives admins the ability to view any modifications made within the GitLab server in an advanced audit log system, so you can control, analyze and track every change.|Premium+||
-|**[Auditor users](../administration/auditor_users.html)**<br>Auditor users are users who are given read-only access to all projects, groups, and other resources on the GitLab instance.|Premium+||
+|**[Lock project membership to group](../user/group/index.md#member-lock-starter)**<br>Group owners can prevent new members from being added to projects within a group.|Starter+|✓|
+|**[LDAP group sync](auth/ldap-ee.md#group-sync)**<br>GitLab Enterprise Edition gives admins the ability to automatically sync groups and manage SSH keys, permissions, and authentication, so you can focus on building your product, not configuring your tools.|Starter+||
+|**[LDAP group sync filters](auth/ldap-ee.md#group-sync)**<br>GitLab Enterprise Edition Premium gives more flexibility to synchronize with LDAP based on filters, meaning you can leverage LDAP attributes to map GitLab permissions.|Premium+||
+|**[Audit logs](audit_events.md)**<br>To maintain the integrity of your code, GitLab Enterprise Edition Premium gives admins the ability to view any modifications made within the GitLab server in an advanced audit log system, so you can control, analyze and track every change.|Premium+||
+|**[Auditor users](auditor_users.md)**<br>Auditor users are users who are given read-only access to all projects, groups, and other resources on the GitLab instance.|Premium+||

doc/administration/geo/disaster_recovery/bring_primary_back.md

@@ -31,7 +31,7 @@ To bring the former **primary** node up to date:
     > the GitLab instance from scratch and set it up as a **secondary** node by
     > following [Setup instructions][setup-geo]. In this case, you don't need to follow the next step.
     >
-    > **Note 2:** If you [changed the DNS records](index.md#step-4-optional-updating-the-primary-domains-dns-record)
+    > **Note 2:** If you [changed the DNS records](index.md#step-4-optional-updating-the-primary-domain-dns-record)
     > for this node during disaster recovery procedure you may need to [block
     > all the writes to this node](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/doc/gitlab-geo/planned-failover.md#block-primary-traffic)
     > during this procedure.

doc/administration/geo/disaster_recovery/index.md

@@ -224,7 +224,7 @@ sudo rm -rf /var/opt/gitlab/geo-postgresql
 ## Promoting secondary Geo replica in multi-secondary configurations
 
 If you have more than one **secondary** node and you need to promote one of them, we suggest you follow
-[Promoting **secondary** Geo node in single-secondary configurations](#promoting-secondary-geo-node-in-single-secondary-configurations)
+[Promoting a **secondary** Geo node in single-secondary configurations](#promoting-a-secondary-geo-node-in-single-secondary-configurations)
 and after that you also need two extra steps.
 
 ### Step 1. Prepare the new **primary** node to serve one or more **secondary** nodes

doc/administration/geo/disaster_recovery/planned_failover.md

@@ -113,7 +113,7 @@ If any objects are failing to replicate, this should be investigated before
 scheduling the maintenance window. Following a planned failover, anything that
 failed to replicate will be **lost**.
 
-You can use the [Geo status API][geo-status-api] to review failed objects and
+You can use the [Geo status API](../../../api/geo_nodes.md#retrieve-project-sync-or-verification-failures-that-occurred-on-the-current-node) to review failed objects and
 the reasons for failure.
 
 A common cause of replication failures is the data being missing on the
@@ -223,7 +223,6 @@ Don't forget to remove the broadcast message after failover is complete.
 [ee-5064]: https://gitlab.com/gitlab-org/gitlab-ee/issues/5064
 [foreground-verification]: ../../raketasks/check.md
 [background-verification]: background_verification.md
-[geo-status-api]: ../../../api/geo_nodes.html#retrieve-project-sync-failures-ocurred-on-the-current-node
 [limitations]: ../replication/index.md#current-limitations
 [moving-repositories]: ../../operations/moving_repositories.md
 [os-conf]: ../replication/object_storage.md#configuration

doc/administration/geo/replication/configuration_source.md

@@ -11,7 +11,7 @@ using the Omnibus GitLab packages, follow the
 NOTE: **Note:**
 This is the final step in setting up a **secondary** node. Stages of the setup
 process must be completed in the documented order. Before attempting the steps
-in this stage, [complete all prior stages][setup-geo-source].
+in this stage, [complete all prior stages](index.md#using-gitlab-installed-from-source-deprecated).
 
 The basic steps of configuring a **secondary** node are to:
 
@@ -88,7 +88,7 @@ the **secondary** node with the same credentials as used for the **primary** nod
 
 ### Step 2. Manually replicate the **primary** node's SSH host keys
 
-Read [Manually replicate the **primary** node's SSH host keys][configuration-replicate-ssh]
+Read [Manually replicate the **primary** node's SSH host keys](configuration.md#step-2-manually-replicate-the-primary-nodes-ssh-host-keys)
 
 ### Step 3. Add the **secondary** GitLab node
 
@@ -166,10 +166,8 @@ Read [Selective synchronization][configuration-selective-replication].
 
 Read the [troubleshooting document][troubleshooting].
 
-[setup-geo-source]: index.md#using-gitlab-installed-from-source
 [gitlab-org/gitlab-ee#3789]: https://gitlab.com/gitlab-org/gitlab-ee/issues/3789
 [configuration]: configuration.md
-[configuration-replicate-ssh]: configuration.md#step-2-manually-replicate-primary-ssh-host-keys
 [configuration-selective-replication]: configuration.md#selective-synchronization
 [configuration-verify-node]: configuration.md#step-7-verify-proper-functioning-of-the-secondary-node
 [troubleshooting]: troubleshooting.md

doc/administration/geo/replication/database_source.md

@@ -8,7 +8,7 @@ using the Omnibus GitLab packages, follow the
 
 NOTE: **Note:**
 The stages of the setup process must be completed in the documented order.
-Before attempting the steps in this stage, [complete all prior stages][toc].
+Before attempting the steps in this stage, [complete all prior stages](index.md#using-gitlab-installed-from-source-deprecated).
 
 This document describes the minimal steps you have to take in order to
 replicate your **primary** GitLab database to a **secondary** node's database. You may
@@ -423,7 +423,6 @@ Read the [troubleshooting document](troubleshooting.md).
 [pgback]: http://www.postgresql.org/docs/9.6/static/app-pgbasebackup.html
 [replication user]:https://wiki.postgresql.org/wiki/Streaming_Replication
 [FDW]: https://www.postgresql.org/docs/9.6/static/postgres-fdw.html
-[toc]: index.md#using-gitlab-installed-from-source
 [database]: database.md
 [add-geo-node]: configuration.md#step-3-add-the-secondary-gitlab-node
 [database-replication]: database.md#step-2-configure-the-secondary-server

doc/administration/geo/replication/object_storage.md

@@ -13,12 +13,12 @@ they can use a replicated storage bucket. At this time GitLab does not
 take care of content replication in object storage.
 
 For LFS, follow the documentation to
-[set up LFS object storage](../../../workflow/lfs/lfs_administration.md#setting-up-s3-compatible-object-storage).
+[set up LFS object storage](../../../workflow/lfs/lfs_administration.md#storing-lfs-objects-in-remote-object-storage).
 
 For CI job artifacts, there is similar documentation to configure
 [jobs artifact object storage](../../job_artifacts.md#using-object-storage)
 
-For user uploads, there is similar documentation to configure [upload object storage](../../uploads.md#using-object-storage)
+For user uploads, there is similar documentation to configure [upload object storage](../../uploads.md#using-object-storage-core-only)
 
 You should enable and configure object storage on both **primary** and **secondary**
 nodes. Migrating existing data to object storage should be performed on the

doc/administration/geo/replication/updating_the_geo_nodes.md

@@ -112,11 +112,11 @@ sudo gitlab-ctl reconfigure
 ```
 
 If you do not perform this step, you may find that two-factor authentication
-[is broken following DR](faq.md#i-followed-the-disaster-recovery-instructions-and-now-two-factor-auth-is-broken).
+[is broken following DR](../disaster_recovery/index.html#i-followed-the-disaster-recovery-instructions-and-now-two-factor-auth-is-broken).
 
 To prevent SSH requests to the newly promoted **primary** node from failing
 due to SSH host key mismatch when updating the **primary** node domain's DNS record
-you should perform the step to [Manually replicate **primary** SSH host keys][configuration-replicate-ssh] in each
+you should perform the step to [Manually replicate **primary** SSH host keys](configuration.md#step-2-manually-replicate-the-primary-nodes-ssh-host-keys) in each
 **secondary** node.
 
 ## Upgrading to GitLab 10.4
@@ -131,7 +131,7 @@ In GitLab 10.2, synchronizing secondaries over SSH was deprecated. In 10.3,
 support is removed entirely. All installations will switch to the HTTP/HTTPS
 cloning method instead. Before upgrading, ensure that all your Geo nodes are
 configured to use this method and that it works for your installation. In
-particular, ensure that [Git access over HTTP/HTTPS is enabled][configuration-git-over-http].
+particular, ensure that [Git access over HTTP/HTTPS is enabled](configuration.md#step-6-enable-git-access-over-httphttps).
 
 Synchronizing repositories over the public Internet using HTTP is insecure, so
 you should ensure that you have HTTPS configured before upgrading. Note that
@@ -402,5 +402,3 @@ and it is required since 10.0.
 [Hashed Storage]: ../../repository_storage_types.md
 [hashed-migration]: ../../raketasks/storage.md
 [ssh-fast-lookup]: ../../operations/fast_ssh_key_lookup.md
-[configuration-replicate-ssh]: configuration.md#step-2-manually-replicate-primary-ssh-host-keys
-[configuration-git-over-http]: configuration.md#step-6-enable-git-access-over-http-https

doc/administration/index.md

@@ -152,7 +152,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 - [Job artifacts](job_artifacts.md): Enable, disable, and configure job artifacts (a set of files and directories which are outputted by a job when it completes successfully).
 - [Job traces](job_traces.md): Information about the job traces (logs).
 - [Register Shared and specific Runners](../ci/runners/README.md#registering-a-shared-runner): Learn how to register and configure Shared and specific Runners to your own instance.
-- [Shared Runners pipelines quota](../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota): Limit the usage of pipeline minutes for Shared Runners.
+- [Shared Runners pipelines quota](https://docs.gitlab.com/ee/user/admin_area/settings/continuous_integration.html#shared-runners-pipeline-minutes-quota-starter-only): Limit the usage of pipeline minutes for Shared Runners. **[STARTER ONLY]**
 - [Enable/disable Auto DevOps](../topics/autodevops/index.md#enablingdisabling-auto-devops): Enable or disable Auto DevOps for your instance.
 
 ## Git configuration options

doc/administration/job_artifacts.md

@@ -274,7 +274,7 @@ you can flip the feature flag from a Rails console.
 ## Set the maximum file size of the artifacts
 
 Provided the artifacts are enabled, you can change the maximum file size of the
-artifacts through the [Admin area settings](../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size).
+artifacts through the [Admin area settings](../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size-core-only).
 
 ## Storage statistics
 

doc/administration/monitoring/prometheus/index.md

@@ -17,7 +17,7 @@ access to high quality time-series monitoring of GitLab services.
 ## Overview
 
 Prometheus works by periodically connecting to data sources and collecting their
-performance metrics via the [various exporters](#prometheus-exporters). To view
+performance metrics via the [various exporters](#bundled-software-metrics). To view
 and work with the monitoring data, you can either
 [connect directly to Prometheus](#viewing-performance-metrics) or utilize a
 dashboard tool like [Grafana].

doc/administration/operations/fast_ssh_key_lookup.md

@@ -37,7 +37,7 @@ public SSH keys for users allowed to access GitLab. However, to maintain a
 single source of truth, [Geo](../../gitlab-geo/README.md) needs to be configured to perform SSH fingerprint
 lookups via database lookup.
 
-As part of [setting up Geo](../../gitlab-geo/README.md#setup-instructions),
+As part of [setting up Geo](../geo/replication/index.md#setup-instructions),
 you will be required to follow the steps outlined below for both the primary and
 secondary nodes, but note that the `Write to "authorized keys" file` checkbox
 only needs to be unchecked on the primary node since it will be reflected

doc/administration/raketasks/uploads/migrate.md

@@ -2,7 +2,7 @@
 
 ## Migrate to Object Storage
 
-After [configuring the object storage](../../uploads.md#using-object-storage) for GitLab's uploads, you may use this task to migrate existing uploads from the local storage to the remote storage.
+After [configuring the object storage](../../uploads.md#using-object-storage-core-only) for GitLab's uploads, you may use this task to migrate existing uploads from the local storage to the remote storage.
 
 >**Note:**
 All of the processing will be done in a background worker and requires **no downtime**.

doc/administration/repository_checks.md

@@ -31,7 +31,7 @@ panel.
 If the repository check fails for some repository you should look up the error
 in `repocheck.log`:
 
-- in the [admin panel](logs.md#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

doc/gitlab-geo/README.md

+---
+redirect_to: '../administration/geo/replication/index.md'
+---
+
 This document was moved to [another location](../administration/geo/replication/index.md).

doc/gitlab-geo/configuration.md

+---
+redirect_to: '../administration/geo/replication/configuration.md'
+---
+
 This document was moved to [another location](../administration/geo/replication/configuration.md).

doc/user/admin_area/geo_nodes.md

@@ -24,7 +24,7 @@ Secondaries have a number of additional settings available:
 
 | Setting                   | Description |
 |---------------------------|-------------|
-| Selective synchronization | Enable Geo [selective sync](../../gitlab-geo/configuration.md#selective-synchronization) for this secondary. |
+| Selective synchronization | Enable Geo [selective sync](../../administration/geo/replication/configuration.md#selective-synchronization) for this secondary. |
 | Repository sync capacity  | Number of concurrent requests this secondary will make to the primary when backfilling repositories. |
 | File sync capacity        | Number of concurrent requests this secondary will make to the primary when backfilling files. |
 

doc/user/admin_area/monitoring/health_check.md

@@ -2,10 +2,9 @@
 
 > **Notes:**
 >   - 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 will
->     be deprecated in GitLab 9.1. Read more in the [old behavior](#old-behavior)
->     section.
->   - [Access token](#access-token) has been deprecated in GitLab 9.4
+>   - The `health_check` endpoint was [introduced][ce-3888] in GitLab 8.8 and was
+>     be deprecated in GitLab 9.1.
+>   - [Access token](#access-token-deprecated) has been deprecated in GitLab 9.4
 >     in favor of [IP whitelist](#ip-whitelist)
 
 GitLab provides liveness and readiness probes to indicate service health and

doc/user/index.md

@@ -8,13 +8,13 @@ Welcome to GitLab! We're glad to have you here!
 
 As a GitLab user you'll have access to all the features
 your [subscription](https://about.gitlab.com/pricing/)
-includes, except [GitLab administrator](../README.md#administrator-documentation)
+includes, except [GitLab administrator](../administration/index.md)
 settings, unless you have admin privileges to install, configure,
 and upgrade your GitLab instance.
 
 Admin privileges for [GitLab.com](https://gitlab.com/) are restricted to the GitLab team.
 
-For more information on configuring GitLab self-managed instances, see [Administrator documentation](../README.md#administrator-documentation).
+For more information on configuring GitLab self-managed instances, see [Administrator documentation](../administration/index.md).
 
 ## Overview
 

doc/user/instance_statistics/convdev.md

 # Conversational Development Index
 
-> [Introduced][ce-30469] in GitLab 9.3.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/30469) in GitLab 9.3.
 
 NOTE: **NOTE**
-Your GitLab instance's [usage ping][ping] must be activated in order to use this feature.
+Your GitLab instance's [usage ping](../admin_area/settings/usage_statistics.md#usage-ping-core-only) must be activated in order to use this feature.
 
 The Conversational Development Index (ConvDev Index) gives you an overview of your entire
 instance's adoption of [Concurrent DevOps](https://about.gitlab.com/concurrent-devops/)
@@ -12,7 +12,7 @@ from planning to monitoring.
 This displays the usage of these GitLab features over
 the last 30 days, averaged over the number of active users in that time period. It also
 provides a Lead score per feature, which is calculated based on GitLab's analysis
-of top-performing instances based on [usage ping data][ping] that GitLab has
+of top-performing instances based on [usage ping data](../admin_area/settings/usage_statistics.md#usage-ping-core-only) that GitLab has
 collected. Your score is compared to the lead score of each feature and then expressed as a percentage at the bottom of said feature.
 Your overall index score is an average of all your feature score percentages - this percentage value is presented above all the of features on the page.
 
@@ -21,9 +21,7 @@ Your overall index score is an average of all your feature score percentages - t
 The page also provides helpful links to articles and GitLab docs, to help you
 improve your scores.
 
+
 Usage ping data is aggregated on GitLab's servers for analysis. Your usage
 information is **not sent** to any other GitLab instances. If you have just started using GitLab, it may take a few weeks for data to be
 collected before this feature is available.
-
-[ce-30469]: https://gitlab.com/gitlab-org/gitlab-ce/issues/30469
-[ping]: ../admin_area/settings/usage_statistics.md#usage-ping

doc/user/permissions.md

@@ -14,7 +14,7 @@ be able to create issues, leave comments, and clone or download the project code
 When a member leaves the team all the assigned [Issues](project/issues/index.md) and [Merge Requests](project/merge_requests/index.md)
 will be unassigned automatically.
 
-GitLab [administrators](../README.md#administrator-documentation) receive all permissions.
+GitLab [administrators](../administration/index.md) receive all permissions.
 
 To add or import a user, you can follow the
 [project members documentation](../user/project/members/index.md).

doc/user/project/service_desk.md

 # Service Desk **[PREMIUM]**
 
-> [Introduced][ee-149] in [GitLab Premium 9.1][eep-9.1].
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/149) in [GitLab Premium 9.1](https://about.gitlab.com/2017/04/22/gitlab-9-1-released/#service-desk-eep).
 
 ## Overview
 
@@ -53,8 +53,8 @@ Service Desk is enabled on GitLab.com. If you're a
 [Silver subscriber](https://about.gitlab.com/gitlab-com/),
 you can skip the step 1 below; you only need to enable it per project.
 
-1.   [Set up incoming email][incoming-email] for the GitLab instance. This must
-     support [email sub-addressing][email-sub-addressing].
+1.   [Set up incoming email](../../administration/incoming_email.md#set-it-up) for the GitLab instance. This must
+     support [email sub-addressing](../../administration/incoming_email.md#email-sub-addressing).
 2.   Navigate to your project's **Settings** and scroll down to the **Service Desk**
      section.
 3.   If you have the correct access and an Premium license,
@@ -64,12 +64,12 @@ you can skip the step 1 below; you only need to enable it per project.
 
 4.   Checking that box will enable Service Desk for the project, and show a
      unique email address to email issues to the project. These issues will be
-     [confidential], so they will only be visible to project members.
+     [confidential](issues/confidential_issues.md), so they will only be visible to project members.
 
      **Warning**: this email address can be used by anyone to create an issue on
      this project, whether or not they have access to your GitLab instance.
      We recommend **putting this behind an alias** so that it can be changed if
-     needed, and **[enabling Akismet][akismet]** on your GitLab instance to add spam
+     needed, and **[enabling Akismet](../../integration/akismet.md)** on your GitLab instance to add spam
      checking to this service.  Unblocked email spam would result in many spam
      issues being created, and may disrupt your GitLab service.
 
@@ -122,11 +122,3 @@ you can read and write comments as you normally do:
 
 Behind the scenes, Service Desk works by the special Support Bot user creating issues. This user
 does not count toward the license limit count.
-
-[ee-149]: https://gitlab.com/gitlab-org/gitlab-ee/issues/149 "Service Desk with email"
-[ee]: https://about.gitlab.com/pricing/ "GitLab Enterprise Edition landing page"
-[eep-9.1]: https://about.gitlab.com/2017/04/22/gitlab-9-1-released/#service-desk-eep
-[incoming-email]: ../../administration/incoming_email.md#set-it-up
-[email-sub-addressing]: ../../administration/reply_by_email.md#email-sub-addressing
-[confidential]: ./issues/confidential_issues.md "Confidential issues"
-[akismet]: ../../integration/akismet.md

doc/workflow/groups.md

+---
+redirect_to: '../user/group/index.md'
+---
 
 This document was moved to [another location](../user/group/index.md).