Finish updating caps and backticks

Finish cleaning up improper capitalization and backticks
in various remaining docs.

doc/ci/examples/README.md

@@ -11,7 +11,7 @@ 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/).
 - Examples and [other resources](#other-resources) listed below.

doc/gitlab-basics/create-project.md

@@ -83,8 +83,8 @@ You can improve the existing built-in templates or contribute new ones in the
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/6860) in
 [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)

doc/install/aws/index.md

@@ -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
 
@@ -231,7 +231,7 @@ Now, it's time to create the database:
    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

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)
 
@@ -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**
@@ -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)_.
 
@@ -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.

doc/install/installation.md

@@ -27,12 +27,12 @@ following the
 
 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
 
@@ -588,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`
@@ -646,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
 
@@ -749,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
 
@@ -784,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:
@@ -858,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.
@@ -884,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
 
@@ -945,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
 
@@ -971,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

doc/install/openshift_and_gitlab/index.md

@@ -14,7 +14,7 @@ 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
@@ -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
@@ -44,8 +44,8 @@ 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
 
@@ -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
@@ -349,7 +349,7 @@ 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)

doc/install/requirements.md

@@ -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).
 

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

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:
 
@@ -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](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).
 
 ### When the secrets file is lost
 

doc/security/crime_vulnerability.md

@@ -56,7 +56,7 @@ 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
 

doc/topics/autodevops/index.md

@@ -122,7 +122,7 @@ 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.
     - Installing the Ingress [GitLab Managed App](../../user/clusters/applications.md#ingress).
@@ -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
 
@@ -529,7 +529,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 +572,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 +583,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):
@@ -860,27 +860,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) 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). |
 

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

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
@@ -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.
 

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

doc/update/upgrading_from_source.md

@@ -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,7 +268,7 @@ 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].

doc/user/application_security/sast/analyzers.md

@@ -15,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)

doc/user/application_security/sast/index.md

@@ -72,7 +72,7 @@ The following table shows which languages, package managers and frameworks are s
 | 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                         |

doc/user/clusters/applications.md

@@ -106,8 +106,7 @@ 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/blob/master/vendor/runner/values.yaml)
 file.
@@ -123,8 +122,7 @@ 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/blob/master/vendor/ingress/values.yaml)
 file.
@@ -139,7 +137,7 @@ to check requests against [OWASP's Core Rule Set](https://www.modsecurity.org/CR
 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
@@ -185,8 +183,7 @@ 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/blob/master/vendor/jupyter/values.yaml)
 file.
@@ -234,12 +231,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,8 +248,7 @@ 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/blob/master/vendor/prometheus/values.yaml)
 file.

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
 

doc/user/group/index.md

@@ -351,7 +351,7 @@ 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 and API access, Git actions via SSH are not restricted.
 To avoid accidental lock-out, admins and group owners are are able to access
 the group regardless of the IP restriction.
 

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).

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

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)
 
@@ -380,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.
@@ -548,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
 
@@ -565,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:
 

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,7 +48,7 @@ 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)
 for more information.

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)
 

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
 

doc/user/project/pages/custom_domains_ssl_tls_certification/index.md

@@ -68,9 +68,9 @@ Root domains (`example.com`) require:
 - 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 |
+| --------------------------------------------- | ---------- | --------------- |
+| `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
@@ -96,9 +96,9 @@ Subdomains (`subdomain.example.com`) require:
 - 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 |
+| ------------------------------------------------------- | ---------- | --------------------- |
+| `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`),
@@ -118,12 +118,12 @@ They require:
 - 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 |
+| ------------------------------------------------- | ---------- | ---------------------- |
+| `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).

doc/user/project/pages/custom_domains_ssl_tls_certification/ssl_tls_concepts.md

@@ -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.
 

doc/user/project/pages/getting_started_part_four.md

@@ -390,5 +390,5 @@ to understand how to go even further on your scripts.
   in parallel, or build a custom pipeline](https://about.gitlab.com/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.
+  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/2016/11/03/publish-code-coverage-report-with-gitlab-pages/).

doc/user/project/pipelines/settings.md

@@ -152,7 +152,7 @@ If **Public pipelines** is disabled:
 > [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