Fix identified spelling errors

As part of the spelling test being developed in another issue,
fix some of the identified spelling issues.

doc/administration/geo/disaster_recovery/background_verification.md

@@ -17,7 +17,7 @@ You can restore it from backup or remove it from the **primary** node to resolve
 If verification succeeds on the **primary** node but fails on the **secondary** node,
 this indicates that the object was corrupted during the replication process.
 Geo actively try to correct verification failures marking the repository to
-be resynced with a backoff period. If you want to reset the verification for
+be resynced with a back-off period. If you want to reset the verification for
 these failures, so you should follow [these instructions][reset-verification].
 
 If verification is lagging significantly behind replication, consider giving
@@ -114,9 +114,9 @@ Feature.enable('geo_repository_reverification')
 ## Reset verification for projects where verification has failed
 
 Geo actively try to correct verification failures marking the repository to
-be resynced with a backoff period. If you want to reset them manually, this
+be resynced with a back-off period. If you want to reset them manually, this
 rake task marks projects where verification has failed or the checksum mismatch
-to be resynced without the backoff period:
+to be resynced without the back-off period:
 
 For repositories:
 

doc/administration/geo/disaster_recovery/planned_failover.md

@@ -36,7 +36,7 @@ Repository-centric strategies for using `rsync` effectively can be found in the
 be adapted for use with any other file-based data, such as GitLab Pages (to
 be found in `/var/opt/gitlab/gitlab-rails/shared/pages` if using Omnibus).
 
-## Pre-flight checks
+## Preflight checks
 
 Follow these steps before scheduling a planned failover to ensure the process
 will go smoothly.

doc/administration/geo/replication/configuration.md

@@ -107,7 +107,7 @@ keys must be manually replicated to the **secondary** node.
    scp root@<primary_node_fqdn>:/etc/ssh/ssh_host_*_key* /etc/ssh
    ```
 
-   If you only have access through a user with **sudo** privileges:
+   If you only have access through a user with `sudo` privileges:
 
    ```shell
    # Run this from your primary node:
@@ -153,7 +153,7 @@ keys must be manually replicated to the **secondary** node.
    NOTE: **Note:**
    The output for private keys and public keys command should generate the same fingerprint.
 
-1. Restart sshd on your **secondary** node:
+1. Restart `sshd` on your **secondary** node:
 
    ```shell
    # Debian or Ubuntu installations

doc/administration/geo/replication/database.md

@@ -469,7 +469,7 @@ work:
 
 1. On the **primary** Geo database, enter the PostgreSQL on the console as an
    admin user. If you are using an Omnibus-managed database, log onto the **primary**
-   node that is running the PostgreSQL database (the default Omnibus database name is gitlabhq_production):
+   node that is running the PostgreSQL database (the default Omnibus database name is `gitlabhq_production`):
 
    ```shell
     sudo \

doc/administration/geo/replication/troubleshooting.md

@@ -290,7 +290,7 @@ sudo gitlab-ctl \
 This will give the initial replication up to six hours to complete, rather than
 the default thirty minutes. Adjust as required for your installation.
 
-### Message: "PANIC: could not write to file 'pg_xlog/xlogtemp.123': No space left on device"
+### Message: "PANIC: could not write to file `pg_xlog/xlogtemp.123`: No space left on device"
 
 Determine if you have any unused replication slots in the **primary** database. This can cause large amounts of
 log data to build up in `pg_xlog`. Removing the unused slots can reduce the amount of space used in the `pg_xlog`.

doc/administration/gitaly/reference.md

@@ -233,7 +233,7 @@ The following values configure logging in Gitaly under the `[logging]` section.
 | `sentry_environment` | string | no | [Sentry Environment](https://docs.sentry.io/enriching-error-data/environments/) for exception monitoring. |
 | `ruby_sentry_dsn` | string | no | Sentry DSN for `gitaly-ruby` exception monitoring. |
 
-While the main Gitaly application logs go to stdout, there are some extra log
+While the main Gitaly application logs go to `stdout`, there are some extra log
 files that go to a configured directory, like the GitLab Shell logs.
 GitLab Shell does not support `panic` or `trace` level logs. `panic` will fall
 back to `error`, while `trace` will fall back to `debug`. Any other invalid log

doc/administration/high_availability/database.md

@@ -163,7 +163,7 @@ Similarly, PostgreSQL access is controlled based on the network source.
 This is why you will need:
 
 - IP address of each nodes network interface. This can be set to `0.0.0.0` to
-  listen on all interfaces. It cannot be set to the loopack address `127.0.0.1`.
+  listen on all interfaces. It cannot be set to the loopback address `127.0.0.1`.
 - Network Address. This can be in subnet (i.e. `192.168.0.0/255.255.255.0`)
   or CIDR (i.e. `192.168.0.0/24`) form.
 
@@ -383,7 +383,7 @@ Select one node as a primary node.
    * master  | HOSTNAME |          | host=HOSTNAME user=gitlab_repmgr dbname=gitlab_repmgr
    ```
 
-1. Note down the hostname/ip in the connection string: `host=HOSTNAME`. We will
+1. Note down the hostname or IP address in the connection string: `host=HOSTNAME`. We will
    refer to the hostname in the next section as `MASTER_NODE_NAME`. If the value
    is not an IP address, it will need to be a resolvable name (via DNS or
    `/etc/hosts`)
@@ -535,7 +535,7 @@ Here is a list and description of each machine and the assigned IP:
 - `10.6.0.33`: PostgreSQL secondary
 - `10.6.0.41`: GitLab application
 
-All passwords are set to `toomanysecrets`, please do not use this password or derived hashes and the external_url for GitLab is `http://gitlab.example.com`.
+All passwords are set to `toomanysecrets`, please do not use this password or derived hashes and the `external_url` for GitLab is `http://gitlab.example.com`.
 
 Please note that after the initial configuration, if a failover occurs, the PostgresSQL master will change to one of the available secondaries until it is failed back.
 
@@ -739,7 +739,7 @@ Here is a list and description of each machine and the assigned IP:
 
 All passwords are set to `toomanysecrets`, please do not use this password or derived hashes.
 
-The external_url for GitLab is `http://gitlab.example.com`
+The `external_url` for GitLab is `http://gitlab.example.com`
 
 Please note that after the initial configuration, if a failover occurs, the PostgresSQL master will change to one of the available secondaries until it is failed back.
 
@@ -944,7 +944,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/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

doc/administration/high_availability/nfs.md

@@ -149,7 +149,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 directories within a mount, that allows automatic
 restore of backups without manually moving existing data.
 
 ```plaintext

doc/administration/high_availability/nfs_host_client_setup.md

@@ -25,7 +25,7 @@ Using EFS may negatively impact performance. Please review the [relevant documen
 
 ### Step 1 - Install NFS Server on Host
 
-Installing the nfs-kernel-server package allows you to share directories with the clients running the GitLab application.
+Installing the `nfs-kernel-server` package allows you to share directories with the clients running the GitLab application.
 
 ```shell
 apt-get update
@@ -61,7 +61,7 @@ inside your HA environment to the NFS server configured above.
 
 ### Step 1 - Install NFS Common on Client
 
-The nfs-common provides NFS functionality without installing server components which
+The `nfs-common` provides NFS functionality without installing server components which
 we don't need running on the application nodes.
 
 ```shell
@@ -126,7 +126,7 @@ by a firewall, then you will need to reconfigure that firewall to allow NFS comm
 
 [This guide from TDLP](http://tldp.org/HOWTO/NFS-HOWTO/security.html#FIREWALLS)
 covers the basics of using NFS in a firewalled environment. Additionally, we encourage you to
-search for and review the specific documentation for your OS/distro and your firewall software.
+search for and review the specific documentation for your operating system or distribution and your firewall software.
 
 Example for Ubuntu:
 

doc/administration/high_availability/redis.md

@@ -14,7 +14,7 @@ The following are the requirements for providing your own Redis instance:
   [Merge Trains](../../ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md).
 - Standalone Redis or Redis high availability with Sentinel are supported. Redis
   Cluster is not supported.
-- Managed Redis from cloud providers such as AWS Elasticache will work. If these
+- Managed Redis from cloud providers such as AWS ElastiCache will work. If these
   services support high availability, be sure it is not the Redis Cluster type.
 
 Note the Redis node's IP address or hostname, port, and password (if required).
@@ -862,7 +862,7 @@ mailroom['enable'] = false
 redis['master'] = false
 ```
 
-You can find the relevant attributes defined in [gitlab_rails.rb][omnifile].
+You can find the relevant attributes defined in [`gitlab_rails.rb`][omnifile].
 
 ## Troubleshooting
 
@@ -936,7 +936,7 @@ and `redis['master_pasword']` as you defined for your sentinel node.
 
 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.
+a few extra configurations.
 
 ---
 

doc/administration/housekeeping.md

@@ -15,7 +15,7 @@ The housekeeping function runs `repack` or `gc` depending on the
 
 For example in the following scenario a `git repack -d` will be executed:
 
-- Project: pushes since gc counter (`pushes_since_gc`) = `10`
+- Project: pushes since GC counter (`pushes_since_gc`) = `10`
 - Git GC period = `200`
 - Full repack period = `50`
 
@@ -23,7 +23,7 @@ When the `pushes_since_gc` value is 50 a `repack -A -d --pack-kept-objects` will
 the `pushes_since_gc` value is 200 a `git gc` will be run.
 
 - `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)
+  such as compressing file revisions (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](https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-repack.html)) re-organize existing packs into a single, more efficient pack.

doc/administration/index.md

@@ -38,7 +38,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
   - [Installing GitLab HA on Amazon Web Services (AWS)](../install/aws/index.md): Set up GitLab High Availability on Amazon AWS.
 - [Geo](geo/replication/index.md): Replicate your GitLab instance to other geographic locations as a read-only fully operational version. **(PREMIUM ONLY)**
 - [Disaster Recovery](geo/disaster_recovery/index.md): Quickly fail-over to a different site with minimal effort in a disaster situation. **(PREMIUM ONLY)**
-- [Pivotal Tile](../install/pivotal/index.md): Deploy GitLab as a pre-configured appliance using Ops Manager (BOSH) for Pivotal Cloud Foundry. **(PREMIUM ONLY)**
+- [Pivotal Tile](../install/pivotal/index.md): Deploy GitLab as a preconfigured appliance using Ops Manager (BOSH) for Pivotal Cloud Foundry. **(PREMIUM ONLY)**
 - [Add License](../user/admin_area/license.md): Upload a license at install time to unlock features that are in paid tiers of GitLab. **(STARTER ONLY)**
 
 ### Configuring GitLab
@@ -86,7 +86,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 
 - [GitLab versions and maintenance policy](../policy/maintenance.md): Understand GitLab versions and releases (Major, Minor, Patch, Security), as well as update recommendations.
 - [Update GitLab](../update/README.md): Update guides to upgrade your installation to a new version.
-- [Downtimeless updates](../update/README.md#upgrading-without-downtime): Upgrade to a newer major, minor, or patch version of GitLab without taking your GitLab instance offline.
+- [Upgrading without downtime](../update/README.md#upgrading-without-downtime): Upgrade to a newer major, minor, or patch version of GitLab without taking your GitLab instance offline.
 - [Migrate your GitLab CI/CD data to another version of GitLab](../migrate_ci_to_ce/README.md): If you have an old GitLab installation (older than 8.0), follow this guide to migrate your existing GitLab CI/CD data to another version of GitLab.
 
 ### Upgrading or downgrading GitLab
@@ -227,6 +227,6 @@ who are aware of the risks.
   - [GitLab Developer Docs](../development/README.md)
   - [Repairing and recovering broken Git repositories](https://git.seveas.net/repairing-and-recovering-broken-git-repositories.html)
   - [Testing with OpenSSL](https://www.feistyduck.com/library/openssl-cookbook/online/ch-testing-with-openssl.html)
-  - [Strace zine](https://wizardzines.com/zines/strace/)
+  - [`Strace` zine](https://wizardzines.com/zines/strace/)
 - GitLab.com-specific resources:
   - [Group SAML/SCIM setup](troubleshooting/group_saml_scim.md)

doc/administration/integration/plantuml.md

@@ -149,9 +149,9 @@ our AsciiDoc snippets, wikis and repos using delimited blocks:
      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.
+   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.
 
-The above blocks will be converted to an HTML img tag with source pointing to the
+The above blocks will be converted to an HTML image tag with source pointing to the
 PlantUML instance. If the PlantUML server is correctly configured, this should
 render a nice diagram instead of the block:
 
@@ -172,7 +172,7 @@ Some parameters can be added to the AsciiDoc block definition:
 - *format*: Can be either `png` or `svg`. Note that `svg` is not supported by
   all browsers so use with care. The default is `png`.
 - *id*: A CSS id added to the diagram HTML tag.
-- *width*: Width attribute added to the img tag.
-- *height*: Height attribute added to the img tag.
+- *width*: Width attribute added to the image tag.
+- *height*: Height attribute added to the image tag.
 
 Markdown does not support any parameters and will always use PNG format.

doc/administration/lfs/lfs_administration.md

@@ -63,13 +63,13 @@ GitLab provides two different options for the uploading mechanism: "Direct uploa
 
 **Option 1. Direct upload**
 
-1. User pushes an lfs file to the GitLab instance
+1. User pushes an `lfs` file to the GitLab instance
 1. GitLab-workhorse uploads the file directly to the external object storage
 1. GitLab-workhorse notifies GitLab-rails that the upload process is complete
 
 **Option 2. Background upload**
 
-1. User pushes an lfs file to the GitLab instance
+1. User pushes an `lfs` file to the GitLab instance
 1. GitLab-rails stores the file in the local file storage
 1. GitLab-rails then uploads the file to the external object storage asynchronously
 
@@ -127,7 +127,7 @@ Here is a configuration example with Rackspace Cloud Files.
 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
+instantiating storage with a temp-url-key, ensure that you have set the key properly
 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.
@@ -261,7 +261,7 @@ See more information in [!19581](https://gitlab.com/gitlab-org/gitlab-foss/-/mer
 
 ## Known limitations
 
-- Support for removing unreferenced LFS objects was added in 8.14 onwards.
+- Support for removing unreferenced LFS objects was added in 8.14 onward.
 - LFS authentications via SSH was added with GitLab 8.12.
 - 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