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

Docs: another set of spelling fixes

See merge request gitlab-org/gitlab!33640

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

 Akismet
 Alertmanager
 Algolia
+allowlist
+allowlisting
+allowlists
 Ansible
 Anthos
 API
@@ -29,6 +32,7 @@ autoscaling
 awardable
 Axios
 Azure
+B-tree
 backport
 backported
 backporting
@@ -57,6 +61,7 @@ CAS
 CentOS
 Chatops
 Citrix
+Citus
 clonable
 Cloudwatch
 Cobertura
@@ -83,6 +88,9 @@ deduplicated
 deduplicates
 deduplicating
 deduplication
+denylist
+denylisting
+denylists
 deprovision
 deprovisioned
 deprovisioning
@@ -114,6 +122,7 @@ Fluentd
 Forgerock
 Gantt
 Gemnasium
+gettext
 Git
 Gitaly
 Gitea
@@ -129,6 +138,7 @@ Gradle
 Grafana
 gravatar
 Gzip
+Haml
 hardcode
 hardcoded
 hardcodes
@@ -168,6 +178,7 @@ kanbans
 Karma
 Kerberos
 Kibana
+Kinesis
 Knative
 Kramdown
 Kubernetes
@@ -190,6 +201,10 @@ Markdown
 markdownlint
 Mattermost
 mbox
+memoization
+memoize
+memoized
+memoizing
 mergeable
 Microsoft
 middleware
@@ -204,6 +219,8 @@ misconfiguration
 misconfigurations
 misconfiguring
 mitigations
+mixin
+mixins
 mockup
 mockups
 ModSecurity
@@ -224,6 +241,7 @@ offboarded
 offboarding
 offboards
 OmniAuth
+onboarding
 OpenID
 OpenShift
 Packagist
@@ -235,6 +253,8 @@ Pipfiles
 Piwik
 PgBouncer
 plaintext
+Poedit
+pooler
 PostgreSQL
 precompile
 preconfigure
@@ -299,6 +319,7 @@ reverified
 reverifies
 reverify
 Rubix
+Rubocop
 runbook
 runbooks
 runit
@@ -306,11 +327,13 @@ runtime
 runtimes
 Salesforce
 SAML
+sandboxing
 sbt
 Sendmail
 Sentry
 serverless
 Sidekiq
+Sisense
 sharding
 shfmt
 Shibboleth
@@ -330,6 +353,7 @@ spidering
 Splunk
 SpotBugs
 SSH
+Stackdriver
 storable
 strace
 strikethrough

doc/development/geo.md

@@ -94,7 +94,7 @@ projects that need updating. Those projects can be:
   [Geo admin panel](../user/admin_area/geo_nodes.md).
 
 When we fail to fetch a repository on the secondary `RETRIES_BEFORE_REDOWNLOAD`
-times, Geo does a so-called _redownload_. It will do a clean clone
+times, Geo does a so-called _re-download_. It will do a clean clone
 into the `@geo-temporary` directory in the root of the storage. When
 it's successful, we replace the main repo with the newly cloned one.
 
@@ -218,7 +218,7 @@ the performance of many synchronization operations.
 
 FDW is a PostgreSQL extension ([`postgres_fdw`](https://www.postgresql.org/docs/11/postgres-fdw.html)) that is enabled within
 the Geo Tracking Database (on a **secondary** node), which allows it
-to connect to the readonly database replica and perform queries and filter
+to connect to the read-only database replica and perform queries and filter
 data from both instances.
 
 This persistent connection is configured as an FDW server
@@ -226,7 +226,7 @@ named `gitlab_secondary`. This configuration exists within the database's user
 context only. To access the `gitlab_secondary`, GitLab needs to use the
 same database user that had previously been configured.
 
-The Geo Tracking Database accesses the readonly database replica via FDW as a regular user,
+The Geo Tracking Database accesses the read-only database replica via FDW as a regular user,
 limited by its own restrictions. The credentials are configured as a
 `USER MAPPING` associated with the `SERVER` mapped previously
 (`gitlab_secondary`).

doc/development/gitaly.md

@@ -54,7 +54,7 @@ The process for adding new Gitaly features is:
 These steps often overlap. It is possible to use an unreleased version
 of Gitaly and `gitaly-proto` during testing and development.
 
-- See the [Gitaly repo](https://gitlab.com/gitlab-org/gitaly/blob/master/CONTRIBUTING.md#development-and-testing-with-a-custom-gitaly-proto) for instructions on writing server side code with an unreleased protocol.
+- See the [Gitaly repository](https://gitlab.com/gitlab-org/gitaly/blob/master/CONTRIBUTING.md#development-and-testing-with-a-custom-gitaly-proto) for instructions on writing server side code with an unreleased protocol.
 - See [below](#running-tests-with-a-locally-modified-version-of-gitaly) for instructions on running GitLab CE tests with a modified version of Gitaly.
 - In GDK run `gdk install` and restart `gdk run` (or `gdk run app`) to use a locally modified Gitaly version for development
 
@@ -67,7 +67,7 @@ This should make it easier to contribute for developers who are less
 comfortable writing Go code.
 
 There is documentation for this approach in [the Gitaly
-repo](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/ruby_endpoint.md).
+repository](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/ruby_endpoint.md).
 
 ## Gitaly-Related Test Failures
 
@@ -323,8 +323,8 @@ the integration by using GDK:
    1. Navigate to GDK's root directory.
    1. Make sure you have the proper branch checked out for Gitaly.
    1. Recompile it with `make gitaly-setup` and restart the service with `gdk restart gitaly`.
-   1. Make sure your setup is runnig: `gdk status | grep praefect`.
-   1. Check what config file is used: `cat ./services/praefect/run | grep praefect` value of the `-config` flag
+   1. Make sure your setup is running: `gdk status | grep praefect`.
+   1. Check what configuration file is used: `cat ./services/praefect/run | grep praefect` value of the `-config` flag
    1. Uncomment `prometheus_listen_addr` in the configuration file and run `gdk restart gitaly`.
 
 1. Make sure that the flag is not enabled yet:

doc/development/gotchas.md

@@ -155,7 +155,7 @@ refresh_service.execute(oldrev, newrev, ref)
 See ["Why is it bad style to `rescue Exception => e` in Ruby?"](https://stackoverflow.com/questions/10048173/why-is-it-bad-style-to-rescue-exception-e-in-ruby).
 
 _**Note:** This rule is [enforced automatically by
-Rubocop](https://gitlab.com/gitlab-org/gitlab-foss/blob/8-4-stable/.rubocop.yml#L911-914)._
+RuboCop](https://gitlab.com/gitlab-org/gitlab-foss/blob/8-4-stable/.rubocop.yml#L911-914)._
 
 ## Do not use inline JavaScript in views
 

doc/development/hash_indexes.md

 # Hash Indexes
 
-PostgreSQL supports hash indexes besides the regular btree
+PostgreSQL supports hash indexes besides the regular B-tree
 indexes. Hash indexes however are to be avoided at all costs. While they may
 _sometimes_ provide better performance the cost of rehashing can be very high.
 More importantly: at least until PostgreSQL 10.0 hash indexes are not
@@ -17,4 +17,4 @@ documentation:
 RuboCop is configured to register an offense when it detects the use of a hash
 index.
 
-Instead of using hash indexes you should use regular btree indexes.
+Instead of using hash indexes you should use regular B-tree indexes.

doc/development/i18n/proofreader.md

@@ -5,6 +5,7 @@ are very appreciative of the work done by translators and proofreaders!
 
 ## Proofreaders
 
+<!-- vale gitlab.Spelling = NO -->
 - Albanian
   - Proofreaders needed.
 - Amharic
@@ -104,6 +105,7 @@ are very appreciative of the work done by translators and proofreaders!
   - Andrew Vityuk - [GitLab](https://gitlab.com/3_1_3_u), [CrowdIn](https://crowdin.com/profile/andruwa13)
 - Welsh
   - Proofreaders needed.
+<!-- vale gitlab.Spelling = YES -->
 
 ## Become a proofreader
 

doc/development/i18n/translation.md

@@ -79,8 +79,10 @@ ethnicity.
 In languages which distinguish between a male and female form, use both or
 choose a neutral formulation.
 
+<!-- vale gitlab.Spelling = NO -->
 For example in German, the word "user" can be translated into "Benutzer" (male) or "Benutzerin" (female).
 Therefore "create a new user" would translate into "Benutzer(in) anlegen".
+<!-- vale gitlab.Spelling = YES -->
 
 ### Updating the glossary
 
@@ -91,6 +93,8 @@ To propose additions to the glossary please
 
 ### Inclusive language in French
 
+<!-- vale gitlab.Spelling = NO -->
 In French, the "écriture inclusive" is now over (see on [Legifrance](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000036068906&categorieLien=id)).
 So, to include both genders, write “Utilisateurs et utilisatrices” instead of “Utilisateur·rice·s”.
 When space is missing, the male gender should be used alone.
+<!-- vale gitlab.Spelling = YES -->

doc/development/instrumentation.md

@@ -119,9 +119,9 @@ without measuring anything.
 
 Three values are measured for a block:
 
-- The real time elapsed, stored in NAME_real_time.
-- The CPU time elapsed, stored in NAME_cpu_time.
-- The call count, stored in NAME_call_count.
+- The real time elapsed, stored in `NAME_real_time`.
+- The CPU time elapsed, stored in `NAME_cpu_time`.
+- The call count, stored in `NAME_call_count`.
 
 Both the real and CPU timings are measured in milliseconds.
 

doc/development/integrations/secure.md

@@ -15,7 +15,7 @@ scanner, as well as requirements and guidelines for the Docker image.
 
 ## Job definition
 
-This section desribes several important fields to add to the security scanner's job
+This section describes several important fields to add to the security scanner's job
 definition file. Full documentation on these and other available fields can be viewed
 in the [CI documentation](../../ci/yaml/README.md#image).
 
@@ -89,9 +89,9 @@ for variables such as `DEPENDENCY_SCANNING_DISABLED`, `CONTAINER_SCANNING_DISABL
 disable running the custom scanner.
 
 GitLab also defines a `CI_PROJECT_REPOSITORY_LANGUAGES` variable, which provides the list of
-languages in the repo. Depending on this value, your scanner may or may not do something different.
+languages in the repository. Depending on this value, your scanner may or may not do something different.
 Language detection currently relies on the [`linguist`](https://github.com/github/linguist) Ruby gem.
-See [GitLab CI/CD prefined variables](../../ci/variables/predefined_variables.md#variables-reference).
+See [GitLab CI/CD predefined variables](../../ci/variables/predefined_variables.md#variables-reference).
 
 #### Policy checking example
 

doc/development/integrations/secure_partner_integration.md

@@ -54,7 +54,7 @@ best place to integrate your own product and its results into GitLab.
 ## How to onboard
 
 This section describes the steps you need to complete to onboard as a partner
-and complete an intgration with the Secure stage.
+and complete an integration with the Secure stage.
 
 1. Read about our [partnerships](https://about.gitlab.com/partners/integrate/).
 1. [Create an issue](https://gitlab.com/gitlab-com/alliances/alliances/-/issues/new?issuable_template=new_partner)

doc/development/internal_api.md

@@ -47,7 +47,7 @@ POST /internal/allowed
 | `protocol` | string | yes     | SSH when called from GitLab-shell, HTTP or SSH when called from Gitaly |
 | `action`   | string | yes     | Git command being run (`git-upload-pack`, `git-receive-pack`, `git-upload-archive`) |
 | `changes`  | string | yes     | `<oldrev> <newrev> <refname>` when called from Gitaly, The magic string `_any` when called from GitLab Shell |
-| `check_ip` | string | no     | Ip address from which call to GitLab Shell was made |
+| `check_ip` | string | no     | IP address from which call to GitLab Shell was made |
 
 Example request:
 

doc/development/logging.md

@@ -359,7 +359,7 @@ end
 
 1. If you add a new file, submit an issue to the [production
    tracker](https://gitlab.com/gitlab-com/gl-infra/production/-/issues) or
-   a merge request to the [gitlab_fluentd](https://gitlab.com/gitlab-cookbooks/gitlab_fluentd)
+   a merge request to the [`gitlab_fluentd`](https://gitlab.com/gitlab-cookbooks/gitlab_fluentd)
    project. See [this example](https://gitlab.com/gitlab-cookbooks/gitlab_fluentd/-/merge_requests/51/diffs).
 
 1. Be sure to update the [GitLab CE/EE documentation](../administration/logs.md) and the [GitLab.com

doc/development/migration_style_guide.md

@@ -35,7 +35,7 @@ and post-deployment migrations (`db/post_migrate`) are run after the deployment
 
 ## Schema Changes
 
-Changes to the schema should be commited to `db/structure.sql`. This
+Changes to the schema should be committed to `db/structure.sql`. This
 file is automatically generated by Rails, so you normally should not
 edit this file by hand. If your migration is adding a column to a
 table, that column will be added at the bottom. Please do not reorder
@@ -49,7 +49,7 @@ regenerate a clean `db/structure.sql` for the migrations you're
 adding. This script will apply all migrations found in `db/migrate`
 or `db/post_migrate`, so if there are any migrations you don't want to
 commit to the schema, rename or remove them. If your branch is not
-targetting `master` you can set the `TARGET` environment variable.
+targeting `master` you can set the `TARGET` environment variable.
 
 ```shell
 # Regenerate schema against `master`
@@ -343,7 +343,7 @@ def up
 end
 ```
 
-The RuboCop rule generally allows standard Rails migration methods, listed below. This example will cause a rubocop offense:
+The RuboCop rule generally allows standard Rails migration methods, listed below. This example will cause a Rubocop offense:
 
 ```ruby
 disabled_ddl_transaction!

doc/development/new_fe_guide/development/accessibility.md

-# Accessiblity
+# Accessibility
 
 Using semantic HTML plays a key role when it comes to accessibility.
 
@@ -37,7 +37,7 @@ In forms we should use the `for` attribute in the label statement:
 ## Testing
 
 1. On MacOS you can use [VoiceOver](https://www.apple.com/accessibility/mac/vision/) by pressing `cmd+F5`.
-1. On Windows you can use [Narrator](https://www.microsoft.com/en-us/accessibility/windows) by pressing Windows logo key + Ctrl + Enter.
+1. On Windows you can use [Narrator](https://www.microsoft.com/en-us/accessibility/windows) by pressing Windows logo key + Control + Enter.
 
 ## Online resources
 

doc/development/new_fe_guide/development/performance.md

@@ -5,7 +5,7 @@
 We have a performance dashboard available in one of our [Grafana instances](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://www.sitespeed.io/) every 6 hours. These changes are displayed after a set number of pages are aggregated.
 
 These pages can be found inside a text file in the [`gitlab-build-images` repository](https://gitlab.com/gitlab-org/gitlab-build-images) called [`gitlab.txt`](https://gitlab.com/gitlab-org/gitlab-build-images/blob/master/scripts/gitlab.txt)
-Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing urls of pages from this text file. Please have a [frontend monitoring expert](https://about.gitlab.com/company/team/) review your changes before assigning to a maintainer of the `gitlab-build-images` project. The changes will go live on the next scheduled run after the changes are merged into `master`.
+Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing URLs of pages from this text file. Please have a [frontend monitoring expert](https://about.gitlab.com/company/team/) review your changes before assigning to a maintainer of the `gitlab-build-images` project. The changes will go live on the next scheduled run after the changes are merged into `master`.
 
 There are 3 recommended high impact metrics to review on each page:
 

doc/development/omnibus.md

@@ -24,7 +24,7 @@ and write it to the Rails root. In the Omnibus packages, reconfigure writes the
 The Omnibus design separates code (read-only, under `/opt/gitlab`) from data
 (read/write, under `/var/opt/gitlab`) and logs (read/write, under
 `/var/log/gitlab`). To make this happen the reconfigure script sets custom
-paths where it can in GitLab config files, and where there are no path
+paths where it can in GitLab configuration files, and where there are no path
 settings, it uses symlinks.
 
 For example, `config/gitlab.yml` is treated as data so that file is a symlink.

doc/development/permissions.md

@@ -14,7 +14,7 @@ Groups and projects can have the following visibility levels:
 - private (`0`) - an entity is visible only to the approved members of the entity
 
 The visibility level of a group can be changed only if all subgroups and
-subprojects have the same or lower visibility level. (e.g., a group can be set
+sub-projects have the same or lower visibility level. (e.g., a group can be set
 to internal only if all subgroups and projects are internal or private).
 
 Visibility levels can be found in the `Gitlab::VisibilityLevel` module.
@@ -92,10 +92,10 @@ into different features like Merge Requests and CI flow.
 
 | Activity level | Resource | Locations |Permission dependency|
 |----------------|----------|-----------|-----|
-| View | License information | Dependency list, License Compliance | Can view repo |
-| View | Dependency information | Dependency list, License Compliance | Can view repo |
+| View | License information | Dependency list, License Compliance | Can view repository |
+| View | Dependency information | Dependency list, License Compliance | Can view repository |
 | View | Vulnerabilities information | Dependency list | Can view security findings |
-| View | Black/Whitelisted licenses for the project | License Compliance, Merge request  | Can view repo |
+| View | Black/Whitelisted licenses for the project | License Compliance, Merge request  | Can view repository |
 | View | Security findings | Merge Request, CI job page, Pipeline security tab | Can read the project and CI jobs |
 | View | Vulnerability feedback | Merge Request | Can read security findings |
 | View | Dependency List page | Project | Can access Dependency information |

doc/development/pipelines.md

@@ -416,7 +416,7 @@ of the `gitlab-org/gitlab-foss` project. These jobs are only created in the foll
 - `master` commits (pushes and scheduled pipelines).
 - `gitlab-org/security/gitlab` merge requests.
 - Merge requests which include `RUN AS-IF-FOSS` in their title.
-- Merge requests that changes the CI config.
+- Merge requests that changes the CI configuration.
 
 The `* as-if-foss` jobs have the `FOSS_ONLY='1'` variable set and gets their EE-specific
 folders removed before the tests start running.
@@ -546,19 +546,19 @@ The current stages are:
 - `post-qa`: This stage includes jobs that build reports or gather data from
   the `qa` stage's jobs (e.g. Review App performance report).
 - `pages`: This stage includes a job that deploys the various reports as
-  GitLab Pages (e.g. <https://gitlab-org.gitlab.io/gitlab/coverage-ruby/>,
-  <https://gitlab-org.gitlab.io/gitlab/coverage-javascript/>,
-  <https://gitlab-org.gitlab.io/gitlab/webpack-report/>).
+  GitLab Pages (e.g. [`coverage-ruby`](https://gitlab-org.gitlab.io/gitlab/coverage-ruby/),
+  [`coverage-javascript`](https://gitlab-org.gitlab.io/gitlab/coverage-javascript/),
+  [`webpack-report`](https://gitlab-org.gitlab.io/gitlab/webpack-report/).
 
 ### Default image
 
-The default image is defined in <https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml>.
+The default image is defined in [`.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml).
 
 It includes Ruby, Go, Git, Git LFS, Chrome, Node, Yarn, PostgreSQL, and Graphics Magick.
 
 The images used in our pipelines are configured in the
 [`gitlab-org/gitlab-build-images`](https://gitlab.com/gitlab-org/gitlab-build-images)
-project, which is push-mirrored to <https://dev.gitlab.org/gitlab/gitlab-build-images>
+project, which is push-mirrored to [`gitlab/gitlab-build-images`](https://dev.gitlab.org/gitlab/gitlab-build-images)
 for redundancy.
 
 The current version of the build images can be found in the
@@ -600,7 +600,7 @@ then included in individual jobs via [`extends`](../ci/yaml/README.md#extends).
 
 The `rules` definitions are composed of `if:` conditions and `changes:` patterns,
 which are also 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)
 and included in `rules` definitions via [YAML anchors](../ci/yaml/README.md#anchors)
 
 #### `if:` conditions

doc/development/redis.md

@@ -18,7 +18,7 @@ database.
 
 Redis is a flat namespace with no hierarchy, which means we must pay attention
 to key names to avoid collisions. Typically we use colon-separated elements to
-provide a semblence of structure at application level. An example might be
+provide a semblance of structure at application level. An example might be
 `projects:1:somekey`.
 
 Although we split our Redis usage into three separate purposes, and those may

doc/development/refactoring_guide/index.md

@@ -69,7 +69,7 @@ expect(cleanForSnapshot(wrapper.element)).toMatchSnapshot();
 
 ### Examples
 
-- [Pinning test in a haml to vue refactor](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/27691#pinning-tests)
+- [Pinning test in a Haml to Vue refactor](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/27691#pinning-tests)
 - [Pinning test in isolating a bug](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/32198#note_212736225)
 - [Pinning test in refactoring dropdown](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28173)
 - [Pinning test in refactoring vulnerability_details.vue](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25830/commits)

doc/development/renaming_features.md

@@ -16,7 +16,7 @@ The more of the following that are true, the more likely you should choose the f
 
 - You are not confident the new name is permanent.
 - The feature is susceptible to bugs (large, complex, needing refactor, etc).
-- The renaming will be difficult to review (feature spans many lines/files/repos).
+- The renaming will be difficult to review (feature spans many lines, files, or repositories).
 - The renaming will be disruptive in some way (database table renaming).
 
 ## Consider a façade-first approach

doc/development/scalability.md

@@ -52,10 +52,10 @@ maintain and support one database with tables with many rows.
 
 There are two ways to deal with this:
 
-- Partioning. Locally split up tables data.
+- Partitioning. Locally split up tables data.
 - Sharding. Distribute data across multiple databases.
 
-Partioning is a built-in PostgreSQL feature and requires minimal changes
+Partitioning is a built-in PostgreSQL feature and requires minimal changes
 in the application. However, it [requires PostgreSQL
 11](https://www.2ndquadrant.com/en/blog/partitioning-evolution-postgresql-11/).
 
@@ -246,9 +246,9 @@ lifting of many activities, including:
 - Processing CI builds and pipelines.
 
 The full list of jobs can be found in the
-[app/workers](https://gitlab.com/gitlab-org/gitlab/tree/master/app/workers)
+[`app/workers`](https://gitlab.com/gitlab-org/gitlab/tree/master/app/workers)
 and
-[ee/app/workers](https://gitlab.com/gitlab-org/gitlab/tree/master/ee/app/workers)
+[`ee/app/workers`](https://gitlab.com/gitlab-org/gitlab/tree/master/ee/app/workers)
 directories in the GitLab code base.
 
 #### Runaway Queues
@@ -281,7 +281,7 @@ in a timely manner:
   benefits.
 
 From the Sidekiq logs, it's possible to see which jobs run the most
-frequently and/or take the longest. For example, theis Kibana
+frequently and/or take the longest. For example, these Kibana
 visualizations show the jobs that consume the most total time:
 
 ![Most time-consuming Sidekiq jobs](img/sidekiq_most_time_consuming_jobs.png)

doc/development/secure_coding_guidelines.md

@@ -52,7 +52,7 @@ Some example of well implemented access controls and tests:
 1. [example2](https://dev.gitlab.org/gitlab/gitlabhq/-/merge_requests/2511/diffs#ed3aaab1510f43b032ce345909a887e5b167e196_142_155)
 1. [example3](https://dev.gitlab.org/gitlab/gitlabhq/-/merge_requests/3170/diffs?diff_id=17494)
 
-**NB:** any input from development team is welcome, e.g. about rubocop rules.
+**NB:** any input from development team is welcome, e.g. about Rubocop rules.
 
 ## Regular Expressions guidelines
 
@@ -67,7 +67,7 @@ matches = re.findall("^bar$",text)
 print(matches)
 ```
 
-The Python example will output an emtpy array (`[]`) as the matcher considers the whole string `foo\nbar` including the newline (`\n`). In contrast Ruby's Regular Expression engine acts differently:
+The Python example will output an empty array (`[]`) as the matcher considers the whole string `foo\nbar` including the newline (`\n`). In contrast Ruby's Regular Expression engine acts differently:
 
 ```ruby
 text = "foo\nbar"
@@ -111,7 +111,7 @@ or controls the regular expression (regex) used, and is able to enter user input
 
 ### Impact
 
-The resource, for example Unicorn, Puma, or Sidekiq, can be made to hang as it takes a long time to evaulate the bad regex match.
+The resource, for example Unicorn, Puma, or Sidekiq, can be made to hang as it takes a long time to evaluate the bad regex match.
 
 ### Examples
 
@@ -140,9 +140,9 @@ class Email < ApplicationRecord
 GitLab has `Gitlab::UntrustedRegexp` which internally uses the [`re2`](https://github.com/google/re2/wiki/Syntax) library.
 By utilizing `re2`, we get a strict limit on total execution time, and a smaller subset of available regex features.
 
-All user-provided regexes should use `Gitlab::UntrustedRegexp`.
+All user-provided regular expressions should use `Gitlab::UntrustedRegexp`.
 
-For other regexes, here are a few guidelines:
+For other regular expressions, here are a few guidelines:
 
 - Remove unnecessary backtracking.
 - Avoid nested quantifiers if possible.
@@ -206,14 +206,14 @@ The [GitLab::HTTP](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab
 `Outbound requests` options that allow instance administrators to block all internal connections, or limit the networks to which connections can be made.
 
 In some cases, it has been possible to configure GitLab::HTTP as the HTTP
-connection library for 3rd-party gems. This is preferrable over re-implementing
+connection library for 3rd-party gems. This is preferable over re-implementing
 the mitigations for a new feature.
 
 - [More details](https://dev.gitlab.org/gitlab/gitlabhq/-/merge_requests/2530/diffs)
 
 #### Feature-specific Mitigations
 
-For situtions in which an allowlist or GitLab:HTTP cannot be used, it will be necessary to implement mitigations directly in the feature. It is best to validate the destination IP addresses themselves, not just domain names, as DNS can be controlled by the attacker. Below are a list of mitigations that should be implemented.
+For situations in which an allowlist or GitLab:HTTP cannot be used, it will be necessary to implement mitigations directly in the feature. It is best to validate the destination IP addresses themselves, not just domain names, as DNS can be controlled by the attacker. Below are a list of mitigations that should be implemented.
 
 **Important Note:** There are many tricks to bypass common SSRF validations. If feature-specific mitigations are necessary, they should be reviewed by the AppSec team, or a developer who has worked on SSRF mitigations previously.
 
@@ -230,7 +230,7 @@ For situtions in which an allowlist or GitLab:HTTP cannot be used, it will be ne
 - For HTTP connections: Disable redirects or validate the redirect destination
 - To mitigate DNS rebinding attacks, validate and use the first IP address received
 
-See [url_blocker_spec.rb](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/lib/gitlab/url_blocker_spec.rb) for examples of SSRF payloads
+See [`url_blocker_spec.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/lib/gitlab/url_blocker_spec.rb) for examples of SSRF payloads
 
 ## XSS guidelines
 

doc/development/telemetry/snowplow.md

@@ -127,7 +127,7 @@ Below is an example of `data-track-*` attributes assigned to a button:
 />
 ```
 
-Event listeners are bound at the document level to handle click events on or within elements with these data attributes. This allows for them to be properly handled on rerendering and changes to the DOM, but it's important to know that because of the way these events are bound, click events shouldn't be stopped from propagating up the DOM tree. If for any reason click events are being stopped from propagating, you'll need to implement your own listeners and follow the instructions in [Tracking in raw JavaScript](#tracking-in-raw-javascript).
+Event listeners are bound at the document level to handle click events on or within elements with these data attributes. This allows for them to be properly handled on re-rendering and changes to the DOM, but it's important to know that because of the way these events are bound, click events shouldn't be stopped from propagating up the DOM tree. If for any reason click events are being stopped from propagating, you'll need to implement your own listeners and follow the instructions in [Tracking in raw JavaScript](#tracking-in-raw-javascript).
 
 Below is a list of supported `data-track-*` attributes:
 
@@ -219,7 +219,7 @@ button.addEventListener('click', () => {
 
 ### Tests and test helpers
 
-In Jest particularly in vue tests, you can use the following:
+In Jest particularly in Vue tests, you can use the following:
 
 ```javascript
 import { mockTracking } from 'helpers/tracking_helper';
@@ -339,7 +339,7 @@ Snowplow Micro is a very small version of a full Snowplow data collection pipeli
 Snowplow Micro is a Docker-based solution for testing frontend and backend events in a local development environment. You need to modify GDK using the instructions below to set this up.
 
 - Read [Introducing Snowplow Micro](https://snowplowanalytics.com/blog/2019/07/17/introducing-snowplow-micro/)
-- Look at the [Snowplow Micro repo](https://github.com/snowplow-incubator/snowplow-micro)
+- Look at the [Snowplow Micro repository](https://github.com/snowplow-incubator/snowplow-micro)
 - Watch our [installation guide recording](https://www.youtube.com/watch?v=OX46fo_A0Ag)
 
 1. Install [Snowplow Micro](https://github.com/snowplow-incubator/snowplow-micro)