Add latest changes from gitlab-org/gitlab@12-4-stable-ee

587 files changed, 8040 insertions, 4158 deletions

diff --git a/doc/README.md b/doc/README.md
index 0ba2fd27b6a..61265f94004 100644
--- a/doc/README.md
+++ b/doc/README.md
@@ -258,6 +258,7 @@ The following documentation relates to the DevOps **Package** stage:
 |:----------------------------------------------------------------|:-------------------------------------------------------|
 | [Container Registry](user/packages/container_registry/index.md)   | The GitLab Container Registry enables every project in GitLab to have its own space to store [Docker](https://www.docker.com/) images. |
 | [Dependency Proxy](user/packages/dependency_proxy/index.md) **(PREMIUM)** | The GitLab Dependency Proxy sets up a local proxy for frequently used upstream images/packages. |
+| [Conan Repository](user/packages/conan_repository/index.md) **(PREMIUM)** | The GitLab Conan Repository enables every project in GitLab to have its own space to store [Conan](https://conan.io/) packages. |
 | [Maven Repository](user/packages/maven_repository/index.md) **(PREMIUM)** | The GitLab Maven Repository enables every project in GitLab to have its own space to store [Maven](https://maven.apache.org/) packages. |
 | [NPM Registry](user/packages/npm_registry/index.md) **(PREMIUM)**  | The GitLab NPM Registry enables every project in GitLab to have its own space to store [NPM](https://www.npmjs.com/) packages. |
 
diff --git a/doc/administration/audit_events.md b/doc/administration/audit_events.md
index bd51a3e18d7..61ea673071e 100644
--- a/doc/administration/audit_events.md
+++ b/doc/administration/audit_events.md
@@ -117,6 +117,35 @@ on adding these events into GitLab:
 - [Group settings and activity](https://gitlab.com/groups/gitlab-org/-/epics/475)
 - [Instance-level settings and activity](https://gitlab.com/groups/gitlab-org/-/epics/476)
 
+### Disabled events
+
+#### Repository push
+
+The current architecture of audit events is not prepared to receive a very high amount of records.
+It may make your project/admin audit logs UI very busy and the disk space consumed by the
+`audit_events` Postgres table will increase considerably. Thus, it's disabled by default
+to prevent performance degradations on GitLab instances with very high Git write traffic.
+
+In an upcoming release, Audit Logs for Git push events will be enabled
+by default. Follow [#7865](https://gitlab.com/gitlab-org/gitlab/issues/7865) for updates.
+
+If you still wish to enable **Repository push** events in your instance, follow
+the steps bellow.
+
+**In Omnibus installations:**
+
+1. Enter the Rails console:
+
+   ```sh
+   sudo gitlab-rails console
+   ```
+
+1. Flip the switch and enable the feature flag:
+
+   ```ruby
+   Feature.enable(:repository_push_audit_event)
+   ```
+
 [ee-2336]: https://gitlab.com/gitlab-org/gitlab/issues/2336
 [ee]: https://about.gitlab.com/pricing/
 [permissions]: ../user/permissions.md
diff --git a/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md b/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md
index ef35a2d5266..743893d984a 100644
--- a/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md
+++ b/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md
@@ -8,7 +8,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](../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.
+GitLab has supported LDAP integration since [version 2.2](https://about.gitlab.com/blog/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/blog/2013/08/20/gitlab-6-dot-0-released/). LDAP integration has become one of the most popular features in GitLab.
 
 ## Getting started
 
@@ -18,12 +18,12 @@ The main reason organizations choose to utilize a LDAP server is to keep the ent
 
 There are many commercial and open source [directory servers](https://en.wikipedia.org/wiki/Directory_service#LDAP_implementations) that support the LDAP protocol. Deciding on the right directory server highly depends on the existing IT environment in which the server will be integrated with.
 
-For example, [Active Directory](https://technet.microsoft.com/en-us/library/hh831484(v=ws.11).aspx) is generally favored in a primarily Windows environment, as this allows quick integration with existing services. Other popular directory services include:
+For example, [Active Directory](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831484(v=ws.11)) is generally favored in a primarily Windows environment, as this allows quick integration with existing services. Other popular directory services include:
 
-- [Oracle Internet Directory](http://www.oracle.com/technetwork/middleware/id-mgmt/overview/index-082035.html)
+- [Oracle Internet Directory](https://www.oracle.com/middleware/technologies/internet-directory.html)
 - [OpenLDAP](http://www.openldap.org/)
 - [389 Directory](http://directory.fedoraproject.org/)
-- [OpenDJ](https://forgerock.org/opendj/)
+- [OpenDJ (Renamed to Foregerock Directory Services)](https://www.forgerock.com/platform/directory-services)
 - [ApacheDS](https://directory.apache.org/)
 
 > GitLab uses the [Net::LDAP](https://rubygems.org/gems/net-ldap) library under the hood. This means it supports all [IETF](https://tools.ietf.org/html/rfc2251) compliant LDAPv3 servers.
@@ -32,9 +32,9 @@ For example, [Active Directory](https://technet.microsoft.com/en-us/library/hh83
 
 We won't cover the installation and configuration of Windows Server or Active Directory Domain Services in this tutorial. There are a number of resources online to guide you through this process:
 
-- Install Windows Server 2012  - (_technet.microsoft.com_) - [Installing Windows Server 2012](https://technet.microsoft.com/en-us/library/jj134246(v=ws.11).aspx)
+- Install Windows Server 2012  - (`technet.microsoft.com`) - [Installing Windows Server 2012](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj134246(v=ws.11))
 
-- Install Active Directory Domain Services (AD DS) (_technet.microsoft.com_)- [Install Active Directory Domain Services](https://technet.microsoft.com/windows-server-docs/identity/ad-ds/deploy/install-active-directory-domain-services--level-100-#BKMK_PS)
+- Install Active Directory Domain Services (AD DS) (`technet.microsoft.com`)- [Install Active Directory Domain Services](https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/install-active-directory-domain-services--level-100-#BKMK_PS)
 
 > **Shortcut:** You can quickly install AD DS via PowerShell using
 `Install-WindowsFeature AD-Domain-Services -IncludeManagementTools`
@@ -97,7 +97,7 @@ People Ops US     GitLab.org/GitLab INT/Global Groups/People Ops US
 Global Admins     GitLab.org/GitLab INT/Global Groups/Global Admins
 ```
 
-> See [more information](https://technet.microsoft.com/en-us/library/ff730967.aspx) on searching Active Directory with Windows PowerShell from [The Scripting Guys](https://technet.microsoft.com/en-us/scriptcenter/dd901334.aspx)
+> See [more information](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-powershell-1.0/ff730967(v=technet.10)) on searching Active Directory with Windows PowerShell from [The Scripting Guys](https://devblogs.microsoft.com/scripting/)
 
 ## GitLab LDAP configuration
 
diff --git a/doc/administration/auth/how_to_configure_ldap_gitlab_ee/index.md b/doc/administration/auth/how_to_configure_ldap_gitlab_ee/index.md
index 9977f9aee14..f0eb6c5180b 100644
--- a/doc/administration/auth/how_to_configure_ldap_gitlab_ee/index.md
+++ b/doc/administration/auth/how_to_configure_ldap_gitlab_ee/index.md
@@ -110,7 +110,7 @@ gitlab_rails['ldap_servers'] = {
 Integration of GitLab with Active Directory (LDAP) reduces the complexity of user management.
 It has the advantage of improving user permission controls, whilst easing the deployment of GitLab into an existing [IT environment](https://www.techopedia.com/definition/29199/it-infrastructure). GitLab EE offers advanced group management and multiple LDAP servers.
 
-With the assistance of the [GitLab Support](https://about.gitlab.com/support) team, setting up GitLab with an existing AD/LDAP solution will be a smooth and painless process.
+With the assistance of the [GitLab Support](https://about.gitlab.com/support/) team, setting up GitLab with an existing AD/LDAP solution will be a smooth and painless process.
 
 <!-- ## Troubleshooting
 
diff --git a/doc/administration/auth/ldap-ee.md b/doc/administration/auth/ldap-ee.md
index d9b7d8b4382..e2894318fe5 100644
--- a/doc/administration/auth/ldap-ee.md
+++ b/doc/administration/auth/ldap-ee.md
@@ -281,7 +281,7 @@ sync to run once every 2 hours at the top of the hour.
 > Introduced in GitLab Enterprise Edition Starter 8.9.
 
 Using the `external_groups` setting will allow you to mark all users belonging
-to these groups as [external users](../../user/permissions.md#external-users-permissions).
+to these groups as [external users](../../user/permissions.md#external-users-core-only).
 Group membership is checked periodically through the `LdapGroupSync` background
 task.
 
@@ -415,7 +415,7 @@ main: # 'main' is the GitLab 'provider ID' of this LDAP server
 
 [^1]: In Active Directory, a user is marked as disabled/blocked if the user
       account control attribute (`userAccountControl:1.2.840.113556.1.4.803`)
-      has bit 2 set. See <https://ctogonewild.com/2009/09/03/bitmask-searches-in-ldap/>
+      has bit 2 set. See <https://ctovswild.com/2009/09/03/bitmask-searches-in-ldap/>
       for more information.
 
 ### User DN has changed
diff --git a/doc/administration/auth/ldap.md b/doc/administration/auth/ldap.md
index 186bf4c4825..e02ce1c0a21 100644
--- a/doc/administration/auth/ldap.md
+++ b/doc/administration/auth/ldap.md
@@ -408,12 +408,12 @@ 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
+<https://docs.microsoft.com/en-us/windows/win32/adsi/search-filter-syntax>. Support for
 nested members in the user filter should not be confused with
 [group sync nested groups support](ldap-ee.md#supported-ldap-group-typesattributes). **(STARTER ONLY)**
 
 Please note that GitLab does not support the custom filter syntax used by
-omniauth-ldap.
+OmniAuth LDAP.
 
 ### Escaping special characters
 
@@ -536,7 +536,7 @@ ldapsearch -H ldaps://$host:$port -D "$bind_dn" -y bind_dn_password.txt  -b "$ba
 
 - Variables beginning with a `$` refer to a variable from the LDAP section of
   your configuration file.
-- Replace ldaps:// with ldap:// if you are using the plain authentication method.
+- Replace `ldaps://` with `ldap://` if you are using the plain authentication method.
   Port `389` is the default `ldap://` port and `636` is the default `ldaps://`
   port.
 - We are assuming the password for the bind_dn user is in bind_dn_password.txt.
@@ -563,3 +563,15 @@ If you are getting 'Connection Refused' errors when trying to connect to the
 LDAP server please double-check the LDAP `port` and `encryption` settings used by
 GitLab. Common combinations are `encryption: 'plain'` and `port: 389`, OR
 `encryption: 'simple_tls'` and `port: 636`.
+
+### Connection times out
+
+If GitLab cannot reach your LDAP endpoint, you will see a message like this:
+
+```
+Could not authenticate you from Ldapmain because "Connection timed out - user specified timeout".
+```
+
+If your configured LDAP provider and/or endpoint is offline or otherwise unreachable by GitLab, no LDAP user will be able to authenticate and log in. GitLab does not cache or store credentials for LDAP users to provide authentication during an LDAP outage.
+
+Contact your LDAP provider or administrator if you are seeing this error.
diff --git a/doc/administration/auth/oidc.md b/doc/administration/auth/oidc.md
index 3445f916ef4..698a5506b83 100644
--- a/doc/administration/auth/oidc.md
+++ b/doc/administration/auth/oidc.md
@@ -35,7 +35,7 @@ The OpenID Connect will provide you with a client details and secret for you to
      { 'name' => 'openid_connect',
        'label' => '<your_oidc_label>',
        'args' => {
-         "name' => 'openid_connect',
+         'name' => 'openid_connect',
          'scope' => ['openid','profile'],
          'response_type' => 'code',
          'issuer' => '<your_oidc_url>',
diff --git a/doc/administration/auth/smartcard.md b/doc/administration/auth/smartcard.md
index 2d2734096ed..eb63df6b482 100644
--- a/doc/administration/auth/smartcard.md
+++ b/doc/administration/auth/smartcard.md
@@ -206,7 +206,7 @@ attribute. As a prerequisite, you must use an LDAP server that:
 
 **For installations from source**
 
-1. Add the `san_extensions` line to config/gitlab.yml` within the smartcard section:
+1. Add the `san_extensions` line to `config/gitlab.yml` within the smartcard section:
 
    ```yaml
    smartcard:
diff --git a/doc/administration/custom_hooks.md b/doc/administration/custom_hooks.md
index 3e714b446af..0702e0aa141 100644
--- a/doc/administration/custom_hooks.md
+++ b/doc/administration/custom_hooks.md
@@ -48,10 +48,9 @@ as appropriate.
 ## Set a global Git hook for all repositories
 
 To create a Git hook that applies to all of your repositories in
-your instance, set a global Git hook. Since all the repositories' `hooks`
-directories are symlinked to GitLab Shell's `hooks` directory, adding any hook
-to the GitLab Shell `hooks` directory will also apply it to all repositories. Follow
-the steps below to properly set up a custom hook for all repositories:
+your instance, set a global Git hook. Since GitLab will look inside the GitLab Shell
+`hooks` directory for global hooks, adding any hook there will apply it to all repositories.
+Follow the steps below to properly set up a custom hook for all repositories:
 
 1. On the GitLab server, navigate to the configured custom hook directory. The
    default is in the GitLab Shell directory. The GitLab Shell `hook` directory
diff --git a/doc/administration/geo/disaster_recovery/index.md b/doc/administration/geo/disaster_recovery/index.md
index 5eb23422374..ad5284938fa 100644
--- a/doc/administration/geo/disaster_recovery/index.md
+++ b/doc/administration/geo/disaster_recovery/index.md
@@ -51,7 +51,7 @@ must disable the **primary** node.
 
    NOTE: **Note:**
    (**CentOS only**) In CentOS 6 or older, there is no easy way to prevent GitLab from being
-   started if the machine reboots isn't available (see [gitlab-org/omnibus-gitlab#3058]).
+   started if the machine reboots isn't available (see [Omnibus GitLab issue #3058](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3058)).
    It may be safest to uninstall the GitLab package completely:
 
    ```sh
@@ -317,6 +317,5 @@ section to resolve the error. Otherwise, the secret is lost and you'll need to
 [setup-geo]: ../replication/index.md#setup-instructions
 [updating-geo]: ../replication/version_specific_updates.md#updating-to-gitlab-105
 [sec-tfa]: ../../../security/two_factor_authentication.md#disabling-2fa-for-everyone
-[gitlab-org/omnibus-gitlab#3058]: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3058
 [initiate-the-replication-process]: ../replication/database.html#step-3-initiate-the-replication-process
 [configure-the-primary-server]: ../replication/database.html#step-1-configure-the-primary-server
diff --git a/doc/administration/geo/disaster_recovery/planned_failover.md b/doc/administration/geo/disaster_recovery/planned_failover.md
index 75e07bcf863..8fee172ec64 100644
--- a/doc/administration/geo/disaster_recovery/planned_failover.md
+++ b/doc/administration/geo/disaster_recovery/planned_failover.md
@@ -43,23 +43,14 @@ will go smoothly.
 
 ### Object storage
 
-Some classes of non-repository data can use object storage in preference to
-file storage. Geo [does not replicate data in object storage](../replication/object_storage.md),
-leaving that task up to the object store itself. For a planned failover, this
-means you can decouple the replication of this data from the failover of the
-GitLab service.
-
-If you're already using object storage, simply verify that your **secondary**
-node has access to the same data as the **primary** node - they must either they share the
-same object storage configuration, or the **secondary** node should be configured to
-access a [geographically-replicated][os-repl] copy provided by the object store
-itself.
-
 If you have a large GitLab installation or cannot tolerate downtime, consider
 [migrating to Object Storage][os-conf] **before** scheduling a planned failover.
 Doing so reduces both the length of the maintenance window, and the risk of data
 loss as a result of a poorly executed planned failover.
 
+In GitLab 12.4, you can optionally allow GitLab to manage replication of Object Storage for
+**secondary** nodes. For more information, see [Object Storage replication][os-conf].
+
 ### Review the configuration of each **secondary** node
 
 Database settings are automatically replicated to the **secondary**  node, but the
@@ -224,5 +215,4 @@ Don't forget to remove the broadcast message after failover is complete.
 [background-verification]: background_verification.md
 [limitations]: ../replication/index.md#current-limitations
 [moving-repositories]: ../../operations/moving_repositories.md
-[os-conf]: ../replication/object_storage.md#configuration
-[os-repl]: ../replication/object_storage.md#replication
+[os-conf]: ../replication/object_storage.md
diff --git a/doc/administration/geo/replication/configuration.md b/doc/administration/geo/replication/configuration.md
index ddb5f22fd05..f09d9f20dab 100644
--- a/doc/administration/geo/replication/configuration.md
+++ b/doc/administration/geo/replication/configuration.md
@@ -25,7 +25,7 @@ Any change that requires access to the **Admin Area** needs to be done in the
 
 GitLab stores a number of secret values in the `/etc/gitlab/gitlab-secrets.json`
 file which *must* be the same on all nodes. Until there is
-a means of automatically replicating these between nodes (see issue [gitlab-org/gitlab-ee#3789]),
+a means of automatically replicating these between nodes (see [issue #3789](https://gitlab.com/gitlab-org/gitlab/issues/3789)),
 they must be manually replicated to the **secondary** node.
 
 1. SSH into the **primary** node, and execute the command below:
@@ -75,7 +75,7 @@ they must be manually replicated to the **secondary** node.
 ### Step 2. Manually replicate the **primary** node's SSH host keys
 
 GitLab integrates with the system-installed SSH daemon, designating a user
-(typically named git) through which all access requests are handled.
+(typically named `git`) through which all access requests are handled.
 
 In a [Disaster Recovery] situation, GitLab system
 administrators will promote a **secondary** node to the **primary** node. DNS records for the
@@ -165,10 +165,32 @@ keys must be manually replicated to the **secondary** node.
 
 ### Step 3. Add the **secondary** node
 
+1. SSH into your GitLab **secondary** server and login as root:
+
+   ```sh
+   sudo -i
+   ```
+
+1. Edit `/etc/gitlab/gitlab.rb` and add a **unique** name for your node.  You will need this in the next steps:
+
+   ```ruby
+   # The unique identifier for the Geo node.
+   gitlab_rails['geo_node_name'] = '<node_name_here>'
+   ```
+
+1. Reconfigure the **secondary** node for the change to take effect:
+
+   ```sh
+   gitlab-ctl reconfigure
+   ```
+
 1. Visit the **primary** node's **Admin Area > Geo**
    (`/admin/geo/nodes`) in your browser.
-1. Add the **secondary** node by providing its full URL. **Do NOT** check the
+1. Click the **New node** button.
+1. Add the **secondary** node. Use the **exact** name you inputed for `gitlab_rails['geo_node_name']` as the Name and the full URL as the URL.  **Do NOT** check the
    **This is a primary node** checkbox.
+
+   ![Add secondary node](img/adding_a_secondary_node.png)
 1. Optionally, choose which groups or storage shards should be replicated by the
    **secondary** node. Leave blank to replicate all. Read more in
    [selective synchronization](#selective-synchronization).
@@ -299,7 +321,6 @@ See the [troubleshooting document](troubleshooting.md).
 [setup-geo-omnibus]: index.md#using-omnibus-gitlab
 [Hashed Storage]: ../../repository_storage_types.md
 [Disaster Recovery]: ../disaster_recovery/index.md
-[gitlab-org/gitlab-ee#3789]: https://gitlab.com/gitlab-org/gitlab/issues/3789
 [gitlab-com/infrastructure#2821]: https://gitlab.com/gitlab-com/infrastructure/issues/2821
 [omnibus-ssl]: https://docs.gitlab.com/omnibus/settings/ssl.html
 [using-geo]: using_a_geo_server.md
diff --git a/doc/administration/geo/replication/database.md b/doc/administration/geo/replication/database.md
index 33f240ed11f..fa1b0f0e1d7 100644
--- a/doc/administration/geo/replication/database.md
+++ b/doc/administration/geo/replication/database.md
@@ -1,9 +1,6 @@
 # Geo database replication **(PREMIUM ONLY)**
 
 NOTE: **Note:**
-The following steps are for Omnibus installs only. Using Geo with source-based installs was **deprecated** in GitLab 11.5.
-
-NOTE: **Note:**
 If your GitLab installation uses external (not managed by Omnibus) PostgreSQL
 instances, the Omnibus roles will not be able to perform all necessary
 configuration steps. In this case,
@@ -37,8 +34,8 @@ recover. See below for more details.
 The following guide assumes that:
 
 - You are using Omnibus and therefore you are using PostgreSQL 9.6 or later
-  which includes the  [`pg_basebackup` tool][pgback] and improved
-  [Foreign Data Wrapper][FDW] support.
+  which includes the [`pg_basebackup` tool](https://www.postgresql.org/docs/9.6/app-pgbasebackup.html) and improved
+  [Foreign Data Wrapper][FDW](https://www.postgresql.org/docs/9.6/postgres-fdw.html) support.
 - You have a **primary** node already set up (the GitLab server you are
   replicating from), running Omnibus' PostgreSQL (or equivalent version), and
   you have a new **secondary** server set up with the same versions of the OS,
@@ -56,6 +53,19 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    sudo -i
    ```
 
+1. Edit `/etc/gitlab/gitlab.rb` and add a **unique** name for your node:
+
+   ```ruby
+   # The unique identifier for the Geo node.
+   gitlab_rails['geo_node_name'] = '<node_name_here>'
+   ```
+
+1. Reconfigure the **primary** node for the change to take effect:
+
+   ```sh
+   gitlab-ctl reconfigure
+   ```
+
 1. Execute the command below to define the node as **primary** node:
 
    ```sh
@@ -149,9 +159,9 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    address (corresponds to "internal address" for Google Cloud Platform) for
    `postgresql['md5_auth_cidr_addresses']` and `postgresql['listen_address']`.
 
-   The `listen_address` option opens PostgreSQL up to network connections
-   with the interface corresponding to the given address. See [the PostgreSQL
-   documentation][pg-docs-runtime-conn] for more details.
+   The `listen_address` option opens PostgreSQL up to network connections with the interface
+   corresponding to the given address. See [the PostgreSQL documentation](https://www.postgresql.org/docs/9.6/runtime-config-connection.html)
+   for more details.
 
    Depending on your network configuration, the suggested addresses may not
    be correct. If your **primary** node and **secondary** nodes connect over a local
@@ -202,9 +212,8 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    postgresql['md5_auth_cidr_addresses'] = ['<primary_node_ip>/32', '<secondary_node_ip>/32', '<another_secondary_node_ip>/32']
    ```
 
-   You may also want to edit the `wal_keep_segments` and `max_wal_senders` to
-   match your database replication requirements. Consult the [PostgreSQL -
-   Replication documentation][pg-docs-runtime-replication]
+   You may also want to edit the `wal_keep_segments` and `max_wal_senders` to match your
+   database replication requirements. Consult the [PostgreSQL - Replication documentation](https://www.postgresql.org/docs/9.6/runtime-config-replication.html)
    for more information.
 
 1. Save the file and reconfigure GitLab for the database listen changes and
@@ -430,7 +439,7 @@ data before running `pg_basebackup`.
      (e.g., you know the network path is secure, or you are using a site-to-site
      VPN). This is **not** safe over the public Internet!
    - You can read more details about each `sslmode` in the
-     [PostgreSQL documentation][pg-docs-ssl];
+     [PostgreSQL documentation](https://www.postgresql.org/docs/9.6/libpq-ssl.html#LIBPQ-SSL-PROTECTION);
      the instructions above are carefully written to ensure protection against
      both passive eavesdroppers and active "man-in-the-middle" attackers.
    - Change the `--slot-name` to the name of the replication slot
@@ -443,16 +452,16 @@ data before running `pg_basebackup`.
 
 The replication process is now complete.
 
-## PGBouncer support (optional)
+## PgBouncer support (optional)
 
-[PGBouncer](http://pgbouncer.github.io/) may be used with GitLab Geo to pool
-PostgreSQL connections. We recommend using PGBouncer if you use GitLab in a
+[PgBouncer](http://pgbouncer.github.io/) may be used with GitLab Geo to pool
+PostgreSQL connections. We recommend using PgBouncer if you use GitLab in a
 high-availability configuration with a cluster of nodes supporting a Geo
 **primary** node and another cluster of nodes supporting a Geo **secondary** node. For more
 information, see [High Availability with GitLab Omnibus](../../high_availability/database.md#high-availability-with-gitlab-omnibus-premium-only).
 
-For a Geo **secondary** node to work properly with PGBouncer in front of the database,
-it will need a separate read-only user to make [PostgreSQL FDW queries][FDW]
+For a Geo **secondary** node to work properly with PgBouncer in front of the database,
+it will need a separate read-only user to make [PostgreSQL FDW queries](https://www.postgresql.org/docs/9.6/postgres-fdw.html)
 work:
 
 1. On the **primary** Geo database, enter the PostgreSQL on the console as an
@@ -498,11 +507,6 @@ work:
 Read the [troubleshooting document](troubleshooting.md).
 
 [replication-slots-article]: https://medium.com/@tk512/replication-slots-in-postgresql-b4b03d277c75
-[pgback]: http://www.postgresql.org/docs/9.2/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-omnibus-gitlab
 [rake-maintenance]: ../../raketasks/maintenance.md
-[pg-docs-ssl]: https://www.postgresql.org/docs/9.6/static/libpq-ssl.html#LIBPQ-SSL-PROTECTION
-[pg-docs-runtime-conn]: https://www.postgresql.org/docs/9.6/static/runtime-config-connection.html
-[pg-docs-runtime-replication]: https://www.postgresql.org/docs/9.6/static/runtime-config-replication.html
diff --git a/doc/administration/geo/replication/external_database.md b/doc/administration/geo/replication/external_database.md
index 256195998a7..4451d3c6c08 100644
--- a/doc/administration/geo/replication/external_database.md
+++ b/doc/administration/geo/replication/external_database.md
@@ -132,7 +132,7 @@ when `roles ['geo_secondary_role']` is set. For high availability,
 refer to [Geo High Availability](../../high_availability/README.md).
 If you want to run this database external to Omnibus, please follow the instructions below.
 
-The tracking database requires an [FDW](https://www.postgresql.org/docs/9.6/static/postgres-fdw.html)
+The tracking database requires an [FDW](https://www.postgresql.org/docs/9.6/postgres-fdw.html)
 connection with the **secondary** replica database for improved performance.
 
 If you have an external database ready to be used as the tracking database,
@@ -173,7 +173,7 @@ the tracking database on port 5432.
    gitlab-rake geo:db:migrate
    ```
 
-1. Configure the [PostgreSQL FDW](https://www.postgresql.org/docs/9.6/static/postgres-fdw.html)
+1. Configure the [PostgreSQL FDW](https://www.postgresql.org/docs/9.6/postgres-fdw.html)
    connection and credentials:
 
    Save the script below in a file, ex. `/tmp/geo_fdw.sh` and modify the connection
diff --git a/doc/administration/geo/replication/faq.md b/doc/administration/geo/replication/faq.md
index b3580a706c3..b07b518d3b1 100644
--- a/doc/administration/geo/replication/faq.md
+++ b/doc/administration/geo/replication/faq.md
@@ -43,9 +43,9 @@ attachments / avatars and the whole database. This means user accounts,
 issues, merge requests, groups, project data, etc., will be available for
 query.
 
-## Can I git push to a **secondary** node?
+## Can I `git push` to a **secondary** node?
 
-Yes!  Pushing directly to a **secondary** node (for both HTTP and SSH, including git-lfs) was [introduced](https://about.gitlab.com/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
+Yes!  Pushing directly to a **secondary** node (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/blog/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
 
 ## How long does it take to have a commit replicated to a **secondary** node?
 
diff --git a/doc/administration/geo/replication/high_availability.md b/doc/administration/geo/replication/high_availability.md
index 9d84e10d496..faa9d051107 100644
--- a/doc/administration/geo/replication/high_availability.md
+++ b/doc/administration/geo/replication/high_availability.md
@@ -8,7 +8,7 @@ described, it is possible to adapt these instructions to your needs.
 
 ![Geo HA Diagram](../../high_availability/img/geo-ha-diagram.png)
 
-_[diagram source - gitlab employees only][diagram-source]_
+_[diagram source - GitLab employees only][diagram-source]_
 
 The topology above assumes that the **primary** and **secondary** Geo clusters
 are located in two separate locations, on their own virtual network
@@ -57,6 +57,11 @@ The following steps enable a GitLab cluster to serve as the **primary** node.
    roles ['geo_primary_role']
 
    ##
+   ## The unique identifier for the Geo node.
+   ##
+   gitlab_rails['geo_node_name'] = '<node_name_here>'
+
+   ##
    ## Disable automatic migrations
    ##
    gitlab_rails['auto_migrate'] = false
@@ -71,8 +76,16 @@ high availability configuration documentation for
 [PostgreSQL](../../high_availability/database.md#configuring-the-application-nodes)
 and [Redis](../../high_availability/redis.md#example-configuration-for-the-gitlab-application).
 
-The **primary** database will require modification later, as part of
-[step 2](#step-2-configure-the-main-read-only-replica-postgresql-database-on-the-secondary-node).
+### Step 2: Configure the **primary** database
+
+1. Edit `/etc/gitlab/gitlab.rb` and add the following:
+
+   ```ruby
+   ##
+   ## Configure the Geo primary role and the PostgreSQL role
+   ##
+   roles ['geo_primary_role', 'postgres_role']
+   ```
 
 ## Configure a **secondary** node
 
@@ -115,9 +128,9 @@ the **primary** database. Use the following as a guide.
 
    ```ruby
    ##
-   ## Configure the PostgreSQL role
+   ## Configure the Geo secondary role and the PostgreSQL role
    ##
-   roles ['postgres_role']
+   roles ['geo_secondary_role', 'postgres_role']
 
    ##
    ## Secondary address
@@ -222,6 +235,11 @@ following modifications:
    roles ['geo_secondary_role', 'application_role']
 
    ##
+   ## The unique identifier for the Geo node.
+   ##
+   gitlab_rails['geo_node_name'] = '<node_name_here>'
+
+   ##
    ## Disable automatic migrations
    ##
    gitlab_rails['auto_migrate'] = false
@@ -274,15 +292,15 @@ After making these changes [Reconfigure GitLab][gitlab-reconfigure] so the chang
 
 On the secondary the following GitLab frontend services will be enabled:
 
-- geo-logcursor
-- gitlab-pages
-- gitlab-workhorse
-- logrotate
-- nginx
-- registry
-- remote-syslog
-- sidekiq
-- unicorn
+- `geo-logcursor`
+- `gitlab-pages`
+- `gitlab-workhorse`
+- `logrotate`
+- `nginx`
+- `registry`
+- `remote-syslog`
+- `sidekiq`
+- `unicorn`
 
 Verify these services by running `sudo gitlab-ctl status` on the frontend
 application servers.
diff --git a/doc/administration/geo/replication/img/adding_a_secondary_node.png b/doc/administration/geo/replication/img/adding_a_secondary_node.png
new file mode 100644
index 00000000000..5421b578672
--- /dev/null
+++ b/doc/administration/geo/replication/img/adding_a_secondary_node.png
diff --git a/doc/administration/geo/replication/img/single_git_add_geolocation_rule.png b/doc/administration/geo/replication/img/single_git_add_geolocation_rule.png
new file mode 100644
index 00000000000..4b04ba8d1f1
--- /dev/null
+++ b/doc/administration/geo/replication/img/single_git_add_geolocation_rule.png
diff --git a/doc/administration/geo/replication/img/single_git_add_traffic_policy_endpoints.png b/doc/administration/geo/replication/img/single_git_add_traffic_policy_endpoints.png
new file mode 100644
index 00000000000..c19ad57c953
--- /dev/null
+++ b/doc/administration/geo/replication/img/single_git_add_traffic_policy_endpoints.png
diff --git a/doc/administration/geo/replication/img/single_git_clone_panel.png b/doc/administration/geo/replication/img/single_git_clone_panel.png
new file mode 100644
index 00000000000..8aa0bd2f7d8
--- /dev/null
+++ b/doc/administration/geo/replication/img/single_git_clone_panel.png
diff --git a/doc/administration/geo/replication/img/single_git_create_policy_records_with_traffic_policy.png b/doc/administration/geo/replication/img/single_git_create_policy_records_with_traffic_policy.png
new file mode 100644
index 00000000000..a554532f3b8
--- /dev/null
+++ b/doc/administration/geo/replication/img/single_git_create_policy_records_with_traffic_policy.png
diff --git a/doc/administration/geo/replication/img/single_git_created_policy_record.png b/doc/administration/geo/replication/img/single_git_created_policy_record.png
new file mode 100644
index 00000000000..74c42395e15
--- /dev/null
+++ b/doc/administration/geo/replication/img/single_git_created_policy_record.png
diff --git a/doc/administration/geo/replication/img/single_git_name_policy.png b/doc/administration/geo/replication/img/single_git_name_policy.png
new file mode 100644
index 00000000000..1a976539e94
--- /dev/null
+++ b/doc/administration/geo/replication/img/single_git_name_policy.png
diff --git a/doc/administration/geo/replication/img/single_git_policy_diagram.png b/doc/administration/geo/replication/img/single_git_policy_diagram.png
new file mode 100644
index 00000000000..d62952dbbb3
--- /dev/null
+++ b/doc/administration/geo/replication/img/single_git_policy_diagram.png
diff --git a/doc/administration/geo/replication/img/single_git_traffic_policies.png b/doc/administration/geo/replication/img/single_git_traffic_policies.png
new file mode 100644
index 00000000000..b3193c23d99
--- /dev/null
+++ b/doc/administration/geo/replication/img/single_git_traffic_policies.png
diff --git a/doc/administration/geo/replication/index.md b/doc/administration/geo/replication/index.md
index f9f56b96e22..1fef2e85ce6 100644
--- a/doc/administration/geo/replication/index.md
+++ b/doc/administration/geo/replication/index.md
@@ -63,7 +63,7 @@ Keep in mind that:
   - Get user data for logins (API).
   - Replicate repositories, LFS Objects, and Attachments (HTTPS + JWT).
 - Since GitLab Premium 10.0, the **primary** node no longer talks to **secondary** nodes to notify for changes (API).
-- Pushing directly to a **secondary** node (for both HTTP and SSH, including git-lfs) was [introduced](https://about.gitlab.com/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
+- Pushing directly to a **secondary** node (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/blog/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
 - There are [limitations](#current-limitations) in the current implementation.
 
 ### Architecture
@@ -108,7 +108,7 @@ The following are required to run Geo:
   [fast lookup of authorized SSH keys in the database](../../operations/fast_ssh_key_lookup.md))
   The following operating systems are known to ship with a current version of OpenSSH:
   - [CentOS](https://www.centos.org) 7.4+
-  - [Ubuntu](https://www.ubuntu.com) 16.04+
+  - [Ubuntu](https://ubuntu.com) 16.04+
 - PostgreSQL 9.6+ with [FDW](https://www.postgresql.org/docs/9.6/postgres-fdw.html) support and [Streaming Replication](https://wiki.postgresql.org/wiki/Streaming_Replication)
 - Git 2.9+
 - All nodes must run the same GitLab version.
@@ -229,6 +229,10 @@ For more information on Geo security, see [Geo security review](security_review.
 
 For more information on tuning Geo, see [Tuning Geo](tuning.md).
 
+### Set up a location-aware Git URL
+
+For an example of how to set up a location-aware Git remote URL with AWS Route53, see [Location-aware Git remote URL with AWS Route53](location_aware_git_url.md).
+
 ## Remove Geo node
 
 For more information on removing a Geo node, see [Removing **secondary** Geo nodes](remove_geo_node.md).
@@ -240,7 +244,7 @@ This list of limitations only reflects the latest version of GitLab. If you are
 
 - Pushing directly to a **secondary** node redirects (for HTTP) or proxies (for SSH) the request to the **primary** node instead of [handling it directly](https://gitlab.com/gitlab-org/gitlab/issues/1381), except when using Git over HTTP with credentials embedded within the URI. For example, `https://user:password@secondary.tld`.
 - The **primary** node has to be online for OAuth login to happen. Existing sessions and Git are not affected.
-- The installation takes multiple manual steps that together can take about an hour depending on circumstances. We are working on improving this experience. See [gitlab-org/omnibus-gitlab#2978](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2978) for details.
+- The installation takes multiple manual steps that together can take about an hour depending on circumstances. We are working on improving this experience. See [Omnibus GitLab issue #2978](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2978) for details.
 - Real-time updates of issues/merge requests (for example, via long polling) doesn't work on the **secondary** node.
 - [Selective synchronization](configuration.md#selective-synchronization) applies only to files and repositories. Other datasets are replicated to the **secondary** node in full, making it inappropriate for use as an access control mechanism.
 - Object pools for forked project deduplication work only on the **primary** node, and are duplicated on the **secondary** node.
@@ -251,36 +255,58 @@ This list of limitations only reflects the latest version of GitLab. If you are
 The following table lists the GitLab features along with their replication
 and verification status on a **secondary** node.
 
-You can keep track of the progress to include the missing items in:
-
-- [ee-893](https://gitlab.com/groups/gitlab-org/-/epics/893).
-- [ee-1430](https://gitlab.com/groups/gitlab-org/-/epics/1430).
-
-| Feature | Replicated | Verified |
-|-----------|------------|----------|
-| All database content (e.g. snippets, epics, issues, merge requests, groups, and project metadata)  | Yes | Yes |
-| Project repository | Yes | Yes |
-| Project wiki repository | Yes | Yes |
-| Project designs repository | No | No |
-| Uploads (e.g. attachments to issues, merge requests, epics, and avatars) | Yes | Yes, only on transfer, or manually (1) |
-| LFS Objects | Yes | Yes, only on transfer, or manually (1) |
-| CI job artifacts (other than traces) | Yes | No, only manually (1) |
-| Archived traces | Yes | Yes, only on transfer, or manually (1) |
-| Personal snippets | Yes | Yes |
-| Version-controlled personal snippets ([unsupported](https://gitlab.com/gitlab-org/gitlab-foss/issues/13426)) | No | No |
-| Project snippets | Yes | Yes |
-| Version-controlled project snippets ([unsupported](https://gitlab.com/gitlab-org/gitlab-foss/issues/13426)) | No | No |
-| Object pools for forked project deduplication | No | No |
-| [Server-side Git Hooks](../../custom_hooks.md) | No | No |
-| [Elasticsearch integration](../../../integration/elasticsearch.md) | No | No |
-| [GitLab Pages](../../pages/index.md) | No | No |
-| [Container Registry](../../packages/container_registry.md) | Yes | No |
-| [NPM Registry](../../../user/packages/npm_registry/index.md) | No | No |
-| [Maven Packages](../../../user/packages/maven_repository/index.md) | No | No |
-| [External merge request diffs](../../merge_request_diffs.md) | No, if they are on-disk | No |
-| Content in object storage ([track progress](https://gitlab.com/groups/gitlab-org/-/epics/1526)) | No | No |
-
-1. The integrity can be verified manually using [Integrity Check Rake Task](../../raketasks/check.md) on both nodes and comparing the output between them.
+You can keep track of the progress to implement the missing items in
+these epics/issues:
+
+- [Unreplicated Data Types](https://gitlab.com/groups/gitlab-org/-/epics/893)
+- [Verify all replicated data](https://gitlab.com/groups/gitlab-org/-/epics/1430)
+
+| Feature                                             | Replicated               | Verified                    | Notes                                      |
+|-----------------------------------------------------|--------------------------|-----------------------------|--------------------------------------------|
+| All database content                                | **Yes**                  | **Yes**                     |                                            |
+| Project repository                                  | **Yes**                  | **Yes**                     |                                            |
+| Project wiki repository                             | **Yes**                  | **Yes**                     |                                            |
+| Project designs repository                          | [No][design-replication] | [No][design-verification]   |                                            |
+| Uploads                                             | **Yes**                  | [No][upload-verification]   | Verified only on transfer, or manually (1) |
+| LFS Objects                                         | **Yes**                  | [No][lfs-verification]      | Verified only on transfer, or manually (1) |
+| CI job artifacts (other than traces)                | **Yes**                  | [No][artifact-verification] | Verified only manually (1)                 |
+| Archived traces                                     | **Yes**                  | [No][artifact-verification] | Verified only on transfer, or manually (1) |
+| Personal snippets                                   | **Yes**                  | **Yes**                     |                                            |
+| Version-controlled personal snippets                | No                       | No                          | [Not yet supported][unsupported-snippets]  |
+| Project snippets                                    | **Yes**                  | **Yes**                     |                                            |
+| Version-controlled project snippets                 | No                       | No                          | [Not yet supported][unsupported-snippets]  |
+| Object pools for forked project deduplication       | **Yes**                  | No                          |                                            |
+| [Server-side Git Hooks][custom-hooks]               | No                       | No                          |                                            |
+| [Elasticsearch integration][elasticsearch]          | No                       | No                          |                                            |
+| [GitLab Pages][gitlab-pages]                        | [No][pages-replication]  | No                          |                                            |
+| [Container Registry][container-registry]            | **Yes**                  | No                          |                                            |
+| [NPM Registry][npm-registry]                        | No                       | No                          |                                            |
+| [Maven Repository][maven-repository]                | No                       | No                          |                                            |
+| [Conan Repository][conan-repository]                | No                       | No                          |                                            |
+| [External merge request diffs][merge-request-diffs] | [No][diffs-replication]  | No                          |                                            |
+| Content in object storage                           | **Yes**                  | No                          |                                            |
+
+[design-replication]: https://gitlab.com/groups/gitlab-org/-/epics/1633
+[design-verification]: https://gitlab.com/gitlab-org/gitlab/issues/32467
+[upload-verification]: https://gitlab.com/groups/gitlab-org/-/epics/1817
+[lfs-verification]: https://gitlab.com/gitlab-org/gitlab/issues/8922
+[artifact-verification]: https://gitlab.com/gitlab-org/gitlab/issues/8923
+[diffs-replication]: https://gitlab.com/gitlab-org/gitlab/issues/33817
+[pages-replication]: https://gitlab.com/groups/gitlab-org/-/epics/589
+
+[unsupported-snippets]: https://gitlab.com/gitlab-org/gitlab/issues/14228
+[custom-hooks]: ../../custom_hooks.md
+[elasticsearch]: ../../../integration/elasticsearch.md
+[gitlab-pages]: ../../pages/index.md
+[container-registry]: ../../packages/container_registry.md
+[npm-registry]: ../../../user/packages/npm_registry/index.md
+[maven-repository]: ../../../user/packages/maven_repository/index.md
+[conan-repository]: ../../../user/packages/conan_repository/index.md
+[merge-request-diffs]: ../../merge_request_diffs.md
+
+1. The integrity can be verified manually using
+[Integrity Check Rake Task](../../raketasks/check.md)
+on both nodes and comparing the output between them.
 
 DANGER: **DANGER**
 Features not on this list, or with **No** in the **Replicated** column,
diff --git a/doc/administration/geo/replication/location_aware_git_url.md b/doc/administration/geo/replication/location_aware_git_url.md
new file mode 100644
index 00000000000..6183a0ad119
--- /dev/null
+++ b/doc/administration/geo/replication/location_aware_git_url.md
@@ -0,0 +1,119 @@
+# Location-aware Git remote URL with AWS Route53 **(PREMIUM ONLY)**
+
+You can provide GitLab users with a single remote URL that automatically uses
+the Geo node closest to them. This means users don't need to update their Git
+configuration to take advantage of closer Geo nodes as they move.
+
+This is possible because, Git push requests can be automatically redirected
+(HTTP) or proxied (SSH) from **secondary** nodes to the **primary** node.
+
+Though these instructions use [AWS Route53](https://aws.amazon.com/route53/),
+other services such as [Cloudflare](https://www.cloudflare.com/) could be used
+as well.
+
+NOTE: **Note**
+You can also use a load balancer to distribute web UI or API traffic to
+[multiple Geo **secondary** nodes](../../../user/admin_area/geo_nodes.md#multiple-secondary-nodes-behind-a-load-balancer).
+Importantly, the **primary** node cannot yet be included. See the feature request
+[Support putting the **primary** behind a Geo node load balancer](https://gitlab.com/gitlab-org/gitlab/issues/10888).
+
+## Prerequisites
+
+In this example, we have already set up:
+
+- `primary.example.com` as a Geo **primary** node.
+- `secondary.example.com` as a Geo **secondary** node.
+
+We will create a `git.example.com` subdomain that will automatically direct
+requests:
+
+- From Europe to the **secondary** node.
+- From all other locations to the **primary** node.
+
+In any case, you require:
+
+- A working GitLab **primary** node that is accessible at its own address.
+- A working GitLab **secondary** node.
+- A Route53 Hosted Zone managing your domain.
+
+If you have not yet setup a Geo **primary** node and **secondary** node, please consult
+[the Geo setup instructions](https://docs.gitlab.com/ee/administration/geo/replication/#setup-instructions).
+
+## Create a traffic policy
+
+In a Route53 Hosted Zone, traffic policies can be used to set up a variety of
+routing configurations.
+
+1. Navigate to the
+[Route53 dashboard](https://console.aws.amazon.com/route53/home) and click
+**Traffic policies**.
+
+   ![Traffic policies](img/single_git_traffic_policies.png)
+
+1. Click the **Create traffic policy** button.
+
+   ![Name policy](img/single_git_name_policy.png)
+
+1. Fill in the **Policy Name** field with `Single Git Host` and click **Next**.
+
+   ![Policy diagram](img/single_git_policy_diagram.png)
+
+1. Leave **DNS type** as `A: IP Address in IPv4 format`.
+1. Click **Connect to...** and select **Geolocation rule**.
+
+   ![Add geolocation rule](img/single_git_add_geolocation_rule.png)
+
+1. For the first **Location**, leave it as `Default`.
+1. Click **Connect to...** and select **New endpoint**.
+1. Choose **Type** `value` and fill it in with `<your **primary** IP address>`.
+1. For the second **Location**, choose `Europe`.
+1. Click **Connect to...** and select **New endpoint**.
+1. Choose **Type** `value` and fill it in with `<your **secondary** IP address>`.
+
+   ![Add traffic policy endpoints](img/single_git_add_traffic_policy_endpoints.png)
+
+1. Click **Create traffic policy**.
+
+   ![Create policy records with traffic policy](img/single_git_create_policy_records_with_traffic_policy.png)
+
+1. Fill in **Policy record DNS name** with `git`.
+1. Click **Create policy records**.
+
+   ![Created policy record](img/single_git_created_policy_record.png)
+
+You have successfully set up a single host, e.g. `git.example.com` which
+distributes traffic to your Geo nodes by geolocation!
+
+## Configure Git clone URLs to use the special Git URL
+
+When a user clones a repository for the first time, they typically copy the Git
+remote URL from the project page. By default, these SSH and HTTP URLs are based
+on the external URL of the current host. For example:
+
+- `git@secondary.example.com:group1/project1.git`
+- `https://secondary.example.com/group1/project1.git`
+
+![Clone panel](img/single_git_clone_panel.png)
+
+You can customize the:
+
+- SSH remote URL to use the location-aware `git.example.com`. To do so, change the SSH remote URL's
+  host by setting `gitlab_rails['gitlab_ssh_host']` in `gitlab.rb` of web nodes.
+- HTTP remote URL as shown in
+  [Custom Git clone URL for HTTP(S)](../../../user/admin_area/settings/visibility_and_access_controls.md#custom-git-clone-url-for-https).
+
+## Example Git request handling behavior
+
+After following the configuration steps above, handling for Git requests is now location aware.
+For requests:
+
+- Outside Europe, all requests are directed to the **primary** node.
+- Within Europe, over:
+  - HTTP:
+    - `git clone http://git.example.com/foo/bar.git` is directed to the **secondary** node.
+    - `git push` is initially directed to the **secondary**, which automatically
+      redirects to `primary.example.com`.
+  - SSH:
+    - `git clone git@git.example.com:foo/bar.git` is directed to the **secondary**.
+    - `git push` is initially directed to the **secondary**, which automatically
+       proxies the request to `primary.example.com`.
diff --git a/doc/administration/geo/replication/object_storage.md b/doc/administration/geo/replication/object_storage.md
index 878b67a8f8e..a9087abcbd9 100644
--- a/doc/administration/geo/replication/object_storage.md
+++ b/doc/administration/geo/replication/object_storage.md
@@ -1,16 +1,33 @@
 # Geo with Object storage **(PREMIUM ONLY)**
 
-Geo can be used in combination with Object Storage (AWS S3, or
-other compatible object storage).
+Geo can be used in combination with Object Storage (AWS S3, or other compatible object storage).
 
-## Configuration
+Currently, **secondary** nodes can use either:
 
-At this time it is required that if object storage is enabled on the
-**primary** node, it must also be enabled on each **secondary** node.
+- The same storage bucket as the **primary** node.
+- A replicated storage bucket.
 
-**Secondary** nodes can use the same storage bucket as the **primary** node, or
-they can use a replicated storage bucket. At this time GitLab does not
-take care of content replication in object storage.
+To have:
+
+- GitLab manage replication, follow [Enabling GitLab replication](#enabling-gitlab-managed-object-storage-replication).
+- Third-party services manage replication, follow [Third-party replication services](#third-party-replication-services).
+
+## Enabling GitLab managed object storage replication
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/10586) in GitLab 12.4.
+
+CAUTION: **Caution:**
+This is a [**beta** feature](https://about.gitlab.com/handbook/product/#beta) and is not ready yet for production use at any scale.
+
+**Secondary** nodes can replicate files stored on the **primary** node regardless of
+whether they are stored on the local filesystem or in object storage.
+
+To enable GitLab replication, you must:
+
+1. Go to **Admin Area > Geo**.
+1. Press **Edit** on the **secondary** node.
+1. Enable the **Allow this secondary node to replicate content on Object Storage**
+   checkbox.
 
 For LFS, follow the documentation to
 [set up LFS object storage](../../../workflow/lfs/lfs_administration.md#storing-lfs-objects-in-remote-object-storage).
@@ -20,12 +37,21 @@ For CI job artifacts, there is similar documentation to configure
 
 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
-**primary** node only. **Secondary** nodes will automatically notice that the migrated
-files are now in object storage.
+If you want to migrate the **primary** node's files to object storage, you can
+configure the **secondary** in a few ways:
+
+- Use the exact same object storage.
+- Use a separate object store but leverage your object storage solution's built-in
+  replication.
+- Use a separate object store and enable the **Allow this secondary node to replicate
+  content on Object Storage** setting.
+
+GitLab does not currently support the case where both:
+
+- The **primary** node uses local storage.
+- A **secondary** node uses object storage.
 
-## Replication
+## Third-party replication services
 
 When using Amazon S3, you can use
 [CRR](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) to
diff --git a/doc/administration/geo/replication/security_review.md b/doc/administration/geo/replication/security_review.md
index 832d02be9a5..68bf5b5d23a 100644
--- a/doc/administration/geo/replication/security_review.md
+++ b/doc/administration/geo/replication/security_review.md
@@ -1,9 +1,9 @@
 # Geo security review (Q&A) **(PREMIUM ONLY)**
 
-The following security review of the Geo feature set focuses on security
-aspects of the feature as they apply to customers running their own GitLab
-instances. The review questions are based in part on the [application security architecture](https://www.owasp.org/index.php/Application_Security_Architecture_Cheat_Sheet)
-questions from [owasp.org](https://www.owasp.org).
+The following security review of the Geo feature set focuses on security aspects of
+the feature as they apply to customers running their own GitLab instances. The review
+questions are based in part on the [OWASP Application Security Verification Standard Project](https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project)
+from [owasp.org](https://www.owasp.org/index.php/Main_Page).
 
 ## Business Model
 
@@ -30,7 +30,7 @@ questions from [owasp.org](https://www.owasp.org).
   private projects. Geo replicates them all indiscriminately. “Selective sync”
   exists for files and repositories (but not database content), which would permit
   only less-sensitive projects to be replicated to a **secondary** node if desired.
-- See also: [developing a data classification policy](https://gitlab.com/gitlab-com/security/issues/4).
+- See also: [GitLab data classification policy](https://about.gitlab.com/handbook/engineering/security/data-classification-policy.html).
 
 ### What data backup and retention requirements have been defined for the application?
 
@@ -49,9 +49,9 @@ questions from [owasp.org](https://www.owasp.org).
 ### How do the end‐users interact with the application?
 
 - **Secondary** nodes provide all the interfaces a **primary** node does
-  (notably a HTTP/HTTPS web application, and HTTP/HTTPS or SSH git repository
+  (notably a HTTP/HTTPS web application, and HTTP/HTTPS or SSH Git repository
   access), but is constrained to read-only activities. The principal use case is
-  envisioned to be cloning git repositories from the **secondary** node in favor of the
+  envisioned to be cloning Git repositories from the **secondary** node in favor of the
   **primary** node, but end-users may use the GitLab web interface to view projects,
   issues, merge requests, snippets, etc.
 
@@ -229,7 +229,7 @@ questions from [owasp.org](https://www.owasp.org).
 - A static secret shared across all hosts in a GitLab deployment.
 - In transit, data should be encrypted, although the application does permit
   communication to proceed unencrypted. The two main transits are the **secondary** node’s
-  replication process for PostgreSQL, and for git repositories/files. Both should
+  replication process for PostgreSQL, and for Git repositories/files. Both should
   be protected using TLS, with the keys for that managed via Omnibus per existing
   configuration for end-user access to GitLab.
 
diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index 263fc05dce9..4d64941411a 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -252,7 +252,7 @@ to start again from scratch, there are a few steps that can help you:
    gitlab-ctl stop geo-logcursor
    ```
 
-   You can watch sidekiq logs to know when sidekiq jobs processing have finished:
+   You can watch Sidekiq logs to know when Sidekiq jobs processing have finished:
 
    ```sh
    gitlab-ctl tail sidekiq
@@ -280,8 +280,8 @@ to start again from scratch, there are a few steps that can help you:
    Any uploaded content like file attachments, avatars or LFS objects are stored in a
    subfolder in one of the two paths below:
 
-   - /var/opt/gitlab/gitlab-rails/shared
-   - /var/opt/gitlab/gitlab-rails/uploads
+   - `/var/opt/gitlab/gitlab-rails/shared`
+   - `/var/opt/gitlab/gitlab-rails/uploads`
 
    To rename all of them:
 
diff --git a/doc/administration/geo/replication/using_a_geo_server.md b/doc/administration/geo/replication/using_a_geo_server.md
index 55b5d486676..55c7e78da92 100644
--- a/doc/administration/geo/replication/using_a_geo_server.md
+++ b/doc/administration/geo/replication/using_a_geo_server.md
@@ -4,7 +4,7 @@
 
 After you set up the [database replication and configure the Geo nodes][req], use your closest GitLab node as you would a normal standalone GitLab instance.
 
-Pushing directly to a **secondary** node (for both HTTP, SSH including git-lfs) was [introduced](https://about.gitlab.com/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
+Pushing directly to a **secondary** node (for both HTTP, SSH including Git LFS) was [introduced](https://about.gitlab.com/blog/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
 
 Example of the output you will see when pushing to a **secondary** node:
 
diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md
index 3b32baf28b9..d5749427f6e 100644
--- a/doc/administration/gitaly/index.md
+++ b/doc/administration/gitaly/index.md
@@ -3,7 +3,7 @@
 [Gitaly](https://gitlab.com/gitlab-org/gitaly) is the service that
 provides high-level RPC access to Git repositories. Without it, no other
 components can read or write Git data. GitLab components that access Git
-repositories (gitlab-rails, gitlab-shell, gitlab-workhorse, etc.) act as clients
+repositories (GitLab Rails, GitLab Shell, GitLab Workhorse, etc.) act as clients
 to Gitaly. End users do not have direct access to Gitaly.
 
 In the rest of this page, Gitaly server is referred to the standalone node that
@@ -47,8 +47,8 @@ But since 11.8 the indexer uses Gitaly for data access as well. NFS can still
 be leveraged for redudancy on block level of the Git data. But only has to
 be mounted on the Gitaly server.
 
-Starting with GitLab 11.8, it is possible to use ElasticSearch in conjunction with
-a Gitaly setup that isn't utilising NFS. In order to use ElasticSearch in this
+Starting with GitLab 11.8, it is possible to use Elasticsearch in conjunction with
+a Gitaly setup that isn't utilising NFS. In order to use Elasticsearch in this
 scenario, the [new repository indexer](../../integration/elasticsearch.md#elasticsearch-repository-indexer-beta)
 needs to be enabled in your GitLab configuration.
 
@@ -71,8 +71,8 @@ The following list depicts what the network architecture of Gitaly is:
 - A GitLab server can use one or more Gitaly servers.
 - Gitaly addresses must be specified in such a way that they resolve
   correctly for ALL Gitaly clients.
-- Gitaly clients are: Unicorn, Sidekiq, gitlab-workhorse,
-  gitlab-shell, Elasticsearch Indexer, and Gitaly itself.
+- Gitaly clients are: Unicorn, Sidekiq, GitLab Workhorse,
+  GitLab Shell, Elasticsearch Indexer, and Gitaly itself.
 - A Gitaly server must be able to make RPC calls **to itself** via its own
   `(Gitaly address, Gitaly token)` pair as specified in `/config/gitlab.yml`.
 - Gitaly servers must not be exposed to the public internet as Gitaly's network
@@ -86,7 +86,8 @@ Below we describe how to configure two Gitaly servers one at
 `gitaly1.internal` and the other at `gitaly2.internal`
 with secret token `abc123secret`. We assume
 your GitLab installation has three repository storages: `default`,
-`storage1` and `storage2`.
+`storage1` and `storage2`. You can use as little as just one server with one
+repository storage if desired.
 
 ### 1. Installation
 
@@ -129,7 +130,7 @@ Configure a token on the instance that runs the GitLab Rails application.
 Next, on the Gitaly servers, you need to configure storage paths, enable
 the network listener and configure the token.
 
-NOTE: **Note:** if you want to reduce the risk of downtime when you enable
+NOTE: **Note:** If you want to reduce the risk of downtime when you enable
 authentication you can temporarily disable enforcement, see [the
 documentation on configuring Gitaly
 authentication](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/configuration/README.md#authentication)
@@ -177,20 +178,19 @@ Check the directory layout on your Gitaly server to be sure.
    # Don't forget to copy `/etc/gitlab/gitlab-secrets.json` from web server to Gitaly server.
    gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
 
+   # Authentication token to ensure only authorized servers can communicate with
+   # Gitaly server
+   gitaly['auth_token'] = 'abc123secret'
+
    # Make Gitaly accept connections on all network interfaces. You must use
    # firewalls to restrict access to this address/port.
+   # Comment out following line if you only want to support TLS connections
    gitaly['listen_addr'] = "0.0.0.0:8075"
-   gitaly['auth_token'] = 'abc123secret'
-
-   # To use TLS for Gitaly you need to add
-   gitaly['tls_listen_addr'] = "0.0.0.0:9999"
-   gitaly['certificate_path'] = "path/to/cert.pem"
-   gitaly['key_path'] = "path/to/key.pem"
    ```
 
 1. Append the following to `/etc/gitlab/gitlab.rb` for each respective server:
 
-   For `gitaly1.internal`:
+   On `gitaly1.internal`:
 
    ```
    gitaly['storage'] = [
@@ -199,7 +199,7 @@ Check the directory layout on your Gitaly server to be sure.
    ]
    ```
 
-   For `gitaly2.internal`:
+   On `gitaly2.internal`:
 
    ```
    gitaly['storage'] = [
@@ -219,11 +219,6 @@ Check the directory layout on your Gitaly server to be sure.
 
    ```toml
    listen_addr = '0.0.0.0:8075'
-   tls_listen_addr = '0.0.0.0:9999'
-
-   [tls]
-   certificate_path = /path/to/cert.pem
-   key_path = /path/to/key.pem
 
    [auth]
    token = 'abc123secret'
@@ -231,7 +226,7 @@ Check the directory layout on your Gitaly server to be sure.
 
 1. Append the following to `/home/git/gitaly/config.toml` for each respective server:
 
-   For `gitaly1.internal`:
+   On `gitaly1.internal`:
 
    ```toml
    [[storage]]
@@ -241,7 +236,7 @@ Check the directory layout on your Gitaly server to be sure.
    name = 'storage1'
    ```
 
-   For `gitaly2.internal`:
+   On `gitaly2.internal`:
 
    ```toml
    [[storage]]
@@ -369,14 +364,23 @@ To disable Gitaly on a client node:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/22602) in GitLab 11.8.
 
 Gitaly supports TLS encryption. To be able to communicate
-with a Gitaly instance that listens for secure connections you will need to use `tls://` url
+with a Gitaly instance that listens for secure connections you will need to use `tls://` URL
 scheme in the `gitaly_address` of the corresponding storage entry in the GitLab configuration.
 
 You will need to bring your own certificates as this isn't provided automatically.
-The certificate to be used needs to be installed on all Gitaly nodes and on all
+The certificate to be used needs to be installed on all Gitaly nodes, and the
+certificate (or CA of certificate) on all
 client nodes that communicate with it following the procedure described in
 [GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates).
 
+NOTE: **Note**
+The self-signed certificate must specify the address you use to access the
+Gitaly server. If you are addressing the Gitaly server by a hostname, you can
+either use the Common Name field for this, or add it as a Subject Alternative
+Name. If you are addressing the Gitaly server by its IP address, you must add it
+as a Subject Alternative Name to the certificate.
+[gRPC does not support using an IP address as Common Name in a certificate](https://github.com/grpc/grpc/issues/2691).
+
 NOTE: **Note:**
 It is possible to configure Gitaly servers with both an
 unencrypted listening address `listen_addr` and an encrypted listening
@@ -387,7 +391,7 @@ To configure Gitaly with TLS:
 
 **For Omnibus GitLab**
 
-1. On the client nodes, edit `/etc/gitlab/gitlab.rb`:
+1. On the client node(s), edit `/etc/gitlab/gitlab.rb` as follows:
 
    ```ruby
    git_data_dirs({
@@ -399,20 +403,38 @@ To configure Gitaly with TLS:
    gitlab_rails['gitaly_token'] = 'abc123secret'
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
-1. On the Gitaly server nodes, edit `/etc/gitlab/gitlab.rb`:
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) on client node(s).
+1. Create the `/etc/gitlab/ssl` directory and copy your key and certificate there:
+
+   ```sh
+   sudo mkdir -p /etc/gitlab/ssl
+   sudo chmod 700 /etc/gitlab/ssl
+   sudo cp key.pem cert.pem /etc/gitlab/ssl/
+   ```
+
+1. On the Gitaly server node(s), edit `/etc/gitlab/gitlab.rb` and add:
+
+   <!--
+   updates to following example must also be made at
+   https://gitlab.com/gitlab-org/charts/gitlab/blob/master/doc/advanced/external-gitaly/external-omnibus-gitaly.md#configure-omnibus-gitlab
+   -->
 
    ```ruby
    gitaly['tls_listen_addr'] = "0.0.0.0:9999"
-   gitaly['certificate_path'] = "path/to/cert.pem"
-   gitaly['key_path'] = "path/to/key.pem"
+   gitaly['certificate_path'] = "/etc/gitlab/ssl/cert.pem"
+   gitaly['key_path'] = "/etc/gitlab/ssl/key.pem"
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) on Gitaly server node(s).
+1. (Optional) After [verifying that all Gitaly traffic is being served over TLS](#observe-type-of-gitaly-connections),
+   you can improve security by disabling non-TLS connections by commenting out
+   or deleting `gitaly['listen_addr']` in `/etc/gitlab/gitlab.rb`, saving the file,
+   and [reconfiguring GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure)
+   on Gitaly server node(s).
 
 **For installations from source**
 
-1. On the client nodes, edit `/home/git/gitlab/config/gitlab.yml`:
+1. On the client node(s), edit `/home/git/gitlab/config/gitlab.yml` as follows:
 
    ```yaml
    gitlab:
@@ -437,18 +459,33 @@ To configure Gitaly with TLS:
    data will be stored in this folder. This will no longer be necessary after
    [this issue](https://gitlab.com/gitlab-org/gitaly/issues/1282) is resolved.
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
-1. On the Gitaly server nodes, edit `/home/git/gitaly/config.toml`:
+1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) on client node(s).
+1. Create the `/etc/gitlab/ssl` directory and copy your key and certificate there:
+
+   ```sh
+   sudo mkdir -p /etc/gitlab/ssl
+   sudo chmod 700 /etc/gitlab/ssl
+   sudo cp key.pem cert.pem /etc/gitlab/ssl/
+   ```
+
+1. On the Gitaly server node(s), edit `/home/git/gitaly/config.toml` and add:
 
    ```toml
    tls_listen_addr = '0.0.0.0:9999'
 
    [tls]
-   certificate_path = '/path/to/cert.pem'
-   key_path = '/path/to/key.pem'
+   certificate_path = '/etc/gitlab/ssl/cert.pem'
+   key_path = '/etc/gitlab/ssl/key.pem'
    ```
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
+1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) on Gitaly server node(s).
+1. (Optional) After [verifying that all Gitaly traffic is being served over TLS](#observe-type-of-gitaly-connections),
+   you can improve security by disabling non-TLS connections by commenting out
+   or deleting `listen_addr` in `/home/git/gitaly/config.toml`, saving the file,
+   and [restarting GitLab](../restart_gitlab.md#installations-from-source)
+   on Gitaly server node(s).
+
+### Observe type of Gitaly connections
 
 To observe what type of connections are actually being used in a
 production environment you can use the following Prometheus query:
@@ -512,7 +549,7 @@ a few things that you need to do:
 1. Configure [database lookup of SSH keys](../operations/fast_ssh_key_lookup.md)
    to eliminate the need for a shared authorized_keys file.
 1. Configure [object storage for job artifacts](../job_artifacts.md#using-object-storage)
-   including [live tracing](../job_traces.md#new-live-trace-architecture).
+   including [incremental logging](../job_logs.md#new-incremental-logging-architecture).
 1. Configure [object storage for LFS objects](../../workflow/lfs/lfs_administration.md#storing-lfs-objects-in-remote-object-storage).
 1. Configure [object storage for uploads](../uploads.md#using-object-storage-core-only).
 
@@ -564,6 +601,109 @@ concurrency limiter, not a rate limiter. If a client makes 1000 requests
 in a row in a very short timespan, the concurrency will not exceed 1,
 and this mechanism (the concurrency limiter) will do nothing.
 
+## Rotating a Gitaly authentication token
+
+Rotating credentials in a production environment often either requires
+downtime, or causes outages, or both. If you are careful, though, you
+*can* rotate Gitaly credentials without a service interruption.
+
+This procedure also works if you are running GitLab on a single server.
+In that case, "Gitaly servers" and "Gitaly clients" refers to the same
+machine.
+
+### 1. Monitor current authentication behavior
+
+Use Prometheus to see what the current authentication behavior of your
+GitLab installation is.
+
+```
+sum(rate(gitaly_authentications_total[5m])) by (enforced, status)
+```
+
+In a system where authentication is configured correctly, and where you
+have live traffic, you will see something like this:
+
+```
+{enforced="true",status="ok"}  4424.985419441742
+```
+
+There may also be other numbers with rate 0. We only care about the
+non-zero numbers.
+
+The only non-zero number should have `enforced="true",status="ok"`. If
+you have other non-zero numbers, something is wrong in your
+configuration.
+
+The 'status="ok"' number reflects your current request rate. In the example
+above, Gitaly is handling about 4000 requests per second.
+
+Now you have established that you can monitor the Gitaly authentication
+behavior of your GitLab installation.
+
+### 2. Reconfigure all Gitaly servers to be in "auth transitioning" mode
+
+The second step is to temporarily disable authentication on the Gitaly servers.
+
+```ruby
+# in /etc/gitlab/gitlab.rb
+gitaly['auth_transitioning'] = true
+```
+
+After you have applied this, your Prometheus query should return
+something like this:
+
+```
+{enforced="false",status="would be ok"}  4424.985419441742
+```
+
+Because `enforced="false"`, it will be safe to start rolling out the new
+token.
+
+### 3. Update Gitaly token on all clients and servers
+
+```ruby
+# in /etc/gitlab/gitlab.rb
+
+gitaly['auth_token'] = 'my new secret token'
+```
+
+Remember to apply this on both your Gitaly clients *and* servers. If you
+check your Prometheus query while this change is being rolled out, you
+will see non-zero values for the `enforced="false",status="denied"` counter.
+
+### 4. Use Prometheus to ensure there are no authentication failures
+
+After you applied the Gitaly token change everywhere, and all services
+involved have been restarted, you should will temporarily see a mix of
+`status="would be ok"` and `status="denied"`.
+
+After the new token has been picked up by all Gitaly clients and
+servers, the **only non-zero rate** should be
+`enforced="false",status="would be ok"`.
+
+### 5. Disable "auth transitioning" Mode
+
+Now we turn off the 'auth transitioning' mode. These final steps are
+important: without them, you have **no authentication**.
+
+Update the configuration on your Gitaly servers:
+
+```ruby
+# in /etc/gitlab/gitlab.rb
+gitaly['auth_transitioning'] = false
+```
+
+### 6. Verify that authentication is enforced again
+
+Refresh your Prometheus query. You should now see the same kind of
+result as you did in the beginning:
+
+```
+{enforced="true",status="ok"}  4424.985419441742
+```
+
+Note that `enforced="true"`, meaning that authentication is being enforced.
+
 ## Troubleshooting Gitaly
 
 ### `gitaly-debug`
@@ -747,3 +887,8 @@ To remove the proxy setting, run the following commands (depending on which vari
 unset http_proxy
 unset https_proxy
 ```
+
+### Praefect
+
+Praefect is an experimental daemon that allows for replication of the Git data.
+It can be setup with omnibus, [as explained here](./praefect.md).
diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
new file mode 100644
index 00000000000..9038675a28f
--- /dev/null
+++ b/doc/administration/gitaly/praefect.md
@@ -0,0 +1,114 @@
+# Praefect
+
+NOTE: **Note:** Praefect is an experimental service, and for testing purposes only at
+this time.
+
+Praefect is an optional reverse-proxy for [Gitaly](../index.md) to manage a
+cluster of Gitaly nodes for high availability through replication.
+If a Gitaly node becomes unavailable, it will be possible to fail over to a
+warm Gitaly replica.
+
+The first minimal version will support:
+
+- Eventual consistency of the secondary replicas.
+- Manual fail over from the primary to the secondary.
+
+Follow the [HA Gitaly epic](https://gitlab.com/groups/gitlab-org/-/epics/1489)
+for updates and roadmap.
+
+## Omnibus
+
+### Architecture
+
+For this document, the following network topology is assumed:
+
+```mermaid
+graph TB
+  GitLab --> Gitaly;
+  GitLab --> Praefect;
+  Praefect --> Preafect-Git-1;
+  Praefect --> Preafect-Git-2;
+  Praefect --> Preafect-Git-3;
+```
+
+Where `GitLab` is the collection of clients that can request Git operations.
+`Gitaly` is a Gitaly server before using Praefect. The Praefect node has two
+storage nodes attached. Praefect itself doesn't store data, but connects to
+three Gitaly nodes, `Praefect-Git-1`,  `Praefect-Git-2`, and `Praefect-Git-3`.
+There should be no knowledge other than with Praefect about the existence of
+the `Praefect-Git-X` nodes.
+
+### Setup
+
+In this setup guide, the Gitaly node will be added first, then Praefect, and
+lastly we update the GitLab configuration.
+
+#### Gitaly
+
+In their own machine, configure the Gitaly server as described in the
+[gitaly documentation](index.md#3-gitaly-server-configuration).
+
+#### Praefect
+
+Next, Praefect has to be enabled on its own node. Disable all other services,
+and add each Gitaly node that will be connected to Praefect. In the example below,
+the Gitaly nodes are named `praefect-git-X`. Note that one node is designated as
+primary, by setting the primary to `true`:
+
+```ruby
+# /etc/gitlab/gitlab.rb
+
+# Avoid running unnecessary services on the Gitaly server
+postgresql['enable'] = false
+redis['enable'] = false
+nginx['enable'] = false
+prometheus['enable'] = false
+unicorn['enable'] = false
+sidekiq['enable'] = false
+gitlab_workhorse['enable'] = false
+gitaly['enable'] = false
+
+# virtual_storage_name must match the same storage name given to praefect in git_data_dirs
+praefect['virtual_storage_name'] = 'praefect'
+praefect['auth_token'] = 'super_secret_abc'
+praefect['enable'] = true
+praefect['storage_nodes'] = [
+  {
+    'storage' => 'praefect-git-1',
+    'address' => 'tcp://praefect-git-1.internal',
+    'token'   => 'token1',
+    'primary' => true
+  },
+  {
+    'storage' => 'praefect-git-2',
+    'address' => 'tcp://praefect-git-2.internal',
+    'token'   => 'token2'
+  },
+  {
+    'storage' => 'praefect-git-3',
+    'address' => 'tcp://praefect-git-3.internal',
+    'token'   => 'token3'
+  }
+]
+```
+
+Save the file and [reconfigure Praefect](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+
+#### GitLab
+
+When Praefect is running, it should be exposed as a storage to GitLab. This
+is done through setting the `git_data_dirs`. Assuming the default storage
+configuration is used, there would be two storages available to GitLab:
+
+```ruby
+git_data_dirs({
+  "default" => {
+    "gitaly_address" => "tcp://gitaly.internal"
+  },
+  "praefect" => {
+    "gitaly_address" => "tcp://praefect.internal:2305"
+  }
+})
+```
+
+Restart GitLab using `gitlab-ctl restart` on the GitLab node.
diff --git a/doc/administration/gitaly/reference.md b/doc/administration/gitaly/reference.md
index a3bb4f8a509..fe88ef13958 100644
--- a/doc/administration/gitaly/reference.md
+++ b/doc/administration/gitaly/reference.md
@@ -134,7 +134,7 @@ A lot of Gitaly RPCs need to look up Git objects from repositories.
 Most of the time we use `git cat-file --batch` processes for that. For
 better performance, Gitaly can re-use these `git cat-file` processes
 across RPC calls. Previously used processes are kept around in a
-["git cat-file cache"](https://about.gitlab.com/2019/07/08/git-performance-on-nfs/#enter-cat-file-cache).
+["git cat-file cache"](https://about.gitlab.com/blog/2019/07/08/git-performance-on-nfs/#enter-cat-file-cache).
 In order to control how much system resources this uses, we have a maximum number
 of cat-file processes that can go into the cache.
 
diff --git a/doc/administration/high_availability/README.md b/doc/administration/high_availability/README.md
index 0aaf956f169..199944a160c 100644
--- a/doc/administration/high_availability/README.md
+++ b/doc/administration/high_availability/README.md
@@ -25,24 +25,24 @@ solution should balance the costs against the benefits.
 
 There are many options when choosing a highly-available GitLab architecture. We
 recommend engaging with GitLab Support to choose the best architecture for your
-use-case. This page contains some various options and guidelines based on
+use case. This page contains some various options and guidelines based on
 experience with GitLab.com and Enterprise Edition on-premises customers.
 
-For a detailed insight into how GitLab scales and configures GitLab.com, you can
+For detailed insight into how GitLab scales and configures GitLab.com, you can
 watch [this 1 hour Q&A](https://www.youtube.com/watch?v=uCU8jdYzpac)
 with [John Northrup](https://gitlab.com/northrup), and live questions coming in from some of our customers.
 
 ## GitLab Components
 
 The following components need to be considered for a scaled or highly-available
-environment. In many cases components can be combined on the same nodes to reduce
+environment. In many cases, components can be combined on the same nodes to reduce
 complexity.
 
 - Unicorn/Workhorse - Web-requests (UI, API, Git over HTTP)
 - Sidekiq - Asynchronous/Background jobs
 - PostgreSQL - Database
   - Consul - Database service discovery and health checks/failover
-  - PGBouncer - Database pool manager
+  - PgBouncer - Database pool manager
 - Redis - Key/Value store (User sessions, cache, queue for Sidekiq)
   - Sentinel - Redis health check/failover manager
 - Gitaly - Provides high-level RPC access to Git repositories
@@ -57,12 +57,12 @@ infrastructure and maintenance costs of full high availability.
 ### Basic Scaling
 
 This is the simplest form of scaling and will work for the majority of
-cases. Backend components such as PostgreSQL, Redis and storage are offloaded
+cases. Backend components such as PostgreSQL, Redis, and storage are offloaded
 to their own nodes while the remaining GitLab components all run on 2 or more
 application nodes.
 
 This form of scaling also works well in a cloud environment when it is more
-cost-effective to deploy several small nodes rather than a single
+cost effective to deploy several small nodes rather than a single
 larger one.
 
 - 1 PostgreSQL node
@@ -85,11 +85,11 @@ you can continue with the next step.
 
 ### Full Scaling
 
-For very large installations it may be necessary to further split components
-for maximum scalability. In a fully-scaled architecture the application node
+For very large installations, it might be necessary to further split components
+for maximum scalability. In a fully-scaled architecture, the application node
 is split into separate Sidekiq and Unicorn/Workhorse nodes. One indication that
 this architecture is required is if Sidekiq queues begin to periodically increase
-in size, indicating that there is contention or not enough resources.
+in size, indicating that there is contention or there are not enough resources.
 
 - 1 PostgreSQL node
 - 1 Redis node
@@ -100,7 +100,7 @@ in size, indicating that there is contention or not enough resources.
 
 ## High Availability Architecture Examples
 
-When organizations require scaling *and* high availability the following
+When organizations require scaling *and* high availability, the following
 architectures can be utilized. As the introduction section at the top of this
 page mentions, there is a tradeoff between cost/complexity and uptime. Be sure
 this complexity is absolutely required before taking the step into full
@@ -108,11 +108,11 @@ high availability.
 
 For all examples below, we recommend running Consul and Redis Sentinel on
 dedicated nodes. If Consul is running on PostgreSQL nodes or Sentinel on
-Redis nodes there is a potential that high resource usage by PostgreSQL or
+Redis nodes, there is a potential that high resource usage by PostgreSQL or
 Redis could prevent communication between the other Consul and Sentinel nodes.
-This may lead to the other nodes believing a failure has occurred and automated
-failover is necessary. Isolating them from the services they monitor reduces
-the chances of split-brain.
+This may lead to the other nodes believing a failure has occurred and initiating
+automated failover. Isolating Redis and Consul from the services they monitor
+reduces the chances of a false positive that a failure has occurred.
 
 The examples below do not really address high availability of NFS. Some enterprises
 have access to NFS appliances that manage availability. This is the best case
@@ -131,14 +131,14 @@ trade-offs and limits.
 This architecture will work well for many GitLab customers. Larger customers
 may begin to notice certain events cause contention/high load - for example,
 cloning many large repositories with binary files, high API usage, a large
-number of enqueued Sidekiq jobs, etc. If this happens you should consider
+number of enqueued Sidekiq jobs, and so on. If this happens, you should consider
 moving to a hybrid or fully distributed architecture depending on what is causing
 the contention.
 
 - 3 PostgreSQL nodes
 - 2 Redis nodes
 - 3 Consul/Sentinel nodes
-- 2 or more GitLab application nodes (Unicorn, Workhorse, Sidekiq, PGBouncer)
+- 2 or more GitLab application nodes (Unicorn, Workhorse, Sidekiq, PgBouncer)
 - 1 NFS/Gitaly server
 - 1 Monitoring node (Prometheus, Grafana)
 
@@ -162,32 +162,11 @@ contention due to certain workloads.
 
 ![Hybrid architecture diagram](img/hybrid.png)
 
-#### Reference Architecture
-
-- **Supported Users (approximate):** 10,000
-- **Known Issues:** While validating the reference architecture, slow endpoints were discovered and are being investigated. [gitlab-org/gitlab-ce/issues/64335](https://gitlab.com/gitlab-org/gitlab-foss/issues/64335)
-
-The Support and Quality teams built, performance tested, and validated an
-environment that supports about 10,000 users. The specifications below are a
-representation of the work so far. The specifications may be adjusted in the
-future based on additional testing and iteration.
-
-NOTE: **Note:** The specifications here were performance tested against a specific coded workload. Your exact needs may be more, depending on your workload. Your workload is influenced by factors such as - but not limited to - how active your users are, how much automation you use, mirroring, and repo/change size.
-
-- 3 PostgreSQL - 4 CPU, 16GiB memory per node
-- 1 PgBouncer - 2 CPU, 4GiB memory
-- 2 Redis - 2 CPU, 8GiB memory per node
-- 3 Consul/Sentinel - 2 CPU, 2GiB memory per node
-- 4 Sidekiq - 4 CPU, 16GiB memory per node
-- 5 GitLab application nodes - 16 CPU, 64GiB memory per node
-- 1 Gitaly - 16 CPU, 64GiB memory
-- 1 Monitoring node - 2 CPU, 8GiB memory, 100GiB local storage
-
 ### Fully Distributed
 
 This architecture scales to hundreds of thousands of users and projects and is
 the basis of the GitLab.com architecture. While this scales well it also comes
-with the added complexity of many more nodes to configure, manage and monitor.
+with the added complexity of many more nodes to configure, manage, and monitor.
 
 - 3 PostgreSQL nodes
 - 4 or more Redis nodes (2 separate clusters for persistent and cache data)
@@ -214,3 +193,110 @@ separately:
 1. [Configure the GitLab application servers](gitlab.md)
 1. [Configure the load balancers](load_balancer.md)
 1. [Monitoring node (Prometheus and Grafana)](monitoring_node.md)
+
+## Reference Architecture Examples
+
+These reference architecture examples rely on the general rule that approximately 2 requests per second (RPS) of load is generated for every 100 users.
+
+The specifications here were performance tested against a specific coded
+workload. Your exact needs may be more, depending on your workload. Your
+workload is influenced by factors such as - but not limited to - how active your
+users are, how much automation you use, mirroring, and repo/change size.
+
+### 10,000 User Configuration
+
+- **Supported Users (approximate):** 10,000
+- **RPS:** 200 requests per second
+- **Known Issues:** While validating the reference architecture, slow API endpoints
+  were discovered. For details, see the related issues list in
+  [this issue](https://gitlab.com/gitlab-org/gitlab-foss/issues/64335).
+
+The Support and Quality teams built, performance tested, and validated an
+environment that supports about 10,000 users. The specifications below are a
+representation of the work so far. The specifications may be adjusted in the
+future based on additional testing and iteration.
+
+| Service                       | Configuration           | GCP type       |
+| ------------------------------|-------------------------|----------------|
+| 3 GitLab Rails <br> - Puma workers on each node set to 90% of available CPUs with 16 threads | 32 vCPU, 28.8GB Memory | n1-highcpu-32 |
+| 3 PostgreSQL                  | 4 vCPU, 15GB Memory     | n1-standard-4  |
+| 1 PgBouncer                   | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
+| X Gitaly[^1] <br> - Gitaly Ruby workers on each node set to 90% of available CPUs with 16 threads | 16 vCPU, 60GB Memory   | n1-standard-16 |
+| 3 Redis Cache + Sentinel <br> - Cache maxmemory set to 90% of available memory | 4 vCPU, 15GB Memory | n1-standard-4 |
+| 3 Redis Persistent + Sentinel | 4 vCPU, 15GB Memory     | n1-standard-4  |
+| 4 Sidekiq                     | 4 vCPU, 15GB Memory     | n1-standard-4  |
+| 3 Consul                      | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
+| 1 NFS Server                  | 16 vCPU, 14.4GB Memory  | n1-highcpu-16  |
+| 1 Monitoring node             | 4 CPU, 3.6GB Memory     | n1-highcpu-4   |
+| 1 Load Balancing node[^2] .   | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
+
+### 25,000 User Configuration
+
+- **Supported Users (approximate):** 25,000
+- **RPS:** 500 requests per second
+- **Known Issues:** The slow API endpoints that were discovered during testing
+  the 10,000 user architecture also affect the 25,000 user architecture. For
+  details, see the related issues list in
+  [this issue](https://gitlab.com/gitlab-org/gitlab-foss/issues/64335).
+
+The GitLab Support and Quality teams built, performance tested, and validated an
+environment that supports around 25,000 users. The specifications below are a
+representation of the work so far. The specifications may be adjusted in the
+future based on additional testing and iteration.
+
+NOTE: **Note:** The specifications here were performance tested against a
+specific coded workload. Your exact needs may be more, depending on your
+workload. Your workload is influenced by factors such as - but not limited to -
+how active your users are, how much automation you use, mirroring, and
+repo/change size.
+
+| Service                       | Configuration           | GCP type       |
+| ------------------------------|-------------------------|----------------|
+| 7 GitLab Rails <br> - Puma workers on each node set to 90% of available CPUs with 16 threads | 32 vCPU, 28.8GB Memory | n1-highcpu-32 |
+| 3 PostgreSQL                  | 8 vCPU, 30GB Memory     | n1-standard-8  |
+| 1 PgBouncer                   | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
+| X Gitaly[^1] <br> - Gitaly Ruby workers on each node set to 90% of available CPUs with 16 threads | 32 vCPU, 120GB Memory   | n1-standard-32 |
+| 3 Redis Cache + Sentinel <br> - Cache maxmemory set to 90% of available memory | 4 vCPU, 15GB Memory | n1-standard-4 |
+| 3 Redis Persistent + Sentinel | 4 vCPU, 15GB Memory     | n1-standard-4  |
+| 4 Sidekiq                     | 4 vCPU, 15GB Memory     | n1-standard-4  |
+| 3 Consul                      | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
+| 1 NFS Server                  | 16 vCPU, 14.4GB Memory  | n1-highcpu-16  |
+| 1 Monitoring node             | 4 CPU, 3.6GB Memory     | n1-highcpu-4   |
+| 1 Load Balancing node[^2] .   | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
+
+### 50,000 User Configuration
+
+- **Supported Users (approximate):** 50,000
+- **RPS:** 1,000 requests per second
+- **Status:** Work-in-progress
+- **Related Issue:** See the [related issue](https://gitlab.com/gitlab-org/quality/performance/issues/66) for more information.
+
+The Support and Quality teams are in the process of building and performance
+testing an environment that will support around 50,000 users. The specifications
+below are a very rough work-in-progress representation of the work so far. The
+Quality team will be certifying this environment in late 2019. The
+specifications may be adjusted prior to certification based on performance
+testing.
+
+| Service                       | Configuration           | GCP type       |
+| ------------------------------|-------------------------|----------------|
+| 15 GitLab Rails <br> - Puma workers on each node set to 90% of available CPUs with 16 threads | 32 vCPU, 28.8GB Memory | n1-highcpu-32 |
+| 3 PostgreSQL                  | 8 vCPU, 30GB Memory     | n1-standard-8  |
+| 1 PgBouncer                   | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
+| X Gitaly[^1] <br> - Gitaly Ruby workers on each node set to 90% of available CPUs with 16 threads | 64 vCPU, 240GB Memory   | n1-standard-64 |
+| 3 Redis Cache + Sentinel <br> - Cache maxmemory set to 90% of available memory | 4 vCPU, 15GB Memory | n1-standard-4 |
+| 3 Redis Persistent + Sentinel | 4 vCPU, 15GB Memory     | n1-standard-4  |
+| 4 Sidekiq                     | 4 vCPU, 15GB Memory     | n1-standard-4  |
+| 3 Consul                      | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
+| 1 NFS Server                  | 16 vCPU, 14.4GB Memory  | n1-highcpu-16  |
+| 1 Monitoring node             | 4 CPU, 3.6GB Memory     | n1-highcpu-4   |
+| 1 Load Balancing node[^2] .   | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
+
+[^1]: Gitaly node requirements are dependent on customer data. We recommend 2
+      nodes as an absolute minimum for performance at the 10,000 and 25,000 user
+      scale and 4 nodes as an absolute minimum at the 50,000 user scale, but
+      additional nodes should be considered in conjunction with a review of
+      project counts and sizes.
+
+[^2]: HAProxy is the only tested and recommended load balancer. Additional
+      options may be supported in the future.
diff --git a/doc/administration/high_availability/consul.md b/doc/administration/high_availability/consul.md
index b02a61b9256..b01419200cc 100644
--- a/doc/administration/high_availability/consul.md
+++ b/doc/administration/high_availability/consul.md
@@ -6,7 +6,7 @@ type: reference
 
 As part of its High Availability stack, GitLab Premium includes a bundled version of [Consul](https://www.consul.io/) that can be managed through `/etc/gitlab/gitlab.rb`.
 
-A Consul cluster consists of multiple server agents, as well as client agents that run on other nodes which need to talk to the consul cluster.
+A Consul cluster consists of multiple server agents, as well as client agents that run on other nodes which need to talk to the Consul cluster.
 
 ## Prerequisites
 
@@ -96,7 +96,7 @@ Ideally all nodes will have a `Status` of `alive`.
 
 **Note**: This section only applies to server agents. It is safe to restart client agents whenever needed.
 
-If it is necessary to restart the server cluster, it is important to do this in a controlled fashion in order to maintain quorum. If quorum is lost, you will need to follow the consul [outage recovery](#outage-recovery) process to recover the cluster.
+If it is necessary to restart the server cluster, it is important to do this in a controlled fashion in order to maintain quorum. If quorum is lost, you will need to follow the Consul [outage recovery](#outage-recovery) process to recover the cluster.
 
 To be safe, we recommend you only restart one server agent at a time to ensure the cluster remains intact.
 
@@ -129,7 +129,7 @@ To fix this:
 
 1. Run `gitlab-ctl reconfigure`
 
-If you still see the errors, you may have to [erase the consul database and reinitialize](#recreate-from-scratch) on the affected node.
+If you still see the errors, you may have to [erase the Consul database and reinitialize](#recreate-from-scratch) on the affected node.
 
 ### Consul agents do not start - Multiple private IPs
 
@@ -158,11 +158,11 @@ To fix this:
 
 ### Outage recovery
 
-If you lost enough server agents in the cluster to break quorum, then the cluster is considered failed, and it will not function without manual intervenetion.
+If you lost enough server agents in the cluster to break quorum, then the cluster is considered failed, and it will not function without manual intervention.
 
 #### Recreate from scratch
 
-By default, GitLab does not store anything in the consul cluster that cannot be recreated. To erase the consul database and reinitialize
+By default, GitLab does not store anything in the Consul cluster that cannot be recreated. To erase the Consul database and reinitialize
 
 ```
 # gitlab-ctl stop consul
@@ -174,4 +174,4 @@ After this, the cluster should start back up, and the server agents rejoin. Shor
 
 #### Recover a failed cluster
 
-If you have taken advantage of consul to store other data, and want to restore the failed cluster, please follow the [Consul guide](https://www.consul.io/docs/guides/outage.html) to recover a failed cluster.
+If you have taken advantage of Consul to store other data, and want to restore the failed cluster, please follow the [Consul guide](https://learn.hashicorp.com/consul/day-2-operations/outage) to recover a failed cluster.
diff --git a/doc/administration/high_availability/database.md b/doc/administration/high_availability/database.md
index 99582dae57a..a50cc0cbd03 100644
--- a/doc/administration/high_availability/database.md
+++ b/doc/administration/high_availability/database.md
@@ -153,9 +153,9 @@ Database nodes run two services with PostgreSQL:
   - Instructing remaining servers to follow the new master node.
 
   On failure, the old master node is automatically evicted from the cluster, and should be rejoined manually once recovered.
-- Consul. Monitors the status of each node in the database cluster and tracks its health in a service definition on the consul cluster.
+- Consul. Monitors the status of each node in the database cluster and tracks its health in a service definition on the Consul cluster.
 
-Alongside pgbouncer, there is a consul agent that watches the status of the PostgreSQL service. If that status changes, consul runs a script which updates the configuration and reloads pgbouncer
+Alongside PgBouncer, there is a Consul agent that watches the status of the PostgreSQL service. If that status changes, Consul runs a script which updates the configuration and reloads PgBouncer
 
 ##### Connection flow
 
@@ -198,7 +198,7 @@ When using default setup, minimum configuration requires:
 
 - `CONSUL_USERNAME`. Defaults to `gitlab-consul`
 - `CONSUL_DATABASE_PASSWORD`. Password for the database user.
-- `CONSUL_PASSWORD_HASH`. This is a hash generated out of consul username/password pair.
+- `CONSUL_PASSWORD_HASH`. This is a hash generated out of Consul username/password pair.
    Can be generated with:
 
    ```sh
@@ -248,26 +248,26 @@ We will need the following password information for the application's database u
   sudo gitlab-ctl pg-password-md5 POSTGRESQL_USERNAME
   ```
 
-##### Pgbouncer information
+##### PgBouncer information
 
 When using default setup, minimum configuration requires:
 
 - `PGBOUNCER_USERNAME`. Defaults to `pgbouncer`
-- `PGBOUNCER_PASSWORD`. This is a password for pgbouncer service.
-- `PGBOUNCER_PASSWORD_HASH`. This is a hash generated out of pgbouncer username/password pair.
+- `PGBOUNCER_PASSWORD`. This is a password for PgBouncer service.
+- `PGBOUNCER_PASSWORD_HASH`. This is a hash generated out of PgBouncer username/password pair.
   Can be generated with:
 
   ```sh
   sudo gitlab-ctl pg-password-md5 PGBOUNCER_USERNAME
   ```
 
-- `PGBOUNCER_NODE`, is the IP address or a FQDN of the node running Pgbouncer.
+- `PGBOUNCER_NODE`, is the IP address or a FQDN of the node running PgBouncer.
 
 Few notes on the service itself:
 
 - The service runs as the same system account as the database
   - In the package, this is by default `gitlab-psql`
-- If you use a non-default user account for Pgbouncer service (by default `pgbouncer`), you will have to specify this username. We will refer to this requirement with `PGBOUNCER_USERNAME`.
+- If you use a non-default user account for PgBouncer service (by default `pgbouncer`), you will have to specify this username. We will refer to this requirement with `PGBOUNCER_USERNAME`.
 - The service will have a regular database user account generated for it
   - This defaults to `repmgr`
 - Passwords will be stored in the following locations:
@@ -315,7 +315,7 @@ When installing the GitLab package, do not supply `EXTERNAL_URL` value.
    # Disable automatic database migrations
    gitlab_rails['auto_migrate'] = false
 
-   # Configure the consul agent
+   # Configure the Consul agent
    consul['services'] = %w(postgresql)
 
    # START user configuration
@@ -348,7 +348,7 @@ When installing the GitLab package, do not supply `EXTERNAL_URL` value.
 
 1. On secondary nodes, add all the configuration specified above for primary node
    to `/etc/gitlab/gitlab.rb`. In addition, append the following configuration
-   to inform gitlab-ctl that they are standby nodes initially and it need not
+   to inform `gitlab-ctl` that they are standby nodes initially and it need not
    attempt to register them as primary node
 
    ```
@@ -363,7 +363,7 @@ When installing the GitLab package, do not supply `EXTERNAL_URL` value.
 >
 > - If you want your database to listen on a specific interface, change the config:
 >   `postgresql['listen_address'] = '0.0.0.0'`.
-> - If your Pgbouncer service runs under a different user account,
+> - If your PgBouncer service runs under a different user account,
 >   you also need to specify: `postgresql['pgbouncer_user'] = PGBOUNCER_USERNAME` in
 >   your configuration.
 
@@ -484,9 +484,9 @@ or secondary. The most important thing here is that this command does not produc
 If there are errors it's most likely due to incorrect `gitlab-consul` database user permissions.
 Check the [Troubleshooting section](#troubleshooting) before proceeding.
 
-#### Configuring the Pgbouncer node
+#### Configuring the PgBouncer node
 
-See our [documentation for Pgbouncer](pgbouncer.md) for information on running Pgbouncer as part of an HA setup.
+See our [documentation for PgBouncer](pgbouncer.md) for information on running PgBouncer as part of an HA setup.
 
 #### Configuring the Application nodes
 
@@ -515,10 +515,10 @@ Ensure that all migrations ran:
 gitlab-rake gitlab:db:configure
 ```
 
-> **Note**: If you encounter a `rake aborted!` error stating that PGBouncer is failing to connect to
-PostgreSQL it may be that your PGBouncer node's IP address is missing from
+> **Note**: If you encounter a `rake aborted!` error stating that PgBouncer is failing to connect to
+PostgreSQL it may be that your PgBouncer node's IP address is missing from
 PostgreSQL's `trust_auth_cidr_addresses` in `gitlab.rb` on your database nodes. See
-[PGBouncer error `ERROR:  pgbouncer cannot connect to server`](#pgbouncer-error-error-pgbouncer-cannot-connect-to-server)
+[PgBouncer error `ERROR:  pgbouncer cannot connect to server`](#pgbouncer-error-error-pgbouncer-cannot-connect-to-server)
 in the Troubleshooting section before proceeding.
 
 ##### Ensure GitLab is running
@@ -533,7 +533,7 @@ Here we'll show you some fully expanded example configurations.
 
 ##### Example recommended setup
 
-This example uses 3 consul servers, 3 postgresql servers, and 1 application node.
+This example uses 3 Consul servers, 3 PostgreSQL servers, and 1 application node.
 
 We start with all servers on the same 10.6.0.0/16 private network range, they
 can connect to each freely other on those addresses.
@@ -589,7 +589,7 @@ postgresql['shared_preload_libraries'] = 'repmgr_funcs'
 # Disable automatic database migrations
 gitlab_rails['auto_migrate'] = false
 
-# Configure the consul agent
+# Configure the Consul agent
 consul['services'] = %w(postgresql)
 
 postgresql['pgbouncer_user_password'] = '771a8625958a529132abe6f1a4acb19c'
@@ -635,7 +635,7 @@ postgresql['enable'] = false
 pgbouncer['enable'] = true
 consul['enable'] = true
 
-# Configure Pgbouncer
+# Configure PgBouncer
 pgbouncer['admin_users'] = %w(pgbouncer gitlab-consul)
 
 # Configure Consul agent
@@ -691,7 +691,7 @@ After deploying the configuration follow these steps:
 
 1. On `10.6.0.31`, our application server
 
-   Set gitlab-consul's pgbouncer password to `toomanysecrets`
+   Set `gitlab-consul` user's PgBouncer password to `toomanysecrets`
 
    ```sh
    gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
@@ -705,10 +705,10 @@ After deploying the configuration follow these steps:
 
 #### Example minimal setup
 
-This example uses 3 postgresql servers, and 1 application node.
+This example uses 3 PostgreSQL servers, and 1 application node.
 
-It differs from the [recommended setup](#example-recommended-setup) by moving the consul servers into the same servers we use for PostgreSQL.
-The trade-off is between reducing server counts, against the increased operational complexity of needing to deal with postgres [failover](#failover-procedure) and [restore](#restore-procedure) procedures in addition to [consul outage recovery](consul.md#outage-recovery) on the same set of machines.
+It differs from the [recommended setup](#example-recommended-setup) by moving the Consul servers into the same servers we use for PostgreSQL.
+The trade-off is between reducing server counts, against the increased operational complexity of needing to deal with PostgreSQL [failover](#failover-procedure) and [restore](#restore-procedure) procedures in addition to [Consul outage recovery](consul.md#outage-recovery) on the same set of machines.
 
 In this example we start with all servers on the same 10.6.0.0/16 private network range, they can connect to each freely other on those addresses.
 
@@ -744,7 +744,7 @@ postgresql['shared_preload_libraries'] = 'repmgr_funcs'
 # Disable automatic database migrations
 gitlab_rails['auto_migrate'] = false
 
-# Configure the consul agent
+# Configure the Consul agent
 consul['services'] = %w(postgresql)
 
 postgresql['pgbouncer_user_password'] = '771a8625958a529132abe6f1a4acb19c'
@@ -788,7 +788,7 @@ postgresql['enable'] = false
 pgbouncer['enable'] = true
 consul['enable'] = true
 
-# Configure Pgbouncer
+# Configure PgBouncer
 pgbouncer['admin_users'] = %w(pgbouncer gitlab-consul)
 
 # Configure Consul agent
@@ -817,7 +817,7 @@ The manual steps for this configuration are the same as for the [example recomme
 #### Failover procedure
 
 By default, if the master database fails, `repmgrd` should promote one of the
-standby nodes to master automatically, and consul will update pgbouncer with
+standby nodes to master automatically, and Consul will update PgBouncer with
 the new master.
 
 If you need to failover manually, you have two options:
@@ -907,7 +907,7 @@ can require md5 authentication.
 
 ##### Trust specific addresses
 
-If you know the IP address, or FQDN of all database and pgbouncer nodes in the
+If you know the IP address, or FQDN of all database and PgBouncer nodes in the
 cluster, you can trust only those nodes.
 
 In `/etc/gitlab/gitlab.rb` on all of the database nodes, set
@@ -926,7 +926,7 @@ repmgr['trust_auth_cidr_addresses'] = %w(192.168.1.44/32 db2.example.com)
 ##### MD5 Authentication
 
 If you are running on an untrusted network, repmgr can use md5 authentication
-with a [.pgpass file](https://www.postgresql.org/docs/9.6/static/libpq-pgpass.html)
+with a [.pgpass file](https://www.postgresql.org/docs/9.6/libpq-pgpass.html)
 to authenticate.
 
 You can specify by IP address, FQDN, or by subnet, using the same format as in
@@ -950,7 +950,7 @@ the previous section:
       1. Set `postgresql['md5_auth_cidr_addresses']` to the desired value
       1. Set `postgresql['sql_replication_user'] = 'gitlab_repmgr'`
       1. Reconfigure with `gitlab-ctl reconfigure`
-      1. Restart postgresql with `gitlab-ctl restart postgresql`
+      1. Restart PostgreSQL with `gitlab-ctl restart postgresql`
 
    1. Create a `.pgpass` file. Enter the `gitlab_repmgr` password twice to
       when asked:
@@ -959,7 +959,7 @@ the previous section:
       gitlab-ctl write-pgpass --user gitlab_repmgr --hostuser gitlab-psql --database '*'
       ```
 
-1. On each pgbouncer node, edit `/etc/gitlab/gitlab.rb`:
+1. On each PgBouncer node, edit `/etc/gitlab/gitlab.rb`:
    1. Ensure `gitlab_rails['db_password']` is set to the plaintext password for
       the `gitlab` database user
    1. [Reconfigure GitLab] for the changes to take effect
@@ -993,7 +993,7 @@ To restart either service, run `gitlab-ctl restart SERVICE`
 
 For PostgreSQL, it is usually safe to restart the master node by default. Automatic failover defaults to a 1 minute timeout. Provided the database returns before then, nothing else needs to be done. To be safe, you can stop `repmgrd` on the standby nodes first with `gitlab-ctl stop repmgrd`, then start afterwards with `gitlab-ctl start repmgrd`.
 
-On the consul server nodes, it is important to restart the consul service in a controlled fashion. Read our [consul documentation](consul.md#restarting-the-server-cluster) for instructions on how to restart the service.
+On the Consul server nodes, it is important to restart the Consul service in a controlled fashion. Read our [Consul documentation](consul.md#restarting-the-server-cluster) for instructions on how to restart the service.
 
 ### `gitlab-ctl repmgr-check-master` command produces errors
 
@@ -1010,16 +1010,16 @@ steps to fix the problem:
 
 Now there should not be errors. If errors still occur then there is another problem.
 
-### PGBouncer error `ERROR: pgbouncer cannot connect to server`
+### PgBouncer error `ERROR: pgbouncer cannot connect to server`
 
 You may get this error when running `gitlab-rake gitlab:db:configure` or you
-may see the error in the PGBouncer log file.
+may see the error in the PgBouncer log file.
 
 ```
 PG::ConnectionBad: ERROR:  pgbouncer cannot connect to server
 ```
 
-The problem may be that your PGBouncer node's IP address is not included in the
+The problem may be that your PgBouncer node's IP address is not included in the
 `trust_auth_cidr_addresses` setting in `/etc/gitlab/gitlab.rb` on the database nodes.
 
 You can confirm that this is the issue by checking the PostgreSQL log on the master
@@ -1049,7 +1049,7 @@ If you're running into an issue with a component not outlined here, be sure to c
 ## Configure using Omnibus
 
 **Note**: We recommend that you follow the instructions here for a full [PostgreSQL cluster](#high-availability-with-gitlab-omnibus-premium-only).
-If you are reading this section due to an old bookmark, you can find that old documentation [in the repository](https://gitlab.com/gitlab-org/gitlab-foss/blob/v10.1.4/doc/administration/high_availability/database.md#configure-using-omnibus).
+If you are reading this section due to an old bookmark, you can find that old documentation [in the repository](https://gitlab.com/gitlab-org/gitlab/blob/v10.1.4/doc/administration/high_availability/database.md#configure-using-omnibus).
 
 Read more on high-availability configuration:
 
diff --git a/doc/administration/high_availability/gitlab.md b/doc/administration/high_availability/gitlab.md
index 0d1dd06871a..71ab169a801 100644
--- a/doc/administration/high_availability/gitlab.md
+++ b/doc/administration/high_availability/gitlab.md
@@ -40,7 +40,7 @@ these additional steps before proceeding with GitLab installation.
    ```
 
 1. Download/install GitLab Omnibus using **steps 1 and 2** from
-   [GitLab downloads](https://about.gitlab.com/downloads). Do not complete other
+   [GitLab downloads](https://about.gitlab.com/install/). Do not complete other
    steps on the download page.
 1. Create/edit `/etc/gitlab/gitlab.rb` and use the following configuration.
    Be sure to change the `external_url` to match your eventual GitLab front-end
@@ -90,8 +90,8 @@ these additional steps before proceeding with GitLab installation.
 
    NOTE: **Note:** When you specify `https` in the `external_url`, as in the example
    above, GitLab assumes you have SSL certificates in `/etc/gitlab/ssl/`. If
-   certificates are not present, Nginx will fail to start. See
-   [Nginx documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
+   certificates are not present, NGINX will fail to start. See
+   [NGINX documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
    for more information.
 
    NOTE: **Note:** It is best to set the `uid` and `gid`s prior to the initial reconfigure
@@ -99,14 +99,14 @@ these additional steps before proceeding with GitLab installation.
 
 ## First GitLab application server
 
-As a final step, run the setup rake task **only on** the first GitLab application server.
-Do not run this on additional application servers.
+On the first application server, run:
 
-1. Initialize the database by running `sudo gitlab-rake gitlab:setup`.
-1. Run `sudo gitlab-ctl reconfigure` to compile the configuration.
+```sh
+sudo gitlab-ctl reconfigure
+```
 
-   CAUTION: **WARNING:** Only run this setup task on **NEW** GitLab instances because it
-   will wipe any existing data.
+This should compile the configuration and initialize the database. Do
+not run this on additional application servers until the next step.
 
 ## Extra configuration for additional GitLab application servers
 
@@ -175,7 +175,7 @@ If you enable Monitoring, it must be enabled on **all** GitLab servers.
 
    CAUTION: **Warning:**
    After changing `unicorn['listen']` in `gitlab.rb`, and running `sudo gitlab-ctl reconfigure`,
-   it can take an extended period of time for unicorn to complete reloading after receiving a `HUP`.
+   it can take an extended period of time for Unicorn to complete reloading after receiving a `HUP`.
    For more information, see the [issue](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4401).
 
 ## Troubleshooting
diff --git a/doc/administration/high_availability/load_balancer.md b/doc/administration/high_availability/load_balancer.md
index f11d27487d1..43a7c442d8c 100644
--- a/doc/administration/high_availability/load_balancer.md
+++ b/doc/administration/high_availability/load_balancer.md
@@ -27,10 +27,10 @@ options:
 
 Configure your load balancer(s) to pass connections on port 443 as 'TCP' rather
 than 'HTTP(S)' protocol. This will pass the connection to the application nodes
-Nginx service untouched. Nginx will have the SSL certificate and listen on port 443.
+NGINX service untouched. NGINX will have the SSL certificate and listen on port 443.
 
-See [Nginx HTTPS documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
-for details on managing SSL certificates and configuring Nginx.
+See [NGINX HTTPS documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
+for details on managing SSL certificates and configuring NGINX.
 
 ### Load Balancer(s) terminate SSL without backend SSL
 
@@ -40,7 +40,7 @@ terminating SSL.
 
 Since communication between the load balancer(s) and GitLab will not be secure,
 there is some additional configuration needed. See
-[Nginx Proxied SSL documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#supporting-proxied-ssl)
+[NGINX Proxied SSL documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#supporting-proxied-ssl)
 for details.
 
 ### Load Balancer(s) terminate SSL with backend SSL
@@ -49,12 +49,12 @@ Configure your load balancer(s) to use the 'HTTP(S)' protocol rather than 'TCP'.
 The load balancer(s) will be responsible for managing SSL certificates that
 end users will see.
 
-Traffic will also be secure between the load balancer(s) and Nginx in this
+Traffic will also be secure between the load balancer(s) and NGINX in this
 scenario. There is no need to add configuration for proxied SSL since the
 connection will be secure all the way. However, configuration will need to be
 added to GitLab to configure SSL certificates. See
-[Nginx HTTPS documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
-for details on managing SSL certificates and configuring Nginx.
+[NGINX HTTPS documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
+for details on managing SSL certificates and configuring NGINX.
 
 ## Ports
 
diff --git a/doc/administration/high_availability/monitoring_node.md b/doc/administration/high_availability/monitoring_node.md
index 0b04e48f74a..d293fc350fa 100644
--- a/doc/administration/high_availability/monitoring_node.md
+++ b/doc/administration/high_availability/monitoring_node.md
@@ -34,6 +34,9 @@ Omnibus:
    prometheus['listen_address'] = '0.0.0.0:9090'
    prometheus['monitor_kubernetes'] = false
 
+   # Enable Login form
+   grafana['disable_login_form'] = false
+
    # Enable Grafana
    grafana['enable'] = true
    grafana['admin_password'] = 'toomanysecrets'
@@ -63,6 +66,7 @@ Omnibus:
    sidekiq['enable'] = false
    unicorn['enable'] = false
    node_exporter['enable'] = false
+   gitlab_exporter['enable'] = false
    ```
 
 1. Run `sudo gitlab-ctl reconfigure` to compile the configuration.
diff --git a/doc/administration/high_availability/nfs.md b/doc/administration/high_availability/nfs.md
index 987db3c89a5..f7c5593e211 100644
--- a/doc/administration/high_availability/nfs.md
+++ b/doc/administration/high_availability/nfs.md
@@ -103,13 +103,12 @@ If you do choose to use EFS, avoid storing GitLab log files (e.g. those in `/var
 there because this will also affect performance. We recommend that the log files be
 stored on a local volume.
 
-For more details on another person's experience with EFS, see
-[Amazon's Elastic File System: Burst Credits](https://rawkode.com/2017/04/16/amazons-elastic-file-system-burst-credits/)
+For more details on another person's experience with EFS, see this [Commit Brooklyn 2019 video](https://youtu.be/K6OS8WodRBQ?t=313).
 
 ## Avoid using CephFS and GlusterFS
 
 GitLab strongly recommends against using CephFS and GlusterFS.
-These distributed file systems are not well-suited for GitLab's input/output access patterns because git uses many small files and access times and file locking times to propagate will make git activity very slow.
+These distributed file systems are not well-suited for GitLab's input/output access patterns because Git uses many small files and access times and file locking times to propagate will make Git activity very slow.
 
 ## Avoid using PostgreSQL with NFS
 
@@ -118,7 +117,7 @@ across NFS. The GitLab support team will not be able to assist on performance is
 this configuration.
 
 Additionally, this configuration is specifically warned against in the
-[Postgres Documentation](https://www.postgresql.org/docs/current/static/creating-cluster.html#CREATING-CLUSTER-NFS):
+[Postgres Documentation](https://www.postgresql.org/docs/current/creating-cluster.html#CREATING-CLUSTER-NFS):
 
 >PostgreSQL does nothing special for NFS file systems, meaning it assumes NFS behaves exactly like
 >locally-connected drives. If the client or server NFS implementation does not provide standard file
@@ -147,7 +146,7 @@ Note there are several options that you should consider using:
 
 ## A single NFS mount
 
-It's recommended to nest all gitlab data dirs within a mount, that allows automatic
+It's recommended to nest all GitLab data dirs within a mount, that allows automatic
 restore of backups without manually moving existing data.
 
 ```
diff --git a/doc/administration/high_availability/nfs_host_client_setup.md b/doc/administration/high_availability/nfs_host_client_setup.md
index 9b0e085fe25..5b6b28bf633 100644
--- a/doc/administration/high_availability/nfs_host_client_setup.md
+++ b/doc/administration/high_availability/nfs_host_client_setup.md
@@ -11,7 +11,7 @@ setup act as clients while the NFS server plays host.
 > Note: The instructions provided in this documentation allow for setting a quick
 proof of concept but will leave NFS as potential single point of failure and
 therefore not recommended for use in production. Explore options such as [Pacemaker
-and Corosync](http://clusterlabs.org/) for highly available NFS in production.
+and Corosync](https://clusterlabs.org) for highly available NFS in production.
 
 Below are instructions for setting up an application node(client) in an HA cluster
 to read from and write to a central NFS server(host).
@@ -56,7 +56,7 @@ You may need to update your server's firewall. See the [firewall section](#nfs-i
 
 ## Client/ GitLab application node Setup
 
-> Follow the instructions below to connect any GitLab rails application node running
+> Follow the instructions below to connect any GitLab Rails application node running
 inside your HA environment to the NFS server configured above.
 
 ### Step 1 - Install NFS Common on Client
@@ -108,7 +108,7 @@ When using the default Omnibus configuration you will need to share 5 data locat
 between all GitLab cluster nodes. No other locations should be shared. Changing the
 default file locations in `gitlab.rb` on the client allows you to have one main mount
 point and have all the required locations as subdirectories to use the NFS mount for
-git-data.
+`git-data`.
 
 ```text
 git_data_dirs({"default" => {"path" => "/nfs/home/var/opt/gitlab-data/git-data"}})
diff --git a/doc/administration/high_availability/pgbouncer.md b/doc/administration/high_availability/pgbouncer.md
index b99724d12a2..e7479ad1ecb 100644
--- a/doc/administration/high_availability/pgbouncer.md
+++ b/doc/administration/high_availability/pgbouncer.md
@@ -2,29 +2,29 @@
 type: reference
 ---
 
-# Working with the bundle Pgbouncer service
+# Working with the bundle PgBouncer service
 
-As part of its High Availability stack, GitLab Premium includes a bundled version of [Pgbouncer](https://pgbouncer.github.io/) that can be managed through `/etc/gitlab/gitlab.rb`.
+As part of its High Availability stack, GitLab Premium includes a bundled version of [PgBouncer](https://pgbouncer.github.io/) that can be managed through `/etc/gitlab/gitlab.rb`.
 
-In a High Availability setup, Pgbouncer is used to seamlessly migrate database connections between servers in a failover scenario.
+In a High Availability setup, PgBouncer is used to seamlessly migrate database connections between servers in a failover scenario.
 
 Additionally, it can be used in a non-HA setup to pool connections, speeding up response time while reducing resource usage.
 
-It is recommended to run pgbouncer alongside the `gitlab-rails` service, or on its own dedicated node in a cluster.
+It is recommended to run PgBouncer alongside the `gitlab-rails` service, or on its own dedicated node in a cluster.
 
 ## Operations
 
-### Running Pgbouncer as part of an HA GitLab installation
+### Running PgBouncer as part of an HA GitLab installation
 
 1. Make sure you collect [`CONSUL_SERVER_NODES`](database.md#consul-information), [`CONSUL_PASSWORD_HASH`](database.md#consul-information), and [`PGBOUNCER_PASSWORD_HASH`](database.md#pgbouncer-information) before executing the next step.
 
 1. Edit `/etc/gitlab/gitlab.rb` replacing values noted in the `# START user configuration` section:
 
    ```ruby
-   # Disable all components except Pgbouncer and Consul agent
+   # Disable all components except PgBouncer and Consul agent
    roles ['pgbouncer_role']
 
-   # Configure Pgbouncer
+   # Configure PgBouncer
    pgbouncer['admin_users'] = %w(pgbouncer gitlab-consul)
 
    # Configure Consul agent
@@ -59,13 +59,13 @@ It is recommended to run pgbouncer alongside the `gitlab-rails` service, or on i
 1. Run `gitlab-ctl reconfigure`
 
 1. Create a `.pgpass` file so Consul is able to
-   reload pgbouncer. Enter the `PGBOUNCER_PASSWORD` twice when asked:
+   reload PgBouncer. Enter the `PGBOUNCER_PASSWORD` twice when asked:
 
    ```sh
    gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
    ```
 
-#### PGBouncer Checkpoint
+#### PgBouncer Checkpoint
 
 1. Ensure the node is talking to the current master:
 
@@ -100,7 +100,7 @@ It is recommended to run pgbouncer alongside the `gitlab-rails` service, or on i
    (2 rows)
    ```
 
-### Running Pgbouncer as part of a non-HA GitLab installation
+### Running PgBouncer as part of a non-HA GitLab installation
 
 1. Generate PGBOUNCER_USER_PASSWORD_HASH with the command `gitlab-ctl pg-password-md5 pgbouncer`
 
@@ -119,7 +119,7 @@ It is recommended to run pgbouncer alongside the `gitlab-rails` service, or on i
 
    **Note:** If the database was already running, it will need to be restarted after reconfigure by running `gitlab-ctl restart postgresql`.
 
-1. On the node you are running pgbouncer on, make sure the following is set in `/etc/gitlab/gitlab.rb`
+1. On the node you are running PgBouncer on, make sure the following is set in `/etc/gitlab/gitlab.rb`
 
    ```ruby
    pgbouncer['enable'] = true
@@ -134,7 +134,7 @@ It is recommended to run pgbouncer alongside the `gitlab-rails` service, or on i
 
 1. Run `gitlab-ctl reconfigure`
 
-1. On the node running unicorn, make sure the following is set in `/etc/gitlab/gitlab.rb`
+1. On the node running Unicorn, make sure the following is set in `/etc/gitlab/gitlab.rb`
 
    ```ruby
    gitlab_rails['db_host'] = 'PGBOUNCER_HOST'
@@ -144,13 +144,13 @@ It is recommended to run pgbouncer alongside the `gitlab-rails` service, or on i
 
 1. Run `gitlab-ctl reconfigure`
 
-1. At this point, your instance should connect to the database through pgbouncer. If you are having issues, see the [Troubleshooting](#troubleshooting) section
+1. At this point, your instance should connect to the database through PgBouncer. If you are having issues, see the [Troubleshooting](#troubleshooting) section
 
 ## Enable Monitoring
 
 > [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3786) in GitLab 12.0.
 
-If you enable Monitoring, it must be enabled on **all** pgbouncer servers.
+If you enable Monitoring, it must be enabled on **all** PgBouncer servers.
 
 1. Create/edit `/etc/gitlab/gitlab.rb` and add the following configuration:
 
@@ -173,11 +173,11 @@ If you enable Monitoring, it must be enabled on **all** pgbouncer servers.
 
 1. Run `sudo gitlab-ctl reconfigure` to compile the configuration.
 
-### Interacting with pgbouncer
+### Interacting with PgBouncer
 
 #### Administrative console
 
-As part of omnibus-gitlab, we provide a command `gitlab-ctl pgb-console` to automatically connect to the pgbouncer administrative console. Please see the [pgbouncer documentation](https://pgbouncer.github.io/usage.html#admin-console) for detailed instructions on how to interact with the console.
+As part of Omnibus GitLab, we provide a command `gitlab-ctl pgb-console` to automatically connect to the PgBouncer administrative console. Please see the [PgBouncer documentation](https://pgbouncer.github.io/usage.html#admin-console) for detailed instructions on how to interact with the console.
 
 To start a session, run
 
@@ -235,7 +235,7 @@ ote_pid | tls
 
 ## Troubleshooting
 
-In case you are experiencing any issues connecting through pgbouncer, the first place to check is always the logs:
+In case you are experiencing any issues connecting through PgBouncer, the first place to check is always the logs:
 
 ```shell
 # gitlab-ctl tail pgbouncer
diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md
index aa616ec91d8..ba4599e5bcd 100644
--- a/doc/administration/high_availability/redis.md
+++ b/doc/administration/high_availability/redis.md
@@ -68,7 +68,7 @@ Omnibus:
    gitaly['enable'] = false
 
    redis['bind'] = '0.0.0.0'
-   redis['port'] = '6379'
+   redis['port'] = 6379
    redis['password'] = 'SECRET_PASSWORD_HERE'
 
    gitlab_rails['auto_migrate'] = false
@@ -313,12 +313,12 @@ Pick the one that suits your needs.
 - [Installations from source][source]: You need to install Redis and Sentinel
   yourself. Use the [Redis HA installation from source](redis_source.md)
   documentation.
-- [Omnibus GitLab **Community Edition** (CE) package][ce]: Redis is bundled, so you
+- [Omnibus GitLab **Community Edition** (CE) package](https://about.gitlab.com/install/?version=ce): Redis is bundled, so you
   can use the package with only the Redis service enabled as described in steps
   1 and 2 of this document (works for both master and slave setups). To install
   and configure Sentinel, jump directly to the Sentinel section in the
   [Redis HA installation from source](redis_source.md#step-3-configuring-the-redis-sentinel-instances) documentation.
-- [Omnibus GitLab **Enterprise Edition** (EE) package][ee]: Both Redis and Sentinel
+- [Omnibus GitLab **Enterprise Edition** (EE) package](https://about.gitlab.com/install/?version=ee): Both Redis and Sentinel
   are bundled in the package, so you can use the EE package to set up the whole
   Redis HA infrastructure (master, slave and Sentinel) which is described in
   this document.
@@ -397,7 +397,7 @@ The prerequisites for a HA Redis setup are the following:
 
 1. [Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect.
 
-> Note: You can specify multiple roles like sentinel and redis as:
+> Note: You can specify multiple roles like sentinel and Redis as:
 > `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about high
 > availability roles at <https://docs.gitlab.com/omnibus/roles/>.
 
@@ -446,7 +446,7 @@ The prerequisites for a HA Redis setup are the following:
 1. [Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect.
 1. Go through the steps again for all the other slave nodes.
 
-> Note: You can specify multiple roles like sentinel and redis as:
+> Note: You can specify multiple roles like sentinel and Redis as:
 > `roles ['redis_sentinel_role', 'redis_slave_role']`. Read more about high
 > availability roles at <https://docs.gitlab.com/omnibus/roles/>.
 
@@ -628,7 +628,7 @@ single-machine install, to rotate the **Master** to one of the new nodes.
 
 Make the required changes in configuration and restart the new nodes again.
 
-To disable redis in the single install, edit `/etc/gitlab/gitlab.rb`:
+To disable Redis in the single install, edit `/etc/gitlab/gitlab.rb`:
 
 ```ruby
 redis['enable'] = false
@@ -902,7 +902,7 @@ You can check if everything is correct by connecting to each server using
 /opt/gitlab/embedded/bin/redis-cli -h <redis-host-or-ip> -a '<redis-password>' info replication
 ```
 
-When connected to a `master` redis, you will see the number of connected
+When connected to a `master` Redis, you will see the number of connected
 `slaves`, and a list of each with connection details:
 
 ```
@@ -948,7 +948,7 @@ to [this issue][gh-531].
 You must make sure you are defining the same value in `redis['master_name']`
 and `redis['master_pasword']` as you defined for your sentinel node.
 
-The way the redis connector `redis-rb` works with sentinel is a bit
+The way the Redis connector `redis-rb` works with sentinel is a bit
 non-intuitive. We try to hide the complexity in omnibus, but it still requires
 a few extra configs.
 
@@ -1025,6 +1025,4 @@ Read more on High Availability:
 [sentinel]: https://redis.io/topics/sentinel
 [omnifile]: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/libraries/gitlab_rails.rb
 [source]: ../../install/installation.md
-[ce]: https://about.gitlab.com/downloads
-[ee]: https://about.gitlab.com/downloads-ee
 [it]: https://gitlab.com/gitlab-org/gitlab-foss/uploads/c4cc8cd353604bd80315f9384035ff9e/The_Internet_IT_Crowd.png
diff --git a/doc/administration/high_availability/redis_source.md b/doc/administration/high_availability/redis_source.md
index 0758b240a25..9ab9d9a206d 100644
--- a/doc/administration/high_availability/redis_source.md
+++ b/doc/administration/high_availability/redis_source.md
@@ -341,7 +341,7 @@ to [this upstream issue][gh-531].
 You must make sure that `resque.yml` and `sentinel.conf` are configured correctly,
 otherwise `redis-rb` will not work properly.
 
-The `master-group-name` ('gitlab-redis') defined in (`sentinel.conf`)
+The `master-group-name` (`gitlab-redis`) defined in (`sentinel.conf`)
 **must** be used as the hostname in GitLab (`resque.yml`):
 
 ```conf
@@ -374,4 +374,4 @@ When in doubt, please read [Redis Sentinel documentation](https://redis.io/topic
 [downloads]: https://about.gitlab.com/downloads
 [restart]: ../restart_gitlab.md#installations-from-source
 [it]: https://gitlab.com/gitlab-org/gitlab-foss/uploads/c4cc8cd353604bd80315f9384035ff9e/The_Internet_IT_Crowd.png
-[resque]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/config/resque.yml.example
+[resque]: https://gitlab.com/gitlab-org/gitlab/blob/master/config/resque.yml.example
diff --git a/doc/administration/housekeeping.md b/doc/administration/housekeeping.md
index 43c9679be65..9083619841e 100644
--- a/doc/administration/housekeeping.md
+++ b/doc/administration/housekeeping.md
@@ -1,6 +1,6 @@
 # Housekeeping
 
-> [Introduced][ce-2371] in GitLab 8.4.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/3041) in GitLab 8.4.
 
 ## Automatic housekeeping
 
@@ -23,16 +23,12 @@ For example in the following scenario a `git repack -d` will be executed:
 When the `pushes_since_gc` value is 50 a `repack -A -d --pack-kept-objects` will run, similarly when
 the `pushes_since_gc` value is 200 a `git gc` will be run.
 
-- `git gc` ([man page][man-gc]) runs a number of housekeeping tasks,
+- `git gc` ([man page](https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-gc.html)) runs a number of housekeeping tasks,
   such as compressing filerevisions (to reduce disk space and increase performance)
   and removing unreachable objects which may have been created from prior invocations of
   `git add`.
-- `git repack` ([man page][man-repack]) re-organize existing packs into a single, more efficient pack.
+- `git repack` ([man page](https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-repack.html)) re-organize existing packs into a single, more efficient pack.
 
 You can find this option under your project's **Settings > General > Advanced**.
 
 ![Housekeeping settings](img/housekeeping_settings.png)
-
-[ce-2371]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/2371 "Housekeeping merge request"
-[man-gc]: https://www.kernel.org/pub/software/scm/git/docs/git-gc.html "git gc man page"
-[man-repack]: https://www.kernel.org/pub/software/scm/git/docs/git-repack.html
diff --git a/doc/administration/img/integration/plantuml-example.png b/doc/administration/img/integration/plantuml-example.png
deleted file mode 100644
index 3e0d6389cbd..00000000000
--- a/doc/administration/img/integration/plantuml-example.png
+++ /dev/null
diff --git a/doc/administration/incoming_email.md b/doc/administration/incoming_email.md
index 45634d50b91..88cf702cf0e 100644
--- a/doc/administration/incoming_email.md
+++ b/doc/administration/incoming_email.md
@@ -58,7 +58,7 @@ this method only supports replies, and not the other features of [incoming email
 ## Set it up
 
 If you want to use Gmail / Google Apps for incoming emails, make sure you have
-[IMAP access enabled](https://support.google.com/mail/troubleshooter/1668960?hl=en#ts=1665018)
+[IMAP access enabled](https://support.google.com/mail/answer/7126229)
 and [allowed less secure apps to access the account](https://support.google.com/accounts/answer/6010255)
 or [turn-on 2-step validation](https://support.google.com/accounts/answer/185839)
 and use [an application password](https://support.google.com/mail/answer/185833).
diff --git a/doc/administration/index.md b/doc/administration/index.md
index 6d40039026d..f90b9b2c7d5 100644
--- a/doc/administration/index.md
+++ b/doc/administration/index.md
@@ -97,7 +97,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 
 ### GitLab platform integrations
 
-- [Mattermost](https://docs.gitlab.com/omnibus/gitlab-mattermost/): Integrate with [Mattermost](https://about.mattermost.com/), an open source, private cloud workplace for web messaging.
+- [Mattermost](https://docs.gitlab.com/omnibus/gitlab-mattermost/): Integrate with [Mattermost](https://mattermost.com), an open source, private cloud workplace for web messaging.
 - [PlantUML](integration/plantuml.md): Create simple diagrams in AsciiDoc and Markdown documents
   created in snippets, wikis, and repos.
 - [Web terminals](integration/terminal.md): Provide terminal access to your applications deployed to Kubernetes from within GitLab's CI/CD [environments](../ci/environments.md#web-terminals).
@@ -154,7 +154,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 - [Enable/disable GitLab CI/CD](../ci/enable_or_disable_ci.md#site-wide-admin-setting): Enable or disable GitLab CI/CD for your instance.
 - [GitLab CI/CD admin settings](../user/admin_area/settings/continuous_integration.md): Enable or disable Auto DevOps site-wide and define the artifacts' max size and expiration time.
 - [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).
+- [Job logs](job_logs.md): Information about the job 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-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.
@@ -193,7 +193,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 - [Debugging tips](troubleshooting/debug.md): Tips to debug problems when things go wrong
 - [Log system](logs.md): Where to look for logs.
 - [Sidekiq Troubleshooting](troubleshooting/sidekiq.md): Debug when Sidekiq appears hung and is not processing jobs.
-- [Troubleshooting ElasticSearch](troubleshooting/elasticsearch.md)
+- [Troubleshooting Elasticsearch](troubleshooting/elasticsearch.md)
 
 ### Support Team Docs
 
@@ -212,8 +212,9 @@ who are aware of the risks.
 - [Useful diagnostics tools](troubleshooting/diagnostics_tools.md)
 - [Useful Linux commands](troubleshooting/linux_cheat_sheet.md)
 - [Troubleshooting Kubernetes](troubleshooting/kubernetes_cheat_sheet.md)
+- [Troubleshooting PostgreSQL](troubleshooting/postgresql.md)
 - [Guide to test environments](troubleshooting/test_environments.md) (for Support Engineers)
-- [GitLab rails console commands](troubleshooting/gitlab_rails_cheat_sheet.md) (for Support Engineers)
+- [GitLab Rails console commands](troubleshooting/gitlab_rails_cheat_sheet.md) (for Support Engineers)
 - Useful links:
   - [GitLab Developer Docs](../development/README.md)
   - [Repairing and recovering broken Git repositories](https://git.seveas.net/repairing-and-recovering-broken-git-repositories.html)
diff --git a/doc/administration/integration/plantuml.md b/doc/administration/integration/plantuml.md
index 67e1729e7fd..e595c640aac 100644
--- a/doc/administration/integration/plantuml.md
+++ b/doc/administration/integration/plantuml.md
@@ -21,6 +21,28 @@ docker run -d --name plantuml -p 8080:8080 plantuml/plantuml-server:tomcat
 
 The **PlantUML URL** will be the hostname of the server running the container.
 
+When running GitLab in Docker, it will need to have access to the PlantUML container.
+The easiest way to achieve that is by using [Docker Compose](https://docs.docker.com/compose/).
+
+A simple `docker-compose.yml` file would be:
+
+```yaml
+version: "3"
+services:
+  gitlab:
+    image: 'gitlab/gitlab-ce:12.2.5-ce.0'
+    environment:
+      GITLAB_OMNIBUS_CONFIG: |
+        nginx['custom_gitlab_server_config'] = "location /-/plantuml/ { \n    proxy_cache off; \n    proxy_pass  http://plantuml:8080/; \n}\n"
+
+  plantuml:
+    image: 'plantuml/plantuml-server:tomcat'
+    container_name: plantuml
+```
+
+In this scenario, PlantUML will be accessible for GitLab at the URL
+`http://plantuml:8080/`.
+
 ### Debian/Ubuntu
 
 Installing and configuring your
@@ -54,6 +76,10 @@ http://localhost:8080/plantuml
 
 you can change these defaults by editing the `/etc/tomcat7/server.xml` file.
 
+Note that the default URL is different than when using the Docker-based image,
+where the service is available at the root of URL with no relative path. Adjust
+the configuration below accordingly.
+
 ### Making local PlantUML accessible using custom GitLab setup
 
 The PlantUML server runs locally on your server, so it is not accessible
@@ -61,12 +87,22 @@ externally. As such, it is necessary to catch external PlantUML calls and
 redirect them to the local server.
 
 The idea is to redirect each call to `https://gitlab.example.com/-/plantuml/`
-to the local PlantUML server `http://localhost:8080/plantuml`.
+to the local PlantUML server `http://plantuml:8080/` or `http://localhost:8080/plantuml/`, depending on your setup.
 
 To enable the redirection, add the following line in `/etc/gitlab/gitlab.rb`:
 
 ```ruby
-nginx['custom_gitlab_server_config'] = "location /-/plantuml { \n    proxy_cache off; \n    proxy_pass  http://127.0.0.1:8080; \n}\n"
+# Docker deployment
+nginx['custom_gitlab_server_config'] = "location /-/plantuml/ { \n    proxy_cache off; \n    proxy_pass  http://plantuml:8080/; \n}\n"
+
+# Built from source
+nginx['custom_gitlab_server_config'] = "location /-/plantuml/ { \n    proxy_cache off; \n    proxy_pass  http://127.0.0.1:8080/plantuml/; \n}\n"
+```
+
+To activate the changes, run the following command:
+
+```sh
+sudo gitlab-ctl reconfigure
 ```
 
 ## GitLab
@@ -89,7 +125,7 @@ our AsciiDoc snippets, wikis and repos using delimited blocks:
   ~~~markdown
   ```plantuml
   Bob -> Alice : hello
-  Alice -> Bob : Go Away
+  Alice -> Bob : hi
   ```
   ~~~
 
@@ -99,7 +135,7 @@ our AsciiDoc snippets, wikis and repos using delimited blocks:
   [plantuml, format="png", id="myDiagram", width="200px"]
   ----
   Bob->Alice : hello
-  Alice -> Bob : Go Away
+  Alice -> Bob : hi
   ----
   ```
 
@@ -110,7 +146,7 @@ our AsciiDoc snippets, wikis and repos using delimited blocks:
      :caption: Caption with **bold** and *italic*
 
      Bob -> Alice: hello
-     Alice -> Bob: Go Away
+     Alice -> Bob: hi
   ```
 
    You can also use the `uml::` directive for compatibility with [sphinxcontrib-plantuml](https://pypi.org/project/sphinxcontrib-plantuml/), but please note that we currently only support the `caption` option.
@@ -119,7 +155,10 @@ The above blocks will be converted to an HTML img tag with source pointing to th
 PlantUML instance. If the PlantUML server is correctly configured, this should
 render a nice diagram instead of the block:
 
-![PlantUML Integration](../img/integration/plantuml-example.png)
+```plantuml
+Bob -> Alice : hello
+Alice -> Bob : hi
+```
 
 Inside the block you can add any of the supported diagrams by PlantUML such as
 [Sequence](http://plantuml.com/sequence-diagram), [Use Case](http://plantuml.com/use-case-diagram),
diff --git a/doc/administration/integration/terminal.md b/doc/administration/integration/terminal.md
index dbc61c82061..1af15648b97 100644
--- a/doc/administration/integration/terminal.md
+++ b/doc/administration/integration/terminal.md
@@ -60,8 +60,8 @@ guides document the necessary steps for a selection of popular reverse proxies:
 
 - [Apache](https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html)
 - [NGINX](https://www.nginx.com/blog/websocket-nginx/)
-- [HAProxy](http://blog.haproxy.com/2012/11/07/websockets-load-balancing-with-haproxy/)
-- [Varnish](https://www.varnish-cache.org/docs/4.1/users-guide/vcl-example-websockets.html)
+- [HAProxy](https://www.haproxy.com/blog/websockets-load-balancing-with-haproxy/)
+- [Varnish](https://varnish-cache.org/docs/4.1/users-guide/vcl-example-websockets.html)
 
 Workhorse won't let WebSocket requests through to non-WebSocket endpoints, so
 it's safe to enable support for these headers globally. If you'd rather had a
diff --git a/doc/administration/issue_closing_pattern.md b/doc/administration/issue_closing_pattern.md
index 0e34505c2b0..7b815143597 100644
--- a/doc/administration/issue_closing_pattern.md
+++ b/doc/administration/issue_closing_pattern.md
@@ -13,11 +13,11 @@ in the project's default branch.
 In order to change the pattern you need to have access to the server that GitLab
 is installed on.
 
-The default pattern can be located in [`gitlab.yml.example`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/config/gitlab.yml.example)
+The default pattern can be located in [`gitlab.yml.example`](https://gitlab.com/gitlab-org/gitlab/blob/master/config/gitlab.yml.example)
 under the "Automatic issue closing" section.
 
 > **Tip:**
-You are advised to use <http://rubular.com> to test the issue closing pattern.
+You are advised to use <https://rubular.com> to test the issue closing pattern.
 Because Rubular doesn't understand `%{issue_ref}`, you can replace this by
 `#\d+` when testing your patterns, which matches only local issue references like `#123`.
 
diff --git a/doc/administration/job_artifacts.md b/doc/administration/job_artifacts.md
index 913321012e4..ec2f40700f5 100644
--- a/doc/administration/job_artifacts.md
+++ b/doc/administration/job_artifacts.md
@@ -90,9 +90,9 @@ This configuration relies on valid AWS credentials to be configured already.
 Use an object storage option like AWS S3 to store job artifacts.
 
 DANGER: **Danger:**
-If you're enabling S3 in [GitLab HA](high_availability/README.md), you will need to have an [NFS mount set up for CI traces and artifacts](high_availability/nfs.md#a-single-nfs-mount) or enable [live tracing](job_traces.md#new-live-trace-architecture). If these settings are not set, you will risk job traces disappearing or not being saved.
+If you're enabling S3 in [GitLab HA](high_availability/README.md), you will need to have an [NFS mount set up for CI logs and artifacts](high_availability/nfs.md#a-single-nfs-mount) or enable [incremental logging](job_logs.md#new-incremental-logging-architecture). If these settings are not set, you will risk job logs disappearing or not being saved.
 
-### Object Storage Settings
+#### Object Storage Settings
 
 For source installations the following settings are nested under `artifacts:` and then `object_store:`. On Omnibus GitLab installs they are prefixed by `artifacts_object_store_`.
 
@@ -105,7 +105,7 @@ For source installations the following settings are nested under `artifacts:` an
 | `proxy_download` | Set to true to enable proxying all files served. Option allows to reduce egress traffic as this allows clients to download directly from remote storage instead of proxying all data | `false` |
 | `connection` | Various connection options described below | |
 
-#### S3 compatible connection settings
+##### S3 compatible connection settings
 
 The connection settings match those provided by [Fog](https://github.com/fog), and are as follows:
 
@@ -118,7 +118,7 @@ The connection settings match those provided by [Fog](https://github.com/fog), a
 | `enable_signature_v4_streaming` | Set to true to enable HTTP chunked transfers with [AWS v4 signatures](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-streaming.html). Oracle Cloud S3 needs this to be false | true |
 | `region` | AWS region | us-east-1 |
 | `host` | S3 compatible host for when not using AWS, e.g. `localhost` or `storage.example.com` | s3.amazonaws.com |
-| `endpoint` | Can be used when configuring an S3 compatible service such as [Minio](https://www.minio.io), by entering a URL such as `http://127.0.0.1:9000` | (optional) |
+| `endpoint` | Can be used when configuring an S3 compatible service such as [MinIO](https://min.io), by entering a URL such as `http://127.0.0.1:9000` | (optional) |
 | `path_style` | Set to true to use `host/bucket_name/object` style paths instead of `bucket_name.host/object`. Leave as false for AWS S3 | false |
 | `use_iam_profile` | Set to true to use IAM profile instead of access keys | false
 
@@ -188,6 +188,14 @@ _The artifacts are stored by default in
    sudo -u git -H bundle exec rake gitlab:artifacts:migrate RAILS_ENV=production
    ```
 
+### Migrating from object storage to local storage
+
+In order to migrate back to local storage:
+
+1. Set both `direct_upload` and `background_upload` to false under the artifacts object storage settings. Don't forget to restart GitLab.
+1. Run `rake gitlab:artifacts:migrate_to_local` on your console.
+1. Disable `object_storage` for artifacts in `gitlab.rb`. Remember to restart GitLab afterwards.
+
 ## Expiring artifacts
 
 If an expiry date is used for the artifacts, they are marked for deletion
diff --git a/doc/administration/job_logs.md b/doc/administration/job_logs.md
new file mode 100644
index 00000000000..d6d56515ac6
--- /dev/null
+++ b/doc/administration/job_logs.md
@@ -0,0 +1,169 @@
+# Job logs
+
+> [Renamed from Job Traces to Job logs](https://gitlab.com/gitlab-org/gitlab/issues/29121) in 12.4.
+
+Job logs (traces) are sent by GitLab Runner while it's processing a job. You can see
+logs in job pages, pipelines, email notifications, etc.
+
+## Data flow
+
+In general, there are two states for job logs: `log` and `archived log`.
+In the following table you can see the phases a log goes through:
+
+| Phase          | State        | Condition               | Data flow                                | Stored path |
+| -------------- | ------------ | ----------------------- | -----------------------------------------| ----------- |
+| 1: patching    | log          | When a job is running   | GitLab Runner => Unicorn => file storage | `#{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log` |
+| 2: overwriting | log          | When a job is finished  | GitLab Runner => Unicorn => file storage | `#{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log` |
+| 3: archiving   | archived log | After a job is finished | Sidekiq moves log to artifacts folder    | `#{ROOT_PATH}/gitlab-rails/shared/artifacts/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log` |
+| 4: uploading   | archived log | After a log is archived | Sidekiq moves archived log to [object storage](#uploading-logs-to-object-storage) (if configured) | `#{bucket_name}/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log` |
+
+The `ROOT_PATH` varies per environment. For Omnibus GitLab it
+would be `/var/opt/gitlab`, and for installations from source
+it would be `/home/git/gitlab`.
+
+## Changing the job logs local location
+
+To change the location where the job logs will be stored, follow the steps below.
+
+**In Omnibus installations:**
+
+1. Edit `/etc/gitlab/gitlab.rb` and add or amend the following line:
+
+   ```ruby
+   gitlab_ci['builds_directory'] = '/mnt/to/gitlab-ci/builds'
+   ```
+
+1. Save the file and [reconfigure GitLab][] for the changes to take effect.
+
+---
+
+**In installations from source:**
+
+1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following lines:
+
+   ```yaml
+   gitlab_ci:
+     # The location where build logs are stored (default: builds/).
+     # Relative paths are relative to Rails.root.
+     builds_path: path/to/builds/
+   ```
+
+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"
+
+## Uploading logs to object storage
+
+Archived logs are considered as [job artifacts](job_artifacts.md).
+Therefore, when you [set up the object storage integration](job_artifacts.md#object-storage-settings),
+job logs are automatically migrated to it along with the other job artifacts.
+
+See "Phase 4: uploading" in [Data flow](#data-flow) to learn about the process.
+
+## How to remove job logs
+
+There isn't a way to automatically expire old job logs, but it's safe to remove
+them if they're taking up too much space. If you remove the logs manually, the
+job output in the UI will be empty.
+
+## New incremental logging architecture
+
+> [Introduced][ce-18169] in GitLab 10.4.
+> [Announced as General availability][ce-46097] in GitLab 11.0.
+
+NOTE: **Note:**
+This feature is off by default. See below for how to [enable or disable](#enabling-incremental-logging) it.
+
+By combining the process with object storage settings, we can completely bypass
+the local file storage. This is a useful option if GitLab is installed as
+cloud-native, for example on Kubernetes.
+
+The data flow is the same as described in the [data flow section](#data-flow)
+with one change: _the stored path of the first two phases is different_. This incremental
+log architecture stores chunks of logs in Redis and a persistent store (object storage or database) instead of
+file storage. Redis is used as first-class storage, and it stores up-to 128KB
+of data. Once the full chunk is sent, it is flushed to a persistent store, either object storage(temporary directory) or database.
+After a while, the data in Redis and a persitent store will be archived to [object storage](#uploading-logs-to-object-storage).
+
+The data are stored in the following Redis namespace: `Gitlab::Redis::SharedState`.
+
+Here is the detailed data flow:
+
+1. GitLab Runner picks a job from GitLab
+1. GitLab Runner sends a piece of log to GitLab
+1. GitLab appends the data to Redis
+1. Once the data in Redis reach 128KB, the data is flushed to a persistent store (object storage or the database).
+1. The above steps are repeated until the job is finished.
+1. Once the job is finished, GitLab schedules a Sidekiq worker to archive the log.
+1. The Sidekiq worker archives the log to object storage and cleans up the log
+   in Redis and a persistent store (object storage or the database).
+
+### Enabling incremental logging
+
+The following commands are to be issued in a Rails console:
+
+```sh
+# Omnibus GitLab
+gitlab-rails console
+
+# Installation from source
+cd /home/git/gitlab
+sudo -u git -H bin/rails console RAILS_ENV=production
+```
+
+**To check if incremental logging (trace) is enabled:**
+
+```ruby
+Feature.enabled?('ci_enable_live_trace')
+```
+
+**To enable incremental logging (trace):**
+
+```ruby
+Feature.enable('ci_enable_live_trace')
+```
+
+NOTE: **Note:**
+The transition period will be handled gracefully. Upcoming logs will be
+generated with the incremental architecture, and on-going logs will stay with the
+legacy architecture, which means that on-going logs won't be forcibly
+re-generated with the incremental architecture.
+
+**To disable incremental logging (trace):**
+
+```ruby
+Feature.disable('ci_enable_live_trace')
+```
+
+NOTE: **Note:**
+The transition period will be handled gracefully. Upcoming logs will be generated
+with the legacy architecture, and on-going incremental logs will stay with the incremental
+architecture, which means that on-going incremental logs won't be forcibly re-generated
+with the legacy architecture.
+
+### Potential implications
+
+In some cases, having data stored on Redis could incur data loss:
+
+1. **Case 1: When all data in Redis are accidentally flushed**
+   - On going incremental logs could be recovered by re-sending logs (this is
+     supported by all versions of the GitLab Runner).
+   - Finished jobs which have not archived incremental logs will lose the last part
+     (~128KB) of log data.
+
+1. **Case 2: When Sidekiq workers fail to archive (e.g., there was a bug that
+   prevents archiving process, Sidekiq inconsistency, etc.)**
+   - Currently all log data in Redis will be deleted after one week. If the
+     Sidekiq workers can't finish by the expiry date, the part of log data will be lost.
+
+Another issue that might arise is that it could consume all memory on the Redis
+instance. If the number of jobs is 1000, 128MB (128KB * 1000) is consumed.
+
+Also, it could pressure the database replication lag. `INSERT`s are generated to
+indicate that we have log chunk. `UPDATE`s with 128KB of data is issued once we
+receive multiple chunks.
+
+[ce-18169]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/18169
+[ce-21193]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/21193
+[ce-46097]: https://gitlab.com/gitlab-org/gitlab-foss/issues/46097
diff --git a/doc/administration/job_traces.md b/doc/administration/job_traces.md
index 8a68f82d2fc..d0b346a931e 100644
--- a/doc/administration/job_traces.md
+++ b/doc/administration/job_traces.md
@@ -1,207 +1,5 @@
-# Job traces (logs)
-
-Job traces are sent by GitLab Runner while it's processing a job. You can see
-traces in job pages, pipelines, email notifications, etc.
-
-## Data flow
-
-In general, there are two states in job traces: "live trace" and "archived trace".
-In the following table you can see the phases a trace goes through.
-
-| Phase          | State          | Condition                 | Data flow                                       |  Stored path |
-| -----          | -----          | ---------                 | ---------                                       |  ----------- |
-| 1: patching    | Live trace     | When a job is running     | GitLab Runner => Unicorn => file storage        |`#{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log`|
-| 2: overwriting | Live trace     | When a job is finished    | GitLab Runner => Unicorn => file storage        |`#{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log`|
-| 3: archiving   | Archived trace | After a job is finished   | Sidekiq moves live trace to artifacts folder    |`#{ROOT_PATH}/gitlab-rails/shared/artifacts/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log`|
-| 4: uploading   | Archived trace | After a trace is archived | Sidekiq moves archived trace to [object storage](#uploading-traces-to-object-storage) (if configured)  |`#{bucket_name}/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log`|
-
-The `ROOT_PATH` varies per your environment. For Omnibus GitLab it
-would be `/var/opt/gitlab`, whereas for installations from source
-it would be `/home/git/gitlab`.
-
-## Changing the job traces local location
-
-To change the location where the job logs will be stored, follow the steps below.
-
-**In Omnibus installations:**
-
-1. Edit `/etc/gitlab/gitlab.rb` and add or amend the following line:
-
-   ```ruby
-   gitlab_ci['builds_directory'] = '/mnt/to/gitlab-ci/builds'
-   ```
-
-1. Save the file and [reconfigure GitLab][] for the changes to take effect.
-
+---
+redirect_to: 'job_logs.md'
 ---
 
-**In installations from source:**
-
-1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following lines:
-
-   ```yaml
-   gitlab_ci:
-     # The location where build traces are stored (default: builds/).
-     # Relative paths are relative to Rails.root.
-     builds_path: path/to/builds/
-   ```
-
-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"
-
-## Uploading traces to object storage
-
-Archived traces are considered as [job artifacts](job_artifacts.md).
-Therefore, when you [set up the object storage integration](job_artifacts.md#object-storage-settings),
-job traces are automatically migrated to it along with the other job artifacts.
-
-See "Phase 4: uploading" in [Data flow](#data-flow) to learn about the process.
-
-## How to archive legacy job trace files
-
-Legacy job traces, which were created before GitLab 10.5, were not archived regularly.
-It's the same state with the "2: overwriting" in the above [Data flow](#data-flow).
-To archive those legacy job traces, please follow the instruction below.
-
-1. Execute the following command
-
-   ```bash
-   gitlab-rake gitlab:traces:archive
-   ```
-
-   After you executed this task, GitLab instance queues up Sidekiq jobs (asynchronous processes)
-   for migrating job trace files from local storage to object storage.
-   It could take time to complete the all migration jobs. You can check the progress by the following command
-
-   ```bash
-   sudo gitlab-rails console
-   ```
-
-   ```bash
-   [1] pry(main)> Sidekiq::Stats.new.queues['pipeline_background:archive_trace']
-   => 100
-   ```
-
-   If the count becomes zero, the archiving processes are done
-
-## How to migrate archived job traces to object storage
-
-> [Introduced][ce-21193] in GitLab 11.3.
-
-If job traces have already been archived into local storage, and you want to migrate those traces to object storage, please follow the instruction below.
-
-1. Ensure [Object storage integration for Job Artifacts](job_artifacts.md#object-storage-settings) is enabled
-1. Execute the following command
-
-   ```bash
-   gitlab-rake gitlab:traces:migrate
-   ```
-
-## How to remove job traces
-
-There isn't a way to automatically expire old job logs, but it's safe to remove
-them if they're taking up too much space. If you remove the logs manually, the
-job output in the UI will be empty.
-
-## New live trace architecture
-
-> [Introduced][ce-18169] in GitLab 10.4.
-> [Announced as General availability][ce-46097] in GitLab 11.0.
-
-NOTE: **Note:**
-This feature is off by default. Check below how to [enable/disable](#enabling-live-trace) it.
-
-By combining the process with object storage settings, we can completely bypass
-the local file storage. This is a useful option if GitLab is installed as
-cloud-native, for example on Kubernetes.
-
-The data flow is the same as described in the [data flow section](#data-flow)
-with one change: _the stored path of the first two phases is different_. This new live
-trace architecture stores chunks of traces in Redis and a persistent store (object storage or database) instead of
-file storage. Redis is used as first-class storage, and it stores up-to 128KB
-of data. Once the full chunk is sent, it is flushed a persistent store, either object storage(temporary directory) or database.
-After a while, the data in Redis and a persitent store will be archived to [object storage](#uploading-traces-to-object-storage).
-
-The data are stored in the following Redis namespace: `Gitlab::Redis::SharedState`.
-
-Here is the detailed data flow:
-
-1. GitLab Runner picks a job from GitLab
-1. GitLab Runner sends a piece of trace to GitLab
-1. GitLab appends the data to Redis
-1. Once the data in Redis reach 128KB, the data is flushed to a persistent store (object storage or the database).
-1. The above steps are repeated until the job is finished.
-1. Once the job is finished, GitLab schedules a Sidekiq worker to archive the trace.
-1. The Sidekiq worker archives the trace to object storage and cleans up the trace
-   in Redis and a persistent store (object storage or the database).
-
-### Enabling live trace
-
-The following commands are to be issues in a Rails console:
-
-```sh
-# Omnibus GitLab
-gitlab-rails console
-
-# Installation from source
-cd /home/git/gitlab
-sudo -u git -H bin/rails console RAILS_ENV=production
-```
-
-**To check if live trace is enabled:**
-
-```ruby
-Feature.enabled?('ci_enable_live_trace')
-```
-
-**To enable live trace:**
-
-```ruby
-Feature.enable('ci_enable_live_trace')
-```
-
-NOTE: **Note:**
-The transition period will be handled gracefully. Upcoming traces will be
-generated with the new architecture, and on-going live traces will stay with the
-legacy architecture, which means that on-going live traces won't be forcibly
-re-generated with the new architecture.
-
-**To disable live trace:**
-
-```ruby
-Feature.disable('ci_enable_live_trace')
-```
-
-NOTE: **Note:**
-The transition period will be handled gracefully. Upcoming traces will be generated
-with the legacy architecture, and on-going live traces will stay with the new
-architecture, which means that on-going live traces won't be forcibly re-generated
-with the legacy architecture.
-
-### Potential implications
-
-In some cases, having data stored on Redis could incur data loss:
-
-1. **Case 1: When all data in Redis are accidentally flushed**
-   - On going live traces could be recovered by re-sending traces (this is
-     supported by all versions of the GitLab Runner).
-   - Finished jobs which have not archived live traces will lose the last part
-     (~128KB) of trace data.
-
-1. **Case 2: When Sidekiq workers fail to archive (e.g., there was a bug that
-   prevents archiving process, Sidekiq inconsistency, etc.)**
-   - Currently all trace data in Redis will be deleted after one week. If the
-     Sidekiq workers can't finish by the expiry date, the part of trace data will be lost.
-
-Another issue that might arise is that it could consume all memory on the Redis
-instance. If the number of jobs is 1000, 128MB (128KB * 1000) is consumed.
-
-Also, it could pressure the database replication lag. `INSERT`s are generated to
-indicate that we have trace chunk. `UPDATE`s with 128KB of data is issued once we
-receive multiple chunks.
-
-[ce-18169]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/18169
-[ce-21193]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/21193
-[ce-46097]: https://gitlab.com/gitlab-org/gitlab-foss/issues/46097
+This document was moved to [another location](job_logs.md).
diff --git a/doc/administration/libravatar.md b/doc/administration/libravatar.md
new file mode 100644
index 00000000000..43a6b8f0d34
--- /dev/null
+++ b/doc/administration/libravatar.md
@@ -0,0 +1,101 @@
+---
+type: howto
+---
+
+# Using the Libravatar service with GitLab
+
+GitLab by default supports the [Gravatar](https://gravatar.com) avatar service.
+
+Libravatar is another service that delivers your avatar (profile picture) to
+other websites. The Libravatar API is
+[heavily based on gravatar](https://wiki.libravatar.org/api/), so you can
+easily switch to the Libravatar avatar service or even a self-hosted Libravatar
+server.
+
+## Configuration
+
+In the [`gitlab.yml` gravatar section](https://gitlab.com/gitlab-org/gitlab/blob/672bd3902d86b78d730cea809fce312ec49d39d7/config/gitlab.yml.example#L122), set
+the configuration options as follows:
+
+### For HTTP
+
+```yml
+  gravatar:
+    enabled: true
+    # gravatar URLs: possible placeholders: %{hash} %{size} %{email} %{username}
+    plain_url: "http://cdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
+```
+
+### For HTTPS
+
+```yml
+  gravatar:
+    enabled: true
+    # gravatar URLs: possible placeholders: %{hash} %{size} %{email} %{username}
+    ssl_url: "https://seccdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
+```
+
+### Self-hosted Libravatar server
+
+If you are [running your own libravatar service](https://wiki.libravatar.org/running_your_own/),
+the URL will be different in the configuration, but you must provide the same
+placeholders so GitLab can parse the URL correctly.
+
+For example, you host a service on `http://libravatar.example.com` and the
+`plain_url` you need to supply in `gitlab.yml` is
+
+`http://libravatar.example.com/avatar/%{hash}?s=%{size}&d=identicon`
+
+### Omnibus GitLab example
+
+In `/etc/gitlab/gitlab.rb`:
+
+#### For HTTP
+
+```ruby
+gitlab_rails['gravatar_enabled'] = true
+gitlab_rails['gravatar_plain_url'] = "http://cdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
+```
+
+#### For HTTPS
+
+```ruby
+gitlab_rails['gravatar_enabled'] = true
+gitlab_rails['gravatar_ssl_url'] = "https://seccdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
+```
+
+Then run `sudo gitlab-ctl reconfigure` for the changes to take effect.
+
+## Default URL for missing images
+
+[Libravatar supports different sets](https://wiki.libravatar.org/api/) of
+missing images for user email addresses that are not found on the Libravatar
+service.
+
+In order to use a set other than `identicon`, replace the `&d=identicon`
+portion of the URL with another supported set.
+For example, you can use the `retro` set, in which case the URL would look like:
+`plain_url: "http://cdn.libravatar.org/avatar/%{hash}?s=%{size}&d=retro"`
+
+## Usage examples for Microsoft Office 365
+
+If your users are Office 365 users, the `GetPersonaPhoto` service can be used.
+Note that this service requires a login, so this use case is most useful in a
+corporate installation where all users have access to Office 365.
+
+```ruby
+gitlab_rails['gravatar_plain_url'] = 'http://outlook.office365.com/owa/service.svc/s/GetPersonaPhoto?email=%{email}&size=HR120x120'
+gitlab_rails['gravatar_ssl_url'] = 'https://outlook.office365.com/owa/service.svc/s/GetPersonaPhoto?email=%{email}&size=HR120x120'
+```
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+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. -->
diff --git a/doc/administration/logs.md b/doc/administration/logs.md
index 7857dcc1f08..dae0dae8395 100644
--- a/doc/administration/logs.md
+++ b/doc/administration/logs.md
@@ -23,7 +23,7 @@ requests from the API are logged to a separate file in `api_json.log`.
 Each line contains a JSON line that can be ingested by Elasticsearch, Splunk, etc. For example:
 
 ```json
-{"method":"GET","path":"/gitlab/gitlab-ce/issues/1234","format":"html","controller":"Projects::IssuesController","action":"show","status":200,"duration":229.03,"view":174.07,"db":13.24,"time":"2017-08-08T20:15:54.821Z","params":[{"key":"param_key","value":"param_value"}],"remote_ip":"18.245.0.1","user_id":1,"username":"admin","gitaly_calls":76,"gitaly_duration":7.41,"queue_duration": 112.47}
+{"method":"GET","path":"/gitlab/gitlab-foss/issues/1234","format":"html","controller":"Projects::IssuesController","action":"show","status":200,"duration":229.03,"view":174.07,"db":13.24,"time":"2017-08-08T20:15:54.821Z","params":[{"key":"param_key","value":"param_value"}],"remote_ip":"18.245.0.1","user_id":1,"username":"admin","gitaly_calls":76,"gitaly_duration":7.41,"queue_duration": 112.47}
 ```
 
 In this example, you can see this was a GET request for a specific
@@ -233,7 +233,7 @@ This file lives in `/var/log/gitlab/gitlab-shell/gitlab-shell.log` for
 Omnibus GitLab packages or in `/home/git/gitlab-shell/gitlab-shell.log` for
 installations from source.
 
-GitLab shell is used by GitLab for executing Git commands and provide
+GitLab Shell is used by GitLab for executing Git commands and provide
 SSH access to Git repositories. For example:
 
 ```
@@ -241,7 +241,7 @@ I, [2015-02-13T06:17:00.671315 #9291]  INFO -- : Adding project root/example.git
 I, [2015-02-13T06:17:00.679433 #9291]  INFO -- : Moving existing hooks directory and symlinking global hooks directory for /var/opt/gitlab/git-data/repositories/root/example.git.
 ```
 
-User clone/fetch activity using ssh transport appears in this log as `executing git command <gitaly-upload-pack...`.
+User clone/fetch activity using SSH transport appears in this log as `executing git command <gitaly-upload-pack...`.
 
 ## `unicorn_stderr.log`
 
@@ -252,7 +252,7 @@ installations from source.
 Unicorn is a high-performance forking Web server which is used for
 serving the GitLab application. You can look at this log if, for
 example, your application does not respond. This log contains all
-information about the state of unicorn processes at any given time.
+information about the state of Unicorn processes at any given time.
 
 ```
 I, [2015-02-13T06:14:46.680381 #9047]  INFO -- : Refreshing Gem list
@@ -294,9 +294,11 @@ This log records:
 
 - Information whenever [Rack Attack] registers an abusive request.
 - Requests over the [Rate Limit] on raw endpoints.
+- [Protected paths] abusive requests.
 
 NOTE: **Note:**
-From [%12.1](https://gitlab.com/gitlab-org/gitlab-foss/issues/62756), user id and username are available on this log.
+From [%12.1](https://gitlab.com/gitlab-org/gitlab-foss/issues/62756), user id and username are also
+recorded on this log, if available.
 
 ## `graphql_json.log`
 
@@ -327,17 +329,19 @@ is populated whenever `gitlab-ctl reconfigure` is run manually or as part of an
 Reconfigure logs files are named according to the UNIX timestamp of when the reconfigure
 was initiated, such as `1509705644.log`
 
-## `sidekiq_exporter.log`
+## `sidekiq_exporter.log` and `web_exporter.log`
 
 If Prometheus metrics and the Sidekiq Exporter are both enabled, Sidekiq will
-start a Web server and listen to the defined port (default: 3807). Access logs
+start a Web server and listen to the defined port (default: 8082). Access logs
 will be generated in `/var/log/gitlab/gitlab-rails/sidekiq_exporter.log` for
 Omnibus GitLab packages or in `/home/git/gitlab/log/sidekiq_exporter.log` for
 installations from source.
 
-[repocheck]: repository_checks.md
-[Rack Attack]: ../security/rack_attack.md
-[Rate Limit]: ../user/admin_area/settings/rate_limits_on_raw_endpoints.md
+If Prometheus metrics and the Web Exporter are both enabled, Unicorn/Puma will
+start a Web server and listen to the defined port (default: 8083). Access logs
+will be generated in `/var/log/gitlab/gitlab-rails/web_exporter.log` for
+Omnibus GitLab packages or in `/home/git/gitlab/log/web_exporter.log` for
+installations from source.
 
 ## `database_load_balancing.log` **(PREMIUM ONLY)**
 
@@ -348,3 +352,8 @@ It is stored at:
 
 - `/var/log/gitlab/gitlab-rails/database_load_balancing.log` for Omnibus GitLab packages.
 - `/home/git/gitlab/log/database_load_balancing.log` for installations from source.
+
+[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
diff --git a/doc/administration/merge_request_diffs.md b/doc/administration/merge_request_diffs.md
index f24a3f94ceb..ca09171e5ff 100644
--- a/doc/administration/merge_request_diffs.md
+++ b/doc/administration/merge_request_diffs.md
@@ -61,6 +61,9 @@ To enable external storage of merge request diffs, follow the instructions below
 
 ## Using object storage
 
+CAUTION: **WARNING:**
+  Currently migrating to object storage is **non-reversible**
+
 Instead of storing the external diffs on disk, we recommended the use of an object
 store like AWS S3 instead. This configuration relies on valid AWS credentials to
 be configured already.
@@ -93,7 +96,7 @@ The connection settings match those provided by [Fog](https://github.com/fog), a
 | `enable_signature_v4_streaming` | Set to true to enable HTTP chunked transfers with [AWS v4 signatures](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-streaming.html). Oracle Cloud S3 needs this to be false | true |
 | `region` | AWS region | us-east-1 |
 | `host` | S3 compatible host for when not using AWS, e.g. `localhost` or `storage.example.com` | s3.amazonaws.com |
-| `endpoint` | Can be used when configuring an S3 compatible service such as [Minio](https://www.minio.io), by entering a URL such as `http://127.0.0.1:9000` | (optional) |
+| `endpoint` | Can be used when configuring an S3 compatible service such as [MinIO](https://min.io), by entering a URL such as `http://127.0.0.1:9000` | (optional) |
 | `path_style` | Set to true to use `host/bucket_name/object` style paths instead of `bucket_name.host/object`. Leave as false for AWS S3 | false |
 | `use_iam_profile` | Set to true to use IAM profile instead of access keys | false
 
diff --git a/doc/administration/monitoring/github_imports.md b/doc/administration/monitoring/github_imports.md
index 2b1b7a230f7..4d60cf0d491 100644
--- a/doc/administration/monitoring/github_imports.md
+++ b/doc/administration/monitoring/github_imports.md
@@ -16,7 +16,7 @@ This metric tracks the total time spent (in seconds) importing a project (from
 project creation until the import process finishes), for every imported project.
 
 The name of the project is stored in the `project` label in the format
-`namespace/name` (e.g. `gitlab-org/gitlab-ce`).
+`namespace/name` (e.g. `gitlab-org/gitlab`).
 
 ## Number of imported projects
 
@@ -54,7 +54,7 @@ projects. This metric does not expose any labels.
 This metric tracks the number of imported issues across all projects.
 
 The name of the project is stored in the `project` label in the format
-`namespace/name` (e.g. `gitlab-org/gitlab-ce`).
+`namespace/name` (e.g. `gitlab-org/gitlab`).
 
 ## Number of imported pull requests
 
@@ -65,7 +65,7 @@ The name of the project is stored in the `project` label in the format
 This metric tracks the number of imported pull requests across all projects.
 
 The name of the project is stored in the `project` label in the format
-`namespace/name` (e.g. `gitlab-org/gitlab-ce`).
+`namespace/name` (e.g. `gitlab-org/gitlab`).
 
 ## Number of imported comments
 
@@ -76,7 +76,7 @@ The name of the project is stored in the `project` label in the format
 This metric tracks the number of imported comments across all projects.
 
 The name of the project is stored in the `project` label in the format
-`namespace/name` (e.g. `gitlab-org/gitlab-ce`).
+`namespace/name` (e.g. `gitlab-org/gitlab`).
 
 ## Number of imported pull request review comments
 
@@ -87,7 +87,7 @@ The name of the project is stored in the `project` label in the format
 This metric tracks the number of imported comments across all projects.
 
 The name of the project is stored in the `project` label in the format
-`namespace/name` (e.g. `gitlab-org/gitlab-ce`).
+`namespace/name` (e.g. `gitlab-org/gitlab`).
 
 ## Number of imported repositories
 
diff --git a/doc/administration/monitoring/index.md b/doc/administration/monitoring/index.md
index 2b3daec42bd..80e727f6a5c 100644
--- a/doc/administration/monitoring/index.md
+++ b/doc/administration/monitoring/index.md
@@ -10,4 +10,4 @@ Explore our features to monitor your GitLab instance:
 - [GitHub imports](github_imports.md): Monitor the health and progress of GitLab's GitHub importer with various Prometheus metrics.
 - [Monitoring uptime](../../user/admin_area/monitoring/health_check.md): Check the server status using the health check endpoint.
   - [IP whitelists](ip_whitelist.md): Configure GitLab for monitoring endpoints that provide health check information when probed.
-- [nginx_status](https://docs.gitlab.com/omnibus/settings/nginx.html#enablingdisabling-nginx_status): Monitor your Nginx server status
+- [`nginx_status`](https://docs.gitlab.com/omnibus/settings/nginx.html#enablingdisabling-nginx_status): Monitor your NGINX server status
diff --git a/doc/administration/monitoring/performance/grafana_configuration.md b/doc/administration/monitoring/performance/grafana_configuration.md
index d389c7c5003..ccba0a55479 100644
--- a/doc/administration/monitoring/performance/grafana_configuration.md
+++ b/doc/administration/monitoring/performance/grafana_configuration.md
@@ -32,14 +32,14 @@ in the top bar.
 Fill in the configuration details for the InfluxDB data source. Save and
 Test Connection to ensure the configuration is correct.
 
-- **Name**: InfluxDB
+- **Name**: `InfluxDB`
 - **Default**: Checked
-- **Type**: InfluxDB 0.9.x (Even if you're using InfluxDB 0.10.x)
+- **Type**: `InfluxDB 0.9.x` (Even if you're using InfluxDB 0.10.x)
 - **Url**: `https://localhost:8086` (Or the remote URL if you've installed InfluxDB
   on a separate server)
-- **Access**: proxy
-- **Database**: gitlab
-- **User**: admin (Or the username configured when setting up InfluxDB)
+- **Access**: `proxy`
+- **Database**: `gitlab`
+- **User**: `admin` (Or the username configured when setting up InfluxDB)
 - **Password**: The password configured when you set up InfluxDB
 
 ![Grafana data source configurations](img/grafana_data_source_configuration.png)
@@ -146,7 +146,7 @@ However, you should **not** reinstate your old data _except_ under one of the fo
 
 If you require access to your old Grafana data but do not meet one of these criteria, you may consider reinstating it temporarily, [exporting the dashboards](https://grafana.com/docs/reference/export_import/#exporting-a-dashboard) you need, then refreshing the data and [re-importing your dashboards](https://grafana.com/docs/reference/export_import/#importing-a-dashboard). Note that this poses a temporary vulnerability while your old Grafana data is in use, and the decision to do so should be weighed carefully with your need to access existing data and dashboards.
 
-For more information and further mitigation details, please refer to our [blog post on the security release](https://about.gitlab.com/2019/08/12/critical-security-release-gitlab-12-dot-1-dot-6-released/).
+For more information and further mitigation details, please refer to our [blog post on the security release](https://about.gitlab.com/blog/2019/08/12/critical-security-release-gitlab-12-dot-1-dot-6-released/).
 
 ---
 
diff --git a/doc/administration/monitoring/performance/img/performance_bar_gitaly_threshold.png b/doc/administration/monitoring/performance/img/performance_bar_gitaly_threshold.png
new file mode 100644
index 00000000000..d4bf5c69ffa
--- /dev/null
+++ b/doc/administration/monitoring/performance/img/performance_bar_gitaly_threshold.png
diff --git a/doc/administration/monitoring/performance/img/performance_bar_request_selector_warning.png b/doc/administration/monitoring/performance/img/performance_bar_request_selector_warning.png
new file mode 100644
index 00000000000..966549554a4
--- /dev/null
+++ b/doc/administration/monitoring/performance/img/performance_bar_request_selector_warning.png
diff --git a/doc/administration/monitoring/performance/img/performance_bar_request_selector_warning_expanded.png b/doc/administration/monitoring/performance/img/performance_bar_request_selector_warning_expanded.png
new file mode 100644
index 00000000000..3362186bb48
--- /dev/null
+++ b/doc/administration/monitoring/performance/img/performance_bar_request_selector_warning_expanded.png
diff --git a/doc/administration/monitoring/performance/index.md b/doc/administration/monitoring/performance/index.md
index ef71ca1d6c3..5204ab40dc9 100644
--- a/doc/administration/monitoring/performance/index.md
+++ b/doc/administration/monitoring/performance/index.md
@@ -31,8 +31,8 @@ including (but not limited to):
 - System statistics such as the process' memory usage and open file descriptors.
 - Ruby garbage collection statistics.
 
-Metrics data is written to [InfluxDB][influxdb] over [UDP][influxdb-udp]. Stored
-data can be visualized using [Grafana][grafana] or any other application that
+Metrics data is written to [InfluxDB](https://www.influxdata.com/products/influxdb-overview/)
+over [UDP][influxdb-udp]. Stored data can be visualized using [Grafana](https://grafana.com) or any other application that
 supports reading data from InfluxDB. Alternatively data can be queried using the
 InfluxDB CLI.
 
@@ -67,6 +67,4 @@ the actual interval can be anywhere between 7.5 and 22.5. The interval is
 re-generated for every sampling run instead of being generated once and re-used
 for the duration of the process' lifetime.
 
-[influxdb]: https://influxdata.com/time-series-platform/influxdb/
 [influxdb-udp]: https://docs.influxdata.com/influxdb/v0.9/write_protocols/udp/
-[grafana]: http://grafana.org/
diff --git a/doc/administration/monitoring/performance/influxdb_configuration.md b/doc/administration/monitoring/performance/influxdb_configuration.md
index cf6728510fe..f1f588a924d 100644
--- a/doc/administration/monitoring/performance/influxdb_configuration.md
+++ b/doc/administration/monitoring/performance/influxdb_configuration.md
@@ -38,8 +38,8 @@ InfluxDB needs to be restarted.
 ### Storage Engine
 
 InfluxDB comes with different storage engines and as of InfluxDB 0.9.5 a new
-storage engine is available, called [TSM Tree]. All users **must** use the new
-`tsm1` storage engine as this [will be the default engine][tsm1-commit] in
+storage engine is available, called [TSM Tree](https://www.influxdata.com/blog/new-storage-engine-time-structured-merge-tree/).
+All users **must** use the new `tsm1` storage engine as this [will be the default engine][tsm1-commit] in
 upcoming InfluxDB releases.
 
 Make sure you have the following in your configuration file:
@@ -95,7 +95,7 @@ UDP can be done using the following settings:
 This does the following:
 
 1. Enable UDP and bind it to port 8089 for all addresses.
-1. Store any data received in the "gitlab" database.
+1. Store any data received in the `gitlab` database.
 1. Define a batch of points to be 1000 points in size and allow a maximum of
    5 batches _or_ flush them automatically after 1 second.
 1. Define a UDP read buffer size of 200 MB.
@@ -188,6 +188,5 @@ Read more on:
 [influxdb cli]: https://docs.influxdata.com/influxdb/v0.9/tools/shell/
 [udp]: https://docs.influxdata.com/influxdb/v0.9/write_protocols/udp/
 [influxdb]: https://www.influxdata.com/products/influxdb-overview/
-[tsm tree]: https://influxdata.com/blog/new-storage-engine-time-structured-merge-tree/
 [tsm1-commit]: https://github.com/influxdata/influxdb/commit/15d723dc77651bac83e09e2b1c94be480966cb0d
 [influx-admin]: https://docs.influxdata.com/influxdb/v0.9/administration/authentication_and_authorization/#create-a-new-admin-user
diff --git a/doc/administration/monitoring/performance/performance_bar.md b/doc/administration/monitoring/performance/performance_bar.md
index 02f4b78bd60..53c08e32cb2 100644
--- a/doc/administration/monitoring/performance/performance_bar.md
+++ b/doc/administration/monitoring/performance/performance_bar.md
@@ -21,6 +21,24 @@ On the far right is a request selector that allows you to view the same metrics
 (excluding the page timing and line profiler) for any requests made while the
 page was open. Only the first two requests per unique URL are captured.
 
+## Request warnings
+
+For requests exceeding pre-defined limits, a warning icon will be shown
+next to the failing metric, along with an explanation. In this example,
+the Gitaly call duration exceeded the threshold:
+
+![Gitaly call duration exceeded threshold](img/performance_bar_gitaly_threshold.png)
+
+If any requests on the current page generated warnings, the icon will
+appear next to the request selector:
+
+![Request selector showing two requests with warnings](img/performance_bar_request_selector_warning.png)
+
+And requests with warnings are indicated in the request selector with a
+`(!)` after their path:
+
+![Request selector showing dropdown](img/performance_bar_request_selector_warning_expanded.png)
+
 ## Enable the Performance Bar via the Admin panel
 
 GitLab Performance Bar is disabled by default. To enable it for a given group,
diff --git a/doc/administration/monitoring/performance/prometheus.md b/doc/administration/monitoring/performance/prometheus.md
index 2c5bab46dd9..f05a420fc19 100644
--- a/doc/administration/monitoring/performance/prometheus.md
+++ b/doc/administration/monitoring/performance/prometheus.md
@@ -2,4 +2,4 @@
 redirect_to: '../prometheus/index.md'
 ---
 
-This document was moved to [monitoring/prometheus](../prometheus/index.md).
+This document was moved to [another location](../prometheus/index.md).
diff --git a/doc/administration/monitoring/prometheus/gitlab_exporter.md b/doc/administration/monitoring/prometheus/gitlab_exporter.md
index cfd9f55acc3..f6178799e0a 100644
--- a/doc/administration/monitoring/prometheus/gitlab_exporter.md
+++ b/doc/administration/monitoring/prometheus/gitlab_exporter.md
@@ -1,12 +1,16 @@
 # GitLab exporter
 
->**Note:**
-Available since [Omnibus GitLab 8.17][1132]. For installations from source
-you'll have to install and configure it yourself.
+>- Available since [Omnibus GitLab 8.17](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1132).
+>- Renamed from `GitLab monitor exporter` to `GitLab exporter` in [GitLab 12.3](https://gitlab.com/gitlab-org/gitlab/merge_requests/16511).
 
-The [GitLab exporter] allows you to measure various GitLab metrics, pulled from Redis and the database.
+The [GitLab exporter](https://gitlab.com/gitlab-org/gitlab-exporter) allows you to
+measure various GitLab metrics, pulled from Redis and the database, in Omnibus GitLab
+instances.
 
-To enable the GitLab exporter:
+NOTE: **Note:**
+For installations from source you'll have to install and configure it yourself.
+
+To enable the GitLab exporter in an Omnibus GitLab instance:
 
 1. [Enable Prometheus](index.md#configuring-prometheus)
 1. Edit `/etc/gitlab/gitlab.rb`
@@ -16,15 +20,10 @@ To enable the GitLab exporter:
    gitlab_exporter['enable'] = true
    ```
 
-1. Save the file and [reconfigure GitLab][reconfigure] 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
 
 Prometheus will now automatically begin collecting performance data from
 the GitLab exporter exposed under `localhost:9168`.
 
 [← Back to the main Prometheus page](index.md)
-
-[1132]: https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1132
-[GitLab exporter]: https://gitlab.com/gitlab-org/gitlab-exporter
-[prometheus]: https://prometheus.io
-[reconfigure]: ../../restart_gitlab.md#omnibus-gitlab-reconfigure
diff --git a/doc/administration/monitoring/prometheus/gitlab_metrics.md b/doc/administration/monitoring/prometheus/gitlab_metrics.md
index 302d74dd96a..02920293daa 100644
--- a/doc/administration/monitoring/prometheus/gitlab_metrics.md
+++ b/doc/administration/monitoring/prometheus/gitlab_metrics.md
@@ -42,10 +42,10 @@ The following metrics are available:
 | `gitlab_transaction_cache_read_hit_count_total`                | Counter   |                   10.2 | Counter for cache hits for Rails cache calls                                                        | controller, action                                  |
 | `gitlab_transaction_cache_read_miss_count_total`               | Counter   |                   10.2 | Counter for cache misses for Rails cache calls                                                      | controller, action                                  |
 | `gitlab_transaction_duration_seconds`                          | Histogram |                   10.2 | Duration for all transactions (gitlab_transaction_* metrics)                                        | controller, action                                  |
-| `gitlab_transaction_event_build_found_total`                   | Counter   |                    9.4 | Counter for build found for api /jobs/request                                                       |                                                     |
-| `gitlab_transaction_event_build_invalid_total`                 | Counter   |                    9.4 | Counter for build invalid due to concurrency conflict for api /jobs/request                         |                                                     |
-| `gitlab_transaction_event_build_not_found_cached_total`        | Counter   |                    9.4 | Counter for cached response of build not found for api /jobs/request                                |                                                     |
-| `gitlab_transaction_event_build_not_found_total`               | Counter   |                    9.4 | Counter for build not found for api /jobs/request                                                   |                                                     |
+| `gitlab_transaction_event_build_found_total`                   | Counter   |                    9.4 | Counter for build found for API /jobs/request                                                       |                                                     |
+| `gitlab_transaction_event_build_invalid_total`                 | Counter   |                    9.4 | Counter for build invalid due to concurrency conflict for API /jobs/request                         |                                                     |
+| `gitlab_transaction_event_build_not_found_cached_total`        | Counter   |                    9.4 | Counter for cached response of build not found for API /jobs/request                                |                                                     |
+| `gitlab_transaction_event_build_not_found_total`               | Counter   |                    9.4 | Counter for build not found for API /jobs/request                                                   |                                                     |
 | `gitlab_transaction_event_change_default_branch_total`         | Counter   |                    9.4 | Counter when default branch is changed for any repository                                           |                                                     |
 | `gitlab_transaction_event_create_repository_total`             | Counter   |                    9.4 | Counter when any repository is created                                                              |                                                     |
 | `gitlab_transaction_event_etag_caching_cache_hit_total`        | Counter   |                    9.4 | Counter for etag cache hit.                                                                         | endpoint                                            |
@@ -66,10 +66,10 @@ The following metrics are available:
 | `gitlab_transaction_event_remove_branch_total`                 | Counter   |                    9.4 | Counter when a branch is removed for any repository                                                 |                                                     |
 | `gitlab_transaction_event_remove_repository_total`             | Counter   |                    9.4 | Counter when a repository is removed                                                                |                                                     |
 | `gitlab_transaction_event_remove_tag_total`                    | Counter   |                    9.4 | Counter when a tag is remove for any repository                                                     |                                                     |
-| `gitlab_transaction_event_sidekiq_exception_total`             | Counter   |                    9.4 | Counter of sidekiq exceptions                                                                       |                                                     |
+| `gitlab_transaction_event_sidekiq_exception_total`             | Counter   |                    9.4 | Counter of Sidekiq exceptions                                                                       |                                                     |
 | `gitlab_transaction_event_stuck_import_jobs_total`             | Counter   |                    9.4 | Count of stuck import jobs                                                                          | projects_without_jid_count, projects_with_jid_count |
-| `gitlab_transaction_event_update_build_total`                  | Counter   |                    9.4 | Counter for update build for api /jobs/request/:id                                                  |                                                     |
-| `gitlab_transaction_new_redis_connections_total`               | Counter   |                    9.4 | Counter for new redis connections                                                                   |                                                     |
+| `gitlab_transaction_event_update_build_total`                  | Counter   |                    9.4 | Counter for update build for API /jobs/request/:id                                                  |                                                     |
+| `gitlab_transaction_new_redis_connections_total`               | Counter   |                    9.4 | Counter for new Redis connections                                                                   |                                                     |
 | `gitlab_transaction_queue_duration_total`                      | Counter   |                    9.4 | Duration jobs were enqueued before processing                                                       |                                                     |
 | `gitlab_transaction_rails_queue_duration_total`                | Counter   |                    9.4 | Measures latency between GitLab Workhorse forwarding a request to Rails                             | controller, action                                  |
 | `gitlab_transaction_view_duration_total`                       | Counter   |                    9.4 | Duration for views                                                                                  | controller, action, view                            |
@@ -140,8 +140,7 @@ The following metrics are available:
 
 | Metric                            | Type      | Since                                                         | Description                            |
 |:--------------------------------- |:--------- |:------------------------------------------------------------- |:-------------------------------------- |
-| `db_load_balancing_hosts`         | Gauge     | [12.3](https://gitlab.com/gitlab-org/gitlab/issues/13630)  | Current number of load balancing hosts |
-| `db_load_balancing_index`         | Gauge     | [12.3](https://gitlab.com/gitlab-org/gitlab/issues/13630)  | Current load balancing host index      |
+| `db_load_balancing_hosts`         | Gauge     | [12.3](https://gitlab.com/gitlab-org/gitlab/issues/13630)     | Current number of load balancing hosts |
 
 ## Ruby metrics
 
diff --git a/doc/administration/monitoring/prometheus/gitlab_monitor_exporter.md b/doc/administration/monitoring/prometheus/gitlab_monitor_exporter.md
new file mode 100644
index 00000000000..ae3a3d739b5
--- /dev/null
+++ b/doc/administration/monitoring/prometheus/gitlab_monitor_exporter.md
@@ -0,0 +1,5 @@
+---
+redirect_to: 'gitlab_exporter.md'
+---
+
+This document was moved to [another location](gitlab_exporter.md).
diff --git a/doc/administration/monitoring/prometheus/index.md b/doc/administration/monitoring/prometheus/index.md
index 9228ebf4fed..c35d6f505be 100644
--- a/doc/administration/monitoring/prometheus/index.md
+++ b/doc/administration/monitoring/prometheus/index.md
@@ -21,7 +21,7 @@ Prometheus works by periodically connecting to data sources and collecting their
 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].
+dashboard tool like [Grafana](https://grafana.com).
 
 ## Configuring Prometheus
 
@@ -114,7 +114,7 @@ To use an external Prometheus server:
     gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '192.168.0.1']
     ```
 
-1. To scrape nginx metrics, you'll also need to configure nginx to allow the Prometheus server
+1. To scrape NGINX metrics, you'll also need to configure NGINX to allow the Prometheus server
    IP. For example:
 
    ```ruby
@@ -199,8 +199,8 @@ having [NGINX proxy it][nginx-custom-config].
 
 The performance data collected by Prometheus can be viewed directly in the
 Prometheus console or through a compatible dashboard tool.
-The Prometheus interface provides a [flexible query language][prom-query] to work
-with the collected data where you can visualize their output.
+The Prometheus interface provides a [flexible query language](https://prometheus.io/docs/prometheus/latest/querying/basics/)
+to work with the collected data where you can visualize their output.
 For a more fully featured dashboard, Grafana can be used and has
 [official support for Prometheus][prom-grafana].
 
@@ -274,7 +274,7 @@ The GitLab exporter allows you to measure various GitLab metrics, pulled from Re
 > Introduced in GitLab 9.0.
 > Pod monitoring introduced in GitLab 9.4.
 
-If your GitLab server is running within Kubernetes, Prometheus will collect metrics from the Nodes and [annotated Pods](https://prometheus.io/docs/operating/configuration/#kubernetes_sd_config) in the cluster, including performance data on each container. This is particularly helpful if your CI/CD environments run in the same cluster, as you can use the [Prometheus project integration][prometheus integration] to monitor them.
+If your GitLab server is running within Kubernetes, Prometheus will collect metrics from the Nodes and [annotated Pods](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config) in the cluster, including performance data on each container. This is particularly helpful if your CI/CD environments run in the same cluster, as you can use the [Prometheus project integration][prometheus integration] to monitor them.
 
 To disable the monitoring of Kubernetes:
 
@@ -288,16 +288,11 @@ To disable the monitoring of Kubernetes:
 1. Save the file and [reconfigure GitLab][reconfigure] for the changes to
    take effect.
 
-[grafana]: https://grafana.net
 [hsts]: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
 [multi-user-prometheus]: https://gitlab.com/gitlab-org/multi-user-prometheus
 [nginx-custom-config]: https://docs.gitlab.com/omnibus/settings/nginx.html#inserting-custom-nginx-settings-into-the-gitlab-server-block
 [prometheus]: https://prometheus.io
-[prom-exporters]: https://prometheus.io/docs/instrumenting/exporters/
-[prom-query]: https://prometheus.io/docs/querying/basics
 [prom-grafana]: https://prometheus.io/docs/visualization/grafana/
-[scrape-config]: https://prometheus.io/docs/operating/configuration/#%3Cscrape_config%3E
 [reconfigure]: ../../restart_gitlab.md#omnibus-gitlab-reconfigure
 [1261]: https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1261
 [prometheus integration]: ../../../user/project/integrations/prometheus.md
-[prometheus-cadvisor-metrics]: https://github.com/google/cadvisor/blob/master/docs/storage/prometheus.md
diff --git a/doc/administration/operations/cleaning_up_redis_sessions.md b/doc/administration/operations/cleaning_up_redis_sessions.md
index c9b5ab9d290..fd469ae23e3 100644
--- a/doc/administration/operations/cleaning_up_redis_sessions.md
+++ b/doc/administration/operations/cleaning_up_redis_sessions.md
@@ -11,8 +11,8 @@ start building up again after you clean up.
 In GitLab versions prior to 7.3.0, the session keys in Redis are 16-byte
 hexadecimal values such as '976aa289e2189b17d7ef525a6702ace9'. Starting with
 GitLab 7.3.0, the keys are
-prefixed with 'session:gitlab:', so they would look like
-'session:gitlab:976aa289e2189b17d7ef525a6702ace9'. Below we describe how to
+prefixed with `session:gitlab:`, so they would look like
+`session:gitlab:976aa289e2189b17d7ef525a6702ace9`. Below we describe how to
 remove the keys in the old format.
 
 **Note:** the instructions below must be modified in accordance with your
diff --git a/doc/administration/operations/fast_ssh_key_lookup.md b/doc/administration/operations/fast_ssh_key_lookup.md
index 16424c25a98..9a38e8ddd23 100644
--- a/doc/administration/operations/fast_ssh_key_lookup.md
+++ b/doc/administration/operations/fast_ssh_key_lookup.md
@@ -2,7 +2,7 @@
 
 NOTE: **Note:** This document describes a drop-in replacement for the
 `authorized_keys` file for normal (non-deploy key) users. Consider
-using [ssh certificates](ssh_certificates.md), they are even faster,
+using [SSH certificates](ssh_certificates.md), they are even faster,
 but are not a drop-in replacement.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1631) in
@@ -78,7 +78,7 @@ CAUTION: **Caution:** Do not disable writes until SSH is confirmed to be working
 perfectly, because the file will quickly become out-of-date.
 
 In the case of lookup failures (which are common), the `authorized_keys`
-file will still be scanned. So git SSH performance will still be slow for many
+file will still be scanned. So Git SSH performance will still be slow for many
 users as long as a large file exists.
 
 You can disable any more writes to the `authorized_keys` file by unchecking
diff --git a/doc/administration/operations/moving_repositories.md b/doc/administration/operations/moving_repositories.md
index ec11a92db1b..d54ffacd281 100644
--- a/doc/administration/operations/moving_repositories.md
+++ b/doc/administration/operations/moving_repositories.md
@@ -31,7 +31,7 @@ If you want to see progress, replace `-xf` with `-xvf`.
 ### Tar pipe to another server
 
 You can also use a tar pipe to copy data to another server. If your
-'git' user has SSH access to the newserver as 'git@newserver', you
+`git` user has SSH access to the newserver as `git@newserver`, you
 can pipe the data through SSH.
 
 ```
@@ -61,7 +61,7 @@ If you want to see progress, replace `-a` with `-av`.
 
 ### Single rsync to another server
 
-If the 'git' user on your source system has SSH access to the target
+If the `git` user on your source system has SSH access to the target
 server you can send the repositories over the network with rsync.
 
 ```
@@ -95,7 +95,7 @@ after switching to the new repository storage directory.
 This will sync repositories with 10 rsync processes at a time. We keep
 track of progress so that the transfer can be restarted if necessary.
 
-First we create a new directory, owned by 'git', to hold transfer
+First we create a new directory, owned by `git`, to hold transfer
 logs. We assume the directory is empty before we start the transfer
 procedure, and that we are the only ones writing files in it.
 
diff --git a/doc/administration/operations/sidekiq_memory_killer.md b/doc/administration/operations/sidekiq_memory_killer.md
index 8eac42f2fe2..79e9fb778b6 100644
--- a/doc/administration/operations/sidekiq_memory_killer.md
+++ b/doc/administration/operations/sidekiq_memory_killer.md
@@ -2,7 +2,7 @@
 
 The GitLab Rails application code suffers from memory leaks. For web requests
 this problem is made manageable using
-[unicorn-worker-killer](https://github.com/kzk/unicorn-worker-killer) which
+[`unicorn-worker-killer`](https://github.com/kzk/unicorn-worker-killer) which
 restarts Unicorn worker processes in between requests when needed. The Sidekiq
 MemoryKiller applies the same approach to the Sidekiq processes used by GitLab
 to process background jobs.
@@ -10,8 +10,8 @@ to process background jobs.
 Unlike unicorn-worker-killer, which is enabled by default for all GitLab
 installations since GitLab 6.4, the Sidekiq MemoryKiller is enabled by default
 _only_ for Omnibus packages. The reason for this is that the MemoryKiller
-relies on Runit to restart Sidekiq after a memory-induced shutdown and GitLab
-installations from source do not all use Runit or an equivalent.
+relies on runit to restart Sidekiq after a memory-induced shutdown and GitLab
+installations from source do not all use runit or an equivalent.
 
 With the default settings, the MemoryKiller will cause a Sidekiq restart no
 more often than once every 15 minutes, with the restart causing about one
@@ -26,18 +26,50 @@ run as a process group leader (e.g., using `chpst -P`). If using Omnibus or the
 
 The MemoryKiller is controlled using environment variables.
 
-- `SIDEKIQ_MEMORY_KILLER_MAX_RSS`: if this variable is set, and its value is
-  greater than 0, then after each Sidekiq job, the MemoryKiller will check the
-  RSS of the Sidekiq process that executed the job. If the RSS of the Sidekiq
-  process (expressed in kilobytes) exceeds SIDEKIQ_MEMORY_KILLER_MAX_RSS, a
-  delayed shutdown is triggered. The default value for Omnibus packages is set
-  [in the omnibus-gitlab
+- `SIDEKIQ_DAEMON_MEMORY_KILLER`: defaults to 0. When set to 1, the MemoryKiller
+  works in _daemon_ mode. Otherwise, the MemoryKiller works in _legacy_ mode.
+
+  In _legacy_ mode, the MemoryKiller checks the Sidekiq process RSS after each job.
+
+  In _daemon_ mode, the MemoryKiller checks the Sidekiq process RSS every 3 seconds
+  (defined by `SIDEKIQ_MEMORY_KILLER_CHECK_INTERVAL`).
+
+- `SIDEKIQ_MEMORY_KILLER_MAX_RSS`: if this variable is set, and its value is greater
+  than 0, the MemoryKiller is enabled. Otherwise the MemoryKiller is disabled.
+
+  `SIDEKIQ_MEMORY_KILLER_MAX_RSS` defines the Sidekiq process allowed RSS.
+
+  In _legacy_ mode, if the Sidekiq process exceeds the allowed RSS then an irreversible
+  delayed graceful restart will be triggered. The restart of Sidekiq will happen
+  after `SIDEKIQ_MEMORY_KILLER_GRACE_TIME` seconds.
+
+  In _daemon_ mode, if the Sidekiq process exceeds the allowed RSS for longer than
+  `SIDEKIQ_MEMORY_KILLER_GRACE_TIME` the graceful restart will be triggered. If the
+  Sidekiq process go below the allowed RSS within `SIDEKIQ_MEMORY_KILLER_GRACE_TIME`,
+  the restart will be aborted.
+
+  The default value for Omnibus packages is set
+  [in the Omnibus GitLab
   repository](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/attributes/default.rb).
-- `SIDEKIQ_MEMORY_KILLER_GRACE_TIME`: defaults to 900 seconds (15 minutes). When
-  a shutdown is triggered, the Sidekiq process will keep working normally for
-  another 15 minutes.
-- `SIDEKIQ_MEMORY_KILLER_SHUTDOWN_WAIT`: defaults to 30 seconds. When the grace
-  time has expired, the MemoryKiller tells Sidekiq to stop accepting new jobs.
-  Existing jobs get 30 seconds to finish. After that, the MemoryKiller tells
-  Sidekiq to shut down, and an external supervision mechanism (e.g. Runit) must
-  restart Sidekiq.
+
+- `SIDEKIQ_MEMORY_KILLER_HARD_LIMIT_RSS`: is used by _daemon_ mode. If the Sidekiq
+  process RSS (expressed in kilobytes) exceeds `SIDEKIQ_MEMORY_KILLER_HARD_LIMIT_RSS`,
+  an immediate graceful restart of Sidekiq is triggered.
+
+- `SIDEKIQ_MEMORY_KILLER_CHECK_INTERVAL`: used in _daemon_ mode to define how
+  often to check process RSS, default to 3 seconds.
+
+- `SIDEKIQ_MEMORY_KILLER_GRACE_TIME`: defaults to 900 seconds (15 minutes).
+  The usage of this variable is described as part of `SIDEKIQ_MEMORY_KILLER_MAX_RSS`.
+
+- `SIDEKIQ_MEMORY_KILLER_SHUTDOWN_WAIT`: defaults to 30 seconds. This defines the
+  maximum time allowed for all Sidekiq jobs to finish. No new jobs will be accepted
+  during that time, and the process will exit as soon as all jobs finish.
+
+  If jobs do not finish during that time, the MemoryKiller will interrupt all currently
+  running jobs by sending `SIGTERM` to the Sidekiq process.
+
+  If the process hard shutdown/restart is not performed by Sidekiq,
+  the Sidekiq process will be forcefully terminated after
+  `Sidekiq.options[:timeout] * 2` seconds. An external supervision mechanism
+  (e.g. runit) must restart Sidekiq afterwards.
diff --git a/doc/administration/operations/ssh_certificates.md b/doc/administration/operations/ssh_certificates.md
index 3792bcd3bca..2a9a4cff34e 100644
--- a/doc/administration/operations/ssh_certificates.md
+++ b/doc/administration/operations/ssh_certificates.md
@@ -3,7 +3,7 @@
 > [Available in](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/19911) GitLab
 > Community Edition 11.2.
 
-GitLab's default SSH authentication requires users to upload their ssh
+GitLab's default SSH authentication requires users to upload their SSH
 public keys before they can use the SSH transport.
 
 In centralized (e.g. corporate) environments this can be a hassle
diff --git a/doc/administration/operations/unicorn.md b/doc/administration/operations/unicorn.md
index 8178cb243f3..969f1211643 100644
--- a/doc/administration/operations/unicorn.md
+++ b/doc/administration/operations/unicorn.md
@@ -40,7 +40,7 @@ master process has PID 56227 below.
 
 The main tunables for Unicorn are the number of worker processes and the
 request timeout after which the Unicorn master terminates a worker process.
-See the [omnibus-gitlab Unicorn settings
+See the [Omnibus GitLab Unicorn settings
 documentation](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/unicorn.md)
 if you want to adjust these settings.
 
diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index b5320d39d92..bf86a549fda 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -5,8 +5,8 @@
 >   Docker versions earlier than 1.10.
 
 NOTE: **Note:**
-This document is about the admin guide. To learn how to use GitLab Container
-Registry [user documentation](../../user/packages/container_registry/index.md).
+This document is the administrator's guide. To learn how to use GitLab Container
+Registry, see the [user documentation](../../user/packages/container_registry/index.md).
 
 With the Container Registry integrated into GitLab, every project can have its
 own space to store its Docker images.
@@ -37,7 +37,7 @@ If you have installed GitLab from source:
 1. After the installation is complete, you will have to configure the Registry's
    settings in `gitlab.yml` in order to enable it.
 1. Use the sample NGINX configuration file that is found under
-   [`lib/support/nginx/registry-ssl`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/support/nginx/registry-ssl) and edit it to match the
+   [`lib/support/nginx/registry-ssl`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/support/nginx/registry-ssl) and edit it to match the
    `host`, `port` and TLS certs paths.
 
 The contents of `gitlab.yml` are:
@@ -360,9 +360,9 @@ The different supported drivers are:
 | Driver     | Description                         |
 |------------|-------------------------------------|
 | filesystem | Uses a path on the local filesystem |
-| azure      | Microsoft Azure Blob Storage        |
+| Azure      | Microsoft Azure Blob Storage        |
 | gcs        | Google Cloud Storage                |
-| s3         | Amazon Simple Storage Service. Be sure to configure your storage bucket with the correct [S3 Permission Scopes](https://docs.docker.com/registry/storage-drivers/s3/#s3-permission-scopes).       |
+| s3         | Amazon Simple Storage Service. Be sure to configure your storage bucket with the correct [S3 Permission Scopes](https://docs.docker.com/registry/storage-drivers/s3/#s3-permission-scopes). |
 | swift      | OpenStack Swift Object Storage      |
 | oss        | Aliyun OSS                          |
 
@@ -374,7 +374,7 @@ filesystem. Remember to enable backups with your object storage provider if
 desired.
 
 NOTE: **Note:**
-`regionendpoint` is only required when configuring an S3 compatible service such as Minio. It takes a URL such as `http://127.0.0.1:9000`.
+`regionendpoint` is only required when configuring an S3 compatible service such as MinIO. It takes a URL such as `http://127.0.0.1:9000`.
 
 **Omnibus GitLab installations**
 
@@ -877,6 +877,6 @@ The above image shows:
 - The HEAD request to the AWS bucket reported a 403 Unauthorized.
 
 What does this mean? This strongly suggests that the S3 user does not have the right
-[permissions to perform a HEAD request](http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectHEAD.html).
+[permissions to perform a HEAD request](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectHEAD.html).
 The solution: check the [IAM permissions again](https://docs.docker.com/registry/storage-drivers/s3/).
 Once the right permissions were set, the error will go away.
diff --git a/doc/administration/packages/index.md b/doc/administration/packages/index.md
index 99ec5811681..d4afc65577e 100644
--- a/doc/administration/packages/index.md
+++ b/doc/administration/packages/index.md
@@ -8,6 +8,7 @@ The Packages feature allows GitLab to act as a repository for the following:
 
 | Software repository | Description | Available in GitLab version |
 | ------------------- | ----------- | --------------------------- |
+| [Conan Repository](../../user/packages/conan_repository/index.md) | The GitLab Conan Repository enables every project in GitLab to have its own space to store [Conan](https://conan.io/) packages. | 12.4+ |
 | [Maven Repository](../../user/packages/maven_repository/index.md) | The GitLab Maven Repository enables every project in GitLab to have its own space to store [Maven](https://maven.apache.org/) packages. | 11.3+ |
 | [NPM Registry](../../user/packages/npm_registry/index.md)   | The GitLab NPM Registry enables every project in GitLab to have its own space to store [NPM](https://www.npmjs.com/) packages. | 11.7+ |
 
diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md
index 41a372c4aeb..cacfb73451c 100644
--- a/doc/administration/pages/index.md
+++ b/doc/administration/pages/index.md
@@ -13,10 +13,6 @@ description: 'Learn how to administer GitLab Pages.'
 GitLab Pages allows for hosting of static sites. It must be configured by an
 administrator. Separate [user documentation][pages-userguide] is available.
 
-Read the [changelog](#changelog) if you are upgrading to a new GitLab
-version as it may include new features and changes needed to be made in your
-configuration.
-
 NOTE: **Note:**
 This guide is for Omnibus GitLab installations. If you have installed
 GitLab from source, see
@@ -119,7 +115,7 @@ since that is needed in all configurations.
 URL scheme: `http://page.example.io`
 
 This is the minimum setup that you can use Pages with. It is the base for all
-other setups as described below. Nginx will proxy all requests to the daemon.
+other setups as described below. NGINX will proxy all requests to the daemon.
 The Pages daemon doesn't listen to the outside world.
 
 1. Set the external URL for GitLab Pages in `/etc/gitlab/gitlab.rb`:
@@ -143,7 +139,7 @@ Watch the [video tutorial][video-admin] for this configuration.
 
 URL scheme: `https://page.example.io`
 
-Nginx will proxy all requests to the daemon. Pages daemon doesn't listen to the
+NGINX will proxy all requests to the daemon. Pages daemon doesn't listen to the
 outside world.
 
 1. Place the certificate and key inside `/etc/gitlab/ssl`
@@ -200,7 +196,7 @@ you have IPv6 as well as IPv4 addresses, you can use them both.
 
 URL scheme: `http://page.example.io` and `http://domain.com`
 
-In that case, the Pages daemon is running, Nginx still proxies requests to
+In that case, the Pages daemon is running, NGINX still proxies requests to
 the daemon but the daemon is also able to receive requests from the outside
 world. Custom domains are supported, but no TLS.
 
@@ -231,7 +227,7 @@ world. Custom domains are supported, but no TLS.
 
 URL scheme: `https://page.example.io` and `https://domain.com`
 
-In that case, the Pages daemon is running, Nginx still proxies requests to
+In that case, the Pages daemon is running, NGINX still proxies requests to
 the daemon but the daemon is also able to receive requests from the outside
 world. Custom domains and TLS are supported.
 
@@ -309,7 +305,7 @@ Pages access control is disabled by default. To enable it:
    ```
 
 1. [Reconfigure GitLab][reconfigure].
-1. Users can now configure it in their [projects' settings](../../user/project/pages/introduction.md#gitlab-pages-access-control-core-only).
+1. Users can now configure it in their [projects' settings](../../user/project/pages/introduction.md#gitlab-pages-access-control-core).
 
 ### Running behind a proxy
 
@@ -323,7 +319,7 @@ pages:
    gitlab_pages['http_proxy'] = 'http://example:8080'
    ```
 
-1. [Reconfigure Gitlab][reconfigure] for the changes to take effect.
+1. [Reconfigure GitLab][reconfigure] for the changes to take effect.
 
 ## Activate verbose logging for daemon
 
@@ -430,37 +426,9 @@ Pages are part of the [regular backup][backup] so there is nothing to configure.
 
 ## Security
 
-You should strongly consider running GitLab pages under a different hostname
+You should strongly consider running GitLab Pages under a different hostname
 than GitLab to prevent XSS attacks.
 
-## Changelog
-
-GitLab Pages were first introduced in GitLab EE 8.3. Since then, many features
-where added, like custom CNAME and TLS support, and many more are likely to
-come. Below is a brief changelog. If no changes were introduced or a version is
-missing from the changelog, assume that the documentation is the same as the
-latest previous version.
-
----
-
-**GitLab 8.17 ([documentation](https://gitlab.com/gitlab-org/gitlab-foss/blob/8-17-stable/doc/administration/pages/index.md))**
-
-- GitLab Pages were ported to Community Edition in GitLab 8.17.
-- Documentation was refactored to be more modular and easy to follow.
-
-**GitLab 8.5 ([documentation](https://gitlab.com/gitlab-org/gitlab/blob/8-5-stable-ee/doc/pages/administration.md))**
-
-- In GitLab 8.5 we introduced the [gitlab-pages][] daemon which is now the
-  recommended way to set up GitLab Pages.
-- The [NGINX configs][] have changed to reflect this change. So make sure to
-  update them.
-- Custom CNAME and TLS certificates support.
-- Documentation was moved to one place.
-
-**GitLab 8.3 ([documentation](https://gitlab.com/gitlab-org/gitlab/blob/8-3-stable-ee/doc/pages/administration.md))**
-
-- GitLab Pages feature was introduced.
-
 [backup]: ../../raketasks/backup_restore.md
 [ce-14605]: https://gitlab.com/gitlab-org/gitlab-foss/issues/14605
 [ee-80]: https://gitlab.com/gitlab-org/gitlab/merge_requests/80
diff --git a/doc/administration/pages/source.md b/doc/administration/pages/source.md
index bacfa0117bb..be8bba3c95b 100644
--- a/doc/administration/pages/source.md
+++ b/doc/administration/pages/source.md
@@ -93,7 +93,7 @@ since that is needed in all configurations.
 URL scheme: `http://page.example.io`
 
 This is the minimum setup that you can use Pages with. It is the base for all
-other setups as described below. Nginx will proxy all requests to the daemon.
+other setups as described below. NGINX will proxy all requests to the daemon.
 The Pages daemon doesn't listen to the outside world.
 
 1. Install the Pages daemon:
@@ -136,7 +136,7 @@ The Pages daemon doesn't listen to the outside world.
    gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090"
    ```
 
-1. Copy the `gitlab-pages` Nginx configuration file:
+1. Copy the `gitlab-pages` NGINX configuration file:
 
    ```bash
    sudo cp lib/support/nginx/gitlab-pages /etc/nginx/sites-available/gitlab-pages.conf
@@ -155,7 +155,7 @@ The Pages daemon doesn't listen to the outside world.
 
 URL scheme: `https://page.example.io`
 
-Nginx will proxy all requests to the daemon. Pages daemon doesn't listen to the
+NGINX will proxy all requests to the daemon. Pages daemon doesn't listen to the
 outside world.
 
 1. Install the Pages daemon:
@@ -193,7 +193,7 @@ outside world.
    gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -root-cert /path/to/example.io.crt -root-key /path/to/example.io.key
    ```
 
-1. Copy the `gitlab-pages-ssl` Nginx configuration file:
+1. Copy the `gitlab-pages-ssl` NGINX configuration file:
 
    ```bash
    sudo cp lib/support/nginx/gitlab-pages-ssl /etc/nginx/sites-available/gitlab-pages-ssl.conf
@@ -219,7 +219,7 @@ that without TLS certificates.
 
 URL scheme: `http://page.example.io` and `http://domain.com`
 
-In that case, the pages daemon is running, Nginx still proxies requests to
+In that case, the pages daemon is running, NGINX still proxies requests to
 the daemon but the daemon is also able to receive requests from the outside
 world. Custom domains are supported, but no TLS.
 
@@ -261,7 +261,7 @@ world. Custom domains are supported, but no TLS.
    gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -listen-http 192.0.2.2:80"
    ```
 
-1. Copy the `gitlab-pages-ssl` Nginx configuration file:
+1. Copy the `gitlab-pages-ssl` NGINX configuration file:
 
    ```bash
    sudo cp lib/support/nginx/gitlab-pages /etc/nginx/sites-available/gitlab-pages.conf
@@ -284,7 +284,7 @@ world. Custom domains are supported, but no TLS.
 
 URL scheme: `https://page.example.io` and `https://domain.com`
 
-In that case, the pages daemon is running, Nginx still proxies requests to
+In that case, the pages daemon is running, NGINX still proxies requests to
 the daemon but the daemon is also able to receive requests from the outside
 world. Custom domains and TLS are supported.
 
@@ -330,7 +330,7 @@ world. Custom domains and TLS are supported.
    gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -listen-http 192.0.2.2:80 -listen-https 192.0.2.2:443 -root-cert /path/to/example.io.crt -root-key /path/to/example.io.key
    ```
 
-1. Copy the `gitlab-pages-ssl` Nginx configuration file:
+1. Copy the `gitlab-pages-ssl` NGINX configuration file:
 
    ```bash
    sudo cp lib/support/nginx/gitlab-pages-ssl /etc/nginx/sites-available/gitlab-pages-ssl.conf
@@ -351,7 +351,7 @@ The following information applies only for installations from source.
 Be extra careful when setting up the domain name in the NGINX config. You must
 not remove the backslashes.
 
-If your GitLab pages domain is `example.io`, replace:
+If your GitLab Pages domain is `example.io`, replace:
 
 ```bash
 server_name ~^.*\.YOUR_GITLAB_PAGES\.DOMAIN$;
@@ -401,7 +401,7 @@ Pages access control is disabled by default. To enable it:
 1. Create a new [system OAuth application](../../integration/oauth_provider.md#adding-an-application-through-the-profile).
    This should be called `GitLab Pages` and have a `Redirect URL` of
    `https://projects.example.io/auth`. It does not need to be a "trusted"
-   application, but it does need the "api" scope.
+   application, but it does need the `api` scope.
 1. Start the Pages daemon with the following additional arguments:
 
    ```shell
@@ -411,7 +411,7 @@ Pages access control is disabled by default. To enable it:
      -auth-server <URL of the GitLab instance>
    ```
 
-1. Users can now configure it in their [projects' settings](../../user/project/pages/introduction.md#gitlab-pages-access-control-core-only).
+1. Users can now configure it in their [projects' settings](../../user/project/pages/introduction.md#gitlab-pages-access-control-core).
 
 ## Change storage path
 
@@ -443,7 +443,7 @@ Pages are part of the [regular backup][backup] so there is nothing to configure.
 
 ## Security
 
-You should strongly consider running GitLab pages under a different hostname
+You should strongly consider running GitLab Pages under a different hostname
 than GitLab to prevent XSS attacks.
 
 [backup]: ../../raketasks/backup_restore.md
@@ -455,5 +455,5 @@ than GitLab to prevent XSS attacks.
 [pages-userguide]: ../../user/project/pages/index.md
 [restart]: ../restart_gitlab.md#installations-from-source
 [gitlab-pages]: https://gitlab.com/gitlab-org/gitlab-pages/tree/v0.4.0
-[gl-example]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/support/init.d/gitlab.default.example
+[gl-example]: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/support/init.d/gitlab.default.example
 [shared runners]: ../../ci/runners/README.md
diff --git a/doc/administration/raketasks/check.md b/doc/administration/raketasks/check.md
index d8f80965c21..eb230f02c0d 100644
--- a/doc/administration/raketasks/check.md
+++ b/doc/administration/raketasks/check.md
@@ -8,7 +8,7 @@ help GitLab administrators diagnose problem repositories so they can be fixed.
 
 There are 3 things that are checked to determine integrity.
 
-1. Git repository file system check ([git fsck](https://git-scm.com/docs/git-fsck)).
+1. Git repository file system check ([`git fsck`](https://git-scm.com/docs/git-fsck)).
    This step verifies the connectivity and validity of objects in the repository.
 1. Check for `config.lock` in the repository directory.
 1. Check for any branch/references lock files in `refs/heads`.
diff --git a/doc/administration/raketasks/geo.md b/doc/administration/raketasks/geo.md
index 387bc71965b..09f72c3411d 100644
--- a/doc/administration/raketasks/geo.md
+++ b/doc/administration/raketasks/geo.md
@@ -2,7 +2,7 @@
 
 ## Git housekeeping
 
-There are few tasks you can run to schedule a git housekeeping to start at the
+There are few tasks you can run to schedule a Git housekeeping to start at the
 next repository sync in a **Secondary node**:
 
 ### Incremental Repack
diff --git a/doc/administration/raketasks/maintenance.md b/doc/administration/raketasks/maintenance.md
index 89335fcd2a8..e63e0c40393 100644
--- a/doc/administration/raketasks/maintenance.md
+++ b/doc/administration/raketasks/maintenance.md
@@ -62,7 +62,7 @@ It will check that each component was set up according to the installation guide
 You may also have a look at our Troubleshooting Guides:
 
 - [Troubleshooting Guide (GitLab)](../index.md#troubleshooting)
-- [Troubleshooting Guide (Omnibus Gitlab)](https://docs.gitlab.com/omnibus/README.html#troubleshooting)
+- [Troubleshooting Guide (Omnibus GitLab)](https://docs.gitlab.com/omnibus/README.html#troubleshooting)
 
 **Omnibus Installation**
 
@@ -76,7 +76,7 @@ sudo gitlab-rake gitlab:check
 bundle exec rake gitlab:check RAILS_ENV=production
 ```
 
-NOTE: Use SANITIZE=true for gitlab:check if you want to omit project names from the output.
+NOTE: Use `SANITIZE=true` for `gitlab:check` if you want to omit project names from the output.
 
 Example output:
 
@@ -146,7 +146,7 @@ You will lose any data stored in authorized_keys file.
 Do you want to continue (yes/no)? yes
 ```
 
-## Clear redis cache
+## Clear Redis cache
 
 If for some reason the dashboard shows wrong information you might want to
 clear Redis' cache.
@@ -183,7 +183,7 @@ For omnibus versions, the unoptimized assets (JavaScript, CSS) are frozen at
 the release of upstream GitLab. The omnibus version includes optimized versions
 of those assets. Unless you are modifying the JavaScript / CSS code on your
 production machine after installing the package, there should be no reason to redo
-rake gitlab:assets:compile on the production machine. If you suspect that assets
+`rake gitlab:assets:compile` on the production machine. If you suspect that assets
 have been corrupted, you should reinstall the omnibus package.
 
 ## Tracking Deployments
diff --git a/doc/administration/raketasks/uploads/migrate.md b/doc/administration/raketasks/uploads/migrate.md
index d9b4c9b3369..517d6b01438 100644
--- a/doc/administration/raketasks/uploads/migrate.md
+++ b/doc/administration/raketasks/uploads/migrate.md
@@ -113,3 +113,39 @@ To migrate all uploads created by legacy uploaders, run:
 ```shell
 bundle exec rake gitlab:uploads:legacy:migrate
 ```
+
+## Migrate from object storage to local storage
+
+If you need to disable Object Storage for any reason, first you need to migrate
+your data out of Object Storage and back into your local storage.
+
+**Before proceeding, it is important to disable both `direct_upload` and `background_upload` under `uploads` settings in `gitlab.rb`**
+
+CAUTION: **Warning:**
+   **Extended downtime is required** so no new files are created in object storage during
+   the migration. A configuration setting will be added soon to allow migrating
+   from object storage to local files with only a brief moment of downtime for configuration changes.
+   See issue [gitlab-org/gitlab#30979](https://gitlab.com/gitlab-org/gitlab/issues/30979)
+
+### All-in-one rake task
+
+GitLab provides a wrapper rake task that migrates all uploaded files - avatars,
+logos, attachments, favicon, etc. - to local storage in one go. Under the hood,
+it invokes individual rake tasks to migrate files falling under each of this
+category one by one. For details on these rake tasks please [refer to the section above](#individual-rake-tasks),
+keeping in mind the task name in this case is `gitlab:uploads:migrate_to_local`.
+
+**Omnibus Installation**
+
+```bash
+gitlab-rake "gitlab:uploads:migrate_to_local:all"
+```
+
+**Source Installation**
+
+```bash
+sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:migrate_to_local:all
+```
+
+After this is done, you may disable Object Storage by undoing the changes described
+in the instructions to [configure object storage](../../uploads.md#using-object-storage-core-only)
diff --git a/doc/administration/repository_storage_paths.md b/doc/administration/repository_storage_paths.md
index 376eb90deea..7d3e36e9796 100644
--- a/doc/administration/repository_storage_paths.md
+++ b/doc/administration/repository_storage_paths.md
@@ -118,6 +118,6 @@ randomly placed on one of the selected paths.
 [restart-gitlab]: restart_gitlab.md#installations-from-source
 [reconfigure-gitlab]: restart_gitlab.md#omnibus-gitlab-reconfigure
 [backups]: ../raketasks/backup_restore.md
-[raketask]: https://gitlab.com/gitlab-org/gitlab-foss/blob/033e5423a2594e08a7ebcd2379bd2331f4c39032/lib/backup/repository.rb#L54-56
-[repospath]: https://gitlab.com/gitlab-org/gitlab-foss/blob/8-9-stable/config/gitlab.yml.example#L457
+[raketask]: https://gitlab.com/gitlab-org/gitlab/blob/033e5423a2594e08a7ebcd2379bd2331f4c39032/lib/backup/repository.rb#L54-56
+[repospath]: https://gitlab.com/gitlab-org/gitlab/blob/8-9-stable/config/gitlab.yml.example#L457
 [ce-11449]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/11449
diff --git a/doc/administration/repository_storage_types.md b/doc/administration/repository_storage_types.md
index 5f6738dc190..227d6928baf 100644
--- a/doc/administration/repository_storage_types.md
+++ b/doc/administration/repository_storage_types.md
@@ -10,7 +10,7 @@ that can be:
 
 - Mounted to the local disk
 - Exposed as an NFS shared volume
-- Accessed via [gitaly] on its own machine.
+- Accessed via [Gitaly] on its own machine.
 
 In GitLab, this is configured in `/etc/gitlab/gitlab.rb` by the `git_data_dirs({})`
 configuration hash. The storage layouts discussed here will apply to any shard
diff --git a/doc/administration/restart_gitlab.md b/doc/administration/restart_gitlab.md
index 169a220b9a9..9f95080654f 100644
--- a/doc/administration/restart_gitlab.md
+++ b/doc/administration/restart_gitlab.md
@@ -141,5 +141,5 @@ If you are using other init systems, like systemd, you can check the
 [install]: ../install/installation.md "Documentation to install GitLab from source"
 [mailroom]: reply_by_email.md "Used for replying by email in GitLab issues and merge requests"
 [chef]: https://www.chef.io/products/chef-infra/ "Chef official website"
-[src-service]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/support/init.d/gitlab "GitLab init service file"
+[src-service]: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/support/init.d/gitlab "GitLab init service file"
 [gl-recipes]: https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/init "GitLab Recipes repository"
diff --git a/doc/administration/smime_signing_email.md b/doc/administration/smime_signing_email.md
index 530553ec1c4..60cab22d1f4 100644
--- a/doc/administration/smime_signing_email.md
+++ b/doc/administration/smime_signing_email.md
@@ -1,6 +1,6 @@
 # Signing outgoing email with S/MIME
 
-Notification emails sent by Gitlab can be signed with S/MIME for improved
+Notification emails sent by GitLab can be signed with S/MIME for improved
 security.
 
 > **Note:**
diff --git a/doc/administration/troubleshooting/debug.md b/doc/administration/troubleshooting/debug.md
index 562624fc9dc..3007b711405 100644
--- a/doc/administration/troubleshooting/debug.md
+++ b/doc/administration/troubleshooting/debug.md
@@ -89,10 +89,10 @@ in Omnibus, run as root:
 Many of the tips to diagnose issues below apply to many different situations. We'll use one
 concrete example to illustrate what you can do to learn what is going wrong.
 
-### 502 Gateway Timeout after unicorn spins at 100% CPU
+### 502 Gateway Timeout after Unicorn spins at 100% CPU
 
 This error occurs when the Web server times out (default: 60 s) after not
-hearing back from the unicorn worker. If the CPU spins to 100% while this in
+hearing back from the Unicorn worker. If the CPU spins to 100% while this in
 progress, there may be something taking longer than it should.
 
 To fix this issue, we first need to figure out what is happening. The
@@ -100,7 +100,7 @@ following tips are only recommended if you do NOT mind users being affected by
 downtime. Otherwise skip to the next section.
 
 1. Load the problematic URL
-1. Run `sudo gdb -p <PID>` to attach to the unicorn process.
+1. Run `sudo gdb -p <PID>` to attach to the Unicorn process.
 1. In the gdb window, type:
 
    ```
@@ -135,7 +135,7 @@ downtime. Otherwise skip to the next section.
    exit
    ```
 
-Note that if the unicorn process terminates before you are able to run these
+Note that if the Unicorn process terminates before you are able to run these
 commands, gdb will report an error. To buy more time, you can always raise the
 Unicorn timeout. For omnibus users, you can edit `/etc/gitlab/gitlab.rb` and
 increase it from 60 seconds to 300:
@@ -152,7 +152,7 @@ For source installations, edit `config/unicorn.rb`.
 
 #### Troubleshooting without affecting other users
 
-The previous section attached to a running unicorn process, and this may have
+The previous section attached to a running Unicorn process, and this may have
 undesirable effects for users trying to access GitLab during this time. If you
 are concerned about affecting others during a production system, you can run a
 separate Rails process to debug the issue:
@@ -183,7 +183,7 @@ separate Rails process to debug the issue:
 
 ### GitLab: API is not accessible
 
-This often occurs when gitlab-shell attempts to request authorization via the
+This often occurs when GitLab Shell attempts to request authorization via the
 internal API (e.g., `http://localhost:8080/api/v4/internal/allowed`), and
 something in the check fails. There are many reasons why this may happen:
 
@@ -192,7 +192,7 @@ something in the check fails. There are many reasons why this may happen:
 1. Error accessing the repository (e.g., stale NFS handles)
 
 To diagnose this problem, try to reproduce the problem and then see if there
-is a unicorn worker that is spinning via `top`. Try to use the `gdb`
+is a Unicorn worker that is spinning via `top`. Try to use the `gdb`
 techniques above. In addition, using `strace` may help isolate issues:
 
 ```shell
@@ -211,5 +211,5 @@ The output in `/tmp/unicorn.txt` may help diagnose the root cause.
 
 ## More information
 
-- [Debugging Stuck Ruby Processes](https://blog.newrelic.com/2013/04/29/debugging-stuck-ruby-processes-what-to-do-before-you-kill-9/)
+- [Debugging Stuck Ruby Processes](https://blog.newrelic.com/engineering/debugging-stuck-ruby-processes-what-to-do-before-you-kill-9/)
 - [Cheatsheet of using gdb and ruby processes](gdb-stuck-ruby.txt)
diff --git a/doc/administration/troubleshooting/elasticsearch.md b/doc/administration/troubleshooting/elasticsearch.md
index 13b9c30b29d..37ec32413f8 100644
--- a/doc/administration/troubleshooting/elasticsearch.md
+++ b/doc/administration/troubleshooting/elasticsearch.md
@@ -1,6 +1,6 @@
-# Troubleshooting ElasticSearch
+# Troubleshooting Elasticsearch
 
-Troubleshooting ElasticSearch requires:
+Troubleshooting Elasticsearch requires:
 
 - Knowledge of common terms.
 - Establishing within which category the problem fits.
@@ -30,7 +30,7 @@ The type of problem will determine what steps to take. The possible troubleshoot
 
 ### Search Results workflow
 
-The following workflow is for ElasticSearch search results issues:
+The following workflow is for Elasticsearch search results issues:
 
 ```mermaid
 graph TD;
@@ -42,11 +42,11 @@ graph TD;
   B5 --> |Yes| B6
   B5 --> |No| B7
   B7 --> B8
-  B{Is GitLab using<br>ElasticSearch for<br>searching?}
+  B{Is GitLab using<br>Elasticsearch for<br>searching?}
   B1[Check Admin Area > Integrations<br>to ensure the settings are correct]
   B2[Perform a search via<br>the rails console]
-  B3[If all settings are correct<br>and it still doesn't show ElasticSearch<br>doing the searches, escalate<br>to GitLab support.]
-  B4[Perform<br>the same search via the<br>ElasticSearch API]
+  B3[If all settings are correct<br>and it still doesn't show Elasticsearch<br>doing the searches, escalate<br>to GitLab support.]
+  B4[Perform<br>the same search via the<br>Elasticsearch API]
   B5{Are the results<br>the same?}
   B6[This means it is working as intended.<br>Speak with GitLab support<br>to confirm if the issue lies with<br>the filters.]
   B7[Check the index status of the project<br>containing the missing search<br>results.]
@@ -55,7 +55,7 @@ graph TD;
 
 ### Indexing workflow
 
-The following workflow is for ElasticSearch indexing issues:
+The following workflow is for Elasticsearch indexing issues:
 
 ```mermaid
 graph TD;
@@ -67,7 +67,7 @@ graph TD;
   C --> |No| C6
   C6 --> |No| C10
   C7 --> |GitLab| C8
-  C7 --> |ElasticSearch| C9
+  C7 --> |Elasticsearch| C9
   C6 --> |Yes| C7
   C10 --> |No| C12
   C10 --> |Yes| C11
@@ -76,27 +76,27 @@ graph TD;
   C14 --> |Yes| C15
   C14 --> |No| C16
   C{Is the problem with<br>creating an empty<br>index?}
-  C1{Does the gitlab-production<br>index exist on the<br>ElasticSearch instance?}
-  C2(Try to manually<br>delete the index on the<br>ElasticSearch instance and<br>retry creating an empty index.)
-  C3{Can indices be made<br>manually on the ElasticSearch<br>instance?}
+  C1{Does the gitlab-production<br>index exist on the<br>Elasticsearch instance?}
+  C2(Try to manually<br>delete the index on the<br>Elasticsearch instance and<br>retry creating an empty index.)
+  C3{Can indices be made<br>manually on the Elasticsearch<br>instance?}
   C4(Retry the creation of an empty index)
-  C5(It is best to speak with an<br>ElasticSearch admin concerning the<br>instance's inability to create indices.)
+  C5(It is best to speak with an<br>Elasticsearch admin concerning the<br>instance's inability to create indices.)
   C6{Is the indexer presenting<br>errors during indexing?}
-  C7{Is the error a GitLab<br>error or an ElasticSearch<br>error?}
+  C7{Is the error a GitLab<br>error or an Elasticsearch<br>error?}
   C8[Escalate to<br>GitLab support]
-  C9[You will want<br>to speak with an<br>ElasticSearch admin.]
+  C9[You will want<br>to speak with an<br>Elasticsearch admin.]
   C10{Does the index status<br>show 100%?}
   C11[Escalate to<br>GitLab support]
   C12{Does re-indexing the project<br> present any GitLab errors?}
   C13[Rectify the GitLab errors and<br>restart troubleshooting, or<br>escalate to GitLab support.]
-  C14{Does re-indexing the project<br>present errors on the <br>ElasticSearch instance?}
-  C15[It would be best<br>to speak with an<br>ElasticSearch admin.]
+  C14{Does re-indexing the project<br>present errors on the <br>Elasticsearch instance?}
+  C15[It would be best<br>to speak with an<br>Elasticsearch admin.]
   C16[This is likely a bug/issue<br>in GitLab and will require<br>deeper investigation. Escalate<br>to GitLab support.]
 ```
 
 ### Integration workflow
 
-The following workflow is for ElasticSearch integration issues:
+The following workflow is for Elasticsearch integration issues:
 
 ```mermaid
 graph TD;
@@ -107,7 +107,7 @@ graph TD;
   D4 --> |No| D5
   D4 --> |Yes| D6
   D{Is the error concerning<br>the beta indexer?}
-  D1[It would be best<br>to speak with an<br>ElasticSearch admin.]
+  D1[It would be best<br>to speak with an<br>Elasticsearch admin.]
   D2{Is the ICU development<br>package installed?}
   D3>This package is required.<br>Install the package<br>and retry.]
   D4{Is the error stemming<br>from the indexer?}
@@ -117,7 +117,7 @@ graph TD;
 
 ### Performance workflow
 
-The following workflow is for ElasticSearch performance issues:
+The following workflow is for Elasticsearch performance issues:
 
 ```mermaid
 graph TD;
@@ -128,19 +128,19 @@ graph TD;
   F4 --> F5
   F5 --> |No| F6
   F5 --> |Yes| F7
-  F{Is the ElasticSearch instance<br>running on the same server<br>as the GitLab instance?}
-  F1(This is not advised and will cause issues.<br>We recommend moving the ElasticSearch<br>instance to a different server.)
-  F2{Does the ElasticSearch<br>server have at least 8<br>GB of RAM and 2 CPU<br>cores?}
-  F3(According to ElasticSearch, a non-prod<br>server needs these as a base requirement.<br>Production often requires more. We recommend<br>you increase the server specifications.)
+  F{Is the Elasticsearch instance<br>running on the same server<br>as the GitLab instance?}
+  F1(This is not advised and will cause issues.<br>We recommend moving the Elasticsearch<br>instance to a different server.)
+  F2{Does the Elasticsearch<br>server have at least 8<br>GB of RAM and 2 CPU<br>cores?}
+  F3(According to Elasticsearch, a non-prod<br>server needs these as a base requirement.<br>Production often requires more. We recommend<br>you increase the server specifications.)
   F4(Obtain the <br>cluster health information)
   F5(Does it show the<br>status as green?)
-  F6(We recommend you speak with<br>an ElasticSearch admin<br>about implementing sharding.)
+  F6(We recommend you speak with<br>an Elasticsearch admin<br>about implementing sharding.)
   F7(Escalate to<br>GitLab support.)
 ```
 
 ## Troubleshooting walkthrough
 
-Most ElasticSearch troubleshooting can be broken down into 4 categories:
+Most Elasticsearch troubleshooting can be broken down into 4 categories:
 
 - [Troubleshooting search results](#troubleshooting-search-results)
 - [Troubleshooting indexing](#troubleshooting-indexing)
@@ -150,19 +150,19 @@ Most ElasticSearch troubleshooting can be broken down into 4 categories:
 Generally speaking, if it does not fall into those four categories, it is either:
 
 - Something GitLab support needs to look into.
-- Not a true ElasticSearch issue.
+- Not a true Elasticsearch issue.
 
-Exercise caution. Issues that appear to be ElasticSearch problems can be OS-level issues.
+Exercise caution. Issues that appear to be Elasticsearch problems can be OS-level issues.
 
 ### Troubleshooting search results
 
-Troubleshooting search result issues is rather straight forward on ElasticSearch.
+Troubleshooting search result issues is rather straight forward on Elasticsearch.
 
-The first step is to confirm GitLab is using ElasticSearch for the search function.
+The first step is to confirm GitLab is using Elasticsearch for the search function.
 To do this:
 
 1. Confirm the integration is enabled in **Admin Area > Settings > Integrations**.
-1. Confirm searches utilize ElasticSearch by accessing the rails console
+1. Confirm searches utilize Elasticsearch by accessing the rails console
    (`sudo gitlab-rails console`) and running the following commands:
 
    ```rails
@@ -173,21 +173,21 @@ To do this:
 
 The ouput from the last command is the key here. If it shows:
 
-- `ActiveRecord::Relation`, **it is not** using ElasticSearch.
-- `Kaminari::PaginatableArray`, **it is** using ElasticSearch.
+- `ActiveRecord::Relation`, **it is not** using Elasticsearch.
+- `Kaminari::PaginatableArray`, **it is** using Elasticsearch.
 
-| Not using ElasticSearch  | Using ElasticSearch          |
+| Not using Elasticsearch  | Using Elasticsearch          |
 |--------------------------|------------------------------|
 | `ActiveRecord::Relation` | `Kaminari::PaginatableArray` |
 
-If all the settings look correct and it is still not using ElasticSearch for the search function, it is best to escalate to GitLab support. This could be a bug/issue.
+If all the settings look correct and it is still not using Elasticsearch for the search function, it is best to escalate to GitLab support. This could be a bug/issue.
 
-Moving past that, it is best to attempt the same search using the [ElasticSearch Search API](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-search.html) and compare the results from what you see in GitLab.
+Moving past that, it is best to attempt the same search using the [Elasticsearch Search API](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-search.html) and compare the results from what you see in GitLab.
 
 If the results:
 
 - Sync up, then there is not a technical "issue" per se. Instead, it might be a problem
-  with the ElasticSearch filters we are using. This can be complicated, so it is best to
+  with the Elasticsearch filters we are using. This can be complicated, so it is best to
   escalate to GitLab support to check these and guide you on the potential on whether or
   not a feature request is needed.
 - Do not match up, this indicates a problem with the documents generated from the
@@ -197,20 +197,20 @@ If the results:
 ### Troubleshooting indexing
 
 Troubleshooting indexing issues can be tricky. It can pretty quickly go to either GitLab
-support or your ElasticSearch admin.
+support or your Elasticsearch admin.
 
 The best place to start is to determine if the issue is with creating an empty index.
-If it is, check on the ElasticSearch side to determine if the `gitlab-production` (the
-name for the GitLab index) exists. If it exists, manually delete it on the ElasticSearch
+If it is, check on the Elasticsearch side to determine if the `gitlab-production` (the
+name for the GitLab index) exists. If it exists, manually delete it on the Elasticsearch
 side and attempt to recreate it from the
 [`create_empty_index`](../../integration/elasticsearch.md#gitlab-elasticsearch-rake-tasks)
 rake task.
 
-If you still encounter issues, try creating an index manually on the ElasticSearch
+If you still encounter issues, try creating an index manually on the Elasticsearch
 instance. The details of the index aren't important here, as we want to test if indices
 can be made. If the indices:
 
-- Cannot be made, speak with your ElasticSearch admin.
+- Cannot be made, speak with your Elasticsearch admin.
 - Can be made, Escalate this to GitLab support.
 
 If the issue is not with creating an empty index, the next step is to check for errors
@@ -218,7 +218,7 @@ during the indexing of projects. If errors do occur, they will either stem from
 
 - On the GitLab side. You need to rectify those. If they are not
   something you are familiar with, contact GitLab support for guidance.
-- Within the ElasticSearch instance itself. See if the error is [documented and has a fix](../../integration/elasticsearch.md#troubleshooting). If not, speak with your ElasticSearch admin.
+- Within the Elasticsearch instance itself. See if the error is [documented and has a fix](../../integration/elasticsearch.md#troubleshooting). If not, speak with your Elasticsearch admin.
 
 If the indexing process does not present errors, you will want to check the status of the indexed projects. You can do this via the following rake tasks:
 
@@ -235,8 +235,8 @@ If:
 If reindexing the project shows:
 
 - Errors on the GitLab side, escalate those to GitLab support.
-- ElasticSearch errors or doesn't present any errors at all, reach out to your
-  ElasticSearch admin to check the instance.
+- Elasticsearch errors or doesn't present any errors at all, reach out to your
+  Elasticsearch admin to check the instance.
 
 ### Troubleshooting integration
 
@@ -246,7 +246,7 @@ much to "integrate" here.
 If the issue is:
 
 - Not concerning the beta indexer, it is almost always an
-  ElasticSearch-side issue. This means you should reach out to your ElasticSearch admin
+  Elasticsearch-side issue. This means you should reach out to your Elasticsearch admin
   regarding the error(s) you are seeing. If you are unsure here, it never hurts to reach
   out to GitLab support.
 - With the beta indexer, check if the ICU development package is installed.
@@ -260,48 +260,48 @@ Beyond that, you will want to review the error. If it is:
 
 ### Troubleshooting performance
 
-Troubleshooting performance can be difficult on ElasticSearch. There is a ton of tuning
+Troubleshooting performance can be difficult on Elasticsearch. There is a ton of tuning
 that *can* be done, but the majority of this falls on shoulders of a skilled
-ElasticSearch administrator.
+Elasticsearch administrator.
 
 Generally speaking, ensure:
 
-- The ElasticSearch server **is not** running on the same node as GitLab.
-- The ElasticSearch server have enough RAM and CPU cores.
+- The Elasticsearch server **is not** running on the same node as GitLab.
+- The Elasticsearch server have enough RAM and CPU cores.
 - That sharding **is** being used.
 
-Going into some more detail here, if ElasticSearch is running on the same server as GitLab, resource contention is **very** likely to occur. Ideally, ElasticSearch, which requires ample resources, should be running on its own server (maybe coupled with logstash and kibana).
+Going into some more detail here, if Elasticsearch is running on the same server as GitLab, resource contention is **very** likely to occur. Ideally, Elasticsearch, which requires ample resources, should be running on its own server (maybe coupled with logstash and kibana).
 
-When it comes to ElasticSearch, RAM is the key resource. ElasticSearch themselves recommend:
+When it comes to Elasticsearch, RAM is the key resource. Elasticsearch themselves recommend:
 
 - **At least** 8 GB of RAM for a non-production instance.
 - **At least** 16 GB of RAM for a production instance.
 - Ideally, 64 GB of RAM.
 
-For CPU, ElasticSearch recommends at least 2 CPU cores, but ElasticSearch states common
+For CPU, Elasticsearch recommends at least 2 CPU cores, but Elasticsearch states common
 setups use up to 8 cores. For more details on server specs, check out
-[ElasticSearch's hardware guide](https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html).
+[Elasticsearch's hardware guide](https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html).
 
-Beyond the obvious, sharding comes into play. Sharding is a core part of ElasticSearch.
+Beyond the obvious, sharding comes into play. Sharding is a core part of Elasticsearch.
 It allows for horizontal scaling of indices, which is helpful when you are dealing with
 a large amount of data.
 
 With the way GitLab does indexing, there is a **huge** amount of documents being
-indexed. By utilizing sharding, you can speed up ElasticSearch's ability to locate
+indexed. By utilizing sharding, you can speed up Elasticsearch's ability to locate
 data, since each shard is a Lucene index.
 
 If you are not using sharding, you are likely to hit issues when you start using
-ElasticSearch in a production environment.
+Elasticsearch in a production environment.
 
 Keep in mind that an index with only one shard has **no scale factor** and will
 likely encounter issues when called upon with some frequency.
 
 If you need to know how many shards, read
-[ElasticSearch's documentation on capacity planning](https://www.elastic.co/guide/en/elasticsearch/guide/2.x/capacity-planning.html),
+[Elasticsearch's documentation on capacity planning](https://www.elastic.co/guide/en/elasticsearch/guide/2.x/capacity-planning.html),
 as the answer is not straight forward.
 
 The easiest way to determine if sharding is in use is to check the output of the
-[ElasticSearch Health API](https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html):
+[Elasticsearch Health API](https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html):
 
 - Red means the cluster is down.
 - Yellow means it is up with no sharding/replication.
@@ -311,11 +311,11 @@ For production use, it should always be green.
 
 Beyond these steps, you get into some of the more complicated things to check,
 such as merges and caching. These can get complicated and it takes some time to
-learn them, so it is best to escalate/pair with an ElasticSearch expert if you need to
+learn them, so it is best to escalate/pair with an Elasticsearch expert if you need to
 dig further into these.
 
 Feel free to reach out to GitLab support, but this is likely to be something a skilled
-ElasticSearch admin has more experience with.
+Elasticsearch admin has more experience with.
 
 ## Common issues
 
@@ -324,12 +324,12 @@ feel free to update that page with issues you encounter and solutions.
 
 ## Replication
 
-Setting up ElasticSearch isn't too bad, but it can be a bit finnicky and time consuming.
+Setting up Elasticsearch isn't too bad, but it can be a bit finnicky and time consuming.
 
 The eastiest method is to spin up a docker container with the required version and
 bind ports 9200/9300 so it can be used.
 
-The following is an example of running a docker container of ElasticSearch v7.2.0:
+The following is an example of running a docker container of Elasticsearch v7.2.0:
 
 ```bash
 docker pull docker.elastic.co/elasticsearch/elasticsearch:7.2.0
@@ -341,5 +341,5 @@ From here, you can:
 - Grab the IP of the docker container (use `docker inspect <container_id>`)
 - Use `<IP.add.re.ss:9200>` to communicate with it.
 
-This is a quick method to test out ElasticSearch, but by no means is this a
+This is a quick method to test out Elasticsearch, but by no means is this a
 production solution.
diff --git a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
index a064dfbfbe2..34a5acbe7b7 100644
--- a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
+++ b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
@@ -4,7 +4,7 @@ type: reference
 
 # GitLab Rails Console Cheat Sheet
 
-This is the GitLab Support Team's collection of information regarding the GitLab rails
+This is the GitLab Support Team's collection of information regarding the GitLab Rails
 console, for use while troubleshooting. It is listed here for transparency,
 and it may be useful for users with experience with these tools. If you are currently
 having an issue with GitLab, it is highly recommended that you check your
@@ -556,6 +556,14 @@ parent.members_with_descendants.count
 GroupDestroyWorker.perform_async(group_id, user_id)
 ```
 
+### Modify group project creation
+
+```ruby
+# Project creation levels: 0 - No one, 1 - Maintainers, 2 - Developers + Maintainers
+group = Group.find_by_path_or_name('group-name')
+group.project_creation_level=0
+```
+
 ## LDAP
 
 ### LDAP commands in the rails console
@@ -680,6 +688,15 @@ u = User.find_by_username('')
 MergeRequests::PostMergeService.new(p, u).execute(m)
 ```
 
+### Delete a merge request
+
+```ruby
+u = User.find_by_username('<username>')
+p = Project.find_by_full_path('<group>/<project>')
+m = p.merge_requests.find_by(iid: <IID>)
+Issuable::DestroyService.new(m.project, u).execute(m)
+```
+
 ### Rebase manually
 
 ```ruby
@@ -693,7 +710,8 @@ MergeRequests::RebaseService.new(m.target_project, u).execute(m)
 
 ### Cancel stuck pending pipelines
 
-See <https://gitlab.com/gitlab-com/support-forum/issues/2449#note_41929707>.
+For more information, see the [confidential issue](../../user/project/issues/confidential_issues.md)
+`https://gitlab.com/gitlab-com/support-forum/issues/2449#note_41929707`.
 
 ```ruby
 Ci::Pipeline.where(project_id: p.id).where(status: 'pending').count
@@ -715,13 +733,15 @@ Namespace.find_by_full_path("user/proj").namespace_statistics.update(shared_runn
 project = Project.find_by_full_path('')
 builds_with_artifacts =  project.builds.with_artifacts_archive
 
-# Prior to 10.6 the above line would be:
-# builds_with_artifacts = project.builds.with_artifacts
-
 # Instance-wide:
-builds_with_artifacts = Ci::Build.with_artifacts
+builds_with_artifacts = Ci::Build.with_artifacts_archive
+
+# Prior to 10.6 the above lines would be:
+# builds_with_artifacts =  project.builds.with_artifacts
+# builds_with_artifacts = Ci::Build.with_artifacts
 
 ### CLEAR THEM OUT
+# Note that this will also erase artifacts that developers marked to "Keep"
 builds_to_clear = builds_with_artifacts.where("finished_at < ?", 1.week.ago)
 builds_to_clear.each do |build|
   build.artifacts_expire_at = Time.now
@@ -812,7 +832,7 @@ License.current # check to make sure it applied
 
 From [Zendesk ticket #91083](https://gitlab.zendesk.com/agent/tickets/91083) (internal)
 
-### Poll unicorn requests by seconds
+### Poll Unicorn requests by seconds
 
 ```ruby
 require 'rubygems'
@@ -872,6 +892,23 @@ queue = Sidekiq::Queue.new('repository_import')
 queue.each { |job| job.delete if <condition>}
 ```
 
+`<condition>` probably includes references to job arguments, which depend on the type of job in question.
+
+| queue | worker | job args |
+| ----- | ------ | -------- |
+| repository_import | RepositoryImportWorker | project_id |
+| update_merge_requests | UpdateMergeRequestsWorker | project_id, user_id, oldrev, newrev, ref |
+
+**Example:** Delete all UpdateMergeRequestsWorker jobs associated with a merge request on project_id 125,
+merging branch `ref/heads/my_branch`.
+
+```ruby
+queue = Sidekiq::Queue.new('update_merge_requests')
+queue.each { |job| job.delete if job.args[0]==125 and job.args[4]=='ref/heads/my_branch'}
+```
+
+**Note:** Running jobs will not be killed. Stop sidekiq before doing this, to get all matching jobs.
+
 ### Enable debug logging of Sidekiq
 
 ```ruby
@@ -888,13 +925,13 @@ See <https://github.com/mperham/sidekiq/wiki/Signals#ttin>.
 
 ## Redis
 
-### Connect to redis (omnibus)
+### Connect to Redis (omnibus)
 
 ```sh
 /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket
 ```
 
-### Connect to redis (HA)
+### Connect to Redis (HA)
 
 ```sh
 /opt/gitlab/embedded/bin/redis-cli -h <host ip> -a <password>
diff --git a/doc/administration/troubleshooting/kubernetes_cheat_sheet.md b/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
index 1247060058b..7c2c2050b12 100644
--- a/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
+++ b/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
@@ -15,7 +15,7 @@ If you are on a [paid tier](https://about.gitlab.com/pricing/) and are not sure
 to use these commands, it is best to [contact Support](https://about.gitlab.com/support/)
 and they will assist you with any issues you are having.
 
-## Generic kubernetes commands
+## Generic Kubernetes commands
 
 - How to authorize to your GCP project (can be especially useful if you have projects
   under different GCP accounts):
@@ -33,7 +33,7 @@ and they will assist you with any issues you are having.
   kubectl proxy
   ```
 
-- How to ssh to a Kubernetes node and enter the container as root
+- How to SSH to a Kubernetes node and enter the container as root
   <https://github.com/kubernetes/kubernetes/issues/30656>:
 
   - For GCP, you may find the node name and run `gcloud compute ssh node-name`.
@@ -72,12 +72,12 @@ and they will assist you with any issues you are having.
   This is the principle of Kubernetes, read [Twelve-factor app](https://12factor.net/)
   for details.
 
-## GitLab-specific kubernetes information
+## GitLab-specific Kubernetes information
 
-- Minimal config that can be used to test a Kubernetes helm chart can be found
+- Minimal config that can be used to test a Kubernetes Helm chart can be found
   [here](https://gitlab.com/gitlab-org/charts/gitlab/issues/620).
 
-- Tailing logs of a separate pod. An example for a unicorn pod:
+- Tailing logs of a separate pod. An example for a Unicorn pod:
 
   ```bash
   kubectl logs gitlab-unicorn-7656fdd6bf-jqzfs -c unicorn
@@ -101,7 +101,7 @@ and they will assist you with any issues you are having.
   ```
 
 - Check all events in the `gitlab` namespace (the namespace name can be different if you
-  specified a different one when deploying the helm chart):
+  specified a different one when deploying the Helm chart):
 
   ```bash
   kubectl get events -w --namespace=gitlab
@@ -140,8 +140,8 @@ and they will assist you with any issues you are having.
 
   - Check the output of `kubectl get events -w --all-namespaces`.
   - Check the logs of pods within `gitlab-managed-apps` namespace.
-  - On the side of GitLab check sidekiq log and kubernetes log. When GitLab is installed
-    via Helm Chart, `kubernetes.log` can be found inside the sidekiq pod.
+  - On the side of GitLab check Sidekiq log and Kubernetes log. When GitLab is installed
+    via Helm Chart, `kubernetes.log` can be found inside the Sidekiq pod.
 
 - How to get your initial admin password <https://docs.gitlab.com/charts/installation/deployment.html#initial-login>:
 
@@ -191,8 +191,8 @@ and they will assist you with any issues you are having.
 
 ## Installation of minimal GitLab config via Minukube on macOS
 
-This section is based on [Developing for Kubernetes with Minikube](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/doc/minikube/index.md)
-and [Helm](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/doc/helm/index.md). Refer
+This section is based on [Developing for Kubernetes with Minikube](https://docs.gitlab.com/charts/development/minikube/index.html)
+and [Helm](https://docs.gitlab.com/charts/installation/tools.html#helm). Refer
 to those documents for details.
 
 - Install Kubectl via Homebrew:
diff --git a/doc/administration/troubleshooting/postgresql.md b/doc/administration/troubleshooting/postgresql.md
new file mode 100644
index 00000000000..f427cd88ce0
--- /dev/null
+++ b/doc/administration/troubleshooting/postgresql.md
@@ -0,0 +1,146 @@
+---
+type: reference
+---
+
+# PostgreSQL
+
+This page is useful information about PostgreSQL that the GitLab Support
+Team sometimes uses while troubleshooting. GitLab is making this public, so that anyone
+can make use of the Support team's collected knowledge.
+
+CAUTION: **Caution:** Some procedures documented here may break your GitLab instance. Use at your own risk.
+
+If you are on a [paid tier](https://about.gitlab.com/pricing/) and are not sure how
+to use these commands, it is best to [contact Support](https://about.gitlab.com/support/)
+and they will assist you with any issues you are having.
+
+## Other GitLab PostgreSQL documentation
+
+This section is for links to information elsewhere in the GitLab documentation.
+
+### Procedures
+
+- [Connect to the PostgreSQL console.](https://docs.gitlab.com/omnibus/settings/database.html#connecting-to-the-bundled-postgresql-database)
+
+- [Omnibus database procedures](https://docs.gitlab.com/omnibus/settings/database.html) including
+  - SSL: enabling, disabling, and verifying.
+  - Enabling Write Ahead Log (WAL) archiving.
+  - Using an external (non-Omnibus) PostgreSQL installation; and backing it up.
+  - Listening on TCP/IP as well as or instead of sockets.
+  - Storing data in another location.
+  - Destructively reseeding the GitLab database.
+  - Guidance around updating packaged PostgreSQL, including how to stop it happening automatically.
+
+- [More about external PostgreSQL](../external_database.md)
+
+- [Running GEO with external PostgreSQL](../geo/replication/external_database.md)
+
+- [Upgrades when running PostgreSQL configured for HA.](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-gitlab-ha-cluster)
+
+- Consuming PostgreSQL from [within CI runners](../../ci/services/postgres.md)
+
+- [Using Slony to update PostgreSQL](../../update/upgrading_postgresql_using_slony.md)
+  - Uses replication to handle PostgreSQL upgrades - providing the schemas are the same.
+  - Reduces downtime to a short window for swinging over to the newer vewrsion.
+
+- Managing Omnibus PostgreSQL versions [from the development docs](https://docs.gitlab.com/omnibus/development/managing-postgresql-versions.html)
+
+- [PostgreSQL scaling and HA](../high_availability/database.md)
+  - including [troubleshooting](../high_availability/database.md#troubleshooting) gitlab-ctl repmgr-check-master and pgbouncer errors
+
+- [Developer database documentation](../../development/README.md#database-guides) - some of which is absolutely not for production use. Including:
+  - understanding EXPLAIN plans
+
+### Troubleshooting/Fixes
+
+- [GitLab database requirements](../../install/requirements.md#database) including
+  - Support for MySQL was removed in GitLab 12.1; [migrate to PostgreSQL](../../update/mysql_to_postgresql.md)
+  - required extension pg_trgm
+  - required extension postgres_fdw for Geo
+
+- Errors like this in the production/sidekiq log;  see: [Set default_transaction_isolation into read committed](https://docs.gitlab.com/omnibus/settings/database.html#set-default_transaction_isolation-into-read-committed)
+
+```
+ActiveRecord::StatementInvalid PG::TRSerializationFailure: ERROR:  could not serialize access due to concurrent update
+```
+
+- PostgreSQL HA - [replication slot errors](https://docs.gitlab.com/omnibus/settings/database.html#troubleshooting-upgrades-in-an-ha-cluster)
+
+```
+pg_basebackup: could not create temporary replication slot "pg_basebackup_12345": ERROR:  all replication slots are in use
+HINT:  Free one or increase max_replication_slots.
+```
+
+- GEO [replication errors](../geo/replication/troubleshooting.md#fixing-replication-errors) including:
+
+```
+ERROR: replication slots can only be used if max_replication_slots > 0
+
+FATAL: could not start WAL streaming: ERROR: replication slot “geo_secondary_my_domain_com” does not exist
+
+Command exceeded allowed execution time
+
+PANIC: could not write to file ‘pg_xlog/xlogtemp.123’: No space left on device
+```
+
+- [Checking GEO configuration](../geo/replication/troubleshooting.md#checking-configuration) including
+  - reconfiguring hosts/ports
+  - checking and fixing user/password mappings
+
+- [Common GEO errors](../geo/replication/troubleshooting.md#fixing-common-errors)
+
+## Support topics
+
+### Database deadlocks
+
+References:
+
+- [Issue #1 Deadlocks with GitLab 12.1, PostgreSQL 10.7](https://gitlab.com/gitlab-org/gitlab/issues/30528)
+- [Customer ticket (internal) GitLab 12.1.6](https://gitlab.zendesk.com/agent/tickets/134307) and [google doc (internal)](https://docs.google.com/document/d/19xw2d_D1ChLiU-MO1QzWab-4-QXgsIUcN5e_04WTKy4)
+- [Issue #2 deadlocks can occur if an instance is flooded with pushes](https://gitlab.com/gitlab-org/gitlab/issues/33650). Provided for context about how GitLab code can have this sort of unanticipated effect in unusual situations.
+
+```
+ERROR: deadlock detected
+```
+
+Three applicable timeouts are identified in the issue [#1](https://gitlab.com/gitlab-org/gitlab/issues/30528); our recommended settings are as follows:
+
+```
+deadlock_timeout = 5s
+statement_timeout = 15s
+idle_in_transaction_session_timeout = 60s
+```
+
+Quoting from from issue [#1](https://gitlab.com/gitlab-org/gitlab/issues/30528):
+
+> "If a deadlock is hit, and we resolve it through aborting the transaction after a short period, then the retry mechanisms we already have will make the deadlocked piece of work try again, and it's unlikely we'll deadlock multiple times in a row."
+
+TIP: **Tip:** In support, our general approach to reconfiguring timeouts (applies also to the HTTP stack as well) is that it's acceptable to do it temporarily as a workaround. If it makes GitLab usable for the customer, then it buys time to understand the problem more completely, implement a hot fix, or make some other change that addresses the root cause. Generally, the timeouts should be put back to reasonable defaults once the root cause is resolved.
+
+In this case, the guidance we had from development was to drop deadlock_timeout and/or statement_timeout but to leave the third setting at 60s. Setting idle_in_transaction protects the database from sessions potentially hanging for days. There's more discussion in [the issue relating to introducing this timeout on gitlab.com.](https://gitlab.com/gitlab-com/gl-infra/production/issues/1053)
+
+PostgresSQL defaults:
+
+- statement_timeout = 0 (never)
+- idle_in_transaction_session_timeout = 0 (never)
+
+Comments in issue [#1](https://gitlab.com/gitlab-org/gitlab/issues/30528) indicate that these should both be set to at least a number of minutes for all Omnibus installations (so they don't hang indefinitely). However, 15s for statement_timeout is very short, and will only be effective if the underlying infrastructure is very performant.
+
+See current settings with:
+
+```
+sudo gitlab-rails runner "c = ApplicationRecord.connection ; puts c.execute('SHOW statement_timeout').to_a ;
+puts c.execute('SHOW lock_timeout').to_a ;
+puts c.execute('SHOW idle_in_transaction_session_timeout').to_a ;"
+```
+
+It may take a little while to respond.
+
+```
+{"statement_timeout"=>"1min"}
+{"lock_timeout"=>"0"}
+{"idle_in_transaction_session_timeout"=>"1min"}
+```
+
+NOTE: **Note:**
+These are Omnibus settings. If an external database, such as a customer's PostgreSQL installation or Amazon RDS is being used, these values don't get set, and would have to be set externally.
diff --git a/doc/administration/troubleshooting/sidekiq.md b/doc/administration/troubleshooting/sidekiq.md
index fdafac8420e..41657368ea4 100644
--- a/doc/administration/troubleshooting/sidekiq.md
+++ b/doc/administration/troubleshooting/sidekiq.md
@@ -238,7 +238,7 @@ workers.each do |process_id, thread_id, work|
 end
 ```
 
-### Remove sidekiq jobs for given parameters (destructive)
+### Remove Sidekiq jobs for given parameters (destructive)
 
 ```ruby
 # for jobs like this:
diff --git a/doc/administration/troubleshooting/test_environments.md b/doc/administration/troubleshooting/test_environments.md
index f1cdaf580a3..d0f670a5663 100644
--- a/doc/administration/troubleshooting/test_environments.md
+++ b/doc/administration/troubleshooting/test_environments.md
@@ -49,7 +49,7 @@ gitlab/gitlab-ee:11.5.3-ee.0
 
 #### SAML for Authentication
 
-We can use the [test-saml-idp Docker image](https://hub.docker.com/r/jamedjo/test-saml-idp)
+We can use the [`test-saml-idp` Docker image](https://hub.docker.com/r/jamedjo/test-saml-idp)
 to do the work for us:
 
 ```sh
@@ -91,7 +91,7 @@ gitlab_rails['omniauth_providers'] = [
 
 See [the GDK SAML documentation](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/saml.md).
 
-### ElasticSearch
+### Elasticsearch
 
 ```sh
 docker run -d --name elasticsearch \
@@ -101,7 +101,7 @@ docker.elastic.co/elasticsearch/elasticsearch:5.5.1
 ```
 
 Then confirm it works in the browser at `curl http://<IP_ADDRESS>:9200/_cat/health`.
-ElasticSearch's default username is `elastic` and password is `changeme`.
+Elasticsearch's default username is `elastic` and password is `changeme`.
 
 ### PlantUML
 
diff --git a/doc/administration/uploads.md b/doc/administration/uploads.md
index c6dadbb500b..04cebe568f3 100644
--- a/doc/administration/uploads.md
+++ b/doc/administration/uploads.md
@@ -81,7 +81,7 @@ The connection settings match those provided by [Fog](https://github.com/fog), a
 | `enable_signature_v4_streaming` | Set to true to enable HTTP chunked transfers with [AWS v4 signatures](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-streaming.html). Oracle Cloud S3 needs this to be false | true |
 | `region` | AWS region | us-east-1 |
 | `host` | S3 compatible host for when not using AWS, e.g. `localhost` or `storage.example.com` | s3.amazonaws.com |
-| `endpoint` | Can be used when configuring an S3 compatible service such as [Minio](https://www.minio.io), by entering a URL such as `http://127.0.0.1:9000` | (optional) |
+| `endpoint` | Can be used when configuring an S3 compatible service such as [MinIO](https://min.io), by entering a URL such as `http://127.0.0.1:9000` | (optional) |
 | `path_style` | Set to true to use `host/bucket_name/object` style paths instead of `bucket_name.host/object`. Leave as false for AWS S3 | false |
 | `use_iam_profile` | Set to true to use IAM profile instead of access keys | false
 
@@ -165,7 +165,7 @@ The connection settings match those provided by [Fog](https://github.com/fog), a
 |---------|-------------|---------|
 | `provider` | Always `OpenStack` for compatible hosts | OpenStack |
 | `openstack_username` | OpenStack username | |
-| `openstack_api_key` | OpenStack api key  | |
+| `openstack_api_key` | OpenStack API key  | |
 | `openstack_temp_url_key` | OpenStack key for generating temporary urls | |
 | `openstack_auth_url` | OpenStack authentication endpont | |
 | `openstack_region` | OpenStack region | |
diff --git a/doc/api/README.md b/doc/api/README.md
index d037ab1a95f..6858e5b7d56 100644
--- a/doc/api/README.md
+++ b/doc/api/README.md
@@ -329,7 +329,7 @@ curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab
 
 ### Pagination Link header
 
-[Link headers](http://www.w3.org/wiki/LinkHeader) are sent back with each
+[Link headers](https://www.w3.org/wiki/LinkHeader) are sent back with each
 response. They have `rel` set to prev/next/first/last and contain the relevant
 URL. Please use these links instead of generating your own URLs.
 
@@ -563,7 +563,7 @@ The correct encoding for the query parameter would be:
 ## Clients
 
 There are many unofficial GitLab API Clients for most of the popular
-programming languages. Visit the [GitLab website] for a complete list.
+programming languages. Visit the [GitLab website](https://about.gitlab.com/partners/#api-clients) for a complete list.
 
 ## Rate limits
 
@@ -572,7 +572,6 @@ For administrator documentation on rate limit settings, see
 specifically used by GitLab.com, see
 [GitLab.com-specific rate limits](../user/gitlab_com/index.md#gitlabcom-specific-rate-limits).
 
-[GitLab website]: https://about.gitlab.com/applications/#api-clients "Clients using the GitLab API"
 [lib-api-url]: https://gitlab.com/gitlab-org/gitlab-foss/tree/master/lib/api/api.rb
 [ce-3749]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/3749
 [ce-5951]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/5951
diff --git a/doc/api/access_requests.md b/doc/api/access_requests.md
index 973c3968d90..584a4ecb89c 100644
--- a/doc/api/access_requests.md
+++ b/doc/api/access_requests.md
@@ -6,7 +6,7 @@
 
  The access levels are defined in the `Gitlab::Access` module. Currently, these levels are recognized:
 
-```
+```plaintext
 10 => Guest access
 20 => Reporter access
 30 => Developer access
@@ -18,14 +18,16 @@
 
 Gets a list of access requests viewable by the authenticated user.
 
-```
+```plaintext
 GET /groups/:id/access_requests
 GET /projects/:id/access_requests
 ```
 
-| Attribute | Type | Required | Description |
-| --------- | ---- | -------- | ----------- |
-| `id`      | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
+| Attribute | Type           | Required | Description |
+| --------- | -------------- | -------- | ----------- |
+| `id`      | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
+
+Example request:
 
 ```bash
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/:id/access_requests
@@ -59,14 +61,16 @@ Example response:
 
 Requests access for the authenticated user to a group or project.
 
-```
+```plaintext
 POST /groups/:id/access_requests
 POST /projects/:id/access_requests
 ```
 
-| Attribute | Type | Required | Description |
-| --------- | ---- | -------- | ----------- |
-| `id`      | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
+| Attribute | Type           | Required | Description |
+| --------- | -------------- | -------- | ----------- |
+| `id`      | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
+
+Example request:
 
 ```bash
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/:id/access_requests
@@ -90,16 +94,18 @@ Example response:
 
 Approves an access request for the given user.
 
-```
+```plaintext
 PUT /groups/:id/access_requests/:user_id/approve
 PUT /projects/:id/access_requests/:user_id/approve
 ```
 
-| Attribute | Type | Required | Description |
-| --------- | ---- | -------- | ----------- |
-| `id`      | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
-| `user_id` | integer | yes   | The user ID of the access requester |
-| `access_level` | integer | no | A valid access level (defaults: `30`, developer access level) |
+| Attribute      | Type           | Required | Description |
+| -------------- | -------------- | -------- | ----------- |
+| `id`           | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
+| `user_id`      | integer        | yes      | The user ID of the access requester                                                                             |
+| `access_level` | integer        | no       | A valid access level (defaults: `30`, developer access level)                                                   |
+
+Example request:
 
 ```bash
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/:id/access_requests/:user_id/approve?access_level=20
@@ -123,15 +129,17 @@ Example response:
 
 Denies an access request for the given user.
 
-```
+```plaintext
 DELETE /groups/:id/access_requests/:user_id
 DELETE /projects/:id/access_requests/:user_id
 ```
 
-| Attribute | Type | Required | Description |
-| --------- | ---- | -------- | ----------- |
-| `id`      | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
-| `user_id` | integer | yes   | The user ID of the access requester |
+| Attribute | Type           | Required | Description |
+| --------- | -------------- | -------- | ----------- |
+| `id`      | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
+| `user_id` | integer        | yes      | The user ID of the access requester                                                                             |
+
+Example request:
 
 ```bash
 curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/:id/access_requests/:user_id
diff --git a/doc/api/api_resources.md b/doc/api/api_resources.md
index e2ddc2cbc18..232a9825691 100644
--- a/doc/api/api_resources.md
+++ b/doc/api/api_resources.md
@@ -104,6 +104,7 @@ The following API resources are available outside of project and group contexts
 | Resource                                          | Available endpoints                                                     |
 |:--------------------------------------------------|:------------------------------------------------------------------------|
 | [Applications](applications.md)                   | `/applications`                                                         |
+| [Audit Events](audit_events.md) **(PREMIUM ONLY)** | `/audit_events`                                                         |
 | [Avatar](avatar.md)                               | `/avatar`                                                               |
 | [Broadcast messages](broadcast_messages.md)       | `/broadcast_messages`                                                   |
 | [Code snippets](snippets.md)                      | `/snippets`                                                             |
diff --git a/doc/api/audit_events.md b/doc/api/audit_events.md
new file mode 100644
index 00000000000..aca221cf990
--- /dev/null
+++ b/doc/api/audit_events.md
@@ -0,0 +1,115 @@
+# Audit Events API **(PREMIUM ONLY)**
+
+The Audit Events API allows you to retrieve [instance audit events](../administration/audit_events.md#instance-events-premium-only).
+
+To retrieve audit events using the API, you must [authenticate yourself](README.html#authentication) as an Administrator.
+
+## Retrieve all instance audit events
+
+```
+GET /audit_events
+```
+
+| Attribute | Type | Required | Description |
+| --------- | ---- | -------- | ----------- |
+| `created_after` | string | no | Return audit events created on or after the given time. Format: ISO 8601 YYYY-MM-DDTHH:MM:SSZ  |
+| `created_before` | string | no | Return audit events created on or before the given time. Format: ISO 8601 YYYY-MM-DDTHH:MM:SSZ |
+| `entity_type` | string | no | Return audit events for the given entity type. Valid values are: `User`, `Group`, or `Project`.  |
+| `entity_id` | boolean | no | Return audit events for the given entity ID. Requires `entity_type` attribute to be present. |
+
+By default, `GET` requests return 20 results at a time because the API results
+are paginated.
+
+Read more on [pagination](README.md#pagination).
+
+```bash
+curl --header "PRIVATE-TOKEN: <your_access_token>" https://primary.example.com/api/v4/audit_events
+```
+
+Example response:
+
+```json
+[
+  {
+    "id": 1,
+    "author_id": 1,
+    "entity_id": 6,
+    "entity_type": "Project",
+    "details": {
+      "custom_message": "Project archived",
+      "author_name": "Administrator",
+      "target_id": "flightjs/flight",
+      "target_type": "Project",
+      "target_details": "flightjs/flight",
+      "ip_address": "127.0.0.1",
+      "entity_path": "flightjs/flight"
+    },
+    "created_at": "2019-08-30T07:00:41.885Z"
+  },
+  {
+    "id": 2,
+    "author_id": 1,
+    "entity_id": 60,
+    "entity_type": "Group",
+    "details": {
+      "add": "group",
+      "author_name": "Administrator",
+      "target_id": "flightjs",
+      "target_type": "Group",
+      "target_details": "flightjs",
+      "ip_address": "127.0.0.1",
+      "entity_path": "flightjs"
+    },
+    "created_at": "2019-08-27T18:36:44.162Z"
+  },
+  {
+    "id": 3,
+    "author_id": 51,
+    "entity_id": 51,
+    "entity_type": "User",
+    "details": {
+      "change": "email address",
+      "from": "hello@flightjs.com",
+      "to": "maintainer@flightjs.com",
+      "author_name": "Andreas",
+      "target_id": 51,
+      "target_type": "User",
+      "target_details": "Andreas",
+      "ip_address": null,
+      "entity_path": "Andreas"
+    },
+    "created_at": "2019-08-22T16:34:25.639Z"
+  }
+]
+```
+
+## Retrieve single instance audit event
+
+```
+GET /audit_events/:id
+```
+
+```bash
+curl --header "PRIVATE-TOKEN: <your_access_token>" https://primary.example.com/api/v4/audit_events/1
+```
+
+Example response:
+
+```json
+{
+  "id": 1,
+  "author_id": 1,
+  "entity_id": 6,
+  "entity_type": "Project",
+  "details": {
+    "custom_message": "Project archived",
+    "author_name": "Administrator",
+    "target_id": "flightjs/flight",
+    "target_type": "Project",
+    "target_details": "flightjs/flight",
+    "ip_address": "127.0.0.1",
+    "entity_path": "flightjs/flight"
+  },
+  "created_at": "2019-08-30T07:00:41.885Z"
+}
+```
diff --git a/doc/api/boards.md b/doc/api/boards.md
index 151ab5487dd..b9c2a984dc5 100644
--- a/doc/api/boards.md
+++ b/doc/api/boards.md
@@ -48,7 +48,8 @@ Example response:
           "color" : "#F0AD4E",
           "description" : null
         },
-        "position" : 1
+        "position" : 1,
+        "max_issue_count": 0
       },
       {
         "id" : 2,
@@ -57,7 +58,8 @@ Example response:
           "color" : "#FF0000",
           "description" : null
         },
-        "position" : 2
+        "position" : 2,
+        "max_issue_count": 0
       },
       {
         "id" : 3,
@@ -66,7 +68,8 @@ Example response:
           "color" : "#FF5F00",
           "description" : null
         },
-        "position" : 3
+        "position" : 3,
+        "max_issue_count": 0
       }
     ]
   }
@@ -117,7 +120,8 @@ Example response:
           "color" : "#F0AD4E",
           "description" : null
         },
-        "position" : 1
+        "position" : 1,
+        "max_issue_count": 0
       },
       {
         "id" : 2,
@@ -126,7 +130,8 @@ Example response:
           "color" : "#FF0000",
           "description" : null
         },
-        "position" : 2
+        "position" : 2,
+        "max_issue_count": 0
       },
       {
         "id" : 3,
@@ -135,7 +140,8 @@ Example response:
           "color" : "#FF5F00",
           "description" : null
         },
-        "position" : 3
+        "position" : 3,
+        "max_issue_count": 0
       }
     ]
   }
@@ -185,7 +191,8 @@ Example response:
           "color" : "#F0AD4E",
           "description" : null
         },
-        "position" : 1
+        "position" : 1,
+        "max_issue_count": 0
       },
       {
         "id" : 2,
@@ -194,7 +201,8 @@ Example response:
           "color" : "#FF0000",
           "description" : null
         },
-        "position" : 2
+        "position" : 2,
+        "max_issue_count": 0
       },
       {
         "id" : 3,
@@ -203,7 +211,8 @@ Example response:
           "color" : "#FF5F00",
           "description" : null
         },
-        "position" : 3
+        "position" : 3,
+        "max_issue_count": 0
       }
     ]
   }
@@ -336,7 +345,8 @@ Example response:
       "color" : "#F0AD4E",
       "description" : null
     },
-    "position" : 1
+    "position" : 1,
+    "max_issue_count": 0
   },
   {
     "id" : 2,
@@ -345,7 +355,8 @@ Example response:
       "color" : "#FF0000",
       "description" : null
     },
-    "position" : 2
+    "position" : 2,
+    "max_issue_count": 0
   },
   {
     "id" : 3,
@@ -354,7 +365,8 @@ Example response:
       "color" : "#FF5F00",
       "description" : null
     },
-    "position" : 3
+    "position" : 3,
+    "max_issue_count": 0
   }
 ]
 ```
@@ -387,7 +399,8 @@ Example response:
     "color" : "#F0AD4E",
     "description" : null
   },
-  "position" : 1
+  "position" : 1,
+  "max_issue_count": 0
 }
 ```
 
@@ -427,7 +440,8 @@ Example response:
     "color" : "#F0AD4E",
     "description" : null
   },
-  "position" : 1
+  "position" : 1,
+  "max_issue_count": 0
 }
 ```
 
@@ -460,7 +474,8 @@ Example response:
     "color" : "#F0AD4E",
     "description" : null
   },
-  "position" : 1
+  "position" : 1,
+  "max_issue_count": 0
 }
 ```
 
diff --git a/doc/api/commits.md b/doc/api/commits.md
index cf1bca7b193..3927a4bbc62 100644
--- a/doc/api/commits.md
+++ b/doc/api/commits.md
@@ -11,12 +11,13 @@ GET /projects/:id/repository/commits
 | Attribute | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
 | `id`      | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user
-| `ref_name` | string | no | The name of a repository branch or tag or if not given the default branch |
+| `ref_name` | string | no | The name of a repository branch, tag or revision range, or if not given the default branch |
 | `since` | string | no | Only commits after or on this date will be returned in ISO 8601 format YYYY-MM-DDTHH:MM:SSZ |
 | `until` | string | no | Only commits before or on this date will be returned in ISO 8601 format YYYY-MM-DDTHH:MM:SSZ |
 | `path` | string | no | The file path |
 | `all` | boolean | no | Retrieve every commit from the repository |
 | `with_stats` | boolean | no | Stats about each commit will be added to the response |
+| `first_parent` | boolean | no | Follow only the first parent commit upon seeing a merge commit |
 
 ```bash
 curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/5/repository/commits"
@@ -533,7 +534,7 @@ Example response:
       },
       "description" : null,
       "sha" : "18f3e63d05582537db6d183d9d557be09e1f90c8",
-      "target_url" : "https://gitlab.example.com/thedude/gitlab-ce/builds/91",
+      "target_url" : "https://gitlab.example.com/thedude/gitlab-foss/builds/91",
       "finished_at" : null,
       "id" : 91,
       "ref" : "master"
@@ -544,7 +545,7 @@ Example response:
       "allow_failure" : false,
       "status" : "pending",
       "created_at" : "2016-01-19T08:40:25.832Z",
-      "target_url" : "https://gitlab.example.com/thedude/gitlab-ce/builds/90",
+      "target_url" : "https://gitlab.example.com/thedude/gitlab-foss/builds/90",
       "id" : 90,
       "finished_at" : null,
       "ref" : "master",
diff --git a/doc/api/container_registry.md b/doc/api/container_registry.md
index cb1a81b97b6..7e5e265351e 100644
--- a/doc/api/container_registry.md
+++ b/doc/api/container_registry.md
@@ -252,8 +252,8 @@ This action does not delete blobs. In order to delete them and recycle disk spac
 [run the garbage collection](https://docs.gitlab.com/omnibus/maintenance/README.html#removing-unused-layers-not-referenced-by-manifests).
 
 NOTE: **Note:**
-Due to a [Docker Distribution deficiency](https://gitlab.com/gitlab-org/gitlab-foss/issues/21405),
-it doesn't remove tags whose manifest is shared by multiple tags.
+Since GitLab 12.4, individual tags are deleted.
+For more details, see the [discussion](https://gitlab.com/gitlab-org/gitlab/issues/15737).
 
 Examples:
 
diff --git a/doc/api/deployments.md b/doc/api/deployments.md
index 0a67f134d54..27254c42e3a 100644
--- a/doc/api/deployments.md
+++ b/doc/api/deployments.md
@@ -24,6 +24,7 @@ Example of response
 [
   {
     "created_at": "2016-08-11T07:36:40.222Z",
+    "updated_at": "2016-08-11T07:38:12.414Z",
     "deployable": {
       "commit": {
         "author_email": "admin@example.com",
@@ -83,6 +84,7 @@ Example of response
   },
   {
     "created_at": "2016-08-11T11:32:35.444Z",
+    "updated_at": "2016-08-11T11:34:01.123Z",
     "deployable": {
       "commit": {
         "author_email": "admin@example.com",
@@ -167,6 +169,7 @@ Example of response
   "ref": "master",
   "sha": "a91957a858320c0e17f3a0eca7cfacbff50ea29a",
   "created_at": "2016-08-11T11:32:35.444Z",
+  "updated_at": "2016-08-11T11:34:01.123Z",
   "user": {
     "name": "Administrator",
     "username": "root",
@@ -220,3 +223,100 @@ Example of response
   }
 }
 ```
+
+## Create a deployment
+
+```
+POST /projects/:id/deployments
+```
+
+| Attribute        | Type           | Required | Description         |
+|------------------|----------------|----------|---------------------|
+| `id`             | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
+| `environment`    | string         | yes      | The name of the environment to create the deployment for |
+| `sha`            | string         | yes      | The SHA of the commit that is deployed |
+| `ref`            | string         | yes      | The name of the branch or tag that is deployed |
+| `tag`            | boolean        | yes      | A boolean that indicates if the deployed ref is a tag (true) or not (false) |
+| `status`         | string         | yes      | The status of the deployment |
+
+The status can be one of the following values:
+
+- created
+- running
+- success
+- failed
+- canceled
+
+```bash
+curl --data "environment=production&sha=a91957a858320c0e17f3a0eca7cfacbff50ea29a&ref=master&tag=false&status=success" --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/deployments"
+```
+
+Example of a response:
+
+```json
+{
+  "id": 42,
+  "iid": 2,
+  "ref": "master",
+  "sha": "a91957a858320c0e17f3a0eca7cfacbff50ea29a",
+  "created_at": "2016-08-11T11:32:35.444Z",
+  "status": "success",
+  "user": {
+    "name": "Administrator",
+    "username": "root",
+    "id": 1,
+    "state": "active",
+    "avatar_url": "http://www.gravatar.com/avatar/e64c7d89f26bd1972efa854d13d7dd61?s=80&d=identicon",
+    "web_url": "http://localhost:3000/root"
+  },
+  "environment": {
+    "id": 9,
+    "name": "production",
+    "external_url": "https://about.gitlab.com"
+  },
+  "deployable": null
+}
+```
+
+## Updating a deployment
+
+```
+PUT /projects/:id/deployments/:deployment_id
+```
+
+| Attribute        | Type           | Required | Description         |
+|------------------|----------------|----------|---------------------|
+| `id`             | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
+| `deployment_id`  | integer        | yes      | The ID of the deployment to update |
+| `status`         | string         | yes      | The new status of the deployment |
+
+```bash
+curl --request PUT --data "status=success" --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/deployments/42"
+```
+
+Example of a response:
+
+```json
+{
+  "id": 42,
+  "iid": 2,
+  "ref": "master",
+  "sha": "a91957a858320c0e17f3a0eca7cfacbff50ea29a",
+  "created_at": "2016-08-11T11:32:35.444Z",
+  "status": "success",
+  "user": {
+    "name": "Administrator",
+    "username": "root",
+    "id": 1,
+    "state": "active",
+    "avatar_url": "http://www.gravatar.com/avatar/e64c7d89f26bd1972efa854d13d7dd61?s=80&d=identicon",
+    "web_url": "http://localhost:3000/root"
+  },
+  "environment": {
+    "id": 9,
+    "name": "production",
+    "external_url": "https://about.gitlab.com"
+  },
+  "deployable": null
+}
+```
diff --git a/doc/api/environments.md b/doc/api/environments.md
index 44f86861ff7..3f46c11ed69 100644
--- a/doc/api/environments.md
+++ b/doc/api/environments.md
@@ -26,7 +26,8 @@ Example response:
     "id": 1,
     "name": "review/fix-foo",
     "slug": "review-fix-foo-dfjre3",
-    "external_url": "https://review-fix-foo-dfjre3.example.gitlab.com"
+    "external_url": "https://review-fix-foo-dfjre3.example.gitlab.com",
+    "state": "available"
   }
 ]
 ```
@@ -54,12 +55,14 @@ Example of response
   "name": "review/fix-foo",
   "slug": "review-fix-foo-dfjre3",
   "external_url": "https://review-fix-foo-dfjre3.example.gitlab.com"
+  "state": "available",
   "last_deployment": {
     "id": 100,
     "iid": 34,
     "ref": "fdroid",
     "sha": "416d8ea11849050d3d1f5104cf8cf51053e790ab",
     "created_at": "2019-03-25T18:55:13.252Z",
+    "status": "success",
     "user": {
       "id": 1,
       "name": "Administrator",
@@ -163,7 +166,8 @@ Example response:
   "id": 1,
   "name": "deploy",
   "slug": "deploy",
-  "external_url": "https://deploy.example.gitlab.com"
+  "external_url": "https://deploy.example.gitlab.com",
+  "state": "available"
 }
 ```
 
@@ -180,7 +184,7 @@ PUT /projects/:id/environments/:environments_id
 | Attribute       | Type    | Required                          | Description                      |
 | --------------- | ------- | --------------------------------- | -------------------------------  |
 | `id`            | integer/string | yes                               | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user            |
-| `environment_id` | integer | yes | The ID of the environment  | The ID of the environment        |
+| `environment_id` | integer | yes | The ID of the environment  |
 | `name`          | string  | no                                | The new name of the environment  |
 | `external_url`  | string  | no                                | The new external_url             |
 
@@ -195,7 +199,8 @@ Example response:
   "id": 1,
   "name": "staging",
   "slug": "staging",
-  "external_url": "https://staging.example.gitlab.com"
+  "external_url": "https://staging.example.gitlab.com",
+  "state": "available"
 }
 ```
 
@@ -240,6 +245,7 @@ Example response:
   "id": 1,
   "name": "deploy",
   "slug": "deploy",
-  "external_url": "https://deploy.example.gitlab.com"
+  "external_url": "https://deploy.example.gitlab.com",
+  "state": "stopped"
 }
 ```
diff --git a/doc/api/epics.md b/doc/api/epics.md
index 92b534fc187..c7a050f1465 100644
--- a/doc/api/epics.md
+++ b/doc/api/epics.md
@@ -67,7 +67,7 @@ Example response:
   "title": "Accusamus iste et ullam ratione voluptatem omnis debitis dolor est.",
   "description": "Molestias dolorem eos vitae expedita impedit necessitatibus quo voluptatum.",
   "state": "opened",
-  "web_edit_url": "http://localhost:3001/groups/test/-/epics/4",
+  "web_url": "http://localhost:3001/groups/test/-/epics/4",
   "reference": "&4",
   "author": {
     "id": 10,
@@ -88,6 +88,7 @@ Example response:
   "due_date_from_milestones": "2018-07-31",
   "created_at": "2018-07-17T13:36:22.770Z",
   "updated_at": "2018-07-18T12:22:05.239Z",
+  "closed_at": "2018-08-18T12:22:05.239Z",
   "labels": [],
   "upvotes": 4,
   "downvotes": 0
@@ -122,7 +123,7 @@ Example response:
   "title": "Ea cupiditate dolores ut vero consequatur quasi veniam voluptatem et non.",
   "description": "Molestias dolorem eos vitae expedita impedit necessitatibus quo voluptatum.",
   "state": "opened",
-  "web_edit_url": "http://localhost:3001/groups/test/-/epics/5",
+  "web_url": "http://localhost:3001/groups/test/-/epics/5",
   "reference": "&5",
   "author":{
     "id": 7,
@@ -143,9 +144,11 @@ Example response:
   "due_date_from_milestones": "2018-07-31",
   "created_at": "2018-07-17T13:36:22.770Z",
   "updated_at": "2018-07-18T12:22:05.239Z",
+  "closed_at": "2018-08-18T12:22:05.239Z",
   "labels": [],
   "upvotes": 4,
-  "downvotes": 0
+  "downvotes": 0,
+  "subscribed": true
 }
 ```
 
@@ -167,7 +170,7 @@ POST /groups/:id/epics
 | `id`                | integer/string   | yes        | The ID or [URL-encoded path of the group](README.md#namespaced-path-encoding) owned by the authenticated user                |
 | `title`             | string           | yes        | The title of the epic |
 | `labels`            | string           | no         | The comma separated list of labels |
-| `description`       | string           | no         | The description of the epic. Limited to 1 000 000 characters.  |
+| `description`       | string           | no         | The description of the epic. Limited to 1,048,576 characters.  |
 | `start_date_is_fixed` | boolean        | no         | Whether start date should be sourced from `start_date_fixed` or from milestones (since 11.3) |
 | `start_date_fixed`  | string           | no         | The fixed start date of an epic (since 11.3) |
 | `due_date_is_fixed` | boolean          | no         | Whether due date should be sourced from `due_date_fixed` or from milestones (since 11.3) |
@@ -188,7 +191,7 @@ Example response:
   "title": "Epic",
   "description": "Epic description",
   "state": "opened",
-  "web_edit_url": "http://localhost:3001/groups/test/-/epics/6",
+  "web_url": "http://localhost:3001/groups/test/-/epics/5",
   "reference": "&6",
   "author": {
     "name" : "Alexandra Bashirian",
@@ -209,6 +212,7 @@ Example response:
   "due_date_from_milestones": "2018-07-31",
   "created_at": "2018-07-17T13:36:22.770Z",
   "updated_at": "2018-07-18T12:22:05.239Z",
+  "closed_at": "2018-08-18T12:22:05.239Z",
   "labels": [],
   "upvotes": 4,
   "downvotes": 0
@@ -233,7 +237,7 @@ PUT /groups/:id/epics/:epic_iid
 | `id`                | integer/string   | yes        | The ID or [URL-encoded path of the group](README.md#namespaced-path-encoding) owned by the authenticated user                |
 | `epic_iid`          | integer/string   | yes        | The internal ID  of the epic  |
 | `title`             | string           | no         | The title of an epic |
-| `description`       | string           | no         | The description of an epic. Limited to 1 000 000 characters.  |
+| `description`       | string           | no         | The description of an epic. Limited to 1,048,576 characters.  |
 | `labels`            | string           | no         | The comma separated list of labels |
 | `start_date_is_fixed` | boolean        | no         | Whether start date should be sourced from `start_date_fixed` or from milestones (since 11.3) |
 | `start_date_fixed`  | string           | no         | The fixed start date of an epic (since 11.3) |
@@ -255,7 +259,7 @@ Example response:
   "title": "New Title",
   "description": "Epic description",
   "state": "opened",
-  "web_edit_url": "http://localhost:3001/groups/test/-/epics/6",
+  "web_url": "http://localhost:3001/groups/test/-/epics/5",
   "reference": "&6",
   "author": {
     "name" : "Alexandra Bashirian",
@@ -276,6 +280,7 @@ Example response:
   "due_date_from_milestones": "2018-07-31",
   "created_at": "2018-07-17T13:36:22.770Z",
   "updated_at": "2018-07-18T12:22:05.239Z",
+  "closed_at": "2018-08-18T12:22:05.239Z",
   "labels": [],
   "upvotes": 4,
   "downvotes": 0
@@ -358,7 +363,8 @@ Example response:
     "start_date": null,
     "end_date": null,
     "created_at": "2018-01-21T06:21:13.165Z",
-    "updated_at": "2018-01-22T12:41:41.166Z"
+    "updated_at": "2018-01-22T12:41:41.166Z",
+    "closed_at": "2018-08-18T12:22:05.239Z"
   },
   "target_url": "https://gitlab.example.com/groups/epics/5",
   "body": "Vel voluptas atque dicta mollitia adipisci qui at.",
diff --git a/doc/api/features.md b/doc/api/features.md
index e8d0c7c942b..8b5ea27007d 100644
--- a/doc/api/features.md
+++ b/doc/api/features.md
@@ -61,7 +61,7 @@ POST /features/:name
 | `feature_group` | string | no | A Feature group name |
 | `user` | string | no | A GitLab username |
 | `group` | string | no | A GitLab group's path, for example `gitlab-org` |
-| `project` | string | no | A projects path, for example `gitlab-org/gitlab-ce` |
+| `project` | string | no | A projects path, for example `gitlab-org/gitlab-foss` |
 
 Note that you can enable or disable a feature for a `feature_group`, a `user`,
 a `group`, and a `project` in a single API call.
diff --git a/doc/api/graphql/index.md b/doc/api/graphql/index.md
index eb5faac5ede..9eb254b4677 100644
--- a/doc/api/graphql/index.md
+++ b/doc/api/graphql/index.md
@@ -42,7 +42,7 @@ A first iteration of a GraphQL API includes the following queries
 ### Multiplex queries
 
 GitLab supports batching queries into a single request using
-[apollo-link-batch-http](https://www.apollographql.com/docs/link/links/batch-http). More
+[apollo-link-batch-http](https://www.apollographql.com/docs/link/links/batch-http/). More
 info about multiplexed queries is also available for
 [graphql-ruby](https://graphql-ruby.org/queries/multiplex.html) the
 library GitLab uses on the backend.
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index e87270f884a..839289cf677 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -54,9 +54,87 @@ The API can be explored interactively using the [GraphiQL IDE](../index.md#graph
 | `message` | String |  |
 | `authoredDate` | Time |  |
 | `webUrl` | String! |  |
+| `signatureHtml` | String | Rendered html for the commit signature |
 | `author` | User |  |
 | `latestPipeline` | Pipeline | Latest pipeline for this commit |
 
+### CreateDiffNotePayload
+
+| Name  | Type  | Description |
+| ---   |  ---- | ----------  |
+| `clientMutationId` | String | A unique identifier for the client performing the mutation. |
+| `errors` | String! => Array | Reasons why the mutation failed. |
+| `note` | Note | The note after mutation |
+
+### CreateImageDiffNotePayload
+
+| Name  | Type  | Description |
+| ---   |  ---- | ----------  |
+| `clientMutationId` | String | A unique identifier for the client performing the mutation. |
+| `errors` | String! => Array | Reasons why the mutation failed. |
+| `note` | Note | The note after mutation |
+
+### CreateNotePayload
+
+| Name  | Type  | Description |
+| ---   |  ---- | ----------  |
+| `clientMutationId` | String | A unique identifier for the client performing the mutation. |
+| `errors` | String! => Array | Reasons why the mutation failed. |
+| `note` | Note | The note after mutation |
+
+### Design
+
+| Name  | Type  | Description |
+| ---   |  ---- | ----------  |
+| `id` | ID! |  |
+| `project` | Project! |  |
+| `issue` | Issue! |  |
+| `notesCount` | Int! | The total count of user-created notes for this design |
+| `filename` | String! |  |
+| `fullPath` | String! |  |
+| `event` | DesignVersionEvent! | The change that happened to the design at this version |
+| `image` | String! |  |
+| `diffRefs` | DiffRefs! |  |
+
+### DesignCollection
+
+| Name  | Type  | Description |
+| ---   |  ---- | ----------  |
+| `project` | Project! |  |
+| `issue` | Issue! |  |
+
+### DesignManagementDeletePayload
+
+| Name  | Type  | Description |
+| ---   |  ---- | ----------  |
+| `clientMutationId` | String | A unique identifier for the client performing the mutation. |
+| `errors` | String! => Array | Reasons why the mutation failed. |
+| `version` | DesignVersion | The new version in which the designs are deleted |
+
+### DesignManagementUploadPayload
+
+| Name  | Type  | Description |
+| ---   |  ---- | ----------  |
+| `clientMutationId` | String | A unique identifier for the client performing the mutation. |
+| `errors` | String! => Array | Reasons why the mutation failed. |
+| `designs` | Design! => Array | The designs that were uploaded by the mutation |
+| `skippedDesigns` | Design! => Array | Any designs that were skipped from the upload due to there being no change to their content since their last version |
+
+### DesignVersion
+
+| Name  | Type  | Description |
+| ---   |  ---- | ----------  |
+| `id` | ID! |  |
+| `sha` | ID! |  |
+
+### DestroyNotePayload
+
+| Name  | Type  | Description |
+| ---   |  ---- | ----------  |
+| `clientMutationId` | String | A unique identifier for the client performing the mutation. |
+| `errors` | String! => Array | Reasons why the mutation failed. |
+| `note` | Note | The note after mutation |
+
 ### DetailedStatus
 
 | Name  | Type  | Description |
@@ -74,9 +152,7 @@ The API can be explored interactively using the [GraphiQL IDE](../index.md#graph
 
 | Name  | Type  | Description |
 | ---   |  ---- | ----------  |
-| `headSha` | String! | The sha of the head at the time the comment was made |
-| `baseSha` | String | The merge base of the branch the comment was made on |
-| `startSha` | String! | The sha of the branch being compared against |
+| `diffRefs` | DiffRefs! |  |
 | `filePath` | String! | The path of the file that was changed |
 | `oldPath` | String | The path of the file on the start sha. |
 | `newPath` | String | The path of the file on the head sha. |
@@ -88,13 +164,147 @@ The API can be explored interactively using the [GraphiQL IDE](../index.md#graph
 | `width` | Int | The total width of the image |
 | `height` | Int | The total height of the image |
 
+### DiffRefs
+
+| Name  | Type  | Description |
+| ---   |  ---- | ----------  |
+| `headSha` | String! | The sha of the head at the time the comment was made |
+| `baseSha` | String! | The merge base of the branch the comment was made on |
+| `startSha` | String! | The sha of the branch being compared against |
+
 ### Discussion
 
 | Name  | Type  | Description |
 | ---   |  ---- | ----------  |
 | `id` | ID! |  |
+| `replyId` | ID! | The ID used to reply to this discussion |
 | `createdAt` | Time! |  |
 
+### Epic
+
+| Name  | Type  | Description |
+| ---   |  ---- | ----------  |
+| `userPermissions` | EpicPermissions! | Permissions for the current user on the resource |
+| `id` | ID! |  |
+| `iid` | ID! |  |
+| `title` | String |  |
+| `description` | String |  |
+| `state` | EpicState! |  |
+| `group` | Group! |  |
+| `parent` | Epic |  |
+| `author` | User! |  |
+| `startDate` | Time |  |
+| `startDateIsFixed` | Boolean |  |
+| `startDateFixed` | Time |  |
+| `startDateFromMilestones` | Time |  |
+| `dueDate` | Time |  |
+| `dueDateIsFixed` | Boolean |  |
+| `dueDateFixed` | Time |  |
+| `dueDateFromMilestones` | Time |  |
+| `closedAt` | Time |  |
+| `createdAt` | Time |  |
+| `updatedAt` | Time |  |
+| `hasChildren` | Boolean! |  |
+| `hasIssues` | Boolean! |  |
+| `webPath` | String! |  |
+| `webUrl` | String! |  |
+| `relativePosition` | Int | The relative position of the epic in the Epic tree |
+| `relationPath` | String |  |
+| `reference` | String! |  |
+| `subscribed` | Boolean! | Boolean flag for whether the currently logged in user is subscribed to this epic |
+
+### EpicIssue
+
+| Name  | Type  | Description |
+| ---   |  ---- | ----------  |
+| `userPermissions` | IssuePermissions! | Permissions for the current user on the resource |
+| `iid` | ID! |  |
+| `title` | String! |  |
+| `titleHtml` | String | The GitLab Flavored Markdown rendering of `title` |
+| `description` | String |  |
+| `descriptionHtml` | String | The GitLab Flavored Markdown rendering of `description` |
+| `state` | IssueState! |  |
+| `reference` | String! |  |
+| `author` | User! |  |
+| `milestone` | Milestone |  |
+| `dueDate` | Time |  |
+| `confidential` | Boolean! |  |
+| `discussionLocked` | Boolean! |  |
+| `upvotes` | Int! |  |
+| `downvotes` | Int! |  |
+| `userNotesCount` | Int! |  |
+| `webPath` | String! |  |
+| `webUrl` | String! |  |
+| `relativePosition` | Int |  |
+| `timeEstimate` | Int! | The time estimate on the issue |
+| `totalTimeSpent` | Int! | Total time reported as spent on the issue |
+| `closedAt` | Time |  |
+| `createdAt` | Time! |  |
+| `updatedAt` | Time! |  |
+| `taskCompletionStatus` | TaskCompletionStatus! |  |
+| `epic` | Epic | The epic to which issue belongs |
+| `weight` | Int |  |
+| `designs` | DesignCollection |  |
+| `designCollection` | DesignCollection |  |
+| `epicIssueId` | ID! |  |
+| `relationPath` | String |  |
+| `id` | ID | The global id of the epic-issue relation |
+
+### EpicPermissions
+
+| Name  | Type  | Description |
+| ---   |  ---- | ----------  |
+| `readEpic` | Boolean! | Whether or not a user can perform `read_epic` on this resource |
+| `readEpicIid` | Boolean! | Whether or not a user can perform `read_epic_iid` on this resource |
+| `updateEpic` | Boolean! | Whether or not a user can perform `update_epic` on this resource |
+| `destroyEpic` | Boolean! | Whether or not a user can perform `destroy_epic` on this resource |
+| `adminEpic` | Boolean! | Whether or not a user can perform `admin_epic` on this resource |
+| `createEpic` | Boolean! | Whether or not a user can perform `create_epic` on this resource |
+| `createNote` | Boolean! | Whether or not a user can perform `create_note` on this resource |
+| `awardEmoji` | Boolean! | Whether or not a user can perform `award_emoji` on this resource |
+
+### EpicTreeReorderPayload
+
+| Name  | Type  | Description |
+| ---   |  ---- | ----------  |
+| `clientMutationId` | String | A unique identifier for the client performing the mutation. |
+| `errors` | String! => Array | Reasons why the mutation failed. |
+
+### ExtendedIssue
+
+| Name  | Type  | Description |
+| ---   |  ---- | ----------  |
+| `userPermissions` | IssuePermissions! | Permissions for the current user on the resource |
+| `iid` | ID! |  |
+| `title` | String! |  |
+| `titleHtml` | String | The GitLab Flavored Markdown rendering of `title` |
+| `description` | String |  |
+| `descriptionHtml` | String | The GitLab Flavored Markdown rendering of `description` |
+| `state` | IssueState! |  |
+| `reference` | String! |  |
+| `author` | User! |  |
+| `milestone` | Milestone |  |
+| `dueDate` | Time |  |
+| `confidential` | Boolean! |  |
+| `discussionLocked` | Boolean! |  |
+| `upvotes` | Int! |  |
+| `downvotes` | Int! |  |
+| `userNotesCount` | Int! |  |
+| `webPath` | String! |  |
+| `webUrl` | String! |  |
+| `relativePosition` | Int |  |
+| `timeEstimate` | Int! | The time estimate on the issue |
+| `totalTimeSpent` | Int! | Total time reported as spent on the issue |
+| `closedAt` | Time |  |
+| `createdAt` | Time! |  |
+| `updatedAt` | Time! |  |
+| `taskCompletionStatus` | TaskCompletionStatus! |  |
+| `epic` | Epic | The epic to which issue belongs |
+| `weight` | Int |  |
+| `designs` | DesignCollection |  |
+| `designCollection` | DesignCollection |  |
+| `subscribed` | Boolean! | Boolean flag for whether the currently logged in user is subscribed to this issue |
+
 ### Group
 
 | Name  | Type  | Description |
@@ -109,11 +319,13 @@ The API can be explored interactively using the [GraphiQL IDE](../index.md#graph
 | `visibility` | String |  |
 | `lfsEnabled` | Boolean |  |
 | `requestAccessEnabled` | Boolean |  |
-| `rootStorageStatistics` | RootStorageStatistics | The aggregated storage statistics. Only available if the namespace has no parent |
+| `rootStorageStatistics` | RootStorageStatistics | The aggregated storage statistics. Only available for root namespaces |
 | `userPermissions` | GroupPermissions! | Permissions for the current user on the resource |
 | `webUrl` | String! |  |
 | `avatarUrl` | String |  |
 | `parent` | Group |  |
+| `epicsEnabled` | Boolean |  |
+| `epic` | Epic |  |
 
 ### GroupPermissions
 
@@ -144,10 +356,16 @@ The API can be explored interactively using the [GraphiQL IDE](../index.md#graph
 | `webPath` | String! |  |
 | `webUrl` | String! |  |
 | `relativePosition` | Int |  |
+| `timeEstimate` | Int! | The time estimate on the issue |
+| `totalTimeSpent` | Int! | Total time reported as spent on the issue |
 | `closedAt` | Time |  |
 | `createdAt` | Time! |  |
 | `updatedAt` | Time! |  |
 | `taskCompletionStatus` | TaskCompletionStatus! |  |
+| `epic` | Epic | The epic to which issue belongs |
+| `weight` | Int |  |
+| `designs` | DesignCollection |  |
+| `designCollection` | DesignCollection |  |
 
 ### IssuePermissions
 
@@ -158,6 +376,9 @@ The API can be explored interactively using the [GraphiQL IDE](../index.md#graph
 | `updateIssue` | Boolean! | Whether or not a user can perform `update_issue` on this resource |
 | `createNote` | Boolean! | Whether or not a user can perform `create_note` on this resource |
 | `reopenIssue` | Boolean! | Whether or not a user can perform `reopen_issue` on this resource |
+| `readDesign` | Boolean! | Whether or not a user can perform `read_design` on this resource |
+| `createDesign` | Boolean! | Whether or not a user can perform `create_design` on this resource |
+| `destroyDesign` | Boolean! | Whether or not a user can perform `destroy_design` on this resource |
 
 ### Label
 
@@ -185,6 +406,7 @@ The API can be explored interactively using the [GraphiQL IDE](../index.md#graph
 | `updatedAt` | Time! |  |
 | `sourceProject` | Project |  |
 | `targetProject` | Project! |  |
+| `diffRefs` | DiffRefs |  |
 | `project` | Project! |  |
 | `projectId` | Int! |  |
 | `sourceProjectId` | Int |  |
@@ -213,8 +435,13 @@ The API can be explored interactively using the [GraphiQL IDE](../index.md#graph
 | `webUrl` | String |  |
 | `upvotes` | Int! |  |
 | `downvotes` | Int! |  |
-| `subscribed` | Boolean! |  |
 | `headPipeline` | Pipeline |  |
+| `milestone` | Milestone | The milestone this merge request is linked to |
+| `subscribed` | Boolean! | Boolean flag for whether the currently logged in user is subscribed to this MR |
+| `discussionLocked` | Boolean! | Boolean flag determining if comments on the merge request are locked to members only |
+| `timeEstimate` | Int! | The time estimate for the merge request |
+| `totalTimeSpent` | Int! | Total time reported as spent on the merge request |
+| `reference` | String! | Internal merge request reference. Returned in shortened format by default |
 | `taskCompletionStatus` | TaskCompletionStatus! |  |
 
 ### MergeRequestPermissions
@@ -271,6 +498,7 @@ The API can be explored interactively using the [GraphiQL IDE](../index.md#graph
 | `visibility` | String |  |
 | `lfsEnabled` | Boolean |  |
 | `requestAccessEnabled` | Boolean |  |
+| `rootStorageStatistics` | RootStorageStatistics | The aggregated storage statistics. Only available for root namespaces |
 
 ### Note
 
@@ -381,7 +609,7 @@ The API can be explored interactively using the [GraphiQL IDE](../index.md#graph
 | `statistics` | ProjectStatistics |  |
 | `repository` | Repository |  |
 | `mergeRequest` | MergeRequest |  |
-| `issue` | Issue |  |
+| `issue` | ExtendedIssue |  |
 
 ### ProjectPermissions
 
@@ -424,6 +652,10 @@ The API can be explored interactively using the [GraphiQL IDE](../index.md#graph
 | `createPages` | Boolean! | Whether or not a user can perform `create_pages` on this resource |
 | `destroyPages` | Boolean! | Whether or not a user can perform `destroy_pages` on this resource |
 | `readPagesContent` | Boolean! | Whether or not a user can perform `read_pages_content` on this resource |
+| `adminOperations` | Boolean! | Whether or not a user can perform `admin_operations` on this resource |
+| `readDesign` | Boolean! | Whether or not a user can perform `read_design` on this resource |
+| `createDesign` | Boolean! | Whether or not a user can perform `create_design` on this resource |
+| `destroyDesign` | Boolean! | Whether or not a user can perform `destroy_design` on this resource |
 
 ### ProjectStatistics
 
@@ -458,12 +690,12 @@ The API can be explored interactively using the [GraphiQL IDE](../index.md#graph
 
 | Name  | Type  | Description |
 | ---   |  ---- | ----------  |
-| `storageSize` | Int! | The total storage in Bytes |
-| `repositorySize` | Int! | The git repository size in Bytes |
-| `lfsObjectsSize` | Int! | The LFS objects size in Bytes |
-| `buildArtifactsSize` | Int! | The CI artifacts size in Bytes |
-| `packagesSize` | Int! | The packages size in Bytes |
-| `wikiSize` | Int! | The wiki size in Bytes |
+| `storageSize` | Int! | The total storage in bytes |
+| `repositorySize` | Int! | The git repository size in bytes |
+| `lfsObjectsSize` | Int! | The LFS objects size in bytes |
+| `buildArtifactsSize` | Int! | The CI artifacts size in bytes |
+| `packagesSize` | Int! | The packages size in bytes |
+| `wikiSize` | Int! | The wiki size in bytes |
 
 ### Submodule
 
@@ -474,6 +706,8 @@ The API can be explored interactively using the [GraphiQL IDE](../index.md#graph
 | `type` | EntryType! |  |
 | `path` | String! |  |
 | `flatPath` | String! |  |
+| `webUrl` | String |  |
+| `treeUrl` | String |  |
 
 ### TaskCompletionStatus
 
@@ -482,6 +716,20 @@ The API can be explored interactively using the [GraphiQL IDE](../index.md#graph
 | `count` | Int! |  |
 | `completedCount` | Int! |  |
 
+### Todo
+
+| Name  | Type  | Description |
+| ---   |  ---- | ----------  |
+| `id` | ID! | Id of the todo |
+| `project` | Project | The project this todo is associated with |
+| `group` | Group | Group this todo is associated with |
+| `author` | User! | The owner of this todo |
+| `action` | TodoActionEnum! | Action of the todo |
+| `targetType` | TodoTargetEnum! | Target type of the todo |
+| `body` | String! | Body of the todo |
+| `state` | TodoStateEnum! | State of the todo |
+| `createdAt` | Time! | Timestamp this todo was created |
+
 ### ToggleAwardEmojiPayload
 
 | Name  | Type  | Description |
@@ -495,7 +743,7 @@ The API can be explored interactively using the [GraphiQL IDE](../index.md#graph
 
 | Name  | Type  | Description |
 | ---   |  ---- | ----------  |
-| `lastCommit` | Commit |  |
+| `lastCommit` | Commit | Last commit for the tree |
 
 ### TreeEntry
 
@@ -508,6 +756,22 @@ The API can be explored interactively using the [GraphiQL IDE](../index.md#graph
 | `flatPath` | String! |  |
 | `webUrl` | String |  |
 
+### UpdateEpicPayload
+
+| Name  | Type  | Description |
+| ---   |  ---- | ----------  |
+| `clientMutationId` | String | A unique identifier for the client performing the mutation. |
+| `errors` | String! => Array | Reasons why the mutation failed. |
+| `epic` | Epic | The epic after mutation |
+
+### UpdateNotePayload
+
+| Name  | Type  | Description |
+| ---   |  ---- | ----------  |
+| `clientMutationId` | String | A unique identifier for the client performing the mutation. |
+| `errors` | String! => Array | Reasons why the mutation failed. |
+| `note` | Note | The note after mutation |
+
 ### User
 
 | Name  | Type  | Description |
diff --git a/doc/api/group_clusters.md b/doc/api/group_clusters.md
index 8a85b5b8763..e878bb5fa4d 100644
--- a/doc/api/group_clusters.md
+++ b/doc/api/group_clusters.md
@@ -276,5 +276,5 @@ Parameters:
 Example request:
 
 ```bash
-curl --request DELETE --header 'Private-Token: <your_access_token>' https://gitlab.example.com/api/v4/groups/26/clusters/23'
+curl --request DELETE --header 'Private-Token: <your_access_token>' https://gitlab.example.com/api/v4/groups/26/clusters/23
 ```
diff --git a/doc/api/group_labels.md b/doc/api/group_labels.md
index 5030bba3159..f3c3a821354 100644
--- a/doc/api/group_labels.md
+++ b/doc/api/group_labels.md
@@ -16,6 +16,7 @@ GET /groups/:id/labels
 | ---------     | ----           | -------- | -----------                                                                                                                                                                  |
 | `id`          | integer/string | yes      | The ID or [URL-encoded path of the group](README.md#namespaced-path-encoding) owned by the authenticated user.                                                               |
 | `with_counts` | boolean        | no       | Whether or not to include issue and merge request counts. Defaults to `false`. _([Introduced in GitLab 12.2](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/31543))_ |
+| `include_ancestor_groups` | boolean | no | Include ancestor groups. Defaults to `true`. |
 
 ```bash
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/5/labels?with_counts=true
@@ -50,6 +51,40 @@ Example response:
 ]
 ```
 
+## Get a single group label
+
+Get a single label for a given group.
+
+```
+GET /groups/:id/labels/:label_id
+```
+
+| Attribute     | Type           | Required | Description                                                                                                                                                                  |
+| ---------     | ----           | -------- | -----------                                                                                                                                                                  |
+| `id`          | integer/string | yes      | The ID or [URL-encoded path of the group](README.md#namespaced-path-encoding) owned by the authenticated user.                                                               |
+| `label_id` | integer or string | yes | The ID or title of a group's label. |
+| `include_ancestor_groups` | boolean | no | Include ancestor groups. Defaults to `true`. |
+
+```bash
+curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/5/labels/bug
+```
+
+Example response:
+
+```json
+{
+  "id": 7,
+  "name": "bug",
+  "color": "#FF0000",
+  "text_color" : "#FFFFFF",
+  "description": null,
+  "open_issues_count": 0,
+  "closed_issues_count": 0,
+  "open_merge_requests_count": 0,
+  "subscribed": false
+}
+```
+
 ## Create a new group label
 
 Create a new group label for a given group.
@@ -90,19 +125,19 @@ Example response:
 Updates an existing group label. At least one parameter is required, to update the group label.
 
 ```
-PUT /groups/:id/labels
+PUT /groups/:id/labels/:label_id
 ```
 
 | Attribute     | Type    | Required | Description                  |
 | ------------- | ------- | -------- | ---------------------------- |
 | `id` | integer/string | yes | The ID or [URL-encoded path of the group](README.md#namespaced-path-encoding) owned by the authenticated user |
-| `name`        | string  | yes      | The name of the label        |
+| `label_id` | integer or string | yes | The ID or title of a group's label. |
 | `new_name`    | string  | no      | The new name of the label        |
 | `color`       | string  | no      | The color of the label given in 6-digit hex notation with leading '#' sign (e.g. #FFAABB) or one of the [CSS color names](https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#Color_keywords) |
 | `description` | string  | no       | The description of the label. |
 
 ```bash
-curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" --header "Content-Type: application/json" --data '{"name": "Feature Proposal", "new_name": "Feature Idea" }' https://gitlab.example.com/api/v4/groups/5/labels
+curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" --header "Content-Type: application/json" --data '{"new_name": "Feature Idea" }' https://gitlab.example.com/api/v4/groups/5/labels/Feature%20Proposal
 ```
 
 Example response:
@@ -121,23 +156,27 @@ Example response:
 }
 ```
 
+NOTE: **Note:** An older endpoint `PUT /groups/:id/labels` with `name` in the params is still available, but deprecated.
+
 ## Delete a group label
 
 Deletes a group label with a given name.
 
 ```
-DELETE /groups/:id/labels
+DELETE /groups/:id/labels/:label_id
 ```
 
 | Attribute | Type    | Required | Description           |
 | --------- | ------- | -------- | --------------------- |
 | `id`      | integer/string    | yes      | The ID or [URL-encoded path of the group](README.md#namespaced-path-encoding) owned by the authenticated user |
-| `name`    | string  | yes      | The name of the label. |
+| `label_id` | integer or string | yes | The ID or title of a group's label. |
 
 ```bash
-curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/5/labels?name=bug
+curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/5/labels/bug
 ```
 
+NOTE: **Note:** An older endpoint `DELETE /groups/:id/labels` with `name` in the params is still available, but deprecated.
+
 ## Subscribe to a group label
 
 Subscribes the authenticated user to a group label to receive notifications. If
diff --git a/doc/api/groups.md b/doc/api/groups.md
index b0d60d58049..312bd04e24c 100644
--- a/doc/api/groups.md
+++ b/doc/api/groups.md
@@ -31,6 +31,13 @@ GET /groups
     "path": "foo-bar",
     "description": "An interesting group",
     "visibility": "public",
+    "share_with_group_lock": false,
+    "require_two_factor_authentication": false,
+    "two_factor_grace_period": 48,
+    "project_creation_level": "developer",
+    "auto_devops_enabled": null,
+    "subgroup_creation_level": "owner",
+    "emails_disabled": null,
     "lfs_enabled": true,
     "avatar_url": "http://localhost:3000/uploads/group/avatar/1/foo.jpg",
     "web_url": "http://localhost:3000/groups/foo-bar",
@@ -57,6 +64,13 @@ GET /groups?statistics=true
     "path": "foo-bar",
     "description": "An interesting group",
     "visibility": "public",
+    "share_with_group_lock": false,
+    "require_two_factor_authentication": false,
+    "two_factor_grace_period": 48,
+    "project_creation_level": "developer",
+    "auto_devops_enabled": null,
+    "subgroup_creation_level": "owner",
+    "emails_disabled": null,
     "lfs_enabled": true,
     "avatar_url": "http://localhost:3000/uploads/group/avatar/1/foo.jpg",
     "web_url": "http://localhost:3000/groups/foo-bar",
@@ -119,6 +133,13 @@ GET /groups/:id/subgroups
     "path": "foo-bar",
     "description": "An interesting group",
     "visibility": "public",
+    "share_with_group_lock": false,
+    "require_two_factor_authentication": false,
+    "two_factor_grace_period": 48,
+    "project_creation_level": "developer",
+    "auto_devops_enabled": null,
+    "subgroup_creation_level": "owner",
+    "emails_disabled": null,
     "lfs_enabled": true,
     "avatar_url": "http://gitlab.example.com/uploads/group/avatar/1/foo.jpg",
     "web_url": "http://gitlab.example.com/groups/foo-bar",
@@ -434,6 +455,13 @@ Parameters:
 | `path`                               | string  | yes      | The path of the group. |
 | `description`                        | string  | no       | The group's description. |
 | `visibility`                         | string  | no       | The group's visibility. Can be `private`, `internal`, or `public`. |
+| `share_with_group_lock`              | boolean | no       | Prevent sharing a project with another group within this group. |
+| `require_two_factor_authentication`  | boolean | no       | Require all users in this group to setup Two-factor authentication. |
+| `two_factor_grace_period`            | integer | no       | Time before Two-factor authentication is enforced (in hours). |
+| `project_creation_level`             | string  | no       | Determine if developers can create projects in the group. Can be `noone` (No one), `maintainer` (Maintainers), or `developer` (Developers + Maintainers). |
+| `auto_devops_enabled`                | boolean | no       | Default to Auto DevOps pipeline for all projects within this group. |
+| `subgroup_creation_level`            | integer | no       | Allowed to create subgroups. Can be `owner` (Owners), or `maintainer` (Maintainers). |
+| `emails_disabled`                    | boolean | no       | Disable email notifications |
 | `lfs_enabled`                        | boolean | no       | Enable/disable Large File Storage (LFS) for the projects in this group. |
 | `request_access_enabled`             | boolean | no       | Allow users to request member access. |
 | `parent_id`                          | integer | no       | The parent group ID for creating nested group. |
@@ -472,6 +500,13 @@ PUT /groups/:id
 | `membership_lock`                    | boolean | no       | **(STARTER)** Prevent adding new members to project membership within this group. |
 | `share_with_group_lock`              | boolean | no       | Prevent sharing a project with another group within this group. |
 | `visibility`                         | string  | no       | The visibility level of the group. Can be `private`, `internal`, or `public`. |
+| `share_with_group_lock`              | boolean | no       | Prevent sharing a project with another group within this group. |
+| `require_two_factor_authentication`  | boolean | no       | Require all users in this group to setup Two-factor authentication. |
+| `two_factor_grace_period`            | integer | no       | Time before Two-factor authentication is enforced (in hours). |
+| `project_creation_level`             | string  | no       | Determine if developers can create projects in the group. Can be `noone` (No one), `maintainer` (Maintainers), or `developer` (Developers + Maintainers). |
+| `auto_devops_enabled`                | boolean | no       | Default to Auto DevOps pipeline for all projects within this group. |
+| `subgroup_creation_level`            | integer | no       | Allowed to create subgroups. Can be `owner` (Owners), or `maintainer` (Maintainers). |
+| `emails_disabled`                    | boolean | no       | Disable email notifications |
 | `lfs_enabled` (optional)             | boolean | no       | Enable/disable Large File Storage (LFS) for the projects in this group. |
 | `request_access_enabled`             | boolean | no       | Allow users to request member access. |
 | `file_template_project_id`           | integer | no       | **(PREMIUM)** The ID of a project to load custom file templates from. |
diff --git a/doc/api/issues.md b/doc/api/issues.md
index e323ebce7ca..0ddbb18ce92 100644
--- a/doc/api/issues.md
+++ b/doc/api/issues.md
@@ -58,7 +58,7 @@ GET /issues?confidential=true
 | `updated_after`     | datetime         | no         | Return issues updated on or after the given time                                                                                                    |
 | `updated_before`    | datetime         | no         | Return issues updated on or before the given time                                                                                                   |
 | `confidential`      | Boolean          | no         | Filter confidential or public issues.                                                                                                               |
-| `not`               | Hash             | no         | Return issues that do not match the parameters supplied. Accepts: `labels`, `milestone`, `author_id`, `author_username`, `assignee_id`, `assignee_username`, `my_reaction_emoji`, `search`, `in` |  
+| `not`               | Hash             | no         | Return issues that do not match the parameters supplied. Accepts: `labels`, `milestone`, `author_id`, `author_username`, `assignee_id`, `assignee_username`, `my_reaction_emoji`, `search`, `in` |
 
 ```bash
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/issues
@@ -207,7 +207,7 @@ GET /groups/:id/issues?confidential=true
 | `updated_after`     | datetime         | no         | Return issues updated on or after the given time                                                                              |
 | `updated_before`    | datetime         | no         | Return issues updated on or before the given time                                                                             |
 | `confidential`     | Boolean          | no         | Filter confidential or public issues.                                                                                         |
-| `not`               | Hash             | no         | Return issues that do not match the parameters supplied. Accepts: `labels`, `milestone`, `author_id`, `author_username`, `assignee_id`, `assignee_username`, `my_reaction_emoji`, `search`, `in` |  
+| `not`               | Hash             | no         | Return issues that do not match the parameters supplied. Accepts: `labels`, `milestone`, `author_id`, `author_username`, `assignee_id`, `assignee_username`, `my_reaction_emoji`, `search`, `in` |
 
 ```bash
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/4/issues
@@ -605,7 +605,7 @@ POST /projects/:id/issues
 | `id`                                      | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
 | `iid`                                     | integer/string | no       | The internal ID of the project's issue (requires admin or project owner rights) |
 | `title`                                   | string         | yes      | The title of an issue |
-| `description`                             | string         | no       | The description of an issue. Limited to 1 000 000 characters. |
+| `description`                             | string         | no       | The description of an issue. Limited to 1,048,576 characters. |
 | `confidential`                            | boolean        | no       | Set an issue to be confidential. Default is `false`.  |
 | `assignee_ids`                            | integer array  | no       | The ID of a user to assign issue |
 | `milestone_id`                            | integer        | no       | The global ID of a milestone to assign issue  |
@@ -615,6 +615,7 @@ POST /projects/:id/issues
 | `merge_request_to_resolve_discussions_of` | integer        | no       | The IID of a merge request in which to resolve all issues. This will fill the issue with a default description and mark all discussions as resolved. When passing a description or title, these values will take precedence over the default values.|
 | `discussion_to_resolve`                   | string         | no       | The ID of a discussion to resolve. This will fill in the issue with a default description and mark the discussion as resolved. Use in combination with `merge_request_to_resolve_discussions_of`. |
 | `weight` **(STARTER)**                    | integer        | no       | The weight of the issue. Valid values are greater than or equal to 0. |
+| `epic_iid` **(ULTIMATE)** | integer | no | IID of the epic to add the issue to. Valid values are greater than or equal to 0. |
 
 ```bash
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/4/issues?title=Issues%20with%20auth&labels=bug
@@ -706,7 +707,7 @@ PUT /projects/:id/issues/:issue_iid
 | `id`           | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
 | `issue_iid`    | integer | yes      | The internal ID of a project's issue                                                                       |
 | `title`        | string  | no       | The title of an issue                                                                                      |
-| `description`  | string  | no       | The description of an issue. Limited to 1 000 000 characters.        |
+| `description`  | string  | no       | The description of an issue. Limited to 1,048,576 characters.        |
 | `confidential` | boolean | no       | Updates an issue to be confidential                                                                        |
 | `assignee_ids` | integer array | no | The ID of the user(s) to assign the issue to. Set to `0` or provide an empty value to unassign all assignees. |
 | `milestone_id` | integer | no       | The global ID of a milestone to assign the issue to. Set to `0` or provide an empty value to unassign a milestone.|
@@ -716,6 +717,7 @@ PUT /projects/:id/issues/:issue_iid
 | `due_date`     | string  | no       | Date time string in the format YEAR-MONTH-DAY, e.g. `2016-03-11`                                           |
 | `weight` **(STARTER)** | integer | no | The weight of the issue. Valid values are greater than or equal to 0. 0                                                                    |
 | `discussion_locked` | boolean | no  | Flag indicating if the issue's discussion is locked. If the discussion is locked only project members can add or edit comments. |
+| `epic_iid` **(ULTIMATE)** | integer | no | IID of the epic to add the issue to. Valid values are greater than or equal to 0. |
 
 ```bash
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/4/issues/85?state_event=close
@@ -1370,8 +1372,11 @@ Example response:
     "state": "opened",
     "created_at": "2018-09-18T14:36:15.510Z",
     "updated_at": "2018-09-19T07:45:13.089Z",
+    "closed_by": null,
+    "closed_at": null,
     "target_branch": "v2.x",
     "source_branch": "so_long_jquery",
+    "user_notes_count": 9,
     "upvotes": 0,
     "downvotes": 0,
     "author": {
@@ -1411,10 +1416,10 @@ Example response:
     "merge_status": "cannot_be_merged",
     "sha": "3b7b528e9353295c1c125dad281ac5b5deae5f12",
     "merge_commit_sha": null,
-    "user_notes_count": 9,
     "discussion_locked": null,
     "should_remove_source_branch": null,
     "force_remove_source_branch": false,
+    "reference": "!11",
     "web_url": "https://gitlab.example.com/twitter/flight/merge_requests/4",
     "time_stats": {
       "time_estimate": 0,
@@ -1422,7 +1427,67 @@ Example response:
       "human_time_estimate": null,
       "human_total_time_spent": null
     },
-    "squash": false
+    "squash": false,
+    "task_completion_status": {
+      "count": 0,
+      "completed_count": 0
+    },
+    "changes_count": "10",
+    "latest_build_started_at": "2018-12-05T01:16:41.723Z",
+    "latest_build_finished_at": "2018-12-05T02:35:54.046Z",
+    "first_deployed_to_production_at": null,
+    "pipeline": {
+      "id": 38980952,
+      "sha": "81c6a84c7aebd45a1ac2c654aa87f11e32338e0a",
+      "ref": "test-branch",
+      "status": "success",
+      "web_url": "https://gitlab.com/gitlab-org/gitlab/pipelines/38980952"
+    },
+    "head_pipeline": {
+      "id": 38980952,
+      "sha": "81c6a84c7aebd45a1ac2c654aa87f11e32338e0a",
+      "ref": "test-branch",
+      "status": "success",
+      "web_url": "https://gitlab.example.com/twitter/flight/pipelines/38980952",
+      "before_sha": "3c738a37eb23cf4c0ed0d45d6ddde8aad4a8da51",
+      "tag": false,
+      "yaml_errors": null,
+      "user": {
+        "id": 19,
+        "name": "Jody Baumbach",
+        "username": "felipa.kuvalis",
+        "state": "active",
+        "avatar_url": "https://www.gravatar.com/avatar/6541fc75fc4e87e203529bd275fafd07?s=80&d=identicon",
+        "web_url": "https://gitlab.example.com/felipa.kuvalis"
+      },
+      "created_at": "2018-12-05T01:16:13.342Z",
+      "updated_at": "2018-12-05T02:35:54.086Z",
+      "started_at": "2018-12-05T01:16:41.723Z",
+      "finished_at": "2018-12-05T02:35:54.046Z",
+      "committed_at": null,
+      "duration": 4436,
+      "coverage": "46.68",
+      "detailed_status": {
+        "icon": "status_warning",
+        "text": "passed",
+        "label": "passed with warnings",
+        "group": "success-with-warnings",
+        "tooltip": "passed",
+        "has_details": true,
+        "details_path": "/twitter/flight/pipelines/38",
+        "illustration": null,
+        "favicon": "https://gitlab.example.com/assets/ci_favicons/favicon_status_success-8451333011eee8ce9f2ab25dc487fe24a8758c694827a582f17f42b0a90446a2.png"
+      }
+    },
+    "diff_refs": {
+      "base_sha": "d052d768f0126e8cddf80afd8b1eb07f406a3fcb",
+      "head_sha": "81c6a84c7aebd45a1ac2c654aa87f11e32338e0a",
+      "start_sha": "d052d768f0126e8cddf80afd8b1eb07f406a3fcb"
+    },
+    "merge_error": null,
+    "user": {
+      "can_merge": true
+    }
   }
 ]
 ```
diff --git a/doc/api/jobs.md b/doc/api/jobs.md
index 8ee4facc018..bafcfd110d3 100644
--- a/doc/api/jobs.md
+++ b/doc/api/jobs.md
@@ -537,9 +537,9 @@ Possible response status codes:
 | 400       | Invalid path provided                |
 | 404       | Build not found or no file/artifacts |
 
-## Get a trace file
+## Get a log file
 
-Get a trace of a specific job of a project
+Get a log (trace) of a specific job of a project:
 
 ```
 GET /projects/:id/jobs/:job_id/trace
@@ -556,10 +556,10 @@ curl --location --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.ex
 
 Possible response status codes:
 
-| Status    | Description                       |
-|-----------|-----------------------------------|
-| 200       | Serves the trace file             |
-| 404       | Build not found or no trace file  |
+| Status    | Description                   |
+|-----------|-------------------------------|
+| 200       | Serves the log file           |
+| 404       | Job not found or no log file  |
 
 ## Cancel a job
 
@@ -661,7 +661,7 @@ Example of response
 
 ## Erase a job
 
-Erase a single job of a project (remove job artifacts and a job trace)
+Erase a single job of a project (remove job artifacts and a job log)
 
 ```
 POST /projects/:id/jobs/:job_id/erase
diff --git a/doc/api/labels.md b/doc/api/labels.md
index 93833fd81cb..525dbe02e5f 100644
--- a/doc/api/labels.md
+++ b/doc/api/labels.md
@@ -12,6 +12,7 @@ GET /projects/:id/labels
 | ---------     | -------        | -------- | ---------------------                                                                                                                                                        |
 | `id`          | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user                                                              |
 | `with_counts` | boolean        | no       | Whether or not to include issue and merge request counts. Defaults to `false`. _([Introduced in GitLab 12.2](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/31543))_ |
+| `include_ancestor_groups` | boolean | no | Include ancestor groups. Defaults to `true`. |
 
 ```bash
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/1/labels?with_counts=true
@@ -89,6 +90,42 @@ Example response:
 ]
 ```
 
+## Get a single project label
+
+Get a single label for a given project.
+
+```
+GET /projects/:id/labels/:label_id
+```
+
+| Attribute     | Type           | Required | Description                                                                                                                                                                  |
+| ---------     | -------        | -------- | ---------------------                                                                                                                                                        |
+| `id`          | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user                                                              |
+| `label_id` | integer or string | yes | The ID or title of a group's label. |
+| `include_ancestor_groups` | boolean | no | Include ancestor groups. Defaults to `true`. |
+
+```bash
+curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/1/labels/bug
+```
+
+Example response:
+
+```json
+{
+  "id" : 1,
+  "name" : "bug",
+  "color" : "#d9534f",
+  "text_color" : "#FFFFFF",
+  "description": "Bug reported by user",
+  "open_issues_count": 1,
+  "closed_issues_count": 0,
+  "open_merge_requests_count": 1,
+  "subscribed": false,
+  "priority": 10,
+  "is_project_label": true
+}
+```
+
 ## Create a new label
 
 Creates a new label for the given repository with the given name and color.
@@ -132,40 +169,40 @@ Example response:
 Deletes a label with a given name.
 
 ```
-DELETE /projects/:id/labels
+DELETE /projects/:id/labels/:label_id
 ```
 
 | Attribute | Type    | Required | Description           |
 | --------- | ------- | -------- | --------------------- |
 | `id`            | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
-| `label_id`      | integer        | yes (or `name`)                   | The id of the existing label     |
-| `name`          | string         | yes (or `label_id`)               | The name of the existing label   |
+| `label_id` | integer or string | yes | The ID or title of a group's label. |
 
 ```bash
-curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/labels?name=bug"
+curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/labels/bug"
 ```
 
+NOTE: **Note:** An older endpoint `DELETE /projects/:id/labels` with `name` in the params is still available, but deprecated.
+
 ## Edit an existing label
 
 Updates an existing label with new name or new color. At least one parameter
 is required, to update the label.
 
 ```
-PUT /projects/:id/labels
+PUT /projects/:id/labels/:label_id
 ```
 
 | Attribute       | Type    | Required                          | Description                      |
 | --------------- | ------- | --------------------------------- | -------------------------------  |
 | `id`      | integer/string    | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
-| `label_id`      | integer | yes (or `name`)                   | The id of the existing label     |
-| `name`          | string  | yes (or `label_id`)               | The name of the existing label   |
+| `label_id` | integer or string | yes | The ID or title of a group's label. |
 | `new_name`      | string  | yes if `color` is not provided    | The new name of the label        |
 | `color`         | string  | yes if `new_name` is not provided | The color of the label given in 6-digit hex notation with leading '#' sign (e.g. #FFAABB) or one of the [CSS color names](https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#Color_keywords) |
 | `description`   | string  | no                                | The new description of the label |
 | `priority`    | integer | no       | The new priority of the label. Must be greater or equal than zero or `null` to remove the priority. |
 
 ```bash
-curl --request PUT --data "name=documentation&new_name=docs&color=#8E44AD&description=Documentation" --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/labels"
+curl --request PUT --data "new_name=docs&color=#8E44AD&description=Documentation" --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/labels/documentation"
 ```
 
 Example response:
@@ -186,6 +223,8 @@ Example response:
 }
 ```
 
+NOTE: **Note:** An older endpoint `PUT /projects/:id/labels` with `name` or `label_id` in the params is still available, but deprecated.
+
 ## Promote a project label to a group label
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/25218) in GitLab 12.3.
@@ -193,16 +232,16 @@ Example response:
 Promotes a project label to a group label.
 
 ```
-PUT /projects/:id/labels/promote
+PUT /projects/:id/labels/:label_id/promote
 ```
 
 | Attribute       | Type    | Required                          | Description                      |
 | --------------- | ------- | --------------------------------- | -------------------------------  |
 | `id`      | integer/string    | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
-| `name`          | string  | yes                               | The name of the existing label   |
+| `label_id` | integer or string | yes | The ID or title of a group's label. |
 
 ```bash
-curl --request PUT --data "name=documentation" --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/labels/promote"
+curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/labels/documentation/promote"
 ```
 
 Example response:
@@ -220,6 +259,8 @@ Example response:
 }
 ```
 
+NOTE: **Note:** An older endpoint `PUT /projects/:id/labels/promote` with `name` in the params is still available, but deprecated.
+
 ## Subscribe to a label
 
 Subscribes the authenticated user to a label to receive notifications.
diff --git a/doc/api/members.md b/doc/api/members.md
index da62dc53659..50dcf86c972 100644
--- a/doc/api/members.md
+++ b/doc/api/members.md
@@ -26,6 +26,7 @@ GET /projects/:id/members
 | --------- | ---- | -------- | ----------- |
 | `id`      | integer/string | yes | The ID or [URL-encoded path of the project or group](README.md#namespaced-path-encoding) owned by the authenticated user |
 | `query`   | string | no     | A query string to search for members |
+| `user_ids`   | array of integers | no     | Filter the results on the given user IDs |
 
 ```bash
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/:id/members
@@ -62,9 +63,8 @@ Example response:
 ## List all members of a group or project including inherited members
 
 Gets a list of group or project members viewable by the authenticated user, including inherited members through ancestor groups.
-When a user is a member of the project/group and of one or more ancestor groups the user is returned only once with the project access_level (if exists)
-or the access_level for the user in the first group which he belongs to in the project groups ancestors chain.
-**Note:** We plan to [change](https://gitlab.com/gitlab-org/gitlab-foss/issues/62284) this behavior to return highest access_level instead.
+When a user is a member of the project/group and of one or more ancestor groups the user is returned only once with the project `access_level` (if exists)
+or the `access_level` for the user in the first group which he belongs to in the project groups ancestors chain.
 
 ```
 GET /groups/:id/members/all
@@ -75,6 +75,7 @@ GET /projects/:id/members/all
 | --------- | ---- | -------- | ----------- |
 | `id`      | integer/string | yes | The ID or [URL-encoded path of the project or group](README.md#namespaced-path-encoding) owned by the authenticated user |
 | `query`   | string | no     | A query string to search for members |
+| `user_ids`   | array of integers | no     | Filter the results on the given user IDs |
 
 ```bash
 curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/:id/members/all
@@ -120,7 +121,7 @@ Example response:
 
 ## Get a member of a group or project
 
-Gets a member of a group or project.
+Gets a member of a group or project. Returns only direct members and not inherited members through ancestor groups.
 
 ```
 GET /groups/:id/members/:user_id
@@ -152,6 +153,42 @@ Example response:
 }
 ```
 
+## Get a member of a group or project, including inherited members
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/17744) in GitLab 12.4.
+
+Gets a member of a group or project, including members inherited through ancestor groups. See the corresponding [endpoint to list all inherited members](#list-all-members-of-a-group-or-project-including-inherited-members) for details.
+
+```
+GET /groups/:id/members/all/:user_id
+GET /projects/:id/members/all/:user_id
+```
+
+| Attribute | Type | Required | Description |
+| --------- | ---- | -------- | ----------- |
+| `id`      | integer/string | yes | The ID or [URL-encoded path of the project or group](README.md#namespaced-path-encoding) owned by the authenticated user |
+| `user_id` | integer | yes   | The user ID of the member |
+
+```bash
+curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/groups/:id/members/all/:user_id
+curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/:id/members/all/:user_id
+```
+
+Example response:
+
+```json
+{
+  "id": 1,
+  "username": "raymond_smith",
+  "name": "Raymond Smith",
+  "state": "active",
+  "avatar_url": "https://www.gravatar.com/avatar/c2525a7f58ae3776070e44c106c48e15?s=80&d=identicon",
+  "web_url": "http://192.168.1.8:3000/root",
+  "access_level": 30,
+  "expires_at": null
+}
+```
+
 ## Add a member to a group or project
 
 Adds a member to a group or project.
diff --git a/doc/api/merge_requests.md b/doc/api/merge_requests.md
index 21e24dc7934..4bc46c3030d 100644
--- a/doc/api/merge_requests.md
+++ b/doc/api/merge_requests.md
@@ -823,7 +823,7 @@ Parameters:
 
 ## Create MR Pipeline
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/31722) in Gitlab 12.3.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/31722) in GitLab 12.3.
 
 Create a new [pipeline for a merge request](../ci/merge_request_pipelines/index.md). A pipeline created via this endpoint will not run a regular branch/tag pipeline, it requires `.gitlab-ci.yml` to be configured with `only: [merge_requests]` to create jobs.
 
@@ -897,7 +897,7 @@ POST /projects/:id/merge_requests
 | `title`                    | string  | yes      | Title of MR                                                                     |
 | `assignee_id`              | integer | no       | Assignee user ID                                                                |
 | `assignee_ids`             | integer array | no | The ID of the user(s) to assign the MR to. Set to `0` or provide an empty value to unassign all assignees.  |
-| `description`              | string  | no       | Description of MR. Limited to 1 000 000 characters. |
+| `description`              | string  | no       | Description of MR. Limited to 1,048,576 characters. |
 | `target_project_id`        | integer | no       | The target project (numeric id)                                                 |
 | `labels`                   | string  | no       | Labels for MR as a comma-separated list                                         |
 | `milestone_id`             | integer | no       | The global ID of a milestone                                                           |
@@ -1050,7 +1050,7 @@ PUT /projects/:id/merge_requests/:merge_request_iid
 | `assignee_ids`             | integer array | no | The ID of the user(s) to assign the MR to. Set to `0` or provide an empty value to unassign all assignees.  |
 | `milestone_id`             | integer | no       | The global ID of a milestone to assign the merge request to. Set to `0` or provide an empty value to unassign a milestone.|
 | `labels`                   | string  | no       | Comma-separated label names for a merge request. Set to an empty string to unassign all labels.                    |
-| `description`              | string  | no       | Description of MR. Limited to 1 000 000 characters. |
+| `description`              | string  | no       | Description of MR. Limited to 1,048,576 characters. |
 | `state_event`              | string  | no       | New state (close/reopen)                                                        |
 | `remove_source_branch`     | boolean | no       | Flag indicating if a merge request should remove the source branch when merging |
 | `squash`                   | boolean | no       | Squash commits into a single commit when merging |
diff --git a/doc/api/notes.md b/doc/api/notes.md
index 1f5baf7d0e1..2cace425ff2 100644
--- a/doc/api/notes.md
+++ b/doc/api/notes.md
@@ -113,7 +113,7 @@ Parameters:
 
 - `id` (required) - The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding)
 - `issue_iid` (required) - The IID of an issue
-- `body` (required) - The content of a note. Limited to 1 000 000 characters.
+- `body` (required) - The content of a note. Limited to 1,000,000 characters.
 - `created_at` (optional) - Date time string, ISO 8601 formatted, e.g. 2016-03-11T03:45:40Z (requires admin or project/group owner rights)
 
 ```bash
@@ -133,7 +133,7 @@ Parameters:
 - `id` (required) - The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding)
 - `issue_iid` (required) - The IID of an issue
 - `note_id` (required) - The ID of a note
-- `body` (required) - The content of a note. Limited to 1 000 000 characters.
+- `body` (required) - The content of a note. Limited to 1,000,000 characters.
 
 ```bash
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/5/issues/11/notes?body=note
@@ -231,7 +231,7 @@ Parameters:
 
 - `id` (required) - The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding)
 - `snippet_id` (required) - The ID of a snippet
-- `body` (required) - The content of a note. Limited to 1 000 000 characters.
+- `body` (required) - The content of a note. Limited to 1,000,000 characters.
 - `created_at` (optional) - Date time string, ISO 8601 formatted, e.g. 2016-03-11T03:45:40Z
 
 ```bash
@@ -251,7 +251,7 @@ Parameters:
 - `id` (required) - The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding)
 - `snippet_id` (required) - The ID of a snippet
 - `note_id` (required) - The ID of a note
-- `body` (required) - The content of a note. Limited to 1 000 000 characters.
+- `body` (required) - The content of a note. Limited to 1,000,000 characters.
 
 ```bash
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/5/snippets/11/notes?body=note
@@ -354,7 +354,7 @@ Parameters:
 
 - `id` (required) - The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding)
 - `merge_request_iid` (required) - The IID of a merge request
-- `body` (required) - The content of a note. Limited to 1 000 000 characters.
+- `body` (required) - The content of a note. Limited to 1,000,000 characters.
 - `created_at` (optional) - Date time string, ISO 8601 formatted, e.g. 2016-03-11T03:45:40Z
 
 ### Modify existing merge request note
@@ -370,7 +370,7 @@ Parameters:
 - `id` (required) - The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding)
 - `merge_request_iid` (required) - The IID of a merge request
 - `note_id` (required) - The ID of a note
-- `body` (required) - The content of a note. Limited to 1 000 000 characters.
+- `body` (required) - The content of a note. Limited to 1,000,000 characters.
 
 ```bash
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/5/merge_requests/11/notes?body=note
@@ -472,7 +472,7 @@ Parameters:
 | --------- | -------------- | -------- | ----------- |
 | `id`      | integer/string | yes | The ID or [URL-encoded path of the group](README.md#namespaced-path-encoding) |
 | `epic_id` | integer | yes  | The ID of an epic |
-| `body`    | string  | yes  | The content of a note. Limited to 1 000 000 characters. |
+| `body`    | string  | yes  | The content of a note. Limited to 1,000,000 characters. |
 
 ```bash
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/5/snippet/11/notes?body=note
@@ -493,7 +493,7 @@ Parameters:
 | `id`      | integer/string | yes | The ID or [URL-encoded path of the group](README.md#namespaced-path-encoding) |
 | `epic_id` | integer | yes  | The ID of an epic |
 | `note_id` | integer | yes  | The ID of a note |
-| `body`    | string  | yes  | The content of a note. Limited to 1 000 000 characters. |
+| `body`    | string  | yes  | The content of a note. Limited to 1,000,000 characters. |
 
 ```bash
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/5/snippet/11/notes?body=note
diff --git a/doc/api/oauth2.md b/doc/api/oauth2.md
index f9382361187..6b49a39b83a 100644
--- a/doc/api/oauth2.md
+++ b/doc/api/oauth2.md
@@ -102,7 +102,7 @@ CAUTION: **Important:**
 Avoid using this flow for applications that store data outside of the GitLab
 instance. If you do, make sure to verify `application id` associated with the
 access token before granting access to the data
-(see [/oauth/token/info](https://github.com/doorkeeper-gem/doorkeeper/wiki/API-endpoint-descriptions-and-examples#get----oauthtokeninfo)).
+(see [`/oauth/token/info`](https://github.com/doorkeeper-gem/doorkeeper/wiki/API-endpoint-descriptions-and-examples#get----oauthtokeninfo)).
 
 Unlike the web flow, the client receives an `access token` immediately as a
 result of the authorization request. The flow does not use the client secret
diff --git a/doc/api/pipelines.md b/doc/api/pipelines.md
index c012c947c3a..90a4f8d6e26 100644
--- a/doc/api/pipelines.md
+++ b/doc/api/pipelines.md
@@ -34,14 +34,18 @@ Example of response
     "status": "pending",
     "ref": "new-pipeline",
     "sha": "a91957a858320c0e17f3a0eca7cfacbff50ea29a",
-    "web_url": "https://example.com/foo/bar/pipelines/47"
+    "web_url": "https://example.com/foo/bar/pipelines/47",
+    "created_at": "2016-08-11T11:28:34.085Z",
+    "updated_at": "2016-08-11T11:32:35.169Z",
   },
   {
     "id": 48,
     "status": "pending",
     "ref": "new-pipeline",
     "sha": "eb94b618fb5865b26e80fdd8ae531b7a63ad851a",
-    "web_url": "https://example.com/foo/bar/pipelines/48"
+    "web_url": "https://example.com/foo/bar/pipelines/48",
+    "created_at": "2016-08-12T10:06:04.561Z",
+    "updated_at": "2016-08-12T10:09:56.223Z",
   }
 ]
 ```
diff --git a/doc/api/project_aliases.md b/doc/api/project_aliases.md
index 9d59ca1e3b5..da8d7600c7c 100644
--- a/doc/api/project_aliases.md
+++ b/doc/api/project_aliases.md
@@ -23,12 +23,12 @@ Example response:
   {
     "id": 1,
     "project_id": 1,
-    "name": "gitlab-ce"
+    "name": "gitlab-foss"
   },
   {
     "id": 2,
     "project_id": 2,
-    "name": "gitlab-ee"
+    "name": "gitlab"
   }
 ]
 ```
@@ -46,7 +46,7 @@ GET /project_aliases/:name
 | `name`    | string | yes      | The name of the alias |
 
 ```
-curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/project_aliases/gitlab-ee"
+curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/project_aliases/gitlab"
 ```
 
 Example response:
@@ -55,7 +55,7 @@ Example response:
 {
   "id": 1,
   "project_id": 1,
-  "name": "gitlab-ee"
+  "name": "gitlab"
 }
 ```
 
@@ -74,13 +74,13 @@ POST /project_aliases
 | `name`       | string         | yes      | The name of the alias. Must be unique. |
 
 ```
-curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/project_aliases" --form "project_id=1" --form "name=gitlab-ee"
+curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/project_aliases" --form "project_id=1" --form "name=gitlab"
 ```
 
 or
 
 ```
-curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/project_aliases" --form "project_id=gitlab-org/gitlab-ee" --form "name=gitlab-ee"
+curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/project_aliases" --form "project_id=gitlab-org/gitlab" --form "name=gitlab"
 ```
 
 Example response:
@@ -89,7 +89,7 @@ Example response:
 {
   "id": 1,
   "project_id": 1,
-  "name": "gitlab-ee"
+  "name": "gitlab"
 }
 ```
 
@@ -107,5 +107,5 @@ DELETE /project_aliases/:name
 | `name`    | string | yes      | The name of the alias |
 
 ```
-curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/project_aliases/gitlab-ee"
+curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/project_aliases/gitlab"
 ```
diff --git a/doc/api/project_import_export.md b/doc/api/project_import_export.md
index e285c721d11..cd02d423a9f 100644
--- a/doc/api/project_import_export.md
+++ b/doc/api/project_import_export.md
@@ -111,6 +111,7 @@ POST /projects/import
 | Attribute | Type           | Required | Description                              |
 | --------- | -------------- | -------- | ---------------------------------------- |
 | `namespace` | integer/string | no | The ID or path of the namespace that the project will be imported to. Defaults to the current user's namespace |
+| `name` | string | no | The name of the project to be imported. Defaults to the path of the project if not provided |
 | `file` | string | yes | The file to be uploaded |
 | `path` | string | yes | Name and path for new project |
 | `overwrite` | boolean | no | If there is a project with the same path the import will overwrite it. Default to false |
@@ -131,14 +132,12 @@ cURL doesn't support posting a file from a remote server. Importing a project fr
 
 ```python
 import requests
-import urllib
-import json
-import sys
+from io import BytesIO
 
-s3_file = urllib.urlopen(presigned_url)
+s3_file = requests.get(presigned_url)
 
 url =  'https://gitlab.example.com/api/v4/projects/import'
-files = {'file': s3_file}
+files = {'file': ('file.tar.gz', BytesIO(s3_file.content))}
 data = {
     "path": "example-project",
     "namespace": "example-group"
diff --git a/doc/api/project_snippets.md b/doc/api/project_snippets.md
index c2a39fd2178..7a6c90701ba 100644
--- a/doc/api/project_snippets.md
+++ b/doc/api/project_snippets.md
@@ -78,7 +78,7 @@ Parameters:
 - `title` (required) - The title of a snippet
 - `file_name` (required) - The name of a snippet file
 - `description` (optional) - The description of a snippet
-- `code` (required) - The content of a snippet
+- `content` (required) - The content of a snippet
 - `visibility` (required) - The snippet's visibility
 
 Example request:
@@ -97,7 +97,7 @@ curl --request POST https://gitlab.com/api/v4/projects/:id/snippets \
   "title" : "Example Snippet Title",
   "description" : "More verbose snippet description",
   "file_name" : "example.txt",
-  "code" : "source code \n with multiple lines\n",
+  "content" : "source code \n with multiple lines\n",
   "visibility" : "private"
 }
 ```
@@ -117,7 +117,7 @@ Parameters:
 - `title` (optional) - The title of a snippet
 - `file_name` (optional) - The name of a snippet file
 - `description` (optional) - The description of a snippet
-- `code` (optional) - The content of a snippet
+- `content` (optional) - The content of a snippet
 - `visibility` (optional) - The snippet's visibility
 
 Example request:
@@ -136,7 +136,7 @@ curl --request PUT https://gitlab.com/api/v4/projects/:id/snippets \
   "title" : "Updated Snippet Title",
   "description" : "More verbose snippet description",
   "file_name" : "new_filename.txt",
-  "code" : "updated source code \n with multiple lines\n",
+  "content" : "updated source code \n with multiple lines\n",
   "visibility" : "private"
 }
 ```
diff --git a/doc/api/projects.md b/doc/api/projects.md
index af0c8ed7c5b..c352b972b17 100644
--- a/doc/api/projects.md
+++ b/doc/api/projects.md
@@ -809,16 +809,16 @@ If the project is a fork, and you provide a valid token to authenticate, the
       "description":"GitLab Community Edition",
       "name":"GitLab Community Edition",
       "name_with_namespace":"GitLab.org / GitLab Community Edition",
-      "path":"gitlab-ce",
-      "path_with_namespace":"gitlab-org/gitlab-ce",
+      "path":"gitlab-foss",
+      "path_with_namespace":"gitlab-org/gitlab-foss",
       "created_at":"2013-09-26T06:02:36.000Z",
       "default_branch":"master",
       "tag_list":[],
-      "ssh_url_to_repo":"git@gitlab.com:gitlab-org/gitlab-ce.git",
+      "ssh_url_to_repo":"git@gitlab.com:gitlab-org/gitlab-foss.git",
       "http_url_to_repo":"https://gitlab.com/gitlab-org/gitlab-foss.git",
       "web_url":"https://gitlab.com/gitlab-org/gitlab-foss",
       "avatar_url":"https://assets.gitlab-static.net/uploads/-/system/project/avatar/13083/logo-extra-whitespace.png",
-      "license_url": "https://gitlab.com/gitlab-org/gitlab-foss/blob/master/LICENSE",
+      "license_url": "https://gitlab.com/gitlab-org/gitlab/blob/master/LICENSE",
       "license": {
         "key": "mit",
         "name": "MIT License",
@@ -931,9 +931,13 @@ POST /projects
 | `auto_devops_deploy_strategy` | string | no | Auto Deploy strategy (`continuous`, `manual` or `timed_incremental`) |
 | `repository_storage` | string | no | **(STARTER ONLY)** Which storage shard the repository is on. Available only to admins |
 | `approvals_before_merge` | integer | no | **(STARTER)** How many approvers should approve merge requests by default |
+| `external_authorization_classification_label` | string | no | **(PREMIUM)** The classification label for the project |
 | `mirror` | boolean | no | **(STARTER)** Enables pull mirroring in a project |
 | `mirror_trigger_builds` | boolean | no | **(STARTER)** Pull mirroring triggers builds |
 | `initialize_with_readme` | boolean | no | `false` by default |
+| `template_name` | string | no | When used without `use_custom_template`, name of a [built-in project template](../gitlab-basics/create-project.md#built-in-templates). When used with `use_custom_template`, name of a custom project template |
+| `use_custom_template` | boolean | no | **(PREMIUM)** Use either custom [instance](../user/admin_area/custom_project_templates.md) or [group](../user/group/custom_project_templates.md) (with `group_with_project_templates_id`) project template |
+| `group_with_project_templates_id` | integer | no | **(PREMIUM)** For group-level custom templates, specifies ID of group from which all the custom project templates are sourced. Leave empty for instance-level templates. Requires `use_custom_template` to be true |
 
 NOTE: **Note:** If your HTTP repository is not publicly accessible,
 add authentication information to the URL: `https://username:password@gitlab.company.com/group/project.git`
@@ -991,6 +995,7 @@ POST /projects/user/:user_id
 | `external_authorization_classification_label` | string | no | **(PREMIUM)** The classification label for the project |
 | `mirror` | boolean | no | **(STARTER)** Enables pull mirroring in a project |
 | `mirror_trigger_builds` | boolean | no | **(STARTER)** Pull mirroring triggers builds |
+| `initialize_with_readme` | boolean | no | `false` by default |
 | `template_name` | string | no | When used without `use_custom_template`, name of a [built-in project template](../gitlab-basics/create-project.md#built-in-templates). When used with `use_custom_template`, name of a custom project template |
 | `use_custom_template` | boolean | no | **(PREMIUM)** Use either custom [instance](../user/admin_area/custom_project_templates.md) or [group](../user/group/custom_project_templates.md) (with `group_with_project_templates_id`) project template |
 | `group_with_project_templates_id` | integer | no | **(PREMIUM)** For group-level custom templates, specifies ID of group from which all the custom project templates are sourced. Leave empty for instance-level templates. Requires `use_custom_template` to be true |
@@ -2018,7 +2023,7 @@ Read more in the [Project members](members.md) documentation.
 
 ## Start the pull mirroring process for a Project **(STARTER)**
 
-> Introduced in [GitLab Starter](https://about.gitlab.com/pricing) 10.3.
+> Introduced in [GitLab Starter](https://about.gitlab.com/pricing/) 10.3.
 
 ```
 POST /projects/:id/mirror/pull
diff --git a/doc/api/protected_branches.md b/doc/api/protected_branches.md
index a14c9046ca7..4a750b42f65 100644
--- a/doc/api/protected_branches.md
+++ b/doc/api/protected_branches.md
@@ -46,7 +46,8 @@ Example response:
         "access_level": 40,
         "access_level_description": "Maintainers"
       }
-    ]
+    ],
+    "code_owner_approval_required": "false"
   },
   ...
 ]
@@ -76,7 +77,8 @@ Example response:
         "group_id": 1234,
         "access_level_description": "Example Merge Group"
       }
-    ]
+    ],
+    "code_owner_approval_required": "false"
   },
   ...
 ]
@@ -115,7 +117,8 @@ Example response:
       "access_level": 40,
       "access_level_description": "Maintainers"
     }
-  ]
+  ],
+  "code_owner_approval_required": "false"
 }
 ```
 
@@ -142,7 +145,8 @@ Example response:
       "group_id": 1234,
       "access_level_description": "Example Merge Group"
     }
-  ]
+  ],
+  "code_owner_approval_required": "false"
 }
 ```
 
@@ -161,14 +165,15 @@ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" 'https://gitla
 
 | Attribute | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
-| `id`                     | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
-| `name`                   | string         | yes | The name of the branch or wildcard |
-| `push_access_level`      | string         | no  | Access levels allowed to push (defaults: `40`, maintainer access level) |
-| `merge_access_level`     | string         | no  | Access levels allowed to merge (defaults: `40`, maintainer access level) |
-| `unprotect_access_level` | string         | no  | Access levels allowed to unprotect (defaults: `40`, maintainer access level) |
-| `allowed_to_push`        | array          | no  | **(STARTER)** Array of access levels allowed to push, with each described by a hash |
-| `allowed_to_merge`       | array          | no  | **(STARTER)** Array of access levels allowed to merge, with each described by a hash |
-| `allowed_to_unprotect`   | array          | no  | **(STARTER)**Array of access levels allowed to unprotect, with each described by a hash |
+| `id`                            | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
+| `name`                          | string         | yes | The name of the branch or wildcard |
+| `push_access_level`             | string         | no  | Access levels allowed to push (defaults: `40`, maintainer access level) |
+| `merge_access_level`            | string         | no  | Access levels allowed to merge (defaults: `40`, maintainer access level) |
+| `unprotect_access_level`        | string         | no  | Access levels allowed to unprotect (defaults: `40`, maintainer access level) |
+| `allowed_to_push`               | array          | no  | **(STARTER)** Array of access levels allowed to push, with each described by a hash |
+| `allowed_to_merge`              | array          | no  | **(STARTER)** Array of access levels allowed to merge, with each described by a hash |
+| `allowed_to_unprotect`          | array          | no  | **(STARTER)** Array of access levels allowed to unprotect, with each described by a hash |
+| `code_owner_approval_required`  | boolean        | no  | **(PREMIUM)** Prevent pushes to this branch if it matches an item in the [`CODEOWNERS` file](../user/project/code_owners.md). (defaults: false) |
 
 Example response:
 
@@ -192,7 +197,8 @@ Example response:
       "access_level": 40,
       "access_level_description": "Maintainers"
     }
-  ]
+  ],
+  "code_owner_approval_required": "false"
 }
 ```
 
@@ -227,7 +233,8 @@ Example response:
       "group_id": null,
       "access_level_description": "Maintainers"
     }
-  ]
+  ],
+  "code_owner_approval_required": "false"
 }
 ```
 
@@ -268,7 +275,8 @@ Example response:
       "group_id": null,
       "access_level_description": "Maintainers"
     }
-  ]
+  ],
+  "code_owner_approval_required": "false"
 }
 ```
 
@@ -288,3 +296,21 @@ curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" 'https://git
 | --------- | ---- | -------- | ----------- |
 | `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
 | `name` | string | yes | The name of the branch |
+
+## Require code owner approvals for a single branch
+
+Update the "code owner approval required" option for the given protected branch protected branch.
+
+```
+PATCH /projects/:id/protected_branches/:name
+```
+
+```bash
+curl --request PATCH --header "PRIVATE-TOKEN: <your_access_token>" 'https://gitlab.example.com/api/v4/projects/5/protected_branches/feature-branch'
+```
+
+| Attribute | Type | Required | Description |
+| --------- | ---- | -------- | ----------- |
+| `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
+| `name` | string | yes | The name of the branch |
+| `code_owner_approval_required`  | boolean        | no  | **(PREMIUM)** Prevent pushes to this branch if it matches an item in the [`CODEOWNERS` file](../user/project/code_owners.md). (defaults: false)|
diff --git a/doc/api/releases/index.md b/doc/api/releases/index.md
index c856a06b57d..ee2df3e4c5d 100644
--- a/doc/api/releases/index.md
+++ b/doc/api/releases/index.md
@@ -85,6 +85,8 @@ Example response:
             "web_url":"https://gitlab.example.com/root/awesome-app/-/milestones/2"
          }
       ],
+      "commit_path":"/root/awesome-app/commit/588440f66559714280628a4f9799f0c4eb880a4a",
+      "tag_path":"/root/awesome-app/-/tags/v0.11.1",
       "assets":{
          "count":6,
          "sources":[
@@ -119,7 +121,7 @@ Example response:
                "external":true
             }
          ]
-      }
+      },
    },
    {
       "tag_name":"v0.1",
@@ -175,7 +177,7 @@ Example response:
          "links":[
 
          ]
-      }
+      },
    }
 ]
 ```
@@ -261,6 +263,8 @@ Example response:
          "web_url":"https://gitlab.example.com/root/awesome-app/-/milestones/2"
        }
    ],
+   "commit_path":"/root/awesome-app/commit/588440f66559714280628a4f9799f0c4eb880a4a",
+   "tag_path":"/root/awesome-app/-/tags/v0.11.1",
    "assets":{
       "count":4,
       "sources":[
@@ -284,7 +288,7 @@ Example response:
       "links":[
 
       ]
-   }
+   },
 }
 ```
 
@@ -296,18 +300,18 @@ Create a Release. You need push access to the repository to create a Release.
 POST /projects/:id/releases
 ```
 
-| Attribute          | Type            | Required | Description                                                                                                                      |
-| -------------------| --------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------- |
-| `id`               | integer/string  | yes      | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding).                                              |
-| `name`             | string          | yes      | The release name.                                                                                                                |
-| `tag_name`         | string          | yes      | The tag where the release will be created from.                                                                                  |
-| `description`      | string          | yes      | The description of the release. You can use [markdown](../../user/markdown.md).                                                  |
-| `ref`              | string          | no       | If `tag_name` doesn't exist, the release will be created from `ref`. It can be a commit SHA, another tag name, or a branch name. |
-| `milestones`       | array of string | no       | The title of each milestone the release is associated with.                                                                      |
-| `assets:links`     | array of hash   | no       | An array of assets links.                                                                                                        |
-| `assets:links:name`| string          | required by: `assets:links` | The name of the link.                                                                                         |
-| `assets:links:url` | string          | required by: `assets:links` | The url of the link.                                                                                          |
-| `released_at`      | datetime        | no       | The date when the release will be/was ready. Defaults to the current time. Expected in ISO 8601 format (`2019-03-15T08:00:00Z`). |
+| Attribute          | Type            | Required                    | Description                                                                                                                      |
+| -------------------| --------------- | --------                    | -------------------------------------------------------------------------------------------------------------------------------- |
+| `id`               | integer/string  | yes                         | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding).                                              |
+| `name`             | string          | yes                         | The release name.                                                                                                                |
+| `tag_name`         | string          | yes                         | The tag where the release will be created from.                                                                                  |
+| `description`      | string          | yes                         | The description of the release. You can use [markdown](../../user/markdown.md).                                                  |
+| `ref`              | string          | yes, if `tag_name` doesn't exist | If `tag_name` doesn't exist, the release will be created from `ref`. It can be a commit SHA, another tag name, or a branch name. |
+| `milestones`       | array of string | no                          | The title of each milestone the release is associated with.                                                                      |
+| `assets:links`     | array of hash   | no                          | An array of assets links.                                                                                                        |
+| `assets:links:name`| string          | required by: `assets:links` | The name of the link.                                                                                                            |
+| `assets:links:url` | string          | required by: `assets:links` | The url of the link.                                                                                                             |
+| `released_at`      | datetime        | no                          | The date when the release will be/was ready. Defaults to the current time. Expected in ISO 8601 format (`2019-03-15T08:00:00Z`). |
 
 Example request:
 
@@ -379,6 +383,8 @@ Example response:
          "web_url":"https://gitlab.example.com/root/awesome-app/-/milestones/2"
        }
    ],
+   "commit_path":"/root/awesome-app/commit/588440f66559714280628a4f9799f0c4eb880a4a",
+   "tag_path":"/root/awesome-app/-/tags/v0.11.1",
    "assets":{
       "count":5,
       "sources":[
@@ -407,7 +413,7 @@ Example response:
             "external":true
          }
       ]
-   }
+   },
 }
 ```
 
@@ -483,6 +489,8 @@ Example response:
          "web_url":"https://gitlab.example.com/root/awesome-app/-/milestones/3"
       }
    ],
+   "commit_path":"/root/awesome-app/commit/588440f66559714280628a4f9799f0c4eb880a4a",
+   "tag_path":"/root/awesome-app/-/tags/v0.11.1",
    "assets":{
       "count":4,
       "sources":[
@@ -506,7 +514,7 @@ Example response:
       "links":[
 
       ]
-   }
+   },
 }
 ```
 
@@ -563,6 +571,8 @@ Example response:
       "committer_email":"admin@example.com",
       "committed_date":"2019-01-03T01:53:28.000Z"
    },
+   "commit_path":"/root/awesome-app/commit/588440f66559714280628a4f9799f0c4eb880a4a",
+   "tag_path":"/root/awesome-app/-/tags/v0.11.1",
    "assets":{
       "count":4,
       "sources":[
@@ -586,7 +596,7 @@ Example response:
       "links":[
 
       ]
-   }
+   },
 }
 ```
 
diff --git a/doc/api/runners.md b/doc/api/runners.md
index 51a546e91dc..45d68e40777 100644
--- a/doc/api/runners.md
+++ b/doc/api/runners.md
@@ -184,8 +184,8 @@ Example response:
             "id": 1,
             "name": "GitLab Community Edition",
             "name_with_namespace": "GitLab.org / GitLab Community Edition",
-            "path": "gitlab-ce",
-            "path_with_namespace": "gitlab-org/gitlab-ce"
+            "path": "gitlab-foss",
+            "path_with_namespace": "gitlab-org/gitlab-foss"
         }
     ],
     "token": "205086a8e3b9a2b818ffac9b89d102",
@@ -243,8 +243,8 @@ Example response:
             "id": 1,
             "name": "GitLab Community Edition",
             "name_with_namespace": "GitLab.org / GitLab Community Edition",
-            "path": "gitlab-ce",
-            "path_with_namespace": "gitlab-org/gitlab-ce"
+            "path": "gitlab-foss",
+            "path_with_namespace": "gitlab-org/gitlab-foss"
         }
     ],
     "token": "205086a8e3b9a2b818ffac9b89d102",
diff --git a/doc/api/scim.md b/doc/api/scim.md
index bc4f2bf9040..8cbd6103e88 100644
--- a/doc/api/scim.md
+++ b/doc/api/scim.md
@@ -24,6 +24,11 @@ Parameters:
 |:----------|:--------|:---------|:----------------------------------------------------------------------------------------------------------------------------------------|
 | `filter`   | string  | yes     | A [filter](#available-filters) expression. |
 | `group_path` | string | yes    | Full path to the group. |
+| `startIndex` | integer | no    | The 1-based index indicating where to start returning results from. A value of less than one will be interpreted as 1. |
+| `count` | integer | no    | Desired maximum number of query results. |
+
+NOTE: **Note:**
+Pagination follows the [SCIM spec](https://tools.ietf.org/html/rfc7644#section-3.4.2.4) rather than GitLab pagination as used elsewhere. If records change between requests it is possible for a page to either be missing records that have moved to a different page or repeat records from a previous request.
 
 Example request:
 
diff --git a/doc/api/services.md b/doc/api/services.md
index ff181f2ba61..4abc02dec3c 100644
--- a/doc/api/services.md
+++ b/doc/api/services.md
@@ -10,7 +10,7 @@ Asana - Teamwork without email
 
 Set Asana service for a project.
 
-> This service adds commit messages as comments to Asana tasks. Once enabled, commit messages are checked for Asana task URLs (for example, `https://app.asana.com/0/123456/987654`) or task IDs starting with # (for example, `#987654`). Every task ID found will get the commit comment added to it. You can also close a task with a message containing: `fix #123456`. You can find your Api Keys here: <https://asana.com/developers/documentation/getting-started/auth#api-key>.
+> This service adds commit messages as comments to Asana tasks. Once enabled, commit messages are checked for Asana task URLs (for example, `https://app.asana.com/0/123456/987654`) or task IDs starting with # (for example, `#987654`). Every task ID found will get the commit comment added to it. You can also close a task with a message containing: `fix #123456`. You can find your API Keys here: <https://asana.com/developers/documentation/getting-started/auth#api-key>.
 
 ```
 PUT /projects/:id/services/asana
@@ -414,6 +414,42 @@ Get Flowdock service settings for a project.
 GET /projects/:id/services/flowdock
 ```
 
+## GitHub **(PREMIUM)**
+
+Code collaboration software.
+
+### Create/Edit GitHub service
+
+Set GitHub service for a project.
+
+```
+PUT /projects/:id/services/github
+```
+
+Parameters:
+
+| Parameter | Type | Required | Description |
+| --------- | ---- | -------- | ----------- |
+| `token` | string | true | GitHub API token with `repo:status` OAuth scope |
+| `repository_url` | string | true | GitHub repository URL |
+| `static_context` | boolean | false | Append instance name instead of branch to [status check name](../user/project/integrations/github.md#static--dynamic-status-check-names) |
+
+### Delete GitHub service
+
+Delete GitHub service for a project.
+
+```
+DELETE /projects/:id/services/github
+```
+
+### Get GitHub service settings
+
+Get GitHub service settings for a project.
+
+```
+GET /projects/:id/services/github
+```
+
 ## Hangouts Chat
 
 Google GSuite team collaboration tool.
@@ -1189,7 +1225,7 @@ GET /projects/:id/services/jenkins-deprecated
 ```
 
 [jira-doc]: ../user/project/integrations/jira.md
-[old-jira-api]: https://gitlab.com/gitlab-org/gitlab-foss/blob/8-13-stable/doc/api/services.md#jira
+[old-jira-api]: https://gitlab.com/gitlab-org/gitlab/blob/8-13-stable/doc/api/services.md#jira
 
 ## MockCI
 
diff --git a/doc/api/settings.md b/doc/api/settings.md
index 39fc848b272..2d9e435bbb6 100644
--- a/doc/api/settings.md
+++ b/doc/api/settings.md
@@ -1,7 +1,3 @@
----
-table_display_block: true
----
-
 # Application settings API
 
 These API calls allow you to read and modify GitLab instance
@@ -183,8 +179,8 @@ are listed in the descriptions of the relevant settings.
 | `admin_notification_email`               | string           | no                                   | Abuse reports will be sent to this address if it is set. Abuse reports are always available in the admin area. |
 | `after_sign_out_path`                    | string           | no                                   | Where to redirect users after logout. |
 | `after_sign_up_text`                     | string           | no                                   | Text shown to the user after signing up |
-| `akismet_api_key`                        | string           | required by: `akismet_enabled`       | API key for akismet spam protection. |
-| `akismet_enabled`                        | boolean          | no                                   | (**If enabled, requires:** `akismet_api_key`) Enable or disable akismet spam protection. |
+| `akismet_api_key`                        | string           | required by: `akismet_enabled`       | API key for Akismet spam protection. |
+| `akismet_enabled`                        | boolean          | no                                   | (**If enabled, requires:** `akismet_api_key`) Enable or disable Akismet spam protection. |
 | `allow_group_owners_to_manage_ldap`      | boolean          | no                                   | **(PREMIUM)** Set to `true` to allow group owners to manage LDAP |
 | `allow_local_requests_from_hooks_and_services` | boolean    | no                                   | (Deprecated: Use `allow_local_requests_from_web_hooks_and_services` instead) Allow requests to the local network from hooks and services. |
 | `allow_local_requests_from_system_hooks` | boolean    | no                                   | Allow requests to the local network from system hooks. |
@@ -218,7 +214,7 @@ are listed in the descriptions of the relevant settings.
 | `ed25519_key_restriction`                | integer          | no                                   | The minimum allowed curve size (in bits) of an uploaded ED25519 key. Default is `0` (no restriction). `-1` disables ED25519 keys. |
 | `elasticsearch_aws_access_key`           | string           | no                                   | **(PREMIUM)** AWS IAM access key |
 | `elasticsearch_aws`                      | boolean          | no                                   | **(PREMIUM)** Enable the use of AWS hosted Elasticsearch |
-| `elasticsearch_aws_region`               | string           | no                                   | **(PREMIUM)** The AWS region the elasticsearch domain is configured |
+| `elasticsearch_aws_region`               | string           | no                                   | **(PREMIUM)** The AWS region the Elasticsearch domain is configured |
 | `elasticsearch_aws_secret_access_key`    | string           | no                                   | **(PREMIUM)** AWS IAM secret access key |
 | `elasticsearch_indexing`                 | boolean          | no                                   | **(PREMIUM)** Enable Elasticsearch indexing |
 | `elasticsearch_limit_indexing`           | boolean          | no                                   | **(PREMIUM)** Limit Elasticsearch to index certain namespaces and projects |
@@ -290,12 +286,14 @@ are listed in the descriptions of the relevant settings.
 | `plantuml_url`                           | string           | required by: `plantuml_enabled`      | The PlantUML instance URL for integration. |
 | `polling_interval_multiplier`            | decimal          | no                                   | Interval multiplier used by endpoints that perform polling. Set to `0` to disable polling. |
 | `project_export_enabled`                 | boolean          | no                                   | Enable project export. |
-| `prometheus_metrics_enabled`             | boolean          | no                                   | Enable prometheus metrics. |
+| `prometheus_metrics_enabled`             | boolean          | no                                   | Enable Prometheus metrics. |
 | `protected_ci_variables`                 | boolean          | no                                   | Environment variables are protected by default. |
 | `pseudonymizer_enabled`                  | boolean          | no                                   | **(PREMIUM)** When enabled, GitLab will run a background job that will produce pseudonymized CSVs of the GitLab database that will be uploaded to your configured object storage directory.
-| `recaptcha_enabled`                      | boolean          | no                                   | (**If enabled, requires:** `recaptcha_private_key` and `recaptcha_site_key`) Enable recaptcha. |
-| `recaptcha_private_key`                  | string           | required by: `recaptcha_enabled`     | Private key for recaptcha. |
-| `recaptcha_site_key`                     | string           | required by: `recaptcha_enabled`     | Site key for recaptcha. |
+| `push_event_hooks_limit`                 | integer          | no                                   | Number of changes (branches or tags) in a single push to determine whether webhooks and services will be fired or not. Webhooks and services won't be submitted if it surpasses that value. |
+| `push_event_activities_limit`            | integer          | no                                   | Number of changes (branches or tags) in a single push to determine whether individual push events or bulk push events will be created. [Bulk push events will be created](../user/admin_area/settings/push_event_activities_limit.md) if it surpasses that value. |
+| `recaptcha_enabled`                      | boolean          | no                                   | (**If enabled, requires:** `recaptcha_private_key` and `recaptcha_site_key`) Enable reCAPTCHA. |
+| `recaptcha_private_key`                  | string           | required by: `recaptcha_enabled`     | Private key for reCAPTCHA. |
+| `recaptcha_site_key`                     | string           | required by: `recaptcha_enabled`     | Site key for reCAPTCHA. |
 | `receive_max_input_size`                 | integer          | no                                   | Maximum push size (MB). |
 | `repository_checks_enabled`              | boolean          | no                                   | GitLab will periodically run `git fsck` in all project and wiki repositories to look for silent disk corruption issues. |
 | `repository_size_limit`                  | integer          | no                                   | **(PREMIUM)** Size limit per repository (MB) |
diff --git a/doc/api/tags.md b/doc/api/tags.md
index 3807688ffe3..56143969e3c 100644
--- a/doc/api/tags.md
+++ b/doc/api/tags.md
@@ -116,6 +116,12 @@ Parameters:
 - `message` (optional) - Creates annotated tag.
 - `release_description` (optional) - Add release notes to the Git tag and store it in the GitLab database.
 
+```bash
+curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/5/repository/tags?tag_name=test&ref=master"
+```
+
+Example response:
+
 ```json
 {
   "commit": {
diff --git a/doc/api/templates/gitignores.md b/doc/api/templates/gitignores.md
index 0b6d944cb62..45820b24f10 100644
--- a/doc/api/templates/gitignores.md
+++ b/doc/api/templates/gitignores.md
@@ -12,10 +12,12 @@ information on `gitignore`, see the
 
 Get all `.gitignore` templates.
 
-```
+```plaintext
 GET /templates/gitignores
 ```
 
+Example request:
+
 ```bash
 curl https://gitlab.example.com/api/v4/templates/gitignores
 ```
@@ -111,14 +113,16 @@ Example response:
 
 Get a single `.gitignore` template.
 
-```
+```plaintext
 GET /templates/gitignores/:key
 ```
 
-| Attribute  | Type   | Required | Description |
-| ---------- | ------ | -------- | ----------- |
+| Attribute  | Type   | Required | Description                          |
+| ---------- | ------ | -------- | ------------------------------------ |
 | `key`      | string | yes      | The key of the `.gitignore` template |
 
+Example request:
+
 ```bash
 curl https://gitlab.example.com/api/v4/templates/gitignores/Ruby
 ```
diff --git a/doc/api/templates/gitlab_ci_ymls.md b/doc/api/templates/gitlab_ci_ymls.md
index 80f94b953e3..b8fdb9e233c 100644
--- a/doc/api/templates/gitlab_ci_ymls.md
+++ b/doc/api/templates/gitlab_ci_ymls.md
@@ -12,10 +12,12 @@ information on CI/CD pipeline configuration in GitLab, see the
 
 Get all GitLab CI YML templates.
 
-```
+```plaintext
 GET /templates/gitlab_ci_ymls
 ```
 
+Example request:
+
 ```bash
 curl https://gitlab.example.com/api/v4/templates/gitlab_ci_ymls
 ```
@@ -29,6 +31,10 @@ Example response:
     "name": "Android"
   },
   {
+    "key": "Android-Fastlane",
+    "name": "Android-Fastlane"
+  },
+  {
     "key": "Auto-DevOps",
     "name": "Auto-DevOps"
   },
@@ -49,6 +55,10 @@ Example response:
     "name": "Clojure"
   },
   {
+    "key": "Code-Quality",
+    "name": "Code-Quality"
+  },
+  {
     "key": "Crystal",
     "name": "Crystal"
   },
@@ -95,14 +105,6 @@ Example response:
   {
     "key": "Mono",
     "name": "Mono"
-  },
-  {
-    "key": "Nodejs",
-    "name": "Nodejs"
-  },
-  {
-    "key": "OpenShift",
-    "name": "OpenShift"
   }
 ]
 ```
@@ -111,14 +113,16 @@ Example response:
 
 Get a single GitLab CI YML template.
 
-```
+```plaintext
 GET /templates/gitlab_ci_ymls/:key
 ```
 
-| Attribute  | Type   | Required | Description |
-| ---------- | ------ | -------- | ----------- |
+| Attribute  | Type   | Required | Description                           |
+| ---------- | ------ | -------- | ------------------------------------- |
 | `key`      | string | yes      | The key of the GitLab CI YML template |
 
+Example request:
+
 ```bash
 curl https://gitlab.example.com/api/v4/templates/gitlab_ci_ymls/Ruby
 ```
@@ -128,7 +132,7 @@ Example response:
 ```json
 {
   "name": "Ruby",
-  "content": "# This file is a template, and might need editing before it works on your project.\n# Official language image. Look for the different tagged releases at:\n# https://hub.docker.com/r/library/ruby/tags/\nimage: \"ruby:2.5\"\n\n# Pick zero or more services to be used on all builds.\n# Only needed when using a docker container to run your tests in.\n# Check out: http://docs.gitlab.com/ce/ci/docker/using_docker_images.html#what-is-a-service\nservices:\n  - mysql:latest\n  - redis:latest\n  - postgres:latest\n\nvariables:\n  POSTGRES_DB: database_name\n\n# Cache gems in between builds\ncache:\n  paths:\n    - vendor/ruby\n\n# This is a basic example for a gem or script which doesn't use\n# services such as redis or postgres\nbefore_script:\n  - ruby -v                                   # Print out ruby version for debugging\n  # Uncomment next line if your rails app needs a JS runtime:\n  # - apt-get update -q && apt-get install nodejs -yqq\n  - bundle install -j $(nproc) --path vendor  # Install dependencies into ./vendor/ruby\n\n# Optional - Delete if not using `rubocop`\nrubocop:\n  script:\n  - rubocop\n\nrspec:\n  script:\n  - rspec spec\n\nrails:\n  variables:\n    DATABASE_URL: \"postgresql://postgres:postgres@postgres:5432/$POSTGRES_DB\"\n  script:\n  - rails db:migrate\n  - rails db:seed\n  - rails test\n\n# This deploy job uses a simple deploy flow to Heroku, other providers, e.g. AWS Elastic Beanstalk\n# are supported too: https://github.com/travis-ci/dpl\ndeploy:\n  type: deploy\n  environment: production\n  script:\n  - gem install dpl\n  - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_PRODUCTION_KEY\n"
+  "content": "# This file is a template, and might need editing before it works on your project.\n# Official language image. Look for the different tagged releases at:\n# https://hub.docker.com/r/library/ruby/tags/\nimage: \"ruby:2.5\"\n\n# Pick zero or more services to be used on all builds.\n# Only needed when using a docker container to run your tests in.\n# Check out: http://docs.gitlab.com/ce/ci/docker/using_docker_images.html#what-is-a-service\nservices:\n  - mysql:latest\n  - redis:latest\n  - postgres:latest\n\nvariables:\n  POSTGRES_DB: database_name\n\n# Cache gems in between builds\ncache:\n  paths:\n    - vendor/ruby\n\n# This is a basic example for a gem or script which doesn't use\n# services such as redis or postgres\nbefore_script:\n  - ruby -v  # Print out ruby version for debugging\n  # Uncomment next line if your rails app needs a JS runtime:\n  # - apt-get update -q && apt-get install nodejs -yqq\n  - bundle install -j $(nproc) --path vendor  # Install dependencies into ./vendor/ruby\n\n# Optional - Delete if not using `rubocop`\nrubocop:\n  script:\n    - rubocop\n\nrspec:\n  script:\n    - rspec spec\n\nrails:\n  variables:\n    DATABASE_URL: \"postgresql://postgres:postgres@postgres:5432/$POSTGRES_DB\"\n  script:\n    - rails db:migrate\n    - rails db:seed\n    - rails test\n\n# This deploy job uses a simple deploy flow to Heroku, other providers, e.g. AWS Elastic Beanstalk\n# are supported too: https://github.com/travis-ci/dpl\ndeploy:\n  type: deploy\n  environment: production\n  script:\n    - gem install dpl\n    - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_PRODUCTION_KEY\n"
 }
 ```
 
diff --git a/doc/api/todos.md b/doc/api/todos.md
index bc2eeccacbe..b708b4391a2 100644
--- a/doc/api/todos.md
+++ b/doc/api/todos.md
@@ -36,8 +36,8 @@ Example Response:
       "id": 2,
       "name": "Gitlab Ce",
       "name_with_namespace": "Gitlab Org / Gitlab Ce",
-      "path": "gitlab-ce",
-      "path_with_namespace": "gitlab-org/gitlab-ce"
+      "path": "gitlab-foss",
+      "path_with_namespace": "gitlab-org/gitlab-foss"
     },
     "author": {
       "name": "Administrator",
@@ -109,8 +109,8 @@ Example Response:
       "id": 2,
       "name": "Gitlab Ce",
       "name_with_namespace": "Gitlab Org / Gitlab Ce",
-      "path": "gitlab-ce",
-      "path_with_namespace": "gitlab-org/gitlab-ce"
+      "path": "gitlab-foss",
+      "path_with_namespace": "gitlab-org/gitlab-foss"
     },
     "author": {
       "name": "Maxie Medhurst",
@@ -207,8 +207,8 @@ Example Response:
       "id": 2,
       "name": "Gitlab Ce",
       "name_with_namespace": "Gitlab Org / Gitlab Ce",
-      "path": "gitlab-ce",
-      "path_with_namespace": "gitlab-org/gitlab-ce"
+      "path": "gitlab-foss",
+      "path_with_namespace": "gitlab-org/gitlab-foss"
     },
     "author": {
       "name": "Administrator",
diff --git a/doc/api/users.md b/doc/api/users.md
index 380396c7377..33b6efa7a02 100644
--- a/doc/api/users.md
+++ b/doc/api/users.md
@@ -393,20 +393,21 @@ PUT /users/:id
 
 Parameters:
 
-- `email`                          - Email
-- `username`                       - Username
-- `name`                           - Name
-- `password`                       - Password
-- `skype`                          - Skype ID
-- `linkedin`                       - LinkedIn
-- `twitter`                        - Twitter account
-- `website_url`                    - Website URL
-- `organization`                   - Organization name
-- `projects_limit`                 - Limit projects each user can create
-- `extern_uid`                     - External UID
-- `provider`                       - External provider name
+- `id` (required)                  - The ID of the user
+- `email` (optional)               - Email
+- `username` (optional)            - Username
+- `name` (optional)                - Name
+- `password` (optional)            - Password
+- `skype` (optional)               - Skype ID
+- `linkedin` (optional)            - LinkedIn
+- `twitter` (optional)             - Twitter account
+- `website_url` (optional)         - Website URL
+- `organization` (optional)        - Organization name
+- `projects_limit` (optional)      - Limit projects each user can create
+- `extern_uid` (optional)          - External UID
+- `provider` (optional)            - External provider name
 - `group_id_for_saml` (optional)   - ID of group where SAML has been configured
-- `bio`                            - User's biography
+- `bio` (optional)                 - User's biography
 - `location` (optional)            - User's location
 - `public_email` (optional)        - The public email of the user
 - `admin` (optional)               - User is admin - true or false (default)
@@ -419,7 +420,7 @@ Parameters:
 - `private_profile` (optional)     - User's profile is private - true or false (default)
 - `shared_runners_minutes_limit` (optional)       - Pipeline minutes quota for this user **(STARTER)**
 - `extra_shared_runners_minutes_limit` (optional) - Extra pipeline minutes quota for this user **(STARTER)**
-- `note` (optional) - Admin notes for this user **(STARTER)**
+- `note` (optional)                - Admin notes for this user **(STARTER)**
 
 On password update, user will be forced to change it upon next login.
 Note, at the moment this method does only return a `404` error,
@@ -595,7 +596,7 @@ PUT /user/status
 
 | Attribute | Type   | Required | Description |
 | --------- | ------ | -------- | ----------- |
-| `emoji`   | string | no     | The name of the emoji to use as status, if omitted `speech_balloon` is used. Emoji name can be one of the specified names in the [Gemojione index][gemojione-index]. |
+| `emoji`   | string | no     | The name of the emoji to use as status, if omitted `speech_balloon` is used. Emoji name can be one of the specified names in the [Gemojione index](https://github.com/bonusly/gemojione/blob/master/config/index.json). |
 | `message` | string | no     | The message to set as a status. It can also contain emoji codes. |
 
 When both parameters `emoji` and `message` are empty, the status will be cleared.
@@ -1151,6 +1152,48 @@ Parameters:
 Will return `201 OK` on success, `404 User Not Found` is user cannot be found or
 `403 Forbidden` when trying to unblock a user blocked by LDAP synchronization.
 
+## Deactivate user
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/63921) in GitLab 12.4.
+
+Deactivates the specified user.  Available only for admin.
+
+```
+POST /users/:id/deactivate
+```
+
+Parameters:
+
+- `id` (required) - id of specified user
+
+Returns:
+
+- `201 OK` on success.
+- `404 User Not Found` if user cannot be found.
+- `403 Forbidden` when trying to deactivate a user:
+  - Blocked by admin or by LDAP synchronization.
+  - That has any activity in past 14 days. These cannot be deactivated.
+
+## Activate user
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/63921) in GitLab 12.4.
+
+Activates the specified user.  Available only for admin.
+
+```
+POST /users/:id/activate
+```
+
+Parameters:
+
+- `id` (required) - id of specified user
+
+Returns:
+
+- `201 OK` on success.
+- `404 User Not Found` if user cannot be found.
+- `403 Forbidden` when trying to activate a user blocked by admin or by LDAP synchronization.
+
 ### Get user contribution events
 
 Please refer to the [Events API documentation](events.md#get-user-contribution-events)
@@ -1362,5 +1405,3 @@ Example response:
 ```
 
 Please note that `last_activity_at` is deprecated, please use `last_activity_on`.
-
-[gemojione-index]: https://github.com/jonathanwiesel/gemojione/blob/master/config/index.json
diff --git a/doc/ci/README.md b/doc/ci/README.md
index cc1c85d1a53..5286764d178 100644
--- a/doc/ci/README.md
+++ b/doc/ci/README.md
@@ -85,7 +85,7 @@ GitLab CI/CD supports numerous configuration options:
 | [Job artifacts](../user/project/pipelines/job_artifacts.md) | Output, use, and reuse job artifacts. |
 | [Cache dependencies](caching/index.md) | Cache your dependencies for a faster execution. |
 | [Schedule pipelines](../user/project/pipelines/schedules.md) | Schedule pipelines to run as often as you need. |
-| [Custom path for `.gitlab-ci.yml`](../user/project/pipelines/settings.md#custom-ci-config-path) | Define a custom path for the CI/CD configuration file. |
+| [Custom path for `.gitlab-ci.yml`](../user/project/pipelines/settings.md#custom-ci-configuration-path) | Define a custom path for the CI/CD configuration file. |
 | [Git submodules for CI/CD](git_submodules.md) | Configure jobs for using Git submodules.|
 | [SSH keys for CI/CD](ssh_keys/README.md) | Using SSH keys in your CI pipelines. |
 | [Pipelines triggers](triggers/README.md) | Trigger pipelines through the API. |
@@ -113,7 +113,7 @@ Its feature set is listed on the table below according to DevOps stages.
 | [Browser Performance Testing](../user/project/merge_requests/browser_performance_testing.md) | Quickly determine the performance impact of pending code changes. |
 | [CI services](services/README.md) | Link Docker containers with your base image.|
 | [Code Quality](../user/project/merge_requests/code_quality.md) **(STARTER)** | Analyze your source code quality. |
-| [GitLab CI/CD for external repositories](ci_cd_for_external_repos/index.md) **(PREMIUM)** | Get the benefits of GitLab CI/CD combined with repositories in GitHub and BitBucket Cloud. |
+| [GitLab CI/CD for external repositories](ci_cd_for_external_repos/index.md) **(PREMIUM)** | Get the benefits of GitLab CI/CD combined with repositories in GitHub and Bitbucket Cloud. |
 | [Interactive Web Terminals](interactive_web_terminal/index.md) **(CORE ONLY)** | Open an interactive web terminal to debug the running jobs. |
 | [JUnit tests](junit_test_reports.md) | Identify script failures directly on merge requests. |
 | [Using Docker images](docker/using_docker_images.md) | Use GitLab and GitLab Runner with Docker to build and test applications. |
@@ -161,9 +161,9 @@ See also:
 The following articles explain reasons to use GitLab CI/CD
 for your CI/CD infrastructure:
 
-- [Why we chose GitLab CI for our CI/CD solution](https://about.gitlab.com/2016/10/17/gitlab-ci-oohlala/)
-- [Building our web-app on GitLab CI](https://about.gitlab.com/2016/07/22/building-our-web-app-on-gitlab-ci/)
-- [5 Teams that made the switch to GitLab CI/CD](https://about.gitlab.com/2019/04/25/5-teams-that-made-the-switch-to-gitlab-ci-cd/)
+- [Why we chose GitLab CI for our CI/CD solution](https://about.gitlab.com/blog/2016/10/17/gitlab-ci-oohlala/)
+- [Building our web-app on GitLab CI](https://about.gitlab.com/blog/2016/07/22/building-our-web-app-on-gitlab-ci/)
+- [5 Teams that made the switch to GitLab CI/CD](https://about.gitlab.com/blog/2019/04/25/5-teams-that-made-the-switch-to-gitlab-ci-cd/)
 
 See also the [Why CI/CD?](https://docs.google.com/presentation/d/1OGgk2Tcxbpl7DJaIOzCX4Vqg3dlwfELC3u2jEeCBbDk) presentation.
 
diff --git a/doc/ci/caching/index.md b/doc/ci/caching/index.md
index 558229187f1..6b8e7fa2ad5 100644
--- a/doc/ci/caching/index.md
+++ b/doc/ci/caching/index.md
@@ -12,8 +12,9 @@ content of a previous job. It can be particularly useful when you are
 developing software that depends on other libraries which are fetched via the
 internet during build time.
 
-If caching is enabled, it's shared between pipelines and jobs by default,
-starting from GitLab 9.0.
+If caching is enabled, it's shared between pipelines and jobs at the project
+level by default, starting from GitLab 9.0. Caches are not shared across
+projects.
 
 Make sure you read the [`cache` reference](../yaml/README.md#cache) to learn
 how it is defined in `.gitlab-ci.yml`.
@@ -202,7 +203,7 @@ For more fine tuning, read also about the
 
 The most common use case of cache is to preserve contents between subsequent
 runs of jobs for things like dependencies and commonly used libraries
-(Nodejs packages, PHP packages, rubygems, python libraries, etc.),
+(Nodejs packages, PHP packages, rubygems, Python libraries, etc.),
 so they don't have to be re-fetched from the public internet.
 
 NOTE: **Note:**
@@ -268,7 +269,7 @@ test:
 ### Caching Python dependencies
 
 Assuming your project is using [pip](https://pip.pypa.io/en/stable/) to install
-the python dependencies, the following example defines `cache` globally so that
+the Python dependencies, the following example defines `cache` globally so that
 all jobs inherit it. Python libraries are installed in a virtualenv under `venv/`,
 pip's cache is defined under `.cache/pip/` and both are cached per-branch:
 
@@ -490,8 +491,8 @@ job B:
 To fix that, use different `keys` for each job.
 
 In another case, let's assume you have more than one Runners assigned to your
-project, but the distributed cache is not enabled. We want the second time the
-pipeline is run, `job A` and `job B` to re-use their cache (which in this case
+project, but the distributed cache is not enabled. The second time the
+pipeline is run, we want `job A` and `job B` to re-use their cache (which in this case
 will be different):
 
 ```yaml
@@ -517,7 +518,7 @@ job B:
 ```
 
 In that case, even if the `key` is different (no fear of overwriting), you
-might experience the cached files to "get cleaned" before each stage if the
+might experience that the cached files "get cleaned" before each stage if the
 jobs run on different Runners in the subsequent pipelines.
 
 ## Clearing the cache
diff --git a/doc/ci/chatops/README.md b/doc/ci/chatops/README.md
index 40357608da4..234e7f4ed80 100644
--- a/doc/ci/chatops/README.md
+++ b/doc/ci/chatops/README.md
@@ -19,7 +19,7 @@ GitLab ChatOps is built upon two existing features:
 - [GitLab CI/CD](../README.md).
 - [Slack Slash Commands](../../user/project/integrations/slack_slash_commands.md).
 
-A new `run` action has been added to the [slash commands](../../integration/slash_commands.md), which takes two arguments: a `<job name>` to execute and the `<job arguments>`. When executed, ChatOps will look up the specified job name and attempt to match it to a corresponding job in [.gitlab-ci.yml](../yaml/README.md). If a matching job is found on `master`, a pipeline containing just that job is scheduled. Two additional [CI/CD variables](../variables/README.md#predefined-environment-variables) are passed to the job: `CHAT_INPUT` contains any additional arguments, and `CHAT_CHANNEL` is set to the name of channel the action was triggered in.
+A new `run` action has been added to the [slash commands](../../integration/slash_commands.md), which takes two arguments: a `<job name>` to execute and the `<job arguments>`. When executed, ChatOps will look up the specified job name and attempt to match it to a corresponding job in [`.gitlab-ci.yml`](../yaml/README.md). If a matching job is found on `master`, a pipeline containing just that job is scheduled. Two additional [CI/CD variables](../variables/README.md#predefined-environment-variables) are passed to the job: `CHAT_INPUT` contains any additional arguments, and `CHAT_CHANNEL` is set to the name of channel the action was triggered in.
 
 After the job has finished, its output is sent back to Slack provided it has completed within 30 minutes. If a job takes more than 30 minutes to run it must use the Slack API to manually send data back to a channel.
 
diff --git a/doc/ci/ci_cd_for_external_repos/index.md b/doc/ci/ci_cd_for_external_repos/index.md
index db647530fcd..35e2117c285 100644
--- a/doc/ci/ci_cd_for_external_repos/index.md
+++ b/doc/ci/ci_cd_for_external_repos/index.md
@@ -7,7 +7,7 @@ type: index, howto
 >[Introduced][ee-4642] in [GitLab Premium][eep] 10.6.
 
 NOTE: **Note:**
-This feature [is available for free](https://about.gitlab.com/2019/09/09/ci-cd-github-extended-again/) to
+This feature [is available for free](https://about.gitlab.com/blog/2019/09/09/ci-cd-github-extended-again/) to
 GitLab.com users until March 22nd, 2020.
 
 GitLab CI/CD can be used with:
@@ -100,7 +100,6 @@ requests and not on branches you can add `except: [branches]` to the job specs.
 [Read more](https://gitlab.com/gitlab-org/gitlab/issues/24089#workaround).
 
 [ee-4642]: https://gitlab.com/gitlab-org/gitlab/merge_requests/4642
-[ee-4642]: https://gitlab.com/gitlab-org/gitlab/merge_requests/4642
 [eep]: https://about.gitlab.com/pricing/
 [mirroring]: ../../workflow/repository_mirroring.md
 [settings]: ../../user/project/settings/index.md#sharing-and-permissions
diff --git a/doc/ci/directed_acyclic_graph/index.md b/doc/ci/directed_acyclic_graph/index.md
index 23604e8f898..7215dec287e 100644
--- a/doc/ci/directed_acyclic_graph/index.md
+++ b/doc/ci/directed_acyclic_graph/index.md
@@ -73,4 +73,4 @@ A directed acyclic graph is a complicated feature, and as of the initial MVC the
 are certain use cases that you may need to work around. For more information:
 
 - [`needs` requirements and limitations](../yaml/README.md#requirements-and-limitations).
-- Related epic [gitlab-org#1716](https://gitlab.com/groups/gitlab-org/-/epics/1716).
+- Related epic [tracking planned improvements](https://gitlab.com/groups/gitlab-org/-/epics/1716).
diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md
index a60ede2c8f8..f4bb7cd7d9f 100644
--- a/doc/ci/docker/using_docker_build.md
+++ b/doc/ci/docker/using_docker_build.md
@@ -117,10 +117,10 @@ not without its own challenges:
   history. Concurrent jobs work fine because every build gets it's own
   instance of Docker engine so they won't conflict with each other. But this
   also means jobs can be slower because there's no caching of layers.
-- By default, `docker:dind` uses `--storage-driver vfs` which is the slowest
-  form offered. To use a different driver, see
-  [Using the overlayfs driver](#using-the-overlayfs-driver).
-- Since the `docker:dind` container and the runner container don't share their
+- By default, Docker 17.09 and higher uses `--storage-driver overlay2` which is
+  the recommended storage driver. See [Using the overlayfs driver](#using-the-overlayfs-driver)
+  for details.
+- Since the `docker:19.03.1-dind` container and the Runner container don't share their
   root filesystem, the job's working directory can be used as a mount point for
   child containers. For example, if you have files you want to share with a
   child container, you may create a subdirectory under `/builds/$CI_PROJECT_PATH`
@@ -155,7 +155,7 @@ docker-in-docker service and
 [GitLab.com Shared Runners](../../user/gitlab_com/index.html#shared-runners)
 support this.
 
-1. Install [GitLab Runner](https://docs.gitlab.com/runner/install).
+1. Install [GitLab Runner](https://docs.gitlab.com/runner/install/).
 
 1. Register GitLab Runner from the command line to use `docker` and `privileged`
    mode:
@@ -218,13 +218,10 @@ support this.
      # https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#accessing-the-services.
      #
      # Note that if you're using the Kubernetes executor, the variable
-     # should be set to tcp://localhost:2376/ because of how the
+     # should be set to tcp://localhost:2376 because of how the
      # Kubernetes executor connects services to the job container
-     # DOCKER_HOST: tcp://localhost:2376/
+     # DOCKER_HOST: tcp://localhost:2376
      #
-     # When using dind, it's wise to use the overlayfs driver for
-     # improved performance.
-     DOCKER_DRIVER: overlay2
      # Specify to Docker where to create the certificates, Docker will
      # create them automatically on boot, and will create
      # `/certs/client` that will be shared between the service and job
@@ -283,15 +280,12 @@ variables:
   # https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#accessing-the-services
   #
   # Note that if you're using the Kubernetes executor, the variable should be set to
-  # tcp://localhost:2375/ because of how the Kubernetes executor connects services
+  # tcp://localhost:2375 because of how the Kubernetes executor connects services
   # to the job container
-  # DOCKER_HOST: tcp://localhost:2375/
+  # DOCKER_HOST: tcp://localhost:2375
   #
-  # For non-Kubernetes executors, we use tcp://docker:2375/
-  DOCKER_HOST: tcp://docker:2375/
-  # When using dind, it's wise to use the overlayfs driver for
-  # improved performance.
-  DOCKER_DRIVER: overlay2
+  # For non-Kubernetes executors, we use tcp://docker:2375
+  DOCKER_HOST: tcp://docker:2375
   #
   # This will instruct Docker not to start over TLS.
   DOCKER_TLS_CERTDIR: ""
@@ -317,12 +311,12 @@ container so that Docker is available in the context of that image.
 NOTE: **Note:**
 If you bind the Docker socket [when using GitLab Runner 11.11 or
 newer](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1261),
-you can no longer use `docker:dind` as a service because volume bindings
+you can no longer use `docker:19.03.1-dind` as a service because volume bindings
 are done to the services as well, making these incompatible.
 
 In order to do that, follow the steps:
 
-1. Install [GitLab Runner](https://docs.gitlab.com/runner/install).
+1. Install [GitLab Runner](https://docs.gitlab.com/runner/install/).
 
 1. Register GitLab Runner from the command line to use `docker` and share `/var/run/docker.sock`:
 
@@ -332,14 +326,14 @@ In order to do that, follow the steps:
      --registration-token REGISTRATION_TOKEN \
      --executor docker \
      --description "My Docker Runner" \
-     --docker-image "docker:stable" \
+     --docker-image "docker:19.03.1" \
      --docker-volumes /var/run/docker.sock:/var/run/docker.sock
    ```
 
    The above command will register a new Runner to use the special
-   `docker:stable` image which is provided by Docker. **Notice that it's using
-   the Docker daemon of the Runner itself, and any containers spawned by docker
-   commands will be siblings of the Runner rather than children of the runner.**
+   `docker:19.03.1` image which is provided by Docker. **Notice that it's using
+   the Docker daemon of the Runner itself, and any containers spawned by Docker
+   commands will be siblings of the Runner rather than children of the Runner.**
    This may have complications and limitations that are unsuitable for your workflow.
 
    The above command will create a `config.toml` entry similar to this:
@@ -351,7 +345,7 @@ In order to do that, follow the steps:
      executor = "docker"
      [runners.docker]
        tls_verify = false
-       image = "docker:stable"
+       image = "docker:19.03.1"
        privileged = false
        disable_cache = false
        volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]
@@ -360,10 +354,11 @@ In order to do that, follow the steps:
    ```
 
 1. You can now use `docker` in the build script (note that you don't need to
-   include the `docker:dind` service as when using the Docker in Docker executor):
+   include the `docker:19.03.1-dind` service as when using the Docker in Docker
+   executor):
 
    ```yaml
-   image: docker:stable
+   image: docker:19.03.1
 
    before_script:
      - docker info
@@ -417,14 +412,15 @@ any image that's used with the `--cache-from` argument must first be pulled
 Here's a simple `.gitlab-ci.yml` file showing how Docker caching can be utilized:
 
 ```yaml
-image: docker:stable
+image: docker:19.03.1
 
 services:
-  - docker:dind
+  - docker:19.03.1-dind
 
 variables:
-  DOCKER_HOST: tcp://docker:2375
-  DOCKER_DRIVER: overlay2
+  # Use TLS https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#tls-enabled
+  DOCKER_HOST: tcp://docker:2376
+  DOCKER_TLS_CERTDIR: "/certs"
 
 before_script:
   - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
@@ -526,7 +522,7 @@ Some things you should be aware of:
   longer, but means you don’t get stuck without security patches to base images.
 - Doing an explicit `docker pull` before each `docker run` fetches
   the latest image that was just built. This is especially important if you are
-  using multiple runners that cache images locally. Using the git SHA in your
+  using multiple runners that cache images locally. Using the Git SHA in your
   image tag makes this less necessary since each job will be unique and you
   shouldn't ever have a stale image. However, it's still possible to have a
   stale image if you re-build a given commit after a dependency has changed.
@@ -597,7 +593,6 @@ assuming you have it configured with [TLS enabled](#tls-enabled):
      # `/certs/client` that will be shared between the service and
      # build container.
      DOCKER_TLS_CERTDIR: "/certs"
-     DOCKER_DRIVER: overlay2
    stage: build
    script:
      - docker build -t my-docker-image .
@@ -618,37 +613,36 @@ If you're using docker-in-docker on your Runners, this is how your `.gitlab-ci.y
 could look like:
 
 ```yaml
- build:
-   image: docker:stable
-   services:
-     - docker:dind
-   variables:
-     DOCKER_HOST: tcp://docker:2375
-     DOCKER_DRIVER: overlay2
-   stage: build
-   script:
-     - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
-     - docker build -t $CI_REGISTRY/group/project/image:latest .
-     - docker push $CI_REGISTRY/group/project/image:latest
+build:
+  image: docker:19.03.1
+  stage: build
+  services:
+    - docker:19.03.1-dind
+  variables:
+    # Use TLS https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#tls-enabled
+    DOCKER_HOST: tcp://docker:2376
+    DOCKER_TLS_CERTDIR: "/certs"
+  script:
+    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
+    - docker build -t $CI_REGISTRY/group/project/image:latest .
+    - docker push $CI_REGISTRY/group/project/image:latest
 ```
 
 You can also make use of [other variables](../variables/README.md) to avoid hardcoding:
 
 ```yaml
-services:
-  - docker:dind
-
-variables:
-  DOCKER_HOST: tcp://docker:2375
-  DOCKER_DRIVER: overlay2
-  IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
-
-before_script:
-  - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
-
 build:
+  image: docker:19.03.1
   stage: build
+  services:
+    - docker:19.03.1-dind
+  variables:
+    # Use TLS https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#tls-enabled
+    DOCKER_HOST: tcp://docker:2376
+    DOCKER_TLS_CERTDIR: "/certs"
+    IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
   script:
+    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
     - docker build -t $IMAGE_TAG .
     - docker push $IMAGE_TAG
 ```
@@ -667,9 +661,9 @@ when needed. Changes to `master` also get tagged as `latest` and deployed using
 an application-specific deploy script:
 
 ```yaml
-image: docker:stable
+image: docker:19.03.1
 services:
-  - docker:dind
+  - docker:19.03.1-dind
 
 stages:
   - build
@@ -678,8 +672,9 @@ stages:
   - deploy
 
 variables:
-  DOCKER_HOST: tcp://docker:2375
-  DOCKER_DRIVER: overlay2
+  # Use TLS https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#tls-enabled
+  DOCKER_HOST: tcp://docker:2376
+  DOCKER_TLS_CERTDIR: "/certs"
   CONTAINER_TEST_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
   CONTAINER_RELEASE_IMAGE: $CI_REGISTRY_IMAGE:latest
 
diff --git a/doc/ci/enable_or_disable_ci.md b/doc/ci/enable_or_disable_ci.md
index 56200142055..dcf4d8dde2d 100644
--- a/doc/ci/enable_or_disable_ci.md
+++ b/doc/ci/enable_or_disable_ci.md
@@ -28,18 +28,28 @@ either:
 - Site-wide by modifying the settings in `gitlab.yml` and `gitlab.rb` for source
   and Omnibus installations respectively.
 
+NOTE: **Note:**
+This only applies to pipelines run as part of GitLab CI/CD. This will not enable or disable
+pipelines that are run from an [external integration](../user/project/integrations/project_services.md#services).
+
 ## Per-project user setting
 
-The setting to enable or disable GitLab CI/CD can be found under your project's
-**Settings > General > Permissions**. Choose one of "Disabled", "Only team members"
-or "Everyone with access" and hit **Save changes** for the settings to take effect.
+The setting to enable or disable GitLab CI/CD Pipelines can be found in your project in
+**Settings > General > Visibility, project features, permissions**. If the project
+visibility is set to:
+
+- **Private**, only project members can access pipelines.
+- **Internal** or **Public**, pipelines can be made accessible to either
+  project members only or everyone with access.
+
+Press **Save changes** for the settings to take effect.
 
-![Sharing & Permissions settings](../user/project/settings/img/sharing_and_permissions_settings.png)
+![Sharing & Permissions settings](../user/project/settings/img/sharing_and_permissions_settings_v12_3.png)
 
 ## Site-wide admin setting
 
 You can disable GitLab CI/CD site-wide, by modifying the settings in `gitlab.yml`
-and `gitlab.rb` for source and Omnibus installations respectively.
+for source installations, and `gitlab.rb` for Omnibus installations.
 
 Two things to note:
 
diff --git a/doc/ci/environments.md b/doc/ci/environments.md
index d3a8689551a..cef95c8e22a 100644
--- a/doc/ci/environments.md
+++ b/doc/ci/environments.md
@@ -131,15 +131,27 @@ In summary, with the above `.gitlab-ci.yml` we have achieved the following:
   job will deploy our code to a staging server while the deployment
   will be recorded in an environment named `staging`.
 
-> Starting with GitLab 8.15, the environment name is exposed to the Runner in
-> two forms: `$CI_ENVIRONMENT_NAME`, and `$CI_ENVIRONMENT_SLUG`. The first is
-> the name given in `.gitlab-ci.yml` (with any variables expanded), while the
-> second is a "cleaned-up" version of the name, suitable for use in URLs, DNS,
-> etc.
->
-> Starting with GitLab 9.3, the environment URL is exposed to the Runner via
-> `$CI_ENVIRONMENT_URL`. The URL is expanded from `.gitlab-ci.yml`, or if
-> the URL was not defined there, the external URL from the environment is used.
+#### Environment variables and Runner
+
+Starting with GitLab 8.15, the environment name is exposed to the Runner in
+two forms:
+
+- `$CI_ENVIRONMENT_NAME`. The name given in `.gitlab-ci.yml` (with any variables
+  expanded).
+- `$CI_ENVIRONMENT_SLUG`. A "cleaned-up" version of the name, suitable for use in URLs,
+  DNS, etc.
+
+If you change the name of an existing environment, the:
+
+- `$CI_ENVIRONMENT_NAME` variable will be updated with the new environment name.
+- `$CI_ENVIRONMENT_SLUG` variable will remain unchanged to prevent unintended side
+  effects.
+
+Starting with GitLab 9.3, the environment URL is exposed to the Runner via
+`$CI_ENVIRONMENT_URL`. The URL is expanded from either:
+
+- `.gitlab-ci.yml`.
+- The external URL from the environment if not defined in `.gitlab-ci.yml`.
 
 ### Configuring manual deployments
 
@@ -679,7 +691,7 @@ fetch = +refs/environments/*:refs/remotes/origin/environments/*
 ### Scoping environments with specs
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/2112) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.4.
-> - [Scoping for environment variables was moved to Core](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/30779) to Core in Gitlab 12.2.
+> - [Scoping for environment variables was moved to Core](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/30779) to Core in GitLab 12.2.
 
 You can limit the environment scope of a variable by
 defining which environments it can be available for.
@@ -736,7 +748,7 @@ Re-using variables defined inside `script` as part of the environment name will
 Below are some links you may find interesting:
 
 - [The `.gitlab-ci.yml` definition of environments](yaml/README.md#environment)
-- [A blog post on Deployments & Environments](https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/)
+- [A blog post on Deployments & Environments](https://about.gitlab.com/blog/2016/08/26/ci-deployment-and-environments/)
 - [Review Apps - Use dynamic environments to deploy your code for every branch](review_apps/index.md)
 - [Deploy Boards for your applications running on Kubernetes](../user/project/deploy_boards.md) **(PREMIUM)**
 
diff --git a/doc/ci/examples/README.md b/doc/ci/examples/README.md
index 73f7a555b9c..d2333f7e468 100644
--- a/doc/ci/examples/README.md
+++ b/doc/ci/examples/README.md
@@ -11,9 +11,9 @@ implement [GitLab CI/CD](../README.md) for your specific use case.
 Examples are available in several forms. As a collection of:
 
 - `.gitlab-ci.yml` [template files](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/lib/gitlab/ci/templates) maintained in GitLab. When you create a new file via the UI,
-  GitLab will give you the option to choose one of these templates. This will allow you to quickly bootstrap your project for CI/CD.
+  GitLab will give you the option to choose one of these templates. This will allow you to start using CI/CD with your project quickly.
   If your favorite programming language or framework are missing, we would love your help by sending a merge request with a new `.gitlab-ci.yml` to this project.
-- Repositories with [example projects](https://gitlab.com/gitlab-examples) for various languages. You can fork and adjust them to your own needs. Projects include demonstrations of [multi-project pipelines](https://gitlab.com/gitlab-examples/multi-project-pipelines) and using [Review Apps with a static site served by nginx](https://gitlab.com/gitlab-examples/review-apps-nginx/).
+- Repositories with [example projects](https://gitlab.com/gitlab-examples) for various languages. You can fork and adjust them to your own needs. Projects include demonstrations of [multi-project pipelines](https://gitlab.com/gitlab-examples/multi-project-pipelines) and using [Review Apps with a static site served by NGINX](https://gitlab.com/gitlab-examples/review-apps-nginx/).
 - Examples and [other resources](#other-resources) listed below.
 
 ## CI/CD examples
@@ -59,10 +59,10 @@ Note that older articles and videos may not reflect the state of the latest GitL
 
 For examples of setting up GitLab CI/CD for cloud-based environments, see:
 
-- [How to set up multi-account AWS SAM deployments with GitLab CI](https://about.gitlab.com/2019/02/04/multi-account-aws-sam-deployments-with-gitlab-ci/)
+- [How to set up multi-account AWS SAM deployments with GitLab CI](https://about.gitlab.com/blog/2019/02/04/multi-account-aws-sam-deployments-with-gitlab-ci/)
 - [Automating Kubernetes Deployments with GitLab CI/CD](https://www.youtube.com/watch?v=wEDRfAz6_Uw)
-- [How to autoscale continuous deployment with GitLab Runner on DigitalOcean](https://about.gitlab.com/2018/06/19/autoscale-continuous-deployment-gitlab-runner-digital-ocean/)
-- [How to create a CI/CD pipeline with Auto Deploy to Kubernetes using GitLab and Helm](https://about.gitlab.com/2017/09/21/how-to-create-ci-cd-pipeline-with-autodeploy-to-kubernetes-using-gitlab-and-helm/)
+- [How to autoscale continuous deployment with GitLab Runner on DigitalOcean](https://about.gitlab.com/blog/2018/06/19/autoscale-continuous-deployment-gitlab-runner-digital-ocean/)
+- [How to create a CI/CD pipeline with Auto Deploy to Kubernetes using GitLab and Helm](https://about.gitlab.com/blog/2017/09/21/how-to-create-ci-cd-pipeline-with-autodeploy-to-kubernetes-using-gitlab-and-helm/)
 - [Demo - Deploying from GitLab to OpenShift Container Cluster](https://youtu.be/EwbhA53Jpp4)
 
 See also the following video overviews:
@@ -74,32 +74,32 @@ See also the following video overviews:
 
 For some customer experiences with GitLab CI/CD, see:
 
-- [How Verizon Connect reduced datacenter deploys from 30 days to under 8 hours with GitLab](https://about.gitlab.com/2019/02/14/verizon-customer-story/)
-- [How Wag! cut their release process from 40 minutes to just 6](https://about.gitlab.com/2019/01/16/wag-labs-blog-post/)
-- [How Jaguar Land Rover embraced CI to speed up their software lifecycle](https://about.gitlab.com/2018/07/23/chris-hill-devops-enterprise-summit-talk/)
+- [How Verizon Connect reduced datacenter deploys from 30 days to under 8 hours with GitLab](https://about.gitlab.com/blog/2019/02/14/verizon-customer-story/)
+- [How Wag! cut their release process from 40 minutes to just 6](https://about.gitlab.com/blog/2019/01/16/wag-labs-blog-post/)
+- [How Jaguar Land Rover embraced CI to speed up their software lifecycle](https://about.gitlab.com/blog/2018/07/23/chris-hill-devops-enterprise-summit-talk/)
 
 ### Getting started
 
 For some examples to help get you started, see:
 
-- [GitLab CI/CD's 2018 highlights](https://about.gitlab.com/2019/01/21/gitlab-ci-cd-features-improvements/)
-- [A beginner's guide to continuous integration](https://about.gitlab.com/2018/01/22/a-beginners-guide-to-continuous-integration/)
+- [GitLab CI/CD's 2018 highlights](https://about.gitlab.com/blog/2019/01/21/gitlab-ci-cd-features-improvements/)
+- [A beginner's guide to continuous integration](https://about.gitlab.com/blog/2018/01/22/a-beginners-guide-to-continuous-integration/)
 
 ### Implementing GitLab CI/CD
 
 For examples of others who have implemented GitLab CI/CD, see:
 
-- [How to streamline interactions between multiple repositories with multi-project pipelines](https://about.gitlab.com/2018/10/31/use-multiproject-pipelines-with-gitlab-cicd/)
-- [How we used GitLab CI to build GitLab faster](https://about.gitlab.com/2018/05/02/using-gitlab-ci-to-build-gitlab-faster/)
-- [Test all the things in GitLab CI with Docker by example](https://about.gitlab.com/2018/02/05/test-all-the-things-gitlab-ci-docker-examples/)
-- [A Craftsman looks at continuous integration](https://about.gitlab.com/2018/01/17/craftsman-looks-at-continuous-integration/)
-- [Go tools and GitLab: How to do continuous integration like a boss](https://about.gitlab.com/2017/11/27/go-tools-and-gitlab-how-to-do-continuous-integration-like-a-boss/)
-- [GitBot – automating boring Git operations with CI](https://about.gitlab.com/2017/11/02/automating-boring-git-operations-gitlab-ci/)
-- [How to use GitLab CI for Vue.js](https://about.gitlab.com/2017/09/12/vuejs-app-gitlab/)
+- [How to streamline interactions between multiple repositories with multi-project pipelines](https://about.gitlab.com/blog/2018/10/31/use-multiproject-pipelines-with-gitlab-cicd/)
+- [How we used GitLab CI to build GitLab faster](https://about.gitlab.com/blog/2018/05/02/using-gitlab-ci-to-build-gitlab-faster/)
+- [Test all the things in GitLab CI with Docker by example](https://about.gitlab.com/blog/2018/02/05/test-all-the-things-gitlab-ci-docker-examples/)
+- [A Craftsman looks at continuous integration](https://about.gitlab.com/blog/2018/01/17/craftsman-looks-at-continuous-integration/)
+- [Go tools and GitLab: How to do continuous integration like a boss](https://about.gitlab.com/blog/2017/11/27/go-tools-and-gitlab-how-to-do-continuous-integration-like-a-boss/)
+- [GitBot – automating boring Git operations with CI](https://about.gitlab.com/blog/2017/11/02/automating-boring-git-operations-gitlab-ci/)
+- [How to use GitLab CI for Vue.js](https://about.gitlab.com/blog/2017/09/12/vuejs-app-gitlab/)
 - Video: [GitLab CI/CD Deep Dive](https://youtu.be/pBe4t1CD8Fc?t=195)
-- [Dockerizing GitLab Review Apps](https://about.gitlab.com/2017/07/11/dockerizing-review-apps/)
-- [Fast and natural continuous integration with GitLab CI](https://about.gitlab.com/2017/05/22/fast-and-natural-continuous-integration-with-gitlab-ci/)
-- [Demo: CI/CD with GitLab in action](https://about.gitlab.com/2017/03/13/ci-cd-demo/)
+- [Dockerizing GitLab Review Apps](https://about.gitlab.com/blog/2017/07/11/dockerizing-review-apps/)
+- [Fast and natural continuous integration with GitLab CI](https://about.gitlab.com/blog/2017/05/22/fast-and-natural-continuous-integration-with-gitlab-ci/)
+- [Demo: CI/CD with GitLab in action](https://about.gitlab.com/blog/2017/03/13/ci-cd-demo/)
 
 ### Migrating to GitLab from third-party CI tools
 
@@ -109,17 +109,17 @@ For examples of others who have implemented GitLab CI/CD, see:
 
 To see how you can integrate GitLab CI/CD with third-party systems, see:
 
-- [Streamline and shorten error remediation with Sentry’s new GitLab integration](https://about.gitlab.com/2019/01/25/sentry-integration-blog-post/)
-- [How to simplify your smart home configuration with GitLab CI/CD](https://about.gitlab.com/2018/08/02/using-the-gitlab-ci-slash-cd-for-smart-home-configuration-management/)
-- [Demo: GitLab + Jira + Jenkins](https://about.gitlab.com/2018/07/30/gitlab-workflow-with-jira-jenkins/)
-- [Introducing Auto Breakfast from GitLab (sort of)](https://about.gitlab.com/2018/06/29/introducing-auto-breakfast-from-gitlab/)
+- [Streamline and shorten error remediation with Sentry’s new GitLab integration](https://about.gitlab.com/blog/2019/01/25/sentry-integration-blog-post/)
+- [How to simplify your smart home configuration with GitLab CI/CD](https://about.gitlab.com/blog/2018/08/02/using-the-gitlab-ci-slash-cd-for-smart-home-configuration-management/)
+- [Demo: GitLab + Jira + Jenkins](https://about.gitlab.com/blog/2018/07/30/gitlab-workflow-with-jira-jenkins/)
+- [Introducing Auto Breakfast from GitLab (sort of)](https://about.gitlab.com/blog/2018/06/29/introducing-auto-breakfast-from-gitlab/)
 
 ### Mobile development
 
 For help with using GitLab CI/CD for mobile application development, see:
 
-- [How to publish Android apps to the Google Play Store with GitLab and fastlane](https://about.gitlab.com/2019/01/28/android-publishing-with-gitlab-and-fastlane/)
-- [Setting up GitLab CI for Android projects](https://about.gitlab.com/2018/10/24/setting-up-gitlab-ci-for-android-projects/)
-- [Working with YAML in GitLab CI from the Android perspective](https://about.gitlab.com/2017/11/20/working-with-yaml-gitlab-ci-android/)
-- [How to use GitLab CI and MacStadium to build your macOS or iOS projects](https://about.gitlab.com/2017/05/15/how-to-use-macstadium-and-gitlab-ci-to-build-your-macos-or-ios-projects/)
-- [Setting up GitLab CI for iOS projects](https://about.gitlab.com/2016/03/10/setting-up-gitlab-ci-for-ios-projects/)
+- [How to publish Android apps to the Google Play Store with GitLab and fastlane](https://about.gitlab.com/blog/2019/01/28/android-publishing-with-gitlab-and-fastlane/)
+- [Setting up GitLab CI for Android projects](https://about.gitlab.com/blog/2018/10/24/setting-up-gitlab-ci-for-android-projects/)
+- [Working with YAML in GitLab CI from the Android perspective](https://about.gitlab.com/blog/2017/11/20/working-with-yaml-gitlab-ci-android/)
+- [How to use GitLab CI and MacStadium to build your macOS or iOS projects](https://about.gitlab.com/blog/2017/05/15/how-to-use-macstadium-and-gitlab-ci-to-build-your-macos-or-ios-projects/)
+- [Setting up GitLab CI for iOS projects](https://about.gitlab.com/blog/2016/03/10/setting-up-gitlab-ci-for-ios-projects/)
diff --git a/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md b/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md
index 1d4c9221cf2..49f4a14c5ac 100644
--- a/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md
+++ b/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md
@@ -16,14 +16,14 @@ description: "Continuous Deployment of a Spring Boot application to Cloud Foundr
 In this article, we'll demonstrate how to deploy a [Spring
 Boot](https://projects.spring.io/spring-boot/) application to [Cloud
 Foundry (CF)](https://www.cloudfoundry.org/) with GitLab CI/CD using the [Continuous
-Deployment](https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#continuous-deployment)
+Deployment](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#continuous-deployment)
 method.
 
 All the code for this project can be found in this [GitLab
 repo](https://gitlab.com/gitlab-examples/spring-gitlab-cf-deploy-demo).
 
 In case you're interested in deploying Spring Boot applications to Kubernetes
-using GitLab CI/CD, read through the blog post [Continuous Delivery of a Spring Boot application with GitLab CI and Kubernetes](https://about.gitlab.com/2016/12/14/continuous-delivery-of-a-spring-boot-application-with-gitlab-ci-and-kubernetes/).
+using GitLab CI/CD, read through the blog post [Continuous Delivery of a Spring Boot application with GitLab CI and Kubernetes](https://about.gitlab.com/blog/2016/12/14/continuous-delivery-of-a-spring-boot-application-with-gitlab-ci-and-kubernetes/).
 
 ## Requirements
 
diff --git a/doc/ci/examples/deployment/README.md b/doc/ci/examples/deployment/README.md
index 26b10c7eeaf..afe02e0a7d8 100644
--- a/doc/ci/examples/deployment/README.md
+++ b/doc/ci/examples/deployment/README.md
@@ -46,7 +46,7 @@ staging:
   - dpl --provider=heroku --app=my-app-staging --api-key=$HEROKU_STAGING_API_KEY
 ```
 
-In the above example we use Dpl to deploy `my-app-staging` to Heroku server with api-key stored in `HEROKU_STAGING_API_KEY` secure variable.
+In the above example we use Dpl to deploy `my-app-staging` to Heroku server with API key stored in `HEROKU_STAGING_API_KEY` secure variable.
 
 To use different provider take a look at long list of [Supported Providers](https://github.com/travis-ci/dpl#supported-providers).
 
diff --git a/doc/ci/examples/deployment/composer-npm-deploy.md b/doc/ci/examples/deployment/composer-npm-deploy.md
index 79b3cbd0c69..c9c78c9a4e4 100644
--- a/doc/ci/examples/deployment/composer-npm-deploy.md
+++ b/doc/ci/examples/deployment/composer-npm-deploy.md
@@ -46,7 +46,7 @@ All these operations will put all files into a `build` folder, which is ready to
 
 You have multiple options: rsync, scp, sftp and so on. For now, we will use scp.
 
-To make this work, you need to add a GitLab CI/CD Variable (accessible on _gitlab.example/your-project-name/variables_). That variable will be called `STAGING_PRIVATE_KEY` and it's the  **private** ssh key of your server.
+To make this work, you need to add a GitLab CI/CD Variable (accessible on `gitlab.example/your-project-name/variables`). That variable will be called `STAGING_PRIVATE_KEY` and it's the  **private** SSH key of your server.
 
 ### Security tip
 
@@ -98,7 +98,7 @@ Here's the breakdown:
 1. We will connect via `ssh` and create a new `_tmp` folder
 1. We will connect via `scp` and upload the `build` folder (which was generated by a `npm` script) to our previously created `_tmp` folder
 1. We will connect again via `ssh` and move the `live` folder to an `_old` folder, then move `_tmp` to `live`.
-1. We connect to ssh and remove the `_old` folder
+1. We connect to SSH and remove the `_old` folder
 
 What's the deal with the artifacts? We just tell GitLab CI to keep the `build` directory (later on, you can download that as needed).
 
diff --git a/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md b/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md
index 44d3ec8046c..e1c59f3b025 100644
--- a/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md
+++ b/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md
@@ -22,7 +22,7 @@ and the basics of game development.
 
 Our [demo game](http://gitlab-game-demo.s3-website-us-east-1.amazonaws.com/) consists of a simple spaceship traveling in space that shoots by clicking the mouse in a given direction.
 
-Creating a strong CI/CD pipeline at the beginning of developing another game, [Dark Nova](http://darknova.io/),
+Creating a strong CI/CD pipeline at the beginning of developing another game, [Dark Nova](https://www.darknova.io),
 was essential for the fast pace the team worked at. This tutorial will build upon my
 [previous introductory article](https://ryanhallcs.wordpress.com/2017/03/15/devops-and-game-dev/) and go through the following steps:
 
@@ -254,7 +254,7 @@ pipeline to include running the tests along with the existing build job.
 
 To ensure our changes don't break the build and all tests still pass, we utilize
 Continuous Integration (CI) to run these checks automatically for every push.
-Read through this article to understand [Continuous Integration, Continuous Delivery, and Continuous Deployment](https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/),
+Read through this article to understand [Continuous Integration, Continuous Delivery, and Continuous Deployment](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/),
 and how these methods are leveraged by GitLab.
 From the [last tutorial](https://ryanhallcs.wordpress.com/2017/03/15/devops-and-game-dev/) we already have a `.gitlab-ci.yml` file set up for building our app from
 every push. We need to set up a new CI job for testing, which GitLab CI/CD will run after the build job using our generated artifacts from gulp.
@@ -390,7 +390,7 @@ We have our codebase built and tested on every push. To complete the full pipeli
 let's set up [free web hosting with AWS S3](https://aws.amazon.com/s/dm/optimization/server-side-test/free-tier/free_np/) and a job through which our build artifacts get
 deployed. GitLab also has a free static site hosting service we could use, [GitLab Pages](https://about.gitlab.com/product/pages/),
 however Dark Nova specifically uses other AWS tools that necessitates using `AWS S3`.
-Read through this article that describes [deploying to both S3 and GitLab Pages](https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/)
+Read through this article that describes [deploying to both S3 and GitLab Pages](https://about.gitlab.com/blog/2016/08/26/ci-deployment-and-environments/)
 and further delves into the principles of GitLab CI/CD than discussed in this article.
 
 ### Set up S3 Bucket
@@ -509,7 +509,7 @@ deploy:
 
 Within the [demo repository](https://gitlab.com/blitzgren/gitlab-game-demo) you can also find a handful of boilerplate code to get
 [Typescript](https://www.typescriptlang.org/), [Mocha](https://mochajs.org/), [Gulp](https://gulpjs.com/) and [Phaser](https://phaser.io) all playing
-together nicely with GitLab CI/CD, which is the result of lessons learned while making [Dark Nova](http://darknova.io/).
+together nicely with GitLab CI/CD, which is the result of lessons learned while making [Dark Nova](https://www.darknova.io).
 Using a combination of free and open source software, we have a full CI/CD pipeline, a game foundation,
 and unit tests, all running and deployed at every push to master - with shockingly little code.
 Errors can be easily debugged through GitLab's build logs, and within minutes of a successful commit,
@@ -527,6 +527,6 @@ Here are some ideas to further investigate that can speed up or improve your pip
 
 - [Yarn](https://yarnpkg.com) instead of npm
 - Set up a custom [Docker](../../../ci/docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml) image that can preload dependencies and tools (like AWS CLI)
-- Forward a [custom domain](https:/docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html) to your game's S3 static website
+- Forward a [custom domain](https://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html) to your game's S3 static website
 - Combine jobs if you find it unnecessary for a small project
-- Avoid the queues and set up your own [custom GitLab CI/CD runner](https://about.gitlab.com/2016/03/01/gitlab-runner-with-docker/)
+- Avoid the queues and set up your own [custom GitLab CI/CD runner](https://about.gitlab.com/blog/2016/03/01/gitlab-runner-with-docker/)
diff --git a/doc/ci/examples/end_to_end_testing_webdriverio/index.md b/doc/ci/examples/end_to_end_testing_webdriverio/index.md
index 38d0d86ffa2..17fb6f9a7c9 100644
--- a/doc/ci/examples/end_to_end_testing_webdriverio/index.md
+++ b/doc/ci/examples/end_to_end_testing_webdriverio/index.md
@@ -28,7 +28,7 @@ layers of your application, from the frontend to the database.
 In this article, we will discuss how
 to write such end-to-end tests, and how to set up GitLab CI/CD to automatically run these tests
 against your new code, on a branch-by-branch basis. For the scope of this article, we will walk you
-through the process of setting up GitLab CI/CD for end-to-end testing Javascript-based applications
+through the process of setting up GitLab CI/CD for end-to-end testing JavaScript-based applications
 with WebdriverIO, but the general strategy should carry over to other languages.
 We assume you are familiar with GitLab, [GitLab CI/CD](../../README.md), [Review Apps](../../review_apps/index.md), and running your app locally, e.g., on `localhost:8000`.
 
@@ -47,14 +47,14 @@ infrastructure is up and running, and that your units of code work well together
 [Selenium](http://www.seleniumhq.org/) is a piece of software that can control web browsers, e.g., to make them
 visit a specific URL or interact with elements on the page. It can be programmatically controlled
 from a variety of programming languages. In this article we're going to be using the
-[WebdriverIO](http://webdriver.io/) Javascript bindings, but the general concept should carry over
+[WebdriverIO](https://webdriver.io/) JavaScript bindings, but the general concept should carry over
 pretty well to
 [other programming languages supported by Selenium](http://docs.seleniumhq.org/about/platforms.jsp#programming-languages).
 
 ## Writing tests
 
 You can write tests using
-[several testing frameworks supported by WebdriverIO](http://webdriver.io/guide/testrunner/frameworks.html).
+[several testing frameworks supported by WebdriverIO](https://webdriver.io/guide/testrunner/frameworks.html).
 We will be using [Jasmine](https://jasmine.github.io/) here:
 
 ```javascript
@@ -79,14 +79,14 @@ multiple tests, such as making sure you are logged in.
 
 The function `it` defines an individual test.
 
-[The `browser` object](http://webdriver.io/guide/testrunner/browserobject.html) is WebdriverIO's
-special sauce. It provides most of [the WebdriverIO API methods](http://webdriver.io/api.html) that are the key to
+[The `browser` object](https://webdriver.io/guide/testrunner/browserobject.html) is WebdriverIO's
+special sauce. It provides most of [the WebdriverIO API methods](https://webdriver.io/api.html) that are the key to
 steering the browser. In this case, we can use
-[`browser.url`](http://webdriver.io/api/protocol/url.html) to visit `/page-that-does-not-exist` to
-hit our 404 page. We can then use [`browser.getUrl`](http://webdriver.io/api/property/getUrl.html)
+[`browser.url`](https://webdriver.io/api/protocol/url.html) to visit `/page-that-does-not-exist` to
+hit our 404 page. We can then use [`browser.getUrl`](https://webdriver.io/api/property/getUrl.html)
 to verify that the current page is indeed at the location we specified. To interact with the page,
 we can simply pass CSS selectors to
-[`browser.element`](http://webdriver.io/api/protocol/element.html) to get access to elements on the
+[`browser.element`](https://webdriver.io/api/protocol/element.html) to get access to elements on the
 page and to interact with them - for example, to click on the link back to the home page.
 
 The simple test shown above
@@ -107,9 +107,9 @@ you can use [the Webpack Dev Server WebdriverIO plugin](https://www.npmjs.com/pa
 that automatically starts a development server before executing the tests.
 
 The WebdriverIO documentation has
-[an overview of all configuration options](http://webdriver.io/guide/getstarted/configuration.html), but the
+[an overview of all configuration options](https://webdriver.io/guide/getstarted/configuration.html), but the
 easiest way to get started is to start with
-[WebdriverIO's default configuration](http://webdriver.io/guide/testrunner/configurationfile.html), which
+[WebdriverIO's default configuration](https://webdriver.io/guide/testrunner/configurationfile.html), which
 provides an overview of all available options. The two options that are going to be most relevant now are the
 `specs` option, which is an array of paths to your tests, and the `baseUrl` option, which points to where your app is
 running. And finally, we will need to tell WebdriverIO in which browsers we would like to run our
@@ -182,7 +182,7 @@ e2e:chrome:
 
 Now that we have a job to run the end-to-end tests in, we need to tell WebdriverIO how to connect to
 the Selenium servers running alongside it. We've already cheated a bit above by
-passing the value of the [`host`](http://webdriver.io/guide/getstarted/configuration.html#host)
+passing the value of the [`host`](https://webdriver.io/guide/getstarted/configuration.html#host)
 option as an argument to `npm run confidence-check` on the command line.
 However, we still need to tell WebdriverIO which browser is available for it to use.
 
@@ -248,7 +248,7 @@ production project, see:
 - [Flockademic's `.gitlab-ci.yml`](https://gitlab.com/Flockademic/Flockademic/blob/dev/.gitlab-ci.yml)
 - [Flockademic's tests](https://gitlab.com/Flockademic/Flockademic/tree/dev/__e2e__)
 
-There's plenty more that WebdriverIO can do. For example, you can configure a [`screenshotPath`](http://webdriver.io/guide/getstarted/configuration.html#screenshotPath) to tell WebdriverIO to take
+There's plenty more that WebdriverIO can do. For example, you can configure a [`screenshotPath`](https://webdriver.io/guide/getstarted/configuration.html#screenshotPath) to tell WebdriverIO to take
 a screenshot when tests are failing. Then tell GitLab CI/CD to store those
 [artifacts](../../yaml/README.md#artifacts), and you'll be able to see what went
 wrong within GitLab.
diff --git a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
index d79821ff258..a7ed4ca3514 100644
--- a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
+++ b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
@@ -15,7 +15,7 @@ last_updated: 2019-03-06
 
 GitLab features our applications with Continuous Integration, and it is possible to easily deploy the new code changes to the production server whenever we want.
 
-In this tutorial, we'll show you how to initialize a [Laravel](http://laravel.com/) application and set up our [Envoy](https://laravel.com/docs/envoy) tasks, then we'll jump into see how to test and deploy it with [GitLab CI/CD](../README.md) via [Continuous Delivery](https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/).
+In this tutorial, we'll show you how to initialize a [Laravel](https://laravel.com) application and set up our [Envoy](https://laravel.com/docs/master/envoy) tasks, then we'll jump into see how to test and deploy it with [GitLab CI/CD](../README.md) via [Continuous Delivery](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/).
 
 We assume you have a basic experience with Laravel, Linux servers,
 and you know how to use GitLab.
@@ -25,11 +25,11 @@ It has a great community with a [fantastic documentation](https://laravel.com/do
 Aside from the usual routing, controllers, requests, responses, views, and (blade) templates, out of the box Laravel provides plenty of additional services such as cache, events, localization, authentication and many others.
 
 We will use [Envoy](https://laravel.com/docs/master/envoy) as an SSH task runner based on PHP.
-It uses a clean, minimal [Blade syntax](https://laravel.com/docs/blade) to set up tasks that can run on remote servers, such as, cloning your project from the repository, installing the Composer dependencies, and running [Artisan commands](https://laravel.com/docs/artisan).
+It uses a clean, minimal [Blade syntax](https://laravel.com/docs/master/blade) to set up tasks that can run on remote servers, such as, cloning your project from the repository, installing the Composer dependencies, and running [Artisan commands](https://laravel.com/docs/master/artisan).
 
 ## Initialize our Laravel app on GitLab
 
-We assume [you have installed a new laravel project](https://laravel.com/docs/installation#installation), so let's start with a unit test, and initialize Git for the project.
+We assume [you have installed a new laravel project](https://laravel.com/docs/master/installation#installation), so let's start with a unit test, and initialize Git for the project.
 
 ### Unit Test
 
@@ -82,12 +82,12 @@ git push -u origin master
 ## Configure the production server
 
 Before we begin setting up Envoy and GitLab CI/CD, let's quickly make sure the production server is ready for deployment.
-We have installed LEMP stack which stands for Linux, Nginx, MySQL and PHP on our Ubuntu 16.04.
+We have installed LEMP stack which stands for Linux, NGINX, MySQL and PHP on our Ubuntu 16.04.
 
 ### Create a new user
 
 Let's now create a new user that will be used to deploy our website and give it
-the needed permissions using [Linux ACL](https://serversforhackers.com/video/linux-acls):
+the needed permissions using [Linux ACL](https://serversforhackers.com/c/linux-acls):
 
 ```bash
 # Create user deployer
@@ -151,11 +151,11 @@ git clone git@gitlab.example.com:<USERNAME>/laravel-sample.git
 Answer **yes** if asked `Are you sure you want to continue connecting (yes/no)?`.
 It adds GitLab.com to the known hosts.
 
-### Configuring Nginx
+### Configuring NGINX
 
 Now, let's make sure our web server configuration points to the `current/public` rather than `public`.
 
-Open the default Nginx server block configuration file by typing:
+Open the default NGINX server block configuration file by typing:
 
 ```bash
 sudo nano /etc/nginx/sites-available/default
@@ -179,7 +179,7 @@ You may replace the app's name in `/var/www/app/current/public` with the folder
 So we have our Laravel app ready for production.
 The next thing is to use Envoy to perform the deploy.
 
-To use Envoy, we should first install it on our local machine [using the given instructions by Laravel](https://laravel.com/docs/envoy/#introduction).
+To use Envoy, we should first install it on our local machine [using the given instructions by Laravel](https://laravel.com/docs/master/envoy/#introduction).
 
 ### How Envoy works
 
@@ -216,7 +216,7 @@ Our deployment plan is to clone the latest release from GitLab repository, insta
 
 #### @setup directive
 
-The first step of our deployment process is to define a set of variables within [@setup](https://laravel.com/docs/envoy/#setup) directive.
+The first step of our deployment process is to define a set of variables within [@setup](https://laravel.com/docs/master/envoy/#setup) directive.
 You may change the `app` to your application's name:
 
 ```php
@@ -241,7 +241,7 @@ You may change the `app` to your application's name:
 
 #### @story directive
 
-The [@story](https://laravel.com/docs/envoy/#stories) directive allows us define a list of tasks that can be run as a single task.
+The [@story](https://laravel.com/docs/master/envoy/#stories) directive allows us define a list of tasks that can be run as a single task.
 Here we have three tasks called `clone_repository`, `run_composer`, `update_symlinks`. These variables are usable to making our task's codes more cleaner:
 
 ```php
@@ -391,10 +391,10 @@ git push origin master
 ## Continuous Integration with GitLab
 
 We have our app ready on GitLab, and we also can deploy it manually.
-But let's take a step forward to do it automatically with [Continuous Delivery](https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#continuous-delivery) method.
+But let's take a step forward to do it automatically with [Continuous Delivery](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#continuous-delivery) method.
 We need to check every commit with a set of automated tests to become aware of issues at the earliest, and then, we can deploy to the target environment if we are happy with the result of the tests.
 
-[GitLab CI/CD](../../README.md) allows us to use [Docker](https://docker.com/) engine to handle the process of testing and deploying our app.
+[GitLab CI/CD](../../README.md) allows us to use [Docker](https://www.docker.com) engine to handle the process of testing and deploying our app.
 In the case you're not familiar with Docker, refer to [How to Automate Docker Deployments](http://paislee.io/how-to-automate-docker-deployments/).
 
 To be able to build, test, and deploy our app with GitLab CI/CD, we need to prepare our work environment.
@@ -431,7 +431,7 @@ RUN curl --silent --show-error https://getcomposer.org/installer | php -- --inst
 RUN composer global require "laravel/envoy=~1.0"
 ```
 
-We added the [official PHP 7.1 Docker image](https://hub.docker.com/r/_/php/), which consist of a minimum installation of Debian Jessie with PHP pre-installed, and works perfectly for our use case.
+We added the [official PHP 7.1 Docker image](https://hub.docker.com/_/php), which consist of a minimum installation of Debian Jessie with PHP pre-installed, and works perfectly for our use case.
 
 We used `docker-php-ext-install` (provided by the official PHP Docker image) to install the PHP extensions we need.
 
@@ -469,7 +469,7 @@ Congratulations! You just pushed the first Docker image to the GitLab Registry,
 ![container registry page with image](img/container_registry_page_with_image.jpg)
 
 >**Note:**
-You can also [use GitLab CI/CD](https://about.gitlab.com/2016/05/23/gitlab-container-registry/#use-with-gitlab-ci) to build and push your Docker images, rather than doing that on your machine.
+You can also [use GitLab CI/CD](https://about.gitlab.com/blog/2016/05/23/gitlab-container-registry/#use-with-gitlab-ci) to build and push your Docker images, rather than doing that on your machine.
 
 We'll use this image further down in the `.gitlab-ci.yml` configuration file to handle the process of testing and deploying our app.
 
@@ -557,7 +557,7 @@ GitLab CI/CD allows us to use [environment variables](../../yaml/README.md#varia
 We defined MySQL as our database management system, which comes with a superuser root created by default.
 
 So we should adjust the configuration of MySQL instance by defining `MYSQL_DATABASE` variable as our database name and `MYSQL_ROOT_PASSWORD` variable as the password of `root`.
-Find out more about MySQL variables at the [official MySQL Docker Image](https://hub.docker.com/r/_/mysql/).
+Find out more about MySQL variables at the [official MySQL Docker Image](https://hub.docker.com/_/mysql).
 
 Also set the variables `DB_HOST` to `mysql` and `DB_USERNAME` to `root`, which are Laravel specific variables.
 We define `DB_HOST` as `mysql` instead of `127.0.0.1`, as we use MySQL Docker image as a service which [is linked to the main Docker image](../../docker/using_docker_images.md#how-services-are-linked-to-the-job).
@@ -605,7 +605,7 @@ The job `deploy_production` will deploy the app to the production server.
 To deploy our app with Envoy, we had to set up the `$SSH_PRIVATE_KEY` variable as an [SSH private key](../../ssh_keys/README.md#ssh-keys-when-using-the-docker-executor).
 If the SSH keys have added successfully, we can run Envoy.
 
-As mentioned before, GitLab supports [Continuous Delivery](https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#continuous-delivery) methods as well.
+As mentioned before, GitLab supports [Continuous Delivery](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#continuous-delivery) methods as well.
 The [environment](../../yaml/README.md#environment) keyword tells GitLab that this job deploys to the `production` environment.
 The `url` keyword is used to generate a link to our application on the GitLab Environments page.
 The `only` keyword tells GitLab CI that the job should be executed only when the pipeline is building the `master` branch.
@@ -634,7 +634,7 @@ deploy_production:
     - master
 ```
 
-You may also want to add another job for [staging environment](https://about.gitlab.com/2016/08/26/ci-deployment-and-environments), to final test your application before deploying to production.
+You may also want to add another job for [staging environment](https://about.gitlab.com/blog/2016/08/26/ci-deployment-and-environments/), to final test your application before deploying to production.
 
 ### Turn on GitLab CI/CD
 
diff --git a/doc/ci/examples/test-and-deploy-python-application-to-heroku.md b/doc/ci/examples/test-and-deploy-python-application-to-heroku.md
index f9d185f187c..34d53f67adc 100644
--- a/doc/ci/examples/test-and-deploy-python-application-to-heroku.md
+++ b/doc/ci/examples/test-and-deploy-python-application-to-heroku.md
@@ -72,7 +72,7 @@ You can do this through the [Dashboard](https://dashboard.heroku.com/).
 
 First install [Docker Engine](https://docs.docker.com/installation/).
 
-To build this project you also need to have [GitLab Runner](https://docs.gitlab.com/runner).
+To build this project you also need to have [GitLab Runner](https://docs.gitlab.com/runner/index.html).
 You can use public runners available on `gitlab.com` or you can register your own:
 
 ```sh
@@ -86,6 +86,6 @@ gitlab-runner register \
   --docker-postgres latest
 ```
 
-With the command above, you create a runner that uses the [python:3.5](https://hub.docker.com/r/_/python/) image and uses a [postgres](https://hub.docker.com/r/_/postgres/) database.
+With the command above, you create a runner that uses the [`python:3.5`](https://hub.docker.com/_/python) image and uses a [PostgreSQL](https://hub.docker.com/_/postgres) database.
 
 To access the PostgreSQL database, connect to `host: postgres` as user `postgres` with no password.
diff --git a/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md b/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md
index 79d54b52b5a..9a4fbfcce6d 100644
--- a/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md
+++ b/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md
@@ -77,6 +77,6 @@ gitlab-runner register \
   --docker-postgres latest
 ```
 
-With the command above, you create a Runner that uses the [ruby:2.2](https://hub.docker.com/r/_/ruby/) image and uses a [postgres](https://hub.docker.com/r/_/postgres/) database.
+With the command above, you create a Runner that uses the [ruby:2.2](https://hub.docker.com/_/ruby) image and uses a [postgres](https://hub.docker.com/_/postgres) database.
 
 To access the PostgreSQL database, connect to `host: postgres` as user `postgres` with no password.
diff --git a/doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md b/doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md
index 0e595e1a0be..a81568d6cd4 100644
--- a/doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md
+++ b/doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md
@@ -205,7 +205,7 @@ when running our Phoenix in our `localhost`.
 
   As our project is still fresh, we don't have any data on our database, so, the `migrations`
   directory will be empty.
-  Without `.gitkeep`, git will not upload this empty directory and we'll got an error when running our
+  Without `.gitkeep`, Git will not upload this empty directory and we'll got an error when running our
   test on GitLab.
 
   > **Note:** If we add a folder via the GitLab UI, GitLab itself will add the `.gitkeep` to that new dir.
@@ -412,8 +412,8 @@ other reasons][ci-reasons] to keep using GitLab CI/CD. The benefits to our teams
 [mix-ecto]: https://hexdocs.pm/ecto/Mix.Tasks.Ecto.Create.html "mix and Ecto"
 [iex]: https://elixir-lang.org/getting-started/introduction.html#interactive-mode "Interactive Mode"
 [ci-lint]: https://gitlab.com/ci/lint "CI Lint Tool"
-[ci-reasons]: https://about.gitlab.com/2015/02/03/7-reasons-why-you-should-be-using-ci/ "7 Reasons Why You Should Be Using CI"
-[ci-guide]: https://about.gitlab.com/2015/12/14/getting-started-with-gitlab-and-gitlab-ci/ "Getting Started With GitLab And GitLab CI/CD"
+[ci-reasons]: https://about.gitlab.com/blog/2015/02/03/7-reasons-why-you-should-be-using-ci/ "7 Reasons Why You Should Be Using CI"
+[ci-guide]: https://about.gitlab.com/blog/2015/12/14/getting-started-with-gitlab-and-gitlab-ci/ "Getting Started With GitLab And GitLab CI/CD"
 [ci-docs]: ../../README.md "GitLab CI/CD Documentation"
 [skipping-jobs]: ../../yaml/README.md#skipping-jobs "Skipping Jobs"
 [gitlab-runners]: ../../runners/README.md "GitLab Runners Documentation"
diff --git a/doc/ci/interactive_web_terminal/index.md b/doc/ci/interactive_web_terminal/index.md
index c1d4f784ddd..361e526ed96 100644
--- a/doc/ci/interactive_web_terminal/index.md
+++ b/doc/ci/interactive_web_terminal/index.md
@@ -30,7 +30,7 @@ Two things need to be configured for the interactive web terminal to work:
 
 NOTE: **Note:**
 Interactive web terminals are not yet supported by
-[`gitlab-runner` helm chart](https://docs.gitlab.com/charts/charts/gitlab/gitlab-runner/index.html),
+[`gitlab-runner` Helm chart](https://docs.gitlab.com/charts/charts/gitlab/gitlab-runner/index.html),
 but support [is planned](https://gitlab.com/gitlab-org/charts/gitlab-runner/issues/79).
 
 ## Debugging a running job
diff --git a/doc/ci/introduction/index.md b/doc/ci/introduction/index.md
index 4389b2ce015..a644a89eee4 100644
--- a/doc/ci/introduction/index.md
+++ b/doc/ci/introduction/index.md
@@ -190,6 +190,7 @@ according to each stage (Verify, Package, Release).
    - Store Docker images with [Container Registry](../../user/packages/container_registry/index.md).
    - Store NPM packages with [NPM Registry](../../user/packages/npm_registry/index.md). **(PREMIUM)**
    - Store Maven artifacts with [Maven Repository](../../user/packages/maven_repository/index.md). **(PREMIUM)**
+   - Store Conan packages with [Conan Repository](../../user/packages/conan_repository/index.md). **(PREMIUM)**
 1. **Release**:
    - Continuous Deployment, automatically deploying your app to production.
    - Continuous Delivery, manually click to deploy your app to production.
diff --git a/doc/ci/jenkins/index.md b/doc/ci/jenkins/index.md
index 2c3bdcf30d6..321d0d2778f 100644
--- a/doc/ci/jenkins/index.md
+++ b/doc/ci/jenkins/index.md
@@ -202,7 +202,7 @@ can provide any variables they like.
 
 #### `triggers` / `cron`
 
-Because GitLab is integrated tightly with git, SCM polling options for triggers are not needed. We support an easy to use
+Because GitLab is integrated tightly with Git, SCM polling options for triggers are not needed. We support an easy to use
 [syntax for scheduling pipelines](../../user/project/pipelines/schedules.md).
 
 #### `tools`
diff --git a/doc/ci/large_repositories/index.md b/doc/ci/large_repositories/index.md
index b1359537fca..ce998502b69 100644
--- a/doc/ci/large_repositories/index.md
+++ b/doc/ci/large_repositories/index.md
@@ -111,7 +111,7 @@ machines, and have an existing worktree that you can re-use for builds.
 
 For exact parameters accepted by
 [`GIT_CLEAN_FLAGS`](../yaml/README.md#git-clean-flags), see the documentation
-for [git clean](https://git-scm.com/docs/git-clean). The available parameters
+for [`git clean`](https://git-scm.com/docs/git-clean). The available parameters
 are dependent on Git version.
 
 ## Fork-based workflow
diff --git a/doc/ci/merge_request_pipelines/index.md b/doc/ci/merge_request_pipelines/index.md
index e29a13e87af..a49279f1932 100644
--- a/doc/ci/merge_request_pipelines/index.md
+++ b/doc/ci/merge_request_pipelines/index.md
@@ -151,13 +151,13 @@ parent project. This means you cannot completely trust the pipeline result,
 because, technically, external contributors can disguise their pipeline results
 by tweaking their GitLab Runner in the forked project.
 
-There are multiple reasons about why GitLab doesn't allow those pipelines to be
+There are multiple reasons why GitLab doesn't allow those pipelines to be
 created in the parent project, but one of the biggest reasons is security concern.
 External users could steal secret variables from the parent project by modifying
 `.gitlab-ci.yml`, which could be some sort of credentials. This should not happen.
 
 We're discussing a secure solution of running pipelines for merge requests
-that submitted from forked projects,
+that are submitted from forked projects,
 see [the issue about the permission extension](https://gitlab.com/gitlab-org/gitlab-foss/issues/23902).
 
 ## Additional predefined variables
diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/img/merge_request_pipeline.png b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/img/merge_request_pipeline.png
deleted file mode 100644
index 6d4b66824e1..00000000000
--- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/img/merge_request_pipeline.png
+++ /dev/null
diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/img/merged_result_pipeline_v12_3.png b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/img/merged_result_pipeline_v12_3.png
new file mode 100644
index 00000000000..6f0752bb940
--- /dev/null
+++ b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/img/merged_result_pipeline_v12_3.png
diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md
index e1c5848af03..3a0848fcd08 100644
--- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md
+++ b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md
@@ -20,7 +20,7 @@ GitLab can run pipelines for merge requests
 on this merged result. That is, where the source and target branches are combined into a
 new ref and a pipeline for this ref validates the result prior to merging.
 
-![Merge request pipeline as the head pipeline](img/merge_request_pipeline.png)
+![Merge request pipeline as the head pipeline](img/merged_result_pipeline_v12_3.png)
 
 There are some cases where creating a combined ref is not possible or not wanted.
 For example, a source branch that has conflicts with the target branch
@@ -93,6 +93,17 @@ To check these feature flag values, please ask administrator to execute the foll
 > Feature.enable(:ci_use_merge_request_ref)         # Enable the feature flag.
 ```
 
+### Intermittently pipelines fail by `fatal: reference is not a tree:` error
+
+Since pipelines for merged results are a run on a merge ref of a merge request
+(`refs/merge-requests/<iid>/merge`), the git-reference could be overwritten at an
+unexpected timing, for example, when a source or target branch is advanced.
+In this case, the pipeline fails because of `fatal: reference is not a tree:` error,
+which indicates that the checkout-SHA is not found in the merge ref.
+
+This behavior was improved at GitLab 12.4 by introducing [Persistent pipeline refs](../../pipelines.md#persistent-pipeline-refs).
+You should be able to create pipelines at any timings without concerning the error.
+
 ## Using Merge Trains **(PREMIUM)**
 
 By enabling [Pipelines for merged results](#pipelines-for-merged-results-premium),
diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md
index 767058376ca..f2a7902c9ca 100644
--- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md
+++ b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md
@@ -122,6 +122,12 @@ is unavailable when
 Follow [this issue](https://gitlab.com/gitlab-org/gitlab/issues/12267) to
 track progress on this issue.
 
+### Merge Train Pipeline cannot be retried
+
+A Merge Train pipeline cannot be retried because the merge request is dropped from the merge train upon failure. For this reason, the retry button does not appear next to the pipeline icon.
+
+In the case of pipeline failure, you should [re-enqueue](#how-to-add-a-merge-request-to-a-merge-train) the merge request to the merge train, which will then initiate a new pipeline.
+
 ### Merge Train disturbs your workflow
 
 First of all, please check if [merge immediately](#immediately-merge-a-merge-request-with-a-merge-train)
diff --git a/doc/ci/multi_project_pipelines.md b/doc/ci/multi_project_pipelines.md
index 8ae38db5c96..093d334e937 100644
--- a/doc/ci/multi_project_pipelines.md
+++ b/doc/ci/multi_project_pipelines.md
@@ -5,7 +5,7 @@ type: reference
 # Multi-project pipelines **(PREMIUM)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/2121) in
-[GitLab Premium 9.3](https://about.gitlab.com/2017/06/22/gitlab-9-3-released/#multi-project-pipeline-graphs).
+[GitLab Premium 9.3](https://about.gitlab.com/blog/2017/06/22/gitlab-9-3-released/#multi-project-pipeline-graphs).
 
 When you set up [GitLab CI/CD](README.md) across multiple projects, you can visualize
 the entire pipeline, including all cross-project inter-dependencies.
@@ -24,7 +24,7 @@ and when hovering or tapping (on touchscreen devices) they will expand and be sh
 ![Multi-project mini graph](img/multi_pipeline_mini_graph.gif)
 
 Multi-project pipelines are useful for larger products that require cross-project inter-dependencies, such as those
-adopting a [microservices architecture](https://about.gitlab.com/2016/08/16/trends-in-version-control-land-microservices/).
+adopting a [microservices architecture](https://about.gitlab.com/blog/2016/08/16/trends-in-version-control-land-microservices/).
 
 For a demonstration of how cross-functional development teams can use cross-pipeline
 triggering to trigger multiple pipelines for different microservices projects, see
@@ -115,8 +115,12 @@ staging:
     branch: stable-11-2
 ```
 
-Use a `project` keyword to specify full path to a downstream project. Use
-a `branch` keyword to specify a branch name.
+Use:
+
+- The `project` keyword to specify the full path to a downstream project.
+- The `branch` keyword to specify the name of a branch in the project specified by `project`.
+  [From GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/issues/10126), variable expansion is
+  supported.
 
 GitLab will use a commit that is currently on the HEAD of the branch when
 creating a downstream pipeline.
diff --git a/doc/ci/pipelines.md b/doc/ci/pipelines.md
index de9bac76281..e5f2701c6ae 100644
--- a/doc/ci/pipelines.md
+++ b/doc/ci/pipelines.md
@@ -204,7 +204,7 @@ the following (you can even use them interchangeably):
 - A colon (`:`).
 
 NOTE: **Note:**
-More specifically, it uses [this](https://gitlab.com/gitlab-org/gitlab-foss/blob/2f3dc314f42dbd79813e6251792853bc231e69dd/app/models/commit_status.rb#L99) regular expression: `\d+[\s:\/\\]+\d+\s*`.
+More specifically, it uses [this](https://gitlab.com/gitlab-org/gitlab/blob/2f3dc314f42dbd79813e6251792853bc231e69dd/app/models/commit_status.rb#L99) regular expression: `\d+[\s:\/\\]+\d+\s*`.
 
 #### How grouping works
 
@@ -283,11 +283,11 @@ You can also access pipelines for a merge request by navigating to its **Pipelin
 
 When you access a pipeline, you can see the related jobs for that pipeline.
 
-Clicking on an individual job will show you its job trace, and allow you to:
+Clicking on an individual job will show you its job log, and allow you to:
 
 - Cancel the job.
 - Retry the job.
-- Erase the job trace.
+- Erase the job log.
 
 ### Seeing the failure reason for jobs
 
@@ -379,6 +379,8 @@ This functionality is only available:
 
 ## Most Recent Pipeline
 
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/50499) in GitLab 12.3.
+
 There's a link to the latest pipeline for the last commit of a given branch at `/project/pipelines/[branch]/latest`. Also, `/project/pipelines/latest` will redirect you to the latest pipeline for the last commit on the project's default branch.
 
 ## Security on protected branches
@@ -405,3 +407,32 @@ branches, avoiding untrusted code to be executed on the protected runner and
 preserving deployment keys and other credentials from being unintentionally
 accessed. In order to ensure that jobs intended to be executed on protected
 runners will not use regular runners, they must be tagged accordingly.
+
+## Persistent pipeline refs
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/17043) in GitLab 12.4.
+
+Previously, you'd have encountered unexpected pipeline failures when you force-pushed
+a branch to its remote repository. To illustrate the problem, suppose you've had the current workflow:
+
+1. A user creates a feature branch named `example` and pushes it to a remote repository.
+1. A new pipeline starts running on the `example` branch.
+1. A user rebases the `example` branch on the latest `master` branch and force-pushes it to its remote repository.
+1. A new pipeline starts running on the `example` branch again, however,
+   the previous pipeline (2) fails because of `fatal: reference is not a tree:` error.
+
+This is because the previous pipeline cannot find a checkout-SHA (which associated with the pipeline record)
+from the `example` branch that the commit history has already been overwritten by the force-push.
+Similarly, [Pipelines for merged results](merge_request_pipelines/pipelines_for_merged_results/index.md)
+might have failed intermittently due to [the same reason](merge_request_pipelines/pipelines_for_merged_results/index.md#intermittently-pipelines-fail-by-fatal-reference-is-not-a-tree-error).
+
+As of GitLab 12.4, we've improved this behavior by persisting pipeline refs exclusively.
+To illustrate its life cycle:
+
+1. A pipeline is created on a feature branch named `example`.
+1. A persistent pipeline ref is created at `refs/pipelines/<pipeline-id>`,
+   which retains the checkout-SHA of the associated pipeline record.
+   This persistent ref stays intact during the pipeline execution,
+   even if the commit history of the `example` branch has been overwritten by force-push.
+1. GitLab Runner fetches the persistent pipeline ref and gets source code from the checkout-SHA.
+1. When the pipeline finished, its persistent ref is cleaned up in a background process.
diff --git a/doc/ci/quick_start/README.md b/doc/ci/quick_start/README.md
index 0822b01d553..10a898be900 100644
--- a/doc/ci/quick_start/README.md
+++ b/doc/ci/quick_start/README.md
@@ -22,7 +22,7 @@ GitLab offers a [continuous integration][ci] service. If you
 and configure your GitLab project to use a [Runner], then each commit or
 push triggers your CI [pipeline].
 
-The `.gitlab-ci.yml` file tells the GitLab runner what to do. By default it runs
+The `.gitlab-ci.yml` file tells the GitLab Runner what to do. By default it runs
 a pipeline with three [stages]: `build`, `test`, and `deploy`. You don't need to
 use all three stages; stages with no jobs are simply ignored.
 
@@ -126,7 +126,7 @@ a "CI Lint" button to go to this page under **CI/CD ➔ Pipelines** and
 **Pipelines ➔ Jobs** in your project.
 
 For more information and a complete `.gitlab-ci.yml` syntax, please read
-[the reference documentation on .gitlab-ci.yml](../yaml/README.md).
+[the reference documentation on `.gitlab-ci.yml`](../yaml/README.md).
 
 ### Push `.gitlab-ci.yml` to GitLab
 
@@ -235,7 +235,7 @@ Visit the [examples README][examples] to see a list of examples using GitLab
 CI with various languages.
 
 [runner-install]: https://docs.gitlab.com/runner/install/
-[blog-ci]: https://about.gitlab.com/2015/05/06/why-were-replacing-gitlab-ci-jobs-with-gitlab-ci-dot-yml/
+[blog-ci]: https://about.gitlab.com/blog/2015/05/06/why-were-replacing-gitlab-ci-jobs-with-gitlab-ci-dot-yml/
 [examples]: ../examples/README.md
 [ci]: https://about.gitlab.com/product/continuous-integration/
 [yaml]: ../yaml/README.md
diff --git a/doc/ci/review_apps/index.md b/doc/ci/review_apps/index.md
index 7a1e6e4e1b8..da92fadafc4 100644
--- a/doc/ci/review_apps/index.md
+++ b/doc/ci/review_apps/index.md
@@ -24,8 +24,8 @@ In the above example:
 
 - A Review App is built every time a commit is pushed to `topic branch`.
 - The reviewer fails two reviews before passing the third review.
-- Once the review as passed, `topic branch` is merged into `master` where it's deploy to staging.
-- After been approved in staging, the changes that were merged into `master` are deployed in to production.
+- Once the review has passed, `topic branch` is merged into `master` where it is deployed to staging.
+- After having been approved in staging, the changes that were merged into `master` are deployed in to production.
 
 ## How Review Apps work
 
diff --git a/doc/ci/runners/README.md b/doc/ci/runners/README.md
index f7d1a3e88a2..4011ae4df70 100644
--- a/doc/ci/runners/README.md
+++ b/doc/ci/runners/README.md
@@ -365,8 +365,8 @@ We're always looking for contributions that can mitigate these
 ### Resetting the registration token for a Project
 
 If you think that registration token for a Project was revealed, you should
-reset them. It's recommended because such token can be used to register another
-Runner to the Project. It may be next used to obtain the values of secret
+reset them. It's recommended because such a token can be used to register another
+Runner to the Project. It may then be used to obtain the values of secret
 variables or clone the project code, that normally may be unavailable for the
 attacker.
 
@@ -379,10 +379,10 @@ To reset the token:
 1. After the page is refreshed, expand the **Runners settings** section
    and check the registration token - it should be changed.
 
-From now on the old token is not valid anymore and will not allow to register
-a new Runner to the project. If you are using any tools to provision and
-register new Runners, you should now update the token that is used to the
-new value.
+From now on the old token is no longer valid and will not register
+any new Runners to the project. If you are using any tools to provision and
+register new Runners, the tokens used in those tools should be updated to reflect the
+value of the new token.
 
 ## Determining the IP address of a Runner
 
diff --git a/doc/ci/services/redis.md b/doc/ci/services/redis.md
index 8b227154b06..ccb92fa94d7 100644
--- a/doc/ci/services/redis.md
+++ b/doc/ci/services/redis.md
@@ -30,7 +30,7 @@ Host: redis
 And that's it. Redis will now be available to be used within your testing
 framework.
 
-You can also use any other docker image available on [Docker Hub][hub-redis].
+You can also use any other docker image available on [Docker Hub](https://hub.docker.com/_/redis).
 For example, to use Redis 2.8 the service becomes `redis:2.8`.
 
 ## Use Redis with the Shell executor
@@ -62,12 +62,9 @@ Host: localhost
 
 ## Example project
 
-We have set up an [Example Redis Project][redis-example-repo] for your convenience
+We have set up an [Example Redis Project](https://gitlab.com/gitlab-examples/redis) for your convenience
 that runs on [GitLab.com](https://gitlab.com) using our publicly available
 [shared runners](../runners/README.md).
 
 Want to hack on it? Simply fork it, commit and push  your changes. Within a few
 moments the changes will be picked by a public runner and the job will begin.
-
-[hub-redis]: https://hub.docker.com/r/_/redis/
-[redis-example-repo]: https://gitlab.com/gitlab-examples/redis
diff --git a/doc/ci/ssh_keys/README.md b/doc/ci/ssh_keys/README.md
index b6aebd3bd78..bee1501aed8 100644
--- a/doc/ci/ssh_keys/README.md
+++ b/doc/ci/ssh_keys/README.md
@@ -25,18 +25,18 @@ with any type of [executor](https://docs.gitlab.com/runner/executors/)
 
 ## How it works
 
-1. Create a new SSH key pair locally with [ssh-keygen](http://linux.die.net/man/1/ssh-keygen)
+1. Create a new SSH key pair locally with [`ssh-keygen`](https://linux.die.net/man/1/ssh-keygen)
 1. Add the private key as a [variable](../variables/README.md) to
    your project
-1. Run the [ssh-agent](http://linux.die.net/man/1/ssh-agent) during job to load
+1. Run the [`ssh-agent`](https://linux.die.net/man/1/ssh-agent) during job to load
    the private key.
 1. Copy the public key to the servers you want to have access to (usually in
    `~/.ssh/authorized_keys`) or add it as a [deploy key](../../ssh/README.md#deploy-keys)
    if you are accessing a private GitLab repository.
 
 NOTE: **Note:**
-The private key will not be displayed in the job trace, unless you enable
-[debug tracing](../variables/README.md#debug-tracing). You might also want to
+The private key will not be displayed in the job log, unless you enable
+[debug logging](../variables/README.md#debug-logging). You might also want to
 check the [visibility of your pipelines](../../user/project/pipelines/settings.md#visibility-of-pipelines).
 
 ## SSH keys when using the Docker executor
diff --git a/doc/ci/triggers/README.md b/doc/ci/triggers/README.md
index d2efae8ebef..82cbd40c4c6 100644
--- a/doc/ci/triggers/README.md
+++ b/doc/ci/triggers/README.md
@@ -6,7 +6,7 @@ type: tutorial
 
 > **Notes**:
 >
-> - [Introduced](https://about.gitlab.com/2015/08/22/gitlab-7-14-released/) in GitLab 7.14.
+> - [Introduced](https://about.gitlab.com/blog/2015/08/22/gitlab-7-14-released/) in GitLab 7.14.
 > - GitLab 8.12 has a completely redesigned job permissions system. Read all
 >   about the [new model and its implications](../../user/project/new_ci_build_permissions_model.md#pipeline-triggers).
 
@@ -157,7 +157,7 @@ curl --request POST \
 You can also benefit by using triggers in your `.gitlab-ci.yml`. Let's say that
 you have two projects, A and B, and you want to trigger a rebuild on the `master`
 branch of project B whenever a tag on project A is created. This is the job you
-need to add in project's A `.gitlab-ci.yml`:
+need to add in project A's `.gitlab-ci.yml`:
 
 ```yaml
 build_docs:
diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md
index 5e871ec7958..5d86d382aa8 100644
--- a/doc/ci/variables/README.md
+++ b/doc/ci/variables/README.md
@@ -1,5 +1,4 @@
 ---
-table_display_block: true
 type: reference
 ---
 
@@ -263,12 +262,13 @@ export CI_JOB_TOKEN="abcde-1234ABCD5678ef"
 export CI_PIPELINE_ID="1000"
 export CI_PIPELINE_IID="10"
 export CI_PAGES_DOMAIN="gitlab.io"
-export CI_PAGES_URL="https://gitlab-org.gitlab.io/gitlab-ce"
+export CI_PAGES_URL="https://gitlab-org.gitlab.io/gitlab-foss"
 export CI_PROJECT_ID="34"
 export CI_PROJECT_DIR="/builds/gitlab-org/gitlab-foss"
-export CI_PROJECT_NAME="gitlab-ce"
+export CI_PROJECT_NAME="gitlab-foss"
+export CI_PROJECT_TITLE="GitLab FOSS"
 export CI_PROJECT_NAMESPACE="gitlab-org"
-export CI_PROJECT_PATH="gitlab-org/gitlab-ce"
+export CI_PROJECT_PATH="gitlab-org/gitlab-foss"
 export CI_PROJECT_URL="https://example.com/gitlab-org/gitlab-foss"
 export CI_REGISTRY="registry.example.com"
 export CI_REGISTRY_IMAGE="registry.example.com/gitlab-org/gitlab-foss"
@@ -568,7 +568,7 @@ Below you can find supported syntax reference:
    Precedence of operators follows standard Ruby 2.5 operation
    [precedence](https://ruby-doc.org/core-2.5.0/doc/syntax/precedence_rdoc.html).
 
-## Debug tracing
+## Debug logging
 
 > Introduced in GitLab Runner 1.7.
 
@@ -576,24 +576,24 @@ CAUTION: **Warning:**
 Enabling debug tracing can have severe security implications. The
 output **will** contain the content of all your variables and any other
 secrets! The output **will** be uploaded to the GitLab server and made visible
-in job traces!
+in job logs!
 
 By default, GitLab Runner hides most of the details of what it is doing when
-processing a job. This behavior keeps job traces short, and prevents secrets
-from being leaked into the trace unless your script writes them to the screen.
+processing a job. This behavior keeps job logs short, and prevents secrets
+from being leaked into the log unless your script writes them to the screen.
 
 If a job isn't working as expected, this can make the problem difficult to
 investigate; in these cases, you can enable debug tracing in `.gitlab-ci.yml`.
 Available on GitLab Runner v1.7+, this feature enables the shell's execution
-trace, resulting in a verbose job trace listing all commands that were run,
+log, resulting in a verbose job log listing all commands that were run,
 variables that were set, etc.
 
 Before enabling this, you should ensure jobs are visible to
 [team members only](../../user/permissions.md#project-features). You should
-also [erase](../pipelines.md#accessing-individual-jobs) all generated job traces
+also [erase](../pipelines.md#accessing-individual-jobs) all generated job logs
 before making them visible again.
 
-To enable debug traces, set the `CI_DEBUG_TRACE` variable to `true`:
+To enable debug logs (traces), set the `CI_DEBUG_TRACE` variable to `true`:
 
 ```yaml
 job_name:
@@ -601,7 +601,7 @@ job_name:
     CI_DEBUG_TRACE: "true"
 ```
 
-Example truncated output with debug trace set to true:
+Example truncated output with `CI_DEBUG_TRACE` set to `true`:
 
 ```bash
 ...
@@ -708,6 +708,8 @@ Running on runner-8a2f473d-project-1796893-concurrent-0 via runner-8a2f473d-mach
 ++ CI_PROJECT_ID=17893
 ++ export CI_PROJECT_NAME=ci-debug-trace
 ++ CI_PROJECT_NAME=ci-debug-trace
+++ export 'CI_PROJECT_TITLE="GitLab FOSS'
+++ CI_PROJECT_TITLE='GitLab FOSS'
 ++ export CI_PROJECT_PATH=gitlab-examples/ci-debug-trace
 ++ CI_PROJECT_PATH=gitlab-examples/ci-debug-trace
 ++ export CI_PROJECT_NAMESPACE=gitlab-examples
diff --git a/doc/ci/variables/predefined_variables.md b/doc/ci/variables/predefined_variables.md
index e3ff3385f97..20e70d212b0 100644
--- a/doc/ci/variables/predefined_variables.md
+++ b/doc/ci/variables/predefined_variables.md
@@ -40,13 +40,14 @@ future GitLab releases.**
 | `CI_COMMIT_TAG`                         | 9.0    | 0.5    | The commit tag name. Present only when building tags. |
 | `CI_COMMIT_TITLE`                       | 10.8   | all    | The title of the commit - the full first line of the message |
 | `CI_CONFIG_PATH`                        | 9.4    | 0.5    | The path to CI config file. Defaults to `.gitlab-ci.yml` |
-| `CI_DEBUG_TRACE`                        | all    | 1.7    | Whether [debug tracing](README.md#debug-tracing) is enabled |
+| `CI_DEBUG_TRACE`                        | all    | 1.7    | Whether [debug logging (tracing)](README.md#debug-logging) is enabled |
 | `CI_DEPLOY_PASSWORD`                    | 10.8   | all    | Authentication password of the [GitLab Deploy Token][gitlab-deploy-token], only present if the Project has one related.|
 | `CI_DEPLOY_USER`                        | 10.8   | all    | Authentication username of the [GitLab Deploy Token][gitlab-deploy-token], only present if the Project has one related.|
 | `CI_DISPOSABLE_ENVIRONMENT`             | all    | 10.1   | Marks that the job is executed in a disposable environment (something that is created only for this job and disposed of/destroyed after the execution - all executors except `shell` and `ssh`). If the environment is disposable, it is set to true, otherwise it is not defined at all. |
 | `CI_ENVIRONMENT_NAME`                   | 8.15   | all    | The name of the environment for this job. Only present if [`environment:name`](../yaml/README.md#environmentname) is set. |
 | `CI_ENVIRONMENT_SLUG`                   | 8.15   | all    | A simplified version of the environment name, suitable for inclusion in DNS, URLs, Kubernetes labels, etc. Only present if [`environment:name`](../yaml/README.md#environmentname) is set. |
 | `CI_ENVIRONMENT_URL`                    | 9.3    | all    | The URL of the environment for this job. Only present if [`environment:url`](../yaml/README.md#environmenturl) is set. |
+| `CI_DEFAULT_BRANCH`                     | 12.4   | all    | The name of the default branch for the project. |
 | `CI_JOB_ID`                             | 9.0    | all    | The unique id of the current job that GitLab CI uses internally |
 | `CI_JOB_MANUAL`                         | 8.12   | all    | The flag to indicate that job was manually started |
 | `CI_JOB_NAME`                           | 9.0    | 0.5    | The name of the job as defined in `.gitlab-ci.yml` |
@@ -60,12 +61,12 @@ future GitLab releases.**
 | `CI_MERGE_REQUEST_PROJECT_URL`          | 11.6   | all    | The URL of the project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) (e.g. `http://192.168.10.15:3000/namespace/awesome-project`). Available only if `only: [merge_requests]` is used and the merge request is created.  |
 | `CI_MERGE_REQUEST_REF_PATH`             | 11.6   | all    | The ref path of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). (e.g. `refs/merge-requests/1/head`). Available only if `only: [merge_requests]` is used and the merge request is created.  |
 | `CI_MERGE_REQUEST_SOURCE_BRANCH_NAME`   | 11.6   | all    | The source branch name of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created.  |
-| `CI_MERGE_REQUEST_SOURCE_BRANCH_SHA`    | 11.9   | all    | The HEAD SHA of the source branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created.  |
+| `CI_MERGE_REQUEST_SOURCE_BRANCH_SHA`    | 11.9   | all    | The HEAD SHA of the source branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used, the merge request is created, and the pipeline is a [merged result pipeline](../merge_request_pipelines/pipelines_for_merged_results/index.md). **(PREMIUM)** |
 | `CI_MERGE_REQUEST_SOURCE_PROJECT_ID`    | 11.6   | all    | The ID of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created.  |
 | `CI_MERGE_REQUEST_SOURCE_PROJECT_PATH`  | 11.6   | all    | The path of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created.  |
 | `CI_MERGE_REQUEST_SOURCE_PROJECT_URL`   | 11.6   | all    | The URL of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created.  |
 | `CI_MERGE_REQUEST_TARGET_BRANCH_NAME`   | 11.6   | all    | The target branch name of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created.  |
-| `CI_MERGE_REQUEST_TARGET_BRANCH_SHA`    | 11.9   | all    | The HEAD SHA of the target branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created.  |
+| `CI_MERGE_REQUEST_TARGET_BRANCH_SHA`    | 11.9   | all    | The HEAD SHA of the target branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used, the merge request is created, and the pipeline is a [merged result pipeline](../merge_request_pipelines/pipelines_for_merged_results/index.md). **(PREMIUM)** |
 | `CI_MERGE_REQUEST_TITLE`                | 11.9   | all    | The title of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created.  |
 | `CI_MERGE_REQUEST_ASSIGNEES`            | 11.9   | all    | Comma-separated list of username(s) of assignee(s) for the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. |
 | `CI_MERGE_REQUEST_MILESTONE`            | 11.9   | all    | The milestone title of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created.  |
@@ -87,7 +88,8 @@ future GitLab releases.**
 | `CI_PIPELINE_URL`                       | 11.1   | 0.5    | Pipeline details URL |
 | `CI_PROJECT_DIR`                        | all    | all    | The full path where the repository is cloned and where the job is run. If the GitLab Runner `builds_dir` parameter is set, this variable is set relative to the value of `builds_dir`. For more information, see [Advanced configuration](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section) for GitLab Runner. |
 | `CI_PROJECT_ID`                         | all    | all    | The unique id of the current project that GitLab CI uses internally |
-| `CI_PROJECT_NAME`                       | 8.10   | 0.5    | The project name that is currently being built (actually it is project folder name) |
+| `CI_PROJECT_NAME`                       | 8.10   | 0.5    | The name of the directory for the project that is currently being built. For example, if the project URL is `gitlab.example.com/group-name/project-1`, the `CI_PROJECT_NAME` would be `project-1`. |
+| `CI_PROJECT_TITLE`                      | 12.4   | all    | The human-readable project name as displayed in the GitLab web interface. |
 | `CI_PROJECT_NAMESPACE`                  | 8.10   | 0.5    | The project namespace (username or groupname) that is currently being built |
 | `CI_PROJECT_PATH`                       | 8.10   | 0.5    | The namespace with project name |
 | `CI_PROJECT_PATH_SLUG`                  | 9.3    | all    | `$CI_PROJECT_PATH` lowercased and with everything except `0-9` and `a-z` replaced with `-`. Use in URLs and domain names. |
@@ -108,7 +110,7 @@ future GitLab releases.**
 | `CI_RUNNER_VERSION`                     | all    | 10.6   | GitLab Runner version that is executing the current job |
 | `CI_RUNNER_SHORT_TOKEN`                 | all    | 12.3   | First eight characters of GitLab Runner's token used to authenticate new job requests. Used as Runner's unique ID |
 | `CI_SERVER`                             | all    | all    | Mark that job is executed in CI environment |
-| `CI_SERVER_HOST`                        | 12.1   | all    | Host component of the GitLab instance URL, without protocol and port (like gitlab.example.com) |
+| `CI_SERVER_HOST`                        | 12.1   | all    | Host component of the GitLab instance URL, without protocol and port (like `gitlab.example.com`) |
 | `CI_SERVER_NAME`                        | all    | all    | The name of CI server that is used to coordinate jobs |
 | `CI_SERVER_REVISION`                    | all    | all    | GitLab revision that is used to schedule jobs |
 | `CI_SERVER_VERSION`                     | all    | all    | GitLab version that is used to schedule jobs |
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index 5c747688bb1..4569e9ff9b6 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -20,7 +20,7 @@ We have complete examples of configuring pipelines:
 
 - For a quick introduction to GitLab CI, follow our [quick start guide](../quick_start/README.md).
 - For a collection of examples, see [GitLab CI/CD Examples](../examples/README.md).
-- To see a large `.gitlab-ci.yml` file used in an enterprise, see the [`.gitlab-ci.yml` file for `gitlab-ce`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/.gitlab-ci.yml).
+- To see a large `.gitlab-ci.yml` file used in an enterprise, see the [`.gitlab-ci.yml` file for `gitlab`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml).
 
 NOTE: **Note:**
 If you have a [mirrored repository where GitLab pulls from](../../workflow/repository_mirroring.md#pulling-from-a-remote-repository-starter),
@@ -56,7 +56,7 @@ Jobs are picked up by [Runners](../runners/README.md) and executed within the
 environment of the Runner. What is important, is that each job is run
 independently from each other.
 
-### Validate the .gitlab-ci.yml
+### Validate the `.gitlab-ci.yml`
 
 Each instance of GitLab CI has an embedded debug tool called Lint, which validates the
 content of your `.gitlab-ci.yml` files. You can find the Lint under the page `ci/lint` of your
@@ -107,17 +107,17 @@ The following table lists available parameters for jobs:
 | [`environment`](#environment)                      | Name of an environment to which the job deploys. Also available: `environment:name`, `environment:url`, `environment:on_stop`, and `environment:action`.                                                                                                                                                                                                                                                                                                                                                                                                                                |
 | [`cache`](#cache)                                  | List of files that should be cached between subsequent runs. Also available: `cache:paths`, `cache:key`, `cache:untracked`, and `cache:policy`.                                                                                                                                                                                                                                                                                                                                                                                                                                         |
 | [`artifacts`](#artifacts)                          | List of files and directories to attach to a job on success. Also available: `artifacts:paths`, `artifacts:name`, `artifacts:untracked`, `artifacts:when`, `artifacts:expire_in`, `artifacts:reports`, and `artifacts:reports:junit`.<br><br>In GitLab [Enterprise Edition](https://about.gitlab.com/pricing/), these are available: `artifacts:reports:codequality`, `artifacts:reports:sast`, `artifacts:reports:dependency_scanning`, `artifacts:reports:container_scanning`, `artifacts:reports:dast`, `artifacts:reports:license_management`, `artifacts:reports:performance` and `artifacts:reports:metrics`. |
-| [`dependencies`](#dependencies)                    | Other jobs that a job depends on so that you can pass artifacts between them.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| [`dependencies`](#dependencies)                    | Restrict which artifacts are passed to a specific job by providing a list of jobs to fetch artifacts from.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
 | [`coverage`](#coverage)                            | Code coverage settings for a given job.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
 | [`retry`](#retry)                                  | When and how many times a job can be auto-retried in case of a failure.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-| [`timeout`](#timeout)                              | Define a custom timeout that would take precedence over the project-wide one.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| [`timeout`](#timeout)                              | Define a custom job-level timeout that takes precedence over the project-wide setting.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
 | [`parallel`](#parallel)                            | How many instances of a job should be run in parallel.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
 | [`trigger`](#trigger-premium)                      | Defines a downstream pipeline trigger.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
 | [`include`](#include)                              | Allows this job to include external YAML files. Also available: `include:local`, `include:file`, `include:template`, and `include:remote`.                                                                                                                                                                                                                                                                                                                                                                                                                                              |
 | [`extends`](#extends)                              | Configuration entries that this job is going to inherit from.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
 | [`pages`](#pages)                                  | Upload the result of a job to use with GitLab Pages.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
 | [`variables`](#variables)                          | Define job variables on a job level.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
-| [interruptible](#interruptible)                    | Defines if a job can be canceled when made redundant by a newer run                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
+| [`interruptible`](#interruptible)                  | Defines if a job can be canceled when made redundant by a newer run.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
 
 NOTE: **Note:**
 Parameters `types` and `type` are [deprecated](#deprecated-parameters).
@@ -187,7 +187,7 @@ Used to specify [a Docker image](../docker/using_docker_images.md#what-is-an-ima
 
 For:
 
-- Simple definition examples, see [Define `image` and `services` from .gitlab-ci.yml](../docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml).
+- Simple definition examples, see [Define `image` and `services` from `.gitlab-ci.yml`](../docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml).
 - Detailed usage information, refer to [Docker integration](../docker/README.md) documentation.
 
 #### `image:name`
@@ -208,7 +208,7 @@ Used to specify a [service Docker image](../docker/using_docker_images.md#what-i
 
 For:
 
-- Simple definition examples, see [Define `image` and `services` from .gitlab-ci.yml](../docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml).
+- Simple definition examples, see [Define `image` and `services` from `.gitlab-ci.yml`](../docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml).
 - Detailed usage information, refer to [Docker integration](../docker/README.md) documentation.
 - For example services, see [GitLab CI Services](../services/README.md).
 
@@ -242,10 +242,10 @@ For more information, see see [Available settings for `services`](../docker/usin
 
 `before_script` is used to define the command that should be run before all
 jobs, including deploy jobs, but after the restoration of [artifacts](#artifacts).
-This can be an array or a multi-line string.
+This must be an an array.
 
 `after_script` is used to define the command that will be run after all
-jobs, including failed ones. This has to be an array or a multi-line string.
+jobs, including failed ones. This must be an an array.
 
 Scripts specified in `before_script` are:
 
@@ -318,6 +318,17 @@ There are also two edge cases worth mentioning:
    `test` and `deploy` are allowed to be used as job's stage by default.
 1. If a job doesn't specify a `stage`, the job is assigned the `test` stage.
 
+#### `.pre` and `.post`
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/31441) in GitLab 12.4.
+
+The following stages are available to every pipeline:
+
+- `.pre`, which is guaranteed to always be the first stage in a pipeline.
+- `.post`, which is guaranteed to always be the last stage in a pipeline.
+
+User-defined stages are executed after `.pre` and before `.post`.
+
 ### `stage`
 
 `stage` is defined per-job and relies on [`stages`](#stages) which is defined
@@ -330,6 +341,10 @@ stages:
   - test
   - deploy
 
+job 0:
+  stage: .pre
+  script: make something useful before build stage
+
 job 1:
   stage: build
   script: make build dependencies
@@ -345,6 +360,10 @@ job 3:
 job 4:
   stage: deploy
   script: make deploy
+
+job 5:
+  stage: .post
+  script: make something useful at the end of pipeline
 ```
 
 #### Using your own Runners
@@ -379,8 +398,8 @@ In addition, `only` and `except` allow the use of special keywords:
 
 | **Value** |  **Description**  |
 | --------- |  ---------------- |
-| `branches`       | When a git reference of a pipeline is a branch.  |
-| `tags`           | When a git reference of a pipeline is a tag.  |
+| `branches`       | When a Git reference of a pipeline is a branch.  |
+| `tags`           | When a Git reference of a pipeline is a tag.  |
 | `api`            | When pipeline has been triggered by a second pipelines API (not triggers API).  |
 | `external`       | When using CI services other than GitLab. |
 | `pipelines`      | For multi-project triggers, created using the API with `CI_JOB_TOKEN`. |
@@ -436,13 +455,13 @@ repository and not forks:
 ```yaml
 job:
   only:
-    - branches@gitlab-org/gitlab-ce
+    - branches@gitlab-org/gitlab
   except:
-    - master@gitlab-org/gitlab-ce
-    - /^release/.*$/@gitlab-org/gitlab-ce
+    - master@gitlab-org/gitlab
+    - /^release/.*$/@gitlab-org/gitlab
 ```
 
-The above example will run `job` for all branches on `gitlab-org/gitlab-ce`,
+The above example will run `job` for all branches on `gitlab-org/gitlab`,
 except `master` and those with names prefixed with `release/`.
 
 If a job does not have an `only` rule, `only: ['branches', 'tags']` is set by
@@ -530,15 +549,15 @@ single conjoined expression. That is:
 
 With `only`, individual keys are logically joined by an AND:
 
-> (any of refs) AND (any of variables) AND (any of changes) AND (if kubernetes is active)
+> (any of refs) AND (any of variables) AND (any of changes) AND (if Kubernetes is active)
 
 `except` is implemented as a negation of this complete expression:
 
-> NOT((any of refs) AND (any of variables) AND (any of changes) AND (if kubernetes is active))
+> NOT((any of refs) AND (any of variables) AND (any of changes) AND (if Kubernetes is active))
 
 This, more intuitively, means the keys join by an OR. A functionally equivalent expression:
 
-> (any of refs) OR (any of variables) OR (any of changes) OR (if kubernetes is active)
+> (any of refs) OR (any of variables) OR (any of changes) OR (if Kubernetes is active)
 
 #### `only:refs`/`except:refs`
 
@@ -612,7 +631,7 @@ Learn more about [variables expressions](../variables/README.md#environment-vari
 > `changes` policy [introduced][ce-19232] in GitLab 11.4.
 
 Using the `changes` keyword with `only` or `except` makes it possible to define if
-a job should be created based on files modified by a git push event.
+a job should be created based on files modified by a Git push event.
 
 For example:
 
@@ -627,8 +646,8 @@ docker build:
       - more_scripts/*.{rb,py,sh}
 ```
 
-In the scenario above, when pushing multiple commits to GitLab to an existing
-branch, GitLab creates and triggers the `docker build` job, provided that one of the
+In the scenario above, when pushing commits to an existing branch in GitLab,
+it creates and triggers the `docker build` job, provided that one of the
 commits contains changes to any of the following:
 
 - The `Dockerfile` file.
@@ -636,7 +655,13 @@ commits contains changes to any of the following:
 - Any of the files and subdirectories inside the `dockerfiles` directory.
 - Any of the files with `rb`, `py`, `sh` extensions inside the `more_scripts` directory.
 
-You can also use glob patterns to match multiple files in either the root directory of the repo, or in _any_ directory within the repo. For example:
+CAUTION: **Warning:**
+If using `only:changes` with [only allow merge requests to be merged if the pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds),
+undesired behavior could result if you do not [also use `only:merge_requests`](#using-onlychanges-with-pipelines-for-merge-requests).
+
+You can also use glob patterns to match multiple files in either the root directory
+of the repo, or in _any_ directory within the repo, but they must be wrapped
+in double quotes or GitLab will fail to parse the `.gitlab-ci.yml`. For example:
 
 ```yaml
 test:
@@ -647,10 +672,8 @@ test:
       - "**/*.sql"
 ```
 
-NOTE: **Note:**
-In the example above, the expressions are wrapped double quotes because they are glob patterns. GitLab will fail to parse `.gitlab-ci.yml` files with unwrapped glob patterns.
-
-The following example will skip the CI job if a change is detected in any file in the root directory of the repo with a `.md` extension:
+The following example will skip the `build` job if a change is detected in any file
+in the root directory of the repo with a `.md` extension:
 
 ```yaml
 build:
@@ -661,22 +684,20 @@ build:
 ```
 
 CAUTION: **Warning:**
-There are some caveats when using this feature with new branches and tags. See
-the section below.
-
-##### Using `changes` with new branches and tags
+There are some points to be aware of when
+[using this feature with new branches or tags *without* pipelines for merge requests](#using-onlychanges-without-pipelines-for-merge-requests).
 
-When pushing a **new** branch or a **new** tag to GitLab, the policy always
-evaluates to true and GitLab will create a job. This feature is not connected
-with merge requests yet and, because GitLab is creating pipelines before a user
-can create a merge request, it is unknown what the target branch is at this point.
-
-##### Using `changes` with `merge_requests`
+##### Using `only:changes` with pipelines for merge requests
 
 With [pipelines for merge requests](../merge_request_pipelines/index.md),
 it is possible to define a job to be created based on files modified
 in a merge request.
 
+In order to deduce the correct base SHA of the source branch, we recommend combining
+this keyword with `only: merge_requests`. This way, file differences are correctly
+calculated from any further commits, thus all changes in the merge requests are properly
+tested in pipelines.
+
 For example:
 
 ```yaml
@@ -694,6 +715,42 @@ In the scenario above, if a merge request is created or updated that changes
 either files in `service-one` directory or the `Dockerfile`, GitLab creates
 and triggers the `docker build service one` job.
 
+Note that if [pipelines for merge requests](../merge_request_pipelines/index.md) is
+combined with `only: change`, but `only: merge_requests` is omitted, there could be
+unwanted behavior.
+
+For example:
+
+```yaml
+docker build service one:
+  script: docker build -t my-service-one-image:$CI_COMMIT_REF_SLUG .
+  only:
+    changes:
+      - Dockerfile
+      - service-one/**/*
+```
+
+In the example above, a pipeline could fail due to changes to a file in `service-one/**/*`.
+A later commit could then be pushed that does not include any changes to this file,
+but includes changes to the `Dockerfile`, and this pipeline could pass because it is only
+testing the changes to the `Dockerfile`. GitLab checks the **most recent pipeline**,
+that **passed**, and will show the merge request as mergable, despite the earlier
+failed pipeline caused by a change that was not yet corrected.
+
+With this configuration, care must be taken to check that the most recent pipeline
+properly corrected any failures from previous pipelines.
+
+##### Using `only:changes` without pipelines for merge requests
+
+Without [pipelines for merge requests](../merge_request_pipelines/index.md), pipelines
+run on branches or tags that don't have an explicit association with a merge request.
+In this case, a previous SHA is used to calculate the diff, which equivalent to `git diff HEAD~`.
+This could result in some unexpected behavior, including:
+
+- When pushing a new branch or a new tag to GitLab, the policy always evaluates to true.
+- When pushing a new commit, the changed files are calculated using the previous commit
+  as the base SHA.
+
 ### `rules`
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/29011) in GitLab 12.3.
@@ -707,6 +764,7 @@ Available rule clauses include:
   (similar to [`only:variables`](#onlyvariablesexceptvariables)).
 - [`changes`](#ruleschanges)
   (same as [`only:changes`](#onlychangesexceptchanges)).
+- [`exists`](#rulesexists)
 
 For example, using `if`. This configuration specifies that `job` should be built
 and run for every pipeline on merge requests targeting `master`, regardless of
@@ -716,7 +774,7 @@ the status of other builds:
 job:
   script: "echo Hello, Rules!"
   rules:
-    - if: '$CI_MERGE_REQUEST_TARGET_BRANCH == "master"'
+    - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"'
       when: always
     - if: '$VAR =~ /pattern/'
       when: manual
@@ -742,11 +800,11 @@ evaluated should be conjoined into a single expression using `&&` or `||`. For e
 job:
   script: "echo Hello, Rules!"
   rules:
-    - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH =~ /^feature/ && $CI_MERGE_REQUEST_TARGET_BRANCH == "master"' # This rule will be evaluated
+    - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/ && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"' # This rule will be evaluated
       when: always
-    - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH =~ /^feature/' # This rule will only be evaluated if the target branch is not "master"
+    - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/' # This rule will only be evaluated if the target branch is not "master"
       when: manual
-    - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH' # If neither of the first two match but the simple presence does, we set to "on_success" by default
+    - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME' # If neither of the first two match but the simple presence does, we set to "on_success" by default
 ```
 
 If none of the provided rules match, the job will be set to `when:never`, and
@@ -779,9 +837,44 @@ In this example, a job either set to:
 - Run manually if `Dockerfile` has changed OR `$VAR == "string value"`.
 - `when:on_success` by the last rule, where no earlier clauses evaluate to true.
 
+#### `rules:exists`
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/16574) in GitLab 12.4.
+
+`exists` accepts an array of paths and will match if any of these paths exist
+as files in the repository.
+
+For example:
+
+```yaml
+job:
+  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
+  rules:
+    - exists:
+      - Dockerfile
+```
+
+You can also use glob patterns to match multiple files in any directory within
+the repository.
+
+For example:
+
+```yaml
+job:
+  script: bundle exec rspec
+  rules:
+    - exists:
+      - spec/**.rb
+```
+
+NOTE: **Note:**
+For performance reasons, using `exists` with patterns is limited to 10000
+checks. After the 10000th check, rules with patterned globs will always match.
+
 #### Complex rule clauses
 
-To conjoin `if` and `changes` clauses with an AND, use them in the same rule.
+To conjoin `if`, `changes`, and `exists` clauses with an AND, use them in the
+same rule.
 
 In the following example:
 
@@ -805,6 +898,7 @@ The only clauses currently available are:
 
 - `if`
 - `changes`
+- `exists`
 
 Keywords such as `branches` or `refs` that are currently available for
 `only`/`except` are not yet available in `rules` as they are being individually
@@ -837,7 +931,7 @@ docker build:
 
 Additional job configuration may be added to rules in the future. If something
 useful isn't available, please
-[open an issue](https://www.gitlab.com/gitlab-org/gitlab-foss/issues).
+[open an issue](https://www.gitlab.com/gitlab-org/gitlab/issues).
 
 ### `tags`
 
@@ -1011,7 +1105,52 @@ Manual actions are considered to be write actions, so permissions for
 [protected branches](../../user/project/protected_branches.md) are used when
 a user wants to trigger an action. In other words, in order to trigger a manual
 action assigned to a branch that the pipeline is running for, the user needs to
-have the ability to merge to this branch.
+have the ability to merge to this branch. It is possible to use protected environments
+to more strictly [protect manual deployments](#protecting-manual-jobs-premium) from being
+run by unauthorized users.
+
+NOTE: **Note:**
+Using `when:manual` and `trigger` together results in the error `jobs:#{job-name} when
+should be on_success, on_failure or always`, because `when:manual` prevents triggers
+being used.
+
+##### Protecting manual jobs **(PREMIUM)**
+
+It's possible to use [protected environments](../environments/protected_environments.md)
+to define a precise list of users authorized to run a manual job. By allowing only
+users associated with a protected environment to trigger manual jobs, it is possible
+to implement some special use cases, such as:
+
+- More precisely limiting who can deploy to an environment.
+- Enabling a pipeline to be blocked until an approved user "approves" it.
+
+To do this, you must:
+
+1. Add an `environment` to the job. For example:
+
+   ```yaml
+   deploy_prod:
+     stage: deploy
+     script:
+       - echo "Deploy to production server"
+     environment:
+       name: production
+       url: https://example.com
+     when: manual
+     only:
+       - master
+   ```
+
+1. In the [protected environments settings](../environments/protected_environments.md#protecting-environments),
+   select the environment (`production` in the example above) and add the users, roles or groups
+   that are authorized to trigger the manual job to the **Allowed to Deploy** list. Only those in
+   this list will be able to trigger this manual job, as well as GitLab administrators
+   who are always able to use protected environments.
+
+Additionally, if a manual job is defined as blocking by adding `allow_failure: false`,
+the next stages of the pipeline will not run until the manual job is triggered. This
+can be used as a way to have a defined list of users allowed to "approve" later pipeline
+stages by triggering the blocking manual job.
 
 #### `when:delayed`
 
@@ -1047,7 +1186,7 @@ You can stop the active timer of a delayed job by clicking the **Unschedule** bu
 This job will never be executed in the future unless you execute the job manually.
 
 You can start a delayed job immediately by clicking the **Play** button.
-GitLab runner will pick your job soon and start the job.
+GitLab Runner will pick your job soon and start the job.
 
 ### `environment`
 
@@ -1241,15 +1380,15 @@ Read how caching works and find out some good practices in the
 [caching dependencies documentation](../caching/index.md).
 
 `cache` is used to specify a list of files and directories which should be
-cached between jobs. You can only use paths that are within the project
-workspace.
+cached between jobs. You can only use paths that are within the local working
+copy.
 
 If `cache` is defined outside the scope of jobs, it means it is set
 globally and all jobs will use that definition.
 
 #### `cache:paths`
 
-Use the `paths` directive to choose which files or directories will be cached.
+Use the `paths` directive to choose which files or directories will be cached. You can only specify paths within your `$CI_PROJECT_DIR`.
 Wildcards can be used that follow the [glob](https://en.wikipedia.org/wiki/Glob_(programming)) patterns and [filepath.Match](https://golang.org/pkg/path/filepath/#Match).
 
 Cache all files in `binaries` that end in `.apk` and the `.config` file:
@@ -1412,10 +1551,10 @@ be available for download in the GitLab UI.
 
 #### `artifacts:paths`
 
-You can only use paths that are within the project workspace.
+You can only use paths that are within the local working copy.
 Wildcards can be used that follow the [glob](https://en.wikipedia.org/wiki/Glob_(programming)) patterns and [filepath.Match](https://golang.org/pkg/path/filepath/#Match).
 
-To pass artifacts between different jobs, see [dependencies](#dependencies).
+To restrict which jobs a specific job will fetch artifacts from, see [dependencies](#dependencies).
 
 Send all files in `binaries` and `.config`:
 
@@ -1759,10 +1898,9 @@ be automatically shown in merge requests.
 
 > Introduced in GitLab 8.6 and GitLab Runner v1.1.1.
 
-This feature should be used in conjunction with [`artifacts`](#artifacts) and
-allows you to define the artifacts to pass between different jobs.
-
-Note that `artifacts` from all previous [stages](#stages) are passed by default.
+By default, all [`artifacts`](#artifacts) from all previous [stages](#stages)
+are passed, but you can use the `dependencies` parameter to define a limited
+list of jobs (or no jobs) to fetch artifacts from.
 
 To use this feature, define `dependencies` in context of the job and pass
 a list of all previous jobs from which the artifacts should be downloaded.
@@ -1892,14 +2030,14 @@ This example creates three paths of execution:
   - For self-managed instances, the limit is:
     - Five by default (`ci_dag_limit_needs` feature flag is enabled).
     - 50 if the `ci_dag_limit_needs` feature flag is disabled.
-- It is impossible for now to have `needs: []` (empty needs),
-  the job always needs to depend on something, unless this is the job
-  in the first stage (see [gitlab-ce#65504](https://gitlab.com/gitlab-org/gitlab-foss/issues/65504)).
+- It is impossible for now to have `needs: []` (empty needs), the job always needs to
+  depend on something, unless this is the job in the first stage. However, support for
+  an empty needs array [is planned](https://gitlab.com/gitlab-org/gitlab/issues/30631).
 - If `needs:` refers to a job that is marked as `parallel:`.
   the current job will depend on all parallel jobs created.
-- `needs:` is similar to `dependencies:` in that it needs to use jobs from
-  prior stages, meaning it is impossible to create circular
-  dependencies or depend on jobs in the current stage (see [gitlab-ce#65505](https://gitlab.com/gitlab-org/gitlab-foss/issues/65505)).
+- `needs:` is similar to `dependencies:` in that it needs to use jobs from prior stages,
+  meaning it is impossible to create circular dependencies. Depending on jobs in the
+  current stage is not possible either, but support [is planned](https://gitlab.com/gitlab-org/gitlab/issues/30632).
 - Related to the above, stages must be explicitly defined for all jobs
   that have the keyword `needs:` or are referred to by one.
 
@@ -1996,9 +2134,11 @@ Possible values for `when` are:
 - `missing_dependency_failure`: Retry if a dependency was missing.
 - `runner_unsupported`: Retry if the runner was unsupported.
 
-### timeout
+### `timeout`
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/14887) in GitLab 12.3.
 
-`timeout` allows you to configure a timeout for a specific job:
+`timeout` allows you to configure a timeout for a specific job. For example:
 
 ```yaml
 build:
@@ -2010,6 +2150,10 @@ test:
   timeout: 3h 30m
 ```
 
+The job-level timeout can exceed the
+[project-level timeout](../../user/project/pipelines/settings.md#timeout) but can not
+exceed the Runner-specific timeout.
+
 ### `parallel`
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/22631) in GitLab 11.5.
@@ -2068,6 +2212,11 @@ created.
 
 Learn more about [multi-project pipelines](../multi_project_pipelines.md#creating-multi-project-pipelines-from-gitlab-ciyml).
 
+NOTE: **Note:**
+Using a `trigger` with `when:manual` together results in the error `jobs:#{job-name}
+when should be on_success, on_failure or always`, because `when:manual` prevents
+triggers being used.
+
 #### Simple `trigger` syntax
 
 The most simple way to configure a downstream trigger to use `trigger` keyword
@@ -2104,19 +2253,19 @@ staging:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/23464) in GitLab 12.3.
 
-`interruptible` is used to indicate that a job should be canceled if made redundant by a newer run of the same job. Defaults to `false`.
+`interruptible` is used to indicate that a job should be canceled if made redundant by a newer pipeline run. Defaults to `false`.
 This value will only be used if the [automatic cancellation of redundant pipelines feature](../../user/project/pipelines/settings.md#auto-cancel-pending-pipelines)
 is enabled.
 
 When enabled, a pipeline on the same branch will be canceled when:
 
 - It is made redundant by a newer pipeline run.
-- Either all jobs are set as interruptible, or any uninterruptible jobs are not yet pending.
+- Either all jobs are set as interruptible, or any uninterruptible jobs have not started.
 
 Pending jobs are always considered interruptible.
 
 TIP: **Tip:**
-Set jobs as uninterruptible that should behave atomically and should never be canceled once started.
+Set jobs as interruptible that can be safely canceled once started (for instance, a build job).
 
 Here is a simple example:
 
@@ -2124,23 +2273,33 @@ Here is a simple example:
 stages:
   - stage1
   - stage2
+  - stage3
 
 step-1:
   stage: stage1
   script:
-    - echo "Can be canceled"
-  
+    - echo "Can be canceled."
+  interruptible: true
+
 step-2:
   stage: stage2
   script:
-    - echo "Can not be canceled"
-  interruptible: false
+    - echo "Can not be canceled."
+
+step-3:
+  stage: stage3
+  script:
+    - echo "Because step-2 can not be canceled, this step will never be canceled, even though set as interruptible."
+  interruptible: true
 ```
 
 In the example above, a new pipeline run will cause an existing running pipeline to be:
 
 - Canceled, if only `step-1` is running or pending.
-- Not canceled, once `step-2` becomes pending.
+- Not canceled, once `step-2` starts running.
+
+NOTE: **Note:**
+Once an uninterruptible job is running, the pipeline will never be canceled, regardless of the final job's state.
 
 ### `include`
 
@@ -2243,7 +2402,7 @@ or template includes.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/53445) in GitLab 11.7.
 
 `include:template` can be used to include `.gitlab-ci.yml` templates that are
-[shipped with GitLab](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/lib/gitlab/ci/templates).
+[shipped with GitLab](https://gitlab.com/gitlab-org/gitlab/tree/master/lib/gitlab/ci/templates).
 
 For example:
 
@@ -2284,9 +2443,13 @@ or public project, or template is allowed.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/56836) in GitLab 11.9.
 
 Nested includes allow you to compose a set of includes.
-A total of 50 includes is allowed.
+A total of 100 includes is allowed.
 Duplicate includes are considered a configuration error.
 
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/28212) in GitLab 12.4.
+
+A hard limit of 30 seconds was set for resolving all files.
+
 #### `include` examples
 
 Here are a few more `include` examples.
@@ -2722,14 +2885,14 @@ unspecified, the default from project settings will be used.
 There are three possible values: `clone`, `fetch`, and `none`.
 
 `clone` is the slowest option. It clones the repository from scratch for every
-job, ensuring that the project workspace is always pristine.
+job, ensuring that the local working copy is always pristine.
 
 ```yaml
 variables:
   GIT_STRATEGY: clone
 ```
 
-`fetch` is faster as it re-uses the project workspace (falling back to `clone`
+`fetch` is faster as it re-uses the local working copy (falling back to `clone`
 if it doesn't exist). `git clean` is used to undo any changes made by the last
 job, and `git fetch` is used to retrieve commits made since the last job ran.
 
@@ -2738,11 +2901,11 @@ variables:
   GIT_STRATEGY: fetch
 ```
 
-`none` also re-uses the project workspace, but skips all Git operations
+`none` also re-uses the local working copy, but skips all Git operations
 (including GitLab Runner's pre-clone script, if present). It is mostly useful
 for jobs that operate exclusively on artifacts (e.g., `deploy`). Git repository
 data may be present, but it is certain to be out of date, so you should only
-rely on files brought into the project workspace from cache or artifacts.
+rely on files brought into the local working copy from cache or artifacts.
 
 ```yaml
 variables:
@@ -2829,7 +2992,7 @@ The `GIT_CLEAN_FLAGS` variable is used to control the default behavior of
 `git clean` after checking out the sources. You can set it globally or per-job in the
 [`variables`](#variables) section.
 
-`GIT_CLEAN_FLAGS` accepts all possible options of the [git clean](https://git-scm.com/docs/git-clean)
+`GIT_CLEAN_FLAGS` accepts all possible options of the [`git clean`](https://git-scm.com/docs/git-clean)
 command.
 
 `git clean` is disabled if `GIT_CHECKOUT: "false"` is specified.
@@ -2944,7 +3107,7 @@ default:
 
 ## Custom build directories
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1267) in Gitlab Runner 11.10
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1267) in GitLab Runner 11.10
 
 NOTE: **Note:**
 This can only be used when `custom_build_dir` is enabled in the [Runner's
@@ -3205,13 +3368,8 @@ all updated Merge Requests will have a pipeline created when using
 If your commit message contains `[ci skip]` or `[skip ci]`, using any
 capitalization, the commit will be created but the pipeline will be skipped.
 
-Alternatively, one can pass the `ci.skip` [Git push option][push-option] if
-using Git 2.10 or newer:
-
-```sh
-git push --push-option=ci.skip    # using git 2.10+
-git push -o ci.skip               # using git 2.18+
-```
+Alternatively, one can pass the `ci.skip` [Git push option](../../user/project/push_options.md#push-options-for-gitlab-cicd)
+if using Git 2.10 or newer.
 
 <!-- ## Troubleshooting
 
diff --git a/doc/customization/branded_login_page.md b/doc/customization/branded_login_page.md
index afcc2b71284..9667e5e380a 100644
--- a/doc/customization/branded_login_page.md
+++ b/doc/customization/branded_login_page.md
@@ -1,38 +1,5 @@
 ---
-type: howto
+redirect_to: '../user/admin_area/appearance.md#sign-in--sign-up-pages'
 ---
 
-# Changing the logo and description on the login page
-
-You can customize the login page of your GitLab server to show the logo and
-description of your organization.
-
-By default, the page shows the GitLab logo and description:
-
-![default_login_page](branded_login_page/default_login_page.png)
-
-To customize the login page:
-
-1. Navigate to the **Admin** area and go to the **Appearance** page.
-1. Fill in your desired Title and Description. You can also choose an image file
-   of the logo for your organization.
-
-   ![appearance](branded_login_page/appearance.png)
-
-1. Save your changes.
-
-Your GitLab login page will display the details you provided:
-
-![company_login_page](branded_login_page/custom_sign_in.png)
-
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-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. -->
+This document was moved to [another location](../user/admin_area/appearance.md#sign-in--sign-up-pages).
diff --git a/doc/customization/branded_login_page/appearance.png b/doc/customization/branded_login_page/appearance.png
deleted file mode 100644
index 31ea4559d37..00000000000
--- a/doc/customization/branded_login_page/appearance.png
+++ /dev/null
diff --git a/doc/customization/branded_login_page/custom_sign_in.png b/doc/customization/branded_login_page/custom_sign_in.png
deleted file mode 100644
index 03ea5281ebe..00000000000
--- a/doc/customization/branded_login_page/custom_sign_in.png
+++ /dev/null
diff --git a/doc/customization/branded_login_page/default_login_page.png b/doc/customization/branded_login_page/default_login_page.png
deleted file mode 100644
index 9b1233cef45..00000000000
--- a/doc/customization/branded_login_page/default_login_page.png
+++ /dev/null
diff --git a/doc/customization/branded_page_and_email_header.md b/doc/customization/branded_page_and_email_header.md
index 370c1461d30..64958521f64 100644
--- a/doc/customization/branded_page_and_email_header.md
+++ b/doc/customization/branded_page_and_email_header.md
@@ -1,37 +1,5 @@
 ---
-type: howto
+redirect_to: '../user/admin_area/appearance.md#navigation-bar'
 ---
 
-# Changing the navigation bar and email header logo
-
-You can customize the logo that appears in email headers and in the navigation
-bar on pages that are displayed by your GitLab server.
-
-1. Navigate to the **Admin** area and go to the **Appearance** page, then locate
-   the **Navigation bar** section.
-1. For the **Header Logo**, choose an image file of the logo for your
-   organization.
-
-   ![appearance](branded_page_and_email_header/appearance.png)
-
-1. Save your changes.
-
-Your GitLab navigation bar will display the custom logo:
-
-![custom_brand_header](branded_page_and_email_header/custom_brand_header.png)
-
-The GitLab pipeline emails will also display the custom logo:
-
-![custom_email_header](branded_page_and_email_header/custom_email_header.png)
-
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-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. -->
+This document was moved to [another location](../user/admin_area/appearance.md#navigation-bar).
diff --git a/doc/customization/branded_page_and_email_header/appearance.png b/doc/customization/branded_page_and_email_header/appearance.png
deleted file mode 100644
index 6b79bc47005..00000000000
--- a/doc/customization/branded_page_and_email_header/appearance.png
+++ /dev/null
diff --git a/doc/customization/branded_page_and_email_header/custom_brand_header.png b/doc/customization/branded_page_and_email_header/custom_brand_header.png
deleted file mode 100644
index d779236bbe7..00000000000
--- a/doc/customization/branded_page_and_email_header/custom_brand_header.png
+++ /dev/null
diff --git a/doc/customization/branded_page_and_email_header/custom_email_header.png b/doc/customization/branded_page_and_email_header/custom_email_header.png
deleted file mode 100644
index 729b166364b..00000000000
--- a/doc/customization/branded_page_and_email_header/custom_email_header.png
+++ /dev/null
diff --git a/doc/customization/favicon.md b/doc/customization/favicon.md
index e165a16ffd9..d43ed944e26 100644
--- a/doc/customization/favicon.md
+++ b/doc/customization/favicon.md
@@ -1,37 +1,5 @@
 ---
-type: howto
+redirect_to: '../user/admin_area/appearance.md#favicon'
 ---
 
-# Changing the favicon
-
-> [Introduced][ce-14497] in GitLab 11.0.
-
-[ce-14497]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/14497
-
-You can customize the favicon (the icon displayed in your web browser's
-address bar and web page tabs) for your GitLab server.
-
-1. Navigate to the **Admin** area and go to the **Appearance** page, then
-   locate the **Favicon** section.
-1. Upload an image file of your favicon.
-
-   ![appearance](favicon/appearance.png)
-
-1. Save your changes.
-
-Your new favicon will display in the browser. The main favicon and the CI
-status icons will show the custom icon:
-
-![custom_favicon](favicon/custom_favicon.png)
-
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-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. -->
+This document was moved to [another location](../user/admin_area/appearance.md#favicon).
diff --git a/doc/customization/favicon/appearance.png b/doc/customization/favicon/appearance.png
deleted file mode 100644
index da1002826dd..00000000000
--- a/doc/customization/favicon/appearance.png
+++ /dev/null
diff --git a/doc/customization/favicon/custom_favicon.png b/doc/customization/favicon/custom_favicon.png
deleted file mode 100644
index 20dddfbea33..00000000000
--- a/doc/customization/favicon/custom_favicon.png
+++ /dev/null
diff --git a/doc/customization/help_message.md b/doc/customization/help_message.md
index a4d8f295750..5694ee89c17 100644
--- a/doc/customization/help_message.md
+++ b/doc/customization/help_message.md
@@ -1,36 +1,5 @@
 ---
-type: howto
+redirect_to: '../user/admin_area/settings/help_page.md'
 ---
 
-# Customizing the 'Help' and login page messages
-
-In large organizations, it is useful to have information about who maintains
-the company GitLab server. You can customize and display this information on
-the GitLab login page and on the GitLab server's `/help` page.
-
-1. Navigate to the **Admin** area, then click on **Preferences** and expand
-   **Help page**.
-1. Under **Help page text**, fill in the required information about the
-   person(s) administering GitLab. This text can also contain any other
-   information that you wish to display to users.
-
-   ![help message](help_message/help_text.png)
-
-1. Save your changes.
-
-The information you entered will be shown on the GitLab login page and on the
-GitLab `/help` page (e.g., <https://gitlab.com/help>).
-
-![help text on help page](help_message/help_text_on_help_page.png)
-
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-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. -->
+This document was moved to [another location](../user/admin_area/settings/help_page.md).
diff --git a/doc/customization/help_message/help_text.png b/doc/customization/help_message/help_text.png
deleted file mode 100644
index 5fcabcdb757..00000000000
--- a/doc/customization/help_message/help_text.png
+++ /dev/null
diff --git a/doc/customization/help_message/help_text_on_help_page.png b/doc/customization/help_message/help_text_on_help_page.png
deleted file mode 100644
index 288b4b8c1eb..00000000000
--- a/doc/customization/help_message/help_text_on_help_page.png
+++ /dev/null
diff --git a/doc/customization/index.md b/doc/customization/index.md
index f17a2d80e2c..f3e1e3190fd 100644
--- a/doc/customization/index.md
+++ b/doc/customization/index.md
@@ -1,18 +1,5 @@
 ---
-type: index
-description: Learn how to customize GitLab's appearance for self-managed installations.
+redirect_to: '../user/admin_area/appearance.md'
 ---
 
-# Customizing GitLab's appearance **(CORE ONLY)**
-
-For GitLab self-managed instances, you can customize the page logo,
-email headers, favicon, and several other aspects of GitLab's appearance.
-
-The following pages explain how to customize the appearance of your instance:
-
-- [Changing the logo and description on the login page](branded_login_page.md)
-- [Changing the navigation bar and email header logo](branded_page_and_email_header.md)
-- [Changing the favicon](favicon.md)
-- [Customizing the new project page](new_project_page.md)
-- [Customizing the `/help` and login page messages](help_message.md)
-- [Using the Libravatar service with GitLab](libravatar.md)
+This document was moved to [another location](../user/admin_area/appearance.md).
diff --git a/doc/customization/libravatar.md b/doc/customization/libravatar.md
index 577528fb33b..78df24066ea 100644
--- a/doc/customization/libravatar.md
+++ b/doc/customization/libravatar.md
@@ -1,101 +1,5 @@
 ---
-type: howto
+redirect_to: '../administration/libravatar.md'
 ---
 
-# Using the Libravatar service with GitLab
-
-GitLab by default supports the [Gravatar](https://gravatar.com) avatar service.
-
-Libravatar is another service that delivers your avatar (profile picture) to
-other websites. The Libravatar API is
-[heavily based on gravatar](https://wiki.libravatar.org/api/), so you can
-easily switch to the Libravatar avatar service or even a self-hosted Libravatar
-server.
-
-## Configuration
-
-In the [`gitlab.yml` gravatar section](https://gitlab.com/gitlab-org/gitlab-foss/blob/672bd3902d86b78d730cea809fce312ec49d39d7/config/gitlab.yml.example#L122), set
-the configuration options as follows:
-
-### For HTTP
-
-```yml
-  gravatar:
-    enabled: true
-    # gravatar URLs: possible placeholders: %{hash} %{size} %{email} %{username}
-    plain_url: "http://cdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
-```
-
-### For HTTPS
-
-```yml
-  gravatar:
-    enabled: true
-    # gravatar URLs: possible placeholders: %{hash} %{size} %{email} %{username}
-    ssl_url: "https://seccdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
-```
-
-### Self-hosted Libravatar server
-
-If you are [running your own libravatar service](https://wiki.libravatar.org/running_your_own/),
-the URL will be different in the configuration, but you must provide the same
-placeholders so GitLab can parse the URL correctly.
-
-For example, you host a service on `http://libravatar.example.com` and the
-`plain_url` you need to supply in `gitlab.yml` is
-
-`http://libravatar.example.com/avatar/%{hash}?s=%{size}&d=identicon`
-
-### Omnibus GitLab example
-
-In `/etc/gitlab/gitlab.rb`:
-
-#### For HTTP
-
-```ruby
-gitlab_rails['gravatar_enabled'] = true
-gitlab_rails['gravatar_plain_url'] = "http://cdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
-```
-
-#### For HTTPS
-
-```ruby
-gitlab_rails['gravatar_enabled'] = true
-gitlab_rails['gravatar_ssl_url'] = "https://seccdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
-```
-
-Then run `sudo gitlab-ctl reconfigure` for the changes to take effect.
-
-## Default URL for missing images
-
-[Libravatar supports different sets](https://wiki.libravatar.org/api/) of
-missing images for user email addresses that are not found on the Libravatar
-service.
-
-In order to use a set other than `identicon`, replace the `&d=identicon`
-portion of the URL with another supported set.
-For example, you can use the `retro` set, in which case the URL would look like:
-`plain_url: "http://cdn.libravatar.org/avatar/%{hash}?s=%{size}&d=retro"`
-
-## Usage examples for Microsoft Office 365
-
-If your users are Office 365 users, the `GetPersonaPhoto` service can be used.
-Note that this service requires a login, so this use case is most useful in a
-corporate installation where all users have access to Office 365.
-
-```ruby
-gitlab_rails['gravatar_plain_url'] = 'http://outlook.office365.com/owa/service.svc/s/GetPersonaPhoto?email=%{email}&size=HR120x120'
-gitlab_rails['gravatar_ssl_url'] = 'https://outlook.office365.com/owa/service.svc/s/GetPersonaPhoto?email=%{email}&size=HR120x120'
-```
-
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-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. -->
+This document was moved to [another location](../administration/libravatar.md).
diff --git a/doc/customization/new_project_page.md b/doc/customization/new_project_page.md
index 43b95a76d08..ee09df26cb1 100644
--- a/doc/customization/new_project_page.md
+++ b/doc/customization/new_project_page.md
@@ -1,38 +1,5 @@
 ---
-type: howto
+redirect_to: '../user/admin_area/appearance.md#new-project-pages'
 ---
 
-# Customizing the new project page
-
-You can add a markdown-formatted message to your GitLab new project page.
-
-By default, the new project page shows a sidebar with general information:
-
-![default_new_project_page](new_project_page/default_new_project_page.png)
-
-To customize the information in the sidebar:
-
-1. Navigate to the **Admin** area and go to the **Appearance** page, then
-   locate the **New project pages** section.
-1. Fill in your new project project guidelines:
-
-   ![appearance_settings](new_project_page/appearance_settings.png)
-
-1. Save the page.
-
-Your new project page will show the customized guidelines in the sidebar, below
-the general information:
-
-![custom_new_project_page](new_project_page/custom_new_project_page.png)
-
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-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. -->
+This document was moved to [another location](../user/admin_area/appearance.md#new-project-pages).
diff --git a/doc/customization/new_project_page/appearance_settings.png b/doc/customization/new_project_page/appearance_settings.png
deleted file mode 100644
index 4fcdd1caa21..00000000000
--- a/doc/customization/new_project_page/appearance_settings.png
+++ /dev/null
diff --git a/doc/customization/new_project_page/custom_new_project_page.png b/doc/customization/new_project_page/custom_new_project_page.png
deleted file mode 100644
index c6f7839e9c3..00000000000
--- a/doc/customization/new_project_page/custom_new_project_page.png
+++ /dev/null
diff --git a/doc/customization/new_project_page/default_new_project_page.png b/doc/customization/new_project_page/default_new_project_page.png
deleted file mode 100644
index f5b209ac5ea..00000000000
--- a/doc/customization/new_project_page/default_new_project_page.png
+++ /dev/null
diff --git a/doc/customization/system_header_and_footer_messages.md b/doc/customization/system_header_and_footer_messages.md
index b3aa48b1e2f..1d17f3bee3f 100644
--- a/doc/customization/system_header_and_footer_messages.md
+++ b/doc/customization/system_header_and_footer_messages.md
@@ -1,23 +1,5 @@
-# Adding a system message to every page
+---
+redirect_to: '../user/admin_area/appearance.md#system-header-and-footer-messages'
+---
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/5023) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.7.
-> [Added](https://gitlab.com/gitlab-org/gitlab-foss/issues/55057) to [GitLab Core](https://about.gitlab.com/pricing/) in 11.9.
-
-Navigate to the **Admin** area and go to the **Appearance** page.
-
-Under **System header and footer** insert your header message and/or footer message.
-Both background and font color of the header and footer are customizable.
-
-You can also apply the header and footer messages to GitLab emails,
-by checking the **Enable header and footer in emails** checkbox.
-Note that color settings will only be applied within the app interface and not to emails
-
-![appearance](system_header_and_footer_messages/appearance.png)
-
-After saving, all GitLab pages will contain the custom system header and/or footer messages:
-
-![custom_header_footer](system_header_and_footer_messages/custom_header_footer.png)
-
-The GitLab sign in page will also show the header and the footer messages:
-
-![sign_up_custom_header_and_footer](system_header_and_footer_messages/sign_up_custom_header_and_footer.png)
+This document was moved to [another location](../user/admin_area/appearance.md#system-header-and-footer-messages).
diff --git a/doc/customization/system_header_and_footer_messages/appearance.png b/doc/customization/system_header_and_footer_messages/appearance.png
deleted file mode 100644
index d5a66bcb9f1..00000000000
--- a/doc/customization/system_header_and_footer_messages/appearance.png
+++ /dev/null
diff --git a/doc/customization/system_header_and_footer_messages/custom_header_footer.png b/doc/customization/system_header_and_footer_messages/custom_header_footer.png
deleted file mode 100644
index 15d19c87dd7..00000000000
--- a/doc/customization/system_header_and_footer_messages/custom_header_footer.png
+++ /dev/null
diff --git a/doc/customization/system_header_and_footer_messages/sign_up_custom_header_and_footer.png b/doc/customization/system_header_and_footer_messages/sign_up_custom_header_and_footer.png
deleted file mode 100644
index 51349ddf6f4..00000000000
--- a/doc/customization/system_header_and_footer_messages/sign_up_custom_header_and_footer.png
+++ /dev/null
diff --git a/doc/development/README.md b/doc/development/README.md
index 0d1168c4450..16b073045cc 100644
--- a/doc/development/README.md
+++ b/doc/development/README.md
@@ -19,7 +19,6 @@ description: 'Learn how to contribute to GitLab.'
 - [Code review guidelines](code_review.md) for reviewing code and having code reviewed
 - [Database review guidelines](database_review.md) for reviewing database-related changes and complex SQL queries
 - [Pipelines for the GitLab project](pipelines.md)
-- [Automatic CE->EE merge](automatic_ce_ee_merge.md)
 - [Guidelines for implementing Enterprise Edition features](ee_features.md)
 - [Security process for developers](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#security-releases-critical-non-critical-as-a-developer)
 - [Requesting access to Chatops on GitLab.com](chatops_on_gitlabcom.md#requesting-access) (for GitLabbers)
@@ -34,6 +33,7 @@ description: 'Learn how to contribute to GitLab.'
 ## Backend guides
 
 - [GitLab utilities](utilities.md)
+- [Issuable-like Rails models](issuable-like-models.md)
 - [Logging](logging.md)
 - [API styleguide](api_styleguide.md) Use this styleguide if you are
   contributing to the API
@@ -68,6 +68,7 @@ description: 'Learn how to contribute to GitLab.'
 - [Git LFS](lfs.md)
 - [Developing against interacting components or features](interacting_components.md)
 - [File uploads](uploads.md)
+- [Auto DevOps development guide](auto_devops.md)
 
 ## Performance guides
 
@@ -94,9 +95,11 @@ description: 'Learn how to contribute to GitLab.'
 - [What requires downtime?](what_requires_downtime.md)
 - [SQL guidelines](sql.md) for working with SQL queries
 - [Migrations style guide](migration_style_guide.md) for creating safe SQL migrations
+- [Testing Rails migrations](testing_guide/testing_migrations_guide.md) guide
 - [Post deployment migrations](post_deployment_migrations.md)
 - [Background migrations](background_migrations.md)
 - [Swapping tables](swapping_tables.md)
+- [Deleting exiting migrations](deleting_migrations.md)
 
 ### Best practices
 
@@ -116,7 +119,7 @@ description: 'Learn how to contribute to GitLab.'
 - [Database helper modules](database_helpers.md)
 - [Code comments](code_comments.md)
 
-## Case studies
+### Case studies
 
 - [Database case study: Filtering by label](filtering_by_label.md)
 - [Database case study: Namespaces storage statistics](namespaces_storage_statistics.md)
@@ -148,6 +151,10 @@ description: 'Learn how to contribute to GitLab.'
 - [Frontend tracking guide](event_tracking/frontend.md)
 - [Backend tracking guide](event_tracking/backend.md)
 
+## Experiment Guide
+
+- [Introduction](experiment_guide/index.md)
+
 ## Build guides
 
 - [Building a package for testing purposes](build_test_package.md)
@@ -164,6 +171,10 @@ description: 'Learn how to contribute to GitLab.'
 
 - [Shell scripting standards and style guidelines](shell_scripting_guide/index.md)
 
+## Other Development guides
+
+- [Defining relations between files using projections](projections.md)
+
 ## Other GitLab Development Kit (GDK) guides
 
 - [Run full Auto DevOps cycle in a GDK instance](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/auto_devops.md)
diff --git a/doc/development/adding_database_indexes.md b/doc/development/adding_database_indexes.md
index c47ce0f1182..6932858c699 100644
--- a/doc/development/adding_database_indexes.md
+++ b/doc/development/adding_database_indexes.md
@@ -108,7 +108,7 @@ This query outputs a list containing all indexes that are never used and sorts
 them by indexes sizes in descending order.  This query can be useful to
 determine if any previously indexes are useful after all. More information on
 the meaning of the various columns can be found at
-<https://www.postgresql.org/docs/current/static/monitoring-stats.html>.
+<https://www.postgresql.org/docs/current/monitoring-stats.html>.
 
 Because the output of this query relies on the actual usage of your database it
 may be affected by factors such as (but not limited to):
diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md
index c3165dc2e21..cdd0e9b2a7b 100644
--- a/doc/development/api_graphql_styleguide.md
+++ b/doc/development/api_graphql_styleguide.md
@@ -526,7 +526,7 @@ Using these helpers, we can build specs like this:
 let(:mutation) do
   graphql_mutation(
     :merge_request_set_wip,
-    project_path: 'gitlab-org/gitlab-ce',
+    project_path: 'gitlab-org/gitlab-foss',
     iid: '1',
     wip: true
   )
@@ -539,3 +539,8 @@ it 'returns a successful response' do
    expect(graphql_mutation_response(:merge_request_set_wip)['errors']).to be_empty
 end
 ```
+
+## Documentation
+
+For information on generating GraphQL documentation, see
+[Rake tasks related to GraphQL](rake_tasks.md#update-graphql-documentation).
diff --git a/doc/development/api_styleguide.md b/doc/development/api_styleguide.md
index e3c8c860062..71963ee0c0a 100644
--- a/doc/development/api_styleguide.md
+++ b/doc/development/api_styleguide.md
@@ -14,7 +14,7 @@ Always use an [Entity] to present the endpoint's payload.
 ## Methods and parameters description
 
 Every method must be described using the [Grape DSL](https://github.com/ruby-grape/grape#describing-methods)
-(see <https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/api/environments.rb>
+(see <https://gitlab.com/gitlab-org/gitlab/blob/master/lib/api/environments.rb>
 for a good example):
 
 - `desc` for the method summary. You should pass it a block for additional
@@ -104,6 +104,11 @@ For instance:
 - endpoint = expose_path(api_v4_projects_issues_related_merge_requests_path(id: @project.id, issue_iid: @issue.iid))
 ```
 
-[Entity]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/api/entities.rb
+## Internal API
+
+The [internal API](./internal_api.md) is documented for internal use. Please keep it up to date so we know what endpoints
+different components are making use of.
+
+[Entity]: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/api/entities.rb
 [validation, and coercion of the parameters]: https://github.com/ruby-grape/grape#parameter-validation-and-coercion
 [installing GitLab under a relative URL]: https://docs.gitlab.com/ee/install/relative_url.html
diff --git a/doc/development/architecture.md b/doc/development/architecture.md
index 75562f692ad..ccedb96d27d 100644
--- a/doc/development/architecture.md
+++ b/doc/development/architecture.md
@@ -1,7 +1,3 @@
----
-table_display_block: true
----
-
 # GitLab Architecture Overview
 
 ## Software delivery
@@ -16,7 +12,7 @@ Both EE and CE require some add-on components called GitLab Shell and Gitaly. Th
 
 ## Components
 
-A typical install of GitLab will be on GNU/Linux. It uses Nginx or Apache as a web front end to proxypass the Unicorn web server. By default, communication between Unicorn and the front end is via a Unix domain socket but forwarding requests via TCP is also supported. The web front end accesses `/home/git/gitlab/public` bypassing the Unicorn server to serve static pages, uploads (e.g. avatar images or attachments), and precompiled assets. GitLab serves web pages and a [GitLab API](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/doc/api) using the Unicorn web server. It uses Sidekiq as a job queue which, in turn, uses redis as a non-persistent database backend for job information, meta data, and incoming jobs.
+A typical install of GitLab will be on GNU/Linux. It uses NGINX or Apache as a web front end to proxypass the Unicorn web server. By default, communication between Unicorn and the front end is via a Unix domain socket but forwarding requests via TCP is also supported. The web front end accesses `/home/git/gitlab/public` bypassing the Unicorn server to serve static pages, uploads (e.g. avatar images or attachments), and precompiled assets. GitLab serves web pages and the [GitLab API](../api/README.md) using the Unicorn web server. It uses Sidekiq as a job queue which, in turn, uses Redis as a non-persistent database backend for job information, meta data, and incoming jobs.
 
 We also support deploying GitLab on Kubernetes using our [GitLab Helm chart](https://docs.gitlab.com/charts/).
 
@@ -24,7 +20,7 @@ The GitLab web app uses PostgreSQL for persistent database information (e.g. use
 
 When serving repositories over HTTP/HTTPS GitLab utilizes the GitLab API to resolve authorization and access as well as serving Git objects.
 
-The add-on component GitLab Shell serves repositories over SSH. It manages the SSH keys within `/home/git/.ssh/authorized_keys` which should not be manually edited. GitLab Shell accesses the bare repositories through Gitaly to serve Git objects and communicates with redis to submit jobs to Sidekiq for GitLab to process. GitLab Shell queries the GitLab API to determine authorization and access.
+The add-on component GitLab Shell serves repositories over SSH. It manages the SSH keys within `/home/git/.ssh/authorized_keys` which should not be manually edited. GitLab Shell accesses the bare repositories through Gitaly to serve Git objects and communicates with Redis to submit jobs to Sidekiq for GitLab to process. GitLab Shell queries the GitLab API to determine authorization and access.
 
 Gitaly executes Git operations from GitLab Shell and the GitLab web app, and provides an API to the GitLab web app to get attributes from Git (e.g. title, branches, tags, other meta data), and to get blobs (e.g. diffs, commits, files).
 
@@ -161,7 +157,7 @@ Component statuses are linked to configuration documentation for each component.
 | [Elasticsearch](#elasticsearch) | Improved search within GitLab | [⤓][elasticsearch-omnibus] | [⤓][elasticsearch-charts] | [⤓][elasticsearch-charts] | [❌](https://gitlab.com/groups/gitlab-org/-/epics/153) | [⤓][elasticsearch-source] | [⤓][elasticsearch-gdk] | EE Only |
 | [Sentry integration](#sentry) | Error tracking for deployed apps | [⤓][sentry-integration] | [⤓][sentry-integration] | [⤓][sentry-integration] | [⤓][sentry-integration] | [⤓][sentry-integration] | [⤓][sentry-integration] | CE & EE |
 | [Jaeger integration](#jaeger) | Distributed tracing for deployed apps | [⤓][jaeger-integration] | [⤓][jaeger-integration] | [⤓][jaeger-integration] | [⤓][jaeger-integration] | [⤓][jaeger-integration] | [⤓][jaeger-integration] | EE Only |
-| [GitLab Managed Apps](#gitlab-managed-apps) | Deploy [Helm](https://docs.helm.sh/), [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/), [Cert-Manager](https://docs.cert-manager.io/en/latest/), [Prometheus](https://prometheus.io/docs/introduction/overview/), a [Runner](https://docs.gitlab.com/runner/), [JupyterHub](http://jupyter.org/), [Knative](https://cloud.google.com/knative) to a cluster | [⤓][managed-k8s-apps] | [⤓][managed-k8s-apps] | [⤓][managed-k8s-apps] | [⤓][managed-k8s-apps] | [⤓][managed-k8s-apps] | [⤓][managed-k8s-apps] | CE & EE |
+| [GitLab Managed Apps](#gitlab-managed-apps) | Deploy [Helm](https://helm.sh/docs/), [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/), [Cert-Manager](https://docs.cert-manager.io/en/latest/), [Prometheus](https://prometheus.io/docs/introduction/overview/), a [Runner](https://docs.gitlab.com/runner/), [JupyterHub](https://jupyter.org), [Knative](https://cloud.google.com/knative/) to a cluster | [⤓][managed-k8s-apps] | [⤓][managed-k8s-apps] | [⤓][managed-k8s-apps] | [⤓][managed-k8s-apps] | [⤓][managed-k8s-apps] | [⤓][managed-k8s-apps] | CE & EE |
 
 ### Component details
 
@@ -228,7 +224,7 @@ Gitaly is a service designed by GitLab to remove our need for NFS for Git storag
 - Configuration: [Omnibus][geo-omnibus], [Charts][geo-charts], [GDK][geo-gdk]
 - Layer: Core Service (Processor)
 
-#### Gitlab Exporter
+#### GitLab Exporter
 
 - [Project page](https://gitlab.com/gitlab-org/gitlab-exporter)
 - Configuration: [Omnibus][gitlab-exporter-omnibus], [Charts][gitlab-exporter-charts]
@@ -262,7 +258,7 @@ GitLab CI is the open-source continuous integration service included with GitLab
 - Configuration: [Omnibus][shell-omnibus], [Charts][shell-charts], [Source][shell-source], [GDK][gitlab-yml]
 - Layer: Core Service (Processor)
 
-[GitLab Shell](https://gitlab.com/gitlab-org/gitlab-shell) is a program designed at GitLab to handle ssh-based `git` sessions, and modifies the list of authorized keys. GitLab Shell is not a Unix shell nor a replacement for Bash or Zsh.
+[GitLab Shell](https://gitlab.com/gitlab-org/gitlab-shell) is a program designed at GitLab to handle SSH-based `git` sessions, and modifies the list of authorized keys. GitLab Shell is not a Unix shell nor a replacement for Bash or Zsh.
 
 #### GitLab Workhorse
 
@@ -271,7 +267,7 @@ GitLab CI is the open-source continuous integration service included with GitLab
 - Layer: Core Service (Processor)
 - Process: `gitlab-workhorse`
 
-[GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse) is a program designed at GitLab to help alleviate pressure from Unicorn. You can read more about the [historical reasons for developing](https://about.gitlab.com/2016/04/12/a-brief-history-of-gitlab-workhorse/). It's designed to act as a smart reverse proxy to help speed up GitLab as a whole.
+[GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse) is a program designed at GitLab to help alleviate pressure from Unicorn. You can read more about the [historical reasons for developing](https://about.gitlab.com/blog/2016/04/12/a-brief-history-of-gitlab-workhorse/). It's designed to act as a smart reverse proxy to help speed up GitLab as a whole.
 
 #### Grafana
 
@@ -321,7 +317,7 @@ MinIO is an object storage server released under Apache License v2.0. It is comp
 - Layer: Core Service (Processor)
 - Process: `nginx`
 
-Nginx as an ingress port for all HTTP requests and routes them to the appropriate sub-systems within GitLab. We are bundling an unmodified version of the popular open source webserver.
+NGINX has an Ingress port for all HTTP requests and routes them to the appropriate sub-systems within GitLab. We are bundling an unmodified version of the popular open source webserver.
 
 #### Node Exporter
 
@@ -348,7 +344,7 @@ Lightweight connection pooler for PostgreSQL.
 
 Prometheus exporter for PgBouncer. Exports metrics at 9127/metrics.
 
-#### Postgresql
+#### PostgreSQL
 
 - [Project page](https://github.com/postgres/postgres/blob/master/README)
 - Configuration: [Omnibus][postgres-omnibus], [Charts][postgres-charts], [Source][postgres-source]
@@ -404,7 +400,7 @@ Redis is packaged to provide a place to store:
 - Layer: Core Service (Processor)
 
 The registry is what users use to store their own Docker images. The bundled
-registry uses nginx as a load balancer and GitLab as an authentication manager.
+registry uses NGINX as a load balancer and GitLab as an authentication manager.
 Whenever a client requests to pull or push an image from the registry, it will
 return a `401` response along with a header detailing where to get an
 authentication token, in this case the GitLab instance. The client will then
@@ -428,7 +424,7 @@ Sentry fundamentally is a service that helps you monitor and fix crashes in real
 - Layer: Core Service (Processor)
 - Process: `sidekiq`
 
-Sidekiq is a Ruby background job processor that pulls jobs from the redis queue and processes them. Background jobs allow GitLab to provide a faster request/response cycle by moving work into the background.
+Sidekiq is a Ruby background job processor that pulls jobs from the Redis queue and processes them. Background jobs allow GitLab to provide a faster request/response cycle by moving work into the background.
 
 #### Unicorn
 
@@ -474,9 +470,9 @@ It's important to understand the distinction as some processes are used in both
 
 When making a request to an HTTP Endpoint (think `/users/sign_in`) the request will take the following path through the GitLab Service:
 
-- nginx - Acts as our first line reverse proxy.
+- NGINX - Acts as our first line reverse proxy.
 - GitLab Workhorse - This determines if it needs to go to the Rails application or somewhere else to reduce load on Unicorn.
-- unicorn - Since this is a web request, and it needs to access the application it will go to Unicorn.
+- Unicorn - Since this is a web request, and it needs to access the application it will go to Unicorn.
 - Postgres/Gitaly/Redis - Depending on the type of request, it may hit these services to store or retrieve data.
 
 ### GitLab Git Request Cycle
@@ -512,7 +508,7 @@ ps aux | grep '^git'
 ```
 
 GitLab has several components to operate. It requires a persistent database
-(PostgreSQL) and redis database, and uses Apache httpd or Nginx to proxypass
+(PostgreSQL) and Redis database, and uses Apache httpd or NGINX to proxypass
 Unicorn. All these components should run as different system users to GitLab
 (e.g., `postgres`, `redis` and `www-data`, instead of `git`).
 
@@ -584,7 +580,7 @@ SSH:
 - `/var/log/auth.log` auth log (on Ubuntu).
 - `/var/log/secure` auth log (on RHEL).
 
-nginx:
+NGINX:
 
 - `/var/log/nginx/` contains error and access logs.
 
@@ -614,7 +610,7 @@ GitLab Shell has a configuration file at `/home/git/gitlab-shell/config.yml`.
 
 ### Maintenance Tasks
 
-[GitLab](https://gitlab.com/gitlab-org/gitlab/tree/master) provides rake tasks with which you see version information and run a quick check on your configuration to ensure it is configured properly within the application. See [maintenance rake tasks](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/doc/raketasks/maintenance.md).
+[GitLab](https://gitlab.com/gitlab-org/gitlab/tree/master) provides rake tasks with which you see version information and run a quick check on your configuration to ensure it is configured properly within the application. See [maintenance rake tasks](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/raketasks/maintenance.md).
 In a nutshell, do the following:
 
 ```
@@ -638,7 +634,7 @@ We've also detailed [our architecture of GitLab.com](https://about.gitlab.com/ha
 [unicorn-omnibus]: https://docs.gitlab.com/omnibus/settings/unicorn.html
 [unicorn-charts]: https://docs.gitlab.com/charts/charts/gitlab/unicorn/
 [unicorn-source]: ../install/installation.md#configure-it
-[gitlab-yml]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/config/gitlab.yml.example
+[gitlab-yml]: https://gitlab.com/gitlab-org/gitlab/blob/master/config/gitlab.yml.example
 [sidekiq-omnibus]: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template
 [sidekiq-charts]: https://docs.gitlab.com/charts/charts/gitlab/sidekiq/
 [gitaly-omnibus]: ../administration/gitaly/index.md
diff --git a/doc/development/auto_devops.md b/doc/development/auto_devops.md
new file mode 100644
index 00000000000..f88bcc9cfb8
--- /dev/null
+++ b/doc/development/auto_devops.md
@@ -0,0 +1,42 @@
+# Auto DevOps development guide
+
+This document provides a development guide for contributors to
+[Auto DevOps](../topics/autodevops/index.md)
+
+## Development
+
+Auto DevOps builds on top of GitLab CI to create an automatic pipeline
+based on your project contents. When Auto DevOps is enabled for a
+project, the user does not need to explicitly include any pipeline configuration
+through a [`.gitlab-ci.yml` file](../ci/yaml/README.md).
+
+In the absence of a `.gitlab-ci.yml` file, the [Auto DevOps CI
+template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)
+is used implicitly to configure the pipeline for the project. This
+template is a top-level template that includes other sub-templates,
+which then defines jobs.
+
+Some jobs use images that are built from external projects:
+
+- [Auto Build](../topics/autodevops/index.md#auto-build) uses
+  [configuration](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Build.gitlab-ci.yml)
+  in which the `build` job uses an image that is built using the
+  [`auto-build-image`](https://gitlab.com/gitlab-org/cluster-integration/auto-build-image)
+  project.
+- [Auto Deploy](../topics/autodevops/index.md#auto-deploy) uses
+  [configuration](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml)
+  in which the jobs defined in this template use an image that is built using the
+  [`auto-deploy-image`](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image)
+  project. By default, the Helm chart defined in
+  [`auto-deploy-app`](https://gitlab.com/gitlab-org/charts/auto-deploy-app)
+  is used to deploy.
+
+There are extra variables that get passed to the CI jobs when Auto
+DevOps is enabled that are not present in a normal CI job. These can be
+found in
+[`ProjectAutoDevops`](https://gitlab.com/gitlab-org/gitlab/blob/bf69484afa94e091c3e1383945f60dbe4e8681af/app/models/project_auto_devops.rb).
+
+## Development environment
+
+Configuring [GDK for Auto
+DevOps](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/auto_devops.md).
diff --git a/doc/development/automatic_ce_ee_merge.md b/doc/development/automatic_ce_ee_merge.md
deleted file mode 100644
index f7816091b49..00000000000
--- a/doc/development/automatic_ce_ee_merge.md
+++ /dev/null
@@ -1,243 +0,0 @@
-# Automatic CE->EE merge
-
-Commits pushed to CE `master` are automatically merged into EE `master` roughly
-every 5 minutes. Changes are merged using the `recursive=ours` merge strategy in
-the context of EE. This means that any merge conflicts are resolved by taking
-the EE changes and discarding the CE changes. This removes the need for
-resolving conflicts or reverting changes, at the cost of **absolutely
-requiring** EE merge requests to be created whenever a CE merge request causes
-merge conflicts.  Failing to do so can result in changes not making their way
-into EE.
-
-## Always create an EE merge request if there are conflicts
-
-In CI there is a job called `ee_compat_check`, which checks if a CE MR causes
-merge conflicts with EE. If this job reports conflicts, you **must** create an
-EE merge request. If you are an external contributor you can ask the reviewer to
-do this for you.
-
-## Always merge EE merge requests before their CE counterparts
-
-**In order to avoid conflicts in the CE->EE merge, you should always merge the
-EE version of your CE merge request first, if present.**
-
-Failing to do so will lead to CE changes being discarded when merging into EE,
-if they cause merge conflicts.
-
-## Avoiding CE->EE merge conflicts beforehand
-
-To avoid the conflicts beforehand, check out the
-[Guidelines for implementing Enterprise Edition features](ee_features.md).
-
-In any case, the CI `ee_compat_check` job will tell you if you need to open an
-EE version of your CE merge request.
-
-### Conflicts detection in CE merge requests
-
-For each commit (except on `master`), the `ee_compat_check` CI job tries to
-detect if the current branch's changes will conflict during the CE->EE merge.
-
-The job reports what files are conflicting and how to set up a merge request
-against EE.
-
-#### How the job works
-
-1. Generates the diff between your branch and current CE `master`
-1. Tries to apply it to current EE `master`
-1. If it applies cleanly, the job succeeds, otherwise...
-1. Detects a branch with the `ee-` prefix or `-ee` suffix in EE
-1. If it exists, generate the diff between this branch and current EE `master`
-1. Tries to apply it to current EE `master`
-1. If it applies cleanly, the job succeeds
-
-In the case where the job fails, it means you should create an `ee-<ce_branch>`
-or `<ce_branch>-ee` branch, push it to EE and open a merge request against EE
-`master`.
-At this point if you retry the failing job in your CE merge request, it should
-now pass.
-
-Notes:
-
-- This task is not a silver-bullet, its current goal is to bring awareness to
-  developers that their work needs to be ported to EE.
-- Community contributors shouldn't be required to submit merge requests against
-  EE, but reviewers should take actions by either creating such EE merge request
-  or asking a GitLab developer to do it **before the merge request is merged**.
-- If you branch is too far behind `master`, the job will fail. In that case you
-  should rebase your branch upon latest `master`.
-- Code reviews for merge requests often consist of multiple iterations of
-  feedback and fixes. There is no need to update your EE MR after each
-  iteration. Instead, create an EE MR as soon as you see the
-  `ee_compat_check` job failing. After you receive the final approval
-  from a Maintainer (but **before the CE MR is merged**) update the EE MR.
-  This helps to identify significant conflicts sooner, but also reduces the
-  number of times you have to resolve conflicts.
-- Please remember to
-  [always have your EE merge request merged before the CE version](#always-merge-ee-merge-requests-before-their-ce-counterparts).
-- You can use [`git rerere`](https://git-scm.com/docs/git-rerere)
-  to avoid resolving the same conflicts multiple times.
-
-### Cherry-picking from CE to EE
-
-For avoiding merge conflicts, we use a method of creating equivalent branches
-for CE and EE. If the `ee-compat-check` job fails, this process is required.
-
-This method only requires that you have cloned both CE and EE into your computer.
-If you don't have them yet, please go ahead and clone them:
-
-- Clone CE repo: `git clone git@gitlab.com:gitlab-org/gitlab-ce.git`
-- Clone EE repo: `git clone git@gitlab.com:gitlab-org/gitlab-ee.git`
-
-And the only additional setup we need is to add CE as remote of EE and vice-versa:
-
-- Open two terminal windows, one in CE, and another one in EE:
-  - In EE: `git remote add ce git@gitlab.com:gitlab-org/gitlab-ce.git`
-  - In CE: `git remote add ee git@gitlab.com:gitlab-org/gitlab-ee.git`
-
-That's all setup we need, so that we can cherry-pick a commit from CE to EE, and
-from EE to CE.
-
-Now, every time you create an MR for CE and EE:
-
-1. Open two terminal windows, one in CE, and another one in EE
-1. In the CE terminal:
-   1. Create the CE branch, e.g., `branch-example`
-   1. Make your changes and push a commit (commit A)
-   1. Create the CE merge request in GitLab
-1. In the EE terminal:
-   1. Create the EE-equivalent branch ending with `-ee`, e.g.,
-      `git checkout -b branch-example-ee`
-   1. Fetch the CE branch: `git fetch ce branch-example`
-   1. Cherry-pick the commit A: `git cherry-pick commit-A-SHA`
-   1. If Git prompts you to fix the conflicts, do a `git status`
-      to check which files contain conflicts, fix them, save the files
-   1. Add the changes with `git add .` but **DO NOT commit** them
-   1. Continue cherry-picking: `git cherry-pick --continue`
-   1. Push to EE: `git push origin branch-example-ee`
-1. Create the EE-equivalent MR and link to the CE MR from the
-   description `Ports [CE-MR-LINK] to EE`
-1. Once all the jobs are passing in both CE and EE, you've addressed the
-   feedback from your own team, and got them approved, the merge requests can be merged.
-1. When both MRs are ready, the EE merge request will be merged first, and the
-   CE-equivalent will be merged next.
-
-**Important notes:**
-
-- The commit SHA can be easily found from the GitLab UI. From a merge request,
-  open the tab **Commits** and click the copy icon to copy the commit SHA.
-- To cherry-pick a **commit range**, such as (A > B > C > D) use:
-
-  ```shell
-  git cherry-pick "oldest-commit-SHA^..newest-commit-SHA"
-  ```
-
-  For example, suppose the commit A is the oldest, and its SHA is `4f5e4018c09ed797fdf446b3752f82e46f5af502`,
-  and the commit D is the newest, and its SHA is `80e1c9e56783bd57bd7129828ec20b252ebc0538`.
-  The cherry-pick command will be:
-
-  ```shell
-  git cherry-pick "4f5e4018c09ed797fdf446b3752f82e46f5af502^..80e1c9e56783bd57bd7129828ec20b252ebc0538"
-  ```
-
-- To cherry-pick a **merge commit**, use the flag `-m 1`. For example, suppose that the
-  merge commit SHA is `138f5e2f20289bb376caffa0303adb0cac859ce1`:
-
-  ```shell
-  git cherry-pick -m 1 138f5e2f20289bb376caffa0303adb0cac859ce1
-  ```
-
-- To cherry-pick multiple commits, such as B and D in a range (A > B > C > D), use:
-
-  ```shell
-  git cherry-pick commit-B-SHA commit-D-SHA
-  ```
-
-  For example, suppose commit B SHA = `4f5e4018c09ed797fdf446b3752f82e46f5af502`,
-  and the commit D SHA = `80e1c9e56783bd57bd7129828ec20b252ebc0538`.
-  The cherry-pick command will be:
-
-  ```shell
-  git cherry-pick 4f5e4018c09ed797fdf446b3752f82e46f5af502 80e1c9e56783bd57bd7129828ec20b252ebc0538
-  ```
-
-  This case is particularly useful when you have a merge commit in a sequence of
-  commits and you want to cherry-pick all but the merge commit.
-
-- If you push more commits to the CE branch, you can safely repeat the procedure
-  to cherry-pick them to the EE-equivalent branch. You can do that as many times as
-  necessary, using the same CE and EE branches.
-- If you submitted the merge request to the CE repo and the `ee-compat-check` job passed,
-  you are not required to submit the EE-equivalent MR, but it's still recommended. If the
-  job failed, you are required to submit the EE MR so that you can fix the conflicts in EE
-  before merging your changes into CE.
-
-## How we run the Automatic CE->EE merge at GitLab
-
-At GitLab, we use the [Merge Train](https://gitlab.com/gitlab-org/merge-train)
-project to keep our [GitLab EE](https://gitlab.com/gitlab-org/gitlab)
-repository updated with commits from
-[GitLab CE](https://gitlab.com/gitlab-org/gitlab-foss).
-
-We have a mirror of the [Merge Train](https://gitlab.com/gitlab-org/merge-train)
-project [configured](https://ops.gitlab.net/gitlab-org/merge-train) to run an
-automatic CE->EE merge job every twenty minutes as a scheduled CI job.  The
-[configured](https://ops.gitlab.net/gitlab-org/merge-train) Merge Train project
-is only accessible to authorized GitLab staff.
-
-## FAQ
-
-### How does automatic merging work?
-
-The automatic merging is performed using a project called [Merge
-Train](https://gitlab.com/gitlab-org/merge-train/). This project will clone CE
-and EE master, and merge CE master into EE master using `git merge
---strategy=recursive --strategy-option=ours`. This process runs multiple times
-per hour.
-
-For more information on the exact implementation you can refer to the source
-code.
-
-### Why merge automatically?
-
-As we work towards continuous deployments and a single repository for both CE
-and EE, we need to first make sure that all CE changes make their way into EE as
-fast as possible. Past experiences and data have shown that periodic CE to EE
-merge requests do not scale, and often take a very long time to complete. For
-example, [in this
-comment](https://gitlab.com/gitlab-org/release/framework/issues/49#note_114614619)
-we determined that the average time to close an upstream merge request is around
-5 hours, with peaks up to several days. Periodic merge requests are also
-frustrating to work with, because they often include many changes unrelated to
-your own changes.
-
-To resolve these problems, we now merge changes using the `ours` strategy to
-automatically resolve merge conflicts. This removes the need for resolving
-conflicts in a periodic merge request, and allows us to merge changes from CE
-into EE much faster.
-
-### My CE merge request caused conflicts after it was merged. What do I do?
-
-If you notice this, you should set up an EE merge request that resolves these
-conflicts as **soon as possible**. Failing to do so can lead to your changes not
-being available in EE, which may break tests. This in turn would prevent us from
-being able to deploy.
-
-### Won't this setup be risky?
-
-No, not if there is an EE merge request for every CE merge request that causes
-conflicts _and_ that EE merge request is merged first. In the past we may have
-been a bit more relaxed when it comes to enforcing EE merge requests, but to
-enable automatic merging we have to start requiring such merge requests even for
-the smallest conflicts.
-
-### Some files I work with often conflict, how can I best deal with this?
-
-If you find you keep running into merge conflicts, consider refactoring the file
-so that the EE specific changes are not intertwined with CE code. For Ruby code
-you can do this by moving the EE code to a separate module, which can then be
-injected into the appropriate classes or modules. See [Guidelines for
-implementing Enterprise Edition features](ee_features.md) for more information.
-
----
-
-[Return to Development documentation](README.md)
diff --git a/doc/development/background_migrations.md b/doc/development/background_migrations.md
index 364e276b6cc..0a08360b727 100644
--- a/doc/development/background_migrations.md
+++ b/doc/development/background_migrations.md
@@ -290,7 +290,9 @@ It is required to write tests for:
 - A cleanup migration.
 
 You can use the `:migration` RSpec tag when testing the migrations.
-See [README][migrations-readme].
+See the
+[Testing Rails migrations](testing_guide/testing_migrations_guide.md#testing-a-non-activerecordmigration-class)
+style guide.
 
 When you do that, keep in mind that `before` and `after` RSpec hooks are going
 to migrate you database down and up, which can result in other background
diff --git a/doc/development/build_test_package.md b/doc/development/build_test_package.md
index 21891f70d73..f58ac79b6f4 100644
--- a/doc/development/build_test_package.md
+++ b/doc/development/build_test_package.md
@@ -9,7 +9,7 @@ that will create:
 - A deb package for Ubuntu 16.04, available as a build artifact, and
 - A docker image, which is pushed to [Omnibus GitLab's container
   registry](https://gitlab.com/gitlab-org/omnibus-gitlab/container_registry)
-  (images titled `gitlab-ce` and `gitlab-ee` respectively and image tag is the
+  (images titled `gitlab-foss` and `gitlab-ee` respectively and image tag is the
   commit which triggered the pipeline).
 
 When you push a commit to either the GitLab CE or GitLab EE project, the
diff --git a/doc/development/changelog.md b/doc/development/changelog.md
index cd09438e7c7..8ded3f393ee 100644
--- a/doc/development/changelog.md
+++ b/doc/development/changelog.md
@@ -33,8 +33,13 @@ the `author` field. GitLab team members **should not**.
 
 ## What warrants a changelog entry?
 
+- Any change that introduces a database migration **must** have a changelog entry.
 - Any user-facing change **should** have a changelog entry. Example: "GitLab now
   uses system fonts for all text."
+- Performance improvements **should** have a changelog entry.
+- _Any_ contribution from a community member, no matter how small, **may** have
+  a changelog entry regardless of these guidelines if the contributor wants one.
+  Example: "Fixed a typo on the search results page."
 - Any docs-only changes **should not** have a changelog entry.
 - Any change behind a feature flag **should not** have a changelog entry. The entry should be added [in the merge request removing the feature flags](feature_flags/development.md).
 - A fix for a regression introduced and then fixed in the same release (i.e.,
@@ -43,12 +48,6 @@ the `author` field. GitLab team members **should not**.
 - Any developer-facing change (e.g., refactoring, technical debt remediation,
   test suite changes) **should not** have a changelog entry. Example: "Reduce
   database records created during Cycle Analytics model spec."
-- _Any_ contribution from a community member, no matter how small, **may** have
-  a changelog entry regardless of these guidelines if the contributor wants one.
-  Example: "Fixed a typo on the search results page."
-- Performance improvements **should** have a changelog entry.
-- Any change that introduces a database migration **must** have a
-  changelog entry.
 
 ## Writing good changelog entries
 
@@ -80,7 +79,7 @@ changes.
 
 - **Bad:** Strip out `nil`s in the Array of Commit objects returned from
   `find_commits_by_message_with_elastic`
-- **Good:** Fix 500 errors caused by elasticsearch results referencing
+- **Good:** Fix 500 errors caused by Elasticsearch results referencing
   garbage-collected commits
 
 The first example focuses on _how_ we fixed something, not on _what_ it fixes.
diff --git a/doc/development/chatops_on_gitlabcom.md b/doc/development/chatops_on_gitlabcom.md
index 09d6638924a..8a313a120f1 100644
--- a/doc/development/chatops_on_gitlabcom.md
+++ b/doc/development/chatops_on_gitlabcom.md
@@ -13,8 +13,8 @@ tasks such as:
 
 To request access to Chatops on GitLab.com:
 
-1. Log into <https://ops.gitlab.net/users/sign_in> using the same username as for GitLab.com.
-1. Ask [anyone in the `chatops` project](https://gitlab.com/gitlab-com/chatops/-/project_members) to add you by running `/chatops run member add <username> gitlab-com/chatops --ops`.
+1. Log into <https://ops.gitlab.net/users/sign_in> **using the same username** as for GitLab.com (you may have to rename it).
+1. Ask [an owner/maintainer in the `chatops` project](https://gitlab.com/gitlab-com/chatops/-/project_members?search=&sort=access_level_desc) to add you by running `/chatops run member add <username> gitlab-com/chatops --ops`.
 
 ## See also
 
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index f616eb90bda..421b70bd2db 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -18,7 +18,7 @@ recommended to pick someone who knows the domain well. You can read more about t
 importance of involving reviewer(s) in the section on the responsibility of the author below.
 
 If you need some guidance (e.g. it's your first merge request), feel free to ask
-one of the [Merge request coaches][team].
+one of the [Merge request coaches](https://about.gitlab.com/company/team/).
 
 If you need assistance with security scans or comments, feel free to include the
 Security Team (`@gitlab-com/gl-security`) in the review.
@@ -66,13 +66,13 @@ from teams other than your own.
 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]**.
+   **approved by a [UX team member](https://about.gitlab.com/company/team/)**.
 1. If your merge request includes adding a new JavaScript library [^1], it must be
-   **approved by a [frontend lead][team]**.
+   **approved by a [frontend lead](https://about.gitlab.com/company/team/)**.
 1. If your merge request includes adding a new UI/UX paradigm [^1], it must be
-   **approved by a [UX lead][team]**.
+   **approved by a [UX lead](https://about.gitlab.com/company/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/development/enablement/distribution/#how-to-work-with-distribution) for more details.
+   **approved by a [Distribution team member](https://about.gitlab.com/company/team/)**. See how to work with the [Distribution team](https://about.gitlab.com/handbook/engineering/development/enablement/distribution/#how-to-work-with-distribution) for more details.
 
 #### Security requirements
 
@@ -172,7 +172,7 @@ required approvers.
 Maintainers must check before merging if the merge request is introducing new
 vulnerabilities, by inspecting the list in the Merge Request [Security
 Widget](../user/project/merge_requests/index.md#security-reports-ultimate).
-When in doubt, a [Security Engineer][team] can be involved. The list of detected
+When in doubt, a [Security Engineer](https://about.gitlab.com/company/team/) can be involved. The list of detected
 vulnerabilities must be either empty or containing:
 
 - dismissed vulnerabilities in case of false positives
@@ -256,18 +256,12 @@ Since [unblocking others is always a top priority](https://about.gitlab.com/hand
 reviewers are expected to review assigned merge requests in a timely manner,
 even when this may negatively impact their other tasks and priorities.
 Doing so allows everyone involved in the merge request to iterate faster as the
-context is fresh in memory, improves contributors' experiences significantly,
-and gives authors more time to address feedback and iterate on their work before
-the [feature freeze](https://gitlab.com/gitlab-org/gitlab/blob/master/PROCESS.md#feature-freeze-on-the-7th-for-the-release-on-the-22nd).
+context is fresh in memory, improves contributors' experiences significantly.
 
 A turnaround time of two working days is usually acceptable, since engineers
 will typically have other things to work on while they're waiting for review,
 but don't hesitate to ask the author if it's unclear what time frame would be
-acceptable, how urgent the review is, or how significant the blockage. Authors
-are also encouraged to provide this information up-front to reviewers, but are
-expected to be mindful of the [guidelines on when to ask for review on MRs that
-are intended to go in before the feature freeze](https://gitlab.com/gitlab-org/gitlab/blob/master/PROCESS.md#between-the-1st-and-the-7th),
-and realistic in their expectations if these were not followed.
+acceptable, how urgent the review is, or how significant the blockage.
 
 If you don't think you'll be able to review a merge request within a reasonable
 time frame, let the author know as soon as possible and try to help them find
@@ -433,7 +427,6 @@ Largely based on the [thoughtbot code review guide].
 [Return to Development documentation](README.md)
 
 [projects]: https://about.gitlab.com/handbook/engineering/projects/
-[team]: https://about.gitlab.com/team/
 [build handbook]: https://about.gitlab.com/handbook/build/handbook/build#how-to-work-with-build
 [^1]: Please note that specs other than JavaScript specs are considered backend code.
 [^2]: We encourage you to seek guidance from a database maintainer if your merge request is potentially introducing expensive queries. It is most efficient to comment on the line of code in question with the SQL queries so they can give their advice.
diff --git a/doc/development/contributing/design.md b/doc/development/contributing/design.md
index 79750878aac..9796e195f86 100644
--- a/doc/development/contributing/design.md
+++ b/doc/development/contributing/design.md
@@ -5,7 +5,7 @@ For guidance on UX implementation at GitLab, please refer to our [Design System]
 The UX team uses labels to manage their workflow.
 
 The  ~"UX" label on an issue is a signal to the UX team that it will need UX attention.
-To better understand the priority by which UX tackles issues, see the [UX section](https://about.gitlab.com/handbook/engineering/ux) of the handbook.
+To better understand the priority by which UX tackles issues, see the [UX section](https://about.gitlab.com/handbook/engineering/ux/) of the handbook.
 
 Once an issue has been worked on and is ready for development, a UXer removes the ~"UX" label and applies the ~"UX ready" label to that issue.
 
diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md
index 694f8d2cb45..92dd040a2bd 100644
--- a/doc/development/contributing/index.md
+++ b/doc/development/contributing/index.md
@@ -15,7 +15,7 @@ abbreviation.
 
 To get an overview of GitLab community membership including those that would be reviewing or merging your contributions, please visit [the community roles page](community_roles.md).
 
-If you want to know how the GitLab [core team]
+If you want to know how the GitLab [core team](https://about.gitlab.com/community/core-team/)
 operates please see [the GitLab contributing process](https://gitlab.com/gitlab-org/gitlab/blob/master/PROCESS.md).
 
 [GitLab Inc engineers should refer to the engineering workflow document](https://about.gitlab.com/handbook/engineering/workflow/)
@@ -24,7 +24,7 @@ operates please see [the GitLab contributing process](https://gitlab.com/gitlab-
 
 Please report suspected security vulnerabilities in private to
 `support@gitlab.com`, also see the
-[disclosure section on the GitLab.com website](https://about.gitlab.com/disclosure/).
+[disclosure section on the GitLab.com website](https://about.gitlab.com/security/disclosure/).
 Please do **NOT** create publicly viewable issues for suspected security
 vulnerabilities.
 
@@ -48,7 +48,7 @@ for audiences of all ages.
 
 If a contributor is no longer actively working on a submitted merge request
 we can decide that the merge request will be finished by one of our
-[Merge request coaches][team] or close the merge request. We make this decision
+[Merge request coaches](https://about.gitlab.com/company/team/) or close the merge request. We make this decision
 based on how important the change is for our product vision. If a merge request
 coach is going to finish the merge request we assign the
 ~"coach will finish" label. When a team member picks up a community contribution,
@@ -59,18 +59,17 @@ within the MR.
 ## Helping others
 
 Please help other GitLab users when you can.
-The methods people will use to seek help can be found on the [getting help page][getting-help].
+The methods people will use to seek help can be found on the [getting help page](https://about.gitlab.com/get-help/).
 
 Sign up for the mailing list, answer GitLab questions on StackOverflow or
-respond in the IRC channel. You can also sign up on [CodeTriage][codetriage] to help with
-the remaining issues on the GitHub issue tracker.
+respond in the IRC channel.
 
 ## I want to contribute
 
 If you want to contribute to GitLab,
 [issues with the `Accepting merge requests` label](issue_workflow.md#label-for-community-contributors)
 are a great place to start.
-If you have any questions or need help visit [Getting Help](https://about.gitlab.com/getting-help/#discussion) to
+If you have any questions or need help visit [Getting Help](https://about.gitlab.com/get-help/) to
 learn how to communicate with GitLab. If you're looking for a Gitter or Slack channel
 please consider we favor
 [asynchronous communication](https://about.gitlab.com/handbook/communication/#internal-communication) over real time communication. Thanks for your contribution!
@@ -85,7 +84,7 @@ When maintainers are reading through a merge request they may request guidance f
 
 Sometimes style guides will be followed but the code will lack structural integrity, or the maintainer will have reservations about the code’s overall quality. When there is a reservation the maintainer will inform the author and provide some guidance.  The author may then choose to update the merge request. Once the merge request has been updated and reassigned to the maintainer, they will review the code again. Once the code has been resubmitted any number of times, the maintainer may choose to close the merge request with a summary of why it will not be merged, as well as some guidance. If the merge request is closed the maintainer will be open to discussion as to how to improve the code so it can be approved in the future.
 
-GitLab will do its best to review community contributions as quickly as possible. Specially appointed developers review community contributions daily. You may take a look at the [team page](https://about.gitlab.com/team/) for the merge request coach who specializes in the type of code you have written and mention them in the merge request.  For example, if you have written some JavaScript in your code then you should mention the frontend merge request coach. If your code has multiple disciplines you may mention multiple merge request coaches.
+GitLab will do its best to review community contributions as quickly as possible. Specially appointed developers review community contributions daily. You may take a look at the [team page](https://about.gitlab.com/company/team/) for the merge request coach who specializes in the type of code you have written and mention them in the merge request.  For example, if you have written some JavaScript in your code then you should mention the frontend merge request coach. If your code has multiple disciplines you may mention multiple merge request coaches.
 
 GitLab receives a lot of community contributions, so if your code has not been reviewed within two days (excluding weekend and public holidays) of its initial submission feel free to re-mention the appropriate merge request coach.
 
@@ -122,8 +121,3 @@ This [documentation](style_guides.md) outlines the current style guidelines.
 ---
 
 [Return to Development documentation](../README.md)
-
-[core team]: https://about.gitlab.com/core-team/
-[team]: https://about.gitlab.com/company/team/
-[getting-help]: https://about.gitlab.com/getting-help/
-[codetriage]: http://www.codetriage.com/gitlabhq/gitlabhq
diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md
index 810d03e82c5..349bb371835 100644
--- a/doc/development/contributing/issue_workflow.md
+++ b/doc/development/contributing/issue_workflow.md
@@ -22,14 +22,15 @@ once every quarter.
 The most important thing is making sure valid issues receive feedback from the
 development team. Therefore the priority is mentioning developers that can help
 on those issues. Please select someone with relevant experience from the
-[GitLab team](https://about.gitlab.com/team/).
+[GitLab team](https://about.gitlab.com/company/team/).
 If there is nobody mentioned with that expertise look in the commit history for
 the affected files to find someone.
 
-We also use [GitLab Triage](https://gitlab.com/gitlab-org/gitlab-triage) to
-automate some triaging policies. This is currently set up as a
-[scheduled pipeline](https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/10512/edit)
-running on [quality/triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops) project.
+We also use [GitLab Triage](https://gitlab.com/gitlab-org/gitlab-triage) to automate
+some triaging policies. This is currently set up as a scheduled pipeline
+(`https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/10512/editpipeline_schedules/10512/edit`,
+must have at least developer access to the project) running on [quality/triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops)
+project.
 
 ## Labels
 
@@ -45,8 +46,8 @@ Most issues will have labels for at least one of the following:
 - Category: ~"Category:Code Analytics", ~"Category:DevOps Score", ~"Category:Templates", etc.
 - Feature: ~wiki, ~ldap, ~api, ~issues, ~"merge requests", etc.
 - Department: ~UX, ~Quality
-- Team: ~Documentation, ~Delivery
-- Specialization: ~frontend, ~backend
+- Team: ~"Technical Writing", ~Delivery
+- Specialization: ~frontend, ~backend, ~documentation
 - Release Scoping: ~Deliverable, ~Stretch, ~"Next Patch Release"
 - Priority: ~P1, ~P2, ~P3, ~P4
 - Severity: ~S1, ~S2, ~S3, ~S4
@@ -96,6 +97,7 @@ Following is a non-exhaustive list of facet labels:
 - ~security: A security issue could describe a ~bug or a ~feature.
 - ~database: A database issue could describe a ~bug or a ~feature.
 - ~customer: This relates to an issue that was created by a customer, or that is of interest for a customer.
+- ~"UI text": Issues that add or modify any text within the UI such as user-assistance microcopy, button/menu labels, or error messages.
 
 ### Stage labels
 
@@ -148,10 +150,15 @@ You can find the groups listed in the [Product Stages, Groups, and Categories](h
 We use the term group to map down product requirements from our product stages.
 As a team needs some way to collect the work their members are planning to be assigned to, we use the `~group::` labels to do so.
 
-Normally there is a 1:1 relationship between Stage labels and Group labels. In the spirit of "Everyone can contribute",
-any issue can be picked up by any group, depending on current priorities. For example, an issue labeled ~"devops::create" may be picked up by the ~"group::access" group.
+Normally there is a 1:1 relationship between Stage labels and Group labels. In
+the spirit of "Everyone can contribute", any issue can be picked up by any group,
+depending on current priorities. When picking up an issue belonging to a different
+group, it should be relabelled. For example, if an issue labelled ~"devops::create"
+and ~"group::knowledge" is picked up by someone in the Access group of the Plan stage,
+the issue should be relabelled as ~"group::access" while keeping the original
+~"devops::create" unchanged.
 
-We also use stage and group labels to help quantify our [throughput](https://about.gitlab.com/handbook/engineering/management/throughput).
+We also use stage and group labels to help quantify our [throughput](https://about.gitlab.com/handbook/engineering/management/throughput/).
 Please read [Stage and Group labels in Throughtput](https://about.gitlab.com/handbook/engineering/management/throughput/#stage-and-group-labels-in-throughput) for more information on how the labels are used in this context.
 
 ### Category labels
@@ -228,7 +235,7 @@ people.
 The current team labels are:
 
 - ~Delivery
-- ~Documentation
+- ~"Technical Writing"
 
 #### Naming and color convention
 
@@ -241,6 +248,7 @@ These labels narrow the [specialization](https://about.gitlab.com/company/team/s
 
 - ~frontend
 - ~backend
+- ~documentation
 
 ### Release scoping labels
 
@@ -334,7 +342,7 @@ know how difficult the issue is. Additionally:
 
 - We advertise [`Accepting merge requests` issues with weight < 5](https://gitlab.com/groups/gitlab-org/-/issues?state=opened&label_name[]=Accepting+merge+requests&assignee_id=None&sort=weight)
   as suitable for people that have never contributed to GitLab before on the
-  [Up For Grabs campaign](http://up-for-grabs.net)
+  [Up For Grabs campaign](https://up-for-grabs.net/#/)
 - We encourage people that have never contributed to any open source project to
   look for [`Accepting merge requests` issues with a weight of 1](https://gitlab.com/groups/gitlab-org/-/issues?state=opened&label_name[]=Accepting+merge+requests&assignee_id=None&sort=weight&weight=1)
 
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index 1931dda7151..86f17f4ecdb 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -89,7 +89,7 @@ request is as follows:
 1. Write tests for more complex migrations.
 1. Merge requests **must** adhere to the [merge request performance guidelines](../merge_request_performance_guidelines.md).
 1. For tests that use Capybara, read
-   [how to write reliable, asynchronous integration tests](https://robots.thoughtbot.com/write-reliable-asynchronous-integration-tests-with-capybara).
+   [how to write reliable, asynchronous integration tests](https://thoughtbot.com/blog/write-reliable-asynchronous-integration-tests-with-capybara).
 1. If your merge request introduces changes that require additional steps when
    installing GitLab from source, add them to `doc/install/installation.md` in
    the same merge request.
@@ -101,7 +101,7 @@ request is as follows:
 
 If you would like quick feedback on your merge request feel free to mention someone
 from the [core team](https://about.gitlab.com/community/core-team/) or one of the
-[merge request coaches](https://about.gitlab.com/team/). When having your code reviewed
+[merge request coaches](https://about.gitlab.com/company/team/). When having your code reviewed
 and when reviewing merge requests, please keep the [code review guidelines](../code_review.md)
 in mind. And if your code also makes changes to the database, or does expensive queries,
 check the [database review guidelines](../database_review.md).
@@ -140,7 +140,7 @@ When writing commit messages, please follow the guidelines below:
 - The merge request must not contain more than 10 commit messages.
 
 If the guidelines are not met, the MR will not pass the
-[Danger checks](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/danger/commit_messages/Dangerfile).
+[Danger checks](https://gitlab.com/gitlab-org/gitlab/blob/master/danger/commit_messages/Dangerfile).
 For more information see [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/).
 
 Example commit message template that can be used on your machine that embodies the above (guide for [how to apply template](https://codeinthehole.com/tips/a-useful-template-for-commit-messages/)):
@@ -220,6 +220,8 @@ requirements.
 1. Working and clean code that is commented where needed.
 1. [Unit, integration, and system tests](../testing_guide/index.md) that all pass
    on the CI server.
+1. Regressions and bugs are covered with tests that reduce the risk of the issue happening
+   again.
 1. Performance/scalability implications have been considered, addressed, and tested.
 1. [Documented](../documentation/index.md) in the `/doc` directory.
 1. [Changelog entry added](../changelog.md), if necessary.
@@ -244,5 +246,5 @@ request:
 1. [The upgrade guide](../../update/upgrading_from_source.md).
 1. The [GitLab Installation Guide](../../install/installation.md#1-packages-and-dependencies).
 1. The [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit).
-1. The [CI environment preparation](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/scripts/prepare_build.sh).
+1. The [CI environment preparation](https://gitlab.com/gitlab-org/gitlab/blob/master/scripts/prepare_build.sh).
 1. The [Omnibus package creator](https://gitlab.com/gitlab-org/omnibus-gitlab).
diff --git a/doc/development/dangerbot.md b/doc/development/dangerbot.md
index a6650a50878..0b2e2b43512 100644
--- a/doc/development/dangerbot.md
+++ b/doc/development/dangerbot.md
@@ -15,7 +15,7 @@ to the existing rules, then this is the document for you.
 
 ## Operation
 
-On startup, Danger reads a [`Dangerfile`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/Dangerfile)
+On startup, Danger reads a [`Dangerfile`](https://gitlab.com/gitlab-org/gitlab/blob/master/Dangerfile)
 from the project root. GitLab's Danger code is decomposed into a set of helpers
 and plugins, all within the [`danger/`](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/danger/)
 subdirectory, so ours just tells Danger to load it all. Danger will then run
diff --git a/doc/development/database_debugging.md b/doc/development/database_debugging.md
index 6c9fa983c96..9947f9c16c0 100644
--- a/doc/development/database_debugging.md
+++ b/doc/development/database_debugging.md
@@ -3,7 +3,7 @@
 This section is to help give some copy-pasta you can use as a reference when you
 run into some head-banging database problems.
 
-An easy first step is to search for your error in Slack or google "GitLab (my error)".
+An easy first step is to search for your error in Slack, or search for `GitLab <my error>` with Google.
 
 ---
 
diff --git a/doc/development/database_review.md b/doc/development/database_review.md
index 57cdc2135aa..39236ab1910 100644
--- a/doc/development/database_review.md
+++ b/doc/development/database_review.md
@@ -78,7 +78,8 @@ and details for a database reviewer:
 - Format any queries with a SQL query formatter, for example with [sqlformat.darold.net](http://sqlformat.darold.net).
 - Consider providing query plans via a link to [explain.depesz.com](https://explain.depesz.com) or another tool instead of textual form.
 - For query changes, it is best to provide the SQL query along with a plan *before* and *after* the change. This helps to spot differences quickly.
-- When providing query plans, make sure to use good parameter values, so that the query executed is a good example and also hits enough data. Usually, the `gitlab-org` namespace (`namespace_id = 9970`) and the `gitlab-org/gitlab-ce` project (`project_id = 13083`) provides enough data to serve as a good example.
+- When providing query plans, make sure to use good parameter values, so that the query executed is a good example and also hits enough data.
+  - Usually, the `gitlab-org` namespace (`namespace_id = 9970`) and the `gitlab-org/gitlab-foss` (`project_id = 13083`) or the `gitlab-org/gitlab` (`project_id = 278964`) projects provide enough data to serve as a good example.
 
 ### How to review for database
 
@@ -94,17 +95,22 @@ and details for a database reviewer:
   - Check queries timing (If any): Queries executed in a migration
     need to fit comfortably within `15s` - preferably much less than that - on GitLab.com.
 - Check [background migrations](background_migrations.md):
-  - For data migrations, establish a time estimate for execution
+  - Establish a time estimate for execution on GitLab.com.
   - They should only be used when migrating data in larger tables.
     - If a single `update` is below than `1s` the query can be placed
       directly in a regular migration (inside `db/migrate`).
   - Review queries (for example, make sure batch sizes are fine)
-  - Establish a time estimate for execution
   - Because execution time can be longer than for a regular migration,
     it's suggested to treat background migrations as post migrations:
     place them in `db/post_migrate` instead of `db/migrate`. Keep in mind
     that post migrations are executed post-deployment in production.
 - Check [timing guidelines for migrations](#timing-guidelines-for-migrations)
+- Check migrations are reversible and implement a `#down` method
+- Check data migrations:
+  - Establish a time estimate for execution on GitLab.com.
+  - Depending on timing, data migrations can be placed on regular, post-deploy or background migrations.
+  - Data migrations should be reversible too or come with a description of how to reverse, when possible.
+    This applies to all types of migrations (regular, post-deploy, background).
 - Query performance
   - Check for any obviously complex queries and queries the author specifically
     points out for review (if any)
@@ -120,7 +126,7 @@ and details for a database reviewer:
     pipeline](https://ops.gitlab.net/gitlab-com/gl-infra/gitlab-restore/postgres-gprd)
     in order to establish a proper testing environment.
 
-### Timing guidelines for migrations
+### Timing guidelines for migrations
 
 In general, migrations for a single deploy shouldn't take longer than
 1 hour for GitLab.com. The following guidelines are not hard rules, they were
diff --git a/doc/development/deleting_migrations.md b/doc/development/deleting_migrations.md
new file mode 100644
index 00000000000..438e8c9f5e9
--- /dev/null
+++ b/doc/development/deleting_migrations.md
@@ -0,0 +1,33 @@
+# Delete existing migrations
+
+When removing existing migrations from the GitLab project, you have to take into account
+the possibility of the migration already been included in past releases or in the current release, and thus already executed on GitLab.com and/or in self-hosted instances.
+
+Because of it, it's not possible to delete existing migrations, as that could lead to:
+
+- Schema inconsistency, as changes introduced into the database were not rollbacked properly.
+- Leaving a record on the `schema_versions` table, that points out to migration that no longer exists on the codebase.
+
+Instead of deleting we can opt for disabling the migration.
+
+## Pre-requisites to disable a migration
+
+Migrations can be disabled if:
+
+- They caused a timeout or general issue on GitLab.com.
+- They are obsoleted, e.g. changes are not necessary due to a feature change.
+- Migration is a data migration only, i.e. the migration does not change the database schema.
+
+## How to disable a data migration?
+
+In order to disable a migration, the following steps apply to all types of migrations:
+
+1. Turn the migration into a noop by removing the code inside `#up`, `#down`
+  or `#perform` methods, and adding `#no-op` comment instead.
+1. Add a comment explaining why the code is gone.
+
+Disabling migrations requires explicit approval of Database Maintainer.
+
+## Examples
+
+- [Disable scheduling of productivity analytics](https://gitlab.com/gitlab-org/gitlab/merge_requests/17253)
diff --git a/doc/development/documentation/feature-change-workflow.md b/doc/development/documentation/feature-change-workflow.md
index 4512b0fc987..004d8833e63 100644
--- a/doc/development/documentation/feature-change-workflow.md
+++ b/doc/development/documentation/feature-change-workflow.md
@@ -1,178 +1,5 @@
 ---
-description: How to add docs for new or enhanced GitLab features.
+redirect_to: 'workflow.md'
 ---
 
-# Documentation process for feature changes
-
-At GitLab, developers contribute new or updated documentation along with their code, but product managers and technical writers also have essential roles in the process.
-
-- **Developers**: Author/update documentation in the same MR as their code, and
-  merge it by the feature freeze for the assigned milestone. Request technical writer
-  assistance if needed. Other developers typically act as reviewers.
-- **Product Managers** (PMs): In the issue for all new and enhanced features,
-  confirm the documentation requirements, plus the mentioned feature description
-  and use cases, which can be reused in docs. They can bring in a technical
-  writer for discussion or collaboration, and can be called upon themselves as a doc reviewer.
-- **Technical Writers**: Review doc requirements in issues, track issues and MRs
-  that contain docs changes, help with any questions throughout the authoring/editing process,
-  work on special projects related to the documentation, and review all new and updated
-  docs content, whether before or after it is merged.
-
-Beyond this process, any member of the GitLab community can also author or request documentation
-improvements that are not associated with a new or changed feature. See the [Documentation improvement workflow](improvement-workflow.md).
-
-## When documentation is required
-
-Documentation must be delivered whenever:
-
-- A new or enhanced feature is shipped that impacts the user/admin experience.
-- There are changes to the UI or API.
-- A process, workflow, or previously documented feature is changed.
-- A feature is deprecated or removed.
-
-For example, a UI restyling that offers no difference in functionality may require
-documentation updates if screenshots are now needed, or need to be updated.
-
-Documentation is not required when a feature is changed on the backend
-only and does not directly affect the way that any user or administrator would
-interact with GitLab.
-
-NOTE: **Note:**
-When revamping documentation, if unrelated to the feature change, this should be submitted
-in its own MR (using the [documentation improvement workflow](improvement-workflow.md))
-so that we can ensure the more time-sensitive doc updates are merged with code by the freeze.
-
-## Documentation requirements in feature issues
-
-Requirements for the documentation of a feature should be included as part of the
-issue for planning that feature, in a Documentation section within the issue description.
-
-This section is provided as part of the Feature Proposal template and should be added
-to the issue if it is not already present.
-
-Anyone can add these details, but the product manager who assigns the issue to a specific release
-milestone will ensure these details are present and finalized by the time of that milestone's kickoff.
-Developers, technical writers, and others may help further refine this plan at any time.
-
-### Details to include
-
-- What concepts and procedures should the docs guide and enable the user to understand or accomplish?
-- To this end, what new page(s) are needed, if any? What pages/subsections need updates? Consider user, admin, and API doc changes and additions.
-- For any guide or instruction set, should it help address a single use case, or be flexible to address a certain range of use cases?
-- Do we need to update a previously recommended workflow? Should we link the new feature from various relevant locations? Consider all ways documentation should be affected.
-- Are there any key terms or task descriptions that should be included so that the docs are found in relevant searches?
-- Include suggested titles of any pages or subsections, if applicable.
-
-## Documenting a new or changed feature
-
-To follow a consistent workflow every month, documentation changes
-involve the Product Managers, the developer who shipped the feature,
-and the technical writer for the DevOps stage. Each role is described below.
-
-The Documentation items in the GitLab CE/EE [Feature Proposal issue template](https://gitlab.com/gitlab-org/gitlab/raw/master/.gitlab/issue_templates/Feature%20proposal.md)
-and default merge request template will assist you with following this process.
-
-### Product Manager role
-
-For issues requiring any new or updated documentation, the Product Manager (PM)
-must:
-
-- Add the `Documentation` label.
-- Confirm or add the [documentation requirements](#documentation-requirements-in-feature-issues).
-- Ensure the issue contains any new or updated feature name, overview/description,
-  and use cases, as required per the [documentation structure and template](structure.md), when applicable.
-
-Everyone is encouraged to draft the requirements in the issue, but a product manager will
-do the following:
-
-- When the issue is assigned a release milestone, review and update the Documentation details.
-- By the kickoff, finalize the Documentation details.
-
-### Developer and maintainer roles
-
-#### Authoring
-
-As a developer, if a ~feature issue also contains the ~Documentation label, you must ship the new or updated documentation with the code of the feature. The documentation is an essential part of the product.
-Technical writers are happy to help, as requested and planned on an issue-by-issue basis.
-
-For feature issues requiring documentation, follow the process below unless otherwise agreed with the product manager and technical writer for a given issue:
-
-- Include any new and edited docs in the MR introducing the code.
-- Use the Documentation requirements confirmed by the Product Manager in the
-  issue and discuss any further doc plans or ideas as needed.
-  - If the new or changed doc requires extensive collaboration or conversation, a separate,
-  linked issue can be used for the planning process.
-  - We are trying to avoid using a separate MR, so that the docs stay with the code, but the
-  Technical Writing team is interested in discussing any potential exceptions that may be suggested.
-- Use the [Documentation guidelines](index.md), as well as other resources linked from there,
-  including the Documentation [Structure and template](structure.md) page, [Style Guide](styleguide.md), and [Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/).
-- If you need any help to choose the correct place for a doc, discuss a documentation
-  idea or outline, or request any other help, ping the Technical Writer for the relevant
-  [DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages)
-  in your issue or MR, or write within `#docs` on the GitLab Slack.
-- If you are working on documentation in a separate MR, ensure that if the code is merged by the 17th, the docs are as well, per the [Engineering Workflow](https://about.gitlab.com/handbook/engineering/workflow/). If the docs are not ready, the PM can approve merging the code if the engineer and tech writer commit to get documentation merged by the 21st. Otherwise the feature is not considered complete, and should not be merged.
-- A policy for documenting feature-flagged
-  issues is forthcoming and you are welcome to join the [discussion](https://gitlab.com/gitlab-org/gitlab-foss/issues/56813).
-
-#### Reviews and merging
-
-All reviewers can help ensure accuracy, clarity, completeness, and adherence to the plans in the issue, as well as the [Documentation Guidelines](index.md) and [Style Guide](styleguide.md).
-
-- **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-foss/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-foss/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.
-  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
-
-#### Planning
-
-- The technical writer monitors the documentation needs of issues assigned to the current and next milestone
-  for their DevOps stage(s), and participates in any needed discussion on docs planning and requirements refinement
-  with the dev, PM, and others.
-- The technical writer will review these requirements again upon the kickoff and provide feedback, as needed.
-  This is not a blocking review and developers should not wait to work on docs.
-
-#### Collaboration
-
-By default, the developer will work on documentation changes independently, but
-the developer, PM, or technical writer can propose a broader collaboration for
-any given issue.
-
-Additionally, technical writers are available for questions at any time.
-
-#### Review
-
-- Technical writers provide non-blocking reviews of all documentation changes,
-  before or after the change is merged. However, if the docs are ready in the MR while
-  there's time before the freeze, the technical writer's review can commence early, on request.
-- The technical writer will confirm that the doc is clear, grammatically correct,
-  and discoverable, while avoiding redundancy, bad file locations, typos, broken links,
-  etc. The technical writer will review the documentation for the following, which
-  the developer and code reviewer should have already made a good-faith effort to ensure:
-  - Clarity.
-  - Adherence to the plans and goals in the issue.
-  - Location (make sure the docs are in the correct directories and has the correct name).
-  - Syntax, typos, and broken links.
-  - Improvements to the content.
-  - Accordance with the [Documentation Style Guide](styleguide.md), and [Structure and Template](structure.md) doc.
+This document was moved to [another location](workflow.md).
diff --git a/doc/development/documentation/improvement-workflow.md b/doc/development/documentation/improvement-workflow.md
index 9f3b789712f..004d8833e63 100644
--- a/doc/development/documentation/improvement-workflow.md
+++ b/doc/development/documentation/improvement-workflow.md
@@ -1,63 +1,5 @@
 ---
-description: How to improve GitLab's documentation.
+redirect_to: 'workflow.md'
 ---
 
-# Documentation improvement workflow
-
-Anyone can contribute a merge request or create an issue for GitLab's documentation.
-
-This page covers the process for any contributions to GitLab's docs that are
-not part of feature development. If you are looking for information on updating
-GitLab's docs as is required with the development and release of a new feature
-or feature enhancement, see the [documentation process for feature changes](feature-change-workflow.md).
-
-## Who updates the docs
-
-Anyone can contribute! You can create a merge request with documentation
-when you find errors or other room for improvement in an existing doc, or when you
-have an idea for all-new documentation that would help a GitLab user or administrator
-to accomplish their work with GitLab.
-
-## How to update the docs
-
-1. Click "Edit this Page" at the bottom of any page on docs.gitlab.com, or navigate to
-   one of the repositories and doc paths listed on the [GitLab Documentation guidelines](index.md) page.
-   Work in a fork if you do not have developer access to the GitLab project.
-1. Follow the described standards and processes listed on that Guidelines page,
-   including the linked resources: the [Structure and template](structure.md) page, [Style Guide](styleguide.md), and [Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/).
-1. Follow GitLab's [Merge Request Guidelines](../contributing/merge_request_workflow.md#merge-request-guidelines).
-
-If you need any help to choose the correct place for a doc, discuss a documentation
-idea or outline, or request any other help, ping the Technical Writer for the relevant
-[DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages)
-in your issue or MR, or write within `#docs` if you are a member of GitLab's Slack workspace.
-
-## Review and merging
-
-Anyone with master access to the affected GitLab project can merge documentation changes.
-This person must make a good-faith effort to ensure that the content is clear
-(sufficiently easy for the intended audience to navigate and understand) and
-that it meets the [Documentation Guidelines](index.md) and [Style Guide](styleguide.md).
-
-If the author or reviewer has any questions, or would like a techncial writer's review
-before merging, mention the writer who is assigned to the relevant [DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages).
-
-The process can involve the following parties/phases, and is replicated in the `Documentation` MR template for GitLab CE and EE, to help with following the process.
-
-**1. Primary Reviewer** - Review by a [code reviewer](https://about.gitlab.com/handbook/engineering/projects/) or other appropriate colleague to confirm accuracy, clarity, and completeness. This can be skipped for minor fixes without substantive content changes.
-
-**2. Technical Writer** - Optional - If not requested for this MR, must be scheduled post-merge. To request a pre-merge review, assign the writer listed for the applicable [DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages).
-To request a post-merge review, [create an issue for one using the Doc Review template](https://gitlab.com/gitlab-org/gitlab-foss/issues/new?issuable_template=Doc%20Review) and link it from the MR that makes the doc change.
-
-**3. Maintainer**
-
-1. Review by assigned maintainer, who can always request/require the above reviews. Maintainer review can occur before or after a technical writer review.
-1. Ensure a release milestone of the format XX.Y is set. If the freeze for that release has begun, add the label `pick into <XX.Y>` unless this change is not required for the release. In that case, simply change the milestone.
-1. If EE and CE MRs exist, merge the EE MR first, then the CE MR.
-1. After merging, if there has not been a technical writer review and an issue for a follow-up review was not already created and linked from the MR, [create the issue using the Doc Review template](https://gitlab.com/gitlab-org/gitlab-foss/issues/new?issuable_template=Doc%20Review) and link it from the MR.
-
-## Other ways to help
-
-If you have ideas for further documentation resources that would be best
-considered/handled by technical writers, devs, and other SMEs, please [create an issue](https://gitlab.com/gitlab-org/gitlab-foss/issues/new?issuable_template=Documentation)
-using the Documentation template.
+This document was moved to [another location](workflow.md).
diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md
index 4ad24d08d17..fb0aa5130f8 100644
--- a/doc/development/documentation/index.md
+++ b/doc/development/documentation/index.md
@@ -8,19 +8,16 @@ GitLab's documentation is [intended as the single source of truth (SSOT)](https:
 
 In addition to this page, the following resources can help you craft and contribute documentation:
 
-- [Style Guide](styleguide.md) - What belongs in the docs, language guidelines, and more.
+- [Style Guide](styleguide.md) - What belongs in the docs, language guidelines, Markdown standards to follow, and more.
 - [Structure and template](structure.md) - Learn the typical parts of a doc page and how to write each one.
-- [Workflows](workflow.md) - A landing page for our key workflows:
-  - [Documentation process for feature changes](feature-change-workflow.md) - Adding required documentation when developing a GitLab feature.
-  - [Documentation improvement workflow](improvement-workflow.md) - New content not associated with a new feature.
-- [Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/) - A reference for the markdown implementation used by GitLab's documentation site and about.gitlab.com.
-- [Site architecture](site_architecture/index.md) - How docs.gitlab.com is built.
+- [Documentation process](workflow.md).
+- [Markdown Guide](../../user/markdown.md) - A reference for all Markdown syntax supported by GitLab.
+- [Site architecture](site_architecture/index.md) - How <https://docs.gitlab.com> is built.
 
 ## Source files and rendered web locations
 
-Documentation for GitLab, GitLab Runner, and Omnibus is published to [docs.gitlab.com](https://docs.gitlab.com). Documentation for GitLab is also published within the application at `/help` on the domain of the GitLab instance.
-
-At `/help`, only help for your current edition and version is included. Help for other versions is available at docs.gitlab.com.
+Documentation for GitLab, GitLab Runner, Omnibus GitLab and Charts are published to <https://docs.gitlab.com>. Documentation for GitLab is also published within the application at `/help` on the domain of the GitLab instance.
+At `/help`, only help for your current edition and version is included. Help for other versions is available at <https://docs.gitlab.com/archives/>.
 
 The source of the documentation exists within the codebase of each GitLab application in the following repository locations:
 
@@ -29,6 +26,7 @@ The source of the documentation exists within the codebase of each GitLab applic
 | [GitLab](https://gitlab.com/gitlab-org/gitlab/) | [`/doc`](https://gitlab.com/gitlab-org/gitlab/tree/master/doc) |
 | [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/) | [`/docs`](https://gitlab.com/gitlab-org/gitlab-runner/tree/master/docs) |
 | [Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/) | [`/doc`](https://gitlab.com/gitlab-org/gitlab/tree/master/doc) |
+| [Charts](https://gitlab.com/gitlab-org/charts/gitlab) | [`/doc`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/doc) |
 
 Documentation issues and merge requests are part of their respective repositories and all have the label `Documentation`.
 
@@ -55,8 +53,8 @@ See the [Structure](styleguide.md#structure) section of the [Documentation Style
 
 Changing a document's location requires specific steps to ensure that
 users can seamlessly access the new doc page, whether they are accessing content
-on a GitLab instance domain at `/help` or at docs.gitlab.com. Be sure to ping a
-GitLab technical writer if you have any questions during the process (such as
+on a GitLab instance domain at `/help` or at <https://docs.gitlab.com>. Be sure to assign a
+technical writer if you have any questions during the process (such as
 whether the move is necessary), and ensure that a technical writer reviews this
 change prior to merging.
 
@@ -132,7 +130,7 @@ land on the doc via `/help`.
 If the documentation page being relocated already has Disqus comments,
 we need to preserve the Disqus thread.
 
-Disqus uses an identifier per page, and for docs.gitlab.com, the page identifier
+Disqus uses an identifier per page, and for <https://docs.gitlab.com>, the page identifier
 is configured to be the page URL. Therefore, when we change the document location,
 we need to preserve the old URL as the same Disqus identifier.
 
@@ -181,9 +179,9 @@ Every GitLab instance includes the documentation, which is available at `/help`
 (`https://gitlab.example.com/help`). For example, <https://gitlab.com/help>.
 
 There are [plans](https://gitlab.com/groups/gitlab-org/-/epics/693) to end this
-practice and instead link out from the GitLab application to docs.gitlab.com URLs.
+practice and instead link out from the GitLab application to <https://docs.gitlab.com> URLs.
 
-The documentation available online on docs.gitlab.com is continuously
+The documentation available online on <https://docs.gitlab.com> is continuously
 deployed every hour from the `master` branch of GitLab, Omnibus, and Runner. Therefore,
 once a merge request gets merged, it will be available online on the same day.
 However, they will be shipped (and available on `/help`) within the milestone assigned
@@ -195,7 +193,7 @@ available online on 2018-09-15, but, as the feature freeze date has passed, if
 the MR does not have a "pick into 11.3" label, the milestone has to be changed
 to 11.4 and it will be shipped with all GitLab packages only on 2018-10-22,
 with GitLab 11.4. Meaning, it will only be available under `/help` from GitLab
-11.4 onwards, but available on docs.gitlab.com on the same day it was merged.
+11.4 onwards, but available on <https://docs.gitlab.com/> on the same day it was merged.
 
 ### Linking to `/help`
 
@@ -271,7 +269,7 @@ For example, [GitLab.com's `/help`](https://gitlab.com/help).
 ## Docs site architecture
 
 See the [Docs site architecture](site_architecture/index.md) page to learn
-how we build and deploy the site at [docs.gitlab.com](https://docs.gitlab.com) and
+how we build and deploy the site at <https://docs.gitlab.com> and
 to review all the assets and libraries in use.
 
 ### Global navigation
@@ -301,18 +299,18 @@ You will need to push a branch to those repositories, it doesn't work for forks.
 
 The `review-docs-deploy*` job will:
 
-1. Create a new branch in the [gitlab-docs](https://gitlab.com/gitlab-org/gitlab-docs)
-   project named after the scheme: `$DOCS_GITLAB_REPO_SUFFIX-$CI_ENVIRONMENT_SLUG`,
-   where `DOCS_GITLAB_REPO_SUFFIX` is the suffix for each product, e.g, `ce` for
-   CE, etc.
-1. Trigger a cross project pipeline and build the docs site with your changes
-
-After a few minutes, the Review App will be deployed and you will be able to
-preview the changes. The docs URL can be found in two places:
+1. Create a new branch in the [`gitlab-docs`](https://gitlab.com/gitlab-org/gitlab-docs)
+   project named after the scheme: `docs-preview-$DOCS_GITLAB_REPO_SUFFIX-$CI_MERGE_REQUEST_IID`,
+   where `DOCS_GITLAB_REPO_SUFFIX` is the suffix for each product, e.g, `ee` for
+   EE, `omnibus` for Omnibus GitLab, etc, and `CI_MERGE_REQUEST_IID` is the ID
+   of the respective merge request.
+1. Trigger a cross project pipeline and build the docs site with your changes.
 
-- In the merge request widget
-- In the output of the `review-docs-deploy*` job, which also includes the
-  triggered pipeline so that you can investigate whether something went wrong
+In case the review app URL returns 404, this means that either the site is not
+yet deployed, or something went wrong with the remote pipeline. Give it a few
+minutes and it should appear online, otherwise you can check the status of the
+remote pipeline from the link in the merge request's job output.
+If the pipeline failed or got stuck, drop a line in the `#docs` chat channel.
 
 TIP: **Tip:**
 Someone with no merge rights to the GitLab projects (think of forks from
@@ -345,12 +343,11 @@ If you want to know the in-depth details, here's what's really happening:
 1. The job runs the [`scripts/trigger-build-docs`](https://gitlab.com/gitlab-org/gitlab/blob/master/scripts/trigger-build-docs)
    script with the `deploy` flag, which in turn:
    1. Takes your branch name and applies the following:
-      - The slug of the branch name is used to avoid special characters since
-        ultimately this will be used by NGINX.
-      - The `preview-` prefix is added to avoid conflicts if there's a remote branch
-        with the same name that you created in the merge request.
-      - The final branch name is truncated to 42 characters to avoid filesystem
-        limitations with long branch names (> 63 chars).
+      - The `docs-preview-` prefix is added.
+      - The product slug is used to know the project the review app originated
+        from.
+      - The number of the merge request is added so that you can know by the
+        `gitlab-docs` branch name the merge request it originated from.
    1. The remote branch is then created if it doesn't exist (meaning you can
       re-run the manual job as many times as you want and this step will be skipped).
    1. A new cross-project pipeline is triggered in the docs project.
@@ -371,20 +368,33 @@ The following GitLab features are used among others:
 - [Review Apps](../../ci/review_apps/index.md)
 - [Artifacts](../../ci/yaml/README.md#artifacts)
 - [Specific Runner](../../ci/runners/README.md#locking-a-specific-runner-from-being-enabled-for-other-projects)
+- [Pipelines for merge requests](../../ci/merge_request_pipelines/index.md)
 
 ## Testing
 
-We treat documentation as code, and so use tests to maintain the standards and quality of the docs.
-The current tests are:
-
-1. `docs lint`: Check that all internal (relative) links work correctly and
-   that all cURL examples in API docs use the full switches. It's recommended
-   to [check locally](#previewing-the-changes-live) before pushing to GitLab by executing the command
-   `bundle exec nanoc check internal_links` on your local
-   [`gitlab-docs`](https://gitlab.com/gitlab-org/gitlab-docs) directory. In addition,
-   `docs-lint` also runs [`markdownlint`](#markdownlint) to ensure the
-   markdown is consistent across all documentation.
-1. In a full pipeline, tests for [`/help`](#gitlab-help-tests).
+We treat documentation as code, and so use tests in our CI pipeline to maintain the
+standards and quality of the docs. The current tests, which run in CI jobs when a
+merge request with new or changed docs is submitted, are:
+
+- [`docs lint`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/ci/docs.gitlab-ci.yml#L48):
+  Runs several tests on the content of the docs themselves:
+  - [`lint-doc.sh` script](https://gitlab.com/gitlab-org/gitlab/blob/master/scripts/lint-doc.sh)
+    checks that:
+    - All cURL examples use the long flags (ex: `--header`, not `-H`).
+    - The `CHANGELOG.md` does not contain duplicate versions.
+    - No files in `doc/` are executable.
+    - No new `README.md` was added.
+  - [`markdownlint`](#markdownlint).
+  - Nanoc tests, which you can [run locally](#previewing-the-changes-live) before
+    pushing to GitLab by executing the command `bundle exec nanoc check internal_links`
+    (or `internal_anchors`) on your local [`gitlab-docs`](https://gitlab.com/gitlab-org/gitlab-docs) directory:
+    - [`internal_links`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/ci/docs.gitlab-ci.yml#L67)
+      checks that all internal links (ex: `[link](../index.md)`) are valid.
+    - [`internal_anchors`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/ci/docs.gitlab-ci.yml#L69)
+      checks that all internal anchors (ex: `[link](../index.md#internal_anchor)`)
+      are valid.
+- If any code or the `doc/README.md` file is changed, a full pipeline will run, which
+  runs tests for [`/help`](#gitlab-help-tests).
 
 ### Linting
 
@@ -490,7 +500,10 @@ four repos that are the sources for <https://docs.gitlab.com>:
 - <https://gitlab.com/charts/gitlab/blob/master/.markdownlint.json>
 
 By default all rules are enabled, so the configuration file is used to disable unwanted
-rules, and also to configure optional parameters for enabled rules as needed.
+rules, and also to configure optional parameters for enabled rules as needed. You can
+also check [the issue](https://gitlab.com/gitlab-org/gitlab-foss/issues/64352) that
+tracked the changes required to implement these rules, and details which rules were
+on or off when `markdownlint` was enabled on the docs.
 
 ## Danger Bot
 
diff --git a/doc/development/documentation/site_architecture/index.md b/doc/development/documentation/site_architecture/index.md
index bb598906967..f5a12e9c216 100644
--- a/doc/development/documentation/site_architecture/index.md
+++ b/doc/development/documentation/site_architecture/index.md
@@ -18,8 +18,8 @@ from where content is sourced, the `gitlab-docs` project, and the published outp
 
 ```mermaid
   graph LR
-    A[gitlab-ce/doc]
-    B[gitlab-ee/doc]
+    A[gitlab-foss/doc]
+    B[gitlab/doc]
     C[gitlab-runner/docs]
     D[omnibus-gitlab/doc]
     E[charts/doc]
@@ -68,7 +68,7 @@ the GitLab Documentation website.
 
 ## Global navigation
 
-Read through the global navigation](global_nav.md) documentation to understand:
+Read through [the global navigation documentation](global_nav.md) to understand:
 
 - How the global navigation is built.
 - How to add new navigation items.
diff --git a/doc/development/documentation/structure.md b/doc/development/documentation/structure.md
index 158e69df2a6..21219dc100a 100644
--- a/doc/development/documentation/structure.md
+++ b/doc/development/documentation/structure.md
@@ -32,7 +32,7 @@ For additional details on each, see the [template for new docs](#template-for-ne
 below.
 
 Note that you can include additional subsections, as appropriate, such as 'How it Works', 'Architecture',
-and other logicial divisions such as pre- and post-deployment steps.
+and other logical divisions such as pre- and post-deployment steps.
 
 ## Template for new docs
 
diff --git a/doc/development/documentation/styleguide.md b/doc/development/documentation/styleguide.md
index 79797107a5b..b6ec7a858fa 100644
--- a/doc/development/documentation/styleguide.md
+++ b/doc/development/documentation/styleguide.md
@@ -212,15 +212,36 @@ Do not include the same information in multiple places. [Link to a SSOT instead.
 
 - Use inclusive language and avoid jargon, as well as uncommon
   words. The docs should be clear and easy to understand.
-- Write in the 3rd person (use "we", "you", "us", "one", instead of "I" or "me").
+- Write in the 3rd person (use "we," "you," "us," "one," instead of "I" or "me").
 - Be clear, concise, and stick to the goal of the doc.
-- Write in US English.
+- Write in US English with US grammar.
 - Capitalize "G" and "L" in GitLab.
-- Use title case when referring to [features](https://about.gitlab.com/features/) or
-  [products](https://about.gitlab.com/pricing/) (e.g., GitLab Runner, Geo,
-  Issue Boards, GitLab Core, Git, Prometheus, Kubernetes, etc), and methods or methodologies
-  (e.g., Continuous Integration, Continuous Deployment, Scrum, Agile, etc). Note that
-  some features are also objects (e.g. "GitLab's Merge Requests support X." and "Create a new merge request for Z.").
+- Use title case when referring to:
+  - [GitLab Features](https://about.gitlab.com/features/). For example, Issue Board,
+    Geo, and Runner.
+  - GitLab [product tiers](https://about.gitlab.com/pricing/). For example, GitLab Core
+    and GitLab Ultimate.
+  - Third-party products. For example, Prometheus, Kubernetes, and Git.
+  - Methods or methodologies. For example, Continuous Integration, Continuous
+    Deployment, Scrum, and Agile.
+
+    NOTE: **Note:**
+    Some features are also objects. For example, "GitLab's Merge Requests support X" and
+    "Create a new merge request for Z."
+
+- Avoid use of the future tense:
+  - Instead of, "After you execute this command, the result will be displayed," say "After you execute this command, the result is displayed."
+  - Only use the future tense to convey when the action or result will actually occur at a future time.
+- Do not use contractions:
+  - Instead of "don't," "can't," "doesn't," and so on, say "do not," "cannot," or "does not."
+  - Possible exceptions are cases when a more familiar tone is desired, such as a blog post or other casual context.
+- Do not use slashes to clump different words together or as a replacement for the word "or":
+  - Instead of "and/or," consider saying "or," or use another sensible construction.
+  - Other examples include "clone/fetch," author/assignee," and "namespace/repository name." Break apart any such instances in an appropriate way.
+  - Exceptions to this rule include commonly accepted technical terms such as CI/CD, TCP/IP, and so on.
+- Do not use "may" and "might" interchangeably:
+  - Use "might" to indicate the probability of something occurring. "If you skip this step, the import process might fail."
+  - Use "may" to indicate giving permission for someone to do something, or consider using "can" instead. "You may select either option on this screen." Or, "you can select either option on this screen."
 
 ## Text
 
@@ -239,27 +260,13 @@ Do not include the same information in multiple places. [Link to a SSOT instead.
   - List item 2
   ```
 
-### Tables overlapping the TOC
-
-By default, all tables have a width of 100% on docs.gitlab.com.
-In a few cases, the table will overlap the table of contents (ToC).
-For these cases, add an entry to the document's frontmatter to
-render them displaying block. This will make sure the table
-is displayed behind the ToC, scrolling horizontally:
-
-```md
----
-table_display_block: true
----
-```
-
-## Emphasis
+### Emphasis
 
 - Use double asterisks (`**`) to mark a word or text in bold (`**bold**`).
 - Use underscore (`_`) for text in italics (`_italic_`).
 - Use greater than (`>`) for blockquotes.
 
-## Punctuation
+### Punctuation
 
 Check the general punctuation rules for the GitLab documentation on the table below.
 Check specific punctuation rules for [lists](#lists) below.
@@ -274,6 +281,20 @@ Check specific punctuation rules for [lists](#lists) below.
 | Always add a space before and after dashes when using it in a sentence (for replacing a comma, for example). | _You should try this - or not._ |
 | Always use lowercase after a colon. | _Related Issues: a way to create a relationship between issues._ |
 
+### Placeholder text
+
+Often in examples, a writer will provide a command or configuration that is complete apart from
+a value specific to the reader.
+
+In these cases, use [`<` and `>`](https://en.wikipedia.org/wiki/Usage_message#Pattern) to call out
+where a reader must replace text with their own value.
+
+For example:
+
+```sh
+cp <your_source_directory> <your_destination_directory>
+```
+
 ## Lists
 
 - Always start list items with a capital letter, unless they are parameters or commands
@@ -463,24 +484,58 @@ For other punctuation rules, please refer to the
 - Leave exactly one blank line before and after a heading.
 - Do not use links in headings.
 - Add the corresponding [product badge](#product-badges) according to the tier the feature belongs.
+- Use sentence case in headings. Do not capitalize the words of the title, unless
+  it refers to a product feature. For example, capitalizing "issues" is acceptable in
+  `## What you can do with GitLab Issues`, but not in `## Closing multiple issues`.
 
 ## Links
 
 - Use inline link markdown markup `[Text](https://example.com)`.
   It's easier to read, review, and maintain. **Do not** use `[Text][identifier]`.
-- To link to internal documentation, use relative links, not full URLs. Use `../` to
-  navigate to high-level directories, and always add the file name `file.md` at the
-  end of the link with the `.md` extension, not `.html`.
-  Example: instead of `[text](../../merge_requests/)`, use
-  `[text](../../merge_requests/index.md)` or, `[text](../../ci/README.md)`, or,
-  for anchor links, `[text](../../ci/README.md#examples)`.
-  Using the markdown extension is necessary for the [`/help`](index.md#gitlab-help)
-  section of GitLab.
-- To link from CE to EE-only documentation, use the EE-only doc full URL.
+
 - Use [meaningful anchor texts](https://www.futurehosting.com/blog/links-should-have-meaningful-anchor-text-heres-why/).
   E.g., instead of writing something like `Read more about GitLab Issue Boards [here](LINK)`,
   write `Read more about [GitLab Issue Boards](LINK)`.
 
+### Links to internal documentation
+
+- To link to internal documentation, use relative links, not full URLs.
+  Use `../` to navigate to high-level directories. Links should not refer to root.
+
+  Don't:
+
+  ```md
+  [Geo Troubleshooting](https://docs.gitlab.com/ee/administration/geo/replication/troubleshooting.html)
+  [Geo Troubleshooting](/ee/administration/geo/replication/troubleshooting.md)
+  ```
+
+  Do:
+
+  ```md
+  [Geo Troubleshooting](../../geo/replication/troubleshooting.md)
+  ```
+
+- Always add the file name `file.md` at the end of the link with the `.md` extension, not `.html`.
+
+  Don't:
+
+  ```md
+  [merge requests](../../merge_requests/)
+  [issues](../../issues/tags.html)
+  [issue tags](../../issues/tags.html#stages)
+  ```
+
+  Do:
+
+  ```md
+  [merge requests](../../merge_requests/index.md)
+  [issues](../../issues/tags.md)
+  [issue tags](../../issues/tags.md#stages)
+  ```
+
+- Using the markdown extension is necessary for the [`/help`](index.md#gitlab-help)
+  section of GitLab.
+
 ### Links requiring permissions
 
 Don't link directly to:
@@ -535,7 +590,7 @@ To indicate the steps of navigation through the UI:
   a valid name for an illustration is `devops_diagram_v11_1.png`.
 - Keep all file names in lower case.
 - Consider using PNG images instead of JPEG.
-- Compress all images with <https://tinypng.com/> or similar tool.
+- Compress all images with <https://pngquant.org/> or similar tool.
 - Compress gifs with <https://ezgif.com/optimize> or similar tool.
 - Images should be used (only when necessary) to _illustrate_ the description
   of a process, not to _replace_ it.
@@ -557,7 +612,7 @@ Inside the document:
 
 ### Remove image shadow
 
-All images displayed on docs.gitlab.com have a box shadow by default.
+All images displayed on the [GitLab Docs site](https://docs.gitlab.com) have a box shadow by default.
 To remove the box shadow, use the image class `.image-noshadow` applied
 directly to an HTML `img` tag:
 
@@ -591,7 +646,7 @@ You can link any up-to-date video that is useful to the GitLab user.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-docs/merge_requests/472) in GitLab 12.1.
 
-GitLab docs (docs.gitlab.com) support embedded videos.
+The [GitLab Docs site](https://docs.gitlab.com) supports embedded videos.
 
 You can only embed videos from
 [GitLab's official YouTube account](https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg).
@@ -627,7 +682,7 @@ leave a blank line here
 leave a blank line here
 ```
 
-This is how it renders on docs.gitlab.com:
+This is how it renders on the GitLab Docs site:
 
 <div class="video-fallback">
   See the video: <a href="https://www.youtube.com/watch?v=enMumwvLAug">What is GitLab</a>.
@@ -686,6 +741,10 @@ use the following markup for highlighting.
 _Note that the alert boxes only work for one paragraph only. Multiple paragraphs,
 lists, headers, etc will not render correctly. For multiple lines, use blockquotes instead._
 
+Alert boxes only render on the GitLab Docs site (<https://docs.gitlab.com>).
+Within GitLab itself, they will appear as plain markdown text (like the examples
+above the rendered versions, below).
+
 ### Note
 
 Notes catch the eye of most readers, and therefore should be used very sparingly.
@@ -710,7 +769,7 @@ NOTE: **Note:**
 This is something to note.
 ```
 
-How it renders in docs.gitlab.com:
+How it renders on the GitLab Docs site:
 
 NOTE: **Note:**
 This is something to note.
@@ -722,7 +781,7 @@ TIP: **Tip:**
 This is a tip.
 ```
 
-How it renders in docs.gitlab.com:
+How it renders on the GitLab Docs site:
 
 TIP: **Tip:**
 This is a tip.
@@ -734,7 +793,7 @@ CAUTION: **Caution:**
 This is something to be cautious about.
 ```
 
-How it renders in docs.gitlab.com:
+How it renders on the GitLab Docs site:
 
 CAUTION: **Caution:**
 This is something to be cautious about.
@@ -746,7 +805,7 @@ DANGER: **Danger:**
 This is a breaking change, a bug, or something very important to note.
 ```
 
-How it renders in docs.gitlab.com:
+How it renders on the GitLab Docs site:
 
 DANGER: **Danger:**
 This is a breaking change, a bug, or something very important to note.
@@ -759,7 +818,7 @@ For highlighting a text within a blue blockquote, use this format:
 > This is a blockquote.
 ```
 
-which renders in docs.gitlab.com to:
+which renders on the [GitLab Docs site](https://docs.gitlab.com) as:
 
 > This is a blockquote.
 
@@ -992,6 +1051,38 @@ In this case:
 - Different highlighting languages are used for each config in the code block.
 - The [GitLab Restart](#gitlab-restart) section is used to explain a required restart/reconfigure of GitLab.
 
+## Feature flags
+
+Sometimes features are shipped with feature flags, either:
+
+- On by default, but providing the option to turn the feature off.
+- Off by default, but providing the option to turn the feature on.
+
+When documenting feature flags for a feature, it's important that users know:
+
+- Why a feature flag is necessary. Some of the reasons are
+  [outlined in the handbook](https://about.gitlab.com/handbook/product/#alpha-beta-ga).
+- That administrative access is required to make a feature flag change.
+- What to ask for when requesting a change to a feature flag's state.
+
+NOTE: **Note:**
+The [Product Manager for the relevant group](https://about.gitlab.com/handbook/product/categories/#devops-stages)
+must review and approve the addition or removal of any mentions of using feature flags before the doc change is merged.
+
+The following is sample text for adding feature flag documentation for a feature:
+
+````md
+### Disabling the feature
+
+This feature comes with the `:feature_flag` feature flag enabled by default. However, in some cases
+this feature is incompatible with old configuration. To turn off the feature while configuration is
+migrated, ask a GitLab administrator with Rails console access to run the following command:
+
+```ruby
+Feature.disable(:feature_flag)
+```
+````
+
 ## API
 
 Here is a list of must-have items. Use them in the exact order that appears
@@ -1100,7 +1191,7 @@ Rendered example:
 
 ### cURL Examples
 
-Below is a set of [cURL][] examples that you can use in the API documentation.
+Below is a set of [cURL](https://curl.haxx.se) examples that you can use in the API documentation.
 
 #### Simple cURL command
 
@@ -1147,7 +1238,7 @@ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" --form "title=
 ```
 
 The above example is run by and administrator and will add an SSH public key
-titled ssh-key to user's account which has an id of 25.
+titled `ssh-key` to user's account which has an id of 25.
 
 #### Escape special characters
 
@@ -1172,7 +1263,6 @@ restrict the sign-up e-mail domains of a GitLab instance to `*.example.com` and
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" --data "domain_whitelist[]=*.example.com" --data "domain_whitelist[]=example.net" https://gitlab.example.com/api/v4/application/settings
 ```
 
-[cURL]: http://curl.haxx.se/ "cURL website"
 [single spaces]: http://www.slate.com/articles/technology/technology/2011/01/space_invaders.html
 [gfm]: ../../user/markdown.md#newlines "GitLab flavored markdown documentation"
 [ce-1242]: https://gitlab.com/gitlab-org/gitlab-foss/issues/1242
diff --git a/doc/development/documentation/workflow.md b/doc/development/documentation/workflow.md
index 9f488fac7d0..24399391b1a 100644
--- a/doc/development/documentation/workflow.md
+++ b/doc/development/documentation/workflow.md
@@ -1,10 +1,332 @@
----
-description: Learn the processes for contributing to GitLab's documentation.
----
+# Documentation process
 
-# Documentation workflows
+The process for creating and maintaining GitLab product documentation depends on whether the
+documentation is associated with:
 
-Documentation workflows at GitLab differ depending on the reason for the change:
+- [A new feature or feature enhancement](#for-a-product-change).
 
-- [Documentation process for feature changes](feature-change-workflow.md) - The documentation is being created or updated as part of the development and release of a new or enhanced feature. This process involves the developer of the feature (who includes new/updated documentation files as part of the same merge request containing the feature's code) and also involves the product manager and technical writer who are listed for the feature's [DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages).
-- [Documentation improvement workflow](improvement-workflow.md) - All documentation additions not associated with a feature release. Documentation is being created or updated to improve accuracy, completeness, ease of use, or any reason other than a feature change. Anyone (and everyone) can contribute a merge request for this type of change at any time.
+  Delivered for a specific milestone and associated with specific code changes. This documentation
+  has the highest priority.
+
+- [Changes outside a specific milestone](#for-all-other-documentation).
+
+  It is usually not associated with a specific code change and has a lower priority.
+
+Documentation is not usually required when a "backstage feature" is added or changed, and does not
+directly affect the way that any user or administrator interacts with GitLab.
+
+## For a product change
+
+This documentation is required for any new or changed feature and is:
+
+- Created or updated as part of feature development, typically via the same merge request as the
+  feature code.
+- Required with the delivery of a feature for a specific milestone as part of GitLab's
+  [definition of done](../contributing/merge_request_workflow.md#definition-of-done).
+- Often linked from the release post.
+
+### Roles and responsibilities
+
+Documentation for specific milestones involves the:
+
+- Developer of a feature or enhancement.
+- Product Manager for the group delivering the new feature or feature enhancement.
+- Technical Writer assigned to the group.
+
+Each role is described below.
+
+#### Developers
+
+Developers are the primary author of documentation for a feature or feature enhancement. They are
+responsible for:
+
+- Developing initial content required for a feature.
+- Liaising with their Product Manager to understand what documentation must be delivered, and when.
+- Requesting technical reviews from other developers within their group.
+- Requesting documentation reviews from the Technical Writer
+  [assigned to the DevOps stage group](https://about.gitlab.com/handbook/product/technical-writing/index.html#assignments)
+  that is delivering the new feature or feature enhancements.
+
+TIP: **Tip:**
+Community Contributors can ask for additional help from GitLab team members.
+
+##### Authoring
+
+Because the documentation is an essential part of the product, if a ~feature issue also contains the
+~documentation label, you must ship the new or updated documentation with the code of the feature.
+
+Technical Writers are happy to help, as requested and planned on an issue-by-issue basis.
+
+For feature issues requiring documentation, follow the process below unless otherwise agreed with
+the Product Manager and Technical Writer for a given issue:
+
+- Include any new and edited documentation, either in:
+  - The merge request introducing the code.
+  - A separate merge request raised around the same time.
+- Use the [documentation requirements](#documentation-requirements) developed by the Product Manager
+  in the issue and discuss any further documentation plans or ideas as needed.
+
+  If the new or changed documentation requires extensive collaboration or conversation, a
+  separate, linked issue can be used for the planning process.
+
+- Use the [Documentation guidelines](index.md), as well as other resources linked from there,
+  including:
+  - Documentation [Structure and template](structure.md) page.
+  - [Style Guide](styleguide.md).
+  - [Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/).
+- Contact the Technical Writer for the relevant [DevOps stage](https://about.gitlab.com/handbook/product/technical-writing/index.html#assignments)
+  in your issue or merge request, or within `#docs` on GitLab Slack, if you:
+  - Need any help to choose the correct place for documentation.
+  - Want to discuss a documentation idea or outline.
+  - Want to request any other help.
+- If you are working on documentation in a separate merge request, ensure the documentation is
+  merged as close as possible to the code merge.
+- A policy for documenting [feature-flagged](../feature_flags/index.md) issues is forthcoming and you
+  are welcome to join the [discussion](https://gitlab.com/gitlab-org/gitlab/issues/26347).
+
+##### Reviews and merging
+
+Reviewers help ensure:
+
+- Accuracy.
+- Clarity.
+- Completeness.
+- Adherence to:
+  - [Documentation requirements](#documentation-requirements) in the issue.
+  - [Documentation guidelines](index.md).
+  - [Style guide](styleguide.md).
+
+Prior to merging, documentation changes committed by the developer must be reviewed by:
+
+- The code reviewer for the merge request. This is known as a technical review.
+- Optionally, others involved in the work, such as other developers or the Product Manager.
+- Optionally, the Technical Writer for the DevOps stage group.
+- A maintainer of the project.
+
+If not assigned to a Technical Writer for review prior to merging, a review must be scheduled
+immediately after merge by the developer or maintainer. For this,
+create an issue using the [Doc Review description template](https://gitlab.com/gitlab-org/gitlab/issues/new?issuable_template=Doc%20Review)
+and link to it from the merged merge request that introduced the documentation change.
+
+To decide whether to request a Technical Writer review before or after merge, consider:
+
+- The amount of time left before the milestone release. If there is less than three days
+  remaining, seek a post-merge review and ping the writer via Slack to ensure the review is
+  completed in time.
+- The size of the change and your degree of confidence in having early users (for example,
+  GitLab.com users) of features use your documentation as written.
+- That pre-merge Technical Writer reviews should be most common when the code is complete well in
+  advance of a milestone release and for larger documentation changes.
+- You can request a post-merge Technical Writer review if it's important to get the code part of
+  a merge request merged as soon as possible.
+- The Technical Writer can also help decide that documentation can be merged without Technical
+  writer review, with the review to occur soon after merge.
+
+#### Product Managers
+
+Product Managers are responsible for the [documentation requirements](#documentation-requirements)
+for a feature or feature enhancement. They can also:
+
+- Liaise with the Technical Writer for discussion and collaboration.
+- Review documentation themselves.
+
+For issues requiring any new or updated documentation, the Product Manager must:
+
+- Add the ~documentation label.
+- Confirm or add the [documentation requirements](#documentation-requirements).
+- Ensure the issue contains:
+  - Any new or updated feature name.
+  - Overview, description, and use cases, as required by the
+    [documentation structure and template](structure.md), when applicable.
+
+Everyone is encouraged to draft the documentation requirements in the issue, but a Product Manager
+will do the following:
+
+- When the issue is assigned a release milestone, review and update the Documentation details.
+- By the kickoff, finalize the documentation details.
+
+#### Technical Writers
+
+Technical Writers are responsible for:
+
+- Reviewing documentation requirements in issues when called upon.
+- Answering questions, and helping and providing advice throughout the authoring and editing
+  process.
+- Reviewing all new and updated documentation content, whether before merge or after it is merged.
+- Assisting the developer and Product Manager with feature documentation delivery.
+
+##### Planning
+
+The Technical Writer:
+
+- Reviews their group's `~feature` issues that are part of the next milestone to get a sense of the
+  scope of content likely to be authored.
+- Recommends the `~documentation` label on issues from that list which don't have it but should, or
+  inquires with the PM to determine if documentation is truly required.
+- For `~direction` issues from that list, reads the full issue and reviews its Documentation
+  requirements section. Addresses any recommendations or questions with the PMs and others
+  collaborating on the issue in order to refine or expand the Documentation requirements.
+
+##### Collaboration
+
+By default, the developer will work on documentation changes independently, but
+the developer, Product Manager, or Technical Writer can propose a broader collaboration for
+any given issue.
+
+Additionally, Technical Writers are available for questions at any time.
+
+##### Review
+
+Technical Writers:
+
+- Provide non-blocking reviews of all documentation changes, before or after the change is merged.
+- Confirm that the documentation is:
+  - Clear.
+  - Grammatically correct.
+  - Discoverable.
+  - Navigable.
+- Ensures that the documentation avoids:
+  - Redundancy.
+  - Bad file locations.
+  - Typos.
+  - Broken links.
+
+The Technical Writer will review the documentation to check that the developer and
+code reviewer have ensured:
+
+- Clarity.
+- Appropriate location, making sure the documentation is in the correct directories (often
+  reflecting how the product is structured) and has the correct name.
+- Syntax, typos, and broken links.
+- Improvements to the content.
+- Accordance with the:
+  - [Documentation Style Guide](styleguide.md).
+  - [Structure and Template](structure.md) doc.
+
+### When documentation is required
+
+Documentation [is required](../contributing/merge_request_workflow.html#definition-of-done) for a
+milestone when:
+
+- A new or enhanced feature is shipped that impacts the user of administrator experience.
+- There are changes to the UI or API.
+- A process, workflow, or previously documented feature is changed.
+- A feature is deprecated or removed.
+
+NOTE: **Note:**
+Documentation refactoring unrelated to a feature change is covered in the
+[other process](#for-all-other-documentation), so that time-sensitive documentation updates are
+prioritized.
+
+### Documentation requirements
+
+Requirements for the documentation of a feature should be included as part of the
+issue for planning that feature in a **Documentation** section within the issue description. Issues
+created using the [**Feature Proposal** template](https://gitlab.com/gitlab-org/gitlab/raw/master/.gitlab/issue_templates/Feature%20proposal.md)
+have this section by default.
+
+Anyone can add these details, but the Product Manager who assigns the issue to a specific release
+milestone will ensure these details are present and finalized by the time of that milestone's kickoff.
+
+Developers, Technical Writers, and others may help further refine this plan at any time.
+
+The following details should be included:
+
+- What concepts and procedures should the documentation guide and enable the user to understand or
+  accomplish?
+- To this end, what new page(s) are needed, if any? What pages or subsections need updates?
+  Consider user, admin, and API documentation changes and additions.
+- For any guide or instruction set, should it help address a single use case, or be flexible to
+  address a certain range of use cases?
+- Do we need to update a previously recommended workflow? Should we link the new feature from
+  various relevant locations? Consider all ways documentation should be affected.
+- Are there any key terms or task descriptions that should be included so that the documentation is
+  found in relevant searches?
+- Include suggested titles of any pages or subsection headings, if applicable.
+- List any documentation that should be cross-linked, if applicable.
+
+## For all other documentation
+
+These documentation changes are not associated with the release of a new or updated feature, and are
+therefore labeled `backstage` in GitLab, rather than `feature`. They may include:
+
+- Documentation created or updated to improve accuracy, completeness, ease of use, or any reason
+  other than a [feature change](#for-a-product-change).
+- Addressing gaps in existing documentation, or making improvements to existing documentation.
+- Work on special projects related to the documentation.
+
+TIP: **Tip:**
+Anyone can contribute a merge request or create an issue for GitLab's documentation.
+
+### Who updates the docs
+
+Anyone can contribute! You can create a merge request for documentation when:
+
+- You find errors or other room for improvement in existing documentation.
+- You have an idea for all-new documentation that would help a GitLab user or administrator to
+  accomplish their work with GitLab.
+
+### How to update the docs
+
+To update GitLab documentation:
+
+1. Either:
+   - Click the **Edit this Page** link at the bottom of any page on <https://docs.gitlab.com>.
+   - Navigate to one of the repositories and documentation paths listed on the
+     [GitLab Documentation guidelines](index.md) page.
+1. Follow the described standards and processes listed on the page, including:
+   - The [Structure and template](structure.md) page.
+   - The [Style Guide](styleguide.md).
+   - The [Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/).
+1. Follow GitLab's [Merge Request Guidelines](../contributing/merge_request_workflow.md#merge-request-guidelines).
+
+TIP: **Tip:**
+Work in a fork if you do not have developer access to the GitLab project.
+
+Ping the Technical Writer for the relevant [DevOps stage group](https://about.gitlab.com/handbook/product/technical-writing/index.html#assignments)
+in your issue or merge request, or within `#docs` if you are a member of GitLab's Slack workspace, if you:
+
+- Need help to choose the correct place for documentation.
+- Want to discuss a documentation idea or outline.
+- Want to request any other help.
+
+### Reviewing and merging
+
+Anyone with Maintainer access to the relevant GitLab project can merge documentation changes.
+Maintainers must make a good-faith effort to ensure that the content:
+
+- Is clear and sufficiently easy for the intended audience to navigate and understand.
+- Meets the [Documentation Guidelines](index.md) and [Style Guide](styleguide.md).
+
+If the author or reviewer has any questions, they can mention the writer who is assigned to the relevant
+[DevOps stage group](https://about.gitlab.com/handbook/product/technical-writing/index.html#assignments).
+
+The process involves the following:
+
+- Primary Reviewer. Review by a [code reviewer](https://about.gitlab.com/handbook/engineering/projects/)
+  or other appropriate colleague to confirm accuracy, clarity, and completeness. This can be skipped
+  for minor fixes without substantive content changes.
+- Technical Writer (Optional). If not completed for a merge request prior to merging, must be scheduled
+  post-merge. To request a:
+  - Pre-merge review, assign the Technical Writer listed for the applicable
+    [DevOps stage group](https://about.gitlab.com/handbook/product/technical-writing/index.html#assignments).
+  - Post-merge review, [create an issue for one](https://gitlab.com/gitlab-org/gitlab/issues/new?issuable_template=Doc%20Review)
+    and link it from the MR that makes the documentation change.
+- Maintainer. For merge requests, Maintainers:
+  - Can always request any of the above reviews.
+  - Review before or after a Technical Writer review.
+  - Ensure the given release milestone is set.
+  - Ensure the appropriate labels are applied, including any required to pick a merge request into
+    a release.
+  - Ensure that, if there has not been a Technical Writer review completed or scheduled, they
+    [create the required issue](https://gitlab.com/gitlab-org/gitlab/issues/new?issuable_template=Doc%20Review), assign to the technical writer of the given stage group,
+    and link it from the merge request.
+
+The process is reflected in the **Documentation**
+[merge request template](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/merge_request_templates/Documentation.md).
+
+### Other ways to help
+
+If you have ideas for further documentation resources please
+[create an issue](https://gitlab.com/gitlab-org/gitlab/issues/new?issuable_template=Documentation)
+using the Documentation template.
diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md
index d34c3ce5ba1..cc9df479492 100644
--- a/doc/development/ee_features.md
+++ b/doc/development/ee_features.md
@@ -19,86 +19,22 @@ CE specs should remain untouched as much as possible and extra specs
 should be added for EE. Licensed features can be stubbed using the
 spec helper `stub_licensed_features` in `EE::LicenseHelpers`.
 
-You can force Webpack to act as CE by either deleting the `ee/` directory or by
-setting the [`IS_GITLAB_EE` environment variable](https://gitlab.com/gitlab-org/gitlab/blob/master/config/helpers/is_ee_env.js)
-to something that evaluates as `false`. The same works for running tests
-(for example `IS_GITLAB_EE=0 yarn jest`).
+You can force GitLab to act as CE by either deleting the `ee/` directory or by
+setting the [`FOSS_ONLY` environment variable](https://gitlab.com/gitlab-org/gitlab/blob/master/config/helpers/is_ee_env.js)
+to something that evaluates as `true`. The same works for running tests
+(for example `FOSS_ONLY=1 yarn jest`).
 
 [ee-as-ce]: https://gitlab.com/gitlab-org/gitlab/issues/2500
 
 ## Separation of EE code
 
-We want a [single code base][] eventually, but before we reach the goal,
-we still need to merge changes from GitLab CE to EE. To help us get there,
-we should make sure that we no longer edit CE files in place in order to
-implement EE features.
-
-Instead, all EE code should be put inside the `ee/` top-level directory. The
+All EE code should be put inside the `ee/` top-level directory. The
 rest of the code should be as close to the CE files as possible.
 
-[single code base]: https://gitlab.com/gitlab-org/gitlab/issues/2952#note_41016454
-
-### EE-specific comments
-
-When complete separation can't be achieved with the `ee/` directory, you can wrap
-code in EE specific comments to designate the difference from CE/EE and add
-some context for someone resolving a conflict.
-
-```rb
-# EE-specific start
-stub_licensed_features(variable_environment_scope: true)
-# EE specific end
-```
-
-```haml
--# EE-specific start
-= render 'ci/variables/environment_scope', form_field: form_field, variable: variable
--# EE-specific end
-```
-
-EE-specific comments should not be backported to CE.
-
-**Note:** This is only meant as a workaround, we should follow up and
-resolve this soon.
-
-### Detection of EE-only files
-
-For each commit (except on `master`), the `ee-files-location-check` CI job tries
-to detect if there are any new files that are EE-only. If any file is detected,
-the job fails with an explanation of why and what to do to make it pass.
-
-Basically, the fix is simple: `git mv <file> ee/<file>`.
-
-#### How to name your branches?
-
-For any EE branch, the job will try to detect its CE counterpart by removing any
-`ee-` prefix or `-ee` suffix from the EE branch name, and matching the last
-branch that contains it.
-
-For instance, from the EE branch `new-shiny-feature-ee` (or
-`ee-new-shiny-feature`), the job would find the corresponding CE branches:
-
-- `new-shiny-feature`
-- `ce-new-shiny-feature`
-- `new-shiny-feature-ce`
-- `my-super-new-shiny-feature-in-ce`
-
-#### Whitelist some EE-only files that cannot be moved to `ee/`
-
-The `ee-files-location-check` CI job provides a whitelist of files or folders
-that cannot or should not be moved to `ee/`. Feel free to open an issue to
-discuss adding a new file/folder to this whitelist.
-
-For instance, it was decided that moving EE-only files from `qa/` to `ee/qa/`
-would make it difficult to build the `gitLab-{ce,ee}-qa` Docker images and it
-was [not worth the complexity].
-
-[not worth the complexity]: https://gitlab.com/gitlab-org/gitlab/issues/4997#note_59764702
-
 ### EE-only features
 
 If the feature being developed is not present in any form in CE, we don't
-need to put the codes under `EE` namespace. For example, an EE model could
+need to put the code under the `EE` namespace. For example, an EE model could
 go into: `ee/app/models/awesome.rb` using `Awesome` as the class name. This
 is applied not only to models. Here's a list of other examples:
 
@@ -116,7 +52,7 @@ is applied not only to models. Here's a list of other examples:
 - `ee/app/views/foo.html.haml`
 - `ee/app/views/foo/_bar.html.haml`
 
-This works because for every path that are present in CE's eager-load/auto-load
+This works because for every path that is present in CE's eager-load/auto-load
 paths, we add the same `ee/`-prepended path in [`config/application.rb`].
 This also applies to views.
 
@@ -170,7 +106,7 @@ still having access the class's implementation with `super`.
 
 There are a few gotchas with it:
 
-- you should always [`extend ::Gitlab::Utils::Override`](utilities.md#overridehttpsgitlabcomgitlab-orggitlab-fossblobmasterlibgitlabutilsoverriderb) and use `override` to
+- you should always [`extend ::Gitlab::Utils::Override`](utilities.md#override) and use `override` to
   guard the "overrider" method to ensure that if the method gets renamed in
   CE, the EE override won't be silently forgotten.
 - when the "overrider" would add a line in the middle of the CE
@@ -441,13 +377,10 @@ CE and EE.
 
 The advantages of this:
 
-- Minimal code difference between CE and EE.
-- Very clear hints about where we're extending EE views while reading CE codes.
+- Very clear hints about where we're extending EE views while reading CE code.
 
 The disadvantage of this:
 
-- Slightly more work while developing EE features, because now we need to
-  port `render_if_exists` to CE.
 - If we have typos in the partial name, it would be silently ignored.
 
 ##### Caveats
@@ -858,7 +791,7 @@ end
 ### Code in `spec/`
 
 When you're testing EE-only features, avoid adding examples to the
-existing CE specs. Also do no change existing CE examples, since they
+existing CE specs. Also do not change existing CE examples, since they
 should remain working as-is when EE is running without a license.
 
 Instead place EE specs in the `ee/spec` folder.
@@ -992,10 +925,8 @@ For regular JS files, the approach is similar.
 
 ## SCSS code in `assets/stylesheets`
 
-To separate EE-specific styles in SCSS files, if a component you're adding styles for
-is limited to only EE, it is better to have a separate SCSS file in appropriate directory
-within `app/assets/stylesheets`.
-See [backporting changes](#backporting-changes-from-ee-to-ce) for instructions on how to merge changes safely.
+If a component you're adding styles for is limited to EE, it is better to have a
+separate SCSS file in an appropriate directory within `app/assets/stylesheets`.
 
 In some cases, this is not entirely possible or creating dedicated SCSS file is an overkill,
 e.g. a text style of some component is different for EE. In such cases,
@@ -1037,24 +968,6 @@ to avoid conflicts during CE to EE merge.
 // EE-specific end
 ```
 
-## Backporting changes from EE to CE
-
-Until the work completed to merge the ce and ee codebases, which is tracked on [epic &802](https://gitlab.com/groups/gitlab-org/-/epics/802), there exists times in which some changes for EE require specific changes to the CE
-code base.  Examples of backports include the following:
-
-- Features intended or originally built for EE that are later decided to move to CE
-- Sometimes some code in CE may impact the EE feature
-
-Here is a workflow to make sure those changes end up backported safely into CE too.
-
-1. **Make your changes in the EE branch.** If possible, keep a separated commit (to be squashed) to help backporting and review.
-1. **Open merge request to EE project.**
-1. **Apply the changes you made to CE files in a branch of the CE project.** (Tip: Use `patch` with the diff from your commit in EE branch)
-1. **Open merge request to CE project**, referring it's a backport of EE changes and link to MR open in EE.
-1. Once EE MR is merged, the MR towards CE can be merged. **But not before**.
-
-**Note:** regarding SCSS, make sure the files living outside `/ee/` don't diverge between CE and EE projects.
-
 ## GitLab-svgs
 
 Conflicts in `app/assets/images/icons.json` or `app/assets/images/icons.svg` can
diff --git a/doc/development/elasticsearch.md b/doc/development/elasticsearch.md
index 1475e356b5b..1375bd6d56d 100644
--- a/doc/development/elasticsearch.md
+++ b/doc/development/elasticsearch.md
@@ -1,8 +1,9 @@
 # Elasticsearch knowledge **(STARTER ONLY)**
 
-This area is to maintain a compendium of useful information when working with elasticsearch.
+This area is to maintain a compendium of useful information when working with Elasticsearch.
 
-Information on how to enable Elasticsearch and perform the initial indexing is kept in ../integration/elasticsearch.md#enabling-elasticsearch
+Information on how to enable Elasticsearch and perform the initial indexing is in
+the [Elasticsearch integration documentation](../integration/elasticsearch.md#enabling-elasticsearch).
 
 ## Deep Dive
 
@@ -59,9 +60,9 @@ Additionally, if you need large repos or multiple forks for testing, please cons
 
 ## How does it work?
 
-The Elasticsearch integration depends on an external indexer. We ship an [indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). The user must trigger the initial indexing via a rake task but, after this is done, GitLab itself will trigger reindexing when required via `after_` callbacks on create, update, and destroy that are inherited from [/ee/app/models/concerns/elastic/application_search.rb](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/app/models/concerns/elastic/application_search.rb).
+The Elasticsearch integration depends on an external indexer. We ship an [indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). The user must trigger the initial indexing via a rake task but, after this is done, GitLab itself will trigger reindexing when required via `after_` callbacks on create, update, and destroy that are inherited from [/ee/app/models/concerns/elastic/application_versioned_search.rb](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/app/models/concerns/elastic/application_versioned_search.rb).
 
-All indexing after the initial one is done via `ElasticIndexerWorker` (sidekiq jobs).
+All indexing after the initial one is done via `ElasticIndexerWorker` (Sidekiq jobs).
 
 Search queries are generated by the concerns found in [ee/app/models/concerns/elastic](https://gitlab.com/gitlab-org/gitlab/tree/master/ee/app/models/concerns/elastic). These concerns are also in charge of access control, and have been a historic source of security bugs so please pay close attention to them!
 
@@ -243,4 +244,4 @@ cluster.routing.allocation.disk.watermark.high: 10gb
 
 Restart Elasticsearch, and the `read_only_allow_delete` will clear on it's own.
 
-_from "Disk-based Shard Allocation | Elasticsearch Reference" [5.6](https://www.elastic.co/guide/en/elasticsearch/reference/5.6/disk-allocator.html#disk-allocator) and [6.x](https://www.elastic.co/guide/en/elasticsearch/reference/6.x/disk-allocator.html)_
+_from "Disk-based Shard Allocation | Elasticsearch Reference" [5.6](https://www.elastic.co/guide/en/elasticsearch/reference/5.6/disk-allocator.html#disk-allocator) and [6.x](https://www.elastic.co/guide/en/elasticsearch/reference/6.7/disk-allocator.html)_
diff --git a/doc/development/emails.md b/doc/development/emails.md
index 91b9e11f7f6..2c5f3be45d8 100644
--- a/doc/development/emails.md
+++ b/doc/development/emails.md
@@ -17,10 +17,9 @@ dummy data.
 The previews live in [`app/mailers/previews`][previews] and can be viewed at
 [`/rails/mailers`](http://localhost:3000/rails/mailers).
 
-See the [Rails guides] for more info.
+See the [Rails guides](https://guides.rubyonrails.org/action_mailer_basics.html#previewing-emails) for more info.
 
 [previews]: https://gitlab.com/gitlab-org/gitlab-foss/tree/master/app/mailers/previews
-[Rails guides]: http://guides.rubyonrails.org/action_mailer_basics.html#previewing-emails
 
 ## Incoming email
 
@@ -88,15 +87,15 @@ for the format of the email key:
 
 - Actions are always at the end, separated by `-`.  For example `-issue` or `-merge-request`
 - If your feature is related to a project, the key begins with the project identifiers (project path slug
-  and project id), separated by `-`.  For example, `gitlab-org-gitlab-ce-20`
+  and project id), separated by `-`.  For example, `gitlab-org-gitlab-foss-20`
 - Additional information, such as an author's token, can be added between the project identifiers and
-  the action, separated by `-`.  For example, `gitlab-org-gitlab-ce-20-Author_Token12345678-issue`
+  the action, separated by `-`.  For example, `gitlab-org-gitlab-foss-20-Author_Token12345678-issue`
 - You register your handlers in `lib/gitlab/email/handler.rb`
 
 Examples of valid email keys:
 
-- `gitlab-org-gitlab-ce-20-Author_Token12345678-issue` (create a new issue)
-- `gitlab-org-gitlab-ce-20-Author_Token12345678-merge-request` (create a new merge request)
+- `gitlab-org-gitlab-foss-20-Author_Token12345678-issue` (create a new issue)
+- `gitlab-org-gitlab-foss-20-Author_Token12345678-merge-request` (create a new merge request)
 - `1234567890abcdef1234567890abcdef-unsubscribe` (unsubscribe from a conversation)
 - `1234567890abcdef1234567890abcdef` (reply to a conversation)
 
diff --git a/doc/development/event_tracking/frontend.md b/doc/development/event_tracking/frontend.md
index cdc2e94bf9e..c767efc65b2 100644
--- a/doc/development/event_tracking/frontend.md
+++ b/doc/development/event_tracking/frontend.md
@@ -1,6 +1,6 @@
 # Frontend tracking guide
 
-GitLab provides `Tracking`, an interface that wraps the [Snowplow Javascript Tracker](https://github.com/snowplow/snowplow/wiki/javascript-tracker) for tracking custom events. There are a few ways to utilizing tracking, but each generally requires at minimum, a `category` and an `action`. Additional data can be provided that adheres to our [Feature instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy).
+GitLab provides `Tracking`, an interface that wraps the [Snowplow JavaScript Tracker](https://github.com/snowplow/snowplow/wiki/javascript-tracker) for tracking custom events. There are a few ways to utilize tracking, but each generally requires at minimum, a `category` and an `action`. Additional data can be provided that adheres to our [Feature instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy).
 
 | field      | type   | default value              | description |
 |:-----------|:-------|:---------------------------|:------------|
@@ -26,7 +26,7 @@ Below is an example of `data-track-*` attributes assigned to a button:
 />
 ```
 
-Event listeners are bound at the document level to handle click events on or within elements with these data attributes. This allows for them to be properly handled on rerendering and changes to the DOM, but it's important to know that because of the way these events are bound, click events shouldn't be stopped from propagating up the DOM tree. If for any reason click events are being stopped from propagating, you'll need to implement your own listeners and follow the instructions in [Tracking in raw Javascript](#tracking-in-raw-javascript).
+Event listeners are bound at the document level to handle click events on or within elements with these data attributes. This allows for them to be properly handled on rerendering and changes to the DOM, but it's important to know that because of the way these events are bound, click events shouldn't be stopped from propagating up the DOM tree. If for any reason click events are being stopped from propagating, you'll need to implement your own listeners and follow the instructions in [Tracking in raw JavaScript](#tracking-in-raw-javascript).
 
 Below is a list of supported `data-track-*` attributes:
 
@@ -99,7 +99,7 @@ And if needed within the template, you can use the `track` method directly as we
 </template>
 ```
 
-## Tracking in raw Javascript
+## Tracking in raw JavaScript
 
 Custom event tracking and instrumentation can be added by directly calling the `Tracking.event` static function. The following example demonstrates tracking a click on a button by calling `Tracking.event` manually.
 
diff --git a/doc/development/experiment_guide/index.md b/doc/development/experiment_guide/index.md
new file mode 100644
index 00000000000..5155433c9ad
--- /dev/null
+++ b/doc/development/experiment_guide/index.md
@@ -0,0 +1,65 @@
+# Experiment Guide
+
+Experiments will be conducted by teams from the [Growth Section](https://about.gitlab.com/handbook/engineering/development/growth/) and are not tied to releases, because they will primarily target GitLab.com.
+
+Experiments will be run as an A/B test and will be behind a feature flag to turn the test on or off. Based on the data the experiment generates, the team decides if the experiment had a positive impact and will be the new default or rolled back.
+
+## Follow-up issue
+
+Each experiment requires a follow-up issue to resolve the experiment. Immediately after an experiment is deployed, the deadline of the issue needs to be set (this depends on the experiment but can be up to a few weeks in the future).
+After the deadline, the issue needs to be resolved and either:
+
+- It was successful and the experiment will be the new default.
+- It was not successful and all code related to the experiment will be removed.
+
+In either case, an outcome of the experiment should be posted to the issue with the reasoning for the decision.
+
+## Code reviews
+
+Since the code of experiments will not be part of the codebase for a long time and we want to iterate fast to retrieve data,the code quality of experiments might sometimes not fulfill our standards but should not negatively impact the availability of GitLab whether the experiment is running or not.
+Experiments will only be deployed to a fraction of users but we still want a flawless experience for those users. Therefore, experiments still require tests.
+
+For reviewers and maintainers: if you find code that would usually not make it through the review, but is temporarily acceptable, please mention your concerns but note that it's not necessary to change.
+The author then adds a comment to this piece of code and adds a link to the issue that resolves the experiment.
+
+## How to create an A/B test
+
+- [ ] Add the experiment to the `Gitlab::Experimentation::EXPERIMENTS` hash in [`experimentation.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib%2Fgitlab%2Fexperimentation.rb):
+
+  ```ruby
+  EXPERIMENTS = {
+    other_experiment: {
+      #...
+    },
+    # Add your experiment here:
+    sign_up_flow: {
+      feature_toggle: :experimental_sign_up_flow, # Feature flag that will be used
+      environment: ::Gitlab.dev_env_or_com?, # Target environment
+      enabled_ratio: 0.1 # Percentage of users that will be part of the experiment. 10% of the users would be part of this experiments.
+    }
+  }.freeze
+  ```
+
+- [ ] Use the experiment in a controller:
+
+  ```ruby
+  class RegistrationController < Applicationcontroller
+   def show
+     # experiment_enabled?(:feature_name) is also available in views and helpers
+     if experiment_enabled?(:sign_up_flow)
+       # render the experiment
+     else
+       # render the original version
+     end
+   end
+  end
+  ```
+
+- [ ] Track necessery events. See the [event tracking guide](../event_tracking/index.md) for details.
+- [ ] After the merge request is merged, use [`chatops`](../../ci/chatops/README.md) to enable the feature flag and start the experiment. For visibility, please run the command in the `#s_growth` channel:
+
+  ```
+  /chatops run feature set --project=gitlab-org/gitlab experimental_sign_up_flow true
+  ```
+
+  If you notice issues with the experiment, you can disable the experiment by setting the feature flag to `false` again.
diff --git a/doc/development/fe_guide/components.md b/doc/development/fe_guide/components.md
index e88827f78c1..6b6274a6480 100644
--- a/doc/development/fe_guide/components.md
+++ b/doc/development/fe_guide/components.md
@@ -1,63 +1,3 @@
-# Components
-
-## Contents
-
-- [Dropdowns](#dropdowns)
-- [Modals](#modals)
-
-## Dropdowns
-
-See also the [corresponding UX guide](https://design.gitlab.com/#/components/dropdowns).
-
-### How to style a bootstrap dropdown
-
-1. Use the HTML structure provided by the [docs][bootstrap-dropdowns]
-1. Add a specific class to the top level `.dropdown` element
-
-   ```Haml
-   .dropdown.my-dropdown
-     %button{ type: 'button', data: { toggle: 'dropdown' }, 'aria-haspopup': true, 'aria-expanded': false }
-       %span.dropdown-toggle-text
-         Toggle Dropdown
-       = icon('chevron-down')
-
-     %ul.dropdown-menu
-       %li
-         %a
-           item!
-   ```
-
-   Or use the helpers
-
-   ```Haml
-   .dropdown.my-dropdown
-     = dropdown_toggle('Toogle!', { toggle: 'dropdown' })
-     = dropdown_content
-       %li
-         %a
-           item!
-   ```
-
-[bootstrap-dropdowns]: https://getbootstrap.com/docs/3.3/javascript/#dropdowns
-
-## Modals
-
-See also the [corresponding UX guide](https://design.gitlab.com/#/components/modals).
-
-We have a reusable Vue component for modals: [vue_shared/components/gl_modal.vue](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/assets/javascripts/vue_shared/components/gl_modal.vue)
-
-Here is an example of how to use it:
-
-```html
-  <gl-modal
-    id="dogs-out-modal"
-    :header-title-text="s__('ModalExample|Let the dogs out?')"
-    footer-primary-button-variant="danger"
-    :footer-primary-button-text="s__('ModalExample|Let them out')"
-    @submit="letOut(theDogs)"
-  >
-    {{ s__('ModalExample|You’re about to let the dogs out.') }}
-  </gl-modal>
-```
-
-![example modal](img/gl-modal.png)
+---
+redirect_to: 'https://design.gitlab.com/components/status/'
+---
diff --git a/doc/development/fe_guide/design_patterns.md b/doc/development/fe_guide/design_patterns.md
index 0893299540f..a7a0f39e2f3 100644
--- a/doc/development/fe_guide/design_patterns.md
+++ b/doc/development/fe_guide/design_patterns.md
@@ -77,4 +77,4 @@ new Foo({ container: '.my-element' });
 
 You can find an example of the above in this [class][container-class-example];
 
-[container-class-example]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/assets/javascripts/mini_pipeline_graph_dropdown.js
+[container-class-example]: https://gitlab.com/gitlab-org/gitlab/blob/master/app/assets/javascripts/mini_pipeline_graph_dropdown.js
diff --git a/doc/development/fe_guide/development_process.md b/doc/development/fe_guide/development_process.md
index 41513e6d57e..3724bf60757 100644
--- a/doc/development/fe_guide/development_process.md
+++ b/doc/development/fe_guide/development_process.md
@@ -80,7 +80,7 @@ With the purpose of being [respectful of others' time](https://about.gitlab.com/
 
 1. Before writing code, ensure your vision of the architecture is aligned with
    GitLab's architecture.
-1. Add a diagram to the issue and ask a frontend architect in the slack channel `#fe_architectural` about it.
+1. Add a diagram to the issue and ask a frontend maintainer in the Slack channel `#frontend_maintainers` about it.
 
    ![Diagram of Issue Boards Architecture](img/boards_diagram.png)
 
diff --git a/doc/development/fe_guide/dropdowns.md b/doc/development/fe_guide/dropdowns.md
index e9d6244355c..019bd36573d 100644
--- a/doc/development/fe_guide/dropdowns.md
+++ b/doc/development/fe_guide/dropdowns.md
@@ -1 +1,3 @@
-This page has moved [here](components.md#dropdowns).
+---
+redirect_to: 'https://design.gitlab.com/components/dropdowns/'
+---
diff --git a/doc/development/fe_guide/frontend_faq.md b/doc/development/fe_guide/frontend_faq.md
index 2ec3f8017a1..36c8a03a241 100644
--- a/doc/development/fe_guide/frontend_faq.md
+++ b/doc/development/fe_guide/frontend_faq.md
@@ -26,7 +26,7 @@ question:
 document.body.dataset.page
 ```
 
-Find here the [source code setting the attribute](https://gitlab.com/gitlab-org/gitlab-foss/blob/cc5095edfce2b4d4083a4fb1cdc7c0a1898b9921/app/views/layouts/application.html.haml#L4).
+Find here the [source code setting the attribute](https://gitlab.com/gitlab-org/gitlab/blob/cc5095edfce2b4d4083a4fb1cdc7c0a1898b9921/app/views/layouts/application.html.haml#L4).
 
 #### Rails routes
 
diff --git a/doc/development/fe_guide/graphql.md b/doc/development/fe_guide/graphql.md
index 366c2894b81..fe4f6d7bec8 100644
--- a/doc/development/fe_guide/graphql.md
+++ b/doc/development/fe_guide/graphql.md
@@ -1,11 +1,18 @@
 # GraphQL
 
+Our GraphQL API can be explored via GraphiQL at your instance's
+`/-/graphql-explorer` or at [GitLab.com](https://gitlab.com/-/graphql-explorer).
+
+You can check all existing queries and mutations on the right side
+of GraphiQL in its **Documentation explorer**. It's also possible to
+write queries and mutations directly on the left tab and check
+their execution by clicking **Execute query** button on the top left:
+
+![GraphiQL interface](img/graphiql_explorer_v12_4.png)
+
 We use [Apollo] and [Vue Apollo][vue-apollo] for working with GraphQL
 on the frontend.
 
-In order to use GraphQL, you need to enable the `graphql` feature flag,
-read more about [Feature Flags][feature-flags].
-
 ## Apollo Client
 
 To save duplicated clients getting created in different apps, we have a
@@ -119,6 +126,6 @@ Read more about the [Apollo] client in the [Apollo documentation](https://www.ap
 [Apollo]: https://www.apollographql.com/
 [vue-apollo]: https://github.com/Akryum/vue-apollo/
 [feature-flags]: ../feature_flags.md
-[default-client]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/assets/javascripts/lib/graphql.js
+[default-client]: https://gitlab.com/gitlab-org/gitlab/blob/master/app/assets/javascripts/lib/graphql.js
 [vue-test-utils]: https://vue-test-utils.vuejs.org/
 [apollo-link-state]: https://www.apollographql.com/docs/link/links/state.html
diff --git a/doc/development/fe_guide/icons.md b/doc/development/fe_guide/icons.md
index 4f687d8642e..d81a520c5f3 100644
--- a/doc/development/fe_guide/icons.md
+++ b/doc/development/fe_guide/icons.md
@@ -1,6 +1,6 @@
 # Icons and SVG Illustrations
 
-We manage our own Icon and Illustration library in the [gitlab-svgs][gitlab-svgs] repository.
+We manage our own Icon and Illustration library in the [`gitlab-svgs`][gitlab-svgs] repository.
 This repository is published on [npm][npm] and managed as a dependency via yarn.
 You can browse all available Icons and Illustrations [here][svg-preview].
 To upgrade to a new version run `yarn upgrade @gitlab/svgs`.
@@ -59,8 +59,8 @@ export default {
 <template>
   <icon
     name="issues"
-    :size="72"
-    css-classes="icon-danger"
+    :size="24"
+    class="icon-danger"
   />
 </template>
 ```
diff --git a/doc/development/fe_guide/img/graphiql_explorer_v12_4.png b/doc/development/fe_guide/img/graphiql_explorer_v12_4.png
new file mode 100644
index 00000000000..8981b37ba23
--- /dev/null
+++ b/doc/development/fe_guide/img/graphiql_explorer_v12_4.png
diff --git a/doc/development/fe_guide/index.md b/doc/development/fe_guide/index.md
index 4cccd4aa5fb..1cf798cedb6 100644
--- a/doc/development/fe_guide/index.md
+++ b/doc/development/fe_guide/index.md
@@ -5,8 +5,8 @@ across GitLab's frontend team.
 
 ## Overview
 
-GitLab is built on top of [Ruby on Rails][rails] using [Haml][haml] and also a JavaScript based Frontend with [Vue.js][vue].
-Be wary of [the limitations that come with using Hamlit][hamlit-limits]. We also use [SCSS][scss] and plain JavaScript with
+GitLab is built on top of [Ruby on Rails](https://rubyonrails.org) using [Haml][haml] and also a JavaScript based Frontend with [Vue.js](https://vuejs.org).
+Be wary of [the limitations that come with using Hamlit][hamlit-limits]. We also use [SCSS](https://sass-lang.com) and plain JavaScript with
 modern ECMAScript standards supported through [Babel][babel] and ES module support through [webpack][webpack].
 
 Working with our frontend assets requires Node (v8.10.0 or greater) and Yarn
@@ -41,6 +41,11 @@ or make changes to our frontend development guidelines.
 How we write frontend tests, run the GitLab test suite, and debug test related
 issues.
 
+## Pajamas Design System
+
+Reusable components with technical and usage guidelines can be found in our
+[Pajamas Design System](https://design.gitlab.com/).
+
 ## [Design Patterns](design_patterns.md)
 
 Common JavaScript design patterns in GitLab's codebase.
@@ -65,10 +70,6 @@ How to use GraphQL
 
 How we use SVG for our Icons and Illustrations.
 
-## [Components](components.md)
-
-How we use UI components.
-
 ## Frontend FAQ
 
 Read the [frontend's FAQ](frontend_faq.md) for common small pieces of helpful information.
@@ -83,7 +84,7 @@ changes.
 
 ### [SCSS Style Guide](style_guide_scss.md)
 
-Our SCSS conventions which are enforced through [scss-lint][scss-lint].
+Our SCSS conventions which are enforced through [scss-lint](https://github.com/sds/scss-lint).
 
 ## [Performance](performance.md)
 
@@ -102,17 +103,13 @@ Our accessibility standards and resources.
 Frontend internationalization support is described in [this document](../i18n/).
 The [externalization part of the guide](../i18n/externalization.md) explains the helpers/methods available.
 
-[rails]: http://rubyonrails.org/
 [haml]: http://haml.info/
 [hamlit]: https://github.com/k0kubun/hamlit
 [hamlit-limits]: https://github.com/k0kubun/hamlit/blob/master/REFERENCE.md#limitations
-[scss]: http://sass-lang.com/
 [babel]: https://babeljs.io/
 [webpack]: https://webpack.js.org/
 [jquery]: https://jquery.com/
-[vue]: http://vuejs.org/
 [axios]: https://github.com/axios/axios
 [airbnb-js-style-guide]: https://github.com/airbnb/javascript
-[scss-lint]: https://github.com/brigade/scss-lint
 [install]: ../../install/installation.md#4-node
 [requirements]: ../../install/requirements.md#supported-web-browsers
diff --git a/doc/development/fe_guide/performance.md b/doc/development/fe_guide/performance.md
index bcd22a170e1..6d5021c0f08 100644
--- a/doc/development/fe_guide/performance.md
+++ b/doc/development/fe_guide/performance.md
@@ -65,26 +65,27 @@ within the `pages` directory correspond to Rails controllers and actions. These
 auto-generated bundles will be automatically included on the corresponding
 pages.
 
-For example, if you were to visit [gitlab.com/gitlab-org/gitlab-foss/issues](https://gitlab.com/gitlab-org/gitlab-foss/issues),
+For example, if you were to visit <https://gitlab.com/gitlab-org/gitlab/issues>,
 you would be accessing the `app/controllers/projects/issues_controller.rb`
 controller with the `index` action. If a corresponding file exists at
 `pages/projects/issues/index/index.js`, it will be compiled into a webpack
 bundle and included on the page.
 
-> **Note:** Previously we had encouraged the use of
-> `content_for :page_specific_javascripts` within haml files, along with
-> manually generated webpack bundles. However under this new system you should
-> not ever need to manually add an entry point to the `webpack.config.js` file.
->
-> **Tip:**
-> If you are unsure what controller and action corresponds to a given page, you
-> can find this out by inspecting `document.body.dataset.page` within your
-> browser's developer console while on any page within gitlab.
+NOTE: **Note:**
+Previously we had encouraged the use of
+`content_for :page_specific_javascripts` within haml files, along with
+manually generated webpack bundles. However under this new system you should
+not ever need to manually add an entry point to the `webpack.config.js` file.
+
+TIP: **Tip:**
+If you are unsure what controller and action corresponds to a given page, you
+can find this out by inspecting `document.body.dataset.page` within your
+browser's developer console while on any page within GitLab.
 
 #### Important Considerations
 
 - **Keep Entry Points Lite:**
-  Page-specific javascript entry points should be as lite as possible.  These
+  Page-specific JavaScript entry points should be as lite as possible.  These
   files are exempt from unit tests, and should be used primarily for
   instantiation and dependency injection of classes and methods that live in
   modules outside of the entry point script.  Just import, read the DOM,
@@ -165,14 +166,12 @@ General tips:
 
 ## Additional Resources
 
-- [WebPage Test][web-page-test] for testing site loading time and size.
+- [WebPage Test](https://www.webpagetest.org) for testing site loading time and size.
 - [Google PageSpeed Insights][pagespeed-insights] grades web pages and provides feedback to improve the page.
-- [Profiling with Chrome DevTools][google-devtools-profiling]
+- [Profiling with Chrome DevTools](https://developers.google.com/web/tools/chrome-devtools/)
 - [Browser Diet][browser-diet] is a community-built guide that catalogues practical tips for improving web page performance.
 
-[web-page-test]: http://www.webpagetest.org/
 [pagespeed-insights]: https://developers.google.com/speed/pagespeed/insights/
-[google-devtools-profiling]: https://developers.google.com/web/tools/chrome-devtools/profile/?hl=en
 [browser-diet]: https://browserdiet.com/
 [high-perf-animations]: https://www.html5rocks.com/en/tutorials/speed/high-performance-animations/
 [flip]: https://aerotwist.com/blog/flip-your-animations/
diff --git a/doc/development/fe_guide/security.md b/doc/development/fe_guide/security.md
index 47ac87fc895..7dba61d6b45 100644
--- a/doc/development/fe_guide/security.md
+++ b/doc/development/fe_guide/security.md
@@ -63,7 +63,7 @@ External fonts, CSS, and JavaScript should never be used with the exception of
 Google Analytics and Piwik - and only when the instance has enabled it. Assets
 should always be hosted and served locally from the GitLab instance. Embedded
 resources via `iframes` should never be used except in certain circumstances
-such as with ReCaptcha, which cannot be used without an `iframe`.
+such as with reCAPTCHA, which cannot be used without an `iframe`.
 
 ## Avoiding inline scripts and styles
 
diff --git a/doc/development/fe_guide/style_guide_js.md b/doc/development/fe_guide/style_guide_js.md
index db076243812..306b19c6e5d 100644
--- a/doc/development/fe_guide/style_guide_js.md
+++ b/doc/development/fe_guide/style_guide_js.md
@@ -7,7 +7,7 @@ See the relevant style guides for our guidelines and for information on linting:
 We defer to [Airbnb][airbnb-js-style-guide] on most style-related
 conventions and enforce them with eslint.
 
-See [our current .eslintrc](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/.eslintrc.yml) for specific rules and patterns.
+See [our current .eslintrc](https://gitlab.com/gitlab-org/gitlab/blob/master/.eslintrc.yml) for specific rules and patterns.
 
 ### Common
 
@@ -287,7 +287,7 @@ See [our current .eslintrc](https://gitlab.com/gitlab-org/gitlab-foss/blob/maste
 
 #### CSS classes used for JavaScript
 
-1. If the class is being used in Javascript it needs to be prepend with `js-`
+1. If the class is being used in JavaScript it needs to be prepend with `js-`
 
    ```html
    // bad
@@ -693,7 +693,7 @@ Useful links:
    $('span').tooltip('_fixTitle');
    ```
 
-### The Javascript/Vue Accord
+### The JavaScript/Vue Accord
 
 The goal of this accord is to make sure we are all on the same page.
 
@@ -713,7 +713,7 @@ The goal of this accord is to make sure we are all on the same page.
 - [SCSS](style_guide_scss.md)
 
 [airbnb-js-style-guide]: https://github.com/airbnb/javascript
-[eslintrc]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/.eslintrc
+[eslintrc]: https://gitlab.com/gitlab-org/gitlab/blob/master/.eslintrc
 [eslint-plugin-vue]: https://github.com/vuejs/eslint-plugin-vue
 [eslint-plugin-vue-rules]: https://github.com/vuejs/eslint-plugin-vue#bulb-rules
 [vue-order]: https://github.com/vuejs/eslint-plugin-vue/blob/master/docs/rules/order-in-components.md
diff --git a/doc/development/fe_guide/style_guide_scss.md b/doc/development/fe_guide/style_guide_scss.md
index d5af19e0ea4..07c87920dab 100644
--- a/doc/development/fe_guide/style_guide_scss.md
+++ b/doc/development/fe_guide/style_guide_scss.md
@@ -13,12 +13,12 @@ led by the [GitLab UI WG](https://gitlab.com/gitlab-com/www-gitlab-com/merge_req
 #### Where are utility classes defined?
 
 - [Bootstrap's Utility Classes](https://getbootstrap.com/docs/4.3/utilities/)
-- [`common.scss`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/assets/stylesheets/framework/common.scss) (old)
-- [`utilities.scss`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/assets/stylesheets/utilities.scss) (new)
+- [`common.scss`](https://gitlab.com/gitlab-org/gitlab/blob/master/app/assets/stylesheets/framework/common.scss) (old)
+- [`utilities.scss`](https://gitlab.com/gitlab-org/gitlab/blob/master/app/assets/stylesheets/utilities.scss) (new)
 
 #### Where should I put new utility classes?
 
-New utility classes should be added to [`utilities.scss`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/assets/stylesheets/utilities.scss). Existing classes include:
+New utility classes should be added to [`utilities.scss`](https://gitlab.com/gitlab-org/gitlab/blob/master/app/assets/stylesheets/utilities.scss). Existing classes include:
 
 | Name | Pattern | Example |
 |------|---------|---------|
@@ -27,8 +27,8 @@ New utility classes should be added to [`utilities.scss`](https://gitlab.com/git
 | Font size | `.text-{size}` | `.text-2` |
 
 - `{variant}` is one of 'primary', 'secondary', 'success', 'warning', 'error'
-- `{shade}` is on of the shades listed on [colors](https://design.gitlab.com/foundations/colors/)
-- `{size}` is a number from 1-6 from our [Type scale](https://design.gitlab.com/foundations/typography)
+- `{shade}` is on of the shades listed on [colors](https://design.gitlab.com/product-foundations/colors/)
+- `{size}` is a number from 1-6 from our [Type scale](https://design.gitlab.com/product-foundations/typography)
 
 #### When should I create component classes?
 
@@ -41,13 +41,13 @@ This encourages an organic growth of component classes and prevents the creation
 
 Examples of component classes that were created using "utility-first" include:
 
-- [`.circle-icon-container`](https://gitlab.com/gitlab-org/gitlab-foss/blob/579fa8b8ec7eb38d40c96521f517c9dab8c3b97a/app/assets/stylesheets/framework/icons.scss#L85)
-- [`.d-flex-center`](https://gitlab.com/gitlab-org/gitlab-foss/blob/900083d89cd6af391d26ab7922b3f64fa2839bef/app/assets/stylesheets/framework/common.scss#L425)
+- [`.circle-icon-container`](https://gitlab.com/gitlab-org/gitlab/blob/579fa8b8ec7eb38d40c96521f517c9dab8c3b97a/app/assets/stylesheets/framework/icons.scss#L85)
+- [`.d-flex-center`](https://gitlab.com/gitlab-org/gitlab/blob/900083d89cd6af391d26ab7922b3f64fa2839bef/app/assets/stylesheets/framework/common.scss#L425)
 
 Inspiration:
 
-- <https://tailwindcss.com/docs/utility-first>
-- <https://tailwindcss.com/docs/extracting-components>
+- <https://tailwindcss.com/docs/utility-first/>
+- <https://tailwindcss.com/docs/extracting-components/>
 
 ### Naming
 
@@ -236,7 +236,7 @@ Before adding a new variable for a color or a size, guarantee:
 
 ## Linting
 
-We use [SCSS Lint][scss-lint] to check for style guide conformity. It uses the
+We use [SCSS Lint](https://github.com/sds/scss-lint) to check for style guide conformity. It uses the
 ruleset in `.scss-lint.yml`, which is located in the home directory of the
 project.
 
@@ -245,7 +245,7 @@ scss_lint` in the GitLab directory. SCSS Lint will also run in GitLab CI to
 catch any warnings.
 
 If the Rake task is throwing warnings you don't understand, SCSS Lint's
-documentation includes [a full list of their linters][scss-lint-documentation].
+documentation includes [a full list of their linters][scss-lint-documentation](https://github.com/sds/scss-lint/blob/master/lib/scss_lint/linter/README.md).
 
 ### Fixing issues
 
@@ -260,7 +260,7 @@ Note that this won't fix every problem, but it should fix a majority.
 ### Ignoring issues
 
 If you want a line or set of lines to be ignored by the linter, you can use
-`// scss-lint:disable RuleName` ([more info][disabling-linters]):
+`// scss-lint:disable RuleName` ([more info](https://github.com/sds/scss-lint#disabling-linters-via-source)):
 
 ```scss
 // This lint rule is disabled because it is supported only in Chrome/Safari
@@ -279,6 +279,3 @@ guide is ignored in this instance.
 [csscomb]: https://github.com/csscomb/csscomb.js
 [node]: https://github.com/nodejs/node
 [npm]: https://www.npmjs.com/
-[scss-lint]: https://github.com/brigade/scss-lint
-[scss-lint-documentation]: https://github.com/brigade/scss-lint/blob/master/lib/scss_lint/linter/README.md
-[disabling-linters]: https://github.com/brigade/scss-lint#disabling-linters-via-source
diff --git a/doc/development/fe_guide/vue.md b/doc/development/fe_guide/vue.md
index 396467b47d1..bca24e6ee0b 100644
--- a/doc/development/fe_guide/vue.md
+++ b/doc/development/fe_guide/vue.md
@@ -1,6 +1,6 @@
 # Vue
 
-To get started with Vue, read through [their documentation][vue-docs].
+To get started with Vue, read through [their documentation](https://vuejs.org/v2/guide/).
 
 ## Examples
 
@@ -104,6 +104,51 @@ document.addEventListener('DOMContentLoaded', () => new Vue({
 }));
 ```
 
+#### Accessing feature flags
+
+Use Vue's [provide/inject](https://vuejs.org/v2/api/#provide-inject) mechanism
+to make feature flags available to any descendant components in a Vue
+application. The `glFeatures` object is already provided in `commons/vue.js`, so
+only the mixin is required to utilize the flags:
+
+```javascript
+// An arbitrary descendant component
+
+import glFeatureFlagsMixin from '~/vue_shared/mixins/gl_feature_flags_mixin';
+
+export default {
+  // ...
+  mixins: [glFeatureFlagsMixin()],
+  // ...
+  created() {
+    if (this.glFeatures.myFlag) {
+      // ...
+    }
+  },
+}
+```
+
+This approach has a few benefits:
+
+- Arbitrarily deeply nested components can opt-in and access the flag without
+  intermediate components being aware of it (c.f. passing the flag down via
+  props).
+- Good testability, since the flag can be provided to `mount`/`shallowMount`
+  from `vue-test-utils` as easily as a prop.
+
+  ```javascript
+  import { shallowMount } from '@vue/test-utils';
+
+  shallowMount(component, {
+    provide: {
+      glFeatures: { myFlag: true },
+    },
+  });
+  ```
+
+- No need to access a global variable, except in the application's
+  [entry point](#accessing-the-gl-object).
+
 ### A folder for Components
 
 This folder holds all components that are specific of this new feature.
@@ -245,7 +290,6 @@ One should apply to be a Vue.js expert by opening an MR when the Merge Request's
 - Vuex code follows the [documented pattern](vuex.md#actions-pattern-request-and-receive-namespaces)
 - Knowledge about the existing Vue and Vuex applications and existing reusable components
 
-[vue-docs]: http://vuejs.org/guide/index.html
 [issue-boards]: https://gitlab.com/gitlab-org/gitlab-foss/tree/master/app/assets/javascripts/boards
 [environments-table]: https://gitlab.com/gitlab-org/gitlab-foss/tree/master/app/assets/javascripts/environments
 [page_specific_javascript]: ./performance.md#page-specific-javascript
@@ -253,5 +297,5 @@ One should apply to be a Vue.js expert by opening an MR when the Merge Request's
 [state-management]: https://vuejs.org/v2/guide/state-management.html#Simple-State-Management-from-Scratch
 [one-way-data-flow]: https://vuejs.org/v2/guide/components.html#One-Way-Data-Flow
 [vue-test]: https://vuejs.org/v2/guide/unit-testing.html
-[flux]: https://facebook.github.io/flux
+[flux]: https://facebook.github.io/flux/
 [axios]: https://github.com/axios/axios
diff --git a/doc/development/fe_guide/vuex.md b/doc/development/fe_guide/vuex.md
index bb131746ecf..20abf4fcb3e 100644
--- a/doc/development/fe_guide/vuex.md
+++ b/doc/development/fe_guide/vuex.md
@@ -232,7 +232,7 @@ import { mapGetters } from 'vuex';
 
 ### `mutation_types.js`
 
-From [vuex mutations docs][vuex-mutations]:
+From [vuex mutations docs](https://vuex.vuejs.org/guide/mutations.html):
 > It is a commonly seen pattern to use constants for mutation types in various Flux implementations. This allows the code to take advantage of tooling like linters, and putting all constants in a single file allows your collaborators to get an at-a-glance view of what mutations are possible in the entire application.
 
 ```javascript
@@ -336,7 +336,7 @@ export default {
 
 #### Testing Vuex concerns
 
-Refer to [vuex docs][vuex-testing] regarding testing Actions, Getters and Mutations.
+Refer to [vuex docs](https://vuex.vuejs.org/guide/testing.html) regarding testing Actions, Getters and Mutations.
 
 #### Testing components that need a store
 
@@ -396,6 +396,3 @@ export default () => {};
 ```
 
 [vuex-docs]: https://vuex.vuejs.org
-[vuex-structure]: https://vuex.vuejs.org/en/structure.html
-[vuex-mutations]: https://vuex.vuejs.org/en/mutations.html
-[vuex-testing]: https://vuex.vuejs.org/en/testing.html
diff --git a/doc/development/feature_flags/controls.md b/doc/development/feature_flags/controls.md
index 739f4207e27..f22c3bb1e37 100644
--- a/doc/development/feature_flags/controls.md
+++ b/doc/development/feature_flags/controls.md
@@ -1,9 +1,11 @@
-# Access for enabling a feature flag in production
+# Feature flag controls
 
-In order to be able to turn on/off features behind feature flags in any of the
+## Access
+
+To be able to turn on/off features behind feature flags in any of the
 GitLab Inc. provided environments such as staging and production, you need to
-have access to the chatops bot. Chatops bot is currently running on the ops instance,
-which is different from GitLab.com or dev.gitlab.org.
+have access to the [Chatops](../chatops_on_gitlabcom.md) bot. The Chatops bot
+is currently running on the ops instance, which is different from <https://gitlab.com> or <https://dev.gitlab.org>.
 
 Follow the Chatops document to [request access](../chatops_on_gitlabcom.md#requesting-access).
 
@@ -14,6 +16,19 @@ run:
 /chatops run feature --help
 ```
 
+## Where to run commands
+
+To increase visibility, we recommend that GitLab team members run feature flag
+related Chatops commands within certain slack channels based on the environment
+and related feature. For the [staging](https://staging.gitlab.com)
+and [development](https://dev.gitlab.org) environments of GitLab.com,
+the commands should run in a channel for the stage the feature is relevant too.
+
+For example, use the `#s_monitor` channel for features developed by the
+Monitor stage, Health group.
+
+For all production environment Chatops commands, use the `#production` channel.
+
 ## Rolling out changes
 
 When the changes are deployed to the environments it is time to start
@@ -28,7 +43,7 @@ easier to measure the impact of both separately.
 GitLab's feature library (using
 [Flipper](https://github.com/jnunemaker/flipper), and covered in the [Feature
 Flags process](process.md) guide) supports rolling out changes to a percentage of
-users. This in turn can be controlled using [GitLab chatops](../../ci/chatops/README.md).
+users. This in turn can be controlled using [GitLab Chatops](../../ci/chatops/README.md).
 
 For an up to date list of feature flag commands please see [the source
 code](https://gitlab.com/gitlab-com/chatops/blob/master/lib/chatops/commands/feature.rb).
@@ -37,9 +52,9 @@ Note that all the examples in that file must be preceded by
 
 If you get an error "Whoops! This action is not allowed. This incident
 will be reported." that means your Slack account is not allowed to
-change feature flags or you do not [have access](#access-for-enabling-a-feature-flag-in-production).
+change feature flags or you do not [have access](#access).
 
-### Enabling feature for staging and dev.gitlab.org
+### Enabling feature for preproduction testing
 
 As a first step in a feature rollout, you should enable the feature on <https://staging.gitlab.com>
 and <https://dev.gitlab.org>.
@@ -64,7 +79,7 @@ there for any exceptions while testing your feature after enabling the feature f
 Once you are confident enough that these environments are in a good state with your
 feature enabled, you can roll out the change to GitLab.com.
 
-## Enabling feature for GitLab.com
+### Enabling a feature for GitLab.com
 
 Similar to above, to enable a feature for 25% of all users, run the following in
 Slack:
@@ -91,11 +106,11 @@ sure it is clearly communicated to your team, and the Production team if you
 anticipate any potential problems.
 
 Feature gates can also be actor based, for example a feature could first be
-enabled for only the `gitlab-ce` project. The project is passed by supplying a
+enabled for only the `gitlab` project. The project is passed by supplying a
 `--project` flag:
 
 ```
-/chatops run feature set --project=gitlab-org/gitlab-ce some_feature true
+/chatops run feature set --project=gitlab-org/gitlab some_feature true
 ```
 
 For groups the `--group` flag is available:
@@ -114,10 +129,17 @@ merge request has to be picked into a stable branch, make sure to also add the
 appropriate "Pick into X" label (e.g. "Pick into XX.X").
 See [the process document](process.md#including-a-feature-behind-feature-flag-in-the-final-release) for further details.
 
-When a feature gate has been removed from the code base, the value still exists
-in the database.
-This can be removed through ChatOps:
+When a feature gate has been removed from the code base, the feature
+record still exists in the database that the flag was deployed too.
+The record can be deleted once the MR is deployed to each environment:
 
+```sh
+/chatops run feature delete some_feature --dev
+/chatops run feature delete some_feature --staging
 ```
+
+Then, you can delete it from production after the MR is deployed to prod:
+
+```sh
 /chatops run feature delete some_feature
 ```
diff --git a/doc/development/feature_flags/development.md b/doc/development/feature_flags/development.md
index b338a191f76..929c9b1c71c 100644
--- a/doc/development/feature_flags/development.md
+++ b/doc/development/feature_flags/development.md
@@ -109,6 +109,9 @@ if ( gon.features.vimBindings ) {
 The name of the feature flag in JavaScript will always be camelCased, meaning
 that checking for `gon.features.vim_bindings` would not work.
 
+See the [Vue guide](../fe_guide/vue.md#accessing-feature-flags) for details about
+how to access feature flags in a Vue component.
+
 ### Specs
 
 In the test environment `Feature.enabled?` is stubbed to always respond to `true`,
diff --git a/doc/development/file_storage.md b/doc/development/file_storage.md
index 8d486df9a8a..47a6babe8bc 100644
--- a/doc/development/file_storage.md
+++ b/doc/development/file_storage.md
@@ -146,4 +146,4 @@ end
 [CarrierWave]: https://github.com/carrierwaveuploader/carrierwave
 [Hashed Storage]: ../administration/repository_storage_types.md
 [all-in-one rake task]: ../administration/raketasks/uploads/migrate.md
-[category list]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/tasks/gitlab/uploads/migrate.rake
+[category list]: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/tasks/gitlab/uploads/migrate.rake
diff --git a/doc/development/filtering_by_label.md b/doc/development/filtering_by_label.md
index 6aa7e7a5293..32df54eafd3 100644
--- a/doc/development/filtering_by_label.md
+++ b/doc/development/filtering_by_label.md
@@ -79,7 +79,7 @@ it did not improve query performance.
 
 ## Attempt B: Denormalize using an array column
 
-Having [removed MySQL support in GitLab 12.1](https://about.gitlab.com/2019/06/27/removing-mysql-support/),
+Having [removed MySQL support in GitLab 12.1](https://about.gitlab.com/blog/2019/06/27/removing-mysql-support/),
 using [Postgres's arrays](https://www.postgresql.org/docs/9.6/arrays.html) became more
 tractable as we didn't have to support two databases. We discussed denormalizing
 the `label_links` table for querying in
diff --git a/doc/development/gitaly.md b/doc/development/gitaly.md
index 792ddeed201..64f283f69d9 100644
--- a/doc/development/gitaly.md
+++ b/doc/development/gitaly.md
@@ -15,9 +15,9 @@ In May 2019, Bob Van Landuyt hosted a [Deep Dive] on GitLab's [Gitaly project] a
 
 ## Beginner's guide
 
-Start by reading the gitaly repository's
+Start by reading the Gitaly repository's
 [Beginner's guide to Gitaly contributions](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/beginners_guide.md).
-It describes how to setup gitaly, the various components of gitaly and what they do, and how to run its test suites.
+It describes how to set up Gitaly, the various components of Gitaly and what they do, and how to run its test suites.
 
 ## Developing new Git features
 
@@ -41,14 +41,14 @@ disk access (e.g. Rugged, `git`, `rm -rf`) anywhere outside
 The process for adding new Gitaly features is:
 
 - exploration / prototyping
-- design and create a new Gitaly RPC [in gitaly-proto](https://gitlab.com/gitlab-org/gitaly-proto)
-- release a new version of gitaly-proto
+- design and create a new Gitaly RPC in [`gitaly-proto`](https://gitlab.com/gitlab-org/gitaly-proto)
+- release a new version of `gitaly-proto`
 - write implementation and tests for the RPC [in Gitaly](https://gitlab.com/gitlab-org/gitaly), in Go or Ruby
 - release a new version of Gitaly
 - write client code in GitLab CE/EE, GitLab Workhorse or GitLab Shell that calls the new Gitaly RPC
 
 These steps often overlap. It is possible to use an unreleased version
-of Gitaly and gitaly-proto during testing and development.
+of Gitaly and `gitaly-proto` during testing and development.
 
 - See the [Gitaly repo](https://gitlab.com/gitlab-org/gitaly/blob/master/CONTRIBUTING.md#development-and-testing-with-a-custom-gitaly-proto) for instructions on writing server side code with an unreleased protocol.
 - See [below](#running-tests-with-a-locally-modified-version-of-gitaly) for instructions on running GitLab CE tests with a modified version of Gitaly.
@@ -58,7 +58,7 @@ of Gitaly and gitaly-proto during testing and development.
 
 It is possible to implement and test RPC's in Gitaly using Ruby code,
 in
-[gitaly-ruby](https://gitlab.com/gitlab-org/gitaly/tree/master/ruby).
+[`gitaly-ruby`](https://gitlab.com/gitlab-org/gitaly/tree/master/ruby).
 This should make it easier to contribute for developers who are less
 comfortable writing Go code.
 
@@ -234,7 +234,7 @@ Here are the steps to gate a new feature in Gitaly behind a feature flag.
    }
    ```
 
-1. Create prometheus metrics:
+1. Create Prometheus metrics:
 
    ```go
    var findAllTagsRequests = prometheus.NewCounterVec(
diff --git a/doc/development/go_guide/index.md b/doc/development/go_guide/index.md
index 1e230a54023..33dd9dd9b6f 100644
--- a/doc/development/go_guide/index.md
+++ b/doc/development/go_guide/index.md
@@ -62,8 +62,8 @@ file and ask your manager to review and merge.
 
 ```yaml
 projects:
-  gitlab-ee: reviewer go
-  gitlab-ce: reviewer go
+  gitlab: reviewer go
+  gitlab-foss: reviewer go
 ```
 
 ## Code style and format
diff --git a/doc/development/gotchas.md b/doc/development/gotchas.md
index e492b8ea7c9..c7eed880554 100644
--- a/doc/development/gotchas.md
+++ b/doc/development/gotchas.md
@@ -106,13 +106,16 @@ end
        Using `any_instance` to stub a method (elasticsearch_indexing) that has been defined on a prepended module (EE::ApplicationSetting) is not supported.
   ```
 
-### Alternative: `expect_next_instance_of`
+### Alternative: `expect_next_instance_of` or `allow_next_instance_of`
 
 Instead of writing:
 
 ```ruby
 # Don't do this:
 expect_any_instance_of(Project).to receive(:add_import_job)
+
+# Don't do this:
+allow_any_instance_of(Project).to receive(:add_import_job)
 ```
 
 We could write:
@@ -122,10 +125,15 @@ We could write:
 expect_next_instance_of(Project) do |project|
   expect(project).to receive(:add_import_job)
 end
+
+# Do this:
+allow_next_instance_of(Project) do |project|
+  allow(project).to receive(:add_import_job)
+end
 ```
 
-If we also want to expect the instance was initialized with some particular
-arguments, we could also pass it to `expect_next_instance_of` like:
+If we also want to initialize the instance with some particular arguments, we
+could also pass it like:
 
 ```ruby
 # Do this:
@@ -144,21 +152,19 @@ refresh_service.execute(oldrev, newrev, ref)
 
 ## Do not `rescue Exception`
 
-See ["Why is it bad style to `rescue Exception => e` in Ruby?"][Exception].
+See ["Why is it bad style to `rescue Exception => e` in Ruby?"](https://stackoverflow.com/questions/10048173/why-is-it-bad-style-to-rescue-exception-e-in-ruby).
 
 _**Note:** This rule is [enforced automatically by
-Rubocop](https://gitlab.com/gitlab-org/gitlab-foss/blob/8-4-stable/.rubocop.yml#L911-914)._
-
-[Exception]: http://stackoverflow.com/q/10048173/223897
+Rubocop](https://gitlab.com/gitlab-org/gitlab/blob/8-4-stable/.rubocop.yml#L911-914)._
 
 ## Do not use inline JavaScript in views
 
 Using the inline `:javascript` Haml filters comes with a
 performance overhead. Using inline JavaScript is not a good way to structure your code and should be avoided.
 
-_**Note:** We've [removed these two filters](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/config/initializers/hamlit.rb)
+_**Note:** We've [removed these two filters](https://gitlab.com/gitlab-org/gitlab/blob/master/config/initializers/hamlit.rb)
 in an initializer._
 
 ### Further reading
 
-- Stack Overflow: [Why you should not write inline JavaScript](http://programmers.stackexchange.com/questions/86589/why-should-i-avoid-inline-scripting)
+- Stack Overflow: [Why you should not write inline JavaScript](https://softwareengineering.stackexchange.com/questions/86589/why-should-i-avoid-inline-scripting)
diff --git a/doc/development/i18n/externalization.md b/doc/development/i18n/externalization.md
index b5e1641abcb..2f067ede70f 100644
--- a/doc/development/i18n/externalization.md
+++ b/doc/development/i18n/externalization.md
@@ -236,11 +236,11 @@ This makes use of [`Intl.DateTimeFormat`].
 - In Ruby/HAML, we have two ways of adding format to dates and times:
 
   1. **Through the `l` helper**, i.e. `l(active_session.created_at, format: :short)`. We have some predefined formats for
-     [dates](https://gitlab.com/gitlab-org/gitlab-foss/blob/v11.7.0/config/locales/en.yml#L54) and [times](https://gitlab.com/gitlab-org/gitlab-foss/blob/v11.7.0/config/locales/en.yml#L261).
+     [dates](https://gitlab.com/gitlab-org/gitlab/blob/4ab54c2233e91f60a80e5b6fa2181e6899fdcc3e/config/locales/en.yml#L54) and [times](https://gitlab.com/gitlab-org/gitlab/blob/4ab54c2233e91f60a80e5b6fa2181e6899fdcc3e/config/locales/en.yml#L262).
      If you need to add a new format, because other parts of the code could benefit from it,
-     you'll need to add it to [en.yml](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/config/locales/en.yml) file.
+     you'll need to add it to [en.yml](https://gitlab.com/gitlab-org/gitlab/blob/master/config/locales/en.yml) file.
   1. **Through `strftime`**, i.e. `milestone.start_date.strftime('%b %-d')`. We use `strftime` in case none of the formats
-     defined on [en.yml](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/config/locales/en.yml) matches the date/time
+     defined on [en.yml](https://gitlab.com/gitlab-org/gitlab/blob/master/config/locales/en.yml) matches the date/time
      specifications we need, and if there is no need to add it as a new format because is very particular (i.e. it's only used in a single view).
 
 ## Best practices
@@ -313,17 +313,22 @@ Developer documentation][mdn].
 
 ## Updating the PO files with the new content
 
-Now that the new content is marked for translation, we need to update the PO
-files with the following command:
+Now that the new content is marked for translation, we need to update
+`locale/gitlab.pot` files with the following command:
 
 ```sh
 bin/rake gettext:regenerate
 ```
 
-This command will update the `locale/gitlab.pot` file with the newly externalized
+This command will update `locale/gitlab.pot` file with the newly externalized
 strings and remove any strings that aren't used anymore. You should check this
 file in. Once the changes are on master, they will be picked up by
-[Crowdin](http://translate.gitlab.com) and be presented for translation.
+[Crowdin](https://translate.gitlab.com) and be presented for
+translation.
+
+We don't need to check in any changes to the
+`locale/[language]/gitlab.po` files. Those will be updated in a [when
+translations from Crowdin are merged](merging_translations.md).
 
 If there are merge conflicts in the `gitlab.pot` file, you can delete the file
 and regenerate it using the same command.
diff --git a/doc/development/i18n/index.md b/doc/development/i18n/index.md
index 5e4923341af..7f59d30f8f9 100644
--- a/doc/development/i18n/index.md
+++ b/doc/development/i18n/index.md
@@ -29,7 +29,7 @@ See [Externalization for GitLab](externalization.md).
 
 ### Translate strings
 
-The translation process is managed at [translate.gitlab.com](https://translate.gitlab.com)
+The translation process is managed at <https://translate.gitlab.com>
 using [Crowdin](https://crowdin.com/).
 You will need to create an account before you can submit translations.
 Once you are signed in, select the language you wish to contribute translations to.
diff --git a/doc/development/i18n/merging_translations.md b/doc/development/i18n/merging_translations.md
index 7a8046ccdd9..f5953cc5f6c 100644
--- a/doc/development/i18n/merging_translations.md
+++ b/doc/development/i18n/merging_translations.md
@@ -15,8 +15,8 @@ By default Crowdin commits translations with `[skip ci]` in the commit
 message. This is done to avoid a bunch of pipelines being run. Before
 merging translations, make sure to trigger a pipeline to validate
 translations, we have static analysis validating things Crowdin
-doesn't do. Create a [new pipeline](https://gitlab.com/gitlab-org/gitlab/pipelines/new) for the
-`master-i18n` branch.
+doesn't do. Create a new pipeline at `https://gitlab.com/gitlab-org/gitlab/pipelines/new`
+(need Developer access permissions) for the `master-i18n` branch.
 
 If there are validation errors, the easiest solution is to disapprove
 the offending string in Crowdin, leaving a comment with what is
@@ -53,7 +53,7 @@ or merged. But it won't recreate the `master-i18n` branch every
 time. To force Crowdin to recreate the branch, close any [open merge
 request](https://gitlab.com/gitlab-org/gitlab/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&author_username=gitlab-crowdin-bot)
 and delete the
-[`master-18n`](https://gitlab.com/gitlab-org/gitlab/branches/all?utf8=%E2%9C%93&search=master-i18n).
+[`master-18n`](https://gitlab.com/gitlab-org/gitlab/-/branches/all?utf8=✓&search=master-i18n).
 
 This might be needed when the merge request contains failures that
 have been fixed on master.
diff --git a/doc/development/i18n/proofreader.md b/doc/development/i18n/proofreader.md
index db15633fc73..8b3a5d893fe 100644
--- a/doc/development/i18n/proofreader.md
+++ b/doc/development/i18n/proofreader.md
@@ -57,7 +57,7 @@ are very appreciative of the work done by translators and proofreaders!
   - Paolo Falomo - [GitLab](https://gitlab.com/paolofalomo), [Crowdin](https://crowdin.com/profile/paolo.falomo)
 - Japanese
   - Hiroyuki Sato - [GitLab](https://gitlab.com/hiroponz), [Crowdin](https://crowdin.com/profile/hiroponz)
-  - Tomo Dote - [Gitlab](https://gitlab.com/fu7mu4), [Crowdin](https://crowdin.com/profile/fu7mu4)
+  - Tomo Dote - [GitLab](https://gitlab.com/fu7mu4), [Crowdin](https://crowdin.com/profile/fu7mu4)
 - Korean
   - Chang-Ho Cha - [GitLab](https://gitlab.com/changho-cha), [Crowdin](https://crowdin.com/profile/zzazang)
   - Ji Hun Oh - [GitLab](https://gitlab.com/Baw-Appie), [Crowdin](https://crowdin.com/profile/BawAppie)
@@ -128,10 +128,10 @@ are very appreciative of the work done by translators and proofreaders!
    have previously translated.
 
 1. Your request to become a proofreader will be considered on the merits of
-   your previous translations by [GitLab team members](https://about.gitlab.com/team/)
-   or [Core team members](https://about.gitlab.com/core-team/) who are fluent in
+   your previous translations by [GitLab team members](https://about.gitlab.com/company/team/)
+   or [Core team members](https://about.gitlab.com/community/core-team/) who are fluent in
    the language or current proofreaders.
-   - When a request is made for the first proofreader for a language and there are no [GitLab team members](https://about.gitlab.com/team/)
-   or [Core team members](https://about.gitlab.com/core-team/) who speak the language, we will request links to previous translation work in other communities or projects.
+   - When a request is made for the first proofreader for a language and there are no [GitLab team members](https://about.gitlab.com/company/team/)
+   or [Core team members](https://about.gitlab.com/community/core-team/) who speak the language, we will request links to previous translation work in other communities or projects.
 
 [proofreader-src]: https://gitlab.com/gitlab-org/gitlab/blob/master/doc/development/i18n/proofreader.md
diff --git a/doc/development/i18n/translation.md b/doc/development/i18n/translation.md
index 1793afcd86d..c1a6fd8983c 100644
--- a/doc/development/i18n/translation.md
+++ b/doc/development/i18n/translation.md
@@ -8,7 +8,7 @@ The first step is to get familiar with Crowdin.
 
 ### Sign In
 
-To contribute translations at [translate.gitlab.com](https://translate.gitlab.com)
+To contribute translations at <https://translate.gitlab.com>
 you must create a Crowdin account.
 You may create a new account or use any of their supported sign in services.
 
@@ -54,7 +54,7 @@ For example in French `OpenedNDaysAgo|Opened` would be translated to
 Some technical terms should be treated like proper nouns and not be translated.
 
 Technical terms that should always be in English are noted in the glossary when
-using [translate.gitlab.com](https://translate.gitlab.com).
+using <https://translate.gitlab.com>.
 
 This helps maintain a logical connection and consistency between tools (e.g.
 `git` client) and GitLab.
diff --git a/doc/development/img/memory_ruby_heap_fragmentation.png b/doc/development/img/memory_ruby_heap_fragmentation.png
new file mode 100644
index 00000000000..6567abe58bb
--- /dev/null
+++ b/doc/development/img/memory_ruby_heap_fragmentation.png
diff --git a/doc/development/import_export.md b/doc/development/import_export.md
index fcfb9bf4915..38119d9bbd0 100644
--- a/doc/development/import_export.md
+++ b/doc/development/import_export.md
@@ -31,10 +31,12 @@ Read through the current performance problems using the Import/Export below.
 Out of memory (OOM) errors are normally caused by the [Sidekiq Memory Killer](../administration/operations/sidekiq_memory_killer.md):
 
 ```bash
-SIDEKIQ_MEMORY_KILLER_MAX_RSS = 2GB in GitLab.com
+SIDEKIQ_MEMORY_KILLER_MAX_RSS = 2000000
+SIDEKIQ_MEMORY_KILLER_HARD_LIMIT_RSS = 3000000
+SIDEKIQ_MEMORY_KILLER_GRACE_TIME = 900
 ```
 
-An import status `started`, and the following sidekiq logs will signal a memory issue:
+An import status `started`, and the following Sidekiq logs will signal a memory issue:
 
 ```bash
 WARN: Work still in progress <struct with JID>
@@ -96,7 +98,8 @@ importing big projects, using a foreground import:
 ## Security
 
 The Import/Export feature is constantly updated (adding new things to export), however
-the code hasn't been refactored in a long time. We should perform a [code audit](https://gitlab.com/gitlab-org/gitlab-foss/issues/42135)
+the code hasn't been refactored in a long time. We should perform a code audit (see
+[confidential issue](../user/project/issues/confidential_issues.md) `https://gitlab.com/gitlab-org/gitlab/issues/20720`).
 to make sure its dynamic nature does not increase the number of security concerns.
 
 ### Security in the code
@@ -309,7 +312,7 @@ module Gitlab
     class Importer
       def execute
         if import_file && check_version! && restorers.all?(&:restore) && overwrite_project
-          project_tree.restored_project
+          project
         else
           raise Projects::ImportService::Error.new(@shared.errors.join(', '))
         end
diff --git a/doc/development/interacting_components.md b/doc/development/interacting_components.md
index 5e6dc8d460a..3db260d5f85 100644
--- a/doc/development/interacting_components.md
+++ b/doc/development/interacting_components.md
@@ -14,7 +14,7 @@ change that affects uploads should also be tested against [object storage],
 which is _not_ enabled by default in [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit).
 
 When working on a related feature, make sure to enable and test it
-against [Minio](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/object_storage.md).
+against [MinIO](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/object_storage.md).
 
 See also [File Storage in GitLab](file_storage.md).
 
diff --git a/doc/development/internal_api.md b/doc/development/internal_api.md
new file mode 100644
index 00000000000..b08112aacb2
--- /dev/null
+++ b/doc/development/internal_api.md
@@ -0,0 +1,328 @@
+# Internal API
+
+The internal API is used by different GitLab components, it can not be
+used by other consumers. This documentation is intended for people
+working on the GitLab codebase.
+
+This documentation does not yet include the internal api used by
+GitLab pages.
+
+## Authentication
+
+These methods are all authenticated using a shared secret. This secret
+is stored in a file at the path configured in `config/gitlab.yml` by
+default this is in the root of the rails app named
+`.gitlab_shell_secret`
+
+To authenticate using that token, clients read the contents of that
+file, and include the token Base64 encoded in a `secret_token` param
+or in the `Gitlab-Shared-Secret` header.
+
+NOTE: **Note:**
+The internal api used by GitLab pages uses a different kind of
+authentication.
+
+## Git Authentication
+
+This is called by Gitaly and GitLab-shell to check access to a
+repository.
+
+When called from GitLab-shell no changes are passed and the internal
+API replies with the information needed to pass the request on to
+Gitaly.
+
+When called from Gitaly in a `pre-receive` hook the changes are passed
+and those are validated to determine if the push is allowed.
+
+```
+POST /internal/allowed
+```
+
+| Attribute | Type   | Required | Description |
+|:----------|:-------|:---------|:------------|
+| `key_id`  | string | no       | Id of the SSH-key used to connect to GitLab-shell |
+| `username` | string | no      | Username from the certificate used to connect to GitLab-Shell |
+| `project`  | string | no (if `gl_repository` is passed) | Path to the project |
+| `gl_repository`  | string | no (if `project` is passed) | Path to the project |
+| `protocol` | string | yes     | SSH when called from GitLab-shell, HTTP or SSH when called from Gitaly |
+| `action`   | string | yes     | Git command being run (`git-upload-pack`, `git-receive-pack`, `git-upload-archive`) |
+| `changes`  | string | yes     | `<oldrev> <newrev> <refname>` when called from Gitaly, The magic string `_any` when called from GitLab Shell |
+| `check_ip` | string | no     | Ip adress from which call to GitLab Shell was made |
+
+Example request:
+
+```sh
+curl --request POST --header "Gitlab-Shared-Secret: <Base64 encoded token>" --data "key_id=11&project=gnuwget/wget2&action=git-upload-pack&protocol=ssh" http://localhost:3001/api/v4/internal/allowed
+```
+
+Example response:
+
+```
+{
+  "status": true,
+  "gl_repository": "project-3",
+  "gl_project_path": "gnuwget/wget2",
+  "gl_id": "user-1",
+  "gl_username": "root",
+  "git_config_options": [],
+  "gitaly": {
+    "repository": {
+      "storage_name": "default",
+      "relative_path": "@hashed/4e/07/4e07408562bedb8b60ce05c1decfe3ad16b72230967de01f640b7e4729b49fce.git",
+      "git_object_directory": "",
+      "git_alternate_object_directories": [],
+      "gl_repository": "project-3",
+      "gl_project_path": "gnuwget/wget2"
+    },
+    "address": "unix:/Users/bvl/repos/gitlab/gitaly.socket",
+    "token": null
+  },
+  "gl_console_messages": []
+}
+```
+
+### Known consumers
+
+- Gitaly
+- GitLab-shell
+
+## LFS Authentication
+
+This is the endpoint that gets called from GitLab-shell to provide
+information for LFS clients when the repository is accessed over SSH.
+
+| Attribute | Type   | Required | Description |
+|:----------|:-------|:---------|:------------|
+| `key_id`  | string | no       | Id of the SSH-key used to connect to GitLab-shell |
+| `username`| string | no       | Username from the certificate used to connect to GitLab-Shell |
+| `project` | string | no       | Path to the project |
+
+Example request:
+
+```sh
+curl --request POST --header "Gitlab-Shared-Secret: <Base64 encoded token>" --data "key_id=11&project=gnuwget/wget2" http://localhost:3001/api/v4/internal/lfs_authenticate
+```
+
+```
+{
+  "username": "root",
+  "lfs_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkYXRhIjp7ImFjdG9yIjoicm9vdCJ9LCJqdGkiOiIyYWJhZDcxZC0xNDFlLTQ2NGUtOTZlMi1mODllYWRiMGVmZTYiLCJpYXQiOjE1NzAxMTc2NzYsIm5iZiI6MTU3MDExNzY3MSwiZXhwIjoxNTcwMTE5NDc2fQ.g7atlBw1QMY7QEBVPE0LZ8ZlKtaRzaMRmNn41r2YITM",
+  "repository_http_path": "http://localhost:3001/gnuwget/wget2.git",
+  "expires_in": 1800
+}
+```
+
+### Known consumers
+
+- GitLab-shell
+
+## Authorized Keys Check
+
+This endpoint is called by the GitLab-shell authorized keys
+check. Which is called by OpenSSH for [fast ssh key
+lookup](../administration/operations/fast_ssh_key_lookup.md).
+
+| Attribute | Type   | Required | Description |
+|:----------|:-------|:---------|:------------|
+| `key`     | string | yes      | SSH key as passed by OpenSSH to GitLab-shell |
+
+```
+GET /internal/authorized_keys
+```
+
+Example request:
+
+```sh
+curl --request GET --header "Gitlab-Shared-Secret: <Base64 encoded secret>""http://localhost:3001/api/v4/internal/authorized_keys?key=<key as passed by OpenSSH>"
+```
+
+Example response:
+
+```
+{
+  "id": 11,
+  "title": "admin@example.com",
+  "key": "ssh-rsa ...",
+  "created_at": "2019-06-27T15:29:02.219Z"
+}
+```
+
+### Known consumers
+
+- GitLab-shell
+
+## Get user for user id or key
+
+This endpoint is used when a user performs `ssh git@gitlab.com`. It
+discovers the user associated with an SSH key.
+
+| Attribute | Type   | Required | Description |
+|:----------|:-------|:---------|:------------|
+| `key_id` | integer | no | The id of the SSH key used as found in the authorized-keys file or through the `/authorized_keys` check |
+| `username` | string | no | Username of the user being looked up, used by GitLab-shell when authenticating using a certificate |
+
+```
+GET /internal/discover
+```
+
+Example request:
+
+```sh
+curl --request GET --header "Gitlab-Shared-Secret: <Base64 encoded secret>" "http://localhost:3001/api/v4/internal/discover?key_id=7"
+```
+
+Example response:
+
+```
+{
+  "id": 7,
+  "name": "Dede Eichmann",
+  "username": "rubi"
+}
+```
+
+### Known consumers
+
+- GitLab-shell
+
+## Instance information
+
+This get's some generic information about the instance. This is used
+by Geo nodes to get information about eachother
+
+```
+GET /internal/check
+```
+
+Example request:
+
+```sh
+curl --request GET --header "Gitlab-Shared-Secret: <Base64 encoded secret>" "http://localhost:3001/api/v4/internal/check"
+```
+
+Example response:
+
+```
+{
+  "api_version": "v4",
+  "gitlab_version": "12.3.0-pre",
+  "gitlab_rev": "d69c988e6a6",
+  "redis": true
+}
+```
+
+### Known consumers
+
+- GitLab Geo
+- GitLab-shell's `bin/check`
+
+## Get new 2FA recovery codes using an SSH key
+
+This is called from GitLab-shell and allows users to get new 2FA
+recovery codes based on their SSH key
+
+| Attribute | Type   | Required | Description |
+|:----------|:-------|:---------|:------------|
+| `key_id`  | integer | no | The id of the SSH key used as found in the authorized-keys file or through the `/authorized_keys` check |
+| `user_id` | integer | no | **Deprecated** User_id for which to generate new recovery codes |
+
+```
+GET /internal/two_factor_recovery_codes
+```
+
+Example request:
+
+```sh
+curl --request POST --header "Gitlab-Shared-Secret: <Base64 encoded secret>" --data "key_id=7" http://localhost:3001/api/v4/internal/two_factor_recovery_codes
+```
+
+Example response:
+
+```
+{
+  "success": true,
+  "recovery_codes": [
+    "d93ee7037944afd5",
+    "19d7b84862de93dd",
+    "1e8c52169195bf71",
+    "be50444dddb7ca84",
+    "26048c77d161d5b7",
+    "482d5c03d1628c47",
+    "d2c695e309ce7679",
+    "dfb4748afc4f12a7",
+    "0e5f53d1399d7979",
+    "af04d5622153b020"
+  ]
+}
+```
+
+### Known consumers
+
+- GitLab-shell
+
+## Incrementing counter on pre-receive
+
+This is called from the Gitaly hooks increasing the reference counter
+for a push that might be accepted.
+
+| Attribute | Type   | Required | Description |
+|:----------|:-------|:---------|:------------|
+| `gl_repository` | string | yes | repository identifier for the repository receiving the push |
+
+```
+POST /internal/pre_receive
+```
+
+Example request:
+
+```sh
+curl --request POST --header "Gitlab-Shared-Secret: <Base64 encoded secret>" --data "gl_repository=project-7" http://localhost:3001/api/v4/internal/pre_receive
+```
+
+Example response:
+
+```
+{
+  "reference_counter_increased": true
+}
+```
+
+## Notify Post Receive [UNUSED] ?
+
+## PostReceive
+
+Called from Gitaly after a receiving a push. This triggers the
+`PostReceive`-worker in sidekiq, processes the passed push options and
+builds the response including messages that need to be displayed to
+the user.
+
+| Attribute | Type   | Required | Description |
+|:----------|:-------|:---------|:------------|
+| `identifier` | string | yes | `user-[id]` or `key-[id]` Identifying the user performing the push |
+| `gl_repository` | string | yes | identifier of the repository being pushed to |
+| `push_options` | [string] | no | array of push options |
+| `changes` | string | no | refs to be updated in the push in the format `oldrev newrev refname\n`. |
+
+```
+POST /internal/post_receive
+```
+
+Example Request:
+
+```sh
+curl --request POST --header "Gitlab-Shared-Secret: <Base64 encoded secret>" --data "gl_repository=project-7" --data "identifier=user-1" --data "changes=0000000000000000000000000000000000000000 fd9e76b9136bdd9fe217061b497745792fe5a5ee gh-pages\n"  http://localhost:3001/api/v4/internal/post_receive
+```
+
+Example response:
+
+```
+{
+  "messages": [
+    {
+      "message": "Hello from post-receive",
+      "type": "alert"
+    }
+  ],
+  "reference_counter_decreased": true
+}
+```
diff --git a/doc/development/issuable-like-models.md b/doc/development/issuable-like-models.md
new file mode 100644
index 00000000000..ce19fd77496
--- /dev/null
+++ b/doc/development/issuable-like-models.md
@@ -0,0 +1,19 @@
+# Issuable-like Rails models utilities
+
+GitLab Rails codebase contains several models that hold common functionality and behave similarly to an [Issue]. Other
+examples of `Issuable`s are [Merge Requests] and [Epics].
+
+This guide accumulates guidelines on working with such Rails models.
+
+## Important text fields
+
+There are max length constraints for the most important text fields for `Issuable`s:
+
+- `title`: 255 chars
+- `title_html`: 800 chars
+- `description`: 1 megabyte
+- `description_html`: 5 megabytes
+
+[Issue]: https://docs.gitlab.com/ee/user/project/issues
+[Merge Requests]: https://docs.gitlab.com/ee/user/project/merge_requests
+[Epics]: https://docs.gitlab.com/ee/user/group/epics
diff --git a/doc/development/kubernetes.md b/doc/development/kubernetes.md
index 5265e5b11cd..82aa02ac75d 100644
--- a/doc/development/kubernetes.md
+++ b/doc/development/kubernetes.md
@@ -29,12 +29,12 @@ We use the [`kubeclient`](https://rubygems.org/gems/kubeclient) gem to
 perform Kubernetes API calls. As the `kubeclient` gem does not support
 different API Groups (e.g. `apis/rbac.authorization.k8s.io`) from a
 single client, we have created a wrapper class,
-[`Gitlab::Kubernetes::KubeClient`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/kubernetes/kube_client.rb)
+[`Gitlab::Kubernetes::KubeClient`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/kubernetes/kube_client.rb)
 that will enable you to achieve this.
 
 Selected Kubernetes API groups are currently supported. Do add support
 for new API groups or methods to
-[`Gitlab::Kubernetes::KubeClient`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/kubernetes/kube_client.rb)
+[`Gitlab::Kubernetes::KubeClient`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/kubernetes/kube_client.rb)
 if you need to use them. New API groups or API group versions can be
 added to `SUPPORTED_API_GROUPS` - internally, this will create an
 internal client for that group. New methods can be added as a delegation
@@ -44,17 +44,16 @@ to the relevant internal client.
 
 All calls to the Kubernetes API must be in a background process. Do not
 perform Kubernetes API calls within a web request as this will block
-unicorn and can easily lead to a Denial Of Service (DoS) attack in GitLab as
+Unicorn and can easily lead to a Denial Of Service (DoS) attack in GitLab as
 the Kubernetes cluster response times are outside of our control.
 
 The easiest way to ensure your calls happen a background process is to
-delegate any such work to happen in a [sidekiq
-worker](sidekiq_style_guide.md).
+delegate any such work to happen in a [Sidekiq worker](sidekiq_style_guide.md).
 
 There are instances where you would like to make calls to Kubernetes and
 return the response and as such a background worker does not seem to be
 a good fit. For such cases you should make use of [reactive
-caching](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/models/concerns/reactive_caching.rb).
+caching](https://gitlab.com/gitlab-org/gitlab/blob/master/app/models/concerns/reactive_caching.rb).
 For example:
 
 ```ruby
@@ -72,7 +71,7 @@ For example:
 ### Testing
 
 We have some Webmock stubs in
-[`KubernetesHelpers`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/spec/support/helpers/kubernetes_helpers.rb)
+[`KubernetesHelpers`](https://gitlab.com/gitlab-org/gitlab/blob/master/spec/support/helpers/kubernetes_helpers.rb)
 which can help with mocking out calls to Kubernetes API in your tests.
 
 ## Security
@@ -87,7 +86,7 @@ a cluster.
 Mitigation strategies include:
 
 1. Not allowing redirects to attacker controller resources:
-   [`Kubeclient::KubeClient`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/kubernetes/kube_client.rb#)
+   [`Kubeclient::KubeClient`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/kubernetes/kube_client.rb#)
    can be configured to disallow any redirects by passing in
    `http_max_redirects: 0` as an option.
 1. Not exposing error messages: by doing so, we
@@ -111,7 +110,7 @@ Logs related to the Kubernetes integration can be found in
 GDK install, this will be present in `log/kubernetes.log`.
 
 Some services such as
-[`Clusters::Applications::InstallService`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/services/clusters/applications/install_service.rb#L18)
+[`Clusters::Applications::InstallService`](https://gitlab.com/gitlab-org/gitlab/blob/master/app/services/clusters/applications/install_service.rb#L18)
 rescues `StandardError` which can make it harder to debug issues in an
 development environment. The current workaround is to temporarily
 comment out the `rescue` in your local development source.
diff --git a/doc/development/licensing.md b/doc/development/licensing.md
index 538c8f2039b..40ff604c7c4 100644
--- a/doc/development/licensing.md
+++ b/doc/development/licensing.md
@@ -46,9 +46,9 @@ More detailed information on how the gem and its commands work is available in t
 
 Libraries with the following licenses are acceptable for use:
 
-- [The MIT License][MIT] (the MIT Expat License specifically): The MIT License requires that the license itself is included with all copies of the source. It is a permissive (non-copyleft) license as defined by the Open Source Initiative.
-- [LGPL][LGPL] (version 2, version 3): GPL constraints regarding modification and redistribution under the same license are not required of projects using an LGPL library, only upon modification of the LGPL-licensed library itself.
-- [Apache 2.0 License][apache-2]: A permissive license that also provides an express grant of patent rights from contributors to users.
+- [The MIT License](https://choosealicense.com/licenses/mit/) (the MIT Expat License specifically): The MIT License requires that the license itself is included with all copies of the source. It is a permissive (non-copyleft) license as defined by the Open Source Initiative.
+- [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) (version 2, version 3): GPL constraints regarding modification and redistribution under the same license are not required of projects using an LGPL library, only upon modification of the LGPL-licensed library itself.
+- [Apache 2.0 License](https://choosealicense.com/licenses/apache-2.0/): A permissive license that also provides an express grant of patent rights from contributors to users.
 - [Ruby 1.8 License][ruby-1.8]: Dual-licensed under either itself or the GPLv2, defer to the Ruby License itself. Acceptable because of point 3b: "You may distribute the software in object code or binary form, provided that you do at least ONE of the following: b) accompany the distribution with the machine-readable source of the software."
 - [Ruby 1.9 License][ruby-1.9]: Dual-licensed under either itself or the BSD 2-Clause License, defer to BSD 2-Clause.
 - [BSD 2-Clause License][BSD-2-Clause]: A permissive (non-copyleft) license as defined by the Open Source Initiative.
@@ -62,8 +62,8 @@ Libraries with the following licenses are acceptable for use:
 
 Libraries with the following licenses require legal approval for use:
 
-- [GNU GPL][GPL] (version 1, [version 2][GPLv2], [version 3][GPLv3], or any future versions): GPL-licensed libraries cannot be linked to from non-GPL projects.
-- [GNU AGPLv3][AGPLv3]: AGPL-licensed libraries cannot be linked to from non-GPL projects.
+- [GNU GPL](https://choosealicense.com/licenses/gpl-3.0/) (version 1, [version 2][GPLv2], [version 3][GPLv3], or any future versions): GPL-licensed libraries cannot be linked to from non-GPL projects.
+- [GNU AGPLv3](https://choosealicense.com/licenses/agpl-3.0/): AGPL-licensed libraries cannot be linked to from non-GPL projects.
 - [Open Software License (OSL)][OSL]: is a copyleft license. In addition, the FSF [recommend against its use][OSL-GNU].
 - [Facebook BSD + PATENTS][Facebook]: is a 3-clause BSD license with a patent grant that has been deemed [Category X][x-list] by the Apache foundation.
 - [WTFPL][WTFPL]: is a public domain dedication [rejected by the OSI (3.2)][WTFPL-OSI]. Also has a strong language which is not in accordance with our diversity policy.
@@ -109,19 +109,14 @@ Dependencies which are only used in development or test environment are exempt f
 [CE]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/LICENSE
 [EE]: https://gitlab.com/gitlab-org/gitlab/blob/master/LICENSE
 [license_finder]: https://github.com/pivotal/LicenseFinder
-[MIT]: http://choosealicense.com/licenses/mit/
-[LGPL]: http://choosealicense.com/licenses/lgpl-3.0/
-[apache-2]: http://choosealicense.com/licenses/apache-2.0/
 [ruby-1.8]: https://github.com/ruby/ruby/blob/ruby_1_8_6/COPYING
 [ruby-1.9]: https://www.ruby-lang.org/en/about/license.txt
 [BSD-2-Clause]: https://opensource.org/licenses/BSD-2-Clause
 [BSD-3-Clause]: https://opensource.org/licenses/BSD-3-Clause
 [ISC]: https://opensource.org/licenses/ISC
 [CC0]: https://creativecommons.org/publicdomain/zero/1.0/
-[GPL]: http://choosealicense.com/licenses/gpl-3.0/
 [GPLv2]: http://www.gnu.org/licenses/gpl-2.0.txt
 [GPLv3]: http://www.gnu.org/licenses/gpl-3.0.txt
-[AGPLv3]: http://choosealicense.com/licenses/agpl-3.0/
 [GNU-GPL-FAQ]: http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
 [OSI-GPL]: https://opensource.org/faq#linking-proprietary-code
 [OSL]: https://opensource.org/licenses/OSL-3.0
diff --git a/doc/development/merge_request_performance_guidelines.md b/doc/development/merge_request_performance_guidelines.md
index 6f1baad3a2d..4456e5e6d18 100644
--- a/doc/development/merge_request_performance_guidelines.md
+++ b/doc/development/merge_request_performance_guidelines.md
@@ -41,7 +41,7 @@ about the impact.
 
 Sometimes it's hard to assess the impact of a merge request. In this case you
 should ask one of the merge request reviewers to review your changes. You can
-find a list of these reviewers at <https://about.gitlab.com/team/>. A reviewer
+find a list of these reviewers at <https://about.gitlab.com/company/team/>. A reviewer
 in turn can request a performance specialist to review the changes.
 
 ## Query Counts
@@ -68,7 +68,7 @@ end
 This will end up running one query for every object to update. This code can
 easily overload a database given enough rows to update or many instances of this
 code running in parallel. This particular problem is known as the
-["N+1 query problem"](http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations). You can write a test with [QueryRecoder](query_recorder.md) to detect this and prevent regressions.
+["N+1 query problem"](https://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations). You can write a test with [QueryRecoder](query_recorder.md) to detect this and prevent regressions.
 
 In this particular case the workaround is fairly easy:
 
@@ -171,4 +171,4 @@ Caching data per transaction can be done using
 [RequestStore](https://github.com/steveklabnik/request_store) (use
 `Gitlab::SafeRequestStore` to avoid having to remember to check
 `RequestStore.active?`). Caching data in Redis can be done using [Rails' caching
-system](http://guides.rubyonrails.org/caching_with_rails.html).
+system](https://guides.rubyonrails.org/caching_with_rails.html).
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md
index 5fded9e3aed..20d705136b2 100644
--- a/doc/development/migration_style_guide.md
+++ b/doc/development/migration_style_guide.md
@@ -286,6 +286,48 @@ For a small table (such as an empty one or one with less than `1,000` records),
 use `add_column` and `change_column_default` in a single-transaction migration,
 combining it with other operations that don't require `disable_ddl_transaction!`.
 
+## Changing the column default
+
+One might think that changing a default column with `change_column_default` is an
+expensive and disruptive operation for larger tables, but in reality it's not.
+
+Take the following migration as an example:
+
+```ruby
+class DefaultRequestAccessGroups < ActiveRecord::Migration[5.2]
+  include Gitlab::Database::MigrationHelpers
+
+  DOWNTIME = false
+
+  def up
+    change_column_default :namespaces, :request_access_enabled, true
+  end
+
+  def down
+    change_column_default :namespaces, :request_access_enabled, false
+  end
+end
+```
+
+Migration above changes the default column value of one of our largest
+tables: `namespaces`. This can be translated to:
+
+```sql
+ALTER TABLE namespaces
+ALTER COLUMN request_access_enabled
+DEFAULT false
+```
+
+In this particular case, the default value exists and we're just changing the metadata for
+`request_access_enabled` column, which does not imply a rewrite of all the existing records
+in the `namespaces` table. Only when creating a new column with a default, all the records are going be rewritten.
+
+NOTE: **Note:**  A faster [ALTER TABLE ADD COLUMN with a non-null default](https://www.depesz.com/2018/04/04/waiting-for-postgresql-11-fast-alter-table-add-column-with-a-non-null-default/)
+was introduced on PostgresSQL 11.0, removing the need of rewritting the table when a new column with a default value is added.
+
+For the reasons mentioned above, it's safe to use `change_column_default` in a single-transaction migration
+without requiring `disable_ddl_transaction!`.
+
 ## Updating an existing column
 
 To update an existing column to a particular value, you can use
@@ -375,6 +417,7 @@ timestamps with timezones:
 
 - `add_timestamps_with_timezone`
 - `timestamps_with_timezone`
+- `datetime_with_timezone`
 
 This ensures all timestamps have a time zone specified. This, in turn, means
 existing timestamps won't suddenly use a different timezone when the system's
@@ -406,10 +449,7 @@ end
 
 ## Testing
 
-Make sure that your migration works for databases with data. An
-empty database does not guarantee that your migration is correct.
-
-Make sure your migration can be reversed.
+See the [Testing Rails migrations](testing_guide/testing_migrations_guide.md) style guide.
 
 ## Data migration
 
@@ -481,5 +521,5 @@ by an integer. For example: `users` would turn into `users0`
 ### Moving migrations from EE to CE
 
 When migrations need to be moved from GitLab Enterprise Edition to GitLab Community Edition,
-a migration file should be moved from `ee/db/{post_,}migrate` directory in the `gitlab-ee` project to `db/{post_,}migrate` directory in the `gitlab-ce` project. This way
+a migration file should be moved from `ee/db/{post_,}migrate` directory in the `gitlab` project to `db/{post_,}migrate` directory in the `gitlab-foss` project. This way
 the schema number remains intact, there is no need to modify old migrations, and proper columns, tables or data are added in the Community Edition.
diff --git a/doc/development/namespaces_storage_statistics.md b/doc/development/namespaces_storage_statistics.md
index f8aea10097d..648f189a826 100644
--- a/doc/development/namespaces_storage_statistics.md
+++ b/doc/development/namespaces_storage_statistics.md
@@ -14,11 +14,11 @@ storage consumed by a group, and allow easy management.
 ## Problem
 
 In GitLab, we update the project storage statistics through a
-[callback](https://gitlab.com/gitlab-org/gitlab-foss/blob/v12.2.0.pre/app/models/project.rb#L90)
+[callback](https://gitlab.com/gitlab-org/gitlab/blob/4ab54c2233e91f60a80e5b6fa2181e6899fdcc3e/app/models/project.rb#L97)
 every time the project is saved.
 
 The summary of those statistics per namespace is then retrieved
-by [`Namespaces#with_statistics`](https://gitlab.com/gitlab-org/gitlab-foss/blob/v12.2.0.pre/app/models/namespace.rb#L70) scope. Analyzing this query we noticed that:
+by [`Namespaces#with_statistics`](https://gitlab.com/gitlab-org/gitlab/blob/4ab54c2233e91f60a80e5b6fa2181e6899fdcc3e/app/models/namespace.rb#L70) scope. Analyzing this query we noticed that:
 
 - It takes up to `1.2` seconds for namespaces with over `15k` projects.
 - It can't be analyzed with [ChatOps](chatops_on_gitlabcom.md), as it times out.
diff --git a/doc/development/new_fe_guide/development/components.md b/doc/development/new_fe_guide/development/components.md
index cebdc87eab9..7cccd4b5b1b 100644
--- a/doc/development/new_fe_guide/development/components.md
+++ b/doc/development/new_fe_guide/development/components.md
@@ -7,7 +7,7 @@ We have a lot of graphing libraries in our codebase to render graphs. In an effo
 We chose D3 as our library going forward because of the following features:
 
 - [Tree shaking webpack capabilities](https://github.com/d3/d3/blob/master/CHANGES.md#changes-in-d3-40).
-- [Compatible with vue.js as well as vanilla javascript](https://github.com/d3/d3/blob/master/CHANGES.md#changes-in-d3-40).
+- [Compatible with vue.js as well as vanilla JavaScript](https://github.com/d3/d3/blob/master/CHANGES.md#changes-in-d3-40).
 
 D3 is very popular across many projects outside of GitLab:
 
diff --git a/doc/development/new_fe_guide/development/performance.md b/doc/development/new_fe_guide/development/performance.md
index d41239693bf..4a85c04d8cf 100644
--- a/doc/development/new_fe_guide/development/performance.md
+++ b/doc/development/new_fe_guide/development/performance.md
@@ -2,9 +2,9 @@
 
 ## Monitoring
 
-We have a performance dashboard available in one of our [grafana instances](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://www.sitespeed.io/) every 6 hours. These changes are displayed after a set number of pages are aggregated.
+We have a performance dashboard available in one of our [Grafana instances](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://www.sitespeed.io/) every 6 hours. These changes are displayed after a set number of pages are aggregated.
 
-These pages can be found inside a text file in the gitlab-build-images [repository](https://gitlab.com/gitlab-org/gitlab-build-images) called [gitlab.txt](https://gitlab.com/gitlab-org/gitlab-build-images/blob/master/scripts/gitlab.txt)
+These pages can be found inside a text file in the [`gitlab-build-images` repository](https://gitlab.com/gitlab-org/gitlab-build-images) called [`gitlab.txt`](https://gitlab.com/gitlab-org/gitlab-build-images/blob/master/scripts/gitlab.txt)
 Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing urls of pages from this text file. Please have a [frontend monitoring expert](https://about.gitlab.com/company/team/) review your changes before assigning to a maintainer of the `gitlab-build-images` project. The changes will go live on the next scheduled run after the changes are merged into `master`.
 
 There are 3 recommended high impact metrics to review on each page:
diff --git a/doc/development/new_fe_guide/modules/dirty_submit.md b/doc/development/new_fe_guide/modules/dirty_submit.md
index 2ad6b8b60a3..dd7d5d61c4d 100644
--- a/doc/development/new_fe_guide/modules/dirty_submit.md
+++ b/doc/development/new_fe_guide/modules/dirty_submit.md
@@ -8,7 +8,7 @@ Prevent submitting forms with no changes.
 
 Currently handles `input`, `textarea` and `select` elements.
 
-Also, see [the code](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/assets/javascripts/dirty_submit/)
+Also, see [the code](https://gitlab.com/gitlab-org/gitlab/blob/master/app/assets/javascripts/dirty_submit/)
 within the GitLab project.
 
 ## Usage
diff --git a/doc/development/new_fe_guide/style/javascript.md b/doc/development/new_fe_guide/style/javascript.md
index b742d567f41..d31edcb372d 100644
--- a/doc/development/new_fe_guide/style/javascript.md
+++ b/doc/development/new_fe_guide/style/javascript.md
@@ -188,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](https://eslint.org/docs/rules/no-new)
+- [class-method-use-this](https://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`.
diff --git a/doc/development/performance.md b/doc/development/performance.md
index 39fcc8ff806..786b590ec70 100644
--- a/doc/development/performance.md
+++ b/doc/development/performance.md
@@ -251,6 +251,36 @@ These results can also be placed into a PostgreSQL database by setting the
 `RSPEC_PROFILING_POSTGRES_URL` variable. This is used to profile the test suite
 when running in the CI environment.
 
+## Memory profiling
+
+One of the reasons of the increased memory footprint could be Ruby memory fragmentation.
+
+To diagnose it, you can visualize Ruby heap as described in [this post by Aaron Patterson](https://tenderlovemaking.com/2017/09/27/visualizing-your-ruby-heap.html).
+
+To start, you want to dump the heap of the process you are investigating to a JSON file.  
+
+You need to run the command inside the process you are exploring, you may do that with `rbtrace`.  
+`rbtrace` is already present in GitLab `Gemfile`, you just need to require it.  
+It could be achieved running webserver or Sidekiq with the environment variable set to `ENABLE_RBTRACE=1`.
+
+To get the heap dump:
+
+```ruby
+bundle exec rbtrace -p <PID> -e 'File.open("heap.json", "wb") { |t| ObjectSpace.dump_all(output: t) }'
+```
+
+Having the JSON, you finally could render a picture using the script [provided by Aaron](https://gist.github.com/tenderlove/f28373d56fdd03d8b514af7191611b88) or similar:
+
+```sh
+ruby heapviz.rb heap.json
+```
+  
+Fragmented Ruby heap snapshot could look like this:
+
+![Ruby heap fragmentation](img/memory_ruby_heap_fragmentation.png)
+
+Memory fragmentation could be reduced by tuning GC parameters as described in [this post by Nate Berkopec](https://www.speedshop.co/2017/12/04/malloc-doubles-ruby-memory.html), which should be considered as a tradeoff, as it may affect overall performance of memory allocation and GC cycles.
+
 ## Importance of Changes
 
 When working on performance improvements, it's important to always ask yourself
diff --git a/doc/development/pipelines.md b/doc/development/pipelines.md
index 448fb0f9f5a..5954de03db4 100644
--- a/doc/development/pipelines.md
+++ b/doc/development/pipelines.md
@@ -27,6 +27,7 @@ The current stages are:
 - `review`: This stage includes jobs that deploy the GitLab and Docs Review Apps.
 - `qa`: This stage includes jobs that perform QA tasks against the Review App
   that is deployed in the previous stage.
+- `notification`: This stage includes jobs that sends notifications about pipeline status.
 - `post-test`: This stage includes jobs that build reports or gather data from
   the previous stages' jobs (e.g. coverage, Knapsack metadata etc.).
 - `pages`: This stage includes a job that deploys the various reports as
@@ -37,7 +38,7 @@ The current stages are:
 ## Default image
 
 The default image is currently
-`dev.gitlab.org:5005/gitlab/gitlab-build-images:ruby-2.6.3-golang-1.11-git-2.22-chrome-73.0-node-12.x-yarn-1.16-postgresql-9.6-graphicsmagick-1.3.33`.
+`gitlab.com/gitlab-org/gitlab-build-images:ruby-2.6.3-golang-1.11-git-2.22-chrome-73.0-node-12.x-yarn-1.16-postgresql-9.6-graphicsmagick-1.3.33`.
 It includes Ruby 2.6.3, Go 1.11, Git 2.22, Chrome 73, Node 12, Yarn 1.16,
 PostgreSQL 9.6, and Graphics Magick 1.3.33.
 
@@ -57,11 +58,10 @@ each pipeline includes the following [variables](../ci/variables/README.md):
 - `RAILS_ENV: "test"`
 - `NODE_ENV: "test"`
 - `SIMPLECOV: "true"`
-- `GIT_DEPTH: "20"`
+- `GIT_DEPTH: "50"`
 - `GIT_SUBMODULE_STRATEGY: "none"`
 - `GET_SOURCES_ATTEMPTS: "3"`
 - `KNAPSACK_RSPEC_SUITE_REPORT_PATH: knapsack/${CI_PROJECT_NAME}/rspec_report-master.json`
-- `EE_KNAPSACK_RSPEC_SUITE_REPORT_PATH: knapsack/${CI_PROJECT_NAME}/rspec_report-master-ee.json`
 - `FLAKY_RSPEC_SUITE_REPORT_PATH: rspec_flaky/report-suite.json`
 - `BUILD_ASSETS_IMAGE: "false"`
 - `ES_JAVA_OPTS: "-Xms256m -Xmx256m"`
@@ -92,9 +92,17 @@ These common definitions are:
   for `master` and auto-deploy branches.
 - `.only-review-schedules`: Same as `.only-review` but also restrict a job to
   only run for [schedules](../user/project/pipelines/schedules.md).
-- `.use-pg`: Allows a job to use the `postgres:9.6.14` and `redis:alpine` services.
-- `.use-pg-10`: Allows a job to use the `postgres:10.9` and `redis:alpine` services.
+- `.only-canonical-schedules`: Only creates a job for scheduled pipelines in
+  the `gitlab-org/gitlab` and `gitlab-org/gitlab-foss` projects
+- `.use-pg9`: Allows a job to use the `postgres:9.6` and `redis:alpine` services.
+- `.use-pg10`: Allows a job to use the `postgres:10.9` and `redis:alpine` services.
+- `.use-pg9-ee`: Same as `.use-pg9` but also use the
+  `docker.elastic.co/elasticsearch/elasticsearch:5.6.12` services.
+- `.use-pg10-ee`: Same as `.use-pg10` but also use the
+  `docker.elastic.co/elasticsearch/elasticsearch:5.6.12` services.
 - `.only-ee`: Only creates a job for the `gitlab` project.
+- `.only-ee-as-if-foss`: Same as `.only-ee` but simulate the FOSS project by
+  setting the `FOSS_ONLY='1'` environment variable.
 
 ## Changes detection
 
@@ -107,6 +115,7 @@ from a commit or MR by extending from the following CI definitions:
 - `.only-qa-changes`: Allows a job to only be created upon QA-related changes.
 - `.only-docs-changes`: Allows a job to only be created upon docs-related changes.
 - `.only-code-qa-changes`: Allows a job to only be created upon code-related or QA-related changes.
+- `.only-graphql-changes`: Allows a job to only be created upon graphql-related changes.
 
 **See <https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/ci/global.gitlab-ci.yml>
 for the list of exact patterns.**
@@ -119,7 +128,7 @@ execute jobs out of order for the following jobs:
 ```mermaid
 graph RL;
   A[setup-test-env];
-  B["gitlab:assets:compile<br/>(master only)"];
+  B["gitlab:assets:compile pull-push-cache<br/>(master only)"];
   C[gitlab:assets:compile pull-cache];
   D["cache gems<br/>(master and tags only)"];
   E[review-build-cng];
@@ -128,48 +137,51 @@ graph RL;
   G2["schedule:review-deploy<br/>(master only)"];
   H[karma];
   I[jest];
-  J["compile-assets<br/>(master only)"];
+  J["compile-assets pull-push-cache<br/>(master only)"];
   K[compile-assets pull-cache];
   L[webpack-dev-server];
   M[coverage];
   N[pages];
   O[static-analysis];
-  P["package-and-qa-manual:master<br/>(master schedule only)"];
+  P["schedule:package-and-qa<br/>(master schedule only)"];
   Q[package-and-qa];
   R[package-and-qa-manual];
+  S["RSpec<br/>(e.g. rspec unit pg9)"]
+  T[retrieve-tests-metadata];
 
 subgraph "`prepare` stage"
     A
     F
-    J
     K
+    J
+    T
     end
 
 subgraph "`test` stage"
     B --> |needs| A;
     C --> |needs| A;
     D --> |needs| A;
-    H -.-> |depends on| A;
-    H -.-> |depends on| J;
-    H -.-> |depends on| K;
-    I -.-> |depends on| A;
-    I -.-> |depends on| J;
-    I -.-> |depends on| K;
-    L -.-> |depends on| A;
-    L -.-> |depends on| J;
-    L -.-> |depends on| K;
+    H -.-> |needs and depends on| A;
+    H -.-> |needs and depends on| K;
+    I -.-> |needs and depends on| A;
+    I -.-> |needs and depends on| K;
+    L -.-> |needs and depends on| A;
+    L -.-> |needs and depends on| K;
+    O -.-> |needs and depends on| A;
+    O -.-> |needs and depends on| K;
+    S -.-> |needs and depends on| A;
+    S -.-> |needs and depends on| K;
+    S -.-> |needs and depends on| T;
     downtime_check --> |needs and depends on| A;
     db:* --> |needs| A;
     gitlab:setup --> |needs| A;
-    O -.-> |depends on| A;
-    O -.-> |depends on| B;
-    O -.-> |depends on| C;
     downtime_check --> |needs and depends on| A;
+    graphql-docs-verify --> |needs| A;
     end
 
 subgraph "`review-prepare` stage"
     E --> |needs| C;
-    X["schedule:review-build-cng<br/>(master schedule only)"] --> |needs| B;
+    X["schedule:review-build-cng<br/>(master schedule only)"] --> |needs| C;
     end
 
 subgraph "`review` stage"
@@ -182,13 +194,18 @@ subgraph "`qa` stage"
     Q --> |needs| F;
     R --> |needs| C;
     R --> |needs| F;
-    P --> |needs| B;
+    P --> |needs| C;
     P --> |needs| F;
-    review-qa-smoke -.-> |depends on| G;
-    review-qa-all -.-> |depends on| G;
-    review-qa-performance -.-> |depends on| G;
-    X2["schedule:review-performance<br/>(master only)"] -.-> |depends on| G2;
-    dast -.-> |depends on| G;
+    review-qa-smoke -.-> |needs and depends on| G;
+    review-qa-all -.-> |needs and depends on| G;
+    review-performance -.-> |needs and depends on| G;
+    X2["schedule:review-performance<br/>(master only)"] -.-> |needs and depends on| G2;
+    dast -.-> |needs and depends on| G;
+    end
+
+subgraph "`notification` stage"
+    NOTIFICATION1["schedule:package-and-qa:notify-success<br>(on_success)"] -.-> |needs| P;
+    NOTIFICATION2["schedule:package-and-qa:notify-failure<br>(on_failure)"] -.-> |needs| P;
     end
 
 subgraph "`post-test` stage"
@@ -196,7 +213,7 @@ subgraph "`post-test` stage"
     end
 
 subgraph "`pages` stage"
-    N -.-> |depends on| B;
+    N -.-> |depends on| C;
     N -.-> |depends on| H;
     N -.-> |depends on| M;
     end
diff --git a/doc/development/profiling.md b/doc/development/profiling.md
index e1d1d2e33fa..04897e770f8 100644
--- a/doc/development/profiling.md
+++ b/doc/development/profiling.md
@@ -86,8 +86,8 @@ that builds on this to add some additional niceties, such as allowing
 configuration with a single Yaml file for multiple URLs, and uploading of the
 profile and log output to S3.
 
-For GitLab.com, you can find the latest results here:
-<http://redash.gitlab.com/dashboard/gitlab-profiler-statistics>
+For GitLab.com, you can find the latest results here (restricted to GitLab Team members only):
+`https://redash.gitlab.com/dashboard/gitlab-profiler-statistics`
 
 ## Sherlock
 
diff --git a/doc/development/projections.md b/doc/development/projections.md
new file mode 100644
index 00000000000..9d5702da530
--- /dev/null
+++ b/doc/development/projections.md
@@ -0,0 +1,34 @@
+# Projections
+
+Projections are a way to define relations between files. Every file can have a
+"related" or "alternate" file. It's common to consider spec files to be
+"alternate" files to source files.
+
+## How to use it
+
+- Install an editor plugin that consumes projections
+- Copy `.projections.json.example` to `.projections.json`
+
+## How to customize it
+
+You can find a basic list of projection options in
+[projectionist.txt](https://github.com/tpope/vim-projectionist/blob/master/doc/projectionist.txt)
+
+## Which plugins can I use
+
+- vim
+  - [vim-projectionist](https://github.com/tpope/vim-projectionist)
+- VSCode
+  - [Alternate File](https://marketplace.visualstudio.com/items?itemName=will-wow.vscode-alternate-file)
+  - [projectionist](https://github.com/jarsen/projectionist)
+  - [jumpto](https://github.com/gmdayley/jumpto)
+- Atom
+  - [projectionist-atom](https://atom.io/packages/projectionist-atom)
+- Command-line
+  - [projectionist](https://github.com/glittershark/projectionist)
+
+## History
+
+This started as a
+[plugin for vim by tpope](https://github.com/tpope/vim-projectionist)
+It has since become editor-agnostic and ported to most modern editors.
diff --git a/doc/development/prometheus_metrics.md b/doc/development/prometheus_metrics.md
index eecce9f4f11..b479c053862 100644
--- a/doc/development/prometheus_metrics.md
+++ b/doc/development/prometheus_metrics.md
@@ -2,7 +2,7 @@
 
 ## Adding to the library
 
-We strive to support the 2-4 most important metrics for each common system service that supports Prometheus. If you are looking for support for a particular exporter which has not yet been added to the library, additions can be made [to the `common_metrics.yml`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/config/prometheus/common_metrics.yml) file.
+We strive to support the 2-4 most important metrics for each common system service that supports Prometheus. If you are looking for support for a particular exporter which has not yet been added to the library, additions can be made [to the `common_metrics.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/config/prometheus/common_metrics.yml) file.
 
 ### Query identifier
 
diff --git a/doc/development/python_guide/index.md b/doc/development/python_guide/index.md
index 47d9d96766c..d898351345d 100644
--- a/doc/development/python_guide/index.md
+++ b/doc/development/python_guide/index.md
@@ -27,7 +27,7 @@ To install `pyenv` on Linux, you can run the command below:
 curl https://pyenv.run | bash
 ```
 
-Alternatively, you may find `pypenv` available as a system package via your distro package manager.
+Alternatively, you may find `pyenv` available as a system package via your distro package manager.
 
 You can read more about it in: <https://github.com/pyenv/pyenv-installer#prerequisites>.
 
diff --git a/doc/development/query_recorder.md b/doc/development/query_recorder.md
index 3ed75c87f6f..81970b45bbd 100644
--- a/doc/development/query_recorder.md
+++ b/doc/development/query_recorder.md
@@ -2,7 +2,7 @@
 
 QueryRecorder is a tool for detecting the [N+1 queries problem](https://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations) from tests.
 
-> Implemented in [spec/support/query_recorder.rb](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/spec/support/helpers/query_recorder.rb) via [9c623e3e](https://gitlab.com/gitlab-org/gitlab-foss/commit/9c623e3e5d7434f2e30f7c389d13e5af4ede770a)
+> Implemented in [spec/support/query_recorder.rb](https://gitlab.com/gitlab-org/gitlab/blob/master/spec/support/helpers/query_recorder.rb) via [9c623e3e](https://gitlab.com/gitlab-org/gitlab-foss/commit/9c623e3e5d7434f2e30f7c389d13e5af4ede770a)
 
 As a rule, merge requests [should not increase query counts](merge_request_performance_guidelines.md#query-counts). If you find yourself adding something like `.includes(:author, :assignee)` to avoid having `N+1` queries, consider using QueryRecorder to enforce this with a test. Without this, a new feature which causes an additional model to be accessed will silently reintroduce the problem.
 
diff --git a/doc/development/rake_tasks.md b/doc/development/rake_tasks.md
index a144bf70a86..a6d3c008686 100644
--- a/doc/development/rake_tasks.md
+++ b/doc/development/rake_tasks.md
@@ -143,12 +143,6 @@ This will compile and minify all JavaScript and CSS assets and copy them along
 with all other frontend assets (images, fonts, etc) into `/public/assets` where
 they can be easily inspected.
 
-## Generate API documentation for project services (e.g. Slack)
-
-```
-bundle exec rake services:doc
-```
-
 ## Updating Emoji Aliases
 
 To update the Emoji aliases file (used for Emoji autocomplete) you must run the
@@ -226,3 +220,26 @@ bundle exec rake db:obsolete_ignored_columns
 ```
 
 Feel free to remove their definitions from their `ignored_columns` definitions.
+
+## Update GraphQL Documentation
+
+To generate GraphQL documentation based on the GitLab schema, run:
+
+```shell
+bundle exec rake gitlab:graphql:compile_docs
+```
+
+In its current state, the rake task:
+
+- Generates output for GraphQL objects.
+- Places the output at `doc/api/graphql/reference/index.md`.
+
+This uses some features from `graphql-docs` gem like its schema parser and helper methods.
+The docs generator code comes from our side giving us more flexibility, like using Haml templates and generating Markdown files.
+
+To edit the template used, please take a look at `lib/gitlab/graphql/docs/templates/default.md.haml`.
+The actual renderer is at `Gitlab::Graphql::Docs::Renderer`.
+
+`@parsed_schema` is an instance variable that the `graphql-docs` gem expects to have available.
+`Gitlab::Graphql::Docs::Helper` defines the `object` method we currently use. This is also where you
+should implement any new methods for new types you'd like to display.
diff --git a/doc/development/repository_mirroring.md b/doc/development/repository_mirroring.md
index dc51bf80e92..8521d6fcd30 100644
--- a/doc/development/repository_mirroring.md
+++ b/doc/development/repository_mirroring.md
@@ -2,10 +2,9 @@
 
 ## Deep Dive
 
-In December 2018, Tiago Botelho hosted a [Deep Dive] on GitLab's [Pull Repository Mirroring functionality] to share his domain specific knowledge with anyone who may work in this part of the code base in the future. You can find the [recording on YouTube], and the slides on [Google Slides] and in [PDF]. Everything covered in this deep dive was accurate as of GitLab 11.6, and while specific details may have changed since then, it should still serve as a good introduction.
+In December 2018, Tiago Botelho hosted a [Deep Dive] on GitLab's [Pull Repository Mirroring functionality] to share his domain specific knowledge with anyone who may work in this part of the code base in the future. You can find the [recording on YouTube], and the slides in [PDF]. Everything covered in this deep dive was accurate as of GitLab 11.6, and while specific details may have changed since then, it should still serve as a good introduction.
 
 [Deep Dive]: https://gitlab.com/gitlab-org/create-stage/issues/1
 [Pull Repository Mirroring functionality]: ../workflow/repository_mirroring.md#pulling-from-a-remote-repository-starter
 [recording on YouTube]: https://www.youtube.com/watch?v=sSZq0fpdY-Y
-[Google Slides]: https://docs.google.com/presentation/d/17BTT6M6RyNRckV4wTt-dr07nIfBvD325_xVBoLtSoPM/edit?usp=sharing
 [PDF]: https://gitlab.com/gitlab-org/create-stage/uploads/8693404888a941fd851f8a8ecdec9675/Gitlab_Create_-_Pull_Mirroring_Deep_Dive.pdf
diff --git a/doc/development/routing.md b/doc/development/routing.md
index 0b95477974b..e0741e78821 100644
--- a/doc/development/routing.md
+++ b/doc/development/routing.md
@@ -57,9 +57,9 @@ client or other software requires something different.
 Examples:
 
 ```
-gitlab-org/gitlab-ce/-/activity
-gitlab-org/gitlab-ce/-/jobs/123
-gitlab-org/gitlab-ce/-/settings/repository
+gitlab-org/gitlab/-/activity
+gitlab-org/gitlab/-/jobs/123
+gitlab-org/gitlab/-/settings/repository
 gitlab-org/serverless/runtimes/-/settings/repository
 ```
 
diff --git a/doc/development/shell_commands.md b/doc/development/shell_commands.md
index 1300c99622e..aa326cbdd34 100644
--- a/doc/development/shell_commands.md
+++ b/doc/development/shell_commands.md
@@ -5,9 +5,9 @@ These guidelines are meant to make your code more reliable _and_ secure.
 
 ## References
 
-- [Google Ruby Security Reviewer's Guide](https://code.google.com/p/ruby-security/wiki/Guide)
+- [Google Ruby Security Reviewer's Guide](https://code.google.com/archive/p/ruby-security/wikis/Guide.wiki)
 - [OWASP Command Injection](https://www.owasp.org/index.php/Command_Injection)
-- [Ruby on Rails Security Guide Command Line Injection](http://guides.rubyonrails.org/security.html#command-line-injection)
+- [Ruby on Rails Security Guide Command Line Injection](https://guides.rubyonrails.org/security.html#command-line-injection)
 
 ## Use File and FileUtils instead of shell commands
 
@@ -87,7 +87,7 @@ $ cat -- -l
 hello
 ```
 
-In the GitLab codebase, we avoid the option/argument ambiguity by _always_ using `--`.
+In the GitLab codebase, we avoid the option/argument ambiguity by _always_ using `--` for commands that support it.
 
 ```ruby
 # Wrong
diff --git a/doc/development/sidekiq_style_guide.md b/doc/development/sidekiq_style_guide.md
index 8e268224c98..d52a3e652e3 100644
--- a/doc/development/sidekiq_style_guide.md
+++ b/doc/development/sidekiq_style_guide.md
@@ -27,7 +27,7 @@ While different workers cannot share a queue, they can share a queue namespace.
 Defining a queue namespace for a worker makes it possible to start a Sidekiq
 process that automatically handles jobs for all workers in that namespace,
 without needing to explicitly list all their queue names. If, for example, all
-workers that are managed by sidekiq-cron use the `cronjob` queue namespace, we
+workers that are managed by `sidekiq-cron` use the `cronjob` queue namespace, we
 can spin up a Sidekiq process specifically for these kinds of scheduled jobs.
 If a new worker using the `cronjob` namespace is added later on, the Sidekiq
 process will automatically pick up jobs for that worker too (after having been
@@ -61,6 +61,56 @@ the extra jobs will take resources away from jobs from workers that were already
 there, if the resources available to the Sidekiq process handling the namespace
 are not adjusted appropriately.
 
+## Feature Categorization
+
+Each Sidekiq worker, or one of its ancestor classes, must declare a
+`feature_category` attribute. This attribute maps each worker to a feature
+category. This is done for error budgeting, alert routing, and team attribution
+for Sidekiq workers.
+
+The declaration uses the `feature_category` class method, as shown below.
+
+```ruby
+class SomeScheduledTaskWorker
+  include ApplicationWorker
+
+  # Declares that this feature is part of the
+  # `continuous_integration` feature category
+  feature_category :continuous_integration
+
+  # ...
+end
+```
+
+The list of value values can be found in the file `config/feature_categories.yml`.
+This file is, in turn generated from the [`stages.yml` from the GitLab Company Handbook
+source](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml).
+
+### Updating `config/feature_categories.yml`
+
+Occassionally new features will be added to GitLab stages. When this occurs, you
+can automatically update `config/feature_categories.yml` by running
+`scripts/update-feature-categories`. This script will fetch and parse
+[`stages.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml)
+and generare a new version of the file, which needs to be checked into source control.
+
+### Excluding Sidekiq workers from feature categorization
+
+A few Sidekiq workers, that are used across all features, cannot be mapped to a
+single category. These should be declared as such using the `feature_category_not_owned!`
+ declaration, as shown below:
+
+```ruby
+class SomeCrossCuttingConcernWorker
+  include ApplicationWorker
+
+  # Declares that this worker does not map to a feature category
+  feature_category_not_owned!
+
+  # ...
+end
+```
+
 ## Tests
 
 Each Sidekiq worker must be tested using RSpec, just like any other class. These
diff --git a/doc/development/sql.md b/doc/development/sql.md
index 2584dcfb4ca..8a8204ffe87 100644
--- a/doc/development/sql.md
+++ b/doc/development/sql.md
@@ -74,7 +74,7 @@ USING GIN(column_name gin_trgm_ops);
 ```
 
 The key here is the `GIN(column_name gin_trgm_ops)` part. This creates a [GIN
-index][gin-index] with the operator class set to `gin_trgm_ops`. These indexes
+index](https://www.postgresql.org/docs/current/gin.html) with the operator class set to `gin_trgm_ops`. These indexes
 _can_ be used by `ILIKE` / `LIKE` and can lead to greatly improved performance.
 One downside of these indexes is that they can easily get quite large (depending
 on the amount of data indexed).
@@ -247,8 +247,6 @@ WHERE EXISTS (
 )
 ```
 
-[gin-index]: http://www.postgresql.org/docs/current/static/gin.html
-
 ## `.find_or_create_by` is not atomic
 
 The inherent pattern with methods like `.find_or_create_by` and
diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md
index a8cbf3aaa5b..32e079f915c 100644
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@@ -51,7 +51,7 @@ bundle exec rspec spec/[path]/[to]/[spec].rb
   methods.
 - Use `context` to test branching logic.
 - Try to match the ordering of tests to the ordering within the class.
-- Try to follow the [Four-Phase Test][four-phase-test] pattern, using newlines
+- Try to follow the [Four-Phase Test](https://thoughtbot.com/blog/four-phase-test) pattern, using newlines
   to separate phases.
 - Use `Gitlab.config.gitlab.host` rather than hard coding `'localhost'`
 - Don't assert against the absolute value of a sequence-generated attribute (see
@@ -62,8 +62,6 @@ bundle exec rspec spec/[path]/[to]/[spec].rb
   use a Capyabara matcher beforehand (e.g. `find('.js-foo')`) to ensure the element actually exists.
 - Use `focus: true` to isolate parts of the specs you want to run.
 
-[four-phase-test]: https://robots.thoughtbot.com/four-phase-test
-
 ### System / Feature tests
 
 NOTE: **Note:** Before writing a new system test, [please consider **not**
@@ -115,7 +113,7 @@ Finished in 34.51 seconds (files took 0.76702 seconds to load)
 1 example, 0 failures
 ```
 
-Note: `live_debug` only works on javascript enabled specs.
+Note: `live_debug` only works on JavaScript enabled specs.
 
 #### Run `:js` spec in a visible browser
 
@@ -160,7 +158,7 @@ really fast since:
 
 - Gems loading is skipped
 - Rails app boot is skipped
-- gitlab-shell and Gitaly setup are skipped
+- GitLab Shell and Gitaly setup are skipped
 - Test repositories setup are skipped
 
 `fast_spec_helper` also support autoloading classes that are located inside the
@@ -185,7 +183,7 @@ instead of 30+ seconds in case of a regular `spec_helper`.
 ### `let` variables
 
 GitLab's RSpec suite has made extensive use of `let`(along with it strict, non-lazy
-version `let!`) variables to reduce duplication. However, this sometimes [comes at the cost of clarity][lets-not],
+version `let!`) variables to reduce duplication. However, this sometimes [comes at the cost of clarity](https://thoughtbot.com/blog/lets-not),
 so we need to set some guidelines for their use going forward:
 
 - `let!` variables are preferable to instance variables. `let` variables
@@ -204,10 +202,51 @@ so we need to set some guidelines for their use going forward:
   order is required, otherwise `let` will suffice. Remember that `let` is lazy and won't
   be evaluated until it is referenced.
 
-[lets-not]: https://robots.thoughtbot.com/lets-not
+### Common test setup
+
+In some cases, there is no need to recreate the same object for tests
+again for each example. For example, a project and a guest of that project
+is needed to test issues on the same project, one project and user will do for the entire file.
+This can be achieved by using
+[`let_it_be`](https://test-prof.evilmartians.io/#/let_it_be) variables and the
+[`before_all`](https://test-prof.evilmartians.io/#/before_all) hook
+from the [`test-prof` gem](https://rubygems.org/gems/test-prof).
+
+```
+let_it_be(:project) { create(:project) }
+let_it_be(:user) { create(:user) }
+
+before_all do
+  project.add_guest(user)
+end
+```
+
+This will result in only one `Project`, `User`, and `ProjectMember` created for this context.
+
+`let_it_be` and `before_all` are also available within nested contexts. Cleanup after the context
+is handled automatically using a transaction rollback.
+
+Note that if you modify an object defined inside a `let_it_be` block,
+then you will need to reload the object as needed, or specify the `reload`
+option to reload for every example.
+
+```
+let_it_be(:project, reload: true) { create(:project) }
+```
+
+You can also specify the `refind` option as well to completely load a
+new object.
+
+```
+let_it_be(:project, refind: true) { create(:project) }
+```
 
 ### `set` variables
 
+NOTE: **Note:**
+We are incrementally removing `set` in favour of `let_it_be`. See the
+[removal issue](https://gitlab.com/gitlab-org/gitlab/issues/27922).
+
 In some cases there is no need to recreate the same object for tests again for
 each example. For example, a project is needed to test issues on the same
 project, one project will do for the entire file. This can be achieved by using
@@ -308,7 +347,7 @@ them unspecified, and look up the value after the row is created.
 
 #### Redis
 
-GitLab stores two main categories of data in Redis: cached items, and sidekiq
+GitLab stores two main categories of data in Redis: cached items, and Sidekiq
 jobs.
 
 In most specs, the Rails cache is actually an in-memory store. This is replaced
@@ -532,7 +571,7 @@ GitLab uses [factory_bot] as a test fixture replacement.
 - There should be only one top-level factory definition per file.
 - FactoryBot methods are mixed in to all RSpec groups. This means you can (and
   should) call `create(...)` instead of `FactoryBot.create(...)`.
-- Make use of [traits] to clean up definitions and usages.
+- Make use of [traits](https://www.rubydoc.info/gems/factory_bot/file/GETTING_STARTED.md#Traits) to clean up definitions and usages.
 - When defining a factory, don't define attributes that are not required for the
   resulting record to pass validation.
 - When instantiating from a factory, don't supply attributes that aren't
@@ -541,7 +580,6 @@ GitLab uses [factory_bot] as a test fixture replacement.
   [See example](https://gitlab.com/gitlab-org/gitlab-foss/commit/0b8cefd3b2385a21cfed779bd659978c0402766d).
 
 [factory_bot]: https://github.com/thoughtbot/factory_bot
-[traits]: http://www.rubydoc.info/gems/factory_bot/file/GETTING_STARTED.md#Traits
 
 ### Fixtures
 
@@ -549,9 +587,9 @@ All fixtures should be placed under `spec/fixtures/`.
 
 ### Repositories
 
-Testing some functionality, e.g., merging a merge request, requires a git
+Testing some functionality, e.g., merging a merge request, requires a Git
 repository with a certain state to be present in the test environment. GitLab
-maintains the [gitlab-test](https://gitlab.com/gitlab-org/gitlab-test)
+maintains the [`gitlab-test`](https://gitlab.com/gitlab-org/gitlab-test)
 repository for certain common cases - you can ensure a copy of the repository is
 used with the `:repository` trait for project factories:
 
diff --git a/doc/development/testing_guide/ci.md b/doc/development/testing_guide/ci.md
index d9f66a827de..5bdd0a69d7f 100644
--- a/doc/development/testing_guide/ci.md
+++ b/doc/development/testing_guide/ci.md
@@ -4,27 +4,24 @@
 
 Our current CI parallelization setup is as follows:
 
-1. The `knapsack` job in the prepare stage that is supposed to ensure we have a
-   `knapsack/${CI_PROJECT_NAME}/rspec_report-master.json` file:
-   - The `knapsack/${CI_PROJECT_NAME}/rspec_report-master.json` file is fetched
-     from S3, if it's not here we initialize the file with `{}`.
-1. Each `rspec x y` job are run with `knapsack rspec` and should have an evenly
-   distributed share of tests:
-   - It works because the jobs have access to the
-     `knapsack/${CI_PROJECT_NAME}/rspec_report-master.json` since the "artifacts
-     from all previous stages are passed by default".
+1. The `retrieve-tests-metadata` job in the `prepare` stage ensures we have a
+   `knapsack/report-master.json` file:
+   - The `knapsack/report-master.json` file is fetched from S3, if it's not here
+     we initialize the file with `{}`.
+1. Each `[rspec|rspec-ee] [unit|integration|system|geo] n m` job are run with
+   `knapsack rspec` and should have an evenly distributed share of tests:
+   - It works because the jobs have access to the `knapsack/report-master.json`
+     since the "artifacts from all previous stages are passed by default".
    - the jobs set their own report path to
-     `KNAPSACK_REPORT_PATH=knapsack/${CI_PROJECT_NAME}/${JOB_NAME[0]}_node_${CI_NODE_INDEX}_${CI_NODE_TOTAL}_report.json`.
+     `"knapsack/${TEST_TOOL}_${TEST_LEVEL}_${DATABASE}_${CI_NODE_INDEX}_${CI_NODE_TOTAL}_report.json"`.
    - if knapsack is doing its job, test files that are run should be listed under
      `Report specs`, not under `Leftover specs`.
-1. The `update-knapsack` job takes all the
-   `knapsack/${CI_PROJECT_NAME}/${JOB_NAME[0]}_node_${CI_NODE_INDEX}_${CI_NODE_TOTAL}_report.json`
-   files from the `rspec x y` jobs and merge them all together into a single
-   `knapsack/${CI_PROJECT_NAME}/rspec_report-master.json` file that is then
-   uploaded to S3.
-
-After that, the next pipeline will use the up-to-date
-`knapsack/${CI_PROJECT_NAME}/rspec_report-master.json` file.
+1. The `update-tests-metadata` job (which only runs on scheduled pipelines for
+   [the canonical project](https://gitlab.com/gitlab-org/gitlab) takes all the
+   `knapsack/rspec*_pg_*.json` files and merge them all together into a single
+   `knapsack/report-master.json` file that is then uploaded to S3.
+
+After that, the next pipeline will use the up-to-date `knapsack/report-master.json` file.
 
 ## Monitoring
 
diff --git a/doc/development/testing_guide/end_to_end/best_practices.md b/doc/development/testing_guide/end_to_end/best_practices.md
index 2200069ecfd..042879b47aa 100644
--- a/doc/development/testing_guide/end_to_end/best_practices.md
+++ b/doc/development/testing_guide/end_to_end/best_practices.md
@@ -53,3 +53,15 @@ In summary:
 
 - **Do**: Split tests across separate files, unless the tests share expensive setup.
 - **Don't**: Put new tests in an existing file without considering the impact on parallelization.
+
+## Limit the use of `before(:all)` hook
+
+Limit the use of `before(:all)` to perform setup tasks with only API calls, non UI operations
+or basic UI operations such as login.
+
+We use [`capybara-screenshot`](https://github.com/mattheworiordan/capybara-screenshot) library to automatically save screenshots on failures.
+This library [saves the screenshots in the RSpec's `after` hook](https://github.com/mattheworiordan/capybara-screenshot/blob/master/lib/capybara-screenshot/rspec.rb#L97).
+[If there is a failure in `before(:all)`, the `after` hook is not called](https://github.com/rspec/rspec-core/pull/2652/files#diff-5e04af96d5156e787f28d519a8c99615R148) and so the screenshots are not saved.
+
+Given this fact, we should limit the use of `before(:all)` to only those operations where a screenshot is not
+necessary in case of failure and QA logs would be enough for debugging.
diff --git a/doc/development/testing_guide/end_to_end/index.md b/doc/development/testing_guide/end_to_end/index.md
index 9685a61d0c1..a9fb4be284e 100644
--- a/doc/development/testing_guide/end_to_end/index.md
+++ b/doc/development/testing_guide/end_to_end/index.md
@@ -16,14 +16,14 @@ a black-box testing framework for the API and the UI.
 ### Testing nightly builds
 
 We run scheduled pipeline each night to test nightly builds created by Omnibus.
-You can find these nightly pipelines at [gitlab-org/quality/nightly/pipelines][quality-nightly-pipelines].
-Results are reported in the `#qa-nightly` Slack channel.
+You can find these nightly pipelines at `https://gitlab.com/gitlab-org/quality/nightly/pipelines`
+(need Developer access permissions). Results are reported in the `#qa-nightly` Slack channel.
 
 ### Testing staging
 
 We run scheduled pipeline each night to test staging.
-You can find these nightly pipelines at [gitlab-org/quality/staging/pipelines][quality-staging-pipelines].
-Results are reported in the `#qa-staging` Slack channel.
+You can find these nightly pipelines at `https://gitlab.com/gitlab-org/quality/staging/pipelines`
+(need developer access permissions). Results are reported in the `#qa-staging` Slack channel.
 
 ### Testing code in merge requests
 
@@ -52,7 +52,7 @@ graph LR
     A1 -.->|1. Triggers an omnibus-gitlab pipeline and wait for it to be done| A2
     B2[`Trigger-qa` stage<br>`Trigger:qa-test` job] -.->|2. Triggers a gitlab-qa pipeline and wait for it to be done| A3
 
-subgraph "gitlab-ce/ee pipeline"
+subgraph "gitlab-foss/gitlab pipeline"
     A1[`test` stage<br>`package-and-qa-manual` job]
     end
 
@@ -135,20 +135,16 @@ Continued reading:
 
 You can ask question in the `#quality` channel on Slack (GitLab internal) or
 you can find an issue you would like to work on in
-[the `gitlab-ce` issue tracker][gitlab-ce-issues],
-[the `gitlab-ee` issue tracker][gitlab-ce-issues], or
+[the `gitlab` issue tracker][gitlab-issues], or
 [the `gitlab-qa` issue tracker][gitlab-qa-issues].
 
 [omnibus-gitlab]: https://gitlab.com/gitlab-org/omnibus-gitlab
 [gitlab-qa]: https://gitlab.com/gitlab-org/gitlab-qa
 [gitlab-qa-readme]: https://gitlab.com/gitlab-org/gitlab-qa/tree/master/README.md
-[quality-nightly-pipelines]: https://gitlab.com/gitlab-org/quality/nightly/pipelines
-[quality-staging-pipelines]: https://gitlab.com/gitlab-org/quality/staging/pipelines
 [review-apps]: ../review_apps.md
 [gitlab-qa-architecture]: https://gitlab.com/gitlab-org/gitlab-qa/blob/master/docs/architecture.md
 [gitlab-qa-issues]: https://gitlab.com/gitlab-org/gitlab-qa/issues?label_name%5B%5D=new+scenario
-[gitlab-ce-issues]: https://gitlab.com/gitlab-org/gitlab-foss/issues?label_name[]=QA&label_name[]=test
-[gitlab-ee-issues]: https://gitlab.com/gitlab-org/gitlab/issues?label_name[]=QA&label_name[]=test
+[gitlab-issues]: https://gitlab.com/gitlab-org/gitlab/issues?label_name[]=QA&label_name[]=test
 [test environment orchestration scenarios]: https://gitlab.com/gitlab-org/gitlab-qa/tree/master/lib/gitlab/qa/scenario
 [instance-level scenarios]: https://gitlab.com/gitlab-org/gitlab-foss/tree/master/qa/qa/specs/features
 [Page objects documentation]: https://gitlab.com/gitlab-org/gitlab/tree/master/qa/qa/page/README.md
diff --git a/doc/development/testing_guide/end_to_end/page_objects.md b/doc/development/testing_guide/end_to_end/page_objects.md
index 8820b54fa87..28111c18378 100644
--- a/doc/development/testing_guide/end_to_end/page_objects.md
+++ b/doc/development/testing_guide/end_to_end/page_objects.md
@@ -2,7 +2,7 @@
 
 In GitLab QA we are using a known pattern, called _Page Objects_.
 
-This means that we have built an abstraction for all GitLab pages that we use
+This means that we have built an abstraction for all pages in GitLab that we use
 to drive GitLab QA scenarios. Whenever we do something on a page, like filling
 in a form, or clicking a button, we do that only through a page object
 associated with this area of GitLab.
diff --git a/doc/development/testing_guide/end_to_end/quick_start_guide.md b/doc/development/testing_guide/end_to_end/quick_start_guide.md
index f5a46d574b0..2457d8ada5a 100644
--- a/doc/development/testing_guide/end_to_end/quick_start_guide.md
+++ b/doc/development/testing_guide/end_to_end/quick_start_guide.md
@@ -24,7 +24,7 @@ If you don't exactly understand what we mean by **not everything needs to happen
 
 ### 0. Are end-to-end tests needed?
 
-At GitLab we respect the [test pyramid](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/development/testing_guide/testing_levels.md), and so, we recommend you check the code coverage of a specific feature before writing end-to-end tests, for both [CE](https://gitlab-org.gitlab.io/gitlab-ce/coverage-ruby/#_AllFiles) and [EE](https://gitlab-org.gitlab.io/gitlab-ee/coverage-ruby/#_AllFiles) projects.
+At GitLab we respect the [test pyramid](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/development/testing_guide/testing_levels.md), and so, we recommend you check the code coverage of a specific feature before writing end-to-end tests, for both [CE](https://gitlab-org.gitlab.io/gitlab-foss/coverage-ruby/#_AllFiles) and [EE](https://gitlab-org.gitlab.io/gitlab/coverage-ruby/#_AllFiles) projects.
 
 Sometimes you may notice that there is already good coverage in other test levels, and we can stay confident that if we break a feature, we will still have quick feedback about it, even without having end-to-end tests.
 
@@ -38,7 +38,7 @@ The GitLab QA end-to-end tests are organized by the different [stages in the Dev
 
 > There may be sub-directories inside the stages directories, for different features. For example: `.../browser_ui/2_plan/ee_epics/` and `.../browser_ui/2_plan/issues/`.
 
-Now, let's say we want to create tests for the [scoped labels](https://about.gitlab.com/2019/04/22/gitlab-11-10-released/#scoped-labels) feature, available on GitLab EE Premium (this feature is part of the Plan stage.)
+Now, let's say we want to create tests for the [scoped labels](https://about.gitlab.com/blog/2019/04/22/gitlab-11-10-released/#scoped-labels) feature, available on GitLab EE Premium (this feature is part of the Plan stage.)
 
 > Because these tests are for a feature available only on GitLab EE, we need to create them in the [EE repository](https://gitlab.com/gitlab-org/gitlab).
 
diff --git a/doc/development/testing_guide/flaky_tests.md b/doc/development/testing_guide/flaky_tests.md
index 8e73b3d9ae9..0823c2e02b8 100644
--- a/doc/development/testing_guide/flaky_tests.md
+++ b/doc/development/testing_guide/flaky_tests.md
@@ -51,7 +51,7 @@ is detected in any other branch (`flaky-examples-check` job). In the future, the
 This was originally implemented in: <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/13021>.
 
 [rspec-retry]: https://github.com/NoRedInk/rspec-retry
-[`spec/spec_helper.rb`]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/spec/spec_helper.rb
+[`spec/spec_helper.rb`]: https://gitlab.com/gitlab-org/gitlab/blob/master/spec/spec_helper.rb
 
 ## Problems we had in the past at GitLab
 
@@ -61,7 +61,7 @@ This was originally implemented in: <https://gitlab.com/gitlab-org/gitlab-foss/m
   - [Capybara.reset_session! should be called before requests are blocked](https://gitlab.com/gitlab-org/gitlab-foss/issues/33779): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12224>
 - FFaker generates funky data that tests are not ready to handle (and tests should be predictable so that's bad!):
   - [Make `spec/mailers/notify_spec.rb` more robust](https://gitlab.com/gitlab-org/gitlab-foss/issues/20121): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10015>
-  - [Transient failure in spec/requests/api/commits_spec.rb](https://gitlab.com/gitlab-org/gitlab-foss/issues/27988#note_25342521): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/9944>
+  - [Transient failure in `spec/requests/api/commits_spec.rb`](https://gitlab.com/gitlab-org/gitlab-foss/issues/27988#note_25342521): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/9944>
   - [Replace FFaker factory data with sequences](https://gitlab.com/gitlab-org/gitlab-foss/issues/29643): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10184>
   - [Transient failure in spec/finders/issues_finder_spec.rb](https://gitlab.com/gitlab-org/gitlab-foss/issues/30211#note_26707685): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10404>
 
@@ -80,6 +80,9 @@ This was originally implemented in: <https://gitlab.com/gitlab-org/gitlab-foss/m
 - [Bis](https://gitlab.com/gitlab-org/gitlab-foss/issues/34609#note_34048715): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12604>
 - [Bis](https://gitlab.com/gitlab-org/gitlab-foss/issues/34698#note_34276286): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12664>
 - [Assert against the underlying database state instead of against a page's content](https://gitlab.com/gitlab-org/gitlab-foss/issues/31437): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10934>
+- In JS tests, shifting elements can cause Capybara to misclick when the element moves at the exact time Capybara sends the click
+  - [Dropdowns rendering upward or downward due to window size and scroll position](https://gitlab.com/gitlab-org/gitlab/merge_requests/17660)
+  - [Lazy loaded images can cause Capybara to misclick](https://gitlab.com/gitlab-org/gitlab/merge_requests/18713)
 
 #### Capybara viewport size related issues
 
diff --git a/doc/development/testing_guide/frontend_testing.md b/doc/development/testing_guide/frontend_testing.md
index da843218d8b..314995ca9b3 100644
--- a/doc/development/testing_guide/frontend_testing.md
+++ b/doc/development/testing_guide/frontend_testing.md
@@ -38,7 +38,7 @@ which could arise (especially with testing against browser specific features).
 - Jest runs in a Node.js environment, not in a browser. Support for running Jest tests in a browser [is planned](https://gitlab.com/gitlab-org/gitlab-foss/issues/58205).
 - Because Jest runs in a Node.js environment, it uses [jsdom](https://github.com/jsdom/jsdom) by default. See also its [limitations](#limitations-of-jsdom) below.
 - Jest does not have access to Webpack loaders or aliases.
-  The aliases used by Jest are defined in its [own config](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/jest.config.js).
+  The aliases used by Jest are defined in its [own config](https://gitlab.com/gitlab-org/gitlab/blob/master/jest.config.js).
 - All calls to `setTimeout` and `setInterval` are mocked away. See also [Jest Timer Mocks](https://jestjs.io/docs/en/timer-mocks).
 - `rewire` is not required because Jest supports mocking modules. See also [Manual Mocks](https://jestjs.io/docs/en/manual-mocks).
 - No [context object](https://jasmine.github.io/tutorials/your_first_suite#section-The_%3Ccode%3Ethis%3C/code%3E_keyword) is passed to tests in Jest.
@@ -67,13 +67,13 @@ Running `yarn jest-debug` will run Jest in debug mode, allowing you to debug/ins
 ### Timeout error
 
 The default timeout for Jest is set in
-[`/spec/frontend/test_setup.js`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/spec/frontend/test_setup.js).
+[`/spec/frontend/test_setup.js`](https://gitlab.com/gitlab-org/gitlab/blob/master/spec/frontend/test_setup.js).
 
 If your test exceeds that time, it will fail.
 
 If you cannot improve the performance of the tests, you can increase the timeout
 for a specific test using
-[`setTestTimeout`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/spec/frontend/helpers/timeout.js).
+[`setTestTimeout`](https://gitlab.com/gitlab-org/gitlab/blob/master/spec/frontend/helpers/timeout.js).
 
 ```javascript
 import { setTestTimeout } from 'helpers/timeout';
@@ -388,7 +388,7 @@ it('renders something', done => {
 ##### `setTimeout()` / `setInterval()` in application
 
 If the application itself is waiting for some time, mock await the waiting. In Jest this is already
-[done by default](https://gitlab.com/gitlab-org/gitlab-foss/blob/a2128edfee799e49a8732bfa235e2c5e14949c68/jest.config.js#L47)
+[done by default](https://gitlab.com/gitlab-org/gitlab/blob/a2128edfee799e49a8732bfa235e2c5e14949c68/jest.config.js#L47)
 (see also [Jest Timer Mocks](https://jestjs.io/docs/en/timer-mocks)). In Karma you can use the
 [Jasmine mock clock](https://jasmine.github.io/api/2.9/Clock.html).
 
@@ -482,7 +482,7 @@ As long as the fixtures don't change, `yarn test` is sufficient (and saves you s
 
 While developing locally, it may be helpful to keep Karma running so that you
 can get instant feedback on as you write tests and modify code. To do this
-you can start Karma with `yarn run karma-start`. It will compile the javascript
+you can start Karma with `yarn run karma-start`. It will compile the JavaScript
 assets and run a server at `http://localhost:9876/` where it will automatically
 run the tests on any browser which connects to it. You can enter that url on
 multiple browsers at once to have it run the tests on each in parallel.
@@ -516,11 +516,6 @@ glob otherwise your shell may split it into multiple arguments:
 yarn karma -f 'spec/javascripts/ide/**/file_spec.js'
 ```
 
-## RSpec feature integration tests
-
-Information on setting up and running RSpec integration tests with
-[Capybara] can be found in the [Testing Best Practices](best_practices.md).
-
 ## Frontend test fixtures
 
 Code that is added to HAML templates (in `app/views/`) or makes Ajax requests to the backend has tests that require HTML or JSON from the backend.
@@ -598,7 +593,6 @@ end
 [karma]: http://karma-runner.github.io/
 [vue-test]: ../fe_guide/vue.md#testing-vue-components
 [rspec]: https://github.com/rspec/rspec-rails#feature-specs
-[capybara]: https://github.com/teamcapybara/capybara
 [jasmine]: https://jasmine.github.io/
 
 ## Overview of Frontend Testing Levels
@@ -955,7 +949,11 @@ graph RL
 In contrast to [frontend integration tests](#frontend-integration-tests), feature tests make requests against the real backend instead of using fixtures.
 This also implies that database queries are executed which makes this category significantly slower.
 
-See also the [RSpec testing guidelines](../testing_guide/best_practices.md#rspec).
+See also
+
+- The [RSpec testing guidelines](../testing_guide/best_practices.md#rspec).
+- System / Feature tests in the [Testing Best Practices](best_practices.md#system--feature-tests).
+- [Issue #26159](https://gitlab.com/gitlab-org/gitlab/issues/26159) which aims at combine those guidelines with this page.
 
 ```mermaid
 graph RL
@@ -1048,7 +1046,7 @@ testAction(
 );
 ```
 
-Check an example in [spec/javascripts/ide/stores/actions_spec.jsspec/javascripts/ide/stores/actions_spec.js](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/spec/javascripts/ide/stores/actions_spec.js).
+Check an example in [spec/javascripts/ide/stores/actions_spec.jsspec/javascripts/ide/stores/actions_spec.js](https://gitlab.com/gitlab-org/gitlab/blob/master/spec/javascripts/ide/stores/actions_spec.js).
 
 ### Vue Helper: `mountComponent`
 
diff --git a/doc/development/testing_guide/index.md b/doc/development/testing_guide/index.md
index 173471e3af8..25da72b6b6a 100644
--- a/doc/development/testing_guide/index.md
+++ b/doc/development/testing_guide/index.md
@@ -19,7 +19,7 @@ integration testing.
 Following are two great articles that everyone should read to understand what
 automated testing means, and what are its principles:
 
-- [Five Factor Testing](https://www.devmynd.com/blog/five-factor-testing): Why do we need tests?
+- [Five Factor Testing](https://madeintandem.com/blog/five-factor-testing/): Why do we need tests?
 - [Principles of Automated Testing](http://www.lihaoyi.com/post/PrinciplesofAutomatedTesting.html): Levels of testing. Prioritize tests. Cost of tests.
 
 ## [Testing levels](testing_levels.md)
@@ -60,6 +60,10 @@ Everything you should know about how to test Rake tasks.
 Everything you should know about how to run end-to-end tests using
 [GitLab QA][gitlab-qa] testing framework.
 
+## [Migrations tests](testing_migrations_guide.md)
+
+Everything you should know about how to test migrations.
+
 [Return to Development documentation](../README.md)
 
 [RSpec]: https://github.com/rspec/rspec-rails#feature-specs
diff --git a/doc/development/testing_guide/review_apps.md b/doc/development/testing_guide/review_apps.md
index 8ce25376a05..3dd403f148e 100644
--- a/doc/development/testing_guide/review_apps.md
+++ b/doc/development/testing_guide/review_apps.md
@@ -16,23 +16,23 @@ graph TD
     review-build-cng -->|once the `review-build-cng` job is done| review-deploy
     review-deploy -->|once the `review-deploy` job is done| review-qa-smoke
 
-subgraph "1. gitlab-ce/ee `prepare` stage"
+subgraph "1. gitlab-foss/gitlab `prepare` stage"
     build-qa-image
     end
 
-subgraph "2. gitlab-ce/ee `test` stage"
+subgraph "2. gitlab-foss/gitlab `test` stage"
     gitlab:assets:compile
     end
 
-subgraph "3. gitlab-ce/ee `review-prepare` stage"
+subgraph "3. gitlab-foss/gitlab `review-prepare` stage"
     review-build-cng
     end
 
-subgraph "4. gitlab-ce/ee `review` stage"
+subgraph "4. gitlab-foss/gitlab `review` stage"
     review-deploy["review-deploy<br><br>Helm deploys the Review App using the Cloud<br/>Native images built by the CNG-mirror pipeline.<br><br>Cloud Native images are deployed to the `review-apps-ce` or `review-apps-ee`<br>Kubernetes (GKE) cluster, in the GCP `gitlab-review-apps` project."]
     end
 
-subgraph "5. gitlab-ce/ee `qa` stage"
+subgraph "5. gitlab-foss/gitlab `qa` stage"
     review-qa-smoke[review-qa-smoke<br><br>gitlab-qa runs the smoke suite against the Review App.]
     end
 
@@ -142,7 +142,7 @@ their node under pressure.
 ### Log into my Review App
 
 The default username is `root` and its password can be found in the 1Password
-secure note named **gitlab-{ce,ee} Review App's root password**.
+secure note named `gitlab-{ce,ee} Review App's root password`.
 
 ### Enable a feature flag for my Review App
 
@@ -193,7 +193,7 @@ The following items may help diagnose this:
 - [Instance Group size in GCP](https://console.cloud.google.com/compute/instanceGroups/details/us-central1-b/gke-review-apps-ee-preemp-n1-standard-8affc0f5-grp?project=gitlab-review-apps&tab=monitoring&graph=GCE_SIZE&duration=P30D) - aids in identifying load spikes on the cluster. Kubernetes will add nodes up to 220 based on total resource requests.
 - `kubectl top nodes --sort-by=cpu` - can identify if node spikes are common or load on specific nodes which may get rebalanced by the Kubernetes scheduler.
 - `kubectl top pods --sort-by=cpu` -
-- [K9s] - K9s is a powerful command line dashboard which allows you to filter by labels. This can help identify trends with apps exceeding the [review-app resource requests](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/scripts/review_apps/base-config.yaml). Kubernetes will schedule pods to nodes based on resource requests and allow for CPU usage up to the limits.
+- [K9s] - K9s is a powerful command line dashboard which allows you to filter by labels. This can help identify trends with apps exceeding the [review-app resource requests](https://gitlab.com/gitlab-org/gitlab/blob/master/scripts/review_apps/base-config.yaml). Kubernetes will schedule pods to nodes based on resource requests and allow for CPU usage up to the limits.
   - In K9s you can sort or add filters by typing the `/` character
     - `-lrelease=<review-app-slug>` - filters down to all pods for a release. This aids in determining what is having issues in a single deployment
     - `-lapp=<app>` - filters down to all pods for a specific app. This aids in determining resource usage by app.
@@ -232,10 +232,10 @@ using `v232`.
 
 For the record, the debugging steps to find out this issue were:
 
-1. Switch kubectl context to review-apps-ce (we recommend using [kubectx](https://kubectx.dev/))
+1. Switch kubectl context to review-apps-ce (we recommend using [kubectx](https://github.com/ahmetb/kubectx/))
 1. `kubectl get pods | grep dns`
 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. 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)
 1. In the node: `systemctl --version` => systemd 232
@@ -311,8 +311,8 @@ find a way to limit it to only us.**
 [review-apps-ee]: https://console.cloud.google.com/kubernetes/clusters/details/us-central1-b/review-apps-ee?project=gitlab-review-apps
 [review-apps.sh]: https://gitlab.com/gitlab-org/gitlab/blob/master/scripts/review_apps/review-apps.sh
 [automated_cleanup.rb]: https://gitlab.com/gitlab-org/gitlab/blob/master/scripts/review_apps/automated_cleanup.rb
-[Auto-DevOps.gitlab-ci.yml]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml
-[gitlab-ci-yml]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/.gitlab-ci.yml
+[Auto-DevOps.gitlab-ci.yml]: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml
+[gitlab-ci-yml]: https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml
 [gitlab-k8s-integration]: ../../user/project/clusters/index.md
 [K9s]: https://github.com/derailed/k9s
 [password-bug]: https://gitlab.com/gitlab-org/gitlab-foss/issues/53621
diff --git a/doc/development/testing_guide/testing_levels.md b/doc/development/testing_guide/testing_levels.md
index b9436abf856..13659d66180 100644
--- a/doc/development/testing_guide/testing_levels.md
+++ b/doc/development/testing_guide/testing_levels.md
@@ -44,7 +44,7 @@ records should use stubs/doubles as much as possible.
 | `config/routes.rb`, `config/routes/` | `spec/routing/` | RSpec | |
 | `config/puma.example.development.rb`, `config/unicorn.rb.example` | `spec/rack_servers/` | RSpec | |
 | `db/` | `spec/db/` | RSpec | |
-| `db/{post_,}migrate/` | `spec/migrations/` | RSpec | More details at [`spec/migrations/README.md`](https://gitlab.com/gitlab-org/gitlab/blob/master/spec/migrations/README.md). |
+| `db/{post_,}migrate/` | `spec/migrations/` | RSpec | More details in the [Testing Rails migrations guide](testing_migrations_guide.md). |
 | `Gemfile` | `spec/dependencies/`, `spec/sidekiq/` | RSpec | |
 | `lib/` | `spec/lib/` | RSpec | |
 | `lib/tasks/` | `spec/tasks/` | RSpec | |
@@ -99,7 +99,7 @@ Formal definitions:
 - <https://en.wikipedia.org/wiki/White-box_testing>
 
 These kind of tests ensure the GitLab *Rails* application (i.e.
-`gitlab-ce`/`gitlab-ee`) works as expected from a *browser* point of view.
+`gitlab-foss`/`gitlab`) works as expected from a *browser* point of view.
 
 Note that:
 
diff --git a/doc/development/testing_guide/testing_migrations_guide.md b/doc/development/testing_guide/testing_migrations_guide.md
new file mode 100644
index 00000000000..b28d17a4b55
--- /dev/null
+++ b/doc/development/testing_guide/testing_migrations_guide.md
@@ -0,0 +1,216 @@
+---
+type: reference
+---
+
+# Testing Rails migrations at GitLab
+
+In order to reliably check Rails migrations, we need to test them against
+a database schema.
+
+## When to write a migration test
+
+- Post migrations (`/db/post_migrate`) and background migrations
+  (`lib/gitlab/background_migration`) **must** have migration tests performed.
+- If your migration is a data migration then it **must** have a migration test.
+- Other migrations may have a migration test if necessary.
+
+## How does it work?
+
+Adding a `:migration` tag to a test signature enables some custom RSpec
+`before` and `after` hooks in our
+[`spec_helper.rb`](https://gitlab.com/gitlab-org/gitlab/blob/3b29908a64ff729c0cf6d93452fe00ab23079c75/spec%2Fspec_helper.rb#L259)
+to run.
+
+A `before` hook will revert all migrations to the point that a migration
+under test is not yet migrated.
+
+In other words, our custom RSpec hooks will find a previous migration, and
+migrate the database **down** to the previous migration version.
+
+With this approach you can test a migration against a database schema.
+
+An `after` hook will migrate the database **up** and reinstitute the latest
+schema version, so that the process does not affect subsequent specs and
+ensures proper isolation.
+
+## Testing an `ActiveRecord::Migration` class
+
+To test an `ActiveRecord::Migration` class (i.e., a
+regular migration `db/migrate` or a post-migration `db/post_migrate`), you
+will need to manually `require` the migration file because it is not
+autoloaded with Rails. Example:
+
+```ruby
+require Rails.root.join('db', 'post_migrate', '20170526185842_migrate_pipeline_stages.rb')
+```
+
+### Test helpers
+
+#### `table`
+
+Use the `table` helper to create a temporary `ActiveRecord::Base`-derived model
+for a table. [FactoryBot](https://docs.gitlab.com/ee/development/testing_guide/best_practices.html#factories)
+**should not** be used to create data for migration specs. For example, to
+create a record in the `projects` table:
+
+```ruby
+project = table(:projects).create!(id: 1, name: 'gitlab1', path: 'gitlab1')
+```
+
+#### `migrate!`
+
+Use the `migrate!` helper to run the migration that is under test.  It will not only
+run the migration, but will also bump the schema version in the `schema_migrations`
+table. It is necessary because in the `after` hook we trigger the rest of
+the migrations, and we need to know where to start. Example:
+
+```ruby
+it 'migrates successfully' do
+  # ... pre-migration expectations
+
+  migrate!
+
+  # ... post-migration expectations
+end
+```
+
+#### `reversible_migration`
+
+Use the `reversible_migration` helper to test migrations with either a
+`change` or both `up` and `down` hooks. This will test that the state of
+the application and its data after the migration becomes reversed is the
+same as it was before the migration ran in the first place. The helper:
+
+1. Runs the `before` expectations before the **up** migration.
+1. Migrates **up**.
+1. Runs the `after` expectations.
+1. Migrates **down**.
+1. Runs the `before` expectations a second time.
+
+Example:
+
+```ruby
+reversible_migration do |migration|
+  migration.before -> {
+    # ... pre-migration expectations
+  }
+
+  migration.after -> {
+    # ... post-migration expectations
+  }
+end
+```
+
+### Example database migration test
+
+This spec tests the
+[`db/post_migrate/20170526185842_migrate_pipeline_stages.rb`](https://gitlab.com/gitlab-org/gitlab/blob/v11.6.5/db/post_migrate/20170526185842_migrate_pipeline_stages.rb)
+migration. You can find the complete spec in
+[`spec/migrations/migrate_pipeline_stages_spec.rb`](https://gitlab.com/gitlab-org/gitlab/blob/v11.6.5/spec/migrations/migrate_pipeline_stages_spec.rb).
+
+```ruby
+require 'spec_helper'
+require Rails.root.join('db', 'post_migrate', '20170526185842_migrate_pipeline_stages.rb')
+
+describe MigratePipelineStages, :migration do
+  # Create test data - pipeline and CI/CD jobs.
+  let(:jobs) { table(:ci_builds) }
+  let(:stages) { table(:ci_stages) }
+  let(:pipelines) { table(:ci_pipelines) }
+  let(:projects) { table(:projects) }
+
+  before do
+    projects.create!(id: 123, name: 'gitlab1', path: 'gitlab1')
+    pipelines.create!(id: 1, project_id: 123, ref: 'master', sha: 'adf43c3a')
+    jobs.create!(id: 1, commit_id: 1, project_id: 123, stage_idx: 2, stage: 'build')
+    jobs.create!(id: 2, commit_id: 1, project_id: 123, stage_idx: 1, stage: 'test')
+  end
+
+  # Test just the up migration.
+  it 'correctly migrates pipeline stages' do
+    expect(stages.count).to be_zero
+
+    migrate!
+
+    expect(stages.count).to eq 2
+    expect(stages.all.pluck(:name)).to match_array %w[test build]
+  end
+
+  # Test a reversible migration.
+  it 'correctly migrates up and down pipeline stages' do
+    reversible_migration do |migration|
+      # Expectations will run before the up migration,
+      # and then again after the down migration
+      migration.before -> {
+        expect(stages.count).to be_zero
+      }
+
+      # Expectations will run after the up migration.
+      migration.after -> {
+        expect(stages.count).to eq 2
+        expect(stages.all.pluck(:name)).to match_array %w[test build]
+      }
+    end
+end
+```
+
+## Testing a non-`ActiveRecord::Migration` class
+
+To test a non-`ActiveRecord::Migration` test (a background migration),
+you will need to manually provide a required schema version. Please add a
+schema tag to a context that you want to switch the database schema within.
+
+Example:
+
+```ruby
+describe SomeClass, :migration, schema: 20170608152748 do
+  # ...
+end
+```
+
+### Example background migration test
+
+This spec tests the
+[`lib/gitlab/background_migration/archive_legacy_traces.rb`](https://gitlab.com/gitlab-org/gitlab/blob/v11.6.5/lib/gitlab/background_migration/archive_legacy_traces.rb)
+background migration. You can find the complete spec on
+[`spec/lib/gitlab/background_migration/archive_legacy_traces_spec.rb`](https://gitlab.com/gitlab-org/gitlab/blob/v11.6.5/spec/lib/gitlab/background_migration/archive_legacy_traces_spec.rb)
+
+```ruby
+require 'spec_helper'
+
+describe Gitlab::BackgroundMigration::ArchiveLegacyTraces, :migration, schema: 20180529152628 do
+  include TraceHelpers
+
+  let(:namespaces) { table(:namespaces) }
+  let(:projects) { table(:projects) }
+  let(:builds) { table(:ci_builds) }
+  let(:job_artifacts) { table(:ci_job_artifacts) }
+
+  before do
+    namespaces.create!(id: 123, name: 'gitlab1', path: 'gitlab1')
+    projects.create!(id: 123, name: 'gitlab1', path: 'gitlab1', namespace_id: 123)
+    @build = builds.create!(id: 1, project_id: 123, status: 'success', type: 'Ci::Build')
+  end
+
+  context 'when trace file exists at the right place' do
+    before do
+      create_legacy_trace(@build, 'trace in file')
+    end
+
+    it 'correctly archive legacy traces' do
+      expect(job_artifacts.count).to eq(0)
+      expect(File.exist?(legacy_trace_path(@build))).to be_truthy
+
+      described_class.new.perform(1, 1)
+
+      expect(job_artifacts.count).to eq(1)
+      expect(File.exist?(legacy_trace_path(@build))).to be_falsy
+      expect(File.read(archived_trace_path(job_artifacts.first))).to eq('trace in file')
+    end
+  end
+end
+```
+
+NOTE: **Note:**
+These tests do not run within a database transaction, as we use a deletion database
+cleanup strategy. Do not depend on a transaction being present.
diff --git a/doc/development/uploads.md b/doc/development/uploads.md
index 1af3e9db954..e3ff62f1d2f 100644
--- a/doc/development/uploads.md
+++ b/doc/development/uploads.md
@@ -82,7 +82,7 @@ To address this problem an HA object storage can be used and it's supported by [
 
 Scaling NFS is outside of our support scope, and NFS is not a part of cloud native installations.
 
-All features that require sidekiq and do not use object storage acceleration won't work without NFS. In Kubernetes, machine boundaries translate to PODs, and in this case the uploaded file will be written into the POD private disk. Since sidekiq POD cannot reach into other pods, the operation will fail to read it.
+All features that require Sidekiq and do not use object storage acceleration won't work without NFS. In Kubernetes, machine boundaries translate to PODs, and in this case the uploaded file will be written into the POD private disk. Since Sidekiq POD cannot reach into other pods, the operation will fail to read it.
 
 ## How to select the proper level of acceleration?
 
@@ -92,19 +92,19 @@ We can identify three major use-cases for an upload:
 
 1. **storage:** if we are uploading for storing a file (i.e. artifacts, packages, discussion attachments). In this case [object storage acceleration](#workhorse-object-storage-acceleration) is the proper level as it's the less resource-intensive operation. Additional information can be found on [File Storage in GitLab](file_storage.md).
 1. **in-controller/synchronous processing:** if we allow processing **small files** synchronously, using [disk acceleration](#workhorse-disk-acceleration) may speed up development.
-1. **sidekiq/asynchronous processing:** Async processing must implement [object storage acceleration](#workhorse-object-storage-acceleration), the reason being that it's the only way to support Cloud Native deployments without a shared NFS.
+1. **Sidekiq/asynchronous processing:** Async processing must implement [object storage acceleration](#workhorse-object-storage-acceleration), the reason being that it's the only way to support Cloud Native deployments without a shared NFS.
 
 For more details about currently broken feature see [epic &1802](https://gitlab.com/groups/gitlab-org/-/epics/1802).
 
 ### Handling repository uploads
 
-Some features involves git repository uploads without using a regular git client.
+Some features involves Git repository uploads without using a regular Git client.
 Some examples are uploading a repository file from the web interface and [design management](../user/project/issues/design_management.md).
 
-Those uploads requires the rails controller to act as a git client in lieu of the user.
+Those uploads requires the rails controller to act as a Git client in lieu of the user.
 Those operation falls into _in-controller/synchronous processing_ category, but we have no warranties on the file size.
 
-In case of a LFS upload, the file pointer is committed synchronously, but file upload to object storage is performed asynchronously with sidekiq.
+In case of a LFS upload, the file pointer is committed synchronously, but file upload to object storage is performed asynchronously with Sidekiq.
 
 ## Upload encodings
 
@@ -114,7 +114,7 @@ We have three kinds of file encoding in our uploads:
 
 1. <i class="fa fa-check-circle"></i> **multipart**: `multipart/form-data` is the most common, a file is encoded as a part of a multipart encoded request.
 1. <i class="fa fa-check-circle"></i> **body**: some APIs uploads files as the whole request body.
-1. <i class="fa fa-times-circle"></i> **JSON**: some JSON API uploads files as base64 encoded strings. This requires [gitlab-workhorse#226](https://gitlab.com/gitlab-org/gitlab-workhorse/issues/226) to be implemented.
+1. <i class="fa fa-times-circle"></i> **JSON**: some JSON API uploads files as base64 encoded strings. This will require a change to GitLab Workhorse, which [is planned](https://gitlab.com/gitlab-org/gitlab-workhorse/issues/226).
 
 ## Uploading technologies
 
@@ -209,10 +209,12 @@ This is the more advanced acceleration technique we have in place.
 Workhorse asks rails for temporary pre-signed object storage URLs and directly uploads to object storage.
 
 In this setup an extra rails route needs to be implemented in order to handle authorization,
-you can see an example of this in [`Projects::LfsStorageController`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/controllers/projects/lfs_storage_controller.rb)
-and [its routes](https://gitlab.com/gitlab-org/gitlab-foss/blob/v12.2.0/config/routes/git_http.rb#L31-32).
+you can see an example of this in [`Projects::LfsStorageController`](https://gitlab.com/gitlab-org/gitlab/blob/cc723071ad337573e0360a879cbf99bc4fb7adb9/app/controllers/projects/lfs_storage_controller.rb)
+and [its routes](https://gitlab.com/gitlab-org/gitlab/blob/cc723071ad337573e0360a879cbf99bc4fb7adb9/config/routes/git_http.rb#L31-32).
 
-**note:** this will fallback to _Workhorse disk acceleration_ when object storage is not enabled in the gitlab instance. The answer to the `/authorize` call will only contain a file system path.
+NOTE: **Note:**
+This will fall back to _Workhorse disk acceleration_ when object storage is not enabled
+in the GitLab instance. The answer to the `/authorize` call will only contain a file system path.
 
 ```mermaid
 sequenceDiagram
@@ -267,4 +269,4 @@ sequenceDiagram
 
 This option affect the response to the `/authorize` call. When not enabled, the API response will not contain presigned URLs and workhorse will write the file the shared disk, on the path is provided by rails, acting like object storage was disabled.
 
-Once the request reachs rails, it will schedule an object storage upload as a sidekiq job.
+Once the request reachs rails, it will schedule an object storage upload as a Sidekiq job.
diff --git a/doc/development/utilities.md b/doc/development/utilities.md
index 11de0d56ef3..38e416d68e4 100644
--- a/doc/development/utilities.md
+++ b/doc/development/utilities.md
@@ -2,7 +2,9 @@
 
 We developed a number of utilities to ease development.
 
-## [`MergeHash`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/utils/merge_hash.rb)
+## `MergeHash`
+
+Refer to: <https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/utils/merge_hash.rb>:
 
 - Deep merges an array of hashes:
 
@@ -45,7 +47,9 @@ We developed a number of utilities to ease development.
   [:hello, "world", :this, :crushes, "an entire", "hash"]
   ```
 
-## [`Override`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/utils/override.rb)
+## `Override`
+
+Refer to <https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/utils/override.rb>:
 
 - This utility could help us check if a particular method would override
   another method or not. It has the same idea of Java's `@Override` annotation
@@ -90,7 +94,9 @@ We developed a number of utilities to ease development.
     end
     ```
 
-## [`StrongMemoize`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/utils/strong_memoize.rb)
+## `StrongMemoize`
+
+Refer to <https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/utils/strong_memoize.rb>:
 
 - Memoize the value even if it is `nil` or `false`.
 
@@ -136,7 +142,9 @@ We developed a number of utilities to ease development.
   Find.new.clear_memoization(:result)
   ```
 
-## [`RequestCache`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/cache/request_cache.rb)
+## `RequestCache`
+
+Refer to <https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/cache/request_cache.rb>.
 
 This module provides a simple way to cache values in RequestStore,
 and the cache key would be based on the class name, method name,
diff --git a/doc/downgrade_ee_to_ce/README.md b/doc/downgrade_ee_to_ce/README.md
index 0dc029a4cd1..db4bbe8ae39 100644
--- a/doc/downgrade_ee_to_ce/README.md
+++ b/doc/downgrade_ee_to_ce/README.md
@@ -90,7 +90,7 @@ your GitLab installation with the Community Edition's remote, fetch the latest
 changes, and checkout the latest stable branch:
 
 ```sh
-git remote set-url origin git@gitlab.com:gitlab-org/gitlab-ce.git
+git remote set-url origin git@gitlab.com:gitlab-org/gitlab-foss.git
 git fetch --all
 git checkout 8-x-stable
 ```
diff --git a/doc/gitlab-basics/create-project.md b/doc/gitlab-basics/create-project.md
index de63abe2b14..8edce515ec8 100644
--- a/doc/gitlab-basics/create-project.md
+++ b/doc/gitlab-basics/create-project.md
@@ -81,10 +81,10 @@ You can improve the existing built-in templates or contribute new ones in the
 #### Custom project templates **(PREMIUM)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/6860) in
-[GitLab Premium](https://about.gitlab.com/pricing) 11.2.
+[GitLab Premium](https://about.gitlab.com/pricing/) 11.2.
 
-Creating new projects based on custom project templates is a convenient option to
-bootstrap a project.
+Creating new projects based on custom project templates is a convenient option for
+quickly starting projects.
 
 Custom projects are available at the [instance-level](../user/admin_area/custom_project_templates.md)
 from the **Instance** tab, or at the [group-level](../user/group/custom_project_templates.md)
diff --git a/doc/gitlab-basics/start-using-git.md b/doc/gitlab-basics/start-using-git.md
index 385f69e62ab..05329993c64 100644
--- a/doc/gitlab-basics/start-using-git.md
+++ b/doc/gitlab-basics/start-using-git.md
@@ -13,9 +13,9 @@ make sure that you have created and/or signed into an account on GitLab.
 Depending on your operating system, you will need to use a shell of your preference.
 Here are some suggestions:
 
-- [Terminal](http://blog.teamtreehouse.com/introduction-to-the-mac-os-x-command-line) on macOS
+- [Terminal](https://blog.teamtreehouse.com/introduction-to-the-mac-os-x-command-line) on macOS
 - [GitBash](https://msysgit.github.io) on Windows
-- [Linux Terminal](http://www.howtogeek.com/140679/beginner-geek-how-to-start-using-the-linux-terminal/) on Linux
+- [Linux Terminal](https://www.howtogeek.com/140679/beginner-geek-how-to-start-using-the-linux-terminal/) on Linux
 
 ## Check if Git has already been installed
 
@@ -110,8 +110,8 @@ and paste in your command line.
 
 As an example, consider this repository path:
 
-- HTTPS: `https://gitlab.com/gitlab-org/gitlab-foss.git`
-- SSH: `git@gitlab.com:gitlab-org/gitlab-ce.git`
+- HTTPS: `https://gitlab.com/gitlab-org/gitlab.git`
+- SSH: `git@gitlab.com:gitlab-org/gitlab.git`
 
 To get started, open a terminal window in the directory you wish to clone the repository
 files into, and run one of the following commands.
@@ -119,13 +119,13 @@ files into, and run one of the following commands.
 Clone via HTTPS:
 
 ```bash
-git clone https://gitlab.com/gitlab-org/gitlab-foss.git
+git clone https://gitlab.com/gitlab-org/gitlab.git
 ```
 
 Clone via SSH:
 
 ```bash
-git clone git@gitlab.com:gitlab-org/gitlab-ce.git
+git clone git@gitlab.com:gitlab-org/gitlab.git
 ```
 
 Both commands will download a copy of the files in a folder named after the project's
diff --git a/doc/install/README.md b/doc/install/README.md
index fd91527ed4c..b906deadca9 100644
--- a/doc/install/README.md
+++ b/doc/install/README.md
@@ -83,7 +83,7 @@ the above methods, provided the cloud provider supports it.
 - [Install GitLab on Google Cloud Platform](google_cloud_platform/index.md): Install Omnibus GitLab on a VM in GCP.
 - [Install GitLab on Azure](azure/index.md): Install Omnibus GitLab from Azure Marketplace.
 - [Install GitLab on OpenShift](https://docs.gitlab.com/charts/installation/cloud/openshift.html): Install GitLab on OpenShift by using GitLab's Helm charts.
-- [Install GitLab on DC/OS](https://mesosphere.com/blog/gitlab-dcos/): Install GitLab on Mesosphere DC/OS via the [GitLab-Mesosphere integration](https://about.gitlab.com/2016/09/16/announcing-gitlab-and-mesosphere/).
-- [Install GitLab on DigitalOcean](https://about.gitlab.com/2016/04/27/getting-started-with-gitlab-and-digitalocean/): Install Omnibus GitLab on DigitalOcean.
+- [Install GitLab on DC/OS](https://d2iq.com/blog/gitlab-dcos): Install GitLab on Mesosphere DC/OS via the [GitLab-Mesosphere integration](https://about.gitlab.com/blog/2016/09/16/announcing-gitlab-and-mesosphere/).
+- [Install GitLab on DigitalOcean](https://about.gitlab.com/blog/2016/04/27/getting-started-with-gitlab-and-digitalocean/): Install Omnibus GitLab on DigitalOcean.
 - _Testing only!_ [DigitalOcean and Docker Machine](digitaloceandocker.md):
   Quickly test any version of GitLab on DigitalOcean using Docker Machine.
diff --git a/doc/install/aws/index.md b/doc/install/aws/index.md
index d08a50b3804..2dea763688e 100644
--- a/doc/install/aws/index.md
+++ b/doc/install/aws/index.md
@@ -43,7 +43,7 @@ Below is a diagram of the recommended architecture.
 Here's a list of the AWS services we will use, with links to pricing information:
 
 - **EC2**: GitLab will deployed on shared hardware which means
-  [on-demand pricing](https://aws.amazon.com/ec2/pricing/on-demand)
+  [on-demand pricing](https://aws.amazon.com/ec2/pricing/on-demand/)
   will apply. If you want to run it on a dedicated or reserved instance,
   consult the [EC2 pricing page](https://aws.amazon.com/ec2/pricing/) for more
   information on the cost.
@@ -112,12 +112,12 @@ RDS instances as well:
 
 1. Follow the same steps to create all subnets:
 
-   | Name tag | Type |Availability Zone | CIDR block |
-   | -------- | ---- | ---------------- | ---------- |
-   | gitlab-public-10.0.0.0  | public  | us-west-2a | 10.0.0.0 |
-   | gitlab-private-10.0.1.0 | private | us-west-2a | 10.0.1.0 |
-   | gitlab-public-10.0.2.0  | public  | us-west-2b | 10.0.2.0 |
-   | gitlab-private-10.0.3.0 | private | us-west-2b | 10.0.3.0 |
+   | Name tag                  | Type    | Availability Zone | CIDR block |
+   | ------------------------- | ------- | ----------------- | ---------- |
+   | `gitlab-public-10.0.0.0`  | public  | `us-west-2a`      | `10.0.0.0` |
+   | `gitlab-private-10.0.1.0` | private | `us-west-2a`      | `10.0.1.0` |
+   | `gitlab-public-10.0.2.0`  | public  | `us-west-2b`      | `10.0.2.0` |
+   | `gitlab-private-10.0.3.0` | private | `us-west-2b`      | `10.0.3.0` |
 
 ### Route Table
 
@@ -222,16 +222,16 @@ Now, it's time to create the database:
    1. For the size, let's select a `t2.medium` instance.
    1. Multi-AZ-deployment is recommended as redundancy, so choose "Create
       replica in different zone". Read more at
-      [High Availability (Multi-AZ)](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html).
+      [High Availability (Multi-AZ)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html).
    1. A Provisioned IOPS (SSD) storage type is best suited for HA (though you can
       choose a General Purpose (SSD) to reduce the costs). Read more about it at
-      [Storage for Amazon RDS](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html).
+      [Storage for Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html).
 
 1. The rest of the settings on this page request a DB instance identifier, username
    and a master password. We've chosen to use `gitlab-db-ha`, `gitlab` and a
    very secure password respectively. Keep these in hand for later.
 1. Click **Next** to proceed to the advanced settings.
-1. Make sure to choose our gitlab VPC, our subnet group, set public accessibility to
+1. Make sure to choose our GitLab VPC, our subnet group, set public accessibility to
    **No**, and to leave it to create a new security group. The only additional
    change which will be helpful is the database name for which we can use
    `gitlabhq_production`. At the very bottom, there's an option to enable
@@ -668,7 +668,7 @@ to request additional material:
   about administering your GitLab instance.
 - [Upload a license](../../user/admin_area/license.md):
   Activate all GitLab Enterprise Edition functionality with a license.
-- [Pricing](https://about.gitlab.com/pricing): Pricing for the different tiers.
+- [Pricing](https://about.gitlab.com/pricing/): Pricing for the different tiers.
 
 <!-- ## Troubleshooting
 
diff --git a/doc/install/azure/index.md b/doc/install/azure/index.md
index dfb1dbcf1ed..c789467175a 100644
--- a/doc/install/azure/index.md
+++ b/doc/install/azure/index.md
@@ -28,8 +28,8 @@ First, you'll need an account on Azure. There are three ways to do this:
 
 ## Working with Azure
 
-Once you have an Azure account, you can get started. Login to Azure using
-[portal.azure.com](https://portal.azure.com) and the first thing you will see is the Dashboard:
+Once you have an Azure account, you can get started. [Log in to Azure](https://portal.azure.com)
+and the first thing you will see is the Dashboard:
 
 ![Azure Dashboard](img/azure-dashboard.png)
 
@@ -38,7 +38,7 @@ create SQL Databases, author websites, and perform lots of other cloud tasks.
 
 ## Create New VM
 
-The [Azure Marketplace][Azure-Marketplace] is an online store for pre-configured applications and
+The [Azure Marketplace](https://azuremarketplace.microsoft.com/en-us/marketplace/) is an online store for pre-configured applications and
 services which have been optimized for the cloud by software vendors like GitLab,
 available on the Azure Marketplace as pre-configured solutions. In this tutorial
 we will install GitLab Community Edition, but for GitLab Enterprise Edition you
@@ -64,7 +64,7 @@ The first items we need to configure are the basic settings of the underlying vi
 
 1. Enter a `Name` for the VM - e.g. **"GitLab-CE"**
 1. Select a `VM disk type` - either **HDD** _(slower, lower cost)_ or **SSD** _(faster, higher cost)_
-1. Enter a `User name` - e.g. **"gitlab-admin"**
+1. Enter a `User name` - e.g. `gitlab-admin`
 1. Select an `Authentication type`, either **SSH public key** or **Password**:
 
    > **Note:** if you're unsure which authentication type to use, select **Password**
@@ -108,7 +108,7 @@ ahead and select this one, but please choose the size which best meets your own
 > **Note:** be aware that whilst your VM is active (known as "allocated"), it will incur
 "compute charges" which, ultimately, you will be billed for. So, even if you're using the
 free trial credits, you'll likely want to learn
-[how to properly shutdown an Azure VM to save money][Azure-Properly-Shutdown-VM].
+[how to properly shutdown an Azure VM to save money](https://buildazure.com/properly-shutdown-azure-vm-to-save-money/).
 
 Go ahead and click your chosen size, then click **"Select"** when you're ready to proceed to the
 next step.
@@ -167,7 +167,7 @@ in the `DNS name label` field:
 
 ![Azure - VM - Domain Name](img/azure-vm-domain-name.png)
 
-In the screenshot above, you'll see that we've set the `DNS name label` to **"gitlab-ce-test"**.
+In the screenshot above, you'll see that we've set the `DNS name label` to `gitlab-ce-test`.
 This will make our VM accessible at `gitlab-ce-test.centralus.cloudapp.azure.com`
 _(the full domain name of your own VM will be different, of course)_.
 
@@ -329,7 +329,7 @@ To perform an update, we need to connect directly to our Azure VM instance and r
 from the terminal. Our Azure VM is actually a server running Linux (Ubuntu), so we'll need to
 connect to it using SSH ([Secure Shell][SSH]).
 
-If you're running Windows, you'll need to connect using [PuTTY] or an equivalent Windows SSH client.
+If you're running Windows, you'll need to connect using [PuTTY](https://www.putty.org) or an equivalent Windows SSH client.
 If you're running Linux or macOS, then you already have an SSH client installed.
 
 > **Note:**
@@ -337,7 +337,7 @@ If you're running Linux or macOS, then you already have an SSH client installed.
 > - Remember that you will need to login with the username and password you specified
 >   [when you created](#basics) your Azure VM
 > - If you need to reset your VM password, read
->   [how to reset SSH credentials for a user on an Azure VM][Azure-Troubleshoot-SSH-Connection].
+>   [how to reset SSH credentials for a user on an Azure VM](https://docs.microsoft.com/en-us/azure/virtual-machines/troubleshooting/troubleshoot-ssh-connection).
 
 #### SSH from the command-line
 
@@ -356,7 +356,7 @@ Provide your password at the prompt to authenticate.
 
 #### SSH from Windows (PuTTY)
 
-If you're using [PuTTY] in Windows as your [SSH] client, then you might want to take a quick
+If you're using [PuTTY](https://www.putty.org) in Windows as your [SSH] client, then you might want to take a quick
 read on [using PuTTY in Windows][Using-SSH-In-Putty].
 
 ### Updating GitLab
@@ -397,7 +397,7 @@ is now showing **"up-to-date"**:
 
 ## Conclusion
 
-Naturally, we believe that GitLab is a great git repository tool. However, GitLab is a whole lot
+Naturally, we believe that GitLab is a great Git repository tool. However, GitLab is a whole lot
 more than that too. GitLab unifies issues, code review, CI and CD into a single UI, helping you to
 move faster from idea to production, and in this tutorial we showed you how quick and easy it is to
 set up and run your own instance of GitLab on Azure, Microsoft's cloud service.
@@ -416,30 +416,26 @@ Check out our other [Technical Articles](../../articles/index.md) or browse the
 - [GitLab Enterprise Edition][EE]
 - [Microsoft Azure][Azure]
   - [Azure - Free Account FAQ][Azure-Free-Account-FAQ]
-  - [Azure - Marketplace][Azure-Marketplace]
+  - [Azure - Marketplace](https://azuremarketplace.microsoft.com/en-us/marketplace/)
   - [Azure Portal][Azure-Portal]
   - [Azure - Pricing Calculator][Azure-Pricing-Calculator]
-  - [Azure - Troubleshoot SSH Connections to an Azure Linux VM][Azure-Troubleshoot-SSH-Connection]
-  - [Azure - Properly Shutdown an Azure VM][Azure-Properly-Shutdown-VM]
-- [SSH], [PuTTY] and [Using SSH in PuTTY][Using-SSH-In-Putty]
+  - [Azure - Troubleshoot SSH Connections to an Azure Linux VM](https://docs.microsoft.com/en-us/azure/virtual-machines/troubleshooting/troubleshoot-ssh-connection)
+  - [Azure - Properly Shutdown an Azure VM](https://buildazure.com/properly-shutdown-azure-vm-to-save-money/)
+- [SSH], [PuTTY](https://www.putty.org) and [Using SSH in PuTTY][Using-SSH-In-Putty]
 
-[Original-Blog-Post]: https://about.gitlab.com/2016/07/13/how-to-setup-a-gitlab-instance-on-microsoft-azure/ "How to Set up a GitLab Instance on Microsoft Azure"
+[Original-Blog-Post]: https://about.gitlab.com/blog/2016/07/13/how-to-setup-a-gitlab-instance-on-microsoft-azure/ "How to Set up a GitLab Instance on Microsoft Azure"
 [CE]: https://about.gitlab.com/features/
 [EE]: https://about.gitlab.com/features/#ee-starter
 
 [Azure-Troubleshoot-Linux-VM]: https://docs.microsoft.com/en-us/azure/virtual-machines/linux/troubleshoot-app-connection "Troubleshoot application connectivity issues on a Linux virtual machine in Azure"
 [Azure-IP-Address-Types]: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-ip-addresses-overview-arm "IP address types and allocation methods in Azure"
 [Azure-How-To-Open-Ports]: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/nsg-quickstart-portal "How to open ports to a virtual machine with the Azure portal"
-[Azure-Troubleshoot-SSH-Connection]: https://docs.microsoft.com/en-us/azure/virtual-machines/linux/troubleshoot-ssh-connection "Troubleshoot SSH connections to an Azure Linux VM"
 [Azure]: https://azure.microsoft.com/en-us/
 [Azure-Free-Account-FAQ]: https://azure.microsoft.com/en-us/free/free-account-faq/
-[Azure-Marketplace]: https://azure.microsoft.com/en-us/marketplace/
 [Azure-Portal]: https://portal.azure.com
 [Azure-Pricing-Calculator]: https://azure.microsoft.com/en-us/pricing/calculator/
-[Azure-Properly-Shutdown-VM]: https://buildazure.com/2017/03/16/properly-shutdown-azure-vm-to-save-money/ "Properly Shutdown an Azure VM to Save Money"
 
 [SSH]: https://en.wikipedia.org/wiki/Secure_Shell
-[PuTTY]: http://www.putty.org/
 [Using-SSH-In-Putty]: https://mediatemple.net/community/products/dv/204404604/using-ssh-in-putty-
 
 <!-- ## Troubleshooting
diff --git a/doc/install/digitaloceandocker.md b/doc/install/digitaloceandocker.md
index b6bf7c95527..bff7d97830f 100644
--- a/doc/install/digitaloceandocker.md
+++ b/doc/install/digitaloceandocker.md
@@ -14,9 +14,9 @@ locally on either macOS or Linux.
 
 ### On macOS
 
-#### Install Docker Toolbox
+#### Install Docker Desktop
 
-- <https://www.docker.com/products/docker-toolbox>
+- <https://www.docker.com/products/docker-desktop>
 
 ### On Linux
 
@@ -115,7 +115,7 @@ docker-machine ip gitlab-test-env-do
 # example output: 192.168.151.134
 ```
 
-Browse to: <http://192.168.151.134:8888/>.
+Browse to: `http://192.168.151.134:8888/`.
 
 #### Execute interactive shell/edit configuration
 
diff --git a/doc/install/google_cloud_platform/index.md b/doc/install/google_cloud_platform/index.md
index 56e5ecb3a58..aba30870640 100644
--- a/doc/install/google_cloud_platform/index.md
+++ b/doc/install/google_cloud_platform/index.md
@@ -72,7 +72,7 @@ By default, Google assigns an ephemeral IP to your instance. It is strongly
 recommended to assign a static IP if you are going to use GitLab in production
 and use a domain name as we'll see below.
 
-Read Google's documentation on how to [promote an ephemeral IP address][ip].
+Read Google's documentation on how to [promote an ephemeral IP address](https://cloud.google.com/compute/docs/ip-addresses/reserve-static-external-ip-address#promote_ephemeral_ip).
 
 ### Using a domain name
 
@@ -133,9 +133,7 @@ Kerberos, etc. Here are some documents you might be interested in reading:
 - [GitLab Container Registry configuration](../../administration/packages/container_registry.md)
 
 [freetrial]: https://console.cloud.google.com/freetrial "GCP free trial"
-[ip]: https://cloud.google.com/compute/docs/configure-instance-ip-addresses#promote_ephemeral_ip "Configuring an Instance's IP Addresses"
 [gcp]: https://cloud.google.com/ "Google Cloud Platform"
-[launcher]: https://cloud.google.com/launcher/ "Google Cloud Launcher home page"
 [req]: ../requirements.md "GitLab hardware and software requirements"
 [ssh]: https://cloud.google.com/compute/docs/instances/connecting-to-instance "Connecting to Linux Instances"
 [omni-smtp]: https://docs.gitlab.com/omnibus/settings/smtp.html#smtp-settings "Omnibus GitLab SMTP settings"
diff --git a/doc/install/installation.md b/doc/install/installation.md
index 41ce6cb2f8b..dd4b5544659 100644
--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -10,7 +10,7 @@ other installation options, see the [main installation page](README.md).
 It was created for and tested on **Debian/Ubuntu** operating systems.
 Read [requirements.md](requirements.md) for hardware and operating system requirements.
 If you want to install on RHEL/CentOS, we recommend using the
-[Omnibus packages](https://about.gitlab.com/downloads/).
+[Omnibus packages](https://about.gitlab.com/install/).
 
 This guide is long because it covers many cases and includes all commands you
 need, this is [one of the few installation scripts that actually works out of the box](https://twitter.com/robinvdvleuten/status/424163226532986880).
@@ -25,14 +25,14 @@ following the
 
 ## Consider the Omnibus package installation
 
-Since an installation from source is a lot of work and error prone we strongly recommend the fast and reliable [Omnibus package installation](https://about.gitlab.com/downloads/) (deb/rpm).
+Since an installation from source is a lot of work and error prone we strongly recommend the fast and reliable [Omnibus package installation](https://about.gitlab.com/install/) (deb/rpm).
 
-One reason the Omnibus package is more reliable is its use of Runit to restart any of the GitLab processes in case one crashes.
+One reason the Omnibus package is more reliable is its use of runit to restart any of the GitLab processes in case one crashes.
 On heavily used GitLab instances the memory usage of the Sidekiq background worker will grow over time.
 
 Omnibus packages solve this by [letting the Sidekiq terminate gracefully](../administration/operations/sidekiq_memory_killer.md) if it uses too much memory.
-After this termination Runit will detect Sidekiq is not running and will start it.
-Since installations from source don't use Runit for process supervision, Sidekiq
+After this termination runit will detect Sidekiq is not running and will start it.
+Since installations from source don't use runit for process supervision, Sidekiq
 can't be terminated and its memory usage will grow over time.
 
 ## Select version to install
@@ -84,7 +84,7 @@ The GitLab installation consists of setting up the following components:
 1. [Database](#6-database).
 1. [Redis](#7-redis).
 1. [GitLab](#8-gitlab).
-1. [Nginx](#9-nginx).
+1. [NGINX](#9-nginx).
 
 ## 1. Packages and dependencies
 
@@ -205,7 +205,7 @@ The Ruby interpreter is required to run GitLab.
 **Note:** The current supported Ruby (MRI) version is 2.6.x. GitLab 12.2
   dropped support for Ruby 2.5.x.
 
-The use of Ruby version managers such as [RVM], [rbenv] or [chruby] with GitLab
+The use of Ruby version managers such as [RVM], [rbenv](https://github.com/rbenv/rbenv) or [chruby] with GitLab
 in production, frequently leads to hard to diagnose problems. For example,
 GitLab Shell is called from OpenSSH, and having a version manager can prevent
 pushing and pulling over SSH. Version managers are not supported and we strongly
@@ -448,7 +448,7 @@ sudo -u git -H mkdir -p public/uploads/
 # now that files in public/uploads are served by gitlab-workhorse
 sudo chmod 0700 public/uploads
 
-# Change the permissions of the directory where CI job traces are stored
+# Change the permissions of the directory where CI job logs are stored
 sudo chmod -R u+rwX builds/
 
 # Change the permissions of the directory where CI artifacts are stored
@@ -484,6 +484,9 @@ sudo -u git -H git config --global repack.writeBitmaps true
 # Enable push options
 sudo -u git -H git config --global receive.advertisePushOptions true
 
+# Enable fsyncObjectFiles to reduce risk of repository corruption if the server crashes
+sudo -u git -H git config --global core.fsyncObjectFiles true
+
 # Configure Redis connection settings
 sudo -u git -H cp config/resque.yml.example config/resque.yml
 
@@ -529,7 +532,7 @@ sudo -u git -H chmod o-rwx config/database.yml
 ### Install Gems
 
 NOTE: **Note:**
-As of Bundler 1.5.2, you can invoke `bundle install -jN` (where `N` is the number of your processor cores) and enjoy parallel gems installation with measurable difference in completion time (~60% faster). Check the number of your cores with `nproc`. For more information, see this [post](https://robots.thoughtbot.com/parallel-gem-installing-using-bundler).
+As of Bundler 1.5.2, you can invoke `bundle install -jN` (where `N` is the number of your processor cores) and enjoy parallel gems installation with measurable difference in completion time (~60% faster). Check the number of your cores with `nproc`. For more information, see this [post](https://thoughtbot.com/blog/parallel-gem-installing-using-bundler).
 
 Make sure you have `bundle` (run `bundle -v`):
 
@@ -585,7 +588,7 @@ You can specify a different Git repository by providing it as an extra parameter
 sudo -u git -H bundle exec rake "gitlab:workhorse:install[/home/git/gitlab-workhorse,https://example.com/gitlab-workhorse.git]" RAILS_ENV=production
 ```
 
-### Install gitlab-elasticsearch-indexer
+### Install GitLab-Elasticsearch-indexer`
 
 GitLab-Elasticsearch-Indexer uses [GNU Make](https://www.gnu.org/software/make/). The
 following command-line will install GitLab-Elasticsearch-Indexer in `/home/git/gitlab-elasticsearch-indexer`
@@ -643,7 +646,7 @@ sudo -u git -H editor config.toml
 ```
 
 For more information about configuring Gitaly see
-[doc/administration/gitaly](../administration/gitaly).
+[the Gitaly documentation](../administration/gitaly/index.md).
 
 ### Start Gitaly
 
@@ -746,10 +749,10 @@ sudo service gitlab start
 sudo /etc/init.d/gitlab restart
 ```
 
-## 9. Nginx
+## 9. NGINX
 
 NOTE: **Note:**
-Nginx is the officially supported web server for GitLab. If you cannot or do not want to use Nginx as your web server, see [GitLab recipes](https://gitlab.com/gitlab-org/gitlab-recipes/).
+NGINX is the officially supported web server for GitLab. If you cannot or do not want to use NGINX as your web server, see [GitLab recipes](https://gitlab.com/gitlab-org/gitlab-recipes/).
 
 ### Installation
 
@@ -781,21 +784,21 @@ Make sure to edit the config file to match your setup. Also, ensure that you mat
 sudo editor /etc/nginx/sites-available/gitlab
 ```
 
-If you intend to enable GitLab pages, there is a separate Nginx config you need
+If you intend to enable GitLab Pages, there is a separate NGINX config you need
 to use. Read all about the needed configuration at the
 [GitLab Pages administration guide](../administration/pages/index.md).
 
-**Note:** If you want to use HTTPS, replace the `gitlab` Nginx config with `gitlab-ssl`. See [Using HTTPS](#using-https) for HTTPS configuration details.
+**Note:** If you want to use HTTPS, replace the `gitlab` NGINX config with `gitlab-ssl`. See [Using HTTPS](#using-https) for HTTPS configuration details.
 
 ### Test Configuration
 
-Validate your `gitlab` or `gitlab-ssl` Nginx config file with the following command:
+Validate your `gitlab` or `gitlab-ssl` NGINX config file with the following command:
 
 ```sh
 sudo nginx -t
 ```
 
-You should receive `syntax is okay` and `test is successful` messages. If you receive errors check your `gitlab` or `gitlab-ssl` Nginx config file for typos, etc. as indicated in the error message given.
+You should receive `syntax is okay` and `test is successful` messages. If you receive errors check your `gitlab` or `gitlab-ssl` NGINX config file for typos, etc. as indicated in the error message given.
 
 NOTE: **Note:**
 Verify that the installed version is greater than 1.12.1 by running `nginx -v`. If it's lower, you may receive the error below:
@@ -855,7 +858,7 @@ To use GitLab with HTTPS:
 1. In the `config.yml` of GitLab Shell:
    1. Set `gitlab_url` option to the HTTPS endpoint of GitLab (e.g. `https://git.example.com`).
    1. Set the certificates using either the `ca_file` or `ca_path` option.
-1. Use the `gitlab-ssl` Nginx example config instead of the `gitlab` config.
+1. Use the `gitlab-ssl` NGINX example config instead of the `gitlab` config.
    1. Update `YOUR_SERVER_FQDN`.
    1. Update `ssl_certificate` and `ssl_certificate_key`.
    1. Review the configuration file and consider applying other security and performance enhancing features.
@@ -881,9 +884,9 @@ See the ["Reply by email" documentation](../administration/reply_by_email.md) fo
 
 You can configure LDAP authentication in `config/gitlab.yml`. Restart GitLab after editing this file.
 
-### Using Custom Omniauth Providers
+### Using Custom OmniAuth Providers
 
-See the [omniauth integration document](../integration/omniauth.md).
+See the [OmniAuth integration documentation](../integration/omniauth.md).
 
 ### Build your projects
 
@@ -942,7 +945,7 @@ You also need to change the corresponding options (e.g. `ssh_user`, `ssh_host`,
 
 ### Additional Markup Styles
 
-Apart from the always supported markdown style, there are other rich text files that GitLab can display. But you might have to install a dependency to do so. See the [github-markup gem README](https://github.com/gitlabhq/markup#markups) for more information.
+Apart from the always supported Markdown style, there are other rich text files that GitLab can display. But you might have to install a dependency to do so. See the [`github-markup` gem README](https://github.com/gitlabhq/markup#markups) for more information.
 
 ### Using Puma
 
@@ -968,12 +971,12 @@ To use GitLab with Puma:
 ### "You appear to have cloned an empty repository."
 
 If you see this message when attempting to clone a repository hosted by GitLab,
-this is likely due to an outdated Nginx or Apache configuration, or a missing or
+this is likely due to an outdated NGINX or Apache configuration, or a missing or
 misconfigured GitLab Workhorse instance. Double-check that you've
 [installed Go](#3-go), [installed GitLab Workhorse](#install-gitlab-workhorse),
-and correctly [configured Nginx](#site-configuration).
+and correctly [configured NGINX](#site-configuration).
 
-### google-protobuf "LoadError: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found"
+### `google-protobuf` "LoadError: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found"
 
 This can happen on some platforms for some versions of the
 `google-protobuf` gem. The workaround is to install a source-only
@@ -1022,5 +1025,4 @@ sudo yum groupinstall 'Development Tools'
 ```
 
 [RVM]: https://rvm.io/ "RVM Homepage"
-[rbenv]: https://github.com/sstephenson/rbenv "rbenv on GitHub"
 [chruby]: https://github.com/postmodern/chruby "chruby on GitHub"
diff --git a/doc/install/openshift_and_gitlab/index.md b/doc/install/openshift_and_gitlab/index.md
index cfd0fd48c70..010e56fb097 100644
--- a/doc/install/openshift_and_gitlab/index.md
+++ b/doc/install/openshift_and_gitlab/index.md
@@ -14,14 +14,14 @@ for details.
 ## Introduction
 
 [OpenShift Origin](https://www.okd.io/) (**Note:** renamed to OKD in Aug 2018) is an open source container application
-platform created by [RedHat], based on [kubernetes](https://kubernetes.io/) and [Docker]. That means
+platform created by [RedHat], based on [Kubernetes](https://kubernetes.io/) and [Docker]. That means
 you can host your own PaaS for free and almost with no hassle.
 
 In this tutorial, we will see how to deploy GitLab in OpenShift using GitLab's
 official Docker image while getting familiar with the web interface and CLI
 tools that will help us achieve our goal.
 
-For a video demonstration on installing GitLab on OpenShift, check the article [In 13 minutes from Kubernetes to a complete application development tool](https://about.gitlab.com/2016/11/14/idea-to-production/).
+For a video demonstration on installing GitLab on OpenShift, check the article [In 13 minutes from Kubernetes to a complete application development tool](https://about.gitlab.com/blog/2016/11/14/idea-to-production/).
 
 ---
 
@@ -30,7 +30,7 @@ For a video demonstration on installing GitLab on OpenShift, check the article [
 CAUTION: **Caution:** This information is no longer up to date, as the current versions
 have changed and products have been renamed.
 
-OpenShift 3 is not yet deployed on RedHat's offered Online platform, [openshift.com](https://www.openshift.com/),
+OpenShift 3 is not yet deployed on RedHat's offered [Online platform](https://www.openshift.com/),
 so in order to test it, we will use an [all-in-one Virtualbox image](https://www.okd.io/minishift/) that is
 offered by the OpenShift developers and managed by Vagrant. If you haven't done
 already, go ahead and install the following components as they are essential to
@@ -38,14 +38,14 @@ test OpenShift easily:
 
 - [VirtualBox]
 - [Vagrant]
-- [OpenShift Client][oc] (`oc` for short)
+- [OpenShift Client](https://docs.okd.io/latest/cli_reference/get_started_cli.html) (`oc` for short)
 
 It is also important to mention that for the purposes of this tutorial, the
 latest Origin release is used:
 
 - **oc** `v1.3.0` (must be [installed][oc-gh] locally on your computer)
-- **openshift** `v1.3.0` (is pre-installed in the [VM image][vm-new])
-- **kubernetes** `v1.3.0` (is pre-installed in the [VM image][vm-new])
+- **OpenShift** `v1.3.0` (is pre-installed in the [VM image][vm-new])
+- **Kubernetes** `v1.3.0` (is pre-installed in the [VM image][vm-new])
 
 >**Note:**
 If you intend to deploy GitLab on a production OpenShift cluster, there are some
@@ -59,7 +59,7 @@ on your computer.
 ## Getting familiar with OpenShift Origin
 
 The environment we are about to use is based on CentOS 7 which comes with all
-the tools needed pre-installed: Docker, kubernetes, OpenShift, etcd.
+the tools needed pre-installed: Docker, Kubernetes, OpenShift, etcd.
 
 ### Test OpenShift using Vagrant
 
@@ -92,7 +92,7 @@ Now that OpenShift is set up, let's see how the web console looks like.
 
 Once Vagrant finishes its thing with the VM, you will be presented with a
 message which has some important information. One of them is the IP address
-of the deployed OpenShift platform and in particular <https://10.2.2.2:8443/console/>.
+of the deployed OpenShift platform and in particular `https://10.2.2.2:8443/console/`.
 Open this link with your browser and accept the self-signed certificate in
 order to proceed.
 
@@ -101,7 +101,7 @@ landing page looks like:
 
 ![openshift web console](img/web-console.png)
 
-You can see that a number of [projects] are already created for testing purposes.
+You can see that a number of [projects](https://docs.okd.io/latest/dev_guide/projects.html) are already created for testing purposes.
 
 If you head over the `openshift-infra` project, a number of services with their
 respective pods are there to explore.
@@ -109,15 +109,15 @@ respective pods are there to explore.
 ![openshift web console](img/openshift-infra-project.png)
 
 We are not going to explore the whole interface, but if you want to learn about
-the key concepts of OpenShift, read the [core concepts reference][core] in the
-official documentation.
+the key concepts of OpenShift, read the [core concepts reference](https://docs.okd.io/latest/architecture/core_concepts/index.html)
+in the official documentation.
 
 ### Explore the OpenShift CLI
 
 OpenShift Client (`oc`), is a powerful CLI tool that talks to the OpenShift API
 and performs pretty much everything you can do from the web UI and much more.
 
-Assuming you have [installed][oc] it, let's explore some of its main
+Assuming you have [installed](https://docs.okd.io/latest/cli_reference/get_started_cli.html) it, let's explore some of its main
 functionalities.
 
 Let's first see the version of `oc`:
@@ -130,7 +130,7 @@ kubernetes v1.3.0+52492b4
 ```
 
 With `oc help` you can see the top level arguments you can run with `oc` and
-interact with your cluster, kubernetes, run applications, create projects and
+interact with your cluster, Kubernetes, run applications, create projects and
 much more.
 
 Let's login to the all-in-one VM and see how to achieve the same results like
@@ -174,7 +174,7 @@ The last command should spit a bunch of information about the statuses of the
 pods and the services, which if you look closely is what we encountered in the
 second image when we explored the web console.
 
-You can always read more about `oc` in the [OpenShift CLI documentation][oc].
+You can always read more about `oc` in the [OpenShift CLI documentation](https://docs.okd.io/latest/cli_reference/get_started_cli.html).
 
 ### Troubleshooting the all-in-one VM
 
@@ -250,7 +250,7 @@ The next step is to import the OpenShift template for GitLab.
 
 ### Import the template
 
-The [template][templates] is basically a JSON file which describes a set of
+The [template](https://docs.okd.io/latest/architecture/core_concepts/templates.html) is basically a JSON file which describes a set of
 related object definitions to be created together, as well as a set of
 parameters for those objects.
 
@@ -318,7 +318,7 @@ password for PostgreSQL, it will be created automatically.
 The `gitlab.apps.10.2.2.2.nip.io` hostname that is used by default will
 resolve to the host with IP `10.2.2.2` which is the IP our VM uses. It is a
 trick to have distinct FQDNs pointing to services that are on our local network.
-Read more on how this works in <http://nip.io>.
+Read more on how this works in <https://nip.io>.
 
 Now that we configured this, let's see how to manage and scale GitLab.
 
@@ -349,13 +349,13 @@ tab.
 
 ![GitLab logs](img/gitlab-logs.png)
 
-At a point you should see a _**gitlab Reconfigured!**_ message in the logs.
+At a point you should see a `gitlab Reconfigured!` message in the logs.
 Navigate back to the **Overview** and hopefully all pods will be up and running.
 
 ![GitLab running](img/gitlab-running.png)
 
 Congratulations! You can now navigate to your new shinny GitLab instance by
-visiting <http://gitlab.apps.10.2.2.2.nip.io> where you will be asked to
+visiting `http://gitlab.apps.10.2.2.2.nip.io` where you will be asked to
 change the root user password. Login using `root` as username and providing the
 password you just set, and start using GitLab!
 
@@ -366,7 +366,7 @@ of resources, you'd be happy to know that you can scale up with the push of a
 button.
 
 In the **Overview** page just click the up arrow button in the pod where
-GitLab is. The change is instant and you can see the number of [replicas] now
+GitLab is. The change is instant and you can see the number of [replicas](https://docs.okd.io/latest/architecture/core_concepts/deployments.html#replication-controllers) now
 running scaled to 2.
 
 ![GitLab scale](img/gitlab-scale.png)
@@ -384,7 +384,7 @@ scale up. If a pod is in pending state for too long, you can navigate to
 ### Scale GitLab using the `oc` CLI
 
 Using `oc` is super easy to scale up the replicas of a pod. You may want to
-skim through the [basic CLI operations][basic-cli] to get a taste how the CLI
+skim through the [basic CLI operations](https://docs.okd.io/latest/cli_reference/basic_cli_operations.html) to get a taste how the CLI
 commands are used. Pay extra attention to the object types as we will use some
 of them and their abbreviated versions below.
 
@@ -457,7 +457,7 @@ In case you were wondering whether there is an option to autoscale a pod based
 on the resources of your server, the answer is yes, of course there is.
 
 We will not expand on this matter, but feel free to read the documentation on
-OpenShift's website about [autoscaling].
+OpenShift's website about [autoscaling](https://docs.okd.io/latest/dev_guide/pod_autoscaling.html).
 
 ## Current limitations
 
@@ -472,7 +472,7 @@ bother us. In any case, it is something to keep in mind when deploying GitLab
 on a production cluster.
 
 In order to deploy GitLab on a production cluster, you will need to assign the
-GitLab service account to the `anyuid` [Security Context Constraints][scc].
+GitLab service account to the `anyuid` [Security Context Constraints](https://docs.okd.io/latest/admin_guide/manage_scc.html).
 
 For OpenShift v3.0, you will need to do this manually:
 
@@ -505,25 +505,16 @@ application and you are done. You are ready to login to your new GitLab instance
 
 And remember that in this tutorial we just scratched the surface of what Origin
 is capable of. As always, you can refer to the detailed
-[documentation][openshift-docs] to learn more about deploying your own OpenShift
+[documentation](https://docs.okd.io) to learn more about deploying your own OpenShift
 PaaS and managing your applications with the ease of containers.
 
 [RedHat]: https://www.redhat.com/en "RedHat website"
 [vm-new]: https://app.vagrantup.com/openshift/boxes/origin-all-in-one "Official OpenShift Vagrant box on Vagrant Cloud"
 [template]: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/docker/openshift-template.json "OpenShift template for GitLab"
 [Docker]: https://www.docker.com "Docker website"
-[oc]: https://docs.openshift.org/latest/cli_reference/get_started_cli.html "Documentation - oc CLI documentation"
 [VirtualBox]: https://www.virtualbox.org/wiki/Downloads "VirtualBox downloads"
 [Vagrant]: https://www.vagrantup.com/downloads.html "Vagrant downloads"
-[projects]: https://docs.openshift.org/latest/dev_guide/projects.html "Documentation - Projects overview"
-[core]: https://docs.openshift.org/latest/architecture/core_concepts/index.html "Documentation - Core concepts of OpenShift Origin"
-[templates]: https://docs.openshift.org/latest/architecture/core_concepts/templates.html "Documentation - OpenShift templates"
 [old-post]: https://blog.openshift.com/deploy-gitlab-openshift/ "Old post - Deploy GitLab on OpenShift"
 [line]: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/658c065c8d022ce858dd63eaeeadb0b2ddc8deea/docker/openshift-template.json#L239 "GitLab - OpenShift template"
 [oc-gh]: https://github.com/openshift/origin/releases/tag/v1.3.0 "OpenShift Origin 1.3.0 release on GitHub"
-[ha]: ../../administration/high_availability/gitlab.html "Documentation - GitLab High Availability"
-[replicas]: https://docs.openshift.org/latest/architecture/core_concepts/deployments.html#replication-controllers "Documentation - Replication controller"
-[autoscaling]: https://docs.openshift.org/latest/dev_guide/pod_autoscaling.html "Documentation - Autoscale"
-[basic-cli]: https://docs.openshift.org/latest/cli_reference/basic_cli_operations.html "Documentation - Basic CLI operations"
-[openshift-docs]: https://docs.openshift.org "OpenShift documentation"
-[scc]: https://docs.openshift.org/latest/admin_guide/manage_scc.html "Documentation - Managing Security Context Constraints"
+[ha]: ../../administration/high_availability/gitlab.md "Documentation - GitLab High Availability"
diff --git a/doc/install/requirements.md b/doc/install/requirements.md
index 21bee67ec1d..8b53ee7c3e1 100644
--- a/doc/install/requirements.md
+++ b/doc/install/requirements.md
@@ -69,7 +69,7 @@ This is the recommended minimum hardware for a handful of example GitLab user ba
 - 4 cores supports up to 500 users
 - 8 cores supports up to 1,000 users
 - 32 cores supports up to 5,000 users
-- More users? Run it high-availability on [multiple application servers](https://about.gitlab.com/high-availability/)
+- More users? Run it high-availability on [multiple application servers](https://about.gitlab.com/solutions/high-availability/)
 
 ### Memory
 
@@ -86,7 +86,7 @@ errors during usage.
 - 16GB RAM supports up to 500 users
 - 32GB RAM supports up to 1,000 users
 - 128GB RAM supports up to 5,000 users
-- More users? Run it high-availability on [multiple application servers](https://about.gitlab.com/high-availability/)
+- More users? Run it high-availability on [multiple application servers](https://about.gitlab.com/solutions/high-availability/)
 
 We recommend having at least [2GB of swap on your server](https://askubuntu.com/a/505344/310789), even if you currently have
 enough available RAM. Having swap will help reduce the chance of errors occurring
@@ -139,7 +139,7 @@ If you are using [GitLab Geo](../development/geo.md):
 - The
   [tracking database](../development/geo.md#using-the-tracking-database)
   requires the
-  [postgres_fdw](https://www.postgresql.org/docs/9.6/static/postgres-fdw.html)
+  [postgres_fdw](https://www.postgresql.org/docs/9.6/postgres-fdw.html)
   extension.
 
 ```
@@ -148,13 +148,13 @@ CREATE EXTENSION postgres_fdw;
 
 ## Unicorn Workers
 
-For most instances we recommend using: (CPU cores * 1.5) + 1 = unicorn workers.
-For example a node with 4 cores would have 7 unicorn workers.
+For most instances we recommend using: (CPU cores * 1.5) + 1 = Unicorn workers.
+For example a node with 4 cores would have 7 Unicorn workers.
 
-For all machines that have 2GB and up we recommend a minimum of three unicorn workers.
+For all machines that have 2GB and up we recommend a minimum of three Unicorn workers.
 If you have a 1GB machine we recommend to configure only two Unicorn workers to prevent excessive swapping.
 
-As long as you have enough available CPU and memory capacity, it's okay to increase the number of unicorn workers and this will usually help to reduce the response time of the applications and increase the ability to handle parallel requests.
+As long as you have enough available CPU and memory capacity, it's okay to increase the number of Unicorn workers and this will usually help to reduce the response time of the applications and increase the ability to handle parallel requests.
 
 To change the Unicorn workers when you have the Omnibus package (which defaults to the recommendation above) please see [the Unicorn settings in the Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/unicorn.html).
 
diff --git a/doc/integration/README.md b/doc/integration/README.md
index 55f9666e3a3..3a08303bf20 100644
--- a/doc/integration/README.md
+++ b/doc/integration/README.md
@@ -47,10 +47,10 @@ application, most likely Sidekiq. There are 2 approaches you can take to solve t
 
 **OS main trusted chain**
 
-This [resource](http://kb.kerio.com/product/kerio-connect/server-configuration/ssl-certificates/adding-trusted-root-certificates-to-the-server-1605.html)
+This [resource](https://manuals.gfi.com/en/kerio/connect/content/server-configuration/ssl-certificates/adding-trusted-root-certificates-to-the-server-1605.html)
 has all the information you need to add a certificate to the main trusted chain.
 
-This [answer](http://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu)
+This [answer](https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu)
 at Super User also has relevant information.
 
 **Omnibus Trusted Chain**
diff --git a/doc/integration/bitbucket.md b/doc/integration/bitbucket.md
index 1973d18ca34..63ffa69e606 100644
--- a/doc/integration/bitbucket.md
+++ b/doc/integration/bitbucket.md
@@ -137,7 +137,7 @@ you can [disable Sign-Ins in the admin panel](omniauth.md#enable-or-disable-sign
 
 [init-oauth]: omniauth.md#initial-omniauth-configuration
 [bb-import]: ../workflow/importing/import_projects_from_bitbucket.md
-[bb-old]: https://gitlab.com/gitlab-org/gitlab-foss/blob/8-14-stable/doc/integration/bitbucket.md
+[bb-old]: https://gitlab.com/gitlab-org/gitlab/blob/8-14-stable/doc/integration/bitbucket.md
 [bitbucket-docs]: https://confluence.atlassian.com/bitbucket/use-the-ssh-protocol-with-bitbucket-cloud-221449711.html#UsetheSSHprotocolwithBitbucketCloud-KnownhostorBitbucket%27spublickeyfingerprints
 [reconfigure GitLab]: ../administration/restart_gitlab.md#omnibus-gitlab-reconfigure
 [restart]: ../administration/restart_gitlab.md#installations-from-source
diff --git a/doc/integration/elasticsearch.md b/doc/integration/elasticsearch.md
index 000bb0c2def..da53987ce1b 100644
--- a/doc/integration/elasticsearch.md
+++ b/doc/integration/elasticsearch.md
@@ -1,7 +1,7 @@
 # Elasticsearch integration **(STARTER ONLY)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/109 "Elasticsearch Merge Request") in GitLab [Starter](https://about.gitlab.com/pricing/) 8.4. Support
-> for [Amazon Elasticsearch](http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-gsg.html) was [introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/1305) in GitLab
+> for [Amazon Elasticsearch](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-gsg.html) was [introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/1305) in GitLab
 > [Starter](https://about.gitlab.com/pricing/) 9.0.
 
 This document describes how to set up Elasticsearch with GitLab. Once enabled,
@@ -32,7 +32,7 @@ of this document.
 NOTE: **Note:**
 Elasticsearch should be installed on a separate server, whether you install
 it yourself or by using the
-[Amazon Elasticsearch](http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-gsg.html)
+[Amazon Elasticsearch](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-gsg.html)
 service. Running Elasticsearch on the same server as GitLab is not recommended
 and it will likely cause performance degradation on the GitLab installation.
 
@@ -42,7 +42,7 @@ updated automatically.
 
 ## Elasticsearch repository indexer (beta)
 
-In order to improve elasticsearch indexing performance, GitLab has made available a [new indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer).
+In order to improve Elasticsearch indexing performance, GitLab has made available a [new indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer).
 This will replace the included Ruby indexer in the future but should be considered beta software for now, so there may be some bugs.
 
 The Elasticsearch Go indexer is included in Omnibus for GitLab 11.8 and newer.
@@ -110,7 +110,7 @@ Example:
 PREFIX=/usr sudo -E make install
 ```
 
-Once installed, enable it under your instance's elasticsearch settings explained [below](#enabling-elasticsearch).
+Once installed, enable it under your instance's Elasticsearch settings explained [below](#enabling-elasticsearch).
 
 ## System Requirements
 
@@ -136,19 +136,19 @@ Click **Save changes** for the changes to take effect.
 
 The following Elasticsearch settings are available:
 
-| Parameter                           | Description |
-| ---------                           | ----------- |
-| `Elasticsearch indexing`            | Enables/disables Elasticsearch indexing. You may want to enable indexing but disable search in order to give the index time to be fully completed, for example. Also, keep in mind that this option doesn't have any impact on existing data, this only enables/disables background indexer which tracks data changes. So by enabling this you will not get your existing data indexed, use special rake task for that as explained in [Adding GitLab's data to the Elasticsearch index](#adding-gitlabs-data-to-the-elasticsearch-index). |
-| `Use the new repository indexer (beta)` | Perform repository indexing using [GitLab Elasticsearch Indexer](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). |
-| `Search with Elasticsearch enabled` | Enables/disables using Elasticsearch in search. |
-| `URL`                              | The URL to use for connecting to Elasticsearch. Use a comma-separated list to support clustering (e.g., `http://host1, https://host2:9200`). If your Elasticsearch instance is password protected, pass the `username:password` in the URL (e.g., `http://<username>:<password>@<elastic_host>:9200/`). |
-| `Number of Elasticsearch shards` | Elasticsearch indexes are split into multiple shards for performance reasons. In general, larger indexes need to have more shards. Changes to this value do not take effect until the index is recreated. You can read more about tradeoffs in the [Elasticsearch documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-create-index.html#create-index-settings) |
-| `Number of Elasticsearch replicas` | Each Elasticsearch shard can have a number of replicas. These are a complete copy of the shard, and can provide increased query performance or resilience against hardware failure. Increasing this value will greatly increase total disk space required by the index. |
-| `Limit namespaces and projects that can be indexed` | Enabling this will allow you to select namespaces and projects to index. All other namespaces and projects will use database search instead. Please note that if you enable this option but do not select any namespaces or projects, none will be indexed. [Read more below](#limiting-namespaces-and-projects).
-| `Using AWS hosted Elasticsearch with IAM credentials` | Sign your Elasticsearch requests using [AWS IAM authorization](http://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html) or [AWS EC2 Instance Profile Credentials](http://docs.aws.amazon.com/codedeploy/latest/userguide/getting-started-create-iam-instance-profile.html#getting-started-create-iam-instance-profile-cli). The policies must be configured to allow `es:*` actions. |
-| `AWS Region` | The AWS region your Elasticsearch service is located in. |
-| `AWS Access Key` | The AWS access key. |
-| `AWS Secret Access Key` | The AWS secret access key. |
+| Parameter                                             | Description |
+| ----------------------------------------------------- | ----------- |
+| `Elasticsearch indexing`                              | Enables/disables Elasticsearch indexing. You may want to enable indexing but disable search in order to give the index time to be fully completed, for example. Also, keep in mind that this option doesn't have any impact on existing data, this only enables/disables background indexer which tracks data changes. So by enabling this you will not get your existing data indexed, use special rake task for that as explained in [Adding GitLab's data to the Elasticsearch index](#adding-gitlabs-data-to-the-elasticsearch-index). |
+| `Use the new repository indexer (beta)`               | Perform repository indexing using [GitLab Elasticsearch Indexer](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). |
+| `Search with Elasticsearch enabled`                   | Enables/disables using Elasticsearch in search. |
+| `URL`                                                 | The URL to use for connecting to Elasticsearch. Use a comma-separated list to support clustering (e.g., `http://host1, https://host2:9200`). If your Elasticsearch instance is password protected, pass the `username:password` in the URL (e.g., `http://<username>:<password>@<elastic_host>:9200/`). |
+| `Number of Elasticsearch shards`                      | Elasticsearch indexes are split into multiple shards for performance reasons. In general, larger indexes need to have more shards. Changes to this value do not take effect until the index is recreated. You can read more about tradeoffs in the [Elasticsearch documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-create-index.html#create-index-settings) |
+| `Number of Elasticsearch replicas`                    | Each Elasticsearch shard can have a number of replicas. These are a complete copy of the shard, and can provide increased query performance or resilience against hardware failure. Increasing this value will greatly increase total disk space required by the index. |
+| `Limit namespaces and projects that can be indexed`   | Enabling this will allow you to select namespaces and projects to index. All other namespaces and projects will use database search instead. Please note that if you enable this option but do not select any namespaces or projects, none will be indexed. [Read more below](#limiting-namespaces-and-projects).
+| `Using AWS hosted Elasticsearch with IAM credentials` | Sign your Elasticsearch requests using [AWS IAM authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html) or [AWS EC2 Instance Profile Credentials](https://docs.aws.amazon.com/codedeploy/latest/userguide/getting-started-create-iam-instance-profile.html#getting-started-create-iam-instance-profile-cli). The policies must be configured to allow `es:*` actions. |
+| `AWS Region`                                          | The AWS region your Elasticsearch service is located in. |
+| `AWS Access Key`                                      | The AWS access key. |
+| `AWS Secret Access Key`                               | The AWS secret access key. |
 
 ### Limiting namespaces and projects
 
@@ -402,7 +402,7 @@ There are several rake tasks available to you via the command line:
     - `sudo gitlab-rake gitlab:elastic:index_projects`
     - `sudo gitlab-rake gitlab:elastic:index_snippets`
 - [`sudo gitlab-rake gitlab:elastic:index_projects`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/tasks/gitlab/elastic.rake)
-  - This iterates over all projects and queues sidekiq jobs to index them in the background.
+  - This iterates over all projects and queues Sidekiq jobs to index them in the background.
 - [`sudo gitlab-rake gitlab:elastic:index_projects_status`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/tasks/gitlab/elastic.rake)
   - This determines the overall status of the indexing. It is done by counting the total number of indexed projects, dividing by a count of the total number of projects, then multiplying by 100.
 - [`sudo gitlab-rake gitlab:elastic:create_empty_index`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/tasks/gitlab/elastic.rake)
@@ -580,6 +580,6 @@ Here are some common pitfalls and how to overcome them:
   `http.max_content_length` setting in `elasticsearch.yml`. Increase it to a
   larger size and restart your Elasticsearch cluster.
 
-  AWS has [fixed limits](http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-limits.html)
+  AWS has [fixed limits](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-limits.html)
   for this setting ("Maximum Size of HTTP Request Payloads"), based on the size of
   the underlying instance.
diff --git a/doc/integration/google.md b/doc/integration/google.md
index 4f6999571b6..97323557878 100644
--- a/doc/integration/google.md
+++ b/doc/integration/google.md
@@ -16,7 +16,7 @@ In Google's side:
      the randomly generated ID or choose a new one.
 1. Refresh the page and you should see your new project in the list
 1. Go to the [Google API Console](https://console.developers.google.com/apis/dashboard)
-1. Select the previously created project form the upper left corner
+1. Select the previously created project in the upper left corner
 1. Select **Credentials** from the sidebar
 1. Select **OAuth consent screen** and fill the form with the required information
 1. In the **Credentials** tab, select **Create credentials > OAuth client ID**
@@ -41,6 +41,13 @@ In Google's side:
    - Cloud Resource Manager API
    - Cloud Billing API
 
+   To do so you need to:
+
+   1. Go to the [Google API Console](https://console.developers.google.com/apis/dashboard).
+   1. Click on **ENABLE APIS AND SERVICES** button at the top of the page.
+   1. Find each of the above APIs. On the page for the API, press the **ENABLE** button.
+      It may take a few minutes for the API to be fully functional.
+
 On your GitLab server:
 
 1. Open the configuration file.
diff --git a/doc/integration/jenkins.md b/doc/integration/jenkins.md
index d865f977799..a54f6843c53 100644
--- a/doc/integration/jenkins.md
+++ b/doc/integration/jenkins.md
@@ -33,7 +33,7 @@ and [Migrating from Jenkins to GitLab](https://www.youtube.com/watch?v=RlEVGOpYF
   therefore, you opt for keep using Jenkins to build your apps. Show the results of your
   pipelines directly in GitLab.
 
-For a real use case, read the blog post [Continuous integration: From Jenkins to GitLab using Docker](https://about.gitlab.com/2017/07/27/docker-my-precious/).
+For a real use case, read the blog post [Continuous integration: From Jenkins to GitLab using Docker](https://about.gitlab.com/blog/2017/07/27/docker-my-precious/).
 
 NOTE: **Moving from a traditional CI plug-in to a single application for the entire software development lifecycle can decrease hours spent on maintaining toolchains by 10% or more.**
 Visit the ['GitLab vs. Jenkins' comparison page](https://about.gitlab.com/devops-tools/jenkins-vs-gitlab.html) to learn how our built-in CI compares to Jenkins.
diff --git a/doc/integration/jenkins_deprecated.md b/doc/integration/jenkins_deprecated.md
index 3e437eb688a..af7f847f803 100644
--- a/doc/integration/jenkins_deprecated.md
+++ b/doc/integration/jenkins_deprecated.md
@@ -14,7 +14,7 @@ Integration includes:
 Requirements:
 
 - [Jenkins GitLab Hook plugin](https://wiki.jenkins.io/display/JENKINS/GitLab+Hook+Plugin)
-- Git clone access for Jenkins from GitLab repo (via ssh key)
+- Git clone access for Jenkins from GitLab repo (via SSH key)
 
 ## Jenkins
 
diff --git a/doc/integration/kerberos.md b/doc/integration/kerberos.md
index 1888d7c51d5..2a3e2e43d72 100644
--- a/doc/integration/kerberos.md
+++ b/doc/integration/kerberos.md
@@ -46,7 +46,7 @@ sudo chmod 0600 /etc/http.keytab
 For source installations, make sure the `kerberos` gem group
 [has been installed](../install/installation.md#install-gems).
 
-1. Edit the `kerberos` section of [`gitlab.yml`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/config/gitlab.yml.example) to enable Kerberos ticket-based
+1. Edit the `kerberos` section of [`gitlab.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/config/gitlab.yml.example) to enable Kerberos ticket-based
    authentication. In most cases, you only need to enable Kerberos and specify
    the location of the keytab:
 
@@ -153,7 +153,7 @@ keep offering only `basic` authentication.
      listen [::]:8443 ipv6only=on ssl;
    ```
 
-1. Update the `kerberos` section of [`gitlab.yml`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/config/gitlab.yml.example):
+1. Update the `kerberos` section of [`gitlab.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/config/gitlab.yml.example):
 
    ```yaml
    kerberos:
@@ -203,7 +203,7 @@ remove the OmniAuth provider named `kerberos` from your `gitlab.yml` /
 
 **For installations from source**
 
-1. Edit [`gitlab.yml`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/config/gitlab.yml.example) and remove the `- { name: 'kerberos' }` line under omniauth
+1. Edit [`gitlab.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/config/gitlab.yml.example) and remove the `- { name: 'kerberos' }` line under OmniAuth
    providers:
 
    ```yaml
@@ -293,7 +293,7 @@ See also: [Git v2.11 release notes](https://github.com/git/git/blob/master/Docum
 
 - <https://help.ubuntu.com/community/Kerberos>
 - <http://blog.manula.org/2012/04/setting-up-kerberos-server-with-debian.html>
-- <http://www.roguelynn.com/words/explain-like-im-5-kerberos/>
+- <https://www.roguelynn.com/words/explain-like-im-5-kerberos/>
 
 [restart gitlab]: ../administration/restart_gitlab.md#installations-from-source
 [reconfigure gitlab]: ../administration/restart_gitlab.md#omnibus-gitlab-reconfigure
diff --git a/doc/integration/omniauth.md b/doc/integration/omniauth.md
index 30a4c348c22..6ac2e3e13d6 100644
--- a/doc/integration/omniauth.md
+++ b/doc/integration/omniauth.md
@@ -35,7 +35,7 @@ contains some settings that are common for all providers.
 - [JWT](../administration/auth/jwt.md)
 - [OpenID Connect](../administration/auth/oidc.md)
 - [UltraAuth](ultra_auth.md)
-- [SalesForce](salesforce.md)
+- [Salesforce](salesforce.md)
 
 ## Initial OmniAuth Configuration
 
@@ -43,7 +43,7 @@ Before configuring individual OmniAuth providers there are a few global settings
 that are in common for all providers that we need to consider.
 
 > **NOTE:**
-> Starting from GitLab 11.4, Omniauth is enabled by default. If you're using an
+> Starting from GitLab 11.4, OmniAuth is enabled by default. If you're using an
 > earlier version, you'll need to explicitly enable it.
 
 - `allow_single_sign_on` allows you to specify the providers you want to allow to
@@ -171,20 +171,20 @@ omniauth:
   external_providers: ['twitter', 'google_oauth2']
 ```
 
-## Using Custom Omniauth Providers
+## Using Custom OmniAuth Providers
 
 >**Note:**
 The following information only applies for installations from source.
 
-GitLab uses [Omniauth](https://github.com/omniauth/omniauth) for authentication and already ships
+GitLab uses [OmniAuth](https://github.com/omniauth/omniauth) for authentication and already ships
 with a few providers pre-installed (e.g. LDAP, GitHub, Twitter). But sometimes that
 is not enough and you need to integrate with other authentication solutions. For
-these cases you can use the Omniauth provider.
+these cases you can use the OmniAuth provider.
 
 ### Steps
 
 These steps are fairly general and you will need to figure out the exact details
-from the Omniauth provider's documentation.
+from the OmniAuth provider's documentation.
 
 - Stop GitLab:
 
@@ -192,13 +192,13 @@ from the Omniauth provider's documentation.
   sudo service gitlab stop
   ```
 
-- Add the gem to your [Gemfile](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/Gemfile):
+- Add the gem to your [Gemfile](https://gitlab.com/gitlab-org/gitlab/blob/master/Gemfile):
 
   ```sh
   gem "omniauth-your-auth-provider"
   ```
 
-- Install the new Omniauth provider gem by running the following command:
+- Install the new OmniAuth provider gem by running the following command:
 
   ```sh
   sudo -u git -H bundle install --without development test mysql --path vendor/bundle --no-deployment
@@ -238,13 +238,13 @@ In order to enable/disable an OmniAuth provider, go to Admin Area -> Settings ->
 
 ![Enabled OAuth Sign-In sources](img/enabled-oauth-sign-in-sources.png)
 
-## Disabling Omniauth
+## Disabling OmniAuth
 
-Starting from version 11.4 of GitLab, Omniauth is enabled by default. This only
+Starting from version 11.4 of GitLab, OmniAuth is enabled by default. This only
 has an effect if providers are configured and [enabled](#enable-or-disable-sign-in-with-an-omniauth-provider-without-disabling-import-sources).
 
-If omniauth providers are causing problems even when individually disabled, you
-can disable the entire omniauth subsystem by modifying the configuration file:
+If OmniAuth providers are causing problems even when individually disabled, you
+can disable the entire OmniAuth subsystem by modifying the configuration file:
 
 **For Omnibus installations**
 
diff --git a/doc/integration/openid_connect_provider.md b/doc/integration/openid_connect_provider.md
index 89f4924d717..f75630b93a2 100644
--- a/doc/integration/openid_connect_provider.md
+++ b/doc/integration/openid_connect_provider.md
@@ -13,7 +13,7 @@ REST-like manner. OIDC performs many of the same tasks as OpenID 2.0,
 but does so in a way that is API-friendly, and usable by native and
 mobile applications.
 
-On the client side, you can use [omniauth-openid-connect] for Rails
+On the client side, you can use [OmniAuth::OpenIDConnect](https://github.com/jjbohn/omniauth-openid-connect/) for Rails
 applications, or any of the other available [client implementations](https://openid.net/developers/libraries/#connect).
 
 GitLab's implementation uses the [doorkeeper-openid_connect] gem, refer
@@ -48,4 +48,3 @@ Only the `sub` and `sub_legacy` claims are included in the ID token, all other c
 
 [doorkeeper-openid_connect]: https://github.com/doorkeeper-gem/doorkeeper-openid_connect "Doorkeeper::OpenidConnect website"
 [OAuth guide]: oauth_provider.md "GitLab as OAuth2 authentication service provider"
-[omniauth-openid-connect]: https://github.com/jjbohn/omniauth-openid-connect/ "OmniAuth::OpenIDConnect website"
diff --git a/doc/integration/recaptcha.md b/doc/integration/recaptcha.md
index 825c3654492..10613129490 100644
--- a/doc/integration/recaptcha.md
+++ b/doc/integration/recaptcha.md
@@ -12,7 +12,7 @@ To use reCAPTCHA, first you must create a site and private key.
 1. Fill out the form necessary to obtain reCAPTCHA v2 keys.
 1. Log in to your GitLab server, with administrator credentials.
 1. Go to Reporting Applications Settings in the Admin Area (`admin/application_settings/reporting`).
-1. Fill all recaptcha fields with keys from previous steps.
+1. Fill all reCAPTCHA fields with keys from previous steps.
 1. Check the `Enable reCAPTCHA` checkbox.
 1. Save the configuration.
 
diff --git a/doc/integration/salesforce.md b/doc/integration/salesforce.md
index 10ab9d3c126..958f05cf030 100644
--- a/doc/integration/salesforce.md
+++ b/doc/integration/salesforce.md
@@ -21,7 +21,7 @@ To get the credentials (a pair of Client ID and Client Secret), you must [create
 1. Select **API (Enable OAuth Settings)** and click on **Enable OAuth Settings**.
 1. Fill in the application details into the following fields:
    - **Callback URL**: The callback URL of your GitLab installation. For example, `https://gitlab.example.com/users/auth/salesforce/callback`.
-   - **Selected OAuth Scopes**: Move **Access your basic information (id, profile, email, address, phone)** and **Allow access to your unique identifier (openid)** to the right column.
+   - **Selected OAuth Scopes**: Move **Access your basic information (id, profile, email, address, phone)** and **Allow access to your unique identifier (OpenID)** to the right column.
 
    ![Salesforce Oauth App Details](img/salesforce_oauth_app_details.png)
 
diff --git a/doc/integration/saml.md b/doc/integration/saml.md
index 23e9e44e076..b72be55aca3 100644
--- a/doc/integration/saml.md
+++ b/doc/integration/saml.md
@@ -111,7 +111,7 @@ in your SAML IdP:
 1. Change the values of `idp_cert_fingerprint`, `idp_sso_target_url`,
    `name_identifier_format` to match your IdP. If a fingerprint is used it must
    be a SHA1 fingerprint; check
-   [the omniauth-saml documentation](https://github.com/omniauth/omniauth-saml)
+   [the OmniAuth SAML documentation](https://github.com/omniauth/omniauth-saml)
    for more details on these options.
 
 1. Change the value of `issuer` to a unique name, which will identify the application
@@ -133,7 +133,7 @@ https://gitlab.example.com/users/auth/saml/metadata
 At a minimum the IdP *must* provide a claim containing the user's email address, using
 claim name `email` or `mail`. The email will be used to automatically generate the GitLab
 username. GitLab will also use claims with name `name`, `first_name`, `last_name`
-(see [the omniauth-saml gem](https://github.com/omniauth/omniauth-saml/blob/master/lib/omniauth/strategies/saml.rb)
+(see [the OmniAuth SAML gem](https://github.com/omniauth/omniauth-saml/blob/master/lib/omniauth/strategies/saml.rb)
 for supported claims).
 
 On the sign in page there should now be a SAML button below the regular sign in form.
@@ -370,7 +370,7 @@ This setting should only be used to map attributes that are part of the
 OmniAuth info hash schema.
 
 `attribute_statements` is used to map Attribute Names in a SAMLResponse to entries
-in the OmniAuth [info hash](https://github.com/intridea/omniauth/wiki/Auth-Hash-Schema#schema-10-and-later).
+in the OmniAuth [info hash](https://github.com/omniauth/omniauth/wiki/Auth-Hash-Schema#schema-10-and-later).
 
 For example, if your SAMLResponse contains an Attribute called 'EmailAddress',
 specify `{ email: ['EmailAddress'] }` to map the Attribute to the
@@ -414,7 +414,7 @@ args: {
 
 ### `uid_attribute`
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/43806) in GitLab 10.7.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/17734) in GitLab 10.7.
 
 By default, the `uid` is set as the `name_id` in the SAML response. If you'd like to designate a unique attribute for the `uid`, you can set the `uid_attribute`. In the example below, the value of `uid` attribute in the SAML response is set as the `uid_attribute`.
 
@@ -429,6 +429,120 @@ args: {
 }
 ```
 
+## Response signature validation (required)
+
+We require Identity Providers to sign SAML responses to ensure that the assertions are
+not tampered with.
+
+This prevents user impersonation and prevents privilege escalation when specific group
+membership is required. Typically this:
+
+- Is configured using `idp_cert_fingerprint`.
+- Includes the full certificate in the response, although if your Identity Provider
+  doesn't support this, you can directly configure GitLab using the `idp_cert` option.
+
+Example configuration with `idp_cert_fingerprint`:
+
+```yaml
+args: {
+  assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
+  idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
+  idp_sso_target_url: 'https://login.example.com/idp',
+  issuer: 'https://gitlab.example.com',
+  name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
+}
+```
+
+Example configuration with `idp_cert`:
+
+```yaml
+args: {
+  assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
+  idp_cert: '-----BEGIN CERTIFICATE-----
+    <redacted>
+    -----END CERTIFICATE-----',
+  idp_sso_target_url: 'https://login.example.com/idp',
+  issuer: 'https://gitlab.example.com',
+  name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
+}
+```
+
+If the response signature validation is configured incorrectly, you can see error messages
+such as:
+
+- A key validation error.
+- Digest mismatch.
+- Fingerprint mismatch.
+
+Refer to the [troubleshooting section](#troubleshooting) for more information on
+debugging these errors.
+
+## Assertion Encryption (optional)
+
+GitLab requires the use of TLS encryption with SAML, but in some cases there can be a
+need for additional encryption of the assertions.
+
+This may be the case, for example, if you terminate TLS encryption early at a load
+balancer and include sensitive details in assertions that you do not want appearing
+in logs. Most organizations should not need additional encryption at this layer.
+
+The SAML integration supports EncryptedAssertion. You need to define the private key and the public certificate of your GitLab instance in the SAML settings:
+
+```yaml
+args: {
+  assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
+  idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
+  idp_sso_target_url: 'https://login.example.com/idp',
+  issuer: 'https://gitlab.example.com',
+  name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
+  certificate: '-----BEGIN CERTIFICATE-----
+    <redacted>
+    -----END CERTIFICATE-----',
+  private_key: '-----BEGIN PRIVATE KEY-----
+    <redacted>
+    -----END PRIVATE KEY-----'
+}
+```
+
+Your Identity Provider will encrypt the assertion with the public certificate of GitLab. GitLab will decrypt the EncryptedAssertion with its private key.
+
+NOTE: **Note:**
+This integration uses the `certificate` and `private_key` settings for both assertion encryption and request signing.
+
+## Request signing (optional)
+
+Another optional configuration is to sign SAML authentication requests. GitLab SAML Requests uses the SAML redirect binding so this is not necessary, unlike the SAML POST binding where signing is required to prevent intermediaries tampering with the requests.
+
+In order to sign, you need to create a private key and public certificate pair for your GitLab instance to use for SAML. The settings related to signing can be set in the `security` section of the configuration.
+
+For example:
+
+```yaml
+args: {
+  assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback',
+  idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8',
+  idp_sso_target_url: 'https://login.example.com/idp',
+  issuer: 'https://gitlab.example.com',
+  name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
+  certificate: '-----BEGIN CERTIFICATE-----
+    <redacted>
+    -----END CERTIFICATE-----',
+  private_key: '-----BEGIN PRIVATE KEY-----
+    <redacted>
+    -----END PRIVATE KEY-----',
+  security: {
+    authn_requests_signed: true, # enable signature on AuthNRequest
+    want_assertions_signed: true, # enable the requirement of signed assertion
+    embed_sign: true, # embedded signature or HTTP GET parameter signature
+    metadata_signed: false, # enable signature on Metadata
+    signature_method: 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256',
+    digest_method: 'http://www.w3.org/2001/04/xmlenc#sha256',
+  }
+}
+```
+
+GitLab will sign the request with the provided private key. GitLab will include the configured public x500 certificate in the metadata for your Identity Provider to validate the signature of the received request with. For more information on this option, see the [ruby-saml gem documentation](https://github.com/onelogin/ruby-saml/tree/v1.7.0). The `ruby-saml` gem is used by the [omniauth-saml gem](https://github.com/omniauth/omniauth-saml) to implement the client side of the SAML authentication.
+
 ## Troubleshooting
 
 ### 500 error after login
@@ -458,7 +572,7 @@ installations from source. Restart Unicorn using the `sudo gitlab-ctl restart un
 command on Omnibus installations and `sudo service gitlab restart` on installations
 from source.
 
-You may also find the [SSO Tracer](https://addons.mozilla.org/en-US/firefox/addon/sso-tracer)
+You may also find the [SSO Tracer](https://addons.mozilla.org/en-US/firefox/addon/sso-tracer/)
 (Firefox) and [SAML Chrome Panel](https://chrome.google.com/webstore/detail/saml-chrome-panel/paijfdbeoenhembfhkhllainmocckace)
 (Chrome) browser extensions useful in your debugging.
 
diff --git a/doc/integration/shibboleth.md b/doc/integration/shibboleth.md
index 1b4e75e0ca1..885a6fe59da 100644
--- a/doc/integration/shibboleth.md
+++ b/doc/integration/shibboleth.md
@@ -2,9 +2,9 @@
 
 NOTE: **Note:**
 The preferred approach for integrating a Shibboleth authentication system
-with Gitlab 10 or newer is to use [GitLab's SAML integration](saml.md). This documentation is for Omnibus GitLab 9.x installs or older.
+with GitLab 10 or newer is to use [GitLab's SAML integration](saml.md). This documentation is for Omnibus GitLab 9.x installs or older.
 
-In order to enable Shibboleth support in GitLab we need to use Apache instead of Nginx (It may be possible to use Nginx, however this is difficult to configure using the bundled Nginx provided in the Omnibus GitLab package). Apache uses mod_shib2 module for Shibboleth authentication and can pass attributes as headers to Omniauth Shibboleth provider.
+In order to enable Shibboleth support in GitLab we need to use Apache instead of NGINX (It may be possible to use NGINX, however this is difficult to configure using the bundled NGINX provided in the Omnibus GitLab package). Apache uses mod_shib2 module for Shibboleth authentication and can pass attributes as headers to OmniAuth Shibboleth provider.
 
 To enable the Shibboleth OmniAuth provider you must configure Apache Shibboleth module.
 The installation and configuration of the module itself is out of the scope of this document.
@@ -14,7 +14,7 @@ You can find Apache config in [GitLab Recipes](https://gitlab.com/gitlab-org/git
 
 The following changes are needed to enable Shibboleth:
 
-1. Protect Omniauth Shibboleth callback URL:
+1. Protect OmniAuth Shibboleth callback URL:
 
    ```
    <Location /users/auth/shibboleth/callback>
diff --git a/doc/integration/slack.md b/doc/integration/slack.md
index 9fcf2c2d99a..815032a08d5 100644
--- a/doc/integration/slack.md
+++ b/doc/integration/slack.md
@@ -2,4 +2,4 @@
 redirect_to: '../user/project/integrations/slack.md'
 ---
 
-This document was moved to [project_services/slack.md](../user/project/integrations/slack.md).
+This document was moved to [another location](../user/project/integrations/slack.md).
diff --git a/doc/migrate_ci_to_ce/README.md b/doc/migrate_ci_to_ce/README.md
index 4a96001f2de..85e69be6516 100644
--- a/doc/migrate_ci_to_ce/README.md
+++ b/doc/migrate_ci_to_ce/README.md
@@ -268,11 +268,11 @@ If you installed GitLab CI from source we now need to configure a redirect in
 NGINX so that existing CI runners can keep using the old CI server address, and
 so that existing links to your CI server keep working.
 
-### 1. Update Nginx configuration
+### 1. Update NGINX configuration
 
 To ensure that your existing CI runners are able to communicate with the
 migrated installation, and that existing build triggers still work, you'll need
-to update your Nginx configuration to redirect requests for the old locations to
+to update your NGINX configuration to redirect requests for the old locations to
 the new ones.
 
 Edit `/etc/nginx/sites-available/gitlab_ci` and paste:
@@ -324,13 +324,13 @@ You should also make sure that you can:
 1. `curl https://YOUR_GITLAB_SERVER_FQDN/` from your previous GitLab CI server.
 1. `curl https://YOUR_CI_SERVER_FQDN/` from your GitLab CE (or EE) server.
 
-### 2. Check Nginx configuration
+### 2. Check NGINX configuration
 
 ```sh
 sudo nginx -t
 ```
 
-### 3. Restart Nginx
+### 3. Restart NGINX
 
 ```sh
 sudo /etc/init.d/nginx restart
diff --git a/doc/policy/maintenance.md b/doc/policy/maintenance.md
index f7ba7c16a9e..d118c2f40cb 100644
--- a/doc/policy/maintenance.md
+++ b/doc/policy/maintenance.md
@@ -10,7 +10,7 @@ patch and security releases. New releases are usually announced on the [GitLab b
 ## Versioning
 
 GitLab uses [Semantic Versioning](https://semver.org/) for its releases:
-`(Major).(Minor).(Patch)` in a [pragmatic way](https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e).
+`(Major).(Minor).(Patch)`.
 
 For example, for GitLab version 10.5.7:
 
@@ -24,7 +24,7 @@ The following table describes the version types and their release cadence:
 
 | Version type | Description | Cadence |
 |:-------------|:------------|:--------|
-| Major        | For significant changes, or when any backward-incompatible changes are introduced to the public API. | Yearly. The next major release is GitLab 12.0 on June 22, 2019. Subsequent major releases will be scheduled for May 22 each year, by default. |
+| Major        | For significant changes, or when any backward-incompatible changes are introduced to the public API. | Yearly. The next major release is GitLab 13.0 on May 22, 2020. Subsequent major releases will be scheduled for May 22 each year, by default. |
 | Minor        | For when new backward-compatible functionality is introduced to the public API, a minor feature is introduced, or when a set of smaller features is rolled out. | Monthly on the 22nd. |
 | Patch        | For backward-compatible bug fixes that fix incorrect behavior. See [Patch releases](#patch-releases). | As needed. |
 
@@ -47,7 +47,7 @@ medium-level security issues, we may backport security fixes to the previous two
 monthly releases.
 
 For very serious security issues, there is
-[precedent](https://about.gitlab.com/2016/05/02/cve-2016-4340-patches/)
+[precedent](https://about.gitlab.com/blog/2016/05/02/cve-2016-4340-patches/)
 to backport security fixes to even more monthly releases of GitLab.
 This decision is made on a case-by-case basis.
 
diff --git a/doc/public_access/img/restrict_visibility_levels.png b/doc/public_access/img/restrict_visibility_levels.png
deleted file mode 100644
index e9315cfb701..00000000000
--- a/doc/public_access/img/restrict_visibility_levels.png
+++ /dev/null
diff --git a/doc/public_access/public_access.md b/doc/public_access/public_access.md
index e7d29fb8018..bb19436017a 100644
--- a/doc/public_access/public_access.md
+++ b/doc/public_access/public_access.md
@@ -4,7 +4,7 @@ type: reference
 
 # Public access
 
-GitLab allows [Owners](../user/permissions.md) to set a projects' visibility as **public**, **internal**
+GitLab allows [Owners](../user/permissions.md) to set a project's visibility as **public**, **internal**,
 or **private**. These visibility levels affect who can see the project in the
 public access directory (`/public` under your GitLab instance), like at <https://gitlab.com/public>
 
@@ -12,7 +12,7 @@ public access directory (`/public` under your GitLab instance), like at <https:/
 
 ### Public projects
 
-Public projects can be cloned **without any** authentication over https.
+Public projects can be cloned **without any** authentication over HTTPS.
 
 They will be listed in the public access directory (`/public`) for all users.
 
@@ -43,8 +43,8 @@ They will appear in the public access directory (`/public`) for project members
 
 ### How to change project visibility
 
-1. Go to your project's **Settings**
-1. Change "Visibility Level" to either Public, Internal or Private
+1. Go to your project's **Settings**.
+1. Change **Visibility Level** to either Public, Internal, or Private.
 
 ## Visibility of groups
 
@@ -71,15 +71,12 @@ If the public level is restricted, user profiles are only visible to logged in u
 
 ## Restricting the use of public or internal projects
 
-In the Admin area under **Settings** (`/admin/application_settings`), you can
-restrict the use of visibility levels for users when they create a project or a
-snippet:
-
-![Restrict visibility levels](img/restrict_visibility_levels.png)
-
-This is useful to prevent people exposing their repositories to public
+You can restrict the use of visibility levels for users when they create a project or a
+snippet. This is useful to prevent users from publicly exposing their repositories
 by accident. The restricted visibility settings do not apply to admin users.
 
+For details, see [Restricted visibility levels](../user/admin_area/settings/visibility_and_access_controls.md#restricted-visibility-levels).
+
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues
diff --git a/doc/push_rules/push_rules.md b/doc/push_rules/push_rules.md
index 08484fb4187..0771a3e4225 100644
--- a/doc/push_rules/push_rules.md
+++ b/doc/push_rules/push_rules.md
@@ -74,10 +74,10 @@ The following options are available.
 | Restrict by branch name | **Starter** 9.3 | Only branch names that match this regular expression are allowed to be pushed. Leave empty to allow any branch name. |
 | Restrict by commit author's email | **Starter** 7.10 | Only commit author's email that match this regular expression are allowed to be pushed. Leave empty to allow any email. |
 | Prohibited file names | **Starter** 7.10 | Any committed filenames that match this regular expression are not allowed to be pushed. Leave empty to allow any filenames. |
-| Maximum file size | **Starter** 7.12 | Pushes that contain added or updated files that exceed this file size (in MB) are rejected. Set to 0 to allow files of any size. |
+| Maximum file size | **Starter** 7.12 | Pushes that contain added or updated files that exceed this file size (in MB) are rejected. Set to 0 to allow files of any size. Files tracked by Git LFS are exempted. |
 
 TIP: **Tip:**
-GitLab uses [RE2 syntax](https://github.com/google/re2/wiki/Syntax) for regular expressions in push rules, and you can test them at the [GoLang regex tester](https://regex-golang.appspot.com).
+GitLab uses [RE2 syntax](https://github.com/google/re2/wiki/Syntax) for regular expressions in push rules, and you can test them at the [GoLang regex tester](https://regex-golang.appspot.com/assets/html/index.html).
 
 ## Prevent pushing secrets to the repository
 
diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md
index cc43a120e22..fe9617c75ad 100644
--- a/doc/raketasks/backup_restore.md
+++ b/doc/raketasks/backup_restore.md
@@ -98,7 +98,7 @@ docker exec -t <container name> gitlab-backup create
 NOTE: **Note**
 For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
 
-If you are using the [GitLab helm chart](https://gitlab.com/gitlab-org/charts/gitlab) on a
+If you are using the [GitLab Helm chart](https://gitlab.com/gitlab-org/charts/gitlab) on a
 Kubernetes cluster, you can run the backup task using `backup-utility` script on
 the GitLab task runner pod via `kubectl`. Refer to [backing up a GitLab installation](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/doc/backup-restore/backup.md#backing-up-a-gitlab-installation) for more details:
 
@@ -277,7 +277,7 @@ Starting with GitLab 7.4 you can let the backup script upload the '.tar' file it
 It uses the [Fog library](http://fog.io/) to perform the upload.
 In the example below we use Amazon S3 for storage, but Fog also lets you use
 [other storage providers](http://fog.io/storage/). GitLab
-[imports cloud drivers](https://gitlab.com/gitlab-org/gitlab-foss/blob/30f5b9a5b711b46f1065baf755e413ceced5646b/Gemfile#L88)
+[imports cloud drivers](https://gitlab.com/gitlab-org/gitlab/blob/30f5b9a5b711b46f1065baf755e413ceced5646b/Gemfile#L88)
 for AWS, Google, OpenStack Swift, Rackspace and Aliyun as well. A local driver is
 [also available](#uploading-to-locally-mounted-shares).
 
@@ -575,7 +575,7 @@ files. GitLab does not automatically prune old files stored in a third-party
 object storage (e.g., AWS S3) because the user may not have permission to list
 and delete files. We recommend that you configure the appropriate retention
 policy for your object storage. For example, you can configure [the S3 backup
-policy as described here](http://stackoverflow.com/questions/37553070/gitlab-omnibus-delete-backup-from-amazon-s3).
+policy as described here](https://stackoverflow.com/questions/37553070/gitlab-omnibus-delete-backup-from-amazon-s3).
 
 To schedule a cron job that backs up your repositories and GitLab metadata, use the root user:
 
@@ -775,9 +775,9 @@ If there is a GitLab version mismatch between your backup tar file and the insta
 version of GitLab, the restore command will abort with an error. Install the
 [correct GitLab version](https://packages.gitlab.com/gitlab/) and try again.
 
-### Restore for Docker image and GitLab helm chart installations
+### Restore for Docker image and GitLab Helm chart installations
 
-For GitLab installations using the Docker image or the GitLab helm chart on
+For GitLab installations using the Docker image or the GitLab Helm chart on
 a Kubernetes cluster, the restore task expects the restore directories to be empty.
 However, with docker and Kubernetes volume mounts, some system level directories
 may be created at the volume roots, like `lost+found` directory found in Linux
@@ -803,8 +803,8 @@ CAUTION: **Warning:**
 This is a [known issue](https://gitlab.com/gitlab-org/gitlab-foss/issues/62759). On GitLab 12.2 or newer, you can
 use `gitlab-backup restore` to avoid this issue.
 
-The GitLab helm chart uses a different process, documented in
-[restoring a GitLab helm chart installation](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/doc/backup-restore/restore.md).
+The GitLab Helm chart uses a different process, documented in
+[restoring a GitLab Helm chart installation](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/doc/backup-restore/restore.md).
 
 ## Alternative backup strategies
 
@@ -859,7 +859,7 @@ Be advised that, backup is successfully restored in spite of these warnings.
 The rake task runs this as the `gitlab` user which does not have the superuser access to the database. When restore is initiated it will also run as `gitlab` user but it will also try to alter the objects it does not have access to.
 Those objects have no influence on the database backup/restore but they give this annoying warning.
 
-For more information see similar questions on postgresql issue tracker[here](http://www.postgresql.org/message-id/201110220712.30886.adrian.klaver@gmail.com) and [here](http://www.postgresql.org/message-id/2039.1177339749@sss.pgh.pa.us) as well as [stack overflow](http://stackoverflow.com/questions/4368789/error-must-be-owner-of-language-plpgsql).
+For more information see similar questions on PostgreSQL issue tracker[here](https://www.postgresql.org/message-id/201110220712.30886.adrian.klaver@gmail.com) and [here](https://www.postgresql.org/message-id/2039.1177339749@sss.pgh.pa.us) as well as [stack overflow](https://stackoverflow.com/questions/4368789/error-must-be-owner-of-language-plpgsql).
 
 ### When the secrets file is lost
 
diff --git a/doc/raketasks/cleanup.md b/doc/raketasks/cleanup.md
index e2ec58be367..67bf7cbd828 100644
--- a/doc/raketasks/cleanup.md
+++ b/doc/raketasks/cleanup.md
@@ -2,46 +2,6 @@
 
 ## Remove garbage from filesystem
 
-DANGER: **Danger:**
-The commands below will remove data permanently from your GitLab instance. Only use
-these commands if you are 100% certain that it is safe to delete this data.
-
-Remove namespaces(dirs) from all repository storage paths if they don't exist in GitLab database.
-
-```
-# omnibus-gitlab
-sudo gitlab-rake gitlab:cleanup:dirs
-
-# installation from source
-bundle exec rake gitlab:cleanup:dirs RAILS_ENV=production
-```
-
-DANGER: **Danger:**
-The following task does not currently work as expected.
-The use will probably mark more existing repositories as orphaned.
-For more information, see the [issue](https://gitlab.com/gitlab-org/gitlab-ee/issues/24633).
-
-Rename repositories from all repository storage paths if they don't exist in GitLab database.
-The repositories get a `+orphaned+TIMESTAMP` suffix so that they cannot block new repositories from being created.
-
-```
-# omnibus-gitlab
-sudo gitlab-rake gitlab:cleanup:repos
-
-# installation from source
-bundle exec rake gitlab:cleanup:repos RAILS_ENV=production
-```
-
-Remove old repository copies from repositories moved to another storage.
-
-```
-# omnibus-gitlab
-sudo gitlab-rake gitlab:cleanup:moved
-
-# installation from source
-bundle exec rake gitlab:cleanup:moved RAILS_ENV=production
-```
-
 Clean up local project upload files if they don't exist in GitLab database. The
 task attempts to fix the file if it can find its project, otherwise it moves the
 file to a lost and found directory.
diff --git a/doc/raketasks/import.md b/doc/raketasks/import.md
index b6253bbecdc..5f11af0213d 100644
--- a/doc/raketasks/import.md
+++ b/doc/raketasks/import.md
@@ -100,7 +100,7 @@ the Git repository's config file. This section is formatted as follows:
 
 ```
 [gitlab]
-  fullpath = gitlab-org/gitlab-ce
+  fullpath = gitlab-org/gitlab
 ```
 
 However, existing repositories were not migrated to include this path.
@@ -129,7 +129,7 @@ Until then, you may wish to manually migrate repositories yourself. You can use
 to do so. In a Rails console session, run the following to migrate a project:
 
 ```
-project = Project.find_by_full_path('gitlab-org/gitlab-ce')
+project = Project.find_by_full_path('gitlab-org/gitlab')
 project.write_repository_config
 ```
 
diff --git a/doc/raketasks/list_repos.md b/doc/raketasks/list_repos.md
index 476428eb4f5..cfcf11cf3c2 100644
--- a/doc/raketasks/list_repos.md
+++ b/doc/raketasks/list_repos.md
@@ -15,7 +15,7 @@ sudo -u git -H bundle exec rake gitlab:list_repos RAILS_ENV=production
 If you only want to list projects with recent activity you can pass
 a date with the 'SINCE' environment variable.  The time you specify
 is parsed by the Rails [TimeZone#parse
-function](http://api.rubyonrails.org/classes/ActiveSupport/TimeZone.html#method-i-parse).
+function](https://api.rubyonrails.org/classes/ActiveSupport/TimeZone.html#method-i-parse).
 
 ```
 # Omnibus
diff --git a/doc/security/asset_proxy.md b/doc/security/asset_proxy.md
index b480905339b..6e615028e8b 100644
--- a/doc/security/asset_proxy.md
+++ b/doc/security/asset_proxy.md
@@ -11,12 +11,12 @@ to log the IP address of the user.
 One way to mitigate this is by proxying any external images to a server you
 control.
 
-GitLab can be configured to use an asset proxy server when requesting external images/videos in
+GitLab can be configured to use an asset proxy server when requesting external images/videos/audio in
 issues, comments, etc. This helps ensure that malicious images do not expose the user's IP address
 when they are fetched.
 
 We currently recommend using [cactus/go-camo](https://github.com/cactus/go-camo#how-it-works)
-as it supports proxying video and is more configurable.
+as it supports proxying video, audio, and is more configurable.
 
 ## Installing Camo server
 
@@ -52,7 +52,7 @@ To install a Camo server as an asset proxy:
 
 ## Using the Camo server
 
-Once the Camo server is running and you've enabled the GitLab settings, any image or video that
+Once the Camo server is running and you've enabled the GitLab settings, any image, video, or audio that
 references an external source will get proxied to the Camo server.
 
 For example, the following is a link to an image in Markdown:
diff --git a/doc/security/crime_vulnerability.md b/doc/security/crime_vulnerability.md
index 6e0a62b6510..77592f1b440 100644
--- a/doc/security/crime_vulnerability.md
+++ b/doc/security/crime_vulnerability.md
@@ -56,11 +56,11 @@ vulnerability.
 
 ## References
 
-- Nginx ["Module ngx_http_spdy_module"][ngx-spdy]
+- NGINX ["Module ngx_http_spdy_module"][ngx-spdy]
 - Tenable Network Security, Inc. ["Transport Layer Security (TLS) Protocol CRIME Vulnerability"][nessus]
 - Wikipedia contributors, ["CRIME"][wiki-crime] Wikipedia, The Free Encyclopedia
 
-[source-nginx]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/support/nginx/gitlab-ssl
+[source-nginx]: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/support/nginx/gitlab-ssl
 [omnibus-nginx]: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/templates/default/nginx-gitlab-http.conf.erb
 [ngx-spdy]: http://nginx.org/en/docs/http/ngx_http_spdy_module.html
 [nessus]: https://www.tenable.com/plugins/index.php?view=single&id=62565
diff --git a/doc/security/rack_attack.md b/doc/security/rack_attack.md
index 09d29bf3446..51b7d7db3e4 100644
--- a/doc/security/rack_attack.md
+++ b/doc/security/rack_attack.md
@@ -36,6 +36,9 @@ will be enabled:
 
 ### Protected paths throttle
 
+NOTE: **Note:** Omnibus GitLab protected paths throttle is deprecated and is scheduled for removal in
+GitLab 13.0. Please refer to [Migrate settings from GitLab 12.3 and earlier](../user/admin_area/settings/protected_paths.md#migrate-settings-from-gitlab-123-and-earlier).
+
 GitLab responds with HTTP status code `429` to POST requests at protected paths
 that exceed 10 requests per minute per IP address.
 
@@ -124,6 +127,9 @@ The following settings can be configured:
 
 **Installations from source**
 
+NOTE: **Note:** Rack Attack initializer was temporarily renamed to `rack_attack_new`, to
+support backwards compatibility with the one [Omnibus initializer](https://docs.gitlab.com/omnibus/settings/configuration.html#setting-up-paths-to-be-protected-by-rack-attack). It'll be renamed back to `rack_attack.rb` once Omnibus throttle is removed. Please see the [GitLab issue](https://gitlab.com/gitlab-org/gitlab/issues/29952) for more information.
+
 These settings can be found in `config/initializers/rack_attack.rb`. If you are
 missing `config/initializers/rack_attack.rb`, the following steps need to be
 taken in order to enable protection for your GitLab instance:
diff --git a/doc/ssh/README.md b/doc/ssh/README.md
index e18f49de3f0..07b426b7f28 100644
--- a/doc/ssh/README.md
+++ b/doc/ssh/README.md
@@ -83,20 +83,6 @@ The minimum key size is 1024 bits, defaulting to 2048. If you wish to generate a
 stronger RSA key pair, specify the `-b` flag with a higher bit value than the
 default.
 
-The old, default password encoding for SSH private keys is
-[insecure](https://latacora.singles/2018/08/03/the-default-openssh.html);
-it's only a single round of an MD5 hash. Since OpenSSH version 6.5, you should
-use the `-o` option to `ssh-keygen` to encode your private key in a new, more
-secure format.
-
-If you already have an RSA SSH key pair to use with GitLab, consider upgrading it
-to use the more secure password encryption format by using the following command
-on the private key:
-
-```bash
-ssh-keygen -o -f ~/.ssh/id_rsa
-```
-
 ## Generating a new SSH key pair
 
 Before creating an SSH key pair, make sure to understand the
@@ -114,7 +100,7 @@ To create a new SSH key pair:
    Or, if you want to use RSA:
 
    ```bash
-   ssh-keygen -o -t rsa -b 4096 -C "email@example.com"
+   ssh-keygen -t rsa -b 4096 -C "email@example.com"
    ```
 
    The `-C` flag adds a comment in the key in case you have multiple of them
@@ -139,9 +125,31 @@ To create a new SSH key pair:
    you can use the `-p` flag:
 
    ```
-   ssh-keygen -p -o -f <keyname>
+   ssh-keygen -p -f <keyname>
    ```
 
+### OpenSSH < v7.8
+
+Pre OpenSSH 7.8, default password encoding for SSH private keys was
+[insecure](https://latacora.micro.blog/the-default-openssh/);
+it's only a single round of an MD5 hash. For OpenSSH version 6.5 to version 7.8, you should
+use the `-o` option to `ssh-keygen` to [encode your private key in a new, more
+secure format.](https://superuser.com/questions/1455735/what-does-ssh-keygen-o-do#answer-1455738)
+
+If you already have an RSA SSH key pair to use with GitLab, consider upgrading it
+to use the more secure password encryption format by using the following command
+on the private key:
+
+```bash
+ssh-keygen -o -f ~/.ssh/id_rsa
+```
+
+Or generate a new RSA key:
+
+```bash
+ssh-keygen -o -t rsa -b 4096 -C "email@example.com"
+```
+
 Now, it's time to add the newly created public key to your GitLab account.
 
 ## Adding an SSH key to your GitLab account
diff --git a/doc/subscriptions/index.md b/doc/subscriptions/index.md
index 950850536e9..cae83d6186f 100644
--- a/doc/subscriptions/index.md
+++ b/doc/subscriptions/index.md
@@ -148,7 +148,7 @@ For more information, please see our:
 
 - [Subscription FAQ](https://about.gitlab.com/pricing/licensing-faq/).
 - [Pricing page](https://about.gitlab.com/pricing/), which includes information
-  on our [true-up pricing policy](https://about.gitlab.com/handbook/product/pricing/#true-up-pricing)
+  on our [true-up pricing policy](https://about.gitlab.com/handbook/ceo/pricing/#true-up-pricing)
   when adding more users other than at the time of purchase.
 
 NOTE: **Note:**
@@ -192,13 +192,15 @@ account:
 
 #### Change associated namespace
 
-With a linked GitLab.com account, go to the
-[**Subscriptions**](https://customers.gitlab.com/subscriptions) page to choose
-or change the namespace your subscription applies to.
+With a linked GitLab.com account:
 
-NOTE: **Note:**
-Please note that you need to be a group owner to associate a group to your
-subscription.
+1. Log in to the [GitLab Subscription Manager](https://customers.gitlab.com/customers/sign_in).
+1. Navigate to the **Manage Purchases** page.
+1. Click **Change linked group**.
+1. Select the desired group from the **This subscription is for** dropdown.
+1. Click **Proceed to checkout**.
+
+Subscription charges are calculated based on the total number of users in a group, including its subgroups and nested projects. If the total number of users exceeds the number of seats in your subscription, you will be charged for the additional users.
 
 ### Confirm or upgrade your subscription
 
@@ -247,6 +249,9 @@ In order to purchase additional minutes, you should follow these steps:
 
    ![Additional minutes](img/additional_minutes.png)
 
+   The **Additional minutes** displayed now includes the purchased additional CI minutes, plus any
+   minutes rolled over from last month.
+
 Be aware that:
 
 1. If you have purchased extra CI minutes before the purchase of a paid plan,
diff --git a/doc/topics/authentication/index.md b/doc/topics/authentication/index.md
index ad196e27f53..9e4a666d442 100644
--- a/doc/topics/authentication/index.md
+++ b/doc/topics/authentication/index.md
@@ -8,8 +8,8 @@ This page gathers all the resources for the topic **Authentication** within GitL
 - [Two-Factor Authentication (2FA)](../../user/profile/account/two_factor_authentication.md#two-factor-authentication)
 - [Why do I keep getting signed out?](../../user/profile/index.md#why-do-i-keep-getting-signed-out)
 - **Articles:**
-  - [Support for Universal 2nd Factor Authentication - YubiKeys](https://about.gitlab.com/2016/06/22/gitlab-adds-support-for-u2f/)
-  - [Security Webcast with Yubico](https://about.gitlab.com/2016/08/31/gitlab-and-yubico-security-webcast/)
+  - [Support for Universal 2nd Factor Authentication - YubiKeys](https://about.gitlab.com/blog/2016/06/22/gitlab-adds-support-for-u2f/)
+  - [Security Webcast with Yubico](https://about.gitlab.com/blog/2016/08/31/gitlab-and-yubico-security-webcast/)
 - **Integrations:**
   - [GitLab as OAuth2 authentication service provider](../../integration/oauth_provider.md#introduction-to-oauth)
   - [GitLab as OpenID Connect identity provider](../../integration/openid_connect_provider.md)
@@ -22,7 +22,7 @@ This page gathers all the resources for the topic **Authentication** within GitL
 - **Articles:**
   - [How to Configure LDAP with GitLab CE](../../administration/auth/how_to_configure_ldap_gitlab_ce/index.md)
   - [How to Configure LDAP with GitLab EE](../../administration/auth/how_to_configure_ldap_gitlab_ee/index.md) **(STARTER)**
-  - [Feature Highlight: LDAP Integration](https://about.gitlab.com/2014/07/10/feature-highlight-ldap-sync/)
+  - [Feature Highlight: LDAP Integration](https://about.gitlab.com/blog/2014/07/10/feature-highlight-ldap-sync/)
   - [Debugging LDAP](https://about.gitlab.com/handbook/support/workflows/debugging_ldap.html)
 - **Integrations:**
   - [OmniAuth](../../integration/omniauth.md)
diff --git a/doc/topics/autodevops/img/disable_postgres.png b/doc/topics/autodevops/img/disable_postgres.png
new file mode 100644
index 00000000000..f8fe508915c
--- /dev/null
+++ b/doc/topics/autodevops/img/disable_postgres.png
diff --git a/doc/topics/autodevops/img/guide_base_domain_v12_3.png b/doc/topics/autodevops/img/guide_base_domain_v12_3.png
new file mode 100644
index 00000000000..0c8ab9b26e4
--- /dev/null
+++ b/doc/topics/autodevops/img/guide_base_domain_v12_3.png
diff --git a/doc/topics/autodevops/img/guide_choose_gke.png b/doc/topics/autodevops/img/guide_choose_gke.png
deleted file mode 100644
index 6da3a7220da..00000000000
--- a/doc/topics/autodevops/img/guide_choose_gke.png
+++ /dev/null
diff --git a/doc/topics/autodevops/img/guide_cluster_apps.png b/doc/topics/autodevops/img/guide_cluster_apps.png
deleted file mode 100644
index 33d25f2950d..00000000000
--- a/doc/topics/autodevops/img/guide_cluster_apps.png
+++ /dev/null
diff --git a/doc/topics/autodevops/img/guide_cluster_apps_v12_3.png b/doc/topics/autodevops/img/guide_cluster_apps_v12_3.png
new file mode 100644
index 00000000000..f903ae40c02
--- /dev/null
+++ b/doc/topics/autodevops/img/guide_cluster_apps_v12_3.png
diff --git a/doc/topics/autodevops/img/guide_create_project.png b/doc/topics/autodevops/img/guide_create_project.png
deleted file mode 100644
index 4ed1071db03..00000000000
--- a/doc/topics/autodevops/img/guide_create_project.png
+++ /dev/null
diff --git a/doc/topics/autodevops/img/guide_create_project_v12_3.png b/doc/topics/autodevops/img/guide_create_project_v12_3.png
new file mode 100644
index 00000000000..68ab7f23f3c
--- /dev/null
+++ b/doc/topics/autodevops/img/guide_create_project_v12_3.png
diff --git a/doc/topics/autodevops/img/guide_enable_autodevops.png b/doc/topics/autodevops/img/guide_enable_autodevops.png
deleted file mode 100644
index 0fc3ecca19a..00000000000
--- a/doc/topics/autodevops/img/guide_enable_autodevops.png
+++ /dev/null
diff --git a/doc/topics/autodevops/img/guide_enable_autodevops_v12_3.png b/doc/topics/autodevops/img/guide_enable_autodevops_v12_3.png
new file mode 100644
index 00000000000..7f0e7c60086
--- /dev/null
+++ b/doc/topics/autodevops/img/guide_enable_autodevops_v12_3.png
diff --git a/doc/topics/autodevops/img/guide_environments.png b/doc/topics/autodevops/img/guide_environments.png
deleted file mode 100644
index 404db17c57a..00000000000
--- a/doc/topics/autodevops/img/guide_environments.png
+++ /dev/null
diff --git a/doc/topics/autodevops/img/guide_environments_metrics.png b/doc/topics/autodevops/img/guide_environments_metrics.png
deleted file mode 100644
index f0d31f31581..00000000000
--- a/doc/topics/autodevops/img/guide_environments_metrics.png
+++ /dev/null
diff --git a/doc/topics/autodevops/img/guide_environments_metrics_v12_3.png b/doc/topics/autodevops/img/guide_environments_metrics_v12_3.png
new file mode 100644
index 00000000000..74f997a5122
--- /dev/null
+++ b/doc/topics/autodevops/img/guide_environments_metrics_v12_3.png
diff --git a/doc/topics/autodevops/img/guide_environments_v12_3.png b/doc/topics/autodevops/img/guide_environments_v12_3.png
new file mode 100644
index 00000000000..0ad282cfe4e
--- /dev/null
+++ b/doc/topics/autodevops/img/guide_environments_v12_3.png
diff --git a/doc/topics/autodevops/img/guide_first_pipeline.png b/doc/topics/autodevops/img/guide_first_pipeline.png
deleted file mode 100644
index 57459dcc9d9..00000000000
--- a/doc/topics/autodevops/img/guide_first_pipeline.png
+++ /dev/null
diff --git a/doc/topics/autodevops/img/guide_first_pipeline_v12_3.png b/doc/topics/autodevops/img/guide_first_pipeline_v12_3.png
new file mode 100644
index 00000000000..7654b4f0934
--- /dev/null
+++ b/doc/topics/autodevops/img/guide_first_pipeline_v12_3.png
diff --git a/doc/topics/autodevops/img/guide_gitlab_gke_details.png b/doc/topics/autodevops/img/guide_gitlab_gke_details.png
deleted file mode 100644
index bc5a53800f7..00000000000
--- a/doc/topics/autodevops/img/guide_gitlab_gke_details.png
+++ /dev/null
diff --git a/doc/topics/autodevops/img/guide_gitlab_gke_details_v12_3.png b/doc/topics/autodevops/img/guide_gitlab_gke_details_v12_3.png
new file mode 100644
index 00000000000..ba2b00dd984
--- /dev/null
+++ b/doc/topics/autodevops/img/guide_gitlab_gke_details_v12_3.png
diff --git a/doc/topics/autodevops/img/guide_google_auth.png b/doc/topics/autodevops/img/guide_google_auth_v12_3.png
index b97b2be9f15..b97b2be9f15 100644
--- a/doc/topics/autodevops/img/guide_google_auth.png
+++ b/doc/topics/autodevops/img/guide_google_auth_v12_3.png
diff --git a/doc/topics/autodevops/img/guide_google_signin.png b/doc/topics/autodevops/img/guide_google_signin.png
deleted file mode 100644
index e59fc94bd4c..00000000000
--- a/doc/topics/autodevops/img/guide_google_signin.png
+++ /dev/null
diff --git a/doc/topics/autodevops/img/guide_google_signin_v12_3.png b/doc/topics/autodevops/img/guide_google_signin_v12_3.png
new file mode 100644
index 00000000000..ac8a325dde6
--- /dev/null
+++ b/doc/topics/autodevops/img/guide_google_signin_v12_3.png
diff --git a/doc/topics/autodevops/img/guide_ide_commit.png b/doc/topics/autodevops/img/guide_ide_commit.png
deleted file mode 100644
index d7be66f4049..00000000000
--- a/doc/topics/autodevops/img/guide_ide_commit.png
+++ /dev/null
diff --git a/doc/topics/autodevops/img/guide_ide_commit_v12_3.png b/doc/topics/autodevops/img/guide_ide_commit_v12_3.png
new file mode 100644
index 00000000000..c40658e9ba9
--- /dev/null
+++ b/doc/topics/autodevops/img/guide_ide_commit_v12_3.png
diff --git a/doc/topics/autodevops/img/guide_merge_request.png b/doc/topics/autodevops/img/guide_merge_request.png
deleted file mode 100644
index d78e69be776..00000000000
--- a/doc/topics/autodevops/img/guide_merge_request.png
+++ /dev/null
diff --git a/doc/topics/autodevops/img/guide_merge_request_review_app.png b/doc/topics/autodevops/img/guide_merge_request_review_app.png
deleted file mode 100644
index 1b9b854ddac..00000000000
--- a/doc/topics/autodevops/img/guide_merge_request_review_app.png
+++ /dev/null
diff --git a/doc/topics/autodevops/img/guide_merge_request_review_app_v12_3.png b/doc/topics/autodevops/img/guide_merge_request_review_app_v12_3.png
new file mode 100644
index 00000000000..e1a4f181744
--- /dev/null
+++ b/doc/topics/autodevops/img/guide_merge_request_review_app_v12_3.png
diff --git a/doc/topics/autodevops/img/guide_merge_request_v12_3.png b/doc/topics/autodevops/img/guide_merge_request_v12_3.png
new file mode 100644
index 00000000000..8c70620162c
--- /dev/null
+++ b/doc/topics/autodevops/img/guide_merge_request_v12_3.png
diff --git a/doc/topics/autodevops/img/guide_pipeline_stages.png b/doc/topics/autodevops/img/guide_pipeline_stages.png
deleted file mode 100644
index 6e2f078152b..00000000000
--- a/doc/topics/autodevops/img/guide_pipeline_stages.png
+++ /dev/null
diff --git a/doc/topics/autodevops/img/guide_pipeline_stages_v12_3.png b/doc/topics/autodevops/img/guide_pipeline_stages_v12_3.png
new file mode 100644
index 00000000000..f55a985f543
--- /dev/null
+++ b/doc/topics/autodevops/img/guide_pipeline_stages_v12_3.png
diff --git a/doc/topics/autodevops/img/guide_project_landing_page.png b/doc/topics/autodevops/img/guide_project_landing_page.png
deleted file mode 100644
index 4f8d2eb10b1..00000000000
--- a/doc/topics/autodevops/img/guide_project_landing_page.png
+++ /dev/null
diff --git a/doc/topics/autodevops/img/guide_project_landing_page_v12_3.png b/doc/topics/autodevops/img/guide_project_landing_page_v12_3.png
new file mode 100644
index 00000000000..4d62588ed90
--- /dev/null
+++ b/doc/topics/autodevops/img/guide_project_landing_page_v12_3.png
diff --git a/doc/topics/autodevops/img/guide_project_template.png b/doc/topics/autodevops/img/guide_project_template.png
deleted file mode 100644
index 298ac0f6fcf..00000000000
--- a/doc/topics/autodevops/img/guide_project_template.png
+++ /dev/null
diff --git a/doc/topics/autodevops/img/guide_project_template_v12_3.png b/doc/topics/autodevops/img/guide_project_template_v12_3.png
new file mode 100644
index 00000000000..9ce730518d0
--- /dev/null
+++ b/doc/topics/autodevops/img/guide_project_template_v12_3.png
diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md
index e42c89ac567..a1373639a87 100644
--- a/doc/topics/autodevops/index.md
+++ b/doc/topics/autodevops/index.md
@@ -77,7 +77,7 @@ As Auto DevOps relies on many different components, it's good to have a basic
 knowledge of the following:
 
 - [Kubernetes](https://kubernetes.io/docs/home/)
-- [Helm](https://docs.helm.sh/)
+- [Helm](https://helm.sh/docs/)
 - [Docker](https://docs.docker.com)
 - [GitLab Runner](https://docs.gitlab.com/runner/)
 - [Prometheus](https://prometheus.io/docs/introduction/overview/)
@@ -85,7 +85,7 @@ knowledge of the following:
 Auto DevOps provides great defaults for all the stages; you can, however,
 [customize](#customizing) almost everything to your needs.
 
-For an overview on the creation of Auto DevOps, read the blog post [From 2/3 of the Self-Hosted Git Market, to the Next-Generation CI System, to Auto DevOps](https://about.gitlab.com/2017/06/29/whats-next-for-gitlab-ci/).
+For an overview on the creation of Auto DevOps, read the blog post [From 2/3 of the Self-Hosted Git Market, to the Next-Generation CI System, to Auto DevOps](https://about.gitlab.com/blog/2017/06/29/whats-next-for-gitlab-ci/).
 
 NOTE: **Note**
 Kubernetes clusters can [be used without](../../user/project/clusters/index.md)
@@ -98,7 +98,7 @@ To make full use of Auto DevOps, you will need:
 - **GitLab Runner** (for all stages)
 
   Your Runner needs to be configured to be able to run Docker. Generally this
-  means using the either the [Docker](https://docs.gitlab.com/runner/executors/docker.html)
+  means using either the [Docker](https://docs.gitlab.com/runner/executors/docker.html)
   or [Kubernetes](https://docs.gitlab.com/runner/executors/kubernetes.html) executors, with
   [privileged mode enabled](https://docs.gitlab.com/runner/executors/docker.html#use-docker-in-docker-with-privileged-mode).
 
@@ -122,9 +122,9 @@ To make full use of Auto DevOps, you will need:
 
   - Kubernetes 1.5+.
   - A [Kubernetes cluster][kubernetes-clusters] for the project.
-  - A load balancer. You can use NGINX ingress by deploying it to your
+  - A load balancer. You can use NGINX Ingress by deploying it to your
     Kubernetes cluster by either:
-    - Using the [`nginx-ingress`](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress) Helm chart.
+    - Using the [`nginx-ingress`](https://github.com/helm/charts/tree/master/stable/nginx-ingress) Helm chart.
     - Installing the Ingress [GitLab Managed App](../../user/clusters/applications.md#ingress).
 - **Prometheus** (for Auto Monitoring)
 
@@ -172,7 +172,7 @@ and `1.2.3.4` is the IP address of your load balancer; generally NGINX
 ([see requirements](#requirements)). How to set up the DNS record is beyond
 the scope of this document; you should check with your DNS provider.
 
-Alternatively you can use free public services like [nip.io](http://nip.io)
+Alternatively you can use free public services like [nip.io](https://nip.io)
 which provide automatic wildcard DNS without any configuration. Just set the
 Auto DevOps base domain to `1.2.3.4.nip.io`.
 
@@ -331,7 +331,7 @@ If a project's repository contains a `Dockerfile`, Auto Build will use
 If you are also using Auto Review Apps and Auto Deploy and choose to provide
 your own `Dockerfile`, make sure you expose your application to port
 `5000` as this is the port assumed by the
-[default Helm chart](https://gitlab.com/gitlab-org/charts/auto-deploy-app). Alternatively you can override the default values by [customizing the Auto Deploy helm chart](#custom-helm-chart)
+[default Helm chart](https://gitlab.com/gitlab-org/charts/auto-deploy-app). Alternatively you can override the default values by [customizing the Auto Deploy Helm chart](#custom-helm-chart)
 
 #### Auto Build using Heroku buildpacks
 
@@ -487,6 +487,9 @@ in the first place, and thus not realize that it needs to re-apply the old confi
 
 > Introduced in [GitLab Ultimate][ee] 10.4.
 
+This is an optional step, since it requires a [review app](#auto-review-apps).
+If that requirement is not met, the job will be silently skipped.
+
 Dynamic Application Security Testing (DAST) uses the
 popular open source tool [OWASP ZAProxy](https://github.com/zaproxy/zaproxy)
 to perform an analysis on the current code and checks for potential security
@@ -498,6 +501,29 @@ later download and check out.
 Any security warnings are also shown in the merge request widget. Read how
 [DAST works](../../user/application_security/dast/index.md).
 
+On your default branch, DAST scans an app deployed specifically for that purpose.
+The app is deleted after DAST has run.
+
+On feature branches, DAST scans the [review app](#auto-review-apps).
+
+#### Overriding the DAST target
+
+To use a custom target instead of the auto-deployed review apps,
+set a `DAST_WEBSITE` environment variable to the URL for DAST to scan.
+
+NOTE: **Note:**
+If [DAST Full Scan](../../user/application_security/dast/index.md#full-scan) is enabled, it is strongly advised **not**
+to set `DAST_WEBSITE` to any staging or production environment. DAST Full Scan
+actively attacks the target, which can take down the application and lead to
+data loss or corruption.
+
+#### Disabling Auto DAST
+
+DAST can be disabled:
+
+- On all branches by setting the `DAST_DISABLED` environment variable to `"true"`.
+- Only on the default branch by setting the `DAST_DISABLED_FOR_DEFAULT_BRANCH` environment variable to `"true"`.
+
 ### Auto Browser Performance Testing **(PREMIUM)**
 
 > Introduced in [GitLab Premium][ee] 10.4.
@@ -529,7 +555,7 @@ Auto Deploy doesn't include deployments to staging or canary by default, but the
 enable them.
 
 You can make use of [environment variables](#environment-variables) to automatically
-scale your pod replicas and to apply custom arguments to the Auto DevOps `helm upgrade` commands. This is an easy way to [customize the Auto Deploy helm chart](#custom-helm-chart).
+scale your pod replicas and to apply custom arguments to the Auto DevOps `helm upgrade` commands. This is an easy way to [customize the Auto Deploy Helm chart](#custom-helm-chart).
 
 Apps are deployed using the
 [auto-deploy-app](https://gitlab.com/gitlab-org/charts/auto-deploy-app) chart with
@@ -572,7 +598,7 @@ within the application pod by setting the project variables `DB_INITIALIZE` and
 `DB_MIGRATE` respectively.
 
 If present, `DB_INITIALIZE` will be run as a shell command within an
-application pod as a helm post-install hook. As some applications will
+application pod as a Helm post-install hook. As some applications will
 not run without a successful database initialization step, GitLab will
 deploy the first release without the application deployment and only the
 database initialization step. After the database initialization completes,
@@ -583,7 +609,7 @@ Note that a post-install hook means that if any deploy succeeds,
 `DB_INITIALIZE` will not be processed thereafter.
 
 If present, `DB_MIGRATE` will be run as a shell command within an application pod as
-a helm pre-upgrade hook.
+a Helm pre-upgrade hook.
 
 For example, in a Rails application in an image built with
 [Herokuish](https://github.com/gliderlabs/herokuish):
@@ -734,14 +760,16 @@ Avoid passing secrets as Docker build arguments if possible, as they may be
 persisted in your image. See
 [this discussion](https://github.com/moby/moby/issues/13490) for details.
 
-### Passing secrets to `docker build` (beta)
+### Passing secrets to `docker build`
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/25514) in GitLab 12.3, but available in versions 11.9 and above.
 
 CI environment variables can be passed as [build
 secrets](https://docs.docker.com/develop/develop-images/build_enhancements/#new-docker-build-secret-information) to the `docker build` command by listing them comma separated by name in the
 `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` variable. For example, in order to forward the variables `CI_COMMIT_SHA` and `CI_ENVIRONMENT_NAME`, one would set `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` to `CI_COMMIT_SHA,CI_ENVIRONMENT_NAME`.
 
 Unlike build arguments, these are not persisted by Docker in the final image
-(though you can still persist them yourself, so be careful).
+(though you can still persist them yourself, so **be careful**).
 
 In projects:
 
@@ -845,6 +873,35 @@ the database are preconfigured, but can be customized by setting the associated
 postgres://user:password@postgres-host:postgres-port/postgres-database
 ```
 
+#### Using external PostgreSQL database providers
+
+While Auto DevOps provides out-of-the-box support for a PostgreSQL container for
+production environments, for some use-cases it may not be sufficiently secure or
+resilient and you may wish to use an external managed provider for PostgreSQL.
+For example, AWS Relational Database Service.
+
+You will need to define environment-scoped variables for `POSTGRES_ENABLED` and `DATABASE_URL` in your project's CI/CD settings.
+
+To achieve this:
+
+1. Disable the built-in PostgreSQL installation for the required environments using
+   scoped [environment variables](../../ci/environments.md#scoping-environments-with-specs).
+   For this use case, it's likely that only `production` will need to be added to this
+   list as the builtin PostgreSQL setup for Review Apps and staging will be sufficient
+   as a high availability setup is not required.
+
+   ![Auto Metrics](img/disable_postgres.png)
+
+1. Define the `DATABASE_URL` CI variable as a scoped environment variable that will be
+   available to your application. This should be a URL in the following format:
+
+   ```yaml
+   postgres://user:password@postgres-host:postgres-port/postgres-database
+   ```
+
+You will need to ensure that your Kubernetes cluster has network access to wherever
+PostgreSQL is hosted.
+
 ### Environment variables
 
 The following variables can be used for setting up the Auto DevOps domain,
@@ -858,27 +915,27 @@ applications.
 
 | **Variable**                            | **Description**                    |
 |-----------------------------------------|------------------------------------|
-| `ADDITIONAL_HOSTS`                      | Fully qualified domain names specified as a comma-separated list that are added to the ingress hosts. |
-| `<ENVIRONMENT>_ADDITIONAL_HOSTS`        | For a specific environment, the fully qualified domain names specified as a comma-separated list that are added to the ingress hosts. This takes precedence over `ADDITIONAL_HOSTS`. |
+| `ADDITIONAL_HOSTS`                      | Fully qualified domain names specified as a comma-separated list that are added to the Ingress hosts. |
+| `<ENVIRONMENT>_ADDITIONAL_HOSTS`        | For a specific environment, the fully qualified domain names specified as a comma-separated list that are added to the Ingress hosts. This takes precedence over `ADDITIONAL_HOSTS`. |
 | `AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS`    | Extra arguments to be passed to the `docker build` command. Note that using quotes will not prevent word splitting. [More details](#passing-arguments-to-docker-build). |
-| `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` | A [comma-separated list of CI variable names](#passing-secrets-to-docker-build-beta) to be passed to the `docker build` command as secrets. |
+| `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` | A [comma-separated list of CI variable names](#passing-secrets-to-docker-build) to be passed to the `docker build` command as secrets. |
 | `AUTO_DEVOPS_CHART`                     | Helm Chart used to deploy your apps. Defaults to the one [provided by GitLab](https://gitlab.com/gitlab-org/charts/auto-deploy-app). |
 | `AUTO_DEVOPS_CHART_REPOSITORY`          | Helm Chart repository used to search for charts. Defaults to `https://charts.gitlab.io`. |
-| `AUTO_DEVOPS_CHART_REPOSITORY_NAME`     | From Gitlab 11.11, used to set the name of the helm repository. Defaults to `gitlab`. |
-| `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME` | From Gitlab 11.11, used to set a username to connect to the helm repository. Defaults to no credentials. Also set `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD`. |
-| `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD` | From Gitlab 11.11, used to set a password to connect to the helm repository. Defaults to no credentials. Also set `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME`. |
+| `AUTO_DEVOPS_CHART_REPOSITORY_NAME`     | From GitLab 11.11, used to set the name of the Helm repository. Defaults to `gitlab`. |
+| `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME` | From GitLab 11.11, used to set a username to connect to the Helm repository. Defaults to no credentials. Also set `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD`. |
+| `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD` | From GitLab 11.11, used to set a password to connect to the Helm repository. Defaults to no credentials. Also set `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME`. |
 | `BUILDPACK_URL`                         | Buildpack's full URL. Can point to either Git repositories or a tarball URL. For Git repositories, it is possible to point to a specific `ref`. For example `https://github.com/heroku/heroku-buildpack-ruby.git#v142`. |
 | `CANARY_ENABLED`                        | From GitLab 11.0, used to define a [deploy policy for canary environments](#deploy-policy-for-canary-environments-premium). |
 | `CANARY_PRODUCTION_REPLICAS`            | Number of canary replicas to deploy for [Canary Deployments](../../user/project/canary_deployments.md) in the production environment. Takes precedence over `CANARY_REPLICAS`. Defaults to 1. |
 | `CANARY_REPLICAS`                       | Number of canary replicas to deploy for [Canary Deployments](../../user/project/canary_deployments.md). Defaults to 1. |
 | `HELM_RELEASE_NAME`                     | From GitLab 12.1, allows the `helm` release name to be overridden. Can be used to assign unique release names when deploying multiple projects to a single namespace. |
-| `HELM_UPGRADE_EXTRA_ARGS`               | From GitLab 11.11, allows extra arguments in `helm` commands when deploying the application. Note that using quotes will not prevent word splitting. **Tip:** you can use this variable to [customize the Auto Deploy helm chart](#custom-helm-chart) by applying custom override values with `--values my-values.yaml`. |
+| `HELM_UPGRADE_EXTRA_ARGS`               | From GitLab 11.11, allows extra arguments in `helm` commands when deploying the application. Note that using quotes will not prevent word splitting. **Tip:** you can use this variable to [customize the Auto Deploy Helm chart](#custom-helm-chart) by applying custom override values with `--values my-values.yaml`. |
 | `INCREMENTAL_ROLLOUT_MODE`              | From GitLab 11.4, if present, can be used to enable an [incremental rollout](#incremental-rollout-to-production-premium) of your application for the production environment. Set to `manual` for manual deployment jobs or `timed` for automatic rollout deployments with a 5 minute delay each one. |
 | `K8S_SECRET_*`                          | From GitLab 11.7, any variable prefixed with [`K8S_SECRET_`](#application-secret-variables) will be made available by Auto DevOps as environment variables to the deployed application. |
 | `KUBE_INGRESS_BASE_DOMAIN`              | From GitLab 11.8, can be used to set a domain per cluster. See [cluster domains](../../user/project/clusters/index.md#base-domain) for more information. |
 | `PRODUCTION_REPLICAS`                   | Number of replicas to deploy in the production environment. Takes precedence over `REPLICAS` and defaults to 1. For zero downtime upgrades, set to 2 or greater. |
 | `REPLICAS`                              | Number of replicas to deploy. Defaults to 1. |
-| `ROLLOUT_RESOURCE_TYPE`                 | From GitLab 11.9, allows specification of the resource type being deployed when using a custom helm chart. Default value is `deployment`. |
+| `ROLLOUT_RESOURCE_TYPE`                 | From GitLab 11.9, allows specification of the resource type being deployed when using a custom Helm chart. Default value is `deployment`. |
 | `ROLLOUT_STATUS_DISABLED`               | From GitLab 12.0, used to disable rollout status check because it doesn't support all resource types, for example, `cronjob`. |
 | `STAGING_ENABLED`                       | From GitLab 10.8, used to define a [deploy policy for staging and production environments](#deploy-policy-for-staging-and-production-environments). |
 
@@ -1138,13 +1195,13 @@ This configuration is deprecated and will be removed in the future.
 TIP: **Tip:**
 You can also set this inside your [project's settings](#deployment-strategy).
 
-This configuration based on
+This configuration is based on
 [incremental rollout to production](#incremental-rollout-to-production-premium).
 
 Everything behaves the same way, except:
 
 - It's enabled by setting the `INCREMENTAL_ROLLOUT_MODE` variable to `timed`.
-- Instead of the standard `production` job, the following jobs with a 5 minute delay between each are created:
+- Instead of the standard `production` job, the following jobs are created with a 5 minute delay between each :
   1. `timed rollout 10%`
   1. `timed rollout 25%`
   1. `timed rollout 50%`
@@ -1181,22 +1238,6 @@ As of GitLab 10.0, the supported buildpacks are:
 
 The following restrictions apply.
 
-### Private project support
-
-CAUTION: **Caution:** Private project support in Auto DevOps is experimental.
-
-When a project has been marked as private, GitLab's [Container
-Registry][container-registry] requires authentication when downloading
-containers. Auto DevOps will automatically provide the required authentication
-information to Kubernetes, allowing temporary access to the registry.
-Authentication credentials will be valid while the pipeline is running, allowing
-for a successful initial deployment.
-
-After the pipeline completes, Kubernetes will no longer be able to access the
-Container Registry. **Restarting a pod, scaling a service, or other actions which
-require on-going access to the registry may fail**. On-going secure access is
-planned for a subsequent release.
-
 ### Private registry support
 
 There is no documented way of using private container registry with Auto DevOps.
@@ -1265,11 +1306,11 @@ curl --data "value=true" --header "PRIVATE-TOKEN: personal_access_token" https:/
 [review-app]: ../../ci/review_apps/index.md
 [container-registry]: ../../user/packages/container_registry/index.md
 [postgresql]: https://www.postgresql.org/
-[Auto DevOps template]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml
+[Auto DevOps template]: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml
 [ee]: https://about.gitlab.com/pricing/
 [ce-21955]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/21955
 [ce-19507]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/19507
 
 ## Development guides
 
-Configuring [GDK for Auto DevOps](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/auto_devops.md).
+[Development guide for Auto DevOps](../../development/auto_devops.md)
diff --git a/doc/topics/autodevops/quick_start_guide.md b/doc/topics/autodevops/quick_start_guide.md
index d0ff149cf31..d9bdd73221f 100644
--- a/doc/topics/autodevops/quick_start_guide.md
+++ b/doc/topics/autodevops/quick_start_guide.md
@@ -25,7 +25,7 @@ Google account (for example, one that you use to access Gmail, Drive, etc.) or c
 TIP: **Tip:**
 Every new Google Cloud Platform (GCP) account receives [$300 in credit](https://console.cloud.google.com/freetrial),
 and in partnership with Google, GitLab is able to offer an additional $200 for new GCP accounts to get started with GitLab's
-Google Kubernetes Engine Integration. All you have to do is [follow this link](https://goo.gl/AaJzRW) and apply for credit.
+Google Kubernetes Engine Integration. All you have to do is [follow this link](https://cloud.google.com/partners/partnercredit/?PCN=a0n60000006Vpz4AAC) and apply for credit.
 
 ## Creating a new project from a template
 
@@ -35,16 +35,16 @@ those projects provide a barebones application built on some well-known framewor
 1. In GitLab, click the plus icon (**+**) at the top of the navigation bar and select
    **New project**.
 1. Go to the **Create from template** tab where you can choose among a Ruby on
-   Rails, Spring, or NodeJS Express project. For this example,
-   we'll use the Ruby on Rails template.
+   Rails, Spring, or NodeJS Express project.
+   We'll use the Ruby on Rails template.
 
-   ![Select project template](img/guide_project_template.png)
+   ![Select project template](img/guide_project_template_v12_3.png)
 
 1. Give your project a name, optionally a description, and make it public so that
    you can take advantage of the features available in the
    [GitLab Gold plan](https://about.gitlab.com/pricing/#gitlab-com).
 
-   ![Create project](img/guide_create_project.png)
+   ![Create project](img/guide_create_project_v12_3.png)
 
 1. Click **Create project**.
 
@@ -56,37 +56,30 @@ under which this application will be deployed.
 1. On the project's landing page, click the button labeled **Add Kubernetes cluster**
    (note that this option is also available when you navigate to **Operations > Kubernetes**).
 
-   ![Project landing page](img/guide_project_landing_page.png)
+   ![Project landing page](img/guide_project_landing_page_v12_3.png)
 
-1. Choose **Create on Google Kubernetes Engine**.
+1. One the **Create new cluster on GKE** tab, click "Sign in with Google".
 
-   ![Choose GKE](img/guide_choose_gke.png)
-
-1. Sign in with Google.
-
-   ![Google sign in](img/guide_google_signin.png)
+   ![Google sign in](img/guide_google_signin_v12_3.png)
 
 1. Connect with your Google account and press **Allow** when asked (this will
    be shown only the first time you connect GitLab with your Google account).
 
-   ![Google auth](img/guide_google_auth.png)
+   ![Google auth](img/guide_google_auth_v12_3.png)
 
-1. The last step is to fill in the cluster details. Give it a name, leave the
+1. The last step is to provide the cluster details. Give it a name, leave the
    environment scope as is, and choose the GCP project under which the cluster
    will be created. (Per the instructions when you
    [configured your Google account](#configuring-your-google-account), a project
    should have already been created for you.) Next, choose the
    [region/zone](https://cloud.google.com/compute/docs/regions-zones/) under which the
    cluster will be created, enter the number of nodes you want it to have, and
-   finally choose their [machine type](https://cloud.google.com/compute/docs/machine-types).
+   finally choose the [machine type](https://cloud.google.com/compute/docs/machine-types).
 
-   ![GitLab GKE cluster details](img/guide_gitlab_gke_details.png)
+   ![GitLab GKE cluster details](img/guide_gitlab_gke_details_v12_3.png)
 
 1. Once ready, click **Create Kubernetes cluster**.
 
-NOTE: **Note:**
-Do not select `f1-micro` from the **Machine type** dropdown. `f1-micro` machines cannot support a full GitLab installation.
-
 After a couple of minutes, the cluster will be created. You can also see its
 status on your [GCP dashboard](https://console.cloud.google.com/kubernetes).
 
@@ -99,7 +92,7 @@ GitLab's Kubernetes integration comes with some
 [pre-defined applications](../../user/project/clusters/index.md#installing-applications)
 for you to install.
 
-![Cluster applications](img/guide_cluster_apps.png)
+![Cluster applications](img/guide_cluster_apps_v12_3.png)
 
 The first one to install is Helm Tiller, a package manager for Kubernetes, which
 is needed in order to install the rest of the applications. Go ahead and click
@@ -113,32 +106,31 @@ use to supervise the deployed application. We will not install GitLab Runner as
 we'll use the shared Runners that GitLab.com provides.
 
 After the Ingress is installed, wait a few seconds and copy the IP address that
-is displayed, which we'll use in the next step when enabling Auto DevOps.
+is displayed in order to add in your base **Domain** at the top of the page. For
+the purpose of this guide, we will use the one suggested by GitLab. Once you have
+filled in the domain, click **Save changes**.
+
+![Cluster Base Domain](img/guide_base_domain_v12_3.png)
 
-## Enabling Auto DevOps
+## Enabling Auto DevOps (optional)
 
-Now that the Kubernetes cluster is set up and ready, let's enable Auto DevOps.
+Starting with GitLab 11.3, Auto DevOps is enabled by default. However, it is possible to disable
+Auto DevOps at both the instance-level (for self-managed instances) and also at the group-level.
+Follow these steps if Auto DevOps has been manually disabled.
 
 1. First, navigate to **Settings > CI/CD > Auto DevOps**.
-1. Select **Enable Auto DevOps**.
-1. Add in your base **Domain** by using the one GitLab suggests. Note that
-   generally, you would associate the IP address with a domain name on your
-   registrar's settings. In this case, for the sake of the guide, we will use
-   an alternative DNS that will map any domain name of the scheme
-   `anything.ip_address.nip.io` to the corresponding `ip_address`. For example,
-   if the IP address of the Ingress is `1.2.3.4`, the domain name to fill in
-   would be `1.2.3.4.nip.io`.
+1. Select **Default to Auto DevOps pipeline**.
 1. Lastly, let's select the [continuous deployment strategy](index.md#deployment-strategy)
    which will automatically deploy the application to production once the pipeline
    successfully runs on the `master` branch.
 1. Click **Save changes**.
 
-   ![Auto DevOps settings](img/guide_enable_autodevops.png)
+   ![Auto DevOps settings](img/guide_enable_autodevops_v12_3.png)
 
 Once you complete all the above and save your changes, a new pipeline is
 automatically created. To view the pipeline, go to **CI/CD > Pipelines**.
 
-![First pipeline](img/guide_first_pipeline.png)
+![First pipeline](img/guide_first_pipeline_v12_3.png)
 
 In the next section we'll break down the pipeline and explain what each job does.
 
@@ -149,7 +141,7 @@ By now you should see the pipeline running, but what is it running exactly?
 To navigate inside the pipeline, click its status badge. (Its status should be "running").
 The pipeline is split into 4 stages, each running a couple of jobs.
 
-![Pipeline stages](img/guide_pipeline_stages.png)
+![Pipeline stages](img/guide_pipeline_stages_v12_3.png)
 
 In the **build** stage, the application is built into a Docker image and then
 uploaded to your project's [Container Registry](../../user/packages/container_registry/index.md) ([Auto Build](index.md#auto-build)).
@@ -190,7 +182,7 @@ page where you can also monitor your application. Let's explore that.
 Now that the application is successfully deployed, let's navigate to its
 website. First, go to **Operations > Environments**.
 
-![Environments](img/guide_environments.png)
+![Environments](img/guide_environments_v12_3.png)
 
 In **Environments** you can see some details about the deployed
 applications. In the rightmost column for the production environment, you can make use of the three icons:
@@ -201,7 +193,7 @@ applications. In the rightmost column for the production environment, you can ma
   Prometheus collects data about the Kubernetes cluster and how the application
   affects it (in terms of memory/CPU usage, latency, etc.).
 
-  ![Environments metrics](img/guide_environments_metrics.png)
+  ![Environments metrics](img/guide_environments_metrics_v12_3.png)
 
 - The third icon is the [web terminal](../../ci/environments.md#web-terminals)
   and it will open a terminal session right inside the container where the
@@ -235,13 +227,13 @@ you're on the Web IDE, make the following change:
 Stage the file, add a commit message, and create a new branch and a merge request
 by clicking **Commit**.
 
-![Web IDE commit](img/guide_ide_commit.png)
+![Web IDE commit](img/guide_ide_commit_v12_3.png)
 
 Once you submit the merge request, you'll see the pipeline running. This will
 run all the jobs as [described previously](#deploying-the-application), as well as
 a few more that run only on branches other than `master`.
 
-![Merge request](img/guide_merge_request.png)
+![Merge request](img/guide_merge_request_v12_3.png)
 
 After a few minutes you'll notice that there was a failure in a test.
 This means there's a test that was 'broken' by our change.
@@ -259,7 +251,7 @@ bin/rails test test/controllers/welcome_controller_test.rb:4
 
 Let's fix that:
 
-1. Back to the merge request, click the **Web IDE** button.
+1. Back to the merge request, click the **Open in Web IDE** button.
 1. Find the `test/controllers/welcome_controller_test.rb` file and open it.
 1. Change line 7 to say `You're on Rails! Powered by GitLab Auto DevOps.`
 1. Click **Commit**.
@@ -269,10 +261,10 @@ Let's fix that:
 
 Now, if you go back to the merge request you should not only see the test passing, but
 also the application deployed as a [review app](index.md#auto-review-apps). You
-can visit it by following the URL in the merge request. The changes that we
-previously made should be there.
+can visit it by following clicking the **View app** button. You will see
+the changes that we previously made.
 
-![Review app](img/guide_merge_request_review_app.png)
+![Review app](img/guide_merge_request_review_app_v12_3.png)
 
 Once you merge the merge request, the pipeline will run on the `master` branch,
 and the application will be eventually deployed straight to production.
diff --git a/doc/topics/git/how_to_install_git/index.md b/doc/topics/git/how_to_install_git/index.md
index c7bede2d269..db474559627 100644
--- a/doc/topics/git/how_to_install_git/index.md
+++ b/doc/topics/git/how_to_install_git/index.md
@@ -38,7 +38,7 @@ through the macOS App Store.
 
 ### Installing Homebrew
 
-Once Xcode is installed browse to the [Homebrew website](http://brew.sh/index.html)
+Once Xcode is installed browse to the [Homebrew website](https://brew.sh/index.html)
 for the official Homebrew installation instructions.
 
 ### Installing Git via Homebrew
diff --git a/doc/topics/git/index.md b/doc/topics/git/index.md
index 6a539b526f3..d6e1f83b876 100644
--- a/doc/topics/git/index.md
+++ b/doc/topics/git/index.md
@@ -11,7 +11,7 @@ large projects with speed and efficiency.
 [GitLab](https://about.gitlab.com) is a Git-based fully integrated platform for
 software development. Besides Git's functionalities, GitLab has a lot of
 powerful [features](https://about.gitlab.com/features/) to enhance your
-[workflow](https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/).
+[workflow](https://about.gitlab.com/blog/2016/10/25/gitlab-workflow-an-overview/).
 
 We've gathered some resources to help you to get the best from Git with GitLab.
 
@@ -39,8 +39,8 @@ The following resources will help you get started with Git:
 The following are resources about version control concepts:
 
 - [Git concepts](../../university/training/user_training.md#git-concepts)
-- [Why Git is Worth the Learning Curve](https://about.gitlab.com/2017/05/17/learning-curve-is-the-biggest-challenge-developers-face-with-git/)
-- [The future of SaaS hosted Git repository pricing](https://about.gitlab.com/2016/05/11/git-repository-pricing/)
+- [Why Git is Worth the Learning Curve](https://about.gitlab.com/blog/2017/05/17/learning-curve-is-the-biggest-challenge-developers-face-with-git/)
+- [The future of SaaS hosted Git repository pricing](https://about.gitlab.com/blog/2016/05/11/git-repository-pricing/)
 - [Git website topic about version control](https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control)
 - [GitLab University presentation about Version Control](https://docs.google.com/presentation/d/16sX7hUrCZyOFbpvnrAFrg6tVO5_yT98IgdAqOmXwBho/edit?usp=sharing)
 
@@ -49,8 +49,8 @@ The following are resources about version control concepts:
 The following resources may help you become more efficient at using Git:
 
 - [Useful Git commands](useful_git_commands.md) collected by the GitLab support team.
-- [Git Tips & Tricks](https://about.gitlab.com/2016/12/08/git-tips-and-tricks/)
-- [Eight Tips to help you work better with Git](https://about.gitlab.com/2015/02/19/8-tips-to-help-you-work-better-with-git/)
+- [Git Tips & Tricks](https://about.gitlab.com/blog/2016/12/08/git-tips-and-tricks/)
+- [Eight Tips to help you work better with Git](https://about.gitlab.com/blog/2015/02/19/8-tips-to-help-you-work-better-with-git/)
 
 ## Troubleshooting Git
 
@@ -63,7 +63,7 @@ If you have problems with Git, the following may help:
 
 - [Git Branching - Branches in a Nutshell](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell)
 - [Git Branching - Branching Workflows](https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows)
-- [GitLab Flow](https://about.gitlab.com/2014/09/29/gitlab-flow/)
+- [GitLab Flow](https://about.gitlab.com/blog/2014/09/29/gitlab-flow/)
 
 ## Advanced use
 
@@ -83,9 +83,9 @@ Git-related queries from GitLab.
 
 The following relate to Git Large File Storage:
 
-- [Getting Started with Git LFS](https://about.gitlab.com/2017/01/30/getting-started-with-git-lfs-tutorial/)
+- [Getting Started with Git LFS](https://about.gitlab.com/blog/2017/01/30/getting-started-with-git-lfs-tutorial/)
 - [Migrate an existing Git repo with Git LFS](migrate_to_git_lfs/index.md)
 - [GitLab Git LFS user documentation](../../workflow/lfs/manage_large_binaries_with_git_lfs.md)
 - [GitLab Git LFS admin documentation](../../workflow/lfs/lfs_administration.md)
-- [Git-Annex to Git-LFS migration guide](../../workflow/lfs/migrate_from_git_annex_to_git_lfs.md)
-- [Towards a production quality open source Git LFS server](https://about.gitlab.com/2015/08/13/towards-a-production-quality-open-source-git-lfs-server/)
+- [git-annex to Git-LFS migration guide](../../workflow/lfs/migrate_from_git_annex_to_git_lfs.md)
+- [Towards a production quality open source Git LFS server](https://about.gitlab.com/blog/2015/08/13/towards-a-production-quality-open-source-git-lfs-server/)
diff --git a/doc/topics/git/migrate_to_git_lfs/index.md b/doc/topics/git/migrate_to_git_lfs/index.md
index c879e404997..0c30b45c552 100644
--- a/doc/topics/git/migrate_to_git_lfs/index.md
+++ b/doc/topics/git/migrate_to_git_lfs/index.md
@@ -15,7 +15,7 @@ will not actually reduce the size of your repository because
 the files are still referenced by previous commits.
 
 Through the method described on this document, first migrate
-to Git LFS with [BFG](https://rtyley.github.io/bfg-repo-cleaner/)
+to Git LFS with a tool such as the open source community-maintained [BFG](https://rtyley.github.io/bfg-repo-cleaner/)
 through a mirror repo, then clean up the repository's history,
 and lastly create LFS tracking rules to prevent new binary files
 from being added.
@@ -133,7 +133,7 @@ Consider an example upstream project, `git@gitlab.com:gitlab-tests/test-git-lfs-
    # You may need to reset your local copy with upstream's `master` after force-pushing from the mirror:
    git reset --hard origin/master
    # Track the files with LFS:
-   git lfs track "*.gif" "*.png" "*.jpg" "*.psd" "*.mp4" ".gitattributes" "img/"
+   git lfs track "*.gif" "*.png" "*.jpg" "*.psd" "*.mp4" "img/"
    ```
 
    Now all existing the files you converted, as well as the new
@@ -162,7 +162,7 @@ but commented out to help encourage others to add to it in the future. -->
 
 ## References
 
-- [Getting Started with Git LFS](https://about.gitlab.com/2017/01/30/getting-started-with-git-lfs-tutorial/)
+- [Getting Started with Git LFS](https://about.gitlab.com/blog/2017/01/30/getting-started-with-git-lfs-tutorial/)
 - [Migrate from Git Annex to Git LFS](../../../workflow/lfs/migrate_from_git_annex_to_git_lfs.md)
 - [GitLab's Git LFS user documentation](../../../workflow/lfs/manage_large_binaries_with_git_lfs.md)
 - [GitLab's Git LFS administrator documentation](../../../workflow/lfs/lfs_administration.md)
diff --git a/doc/topics/git/numerous_undo_possibilities_in_git/index.md b/doc/topics/git/numerous_undo_possibilities_in_git/index.md
index 2ab03df095c..33da01d35b8 100644
--- a/doc/topics/git/numerous_undo_possibilities_in_git/index.md
+++ b/doc/topics/git/numerous_undo_possibilities_in_git/index.md
@@ -487,9 +487,9 @@ git filter-branch --tree-filter 'rm filename' HEAD
 Since `git filter-branch` command might be slow on big repositories, there are
 tools that can use some of Git specifics to enable faster execution of common
 tasks (which is exactly what removing sensitive information file is about).
-An alternative is [BFG Repo-cleaner][bfg-repo-cleaner]. Keep in mind that these
-tools are faster because they do not provide a same fully feature set as `git filter-branch`
-does, but focus on specific use cases.
+An alternative is the open source community-maintained tool [BFG][bfg-repo-cleaner].  
+Keep in mind that these tools are faster because they do not provide the same  
+feature set as `git filter-branch` does, but focus on specific use cases.
 
 ## Conclusion
 
@@ -521,5 +521,5 @@ but commented out to help encourage others to add to it in the future. -->
 [git-filters-manual]: https://git-scm.com/docs/git-filter-branch#_options
 [git-official]: https://git-scm.com/
 [gitlab]: https://gitlab.com/gitlab-org/gitlab/blob/master/CONTRIBUTING.md#contribution-acceptance-criteria
-[gitlab-flow]: https://about.gitlab.com/2014/09/29/gitlab-flow/
-[gitlab-git-tips-n-tricks]: https://about.gitlab.com/2016/12/08/git-tips-and-tricks/
+[gitlab-flow]: https://about.gitlab.com/blog/2014/09/29/gitlab-flow/
+[gitlab-git-tips-n-tricks]: https://about.gitlab.com/blog/2016/12/08/git-tips-and-tricks/
diff --git a/doc/topics/git/partial_clone.md b/doc/topics/git/partial_clone.md
index c9a5430b2c6..ce1b551ddb6 100644
--- a/doc/topics/git/partial_clone.md
+++ b/doc/topics/git/partial_clone.md
@@ -102,7 +102,8 @@ enabled on the Git server:
 1. *Create a new Git repository and fetch.* Support for `--filter=sparse:oid`
    using the clone command is incomplete, so we will emulate the clone command
    by hand, using `git init` and `git fetch`. Follow
-   [gitaly#1769](https://gitlab.com/gitlab-org/gitaly/issues/1769) for updates.
+   [issue tracking support for `--filter=sparse:oid`](https://gitlab.com/gitlab-org/git/issues/4)
+   for updates.
 
    ```bash
    # Create a new directory for the Git repository
@@ -133,7 +134,7 @@ enabled on the Git server:
 
 1. **Sparse checkout** must be enabled and configured to prevent objects from
    other paths being downloaded automatically when checking out branches. Follow
-   [gitaly#1765](https://gitlab.com/gitlab-org/gitaly/issues/1765) for updates.
+   [issue proposing automating sparse checkouts](https://gitlab.com/gitlab-org/git/issues/5) for updates.
 
    ```bash
    # Enable sparse checkout
diff --git a/doc/topics/git/troubleshooting_git.md b/doc/topics/git/troubleshooting_git.md
index 11284da30af..5391f6e5ad6 100644
--- a/doc/topics/git/troubleshooting_git.md
+++ b/doc/topics/git/troubleshooting_git.md
@@ -8,7 +8,7 @@ Sometimes things don't work the way they should or as you might expect when
 you're using Git. Here are some tips on troubleshooting and resolving issues
 with Git.
 
-## Broken pipe errors on git push
+## Broken pipe errors on `git push`
 
 'Broken pipe' errors can occur when attempting to push to a remote repository.
 When pushing you will usually see:
@@ -22,8 +22,13 @@ To fix this issue, here are some possible solutions.
 
 ### Increase the POST buffer size in Git
 
-**If pushing over HTTP**, you can try increasing the POST buffer size in Git's
-configuration. Open a terminal and enter:
+**If you're using Git over HTTP instead of SSH**, you can try increasing the POST buffer size in Git's
+configuration.
+
+Example of an error during a clone:
+`fatal: pack has bad object at offset XXXXXXXXX: inflate returned -5`
+
+Open a terminal and enter:
 
 ```sh
 git config http.postBuffer 52428800
@@ -68,7 +73,7 @@ ClientAliveInterval 60
 ClientAliveCountMax 5
 ```
 
-### Running a git repack
+### Running a `git repack`
 
 **If 'pack-objects' type errors are also being displayed**, you can try to
 run a `git repack` before attempting to push to the remote repository again:
@@ -110,7 +115,7 @@ MaxStartups 100
 
 Restart SSHD for the change to take effect.
 
-## Timeout during git push/pull
+## Timeout during `git push` / `git pull`
 
 If pulling/pushing from/to your repository ends up taking more than 50 seconds,
 a timeout will be issued with a log of the number of operations performed
diff --git a/doc/topics/git/useful_git_commands.md b/doc/topics/git/useful_git_commands.md
index 030e62f485a..cfe19c89618 100644
--- a/doc/topics/git/useful_git_commands.md
+++ b/doc/topics/git/useful_git_commands.md
@@ -108,7 +108,7 @@ git reflog
 
 ### Check the Git history of a file
 
-The basic command to check the git history of a file:
+The basic command to check the Git history of a file:
 
 ```sh
 git log <file>
@@ -147,7 +147,7 @@ gitk --follow <file>
 
 ## Debugging
 
-### Use a custom SSH key for a git command
+### Use a custom SSH key for a Git command
 
 ```sh
 GIT_SSH_COMMAND="ssh -i ~/.ssh/gitlabadmin" git <command>
@@ -183,7 +183,7 @@ git rebase -i master
 git rebase --continue
 ```
 
-### Use git rerere
+### Use `git rerere`
 
 To _reuse_ recorded solutions to the same problems when repeated:
 
diff --git a/doc/university/README.md b/doc/university/README.md
index 2d2321ffc2d..8f5a5038bb9 100644
--- a/doc/university/README.md
+++ b/doc/university/README.md
@@ -26,7 +26,7 @@ The GitLab University curriculum is composed of GitLab videos, screencasts, pres
 ### 1.1. Version Control and Git
 
 1. [Version Control Systems](https://docs.google.com/presentation/d/16sX7hUrCZyOFbpvnrAFrg6tVO5_yT98IgdAqOmXwBho/edit#slide=id.g72f2e4906_2_29)
-1. [Code School: An Introduction to Git](https://www.codeschool.com/account/courses/try-git)
+1. [Katakoda: Learn Git Version Control using Interactive Browser-Based Scenarios](https://www.katacoda.com/courses/git)
 
 ### 1.2. GitLab Basics
 
@@ -34,49 +34,49 @@ The GitLab University curriculum is composed of GitLab videos, screencasts, pres
 1. [Why Use Git and GitLab - Slides](https://docs.google.com/a/gitlab.com/presentation/d/1RcZhFmn5VPvoFu6UMxhMOy7lAsToeBZRjLRn0LIdaNc/edit?usp=drive_web)
 1. [GitLab Basics - Article](../gitlab-basics/README.md)
 1. [Git and GitLab Basics - Video](https://www.youtube.com/watch?v=03wb9FvO4Ak&index=5&list=PLFGfElNsQthbQu_IWlNOxul0TbS_2JH-e)
-1. [Git and GitLab Basics - Online Course](https://courses.platzi.com/classes/git-gitlab/concepto/part-1/part-23370/material/)
+1. [Git and GitLab Basics - Online Course](https://courses.platzi.com/classes/57-git-gitlab/2475-part-233-2/)
 1. [Comparison of GitLab Versions](https://about.gitlab.com/features/#compare)
 
 ### 1.3. Your GitLab Account
 
-1. [Create a GitLab Account - Online Course](https://courses.platzi.com/classes/git-gitlab/concepto/first-steps/create-an-account-on-gitlab/material/)
+1. [Create a GitLab Account - Online Course](https://courses.platzi.com/classes/57-git-gitlab/2434-create-an-account-on-gitlab/)
 1. [Create and Add your SSH key to GitLab - Video](https://www.youtube.com/watch?v=54mxyLo3Mqk)
 
 ### 1.4. GitLab Projects
 
 1. [Repositories, Projects and Groups - Video](https://www.youtube.com/watch?v=4TWfh1aKHHw&index=1&list=PLFGfElNsQthbQu_IWlNOxul0TbS_2JH-e)
 1. [Creating a Project in GitLab - Video](https://www.youtube.com/watch?v=7p0hrpNaJ14)
-1. [How to Create Files and Directories](https://about.gitlab.com/2016/02/10/feature-highlight-create-files-and-directories-from-files-page/)
-1. [GitLab Todos](https://about.gitlab.com/2016/03/02/gitlab-todos-feature-highlight/)
-1. [GitLab's Work in Progress (WIP) Flag](https://about.gitlab.com/2016/01/08/feature-highlight-wip/)
+1. [How to Create Files and Directories](https://about.gitlab.com/blog/2016/02/10/feature-highlight-create-files-and-directories-from-files-page/)
+1. [GitLab Todos](https://about.gitlab.com/blog/2016/03/02/gitlab-todos-feature-highlight/)
+1. [GitLab's Work in Progress (WIP) Flag](https://about.gitlab.com/blog/2016/01/08/feature-highlight-wip/)
 
 ### 1.5. Migrating from other Source Control
 
-1. [Migrating from BitBucket/Stash](../user/project/import/bitbucket.md)
+1. [Migrating from Bitbucket/Stash](../user/project/import/bitbucket.md)
 1. [Migrating from GitHub](../user/project/import/github.md)
 1. [Migrating from SVN](../user/project/import/svn.md)
 1. [Migrating from Fogbugz](../user/project/import/fogbugz.md)
 
 ### 1.6. The GitLab team
 
-1. [About GitLab](https://about.gitlab.com/about/)
+1. [About GitLab](https://about.gitlab.com/company/)
 1. [GitLab Direction](https://about.gitlab.com/direction/)
-1. [GitLab Master Plan](https://about.gitlab.com/2016/09/13/gitlab-master-plan/)
+1. [GitLab Master Plan](https://about.gitlab.com/blog/2016/09/13/gitlab-master-plan/)
 1. [Making GitLab Great for Everyone - Video](https://www.youtube.com/watch?v=GGC40y4vMx0) - Response to "Dear GitHub" letter
-1. [Using Innersourcing to Improve Collaboration](https://about.gitlab.com/2014/09/05/innersourcing-using-the-open-source-workflow-to-improve-collaboration-within-an-organization/)
+1. [Using Innersourcing to Improve Collaboration](https://about.gitlab.com/blog/2014/09/05/innersourcing-using-the-open-source-workflow-to-improve-collaboration-within-an-organization/)
 1. [The Software Development Market and GitLab - Video](https://www.youtube.com/watch?v=sXlhgPK1NTY&list=PLFGfElNsQthbQu_IWlNOxul0TbS_2JH-e&index=6) - [Slides](https://docs.google.com/presentation/d/1vCU-NbZWz8NTNK8Vu3y4zGMAHb5DpC8PE5mHtw1PWfI/edit)
 1. [The GitLab Book Club](bookclub/index.md)
 1. [GitLab Resources](https://about.gitlab.com/resources/)
 
 ### 1.7 Community and Support
 
-1. [Getting Help](https://about.gitlab.com/getting-help/)
+1. [Getting Help](https://about.gitlab.com/get-help/)
    - Proposing Features and Reporting and Tracking bugs for GitLab
    - The GitLab IRC channel, Gitter Chat Room, Community Forum and Mailing List
    - Getting Technical Support
    - Being part of our Great Community and Contributing to GitLab
-1. [Getting Started with the GitLab Development Kit (GDK)](https://about.gitlab.com/2016/06/08/getting-started-with-gitlab-development-kit/)
-1. [Contributing Technical Articles to the GitLab Blog](https://about.gitlab.com/2016/01/26/call-for-writers/)
+1. [Getting Started with the GitLab Development Kit (GDK)](https://about.gitlab.com/blog/2016/06/08/getting-started-with-gitlab-development-kit/)
+1. [Contributing Technical Articles to the GitLab Blog](https://about.gitlab.com/blog/2016/01/26/call-for-writers/)
 1. [GitLab Training Workshops](training/end-user/README.md)
 1. [GitLab Professional Services](https://about.gitlab.com/services/)
 
@@ -88,56 +88,56 @@ The GitLab University curriculum is composed of GitLab videos, screencasts, pres
 
 ### 2.1 GitLab Pages
 
-1. [Using any Static Site Generator with GitLab Pages](https://about.gitlab.com/2016/06/17/ssg-overview-gitlab-pages-part-3-examples-ci/)
-1. [Securing GitLab Pages with SSL](https://about.gitlab.com/2016/06/24/secure-gitlab-pages-with-startssl/)
+1. [Using any Static Site Generator with GitLab Pages](https://about.gitlab.com/blog/2016/06/17/ssg-overview-gitlab-pages-part-3-examples-ci/)
+1. [Securing GitLab Pages with SSL](https://about.gitlab.com/blog/2016/06/24/secure-gitlab-pages-with-startssl/)
 1. [GitLab Pages Documentation](../user/project/pages/index.md)
 
 ### 2.2. GitLab Issues
 
 1. [Markdown in GitLab](../user/markdown.md)
 1. [Issues and Merge Requests - Video](https://www.youtube.com/watch?v=raXvuwet78M)
-1. [Due Dates and Milestones for GitLab Issues](https://about.gitlab.com/2016/08/05/feature-highlight-set-dates-for-issues/)
-1. [How to Use GitLab Labels](https://about.gitlab.com/2016/08/17/using-gitlab-labels/)
-1. [Applying GitLab Labels Automatically](https://about.gitlab.com/2016/08/19/applying-gitlab-labels-automatically/)
+1. [Due Dates and Milestones for GitLab Issues](https://about.gitlab.com/blog/2016/08/05/feature-highlight-set-dates-for-issues/)
+1. [How to Use GitLab Labels](https://about.gitlab.com/blog/2016/08/17/using-gitlab-labels/)
+1. [Applying GitLab Labels Automatically](https://about.gitlab.com/blog/2016/08/19/applying-gitlab-labels-automatically/)
 1. [GitLab Issue Board - Product Page](https://about.gitlab.com/product/issueboard/)
-1. [An Overview of GitLab Issue Board](https://about.gitlab.com/2016/08/22/announcing-the-gitlab-issue-board/)
-1. [Designing GitLab Issue Board](https://about.gitlab.com/2016/08/31/designing-issue-boards/)
+1. [An Overview of GitLab Issue Board](https://about.gitlab.com/blog/2016/08/22/announcing-the-gitlab-issue-board/)
+1. [Designing GitLab Issue Board](https://about.gitlab.com/blog/2016/08/31/designing-issue-boards/)
 1. [From Idea to Production with GitLab - Video](https://www.youtube.com/watch?v=25pHyknRgEo&index=14&list=PLFGfElNsQthbQu_IWlNOxul0TbS_2JH-e)
 
 ### 2.3. Continuous Integration
 
 1. [Operating Systems, Servers, VMs, Containers and Unix - Video](https://www.youtube.com/watch?v=V61kL6IC-zY&index=8&list=PLFGfElNsQthbQu_IWlNOxul0TbS_2JH-e)
-1. [GitLab CI - Product Page](https://about.gitlab.com/gitlab-ci/)
-1. [Getting started with GitLab and GitLab CI](https://about.gitlab.com/2015/12/14/getting-started-with-gitlab-and-gitlab-ci/)
-1. [GitLab Container Registry](https://about.gitlab.com/2016/05/23/gitlab-container-registry/)
+1. [GitLab CI - Product Page](https://about.gitlab.com/product/continuous-integration/)
+1. [Getting started with GitLab and GitLab CI](https://about.gitlab.com/blog/2015/12/14/getting-started-with-gitlab-and-gitlab-ci/)
+1. [GitLab Container Registry](https://about.gitlab.com/blog/2016/05/23/gitlab-container-registry/)
 1. [GitLab and Docker - Video](https://www.youtube.com/watch?v=ugOrCcbdHko&index=12&list=PLFGfElNsQthbQu_IWlNOxul0TbS_2JH-e)
-1. [How we scale GitLab with built in Docker](https://about.gitlab.com/2016/06/21/how-we-scale-gitlab-by-having-docker-built-in/)
-1. [Continuous Integration, Delivery, and Deployment with GitLab](https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/)
-1. [Deployments and Environments](https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/)
-1. [Sequential, Parallel or Custom Pipelines](https://about.gitlab.com/2016/07/29/the-basics-of-gitlab-ci/)
-1. [Setting up GitLab Runner For Continuous Integration](https://about.gitlab.com/2016/03/01/gitlab-runner-with-docker/)
-1. [Setting up GitLab Runner on DigitalOcean](https://about.gitlab.com/2016/04/19/how-to-set-up-gitlab-runner-on-digitalocean/)
-1. [Setting up GitLab CI for iOS projects](https://about.gitlab.com/2016/03/10/setting-up-gitlab-ci-for-ios-projects/)
+1. [How we scale GitLab with built in Docker](https://about.gitlab.com/blog/2016/06/21/how-we-scale-gitlab-by-having-docker-built-in/)
+1. [Continuous Integration, Delivery, and Deployment with GitLab](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/)
+1. [Deployments and Environments](https://about.gitlab.com/blog/2016/08/26/ci-deployment-and-environments/)
+1. [Sequential, Parallel or Custom Pipelines](https://about.gitlab.com/blog/2016/07/29/the-basics-of-gitlab-ci/)
+1. [Setting up GitLab Runner For Continuous Integration](https://about.gitlab.com/blog/2016/03/01/gitlab-runner-with-docker/)
+1. [Setting up GitLab Runner on DigitalOcean](https://about.gitlab.com/blog/2016/04/19/how-to-set-up-gitlab-runner-on-digitalocean/)
+1. [Setting up GitLab CI for iOS projects](https://about.gitlab.com/blog/2016/03/10/setting-up-gitlab-ci-for-ios-projects/)
 1. [IBM: Continuous Delivery vs Continuous Deployment - Video](https://www.youtube.com/watch?v=igwFj8PPSnw)
 1. [Amazon: Transition to Continuous Delivery - Video](https://www.youtube.com/watch?v=esEFaY0FDKc)
-1. [TechBeacon: Doing continuous delivery? Focus first on reducing release cycle times](https://techbeacon.com/doing-continuous-delivery-focus-first-reducing-release-cycle-times)
+1. [TechBeacon: Doing continuous delivery? Focus first on reducing release cycle times](https://techbeacon.com/devops/doing-continuous-delivery-focus-first-reducing-release-cycle-times)
 1. See **[Integrations](#39-integrations)** for integrations with other CI services.
 
 ### 2.4. Workflow
 
 1. [GitLab Flow - Video](https://youtu.be/enMumwvLAug?list=PLFGfElNsQthZnwMUFi6rqkyUZkI00OxIV)
 1. [GitLab Flow vs Forking in GitLab - Video](https://www.youtube.com/watch?v=UGotqAUACZA)
-1. [GitLab Flow Overview](https://about.gitlab.com/2014/09/29/gitlab-flow/)
-1. [Always Start with an Issue](https://about.gitlab.com/2016/03/03/start-with-an-issue/)
+1. [GitLab Flow Overview](https://about.gitlab.com/blog/2014/09/29/gitlab-flow/)
+1. [Always Start with an Issue](https://about.gitlab.com/blog/2016/03/03/start-with-an-issue/)
 1. [GitLab Flow Documentation](../workflow/gitlab_flow.md)
 
 ### 2.5. GitLab Comparisons
 
-1. [GitLab Compared to Other Tools](https://about.gitlab.com/comparison/)
-1. [Comparing GitLab Terminology](https://about.gitlab.com/2016/01/27/comparing-terms-gitlab-github-bitbucket/)
+1. [GitLab Compared to Other Tools](https://about.gitlab.com/devops-tools/)
+1. [Comparing GitLab Terminology](https://about.gitlab.com/blog/2016/01/27/comparing-terms-gitlab-github-bitbucket/)
 1. [GitLab Compared to Atlassian (Recording 2016-03-03)](https://youtu.be/Nbzp1t45ERo)
-1. [GitLab Position FAQ](https://about.gitlab.com/handbook/positioning-faq)
-1. [Customer review of GitLab with points on why they prefer GitLab](https://www.enovate.co.uk/web-design-blog/2015/11/25/gitlab-review/)
+1. [GitLab Position FAQ](https://about.gitlab.com/handbook/positioning-faq/)
+1. [Customer review of GitLab with points on why they prefer GitLab](https://www.enovate.co.uk/blog/2015/11/25/gitlab-review)
 
 ## 3. GitLab Advanced
 
@@ -145,16 +145,16 @@ The GitLab University curriculum is composed of GitLab videos, screencasts, pres
 
 1. [Xebia Labs: Dev Ops Terminology](https://xebialabs.com/glossary/)
 1. [Xebia Labs: Periodic Table of DevOps Tools](https://xebialabs.com/periodic-table-of-devops-tools/)
-1. [Puppet Labs: State of Dev Ops 2016 - Book](https://puppet.com/resources/white-paper/2016-state-of-devops-report)
+1. [Puppet Labs: State of Dev Ops 2016 - Book](https://puppet.com/resources/whitepaper/2016-state-of-devops-report)
 
 ### 3.2. Installing GitLab with Omnibus
 
 1. [What is Omnibus - Video](https://www.youtube.com/watch?v=XTmpKudd-Oo)
 1. [How to Install GitLab with Omnibus - Video](https://www.youtube.com/watch?v=Q69YaOjqNhg)
-1. [Installing GitLab - Online Course](https://courses.platzi.com/classes/git-gitlab/concepto/part-1/part-3/material/)
+1. [Installing GitLab - Online Course](https://courses.platzi.com/classes/57-git-gitlab/2476-part-0/)
 1. [Using a Non-Packaged PostgreSQL Database](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md#using-a-non-packaged-postgresql-database-management-server)
-1. [Installing GitLab on Microsoft Azure](https://about.gitlab.com/2016/07/13/how-to-setup-a-gitlab-instance-on-microsoft-azure/)
-1. [Installing GitLab on Digital Ocean](https://about.gitlab.com/2016/04/27/getting-started-with-gitlab-and-digitalocean/)
+1. [Installing GitLab on Microsoft Azure](https://about.gitlab.com/blog/2016/07/13/how-to-setup-a-gitlab-instance-on-microsoft-azure/)
+1. [Installing GitLab on Digital Ocean](https://about.gitlab.com/blog/2016/04/27/getting-started-with-gitlab-and-digitalocean/)
 
 ### 3.3. Permissions
 
@@ -176,11 +176,11 @@ The GitLab University curriculum is composed of GitLab videos, screencasts, pres
 
 1. [Scalability and High Availability - Video](https://www.youtube.com/watch?v=cXRMJJb6sp4&list=PLFGfElNsQthbQu_IWlNOxul0TbS_2JH-e&index=2)
 1. [High Availability - Video](https://www.youtube.com/watch?v=36KS808u6bE&index=15&list=PLFGfElNsQthbQu_IWlNOxul0TbS_2JH-e)
-1. [High Availability Documentation](https://about.gitlab.com/high-availability/)
+1. [High Availability Documentation](https://about.gitlab.com/solutions/high-availability/)
 
 ### 3.8 Cycle Analytics
 
-1. [GitLab Cycle Analytics Overview](https://about.gitlab.com/2016/09/21/cycle-analytics-feature-highlight/)
+1. [GitLab Cycle Analytics Overview](https://about.gitlab.com/blog/2016/09/21/cycle-analytics-feature-highlight/)
 1. [GitLab Cycle Analytics - Product Page](https://about.gitlab.com/product/cycle-analytics/)
 
 ### 3.9. Integrations
@@ -190,8 +190,8 @@ The GitLab University curriculum is composed of GitLab videos, screencasts, pres
 1. [How to Integrate Jenkins with GitLab](../integration/jenkins.md)
 1. [How to Integrate Bamboo with GitLab](../user/project/integrations/bamboo.md)
 1. [How to Integrate Slack with GitLab](../user/project/integrations/slack.md)
-1. [How to Integrate Convox with GitLab](https://about.gitlab.com/2016/06/09/continuous-delivery-with-gitlab-and-convox/)
-1. [Getting Started with GitLab and Shippable CI](https://about.gitlab.com/2016/05/05/getting-started-gitlab-and-shippable/)
+1. [How to Integrate Convox with GitLab](https://about.gitlab.com/blog/2016/06/09/continuous-delivery-with-gitlab-and-convox/)
+1. [Getting Started with GitLab and Shippable CI](https://about.gitlab.com/blog/2016/05/05/getting-started-gitlab-and-shippable/)
 
 ## 4. External Articles
 
@@ -205,7 +205,7 @@ NOTE: **Note:**
 Some content can only be accessed by GitLab team members.
 
 1. [Support Path](support/README.md)
-1. [Sales Path](https://about.gitlab.com/handbook/sales-onboarding/)
+1. [Sales Path](https://about.gitlab.com/handbook/sales/onboarding/)
 1. [User Training](training/user_training.md)
 1. [GitLab Flow Training](training/gitlab_flow.md)
 1. [Training Topics](training/index.md)
diff --git a/doc/university/bookclub/index.md b/doc/university/bookclub/index.md
index 330078e979f..c6dad663c0e 100644
--- a/doc/university/bookclub/index.md
+++ b/doc/university/bookclub/index.md
@@ -15,10 +15,10 @@ See the [book list](booklist.md) for additional recommendations.
 1. **Remote: Office not required**
 
    David Heinemeier Hansson and Jason Fried, 2013
-   ([amazon](http://www.amazon.co.uk/Remote-Required-David-Heinemeier-Hansson/dp/0091954673))
+   ([amazon](https://www.amazon.co.uk/Remote-Required-David-Heinemeier-Hansson/dp/0091954673))
 
 1. **The Year Without Pants**
 
-   Scott Berkun, 2013 ([ScottBerkun.com](http://scottberkun.com/yearwithoutpants/))
+   Scott Berkun, 2013 ([ScottBerkun.com](https://scottberkun.com/yearwithoutpants/))
 
 Any other books you'd like to suggest? Edit this page and add them to the queue.
diff --git a/doc/university/glossary/README.md b/doc/university/glossary/README.md
index 21e2da3e47c..297b841b283 100644
--- a/doc/university/glossary/README.md
+++ b/doc/university/glossary/README.md
@@ -6,6 +6,6 @@ comments: false
 
 This page has been removed after an effort to ensure that all applicable GitLab-specific
 terms are available in context on the relevant [GitLab Documentation](https://docs.gitlab.com/)
-or [about.gitlab.com](https://about.gitlab.com/) pages.
+or <https://about.gitlab.com/> pages.
 
 If you are looking for a definition of a specific term, please search these sites.
diff --git a/doc/university/process/README.md b/doc/university/process/README.md
index c3e023da655..a9835ce879c 100644
--- a/doc/university/process/README.md
+++ b/doc/university/process/README.md
@@ -19,10 +19,10 @@ please submit a merge request to add an upcoming class, assign to
 1. Don't make materials that are needlessly specific to one group of people, try
    to keep the wording broad and inclusive (don't make things for only GitLab Inc.
    people, only interns, only customers, etc.).
-1. To allow people to contribute all content should be in git.
+1. To allow people to contribute all content should be in Git.
 1. The content can go in a subdirectory under `/doc/university/`.
-1. To make, view or modify the slides of the classes use [Deckset](http://www.decksetapp.com/)
-   or [RevealJS](http://lab.hakim.se/reveal-js/). Do not use Powerpoint or Google
+1. To make, view or modify the slides of the classes use [Deckset](https://www.deckset.com)
+   or [RevealJS](https://revealjs.com/#/). Do not use Powerpoint or Google
    Slides since this prevents everyone from contributing.
 1. Please upload any video recordings to our Youtube channel. We prefer them to
    be public, if needed they can be unlisted but if so they should be linked from
diff --git a/doc/university/support/README.md b/doc/university/support/README.md
index 76cc258355f..1c77fbeb8d6 100644
--- a/doc/university/support/README.md
+++ b/doc/university/support/README.md
@@ -70,7 +70,7 @@ Sometimes we need to upgrade customers from old versions of GitLab to latest, so
   - [Perform the MySQL to PostgreSQL migration to convert your backup](../../update/mysql_to_postgresql.md)
   - [Upgrade to Omnibus 7.14](https://docs.gitlab.com/omnibus/update/README.html#upgrading-from-a-non-omnibus-installation-to-an-omnibus-installation)
   - [Restore backup using our Restore rake task](../../raketasks/backup_restore.md#restore)
-  - [Upgrade to latest EE](https://about.gitlab.com/downloads-ee)
+  - [Upgrade to latest EE](https://about.gitlab.com/update/)
     - (GitLab inc. only) Acquire and apply a license for the Enterprise Edition product, ask in #support
 - Perform a downgrade from [EE to CE](../../downgrade_ee_to_ce/README.md)
 
@@ -147,12 +147,12 @@ Some tickets need specific knowledge or a deep understanding of a particular com
 
 - Read about [Escalation](https://about.gitlab.com/handbook/support/workflows/issue_escalations.html)
 - Find the macros in Zendesk for ticket escalations
-- Take a look at the [GitLab.com Team page](https://about.gitlab.com/team/) to find the resident experts in their fields
+- Take a look at the [GitLab.com Team page](https://about.gitlab.com/company/team/) to find the resident experts in their fields
 
 ### Learn about raising issues and fielding feature proposals
 
 - Understand what's in the pipeline and proposed features at GitLab: [Direction Page](https://about.gitlab.com/direction/)
-- Practice searching issues and filtering using [labels](https://gitlab.com/gitlab-org/gitlab-foss/labels) to find existing feature proposals and bugs
+- Practice searching issues and filtering using [labels](https://gitlab.com/gitlab-org/gitlab/-/labels) to find existing feature proposals and bugs
 - If raising a new issue always provide a relevant label and a link to the relevant ticket in Zendesk
 - Add [customer labels](https://gitlab.com/gitlab-org/gitlab-foss/issues?label_name%5B%5D=customer) for those issues relevant to our subscribers
 - Take a look at the [existing issue templates](https://gitlab.com/gitlab-org/gitlab/blob/master/CONTRIBUTING.md#issue-tracker) to see what is expected
diff --git a/doc/university/training/end-user/README.md b/doc/university/training/end-user/README.md
index 0ea51a95445..4c86aedff8f 100644
--- a/doc/university/training/end-user/README.md
+++ b/doc/university/training/end-user/README.md
@@ -48,7 +48,7 @@ Workshop Time!
 ### Setup
 
 - Windows: Install 'Git for Windows'
-  - <https://git-for-windows.github.io>
+  - <https://gitforwindows.org>
 - Mac: Type `git` in the Terminal application.
   - If it's not installed, it will prompt you to install it.
 - Linux
@@ -109,11 +109,11 @@ cd ~/workspace
 - GitLab is an application to code, test and deploy.
 - Provides repository management with access controls, code reviews,
   issue tracking, Merge Requests, and other features.
-- The hosted version of GitLab is gitlab.com
+- The hosted version of GitLab is <https://gitlab.com>
 
 ### New Project
 
-- Sign in into your gitlab.com account
+- Sign in into your <https://gitlab.com> account
 - Create a project
 - Choose to import from 'Any Repo by URL' and use <https://gitlab.com/gitlab-org/training-examples.git>
 - On your machine clone the `training-examples` project
@@ -126,7 +126,7 @@ cd ~/workspace
 1. Stage the file
 1. Commit
 1. Push the commit to the remote
-1. View the git log
+1. View the Git log
 
 ```shell
 # Edit `edit_this_file.rb`
@@ -253,7 +253,7 @@ git push origin conflicts_branch -f
 - When to use `git merge` and when to use `git rebase`
 - Rebase when updating your branch with master
 - Merge when bringing changes from feature to master
-- Reference: <https://www.atlassian.com/git/tutorials/merging-vs-rebasing/>
+- Reference: <https://www.atlassian.com/git/tutorials/merging-vs-rebasing>
 
 ## Revert and Unstage
 
@@ -271,7 +271,7 @@ This will unstage the file but maintain the modifications. To revert the file ba
 git checkout -- <file>
 ```
 
-To remove a file from disk and repo use 'git rm' and to rm a dir use the '-r' flag:
+To remove a file from disk and repo use `git rm` and to remove a directory use the `-r` flag:
 
 ```sh
 git rm '*.txt'
@@ -338,7 +338,7 @@ git pull origin master
 git push origin master
 ```
 
-### git revert vs git reset
+### `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
diff --git a/doc/university/training/topics/env_setup.md b/doc/university/training/topics/env_setup.md
index 92d2613c5d2..f65b4f68868 100644
--- a/doc/university/training/topics/env_setup.md
+++ b/doc/university/training/topics/env_setup.md
@@ -7,7 +7,7 @@ comments: false
 ## Install
 
 - **Windows**
-  - Install 'Git for Windows' from <https://git-for-windows.github.io>
+  - Install 'Git for Windows' from <https://gitforwindows.org>
 
 - **Mac**
   - Type '`git`' in the Terminal application.
diff --git a/doc/university/training/topics/getting_started.md b/doc/university/training/topics/getting_started.md
index 3fadb58e804..bb197f3f1ed 100644
--- a/doc/university/training/topics/getting_started.md
+++ b/doc/university/training/topics/getting_started.md
@@ -65,7 +65,7 @@ Modified files that have been marked to go in the next commit.
 1. Stage the file
 1. Commit
 1. Push the commit to the remote
-1. View the git log
+1. View the Git log
 
 ```sh
 # Edit `edit_this_file.rb`
@@ -79,5 +79,5 @@ git log
 
 ## Note
 
-- git fetch vs pull
-- Pull is git fetch + git merge
+- `git fetch` vs `git pull`
+- Pull is `git fetch` + `git merge`
diff --git a/doc/university/training/topics/merge_conflicts.md b/doc/university/training/topics/merge_conflicts.md
index 97bb038f405..a01b3dbf3e0 100644
--- a/doc/university/training/topics/merge_conflicts.md
+++ b/doc/university/training/topics/merge_conflicts.md
@@ -60,7 +60,7 @@ git push origin conflicts_branch -f
 
 ## Note
 
-- When to use 'git merge' and when to use 'git rebase'
+- When to use `git merge` and when to use `git rebase`
 - Rebase when updating your branch with master
 - Merge when bringing changes from feature to master
-- Reference: <https://www.atlassian.com/git/tutorials/merging-vs-rebasing/>
+- Reference: <https://www.atlassian.com/git/tutorials/merging-vs-rebasing>
diff --git a/doc/university/training/topics/rollback_commits.md b/doc/university/training/topics/rollback_commits.md
index c17e8d59737..333b2f23a1b 100644
--- a/doc/university/training/topics/rollback_commits.md
+++ b/doc/university/training/topics/rollback_commits.md
@@ -62,7 +62,7 @@ git push origin master
 
 ## Note
 
-- git revert vs git reset
+- `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
 
diff --git a/doc/university/training/topics/stash.md b/doc/university/training/topics/stash.md
index d3e63db0c6a..c582240d0f7 100644
--- a/doc/university/training/topics/stash.md
+++ b/doc/university/training/topics/stash.md
@@ -4,7 +4,7 @@ comments: false
 
 # Git Stash
 
-We use git stash to store our changes when they are not ready to be committed
+We use `git stash` to store our changes when they are not ready to be committed
 and we need to change to a different branch.
 
 - Stash:
diff --git a/doc/university/training/topics/unstage.md b/doc/university/training/topics/unstage.md
index d7482bf2bd5..9a9d42221a4 100644
--- a/doc/university/training/topics/unstage.md
+++ b/doc/university/training/topics/unstage.md
@@ -16,7 +16,7 @@ comments: false
   git checkout -- <file>
   ```
 
-- To remove a file from disk and repo use 'git rm' and to rm a dir use the '-r' flag:
+- To remove a file from disk and repo use `git rm` and to remove a directory use the `-r` flag:
 
   ```sh
   git rm '*.txt'
diff --git a/doc/university/training/user_training.md b/doc/university/training/user_training.md
index 231039b0be8..08b7635f9ce 100644
--- a/doc/university/training/user_training.md
+++ b/doc/university/training/user_training.md
@@ -39,7 +39,7 @@ Use the tools at your disposal when you get stuck.
 
 - Windows: Install 'Git for Windows'
 
-> <https://git-for-windows.github.io>
+> <https://gitforwindows.org>
 
 - Mac: Type '`git`' in the Terminal application.
 
@@ -140,7 +140,7 @@ Modified files that have been marked to go in the next commit.
 1. Stage the file.
 1. Commit.
 1. Push the commit to the remote.
-1. View the git log.
+1. View the Git log.
 
 ## Commands (committing)
 
@@ -242,7 +242,7 @@ See GitLab merge requests for examples: <https://gitlab.com/gitlab-org/gitlab-fo
 1. Create an annotated tag.
 1. Push the tags to the remote repository.
 
-Additional resources: <http://git-scm.com/book/en/Git-Basics-Tagging>.
+Additional resources: <https://git-scm.com/book/en/v2/Git-Basics-Tagging>.
 
 ## Commands (tags)
 
diff --git a/doc/update/mysql_to_postgresql.md b/doc/update/mysql_to_postgresql.md
index b202dd7e9d2..7f6162cca88 100644
--- a/doc/update/mysql_to_postgresql.md
+++ b/doc/update/mysql_to_postgresql.md
@@ -196,7 +196,7 @@ After the database is created, go on with the following steps:
    sudo -u git -H chmod o-rwx config/database.yml
    ```
 
-1. Install Gems related to Postgresql
+1. Install Gems related to PostgreSQL
 
    ```bash
    sudo -u git -H rm .bundle/config
diff --git a/doc/update/patch_versions.md b/doc/update/patch_versions.md
index a555f1c82bf..7314e34666d 100644
--- a/doc/update/patch_versions.md
+++ b/doc/update/patch_versions.md
@@ -72,7 +72,7 @@ cd /home/git/gitlab
 sudo -u git -H bundle exec rake "gitlab:workhorse:install[/home/git/gitlab-workhorse]" RAILS_ENV=production
 ```
 
-### 5. Update gitaly to the corresponding version
+### 5. Update Gitaly to the corresponding version
 
 ```bash
 cd /home/git/gitlab
@@ -87,7 +87,7 @@ cd /home/git/gitlab-shell
 
 sudo -u git -H git fetch --all --tags
 sudo -u git -H git checkout v$(</home/git/gitlab/GITLAB_SHELL_VERSION) -b v$(</home/git/gitlab/GITLAB_SHELL_VERSION)
-sudo -u git -H sh -c 'if [ -x bin/compile ]; then bin/compile; fi'
+sudo -u git -H make build
 ```
 
 ### 7. Update GitLab Pages to the corresponding version (skip if not using pages)
@@ -102,7 +102,7 @@ sudo -u git -H make
 
 ### 8. Install/Update `gitlab-elasticsearch-indexer` (optional) **(STARTER ONLY)**
 
-If you're interested in using GitLab's new [elasticsearch repository indexer](../integration/elasticsearch.md#elasticsearch-repository-indexer-beta) (currently in beta)
+If you're interested in using GitLab's new [Elasticsearch repository indexer](../integration/elasticsearch.md#elasticsearch-repository-indexer-beta) (currently in beta)
 please follow the instructions on the document linked above and enable the
 indexer usage in the GitLab admin settings.
 
diff --git a/doc/update/upgrading_from_ce_to_ee.md b/doc/update/upgrading_from_ce_to_ee.md
index ea9235c6d2a..b553b4aa405 100644
--- a/doc/update/upgrading_from_ce_to_ee.md
+++ b/doc/update/upgrading_from_ce_to_ee.md
@@ -74,8 +74,8 @@ sudo -u git -H bundle exec rake assets:clean assets:precompile cache:clear RAILS
 
 ### 4. Install `gitlab-elasticsearch-indexer` (optional) **(STARTER ONLY)**
 
-If you're interested in using GitLab's new [elasticsearch repository
-indexer](../integration/elasticsearch.md) (currently in beta) please follow the instructions on the
+If you're interested in using GitLab's new [Elasticsearch repository indexer](../integration/elasticsearch.md)
+(currently in beta) please follow the instructions on the
 document linked above and enable the indexer usage in the GitLab admin settings.
 
 ### 5. Start application
diff --git a/doc/update/upgrading_from_source.md b/doc/update/upgrading_from_source.md
index d0265781777..662701dbb56 100644
--- a/doc/update/upgrading_from_source.md
+++ b/doc/update/upgrading_from_source.md
@@ -193,7 +193,7 @@ cd /home/git/gitlab-shell
 
 sudo -u git -H git fetch --all --tags --prune
 sudo -u git -H git checkout v$(</home/git/gitlab/GITLAB_SHELL_VERSION)
-sudo -u git -H bin/compile
+sudo -u git -H make build
 ```
 
 ### 9. Update GitLab Workhorse
@@ -253,7 +253,7 @@ cd /home/git/gitlab
 git diff origin/PREVIOUS_BRANCH:config/gitlab.yml.example origin/BRANCH:config/gitlab.yml.example
 ```
 
-#### Nginx configuration
+#### NGINX configuration
 
 Ensure you're still up-to-date with the latest NGINX configuration changes:
 
@@ -268,13 +268,13 @@ git diff origin/PREVIOUS_BRANCH:lib/support/nginx/gitlab origin/BRANCH:lib/suppo
 ```
 
 If you are using Strict-Transport-Security in your installation to continue
-using it you must enable it in your Nginx configuration as GitLab application no
+using it you must enable it in your NGINX configuration as GitLab application no
 longer handles setting it.
 
 If you are using Apache instead of NGINX please see the updated [Apache templates].
 Also note that because Apache does not support upstreams behind Unix sockets you
 will need to let GitLab Workhorse listen on a TCP port. You can do this
-via [`/etc/default/gitlab`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/support/init.d/gitlab.default.example#L38).
+via [`/etc/default/gitlab`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/support/init.d/gitlab.default.example#L38).
 
 #### SMTP configuration
 
@@ -400,7 +400,7 @@ sudo -u git -H bundle exec rake gitlab:backup:restore RAILS_ENV=production
 
 If you have more than one backup `*.tar` file(s) please add `BACKUP=timestamp_of_backup` to the command above.
 
-[yaml]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/config/gitlab.yml.example
-[gl-example]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/support/init.d/gitlab.default.example
-[smtp_settings.rb.sample]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/config/initializers/smtp_settings.rb.sample#L13
+[yaml]: https://gitlab.com/gitlab-org/gitlab/blob/master/config/gitlab.yml.example
+[gl-example]: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/support/init.d/gitlab.default.example
+[smtp_settings.rb.sample]: https://gitlab.com/gitlab-org/gitlab/blob/master/config/initializers/smtp_settings.rb.sample#L13
 [Apache templates]: https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/web-server/apache
diff --git a/doc/user/admin_area/appearance.md b/doc/user/admin_area/appearance.md
new file mode 100644
index 00000000000..1fea6ab8b02
--- /dev/null
+++ b/doc/user/admin_area/appearance.md
@@ -0,0 +1,113 @@
+---
+type: howto
+disqus_identifier: 'https://docs.gitlab.com/ee/customization/branded_login_page.html'
+---
+
+# GitLab Appearance **(CORE ONLY)**
+
+There are several options for customizing the appearance of a self hosted instance
+of GitLab. These settings are accessed from the **Admin Area** in the **Appearance**
+section.
+
+## Navigation bar
+
+By default, the navigation bar has the GitLab logo, but this can be customized with
+any image desired. It is optimized for images 28px high (any width), but any image can be
+used (less than 1MB) and it will automatically be resized.
+
+![navbar header logo screenshot](img/appearance_header_logo_v12_3.png)
+
+Once you select and upload an image, click **Update appearance settings** at the bottom
+of the page to activate it in the GitLab instance.
+
+NOTE: **Note:**
+GitLab pipeline emails will also display the custom logo.
+
+## Favicon
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/14497) in GitLab 11.0.
+
+By default, the favicon (used by the browser as the tab icon, as well as the CI status icon)
+uses the GitLab logo, but this can be customized with any icon desired. It must be a
+32x32 `.png` or `.ico` image.
+
+![favicon screenshot](img/appearance_favicon_v12_3.png)
+
+After you select and upload an icon, click **Update appearance settings** at the bottom
+of the page to activate it in the GitLab instance.
+
+## System header and footer messages
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/5023) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.7.
+> - [Added](https://gitlab.com/gitlab-org/gitlab-foss/issues/55057) to [GitLab Core](https://about.gitlab.com/pricing/) in 11.9.
+
+You can add a small header message, a small footer message, or both, to the interface
+of your GitLab instance. These messages will appear on all projects and pages of the
+instance, including the sign in / sign up page. The default color is white text on
+an orange background, but this can be customized by clicking on **Customize colors**.
+
+Limited [markdown](../markdown.md) is supported, such as bold, italics, and links, for
+example. Other markdown features, including lists, images and quotes, are not supported,
+as the header and footer messages can only be a single line.
+
+![header and footer screenshot](img/appearance_header_footer_v12_3.png)
+
+If desired, you can select **Enable header and footer in emails** to have the text of
+the header and footer added to all emails sent by the GitLab instance.
+
+After you add a message, click **Update appearance settings** at the bottom of the page
+to activate it in the GitLab instance.
+
+## Sign in / Sign up pages
+
+You can replace the default message on the sign in / sign up page with your own message
+and logo. You can make full use of [markdown](../markdown.md) in the description:
+
+![sign in message screenshot](img/appearance_sign_in_v12_3.png)
+
+The optimal size for the logo is 640x360px, but any image can be used (below 1MB)
+and it will be resized automatically. The logo image will appear between the title and
+the description, on the left of the sign-up page.
+
+![sign in message preview screenshot](img/appearance_sign_in_preview_v12_3.png)
+
+After you add a message, click **Update appearance settings** at the bottom of the page
+to activate it in the GitLab instance. You can also click on the **Sign-in page** button,
+to review the saved appearance settings:
+
+NOTE: **Note:**
+You can add also add a [customized help message](settings/help_page.md) below the sign in message.
+
+## New project pages
+
+You can add a new project guidelines message to the **New project page** within GitLab.
+You can make full use of [markdown](../markdown.md) in the description:
+
+![new project message screenshot](img/appearance_new_project_v12_3.png)
+
+The message will be displayed below the **New Project** message, on the left side
+of the **New project page**.
+
+After you add a message, click **Update appearance settings** at the bottom of the page
+to activate it in the GitLab instance. You can also click on the **New project page**
+button, which will bring you to the new project page so you can review the change.
+
+![new project message preview screenshot](img/appearance_new_project_preview_v12_3.png)
+
+## Libravatar
+
+[Libravatar](https://www.libravatar.org) is supported by GitLab for avatar images, but you must
+[manually enable Libravatar support on the GitLab instance](../../administration/libravatar.md)
+in order to use the service.
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+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. -->
diff --git a/doc/user/admin_area/geo_nodes.md b/doc/user/admin_area/geo_nodes.md
index 817b44bfdc8..bbdb9cb07a6 100644
--- a/doc/user/admin_area/geo_nodes.md
+++ b/doc/user/admin_area/geo_nodes.md
@@ -16,7 +16,7 @@ All Geo nodes have the following settings:
 | Setting | Description |
 | --------| ----------- |
 | Primary | This marks a Geo Node as **primary** node. There can be only one **primary** node; make sure that you first add the **primary** node and then all the others. |
-| Name    | The unique identifier for the Geo node. Must match the setting `gitlab_rails[geo_node_name]` in `/etc/gitlab/gitlab.rb`. The setting defaults to `external_url` with a trailing slash. |
+| Name    | The unique identifier for the Geo node. Must match the setting `gitlab_rails['geo_node_name']` in `/etc/gitlab/gitlab.rb`. The setting defaults to `external_url` with a trailing slash. |
 | URL     | The instance's user-facing URL. |
 
 The node you're reading from is indicated with a green `Current node` label, and
@@ -71,7 +71,7 @@ terminated at the load balancer.
 
 In GitLab 11.11, **secondary** nodes can use identical external URLs as long as
 a unique `name` is set for each Geo node. The `gitlab.rb` setting
-`gitlab_rails[geo_node_name]` must:
+`gitlab_rails['geo_node_name']` must:
 
 - Be set for each GitLab instance that runs `unicorn`, `sidekiq`, or `geo_logcursor`.
 - Match a Geo node name.
diff --git a/doc/user/admin_area/img/appearance_favicon_v12_3.png b/doc/user/admin_area/img/appearance_favicon_v12_3.png
new file mode 100644
index 00000000000..b464c9087e9
--- /dev/null
+++ b/doc/user/admin_area/img/appearance_favicon_v12_3.png
diff --git a/doc/user/admin_area/img/appearance_header_footer_v12_3.png b/doc/user/admin_area/img/appearance_header_footer_v12_3.png
new file mode 100644
index 00000000000..aed0ff820fb
--- /dev/null
+++ b/doc/user/admin_area/img/appearance_header_footer_v12_3.png
diff --git a/doc/user/admin_area/img/appearance_header_logo_v12_3.png b/doc/user/admin_area/img/appearance_header_logo_v12_3.png
new file mode 100644
index 00000000000..0da56d196c0
--- /dev/null
+++ b/doc/user/admin_area/img/appearance_header_logo_v12_3.png
diff --git a/doc/user/admin_area/img/appearance_new_project_preview_v12_3.png b/doc/user/admin_area/img/appearance_new_project_preview_v12_3.png
new file mode 100644
index 00000000000..621e62e787b
--- /dev/null
+++ b/doc/user/admin_area/img/appearance_new_project_preview_v12_3.png
diff --git a/doc/user/admin_area/img/appearance_new_project_v12_3.png b/doc/user/admin_area/img/appearance_new_project_v12_3.png
new file mode 100644
index 00000000000..ae1a8ca0f85
--- /dev/null
+++ b/doc/user/admin_area/img/appearance_new_project_v12_3.png
diff --git a/doc/user/admin_area/img/appearance_sign_in_preview_v12_3.png b/doc/user/admin_area/img/appearance_sign_in_preview_v12_3.png
new file mode 100644
index 00000000000..64bd62c2d32
--- /dev/null
+++ b/doc/user/admin_area/img/appearance_sign_in_preview_v12_3.png
diff --git a/doc/user/admin_area/img/appearance_sign_in_v12_3.png b/doc/user/admin_area/img/appearance_sign_in_v12_3.png
new file mode 100644
index 00000000000..6abe10f8bea
--- /dev/null
+++ b/doc/user/admin_area/img/appearance_sign_in_v12_3.png
diff --git a/doc/user/admin_area/index.md b/doc/user/admin_area/index.md
index 9bc0f64b68d..c75a8bcac79 100644
--- a/doc/user/admin_area/index.md
+++ b/doc/user/admin_area/index.md
@@ -27,12 +27,12 @@ The Admin Area is made up of the following sections:
 | Applications                  | Create system [OAuth applications](../../integration/oauth_provider.md) for integrations with other services.                                                                                                                                                                            |
 | Abuse Reports                 | Manage [abuse reports](abuse_reports.md) submitted by your users.                                                                                                                                                                                                                        |
 | License **(STARTER ONLY)**    | Upload, display, and remove [licenses](license.md).                                                                                                                                                                                                                                      |
-| Push Rules **(STARTER)**      | Configure pre-defined git [push rules](../../push_rules/push_rules.md) for projects.                                                                                                                                                                                                     |
+| Push Rules **(STARTER)**      | Configure pre-defined Git [push rules](../../push_rules/push_rules.md) for projects.                                                                                                                                                                                                     |
 | Geo **(PREMIUM ONLY)**        | Configure and maintain [Geo nodes](geo_nodes.md).                                                                                                                                                                                                                                        |
 | Deploy Keys                   | Create instance-wide [SSH deploy keys](../../ssh/README.md#deploy-keys).                                                                                                                                                                                                                 |
 | Service Templates             | Create [service templates](../project/integrations/services_templates.md) for projects.                                                                                                                                                                                                  |
 | Labels                        | Create and maintain [labels](labels.md) for your GitLab instance.                                                                                                                                                                                                                        |
-| Appearance                    | Customize [GitLab's appearance](../../customization/index.md).                                                                                                                                                                                                                           |
+| Appearance                    | Customize [GitLab's appearance](appearance.md).                                                                                                                                                                                                                           |
 | Settings                      | Modify the [settings](settings/index.md) for your GitLab instance.                                                                                                                                                                                                                       |
 
 ## Admin Dashboard
@@ -105,8 +105,16 @@ You can administer all users in the GitLab instance from the Admin Area's Users
 
 To access the Users page, go to **Admin Area > Overview > Users**.
 
-Click the **Active**, **Admins**, **2FA Enabled**, or **2FA Disabled**, **External**, or
-**Without projects** tab to list only users of that criteria.
+To list users matching a specific criteria, click on one of the following tabs on the **Users** page:
+
+- **Active**
+- **Admins**
+- **2FA Enabled**
+- **2FA Disabled**
+- **External**
+- **Blocked**
+- **Deactivated**
+- **Without projects**
 
 For each user, their username, email address, are listed, also the date their account was
 created and the date of last activity. To edit a user, click the **Edit** button in that user's
diff --git a/doc/user/admin_area/monitoring/health_check.md b/doc/user/admin_area/monitoring/health_check.md
index f5e812cad1b..6439607de33 100644
--- a/doc/user/admin_area/monitoring/health_check.md
+++ b/doc/user/admin_area/monitoring/health_check.md
@@ -59,7 +59,7 @@ GitLab OK
 
 ## Readiness
 
-The readiness probe checks whether the Gitlab instance is ready to use. It checks the dependent services (Database, Redis, Gitaly etc.) and gives a status for each.
+The readiness probe checks whether the GitLab instance is ready to use. It checks the dependent services (Database, Redis, Gitaly etc.) and gives a status for each.
 
 ```text
 GET /-/readiness
@@ -102,6 +102,9 @@ Example response:
 
 ## Liveness
 
+DANGER: **Warning:**
+In Gitlab [12.4](https://about.gitlab.com/upcoming-releases/) the response body of the Liveness check will change to match the example below.
+
 The liveness probe checks whether the application server is alive. Unlike the [`health`](#health) check, this check hits the database.
 
 ```text
@@ -116,28 +119,11 @@ curl 'https://gitlab.example.com/-/liveness'
 
 Example response:
 
-On success, the endpoint will return a valid successful HTTP status code, and a response like below.
+On success, the endpoint will return a `200` HTTP status code, and a response like below.
 
 ```json
 {
-   "db_check":{
-      "status":"ok"
-   },
-   "redis_check":{
-      "status":"ok"
-   },
-   "cache_check":{
-      "status":"ok"
-   },
-   "queues_check":{
-      "status":"ok"
-   },
-   "shared_state_check":{
-      "status":"ok"
-   },
-   "gitaly_check":{
-      "status":"ok"
-   }
+   "status": "ok"
 }
 ```
 
diff --git a/doc/user/admin_area/settings/account_and_limit_settings.md b/doc/user/admin_area/settings/account_and_limit_settings.md
index cdbc6346f3f..a1beee404eb 100644
--- a/doc/user/admin_area/settings/account_and_limit_settings.md
+++ b/doc/user/admin_area/settings/account_and_limit_settings.md
@@ -17,7 +17,7 @@ details.
 
 ## Repository size limit **(STARTER)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/740) in [GitLab Enterprise Edition 8.12](https://about.gitlab.com/2016/09/22/gitlab-8-12-released/#limit-project-size-ee).
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/740) in [GitLab Enterprise Edition 8.12](https://about.gitlab.com/blog/2016/09/22/gitlab-8-12-released/#limit-project-size-ee).
 > Available in [GitLab Starter](https://about.gitlab.com/pricing/).
 
 Repositories within your GitLab instance can grow quickly, especially if you are
diff --git a/doc/user/admin_area/settings/continuous_integration.md b/doc/user/admin_area/settings/continuous_integration.md
index 6ba027dc24a..c60b3323105 100644
--- a/doc/user/admin_area/settings/continuous_integration.md
+++ b/doc/user/admin_area/settings/continuous_integration.md
@@ -29,14 +29,38 @@ If you want to disable it for a specific project, you can do so in
 ## Maximum artifacts size **(CORE ONLY)**
 
 The maximum size of the [job artifacts](../../../administration/job_artifacts.md)
-can be set in the Admin area of your GitLab instance. The value is in *MB* and
-the default is 100MB per job; on GitLab.com it's [set to 1G](../../gitlab_com/index.md#gitlab-cicd).
+can be set at:
 
-To change it:
+- The instance level.
+- [From GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/issues/21688), the project and group level.
 
-1. Go to **Admin area > Settings > Continuous Integration and Deployment**.
-1. Change the value of maximum artifacts size (in MB).
-1. Hit **Save changes** for the changes to take effect.
+The value is:
+
+- In *MB* and the default is 100MB per job.
+- [Set to 1G](../../gitlab_com/index.md#gitlab-cicd) on GitLab.com.
+
+To change it at the:
+
+- Instance level:
+
+   1. Go to **Admin area > Settings > Continuous Integration and Deployment**.
+   1. Change the value of maximum artifacts size (in MB).
+   1. Hit **Save changes** for the changes to take effect.
+
+- [Group level](../../group/index.md#group-settings) (this will override the instance setting):
+
+  1. Go to the group's **Settings > CI / CD > General Pipelines**.
+  1. Change the value of **maximum artifacts size (in MB)**.
+  1. Press **Save changes** for the changes to take effect.
+
+- [Project level](../../project/pipelines/settings.md) (this will override the instance and group settings):
+
+  1. Go to the project's **Settings > CI / CD > General Pipelines**.
+  1. Change the value of **maximum artifacts size (in MB)**.
+  1. Press **Save changes** for the changes to take effect.
+
+NOTE: **Note**
+The setting at all levels is only available to GitLab administrators.
 
 ## Default artifacts expiration **(CORE ONLY)**
 
diff --git a/doc/user/admin_area/settings/help_page.md b/doc/user/admin_area/settings/help_page.md
new file mode 100644
index 00000000000..a2c99f94d8b
--- /dev/null
+++ b/doc/user/admin_area/settings/help_page.md
@@ -0,0 +1,49 @@
+---
+type: howto
+---
+
+# Customizing the 'Help' and login page messages
+
+In large organizations, it is useful to have information about who to contact or where
+to go for help. You can customize and display this information on the GitLab server's
+`/help` page and on the GitLab login page.
+
+## Adding a help message to the help page
+
+You can add a help message, which will be shown on the GitLab `/help` page (e.g.,
+<https://gitlab.com/help>) in a new section at the top of the `/help` page:
+
+1. Navigate to **Admin area > Settings > Preferences**, then expand **Help page**.
+1. Under **Help page text**, fill in the information you wish to display on `/help`.
+
+   ![help page help message](img/help_page_help_page_text_v12_3.png)
+
+1. Save your changes. You can now see the message on `/help`.
+
+![help message on help page example](img/help_page_help_page_text_ex_v12_3.png)
+
+## Adding a help message to the login page **(STARTER)**
+
+You can add a help message, which will be shown on the GitLab login page in a new section
+titled `Need Help?`, located below the login page message:
+
+1. Navigate to **Admin area > Settings > Preferences**, then expand **Help page**.
+1. Under **Help text**, fill in the information you wish to display on the login page.
+
+   ![help message on login page](img/help_page_help_text_v12_3.png)
+
+1. Save your changes.
+
+![help message on login page example](img/help_page_help_text_ex_v12_3.png)
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+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. -->
diff --git a/doc/user/admin_area/settings/img/access_restrictions.png b/doc/user/admin_area/settings/img/access_restrictions.png
deleted file mode 100644
index 8c5336c7835..00000000000
--- a/doc/user/admin_area/settings/img/access_restrictions.png
+++ /dev/null
diff --git a/doc/user/admin_area/settings/img/bulk_push_event_v12_4.png b/doc/user/admin_area/settings/img/bulk_push_event_v12_4.png
new file mode 100644
index 00000000000..38e666e32ac
--- /dev/null
+++ b/doc/user/admin_area/settings/img/bulk_push_event_v12_4.png
diff --git a/doc/user/admin_area/settings/img/clone_panel_v12_4.png b/doc/user/admin_area/settings/img/clone_panel_v12_4.png
new file mode 100644
index 00000000000..8aa0bd2f7d8
--- /dev/null
+++ b/doc/user/admin_area/settings/img/clone_panel_v12_4.png
diff --git a/doc/user/admin_area/settings/img/custom_git_clone_url_for_https_v12_4.png b/doc/user/admin_area/settings/img/custom_git_clone_url_for_https_v12_4.png
new file mode 100644
index 00000000000..22cdd15cc0c
--- /dev/null
+++ b/doc/user/admin_area/settings/img/custom_git_clone_url_for_https_v12_4.png
diff --git a/doc/user/admin_area/settings/img/help_page_help_page_text_ex_v12_3.png b/doc/user/admin_area/settings/img/help_page_help_page_text_ex_v12_3.png
new file mode 100644
index 00000000000..9dc7ef28149
--- /dev/null
+++ b/doc/user/admin_area/settings/img/help_page_help_page_text_ex_v12_3.png
diff --git a/doc/user/admin_area/settings/img/help_page_help_page_text_v12_3.png b/doc/user/admin_area/settings/img/help_page_help_page_text_v12_3.png
new file mode 100644
index 00000000000..59d3343db34
--- /dev/null
+++ b/doc/user/admin_area/settings/img/help_page_help_page_text_v12_3.png
diff --git a/doc/user/admin_area/settings/img/help_page_help_text_ex_v12_3.png b/doc/user/admin_area/settings/img/help_page_help_text_ex_v12_3.png
new file mode 100644
index 00000000000..9de26ac0758
--- /dev/null
+++ b/doc/user/admin_area/settings/img/help_page_help_text_ex_v12_3.png
diff --git a/doc/user/admin_area/settings/img/help_page_help_text_v12_3.png b/doc/user/admin_area/settings/img/help_page_help_text_v12_3.png
new file mode 100644
index 00000000000..1b6aad5753a
--- /dev/null
+++ b/doc/user/admin_area/settings/img/help_page_help_text_v12_3.png
diff --git a/doc/user/admin_area/settings/img/import_sources.png b/doc/user/admin_area/settings/img/import_sources.png
deleted file mode 100644
index 20829a27dd7..00000000000
--- a/doc/user/admin_area/settings/img/import_sources.png
+++ /dev/null
diff --git a/doc/user/admin_area/settings/img/protected_paths.png b/doc/user/admin_area/settings/img/protected_paths.png
new file mode 100644
index 00000000000..7aa9124b845
--- /dev/null
+++ b/doc/user/admin_area/settings/img/protected_paths.png
diff --git a/doc/user/admin_area/settings/img/push_event_activities_limit_v12_4.png b/doc/user/admin_area/settings/img/push_event_activities_limit_v12_4.png
new file mode 100644
index 00000000000..fd3775ac4d7
--- /dev/null
+++ b/doc/user/admin_area/settings/img/push_event_activities_limit_v12_4.png
diff --git a/doc/user/admin_area/settings/index.md b/doc/user/admin_area/settings/index.md
index 2a12614e325..4ca91ae5339 100644
--- a/doc/user/admin_area/settings/index.md
+++ b/doc/user/admin_area/settings/index.md
@@ -20,6 +20,9 @@ include:
 - [Visibility and access controls](visibility_and_access_controls.md)
 - [User and IP rate limits](user_and_ip_rate_limits.md)
 - [Custom templates repository](instance_template_repository.md) **(PREMIUM)**
+- [Protected paths](protected_paths.md) **(CORE ONLY)**
+- [Help messages for the `/help` page and the login page](help_page.md)
+- [Push event activities limit and bulk push events](push_event_activities_limit.md)
 
 NOTE: **Note:**
 You can change the [first day of the week](../../profile/preferences.md) for the entire GitLab instance
diff --git a/doc/user/admin_area/settings/protected_paths.md b/doc/user/admin_area/settings/protected_paths.md
new file mode 100644
index 00000000000..21c8d79b138
--- /dev/null
+++ b/doc/user/admin_area/settings/protected_paths.md
@@ -0,0 +1,76 @@
+---
+type: reference
+---
+
+# Protected paths **(CORE ONLY)**
+
+GitLab protects the following paths with Rack Attack by default:
+
+```
+'/users/password',
+'/users/sign_in',
+'/api/#{API::API.version}/session.json',
+'/api/#{API::API.version}/session',
+'/users',
+'/users/confirmation',
+'/unsubscribes/',
+'/import/github/personal_access_token'
+```
+
+GitLab responds with HTTP status code `429` to POST requests at protected paths
+that exceed 10 requests per minute per IP address.
+
+This header is included in responses to blocked requests:
+
+```
+Retry-After: 60
+```
+
+For example, the following are limited to a maximum 10 requests per minute:
+
+- User sign-in
+- User sign-up (if enabled)
+- User password reset
+
+After 10 requests, the client must wait 60 seconds before it can
+try again.
+
+## Configure using GitLab UI
+
+> Introduced in [GitLab 12.4](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31246).
+
+Throttling of protected paths is enabled by default and can be disabled or
+customized on **Admin > Network > Protected Paths**, along with these options:
+
+- Maximum number of requests per period per user.
+- Rate limit period in seconds.
+- Paths to be protected.
+
+![protected-paths](img/protected_paths.png)
+
+Requests over the rate limit are logged into `auth.log`.
+
+## Migrate settings from GitLab 12.3 and earlier
+
+Omnibus GitLab protected paths throttle is deprecated and is scheduled for removal in
+GitLab 13.0. Please see the [GitLab issue](https://gitlab.com/gitlab-org/gitlab/issues/29952) and the [Omnibus GitLab issue](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4688) for more information.
+
+NOTE: **Note:** If Omnibus settings are present, applications settings will be automatically ignored to avoid generating multiple requests blocks.
+
+To migrate from Omnibus GitLab 12.3 and earlier settings:
+
+1. Disable the Protected Paths throttle from Omnibus, by changing `rack_attack_enabled` value to `false` on [`rack_attack.rb.erb`](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/templates/default/rack_attack.rb.erb#L18):
+
+   ```ruby
+   rack_attack_enabled = false
+   ```
+
+1. Customize and enable your protected paths settings by following [Configure using GitLab UI](#configure-using-gitlab-ui) section.
+
+1. Restart GitLab:
+
+   ```bash
+   sudo gitlab-ctl restart
+   ```
+
+That's it. Protected paths throttle are now managed by GitLab admin settings.
diff --git a/doc/user/admin_area/settings/push_event_activities_limit.md b/doc/user/admin_area/settings/push_event_activities_limit.md
new file mode 100644
index 00000000000..9850de0f4b3
--- /dev/null
+++ b/doc/user/admin_area/settings/push_event_activities_limit.md
@@ -0,0 +1,28 @@
+---
+type: reference
+---
+
+# Push event activities limit and bulk push events
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/31007) in GitLab 12.4.
+
+This allows you to set the number of changes (branches or tags) in a single push
+to determine whether individual push events or bulk push event will be created.
+Bulk push events will be created if it surpasses that value.
+
+For example, if 4 branches are pushed and the limit is currently set to 3,
+you'll see the following in the activity feed:
+
+![Bulk push event](img/bulk_push_event_v12_4.png)
+
+With this feature, when a single push includes a lot of changes (e.g. 1,000
+branches), only 1 bulk push event will be created instead of creating 1,000 push
+events. This helps in maintaining good system performance and preventing spam on
+the activity feed.
+
+This setting can be modified in **Admin Area > Settings > Network > Performance Optimization**.
+This can also be configured via the [Application settings API](../../../api/settings.md#list-of-settings-that-can-be-accessed-via-api-calls)
+as `push_event_activities_limit`. The default value is 3, but it can be greater
+than or equal 0.
+
+![Push event activities limit](img/push_event_activities_limit_v12_4.png)
diff --git a/doc/user/admin_area/settings/rate_limits_on_raw_endpoints.md b/doc/user/admin_area/settings/rate_limits_on_raw_endpoints.md
index 3a6f3a8c20e..29a3591184b 100644
--- a/doc/user/admin_area/settings/rate_limits_on_raw_endpoints.md
+++ b/doc/user/admin_area/settings/rate_limits_on_raw_endpoints.md
@@ -7,7 +7,7 @@ type: reference
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/30829) in GitLab 12.2.
 
 This setting allows you to rate limit the requests to raw endpoints, defaults to `300` requests per minute.
-It can be modified in **Admin Area > Network > Performance Optimization**.
+It can be modified in **Admin Area > Settings > Network > Performance Optimization**.
 
 For example, requests over `300` per minute to `https://gitlab.com/gitlab-org/gitlab-foss/raw/master/app/controllers/application_controller.rb` will be blocked. Access to the raw file will be released after 1 minute.
 
diff --git a/doc/user/admin_area/settings/user_and_ip_rate_limits.md b/doc/user/admin_area/settings/user_and_ip_rate_limits.md
index b9d93bf3671..5d49d88d254 100644
--- a/doc/user/admin_area/settings/user_and_ip_rate_limits.md
+++ b/doc/user/admin_area/settings/user_and_ip_rate_limits.md
@@ -8,7 +8,7 @@ Rate limiting is a common technique used to improve the security and durability
 of a web application. For more details, see
 [Rate limits](../../../security/rate_limits.md).
 
-The following limits can be enforced in **Admin Area > Network > User and
+The following limits can be enforced in **Admin Area > Settings > Network > User and
 IP rate limits**:
 
 - Unauthenticated requests
diff --git a/doc/user/admin_area/settings/visibility_and_access_controls.md b/doc/user/admin_area/settings/visibility_and_access_controls.md
index ad08c852332..f718e31e8bd 100644
--- a/doc/user/admin_area/settings/visibility_and_access_controls.md
+++ b/doc/user/admin_area/settings/visibility_and_access_controls.md
@@ -4,15 +4,7 @@ type: reference
 
 # Visibility and access controls **(CORE ONLY)**
 
-GitLab allows administrators to:
-
-- Control access and visibility to GitLab resources including branches and projects.
-- Select from which hosting sites code can be imported into GitLab.
-- Select the protocols permitted to access GitLab.
-- Enable or disable repository mirroring.
-- Prevent non-administrators from deleting projects
-  ([introduced](https://gitlab.com/gitlab-org/gitlab/issues/5615) in GitLab 12.0).
-  **(PREMIUM ONLY)**
+GitLab allows administrators to enforce specific controls.
 
 To access the visibility and access control options:
 
@@ -20,29 +12,111 @@ To access the visibility and access control options:
 1. Go to **Admin Area > Settings > General**.
 1. Expand the **Visibility and access controls** section.
 
+## Default branch protection
+
+Branch protection specifies which roles can push to branches and which roles can delete
+branches.
+
+To change the default branch protection:
+
+1. Select the desired option.
+1. Click **Save changes**.
+
+For more details, see [Protected branches](../../project/protected_branches.md).
+
+## Default project creation protection
+
+Project creation protection specifies which roles can create projects.
+
+To change the default project creation protection:
+
+1. Select the desired option.
+1. Click **Save changes**.
+
+For more details, see [Default project-creation level](../../group/index.md#default-project-creation-level).
+
+## Default project deletion protection
+
+By default, a project can be deleted by anyone with the **Owner** role, either at the project or
+group level.
+
+To ensure only admin users can delete projects:
+
+1. Check the **Default project deletion protection** checkbox.
+1. Click **Save changes**.
+
+## Default project visibility
+
+To set the default visibility levels for new projects:
+
+1. Select the desired default project visibility.
+1. Click **Save changes**.
+
+For more details on project visibility, see [Public access](../../../public_access/public_access.md).
+
+## Default snippet visibility
+
+To set the default visibility levels for new snippets:
+
+1. Select the desired default snippet visibility.
+1. Click **Save changes**.
+
+For more details on snippet visibility, see [Public access](../../../public_access/public_access.md).
+
+## Default group visibility
+
+To set the default visibility levels for new groups:
+
+1. Select the desired default group visibility.
+1. Click **Save changes**.
+
+For more details on group visibility, see [Public access](../../../public_access/public_access.md).
+
+## Restricted visibility levels
+
+To set the available visibility levels for new projects and snippets:
+
+1. Check the desired visibility levels.
+1. Click **Save changes**.
+
+For more details on project visibility, see [Public access](../../../public_access/public_access.md).
+
 ## Import sources
 
-Choose from which hosting sites users can
-[import their projects](../../project/import/index.md).
+To specify from which hosting sites users can [import their projects](../../project/import/index.md):
+
+1. Check the checkbox beside the name of each hosting site.
+1. Click **Save changes**.
+
+## Project export
 
-![import sources](img/import_sources.png)
+To enable project export:
+
+1. Check the **Project export enabled** checkbox.
+1. Click **Save changes**.
+
+For more details, see [Exporting a project and its data](../../../user/project/settings/import_export.md#exporting-a-project-and-its-data).
 
 ## Enabled Git access protocols
 
-> [Introduced][ce-4696] in GitLab 8.10.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4696) in GitLab 8.10.
 
 With GitLab's access restrictions, you can select with which protocols users can communicate with
 GitLab.
 
-From the **Enabled Git access protocols** dropdown, select one of the following:
+Disabling an access protocol does not block access to the server itself via those ports. The ports
+used for the protocol, SSH or HTTP(S), will still be accessible. The GitLab restrictions apply at the
+application level.
 
-- Both SSH and HTTP(S)
-- Only SSH
-- Only HTTP(s)
+To specify the enabled Git access protocols:
 
-![Settings Overview](img/access_restrictions.png)
+1. Select the desired Git access protocols from the dropdown:
+   - Both SSH and HTTP(S)
+   - Only SSH
+   - Only HTTP(S)
+1. Click **Save changes**.
 
-When both SSH and HTTP(S) are enabled, your users can choose either protocol.
+When both SSH and HTTP(S) are enabled, users can choose either protocol.
 
 When only one protocol is enabled:
 
@@ -57,20 +131,53 @@ On top of these UI restrictions, GitLab will deny all Git actions on the protoco
 not selected.
 
 CAUTION: **Important:**
-Starting with [GitLab 10.7][ce-18021], HTTP(s) protocol will be allowed for
-git clone/fetch requests done by GitLab Runner from CI/CD Jobs, even if
-_Only SSH_ was selected.
+Starting with [GitLab 10.7](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18021),
+HTTP(S) protocol will be allowed for Git clone or fetch requests done by GitLab Runner
+from CI/CD jobs, even if _Only SSH_ was selected.
 
-> **Note:** Please keep in mind that disabling an access protocol does not actually
-block access to the server itself. The ports used for the protocol, be it SSH or
-HTTP, will still be accessible. What GitLab does is restrict access on the
-application level.
+## Custom Git clone URL for HTTP(S)
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/18422) in GitLab 12.4.
+
+You can customize project Git clone URLs for HTTP(S). This will affect the clone
+panel:
+
+![Clone panel](img/clone_panel_v12_4.png)
+
+For example, if:
+
+- Your GitLab instance is at `https://example.com`, then project clone URLs are like
+  `https://example.com/foo/bar.git`.
+- You want clone URLs that look like `https://git.example.com/gitlab/foo/bar.git` instead,
+  you can set this setting to `https://git.example.com/gitlab/`.
+
+![Custom Git clone URL for HTTP](img/custom_git_clone_url_for_https_v12_4.png)
+
+To specify a custom Git clone URL for HTTP(S):
+
+1. Enter a root URL for **Custom Git clone URL for HTTP(S)**.
+1. Click on **Save changes**.
+
+NOTE: **Note:**
+SSH clone URLs can be customized in `gitlab.rb` by setting `gitlab_rails['gitlab_ssh_host']` and
+other related settings.
+
+## RSA, DSA, ECDSA, ED25519 SSH keys
+
+These options specify the permitted types and lengths for SSH keys.
+
+To specify a restriction for each key type:
+
+1. Select the desired option from the dropdown.
+1. Click **Save changes**.
+
+For more details, see [SSH key restrictions](../../../security/ssh_keys_restrictions.md).
 
 ## Allow mirrors to be set up for projects
 
-> [Introduced][ee-3586] in GitLab 10.3.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3586) in GitLab 10.3.
 
-This option is enabled by default. By disabling it, both pull and push mirroring will no longer
+This option is enabled by default. By disabling it, both [pull and push mirroring](../../../workflow/repository_mirroring.md) will no longer
 work in every repository and can only be re-enabled by an admin on a per-project basis.
 
 ![Mirror settings](img/mirror_settings.png)
@@ -86,7 +193,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-4696]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/4696
-[ce-18021]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/18021
-[ee-3586]: https://gitlab.com/gitlab-org/gitlab/merge_requests/3586
diff --git a/doc/user/analytics/cycle_analytics.md b/doc/user/analytics/cycle_analytics.md
index 7a966f92934..e17202645d3 100644
--- a/doc/user/analytics/cycle_analytics.md
+++ b/doc/user/analytics/cycle_analytics.md
@@ -1,7 +1,7 @@
 # Cycle Analytics
 
 > - Introduced prior to GitLab 12.3 at the project level.
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/12077) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.3 at the group level.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/12077) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.3 at the group level.
 
 Cycle Analytics measures the time spent to go from an [idea to production] - also known
 as cycle time - for each of your projects. Cycle Analytics displays the median time for an idea to
@@ -169,14 +169,14 @@ For Cycle Analytics functionality introduced in GitLab 12.3 and later:
 
 Learn more about Cycle Analytics in the following resources:
 
-- [Cycle Analytics feature page](https://about.gitlab.com/features/cycle-analytics/)
-- [Cycle Analytics feature preview](https://about.gitlab.com/2016/09/16/feature-preview-introducing-cycle-analytics/)
-- [Cycle Analytics feature highlight](https://about.gitlab.com/2016/09/21/cycle-analytics-feature-highlight/)
+- [Cycle Analytics feature page](https://about.gitlab.com/product/cycle-analytics/)
+- [Cycle Analytics feature preview](https://about.gitlab.com/blog/2016/09/16/feature-preview-introducing-cycle-analytics/)
+- [Cycle Analytics feature highlight](https://about.gitlab.com/blog/2016/09/21/cycle-analytics-feature-highlight/)
 
 [ce-5986]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/5986
 [ce-20975]: https://gitlab.com/gitlab-org/gitlab-foss/issues/20975
 [environment]: ../../ci/yaml/README.md#environment
 [GitLab flow]: ../../workflow/gitlab_flow.md
-[idea to production]: https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#from-idea-to-production-with-gitlab
+[idea to production]: https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#from-idea-to-production-with-gitlab
 [permissions]: ../permissions.md
 [yml]: ../../ci/yaml/README.md
diff --git a/doc/user/analytics/productivity_analytics.md b/doc/user/analytics/productivity_analytics.md
index a53ef56bbf7..09f83dcff4b 100644
--- a/doc/user/analytics/productivity_analytics.md
+++ b/doc/user/analytics/productivity_analytics.md
@@ -1,6 +1,6 @@
 # Productivity Analytics **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/12079) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.3 (enabled by feature flags `productivity_analytics`).
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/12079) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.3 (enabled by default using the feature flags `productivity_analytics`, `productivity_analytics_scatterplot_enabled`).
 
 Track development velocity with Productivity Analytics.
 
@@ -12,6 +12,8 @@ Software Development Life Cycle (SDLC) process, Productivity Analytics provides
 
 Productivity can slow down for many reasons ranging from degrading code base to quickly growing teams. In order to investigate, department or team leaders can start by visualizing the time it takes for merge requests to be merged.
 
+By default, a data migration job covering three months of historical data will kick off when deploying Productivity Analytics for the first time.
+
 ## Supported features
 
 Productivity Analytics allows GitLab users to:
@@ -41,7 +43,7 @@ The following metrics and visualizations are available on a project or group lev
   - Number of files touched.
 - Scatterplot showing all MRs merged on a certain date, together with the days it took to complete the action and a 30 day rolling median.
   - Users can zoom in and out on specific days of interest.
-- Table showing list of merge requests with their respective times and size metrics.
+- Table showing the list of merge requests with their respective time duration metrics.
   - Users can sort by any of the above metrics.
 
 ## Permissions
diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md
index ad3f0663ed5..14dae56f087 100644
--- a/doc/user/application_security/container_scanning/index.md
+++ b/doc/user/application_security/container_scanning/index.md
@@ -87,7 +87,7 @@ The results will be saved as a
 that you can later download and analyze.
 Due to implementation limitations, we always take the latest Container Scanning
 artifact available. Behind the scenes, the
-[GitLab Container Scanning analyzer](https://gitlab.com/gitlab-org/security-products/container-scanning)
+[GitLab Klar analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/klar/)
 is used and runs the scans.
 
 ## Example
@@ -145,6 +145,23 @@ container_scanning:
     GIT_STRATEGY: fetch
 ```
 
+### Available variables
+
+Container Scanning can be [configured](#overriding-the-container-scanning-template)
+using environment variables.
+
+| Environment Variable           | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   | Default                                  |
+| ------                         | ------                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        | ------                                   |
+| `KLAR_TRACE`                   | Set to true to enable more verbose output from klar.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          | `"false"`                                |
+| `DOCKER_USER`                  | Username for accessing a Docker registry requiring authentication.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            | `$CI_REGISTRY_USER`                      |
+| `DOCKER_PASSWORD`              | Password for accessing a Docker registry requiring authentication.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            | `$CI_REGISTRY_PASSWORD`                  |
+| `CLAIR_OUTPUT`                 | Severity level threshold. Vulnerabilities with severity level higher than or equal to this threshold will be outputted. Supported levels are `Unknown`, `Negligible`, `Low`, `Medium`, `High`, `Critical` and `Defcon1`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      | `Unknown`                                |
+| `REGISTRY_INSECURE`            | Allow [Klar](https://github.com/optiopay/klar) to access insecure registries (HTTP only). Should only be set to `true` when testing the image locally.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        | `"false"`                                |
+| `CLAIR_VULNERABILITIES_DB_URL` | This variable is explicitly set in the [services section](https://gitlab.com/gitlab-org/gitlab/blob/30522ca8b901223ac8c32b633d8d67f340b159c1/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L17-19) of the `Container-Scanning.gitlab-ci.yml` file and defaults to `clair-vulnerabilities-db`.  This value represents the address that the [postgres server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db) is running on and **shouldn't be changed** unless you're running the image locally as described in the [Running the scanning tool](https://gitlab.com/gitlab-org/security-products/analyzers/klar/#running-the-scanning-tool) section of the [klar readme](https://gitlab.com/gitlab-org/security-products/analyzers/klar). | `clair-vulnerabilities-db`               |
+| `CI_APPLICATION_REPOSITORY`    | Docker repository URL for the image to be scanned.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            | `$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG` |
+| `CI_APPLICATION_TAG`           | Docker respository tag for the image to be scanned.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           | `$CI_COMMIT_SHA`                         |
+| `CLAIR_DB_IMAGE_TAG`           | The Docker image tag for the [postgres server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db). It can be useful to override this value with a specific version, for example, to provide a consistent set of vulnerabilities for integration testing purposes.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              | `latest`                                 |
+
 ## Security Dashboard
 
 The Security Dashboard is a good place to get an overview of all the security
diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md
index e90f219337b..951c4b9dd73 100644
--- a/doc/user/application_security/dast/index.md
+++ b/doc/user/application_security/dast/index.md
@@ -81,8 +81,15 @@ variables:
 
 There are two ways to define the URL to be scanned by DAST:
 
-- Set the `DAST_WEBSITE` [variable](../../../ci/yaml/README.md#variables).
-- Add it in an `environment_url.txt` file at the root of your project.
+1. Set the `DAST_WEBSITE` [variable](../../../ci/yaml/README.md#variables).
+
+1. Add it in an `environment_url.txt` file at the root of your project.
+    This is great for testing in dynamic environments. In order to run DAST against
+    an app that is dynamically created during a Gitlab CI pipeline, have the app
+    persist its domain in an `environment_url.txt` file, and DAST will
+    automatically parse that file to find its scan target.
+    You can see an [example](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml)
+    of this in our Auto DevOps CI YML.
 
 If both values are set, the `DAST_WEBSITE` value will take precedence.
 
diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md
index b2f754c17bd..9f87d79025e 100644
--- a/doc/user/application_security/dependency_scanning/index.md
+++ b/doc/user/application_security/dependency_scanning/index.md
@@ -55,7 +55,7 @@ The following languages and dependency managers are supported.
 |----------------------------- | --------- | ------------ |
 | Java ([Gradle](https://gradle.org/)) | not currently ([issue](https://gitlab.com/gitlab-org/gitlab/issues/13075 "Dependency Scanning for Gradle" )) | not available |
 | Java ([Maven](https://maven.apache.org/)) | yes | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium) |
-| JavaScript ([npm](https://www.npmjs.com/), [yarn](https://yarnpkg.com/en/)) | yes | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium), [Retire.js](https://retirejs.github.io/retire.js)         |
+| JavaScript ([npm](https://www.npmjs.com/), [yarn](https://yarnpkg.com/en/)) | yes | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium), [Retire.js](https://retirejs.github.io/retire.js/)         |
 | Go ([Golang](https://golang.org/)) | not currently ([issue](https://gitlab.com/gitlab-org/gitlab/issues/7132 "Dependency Scanning for Go")) | not available |
 | PHP ([Composer](https://getcomposer.org/))  | yes | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium) |
 | Python ([pip](https://pip.pypa.io/en/stable/)) | yes | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium) |
diff --git a/doc/user/application_security/img/dismissed_info.png b/doc/user/application_security/img/dismissed_info.png
deleted file mode 100644
index b4470b664d2..00000000000
--- a/doc/user/application_security/img/dismissed_info.png
+++ /dev/null
diff --git a/doc/user/application_security/img/dismissed_info_v12_3.png b/doc/user/application_security/img/dismissed_info_v12_3.png
new file mode 100644
index 00000000000..92037493eaa
--- /dev/null
+++ b/doc/user/application_security/img/dismissed_info_v12_3.png
diff --git a/doc/user/application_security/index.md b/doc/user/application_security/index.md
index 0e52496ec43..e9f5898950e 100644
--- a/doc/user/application_security/index.md
+++ b/doc/user/application_security/index.md
@@ -57,7 +57,7 @@ This workflow comes with some drawbacks and there's a
 
 ## Interacting with the vulnerabilities
 
-> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing) 10.8.
+> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.8.
 
 CAUTION: **Warning:**
 This feature is currently [Alpha](https://about.gitlab.com/handbook/product/#alpha-beta-ga) and while you can start using it, it may receive important changes in the future.
@@ -84,13 +84,15 @@ If you wish to undo this dismissal, you can click the **Undo dismiss** button.
 
 #### Adding a dismissal reason
 
-> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing) 12.0.
+> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.0.
 
 When dismissing a vulnerability, it's often helpful to provide a reason for doing so.
-If you press the comment button next to **Dismiss vulnerability** in the modal, a text box will appear, allowing you to add a comment with your dismissal.
-This comment can not currently be edited or removed, but [future versions](https://gitlab.com/gitlab-org/gitlab/issues/11721) will add this functionality.
+If you press the comment button next to **Dismiss vulnerability** in the modal,
+a text box will appear, allowing you to add a comment with your dismissal.
+Once added, you can edit it or delete it. This allows you to add and update
+context for a vulnerability as you learn more over time.
 
-![Dismissed vulnerability comment](img/dismissed_info.png)
+![Dismissed vulnerability comment](img/dismissed_info_v12_3.png)
 
 ### Creating an issue for a vulnerability
 
@@ -110,7 +112,7 @@ the vulnerability will now have an associated issue next to the name.
 
 ### Solutions for vulnerabilities (auto-remediation)
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/5656) in [GitLab Ultimate](https://about.gitlab.com/pricing) 11.7.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/5656) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.7.
 
 Some vulnerabilities can be fixed by applying the solution that GitLab
 automatically generates. The following scanners are supported:
@@ -134,7 +136,7 @@ generated by GitLab. To apply the fix:
 
 #### Creating a merge request from a vulnerability
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9224) in [GitLab Ultimate](https://about.gitlab.com/pricing) 11.9.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9224) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.9.
 
 In certain cases, GitLab will allow you to create a merge request that will
 automatically remediate the vulnerability. Any vulnerability that has a
@@ -148,10 +150,10 @@ Clicking on this button will create a merge request to apply the solution onto t
 
 ## Security approvals in merge requests **(ULTIMATE)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9928) in [GitLab Ultimate](https://about.gitlab.com/pricing) 12.2.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9928) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.2.
 
 Merge Request Approvals can be configured to require approval from a member
-of your security team when a vulnerability would be introduced by a merge request.
+of your security team when a vulnerability, or a software license compliance violation would be introduced by a merge request.
 
 This threshold is defined as `high`, `critical`, or `unknown`
 severity. When any vulnerabilities are present within a merge request, an
@@ -178,6 +180,29 @@ An approval will be optional when a security report:
 - Contains no new vulnerabilities.
 - Contains only new vulnerabilities of `low` or `medium` severity.
 
+### Enabling License Approvals within a project
+
+To enable License Approvals, a [project approval rule](../project/merge_requests/merge_request_approvals.md#multiple-approval-rules-premium)
+must be created with the case-sensitive name `License-Check`. This approval
+group must be set with an "Approvals required" count greater than zero.
+
+Once this group has been added to your project, the approval rule will be enabled
+for all Merge Requests. To configure how this rule behaves, you can choose which
+licenses to `approve` or `blacklist` in the
+[project policies for License Compliance](license_compliance/index.md#project-policies-for-license-compliance) section.
+
+Any code changes made will cause the count of approvals required to reset.
+
+An approval will be required when a license report:
+
+- Contains a dependency that includes a software license that is `blacklisted`.
+- Is not generated during pipeline execution.
+
+An approval will be optional when a license report:
+
+- Contains no software license violations.
+- Contains only new licenses that are `approved` or unknown.
+
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues
diff --git a/doc/user/application_security/license_compliance/index.md b/doc/user/application_security/license_compliance/index.md
index fb361acf6e8..75a3b33e32e 100644
--- a/doc/user/application_security/license_compliance/index.md
+++ b/doc/user/application_security/license_compliance/index.md
@@ -60,7 +60,7 @@ The following languages and package managers are supported.
 | Elixir     | [mix](https://elixir-lang.org/getting-started/mix-otp/introduction-to-mix.html) ([experimental support](https://github.com/pivotal/LicenseFinder#experimental-project-types)) |[License Finder](https://github.com/pivotal/LicenseFinder)|
 | C++/C      | [conan](https://conan.io/) ([experimental support](https://github.com/pivotal/LicenseFinder#experimental-project-types))|[License Finder](https://github.com/pivotal/LicenseFinder)|
 | Scala      | [sbt](https://www.scala-sbt.org/) ([experimental support](https://github.com/pivotal/LicenseFinder#experimental-project-types))|[License Finder](https://github.com/pivotal/LicenseFinder)|
-| Rust       | [cargo](https://crates.io/) ([experimental support](https://github.com/pivotal/LicenseFinder#experimental-project-types))|[License Finder](https://github.com/pivotal/LicenseFinder)|
+| Rust       | [cargo](https://crates.io) ([experimental support](https://github.com/pivotal/LicenseFinder#experimental-project-types))|[License Finder](https://github.com/pivotal/LicenseFinder)|
 | PHP        | [composer](https://getcomposer.org/) ([experimental support](https://github.com/pivotal/LicenseFinder#experimental-project-types))|[License Finder](https://github.com/pivotal/LicenseFinder)|
 
 ## Requirements
diff --git a/doc/user/application_security/sast/analyzers.md b/doc/user/application_security/sast/analyzers.md
index a1bd00f34e3..76a566f7514 100644
--- a/doc/user/application_security/sast/analyzers.md
+++ b/doc/user/application_security/sast/analyzers.md
@@ -1,7 +1,3 @@
----
-table_display_block: true
----
-
 # SAST Analyzers **(ULTIMATE)**
 
 SAST relies on underlying third party tools that are wrapped into what we call
@@ -19,7 +15,7 @@ SAST supports the following official analyzers:
 
 - [`bandit`](https://gitlab.com/gitlab-org/security-products/analyzers/bandit) (Bandit)
 - [`brakeman`](https://gitlab.com/gitlab-org/security-products/analyzers/brakeman) (Brakeman)
-- [`eslint`](https://gitlab.com/gitlab-org/security-products/analyzers/eslint) (ESLint (Javascript))
+- [`eslint`](https://gitlab.com/gitlab-org/security-products/analyzers/eslint) (ESLint (JavaScript))
 - [`flawfinder`](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder) (Flawfinder)
 - [`gosec`](https://gitlab.com/gitlab-org/security-products/analyzers/gosec) (Gosec)
 - [`nodejs-scan`](https://gitlab.com/gitlab-org/security-products/analyzers/nodejs-scan) (NodeJsScan)
diff --git a/doc/user/application_security/sast/index.md b/doc/user/application_security/sast/index.md
index 0618c14a3d1..cb54d9f3853 100644
--- a/doc/user/application_security/sast/index.md
+++ b/doc/user/application_security/sast/index.md
@@ -45,12 +45,15 @@ The results are sorted by the priority of the vulnerability:
 
 ## Requirements
 
-To run a SAST job, you need GitLab Runner with the
+To run a SAST job, by default, you need GitLab Runner with the
 [`docker`](https://docs.gitlab.com/runner/executors/docker.html#use-docker-in-docker-with-privileged-mode) or
 [`kubernetes`](https://docs.gitlab.com/runner/install/kubernetes.html#running-privileged-containers-for-the-runners)
 executor running in privileged mode. If you're using the shared Runners on GitLab.com,
 this is enabled by default.
 
+Privileged mode is not necessary if you've [disabled Docker in Docker
+for SAST](#disabling-docker-in-docker-for-sast)
+
 CAUTION: **Caution:**
 If you use your own Runners, make sure that the Docker version you have installed
 is **not** `19.03.00`. See [troubleshooting information](#error-response-from-daemon-error-processing-tar-file-docker-tar-relocation-error) for details.
@@ -62,14 +65,14 @@ The following table shows which languages, package managers and frameworks are s
 | Language (package managers) / framework                                     | Scan tool                                                                              | Introduced in GitLab Version |
 |-----------------------------------------------------------------------------|----------------------------------------------------------------------------------------|------------------------------|
 | .NET                                                                        | [Security Code Scan](https://security-code-scan.github.io)                             | 11.0                         |
-| Any                                                                         | [Gitleaks](https://github.com/zricethezav/gitleaks) and [TruffleHog](https://github.com/dxa4481/truffleHog) | 11.9 |
+| Any                                                                         | [Gitleaks](https://github.com/zricethezav/gitleaks) and [TruffleHog](https://github.com/dxa4481/truffleHog) | 11.9    |
 | Apex (Salesforce)                                                           | [pmd](https://pmd.github.io/pmd/index.html)                                            | 12.1                         |
-| C/C++                                                                       | [Flawfinder](https://www.dwheeler.com/flawfinder/)                                     | 10.7                         |
+| C/C++                                                                       | [Flawfinder](https://dwheeler.com/flawfinder/)                                         | 10.7                         |
 | Elixir (Phoenix)                                                            | [Sobelow](https://github.com/nccgroup/sobelow)                                         | 11.10                        |
 | Go                                                                          | [Gosec](https://github.com/securego/gosec)                                             | 10.7                         |
 | Groovy ([Ant](https://ant.apache.org/), [Gradle](https://gradle.org/), [Maven](https://maven.apache.org/) and [SBT](https://www.scala-sbt.org/)) | [SpotBugs](https://spotbugs.github.io/) with the [find-sec-bugs](https://find-sec-bugs.github.io/) plugin | 11.3 (Gradle) & 11.9 (Ant, Maven, SBT) |
 | Java ([Ant](https://ant.apache.org/), [Gradle](https://gradle.org/), [Maven](https://maven.apache.org/) and [SBT](https://www.scala-sbt.org/)) | [SpotBugs](https://spotbugs.github.io/) with the [find-sec-bugs](https://find-sec-bugs.github.io/) plugin | 10.6 (Maven), 10.8 (Gradle) & 11.9 (Ant, SBT) |
-| Javascript                                                                  | [ESLint security plugin](https://github.com/nodesecurity/eslint-plugin-security)       | 11.8                         |
+| JavaScript                                                                  | [ESLint security plugin](https://github.com/nodesecurity/eslint-plugin-security)       | 11.8                         |
 | Node.js                                                                     | [NodeJsScan](https://github.com/ajinabraham/NodeJsScan)                                | 11.1                         |
 | PHP                                                                         | [phpcs-security-audit](https://github.com/FloeDesignTechnologies/phpcs-security-audit) | 10.8                         |
 | Python ([pip](https://pip.pypa.io/en/stable/))                              | [bandit](https://github.com/PyCQA/bandit)                                              | 10.3                         |
@@ -110,10 +113,9 @@ is used to detect the languages/frameworks and in turn runs the matching scan to
 
 ### Customizing the SAST settings
 
-The SAST settings can be changed through environment variables by using the
+The SAST settings can be changed through [environment variables](#available-variables)
+by using the
 [`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`.
-These variables are documented in the
-[SAST tool documentation](https://gitlab.com/gitlab-org/security-products/sast#settings).
 
 In the following example, we include the SAST template and at the same time we
 set the `SAST_GOSEC_LEVEL` variable to `2`:
@@ -129,7 +131,22 @@ variables:
 Because the template is [evaluated before](../../../ci/yaml/README.md#include)
 the pipeline configuration, the last mention of the variable will take precedence.
 
-#### Using a variable to pass username and password to a private Maven repository
+### Overriding the SAST template
+
+If you want to override the job definition (for example, change properties like
+`variables` or `dependencies`), you need to declare a `sast` job after the
+template inclusion and specify any additional keys under it. For example:
+
+```yaml
+include:
+  template: SAST.gitlab-ci.yml
+
+sast:
+  variables:
+    CI_DEBUG_TRACE: "true"
+```
+
+### Using a variable to pass username and password to a private Maven repository
 
 If you have a private Apache Maven repository that requires login credentials,
 you can use the `MAVEN_CLI_OPTS` [environment variable](#available-variables)
@@ -137,28 +154,28 @@ to pass a username and password. You can set it under your project's settings
 so that your credentials aren't exposed in `.gitlab-ci.yml`.
 
 If the username is `myuser` and the password is `verysecret` then you would
-set the following [variable](../../../ci/variables/README.md#via-the-ui)
+[set the following variable](../../../ci/variables/README.md#via-the-ui)
 under your project's settings:
 
 | Type | Key | Value |
 | ---- | --- | ----- |
 | Variable | `MAVEN_CLI_OPTS` | `-Drepository.password=verysecret -Drepository.user=myuser` |
 
-### Overriding the SAST template
+### Disabling Docker in Docker for SAST
 
-If you want to override the job definition (for example, change properties like
-`variables` or `dependencies`), you need to declare a `sast` job after the
-template inclusion and specify any additional keys under it. For example:
+You can avoid the need for Docker in Docker by running the individual analyzers.
+This does not require running the executor in privileged mode. For example:
 
 ```yaml
 include:
   template: SAST.gitlab-ci.yml
 
-sast:
-  variables:
-    CI_DEBUG_TRACE: "true"
+variables:
+  SAST_DISABLE_DIND: "true"
 ```
 
+This will create individual `<analyzer-name>-sast` jobs for each analyzer that runs in your CI/CD pipeline.
+
 ### Available variables
 
 SAST can be [configured](#customizing-the-sast-settings) using environment variables.
@@ -173,9 +190,10 @@ The following are Docker image-related variables.
 | `SAST_ANALYZER_IMAGE_PREFIX`  | Override the name of the Docker registry providing the default images (proxy). Read more about [customizing analyzers](analyzers.md). |
 | `SAST_ANALYZER_IMAGE_TAG`     | Override the Docker tag of the default images. Read more about [customizing analyzers](analyzers.md).                                 |
 | `SAST_DEFAULT_ANALYZERS`      | Override the names of default images. Read more about [customizing analyzers](analyzers.md).                                          |
+| `SAST_DISABLE_DIND`           | Disable Docker in Docker and run analyzers [individually](#disabling-docker-in-docker-for-sast).                                      |
 | `SAST_PULL_ANALYZER_IMAGES`   | Pull the images from the Docker registry (set to 0 to disable). Read more about [customizing analyzers](analyzers.md).                 |
 
-### Vulnerability filters
+#### Vulnerability filters
 
 Some analyzers make it possible to filter out vulnerabilities under a given threshold.
 
@@ -188,7 +206,7 @@ Some analyzers make it possible to filter out vulnerabilities under a given thre
 | `SAST_GOSEC_LEVEL`      |         0 | Ignore gosec vulnerabilities under given confidence level. Integer, 0=Undefined, 1=Low, 2=Medium, 3=High. | |
 | `SAST_EXCLUDED_PATHS`   |   -        | Exclude vulnerabilities from output based on the paths. This is a comma-separated list of patterns. Patterns can be globs, file or folder paths. Parent directories will also match patterns. | `SAST_EXCLUDED_PATHS=doc,spec` |
 
-### Timeouts
+#### Timeouts
 
 The following variables configure timeouts.
 
@@ -198,7 +216,7 @@ The following variables configure timeouts.
 | `SAST_PULL_ANALYZER_IMAGE_TIMEOUT`       |      5m | Time limit when pulling the image of an analyzer. Timeouts are parsed using Go's [`ParseDuration`](https://golang.org/pkg/time/#ParseDuration). Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h". For example, "300ms", "1.5h" or "2h45m". |
 | `SAST_RUN_ANALYZER_TIMEOUT`              |     20m | Time limit when running an analyzer. Timeouts are parsed using Go's [`ParseDuration`](https://golang.org/pkg/time/#ParseDuration). Valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h". For example, "300ms", "1.5h" or "2h45m".|
 
-### Analyzer settings
+#### Analyzer settings
 
 Some analyzers can be customized with environment variables.
 
diff --git a/doc/user/application_security/security_dashboard/index.md b/doc/user/application_security/security_dashboard/index.md
index 999b98bfa3d..0e26206f070 100644
--- a/doc/user/application_security/security_dashboard/index.md
+++ b/doc/user/application_security/security_dashboard/index.md
@@ -36,7 +36,7 @@ To use the group, project or pipeline security dashboard:
 
 ## Pipeline Security Dashboard
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/13496) in [GitLab Ultimate](https://about.gitlab.com/pricing) 12.3.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/13496) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.3.
 
 At the pipeline level, the Security Dashboard displays the vulnerabilities present in the branch of the project the pipeline was run against.
 
@@ -46,7 +46,7 @@ Visit the page for any pipeline which has run any of the [supported reports](#su
 
 ## Project Security Dashboard
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/6165) in [GitLab Ultimate](https://about.gitlab.com/pricing) 11.1.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/6165) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.1.
 
 At the project level, the Security Dashboard displays the latest security reports
 for your project. Use it to find and fix vulnerabilities affecting the
@@ -56,7 +56,7 @@ for your project. Use it to find and fix vulnerabilities affecting the
 
 ## Group Security Dashboard
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/6709) in [GitLab Ultimate](https://about.gitlab.com/pricing) 11.5.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/6709) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.5.
 
 The group Security Dashboard gives an overview of the vulnerabilities of all the
 projects in a group and its subgroups.
diff --git a/doc/user/asciidoc.md b/doc/user/asciidoc.md
index 862316b57da..b4d3cb58e97 100644
--- a/doc/user/asciidoc.md
+++ b/doc/user/asciidoc.md
@@ -6,7 +6,7 @@ Consult the [Asciidoctor User Manual](https://asciidoctor.org/docs/user-manual/)
 ## Syntax
 
 Here's a brief reference of the most commonly used AsciiDoc syntax.
-You can find the full documentation for the AsciiDoc syntax at <https://asciidoctor.org/docs>.
+You can find the full documentation for the AsciiDoc syntax at <https://asciidoctor.org/docs/>.
 
 ### Paragraphs
 
@@ -44,7 +44,7 @@ monospaced font:
 An admonition paragraph grabs the reader's attention:
 
 ```asciidoc
-NOTE: This is a brief reference, please read the full documentation at https://asciidoctor.org/docs.
+NOTE: This is a brief reference, please read the full documentation at https://asciidoctor.org/docs/.
 
 TIP: Lists can be indented. Leading whitespace is not significant.
 ```
diff --git a/doc/user/clusters/applications.md b/doc/user/clusters/applications.md
index 8a53b4c0e47..dc6f859e881 100644
--- a/doc/user/clusters/applications.md
+++ b/doc/user/clusters/applications.md
@@ -62,7 +62,7 @@ can lead to confusion during deployments.
 > - Introduced in GitLab 10.2 for project-level clusters.
 > - Introduced in GitLab 11.6 for group-level clusters.
 
-[Helm](https://docs.helm.sh/) is a package manager for Kubernetes and is
+[Helm](https://helm.sh/docs/) is a package manager for Kubernetes and is
 required to install all the other applications. It is installed in its
 own pod inside the cluster which can run the `helm` CLI in a safe
 environment.
@@ -86,11 +86,16 @@ NOTE: **Note:**
 The
 [jetstack/cert-manager](https://github.com/jetstack/cert-manager)
 chart is used to install this application with a
-[`values.yaml`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/vendor/cert_manager/values.yaml)
+[`values.yaml`](https://gitlab.com/gitlab-org/gitlab/blob/master/vendor/cert_manager/values.yaml)
 file. Prior to GitLab 12.3,
 the [stable/cert-manager](https://github.com/helm/charts/tree/master/stable/cert-manager)
 chart was used.
 
+NOTE: **Note:**
+If you have installed cert-manager prior to GitLab 12.3, Let's Encrypt will
+[block requests from older versions of cert-manager](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753).
+To resolve this, uninstall cert-manager (consider [backing up any additional configuration](https://docs.cert-manager.io/en/latest/tasks/backup-restore-crds.html)), then install cert-manager again.
+
 ### GitLab Runner
 
 > - Introduced in GitLab 10.6 for project-level clusters.
@@ -106,11 +111,10 @@ mode** by default. Make sure you read the [security
 implications](../project/clusters/index.md#security-implications) before doing so.
 
 NOTE: **Note:**
-The
-[runner/gitlab-runner](https://gitlab.com/gitlab-org/charts/gitlab-runner)
+The [`runner/gitlab-runner`](https://gitlab.com/gitlab-org/charts/gitlab-runner)
 chart is used to install this application with a
-[`values.yaml`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/vendor/runner/values.yaml)
-file.
+[`values.yaml`](https://gitlab.com/gitlab-org/gitlab/blob/master/vendor/runner/values.yaml)
+file. Customizing installation by modifying this file is not supported.
 
 ### Ingress
 
@@ -123,23 +127,26 @@ web proxy for your applications and is useful if you want to use [Auto
 DevOps](../../topics/autodevops/index.md) or deploy your own web apps.
 
 NOTE: **Note:**
-The
-[stable/nginx-ingress](https://github.com/helm/charts/tree/master/stable/nginx-ingress)
+The [`stable/nginx-ingress`](https://github.com/helm/charts/tree/master/stable/nginx-ingress)
 chart is used to install this application with a
-[`values.yaml`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/vendor/ingress/values.yaml)
+[`values.yaml`](https://gitlab.com/gitlab-org/gitlab/blob/master/vendor/ingress/values.yaml)
 file.
 
-#### Modsecurity Application Firewall
+#### Web Application Firewall (ModSecurity)
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/65192) in GitLab 12.3 (enabled using `ingress_modsecurity` [feature flag](../../development/feature_flags/development.md#enabling-a-feature-flag-in-development)).
 
-GitLab supports
+Out of the box, GitLab provides you real-time security monitoring with
 [`modsecurity`](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#modsecurity)
-to check requests against [OWASP's Core Rule Set](https://www.modsecurity.org/CRS/Documentation/).
+
+Modsecurity is a toolkit for real-time web application monitoring, logging,
+and access control. With GitLab's offering, the [OWASP's Core Rule Set](https://www.modsecurity.org/CRS/Documentation/), which provides generic attack detection capabilities,
+is automatically applied.
+
 This feature:
 
 - Runs in "Detection-only mode" unless configured otherwise.
-- Is viewable by checking your ingress controller's `modsec` log for rule violations.
+- Is viewable by checking your Ingress controller's `modsec` log for rule violations.
   For example:
 
   ```sh
@@ -160,7 +167,7 @@ application for the changes to take effect.
 ### JupyterHub
 
 > - Introduced in GitLab 11.0 for project-level clusters.
-> - Introduced in GitLab 12.3 for group-level clusters.
+> - Introduced in GitLab 12.3 for group and instance-level clusters.
 
 [JupyterHub](https://jupyterhub.readthedocs.io/en/stable/) is a
 multi-user service for managing notebooks across a team. [Jupyter
@@ -176,7 +183,7 @@ higher](../permissions.md) access to the associated project or group.
 We use a [custom Jupyter
 image](https://gitlab.com/gitlab-org/jupyterhub-user-image/blob/master/Dockerfile)
 that installs additional useful packages on top of the base Jupyter. You
-will also see ready-to-use DevOps Runbooks built with Nurtch's [Rubix library](https://github.com/amit1rrr/rubix).
+will also see ready-to-use DevOps Runbooks built with Nurtch's [Rubix library](https://github.com/Nurtch/rubix).
 
 More information on
 creating executable runbooks can be found in [our Runbooks
@@ -185,15 +192,15 @@ Ingress must be installed and have an IP address assigned before
 JupyterHub can be installed.
 
 NOTE: **Note:**
-The
-[jupyter/jupyterhub](https://jupyterhub.github.io/helm-chart/)
+The [`jupyter/jupyterhub`](https://jupyterhub.github.io/helm-chart/)
 chart is used to install this application with a
-[`values.yaml`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/vendor/jupyter/values.yaml)
+[`values.yaml`](https://gitlab.com/gitlab-org/gitlab/blob/master/vendor/jupyter/values.yaml)
 file.
 
 #### Jupyter Git Integration
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/28783) in GitLab 12.0 for project-level clusters.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/32512) in GitLab 12.3 for group and instance-level clusters.
 
 When installing JupyterHub onto your Kubernetes cluster, [JupyterLab's Git extension](https://github.com/jupyterlab/jupyterlab-git)
 is automatically provisioned and configured using the authenticated user's:
@@ -223,7 +230,7 @@ You can clone repositories from the files tab in Jupyter:
 > - Introduced in GitLab 11.5 for project-level clusters.
 > - Introduced in GitLab 12.3 for group- and instance-level clusters.
 
-[Knative](https://cloud.google.com/knative) provides a platform to
+[Knative](https://cloud.google.com/knative/) provides a platform to
 create, deploy, and manage serverless workloads from a Kubernetes
 cluster. It is used in conjunction with, and includes
 [Istio](https://istio.io) to provide an external IP address for all
@@ -234,12 +241,11 @@ domain where your applications will be exposed. Configure your DNS
 server to use the external IP address for that domain. For any
 application created and installed, they will be accessible as
 `<program_name>.<kubernetes_namespace>.<domain_name>`. This will require
-your kubernetes cluster to have [RBAC
+your Kubernetes cluster to have [RBAC
 enabled](../project/clusters/index.md#rbac-cluster-resources).
 
 NOTE: **Note:**
-The
-[knative/knative](https://storage.googleapis.com/triggermesh-charts)
+The [`knative/knative`](https://storage.googleapis.com/triggermesh-charts)
 chart is used to install this application.
 
 ### Prometheus
@@ -252,10 +258,9 @@ open-source monitoring and alerting system useful to supervise your
 deployed applications.
 
 NOTE: **Note:**
-The
-[stable/prometheus](https://github.com/helm/charts/tree/master/stable/prometheus)
+The [`stable/prometheus`](https://github.com/helm/charts/tree/master/stable/prometheus)
 chart is used to install this application with a
-[`values.yaml`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/vendor/prometheus/values.yaml)
+[`values.yaml`](https://gitlab.com/gitlab-org/gitlab/blob/master/vendor/prometheus/values.yaml)
 file.
 
 ## Upgrading applications
@@ -281,7 +286,7 @@ To upgrade an application:
 NOTE: **Note:**
 Upgrades will reset values back to the values built into the `runner`
 chart plus the values set by
-[`values.yaml`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/vendor/runner/values.yaml)
+[`values.yaml`](https://gitlab.com/gitlab-org/gitlab/blob/master/vendor/runner/values.yaml)
 
 ## Uninstalling applications
 
@@ -293,7 +298,7 @@ The applications below can be uninstalled.
 | ----------- | -------------- | ----- |
 | Cert-Manager | 12.2+         | The associated private key will be deleted and cannot be restored. Deployed applications will continue to use HTTPS, but certificates will not be renewed. Before uninstalling, you may wish to [back up your configuration](https://docs.cert-manager.io/en/latest/tasks/backup-restore-crds.html) or [revoke your certificates](https://letsencrypt.org/docs/revoking/) |
 | GitLab Runner  | 12.2+         | Any running pipelines will be canceled. |
-| Helm  | 12.2+         | The associated Tiller pod will be deleted and cannot be restored. |
+| Helm  | 12.2+         | The associated Tiller pod, the `gitlab-managed-apps` namespace, and all of its resources will be deleted and cannot be restored. |
 | Ingress  | 12.1+         | The associated load balancer and IP will be deleted and cannot be restored. Furthermore, it can only be uninstalled if JupyterHub is not installed. |
 | JupyterHub  | 12.1+         | All data not committed to GitLab will be deleted and cannot be restored. |
 | Knative  | 12.1+         | The associated IP will be deleted and cannot be restored. |
diff --git a/doc/user/clusters/environments.md b/doc/user/clusters/environments.md
index 4aef871af55..f83be85726a 100644
--- a/doc/user/clusters/environments.md
+++ b/doc/user/clusters/environments.md
@@ -1,6 +1,7 @@
 # Cluster Environments **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/13392) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.3.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/13392) for group-level clusters in [GitLab Premium](https://about.gitlab.com/pricing/) 12.3.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/14809) for instance-level clusters in [GitLab Premium](https://about.gitlab.com/pricing/) 12.4.
 
 Cluster environments provide a consolidated view of which CI [environments](../../ci/environments.md) are
 deployed to the Kubernetes cluster and it:
@@ -10,12 +11,6 @@ deployed to the Kubernetes cluster and it:
 
 ## Overview
 
-NOTE: **Note:**
-Cluster environments are only available for
-[group-level clusters](../group/clusters/index.md).
-Support for [instance-level](../instance/clusters/index.md) clusters is
-[planned](https://gitlab.com/gitlab-org/gitlab-ce/issues/63985).
-
 With cluster environments, you can gain insight into:
 
 - Which projects are deployed to the cluster.
@@ -37,7 +32,7 @@ In order to:
 - Show pod usage correctly, you must
   [enable Deploy Boards](../project/deploy_boards.md#enabling-deploy-boards).
 
-Once you have successful deployments to your group-level cluster:
+Once you have successful deployments to your group-level or instance-level cluster:
 
 1. Navigate to your group's **Kubernetes** page.
 1. Click on the **Environments** tab.
diff --git a/doc/user/clusters/management_project.md b/doc/user/clusters/management_project.md
new file mode 100644
index 00000000000..37308ad7175
--- /dev/null
+++ b/doc/user/clusters/management_project.md
@@ -0,0 +1,101 @@
+# Cluster management project (alpha)
+
+CAUTION: **Warning:**
+This is an _alpha_ feature, and it is subject to change at any time without
+prior notice.
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/17866) in GitLab 12.4
+
+A project can be designated as the management project for a cluster.
+A management project can be used to run deployment jobs with
+Kubernetes
+[`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)
+privileges.
+
+This can be useful for:
+
+- Creating pipelines to install cluster-wide applications into your cluster.
+- Any jobs that require `cluster-admin` privileges.
+
+## Permissions
+
+Only the management project will receive `cluster-admin` privileges. All
+other projects will continue to receive [namespace scoped `edit` level privileges](../project/clusters/index.md#rbac-cluster-resources).
+
+## Usage
+
+### Selecting a cluster management project
+
+This will be implemented as part of [this
+issue](https://gitlab.com/gitlab-org/gitlab/issues/32810).
+
+### Configuring your pipeline
+
+After designating a project as the management project for the cluster,
+write a [`.gitlab-ci,yml`](../../ci/yaml/README.md) in that project. For example:
+
+```yaml
+configure cluster:
+  stage: deploy
+  script: kubectl get namespaces
+  environment:
+    name: production
+```
+
+### Setting the environment scope **(PREMIUM)**
+
+[Environment
+scopes](../project/clusters/index.md#setting-the-environment-scope-premium)
+are usable when associating multiple clusters to the same management
+project.
+
+Each scope can only be used by a single cluster for a management project.
+
+For example, let's say the following Kubernetes clusters are associated
+to a management project:
+
+| Cluster     | Environment scope |
+| ----------- | ----------------- |
+| Development | `*`               |
+| Staging     | `staging`         |
+| Production  | `production`      |
+
+The the following environments set in
+[`.gitlab-ci.yml`](../../ci/yaml/README.md) will deploy to the
+Development, Staging, and Production cluster respectively.
+
+```yaml
+stages:
+- deploy
+
+configure development cluster:
+  stage: deploy
+  script: kubectl get namespaces
+  environment:
+    name: development
+
+configure staging cluster:
+  stage: deploy
+  script: kubectl get namespaces
+  environment:
+    name: staging
+
+configure production cluster:
+  stage: deploy
+  script: kubectl get namespaces
+  environment:
+    name: production
+```
+
+## Disabling this feature
+
+This feature is enabled by default. To disable this feature, disable the
+feature flag `:cluster_management_project`.
+
+To check if the feature flag is enabled on your GitLab instance,
+please ask an administrator to execute the following in a Rails console:
+
+```ruby
+Feature.enabled?(:cluster_management_project)     # Check if it's enabled or not.
+Feature.disable(:cluster_management_project)      # Disable the feature flag.
+```
diff --git a/doc/user/discussions/index.md b/doc/user/discussions/index.md
index 98f744e6e04..dcb75a19b2a 100644
--- a/doc/user/discussions/index.md
+++ b/doc/user/discussions/index.md
@@ -24,6 +24,9 @@ You can also reply to a comment notification email to reply to the comment if
 creates another standard comment. Replying to a threaded comment creates a reply in the thread. Email replies support
 [Markdown] and [quick actions], just as if you replied from the web.
 
+NOTE: **Note:**
+There is a limit of 5,000 comments for every object, for example: issue, epic, and merge request.
+
 ## Resolvable comments and threads
 
 > **Notes:**
diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md
index 463ce2056fc..5912fc8e9f9 100644
--- a/doc/user/gitlab_com/index.md
+++ b/doc/user/gitlab_com/index.md
@@ -41,7 +41,7 @@ Host gitlab.com
 
 ## GitLab Pages
 
-Below are the settings for [GitLab Pages].
+Below are the settings for [GitLab Pages](https://about.gitlab.com/product/pages/).
 
 | Setting                     | GitLab.com        | Default       |
 | --------------------------- | ----------------  | ------------- |
@@ -103,13 +103,11 @@ Below are the shared Runners settings.
 
 | Setting                               | GitLab.com                                        | Default    |
 | -----------                           | -----------------                                 | ---------- |
-| [GitLab Runner]                       | [Runner versions dashboard][ci_version_dashboard] | -          |
+| [GitLab Runner]                       | [Runner versions dashboard](https://dashboards.gitlab.com/d/000000159/ci?from=now-1h&to=now&refresh=5m&orgId=1&panelId=12&fullscreen&theme=light) | - |
 | Executor                              | `docker+machine`                                  | -          |
 | Default Docker image                  | `ruby:2.5`                                        | -          |
 | `privileged` (run [Docker in Docker]) | `true`                                            | `false`    |
 
-[ci_version_dashboard]: https://dashboards.gitlab.com/dashboard/db/ci?from=now-1h&to=now&refresh=5m&orgId=1&panelId=12&fullscreen&theme=light
-
 ### `config.toml`
 
 The full contents of our `config.toml` are:
@@ -174,14 +172,22 @@ sentry_dsn = "X"
 
 ## Sidekiq
 
-GitLab.com runs [Sidekiq][sidekiq] with arguments `--timeout=4 --concurrency=4`
+GitLab.com runs [Sidekiq](https://sidekiq.org) with arguments `--timeout=4 --concurrency=4`
 and the following environment variables:
 
-| Setting                                 | GitLab.com | Default   |
-|--------                                 |----------- |--------   |
-| `SIDEKIQ_MEMORY_KILLER_MAX_RSS`         | `1000000`  | `2000000` |
-| `SIDEKIQ_MEMORY_KILLER_SHUTDOWN_SIGNAL` | `SIGKILL`  | -         |
-| `SIDEKIQ_LOG_ARGUMENTS`                 | `1`        | -         |
+| Setting                                    | GitLab.com | Default   |
+|--------                                    |----------- |--------   |
+| `SIDEKIQ_DAEMON_MEMORY_KILLER`             | -          | -         |
+| `SIDEKIQ_MEMORY_KILLER_MAX_RSS`            | `2000000`  | `2000000` |
+| `SIDEKIQ_MEMORY_KILLER_HARD_LIMIT_RSS`     | -          | -         |
+| `SIDEKIQ_MEMORY_KILLER_CHECK_INTERVAL`     | -          | `3`       |
+| `SIDEKIQ_MEMORY_KILLER_GRACE_TIME`         | -          | `900`     |
+| `SIDEKIQ_MEMORY_KILLER_SHUTDOWN_WAIT`      | -          | `30`      |
+| `SIDEKIQ_LOG_ARGUMENTS`                    | `1`        | -         |
+
+NOTE: **Note:**
+The `SIDEKIQ_MEMORY_KILLER_MAX_RSS` setting is `16000000` on Sidekiq import
+nodes and Sidekiq export nodes.
 
 ## Cron jobs
 
@@ -267,7 +273,7 @@ released depending on the type of block, as described below.
 
 If you receive a `403 Forbidden` error for all requests to GitLab.com, please
 check for any automated processes that may be triggering a block. For
-assistance, contact [GitLab Support](https://support.gitlab.com)
+assistance, contact [GitLab Support](https://support.gitlab.com/hc/en-us)
 with details, such as the affected IP address.
 
 ### HAProxy API throttle
@@ -308,9 +314,7 @@ This header is included in responses to blocked requests:
 Retry-After: 60
 ```
 
-Source:
-
-- Search for `rate_limit_requests_per_period`, `rate_limit_period`, and `rack_attack_protected_paths` in [GitLab.com's current Rails app settings](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/attributes/default.rb).
+See [Protected Paths](../admin_area/settings/protected_paths.md) for more details.
 
 #### Git and container registry failed authentication ban
 
@@ -347,47 +351,45 @@ publicly available at [chef cookbooks](https://gitlab.com/gitlab-cookbooks).
 
 We use Elasticsearch, logstash, and Kibana for part of our monitoring solution:
 
-- [gitlab-cookbooks / gitlab-elk · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-elk)
-- [gitlab-cookbooks / gitlab_elasticsearch · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab_elasticsearch)
+- [`gitlab-cookbooks` / `gitlab-elk` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-elk)
+- [`gitlab-cookbooks` / `gitlab_elasticsearch` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab_elasticsearch)
 
 ### Prometheus
 
 Prometheus complete our monitoring stack:
 
-- [gitlab-cookbooks / gitlab-prometheus · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-prometheus)
+- [`gitlab-cookbooks` / `gitlab-prometheus` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-prometheus)
 
 ### Grafana
 
 For the visualization of monitoring data:
 
-- [gitlab-cookbooks / gitlab-grafana · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-grafana)
+- [`gitlab-cookbooks` / `gitlab-grafana` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-grafana)
 
 ### Sentry
 
 Open source error tracking:
 
-- [gitlab-cookbooks / gitlab-sentry · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-sentry)
+- [`gitlab-cookbooks` / `gitlab-sentry` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-sentry)
 
 ### Consul
 
 Service discovery:
 
-- [gitlab-cookbooks / gitlab_consul · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab_consul)
+- [`gitlab-cookbooks` / `gitlab_consul` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab_consul)
 
 ### Haproxy
 
 High Performance TCP/HTTP Load Balancer:
 
-- [gitlab-cookbooks / gitlab-haproxy · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-haproxy)
+- [`gitlab-cookbooks` / `gitlab-haproxy` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-haproxy)
 
 [autoscale mode]: https://docs.gitlab.com/runner/configuration/autoscale.html "How Autoscale works"
-[runners-post]: https://about.gitlab.com/2016/04/05/shared-runners/ "Shared Runners on GitLab.com"
+[runners-post]: https://about.gitlab.com/blog/2016/04/05/shared-runners/ "Shared Runners on GitLab.com"
 [GitLab Runner]: https://gitlab.com/gitlab-org/gitlab-runner
-[altssh]: https://about.gitlab.com/2016/02/18/gitlab-dot-com-now-supports-an-alternate-git-plus-ssh-port/ "GitLab.com now supports an alternate git+ssh port"
-[GitLab Pages]: https://about.gitlab.com/features/pages "GitLab Pages"
+[altssh]: https://about.gitlab.com/blog/2016/02/18/gitlab-dot-com-now-supports-an-alternate-git-plus-ssh-port/ "GitLab.com now supports an alternate git+ssh port"
 [docker in docker]: https://hub.docker.com/_/docker/ "Docker in Docker at DockerHub"
 [mailgun]: https://www.mailgun.com/ "Mailgun website"
-[sidekiq]: http://sidekiq.org/ "Sidekiq website"
 [unicorn-worker-killer]: https://rubygems.org/gems/unicorn-worker-killer "unicorn-worker-killer"
 [4010]: https://gitlab.com/gitlab-com/infrastructure/issues/4010 "Find a good value for maximum timeout for Shared Runners"
 [4070]: https://gitlab.com/gitlab-com/infrastructure/issues/4070 "Configure per-runner timeout for shared-runners-manager-X on GitLab.com"
diff --git a/doc/user/group/clusters/index.md b/doc/user/group/clusters/index.md
index 1eed1281bba..4742e7189b7 100644
--- a/doc/user/group/clusters/index.md
+++ b/doc/user/group/clusters/index.md
@@ -18,7 +18,7 @@ your group, enabling you to use the same cluster across multiple projects.
 GitLab can install and manage some applications in your group-level
 cluster. For more information on installing, upgrading, uninstalling,
 and troubleshooting applications for your group cluster, see
-[Gitlab Managed Apps](../../clusters/applications.md).
+[GitLab Managed Apps](../../clusters/applications.md).
 
 ## RBAC compatibility
 
@@ -139,7 +139,9 @@ The result will then be:
 
 ## Cluster environments **(PREMIUM)**
 
-Please see the documentation for [cluster environments](../../clusters/environments.md).
+For a consolidated view of which CI [environments](../../../ci/environments.md)
+are deployed to the Kubernetes cluster, see the documentation for
+[cluster environments](../../clusters/environments.md).
 
 ## Security of Runners
 
diff --git a/doc/user/group/custom_project_templates.md b/doc/user/group/custom_project_templates.md
index 094732e6a93..e47a281141d 100644
--- a/doc/user/group/custom_project_templates.md
+++ b/doc/user/group/custom_project_templates.md
@@ -7,7 +7,7 @@ type: reference
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/6861) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.6.
 
 When you create a new [project](../project/index.md), creating it based on custom project templates is
-a convenient bootstrap option.
+a convenient option.
 
 Users can configure a GitLab group that serves as template
 source under a group's **Settings > General > Custom project templates**.
diff --git a/doc/user/group/epics/img/child_epics_roadmap.png b/doc/user/group/epics/img/child_epics_roadmap.png
deleted file mode 100644
index 819fed58989..00000000000
--- a/doc/user/group/epics/img/child_epics_roadmap.png
+++ /dev/null
diff --git a/doc/user/group/epics/img/epic_view.png b/doc/user/group/epics/img/epic_view.png
deleted file mode 100644
index c55d302ec29..00000000000
--- a/doc/user/group/epics/img/epic_view.png
+++ /dev/null
diff --git a/doc/user/group/epics/img/epic_view_roadmap_v12.3.png b/doc/user/group/epics/img/epic_view_roadmap_v12.3.png
new file mode 100755
index 00000000000..a17c56c618b
--- /dev/null
+++ b/doc/user/group/epics/img/epic_view_roadmap_v12.3.png
diff --git a/doc/user/group/epics/img/epic_view_v12.3.png b/doc/user/group/epics/img/epic_view_v12.3.png
new file mode 100755
index 00000000000..79758cf3d52
--- /dev/null
+++ b/doc/user/group/epics/img/epic_view_v12.3.png
diff --git a/doc/user/group/epics/img/epics_list_view.png b/doc/user/group/epics/img/epics_list_view.png
deleted file mode 100644
index b30608d9d31..00000000000
--- a/doc/user/group/epics/img/epics_list_view.png
+++ /dev/null
diff --git a/doc/user/group/epics/img/epics_list_view_v12.3.png b/doc/user/group/epics/img/epics_list_view_v12.3.png
new file mode 100755
index 00000000000..c6817a503e7
--- /dev/null
+++ b/doc/user/group/epics/img/epics_list_view_v12.3.png
diff --git a/doc/user/group/epics/index.md b/doc/user/group/epics/index.md
index d04ecedc7a2..f9690d4edfe 100644
--- a/doc/user/group/epics/index.md
+++ b/doc/user/group/epics/index.md
@@ -10,13 +10,13 @@ Epics let you manage your portfolio of projects more efficiently and with less
 effort by tracking groups of issues that share a theme, across projects and
 milestones.
 
-![epics list view](img/epics_list_view.png)
+![epics list view](img/epics_list_view_v12.3.png)
 
 ## Use cases
 
 - Suppose your team is working on a large feature that involves multiple discussions throughout different issues created in distinct projects within a [Group](../index.md). With Epics, you can track all the related activities that together contribute to that single feature.
 - Track when the work for the group of issues is targeted to begin, and when it is targeted to end.
-- Discuss and collaborate on feature ideas and scope at a high-level.
+- Discuss and collaborate on feature ideas and scope at a high level.
 
 ## Creating an epic
 
@@ -24,78 +24,114 @@ A paginated list of epics is available in each group from where you can create
 a new epic. The list of epics includes also epics from all subgroups of the
 selected group. From your group page:
 
-1. Go to **Epics**
-1. Click the **New epic** button at the top right
-1. Enter a descriptive title and hit **Create epic**
+1. Go to **Epics**.
+1. Click **New epic**.
+1. Enter a descriptive title and click **Create epic**.
 
-Once created, you will be taken to the view for that newly-created epic where
-you can change its title, description, start date, and due date.
+You will be taken to the new epic where can edit the following details:
 
-![epic view](img/epic_view.png)
+- Title
+- Description
+- Start date
+- Due date
+- Labels
+
+An epic's page contains the following tabs:
+
+- **Epics and Issues**: epics and issues added to this epic. Child epics, and their issues, are shown in a tree view.
+  - Click on the <kbd>></kbd> beside a parent epic to reveal the child epics and issues.
+- **Roadmap**: a roadmap view of child epics which have start and due dates.
+
+![epic view](img/epic_view_v12.3.png)
 
 ## Adding an issue to an epic
 
+Any issue that belongs to a project in the epic's group, or any of the epic's
+subgroups, are eligible to be added.  New issues appear at the top of the list of issues in the **Epics and Issues** tab.
+
 An epic contains a list of issues and an issue can be associated with at most
-one epic. When on an epic, you can add its associated issues:
+one epic. When you add an issue to an epic that is already associated with another epic,
+the issue is automatically removed from the previous epic.
+
+To add an issue to an epic:
 
-1. Click the plus icon (<kbd>+</kbd>) under the epic description.
-1. Paste the link of the issue (you can hit <kbd>Spacebar</kbd> to add more than
-   one issues at a time).
+1. Click **Add an issue**.
+1. Paste the link of the issue.
+   - Press <kbd>Spacebar</kbd> and repeat this step if there are multiple issues.
 1. Click **Add**.
 
-Any issue belonging to a project in the epic's group or any of the epic's
-subgroups are eligible to be added. To remove an issue from an epic, click
-on the <kbd>x</kbd> button in the epic's issue list.
+To remove an issue from an epic:
 
-NOTE: **Note:**
-When you add an issue or an epic to an epic that's already associated with another epic,
-the issue or the epic is automatically removed from the previous epic.
+1. Click on the <kbd>x</kbd> button in the epic's issue list.
+1. Click **Remove** in the **Remove issue** warning message.
 
 ## Multi-level child epics
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/8333) in GitLab Ultimate 11.7.
 
-Much like adding issues to an epic, an epic can have multiple child epics with
-the maximum depth being 5. To add a child epic:
+Any epic that belongs to a group, or subgroup of the parent epic's group, is
+eligible to be added. New child epics appear at the top of the list of epics in the **Epics and Issues** tab.
+
+When you add a child epic that is already associated with another epic,
+that epic is automatically removed from the previous epic.
 
-1. Click the plus icon (<kbd>+</kbd>) under the epic description.
+An epic can have multiple child epics with
+the maximum depth being 5.
+
+To add a child epic:
+
+1. Click **Add an epic**.
 1. Paste the link of the epic.
+   - Press <kbd>Spacebar</kbd> and repeat this step if there are multiple issues.
 1. Click **Add**.
 
-Any epic that belongs to a group or subgroup of the parent epic's group is
-eligible to be added. To remove a child epic from a parent epic,
-click on the <kbd>x</kbd> button in the parent epic's epic list.
+To remove a child epic from a parent epic:
+
+1. Click on the <kbd>x</kbd> button in the parent epic's list of epics.
+1. Click **Remove** in the **Remove epic** warning message.
 
 ## Start date and due date
 
-For each of the dates in the sidebar of an epic, you can choose to either:
+To set a **Start date** and **Due date** for an epic, you can choose either of the following:
 
-- Enter a fixed value.
-- Inherit a dynamic value called "From milestones".
+- **Fixed**: Enter a fixed value.
+- **From milestones:** Inherit a dynamic value from the issues added to the epic.
 
-If you select "From milestones" for the start date, GitLab will automatically set the
+If you select **From milestones** for the start date, GitLab will automatically set the
 date to be earliest start date across all milestones that are currently assigned
-to the issues that are attached to the epic. Similarly, if you select "From milestones"
+to the issues that are added to the epic. Similarly, if you select "From milestones"
 for the due date, GitLab will set it to be the latest due date across all
 milestones that are currently assigned to those issues.
 
-These are dynamic dates in that if milestones are re-assigned to the issues, if the
-milestone dates change, or if issues are added or removed from the epic, then
-the re-calculation will happen immediately to set a new dynamic date.
+These are dynamic dates which are recalculated immediately if any of the following occur:
+
+- Milestones are re-assigned to the issues.
+- Milestone dates change.
+- Issues are added or removed from the epic.
 
-## Roadmap in epics
+## Roadmap
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/7327) in [GitLab Ultimate](https://about.gitlab.com/pricing) 11.10.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/7327) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.10.
 
 If your epic contains one or more [child epics](#multi-level-child-epics) which
-have a [start or due date](#start-date-and-due-date), then you can see a
-[roadmap](../roadmap/index.md) view of the child epics under the parent epic itself.
+have a [start or due date](#start-date-and-due-date), a
+[roadmap](../roadmap/index.md) view of the child epics is listed under the parent epic.
 
-![Child epics roadmap](img/child_epics_roadmap.png)
+![Child epics roadmap](img/epic_view_roadmap_v12.3.png)
 
 ## Reordering issues and child epics
 
-Drag and drop to reorder issues and child epics. New issues and child epics added to an epic appear at the top of the list.
+New issues and child epics are added to the top of their respective lists in the **Epics and Issues** tab. You can reorder the list of issues and the list of child epics. Issues and child epics cannot be intermingled.
+
+To reorder issues assigned to an epic:
+
+1. Go to the **Epics and Issues** tab.
+1. Drag and drop issues into the desired order.
+
+To reorder child epics assigned to an epic:
+
+1. Go to the **Epics and Issues** tab.
+1. Drag and drop epics into the desired order.
 
 ## Updating epics
 
diff --git a/doc/user/group/index.md b/doc/user/group/index.md
index 036730ba700..c4be08c842b 100644
--- a/doc/user/group/index.md
+++ b/doc/user/group/index.md
@@ -17,7 +17,7 @@ Find your groups by clicking **Groups > Your Groups** in the top navigation.
 
 ![GitLab Groups](img/groups.png)
 
-> The **Groups** dropdown in the top navigation was [introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/36234) in [GitLab 11.1](https://about.gitlab.com/2018/07/22/gitlab-11-1-released/#groups-dropdown-in-navigation).
+> The **Groups** dropdown in the top navigation was [introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/36234) in [GitLab 11.1](https://about.gitlab.com/blog/2018/07/22/gitlab-11-1-released/#groups-dropdown-in-navigation).
 
 The **Groups** page displays:
 
@@ -178,18 +178,20 @@ There are two different ways to add a new project to a group:
 
 ### Default project-creation level
 
-> [Introduced][ee-2534] in [GitLab Premium][ee] 10.5.
-> Brought to [GitLab Starter][ee] in 10.7.
-> [Moved](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/25975) to [GitLab Core](https://about.gitlab.com/pricing/) in 11.10.
+> - [Introduced][ee-2534] in [GitLab Premium][ee] 10.5.
+> - Brought to [GitLab Starter][ee] in 10.7.
+> - [Moved](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/25975) to [GitLab Core](https://about.gitlab.com/pricing/) in 11.10.
 
-Group owners and administrators can allow users with the
-Developer role to create projects under groups.
+By default, [Developers and Maintainers](../permissions.md#group-members-permissions) can create projects under a group.
 
-By default, [Developers and Maintainers](../permissions.md#group-members-permissions) can create projects under a group. You can change this setting for a specific group within the group settings, or
-you can set this option globally in the Admin area
-at **Settings > General > Visibility and access controls** (you must be a GitLab administrator).
+To change this setting for a specific group:
 
-Available settings are `No one`, `Maintainers`, or `Developers + Maintainers`.
+1. Go to the group's **Settings > General** page.
+1. Expand the **Permissions, LFS, 2FA** section.
+1. Select the desired option in the **Allowed to create projects** dropdown list.
+1. Click **Save changes**.
+
+To change this setting globally, see [Default project creation protection](../admin_area/settings/visibility_and_access_controls.md#default-project-creation-protection).
 
 ## Transfer projects into groups
 
@@ -334,10 +336,9 @@ This will disable the option for all users who previously had permissions to
 operate project memberships, so no new users can be added. Furthermore, any
 request to add a new user to a project through API will not be possible.
 
-#### IP access restriction **(ULTIMATE ONLY)**
+#### IP access restriction **(ULTIMATE)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1985) in
-[GitLab Ultimate](https://about.gitlab.com/pricing/) 12.0.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1985) in [GitLab Ultimate and Gold](https://about.gitlab.com/pricing/) 12.0.
 
 To make sure only people from within your organization can access particular
 resources, you have the option to restrict access to groups and their
@@ -349,16 +350,20 @@ Add one or more whitelisted IP subnets using CIDR notation in comma separated fo
 coming from a different IP address won't be able to access the restricted
 content.
 
-Restriction currently applies to UI and API access, Git actions via ssh are not restricted.
+Restriction currently applies to:
+
+- UI.
+- API access.
+- [From GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/issues/32113), Git actions via SSH.
+
 To avoid accidental lock-out, admins and group owners are are able to access
 the group regardless of the IP restriction.
 
-#### Allowed domain restriction **(PREMIUM ONLY)**
+#### Allowed domain restriction **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/7297) in
-[GitLab Premium](https://about.gitlab.com/pricing/) 12.2.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/7297) in [GitLab Premium and Silver](https://about.gitlab.com/pricing/) 12.2.
 
-You can restrict access to groups and their underlying projects by
+You can restrict access to groups by
 allowing only users with email addresses in particular domains to be added to the group.
 
 Add email domains you want to whitelist and users with emails from different
@@ -449,6 +454,11 @@ For performance reasons, we may delay the update up to 1 hour and 30 minutes.
 
 If your namespace shows `N/A` as the total storage usage, you can trigger a recalculation by pushing a commit to any project in that namespace.
 
+### Maximum artifacts size **(CORE ONLY)**
+
+For information about setting a maximum artifact size for a group, see
+[Maximum artifacts size](../admin_area/settings/continuous_integration.md#maximum-artifacts-size-core-only).
+
 ## User contribution analysis **(STARTER)**
 
 With [GitLab Contribution Analytics](contribution_analytics/index.md),
diff --git a/doc/user/group/roadmap/index.md b/doc/user/group/roadmap/index.md
index a72cd990706..bcd79bd04bf 100644
--- a/doc/user/group/roadmap/index.md
+++ b/doc/user/group/roadmap/index.md
@@ -26,7 +26,7 @@ Epics in the view can be sorted by:
 Each option contains a button that toggles the sort order between **ascending** and **descending**. The sort option and order will be persisted when browsing Epics,
 including the [epics list view](../epics/index.md).
 
-Roadmaps can also be [visualized inside an epic](../epics/index.md#roadmap-in-epics).
+Roadmaps can also be [visualized inside an epic](../epics/index.md#roadmap).
 
 ## Timeline duration
 
diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md
index 90e4dacbd76..ecf2934b877 100644
--- a/doc/user/group/saml_sso/index.md
+++ b/doc/user/group/saml_sso/index.md
@@ -64,7 +64,10 @@ GitLab.com uses the SAML NameID to identify users. The NameID element:
 
 - Is a required field in the SAML response.
 - Must be unique to each user.
-- Must be a persistent value that will never change, such as a unique ID or username. Email could also be used as the NameID, but only if it can be guaranteed to never change.
+- Must be a persistent value that will never change, such as a randomly generated unique user ID.
+- Is case sensitive. The NameID must match exactly on subsequent login attempts, so should not rely on user input that could change between upper and lower case.
+
+We strongly recommend against using Email as the NameID as it is hard to guarantee it will never change, for example when a person's name changes. Similarly usernames should be avoided if possible.
 
 ### Assertions
 
@@ -97,16 +100,37 @@ Once you've set up your identity provider to work with GitLab, you'll need to co
 
 ## Providers
 
+NOTE: **Note:** GitLab is unable to provide support for IdPs that are not listed here.
+
 | Provider | Documentation |
 |----------|---------------|
 | ADFS (Active Directory Federation Services) | [Create a Relying Party Trust](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/create-a-relying-party-trust) |
-| Azure | [Configuring single sign-on to applications](https://docs.microsoft.com/en-us/azure/active-directory/active-directory-saas-custom-apps) |
+| Azure | [Configuring single sign-on to applications](https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-single-sign-on-non-gallery-applications) |
 | Auth0 | [Auth0 as Identity Provider](https://auth0.com/docs/protocols/saml/saml-idp-generic) |
 | G Suite | [Set up your own custom SAML application](https://support.google.com/a/answer/6087519?hl=en) |
 | JumpCloud | [Single Sign On (SSO) with GitLab](https://support.jumpcloud.com/customer/en/portal/articles/2810701-single-sign-on-sso-with-gitlab) |
-| Okta | [Setting up a SAML application in Okta](https://developer.okta.com/standards/SAML/setting_up_a_saml_application_in_okta) |
+| Okta | [Setting up a SAML application in Okta](https://developer.okta.com/docs/guides/saml-application-setup/overview/) |
 | OneLogin | [Use the OneLogin SAML Test Connector](https://onelogin.service-now.com/support?id=kb_article&sys_id=93f95543db109700d5505eea4b96198f) |
-| Ping Identity | [Add and configure a new SAML application](https://docs.pingidentity.com/bundle/p1_enterpriseConfigSsoSaml_cas/page/enableAppWithoutURL.html) |
+| Ping Identity | [Add and configure a new SAML application](https://support.pingidentity.com/s/document-item?bundleId=pingone&topicId=xsh1564020480660-1.html) |
+
+When [configuring your identify provider](#configuring-your-identity-provider), please consider the notes below for specific providers to help avoid common issues and as a guide for terminology used.
+
+### OneLogin setup notes
+
+NOTE: **Note:**
+The GitLab app listed in the directory is for self-managed GitLab instances. Please use a generic SAML Test Connector.
+
+| GitLab Setting | OneLogin Field |
+|--------------|----------------|
+| Identifier | Audience |
+| Assertion consumer service URL | Recipient |
+| Assertion consumer service URL | ACS (Consumer) URL |
+| Assertion consumer service URL (escaped version) | ACS (Consumer) URL Validator |
+| GitLab single sign on URL | Login URL |
+
+Recommended `NameID` value: `OneLogin ID`.
+
+Set parameters according to the [assertions table](#assertions).
 
 ## Linking SAML to your existing GitLab.com account
 
@@ -148,14 +172,41 @@ For example, to unlink the `MyOrg` account, the following **Disconnect** button
 | Issuer | How GitLab identifies itself to the identity provider. Also known as a "Relying party trust identifier". |
 | Certificate fingerprint | Used to confirm that communications over SAML are secure by checking that the server is signing communications with the correct certificate. Also known as a certificate thumbprint. |
 
-<!-- ## Troubleshooting
+## Troubleshooting
+
+### SAML debugging tools
+
+SAML responses are base64 encoded, so we recommend the following browser plugins to decode them on the fly:
+
+- [SAML tracer for Firefox](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/)
+- [Chrome SAML Panel](https://chrome.google.com/webstore/detail/saml-chrome-panel/paijfdbeoenhembfhkhllainmocckace?hl=en)
+
+Specific attention should be paid to:
+
+- The [NameID](#nameid), which we use to identify which user is signing in. If the user has previously signed in, this [must match the value we have stored](#verifying-nameid).
+- The presence of a `X509Certificate`, which we require to verify the response signature.
+- The `SubjectConfirmation` and `Conditions`, which can cause errors if misconfigured.
+
+### Verifying NameID
+
+In troubleshooting the Group SAML setup, any authenticated user can use the API to verify the NameID GitLab already has linked to the user by visiting [https://gitlab.com/api/v4/user](https://gitlab.com/api/v4/user) and checking the `extern_uid` under identities.
+
+This can then be compared to the [NameID](#nameid) being sent by the Identity Provider by decoding the message with a [SAML debugging tool](#saml-debugging-tools). We require that these match in order to identify users.
+
+### Message: "SAML authentication failed: Extern uid has already been taken"
+
+This error suggests you are signed in as a GitLab user but have already linked your SAML identity to a different GitLab user. Sign out and then try to sign in again using the SSO SAML link, which should log you into GitLab with the linked user account.
+
+If you do not wish to use that GitLab user with the SAML login, you can [unlink the GitLab account from the group's SAML](#unlinking-accounts).
+
+### Message: "SAML authentication failed: User has already been taken"
+
+The user you are signed in with already has SAML linked to a different identity. This might mean you've attempted to link multiple SAML identities to the same user for a given Identity Provider. This could also be a symptom of the Identity Provider returning an inconsistent [NameID](#nameid).
+
+To change which identity you sign in with, you can [unlink the previous SAML identity](#unlinking-accounts) from this GitLab account.
+
+### Message: "SAML authentication failed: Extern uid has already been taken, User has already been taken"
 
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-questions that you know someone might ask.
+Getting both of these errors at the same time suggests the NameID capitalization provided by the Identity Provider didn't exactly match the previous value for that user.
 
-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. -->
+This can be prevented by configuring the [NameID](#nameid) to return a consistent value. Fixing this for an individual user involves [unlinking SAML in the GitLab account](#unlinking-accounts), although this will cause group membership and Todos to be lost.
diff --git a/doc/user/group/subgroups/index.md b/doc/user/group/subgroups/index.md
index eec929e3309..a3606fadb89 100644
--- a/doc/user/group/subgroups/index.md
+++ b/doc/user/group/subgroups/index.md
@@ -4,8 +4,7 @@ type: reference, howto, concepts
 
 # Subgroups
 
-NOTE: **Note:**
-[Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/2772) in GitLab 9.0.
+>[Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/2772) in GitLab 9.0.
 
 Subgroups, also known as nested groups or hierarchical groups, allow you to have up to 20
 levels of groups.
@@ -68,9 +67,9 @@ Another example of GitLab as a company would be the following:
 The maximum subgroups a group can have, including the first one in the
 hierarchy, is 21.
 
-Actions such as transferring or importing a project inside subgroups, work like
-when performing these actions the traditional way with the `group/project`
-structure.
+When performing actions such as transferring or importing a project between
+subgroups, the behavior is the same as when performing these actions at the
+`group/project` level.
 
 ## Creating a subgroup
 
@@ -117,6 +116,10 @@ When you add a member to a subgroup, they inherit the membership and permission
 level from the parent group. This model allows access to nested groups if you
 have membership in one of its parents.
 
+Jobs for pipelines in subgroups can use [Runners](../../../ci/runners/README.md) registered to the parent group. This means secrets configured for the parent group are available to subgroup jobs.
+
+In addition, maintainers of projects that belong to subgroups can see the details of Runners registered to parent groups.
+
 The group permissions for a member can be changed only by Owners, and only on
 the **Members** page of the group the member was added.
 
diff --git a/doc/user/img/markdown_audio.mp3 b/doc/user/img/markdown_audio.mp3
new file mode 100644
index 00000000000..8946c3b3b10
--- /dev/null
+++ b/doc/user/img/markdown_audio.mp3
diff --git a/doc/user/index.md b/doc/user/index.md
index e1833cab6b8..ee5d4a0a07b 100644
--- a/doc/user/index.md
+++ b/doc/user/index.md
@@ -26,11 +26,11 @@ For more information, see [All GitLab Features](https://about.gitlab.com/feature
 
 To get familiar with the concepts needed to develop code on GitLab, read the following articles:
 
-- [Demo: Mastering Code Review With GitLab](https://about.gitlab.com/2017/03/17/demo-mastering-code-review-with-gitlab/).
-- [GitLab Workflow: An Overview](https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#gitlab-workflow-use-case-scenario).
-- [Tutorial: It's all connected in GitLab](https://about.gitlab.com/2016/03/08/gitlab-tutorial-its-all-connected/): an overview on code collaboration with GitLab.
-- [Trends in Version Control Land: Microservices](https://about.gitlab.com/2016/08/16/trends-in-version-control-land-microservices/).
-- [Trends in Version Control Land: Innersourcing](https://about.gitlab.com/2016/07/07/trends-version-control-innersourcing/).
+- [Demo: Mastering Code Review With GitLab](https://about.gitlab.com/blog/2017/03/17/demo-mastering-code-review-with-gitlab/).
+- [GitLab Workflow: An Overview](https://about.gitlab.com/blog/2016/10/25/gitlab-workflow-an-overview/#gitlab-workflow-use-case-scenario).
+- [Tutorial: It's all connected in GitLab](https://about.gitlab.com/blog/2016/03/08/gitlab-tutorial-its-all-connected/): an overview on code collaboration with GitLab.
+- [Trends in Version Control Land: Microservices](https://about.gitlab.com/blog/2016/08/16/trends-in-version-control-land-microservices/).
+- [Trends in Version Control Land: Innersourcing](https://about.gitlab.com/blog/2016/07/07/trends-version-control-innersourcing/).
 
 ## Use cases
 
@@ -88,7 +88,7 @@ it all at once, from one single project.
 Use built-in [GitLab CI/CD](../ci/README.md) to test, build, and deploy your applications
 directly from GitLab. No third-party integrations needed.
 
-- [GitLab Auto Deploy](../ci/autodeploy/index.md): Deploy your application out-of-the-box with GitLab Auto Deploy.
+- [GitLab Auto Deploy](../topics/autodevops/index.md#auto-deploy): Deploy your application out-of-the-box with GitLab Auto Deploy.
 - [Review Apps](../ci/review_apps/index.md): Live-preview the changes introduced by a merge request with Review Apps.
 - [GitLab Pages](project/pages/index.md): Publish your static site directly from
   GitLab with GitLab Pages. You can build, test, and deploy any Static Site Generator with Pages.
diff --git a/doc/user/instance/clusters/index.md b/doc/user/instance/clusters/index.md
index 56693a1db1f..3d9a1eb219e 100644
--- a/doc/user/instance/clusters/index.md
+++ b/doc/user/instance/clusters/index.md
@@ -20,3 +20,9 @@ GitLab will try match to clusters in the following order:
 
 To be selected, the cluster must be enabled and
 match the [environment selector](../../../ci/environments.md#scoping-environments-with-specs).
+
+## Cluster environments **(PREMIUM)**
+
+For a consolidated view of which CI [environments](../../../ci/environments.md)
+are deployed to the Kubernetes cluster, see the documentation for
+[cluster environments](../../clusters/environments.md).
diff --git a/doc/user/markdown.md b/doc/user/markdown.md
index 3f77431aa69..0b4bb43b4bf 100644
--- a/doc/user/markdown.md
+++ b/doc/user/markdown.md
@@ -14,7 +14,7 @@ NOTE: **Note:** We encourage you to view this document as [rendered by GitLab it
 
 GitLab uses "GitLab Flavored Markdown" (GFM). It extends the [CommonMark specification](https://spec.commonmark.org/current/)
 (which is based on standard Markdown) in several ways to add additional useful functionality.
-It was inspired by [GitHub Flavored Markdown](https://help.github.com/articles/basic-writing-and-formatting-syntax/).
+It was inspired by [GitHub Flavored Markdown](https://help.github.com/en/articles/basic-writing-and-formatting-syntax).
 
 You can use GFM in the following areas:
 
@@ -108,7 +108,7 @@ changing how standard markdown is used:
 | [code blocks](#code-spans-and-blocks) | [colored code and syntax highlighting](#colored-code-and-syntax-highlighting) |
 | [emphasis](#emphasis)                 | [multiple underscores in words](#multiple-underscores-in-words-and-mid-word-emphasis)
 | [headers](#headers)                   | [linkable Header IDs](#header-ids-and-links) |
-| [images](#images)                     | [embedded videos](#videos) |
+| [images](#images)                     | [embedded videos](#videos) and [audio](#audio) |
 | [linebreaks](#line-breaks)            | [more linebreak control](#newlines) |
 | [links](#links)                       | [automatically linking URLs](#url-auto-linking) |
 
@@ -352,7 +352,7 @@ However the wrapping tags cannot be mixed:
 
 > If this is not rendered correctly, [view it in GitLab itself](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#math).
 
-It is possible to have math written with LaTeX syntax rendered using [KaTeX](https://github.com/Khan/KaTeX).
+It is possible to have math written with LaTeX syntax rendered using [KaTeX](https://github.com/KaTeX/KaTeX).
 
 Math written between dollar signs `$` will be rendered inline with the text. Math written
 inside a [code block](#code-spans-and-blocks) with the language declared as `math`, will be rendered
@@ -379,7 +379,7 @@ a^2+b^2=c^2
 _Be advised that KaTeX only supports a [subset](https://katex.org/docs/supported.html) of LaTeX._
 
 NOTE: **Note:** This also works for the asciidoctor `:stem: latexmath`. For details see
-the [asciidoctor user manual](http://asciidoctor.org/docs/user-manual/#activating-stem-support).
+the [asciidoctor user manual](https://asciidoctor.org/docs/user-manual/#activating-stem-support).
 
 ### Special GitLab references
 
@@ -641,7 +641,7 @@ Tildes are OK too.
 
 GitLab uses the [Rouge Ruby library](http://rouge.jneen.net/) for more colorful syntax
 highlighting in code blocks. For a list of supported languages visit the
-[Rouge project wiki](https://github.com/jneen/rouge/wiki/List-of-supported-languages-and-lexers).
+[Rouge project wiki](https://github.com/rouge-ruby/rouge/wiki/List-of-supported-languages-and-lexers).
 Syntax highlighting is only supported in code blocks, it is not possible to highlight
 code when it is inline.
 
@@ -899,13 +899,30 @@ Here's a sample video:
 
 ![Sample Video](img/markdown_video.mp4)
 
+#### Audio
+
+> If this is not rendered correctly, [view it in GitLab itself](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#audio).
+
+Similar to videos, link tags for files with an audio extension are automatically converted to
+an audio player. The valid audio extensions are `.mp3`, `.ogg`, and `.wav`:
+
+```md
+Here's a sample audio clip:
+
+![Sample Audio](img/markdown_audio.mp3)
+```
+
+Here's a sample audio clip:
+
+![Sample Audio](img/markdown_audio.mp3)
+
 ### Inline HTML
 
 > To see the markdown rendered within HTML in the second example, [view it in GitLab itself](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/user/markdown.md#inline-html).
 
 You can also use raw HTML in your Markdown, and it'll usually work pretty well.
 
-See the documentation for HTML::Pipeline's [SanitizationFilter](http://www.rubydoc.info/gems/html-pipeline/1.11.0/HTML/Pipeline/SanitizationFilter#WHITELIST-constant)
+See the documentation for HTML::Pipeline's [SanitizationFilter](https://www.rubydoc.info/gems/html-pipeline/1.11.0/HTML/Pipeline/SanitizationFilter#WHITELIST-constant)
 class for the list of allowed HTML tags and attributes.  In addition to the default
 `SanitizationFilter` whitelist, GitLab allows `span`, `abbr`, `details` and `summary` elements.
 
@@ -1109,8 +1126,8 @@ Using references:
 
 Some text to show that the reference links can follow later.
 
-[arbitrary case-insensitive reference text]: https://www.mozilla.org
-[1]: http://slashdot.org
+[arbitrary case-insensitive reference text]: https://www.mozilla.org/en-US/
+[1]: https://slashdot.org
 [link text itself]: https://www.reddit.com
 ```
 
@@ -1132,8 +1149,8 @@ Using references:
 
 Some text to show that the reference links can follow later.
 
-[arbitrary case-insensitive reference text]: https://www.mozilla.org
-[1]: http://slashdot.org
+[arbitrary case-insensitive reference text]: https://www.mozilla.org/en-US/
+[1]: https://slashdot.org
 [link text itself]: https://www.reddit.com
 
 NOTE: **Note:** Relative links do not allow the referencing of project files in a wiki
@@ -1147,7 +1164,7 @@ GFM will autolink almost any URL you put into your text:
 
 ```markdown
 - https://www.google.com
-- https://google.com/
+- https://www.google.com
 - ftp://ftp.us.debian.org/debian/
 - smb://foo/bar/baz
 - irc://irc.freenode.net/
@@ -1155,7 +1172,7 @@ GFM will autolink almost any URL you put into your text:
 ```
 
 - <https://www.google.com>
-- <https://google.com/>
+- <https://www.google.com>
 - <ftp://ftp.us.debian.org/debian/>
 - <smb://foo/bar/baz>
 - <irc://irc.freenode.net/>
@@ -1305,7 +1322,7 @@ Example:
 
 ```markdown
 | header 1 | header 2 | header 3 |
-| ---      |  ------  |----------|
+| ---      |  ------  |---------:|
 | cell 1   | cell 2   | cell 3   |
 | cell 4 | cell 5 is longer | cell 6 is much longer than the others, but that's ok. It will eventually wrap the text when the cell is too large for the display size. |
 | cell 7   |          | cell <br> 9 |
diff --git a/doc/user/packages/conan_repository/img/conan_package_view.png b/doc/user/packages/conan_repository/img/conan_package_view.png
new file mode 100644
index 00000000000..79a188d7856
--- /dev/null
+++ b/doc/user/packages/conan_repository/img/conan_package_view.png
diff --git a/doc/user/packages/conan_repository/index.md b/doc/user/packages/conan_repository/index.md
new file mode 100644
index 00000000000..f81756f7979
--- /dev/null
+++ b/doc/user/packages/conan_repository/index.md
@@ -0,0 +1,135 @@
+# GitLab Conan Repository **(PREMIUM)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/8248) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.4.
+
+With the GitLab Conan Repository, every
+project can have its own space to store Conan packages.
+
+![GitLab Conan Repository](img/conan_package_view.png)
+
+## Enabling the Conan Repository
+
+NOTE: **Note:**
+This option is available only if your GitLab administrator has
+[enabled support for the Conan Repository](../../../administration/packages/index.md).**(PREMIUM ONLY)**
+
+After the Conan Repository is enabled, it will be available for all new projects
+by default. To enable it for existing projects, or if you want to disable it:
+
+1. Navigate to your project's **Settings > General > Permissions**.
+1. Find the Packages feature and enable or disable it.
+1. Click on **Save changes** for the changes to take effect.
+
+You should then be able to see the **Packages** section on the left sidebar.
+
+Before proceeding to authenticating with the GitLab Conan Repository, you should
+get familiar with the package naming convention.
+
+## Authenticating to the GitLab Conan Repository
+
+You will need to generate a [personal access token](../../../user/profile/personal_access_tokens.md) for repository authentication.
+
+Now you can run conan commands using your token.
+
+`CONAN_LOGIN_USERNAME=<gitlab-username> CONAN_PASSWORD=<personal_access_token> conan upload Hello/0.2@user/channel --remote=gitlab`
+`CONAN_LOGIN_USERNAME=<gitlab-username> CONAN_PASSWORD=<personal_access_token> conan search Hello* --all --remote=gitlab`
+
+Alternatively, you can set the `CONAN_LOGIN_USERNAME` and `CONAN_PASSWORD` in your local conan config to be used when connecting to the `gitlab` remote. The examples here show the username and password inline.
+
+Next, you'll need to set your Conan remote to point to the GitLab Package Registry.
+
+## Setting the Conan remote to the GitLab Package Registry
+
+After you authenticate to the [GitLab Conan Repository](#authenticating-to-the-gitlab-conan-repository),
+you can set the Conan remote:
+
+```sh
+conan remote add gitlab https://gitlab.example.com/api/v4/packages/conan
+```
+
+Once the remote is set, you can use the remote when running Conan commands:
+
+```sh
+conan search Hello* --all --remote=gitlab
+```
+
+## Supported CLI commands
+
+The GitLab Conan repository supports the following Conan CLI commands:
+
+- `conan upload`: Upload your recipe and package files to the GitLab Package Registry.
+- `conan install`: Install a conan package from the GitLab Package Registry, this includes using the `conan.txt` file.
+- `conan search`: Search the GitLab Package Registry for public packages, and private packages you have permission to view.
+- `conan info`: View the info on a given package from the GitLab Package Registry.
+- `conan remove`: Delete the package from the GitLab Package Registry.
+
+## Uploading a package
+
+First you need to [create your Conan package locally](https://docs.conan.io/en/latest/creating_packages/getting_started.html). In order to work with the GitLab Package Registry, a specific [naming convention](#package-recipe-naming-convention) must be followed.
+
+Ensure you have a project created on GitLab and that the personal access token you are using has the correct permissions for write access to the container registry by selecting the `api` [scope](../../../user/profile/personal_access_tokens.md#limiting-scopes-of-a-personal-access-token).
+
+You can upload your package to the GitLab Package Registry using the `conan upload` command:
+
+```sh
+CONAN_LOGIN_USERNAME=<gitlab-username> CONAN_PASSWORD=<personal_access_token> conan upload Hello/0.1@my-group+my-project/beta --all --remote=gitlab
+```
+
+### Package recipe naming convention
+
+Standard Conan recipe convention looks like `package_name/version@username/channel`.
+
+**Recipe usernames must be the `+` separated project path**. The package
+name may be anything, but it is preferred that the project name be used unless
+it is not possible due to a naming collision. For example:
+
+| Project                            | Package                                         | Supported |
+| ---------------------------------- | ----------------------------------------------- | --------- |
+| `foo/bar`                          | `my-package/1.0.0@foo+bar/stable`               | Yes       |
+| `foo/bar-baz/buz`                  | `my-package/1.0.0@foo+bar-baz+buz/stable`       | Yes       |
+| `gitlab-org/gitlab-ce`             | `my-package/1.0.0@gitlab-org+gitlab-ce/stable`  | Yes       |
+| `gitlab-org/gitlab-ce`             | `my-package/1.0.0@foo/stable`                   | No        |
+
+NOTE: **Note:**
+A future iteration will extend support to [project and group level](https://gitlab.com/gitlab-org/gitlab/issues/11679) remotes which will allow for more flexible naming conventions.
+
+## Installing a package
+
+Add the conan package to the `[requires]` section of your `conan.txt` file and they will be installed when you run `conan install` within your project.
+
+## Removing a package
+
+There are two ways to remove a Conan package from the GitLab Package Registry.
+
+- **Using the Conan client in the command line:**
+
+  ```sh
+  CONAN_LOGIN_USERNAME=<gitlab-username> CONAN_PASSWORD=<personal_access_token> conan remove Hello/0.2@user/channel -r gitlab
+  ```
+
+  NOTE: **Note:**
+  This command will remove all recipe and binary package files from the Package Registry.
+
+- **GitLab project interface**: in the packages view of your project page, you can delete packages by clicking the red trash icons.
+
+## Searching the GitLab Package Registry for Conan packages
+
+The `conan search` command can be run searching by full or partial package name, or by exact recipe.
+
+To search using a partial name, use the wildcard symbol `*`, which should be placed at the end of your search (e.g., `my-packa*`):
+
+```sh
+CONAN_LOGIN_USERNAME=<gitlab-username> CONAN_PASSWORD=<personal_access_token> conan search Hello --all --remote=gitlab
+CONAN_LOGIN_USERNAME=<gitlab-username> CONAN_PASSWORD=<personal_access_token> conan search He* --all --remote=gitlab
+CONAN_LOGIN_USERNAME=<gitlab-username> CONAN_PASSWORD=<personal_access_token> conan search Hello/1.0.0@my-group+my-project/stable --all --remote=gitlab
+```
+
+The scope of your search will include all projects you have permission to access, this includes your private projects as well as all public projects.
+
+## Fetching Conan package info from the GitLab Package Registry
+
+The `conan info` command will return info about a given package:
+
+```sh
+CONAN_LOGIN_USERNAME=<gitlab-username> CONAN_PASSWORD=<personal_access_token> conan info Hello/1.0.0@my-group+my-project/stable -r gitlab
+```
diff --git a/doc/user/packages/index.md b/doc/user/packages/index.md
index 506eb5703a6..9873bd80e8b 100644
--- a/doc/user/packages/index.md
+++ b/doc/user/packages/index.md
@@ -10,6 +10,7 @@ The Packages feature allows GitLab to act as a repository for the following:
 | ------------------- | ----------- | --------------------------- |
 | [Container Registry](container_registry/index.md)   | The GitLab Container Registry enables every project in GitLab to have its own space to store [Docker](https://www.docker.com/) images. | 8.8+ |
 | [Dependency Proxy](dependency_proxy/index.md) **(PREMIUM)** | The GitLab Dependency Proxy sets up a local proxy for frequently used upstream images/packages. | 11.11+ |
+| [Conan Repository](conan_repository/index.md) **(PREMIUM)** | The GitLab Conan Repository enables every project in GitLab to have its own space to store [Conan](https://conan.io/) packages. | 12.4+ |
 | [Maven Repository](maven_repository/index.md) **(PREMIUM)** | The GitLab Maven Repository enables every project in GitLab to have its own space to store [Maven](https://maven.apache.org/) packages. | 11.3+ |
 | [NPM Registry](npm_registry/index.md) **(PREMIUM)**  | The GitLab NPM Registry enables every project in GitLab to have its own space to store [NPM](https://www.npmjs.com/) packages. | 11.7+ |
 
diff --git a/doc/user/packages/maven_repository/index.md b/doc/user/packages/maven_repository/index.md
index 0c0b44b3cd8..8ed10c09891 100644
--- a/doc/user/packages/maven_repository/index.md
+++ b/doc/user/packages/maven_repository/index.md
@@ -170,7 +170,7 @@ the `distributionManagement` section:
 <repositories>
   <repository>
     <id>gitlab-maven</id>
-    <url>https://gitlab.com/api/v4/groups/my-group/-/packages/maven</url>
+    <url>https://gitlab.com/api/v4/groups/GROUP_ID/-/packages/maven</url>
   </repository>
 </repositories>
 <distributionManagement>
diff --git a/doc/user/packages/npm_registry/index.md b/doc/user/packages/npm_registry/index.md
index 6d11ab603ef..5f5d86ab17e 100644
--- a/doc/user/packages/npm_registry/index.md
+++ b/doc/user/packages/npm_registry/index.md
@@ -84,6 +84,28 @@ NOTE: **Note:**
 If you encounter an error message with [Yarn](https://yarnpkg.com/en/), see the
 [troubleshooting section](#troubleshooting).
 
+### Using variables to avoid hard-coding auth token values
+
+To avoid hard-coding the `authToken` value, you may use a variables in its place.
+In your `.npmrc` file, you would add:
+
+```ini
+@foo:registry=https://gitlab.com/api/v4/packages/npm/
+//gitlab.com/api/v4/packages/npm/:_authToken=${NPM_TOKEN}
+//gitlab.com/api/v4/projects/<your_project_id>/packages/npm/:_authToken=${NPM_TOKEN}
+```
+
+Then, you could run `npm publish` either locally or via GitLab CI/CD:
+
+- **Locally:** Export `NPM_TOKEN` before publishing:
+
+  ```sh
+  NPM_TOKEN=<your_token> npm publish
+  ```
+
+- **GitLab CI/CD:** Set an `NPM_TOKEN` [variable](../../../ci/variables/README.md)
+  under your project's **Settings > CI/CD > Variables**.
+
 ## Uploading packages
 
 Before you will be able to upload a package, you need to specify the registry
@@ -145,3 +167,29 @@ with your with your OAuth or personal access token):
 ```text
 //gitlab.com/api/v4/projects/:_authToken=<your_oauth_token>
 ```
+
+### `npm publish` targets default NPM registry (`registry.npmjs.org`)
+
+Ensure that your package scope is set consistently in your `package.json` and `.npmrc` files.
+
+For example, if your project name in GitLab is `foo/my-package`, then your `package.json` file
+should look like:
+
+```json
+{
+  "name": "@foo/my-package",
+  "version": "1.0.0",
+  "description": "Example package for GitLab NPM registry",
+  "publishConfig": {
+    "@foo:registry":"https://gitlab.com/api/v4/projects/<your_project_id>/packages/npm/"
+  }
+}
+```
+
+And the `.npmrc` file should look like:
+
+```ini
+//gitlab.com/api/v4/projects/<your_project_id>/packages/npm/:_authToken=<your_oauth_token>
+//gitlab.com/api/v4/packages/npm/:_authToken=<your_oauth_token>
+@foo:registry=https://gitlab.com/api/v4/packages/npm/
+```
diff --git a/doc/user/permissions.md b/doc/user/permissions.md
index 4f660d07071..90874eca2eb 100644
--- a/doc/user/permissions.md
+++ b/doc/user/permissions.md
@@ -24,7 +24,7 @@ For information on eligible approvers for Merge Requests, see
 
 ## Principles behind permissions
 
-See our [product handbook on permissions](https://about.gitlab.com/handbook/product#permissions-in-gitlab)
+See our [product handbook on permissions](https://about.gitlab.com/handbook/product/#permissions-in-gitlab)
 
 ## Instance-wide user permissions
 
@@ -48,13 +48,13 @@ The following table depicts the various user permission levels in a project.
 | View Insights charts **(ULTIMATE)**               | ✓       | ✓          | ✓           | ✓        | ✓      |
 | View approved/blacklisted licenses **(ULTIMATE)** | ✓       | ✓          | ✓           | ✓        | ✓      |
 | View License Compliance reports **(ULTIMATE)**    | ✓ (*1*) | ✓          | ✓           | ✓        | ✓      |
-| View Security reports **(ULTIMATE)**              | ✓ (*1*) | ✓          | ✓           | ✓        | ✓      |
+| View Security reports **(ULTIMATE)**              | ✓ (*3*) | ✓          | ✓           | ✓        | ✓      |
 | View Dependency list **(ULTIMATE)**               | ✓ (*1*) | ✓          | ✓           | ✓        | ✓      |
 | View licenses in Dependency list **(ULTIMATE)**   | ✓ (*1*) | ✓          | ✓           | ✓        | ✓      |
 | View [Design Management](project/issues/design_management.md) pages **(PREMIUM)** | ✓ (*1*) | ✓          | ✓           | ✓        | ✓      |
 | View project code                                 | ✓ (*1*) | ✓          | ✓           | ✓        | ✓      |
 | Pull project code                                 | ✓ (*1*) | ✓          | ✓           | ✓        | ✓      |
-| View GitLab Pages protected by [access control](project/pages/introduction.md#gitlab-pages-access-control-core-only) | ✓       | ✓          | ✓           | ✓        | ✓      |
+| View GitLab Pages protected by [access control](project/pages/introduction.md#gitlab-pages-access-control-core) | ✓       | ✓          | ✓           | ✓        | ✓      |
 | View wiki pages                                   | ✓ (*1*) | ✓          | ✓           | ✓        | ✓      |
 | See a list of jobs                                | ✓ (*3*) | ✓          | ✓           | ✓        | ✓      |
 | See a job log                                     | ✓ (*3*) | ✓          | ✓           | ✓        | ✓      |
@@ -76,8 +76,8 @@ The following table depicts the various user permission levels in a project.
 | See a list of merge requests                      |         | ✓          | ✓           | ✓        | ✓      |
 | View project statistics                           |         | ✓          | ✓           | ✓        | ✓      |
 | View Error Tracking list                          |         | ✓          | ✓           | ✓        | ✓      |
-| Pull from [Maven repository](packages/maven_repository/index.md) or [NPM registry](packages/npm_registry/index.md) **(PREMIUM)** |         | ✓          | ✓           | ✓        | ✓      |
-| Publish to [Maven repository](packages/maven_repository/index.md) or [NPM registry](packages/npm_registry/index.md) **(PREMIUM)** |         |            | ✓           | ✓        | ✓      |
+| Pull from [Conan repository](packages/conan_repository/index.md), [Maven repository](packages/maven_repository/index.md), or [NPM registry](packages/npm_registry/index.md) **(PREMIUM)** |         | ✓          | ✓           | ✓        | ✓      |
+| Publish to [Conan repository](packages/conan_repository/index.md), [Maven repository](packages/maven_repository/index.md), or [NPM registry](packages/npm_registry/index.md) **(PREMIUM)** |         |            | ✓           | ✓        | ✓      |
 | Upload [Design Management](project/issues/design_management.md) files **(PREMIUM)** |         |            | ✓           | ✓        | ✓      |
 | Create new branches                               |         |            | ✓           | ✓        | ✓      |
 | Push to non-protected branches                    |         |            | ✓           | ✓        | ✓      |
@@ -125,6 +125,7 @@ The following table depicts the various user permission levels in a project.
 | Manage Error Tracking                             |         |            |             | ✓        | ✓      |
 | Delete wiki pages                                 |         |            |             | ✓        | ✓      |
 | View project Audit Events                         |         |            |             | ✓        | ✓      |
+| Manage [push rules](../push_rules/push_rules.md)  |         |            |             | ✓        | ✓      |
 | Switch visibility level                           |         |            |             |          | ✓      |
 | Transfer project to another namespace             |         |            |             |          | ✓      |
 | Remove project                                    |         |            |             |          | ✓      |
@@ -133,10 +134,10 @@ The following table depicts the various user permission levels in a project.
 | Force push to protected branches (*4*)            |         |            |             |          |        |
 | Remove protected branches (*4*)                   |         |            |             |          |        |
 
-- (*1*): All users are able to perform this action on public and internal projects, but not private projects.
+- (*1*): Guest users are able to perform this action on public and internal projects, but not private projects.
 - (*2*): Guest users can only view the confidential issues they created themselves
 - (*3*): If **Public pipelines** is enabled in **Project Settings > CI/CD**
-- (*4*): Not allowed for Guest, Reporter, Developer, Maintainer, or Owner
+- (*4*): Not allowed for Guest, Reporter, Developer, Maintainer, or Owner. See [Protected Branches](./project/protected_branches.md).
 
 ## Project features permissions
 
@@ -210,7 +211,7 @@ group.
 | View group epic **(ULTIMATE)**                         | ✓     | ✓        | ✓         | ✓          | ✓     |
 | Create/edit group epic **(ULTIMATE)**                  |       | ✓        | ✓         | ✓          | ✓     |
 | Manage group labels                                    |       | ✓        | ✓         | ✓          | ✓     |
-| Create project in group                                |       |          | ✓         | ✓          | ✓     |
+| Create project in group                                |       |          | ✓ (3)     | ✓ (3)      | ✓ (3) |
 | Create/edit/delete group milestones                    |       |          | ✓         | ✓          | ✓     |
 | Enable/disable a dependency proxy **(PREMIUM)**        |       |          | ✓         | ✓          | ✓     |
 | Use security dashboard **(ULTIMATE)**                  |       |          | ✓         | ✓          | ✓     |
@@ -222,10 +223,14 @@ group.
 | Edit epic comments (posted by any user) **(ULTIMATE)** |       |          |           | ✓ (2)      | ✓ (2) |
 | View group Audit Events                                |       |          |           |            | ✓     |
 | Disable notification emails                            |       |          |           |            | ✓     |
+| View/manage group-level Kubernetes cluster             |       |          |           | ✓          | ✓     |
 
 - (1): Groups can be set to [allow either Owners or Owners and
   Maintainers to create subgroups](group/subgroups/index.md#creating-a-subgroup)
 - (2): Introduced in GitLab 12.2.
+- (3): Default project creation role can be changed at:
+  - The [instance level](admin_area/settings/visibility_and_access_controls.md#default-project-creation-protection).
+  - The [group level](group/index.html#default-project-creation-level).
 
 ### Subgroup permissions
 
@@ -236,57 +241,83 @@ nested groups if you have membership in one of its parents.
 To learn more, read through the documentation on
 [subgroups memberships](group/subgroups/index.md#membership).
 
-## Guest User
-
-When a user is given `Guest` permissions on a project and/or group, and holds no
-higher permission level on any other project or group on the instance, the user
-is considered a guest user by GitLab and will not consume a license seat.
-There is no other specific "guest" designation for newly created users.
-
-If the user is assigned a higher role on any projects or groups, the user will
-take a license seat. If a user creates a project, the user becomes a `Maintainer`
-on the project, resulting in the use of a license seat. To prevent a guest user
-from creating projects, you can edit the user profile to mark the user as
-[External](#external-users-permissions).
-
-## External users permissions
+## External users **(CORE ONLY)**
 
 In cases where it is desired that a user has access only to some internal or
 private projects, there is the option of creating **External Users**. This
 feature may be useful when for example a contractor is working on a given
 project and should only have access to that project.
 
-External users can only access projects to which they are explicitly granted
-access, thus hiding all other internal or private ones from them. Access can be
-granted by adding the user as member to the project or group.
+External users:
+
+- Cannot create groups or projects.
+- Can only access projects to which they are explicitly granted access,
+  thus hiding all other internal or private ones from them (like being
+  logged out).
 
+Access can be granted by adding the user as member to the project or group.
 They will, like usual users, receive a role in the project or group with all
-the abilities that are mentioned in the table above. They cannot however create
-groups or projects, and they have the same access as logged out users in all
-other cases.
+the abilities that are mentioned in the [permissions table above](#project-members-permissions).
+For example, if an external user is added as Guest, and your project is
+private, they will not have access to the code; you would need to grant the external
+user access at the Reporter level or above if you want them to have access to the code. You should
+always take into account the
+[project's visibility and permissions settings](project/settings/index.md#sharing-and-permissions)
+as well as the permission level of the user.
 
-An administrator can flag a user as external [through the API](../api/users.md)
-or by checking the checkbox on the admin panel. As an administrator, navigate
-to **Admin > Users** to create a new user or edit an existing one. There, you
-will find the option to flag the user as external.
+NOTE: **Note:**
+External users still count towards a license seat.
+
+An administrator can flag a user as external by either of the following methods:
+
+- Either [through the API](../api/users.md#user-modification).
+- Or by navigating to the **Admin area > Overview > Users** to create a new user
+  or edit an existing one. There, you will find the option to flag the user as
+  external.
 
-By default new users are not set as external users. This behavior can be changed
-by an administrator under **Admin > Application Settings**.
+### Setting new users to external
 
-### Default internal users
+By default, new users are not set as external users. This behavior can be changed
+by an administrator under the **Admin Area > Settings > General > Account and limit** page.
 
-The "Internal users" field allows specifying an e-mail address regex pattern to identify default internal users.
+If you change the default behavior of creating new users as external, you will
+have the option to narrow it down by defining a set of internal users.
+The **Internal users** field allows specifying an email address regex pattern to
+identify default internal users. New users whose email address matches the regex
+pattern will be set to internal by default rather than an external collaborator.
 
-New users whose email address matches the regex pattern will be set to internal by default rather than an external collaborator.
+The regex pattern format is Ruby, but it needs to be convertible to JavaScript,
+and the ignore case flag will be set (`/regex pattern/i`). Here are some examples:
 
-The regex pattern format is Ruby, but it needs to be convertible to JavaScript, and the ignore case flag will be set, e.g. "/regex pattern/i".
+- Use `\.internal@domain\.com$` to mark email addresses ending with
+  `.internal@domain.com` as internal.
+- Use `^(?:(?!\.ext@domain\.com).)*$\r?` to mark users with email addresses
+  NOT including `.ext@domain.com` as internal.
 
-Here are some examples:
+CAUTION: **Warning:**
+Be aware that this regex could lead to a
+[regular expression denial of service (ReDoS) attack](https://en.wikipedia.org/wiki/ReDoS).
 
-- Use `\.internal@domain\.com$` to mark email addresses ending with ".internal@domain.com" internal.
-- Use `^(?:(?!\.ext@domain\.com).)*$\r?` to mark users with email addresses NOT including .ext@domain.com internal.
+## Free Guest users **(ULTIMATE)**
 
-Please be aware that this regex could lead to a DOS attack, [see](https://en.wikipedia.org/wiki/ReDoS?) ReDos on Wikipedia.
+When a user is given Guest permissions on a project, group, or both, and holds no
+higher permission level on any other project or group on the GitLab instance,
+the user is considered a guest user by GitLab and will not consume a license seat.
+There is no other specific "guest" designation for newly created users.
+
+If the user is assigned a higher role on any projects or groups, the user will
+take a license seat. If a user creates a project, the user becomes a Maintainer
+on the project, resulting in the use of a license seat. Also, note that if your
+project is internal or private, Guest users will have all the abilities that are
+mentioned in the [permissions table above](#project-members-permissions) (they
+will not be able to browse the project's repository for example).
+
+TIP: **Tip:**
+To prevent a guest user from creating projects, as an admin, you can edit the
+user's profile to mark the user as [external](#external-users-core-only).
+Beware though that even if a user is external, if they already have Reporter or
+higher permissions in any project or group, they will **not** be counted as a
+free guest user.
 
 ## Auditor users **(PREMIUM ONLY)**
 
diff --git a/doc/user/profile/account/delete_account.md b/doc/user/profile/account/delete_account.md
index 9b72956a55e..65896bd19cd 100644
--- a/doc/user/profile/account/delete_account.md
+++ b/doc/user/profile/account/delete_account.md
@@ -42,6 +42,53 @@ a user can be blocked directly from the Admin area. To do this:
 1. Selecting a user.
 1. Under the **Account** tab, click **Block user**.
 
+### Deactivating a user
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/63921) in GitLab 12.4.
+
+A user can be deactivated from the Admin area. Deactivating a user is functionally identical to blocking a user, with the following differences:
+
+- It does not prohibit the user from logging back in via the UI.
+- Once a deactivated user logs back into the GitLab UI, their account is set to active.
+
+A deactivated user:
+
+- Cannot access Git repositories or the API.
+- Will not receive any notifications from GitLab.
+- Will not be able to use [slash commands](../../../integration/slash_commands.md).
+
+Personal projects, group and user history of the deactivated user will be left intact.
+
+NOTE: **Note:**
+A deactivated user does not consume a [seat](../../../subscriptions/index.md#managing-subscriptions).
+
+To do this:
+
+1. Navigate to  **Admin Area > Overview > Users**.
+1. Select a user.
+1. Under the **Account** tab, click **Deactivate user**.
+
+Please note that for the deactivation option to be visible to an admin, the user:
+
+- Must be currently active.
+- Should not have any activity in the last 14 days.
+
+### Activating a user
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/63921) in GitLab 12.4.
+
+A deactivated user can be activated from the Admin area. Activating a user sets their account to active state.
+
+To do this:
+
+1. Navigate to  **Admin Area > Overview > Users**.
+1. Click on the **Deactivated** tab.
+1. Select a user.
+1. Under the **Account** tab, click **Activate user**.
+
+TIP: **Tip:**
+A deactivated user can also activate their account by themselves by simply logging back via the UI.
+
 ## Associated Records
 
 > - Introduced for issues in
diff --git a/doc/user/profile/account/two_factor_authentication.md b/doc/user/profile/account/two_factor_authentication.md
index f7ba921aa7d..108d4f0b387 100644
--- a/doc/user/profile/account/two_factor_authentication.md
+++ b/doc/user/profile/account/two_factor_authentication.md
@@ -107,7 +107,7 @@ prompted to download a set of set recovery codes. Should you ever lose access
 to your one time password authenticator, you can use one of them to log in to
 your account. We suggest copying them, printing them, or downloading them using
 the **Download codes** button for storage in a safe place. If you choose to
-download them, the file will be called **gitlab-recovery-codes.txt**.
+download them, the file will be called `gitlab-recovery-codes.txt`.
 
 If you lose the recovery codes or just want to generate new ones, you can do so
 [using SSH](#generate-new-recovery-codes-using-ssh).
@@ -244,6 +244,12 @@ Sign in and re-enable two-factor authentication as soon as possible.
   - The user logs out and attempts to log in via `second.host.xyz` - U2F authentication fails, because
     the U2F key has only been registered on `first.host.xyz`.
 
+## Troubleshooting
+
+If you are receiving an `invalid pin code` error, this may indicate that there is a time sync issue between the authentication application and the GitLab instance itself.
+
+Most authentication apps have a feature in the settings for syncing the time for the codes themselves. For Google Authenticator for example, go to `Settings > Time correction for codes`.
+
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues
diff --git a/doc/user/profile/personal_access_tokens.md b/doc/user/profile/personal_access_tokens.md
index 4c99d58e51d..980a7d5968d 100644
--- a/doc/user/profile/personal_access_tokens.md
+++ b/doc/user/profile/personal_access_tokens.md
@@ -47,8 +47,8 @@ the following table.
 | `api`              | [GitLab 8.15](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/5951)   | Grants complete read/write access to the API, including all groups and projects, the container registry, and the package registry. |
 | `read_registry`    | [GitLab 9.3](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/11845)   | Allows to read (pull) [container registry] images if a project is private and authorization is required. |
 | `sudo`             | [GitLab 10.2](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/14838)  | Allows performing API actions as any user in the system (if the authenticated user is an admin). |
-| `read_repository`  | [GitLab 10.7](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/17894)  | Allows read-only access (pull) to the repository through git clone. |
-| `write_repository` | [GitLab 11.11](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/26021) | Allows read-write access (pull, push) to the repository through git clone. Required for accessing Git repositories over HTTP when 2FA is enabled. |
+| `read_repository`  | [GitLab 10.7](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/17894)  | Allows read-only access (pull) to the repository through `git clone`. |
+| `write_repository` | [GitLab 11.11](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/26021) | Allows read-write access (pull, push) to the repository through `git clone`. Required for accessing Git repositories over HTTP when 2FA is enabled. |
 
 [2fa]: ../account/two_factor_authentication.md
 [api]: ../../api/README.md
diff --git a/doc/user/project/canary_deployments.md b/doc/user/project/canary_deployments.md
index 95ed511d0b3..3a19c29b241 100644
--- a/doc/user/project/canary_deployments.md
+++ b/doc/user/project/canary_deployments.md
@@ -44,7 +44,7 @@ Canary deployments require that you properly configure Deploy Boards:
 
 1. Follow the steps to [enable Deploy Boards](deploy_boards.md#enabling-deploy-boards).
 1. To track canary deployments you need to label your Kubernetes deployments and
-   pods with `track: canary`. To get started quickly, you can use the [Auto Deploy](../../ci/autodeploy/index.md)
+   pods with `track: canary`. To get started quickly, you can use the [Auto Deploy](../../topics/autodevops/index.md#auto-deploy)
    template for canary deployments that GitLab provides.
 
 Depending on the deploy, the label should be either `stable` or `canary`.
@@ -66,5 +66,5 @@ can easily notice them.
 [ee-1659]: https://gitlab.com/gitlab-org/gitlab/issues/1659
 [kube-canary]: https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments
 [deploy board]: deploy_boards.md
-[cd-blog]: https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/
+[cd-blog]: https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/
 [kube-net]: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies
diff --git a/doc/user/project/clusters/eks_and_gitlab/index.md b/doc/user/project/clusters/eks_and_gitlab/index.md
index 28f3420de35..22576b84926 100644
--- a/doc/user/project/clusters/eks_and_gitlab/index.md
+++ b/doc/user/project/clusters/eks_and_gitlab/index.md
@@ -192,7 +192,7 @@ deployment of the other applications.
 
 Next, if you would like the deployed app to be reachable on the internet, deploy
 the Ingress. Note that this will also cause an
-[Elastic Load Balancer](https://aws.amazon.com/documentation/elastic-load-balancing/)
+[Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/)
 to be created, which will incur additional AWS costs.
 
 Once installed, you may see a `?` for "Ingress IP Address". This is because the
diff --git a/doc/user/project/clusters/img/kubernetes_pod_logs.png b/doc/user/project/clusters/img/kubernetes_pod_logs.png
deleted file mode 100644
index e664a47386a..00000000000
--- a/doc/user/project/clusters/img/kubernetes_pod_logs.png
+++ /dev/null
diff --git a/doc/user/project/clusters/img/kubernetes_pod_logs_v12_4.png b/doc/user/project/clusters/img/kubernetes_pod_logs_v12_4.png
new file mode 100644
index 00000000000..73c2ecd182a
--- /dev/null
+++ b/doc/user/project/clusters/img/kubernetes_pod_logs_v12_4.png
diff --git a/doc/user/project/clusters/index.md b/doc/user/project/clusters/index.md
index 97fa973d3e3..9ecb785d6fe 100644
--- a/doc/user/project/clusters/index.md
+++ b/doc/user/project/clusters/index.md
@@ -61,7 +61,7 @@ GitLab makes it easy to view the logs of running pods in connected Kubernetes cl
 ### Kubernetes monitoring
 
 Automatically detect and monitor Kubernetes metrics. Automatic monitoring of
-[NGINX ingress](../integrations/prometheus_library/nginx.md) is also supported.
+[NGINX Ingress](../integrations/prometheus_library/nginx.md) is also supported.
 
 [Read more about Kubernetes monitoring](../integrations/prometheus_library/kubernetes.md)
 
@@ -112,7 +112,7 @@ There are two options when adding a new cluster to your project:
 TIP: **Tip:**
 Every new Google Cloud Platform (GCP) account receives [$300 in credit upon sign up](https://console.cloud.google.com/freetrial),
 and in partnership with Google, GitLab is able to offer an additional $200 for new GCP accounts to get started with GitLab's
-Google Kubernetes Engine Integration. All you have to do is [follow this link](https://goo.gl/AaJzRW) and apply for credit.
+Google Kubernetes Engine Integration. All you have to do is [follow this link](https://cloud.google.com/partners/partnercredit/?PCN=a0n60000006Vpz4AAC) and apply for credit.
 
 NOTE: **Note:**
 The [Google authentication integration](../../../integration/google.md) must
@@ -154,6 +154,7 @@ new Kubernetes cluster to your project:
    - **Number of nodes** - Enter the number of nodes you wish the cluster to have.
    - **Machine type** - The [machine type](https://cloud.google.com/compute/docs/machine-types)
      of the Virtual Machine instance that the cluster will be based on.
+   - **Enable Cloud Run on GKE (beta)** - Check this if you want to use Cloud Run on GKE for this cluster. See the [Cloud Run on GKE section](#cloud-run-on-gke) for more information.
    - **GitLab-managed cluster** - Leave this checked if you want GitLab to manage namespaces and service accounts for this cluster. See the [Managed clusters section](#gitlab-managed-clusters) for more information.
 1. Finally, click the **Create Kubernetes cluster** button.
 
@@ -339,6 +340,15 @@ functionalities needed to successfully build and deploy a containerized
 application. Bear in mind that the same credentials are used for all the
 applications running on the cluster.
 
+### Cloud Run on GKE
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/16566) in GitLab 12.4.
+
+You can choose to use Cloud Run on GKE in place of installing Knative and Istio
+separately after the cluster has been created. This means that Cloud Run
+(Knative), Istio, and HTTP Load Balancing will be enabled on the cluster at
+create time and cannot be [installed or uninstalled](../../clusters/applications.md) separately.
+
 ### GitLab-managed clusters
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/22011) in GitLab 11.5.
@@ -370,7 +380,7 @@ Specifying a base domain will automatically set `KUBE_INGRESS_BASE_DOMAIN` as an
 If you are using [Auto DevOps](../../../topics/autodevops/index.md), this domain will be used for the different
 stages. For example, Auto Review Apps and Auto Deploy.
 
-The domain should have a wildcard DNS configured to the Ingress IP address. After ingress has been installed (see [Installing Applications](#installing-applications)),
+The domain should have a wildcard DNS configured to the Ingress IP address. After Ingress has been installed (see [Installing Applications](#installing-applications)),
 you can either:
 
 - Create an `A` record that points to the Ingress IP address with your domain provider.
@@ -380,8 +390,8 @@ you can either:
 
 When creating a cluster in GitLab, you will be asked if you would like to create either:
 
-- An [Attribute-based access control (ABAC)](https://kubernetes.io/docs/admin/authorization/abac/) cluster.
-- A [Role-based access control (RBAC)](https://kubernetes.io/docs/admin/authorization/rbac/) cluster.
+- An [Attribute-based access control (ABAC)](https://kubernetes.io/docs/reference/access-authn-authz/abac/) cluster.
+- A [Role-based access control (RBAC)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) cluster.
 
 NOTE: **Note:**
 [RBAC](#rbac-cluster-resources) is recommended and the GitLab default.
@@ -538,7 +548,7 @@ differentiate the new cluster with the rest.
 GitLab can install and manage some applications in your project-level
 cluster. For more information on installing, upgrading, uninstalling,
 and troubleshooting applications for your project cluster, see
-[Gitlab Managed Apps](../../clusters/applications.md).
+[GitLab Managed Apps](../../clusters/applications.md).
 
 ### Getting the external endpoint
 
@@ -555,7 +565,7 @@ address or a hostname associated with your load balancer.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/17052) in GitLab 10.6.
 
-After you install [Ingress or Knative](#installing-applications), Gitlab attempts to determine the external endpoint
+After you install [Ingress or Knative](#installing-applications), GitLab attempts to determine the external endpoint
 and it should be available within a few minutes. If the endpoint doesn't appear
 and your cluster runs on Google Kubernetes Engine:
 
diff --git a/doc/user/project/clusters/kubernetes_pod_logs.md b/doc/user/project/clusters/kubernetes_pod_logs.md
index 82f658ce724..4036eaf0bfb 100644
--- a/doc/user/project/clusters/kubernetes_pod_logs.md
+++ b/doc/user/project/clusters/kubernetes_pod_logs.md
@@ -17,8 +17,14 @@ Everything you need to build, test, deploy, and run your app at scale.
 1. On the **Environments** page, you should see the status of the environment's pods with [Deploy Boards](../deploy_boards.md).
 1. When mousing over the list of pods, a tooltip will appear with the exact pod name and status.
    ![Deploy Boards pod list](img/pod_logs_deploy_board.png)
-1. Click on the desired pod to bring up the logs view, which will contain the last 500 lines for that pod. Support for pods with multiple containers is coming [in a future release](https://gitlab.com/gitlab-org/gitlab/issues/6502).
-   ![Deploy Boards pod list](img/kubernetes_pod_logs.png)
+1. Click on the desired pod to bring up the logs view, which will contain the last 500 lines for that pod.
+   You may switch between the following in this view:
+   - Pods.
+   - [From GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/issues/5769), environments.
+
+   Support for pods with multiple containers is coming [in a future release](https://gitlab.com/gitlab-org/gitlab/issues/6502).
+
+   ![Deploy Boards pod list](img/kubernetes_pod_logs_v12_4.png)
 
 ## Requirements
 
diff --git a/doc/user/project/clusters/runbooks/index.md b/doc/user/project/clusters/runbooks/index.md
index 7e5c1b3d4ed..7b17ec68234 100644
--- a/doc/user/project/clusters/runbooks/index.md
+++ b/doc/user/project/clusters/runbooks/index.md
@@ -38,7 +38,7 @@ To create an executable runbook, you will need:
     The simplest way to get started is to add a cluster using [GitLab's GKE integration](../index.md#add-new-gke-cluster).
 1. **Helm Tiller** - Helm is a package manager for Kubernetes and is required to install
     all the other applications. It is installed in its own pod inside the cluster which
-    can run the helm CLI in a safe environment.
+    can run the Helm CLI in a safe environment.
 1. **Ingress** - Ingress can provide load balancing, SSL termination, and name-based
     virtual hosting. It acts as a web proxy for your applications.
 1. **JupyterHub** - [JupyterHub](https://jupyterhub.readthedocs.io/) is a multi-user service for managing notebooks across
@@ -48,9 +48,9 @@ To create an executable runbook, you will need:
 ## Nurtch
 
 Nurtch is the company behind the [Rubix library](https://github.com/Nurtch/rubix). Rubix is
-an open-source python library that makes it easy to perform common DevOps tasks inside Jupyter Notebooks.
+an open-source Python library that makes it easy to perform common DevOps tasks inside Jupyter Notebooks.
 Tasks such as plotting Cloudwatch metrics and rolling your ECS/Kubernetes app are simplified
-down to a couple of lines of code. See the [Nurtch Documentation](http://docs.nurtch.com/en/latest)
+down to a couple of lines of code. See the [Nurtch Documentation](http://docs.nurtch.com/en/latest/)
 for more information.
 
 ## Configure an executable runbook with GitLab
diff --git a/doc/user/project/clusters/serverless/index.md b/doc/user/project/clusters/serverless/index.md
index 5d91b01e5b0..9a9857bd5da 100644
--- a/doc/user/project/clusters/serverless/index.md
+++ b/doc/user/project/clusters/serverless/index.md
@@ -9,12 +9,12 @@ Serverless is currently in [alpha](https://about.gitlab.com/handbook/product/#al
 
 Serverless architectures offer Operators and Developers the ability write highly scalable applications without provisioning a single server.
 
-Gitlab supports several ways deploy Serverless applications in both Kubernetes Environments and also major cloud FAAS environments.
+GitLab supports several ways deploy Serverless applications in both Kubernetes Environments and also major cloud FAAS environments.
 
 Currently we support:
 
 - [Knative](#knative): Build Knative applications with Knative and gitlabktl on GKE
-- [AWS Lambda](aws.md): Create serverless applications via the Serverless Framework and gitlab-ci
+- [AWS Lambda](aws.md): Create serverless applications via the Serverless Framework and GitLab CI
 
 ## Knative
 
@@ -31,7 +31,7 @@ With GitLab Serverless, you can deploy both functions-as-a-service (FaaS) and se
 
 ## Prerequisites
 
-To run Knative on Gitlab, you will need:
+To run Knative on GitLab, you will need:
 
 1. **Existing GitLab project:** You will need a GitLab project to associate all resources. The simplest way to get started:
 
@@ -82,10 +82,10 @@ The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22.
    For clusters created on GKE, see [GKE Cluster Access](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl),
    for other platforms [Install kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
 
-1. The ingress is now available at this address and will route incoming requests to the proper service based on the DNS
+1. The Ingress is now available at this address and will route incoming requests to the proper service based on the DNS
    name in the request. To support this, a wildcard DNS A record should be created for the desired domain name. For example,
    if your Knative base domain is `knative.info` then you need to create an A record or CNAME record with domain `*.knative.info`
-   pointing the ip address or hostname of the ingress.
+   pointing the ip address or hostname of the Ingress.
 
    ![dns entry](img/dns-entry.png)
 
diff --git a/doc/user/project/code_owners.md b/doc/user/project/code_owners.md
index 0d422612f02..476f513480c 100644
--- a/doc/user/project/code_owners.md
+++ b/doc/user/project/code_owners.md
@@ -1,8 +1,13 @@
+---
+type: reference
+---
+
 # Code Owners **(STARTER)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/6916)
 in [GitLab Starter](https://about.gitlab.com/pricing/) 11.3.
 > - [Support for group namespaces](https://gitlab.com/gitlab-org/gitlab-foss/issues/53182) added in GitLab Starter 12.1.
+> - Code Owners for Merge Request approvals was [introduced](https://gitlab.com/gitlab-org/gitlab/issues/4418) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.9.
 
 You can use a `CODEOWNERS` file to specify users or
 [shared groups](members/share_project_with_groups.md)
@@ -10,9 +15,9 @@ that are responsible for certain files in a repository.
 
 You can choose and add the `CODEOWNERS` file in three places:
 
-- to the root directory of the repository
-- inside the `.gitlab/` directory
-- inside the `docs/` directory
+- To the root directory of the repository
+- Inside the `.gitlab/` directory
+- Inside the `docs/` directory
 
 The `CODEOWNERS` file is scoped to a branch, which means that with the
 introduction of new files, the person adding the new content can
@@ -23,6 +28,18 @@ When a file matches multiple entries in the `CODEOWNERS` file,
 the users from all entries are displayed on the blob page of
 the given file.
 
+## Approvals by Code Owners
+
+Once you've set Code Owners to a project, you can configure it to
+receive approvals:
+
+- As [merge request eligible approvers](merge_requests/merge_request_approvals.md#code-owners-as-eligible-approvers-starter). **(STARTER)**
+- As required approvers for [protected branches](protected_branches.md#protected-branches-approval-by-code-owners-premium). **(PREMIUM)**
+
+Once set, Code Owners are displayed in merge requests widgets:
+
+![MR widget - Code Owners](img/code_owners_mr_widget_v12_4.png)
+
 ## The syntax of Code Owners files
 
 Files can be specified using the same kind of patterns you would use
diff --git a/doc/user/project/deploy_boards.md b/doc/user/project/deploy_boards.md
index 23d11c87676..b14d7f821bb 100644
--- a/doc/user/project/deploy_boards.md
+++ b/doc/user/project/deploy_boards.md
@@ -29,9 +29,9 @@ to the latest release.
 Since Deploy Boards are tightly coupled with Kubernetes, there is some required
 knowledge. In particular you should be familiar with:
 
-- [Kubernetes pods](https://kubernetes.io/docs/user-guide/pods)
+- [Kubernetes pods](https://kubernetes.io/docs/concepts/workloads/pods/pod/)
 - [Kubernetes labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
-- [Kubernetes namespaces](https://kubernetes.io/docs/user-guide/namespaces/)
+- [Kubernetes namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)
 - [Kubernetes canary deployments](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)
 
 ## Use cases
@@ -91,7 +91,8 @@ To display the Deploy Boards for a specific [environment] you should:
    Matching based on the Kubernetes `app` label was removed in [GitLab
    12.1](https://gitlab.com/gitlab-org/gitlab/merge_requests/14020).
    To migrate, please apply the required annotations (see above) and
-   re-deploy your application.
+   re-deploy your application. If you are using Auto DevOps, this will
+   be done automatically and no action is necessary.
 
    ![Deploy Boards Kubernetes Label](img/deploy_boards_kubernetes_label.png)
 
diff --git a/doc/user/project/deploy_tokens/index.md b/doc/user/project/deploy_tokens/index.md
index 6dcf56da4f0..5c3c2188629 100644
--- a/doc/user/project/deploy_tokens/index.md
+++ b/doc/user/project/deploy_tokens/index.md
@@ -71,7 +71,7 @@ To read the container registry images, you'll need to:
 1. Log in to GitLab’s Container Registry using the deploy token:
 
 ```sh
-docker login registry.example.com -u <username> -p <deploy_token>
+docker login -u <username> -p <deploy_token> registry.example.com
 ```
 
 Just replace `<username>` and `<deploy_token>` with the proper values. Then you can simply
diff --git a/doc/user/project/highlighting.md b/doc/user/project/highlighting.md
index 73a2d176b54..a715a313adf 100644
--- a/doc/user/project/highlighting.md
+++ b/doc/user/project/highlighting.md
@@ -1,8 +1,6 @@
-[Rouge]: https://rubygems.org/gems/rouge
-
 # Syntax Highlighting
 
-GitLab provides syntax highlighting on all files and snippets through the [Rouge][] rubygem. It will try to guess what language to use based on the file extension, which most of the time is sufficient.
+GitLab provides syntax highlighting on all files and snippets through the [Rouge](https://rubygems.org/gems/rouge) rubygem. It will try to guess what language to use based on the file extension, which most of the time is sufficient.
 
 If GitLab is guessing wrong, you can override its choice of language using the `gitlab-language` attribute in `.gitattributes`. For example, if you are working in a Prolog project and using the `.pl` file extension (which would normally be highlighted as Perl), you can add the following to your `.gitattributes` file:
 
@@ -12,7 +10,7 @@ If GitLab is guessing wrong, you can override its choice of language using the `
 
 When you check in and push that change, all `*.pl` files in your project will be highlighted as Prolog.
 
-The paths here are simply git's builtin [`.gitattributes` interface](https://git-scm.com/docs/gitattributes).  So, if you were to invent a file format called a `Nicefile` at the root of your project that used ruby syntax, all you need is:
+The paths here are simply Git's built-in [`.gitattributes` interface](https://git-scm.com/docs/gitattributes).  So, if you were to invent a file format called a `Nicefile` at the root of your project that used ruby syntax, all you need is:
 
 ``` conf
 /Nicefile gitlab-language=ruby
diff --git a/doc/user/project/img/code_owners_approval_new_protected_branch_v12_4.png b/doc/user/project/img/code_owners_approval_new_protected_branch_v12_4.png
new file mode 100755
index 00000000000..f813b60dcd9
--- /dev/null
+++ b/doc/user/project/img/code_owners_approval_new_protected_branch_v12_4.png
diff --git a/doc/user/project/img/code_owners_approval_protected_branch_v12_4.png b/doc/user/project/img/code_owners_approval_protected_branch_v12_4.png
new file mode 100755
index 00000000000..59da6874d14
--- /dev/null
+++ b/doc/user/project/img/code_owners_approval_protected_branch_v12_4.png
diff --git a/doc/user/project/img/code_owners_mr_widget_v12_4.png b/doc/user/project/img/code_owners_mr_widget_v12_4.png
new file mode 100644
index 00000000000..7f7b15ee017
--- /dev/null
+++ b/doc/user/project/img/code_owners_mr_widget_v12_4.png
diff --git a/doc/user/project/img/issue_boards_multi_select.png b/doc/user/project/img/issue_boards_multi_select.png
new file mode 100644
index 00000000000..34ec0c1c58e
--- /dev/null
+++ b/doc/user/project/img/issue_boards_multi_select.png
diff --git a/doc/user/project/img/protected_branches_list_v12_3.png b/doc/user/project/img/protected_branches_list_v12_3.png
index 365d8d99e5a..2353ddd23be 100644
--- a/doc/user/project/img/protected_branches_list_v12_3.png
+++ b/doc/user/project/img/protected_branches_list_v12_3.png
diff --git a/doc/user/project/img/protected_branches_page_v12_3.png b/doc/user/project/img/protected_branches_page_v12_3.png
index 17f19642552..9a194c85c41 100644
--- a/doc/user/project/img/protected_branches_page_v12_3.png
+++ b/doc/user/project/img/protected_branches_page_v12_3.png
diff --git a/doc/user/project/import/bitbucket.md b/doc/user/project/import/bitbucket.md
index e509e333313..77fc2761e07 100644
--- a/doc/user/project/import/bitbucket.md
+++ b/doc/user/project/import/bitbucket.md
@@ -56,10 +56,10 @@ namespace that started the import process.
    ![Grant access](img/bitbucket_import_grant_access.png)
 
 1. Click on the projects that you'd like to import or **Import all projects**.
-   You can also select the namespace under which each project will be
-   imported.
+   You can also filter projects by name and select the namespace under which
+   each project will be imported.
 
-   ![Import projects](img/bitbucket_import_select_project.png)
+   ![Import projects](img/bitbucket_import_select_project_v12_3.png)
 
 [bb-import]: ../../../integration/bitbucket.md
 [social sign-in]: ../../profile/account/social_sign_in.md
diff --git a/doc/user/project/import/bitbucket_server.md b/doc/user/project/import/bitbucket_server.md
index 7f2c6005cd4..f10bbaa707d 100644
--- a/doc/user/project/import/bitbucket_server.md
+++ b/doc/user/project/import/bitbucket_server.md
@@ -4,7 +4,7 @@
 in GitLab 11.2.
 
 NOTE: **Note:**
-The Bitbucket Server importer does not work with Bitbucket Cloud (aka bitbucket.org).
+The Bitbucket Server importer does not work with [Bitbucket Cloud](https://bitbucket.org).
 Use the [Bitbucket Cloud importer](bitbucket.md) for that.
 
 Import your projects from Bitbucket Server to GitLab with minimal effort.
diff --git a/doc/user/project/import/cvs.md b/doc/user/project/import/cvs.md
index cabd0eef8d6..3b2404912f7 100644
--- a/doc/user/project/import/cvs.md
+++ b/doc/user/project/import/cvs.md
@@ -64,5 +64,5 @@ Here's a few links to get you started with the migration:
 
 - [Migrate using the `cvs-fast-export` tool](http://www.catb.org/~esr/reposurgeon/dvcs-migration-guide.html) ([_source code_](https://gitlab.com/esr/cvs-fast-export))
 - [Stack Overflow post on importing the CVS repo](https://stackoverflow.com/a/11490134/974710)
-- [Convert a CVS repository to Git](http://www.techrepublic.com/blog/linux-and-open-source/convert-cvs-repositories-to-git/)
-- [Man page of the `git-cvsimport` tool](https://www.kernel.org/pub/software/scm/git/docs/git-cvsimport.html)
+- [Convert a CVS repository to Git](https://www.techrepublic.com/blog/linux-and-open-source/convert-cvs-repositories-to-git/)
+- [Man page of the `git-cvsimport` tool](https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-cvsimport.html)
diff --git a/doc/user/project/import/gemnasium.md b/doc/user/project/import/gemnasium.md
index 3217bbc4772..f1121745c7e 100644
--- a/doc/user/project/import/gemnasium.md
+++ b/doc/user/project/import/gemnasium.md
@@ -53,7 +53,7 @@ Otherwise, you must configure your `.gitlab-ci.yml` according to the
 
 ### If your project is hosted on GitHub (`https://github.com` / GitHub Enterprise)
 
-Since [GitLab 10.6 comes with GitHub integration](https://about.gitlab.com/features/github/),
+Since [GitLab 10.6 comes with GitHub integration](https://about.gitlab.com/solutions/github/),
 GitLab users can now create a CI/CD project in GitLab connected to an external
 GitHub.com or GitHub Enterprise repository. This will automatically prompt
 GitLab CI/CD to run whenever code is pushed to GitHub and post CI/CD results
@@ -81,7 +81,7 @@ back to both GitLab and GitHub when completed.
 
    Optional step: If you set this up on GitLab.com, make sure the project is
    public (in the project settings) if your GitHub project is public, since
-   the security feature is available only for [GitLab Ultimate](https://about.gitlab.com/pricing).
+   the security feature is available only for [GitLab Ultimate](https://about.gitlab.com/pricing/).
 
 1. To set up the dependency scanning job, corresponding to what Gemnasium was
    doing, you must create a `.gitlab-ci.yml` file, or update it according to
diff --git a/doc/user/project/import/gitea.md b/doc/user/project/import/gitea.md
index f5746a0fb31..f883e4474e2 100644
--- a/doc/user/project/import/gitea.md
+++ b/doc/user/project/import/gitea.md
@@ -43,8 +43,8 @@ Click on the **Gitea** link and the import authorization process will start.
 With this method, you will perform a one-off authorization with Gitea to grant
 GitLab access your repositories:
 
-1. Go to <https://you-gitea-instance/user/settings/applications> (replace
-   `you-gitea-instance` with the host of your Gitea instance).
+1. Go to `https://your-gitea-instance/user/settings/applications` (replace
+   `your-gitea-instance` with the host of your Gitea instance).
 1. Click **Generate New Token**.
 1. Enter a token description.
 1. Click **Generate Token**.
@@ -66,10 +66,14 @@ From there, you can see the import statuses of your Gitea repositories.
 - whereas those that are not yet imported will have an **Import** button on the
   right side of the table.
 
-If you want, you can import all your Gitea projects in one go by hitting
-**Import all projects** in the upper left corner.
+You also can:
 
-![Gitea importer page](img/import_projects_from_github_importer.png)
+- Import all your Gitea projects in one go by hitting **Import all projects** in
+  the upper left corner
+- Filter projects by name. If filter is applied, hitting **Import all projects**
+  will only import matched projects
+
+![Gitea importer page](img/import_projects_from_gitea_importer_v12_3.png)
 
 ---
 
diff --git a/doc/user/project/import/github.md b/doc/user/project/import/github.md
index dad53a600dc..0aeca7f73ad 100644
--- a/doc/user/project/import/github.md
+++ b/doc/user/project/import/github.md
@@ -42,7 +42,7 @@ assignees in the database of the GitLab instance (note that pull requests are ca
 
 For this association to succeed, prior to the import, each GitHub author and assignee in the repository must
 have either previously logged in to a GitLab account using the GitHub icon **or** have a GitHub account with
-a [public email address](https://help.github.com/articles/setting-your-commit-email-address-on-github/) that
+a [public email address](https://help.github.com/en/articles/setting-your-commit-email-address) that
 matches their GitLab account's email address.
 
 If a user referenced in the project is not found in GitLab's database, the project creator (typically the user
@@ -71,7 +71,7 @@ Before you begin, ensure that any GitHub users who you want to map to GitLab use
 
 - A GitLab account that has logged in using the GitHub icon
   \- or -
-- A GitLab account with an email address that matches the [public email address](https://help.github.com/articles/setting-your-commit-email-address-on-github/) of the GitHub user
+- A GitLab account with an email address that matches the [public email address](https://help.github.com/en/articles/setting-your-commit-email-address) of the GitHub user
 
 User-matching attempts occur in that order, and if a user is not identified either way, the activity is associated with
 the user account that is performing the import.
@@ -82,7 +82,7 @@ If you are using a self-hosted GitLab instance or if you are importing from GitH
 
 1. From the top navigation bar, click **+** and select **New project**.
 1. Select the **Import project** tab and then select **GitHub**.
-1. Select the first button to **List your GitHub repositories**. You are redirected to a page on github.com to authorize the GitLab application.
+1. Select the first button to **List your GitHub repositories**. You are redirected to a page on [GitHub](https://github.com) to authorize the GitLab application.
 1. Click **Authorize gitlabhq**. You are redirected back to GitLab's Import page and all of your GitHub repositories are listed.
 1. Continue on to [selecting which repositories to import](#selecting-which-repositories-to-import).
 
@@ -115,11 +115,14 @@ your GitHub repositories are listed.
 
 1. By default, the proposed repository namespaces match the names as they exist in GitHub, but based on your permissions,
    you can choose to edit these names before you proceed to import any of them.
-1. Select the **Import** button next to any number of repositories, or select **Import all repositories**.
+1. Select the **Import** button next to any number of repositories, or select **Import all repositories**. Additionally,
+   you can filter projects by name. If filter is applied, **Import all repositories** only imports matched repositories.
 1. The **Status** column shows the import status of each repository. You can choose to leave the page open and it will
    update in realtime or you can return to it later.
 1. Once a repository has been imported, click its GitLab path to open its GitLab URL.
 
+![Github importer page](img/import_projects_from_github_importer_v12_3.png)
+
 ## Mirroring and pipeline status sharing
 
 Depending your GitLab tier, [project mirroring](../../../workflow/repository_mirroring.md) can be set up to keep
diff --git a/doc/user/project/import/img/bitbucket_import_select_project.png b/doc/user/project/import/img/bitbucket_import_select_project.png
deleted file mode 100644
index 1bca6166ec8..00000000000
--- a/doc/user/project/import/img/bitbucket_import_select_project.png
+++ /dev/null
diff --git a/doc/user/project/import/img/bitbucket_import_select_project_v12_3.png b/doc/user/project/import/img/bitbucket_import_select_project_v12_3.png
new file mode 100644
index 00000000000..1f1febd9068
--- /dev/null
+++ b/doc/user/project/import/img/bitbucket_import_select_project_v12_3.png
diff --git a/doc/user/project/import/img/import_projects_from_gitea_importer_v12_3.png b/doc/user/project/import/img/import_projects_from_gitea_importer_v12_3.png
new file mode 100644
index 00000000000..d8ae1a54851
--- /dev/null
+++ b/doc/user/project/import/img/import_projects_from_gitea_importer_v12_3.png
diff --git a/doc/user/project/import/img/import_projects_from_github_importer.png b/doc/user/project/import/img/import_projects_from_github_importer.png
deleted file mode 100644
index d8effaf6075..00000000000
--- a/doc/user/project/import/img/import_projects_from_github_importer.png
+++ /dev/null
diff --git a/doc/user/project/import/img/import_projects_from_github_importer_v12_3.png b/doc/user/project/import/img/import_projects_from_github_importer_v12_3.png
new file mode 100644
index 00000000000..6a53d9e6d1d
--- /dev/null
+++ b/doc/user/project/import/img/import_projects_from_github_importer_v12_3.png
diff --git a/doc/user/project/import/index.md b/doc/user/project/import/index.md
index ecd491d8e5b..571968dd065 100644
--- a/doc/user/project/import/index.md
+++ b/doc/user/project/import/index.md
@@ -1,7 +1,7 @@
 # Migrating projects to a GitLab instance
 
-1. [From Bitbucket Cloud (aka bitbucket.org)](bitbucket.md)
-1. [From Bitbucket Server (aka Stash)](bitbucket_server.md)
+1. [From Bitbucket Cloud](bitbucket.md)
+1. [From Bitbucket Server (also known as Stash)](bitbucket_server.md)
 1. [From ClearCase](clearcase.md)
 1. [From CVS](cvs.md)
 1. [From FogBugz](fogbugz.md)
@@ -24,7 +24,7 @@ There is also the option of [connecting your external repository to get CI/CD be
 
 ## Migrating from self-hosted GitLab to GitLab.com
 
-If you only need to migrate git repos, you can [import each project by URL](repo_by_url.md), but issues and merge requests can't be imported.
+If you only need to migrate Git repos, you can [import each project by URL](repo_by_url.md), but issues and merge requests can't be imported.
 
 If you want to retain all metadata like issues and merge requests, you can use
 the [import/export feature](../settings/import_export.md) to export projects from self-hosted GitLab and import those projects into GitLab.com.
@@ -34,7 +34,7 @@ This approach assumes all users from the self-hosted instance have already been
 If the users haven't been migrated yet, the user conducting the import
 will take the place of all references to the missing user(s).
 
-If you need to migrate all data over, you can leverage our [api](../../../api/README.md) to migrate from self-hosted to GitLab.com.
+If you need to migrate all data over, you can leverage our [API](../../../api/README.md) to migrate from self-hosted to GitLab.com.
 The order of assets to migrate from a self-hosted instance to GitLab is the following:
 
 1. [Users](../../../api/users.md)
diff --git a/doc/user/project/import/perforce.md b/doc/user/project/import/perforce.md
index a1ea716b606..a08488a4baf 100644
--- a/doc/user/project/import/perforce.md
+++ b/doc/user/project/import/perforce.md
@@ -45,8 +45,8 @@ submit back from Git to Perforce.
 
 Here's a few links to get you started:
 
-- [git-p4 manual page](https://www.kernel.org/pub/software/scm/git/docs/git-p4.html)
-- [git-p4 example usage](https://git.wiki.kernel.org/index.php/Git-p4_Usage)
+- [`git-p4` manual page](https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-p4.html)
+- [`git-p4` example usage](https://git.wiki.kernel.org/index.php/Git-p4_Usage)
 - [Git book migration guide](https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git#_perforce_import)
 
 Note that `git p4` and `git filter-branch` are not very good at
diff --git a/doc/user/project/import/svn.md b/doc/user/project/import/svn.md
index 267dca5bf4d..6b22c5f2fd0 100644
--- a/doc/user/project/import/svn.md
+++ b/doc/user/project/import/svn.md
@@ -97,7 +97,7 @@ subgit import $GIT_REPO_PATH
 ### SubGit licensing
 
 Running SubGit in a mirror mode requires a
-[registration](https://subgit.com/pricing/). Registration is free for open
+[registration](https://subgit.com/pricing). Registration is free for open
 source, academic and startup projects.
 
 We're currently working on deeper GitLab/SubGit integration. You may track our
diff --git a/doc/user/project/index.md b/doc/user/project/index.md
index 2700d43ed10..7ae288996da 100644
--- a/doc/user/project/index.md
+++ b/doc/user/project/index.md
@@ -59,10 +59,10 @@ When you create a project in GitLab, you'll have access to a large number of
 
 **GitLab CI/CD:**
 
-- [GitLab CI/CD](../../ci/README.md): GitLab's built-in [Continuous Integration, Delivery, and Deployment](https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/) tool
+- [GitLab CI/CD](../../ci/README.md): GitLab's built-in [Continuous Integration, Delivery, and Deployment](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/) tool
   - [Container Registry](../packages/container_registry/index.md): Build and push Docker
   images out-of-the-box
-  - [Auto Deploy](../../ci/autodeploy/index.md): Configure GitLab CI/CD
+  - [Auto Deploy](../../topics/autodevops/index.md#auto-deploy): Configure GitLab CI/CD
   to automatically set up your app's deployment
   - [Enable and disable GitLab CI](../../ci/enable_or_disable_ci.md)
   - [Pipelines](../../ci/pipelines.md): Configure and visualize
@@ -95,6 +95,7 @@ When you create a project in GitLab, you'll have access to a large number of
 - [Releases](releases/index.md): a way to track deliverables in your project as snapshot in time of
   the source, build output, and other metadata or artifacts
   associated with a released version of your code.
+- [Conan packages](../packages/conan_repository/index.md): your private Conan repository in GitLab. **(PREMIUM)**
 - [Maven packages](../packages/maven_repository/index.md): your private Maven repository in GitLab. **(PREMIUM)**
 - [NPM packages](../packages/npm_registry/index.md): your private NPM package registry in GitLab. **(PREMIUM)**
 - [Code owners](code_owners.md): specify code owners for certain files **(STARTER)**
@@ -129,7 +130,7 @@ Read through the documentation on [project settings](settings/index.md).
 
 - [Import a project](import/index.md) from:
   - [GitHub to GitLab](import/github.md)
-  - [BitBucket to GitLab](import/bitbucket.md)
+  - [Bitbucket to GitLab](import/bitbucket.md)
   - [Gitea to GitLab](import/gitea.md)
   - [FogBugz to GitLab](import/fogbugz.md)
 - [Export a project from GitLab](settings/import_export.md#exporting-a-project-and-its-data)
@@ -154,6 +155,26 @@ when a project is part of a group (under a
 If you choose to leave a project you will no longer be a project
 member, therefore, unable to contribute.
 
+## Project's landing page
+
+The project's landing page shows different information depending on
+the project's visibility settings and user permissions.
+
+For public projects, and to members of internal and private projects
+with [permissions to view the project's code](../permissions.md#project-members-permissions):
+
+- The content of a
+  [`README` or an index file](repository/#repository-readme-and-index-files)
+  is displayed (if any), followed by the list of directories within the
+  project's repository.
+- If the project doesn't contain either of these files, the
+  visitor will see the list of files and directories of the repository.
+
+For users without permissions to view the project's code:
+
+- The wiki homepage is displayed, if any.
+- The list of issues within the project is displayed.
+
 ## Redirects when changing repository paths
 
 When a repository path changes, it is essential to smoothly transition from the
@@ -214,10 +235,10 @@ A project alias can be only created via API and only by GitLab administrators.
 Follow the [Project Aliases API documentation](../../api/project_aliases.md) for
 more details.
 
-Once an alias has been created for a project (e.g., an alias `gitlab-ce` for the
-project `https://gitlab.com/gitlab-org/gitlab-foss`), the repository can be cloned
-using the alias (e.g `git clone git@gitlab.com:gitlab-ce.git` instead of
-`git clone git@gitlab.com:gitlab-org/gitlab-ce.git`).
+Once an alias has been created for a project (e.g., an alias `gitlab` for the
+project `https://gitlab.com/gitlab-org/gitlab`), the repository can be cloned
+using the alias (e.g `git clone git@gitlab.com:gitlab.git` instead of
+`git clone git@gitlab.com:gitlab-org/gitlab.git`).
 
 ## Project APIs
 
diff --git a/doc/user/project/insights/index.md b/doc/user/project/insights/index.md
index 76a6a96eec5..ec3831f2d27 100644
--- a/doc/user/project/insights/index.md
+++ b/doc/user/project/insights/index.md
@@ -58,9 +58,9 @@ For example, here's a single definition for Insights that will display one page
 
 ```yaml
 bugsCharts:
-  title: 'Charts for Bugs'
+  title: "Charts for bugs"
   charts:
-    - title: Monthly Bugs Created (bar)
+    - title: "Monthly bugs created"
       type: bar
       query:
         issuable_type: issue
@@ -76,7 +76,7 @@ Each chart definition is made up of a hash composed of key-value pairs.
 For example, here's single chart definition:
 
 ```yaml
-- title: Monthly Bugs Created (bar)
+- title: "Monthly bugs created"
   type: bar
   query:
     issuable_type: issue
@@ -111,7 +111,7 @@ For example:
 
 ```yaml
 monthlyBugsCreated:
-  title: Monthly Bugs Created (bar)
+  title: "Monthly bugs created"
 ```
 
 ### `type`
@@ -122,7 +122,7 @@ For example:
 
 ```yaml
 monthlyBugsCreated:
-  title: Monthly Bugs Created (bar)
+  title: "Monthly bugs created"
   type: bar
 ```
 
@@ -145,7 +145,7 @@ Example:
 
 ```yaml
 monthlyBugsCreated:
-  title: Monthly Bugs Created (bar)
+  title: "Monthly bugs created"
   type: bar
   query:
     issuable_type: issue
@@ -174,7 +174,7 @@ Supported values are:
 
 Filter by the state of the queried "issuable".
 
-If you omit it, the `opened` state filter will be applied.
+By default, the `opened` state filter will be applied.
 
 Supported values are:
 
@@ -188,14 +188,14 @@ Supported values are:
 
 Filter by labels applied to the queried "issuable".
 
-If you omit it, no labels filter will be applied. All the defined labels must be
+By default, no labels filter will be applied. All the defined labels must be
 applied to the "issuable" in order for it to be selected.
 
 Example:
 
 ```yaml
 monthlyBugsCreated:
-  title: Monthly regressions Created (bar)
+  title: "Monthly regressions created"
   type: bar
   query:
     issuable_type: issue
@@ -209,14 +209,14 @@ monthlyBugsCreated:
 
 Group "issuable" by the configured labels.
 
-If you omit it, no grouping will be done. When using this keyword, you need to
+By default, no grouping will be done. When using this keyword, you need to
 set `type` to either `line` or `stacked-bar`.
 
 Example:
 
 ```yaml
 weeklyBugsBySeverity:
-  title: Weekly Bugs By Severity (stacked bar)
+  title: "Weekly bugs by severity"
   type: stacked-bar
   query:
     issuable_type: issue
@@ -248,7 +248,7 @@ The unit is related to the `query.group_by` you defined. For instance if you
 defined `query.group_by: 'day'`  then `query.period_limit: 365` would mean
 "Gather and display data for the last 365 days".
 
-If you omit it, default values will be applied depending on the `query.group_by`
+By default, default values will be applied depending on the `query.group_by`
 you defined.
 
 | `query.group_by` | Default value |
@@ -257,14 +257,63 @@ you defined.
 | `week`           | 4             |
 | `month`          | 12            |
 
+### `projects`
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/10904) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.4.
+
+You can limit where the "issuables" can be queried from:
+
+- If `.gitlab/insights.yml` is used for a [group's insights](../../group/insights/index.md#configure-your-insights), with `projects`, you can limit the projects to be queried. By default, all projects under the group will be used.
+- If `.gitlab/insights.yml` is used for a project's insights, specifying any other projects will yield no results. By default, the project itself will be used.
+
+#### `projects.only`
+
+The `projects.only` option specifies the projects which the "issuables"
+should be queried from.
+
+Projects listed here will be ignored when:
+
+- They don't exist.
+- The current user doesn't have sufficient permissions to read them.
+- They are outside of the group.
+
+In the following `insights.yml` example, we specify the projects
+the queries will be used on. This example is useful when setting
+a group's insights:
+
+```yaml
+monthlyBugsCreated:
+  title: "Monthly bugs created"
+  type: bar
+  query:
+    issuable_type: issue
+    issuable_state: opened
+    filter_labels:
+      - bug
+  projects:
+    only:
+      - 3                         # You can use the project ID
+      - groupA/projectA           # Or full project path
+      - groupA/subgroupB/projectC # Projects in subgroups can be included
+      - groupB/project            # Projects outside the group will be ignored
+```
+
 ## Complete example
 
 ```yaml
+.projectsOnly: &projectsOnly
+  projects:
+    only:
+      - 3
+      - groupA/projectA
+      - groupA/subgroupB/projectC
+
 bugsCharts:
-  title: 'Charts for Bugs'
+  title: "Charts for bugs"
   charts:
-    - title: Monthly Bugs Created (bar)
+    - title: "Monthly bugs created"
       type: bar
+      <<: *projectsOnly
       query:
         issuable_type: issue
         issuable_state: opened
@@ -272,8 +321,10 @@ bugsCharts:
           - bug
         group_by: month
         period_limit: 24
-    - title: Weekly Bugs By Severity (stacked bar)
+
+    - title: "Weekly bugs by severity"
       type: stacked-bar
+      <<: *projectsOnly
       query:
         issuable_type: issue
         issuable_state: opened
@@ -286,8 +337,10 @@ bugsCharts:
           - S4
         group_by: week
         period_limit: 104
-    - title: Monthly Bugs By Team (line)
+
+    - title: "Monthly bugs by team"
       type: line
+      <<: *projectsOnly
       query:
         issuable_type: merge_request
         issuable_state: opened
diff --git a/doc/user/project/integrations/bamboo.md b/doc/user/project/integrations/bamboo.md
index 94e0c9fd886..ec9b8bd8bb2 100644
--- a/doc/user/project/integrations/bamboo.md
+++ b/doc/user/project/integrations/bamboo.md
@@ -25,9 +25,9 @@ need to be configured in a Bamboo build plan before GitLab can integrate.
    whitelist of IP addresses that are allowed to trigger Bamboo builds.
 1. Save the trigger.
 1. In the left pane, select a build stage. If you have multiple build stages
-   you want to select the last stage that contains the git checkout task.
+   you want to select the last stage that contains the Git checkout task.
 1. Select the 'Miscellaneous' tab.
-1. Under 'Pattern Match Labelling' put '${bamboo.repository.revision.number}'
+1. Under 'Pattern Match Labelling' put `${bamboo.repository.revision.number}`
    in the 'Labels' box.
 1. Save
 
diff --git a/doc/user/project/integrations/generic_alerts.md b/doc/user/project/integrations/generic_alerts.md
index 37fe5132ec2..ec43696fdee 100644
--- a/doc/user/project/integrations/generic_alerts.md
+++ b/doc/user/project/integrations/generic_alerts.md
@@ -1,6 +1,6 @@
 # Generic alerts integration **(ULTIMATE)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/13203) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.3.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/13203) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.3.
 
 GitLab can accept alerts from any source via a generic webhook receiver.
 When you set up the generic alerts integration, a unique endpoint will
@@ -13,11 +13,11 @@ authored by the GitLab Alert Bot.
 
 ## Setting up generic alerts
 
-To set up the generic alerts integration:  
+To set up the generic alerts integration:
 
-1. Navigate to **Settings > Integrations** in a project.  
+1. Navigate to **Settings > Integrations** in a project.
 1. Click on **Alert endpoint**.
-1. Toggle the **Active**  alert setting. The `URL` and `Authorization Key` for the webhook configuration can be found there.  
+1. Toggle the **Active**  alert setting. The `URL` and `Authorization Key` for the webhook configuration can be found there.
 
 ## Customizing the payload
 
@@ -35,7 +35,11 @@ You can customize the payload by sending the following parameters. All fields ar
 Example request:
 
 ```sh
-curl --request POST --data '{"title": "Incident title"}' --header "Authorization: Bearer <autorization_key>" <url>
+curl --request POST \
+  --data '{"title": "Incident title"}' \
+  --header "Authorization: Bearer <autorization_key>" \
+  --header "Content-Type: application/json" \
+  <url>
 ```
 
 The `<autorization_key>` and `<url>` values can be found when [setting up generic alerts](#setting-up-generic-alerts).
diff --git a/doc/user/project/integrations/gitlab_slack_application.md b/doc/user/project/integrations/gitlab_slack_application.md
index 91de64be1fa..50adb5993e5 100644
--- a/doc/user/project/integrations/gitlab_slack_application.md
+++ b/doc/user/project/integrations/gitlab_slack_application.md
@@ -53,11 +53,11 @@ The only difference with the [manually configurable Slack slash commands][slack-
 is that all the commands should be prefixed with the `/gitlab` keyword.
 We are working on making this configurable in the future.
 
-For example, to show the issue number `1001` under the `gitlab-org/gitlab-ce`
+For example, to show the issue number `1001` under the `gitlab-org/gitlab`
 project, you would do:
 
 ```
-/gitlab gitlab-org/gitlab-ce issue show 1001
+/gitlab gitlab-org/gitlab issue show 1001
 ```
 
 [slack-docs]: https://get.slack.help/hc/en-us/articles/202035138-Adding-apps-to-your-team
diff --git a/doc/user/project/integrations/hipchat.md b/doc/user/project/integrations/hipchat.md
index 7a0540aa9e3..85c3eda1208 100644
--- a/doc/user/project/integrations/hipchat.md
+++ b/doc/user/project/integrations/hipchat.md
@@ -18,7 +18,7 @@ allow GitLab to send messages only to *one* room.
 
 ### Complete these steps in HipChat
 
-1. Go to: <https://admin.hipchat.com/admin>
+1. Go to: `https://admin.hipchat.com/admin`
 1. Click on "Group Admin" -> "Integrations".
 1. Find "Build Your Own!" and click "Create".
 1. Select the desired room, name the integration "GitLab", and click "Create".
diff --git a/doc/user/project/integrations/img/prometheus_add_metric.png b/doc/user/project/integrations/img/prometheus_add_metric.png
index e85670e1a13..9afeb535123 100644
--- a/doc/user/project/integrations/img/prometheus_add_metric.png
+++ b/doc/user/project/integrations/img/prometheus_add_metric.png
diff --git a/doc/user/project/integrations/img/prometheus_alert.png b/doc/user/project/integrations/img/prometheus_alert.png
index a37f0477fd9..ffa1008ff51 100644
--- a/doc/user/project/integrations/img/prometheus_alert.png
+++ b/doc/user/project/integrations/img/prometheus_alert.png
diff --git a/doc/user/project/integrations/img/prometheus_dashboard.png b/doc/user/project/integrations/img/prometheus_dashboard.png
index 1fa36ca2675..24d855eb50c 100644
--- a/doc/user/project/integrations/img/prometheus_dashboard.png
+++ b/doc/user/project/integrations/img/prometheus_dashboard.png
diff --git a/doc/user/project/integrations/irker.md b/doc/user/project/integrations/irker.md
index 4fb753d1707..22228025969 100644
--- a/doc/user/project/integrations/irker.md
+++ b/doc/user/project/integrations/irker.md
@@ -15,7 +15,7 @@ repository on <https://gitlab.com/esr/irker>:
 git clone https://gitlab.com/esr/irker.git
 ```
 
-Once you have downloaded the code, you can run the python script named `irkerd`.
+Once you have downloaded the code, you can run the Python script named `irkerd`.
 This script is the gateway script, it acts both as an IRC client, for sending
 messages to an IRC server obviously, and as a TCP server, for receiving messages
 from the GitLab service.
diff --git a/doc/user/project/integrations/jira.md b/doc/user/project/integrations/jira.md
index 1b8af89de61..6d2a0563ec1 100644
--- a/doc/user/project/integrations/jira.md
+++ b/doc/user/project/integrations/jira.md
@@ -21,13 +21,13 @@ Here's how the integration responds when you take the following actions in GitLa
   - GitLab hyperlinks to the Jira issue.
   - The Jira issue adds an issue link to the commit/MR in GitLab.
   - The Jira issue adds a comment reflecting the comment made in GitLab, the comment author, and a link to the commit/MR in GitLab.
-- **Mention that a commit or MR 'closes', 'resolves', or 'fixes' a Jira issue ID**. When the commit is made on master or the change is merged to master:
+- **Mention that a commit or MR 'closes', 'resolves', or 'fixes' a Jira issue ID**. When the commit is made on the project's default branch (usually master) or the change is merged to the default branch:
   - GitLab's merge request page displays a note that it "Closed" the Jira issue, with a link to the issue. (Note: Before the merge, an MR will display that it "Closes" the Jira issue.)
   - The Jira issue shows the activity and the Jira issue is closed, or otherwise transitioned.
 
-You can also use [Jira's Smart Commits](https://confluence.atlassian.com/fisheye/using-smart-commits-298976812.html)
+You can also use [Jira's Smart Commits](https://confluence.atlassian.com/fisheye/using-smart-commits-960155400.html)
 directly from GitLab, as covered in the article
-[How and why to integrate GitLab with Jira](https://www.programmableweb.com/news/how-and-why-to-integrate-gitlab-Jira/how-to/2017/04/25).
+[How and why to integrate GitLab with Jira](https://www.programmableweb.com/news/how-and-why-to-integrate-gitlab-jira/how-to/2017/04/25).
 
 ## Configuration
 
@@ -45,7 +45,7 @@ In order to enable the Jira service in GitLab, you need to first configure the p
 
 #### Jira Server
 
-When connecting to **Jira Server**, which supports basic authentication, a **username and password** are required. Note that connecting to a Jira server via CAS is not possible. [Set up a user in Jira Server](jira_server_configuration.md) first and then proceed to [Configuring GitLab](#configuring-gitlab).
+When connecting to **Jira Server**, which supports basic authentication, a **username and password** are required. Note that connecting to Jira Server via CAS is not possible. [Set up a user in Jira Server](jira_server_configuration.md) first and then proceed to [Configuring GitLab](#configuring-gitlab).
 
 #### Jira Cloud
 
@@ -205,4 +205,4 @@ authenticate with the Jira site. You will need to log in to your Jira instance
 and complete the CAPTCHA.
 
 [services-templates]: services_templates.md
-[jira-repo-old-docs]: https://gitlab.com/gitlab-org/gitlab-foss/blob/8-13-stable/doc/project_services/jira.md
+[jira-repo-old-docs]: https://gitlab.com/gitlab-org/gitlab/blob/8-13-stable/doc/project_services/jira.md
diff --git a/doc/user/project/integrations/jira_cloud_configuration.md b/doc/user/project/integrations/jira_cloud_configuration.md
index 1d5a4a3d4c7..9fa92f19e4f 100644
--- a/doc/user/project/integrations/jira_cloud_configuration.md
+++ b/doc/user/project/integrations/jira_cloud_configuration.md
@@ -15,6 +15,6 @@ below to create one:
 
 ![Jira API token](img/jira_api_token.png)
 
-1. Click **Copy to clipboard**, or click **View** and write down the new API token. It is required when [configuring GitLab](jira.md#configuring-gitlab).
+1. Click **Copy**, or click **View** and write down the new API token. It is required when [configuring GitLab](jira.md#configuring-gitlab).
 
 The Jira configuration is complete. You need the newly created token, and the associated email address, when [configuring GitLab](jira.md#configuring-gitlab) in the next section.
diff --git a/doc/user/project/integrations/mattermost_slash_commands.md b/doc/user/project/integrations/mattermost_slash_commands.md
index a3a2568445e..563cad717e2 100644
--- a/doc/user/project/integrations/mattermost_slash_commands.md
+++ b/doc/user/project/integrations/mattermost_slash_commands.md
@@ -131,12 +131,12 @@ The available slash commands are:
 
 | Command | Description | Example |
 | ------- | ----------- | ------- |
-| <kbd>/&lt;trigger&gt; issue new &lt;title&gt; <kbd>⇧ Shift</kbd>+<kbd>↵ Enter</kbd> &lt;description&gt;</kbd> | Create a new issue in the project that `<trigger>` is tied to. `<description>` is optional. | <samp>/gitlab issue new We need to change the homepage</samp> |
-| <kbd>/&lt;trigger&gt; issue show &lt;issue-number&gt;</kbd> | Show the issue with ID `<issue-number>` from the project that `<trigger>` is tied to. | <samp>/gitlab issue show 42</samp> |
-| <kbd>/&lt;trigger&gt; deploy &lt;environment&gt; to &lt;environment&gt;</kbd> | Start the CI job that deploys from one environment to another, for example `staging` to `production`. CI/CD must be [properly configured][ciyaml]. | <samp>/gitlab deploy staging to production</samp> |
+| <kbd>/&lt;trigger&gt; issue new &lt;title&gt; <kbd>⇧ Shift</kbd>+<kbd>↵ Enter</kbd> &lt;description&gt;</kbd> | Create a new issue in the project that `<trigger>` is tied to. `<description>` is optional. | `/gitlab issue new We need to change the homepage` |
+| <kbd>/&lt;trigger&gt; issue show &lt;issue-number&gt;</kbd> | Show the issue with ID `<issue-number>` from the project that `<trigger>` is tied to. | `/gitlab issue show 42` |
+| <kbd>/&lt;trigger&gt; deploy &lt;environment&gt; to &lt;environment&gt;</kbd> | Start the CI job that deploys from one environment to another, for example `staging` to `production`. CI/CD must be [properly configured][ciyaml]. | `/gitlab deploy staging to production` |
 
 To see a list of available commands to interact with GitLab, type the
-trigger word followed by <kbd>help</kbd>. Example: <samp>/gitlab help</samp>
+trigger word followed by <kbd>help</kbd>. Example: `/gitlab help`
 
 ![Mattermost bot available commands](img/mattermost_bot_available_commands.png)
 
diff --git a/doc/user/project/integrations/project_services.md b/doc/user/project/integrations/project_services.md
index 168ec1b15ea..e385ee53636 100644
--- a/doc/user/project/integrations/project_services.md
+++ b/doc/user/project/integrations/project_services.md
@@ -56,6 +56,16 @@ Click on the service links to see further configuration instructions and details
 | [Redmine](redmine.md) | Redmine issue tracker |
 | [YouTrack](youtrack.md) | YouTrack issue tracker |
 
+## Push hooks limit
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/31009) in GitLab 12.4.
+
+If a single push includes changes to more than three branches or tags, services
+supported by `push_hooks` and `tag_push_hooks` events won't be executed.
+
+The number of branches or tags supported can be changed via
+[`push_event_hooks_limit` application setting](../../../api/settings.md#list-of-settings-that-can-be-accessed-via-api-calls).
+
 ## Services templates
 
 Services templates is a way to set some predefined values in the Service of
diff --git a/doc/user/project/integrations/prometheus.md b/doc/user/project/integrations/prometheus.md
index 1ecefa210a0..d7666d00e76 100644
--- a/doc/user/project/integrations/prometheus.md
+++ b/doc/user/project/integrations/prometheus.md
@@ -115,7 +115,7 @@ You can view the performance dashboard for an environment by [clicking on the mo
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/3799) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.6.
 
-Custom metrics can be monitored by adding them on the Prometheus integration page. Once saved, they will be displayed on the environment performance dashboard provided that either:
+Custom metrics can be monitored by adding them on the monitoring dashboard page. Once saved, they will be displayed on the environment performance dashboard provided that either:
 
 - A [connected Kubernetes cluster](../clusters/index.md#adding-and-removing-clusters) with the environment scope of `*` is used and [Prometheus installed on the cluster](#enabling-prometheus-integration), or
 - Prometheus is [manually configured](#manual-configuration-of-prometheus).
@@ -300,8 +300,12 @@ Data from Prometheus charts on the metrics dashboard can be downloaded as CSV.
 
 For managed Prometheus instances using auto configuration, alerts for metrics [can be configured](#adding-additional-metrics-premium) directly in the performance dashboard.
 
-To set an alert, click on the alarm icon in the top right corner of the metric you want to create the alert for. A dropdown
-will appear, with options to set the threshold and operator. Click **Add** to save and activate the alert.
+To set an alert:
+
+1. Click on the ellipsis icon in the top right corner of the metric you want to create the alert for.
+1. Choose **Alerts**
+1. Set threshold and operator.
+1. Click **Add** to save and activate the alert.
 
 ![Adding an alert](img/prometheus_alert.png)
 
@@ -441,7 +445,7 @@ If the "No data found" screen continues to appear, it could be due to:
   [run a query](prometheus_library/kubernetes.html#metrics-supported), replacing `$CI_ENVIRONMENT_SLUG`
   with the name of your environment.
 
-[autodeploy]: ../../../ci/autodeploy/index.md
+[autodeploy]: ../../../topics/autodevops/index.md#auto-deploy
 [kubernetes]: https://kubernetes.io
 [kube]: ./kubernetes.md
 [prometheus-k8s-sd]: https://prometheus.io/docs/operating/configuration/#<kubernetes_sd_config>
diff --git a/doc/user/project/integrations/prometheus_library/nginx_ingress.md b/doc/user/project/integrations/prometheus_library/nginx_ingress.md
index 1966fc1d289..d630956c109 100644
--- a/doc/user/project/integrations/prometheus_library/nginx_ingress.md
+++ b/doc/user/project/integrations/prometheus_library/nginx_ingress.md
@@ -4,7 +4,7 @@
 
 NOTE: **Note:** NGINX Ingress versions prior to 0.16.0 offer an included [VTS Prometheus metrics exporter](nginx_ingress_vts.md), which exports metrics different than the built-in metrics.
 
-GitLab has support for automatically detecting and monitoring the Kubernetes NGINX ingress controller. This is provided by leveraging the built-in Prometheus metrics included starting with [version 0.16.0](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0160).
+GitLab has support for automatically detecting and monitoring the Kubernetes NGINX Ingress controller. This is provided by leveraging the built-in Prometheus metrics included with Kubernetes NGINX Ingress controller [version 0.16.0](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0160) onward.
 
 ## Requirements
 
@@ -18,7 +18,7 @@ GitLab has support for automatically detecting and monitoring the Kubernetes NGI
 | Latency (ms) | `sum(rate(nginx_ingress_controller_ingress_upstream_latency_seconds_sum{namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m])) / sum(rate(nginx_ingress_controller_ingress_upstream_latency_seconds_count{namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m])) * 1000` |
 | HTTP Error Rate (%) | `sum(rate(nginx_ingress_controller_requests{status=~"5.*",namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m])) / sum(rate(nginx_ingress_controller_requests{namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m])) * 100` |
 
-## Configuring NGINX ingress monitoring
+## Configuring NGINX Ingress monitoring
 
 If you have deployed NGINX Ingress using GitLab's [Kubernetes cluster integration](../../clusters/index.md#installing-applications), it will [automatically be monitored](#about-managed-nginx-ingress-deployments) by Prometheus.
 
@@ -30,7 +30,7 @@ For other deployments, there is [some configuration](#manually-setting-up-nginx-
 
 ### About managed NGINX Ingress deployments
 
-NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress). NGINX Ingress will be [externally reachable via the Load Balancer's Endpoint](../../clusters/index.md#getting-the-external-endpoint).
+NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress). NGINX Ingress will be [externally reachable via the Load Balancer's Endpoint](../../clusters/index.md#getting-the-external-endpoint).
 
 NGINX is configured for Prometheus monitoring, by setting:
 
@@ -42,14 +42,14 @@ When used in conjunction with the GitLab deployed Prometheus service, response m
 
 ### Manually setting up NGINX Ingress for Prometheus monitoring
 
-Version 0.9.0 and above of [NGINX ingress](https://github.com/kubernetes/ingress-nginx) have built-in support for exporting Prometheus metrics. To enable, a ConfigMap setting must be passed: `enable-vts-status: "true"`. Once enabled, a Prometheus metrics endpoint will start running on port 10254.
+Version 0.9.0 and above of [NGINX Ingress](https://github.com/kubernetes/ingress-nginx) have built-in support for exporting Prometheus metrics. To enable, a ConfigMap setting must be passed: `enable-vts-status: "true"`. Once enabled, a Prometheus metrics endpoint will start running on port 10254.
 
-Next, the ingress needs to be annotated for Prometheus monitoring. Two new annotations need to be added:
+Next, the Ingress needs to be annotated for Prometheus monitoring. Two new annotations need to be added:
 
 - `prometheus.io/scrape: "true"`
 - `prometheus.io/port: "10254"`
 
-Managing these settings depends on how NGINX ingress has been deployed. If you have deployed via the [official Helm chart](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress), metrics can be enabled with `controller.stats.enabled` along with the required annotations. Alternatively it is possible edit the NGINX ingress YML directly in the [Kubernetes dashboard](https://github.com/kubernetes/dashboard).
+Managing these settings depends on how NGINX Ingress has been deployed. If you have deployed via the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress), metrics can be enabled with `controller.stats.enabled` along with the required annotations. Alternatively it is possible to edit the NGINX Ingress YML directly in the [Kubernetes dashboard](https://github.com/kubernetes/dashboard).
 
 ## Specifying the Environment label
 
diff --git a/doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md b/doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md
index 0c848496149..83eac44666c 100644
--- a/doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md
+++ b/doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md
@@ -4,7 +4,7 @@
 
 NOTE: **Note:** [NGINX Ingress version 0.16](nginx_ingress.md) and above have built-in Prometheus metrics, which are different than the VTS based metrics.
 
-GitLab has support for automatically detecting and monitoring the Kubernetes NGINX ingress controller. This is provided by leveraging the included VTS Prometheus metrics exporter in [version 0.9.0](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#09-beta1) through [0.15.x](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0150).
+GitLab has support for automatically detecting and monitoring the Kubernetes NGINX Ingress controller. This is provided by leveraging the included VTS Prometheus metrics exporter in [version 0.9.0](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#09-beta1) through [0.15.x](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0150).
 
 ## Requirements
 
@@ -18,7 +18,7 @@ GitLab has support for automatically detecting and monitoring the Kubernetes NGI
 | Latency (ms) | `avg(nginx_upstream_response_msecs_avg{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"})` |
 | HTTP Error Rate (%) | `sum(rate(nginx_upstream_responses_total{status_code="5xx", upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[2m])) / sum(rate(nginx_upstream_responses_total{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[2m])) * 100` |
 
-## Configuring NGINX ingress monitoring
+## Configuring NGINX Ingress monitoring
 
 If you have deployed NGINX Ingress using GitLab's [Kubernetes cluster integration](../../clusters/index.md#installing-applications), it will [automatically be monitored](#about-managed-nginx-ingress-deployments) by Prometheus.
 
@@ -30,7 +30,7 @@ For other deployments, there is [some configuration](#manually-setting-up-nginx-
 
 ### About managed NGINX Ingress deployments
 
-NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress). NGINX Ingress will be [externally reachable via the Load Balancer's Endpoint](../../clusters/index.md#getting-the-external-endpoint).
+NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress). NGINX Ingress will be [externally reachable via the Load Balancer's Endpoint](../../clusters/index.md#getting-the-external-endpoint).
 
 NGINX is configured for Prometheus monitoring, by setting:
 
@@ -42,14 +42,14 @@ When used in conjunction with the GitLab deployed Prometheus service, response m
 
 ### Manually setting up NGINX Ingress for Prometheus monitoring
 
-Version 0.9.0 and above of [NGINX ingress](https://github.com/kubernetes/ingress-nginx) have built-in support for exporting Prometheus metrics. To enable, a ConfigMap setting must be passed: `enable-vts-status: "true"`. Once enabled, a Prometheus metrics endpoint will start running on port 10254.
+Version 0.9.0 and above of [NGINX Ingress](https://github.com/kubernetes/ingress-nginx) has built-in support for exporting Prometheus metrics. To enable, a ConfigMap setting must be passed: `enable-vts-status: "true"`. Once enabled, a Prometheus metrics endpoint will start running on port 10254.
 
-Next, the ingress needs to be annotated for Prometheus monitoring. Two new annotations need to be added:
+Next, the Ingress needs to be annotated for Prometheus monitoring. Two new annotations need to be added:
 
 - `prometheus.io/scrape: "true"`
 - `prometheus.io/port: "10254"`
 
-Managing these settings depends on how NGINX ingress has been deployed. If you have deployed via the [official Helm chart](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress), metrics can be enabled with `controller.stats.enabled` along with the required annotations. Alternatively it is possible edit the NGINX ingress YML directly in the [Kubernetes dashboard](https://github.com/kubernetes/dashboard).
+Managing these settings depends on how NGINX Ingress has been deployed. If you have deployed via the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress), metrics can be enabled with `controller.stats.enabled` along with the required annotations. Alternatively it is possible edit the NGINX Ingress YAML directly in the [Kubernetes dashboard](https://github.com/kubernetes/dashboard).
 
 ## Specifying the Environment label
 
diff --git a/doc/user/project/integrations/redmine.md b/doc/user/project/integrations/redmine.md
index 25b000b2753..56e219fade5 100644
--- a/doc/user/project/integrations/redmine.md
+++ b/doc/user/project/integrations/redmine.md
@@ -14,7 +14,7 @@
 
    Once you have configured and enabled Redmine you'll see the Redmine link on the GitLab project pages that takes you to the appropriate Redmine project.
 
-   As an example, below is a configuration for a project named gitlab-ci.
+   As an example, below is a configuration for a project named `gitlab-ci`.
 
    ![Redmine configuration](img/redmine_configuration.png)
 
diff --git a/doc/user/project/integrations/webhooks.md b/doc/user/project/integrations/webhooks.md
index ae6a215fc34..d0f538a4b52 100644
--- a/doc/user/project/integrations/webhooks.md
+++ b/doc/user/project/integrations/webhooks.md
@@ -53,7 +53,7 @@ Navigate to the webhooks page by going to your project's
   [Slack](https://api.slack.com/incoming-webhooks) every time a job fails.
 - You can [integrate with Twilio to be notified via SMS](https://www.datadoghq.com/blog/send-alerts-sms-customizable-webhooks-twilio/)
   every time an issue is created for a specific project or group within GitLab
-- You can use them to [automatically assign labels to merge requests](https://about.gitlab.com/2016/08/19/applying-gitlab-labels-automatically/).
+- You can use them to [automatically assign labels to merge requests](https://about.gitlab.com/blog/2016/08/19/applying-gitlab-labels-automatically/).
 
 ## Webhook endpoint tips
 
@@ -107,6 +107,9 @@ detailed commit data is expensive. Note that despite only 20 commits being
 present in the `commits` attribute, the `total_commits_count` attribute will
 contain the actual total.
 
+Also, if a single push includes changes for more than three (by default, depending on
+[`push_event_hooks_limit` setting](../../../api/settings.md#list-of-settings-that-can-be-accessed-via-api-calls)) branches, this hook won't be executed.
+
 **Request header**:
 
 ```
@@ -190,6 +193,10 @@ X-Gitlab-Event: Push Hook
 
 Triggered when you create (or delete) tags to the repository.
 
+NOTE: **Note:**
+If a single push includes changes for more than three (by default, depending on
+[`push_event_hooks_limit` setting](../../../api/settings.md#list-of-settings-that-can-be-accessed-via-api-calls)) tags, this hook won't be executed.
+
 **Request header**:
 
 ```
@@ -1251,8 +1258,8 @@ its description:
 ```
 
 It will appear in the webhook body as the below (assuming that GitLab is
-installed at gitlab.example.com, and the project is at
-example-group/example-project):
+installed at `gitlab.example.com`, and the project is at
+`example-group/example-project`):
 
 ```markdown
 ![image](https://gitlab.example.com/example-group/example-project/uploads/$sha/image.png)
diff --git a/doc/user/project/issue_board.md b/doc/user/project/issue_board.md
index 0c0068ddd09..103d50a94e8 100644
--- a/doc/user/project/issue_board.md
+++ b/doc/user/project/issue_board.md
@@ -1,6 +1,6 @@
 # Issue Boards
 
-> [Introduced][ce-5554] in [GitLab 8.11](https://about.gitlab.com/2016/08/22/gitlab-8-11-released/#issue-board).
+> [Introduced][ce-5554] in [GitLab 8.11](https://about.gitlab.com/blog/2016/08/22/gitlab-8-11-released/#issue-board).
 
 ## Overview
 
@@ -125,9 +125,9 @@ Cards finished by the UX team will automatically appear in the **Frontend** colu
 
 NOTE: **Note:**
 For a broader use case, please see the blog post
-[GitLab Workflow, an Overview](https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#gitlab-workflow-use-case-scenario).
+[GitLab Workflow, an Overview](https://about.gitlab.com/blog/2016/10/25/gitlab-workflow-an-overview/#gitlab-workflow-use-case-scenario).
 For a real use case example, you can read why
-[Codepen decided to adopt Issue Boards](https://about.gitlab.com/2017/01/27/codepen-welcome-to-gitlab/#project-management-everything-in-one-place)
+[Codepen decided to adopt Issue Boards](https://about.gitlab.com/blog/2017/01/27/codepen-welcome-to-gitlab/#project-management-everything-in-one-place)
 to improve their workflow with multiple boards.
 
 #### Quick assignments
@@ -180,9 +180,21 @@ These are shortcuts to your last 4 visited boards.
 When you're revisiting an issue board in a project or group with multiple boards,
 GitLab will automatically load the last board you visited.
 
+### Multi-select Issue Cards
+
+As the name suggest, multi-select issue cards allows more than one issue card
+to be dragged and dropped across different lists. This becomes helpful while
+moving and grooming a lot of issues at once.
+
+You can multi-select an issue card by pressing `CTRL` + `Left mouse click` on
+Windows or `CMD` + `Left mouse click` on MacOS. Once done, start by dragging one
+of the issue card you have selected and drop it in the new list you want.
+
+![Multi-select Issue Cards](img/issue_boards_multi_select.png)
+
 ### Configurable Issue Boards **(STARTER)**
 
-> Introduced in [GitLab Starter Edition 10.2](https://about.gitlab.com/2017/11/22/gitlab-10-2-released/#issue-boards-configuration).
+> Introduced in [GitLab Starter Edition 10.2](https://about.gitlab.com/blog/2017/11/22/gitlab-10-2-released/#issue-boards-configuration).
 
 An Issue Board can be associated with a GitLab [Milestone](milestones/index.md#milestones),
 [Labels](labels.md), Assignee and Weight
@@ -202,7 +214,7 @@ If you don't have editing permission in a board, you're still able to see the co
 
 ### Focus mode **(STARTER)**
 
-> Introduced in [GitLab Starter 9.1](https://about.gitlab.com/2017/04/22/gitlab-9-1-released/#issue-boards-focus-mode-ees-eep).
+> Introduced in [GitLab Starter 9.1](https://about.gitlab.com/blog/2017/04/22/gitlab-9-1-released/#issue-boards-focus-mode-ees-eep).
 
 Click the button at the top right to toggle focus mode on and off. In focus mode, the navigation UI is hidden, allowing you to focus on issues in the board.
 
@@ -218,7 +230,7 @@ especially in combination with [assignee lists](#assignee-lists-premium).
 
 ### Group Issue Boards **(PREMIUM)**
 
-> Introduced in [GitLab Premium 10.0](https://about.gitlab.com/2017/09/22/gitlab-10-0-released/#group-issue-boards).
+> Introduced in [GitLab Premium 10.0](https://about.gitlab.com/blog/2017/09/22/gitlab-10-0-released/#group-issue-boards).
 
 Accessible at the group navigation level, a group issue board offers the same features as a project-level board,
 but it can display issues from all projects in that
@@ -227,7 +239,7 @@ boards. When updating milestones and labels for an issue through the sidebar upd
 group-level objects are available.
 
 NOTE: **Note:**
-Multiple group issue boards were originally introduced in [GitLab 10.0 Premium](https://about.gitlab.com/2017/09/22/gitlab-10-0-released/#group-issue-boards) and
+Multiple group issue boards were originally introduced in [GitLab 10.0 Premium](https://about.gitlab.com/blog/2017/09/22/gitlab-10-0-released/#group-issue-boards) and
 one group issue board per group was made available in GitLab 10.6 Core.
 
 ![Group issue board](img/group_issue_board.png)
diff --git a/doc/user/project/issues/crosslinking_issues.md b/doc/user/project/issues/crosslinking_issues.md
index ec9eb7b62bb..ba442ed0a38 100644
--- a/doc/user/project/issues/crosslinking_issues.md
+++ b/doc/user/project/issues/crosslinking_issues.md
@@ -26,7 +26,7 @@ git commit -m "this is my commit message. Related to https://gitlab.com/<usernam
 Of course, you can replace `gitlab.com` with the URL of your own GitLab instance.
 
 NOTE: **Note:** Linking your first commit to your issue is going to be relevant
-for tracking your process with [GitLab Cycle Analytics](https://about.gitlab.com/features/cycle-analytics/).
+for tracking your process with [GitLab Cycle Analytics](https://about.gitlab.com/product/cycle-analytics/).
 It will measure the time taken for planning the implementation of that issue,
 which is the time between creating an issue and making the first commit.
 
diff --git a/doc/user/project/issues/csv_export.md b/doc/user/project/issues/csv_export.md
index 6ad96f41572..fb7fdde7b94 100644
--- a/doc/user/project/issues/csv_export.md
+++ b/doc/user/project/issues/csv_export.md
@@ -1,6 +1,6 @@
 # Export Issues to CSV **(STARTER)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/1126) in [GitLab Starter 9.0](https://about.gitlab.com/2017/03/22/gitlab-9-0-released/#export-issues-ees-eep).
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/1126) in [GitLab Starter 9.0](https://about.gitlab.com/blog/2017/03/22/gitlab-9-0-released/#export-issues-ees-eep).
 
 Issues can be exported as CSV from GitLab and are sent to your default notification email as an attachment.
 
@@ -28,7 +28,7 @@ Among numerous use cases for exporting issues for CSV, we can name a few:
 
 ## Choosing which issues to include
 
-From the issues page you can narrow down which issues to export using the search bar, along with the All/Open/Closed tabs. All issues returned will be exported, including those not shown on the first page.
+After selecting a project, from the issues page you can narrow down which issues to export using the search bar, along with the All/Open/Closed tabs. All issues returned will be exported, including those not shown on the first page.
 
 ![CSV export button](img/csv_export_button.png)
 
@@ -72,4 +72,5 @@ Data will be encoded with a comma as the column delimiter, with `"` used to quot
 
 ## Limitations
 
-As the issues will be sent as an email attachment, there is a limit on how much data can be exported. Currently this limit is 15MB to ensure successful delivery across a range of email providers. If this limit is reached we suggest narrowing the search before export, perhaps by exporting open and closed issues separately.
+- Export Issues to CSV is not available at the Group's Issues List.
+- As the issues will be sent as an email attachment, there is a limit on how much data can be exported. Currently this limit is 15MB to ensure successful delivery across a range of email providers. If this limit is reached we suggest narrowing the search before export, perhaps by exporting open and closed issues separately.
diff --git a/doc/user/project/issues/design_management.md b/doc/user/project/issues/design_management.md
index 9850b401b6f..169da7049a6 100644
--- a/doc/user/project/issues/design_management.md
+++ b/doc/user/project/issues/design_management.md
@@ -38,7 +38,6 @@ to be enabled:
 - Files uploaded must have a file extension of either `png`, `jpg`, `jpeg`, `gif`, `bmp`, `tiff` or `ico`.
   The [`svg` extension is not yet supported](https://gitlab.com/gitlab-org/gitlab/issues/12771).
 - Design uploads are limited to 10 files at a time.
-- [Designs cannot yet be deleted](https://gitlab.com/gitlab-org/gitlab/issues/11089).
 - Design Management is
   [not yet supported in the project export](https://gitlab.com/gitlab-org/gitlab/issues/11090).
 - Design Management data
@@ -48,6 +47,8 @@ to be enabled:
   when an issue is deleted.
 - Design Management
   [isn't supported by Geo](https://gitlab.com/groups/gitlab-org/-/epics/1633) yet.
+- Only the latest version of the designs can be deleted.
+- Deleted designs cannot be recovered but you can see them on previous designs versions.
 
 ## The Design Management page
 
@@ -62,15 +63,18 @@ To upload design images, click the **Upload Designs** button and select images t
 Designs with the same filename as an existing uploaded design will create a new version
 of the design, and will replace the previous version.
 
+Designs cannot be added if the issue has been moved, or its
+[discussion is locked](../../discussions/#lock-discussions).
+
 ## Viewing designs
 
-Images on the Design Management page can be enlarged by clicking on them.  
+Images on the Design Management page can be enlarged by clicking on them.
 
 The number of comments on a design — if any — is listed to the right
 of the design filename. Clicking on this number enlarges the design
 just like clicking anywhere else on the design.
 When a design is added or modified, an icon is displayed on the item
-to help summarize changes between versions.  
+to help summarize changes between versions.
 
 | Indicator | Example |
 | --------- | ------- |
@@ -78,6 +82,34 @@ to help summarize changes between versions.
 | Modified (in the selected version) | ![Design Modified](img/design_modified_v12_3.png) |
 | Added (in the selected version) | ![Design Added](img/design_added_v12_3.png) |
 
+## Deleting designs
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/11089) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.4.
+
+There are two ways to delete designs: manually delete them
+individually, or select a few of them to delete at once,
+as shown below.
+
+To delete a single design, click it to view it enlarged,
+then click the trash icon on the top right corner and confirm
+the deletion by clicking the **Delete** button on the modal window:
+
+![Confirm design deletion](img/confirm_design_deletion_v12_4.png)
+
+To delete multiple designs at once, on the design's list view,
+first select the designs you want to delete:
+
+![Select designs](img/select_designs_v12_4.png)
+
+Once selected, click the **Delete selected** button to confirm the deletion:
+
+![Delete multiple designs](img/delete_multiple_designs_v12_4.png)
+
+NOTE: **Note:**
+Only the latest version of the designs can be deleted.
+Deleted designs are not permanently lost; they can be
+viewed by browsing previous versions.
+
 ## Adding annotations to designs
 
 When a design image is displayed, you can add annotations to it by clicking on
diff --git a/doc/user/project/issues/img/confirm_design_deletion_v12_4.png b/doc/user/project/issues/img/confirm_design_deletion_v12_4.png
new file mode 100644
index 00000000000..b1a55c639ca
--- /dev/null
+++ b/doc/user/project/issues/img/confirm_design_deletion_v12_4.png
diff --git a/doc/user/project/issues/img/delete_multiple_designs_v12_4.png b/doc/user/project/issues/img/delete_multiple_designs_v12_4.png
new file mode 100644
index 00000000000..b421a5577df
--- /dev/null
+++ b/doc/user/project/issues/img/delete_multiple_designs_v12_4.png
diff --git a/doc/user/project/issues/img/delete_single_design_v12_4.png b/doc/user/project/issues/img/delete_single_design_v12_4.png
new file mode 100644
index 00000000000..0ca03b48e76
--- /dev/null
+++ b/doc/user/project/issues/img/delete_single_design_v12_4.png
diff --git a/doc/user/project/issues/img/select_all_designs_v12_4.png b/doc/user/project/issues/img/select_all_designs_v12_4.png
new file mode 100644
index 00000000000..b08b04c1214
--- /dev/null
+++ b/doc/user/project/issues/img/select_all_designs_v12_4.png
diff --git a/doc/user/project/issues/img/select_designs_v12_4.png b/doc/user/project/issues/img/select_designs_v12_4.png
new file mode 100644
index 00000000000..a53bd516300
--- /dev/null
+++ b/doc/user/project/issues/img/select_designs_v12_4.png
diff --git a/doc/user/project/issues/index.md b/doc/user/project/issues/index.md
index eaf4922bec9..6abd6fd7047 100644
--- a/doc/user/project/issues/index.md
+++ b/doc/user/project/issues/index.md
@@ -20,7 +20,7 @@ you can also view all the issues collectively at the group level.
 - Accepting feature proposals, questions, support requests, or bug reports
 - Elaborating on new code implementations
 
-See also [Always start a discussion with an issue](https://about.gitlab.com/2016/03/03/start-with-an-issue/).
+See also [Always start a discussion with an issue](https://about.gitlab.com/blog/2016/03/03/start-with-an-issue/).
 
 ## Parts of an issue
 
diff --git a/doc/user/project/issues/issue_data_and_actions.md b/doc/user/project/issues/issue_data_and_actions.md
index 5313975908b..01f4eb5b912 100644
--- a/doc/user/project/issues/issue_data_and_actions.md
+++ b/doc/user/project/issues/issue_data_and_actions.md
@@ -141,9 +141,9 @@ for the issue. This will automatically enable if you participate in the issue in
 
 #### 14. Reference
 
-- A quick "copy to clipboard" button for that issue's reference, which looks like `foo/bar#xxx`,
-  where `foo` is the `username` or `groupname`, `bar` is the `project-name`, and
-  `xxx` is the issue number.
+- A quick "copy" button for that issue's reference, which looks like
+  `foo/bar#xxx`, where `foo` is the `username` or `groupname`, `bar` is the
+  `project-name`, and `xxx` is the issue number.
 
 #### 15. Edit
 
diff --git a/doc/user/project/issues/multiple_assignees_for_issues.md b/doc/user/project/issues/multiple_assignees_for_issues.md
index a1b16457a0d..b442f70a061 100644
--- a/doc/user/project/issues/multiple_assignees_for_issues.md
+++ b/doc/user/project/issues/multiple_assignees_for_issues.md
@@ -2,7 +2,7 @@
 
 > **Note:**
 [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1904)
-in [GitLab Starter 9.2](https://about.gitlab.com/2017/05/22/gitlab-9-2-released/#multiple-assignees-for-issues).
+in [GitLab Starter 9.2](https://about.gitlab.com/blog/2017/05/22/gitlab-9-2-released/#multiple-assignees-for-issues).
 
 ## Overview
 
diff --git a/doc/user/project/labels.md b/doc/user/project/labels.md
index 32c8c4d0453..cfd6d4eaf4b 100644
--- a/doc/user/project/labels.md
+++ b/doc/user/project/labels.md
@@ -2,9 +2,9 @@
 
 ## Overview
 
-Labels allow you to categorize issues or merge requests using descriptive titles like
+Labels allow you to categorize epics, issues, and merge requests using descriptive titles like
 `bug`, `feature request`, or `docs`. Each label also has a customizable color. They
-allow you to quickly and dynamically filter and manage issues or merge requests you
+allow you to quickly and dynamically filter and manage epics, issues and merge requests you
 care about, and are visible throughout GitLab in most places where issues and merge
 requests are located.
 
@@ -12,8 +12,8 @@ requests are located.
 
 In GitLab, you can create project and group labels:
 
-- **Project labels** can be assigned to issues or merge requests in that project only.
-- **Group labels** can be assigned to any issue or merge request in any project in
+- **Project labels** can be assigned to epics, issues and merge requests in that project only.
+- **Group labels** can be assigned to any epics, issue and merge request in any project in
   that group, or any subgroups of the group.
 
 ## Scoped labels **(PREMIUM)**
@@ -21,7 +21,7 @@ In GitLab, you can create project and group labels:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9175) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10.
 
 Scoped labels allow teams to use the simple and familiar label feature to
-annotate their issues, merge requests, and epics to achieve custom fields and
+annotate their epics, issues, merge requests, and epics to achieve custom fields and
 custom workflow states by leveraging a special label title syntax.
 
 A scoped label is a kind of label defined by a special double-colon syntax
@@ -141,11 +141,8 @@ action cannot be reversed and the changes are permanent.
 
 ## Assigning labels from the sidebar
 
-Every issue and merge request can be assigned any number of labels. The labels are
-visible on every issue and merge request page, in the sidebar. They are also visible on:
-
-- Every issue and merge request page in the sidebar.
-- The issue board.
+Every epic, issue, and merge request can be assigned any number of labels. The labels are
+visible on every epic, issue and merge request page, in the sidebar and on your issue boards.
 
 From the sidebar, you can assign or unassign a label to the object (i.e. label or
 unlabel it). You can also perform this as a [quick action](quick_actions.md),
@@ -166,11 +163,11 @@ GitLab will check both the label titles and descriptions for the search.
 
 ## Filtering by label
 
-The following can be filtered labels:
+The following can be filtered by labels:
 
+- Epic lists **(ULTIMATE)**
 - Issue lists
 - Merge Request lists
-- Epic lists **(ULTIMATE)**
 - Issue Boards
 
 ### Filtering in list pages
@@ -180,7 +177,7 @@ The following can be filtered labels:
   - Group labels (including subgroup ancestors)
   - Project labels
 
-- From the group issue list page and the group merge request list page, you can
+- From the group epic lists page, issue list page and the group merge request list page, you can
   [filter](../search/index.md#issues-and-merge-requests) by:
   - Group labels (including subgroup ancestors and subgroup descendants)
   - Project labels
@@ -214,7 +211,7 @@ The following can be filtered labels:
 
 From the project label list page and the group label list page, you can subscribe
 to [notifications](../../workflow/notifications.md) of a given label, to alert you
-that the label has been assigned to an issue or merge request.
+that the label has been assigned to an epic, issue, and merge request.
 
 ![Labels subscriptions](img/labels_subscriptions_v12_1.png)
 
@@ -226,7 +223,7 @@ that the label has been assigned to an issue or merge request.
 > - Priority sorting is based on the highest priority label only. [This discussion](https://gitlab.com/gitlab-org/gitlab-foss/issues/18554) considers changing this.
 
 Labels can have relative priorities, which are used in the "Label priority" and
-"Priority" sort orders of the issue and merge request list pages.
+"Priority" sort orders of the epic, issue, and merge request list pages.
 
 From the project label list page, star a label to indicate that it has a priority.
 
@@ -242,8 +239,8 @@ on the project label list page.
 
 ![Drag to change label priority](img/labels_drag_priority_v12_1.gif)
 
-On the merge request and issue pages, for both groups and projects, you can sort by `Label priority`
-and `Priority`, which account for objects (issues and merge requests) that have prioritized
+On the epic, merge request and issue pages, for both groups and projects, you can sort by `Label priority`
+and `Priority`, which account for objects (epic, issues, and merge requests) that have prioritized
 labels assigned to them.
 
 If you sort by `Label priority`, GitLab considers this sort comparison order:
diff --git a/doc/user/project/merge_requests/allow_collaboration.md b/doc/user/project/merge_requests/allow_collaboration.md
index 3a389eb1e3a..083a117600b 100644
--- a/doc/user/project/merge_requests/allow_collaboration.md
+++ b/doc/user/project/merge_requests/allow_collaboration.md
@@ -52,7 +52,7 @@ Here's how the process would look like:
 
    ![Check out branch button](img/checkout_button.png)
 
-1. Use the copy to clipboard button to copy the first command and paste them
+1. Use the copy button to copy the first command and paste them
    in your terminal:
 
    ```sh
diff --git a/doc/user/project/merge_requests/browser_performance_testing.md b/doc/user/project/merge_requests/browser_performance_testing.md
index de8a47f3d73..3cfc30a68e9 100644
--- a/doc/user/project/merge_requests/browser_performance_testing.md
+++ b/doc/user/project/merge_requests/browser_performance_testing.md
@@ -44,7 +44,7 @@ For instance, consider the following workflow:
 First of all, you need to define a job in your `.gitlab-ci.yml` file that generates the
 [Performance report artifact](../../../ci/yaml/README.md#artifactsreportsperformance-premium).
 For more information on how the Performance job should look like, check the
-example on [Testing Browser Performance](../../../ci/examples/browser_performance.md).
+example on [Configuring Browser Performance Testing](#configuring-browser-performance-testing).
 
 GitLab then checks this report, compares key performance metrics for each page
 between the source and target branches, and shows the information right on the merge request.
@@ -60,11 +60,6 @@ report will be shown properly.
 
 ## Configuring Browser Performance Testing
 
-NOTE: **Note:**
-The job definition shown below is supported in GitLab 11.5 and later versions.
-It also requires GitLab Runner 11.5 or later. For earlier versions, use the
-[previous job definitions](#previous-job-definitions).
-
 This example shows how to run the [sitespeed.io container](https://hub.docker.com/r/sitespeedio/sitespeed.io/)
 on your code by using GitLab CI/CD and [sitespeed.io](https://www.sitespeed.io)
 using Docker-in-Docker.
@@ -73,29 +68,35 @@ First, you need GitLab Runner with
 [docker-in-docker build](../../../ci/docker/using_docker_build.md#use-docker-in-docker-workflow-with-docker-executor).
 
 Once you set up the Runner, add a new job to `.gitlab-ci.yml` that generates the
-expected report:
+expected report.
+
+For GitLab 12.4 and later, to define the `performance` job, you must
+[include](../../../ci/yaml/README.md#includetemplate) the
+[`Browser-Performance.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Verify/Browser-Performance.gitlab-ci.yml)
+that's provided as a part of your GitLab installation.
+For GitLab versions earlier than 12.4, you can copy and use the job as defined
+in that template.
+
+CAUTION: **Caution:**
+The job definition provided by the template does not support Kubernetes yet. For a complete example of a more complex setup
+that works in Kubernetes, see [here](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Browser-Performance-Testing.gitlab-ci.yml).
+
+Add the following to your `.gitlab-ci.yml` file:
 
 ```yaml
+include:
+  template: Verify/Browser-Performance.gitlab-ci.yml
+
 performance:
-  stage: performance
-  image: docker:git
   variables:
     URL: https://example.com
-  services:
-    - docker:stable-dind
-  script:
-    - mkdir gitlab-exporter
-    - wget -O ./gitlab-exporter/index.js https://gitlab.com/gitlab-org/gl-performance/raw/master/index.js
-    - mkdir sitespeed-results
-    - docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:6.3.1 --plugins.add ./gitlab-exporter --outputFolder sitespeed-results $URL
-    - mv sitespeed-results/data/performance.json performance.json
-  artifacts:
-    paths:
-      - sitespeed-results/
-    reports:
-      performance: performance.json
 ```
 
+CAUTION: **Caution:**
+The job definition provided by the template is supported in GitLab 11.5 and later versions.
+It also requires GitLab Runner 11.5 or later. For earlier versions, use the
+[previous job definitions](#previous-job-definitions).
+
 The above example will create a `performance` job in your CI/CD pipeline and will run
 sitespeed.io against the webpage you defined in `URL` to gather key metrics.
 The [GitLab plugin for sitespeed.io](https://gitlab.com/gitlab-org/gl-performance)
@@ -106,6 +107,20 @@ take the latest Performance artifact available.
 The full HTML sitespeed.io report will also be saved as an artifact, and if you have
 [GitLab Pages](../pages/index.md) enabled, it can be viewed directly in your browser.
 
+It is also possible to customize options by setting the `SITESPEED_OPTIONS` variable.
+For example, this is how to override the number of runs sitespeed.io
+will make on the given URL:
+
+```yaml
+include:
+  template: Verify/Browser-Performance.gitlab-ci.yml
+
+performance:
+  variables:
+    URL: https://example.com
+    SITESPEED_OPTIONS: -n 5
+```
+
 For further customization options for sitespeed.io, including the ability to provide a
 list of URLs to test, please see the [Sitespeed.io Configuration](https://www.sitespeed.io/documentation/sitespeed.io/configuration/)
 documentation.
@@ -126,8 +141,9 @@ set this up:
    as an artifact is as simple as `echo $CI_ENVIRONMENT_URL > environment_url.txt`
    in your job's `script`.
 1. In the `performance` job, read the previous artifact into an environment
-   variable, like `$CI_ENVIRONMENT_URL`, and use it to parameterize the test
-   URLs.
+   variable, in this case `$URL` because this is what our sitespeed.io command
+   uses for the URL parameter. Because Review App URLs are dynamic, we define
+   the `URL` variable through `before_script` instead of `variables`.
 1. You can now run the sitespeed.io container against the desired hostname and
    paths.
 
@@ -138,6 +154,9 @@ stages:
   - deploy
   - performance
 
+include:
+  template: Verify/Browser-Performance.gitlab-ci.yml
+
 review:
   stage: deploy
   environment:
@@ -155,28 +174,12 @@ review:
     - master
 
 performance:
-  stage: performance
-  image: docker:git
-  services:
-    - docker:stable-dind
   dependencies:
     - review
-  script:
-    - export CI_ENVIRONMENT_URL=$(cat environment_url.txt)
-    - mkdir gitlab-exporter
-    - wget -O ./gitlab-exporter/index.js https://gitlab.com/gitlab-org/gl-performance/raw/master/index.js
-    - mkdir sitespeed-results
-    - docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:6.3.1 --plugins.add ./gitlab-exporter --outputFolder sitespeed-results "$CI_ENVIRONMENT_URL"
-    - mv sitespeed-results/data/performance.json performance.json
-  artifacts:
-    paths:
-      - sitespeed-results/
-    reports:
-      performance: performance.json
+  before_script:
+    - export URL=$(cat environment_url.txt)
 ```
 
-A complete example can be found in our [Auto DevOps CI YML](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml).
-
 ### Previous job definitions
 
 CAUTION: **Caution:**
diff --git a/doc/user/project/merge_requests/code_quality.md b/doc/user/project/merge_requests/code_quality.md
index 3c667755787..92681e741de 100644
--- a/doc/user/project/merge_requests/code_quality.md
+++ b/doc/user/project/merge_requests/code_quality.md
@@ -66,6 +66,13 @@ will scan your source code for code quality issues. The report will be saved as
 that you can later download and analyze. Due to implementation limitations we always
 take the latest Code Quality artifact available.
 
+The included `code_quality` job is running in the `test` stage, so it needs to be included in your CI config, like so:
+
+```yaml
+stages:
+  - test
+```
+
 TIP: **Tip:**
 This information will be automatically extracted and shown right in the merge request widget.
 
diff --git a/doc/user/project/merge_requests/img/cross_project_dependencies_edit_inaccessible_v12_2.png b/doc/user/project/merge_requests/img/cross_project_dependencies_edit_inaccessible_v12_2.png
deleted file mode 100644
index 2dc02634fd8..00000000000
--- a/doc/user/project/merge_requests/img/cross_project_dependencies_edit_inaccessible_v12_2.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/cross_project_dependencies_edit_v12_2.png b/doc/user/project/merge_requests/img/cross_project_dependencies_edit_v12_2.png
deleted file mode 100644
index 362e7e0ead2..00000000000
--- a/doc/user/project/merge_requests/img/cross_project_dependencies_edit_v12_2.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/dependencies_edit_inaccessible_v12_4.png b/doc/user/project/merge_requests/img/dependencies_edit_inaccessible_v12_4.png
new file mode 100644
index 00000000000..3699ffd16b4
--- /dev/null
+++ b/doc/user/project/merge_requests/img/dependencies_edit_inaccessible_v12_4.png
diff --git a/doc/user/project/merge_requests/img/dependencies_edit_v12_4.png b/doc/user/project/merge_requests/img/dependencies_edit_v12_4.png
new file mode 100644
index 00000000000..beb452e80cf
--- /dev/null
+++ b/doc/user/project/merge_requests/img/dependencies_edit_v12_4.png
diff --git a/doc/user/project/merge_requests/img/cross_project_dependencies_view_v12_2.png b/doc/user/project/merge_requests/img/dependencies_view_v12_2.png
index e00231c839b..e00231c839b 100644
--- a/doc/user/project/merge_requests/img/cross_project_dependencies_view_v12_2.png
+++ b/doc/user/project/merge_requests/img/dependencies_view_v12_2.png
diff --git a/doc/user/project/merge_requests/img/mr_approvals_by_code_owners_v12_4.png b/doc/user/project/merge_requests/img/mr_approvals_by_code_owners_v12_4.png
new file mode 100755
index 00000000000..c704129685f
--- /dev/null
+++ b/doc/user/project/merge_requests/img/mr_approvals_by_code_owners_v12_4.png
diff --git a/doc/user/project/merge_requests/index.md b/doc/user/project/merge_requests/index.md
index 3f563d58287..2ab7c3fb15b 100644
--- a/doc/user/project/merge_requests/index.md
+++ b/doc/user/project/merge_requests/index.md
@@ -47,7 +47,7 @@ With **[GitLab Enterprise Edition][ee]**, you can also:
 - Analyze your dependencies for vulnerabilities with [Dependency Scanning](../../application_security/dependency_scanning/index.md) **(ULTIMATE)**
 - Analyze your Docker images for vulnerabilities with [Container Scanning](../../application_security/container_scanning/index.md) **(ULTIMATE)**
 - Determine the performance impact of changes with [Browser Performance Testing](#browser-performance-testing-premium) **(PREMIUM)**
-- Specify merge order dependencies with [Cross-project Merge Request Dependencies](#cross-project-merge-request-dependencies-premium) **(PREMIUM)**
+- Specify merge order dependencies with [Merge Request Dependencies](#merge-request-dependencies-premium) **(PREMIUM)**
 
 ## Use cases
 
@@ -70,7 +70,7 @@ B. Consider you're a web developer writing a webpage for your company's website:
 1. Your changes are previewed with [Review Apps](../../../ci/review_apps/index.md)
 1. You request your web designers for their implementation
 1. You request the [approval](merge_request_approvals.md) from your manager **(STARTER)**
-1. Once approved, your merge request is [squashed and merged](squash_and_merge.md), and [deployed to staging with GitLab Pages](https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/)
+1. Once approved, your merge request is [squashed and merged](squash_and_merge.md), and [deployed to staging with GitLab Pages](https://about.gitlab.com/blog/2016/08/26/ci-deployment-and-environments/)
 1. Your production team [cherry picks](#cherry-pick-changes) the merge commit into production
 
 ## Merge requests per project
@@ -221,7 +221,7 @@ to learn more.
 ## Multiple assignees **(STARTER)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/2004)
-in [GitLab Starter 11.11](https://about.gitlab.com/pricing).
+in [GitLab Starter 11.11](https://about.gitlab.com/pricing/).
 
 Multiple people often review merge requests at the same time. GitLab allows you to have multiple assignees for merge requests to indicate everyone that is reviewing or accountable for it.
 
@@ -290,140 +290,10 @@ apply the patches. The target branch can be specified using the
 [`/target_branch` quick action](../quick_actions.md). If the source
 branch already exists, the patches will be applied on top of it.
 
-## Git push options
+## Use Git push options with merge requests
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/26752) in GitLab 11.10.
-
-NOTE: **Note:**
-Git push options are only available with Git 2.10 or newer. With Git older than 2.18
-`git push --push-option=...` should be used instead of `git push -o ...`.
-
-GitLab supports using
-[Git push options](https://git-scm.com/docs/git-push#Documentation/git-push.txt--oltoptiongt)
-to perform the following actions against merge requests at the same time
-as pushing changes:
-
-- Create a new merge request for the pushed branch.
-- Set the target of the merge request to a particular branch.
-- Set the merge request to merge when its pipeline succeeds.
-- Set the merge request to remove the source branch when it's merged.
-- Set the title of the merge request to a particular title.
-- Set the description of the merge request to a particular description.
-- Add or remove labels from the merge request.
-
-### Create a new merge request using git push options
-
-To create a new merge request for a branch, use the
-`merge_request.create` push option:
-
-```sh
-git push -o merge_request.create
-```
-
-### Set the target branch of a merge request using git push options
-
-To update an existing merge request's target branch, use the
-`merge_request.target=<branch_name>` push option:
-
-```sh
-git push -o merge_request.target=branch_name
-```
-
-You can also create a merge request and set its target branch at the
-same time using a `-o` flag per push option:
-
-```sh
-git push -o merge_request.create -o merge_request.target=branch_name
-```
-
-### Set merge when pipeline succeeds using git push options
-
-To set an existing merge request to
-[merge when its pipeline succeeds](merge_when_pipeline_succeeds.md), use
-the `merge_request.merge_when_pipeline_succeeds` push option:
-
-```sh
-git push -o merge_request.merge_when_pipeline_succeeds
-```
-
-You can also create a merge request and set it to merge when its
-pipeline succeeds at the same time using a `-o` flag per push option:
-
-```sh
-git push -o merge_request.create -o merge_request.merge_when_pipeline_succeeds
-```
-
-### Set removing the source branch using git push options
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320) in GitLab 12.2.
-
-To set an existing merge request to remove the source branch when the
-merge request is merged, the
-`merge_request.remove_source_branch` push option can be used:
-
-```sh
-git push -o merge_request.remove_source_branch
-```
-
-You can also use this push option in addition to the
-`merge_request.create` push option.
-
-### Set merge request title using git push options
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320) in GitLab 12.2.
-
-To set the title of an existing merge request, use
-the `merge_request.title` push option:
-
-```sh
-git push -o merge_request.title="The title I want"
-```
-
-You can also use this push option in addition to the
-`merge_request.create` push option.
-
-### Set merge request description using git push options
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320) in GitLab 12.2.
-
-To set the description of an existing merge request, use
-the `merge_request.description` push option:
-
-```sh
-git push -o merge_request.description="The description I want"
-```
-
-You can also use this push option in addition to the
-`merge_request.create` push option.
-
-### Add or remove labels using git push options
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/31831) in GitLab 12.3.
-
-You can add or remove labels from merge requests using push options.
-
-For example, to add two labels to an existing merge request, use the
-`merge_request.label` push option:
-
-```sh
-git push -o merge_request.label="label1" -o merge_request.label="label2"
-```
-
-To remove two labels from an existing merge request, use
-the `merge_request.unlabel` push option:
-
-```sh
-git push -o merge_request.unlabel="label1" -o merge_request.unlabel="label2"
-```
-
-You can also use these push options in addition to the
-`merge_request.create` push option.
-
-To create a merge request and add two labels to it, use:
-
-```sh
-git push -o merge_request.create -o merge_request.label="label1" -o merge_request.label="label2"
-```
+Use [Git push options](../push_options.md) to create or update merge requests when
+pushing changes to GitLab with Git, without needing to use the GitLab interface.
 
 ## Find the merge request that introduced a change
 
@@ -465,11 +335,11 @@ have been marked as a **Work In Progress**.
 ## Merge Requests for Confidential Issues
 
 Create [merge requests to resolve confidential issues](../issues/confidential_issues.md#merge-requests-for-confidential-issues)
-for preventing leakage or early release of sentive data through regular merge requests.
+for preventing leakage or early release of sensitive data through regular merge requests.
 
 ## Merge request approvals **(STARTER)**
 
-> Included in [GitLab Starter][products].
+> Included in [GitLab Starter](https://about.gitlab.com/product/).
 
 If you want to make sure every merge request is approved by one or more people,
 you can enforce this workflow by using merge request approvals. Merge request
@@ -480,7 +350,7 @@ list of approvers that will need to approve every merge request in a project.
 
 ## Code Quality **(STARTER)**
 
-> Introduced in [GitLab Starter][products] 9.3.
+> Introduced in [GitLab Starter](https://about.gitlab.com/product/) 9.3.
 
 If you are using [GitLab CI][ci], you can analyze your source code quality using
 the [Code Climate][cc] analyzer [Docker image][cd]. Going a step further, GitLab
@@ -490,7 +360,7 @@ can show the Code Climate report right in the merge request widget area.
 
 ## Metrics Reports **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9788) in [GitLab Premium][products] 11.10.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9788) in [GitLab Premium](https://about.gitlab.com/product/) 11.10.
 Requires GitLab Runner 11.10 and above.
 
 If you are using [GitLab CI][ci], you can configure your job to output custom
@@ -501,7 +371,7 @@ that it's fast and easy to identify changes to important metrics.
 
 ## Browser Performance Testing **(PREMIUM)**
 
-> Introduced in [GitLab Premium][products] 10.3.
+> Introduced in [GitLab Premium](https://about.gitlab.com/product/) 10.3.
 
 If your application offers a web interface and you are using [GitLab CI/CD][ci], you can quickly determine the performance impact of pending code changes. GitLab uses [Sitespeed.io][sitespeed], a free and open source tool for measuring the performance of web sites, to analyze the performance of specific pages.
 
@@ -509,9 +379,9 @@ GitLab runs the [Sitespeed.io container][sitespeed-container] and displays the d
 
 [Read more about Browser Performance Testing.](browser_performance_testing.md)
 
-## Cross-project Merge Request Dependencies **(PREMIUM)**
+## Merge Request Dependencies **(PREMIUM)**
 
-> Introduced in [GitLab Premium][products] 12.2.
+> Introduced in [GitLab Premium](https://about.gitlab.com/product/) 12.2.
 
 A single logical change may be split across several merge requests, across
 several projects. When this happens, the order in which MRs are merged is
@@ -522,7 +392,7 @@ this relationship in place, the merge request cannot be merged until all of its
 dependencies have also been merged, helping to maintain the consistency of a
 single logical change.
 
-[Read more about cross-project merge request dependencies.](merge_request_dependencies.md)
+[Read more about merge request dependencies.](merge_request_dependencies.md)
 
 ## Security reports **(ULTIMATE)**
 
@@ -570,7 +440,7 @@ whitespace changes.
 
 ## Live preview with Review Apps
 
-If you configured [Review Apps](https://about.gitlab.com/features/review-apps/) for your project,
+If you configured [Review Apps](https://about.gitlab.com/product/review-apps/) for your project,
 you can preview the changes submitted to a feature-branch through a merge request
 in a per-branch basis. No need to checkout the branch, install and preview locally;
 all your changes will be available to preview by anyone with the Review Apps link.
@@ -666,7 +536,7 @@ tricks to checkout a merge request locally.
 Please note that you can checkout a merge request locally even if the source
 project is a fork (even a private fork) of the target project.
 
-#### Checkout locally by adding a git alias
+#### Checkout locally by adding a Git alias
 
 Add the following alias to your `~/.gitconfig`:
 
@@ -736,10 +606,8 @@ And to check out a particular merge request:
 git checkout origin/merge-requests/1
 ```
 
-all the above can be done with [git-mr] script.
+All the above can be done with the [`git-mr`](https://gitlab.com/glensc/git-mr) script.
 
-[git-mr]: https://gitlab.com/glensc/git-mr
-[products]: https://about.gitlab.com/products/ "GitLab products page"
 [protected branches]: ../protected_branches.md
 [ci]: ../../../ci/README.md
 [cc]: https://codeclimate.com/
diff --git a/doc/user/project/merge_requests/merge_request_approvals.md b/doc/user/project/merge_requests/merge_request_approvals.md
index 6f8d821e1c6..2aa92ba2316 100644
--- a/doc/user/project/merge_requests/merge_request_approvals.md
+++ b/doc/user/project/merge_requests/merge_request_approvals.md
@@ -4,7 +4,7 @@ type: reference, concepts
 
 # Merge request approvals **(STARTER)**
 
-> Introduced in [GitLab Enterprise Edition 7.12](https://about.gitlab.com/2015/06/22/gitlab-7-12-released/#merge-request-approvers-ee-only).
+> Introduced in [GitLab Enterprise Edition 7.12](https://about.gitlab.com/blog/2015/06/22/gitlab-7-12-released/#merge-request-approvers-ee-only).
 
 Merge request approvals enable enforced code review by requiring specified people
 to approve a merge request before it can be unblocked for merging.
@@ -66,13 +66,7 @@ suitable to your workflow:
 
 ## Editing approvals **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.8.
-
-CAUTION: **Caution:**
-There was a [regression affecting this feature in 11.8](https://gitlab.com/gitlab-org/gitlab/merge_requests/9648). We recommend upgrading _at least_ to version 11.8.2. to avoid any issues.
-
-NOTE: **Note:**
-In 11.8 this feature does not work in [private groups](https://gitlab.com/gitlab-org/gitlab/issues/10356).
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10.
 
 For GitLab Premium, [multiple approver rules](#multiple-approval-rules-premium) can be configured. To configure the merge
 request approval rules:
@@ -87,7 +81,7 @@ request approval rules:
 
 ## Multiple approval rules **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.8.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10.
 
 For GitLab Premium, a merge request's overall approval status is determined by a set of rules. Each rule contains:
 
@@ -107,7 +101,7 @@ any [eligible approver](#eligible-approvers) may approve.
 The following can approve merge requests:
 
 - Users being added as approvers at project or merge request level.
-- [Code owners](../code_owners.md) related to the merge request ([introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/7933) in [GitLab Starter](https://about.gitlab.com/pricing/) 11.5).
+- [Code owners](#code-owners-as-eligible-approvers-starter) to the files changed by the merge request.
 
 An individual user can be added as an approver for a project if they are a member of:
 
@@ -125,6 +119,31 @@ if [**Prevent author approval**](#allowing-merge-request-authors-to-approve-thei
 and [**Prevent committers approval**](#prevent-approval-of-merge-requests-by-their-committers) (disabled by default)
 are enabled on the project settings.
 
+### Code Owners as eligible approvers **(STARTER)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/7933) in [GitLab Starter](https://about.gitlab.com/pricing/) 11.5.
+
+Once you've added [Code Owners](../code_owners.md) to your
+repository, the owners to the corresponding files will become
+eligible approvers, together with members with Developer or
+higher permissions.
+
+To enable this merge request approval rule:
+
+1. Navigate to your project's **Settings > General** and expand
+**Merge request approvals**.
+1. Locate **All members with Developer role or higher and code owners (if any)** and click **Edit** to choose the number of approvals required.
+
+![MR approvals by Code Owners](img/mr_approvals_by_code_owners_v12_4.png)
+
+Once set, merge requests can only be merged once approved by the
+number of approvals you've set. GitLab will accept approvals from
+users with Developer or higher permissions, as well as by Code Owners,
+indistinguishably.
+
+Alternatively, you can **require**
+[Code Owner's approvals for Protected Branches](../protected_branches.md#protected-branches-approval-by-code-owners-premium). **(PREMIUM)**
+
 ### Implicit approvers
 
 If the number of required approvals is greater than the number of approvers,
@@ -168,26 +187,6 @@ are other conditions that may block it, such as merge conflicts,
 [pending discussions](../../discussions/index.md#only-allow-merge-requests-to-be-merged-if-all-threads-are-resolved)
 or a [failed CI/CD pipeline](merge_when_pipeline_succeeds.md).
 
-## Code Owners approvals **(PREMIUM)**
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/4418) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.9.
-
-It is possible to require at least one approval for each entry in the
-[`CODEOWNERS` file](../code_owners.md) that matches a file changed in
-the merge request. To enable this feature:
-
-1. Navigate to your project's **Settings > General** and expand
-   **Merge request approvals**.
-1. Tick the **Require approval from code owners** checkbox.
-1. Click **Save changes**.
-
-When this feature is enabled, all merge requests will need approval
-from one code owner per matched rule before it can be merged.
-
-NOTE: **Note:** Only the `CODEOWNERS` file on the default branch is evaluated for
-Merge Request approvals. If `CODEOWNERS` is changed on a non-default branch, those
-changes will not affect approvals until merged to the default branch.
-
 ## Overriding the merge request approvals default settings
 
 > Introduced in GitLab Enterprise Edition 9.4.
@@ -329,7 +328,7 @@ the dropdown) `approver` and select the user.
 
 ## Security approvals in merge requests **(ULTIMATE)**
 
-> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing) 12.2.
+> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.2.
 
 Merge Request Approvals can be configured to require approval from a member
 of your security team when a vulnerability would be introduced by a merge request.
@@ -337,6 +336,16 @@ of your security team when a vulnerability would be introduced by a merge reques
 For more information, see
 [Security approvals in merge requests](../../application_security/index.md#security-approvals-in-merge-requests-ultimate).
 
+## License compliance approvals in merge requests **(ULTIMATE)**
+
+> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.3.
+
+Merge Request Approvals can be configured to require approval from a member
+of your security team when a blacklisted software license would be introduced by a merge request.
+
+For more information, see
+[Security approvals in merge requests](../../application_security/index.md#security-approvals-in-merge-requests-ultimate).
+
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues
diff --git a/doc/user/project/merge_requests/merge_request_dependencies.md b/doc/user/project/merge_requests/merge_request_dependencies.md
index c982bd7f78d..c99e6663093 100644
--- a/doc/user/project/merge_requests/merge_request_dependencies.md
+++ b/doc/user/project/merge_requests/merge_request_dependencies.md
@@ -2,14 +2,17 @@
 type: reference, concepts
 ---
 
-# Cross-project Merge Request dependencies **(PREMIUM)**
+# Merge Request dependencies **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9688) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.2.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9688) in
+[GitLab Premium](https://about.gitlab.com/pricing/) 12.2.
+> - [Renamed](https://gitlab.com/gitlab-org/gitlab/merge_requests/17291) from
+"Cross-project dependencies" to "Merge Requests dependencies" in
+[GitLab Premium](https://about.gitlab.com/pricing/) 12.4.
 
-Cross-project merge request dependencies allows a required order of merging
-between merge requests in different projects to be expressed. If a
-merge request "depends on" another, then it cannot be merged until its
-dependency is itself merged.
+Merge request dependencies allows a required order of merging
+between merge requests to be expressed. If a merge request "depends on" another,
+then it cannot be merged until its dependency is itself merged.
 
 NOTE: **Note:**
 Merge requests dependencies are a **PREMIUM** feature, but this restriction is
@@ -58,20 +61,20 @@ instead.
 To continue the above example, you can configure a dependency when creating the
 new merge request in `awesome-project` (or by editing it, if it already exists).
 The dependency needs to be configured on the **dependent** merge
-request. There is a "Cross-project dependencies" section in the form:
+request. There is a **Merge request dependencies** section in the form:
 
-![Cross-project dependencies form control](img/cross_project_dependencies_edit_v12_2.png)
+![Merge request dependencies form control](img/dependencies_edit_v12_4.png)
 
 Anyone who can edit a merge request can change the list of dependencies.
 
 New dependencies can be added by reference, or by URL. To remove a dependency,
 press the **X** by its reference.
 
-As dependencies are specified across projects, it's possible that someone else
+As dependencies can be specified across projects, it's possible that someone else
 has added a dependency for a merge request in a project you don't have access to.
 These are shown as a simple count:
 
-![Cross-project dependencies form control with inaccessible merge requests](img/cross_project_dependencies_edit_inaccessible_v12_2.png)
+![Merge request dependencies form control with inaccessible merge requests](img/dependencies_edit_inaccessible_v12_4.png)
 
 If necessary, you can remove all the dependencies like this by pressing the
 **X**, just as you would for a single, visible dependency.
@@ -82,7 +85,7 @@ or **Cancel** to return without making any changes.
 The list of configured dependencies, and the status of each one, is shown in the
 merge request widget:
 
-![Cross-project dependencies in merge request widget](img/cross_project_dependencies_view_v12_2.png)
+![Dependencies in merge request widget](img/dependencies_view_v12_2.png)
 
 Until all dependencies have, themselves, been merged, the **Merge**
 button will be disabled for the dependent merge request. In
@@ -97,9 +100,9 @@ merge.
 
 ## Limitations
 
-- API support: [gitlab-ee#12551](https://gitlab.com/gitlab-org/gitlab/issues/12551)
-- Dependencies are not preserved across project export/import: [gitlab-ee#12549](https://gitlab.com/gitlab-org/gitlab/issues/12549)
-- Complex merge order dependencies are not supported: [gitlab-ee#11393](https://gitlab.com/gitlab-org/gitlab/issues/11393)
+- API support: [issue #12551](https://gitlab.com/gitlab-org/gitlab/issues/12551)
+- Dependencies are not preserved across project export/import: [issue #12549](https://gitlab.com/gitlab-org/gitlab/issues/12549)
+- Complex merge order dependencies are not supported: [issue #11393](https://gitlab.com/gitlab-org/gitlab/issues/11393)
 
 The last item merits a little more explanation. Dependencies between merge
 requests can be described as a graph of relationships. The simplest possible
diff --git a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
index b717cb0ec24..dab2184448a 100644
--- a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
+++ b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
@@ -36,11 +36,19 @@ changes to be reviewed.
 ## Only allow merge requests to be merged if the pipeline succeeds
 
 You can prevent merge requests from being merged if their pipeline did not succeed
-or if there are threads to be resolved.
+or if there are threads to be resolved. This works for both:
 
-Navigate to your project's settings page and expand the **Merge requests** section.
-In the **Merge checks** subsection, select the **Pipelines must succeed** check
-box and hit **Save** for the changes to take effect.
+- GitLab CI/CD pipelines
+- Pipelines run from an [external CI integration](../integrations/project_services.md#services)
+
+As a result, [disabling GitLab CI/CD pipelines](../../../ci/enable_or_disable_ci.md)
+will not disable this feature, as it will still be possible to use pipelines from external
+CI providers with this feature. To enable it, you must:
+
+1. Navigate to your project's **Settings > General** page.
+1. Expand the **Merge requests** section.
+1. In the **Merge checks** subsection, select the **Pipelines must succeed** checkbox.
+1. Press **Save** for the changes to take effect.
 
 NOTE: **Note:** This setting also prevents merge requests from being merged if there is no pipeline.
 
diff --git a/doc/user/project/milestones/index.md b/doc/user/project/milestones/index.md
index 453983fa882..105854ccd33 100644
--- a/doc/user/project/milestones/index.md
+++ b/doc/user/project/milestones/index.md
@@ -130,13 +130,13 @@ These features are only available for project milestones and not group milestone
 
 ### Project Burndown Charts **(STARTER)**
 
-For project milestones in [GitLab Starter](https://about.gitlab.com/pricing), a [burndown chart](burndown_charts.md) is in the milestone view, showing the progress of completing a milestone.
+For project milestones in [GitLab Starter](https://about.gitlab.com/pricing/), a [burndown chart](burndown_charts.md) is in the milestone view, showing the progress of completing a milestone.
 
 ![burndown chart](img/burndown_chart.png)
 
 ### Group Burndown Charts **(PREMIUM)**
 
-For group milestones in [GitLab Premium](https://about.gitlab.com/pricing), a [burndown chart](burndown_charts.md) is in the milestone view, showing the progress of completing a milestone.
+For group milestones in [GitLab Premium](https://about.gitlab.com/pricing/), a [burndown chart](burndown_charts.md) is in the milestone view, showing the progress of completing a milestone.
 
 ### Milestone sidebar
 
diff --git a/doc/user/project/new_ci_build_permissions_model.md b/doc/user/project/new_ci_build_permissions_model.md
index 0e60c4eca75..5f3bb83df70 100644
--- a/doc/user/project/new_ci_build_permissions_model.md
+++ b/doc/user/project/new_ci_build_permissions_model.md
@@ -47,7 +47,7 @@ It is important to note that we have a few types of users:
   Administrator will have to be a member of it in order to have access to it
   via another project's job.
 
-- **External users**: CI jobs created by [external users](../permissions.md#external-users-permissions) will have
+- **External users**: CI jobs created by [external users](../permissions.md#external-users-core-only) will have
   access only to projects to which user has at least reporter access. This
   rules out accessing all internal projects by default.
 
@@ -58,7 +58,7 @@ Let's consider the following scenario:
    hosted in private repositories and you have multiple CI jobs that make use
    of these repositories.
 
-1. You invite a new [external user](../permissions.md#external-users-permissions). CI jobs created by that user do not
+1. You invite a new [external user](../permissions.md#external-users-core-only). CI jobs created by that user do not
    have access to internal repositories, because the user also doesn't have the
    access from within GitLab. You as an employee have to grant explicit access
    for this user. This allows us to prevent from accidental data leakage.
diff --git a/doc/user/project/operations/feature_flags.md b/doc/user/project/operations/feature_flags.md
index 97b3ca0067e..08df92959c3 100644
--- a/doc/user/project/operations/feature_flags.md
+++ b/doc/user/project/operations/feature_flags.md
@@ -174,9 +174,9 @@ Official clients:
 
 Community contributed clients:
 
-- [stiano/unleash-client-dotnet](https://github.com/stiano/unleash-client-dotnet) (.Net Core)
-- [onybo/unleash-client-core](https://github.com/onybo/unleash-client-core) (.Net Core)
-- [aes/unleash-client-python](https://github.com/aes/unleash-client-python) (Python 3)
+- [Unleash FeatureToggle Client for .Net](https://github.com/stiano/unleash-client-dotnet)
+- [Unofficial .Net Core Unleash client](https://github.com/onybo/unleash-client-core)
+- [Unleash client for Python 3](https://github.com/aes/unleash-client-python)
 
 ### Golang application example
 
diff --git a/doc/user/project/pages/custom_domains_ssl_tls_certification/dns_concepts.md b/doc/user/project/pages/custom_domains_ssl_tls_certification/dns_concepts.md
index dc75eb450a3..e561da423f4 100644
--- a/doc/user/project/pages/custom_domains_ssl_tls_certification/dns_concepts.md
+++ b/doc/user/project/pages/custom_domains_ssl_tls_certification/dns_concepts.md
@@ -27,16 +27,16 @@ to do it for you.
 To help you out, we've gathered some instructions on how to do that
 for the most popular hosting services:
 
-- [Amazon](http://docs.aws.amazon.com/gettingstarted/latest/swh/getting-started-configure-route53.html)
+- [Amazon](https://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html)
 - [Bluehost](https://my.bluehost.com/cgi/help/559)
 - [CloudFlare](https://support.cloudflare.com/hc/en-us/articles/200169096-How-do-I-add-A-records-)
-- [cPanel](https://documentation.cpanel.net/display/ALD/Edit+DNS+Zone)
+- [cPanel](https://documentation.cpanel.net/display/84Docs/Edit+DNS+Zone)
 - [DreamHost](https://help.dreamhost.com/hc/en-us/articles/215414867-How-do-I-add-custom-DNS-records-)
 - [Go Daddy](https://www.godaddy.com/help/add-an-a-record-19238)
-- [Hostgator](http://support.hostgator.com/articles/changing-dns-records)
+- [Hostgator](https://www.hostgator.com/help/article/changing-dns-records)
 - [Inmotion hosting](https://my.bluehost.com/cgi/help/559)
 - [Media Temple](https://mediatemple.net/community/products/dv/204403794/how-can-i-change-the-dns-records-for-my-domain)
-- [Microsoft](https://msdn.microsoft.com/en-us/library/bb727018.aspx)
+- [Microsoft](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/bb727018(v=technet.10))
 
 If your hosting service is not listed above, you can just try to
 search the web for `how to add dns record on <my hosting service>`.
diff --git a/doc/user/project/pages/custom_domains_ssl_tls_certification/index.md b/doc/user/project/pages/custom_domains_ssl_tls_certification/index.md
index 849cd1a8ee4..326a2d302d2 100644
--- a/doc/user/project/pages/custom_domains_ssl_tls_certification/index.md
+++ b/doc/user/project/pages/custom_domains_ssl_tls_certification/index.md
@@ -67,10 +67,10 @@ Root domains (`example.com`) require:
 - A [DNS A record](dns_concepts.md#a-record) pointing your domain to the Pages server.
 - A [TXT record](dns_concepts.md#txt-record) to verify your domain's ownership.
 
-| From | DNS Record | To |
-| ---- | ---------- | -- |
-| example.com | A | 35.185.44.232 |
-| _gitlab-pages-verification-code.example.com | TXT | gitlab-pages-verification-code=00112233445566778899aabbccddeeff |
+| From                                          | DNS Record | To              |
+| --------------------------------------------- | ---------- | --------------- |
+| `example.com`                                 | A          | `35.185.44.232` |
+| `_gitlab-pages-verification-code.example.com` | TXT        | `gitlab-pages-verification-code=00112233445566778899aabbccddeeff` |
 
 For projects on GitLab.com, this IP is `35.185.44.232`.
 For projects living in other GitLab instances (CE or EE), please contact
@@ -95,10 +95,10 @@ Subdomains (`subdomain.example.com`) require:
 - A DNS [CNAME record](dns_concepts.md#cname-record) record pointing your subdomain to the Pages server.
 - A DNS [TXT record](dns_concepts.md#txt-record) to verify your domain's ownership.
 
-| From | DNS Record | To |
-| ---- | ---------- | -- |
-| subdomain.example.com | CNAME | namespace.gitlab.io |
-| _gitlab-pages-verification-code.subdomain.example.com | TXT | gitlab-pages-verification-code=00112233445566778899aabbccddeeff |
+| From                                                    | DNS Record | To                    |
+| ------------------------------------------------------- | ---------- | --------------------- |
+| `subdomain.example.com`                                 | CNAME      | `namespace.gitlab.io` |
+| `_gitlab-pages-verification-code.subdomain.example.com` | TXT        | `gitlab-pages-verification-code=00112233445566778899aabbccddeeff` |
 
 Note that, whether it's a user or a project website, the `CNAME`
 should point to your Pages domain (`namespace.gitlab.io`),
@@ -117,13 +117,13 @@ They require:
 - A DNS CNAME record for the subdomain.
 - A DNS TXT record for each.
 
-| From | DNS Record | To |
-| ---- | ---------- | -- |
-| example.com | A | 35.185.44.232 |
-| _gitlab-pages-verification-code.example.com | TXT | gitlab-pages-verification-code=00112233445566778899aabbccddeeff |
-|---+---|
-| www.example.com | CNAME | namespace.gitlab.io |
-| _gitlab-pages-verification-code.www.example.com | TXT | gitlab-pages-verification-code=00112233445566778899aabbccddeeff |
+| From                                              | DNS Record | To                     |
+| ------------------------------------------------- | ---------- | ---------------------- |
+| `example.com`                                     | A          | `35.185.44.232`        |
+| `_gitlab-pages-verification-code.example.com`     | TXT        | `gitlab-pages-verification-code=00112233445566778899aabbccddeeff` |
+|--------------------------------------------+--------------------------------------------|
+| `www.example.com`                                 | CNAME      | `namespace.gitlab.io`  |
+| `_gitlab-pages-verification-code.www.example.com` | TXT        | `gitlab-pages-verification-code=00112233445566778899aabbccddeeff` |
 
 If you're using CloudFlare, check
 [Redirecting `www.domain.com` to `domain.com` with Cloudflare](#redirecting-wwwdomaincom-to-domaincom-with-cloudflare).
@@ -135,8 +135,8 @@ If you're using CloudFlare, check
 > - **Do not** add any special chars after the default Pages
   domain. E.g., don't point `subdomain.domain.com` to
   or `namespace.gitlab.io/`. Some domain hosting providers may request a trailling dot (`namespace.gitlab.io.`), though.
-> - GitLab Pages IP on GitLab.com [was changed](https://about.gitlab.com/2017/03/06/we-are-changing-the-ip-of-gitlab-pages-on-gitlab-com/) in 2017.
-> - GitLab Pages IP on GitLab.com [has changed](https://about.gitlab.com/2018/07/19/gcp-move-update/#gitlab-pages-and-custom-domains)
+> - GitLab Pages IP on GitLab.com [was changed](https://about.gitlab.com/blog/2017/03/06/we-are-changing-the-ip-of-gitlab-pages-on-gitlab-com/) in 2017.
+> - GitLab Pages IP on GitLab.com [has changed](https://about.gitlab.com/blog/2018/07/19/gcp-move-update/#gitlab-pages-and-custom-domains)
   from `52.167.214.135` to `35.185.44.232` in 2018.
 
 #### 4. Verify the domain's ownership
@@ -162,7 +162,7 @@ from the GitLab project.
 > - Domain verification is **required for GitLab.com users**;
   for GitLab self-managed instances, your GitLab administrator has the option
   to [disabled custom domain verification](../../../../administration/pages/index.md#custom-domain-verification).
-> - [DNS propagation may take some time (up to 24h)](http://www.inmotionhosting.com/support/domain-names/dns-nameserver-changes/domain-names-dns-changes),
+> - [DNS propagation may take some time (up to 24h)](https://www.inmotionhosting.com/support/domain-names/dns-nameserver-changes/domain-names-dns-changes),
   although it's usually a matter of minutes to complete. Until it does, verification
   will fail and attempts to visit your domain will respond with a 404.
 > - Once your domain has been verified, leave the verification record
@@ -221,7 +221,7 @@ To secure your custom domain with GitLab Pages you can opt by:
   the part of the encryption keychain that identifies the CA.
   Usually it's combined with the PEM certificate, but there are
   some cases in which you need to add them manually.
-  [CloudFlare certs](https://about.gitlab.com/2017/02/07/setting-up-gitlab-pages-with-cloudflare-certificates/)
+  [CloudFlare certs](https://about.gitlab.com/blog/2017/02/07/setting-up-gitlab-pages-with-cloudflare-certificates/)
   are one of these cases.
 - **A private key**, it's an encrypted key which validates
   your PEM against your domain.
@@ -238,7 +238,7 @@ To secure your custom domain with GitLab Pages you can opt by:
 1. Add the PEM certificate to its corresponding field.
 1. If your certificate is missing its intermediate, copy
   and paste the root certificate (usually available from your CA website)
-  and paste it in the [same field as your PEM certificate](https://about.gitlab.com/2017/02/07/setting-up-gitlab-pages-with-cloudflare-certificates/),
+  and paste it in the [same field as your PEM certificate](https://about.gitlab.com/blog/2017/02/07/setting-up-gitlab-pages-with-cloudflare-certificates/),
   just jumping a line between them.
 1. Copy your private key and paste it in the last field.
 
diff --git a/doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md b/doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md
index ef5466f03c4..c9b504dc6ee 100644
--- a/doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md
+++ b/doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md
@@ -57,7 +57,7 @@ Once you've met the requirements, to enable Let's Encrypt integration:
 1. Click **Save changes**.
 
 Once enabled, GitLab will obtain a LE certificate and add it to the
-associated Pages domain. It will be also renewed automatically by GitLab.
+associated Pages domain. It also will be renewed automatically by GitLab.
 
 > **Notes:**
 >
diff --git a/doc/user/project/pages/custom_domains_ssl_tls_certification/ssl_tls_concepts.md b/doc/user/project/pages/custom_domains_ssl_tls_certification/ssl_tls_concepts.md
index ee0550bfca2..ac0a1f1ceba 100644
--- a/doc/user/project/pages/custom_domains_ssl_tls_certification/ssl_tls_concepts.md
+++ b/doc/user/project/pages/custom_domains_ssl_tls_certification/ssl_tls_concepts.md
@@ -31,7 +31,7 @@ security measure, necessary just for big companies, like banks and shoppings sit
 with financial transactions.
 Now we have a different picture. [According to Josh Aas](https://letsencrypt.org/2015/10/29/phishing-and-malware.html), Executive Director at [ISRG](https://en.wikipedia.org/wiki/Internet_Security_Research_Group):
 
-> _We’ve since come to realize that HTTPS is important for almost all websites. It’s important for any website that allows people to log in with a password, any website that [tracks its users](https://www.washingtonpost.com/news/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/) in any way, any website that [doesn’t want its content altered](http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/), and for any site that offers content people might not want others to know they are consuming. We’ve also learned that any site not secured by HTTPS [can be used to attack other sites](https://krebsonsecurity.com/2015/04/dont-be-fodder-for-chinas-great-cannon/)._
+> _We’ve since come to realize that HTTPS is important for almost all websites. It’s important for any website that allows people to log in with a password, any website that [tracks its users](https://www.washingtonpost.com/news/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/) in any way, any website that [doesn’t want its content altered](https://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/), and for any site that offers content people might not want others to know they are consuming. We’ve also learned that any site not secured by HTTPS [can be used to attack other sites](https://krebsonsecurity.com/2015/04/dont-be-fodder-for-chinas-great-cannon/)._
 
 Therefore, the reason why certificates are so important is that they encrypt
 the connection between the **client** (you, me, your visitors)
@@ -54,7 +54,7 @@ reiterating the importance of HTTPS.
 ## Issuing Certificates
 
 GitLab Pages accepts certificates provided in the [PEM](https://support.quovadisglobal.com/kb/a37/what-is-pem-format.aspx) format, issued by
-[Certificate Authorities (CAs)](https://en.wikipedia.org/wiki/Certificate_authority) or as
+[Certificate Authorities](https://en.wikipedia.org/wiki/Certificate_authority) or as
 [self-signed certificates](https://en.wikipedia.org/wiki/Self-signed_certificate). Note that [self-signed certificates are typically not used](https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/self-signed-certificates-secure-so-why-ban/)
 for public websites for security reasons and to ensure that browsers trust your site's certificate.
 
@@ -72,4 +72,4 @@ source, and free to use. See [GitLab Pages integration with Let's Encrypt](../cu
 Similarly popular are [certificates issued by CloudFlare](https://www.cloudflare.com/ssl/),
 which also offers a [free CDN service](https://blog.cloudflare.com/cloudflares-free-cdn-and-you/).
 Their certs are valid up to 15 years. See the tutorial on
-[how to add a CloudFlare Certificate to your GitLab Pages website](https://about.gitlab.com/2017/02/07/setting-up-gitlab-pages-with-cloudflare-certificates/).
+[how to add a CloudFlare Certificate to your GitLab Pages website](https://about.gitlab.com/blog/2017/02/07/setting-up-gitlab-pages-with-cloudflare-certificates/).
diff --git a/doc/user/project/pages/getting_started_part_four.md b/doc/user/project/pages/getting_started_part_four.md
index 80fa64b162d..27bd9da8d18 100644
--- a/doc/user/project/pages/getting_started_part_four.md
+++ b/doc/user/project/pages/getting_started_part_four.md
@@ -38,7 +38,7 @@ Explaining [every detail of GitLab CI/CD](../../../ci/yaml/README.md)
 and GitLab Runner is out of the scope of this guide, but we'll
 need to understand just a few things to be able to write our own
 `.gitlab-ci.yml` or tweak an existing one. It's an
-[Yaml](http://docs.ansible.com/ansible/YAMLSyntax.html) file,
+[Yaml](https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html) file,
 with its own syntax. You can always check your CI syntax with
 the [GitLab CI Lint Tool](https://gitlab.com/ci/lint).
 
@@ -127,7 +127,7 @@ pages:
 The script above would be enough to build your Jekyll
 site with GitLab Pages. But, from Jekyll 3.4.0 on, its default
 template originated by `jekyll new project` requires
-[Bundler](http://bundler.io/) to install Jekyll dependencies
+[Bundler](https://bundler.io) to install Jekyll dependencies
 and the default theme. To adjust our script to meet these new
 requirements, we only need to install and build Jekyll with Bundler:
 
@@ -385,10 +385,10 @@ to understand how to go even further on your scripts.
 
 - On this blog post, understand the concept of
   [using GitLab CI `environments` to deploy your
-  web app to staging and production](https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/).
+  web app to staging and production](https://about.gitlab.com/blog/2016/08/26/ci-deployment-and-environments/).
 - On this post, learn [how to run jobs sequentially,
-  in parallel, or build a custom pipeline](https://about.gitlab.com/2016/07/29/the-basics-of-gitlab-ci/)
+  in parallel, or build a custom pipeline](https://about.gitlab.com/blog/2016/07/29/the-basics-of-gitlab-ci/)
 - On this blog post, we go through the process of
-  [pulling specific directories from different projects](https://about.gitlab.com/2016/12/07/building-a-new-gitlab-docs-site-with-nanoc-gitlab-ci-and-gitlab-pages/)
-  to deploy this website you're looking at, docs.gitlab.com.
-- On this blog post, we teach you [how to use GitLab Pages to produce a code coverage report](https://about.gitlab.com/2016/11/03/publish-code-coverage-report-with-gitlab-pages/).
+  [pulling specific directories from different projects](https://about.gitlab.com/blog/2016/12/07/building-a-new-gitlab-docs-site-with-nanoc-gitlab-ci-and-gitlab-pages/)
+  to deploy this website you're looking at, <https://docs.gitlab.com>.
+- On this blog post, we teach you [how to use GitLab Pages to produce a code coverage report](https://about.gitlab.com/blog/2016/11/03/publish-code-coverage-report-with-gitlab-pages/).
diff --git a/doc/user/project/pages/getting_started_part_one.md b/doc/user/project/pages/getting_started_part_one.md
index 45fdab1ca3a..0b1cae9ab4c 100644
--- a/doc/user/project/pages/getting_started_part_one.md
+++ b/doc/user/project/pages/getting_started_part_one.md
@@ -5,7 +5,7 @@ type: concepts, reference
 
 # Static sites and GitLab Pages domains
 
-On this docucument, learn how to name your project for GitLab Pages
+On this document, learn how to name your project for GitLab Pages
 according to your intended website's URL.
 
 ## Static sites
@@ -97,7 +97,7 @@ _Read on about [Projects for GitLab Pages and URL structure](getting_started_par
 
 ### Further reading
 
-- Read through this technical overview on [Static versus Dynamic Websites](https://about.gitlab.com/2016/06/03/ssg-overview-gitlab-pages-part-1-dynamic-x-static/)
-- Understand [how modern Static Site Generators work](https://about.gitlab.com/2016/06/10/ssg-overview-gitlab-pages-part-2/) and what you can add to your static site
-- You can use [any SSG with GitLab Pages](https://about.gitlab.com/2016/06/17/ssg-overview-gitlab-pages-part-3-examples-ci/)
+- Read through this technical overview on [Static versus Dynamic Websites](https://about.gitlab.com/blog/2016/06/03/ssg-overview-gitlab-pages-part-1-dynamic-x-static/)
+- Understand [how modern Static Site Generators work](https://about.gitlab.com/blog/2016/06/10/ssg-overview-gitlab-pages-part-2/) and what you can add to your static site
+- You can use [any SSG with GitLab Pages](https://about.gitlab.com/blog/2016/06/17/ssg-overview-gitlab-pages-part-3-examples-ci/)
 - Fork an [example project](https://gitlab.com/pages) to build your website based upon
diff --git a/doc/user/project/pages/getting_started_part_two.md b/doc/user/project/pages/getting_started_part_two.md
index cb80bf1c433..ff752917087 100644
--- a/doc/user/project/pages/getting_started_part_two.md
+++ b/doc/user/project/pages/getting_started_part_two.md
@@ -122,7 +122,7 @@ where you'll find its default URL.
 
 > **Notes:**
 >
-> - GitLab Pages [supports any SSG](https://about.gitlab.com/2016/06/17/ssg-overview-gitlab-pages-part-3-examples-ci/), but,
+> - GitLab Pages [supports any SSG](https://about.gitlab.com/blog/2016/06/17/ssg-overview-gitlab-pages-part-3-examples-ci/), but,
 >   if you don't find yours among the templates, you'll need
 >   to configure your own `.gitlab-ci.yml`. To do that, please
 >   read through the article [Creating and Tweaking GitLab CI/CD for GitLab Pages](getting_started_part_four.md). New SSGs are very welcome among
diff --git a/doc/user/project/pages/index.md b/doc/user/project/pages/index.md
index 41a89a2130d..7d533c6f9d1 100644
--- a/doc/user/project/pages/index.md
+++ b/doc/user/project/pages/index.md
@@ -64,7 +64,7 @@ To publish a website with Pages, you can use any Static Site Generator (SSG),
 such as Jekyll, Hugo, Middleman, Harp, Hexo, and Brunch, just to name a few. You can also
 publish any website written directly in plain HTML, CSS, and JavaScript.</p>
 <p>Pages does <strong>not</strong> support dynamic server-side processing, for instance, as <code>.php</code> and <code>.asp</code> requires. See this article to learn more about
-<a href="https://about.gitlab.com/2016/06/03/ssg-overview-gitlab-pages-part-1-dynamic-x-static/">static websites vs dynamic websites</a>.</p>
+<a href="https://about.gitlab.com/blog/2016/06/03/ssg-overview-gitlab-pages-part-1-dynamic-x-static/">static websites vs dynamic websites</a>.</p>
 </div>
 <div class="col-md-3"><img src="img/ssgs_pages.png" alt="Examples of SSGs supported by Pages" class="image-noshadow middle display-block"></div>
 </div>
@@ -146,11 +146,11 @@ To learn more about configuration options for GitLab Pages, read the following:
 |---+---|
 | [Custom domains and SSL/TLS Certificates](custom_domains_ssl_tls_certification/index.md) | How to add custom domains and subdomains to your website, configure DNS records and SSL/TLS certificates. |
 | [Let's Encrypt integration](custom_domains_ssl_tls_certification/lets_encrypt_integration.md) | Secure your Pages sites with Let's Encrypt certificates automatically obtained and renewed by GitLab. |
-| [CloudFlare certificates](https://about.gitlab.com/2017/02/07/setting-up-gitlab-pages-with-cloudflare-certificates/) | Secure your Pages site with CloudFlare certificates. |
+| [CloudFlare certificates](https://about.gitlab.com/blog/2017/02/07/setting-up-gitlab-pages-with-cloudflare-certificates/) | Secure your Pages site with CloudFlare certificates. |
 |---+---|
-| [Static vs dynamic websites](https://about.gitlab.com/2016/06/03/ssg-overview-gitlab-pages-part-1-dynamic-x-static/) | A conceptual overview on static versus dynamic sites. |
-| [Modern static site generators](https://about.gitlab.com/2016/06/10/ssg-overview-gitlab-pages-part-2/) | A conceptual overview on SSGs. |
-| [Build any SSG site with GitLab Pages](https://about.gitlab.com/2016/06/17/ssg-overview-gitlab-pages-part-3-examples-ci/) | An overview on using SSGs for GitLab Pages. |
+| [Static vs dynamic websites](https://about.gitlab.com/blog/2016/06/03/ssg-overview-gitlab-pages-part-1-dynamic-x-static/) | A conceptual overview on static versus dynamic sites. |
+| [Modern static site generators](https://about.gitlab.com/blog/2016/06/10/ssg-overview-gitlab-pages-part-2/) | A conceptual overview on SSGs. |
+| [Build any SSG site with GitLab Pages](https://about.gitlab.com/blog/2016/06/17/ssg-overview-gitlab-pages-part-3-examples-ci/) | An overview on using SSGs for GitLab Pages. |
 
 ## Advanced use
 
@@ -158,11 +158,11 @@ There are quite some great examples of GitLab Pages websites built for some
 specific reasons. These examples can teach you some advanced techniques
 to use and adapt to your own needs:
 
-- [Posting to your GitLab Pages blog from iOS](https://about.gitlab.com/2016/08/19/posting-to-your-gitlab-pages-blog-from-ios/).
-- [GitLab CI: Run jobs sequentially, in parallel, or build a custom pipeline](https://about.gitlab.com/2016/07/29/the-basics-of-gitlab-ci/).
-- [GitLab CI: Deployment & environments](https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/).
-- [Building a new GitLab docs site with Nanoc, GitLab CI, and GitLab Pages](https://about.gitlab.com/2016/12/07/building-a-new-gitlab-docs-site-with-nanoc-gitlab-ci-and-gitlab-pages/).
-- [Publish code coverage reports with GitLab Pages](https://about.gitlab.com/2016/11/03/publish-code-coverage-report-with-gitlab-pages/).
+- [Posting to your GitLab Pages blog from iOS](https://about.gitlab.com/blog/2016/08/19/posting-to-your-gitlab-pages-blog-from-ios/).
+- [GitLab CI: Run jobs sequentially, in parallel, or build a custom pipeline](https://about.gitlab.com/blog/2016/07/29/the-basics-of-gitlab-ci/).
+- [GitLab CI: Deployment & environments](https://about.gitlab.com/blog/2016/08/26/ci-deployment-and-environments/).
+- [Building a new GitLab docs site with Nanoc, GitLab CI, and GitLab Pages](https://about.gitlab.com/blog/2016/12/07/building-a-new-gitlab-docs-site-with-nanoc-gitlab-ci-and-gitlab-pages/).
+- [Publish code coverage reports with GitLab Pages](https://about.gitlab.com/blog/2016/11/03/publish-code-coverage-report-with-gitlab-pages/).
 
 ## Admin GitLab Pages for self-managed instances
 
@@ -173,5 +173,5 @@ the [admin guide](../../../administration/pages/index.md).
 
 ## More information about GitLab Pages
 
-- Announcement (2016-12-24): ["We're bringing GitLab Pages to CE"](https://about.gitlab.com/2016/12/24/were-bringing-gitlab-pages-to-community-edition/)
-- Announcement (2017-03-06): ["We are changing the IP of GitLab Pages on GitLab.com"](https://about.gitlab.com/2017/03/06/we-are-changing-the-ip-of-gitlab-pages-on-gitlab-com/)
+- Announcement (2016-12-24): ["We're bringing GitLab Pages to CE"](https://about.gitlab.com/blog/2016/12/24/were-bringing-gitlab-pages-to-community-edition/)
+- Announcement (2017-03-06): ["We are changing the IP of GitLab Pages on GitLab.com"](https://about.gitlab.com/blog/2017/03/06/we-are-changing-the-ip-of-gitlab-pages-on-gitlab-com/)
diff --git a/doc/user/project/pages/introduction.md b/doc/user/project/pages/introduction.md
index e197d7c588f..86257e2aa03 100644
--- a/doc/user/project/pages/introduction.md
+++ b/doc/user/project/pages/introduction.md
@@ -67,15 +67,10 @@ Some static site generators provide plugins for that functionality so that you
 don't have to create and edit HTML files manually. For example, Jekyll has the
 [redirect-from plugin](https://github.com/jekyll/jekyll-redirect-from).
 
-## GitLab Pages Access Control **(CORE ONLY)**
+## GitLab Pages Access Control **(CORE)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/33422) in GitLab 11.5.
 
-NOTE: **Note:**
-GitLab Pages access control is not activated on GitLab.com. You can check its
-progress on the
-[infrastructure issue tracker](https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/5576).
-
 You can enable Pages access control on your project, so that only
 [members of your project](../../permissions.md#project-members-permissions)
 (at least Guest) can access your website:
diff --git a/doc/user/project/pipelines/job_artifacts.md b/doc/user/project/pipelines/job_artifacts.md
index 703b0a94470..794c3030c6a 100644
--- a/doc/user/project/pipelines/job_artifacts.md
+++ b/doc/user/project/pipelines/job_artifacts.md
@@ -50,12 +50,9 @@ For more examples on artifacts, follow the [artifacts reference in
 
 ## Browsing artifacts
 
-> With GitLab 9.2, PDFs, images, videos and other formats can be previewed
-> directly in the job artifacts browser without the need to download them.
-> With [GitLab 10.1][ce-14399], HTML files in a public project can be previewed
-> directly in a new tab without the need to download them when
-> [GitLab Pages](../../../administration/pages/index.md) is enabled.
-> The same holds for textual formats (currently supported extensions: `.txt`, `.json`, and `.log`).
+> - From GitLab 9.2, PDFs, images, videos and other formats can be previewed directly in the job artifacts browser without the need to download them.
+> - Introduced in [GitLab 10.1][ce-14399], HTML files in a public project can be previewed directly in a new tab without the need to download them when [GitLab Pages](../../../administration/pages/index.md) is enabled. The same applies for textual formats (currently supported extensions: `.txt`, `.json`, and `.log`).
+> - Introduced in [GitLab 12.4][gitlab-16675], artifacts in private projects can be previewed when [GitLab Pages access control](../../../administration/pages/index.md#access-control) is enabled.
 
 After a job finishes, if you visit the job's specific page, there are three
 buttons. You can download the artifacts archive or browse its contents, whereas
@@ -68,7 +65,7 @@ The archive browser shows the name and the actual file size of each file in the
 archive. If your artifacts contained directories, then you are also able to
 browse inside them.
 
-Below you can see how browsing looks like. In this case we have browsed inside
+Below you can see what browsing looks like. In this case we have browsed inside
 the archive and at this point there is one directory, a couple files, and
 one HTML file that you can view directly online when
 [GitLab Pages](../../../administration/pages/index.md) is enabled (opens in a new tab).
@@ -123,18 +120,18 @@ https://example.com/<namespace>/<project>/-/jobs/artifacts/<ref>/raw/<path_to_fi
 ```
 
 For example, to download the latest artifacts of the job named `coverage` of
-the `master` branch of the `gitlab-ce` project that belongs to the `gitlab-org`
+the `master` branch of the `gitlab` project that belongs to the `gitlab-org`
 namespace, the URL would be:
 
 ```
-https://gitlab.com/gitlab-org/gitlab-foss/-/jobs/artifacts/master/download?job=coverage
+https://gitlab.com/gitlab-org/gitlab/-/jobs/artifacts/master/download?job=coverage
 ```
 
 To download the file `coverage/index.html` from the same
 artifacts use the following URL:
 
 ```
-https://gitlab.com/gitlab-org/gitlab-foss/-/jobs/artifacts/master/raw/coverage/index.html?job=coverage
+https://gitlab.com/gitlab-org/gitlab/-/jobs/artifacts/master/raw/coverage/index.html?job=coverage
 ```
 
 There is also a URL to browse the latest job artifacts:
@@ -146,7 +143,7 @@ https://example.com/<namespace>/<project>/-/jobs/artifacts/<ref>/browse?job=<job
 For example:
 
 ```
-https://gitlab.com/gitlab-org/gitlab-foss/-/jobs/artifacts/master/browse?job=coverage
+https://gitlab.com/gitlab-org/gitlab/-/jobs/artifacts/master/browse?job=coverage
 ```
 
 There is also a URL to specific files, including html files that
@@ -160,7 +157,7 @@ For example, when a job `coverage` creates the artifact `htmlcov/index.html`,
 you can access it at:
 
 ```
-https://gitlab.com/gitlab-org/gitlab-foss/-/jobs/artifacts/master/file/htmlcov/index.html?job=coverage
+https://gitlab.com/gitlab-org/gitlab/-/jobs/artifacts/master/file/htmlcov/index.html?job=coverage
 ```
 
 The latest builds are also exposed in the UI in various places. Specifically,
@@ -198,6 +195,7 @@ In order to retrieve a job artifact of a different project, you might need to us
 
 [expiry date]: ../../../ci/yaml/README.md#artifactsexpire_in
 [ce-14399]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/14399
+[gitlab-16675]: https://gitlab.com/gitlab-org/gitlab/merge_requests/16675
 
 <!-- ## Troubleshooting
 
diff --git a/doc/user/project/pipelines/schedules.md b/doc/user/project/pipelines/schedules.md
index bb3e37ef2bf..bffb0b58230 100644
--- a/doc/user/project/pipelines/schedules.md
+++ b/doc/user/project/pipelines/schedules.md
@@ -84,7 +84,7 @@ For example, only two pipelines will be created per day if:
 To change the Sidekiq worker's frequency:
 
 1. Edit the `gitlab_rails['pipeline_schedule_worker_cron']` value in your instance's `gitlab.rb` file.
-1. [Restart GitLab](../../../administration/restart_gitlab.md).
+1. [Reconfigure GitLab](../../../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
 For GitLab.com, refer to the [dedicated settings page](../../gitlab_com/index.md#cron-jobs).
 
diff --git a/doc/user/project/pipelines/settings.md b/doc/user/project/pipelines/settings.md
index 26ea328c730..6480c7e0af9 100644
--- a/doc/user/project/pipelines/settings.md
+++ b/doc/user/project/pipelines/settings.md
@@ -21,8 +21,8 @@ from GitLab in a job.
 There are two options. Using:
 
 - `git clone`, which is slower since it clones the repository from scratch
-  for every job, ensuring that the project workspace is always pristine.
-- `git fetch`, which is faster as it re-uses the project workspace (falling
+  for every job, ensuring that the local working copy is always pristine.
+- `git fetch`, which is faster as it re-uses the local working copy (falling
   back to clone if it doesn't exist).
 
 The default Git strategy can be overridden by the [GIT_STRATEGY variable](../../../ci/yaml/README.md#git-strategy)
@@ -60,14 +60,19 @@ if the job surpasses the threshold, it is marked as failed.
 Project defined timeout (either specific timeout set by user or the default
 60 minutes timeout) may be [overridden on Runner level](../../../ci/runners/README.html#setting-maximum-job-timeout-for-a-runner).
 
-## Custom CI config path
+## Maximum artifacts size **(CORE ONLY)**
+
+For information about setting a maximum artifact size for a project, see
+[Maximum artifacts size](../../admin_area/settings/continuous_integration.md#maximum-artifacts-size-core-only).
+
+## Custom CI configuration path
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12509) in GitLab 9.4.
 
 By default we look for the `.gitlab-ci.yml` file in the project's root
 directory. If you require a different location **within** the repository,
-you can set a custom filepath that will be used to lookup the config file,
-this filepath should be **relative** to the root.
+you can set a custom path that will be used to look up the configuration file,
+this path should be **relative** to the root.
 
 Here are some valid examples:
 
@@ -80,7 +85,7 @@ The path can be customized at a project level. To customize the path:
 
 1. Go to the project's **Settings > CI / CD**.
 1. Expand the **General pipelines** section.
-1. Provide a value in the **Custom CI config path** field.
+1. Provide a value in the **Custom CI configuration path** field.
 1. Click **Save changes**.
 
 ## Test coverage parsing
@@ -92,7 +97,7 @@ job log using a regular expression. In the pipelines settings, search for the
 ![Pipelines settings test coverage](img/pipelines_settings_test_coverage.png)
 
 Leave blank if you want to disable it or enter a ruby regular expression. You
-can use <http://rubular.com> to test your regex.
+can use <https://rubular.com> to test your regex.
 
 If the pipeline succeeds, the coverage is shown in the merge request widget and
 in the jobs table.
@@ -122,37 +127,40 @@ lein cloverage | perl -pe 's/\e\[?.*?[\@-~]//g'
 
 ## Visibility of pipelines
 
-Access to pipelines and job details (including output of logs and artifacts)
-is checked against your current user access level and the **Public pipelines**
-project setting under your project's **Settings > CI/CD > General pipelines settings**.
+Pipeline visibility is determined by:
+
+- Your current [user access level](../../permissions.md).
+- The **Public pipelines** project setting under your project's **Settings > CI/CD > General pipelines**.
+
+This also determines the visibility of these related features:
+
+- Job output logs
+- Job artifacts
+- The [pipeline security dashboard](../../application_security/security_dashboard/index.md#pipeline-security-dashboard) **(ULTIMATE)**
 
 If **Public pipelines** is enabled (default):
 
-- For **public** projects, anyone can view the pipelines and access the job details
-  (output logs and artifacts).
+- For **public** projects, anyone can view the pipelines and related features.
 - For **internal** projects, any logged in user can view the pipelines
-  and access the job details
-  (output logs and artifacts).
-- For **private** projects, any member (guest or higher) can view the pipelines
-  and access the job details
-  (output logs and artifacts).
+  and related features.
+- For **private** projects, any project member (guest or higher) can view the pipelines
+  and related features.
 
 If **Public pipelines** is disabled:
 
 - For **public** projects, anyone can view the pipelines, but only members
-  (reporter or higher) can access the job details (output logs and artifacts).
+  (reporter or higher) can access the related features.
 - For **internal** projects, any logged in user can view the pipelines.
-  However, only members (reporter or higher) can access the job details (output logs
-  and artifacts).
-- For **private** projects, only members (reporter or higher)
-  can view the pipelines and access the job details (output logs and artifacts).
+  However, only members (reporter or higher) can access the job related features.
+- For **private** projects, only project members (reporter or higher)
+  can view the pipelines or access the related features.
 
 ## Auto-cancel pending pipelines
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/9362) in GitLab 9.1.
 
 If you want to auto-cancel all pending non-HEAD pipelines on branch, when
-new pipeline will be created (after your git push or manually from UI),
+new pipeline will be created (after your Git push or manually from UI),
 check **Auto-cancel pending pipelines** checkbox and save the changes.
 
 ## Pipeline Badges
diff --git a/doc/user/project/protected_branches.md b/doc/user/project/protected_branches.md
index cf4afef15cd..b7c9faeb1df 100644
--- a/doc/user/project/protected_branches.md
+++ b/doc/user/project/protected_branches.md
@@ -23,6 +23,8 @@ A GitLab admin is allowed to push to the protected branches.
 
 See the [Changelog](#changelog) section for changes over time.
 
+The default branch protection level is set in the [Admin Area](../admin_area/settings/visibility_and_access_controls.md#default-branch-protection).
+
 ## Configuring protected branches
 
 To protect a branch, you need to have at least Maintainer permission level. Note
@@ -41,7 +43,7 @@ that the `master` branch is protected by default.
 
 ## Using the Allowed to merge and Allowed to push settings
 
-> [Introduced][ce-5081] in GitLab 8.11.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/5081) in GitLab 8.11.
 
 Since GitLab 8.11, we added another layer of branch protection which provides
 more granular management of protected branches. The "Developers can push"
@@ -71,7 +73,7 @@ they are set to "Maintainers" by default.
 
 ## Restricting push and merge access to certain users **(STARTER)**
 
-> [Introduced][ce-5081] in [GitLab Starter][ee] 8.11.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/5081) in [GitLab Starter](https://about.gitlab.com/pricing/) 8.11.
 
 With GitLab Enterprise Edition you can restrict access to protected branches
 by choosing a role (Maintainers, Developers) as well as certain users. From the
@@ -86,7 +88,7 @@ Click **Protect** and the branch will appear in the "Protected branch" list.
 
 ## Wildcard protected branches
 
-> [Introduced][ce-4665] in GitLab 8.10.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/4665) in GitLab 8.10.
 
 You can specify a wildcard protected branch, which will protect all branches
 matching the wildcard. For example:
@@ -131,12 +133,12 @@ To create a new branch through the user interface:
 
 ## Deleting a protected branch
 
-> [Introduced][ce-21393] in GitLab 9.3.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/21393) in GitLab 9.3.
 
 From time to time, it may be required to delete or clean up branches that are
 protected.
 
-User with [Maintainer permissions][perm] and up can manually delete protected
+User with [Maintainer permissions](../permissions.md) and up can manually delete protected
 branches via GitLab's web interface:
 
 1. Visit **Repository > Branches**
@@ -150,6 +152,35 @@ Deleting a protected branch is only allowed via the web interface, not via Git.
 This means that you can't accidentally delete a protected branch from your
 command line or a Git client application.
 
+## Protected Branches approval by Code Owners **(PREMIUM)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/13251) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.4.
+
+It is possible to require at least one approval by a
+[Code Owner](code_owners.md) to a file changed by the
+merge request. You can either set Code Owners approvals
+at the time you protect a new branch, or set it to a branch
+already protected, as described below.
+
+To protect a new branch and enable Code Owner's approval:
+
+1. Navigate to your project's **Settings > Repository** and expand **Protected branches**.
+1. Scroll down to **Protect a branch**, select a **Branch** or wildcard you'd like to protect, select who's **Allowed to merge** and **Allowed to push**, and toggle the **Require approval from code owners** slider.
+1. Click **Protect**.
+
+![Code Owners approval - new protected branch](img/code_owners_approval_new_protected_branch_v12_4.png)
+
+To enable Code Owner's approval to branches already protected:
+
+1. Navigate to your project's **Settings > Repository** and expand **Protected branches**.
+1. Scroll down to **Protected branch** and toggle the **Code owner approval** slider for the chosen branch.
+
+![Code Owners approval - branch already protected](img/code_owners_approval_protected_branch_v12_4.png)
+
+When enabled, all merge requests targeting these branches will require approval
+by a Code Owner per matched rule before they can be merged.
+Additionally, direct pushes to the protected branch are denied if a rule is matched.
+
 ## Running pipelines on protected branches
 
 The permission to merge or push to protected branches is used to define if a user can
@@ -166,23 +197,16 @@ for details about the pipelines security model.
 
 **9.2**
 
-- Allow deletion of protected branches via the web interface [gitlab-org/gitlab-ce#21393][ce-21393]
+- Allow deletion of protected branches via the web interface ([issue #21393](https://gitlab.com/gitlab-org/gitlab-foss/issues/21393)).
 
 **8.11**
 
-- Allow creating protected branches that can't be pushed to [gitlab-org/gitlab-ce!5081][ce-5081]
+- Allow creating protected branches that can't be pushed to ([merge request !5081](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/5081)).
 
 **8.10**
 
-- Allow developers to merge into a protected branch without having push access [gitlab-org/gitlab-ce!4892][ce-4892]
-- Allow specifying protected branches using wildcards [gitlab-org/gitlab-ce!4665][ce-4665]
-
-[ce-4665]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/4665 "Allow specifying protected branches using wildcards"
-[ce-4892]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/4892 "Allow developers to merge into a protected branch without having push access"
-[ce-5081]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/5081 "Allow creating protected branches that can't be pushed to"
-[ce-21393]: https://gitlab.com/gitlab-org/gitlab-foss/issues/21393
-[perm]: ../permissions.md
-[ee]: https://about.gitlab.com/pricing/
+- Allow developers without push access to merge into a protected branch ([merge request !4892](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/4892)).
+- Allow specifying protected branches using wildcards ([merge request !4665](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/4665)).
 
 <!-- ## Troubleshooting
 
diff --git a/doc/user/project/push_options.md b/doc/user/project/push_options.md
new file mode 100644
index 00000000000..51c46dbd1d4
--- /dev/null
+++ b/doc/user/project/push_options.md
@@ -0,0 +1,77 @@
+---
+type: reference
+---
+
+# Push Options
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/15643) in GitLab 11.7.
+
+GitLab supports using [Git push options](https://git-scm.com/docs/git-push#Documentation/git-push.txt--oltoptiongt)
+to perform various actions at the same time as pushing changes.
+
+Currently, there are push options available for:
+
+- [Skipping CI jobs](#push-options-for-gitlab-cicd)
+- [Merge requests](#push-options-for-merge-requests)
+
+NOTE: **Note:**
+Git push options are only available with Git 2.10 or newer.
+
+For Git versions 2.10 to 2.17 use `--push-option`:
+
+```shell
+git push --push-option=<push_option>
+```
+
+For version 2.18 and later, you can use the above format, or the shorter `-o`:
+
+```shell
+git push -o <push_option>
+```
+
+## Push options for GitLab CI/CD
+
+If the `ci.skip` push option is used, the commit will be pushed, but no [CI pipeline](../../ci/pipelines.md)
+will be created.
+
+| Push option | Description |
+| ----------- | ----------- |
+| `ci.skip`   | Do not create a CI pipeline for the latest push. |
+
+For example:
+
+```shell
+git push -o ci.skip
+```
+
+## Push options for merge requests
+
+You can use Git push options to perform certain actions for merge requests at the same
+time as pushing changes:
+
+| Push option                                  | Description                                                                                                     | Introduced in version |
+| -------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | --------------------- |
+| `merge_request.create`                       | Create a new merge request for the pushed branch.                                                               | [11.10](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/26752) |
+| `merge_request.target=<branch_name>`         | Set the target of the merge request to a particular branch.                                                     | [11.10](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/26752) |
+| `merge_request.merge_when_pipeline_succeeds` | Set the merge request to [merge when its pipeline succeeds](merge_requests/merge_when_pipeline_succeeds.md).    | [11.10](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/26752) |
+| `merge_request.remove_source_branch`         | Set the merge request to remove the source branch when it's merged.                                             | [12.2](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320)          |
+| `merge_request.title="<title>"`              | Set the title of the merge request. Ex: `git push -o merge_request.title="The title I want"`.                   | [12.2](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320)          |
+| `merge_request.description="<description>"`  | Set the description of the merge request. Ex: `git push -o merge_request.description="The description I want"`. | [12.2](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320)          |
+| `merge_request.label="<label>"`              | Add labels to the merge request. If the label does not exist, it will be created. For example, for two labels: `git push -o merge_request.label="label1" -o merge_request.label="label2"`. | [12.3](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/31831) |
+| `merge_request.unlabel="<label>"`            | Remove labels from the merge request. For example, for two labels: `git push -o merge_request.unlabel="label1" -o merge_request.unlabel="label2"`. | [12.3](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/31831) |
+
+If you use a push option that requires text with spaces in it, you need to enclose it
+in quotes (`"`). You can omit the quotes if there are no spaces. Some examples:
+
+```shell
+git push -o merge_request.label="Label with spaces"
+git push -o merge_request.label=Label-with-no-spaces
+```
+
+You can combine push options to accomplish multiple tasks at once, by using
+multiple `-o` (or `--push-option`) flags. For example, if you want to create a new
+merge request, and target a branch named `my-target-branch`:
+
+```shell
+git push -o merge_request.create -o merge_request.target=my-target-branch
+```
diff --git a/doc/user/project/quick_actions.md b/doc/user/project/quick_actions.md
index 0078e9ea417..61bc66a6a69 100644
--- a/doc/user/project/quick_actions.md
+++ b/doc/user/project/quick_actions.md
@@ -64,8 +64,8 @@ The following quick actions are applicable to descriptions, discussions and thre
 | `/create_merge_request <branch name>` | ✓     |               |      | Create a new merge request starting from the current issue |
 | `/relate #issue1 #issue2`             | ✓     |               |      | Mark issues as related **(STARTER)** |
 | `/move <path/to/project>`             | ✓     |               |      | Move this issue to another project |
-| `/zoom <Zoom URL>`                    | ✓     |               |      | Add Zoom meeting to this issue. ([Introduced in GitLab 12.3](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/16609) enabled by feature flag `issue_zoom_integration`) |
-| `/remove_zoom`                        | ✓     |               |      | Remove Zoom meeting from this issue. ([Introduced in GitLab 12.3](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/16609) enabled by feature flag `issue_zoom_integration`) |
+| `/zoom <Zoom URL>`                    | ✓     |               |      | Add Zoom meeting to this issue. ([Introduced in GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/merge_requests/16609)) |
+| `/remove_zoom`                        | ✓     |               |      | Remove Zoom meeting from this issue. ([Introduced in GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/merge_requests/16609)) |
 | `/target_branch <local branch name>`  |       | ✓             |      | Set target branch |
 | `/wip`                                |       | ✓             |      | Toggle the Work In Progress status |
 | `/approve`                            |       | ✓             |      | Approve the merge request |
diff --git a/doc/user/project/releases/img/custom_notifications_new_release_v12_4.png b/doc/user/project/releases/img/custom_notifications_new_release_v12_4.png
new file mode 100644
index 00000000000..6b4231d5804
--- /dev/null
+++ b/doc/user/project/releases/img/custom_notifications_new_release_v12_4.png
diff --git a/doc/user/project/releases/index.md b/doc/user/project/releases/index.md
index d5ac6f99e7f..ceb077ab8af 100644
--- a/doc/user/project/releases/index.md
+++ b/doc/user/project/releases/index.md
@@ -65,6 +65,18 @@ project.
 
 ![Releases list](img/releases.png)
 
+## Notification for Releases
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/26001) in GitLab 12.4.
+
+You can be notified by email when a new Release is created for your project.
+
+To subscribe to these notifications, navigate to your **Project**'s landing page, then click on the
+bell icon. Choose **Custom** from the dropdown menu. The
+following modal window will be then displayed, from which you can select **New release** to complete your subscription to new Releases notifications.
+
+![Custom notification - New release](img/custom_notifications_new_release_v12_4.png)
+
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues
diff --git a/doc/user/project/repository/reducing_the_repo_size_using_git.md b/doc/user/project/repository/reducing_the_repo_size_using_git.md
index fb07981e033..1187a44fda8 100644
--- a/doc/user/project/repository/reducing_the_repo_size_using_git.md
+++ b/doc/user/project/repository/reducing_the_repo_size_using_git.md
@@ -19,7 +19,8 @@ Unfortunately, it's not so easy and that workflow won't work. Deleting files in
 a commit doesn't actually reduce the size of the repo since the earlier commits
 and blobs are still around. What you need to do is rewrite history with Git's
 [`filter-branch` option](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#The-Nuclear-Option:-filter-branch),
-or a tool like the [BFG Repo-Cleaner](https://rtyley.github.io/bfg-repo-cleaner/).
+or an open source community-maintained tool like the  
+[BFG](https://rtyley.github.io/bfg-repo-cleaner/).
 
 Note that even with that method, until `git gc` runs on the GitLab side, the
 "removed" commits and blobs will still be around. You also need to be able to
@@ -34,8 +35,9 @@ temporarily increase it for you, your only option is to prune all the unneeded
 stuff locally, and then create a new project on GitLab and start using that
 instead.
 
-If you can continue to use the original project, we recommend [using the
-BFG Repo-Cleaner](#using-the-bfg-repo-cleaner). It's faster and simpler than
+If you can continue to use the original project, we recommend [using
+BFG](#using-the-bfg-repo-cleaner), a tool that's built and
+maintained by the open source community. It's faster and simpler than
 `git filter-branch`, and GitLab can use its account of what has changed to clean
 up its own internal state, maximizing the space saved.
 
@@ -54,7 +56,7 @@ removed from the repository.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/19376) in GitLab 11.6.
 
-1. [Install BFG](https://rtyley.github.io/bfg-repo-cleaner/).
+1. [Install BFG](https://rtyley.github.io/bfg-repo-cleaner/) from its open source community repository.
 
 1. Navigate to your repository:
 
@@ -99,7 +101,7 @@ removed from the repository.
    ![Repository settings cleanup form](img/repository_cleanup.png)
 
    Upload the `object-id-map.old-new.txt` file and press **Start cleanup**.
-   This will remove any internal git references to the old commits, and run
+   This will remove any internal Git references to the old commits, and run
    `git gc` against the repository. You will receive an email once it has
    completed.
 
diff --git a/doc/user/project/repository/web_editor.md b/doc/user/project/repository/web_editor.md
index a3cfa48e27e..944720c3863 100644
--- a/doc/user/project/repository/web_editor.md
+++ b/doc/user/project/repository/web_editor.md
@@ -117,7 +117,7 @@ the description field will automatically display the [issue closing pattern](../
 merge request is merged.
 
 [project-services-doc]: ../integrations/project_services.md
-[auto-deploy-doc]: ../../../ci/autodeploy/index.md
+[auto-deploy-doc]: ../../../topics/autodevops/index.md#auto-deploy
 
 ### Create a new branch from a project's dashboard
 
diff --git a/doc/user/project/service_desk.md b/doc/user/project/service_desk.md
index 3f3536838e7..0ca34c4ed02 100644
--- a/doc/user/project/service_desk.md
+++ b/doc/user/project/service_desk.md
@@ -1,6 +1,6 @@
 # Service Desk **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/149) in [GitLab Premium 9.1](https://about.gitlab.com/2017/04/22/gitlab-9-1-released/#service-desk-eep).
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/149) in [GitLab Premium 9.1](https://about.gitlab.com/blog/2017/04/22/gitlab-9-1-released/#service-desk-eep).
 
 ## Overview
 
@@ -18,7 +18,7 @@ As Service Desk is built right into GitLab itself, the complexity and inefficien
 of multiple tools and external integrations are eliminated, significantly shortening
 the cycle time from feedback to software update.
 
-For an overview, check the video demonstration on [GitLab Service Desk](https://about.gitlab.com/2017/05/09/demo-service-desk/).
+For an overview, check the video demonstration on [GitLab Service Desk](https://about.gitlab.com/blog/2017/05/09/demo-service-desk/).
 
 ## Use cases
 
@@ -50,7 +50,7 @@ users will only see the thread through email.
 
 > **Note:**
 Service Desk is enabled on GitLab.com. If you're a
-[Silver subscriber](https://about.gitlab.com/gitlab-com/),
+[Silver subscriber](https://about.gitlab.com/pricing/#gitlab-com),
 you can skip the step 1 below; you only need to enable it per project.
 
 1. [Set up incoming email](../../administration/incoming_email.md#set-it-up) for the GitLab instance. This must
diff --git a/doc/user/project/settings/img/sharing_and_permissions_settings.png b/doc/user/project/settings/img/sharing_and_permissions_settings.png
deleted file mode 100644
index 6cb89c6ea1d..00000000000
--- a/doc/user/project/settings/img/sharing_and_permissions_settings.png
+++ /dev/null
diff --git a/doc/user/project/settings/img/sharing_and_permissions_settings_v12_3.png b/doc/user/project/settings/img/sharing_and_permissions_settings_v12_3.png
new file mode 100644
index 00000000000..cf7fdfe4cce
--- /dev/null
+++ b/doc/user/project/settings/img/sharing_and_permissions_settings_v12_3.png
diff --git a/doc/user/project/settings/import_export.md b/doc/user/project/settings/import_export.md
index 948102110f3..9449ab6d10f 100644
--- a/doc/user/project/settings/import_export.md
+++ b/doc/user/project/settings/import_export.md
@@ -65,6 +65,7 @@ The following items will be exported:
 - Project configuration, including services
 - Issues with comments, merge requests with diffs and comments, labels, milestones, snippets,
   and other project entities
+- Design Management files and data **(PREMIUM)**
 - LFS objects
 - Issue boards
 
diff --git a/doc/user/project/settings/index.md b/doc/user/project/settings/index.md
index 66a861faf93..131999dbf60 100644
--- a/doc/user/project/settings/index.md
+++ b/doc/user/project/settings/index.md
@@ -24,7 +24,7 @@ The project description also partially supports [standard markdown](../../markdo
 
 Set up your project's access, [visibility](../../../public_access/public_access.md), and enable [Container Registry](../../packages/container_registry/index.md) for your projects:
 
-![projects sharing permissions](img/sharing_and_permissions_settings.png)
+![projects sharing permissions](img/sharing_and_permissions_settings_v12_3.png)
 
 If Issues are disabled, or you can't access Issues because you're not a project member, then Labels and Milestones
 links will be missing from the sidebar UI.
diff --git a/doc/user/reserved_names.md b/doc/user/reserved_names.md
index 16d032217b3..b160cb03f94 100644
--- a/doc/user/reserved_names.md
+++ b/doc/user/reserved_names.md
@@ -4,7 +4,8 @@ Not all project & group names are allowed because they would conflict with
 existing routes used by GitLab.
 
 For a list of words that are not allowed to be used as group or project names, see the
-[`path_regex.rb` file][reserved] under the `TOP_LEVEL_ROUTES`, `PROJECT_WILDCARD_ROUTES` and `GROUP_ROUTES` lists:
+[`path_regex.rb` file](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/path_regex.rb)
+under the `TOP_LEVEL_ROUTES`, `PROJECT_WILDCARD_ROUTES` and `GROUP_ROUTES` lists:
 
 - `TOP_LEVEL_ROUTES`: are names that are reserved as usernames or top level groups
 - `PROJECT_WILDCARD_ROUTES`: are names that are reserved for child groups or projects.
@@ -40,52 +41,50 @@ It is currently not possible to create a project with the following names:
 
 Currently the following names are reserved as top level groups:
 
-- \-
-- .well-known
-- 404.html
-- 422.html
-- 500.html
-- 502.html
-- 503.html
-- abuse_reports
-- admin
-- api
-- apple-touch-icon-precomposed.png
-- apple-touch-icon.png
-- assets
-- autocomplete
-- ci
-- dashboard
-- deploy.html
-- explore
-- favicon.ico
-- favicon.png
-- files
-- groups
-- health_check
-- help
-- import
-- invites
-- jwt
-- login
-- notification_settings
-- oauth
-- profile
-- projects
-- public
-- robots.txt
-- s
-- search
-- sent_notifications
-- slash-command-logo.png
-- snippets
-- unsubscribes
-- uploads
-- users
-- v2
+- `\-`
+- `.well-known`
+- `404.html`
+- `422.html`
+- `500.html`
+- `502.html`
+- `503.html`
+- `abuse_reports`
+- `admin`
+- `api`
+- `apple-touch-icon-precomposed.png`
+- `apple-touch-icon.png`
+- `assets`
+- `autocomplete`
+- `ci`
+- `dashboard`
+- `deploy.html`
+- `explore`
+- `favicon.ico`
+- `favicon.png`
+- `files`
+- `groups`
+- `health_check`
+- `help`
+- `import`
+- `invites`
+- `jwt`
+- `login`
+- `notification_settings`
+- `oauth`
+- `profile`
+- `projects`
+- `public`
+- `robots.txt`
+- `s`
+- `search`
+- `sent_notifications`
+- `slash-command-logo.png`
+- `snippets`
+- `unsubscribes`
+- `uploads`
+- `users`
+- `v2`
 
 These group names are unavailable as subgroup names:
 
-- \-
-
-[reserved]:  https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/path_regex.rb
+- `\-`
diff --git a/doc/user/snippets.md b/doc/user/snippets.md
index e55a407295e..77997c53210 100644
--- a/doc/user/snippets.md
+++ b/doc/user/snippets.md
@@ -70,8 +70,8 @@ To embed a snippet, first make sure that:
 - In **Project > Settings > Permissions**, the snippets permissions are
   set to **Everyone with access**
 
-Once the above conditions are met, the "Embed" section will appear in your snippet
-where you can simply click on the "Copy to clipboard" button. This copies a one-line
+Once the above conditions are met, the "Embed" section will appear in your
+snippet where you can simply click on the "Copy" button. This copies a one-line
 script that you can add to any website or blog post.
 
 Here's how an example code looks like:
diff --git a/doc/workflow/file_finder.md b/doc/workflow/file_finder.md
index 324989c173b..8eb705b5363 100644
--- a/doc/workflow/file_finder.md
+++ b/doc/workflow/file_finder.md
@@ -23,7 +23,7 @@ and go back to **Files**.
 
 ## How it works
 
-The File finder feature is powered by the [Fuzzy filter] library.
+The File finder feature is powered by the [Fuzzy filter](https://github.com/jeancroy/fuzz-aldrin-plus) library.
 
 It implements a fuzzy search with highlight, and tries to provide intuitive
 results by recognizing patterns that people use while searching.
@@ -38,5 +38,4 @@ Using fuzzy search, we start by typing letters that get us closer to the file.
 ![Find file button](img/file_finder_find_file.png)
 
 [gh-9889]: https://github.com/gitlabhq/gitlabhq/pull/9889 "File finder pull request"
-[fuzzy filter]: https://github.com/jeancroy/fuzzaldrin-plus "fuzzaldrin-plus on GitHub"
 [ce]: https://gitlab.com/gitlab-org/gitlab-foss/tree/master "GitLab CE repository"
diff --git a/doc/workflow/forking_workflow.md b/doc/workflow/forking_workflow.md
index 82c2709143d..48be38b2eca 100644
--- a/doc/workflow/forking_workflow.md
+++ b/doc/workflow/forking_workflow.md
@@ -48,4 +48,4 @@ changes will be added to the repository and branch you're merging into.
 
 ![New merge request](forking/merge_request.png)
 
-[gitlab flow]: https://about.gitlab.com/2014/09/29/gitlab-flow/ "GitLab Flow blog post"
+[gitlab flow]: https://about.gitlab.com/blog/2014/09/29/gitlab-flow/ "GitLab Flow blog post"
diff --git a/doc/workflow/gitlab_flow.md b/doc/workflow/gitlab_flow.md
index 136e05281a6..e3568d6489d 100644
--- a/doc/workflow/gitlab_flow.md
+++ b/doc/workflow/gitlab_flow.md
@@ -168,7 +168,6 @@ This branch is the place for any work related to this change.
 
 NOTE: **Note:**
 The name of a branch might be dictated by organizational standards.
-For example, in GitLab, any branches in GitLab EE that are equivalent to branches in GitLab CE [must end in `-ee`](../development/automatic_ce_ee_merge.md#cherry-picking-from-ce-to-ee).
 
 When you are done or want to discuss the code, open a merge request.
 A merge request is an online place to discuss the change and review the code.
diff --git a/doc/workflow/lfs/lfs_administration.md b/doc/workflow/lfs/lfs_administration.md
index 89ad7c174a2..7ad87982501 100644
--- a/doc/workflow/lfs/lfs_administration.md
+++ b/doc/workflow/lfs/lfs_administration.md
@@ -53,7 +53,7 @@ to offload local hard disk R/W operations, and free up disk space significantly.
 GitLab is tightly integrated with `Fog`, so you can refer to its [documentation](http://fog.io/about/provider_documentation.html)
 to check which storage services can be integrated with GitLab.
 You can also use external object storage in a private local network. For example,
-[Minio](https://min.io/) is a standalone object storage service, is easy to set up, and works well with GitLab instances.
+[MinIO](https://min.io/) is a standalone object storage service, is easy to set up, and works well with GitLab instances.
 
 GitLab provides two different options for the uploading mechanism: "Direct upload" and "Background upload".
 
@@ -93,7 +93,7 @@ Here is a configuration example with S3.
 | `enable_signature_v4_streaming` | Set to true to enable HTTP chunked transfers with [AWS v4 signatures](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-streaming.html). Oracle Cloud S3 needs this to be false | true |
 | `region` | AWS region | us-east-1 |
 | `host` | S3 compatible host for when not using AWS, e.g. `localhost` or `storage.example.com` | s3.amazonaws.com |
-| `endpoint` | Can be used when configuring an S3 compatible service such as [Minio](https://www.minio.io), by entering a URL such as `http://127.0.0.1:9000` | (optional) |
+| `endpoint` | Can be used when configuring an S3 compatible service such as [MinIO](https://min.io), by entering a URL such as `http://127.0.0.1:9000` | (optional) |
 | `path_style` | Set to true to use `host/bucket_name/object` style paths instead of `bucket_name.host/object`. Leave as false for AWS S3 | false |
 | `use_iam_profile` | Set to true to use IAM profile instead of access keys | false
 
@@ -124,7 +124,7 @@ NOTE: **Note:**
 Regardless of whether the container has public access enabled or disabled, Fog will
 use the TempURL method to grant access to LFS objects. If you see errors in logs referencing
 instantiating storage with a temp-url-key, ensure that you have set they key properly
-on the Rackspace API and in gitlab.rb. You can verify the value of the key Rackspace
+on the Rackspace API and in `gitlab.rb`. You can verify the value of the key Rackspace
 has set by sending a GET request with token header to the service access endpoint URL
 and comparing the output of the returned headers.
 
@@ -218,6 +218,14 @@ For source installations the settings are nested under `lfs:` and then
    will be forwarded to object storage unless `background_upload` is set to
    false.
 
+### Migrating back to local storage
+
+In order to migrate back to local storage:
+
+1. Set both `direct_upload` and `background_upload` to false under the LFS object storage settings. Don't forget to restart GitLab.
+1. Run `rake gitlab:lfs:migrate_to_local` on your console.
+1. Disable `object_storage` for LFS objects in `gitlab.rb`. Remember to restart GitLab afterwards.
+
 ## Storage statistics
 
 You can see the total storage used for LFS objects on groups and projects
@@ -227,7 +235,7 @@ and [projects APIs](../../api/projects.md).
 ## Troubleshooting: `Google::Apis::TransmissionError: execution expired`
 
 If LFS integration is configred with Google Cloud Storage and background uploads (`background_upload: true` and `direct_upload: false`),
-sidekiq workers may encouter this error. This is because the uploading timed out with very large files.
+Sidekiq workers may encouter this error. This is because the uploading timed out with very large files.
 LFS files up to 6Gb can be uploaded without any extra steps, otherwise you need to use the following workaround.
 
 ```shell
@@ -251,7 +259,7 @@ See more information in [!19581](https://gitlab.com/gitlab-org/gitlab-foss/merge
 
 - Support for removing unreferenced LFS objects was added in 8.14 onwards.
 - LFS authentications via SSH was added with GitLab 8.12.
-- Only compatible with the GitLFS client versions 1.1.0 and up, or 1.0.2.
+- 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.
 
diff --git a/doc/workflow/lfs/manage_large_binaries_with_git_lfs.md b/doc/workflow/lfs/manage_large_binaries_with_git_lfs.md
index 10728f79b6c..f747a7b5196 100644
--- a/doc/workflow/lfs/manage_large_binaries_with_git_lfs.md
+++ b/doc/workflow/lfs/manage_large_binaries_with_git_lfs.md
@@ -70,7 +70,7 @@ git add .gitattributes
 ```
 
 Cloning the repository works the same as before. Git automatically detects the
-LFS-tracked files and clones them via HTTP. If you performed the git clone
+LFS-tracked files and clones them via HTTP. If you performed the `git clone`
 command with a SSH URL, you have to enter your GitLab credentials for HTTP
 authentication.
 
@@ -172,7 +172,7 @@ Check if you have permissions to push to the project or fetch from the project.
 LFS object you are trying to push to the project or fetch from the project is not
 available to the project anymore. Probably the object was removed from the server.
 
-- Local git repository is using deprecated LFS API
+- Local Git repository is using deprecated LFS API
 
 ### Invalid status for `<url>` : 501
 
@@ -250,7 +250,7 @@ GitLab checks files to detect LFS pointers on push. If LFS pointers are detected
 
 Verify that LFS in installed locally and consider a manual push with `git lfs push --all`.
 
-If you are storing LFS files outside of GitLab you can disable LFS on the project by setting `lfs_enabled: false` with the [projects api](../../api/projects.md#edit-project).
+If you are storing LFS files outside of GitLab you can disable LFS on the project by setting `lfs_enabled: false` with the [projects API](../../api/projects.md#edit-project).
 
 ### Hosting LFS objects externally
 
diff --git a/doc/workflow/lfs/migrate_from_git_annex_to_git_lfs.md b/doc/workflow/lfs/migrate_from_git_annex_to_git_lfs.md
index 905d5624688..8f24929c9dc 100644
--- a/doc/workflow/lfs/migrate_from_git_annex_to_git_lfs.md
+++ b/doc/workflow/lfs/migrate_from_git_annex_to_git_lfs.md
@@ -247,8 +247,8 @@ git annex uninit
 [Git LFS]: https://git-lfs.github.com/
 [install-lfs]: https://git-lfs.github.com/
 [issue-remove-annex]: https://gitlab.com/gitlab-org/gitlab/issues/1648
-[lfs-track]: https://about.gitlab.com/2017/01/30/getting-started-with-git-lfs-tutorial/#tracking-files-with-lfs
-[post-1]: https://about.gitlab.com/2017/01/30/getting-started-with-git-lfs-tutorial/
-[post-2]: https://about.gitlab.com/2015/11/23/announcing-git-lfs-support-in-gitlab/
-[post-3]: https://about.gitlab.com/2015/02/17/gitlab-annex-solves-the-problem-of-versioning-large-binaries-with-git/
+[lfs-track]: https://about.gitlab.com/blog/2017/01/30/getting-started-with-git-lfs-tutorial/#tracking-files-with-lfs
+[post-1]: https://about.gitlab.com/blog/2017/01/30/getting-started-with-git-lfs-tutorial/
+[post-2]: https://about.gitlab.com/blog/2015/11/23/announcing-git-lfs-support-in-gitlab/
+[post-3]: https://about.gitlab.com/blog/2015/02/17/gitlab-annex-solves-the-problem-of-versioning-large-binaries-with-git/
 [uninit]: https://git-annex.branchable.com/git-annex-uninit/
diff --git a/doc/workflow/notifications.md b/doc/workflow/notifications.md
index 6205ef7b4c3..d619c870c5e 100644
--- a/doc/workflow/notifications.md
+++ b/doc/workflow/notifications.md
@@ -78,12 +78,13 @@ Below is the table of events users can be notified of:
 | New email added              | User                | Security email, always sent. |
 | Email changed                | User                | Security email, always sent. |
 | Password changed             | User                | Security email, always sent. |
-| New user created             | User                | Sent on user creation, except for omniauth (LDAP)|
+| New user created             | User                | Sent on user creation, except for OmniAuth (LDAP)|
 | User added to project        | User                | Sent when user is added to project |
 | Project access level changed | User                | Sent when user project access level is changed |
 | User added to group          | User                | Sent when user is added to group |
 | Group access level changed   | User                | Sent when user group access level is changed |
 | Project moved                | Project members (1) | (1) not disabled |
+| New release                  | Project members     | Custom notification          |
 
 ### Issue / Epics / Merge request events
 
@@ -150,7 +151,7 @@ Notification emails include headers that provide extra content about the notific
 | X-GitLab-Pipeline-Id        | Only in pipeline emails, the ID of the pipeline the notification is for |
 | X-GitLab-Reply-Key          | A unique token to support reply by email                                |
 | X-GitLab-NotificationReason | The reason for being notified. "mentioned", "assigned", etc             |
-| List-Id                     | The path of the project in a RFC 2919 mailing list identifier useful for email organization, for example, with GMail filters |
+| List-Id                     | The path of the project in a RFC 2919 mailing list identifier useful for email organization, for example, with Gmail filters |
 
 #### X-GitLab-NotificationReason
 
diff --git a/doc/workflow/repository_mirroring.md b/doc/workflow/repository_mirroring.md
index cfa846a9c12..6d1a5913789 100644
--- a/doc/workflow/repository_mirroring.md
+++ b/doc/workflow/repository_mirroring.md
@@ -79,7 +79,7 @@ mirror.
 
 To set up a mirror from GitLab to GitHub, you need to follow these steps:
 
-1. Create a [GitHub personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/) with the `public_repo` box checked.
+1. Create a [GitHub personal access token](https://help.github.com/en/articles/creating-a-personal-access-token-for-the-command-line) with the `public_repo` box checked.
 1. Fill in the **Git repository URL** field using this format: `https://<your_github_username>@github.com/<your_github_group>/<your_github_project>.git`.
 1. Fill in **Password** field with your GitHub personal access token.
 1. Click the **Mirror repository** button.
@@ -197,10 +197,10 @@ Assuming you used the former, you now need to verify that the fingerprints are
 those you expect. GitLab.com and other code hosting sites publish their
 fingerprints in the open for you to check:
 
-- [AWS CodeCommit](http://docs.aws.amazon.com/codecommit/latest/userguide/regions.html#regions-fingerprints)
-- [Bitbucket](https://confluence.atlassian.com/bitbucket/use-the-ssh-protocol-with-bitbucket-cloud-221449711.html#UsetheSSHprotocolwithBitbucketCloud-KnownhostorBitbucket%27spublickeyfingerprints)
-- [GitHub](https://help.github.com/articles/github-s-ssh-key-fingerprints/)
-- [GitLab.com](https://about.gitlab.com/gitlab-com/settings/#ssh-host-keys-fingerprints)
+- [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/regions.html#regions-fingerprints)
+- [Bitbucket](https://confluence.atlassian.com/bitbucket/ssh-keys-935365775.html)
+- [GitHub](https://help.github.com/en/articles/githubs-ssh-key-fingerprints)
+- [GitLab.com](../user/gitlab_com/index.md#ssh-host-keys-fingerprints)
 - [Launchpad](https://help.launchpad.net/SSHFingerprints)
 - [Savannah](http://savannah.gnu.org/maintenance/SshAccess/)
 - [SourceForge](https://sourceforge.net/p/forge/documentation/SSH%20Key%20Fingerprints/)
@@ -398,7 +398,7 @@ CAUTION: **Warning:**
 Bidirectional mirroring should not be used as a permanent configuration. Refer to
 [Migrating from Perforce Helix](../user/project/import/perforce.md) for alternative migration approaches.
 
-[Git Fusion](https://www.perforce.com/video-tutorials/git-fusion-overview) provides a Git interface
+[Git Fusion](https://www.perforce.com/manuals/git-fusion/#Git-Fusion/section_avy_hyc_gl.html) provides a Git interface
 to [Perforce Helix](https://www.perforce.com/products) which can be used by GitLab to bidirectionally
 mirror projects with GitLab. This may be useful in some situations when migrating from Perforce Helix
 to GitLab where overlapping Perforce Helix workspaces cannot be migrated simultaneously to GitLab.
@@ -415,7 +415,7 @@ settings are recommended:
 - `unknown_git` user will be used as the commit author if the GitLab user does not exist in
   Perforce Helix.
 
-Read about [Git Fusion settings on Perforce.com](https://www.perforce.com/perforce/doc.current/manuals/git-fusion/Content/Git-Fusion/section_vss_bdw_w3.html#section_zdp_zz1_3l).
+Read about [Git Fusion settings on Perforce.com](https://www.perforce.com/manuals/git-fusion/Content/Git-Fusion/section_vss_bdw_w3.html#section_zdp_zz1_3l).
 
 ## Troubleshooting
 
@@ -423,4 +423,4 @@ Should an error occur during a push, GitLab will display an "Error" highlight fo
 
 ### 13:Received RST_STREAM with error code 2 with GitHub
 
-If you receive an "13:Received RST_STREAM with error code 2" while mirroring to a GitHub repository, your GitHub settings might be set to block pushes that expose your email address used in commits. Either set your email address on GitHub to be public, or disable the [Block command line pushes that expose my email](http://github.com/settings/emails) setting.
+If you receive an "13:Received RST_STREAM with error code 2" while mirroring to a GitHub repository, your GitHub settings might be set to block pushes that expose your email address used in commits. Either set your email address on GitHub to be public, or disable the [Block command line pushes that expose my email](https://github.com/settings/emails) setting.
diff --git a/doc/workflow/time_tracking.md b/doc/workflow/time_tracking.md
index 8c57c43b7d6..3d2e1de24da 100644
--- a/doc/workflow/time_tracking.md
+++ b/doc/workflow/time_tracking.md
@@ -11,7 +11,7 @@ requests within GitLab.
 
 ## Overview
 
-Time Tracking allows you:
+Time Tracking allows you to:
 
 - Record the time spent working on an issue or a merge request.
 - Add an estimate of the amount of time needed to complete an issue or a merge