Merge branch 'docs-aqualls-spelling-again' into 'master'

And yet more spelling fixes

See merge request gitlab-org/gitlab!52390

doc/.vale/gitlab/spelling-exceptions.txt

@@ -10,6 +10,7 @@ Ansible
 Anthos
 approvers
 architected
+Arel
 Artifactory
 Asana
 Asciidoctor
@@ -63,7 +64,10 @@ bundler
 bundlers
 burndown
 burnup
+burstable
 cacheable
+callstack
+callstacks
 CentOS
 Certbot
 changeset
@@ -139,6 +143,7 @@ Ecto
 Elasticsearch
 enablement
 enqueued
+enqueues
 enum
 enums
 ETag
@@ -237,6 +242,8 @@ kaniko
 Karma
 Kerberos
 keyset
+keytab
+keytabs
 Kibana
 Kinesis
 Knative
@@ -311,6 +318,7 @@ namespaces
 namespacing
 namespacings
 Nanoc
+negatable
 Netlify
 Nokogiri
 npm
@@ -516,6 +524,7 @@ Sysbench
 syslog
 tanuki
 tcpdump
+templated
 Thanos
 throughputs
 Tiller
@@ -644,6 +653,7 @@ Wireshark
 Wordpress
 worktree
 worktrees
+Worldline
 Xcode
 Xeon
 YouTrack

doc/development/internal_api.md

@@ -26,7 +26,7 @@ file, and include the token Base64 encoded in a `secret_token` parameter
 or in the `Gitlab-Shared-Secret` header.
 
 NOTE:
-The internal API used by GitLab Pages, and GitLab Kubernetes Agent Server (kas) uses JSON Web Token (JWT)
+The internal API used by GitLab Pages, and GitLab Kubernetes Agent Server (`kas`) uses JSON Web Token (JWT)
 authentication, which is different from GitLab Shell.
 
 ## Git Authentication
@@ -378,7 +378,7 @@ Example response:
 > - This feature is not deployed on GitLab.com
 > - It's not recommended for production use.
 
-The following endpoints are used by the GitLab Kubernetes Agent Server (kas)
+The following endpoints are used by the GitLab Kubernetes Agent Server (`kas`)
 for various purposes.
 
 These endpoints are all authenticated using JWT. The JWT secret is stored in a file
@@ -390,9 +390,9 @@ The Kubernetes agent is under development and is not recommended for production
 
 ### Kubernetes agent information
 
-Called from GitLab Kubernetes Agent Server (kas) to retrieve agent
+Called from GitLab Kubernetes Agent Server (`kas`) to retrieve agent
 information for the given agent token. This returns the Gitaly connection
-information for the agent's project in order for kas to fetch and update
+information for the agent's project in order for `kas` to fetch and update
 the agent's configuration.
 
 ```plaintext
@@ -407,9 +407,9 @@ curl --request GET --header "Gitlab-Kas-Api-Request: <JWT token>" --header "Auth
 
 ### Kubernetes agent project information
 
-Called from GitLab Kubernetes Agent Server (kas) to retrieve project
+Called from GitLab Kubernetes Agent Server (`kas`) to retrieve project
 information for the given agent token. This returns the Gitaly
-connection for the requested project. GitLab kas uses this to configure
+connection for the requested project. GitLab `kas` uses this to configure
 the agent to fetch Kubernetes resources from the project repository to
 sync.
 
@@ -432,7 +432,7 @@ curl --request GET --header "Gitlab-Kas-Api-Request: <JWT token>" --header "Auth
 
 ### Kubernetes agent usage metrics
 
-Called from GitLab Kubernetes Agent Server (kas) to increase the usage
+Called from GitLab Kubernetes Agent Server (`kas`) to increase the usage
 metric counters.
 
 | Attribute | Type   | Required | Description |

doc/development/ordering_table_columns.md

@@ -63,17 +63,17 @@ bits platform and 8 bytes for a 64 bits platform.
 
 | Type             | Size                                 | Alignment needed |
 |:-----------------|:-------------------------------------|:-----------|
-| smallint         | 2 bytes                              | 1 word     |
-| integer          | 4 bytes                              | 1 word     |
-| bigint           | 8 bytes                              | 8 bytes    |
-| real             | 4 bytes                              | 1 word     |
-| double precision | 8 bytes                              | 8 bytes    |
-| boolean          | 1 byte                               | not needed |
-| text / string    | variable, 1 byte plus the data       | 1 word     |
-| bytea            | variable, 1 or 4 bytes plus the data | 1 word     |
-| timestamp        | 8 bytes                              | 8 bytes    |
-| timestamptz      | 8 bytes                              | 8 bytes    |
-| date             | 4 bytes                              | 1 word     |
+| `smallint`         | 2 bytes                              | 1 word     |
+| `integer`          | 4 bytes                              | 1 word     |
+| `bigint`           | 8 bytes                              | 8 bytes    |
+| `real`             | 4 bytes                              | 1 word     |
+| `double precision` | 8 bytes                              | 8 bytes    |
+| `boolean`          | 1 byte                               | not needed |
+| `text` / `string`    | variable, 1 byte plus the data       | 1 word     |
+| `bytea`            | variable, 1 or 4 bytes plus the data | 1 word     |
+| `timestamp`        | 8 bytes                              | 8 bytes    |
+| `timestamptz`      | 8 bytes                              | 8 bytes    |
+| `date`             | 4 bytes                              | 1 word     |
 
 A "variable" size means the actual size depends on the value being stored. If
 PostgreSQL determines this can be embedded directly into a row it may do so, but

doc/development/pipelines.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Pipelines for the GitLab project
 
-Pipelines for <https://gitlab.com/gitlab-org/gitlab> and <https://gitlab.com/gitlab-org/gitlab-foss> (as well as the
+Pipelines for [`gitlab-org/gitlab`](https://gitlab.com/gitlab-org/gitlab) and [`gitlab-org/gitlab-foss`](https://gitlab.com/gitlab-org/gitlab-foss) (as well as the
 `dev` instance's mirrors) are configured in the usual
 [`.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml)
 which itself includes files under
@@ -37,7 +37,7 @@ Pipeline creation is also affected by the following CI variables:
 No pipeline is created in any other cases (for example, when pushing a branch with no
 MR for it).
 
-The source of truth for these workflow rules is defined in <https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml>.
+The source of truth for these workflow rules is defined in [`.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml).
 
 ### Pipelines for Merge Requests
 
@@ -55,7 +55,7 @@ have a pipelines that include jobs from multiple types (e.g. a combination of do
 
 #### Docs-only MR pipeline
 
-Reference pipeline: <https://gitlab.com/gitlab-org/gitlab/pipelines/135236627>
+[Reference pipeline](https://gitlab.com/gitlab-org/gitlab/pipelines/135236627):
 
 ```mermaid
 graph LR
@@ -69,7 +69,7 @@ graph LR
 
 #### Code-only MR pipeline
 
-Reference pipeline: <https://gitlab.com/gitlab-org/gitlab/pipelines/136295694>
+[Reference pipeline](https://gitlab.com/gitlab-org/gitlab/pipelines/136295694)
 
 ```mermaid
 graph RL;
@@ -173,7 +173,7 @@ graph RL;
 
 #### Frontend-only MR pipeline
 
-Reference pipeline: <https://gitlab.com/gitlab-org/gitlab/pipelines/134661039>
+[Reference pipeline](https://gitlab.com/gitlab-org/gitlab/pipelines/134661039):
 
 ```mermaid
 graph RL;
@@ -304,7 +304,7 @@ graph RL;
 
 #### QA-only MR pipeline
 
-Reference pipeline: <https://gitlab.com/gitlab-org/gitlab/pipelines/134645109>
+[Reference pipeline](https://gitlab.com/gitlab-org/gitlab/pipelines/134645109):
 
 ```mermaid
 graph RL;
@@ -584,8 +584,8 @@ runner, or [you can incur network egress charges](https://cloud.google.com/stora
 
 The current stages are:
 
-- `sync`: This stage is used to synchronize changes from <https://gitlab.com/gitlab-org/gitlab> to
-  <https://gitlab.com/gitlab-org/gitlab-foss>.
+- `sync`: This stage is used to synchronize changes from [`gitlab-org/gitlab`](https://gitlab.com/gitlab-org/gitlab) to
+  [`gitlab-org/gitlab-foss`](https://gitlab.com/gitlab-org/gitlab-foss).
 - `prepare`: This stage includes jobs that prepare artifacts that are needed by
   jobs in subsequent stages.
 - `build-images`: This stage includes jobs that prepare Docker images
@@ -614,7 +614,9 @@ that is deployed in stage `review`.
 
 The default image is defined in [`.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml).
 
+<!-- vale gitlab.Spelling = NO -->
 It includes Ruby, Go, Git, Git LFS, Chrome, Node, Yarn, PostgreSQL, and Graphics Magick.
+<!-- vale gitlab.Spelling = YES -->
 
 The images used in our pipelines are configured in the
 [`gitlab-org/gitlab-build-images`](https://gitlab.com/gitlab-org/gitlab-build-images)
@@ -628,7 +630,7 @@ The current version of the build images can be found in the
 
 In addition to the [predefined variables](../ci/variables/predefined_variables.md),
 each pipeline includes default variables defined in
-<https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml>.
+[`.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml).
 
 ### Common job definitions
 
@@ -659,7 +661,7 @@ that are scoped to a single [configuration keyword](../ci/yaml/README.md#job-key
 We're using the [`rules` keyword](../ci/yaml/README.md#rules) extensively.
 
 All `rules` definitions are defined in
-<https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/rules.gitlab-ci.yml>,
+[`rules.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/rules.gitlab-ci.yml),
 then included in individual jobs via [`extends`](../ci/yaml/README.md#extends).
 
 The `rules` definitions are composed of `if:` conditions and `changes:` patterns,

doc/development/projections.md

@@ -27,7 +27,7 @@ You can find a basic list of projection options in
 - VSCode
   - [Alternate File](https://marketplace.visualstudio.com/items?itemName=will-wow.vscode-alternate-file)
   - [projectionist](https://github.com/jarsen/projectionist)
-  - [jumpto](https://github.com/gmdayley/jumpto)
+  - [`jumpto`](https://github.com/gmdayley/jumpto)
 - Atom
   - [projectionist-atom](https://atom.io/packages/projectionist-atom)
 - Command-line
@@ -35,6 +35,8 @@ You can find a basic list of projection options in
 
 ## History
 
+<!-- vale gitlab.Spelling = NO -->
 This started as a
 [plugin for vim by tpope](https://github.com/tpope/vim-projectionist)
 It has since become editor-agnostic and ported to most modern editors.
+<!-- vale gitlab.Spelling = YES -->
\ No newline at end of file

doc/development/pry_debugging.md

@@ -79,7 +79,7 @@ Similar to source browsing, is [Documentation browsing](https://github.com/pry/p
 
 ### Command history
 
-With **Ctrl+R** you can search your [command history](https://github.com/pry/pry/wiki/History).
+With <kbd>Control</kbd> + <kbd>R</kbd> you can search your [command history](https://github.com/pry/pry/wiki/History).
 
 ## Stepping
 

doc/development/python_guide/index.md

@@ -14,8 +14,8 @@ As of GitLab 11.10, we require Python 3.
 ## Installation
 
 There are several ways of installing Python on your system. To be able to use the same version we use in production,
-we suggest you use [pyenv](https://github.com/pyenv/pyenv). It works and behaves similarly to its counterpart in the
-Ruby world: [rbenv](https://github.com/rbenv/rbenv).
+we suggest you use [`pyenv`](https://github.com/pyenv/pyenv). It works and behaves similarly to its counterpart in the
+Ruby world: [`rbenv`](https://github.com/rbenv/rbenv).
 
 ### macOS
 
@@ -35,11 +35,11 @@ curl "https://pyenv.run" | bash
 
 Alternatively, you may find `pyenv` available as a system package via your distribution's package manager.
 
-You can read more about it in: <https://github.com/pyenv/pyenv-installer#prerequisites>.
+You can read more about it in [the `pyenv` prerequisites](https://github.com/pyenv/pyenv-installer#prerequisites).
 
 ### Shell integration
 
-Pyenv installation adds required changes to Bash. If you use a different shell,
+`Pyenv` installation adds required changes to Bash. If you use a different shell,
 check for any additional steps required for it.
 
 For Fish, you can install a plugin for [Fisher](https://github.com/jorgebucaran/fisher):

doc/development/reactive_caching.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # `ReactiveCaching`
 
-> This doc refers to <https://gitlab.com/gitlab-org/gitlab/blob/master/app/models/concerns/reactive_caching.rb>.
+> This doc refers to [`reactive_caching.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/app/models/concerns/reactive_caching.rb).
 
 The `ReactiveCaching` concern is used for fetching some data in the background and storing it
 in the Rails cache, keeping it up-to-date for as long as it is being requested. If the

doc/development/repository_mirroring.md

@@ -8,6 +8,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 ## Deep Dive
 
+<!-- vale gitlab.Spelling = NO -->
+
 In December 2018, Tiago Botelho hosted a Deep Dive (GitLab team members only: `https://gitlab.com/gitlab-org/create-stage/issues/1`)
 on the GitLab [Pull Repository Mirroring functionality](../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository)
 to share his domain specific knowledge with anyone who may work in this part of the
@@ -15,3 +17,5 @@ codebase in the future. You can find the [recording on YouTube](https://www.yout
 and the slides in [PDF](https://gitlab.com/gitlab-org/create-stage/uploads/8693404888a941fd851f8a8ecdec9675/Gitlab_Create_-_Pull_Mirroring_Deep_Dive.pdf).
 Everything covered in this deep dive was accurate as of GitLab 11.6, and while specific
 details may have changed since then, it should still serve as a good introduction.
+
+<!-- vale gitlab.Spelling = YES -->
\ No newline at end of file

doc/development/testing_guide/end_to_end/best_practices.md

@@ -10,7 +10,7 @@ This is a tailored extension of the Best Practices [found in the testing guide](
 
 ## Link a test to its test-case issue
 
-Every test should have a corresponding issue in the [Quality Testcases project](https://gitlab.com/gitlab-org/quality/testcases/).
+Every test should have a corresponding issue in the [Quality Test Cases project](https://gitlab.com/gitlab-org/quality/testcases/).
 It's recommended that you reuse the issue created to plan the test. If one does not already exist you
 can create the issue yourself. Alternatively, you can run the test in a pipeline that has reporting
 enabled and the test-case issue reporter will automatically create a new issue.
@@ -244,7 +244,7 @@ point of failure and so the screenshot would not be captured at the right moment
 
 All tests expect to be able to log in at the start of the test.
 
-For an example see: <https://gitlab.com/gitlab-org/gitlab/-/issues/34736>
+For an example see [issue #34736](https://gitlab.com/gitlab-org/gitlab/-/issues/34736).
 
 Ideally, actions performed in an `after(:context)` (or
 [`before(:context)`](#limit-the-use-of-the-ui-in-beforecontext-and-after-hooks))

doc/development/testing_guide/end_to_end/page_objects.md

@@ -145,7 +145,7 @@ for each element defined.
 
 In our case, `data-qa-selector="login_field"`, `data-qa-selector="password_field"` and `data-qa-selector="sign_in_button"`
 
-**app/views/my/view.html.haml**
+`app/views/my/view.html.haml`
 
 ```haml
 = f.text_field :login, class: "form-control top", autofocus: "autofocus", autocapitalize: "off", autocorrect: "off", required: true, title: "This field is required.", data: { qa_selector: 'login_field' }

doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md

@@ -408,15 +408,15 @@ Geo requires an EE license. To visit the Geo sites in your browser, you need a r
 
 Tests that are tagged with `:ldap_tls` and `:ldap_no_tls` meta are orchestrated tests where the sign-in happens via LDAP.
 
-These tests spin up a Docker container [(osixia/openldap)](https://hub.docker.com/r/osixia/openldap) running an instance of [OpenLDAP](https://www.openldap.org/).
-The container uses fixtures [checked into the GitLab-QA repo](https://gitlab.com/gitlab-org/gitlab-qa/-/tree/9ffb9ad3be847a9054967d792d6772a74220fb42/fixtures/ldap) to create
+These tests spin up a Docker container [(`osixia/openldap`)](https://hub.docker.com/r/osixia/openldap) running an instance of [OpenLDAP](https://www.openldap.org/).
+The container uses fixtures [checked into the GitLab-QA repository](https://gitlab.com/gitlab-org/gitlab-qa/-/tree/9ffb9ad3be847a9054967d792d6772a74220fb42/fixtures/ldap) to create
 base data such as users and groups including the admin group. The password for [all users](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/9ffb9ad3be847a9054967d792d6772a74220fb42/fixtures/ldap/2_add_users.ldif) including [the `tanuki` user](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/9ffb9ad3be847a9054967d792d6772a74220fb42/fixtures/ldap/tanuki.ldif) is `password`.
 
 A GitLab instance is also created in a Docker container based on our [General LDAP setup](../../../administration/auth/ldap/index.md#general-ldap-setup) documentation.
 
-Tests that are tagged `:ldap_tls` enable TLS on GitLab using the certificate [checked into the GitLab-QA repo](https://gitlab.com/gitlab-org/gitlab-qa/-/tree/9ffb9ad3be847a9054967d792d6772a74220fb42/tls_certificates/gitlab).
+Tests that are tagged `:ldap_tls` enable TLS on GitLab using the certificate [checked into the GitLab-QA repository](https://gitlab.com/gitlab-org/gitlab-qa/-/tree/9ffb9ad3be847a9054967d792d6772a74220fb42/tls_certificates/gitlab).
 
-The certificate was generated with openssl using this command:
+The certificate was generated with OpenSSL using this command:
 
 ```shell
 openssl req -x509 -newkey rsa:4096 -keyout gitlab.test.key -out gitlab.test.crt -days 3650 -nodes -subj "/C=US/ST=CA/L=San Francisco/O=GitLab/OU=Org/CN=gitlab.test"
@@ -432,7 +432,7 @@ To run the LDAP tests on your local with TLS enabled, follow these steps:
 
    `127.0.0.1    gitlab.test`
 
-   You can then run tests against GitLab in a Docker container on `https://gitlab.test`. Please note that the TLS certificate [checked into the GitLab-QA repo](https://gitlab.com/gitlab-org/gitlab-qa/-/tree/9ffb9ad3be847a9054967d792d6772a74220fb42/tls_certificates/gitlab) is configured for this domain.
+   You can then run tests against GitLab in a Docker container on `https://gitlab.test`. Please note that the TLS certificate [checked into the GitLab-QA repository](https://gitlab.com/gitlab-org/gitlab-qa/-/tree/9ffb9ad3be847a9054967d792d6772a74220fb42/tls_certificates/gitlab) is configured for this domain.
 1. Run the OpenLDAP container with TLS enabled. Change the path to [`gitlab-qa/fixtures/ldap`](https://gitlab.com/gitlab-org/gitlab-qa/-/tree/9ffb9ad3be847a9054967d792d6772a74220fb42/fixtures/ldap) directory to your local checkout path:
 
    ```shell

doc/development/usage_ping/metrics_dictionary.md

@@ -14,7 +14,7 @@ We are using [JSON Schema](https://gitlab.com/gitlab-org/gitlab/-/blob/master/co
 
 This process is meant to ensure consistent and valid metrics defined for Usage Ping. All metrics *must*:
 
-- Comply with the definied [JSON schema](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/metrics/schema.json).
+- Comply with the defined [JSON schema](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/metrics/schema.json).
 - Have a unique `key_path` .
 - Have an owner.
 
@@ -22,7 +22,7 @@ All metrics are stored in YAML files:
 
 - [`config/metrics`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/config/metrics)
 
-Each metric is definied in a separate YAML file consisting of a number of fields:
+Each metric is defined in a separate YAML file consisting of a number of fields:
 
 | Field               | Required | Additional information                                         |
 |---------------------|----------|----------------------------------------------------------------|

doc/development/utilities.md

@@ -10,7 +10,7 @@ We have developed a number of utilities to help ease development:
 
 ## `MergeHash`
 
-Refer to: <https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/utils/merge_hash.rb>:
+Refer to [`merge_hash.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/utils/merge_hash.rb):
 
 - Deep merges an array of hashes:
 
@@ -111,7 +111,7 @@ Refer to [`override.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gi
 
 ## `StrongMemoize`
 
-Refer to <https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/utils/strong_memoize.rb>:
+Refer to [`strong_memoize.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/utils/strong_memoize.rb):
 
 - Memoize the value even if it is `nil` or `false`.
 

doc/gitlab-basics/command-line-commands.md

@@ -106,9 +106,9 @@ WARNING:
 Be careful of the commands you run with `sudo`. Certain commands may cause
 damage to your data or system.
 
-## Sample Git taskflow
+## Sample Git task flow
 
-If you're completely new to Git, looking through some [sample taskflows](https://rogerdudler.github.io/git-guide/)
+If you're completely new to Git, looking through some [sample task flows](https://rogerdudler.github.io/git-guide/)
 may help you understand the best practices for using these commands as you work.
 
 <!-- ## Troubleshooting

doc/gitlab-basics/start-using-git.md

@@ -51,7 +51,7 @@ prompt, terminal, and command line) of your preference. Here are some suggestion
   - Built-in: [Terminal](https://blog.teamtreehouse.com/introduction-to-the-mac-os-x-command-line). Press <kbd>⌘ command</kbd> + <kbd>space</kbd> and type "terminal" to find it.
   - [iTerm2](https://iterm2.com/), which you can integrate with [zsh](https://git-scm.com/book/id/v2/Appendix-A%3A-Git-in-Other-Environments-Git-in-Zsh) and [oh my zsh](https://ohmyz.sh/) for color highlighting, among other handy features for Git users.
 - For Windows users:
-  - Built-in: **cmd**. Click the search icon on the bottom navbar on Windows and type "cmd" to find it.
+  - Built-in: `cmd`. Click the search icon on the bottom navigation bar on Windows and type `cmd` to find it.
   - [PowerShell](https://docs.microsoft.com/en-us/powershell/scripting/windows-powershell/install/installing-windows-powershell?view=powershell-7): a Windows "powered up" shell, from which you can execute a greater number of commands.
   - Git Bash: it comes built into [Git for Windows](https://gitforwindows.org/).
 - For Linux users:
@@ -152,8 +152,12 @@ Your files in GitLab live in a **repository**, similar to how you have them in a
 directory in your computer. **Remote** repository refers to the files in
 GitLab and the copy in your computer is called **local** copy.
 A **project** in GitLab is what holds a repository, which holds your files.
-Often, the word "repository" is shortened to "repo".
 
+<!-- vale gitlab.Spelling = NO -->
+<!-- vale gitlab.SubstitutionWarning = NO -->
+Often, the word "repository" is shortened to "repo".
+<!-- vale gitlab.Spelling = YES -->
+<!-- vale gitlab.SubstitutionWarning = YES -->
 ### Fork
 
 When you want to copy someone else's repository, you [**fork**](../user/project/repository/forking_workflow.md#creating-a-fork)

doc/install/aws/index.md

@@ -122,7 +122,7 @@ Internet Gateway.
 
 We'll now create a VPC, a virtual networking environment that you'll control:
 
-1. Navigate to <https://console.aws.amazon.com/vpc/home>.
+1. Sign in to [Amazon Web Services](https://console.aws.amazon.com/vpc/home).
 1. Select **Your VPCs** from the left menu and then click **Create VPC**.
    At the "Name tag" enter `gitlab-vpc` and at the "IPv4 CIDR block" enter
    `10.0.0.0/16`. If you don't require dedicated hardware, you can leave
@@ -277,7 +277,7 @@ On the Route 53 dashboard, click **Hosted zones** in the left navigation bar:
     1. Click **Create**.
 1. If you registered your domain through Route 53, you're done. If you used a different domain registrar, you need to update your DNS records with your domain registrar. You'll need to:
    1. Click on **Hosted zones** and select the domain you added above.
-   1. You'll see a list of `NS` records. From your domain registrar's admin panel, add each of these as `NS` records to your domain's DNS records. These steps may vary between domain registrars. If you're stuck, Google **"name of your registrar" add dns records** and you should find a help article specific to your domain registrar.
+   1. You'll see a list of `NS` records. From your domain registrar's admin panel, add each of these as `NS` records to your domain's DNS records. These steps may vary between domain registrars. If you're stuck, Google **"name of your registrar" add DNS records** and you should find a help article specific to your domain registrar.
 
 The steps for doing this vary depending on which registrar you use and is beyond the scope of this guide.
 
@@ -568,7 +568,7 @@ Let's create an EC2 instance where we'll install Gitaly:
 
 1. From the EC2 dashboard, click **Launch instance**.
 1. Choose an AMI. In this example, we'll select the **Ubuntu Server 18.04 LTS (HVM), SSD Volume Type**.
-1. Choose an instance type. We'll pick a **c5.xlarge**.
+1. Choose an instance type. We'll pick a `c5.xlarge`.
 1. Click **Configure Instance Details**.
    1. In the **Network** dropdown, select `gitlab-vpc`, the VPC we created earlier.
    1. In the **Subnet** dropdown, select `gitlab-private-10.0.1.0` from the list of subnets we created earlier.

doc/install/google_cloud_platform/index.md

@@ -36,7 +36,7 @@ To deploy GitLab on GCP you first need to create a virtual machine:
    ![Search for GitLab](img/launch_vm.png)
 
 1. On the next page, you can select the type of VM as well as the
-   estimated costs. Provide the name of the instance, desired datacenter, and machine type.
+   estimated costs. Provide the name of the instance, desired data center, and machine type.
    Note our [hardware requirements for different user base sizes](../requirements.md#hardware-requirements).
 
    ![Launch on Compute Engine](img/vm_details.png)

doc/integration/cas.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # CAS OmniAuth Provider
 
-To enable the CAS OmniAuth provider you must register your application with your CAS instance. This requires the service URL GitLab supplies to CAS. It should be something like: `https://gitlab.example.com:443/users/auth/cas3/callback?url`. By default handling for SLO is enabled, you only need to configure CAS for backchannel logout.
+To enable the CAS OmniAuth provider you must register your application with your CAS instance. This requires the service URL GitLab supplies to CAS. It should be something like: `https://gitlab.example.com:443/users/auth/cas3/callback?url`. By default handling for SLO is enabled, you only need to configure CAS for back-channel logout.
 
 1. On your GitLab server, open the configuration file.
 
@@ -57,7 +57,7 @@ To enable the CAS OmniAuth provider you must register your application with your
          logout_url: '/CAS_PATH/logout' } }
    ```
 
-1. Change 'CAS_PATH' to the root of your CAS instance (ie. `cas`).
+1. Change 'CAS_PATH' to the root of your CAS instance (such as `cas`).
 
 1. If your CAS instance does not use default TGC lifetimes, update the `cas3.session_duration` to at least the current TGC maximum lifetime. To explicitly disable SLO, regardless of CAS settings, set this to 0.
 

doc/integration/gmail_action_buttons_for_gitlab.md

@@ -10,7 +10,7 @@ GitLab supports [Google actions in email](https://developers.google.com/gmail/ma
 
 If correctly set up, emails that require an action are marked in Gmail.
 
-![gmail_actions_button.png](img/gmail_action_buttons_for_gitlab.png)
+![GMail actions button](img/gmail_action_buttons_for_gitlab.png)
 
 To get this functioning, you need to be registered with Google. For instructions, see
 [Register with Google](https://developers.google.com/gmail/markup/registering-with-google).

doc/integration/kerberos.md

@@ -109,7 +109,7 @@ existing GitLab account. To do so:
 
 1. Navigate to **Admin Area > Overview > Users > Example User**.
 1. Select the Identities tab.
-1. Select 'Kerberos Spnego' in the 'Provider' dropdown box.
+1. Select 'Kerberos SPNEGO' in the 'Provider' dropdown box.
 1. Make sure the **Identifier** corresponds to the Kerberos username.
 1. Select **Save changes**.
 
@@ -117,7 +117,7 @@ If you're not an administrator:
 
 1. Select your avatar in the upper-right corner, and select **Settings**.
 1. Select Account. In the **Social sign-in** section, select
-   **Connect Kerberos Spnego**.
+   **Connect Kerberos SPNEGO**.
    If you don't see a **Social sign-in** Kerberos option, follow the
    requirements in [Enable single sign-on](#enable-single-sign-on).
 
@@ -291,10 +291,10 @@ remove support for password-based Kerberos sign-ins in a future
 release, so we recommend that you upgrade to ticket-based sign-ins.
 
 Depending on your existing GitLab configuration, the 'Sign in with:
-Kerberos Spnego' button may already be visible on your GitLab sign-in
+Kerberos SPNEGO' button may already be visible on your GitLab sign-in
 page. If not, then add the settings [described above](#configuration).
 
-Once you have verified that the 'Kerberos Spnego' button works
+Once you have verified that the 'Kerberos SPNEGO' button works
 without entering any passwords, you can proceed to disable
 password-based Kerberos sign-ins. To do this you need only need to
 remove the OmniAuth provider named `kerberos` from your `gitlab.yml` /