Add latest changes from gitlab-org/gitlab@master

30 files changed, 83 insertions, 82 deletions

diff --git a/doc/administration/audit_events.md b/doc/administration/audit_events.md
index 2b068e64901..aa70890d3cd 100644
--- a/doc/administration/audit_events.md
+++ b/doc/administration/audit_events.md
@@ -134,7 +134,7 @@ on adding these events into GitLab:
 
 The current architecture of audit events is not prepared to receive a very high amount of records.
 It may make the user interface for your project or audit logs very busy, and the disk space consumed by the
-`audit_events` Postgres table will increase considerably. It's disabled by default
+`audit_events` PostgreSQL table will increase considerably. 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
diff --git a/doc/administration/auth/smartcard.md b/doc/administration/auth/smartcard.md
index 6aa79200f4a..8986a9866e7 100644
--- a/doc/administration/auth/smartcard.md
+++ b/doc/administration/auth/smartcard.md
@@ -25,10 +25,11 @@ GitLab supports two authentication methods:
 
 ### Authentication against a local database with X.509 certificates
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/726) in
-[GitLab Premium](https://about.gitlab.com/pricing/) 11.6 as an experimental
-feature. Smartcard authentication against local databases may change or be
-removed completely in future releases.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/726) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.6 as an experimental feature.
+
+CAUTION: **Caution:**
+Smartcard authentication against local databases may change or be removed completely in future
+releases.
 
 Smartcards with X.509 certificates can be used to authenticate with GitLab.
 
diff --git a/doc/administration/file_hooks.md b/doc/administration/file_hooks.md
index 5c8fb2f9d74..dbcc37b25e7 100644
--- a/doc/administration/file_hooks.md
+++ b/doc/administration/file_hooks.md
@@ -1,7 +1,7 @@
 # File hooks
 
-> Introduced in GitLab 10.6.
-> Until 12.8 the feature name was Plugins.
+> - Introduced in GitLab 10.6.
+> - Until GitLab 12.8, the feature name was Plugins.
 
 With custom file hooks, GitLab administrators can introduce custom integrations
 without modifying GitLab's source code.
diff --git a/doc/administration/geo/replication/datatypes.md b/doc/administration/geo/replication/datatypes.md
index f8c3076a38c..4c5fe2ebee7 100644
--- a/doc/administration/geo/replication/datatypes.md
+++ b/doc/administration/geo/replication/datatypes.md
@@ -21,9 +21,9 @@ verification methods:
 | Database | Application data in PostgreSQL                | Native                                      | Native               |
 | Database | Redis                                         | _N/A_ (*1*)                                 | _N/A_                |
 | Database | Elasticsearch                                 | Native                                      | Native               |
-| Database | Personal snippets                             | Postgres Replication                        | Postgres Replication |
-| Database | Project snippets                              | Postgres Replication                        | Postgres Replication |
-| Database | SSH public keys                               | Postgres Replication                        | Postgres Replication |
+| Database | Personal snippets                             | PostgreSQL Replication                        | PostgreSQL Replication |
+| Database | Project snippets                              | PostgreSQL Replication                        | PostgreSQL Replication |
+| Database | SSH public keys                               | PostgreSQL Replication                        | PostgreSQL Replication |
 | Git      | Project repository                            | Geo with Gitaly                             | Gitaly Checksum      |
 | Git      | Project wiki repository                       | Geo with Gitaly                             | Gitaly Checksum      |
 | Git      | Project designs repository                    | Geo with Gitaly                             | Gitaly Checksum      |
diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index 3a8219bdbc2..f1af83d0b39 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -242,7 +242,7 @@ sudo gitlab-rake gitlab:geo:check
    Checking Geo ... Finished
    ```
 
-   When performing a Postgres major version (9 > 10) update this is expected. Follow:
+   When performing a PostgreSQL major version (9 > 10) update this is expected. Follow:
 
    - [initiate-the-replication-process](database.md#step-3-initiate-the-replication-process)
    - [Geo database has an outdated FDW remote schema](troubleshooting.md#geo-database-has-an-outdated-fdw-remote-schema-error)
diff --git a/doc/administration/high_availability/database.md b/doc/administration/high_availability/database.md
index e3cd8766654..8278d667fea 100644
--- a/doc/administration/high_availability/database.md
+++ b/doc/administration/high_availability/database.md
@@ -146,7 +146,7 @@ Each service in the package comes with a set of [default ports](https://docs.git
 - Application servers connect to either PgBouncer directly via its [default port](https://docs.gitlab.com/omnibus/package-information/defaults.html#pgbouncer) or via a configured Internal Load Balancer (TCP) that serves multiple PgBouncers.
 - PgBouncer connects to the primary database servers [PostgreSQL default port](https://docs.gitlab.com/omnibus/package-information/defaults.html#postgresql)
 - Repmgr connects to the database servers [PostgreSQL default port](https://docs.gitlab.com/omnibus/package-information/defaults.html#postgresql)
-- Postgres secondaries connect to the primary database servers [PostgreSQL default port](https://docs.gitlab.com/omnibus/package-information/defaults.html#postgresql)
+- PostgreSQL secondaries connect to the primary database servers [PostgreSQL default port](https://docs.gitlab.com/omnibus/package-information/defaults.html#postgresql)
 - Consul servers and agents connect to each others [Consul default ports](https://docs.gitlab.com/omnibus/package-information/defaults.html#consul)
 
 #### Required information
@@ -899,7 +899,7 @@ after it has been restored to service.
   ```shell
   gitlab-ctl repmgr standby unregister --node=959789412
   ```
-  
+
 ##### Add a node as a standby server
 
   From the stnadby node, run:
@@ -916,24 +916,24 @@ after it has been restored to service.
   scratch by performing a `gitlab-ctl repmgr standby setup NEW_MASTER`.
 
 ##### Add a failed master back into the cluster as a standby node
-  
+
   Once `repmgrd` and PostgreSQL are runnning, the node will need to follow the new
   as a standby node.
-  
+
   ```
   gitlab-ctl repmgr standby follow NEW_MASTER
   ```
-  
+
   Once the node is following the new master as a standby, the node needs to be
   [unregistered from the cluster on the new master node](#remove-a-standby-from-the-cluster).
-  
+
   Once the old master node has been unregistered from the cluster, it will need
   to be setup as a new standby:
-  
+
   ```
   gitlab-ctl repmgr standby setup NEW_MASTER
   ```
-  
+
   Failure to unregister and readd the old master node can lead to subsequent failovers
   not working.
 
diff --git a/doc/administration/high_availability/nfs.md b/doc/administration/high_availability/nfs.md
index 8e018b7a6fe..39e998800bb 100644
--- a/doc/administration/high_availability/nfs.md
+++ b/doc/administration/high_availability/nfs.md
@@ -132,7 +132,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/creating-cluster.html#CREATING-CLUSTER-NFS):
+[PostgreSQL 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
diff --git a/doc/administration/high_availability/sidekiq.md b/doc/administration/high_availability/sidekiq.md
index 3d120ea8f09..ed273c3b113 100644
--- a/doc/administration/high_availability/sidekiq.md
+++ b/doc/administration/high_availability/sidekiq.md
@@ -55,7 +55,7 @@ you want using steps 1 and 2 from the GitLab downloads page.
    gitlab_rails['gitaly_token'] = 'YOUR_TOKEN'
    ```
 
-1. Setup Sidekiq's connection to Postgres:
+1. Setup Sidekiq's connection to PostgreSQL:
 
    ```ruby
    gitlab_rails['db_host'] = '10.10.1.30'
@@ -66,7 +66,7 @@ you want using steps 1 and 2 from the GitLab downloads page.
    gitlab_rails['auto_migrate'] = false
    ```
 
-   Remember to add the Sidekiq nodes to the Postgres whitelist:
+   Remember to add the Sidekiq nodes to the PostgreSQL whitelist:
 
    ```ruby
    postgresql['trust_auth_cidr_addresses'] = %w(127.0.0.1/32 10.10.1.30/32 10.10.1.31/32 10.10.1.32/32 10.10.1.33/32 10.10.1.38/32)
diff --git a/doc/administration/integration/terminal.md b/doc/administration/integration/terminal.md
index aa29e238fc1..0aa42e630b9 100644
--- a/doc/administration/integration/terminal.md
+++ b/doc/administration/integration/terminal.md
@@ -1,7 +1,9 @@
 # Web terminals
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7690)
-in GitLab 8.15. Only project maintainers and owners can access web terminals.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7690) in GitLab 8.15.
+
+NOTE: **Note:**
+Only project maintainers and owners can access web terminals.
 
 With the introduction of the [Kubernetes integration](../../user/project/clusters/index.md),
 GitLab gained the ability to store and use credentials for a Kubernetes cluster.
@@ -92,8 +94,7 @@ they will receive a `Connection failed` message.
 
 ## Limiting WebSocket connection time
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8413)
-in GitLab 8.17.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8413) in GitLab 8.17.
 
 Terminal sessions use long-lived connections; by default, these may last
 forever. You can configure a maximum session time in the Admin Area of your
diff --git a/doc/administration/logs.md b/doc/administration/logs.md
index 222d79ddc35..01774f8d320 100644
--- a/doc/administration/logs.md
+++ b/doc/administration/logs.md
@@ -13,7 +13,7 @@ This guide talks about how to read and use these system log files.
 This file lives in `/var/log/gitlab/gitlab-rails/production_json.log` for
 Omnibus GitLab packages or in `/home/git/gitlab/log/production_json.log` for
 installations from source. When GitLab is running in an environment
-other than production, the corresponding logfile is shown here.
+other than production, the corresponding log file is shown here.
 
 It contains a structured log for Rails controller requests received from
 GitLab, thanks to [Lograge](https://github.com/roidrage/lograge/). Note that
@@ -105,7 +105,7 @@ NOTE: **Note:** Starting with GitLab 12.5, if an error occurs, an
 This file lives in `/var/log/gitlab/gitlab-rails/production.log` for
 Omnibus GitLab packages or in `/home/git/gitlab/log/production.log` for
 installations from source. (When GitLab is running in an environment
-other than production, the corresponding logfile is shown here.)
+other than production, the corresponding log file is shown here.)
 
 It contains information about all performed requests. You can see the
 URL and type of request, IP address, and what parts of code were
diff --git a/doc/administration/monitoring/performance/grafana_configuration.md b/doc/administration/monitoring/performance/grafana_configuration.md
index 097c66f92ba..3b7cd8950ec 100644
--- a/doc/administration/monitoring/performance/grafana_configuration.md
+++ b/doc/administration/monitoring/performance/grafana_configuration.md
@@ -39,8 +39,8 @@ Test Connection to ensure the configuration is correct.
 - **Name**: `InfluxDB`
 - **Default**: Checked
 - **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)
+- For the URL, use `https://localhost:8086`, or provide 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)
@@ -52,7 +52,7 @@ Test Connection to ensure the configuration is correct.
 
 If you intend to import the GitLab provided Grafana dashboards, you will need to
 set up the right retention policies and continuous queries. The easiest way of
-doing this is by using the [influxdb-management](https://gitlab.com/gitlab-org/influxdb-management)
+doing this is by using the [InfluxDB Management](https://gitlab.com/gitlab-org/influxdb-management)
 repository.
 
 To use this repository you must first clone it:
@@ -74,7 +74,7 @@ and then editing the `.env` file to contain the correct InfluxDB settings. Once
 configured you can simply run `bundle exec rake` and the InfluxDB database will
 be configured for you.
 
-For more information see the [influxdb-management README](https://gitlab.com/gitlab-org/influxdb-management/blob/master/README.md).
+For more information see the [InfluxDB Management README](https://gitlab.com/gitlab-org/influxdb-management/blob/master/README.md).
 
 ## Import Dashboards
 
diff --git a/doc/administration/monitoring/performance/performance_bar.md b/doc/administration/monitoring/performance/performance_bar.md
index fe4c29fbb01..13474e2a183 100644
--- a/doc/administration/monitoring/performance/performance_bar.md
+++ b/doc/administration/monitoring/performance/performance_bar.md
@@ -33,7 +33,7 @@ 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
+For requests exceeding predefined 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:
 
diff --git a/doc/administration/monitoring/prometheus/gitlab_metrics.md b/doc/administration/monitoring/prometheus/gitlab_metrics.md
index 186b848f8bd..897f9592d84 100644
--- a/doc/administration/monitoring/prometheus/gitlab_metrics.md
+++ b/doc/administration/monitoring/prometheus/gitlab_metrics.md
@@ -201,7 +201,7 @@ When Puma is used instead of Unicorn, the following metrics are available:
 | `puma_running_workers`                         | Gauge   | 12.0  | Number of booted workers |
 | `puma_stale_workers`                           | Gauge   | 12.0  | Number of old workers |
 | `puma_running`                                 | Gauge   | 12.0  | Number of running threads |
-| `puma_queued_connections`                      | Gauge   | 12.0  | Number of connections in that worker's "todo" set waiting for a worker thread |
+| `puma_queued_connections`                      | Gauge   | 12.0  | Number of connections in that worker's "to do" set waiting for a worker thread |
 | `puma_active_connections`                      | Gauge   | 12.0  | Number of threads processing a request |
 | `puma_pool_capacity`                           | Gauge   | 12.0  | Number of requests the worker is capable of taking right now |
 | `puma_max_threads`                             | Gauge   | 12.0  | Maximum number of worker threads |
diff --git a/doc/administration/monitoring/prometheus/index.md b/doc/administration/monitoring/prometheus/index.md
index d29eb266431..da368327c5e 100644
--- a/doc/administration/monitoring/prometheus/index.md
+++ b/doc/administration/monitoring/prometheus/index.md
@@ -268,42 +268,42 @@ export Prometheus metrics.
 The node exporter allows you to measure various machine resources, such as
 memory, disk, and CPU utilization.
 
-[➔ Read more about the node exporter.](node_exporter.md)
+[Read more about the node exporter](node_exporter.md).
 
 ### Redis exporter
 
 The Redis exporter allows you to measure various Redis metrics.
 
-[➔ Read more about the Redis exporter.](redis_exporter.md)
+[Read more about the Redis exporter](redis_exporter.md).
 
-### Postgres exporter
+### PostgreSQL exporter
 
-The Postgres exporter allows you to measure various PostgreSQL metrics.
+The PostgreSQL exporter allows you to measure various PostgreSQL metrics.
 
-[➔ Read more about the Postgres exporter.](postgres_exporter.md)
+[Read more about the PostgreSQL exporter](postgres_exporter.md).
 
 ### PgBouncer exporter
 
 The PgBouncer exporter allows you to measure various PgBouncer metrics.
 
-[➔ Read more about the PgBouncer exporter.](pgbouncer_exporter.md)
+[Read more about the PgBouncer exporter](pgbouncer_exporter.md).
 
 ### Registry exporter
 
 The Registry exporter allows you to measure various Registry metrics.
 
-[➔ Read more about the Registry exporter.](registry_exporter.md)
+[Read more about the Registry exporter](registry_exporter.md).
 
 ### GitLab exporter
 
 The GitLab exporter allows you to measure various GitLab metrics, pulled from Redis and the database.
 
-[➔ Read more about the GitLab exporter.](gitlab_exporter.md)
+[Read more about the GitLab exporter](gitlab_exporter.md).
 
 ## Configuring Prometheus to monitor Kubernetes
 
-> Introduced in GitLab 9.0.
-> Pod monitoring introduced in GitLab 9.4.
+> - 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/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.
 
diff --git a/doc/administration/monitoring/prometheus/pgbouncer_exporter.md b/doc/administration/monitoring/prometheus/pgbouncer_exporter.md
index 3f81f980df3..ba7fc74f269 100644
--- a/doc/administration/monitoring/prometheus/pgbouncer_exporter.md
+++ b/doc/administration/monitoring/prometheus/pgbouncer_exporter.md
@@ -22,8 +22,8 @@ To enable the PgBouncer exporter:
 Prometheus will now automatically begin collecting performance data from
 the PgBouncer exporter exposed under `localhost:9188`.
 
-The PgBouncer exporter will also be enabled by default if the [pgbouncer_role][postgres roles]
-is enabled.
+The PgBouncer exporter will also be enabled by default if the [`pgbouncer_role`][postgres roles]
+role is enabled.
 
 [← Back to the main Prometheus page](index.md)
 
diff --git a/doc/administration/operations/fast_ssh_key_lookup.md b/doc/administration/operations/fast_ssh_key_lookup.md
index 0ee8f26b97c..8e0e60e64b0 100644
--- a/doc/administration/operations/fast_ssh_key_lookup.md
+++ b/doc/administration/operations/fast_ssh_key_lookup.md
@@ -1,16 +1,13 @@
 # Fast lookup of authorized SSH keys in the database
 
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1631) in [GitLab Starter](https://about.gitlab.com/pricing/) 9.3.
+> - [Available in](https://gitlab.com/gitlab-org/gitlab/issues/3953) GitLab Community Edition 10.4.
+
 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,
 but are not a drop-in replacement.
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1631) in
-> [GitLab Starter](https://about.gitlab.com/pricing/) 9.3.
->
-> [Available in](https://gitlab.com/gitlab-org/gitlab/issues/3953) GitLab
-> Community Edition 10.4.
-
 Regular SSH operations become slow as the number of users grows because OpenSSH
 searches for a key to authorize a user via a linear search. In the worst case,
 such as when the user is not authorized to access GitLab, OpenSSH will scan the
@@ -101,7 +98,7 @@ This is a brief overview. Please refer to the above instructions for more contex
 1. [Rebuild the `authorized_keys` file](../raketasks/maintenance.md#rebuild-authorized_keys-file)
 1. Enable writes to the `authorized_keys` file in Application Settings
 1. Remove the `AuthorizedKeysCommand` lines from `/etc/ssh/sshd_config` or from `/assets/sshd_config` if you are using Omnibus Docker.
-1. Reload sshd: `sudo service sshd reload`
+1. Reload `sshd`: `sudo service sshd reload`
 1. Remove the `/opt/gitlab-shell/authorized_keys` file
 
 ## Compiling a custom version of OpenSSH for CentOS 6
@@ -187,7 +184,7 @@ the database. The following instructions can be used to build OpenSSH 7.5:
 
    You should see a line that reads: "debug1: Remote protocol version 2.0, remote software version OpenSSH_7.5"
 
-   If not, you may need to restart sshd (e.g. `systemctl restart sshd.service`).
+   If not, you may need to restart `sshd` (e.g. `systemctl restart sshd.service`).
 
 1. *IMPORTANT!* Open a new SSH session to your server before exiting to make
    sure everything is working! If you need to downgrade, simple install the
diff --git a/doc/administration/operations/moving_repositories.md b/doc/administration/operations/moving_repositories.md
index 2b9ef02ec42..11cd3fa7b02 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 new server as `git@newserver`, you
 can pipe the data through SSH.
 
 ```shell
diff --git a/doc/administration/operations/ssh_certificates.md b/doc/administration/operations/ssh_certificates.md
index 5a9caa36cf8..eaf0e4ab284 100644
--- a/doc/administration/operations/ssh_certificates.md
+++ b/doc/administration/operations/ssh_certificates.md
@@ -33,7 +33,7 @@ uploading user SSH keys to GitLab entirely.
 
 How to fully set up SSH certificates is outside the scope of this
 document. See [OpenSSH's
-PROTOCOL.certkeys](https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.certkeys?annotate=HEAD)
+`PROTOCOL.certkeys`](https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.certkeys?annotate=HEAD)
 for how it works, and e.g. [RedHat's documentation about
 it](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-using_openssh_certificate_authentication).
 
diff --git a/doc/administration/packages/index.md b/doc/administration/packages/index.md
index 40867fc15b6..f33c215fdb8 100644
--- a/doc/administration/packages/index.md
+++ b/doc/administration/packages/index.md
@@ -57,7 +57,7 @@ local location or even use object storage.
 
 The packages for Omnibus GitLab installations are stored under
 `/var/opt/gitlab/gitlab-rails/shared/packages/` and for source
-installations under `shared/packages/` (relative to the Git homedir).
+installations under `shared/packages/` (relative to the Git home directory).
 To change the local storage path:
 
 **Omnibus GitLab installations**
diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md
index ce7d2fa3e73..ad0a828afa0 100644
--- a/doc/administration/pages/index.md
+++ b/doc/administration/pages/index.md
@@ -38,7 +38,7 @@ which you can set it up:
    the Pages daemon is installed, so you will have to share it via network.
 - Run the Pages daemon in the same server as GitLab, listening on the same IP
    but on different ports. In that case, you will have to proxy the traffic with
-   a loadbalancer. If you choose that route note that you should use TCP load
+   a load balancer. If you choose that route note that you should use TCP load
    balancing for HTTPS. If you use TLS-termination (HTTPS-load balancing) the
    pages will not be able to be served with user provided certificates. For
    HTTP it's OK to use HTTP or TCP load balancing.
@@ -256,7 +256,7 @@ GitLab supports [custom domain verification](../../user/project/pages/custom_dom
 When adding a custom domain, users will be required to prove they own it by
 adding a GitLab-controlled verification code to the DNS records for that domain.
 
-If your userbase is private or otherwise trusted, you can disable the
+If your user base is private or otherwise trusted, you can disable the
 verification requirement. Navigate to **Admin Area > Settings > Preferences** and
 uncheck **Require users to prove ownership of custom domains** in the **Pages** section.
 This setting is enabled by default.
@@ -358,7 +358,7 @@ For Omnibus, normally this would be fixed by [installing a custom CA in GitLab O
 but a [bug](https://gitlab.com/gitlab-org/gitlab/issues/25411) is currently preventing
 that method from working. Use the following workaround:
 
-1. Append your GitLab server TLS/SSL certficate to `/opt/gitlab/embedded/ssl/certs/cacert.pem` where `gitlab-domain-example.com` is your GitLab application URL
+1. Append your GitLab server TLS/SSL certificate to `/opt/gitlab/embedded/ssl/certs/cacert.pem` where `gitlab-domain-example.com` is your GitLab application URL
 
    ```shell
    printf "\ngitlab-domain-example.com\n===========================\n" | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem
@@ -582,7 +582,7 @@ but commented out to help encourage others to add to it in the future. -->
 
 ### `open /etc/ssl/ca-bundle.pem: permission denied`
 
-GitLab Pages runs inside a `chroot` jail, usually in a uniquely numbered directory like
+GitLab Pages runs inside a chroot jail, usually in a uniquely numbered directory like
 `/tmp/gitlab-pages-*`.
 
 Within the jail, a bundle of trusted certificates is
@@ -592,7 +592,7 @@ from `/opt/gitlab/embedded/ssl/certs/cacert.pem`
 as part of starting up Pages.
 
 If the permissions on the source file are incorrect (they should be `0644`) then
-the file inside the `chroot` jail will also be wrong.
+the file inside the chroot jail will also be wrong.
 
 Pages will log errors in `/var/log/gitlab/gitlab-pages/current` like:
 
@@ -601,7 +601,7 @@ x509: failed to load system roots and no roots provided
 open /etc/ssl/ca-bundle.pem: permission denied
 ```
 
-The use of a `chroot` jail makes this error misleading, as it is not
+The use of a chroot jail makes this error misleading, as it is not
 referring to `/etc/ssl` on the root filesystem.
 
 The fix is to correct the source file permissions and restart Pages:
diff --git a/doc/administration/pages/source.md b/doc/administration/pages/source.md
index 3e5a82030a2..87f0afeca12 100644
--- a/doc/administration/pages/source.md
+++ b/doc/administration/pages/source.md
@@ -35,7 +35,7 @@ which you can set it up:
    the Pages daemon is installed, so you will have to share it via network.
 1. Run the Pages daemon in the same server as GitLab, listening on the same IP
    but on different ports. In that case, you will have to proxy the traffic with
-   a loadbalancer. If you choose that route note that you should use TCP load
+   a load balancer. If you choose that route note that you should use TCP load
    balancing for HTTPS. If you use TLS-termination (HTTPS-load balancing) the
    pages will not be able to be served with user provided certificates. For
    HTTP it's OK to use HTTP or TCP load balancing.
@@ -51,7 +51,7 @@ Before proceeding with the Pages configuration, make sure that:
    this document we assume that to be `example.io`.
 1. You have configured a **wildcard DNS record** for that domain.
 1. You have installed the `zip` and `unzip` packages in the same server that
-   GitLab is installed since they are needed to compress/uncompress the
+   GitLab is installed since they are needed to compress and decompress the
    Pages artifacts.
 1. (Optional) You have a **wildcard certificate** for the Pages domain if you
    decide to serve Pages (`*.example.io`) under HTTPS.
@@ -388,7 +388,7 @@ Each request to view a resource in a private site is authenticated by Pages
 using that token. For each request it receives, it makes a request to the GitLab
 API to check that the user is authorized to read that site.
 
-From [GitLab 12.8](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/3689) onwards,
+From [GitLab 12.8](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/3689) onward,
 Access Control parameters for Pages are set in a configuration file, which
 by convention is named `gitlab-pages-config`. The configuration file is passed to
 pages using the `-config flag` or CONFIG environment variable.
diff --git a/doc/administration/raketasks/check.md b/doc/administration/raketasks/check.md
index 6f9a7f4293d..abf00a5010a 100644
--- a/doc/administration/raketasks/check.md
+++ b/doc/administration/raketasks/check.md
@@ -129,7 +129,7 @@ Done!
 
 ## LDAP Check
 
-The LDAP check Rake task will test the bind_dn and password credentials
+The LDAP check Rake task will test the bind DN and password credentials
 (if configured) and will list a sample of LDAP users. This task is also
 executed as part of the `gitlab:check` task, but can run independently.
 See [LDAP Rake Tasks - LDAP Check](ldap.md#check) for details.
diff --git a/doc/administration/reply_by_email_postfix_setup.md b/doc/administration/reply_by_email_postfix_setup.md
index c6da88a0eec..8a24514aec2 100644
--- a/doc/administration/reply_by_email_postfix_setup.md
+++ b/doc/administration/reply_by_email_postfix_setup.md
@@ -184,13 +184,13 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
    imapd start
    ```
 
-1. The courier-authdaemon isn't started after installation. Without it, imap authentication will fail:
+1. The `courier-authdaemon` isn't started after installation. Without it, IMAP authentication will fail:
 
    ```shell
    sudo service courier-authdaemon start
    ```
 
-   You can also configure courier-authdaemon to start on boot:
+   You can also configure `courier-authdaemon` to start on boot:
 
    ```shell
    sudo systemctl enable courier-authdaemon
diff --git a/doc/administration/repository_checks.md b/doc/administration/repository_checks.md
index a698138c2ea..a647bc82660 100644
--- a/doc/administration/repository_checks.md
+++ b/doc/administration/repository_checks.md
@@ -1,7 +1,6 @@
 # Repository checks
 
-> [Introduced][ce-3232] in GitLab 8.7. It is OFF by default because it still
-causes too many false alarms.
+> [Introduced][ce-3232] in GitLab 8.7.
 
 Git has a built-in mechanism, [`git fsck`][git-fsck], to verify the
 integrity of all data committed to a repository. GitLab administrators
@@ -11,6 +10,9 @@ before the check result is visible on the project admin page. If the
 checks failed you can see their output on the admin log page under
 'repocheck.log'.
 
+NOTE: **Note:**
+It is OFF by default because it still causes too many false alarms.
+
 ## Periodic checks
 
 When enabled, GitLab periodically runs a repository check on all project
diff --git a/doc/administration/restart_gitlab.md b/doc/administration/restart_gitlab.md
index 176ff5c1b1b..907d7bb307a 100644
--- a/doc/administration/restart_gitlab.md
+++ b/doc/administration/restart_gitlab.md
@@ -37,7 +37,7 @@ sudo gitlab-ctl restart
 
 The output should be similar to this:
 
-```
+```plaintext
 ok: run: gitlab-workhorse: (pid 11291) 1s
 ok: run: logrotate: (pid 11299) 0s
 ok: run: mailroom: (pid 11306) 0s
@@ -103,13 +103,13 @@ depend on those files.
 If you have followed the official installation guide to [install GitLab from
 source][install], run the following command to restart GitLab:
 
-```
+```shell
 sudo service gitlab restart
 ```
 
 The output should be similar to this:
 
-```
+```plaintext
 Shutting down GitLab Unicorn
 Shutting down GitLab Sidekiq
 Shutting down GitLab Workhorse
diff --git a/doc/administration/troubleshooting/debug.md b/doc/administration/troubleshooting/debug.md
index 34d42b8b5b8..78aa10489ce 100644
--- a/doc/administration/troubleshooting/debug.md
+++ b/doc/administration/troubleshooting/debug.md
@@ -118,7 +118,7 @@ downtime. Otherwise skip to the next section.
    ```
 
 1. This forces the process to generate a Ruby backtrace. Check
-   `/var/log/gitlab/unicorn/unicorn_stderr.log` for the backtace. For example, you may see:
+   `/var/log/gitlab/unicorn/unicorn_stderr.log` for the backtrace. For example, you may see:
 
    ```plaintext
    from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:33:in `block in start'
diff --git a/doc/administration/troubleshooting/diagnostics_tools.md b/doc/administration/troubleshooting/diagnostics_tools.md
index ab3b25f0e97..97b367dc353 100644
--- a/doc/administration/troubleshooting/diagnostics_tools.md
+++ b/doc/administration/troubleshooting/diagnostics_tools.md
@@ -19,7 +19,7 @@ running on.
 ## strace-parser
 
 [strace-parser](https://gitlab.com/wchandler/strace-parser) is a small tool to analyze
-and summarize raw strace data.
+and summarize raw `strace` data.
 
 ## Pritaly
 
diff --git a/doc/administration/troubleshooting/elasticsearch.md b/doc/administration/troubleshooting/elasticsearch.md
index 0fdd5314a9d..c864fc7b2b6 100644
--- a/doc/administration/troubleshooting/elasticsearch.md
+++ b/doc/administration/troubleshooting/elasticsearch.md
@@ -8,7 +8,7 @@ Troubleshooting Elasticsearch requires:
 ## Common terminology
 
 - **Lucene**: A full-text search library written in Java.
-- **Near Realtime (NRT)**: Refers to the slight latency from the time to index a
+- **Near real time (NRT)**: Refers to the slight latency from the time to index a
   document to the time when it becomes searchable.
 - **Cluster**: A collection of one or more nodes that work together to hold all
   the data, providing indexing and search capabilities.
@@ -271,7 +271,7 @@ Generally speaking, ensure:
 - 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:
 
diff --git a/doc/administration/troubleshooting/kubernetes_cheat_sheet.md b/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
index ec59705ca99..8b06d6ff530 100644
--- a/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
+++ b/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
@@ -162,7 +162,7 @@ and they will assist you with any issues you are having.
   kubectl get secret <secret-name> -ojsonpath={.data.password} | base64 --decode ; echo
   ```
 
-- How to connect to a GitLab Postgres database:
+- How to connect to a GitLab PostgreSQL database:
 
   ```shell
   kubectl exec -it <task-runner-pod-name> -- /srv/gitlab/bin/rails dbconsole -p
diff --git a/doc/administration/troubleshooting/sidekiq.md b/doc/administration/troubleshooting/sidekiq.md
index 73598bb9441..172e80bee7d 100644
--- a/doc/administration/troubleshooting/sidekiq.md
+++ b/doc/administration/troubleshooting/sidekiq.md
@@ -25,7 +25,7 @@ the `SIDEKIQ_LOG_ARGUMENTS` [environment variable](https://docs.gitlab.com/omnib
 
 Example:
 
-```
+```ruby
 gitlab_rails['env'] = {"SIDEKIQ_LOG_ARGUMENTS" => "1"}
 ```
 
@@ -43,7 +43,7 @@ single argument containing the string `"..."`.
 Send the Sidekiq process ID the `TTIN` signal and it will output thread
 backtraces in the log file.
 
-```
+```shell
 kill -TTIN <sidekiq_pid>
 ```
 
@@ -95,7 +95,7 @@ sudo perf record -p <sidekiq_pid>
 Let this run for 30-60 seconds and then press Ctrl-C. Then view the perf report:
 
 ```shell
-sudo perf report
+$ sudo perf report
 
 # Sample output
 Samples: 348K of event 'cycles', Event count (approx.): 280908431073