Merge branch 'docs-aqualls-spellllling' into 'master'

Fix yet more spelling issues in the docs

See merge request gitlab-org/gitlab!53282

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

@@ -125,6 +125,10 @@ deduplicates
 deduplicating
 deduplication
 deliverables
+denormalize
+denormalized
+denormalizes
+denormalizing
 denylist
 denylisting
 denylists
@@ -138,6 +142,7 @@ dequarantine
 dequarantined
 dequarantining
 DevOps
+disambiguates
 discoverability
 dismissable
 Disqus
@@ -169,6 +174,7 @@ failover
 failovers
 failsafe
 Falco
+falsy
 fastlane
 favicon
 favorited
@@ -181,6 +187,7 @@ Flawfinder
 Flowdock
 Fluentd
 Forgerock
+formatters
 Fugit
 fuzzer
 Gantt
@@ -206,6 +213,7 @@ goroutines
 Gosec
 Gradle
 Grafana
+Grafonnet
 gravatar
 Gzip
 Haml
@@ -253,6 +261,7 @@ Jira
 jq
 jQuery
 jsdom
+Jsonnet
 JupyterHub
 kanban
 kanbans
@@ -282,6 +291,7 @@ Libravatar
 liveness
 Lograge
 logrotate
+Logrus
 Logstash
 lookahead
 lookaheads
@@ -521,6 +531,7 @@ spidering
 Splunk
 SpotBugs
 Stackdriver
+Stackprof
 starrer
 starrers
 storable
@@ -553,6 +564,8 @@ substring
 substrings
 subtask
 subtasks
+subtest
+subtests
 subtree
 subtrees
 sudo
@@ -592,6 +605,7 @@ Trello
 triaged
 triages
 triaging
+truthy
 Truststore
 Twilio
 Twitter
@@ -605,6 +619,7 @@ unarchive
 unarchived
 unarchives
 unarchiving
+unary
 unassign
 unassigning
 unassigns
@@ -673,6 +688,7 @@ unstarted
 unstash
 unstashed
 unstashing
+unsynced
 untarred
 untracked
 untrusted

doc/development/feature_flags/controls.md

@@ -11,12 +11,12 @@ info: "See the Technical Writers assigned to Development Guidelines: https://abo
 
 To be able to turn on/off features behind feature flags in any of the
 GitLab Inc. provided environments such as staging and production, you need to
-have access to the [Chatops](../chatops_on_gitlabcom.md) bot. The Chatops bot
+have access to the [ChatOps](../chatops_on_gitlabcom.md) bot. The ChatOps bot
 is currently running on the ops instance, which is different from <https://gitlab.com> or <https://dev.gitlab.org>.
 
-Follow the Chatops document to [request access](../chatops_on_gitlabcom.md#requesting-access).
+Follow the ChatOps document to [request access](../chatops_on_gitlabcom.md#requesting-access).
 
-Once you are added to the project test if your access propagated,
+After you are added to the project test if your access propagated,
 run:
 
 ```shell
@@ -37,7 +37,7 @@ easier to measure the impact of both separately.
 The GitLab feature library (using
 [Flipper](https://github.com/jnunemaker/flipper), and covered in the [Feature
 Flags process](process.md) guide) supports rolling out changes to a percentage of
-time to users. This in turn can be controlled using [GitLab Chatops](../../ci/chatops/README.md).
+time to users. This in turn can be controlled using [GitLab ChatOps](../../ci/chatops/README.md).
 
 For an up to date list of feature flag commands please see [the source
 code](https://gitlab.com/gitlab-com/chatops/blob/master/lib/chatops/commands/feature.rb).
@@ -48,7 +48,7 @@ If you get an error "Whoops! This action is not allowed. This incident
 will be reported." that means your Slack account is not allowed to
 change feature flags or you do not [have access](#access).
 
-### Enabling a feature for preproduction testing
+### Enabling a feature for pre-production testing
 
 As a first step in a feature rollout, you should enable the feature on <https://about.staging.gitlab.com>
 and <https://dev.gitlab.org>.
@@ -62,7 +62,7 @@ a (very) rough estimate of how your feature will look/behave on GitLab.com.
 Both of these instances are connected to Sentry so make sure you check the projects
 there for any exceptions while testing your feature after enabling the feature flag.
 
-For these preproduction environments, the commands should be run in a
+For these pre-production environments, the commands should be run in a
 Slack channel for the stage the feature is relevant to. For example, use the
 `#s_monitor` channel for features developed by the Monitor stage, Health
 group.
@@ -77,7 +77,7 @@ To enable a feature for 25% of all users, run the following in Slack:
 ### Enabling a feature for GitLab.com
 
 When a feature has successfully been
-[enabled on a preproduction](#enabling-a-feature-for-preproduction-testing)
+[enabled on a pre-production](#enabling-a-feature-for-pre-production-testing)
 environment and verified as safe and working, you can roll out the
 change to GitLab.com (production).
 
@@ -244,9 +244,9 @@ You cannot selectively disable feature flags for a specific project/group/user w
 
 ### Feature flag change logging
 
-#### Chatops level
+#### ChatOps level
 
-Any feature flag change that affects GitLab.com (production) via [Chatops](https://gitlab.com/gitlab-com/chatops)
+Any feature flag change that affects GitLab.com (production) via [ChatOps](https://gitlab.com/gitlab-com/chatops)
 is automatically logged in an issue.
 
 The issue is created in the
@@ -259,7 +259,7 @@ The issue is then also posted to the GitLab internal
 marker to make the change even more visible.
 
 Changes to the issue format can be submitted in the
-[Chatops project](https://gitlab.com/gitlab-com/chatops).
+[ChatOps project](https://gitlab.com/gitlab-com/chatops).
 
 #### Instance level
 

doc/development/feature_flags/process.md

@@ -155,7 +155,7 @@ It may seem like feature flags are configuration, which goes against our [conven
 principle. However, configuration is by definition something that is user-manageable.
 Feature flags are not intended to be user-editable. Instead, they are intended as a tool for Engineers
 and Site Reliability Engineers to use to de-risk their changes. Feature flags are the shim that gets us
-to Continuous Delivery with our mono repo and without having to deploy the entire codebase on every change. 
+to Continuous Delivery with our monorepo and without having to deploy the entire codebase on every change.
 Feature flags are created to ensure that we can safely rollout our work on our terms.
 If we use Feature Flags as a configuration, we are doing it wrong and are indeed in violation of our
 principles. If something needs to be configured, we should intentionally make it configuration from the
@@ -173,5 +173,5 @@ Some of the benefits of using development-type feature flags are:
 1. Improved throughput: when a change is less risky because a flag exists, theoretical tests about
    scalability can potentially become unnecessary or less important. This allows an engineer to
    potentially test a feature on a small project, monitor the impact, and proceed. The alternative might
-   be to build complex benchmarks locally, or on staging, or on another GitLab deployment, which has an
-   outsized impact on the time it can take to build and release a feature.
+   be to build complex benchmarks locally, or on staging, or on another GitLab deployment, which has a
+   large impact on the time it can take to build and release a feature.

doc/development/filtering_by_label.md

@@ -137,7 +137,7 @@ object, so the number of combinations would balloon further.
 
 ### Attempt B2: store label titles for each object
 
-From the perspective of updating the labelable object, this is the worst
+From the perspective of updating the object, this is the worst
 option. We have to bulk update the objects when:
 
 1. The objects are moved from one project to another.
@@ -159,7 +159,7 @@ However, at present, the disadvantages outweigh the advantages.
 
 ## Conclusion
 
-We have yet to find a method that is demonstratably better than the current
+We have yet to find a method that is demonstrably better than the current
 method, when considering:
 
 1. Query performance.

doc/development/gemfile.md

@@ -23,8 +23,8 @@ Refer to [licensing guidelines](licensing.md) for ensuring license compliance.
 
 When upgrading the Rails gem and its dependencies, you also should update the following:
 
-- The [Gemfile in the `qa` directory](https://gitlab.com/gitlab-org/gitlab/-/blob/master/qa/Gemfile).
-- The [Gemfile in Gitaly Ruby](https://gitlab.com/gitlab-org/gitaly/-/blob/master/ruby/Gemfile),
+- The [`Gemfile` in the `qa` directory](https://gitlab.com/gitlab-org/gitlab/-/blob/master/qa/Gemfile).
+- The [`Gemfile` in Gitaly Ruby](https://gitlab.com/gitlab-org/gitaly/-/blob/master/ruby/Gemfile),
   to ensure that we ship only one version of these gems.
 
 You should also update NPM packages that follow the current version of Rails:

doc/development/geo.md

@@ -305,7 +305,7 @@ events include:
 - Repositories Changed event
 - Repository Created event
 - Hashed Storage Migrated event
-- Lfs Object Deleted event
+- LFS Object Deleted event
 - Hashed Storage Attachments event
 - Job Artifact Deleted event
 - Upload Deleted event

doc/development/go_guide/dependencies.md

@@ -178,4 +178,4 @@ authenticate requests made over HTTP. Go rejects HTTP-only entries in
 `GOPROXY` that have embedded credentials.
 
 In a future version, Go may add support for arbitrary authentication headers.
-Follow [golang/go#26232](https://github.com/golang/go/issues/26232) for details.
+Follow [`golang/go#26232`](https://github.com/golang/go/issues/26232) for details.

doc/development/go_guide/index.md

@@ -63,10 +63,9 @@ of possible security breaches in our code:
 
 Remember to run
 [SAST](../../user/application_security/sast/index.md) and [Dependency Scanning](../../user/application_security/dependency_scanning/index.md)
-**(ULTIMATE)** on your project (or at least the [gosec
-analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/gosec)),
-and to follow our [Security
-requirements](../code_review.md#security-requirements).
+**(ULTIMATE)** on your project (or at least the
+[`gosec` analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/gosec)),
+and to follow our [Security requirements](../code_review.md#security-requirements).
 
 Web servers can take advantages of middlewares like [Secure](https://github.com/unrolled/secure).
 
@@ -92,9 +91,9 @@ projects:
 - Avoid global variables, even in packages. By doing so you introduce side
   effects if the package is included multiple times.
 - Use `goimports` before committing.
-  [goimports](https://godoc.org/golang.org/x/tools/cmd/goimports)
+  [`goimports`](https://godoc.org/golang.org/x/tools/cmd/goimports)
   is a tool that automatically formats Go source code using
-  [Gofmt](https://golang.org/cmd/gofmt/), in addition to formatting import lines,
+  [`Gofmt`](https://golang.org/cmd/gofmt/), in addition to formatting import lines,
   adding missing ones and removing unreferenced ones.
 
   Most editors/IDEs allow you to run commands before/after saving a file, you can set it
@@ -162,8 +161,8 @@ be downloaded repeatedly, which can lead to intermittent problems due to rate
 limiting or network failures. In these circumstances, you should [cache the
 downloaded code between](../../ci/caching/index.md#caching-go-dependencies).
 
-There was a [bug on modules
-checksums](https://github.com/golang/go/issues/29278) in Go < v1.11.4, so make
+There was a
+[bug on modules checksums](https://github.com/golang/go/issues/29278) in Go versions earlier than v1.11.4, so make
 sure to use at least this version to avoid `checksum mismatch` errors.
 
 ### ORM
@@ -171,7 +170,7 @@ sure to use at least this version to avoid `checksum mismatch` errors.
 We don't use object-relational mapping libraries (ORMs) at GitLab (except
 [ActiveRecord](https://guides.rubyonrails.org/active_record_basics.html) in
 Ruby on Rails). Projects can be structured with services to avoid them.
-[pgx](https://github.com/jackc/pgx) should be enough to interact with PostgreSQL
+[`pgx`](https://github.com/jackc/pgx) should be enough to interact with PostgreSQL
 databases.
 
 ### Migrations
@@ -193,7 +192,7 @@ external dependencies might be worth considering in case we decide to use a spec
 library or framework:
 
 - [Testify](https://github.com/stretchr/testify)
-- [httpexpect](https://github.com/gavv/httpexpect)
+- [`httpexpect`](https://github.com/gavv/httpexpect)
 
 ### Subtests
 
@@ -329,8 +328,8 @@ A few things to keep in mind when adding context:
 ## CLIs
 
 Every Go program is launched from the command line.
-[cli](https://github.com/urfave/cli) is a convenient package to create command
-line apps. It should be used whether the project is a daemon or a simple cli
+[`cli`](https://github.com/urfave/cli) is a convenient package to create command
+line apps. It should be used whether the project is a daemon or a simple CLI
 tool. Flags can be mapped to [environment
 variables](https://github.com/urfave/cli#values-from-the-environment) directly,
 which documents and centralizes at the same time all the possible command line
@@ -389,7 +388,7 @@ functionality:
 This gives us a thin abstraction over underlying implementations that is
 consistent across Workhorse, Gitaly, and, in future, other Go servers. For
 example, in the case of `gitlab.com/gitlab-org/labkit/tracing` we can switch
-from using Opentracing directly to using Zipkin or Gokit's own tracing wrapper
+from using `Opentracing` directly to using `Zipkin` or Gokit's own tracing wrapper
 without changes to the application code, while still keeping the same
 consistent configuration mechanism (i.e. the `GITLAB_TRACING` environment
 variable).
@@ -489,9 +488,9 @@ The following are some style guidelines that are specific to the Secure Team.
 ### Code style and format
 
 Use `goimports -local gitlab.com/gitlab-org` before committing.
-[goimports](https://godoc.org/golang.org/x/tools/cmd/goimports)
+[`goimports`](https://godoc.org/golang.org/x/tools/cmd/goimports)
 is a tool that automatically formats Go source code using
-[Gofmt](https://golang.org/cmd/gofmt/), in addition to formatting import lines,
+[`Gofmt`](https://golang.org/cmd/gofmt/), in addition to formatting import lines,
 adding missing ones and removing unreferenced ones.
 By using the `-local gitlab.com/gitlab-org` option, `goimports` groups locally referenced
 packages separately from external ones. See

doc/development/graphql_guide/batchloader.md

@@ -20,7 +20,7 @@ When implementing a new endpoint we should aim to minimise the number of SQL que
 
 Batch loading is useful when a series of queries for inputs `Qα, Qβ, ... Qω` can be combined to a single query for `Q[α, β, ... ω]`. An example of this is lookups by ID, where we can find two users by usernames as cheaply as one, but real-world examples can be more complex.
 
-Batchloading is not suitable when the result sets have different sort-orders, grouping, aggregation or other non-composable features.
+Batch loading is not suitable when the result sets have different sort-orders, grouping, aggregation or other non-composable features.
 
 There are two ways to use the batch-loader in your code. For simple ID lookups, use `::Gitlab::Graphql::Loaders::BatchModelLoader.new(model, id).find`. For more complex cases, you can use the batch API directly.
 

doc/development/i18n/merging_translations.md

@@ -66,12 +66,14 @@ have been fixed on master.
 NOTE:
 These instructions work only for GitLab Team Members.
 
-If for some reason the GitLab integration in CrowdIn does not exist, it can be
-recreated by the following steps:
-
-1. Sign in to GitLab as `gitlab-crowdin-bot` (If you're a GitLab Team Member, find credentials in the GitLab shared  [1Password account](https://about.gitlab.com/handbook/security/#1password-for-teams)
-1. Sign in to Crowdin with the GitLab integration
-1. Navigate to Settings > Integrations > GitLab > Set Up Integration
-1. Select `gitlab-org/gitlab` repository
-1. On `Select Branches for Translation`, select `master`
-1. Ensure the `Service Branch Name` is `master-i18n`
+If for some reason the GitLab integration in CrowdIn doesn't exist, you can
+recreate it with the following steps:
+
+1. Sign in to GitLab as `gitlab-crowdin-bot`. (If you're a GitLab Team Member,
+   find credentials in the GitLab shared
+   [1Password account](https://about.gitlab.com/handbook/security/#1password-for-teams).)
+1. Sign in to CrowdIn with the GitLab integration.
+1. Go to **Settings > Integrations > GitLab > Set Up Integration**.
+1. Select the `gitlab-org/gitlab` repository.
+1. In `Select Branches for Translation`, select `master`.
+1. Ensure the `Service Branch Name` is `master-i18n`.

doc/development/integrations/codesandbox.md

@@ -4,17 +4,17 @@ group: Development
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Set up local Codesandbox development environment
+# Set up local CodeSandbox development environment
 
-This guide walks through setting up a local [Codesandbox repository](https://github.com/codesandbox/codesandbox-client) and integrating it with a local GitLab instance. Codesandbox
-is used to power the Web IDE's [Live Preview feature](../../user/project/web_ide/index.md#live-preview). Having a local Codesandbox setup is useful for debugging upstream issues or
+This guide walks through setting up a local [CodeSandbox repository](https://github.com/codesandbox/codesandbox-client) and integrating it with a local GitLab instance. CodeSandbox
+is used to power the Web IDE's [Live Preview feature](../../user/project/web_ide/index.md#live-preview). Having a local CodeSandbox setup is useful for debugging upstream issues or
 creating upstream contributions like [this one](https://github.com/codesandbox/codesandbox-client/pull/5137).
 
 ## Initial setup
 
-Before using Codesandbox with your local GitLab instance, you must:
+Before using CodeSandbox with your local GitLab instance, you must:
 
-1. Enable HTTPS on your GDK. Codesandbox uses Service Workers that require `https`.
+1. Enable HTTPS on your GDK. CodeSandbox uses Service Workers that require `https`.
    Follow the GDK [NGINX configuration instructions](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/master/doc/howto/nginx.md) to enable HTTPS for GDK.
 1. Clone the [`codesandbox-client` project](https://github.com/codesandbox/codesandbox-client)
    locally. If you plan on contributing upstream, you might want to fork and clone first.
@@ -38,16 +38,16 @@ Before using Codesandbox with your local GitLab instance, you must:
 
    You can run `yarn build:clean` to clean up the build assets.
 
-## Use local GitLab instance with local Codesandbox
+## Use local GitLab instance with local CodeSandbox
 
-GitLab integrates with two parts of Codesandbox:
+GitLab integrates with two parts of CodeSandbox:
 
 - An NPM package called `smooshpack` (called `sandpack` in the `codesandbox-client` project).
   This exposes an entrypoint for us to kick off Codesandbox's bundler.
-- A server that houses Codesandbox assets for bundling and previewing. This is hosted
+- A server that houses CodeSandbox assets for bundling and previewing. This is hosted
   on a separate server for security.
 
-Each time you want to run GitLab and Codesandbox together, you need to perform the
+Each time you want to run GitLab and CodeSandbox together, you need to perform the
 steps in the following sections.
 
 ### Use local `smooshpack` for GitLab
@@ -94,7 +94,7 @@ mkdir node_modules
 ln -s $PATH_TO_LOCAL_GITLAB/node_modules/core-js ./node_modules/core-js
 ```
 
-### Start building codesandbox app assets
+### Start building CodeSandbox app assets
 
 In the `codesandbox-client` project directory:
 
@@ -104,7 +104,7 @@ cd packages/app
 yarn start:sandpack-sandbox
 ```
 
-### Create HTTPS proxy for Codesandbox `sandpack` assets
+### Create HTTPS proxy for CodeSandbox `sandpack` assets
 
 Because we need `https`, we need to create a proxy to the webpack server. We can use
 [`http-server`](https://www.npmjs.com/package/http-server), which can do this proxying
@@ -117,7 +117,7 @@ npx http-server --proxy http://localhost:3000 -S -C $PATH_TO_CERT_PEM -K $PATH_T
 ### Update `bundler_url` setting in GitLab
 
 We need to update our `application_setting_implementation.rb` to point to the server that hosts the
-Codesandbox `sandpack` assets. For instance, if these assets are hosted by a server at `https://sandpack.local:8044`:
+CodeSandbox `sandpack` assets. For instance, if these assets are hosted by a server at `https://sandpack.local:8044`:
 
 ```patch
 diff --git a/app/models/application_setting_implementation.rb b/app/models/application_setting_implementation.rb
@@ -139,7 +139,7 @@ index 6eed627b502..1824669e881 100644
 NOTE:
 You can apply this patch by copying it to your clipboard and running `pbpaste | git apply`.
 
-You'll might want to restart the GitLab Rails server after making this change:
+You may want to restart the GitLab Rails server after making this change:
 
 ```shell
 gdk restart rails-web

doc/development/packages.md

@@ -191,7 +191,7 @@ support is done by overriding a specific function in the API helpers, like
 For this authentication mechanism, keep in mind that some clients can send an unauthenticated
 request first, wait for the 401 Unauthorized response with the [`WWW-Authenticate`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate)
 field, then send an updated (authenticated) request. This case is more involved as
-GitLab needs to handle the 401 Unauthorized response. The [Nuget API](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/api/nuget_packages.rb)
+GitLab needs to handle the 401 Unauthorized response. The [NuGet API](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/api/nuget_packages.rb)
 supports this case.
 
 #### Authorization
@@ -245,8 +245,8 @@ in your local development environment.
 #### Rate Limits on GitLab.com
 
 Package manager clients can make rapid requests that exceed the
-[GitLab.com standard API rate limits](../user/gitlab_com/index.md#gitlabcom-specific-rate-limits). 
-This results in a `429 Too Many Requests` error. 
+[GitLab.com standard API rate limits](../user/gitlab_com/index.md#gitlabcom-specific-rate-limits).
+This results in a `429 Too Many Requests` error.
 
 We have opened a set of paths to allow higher rate limits. Unless it is not possible,
 new package managers should follow these conventions so they can take advantage of the

doc/development/performance.md

@@ -50,7 +50,7 @@ GitLab provides built-in tools to help improve performance and availability:
 - [Service measurement](service_measurement.md) for measuring and logging service execution.
 
 GitLab team members can use [GitLab.com's performance monitoring systems](https://about.gitlab.com/handbook/engineering/monitoring/) located at
-<https://dashboards.gitlab.net>, this requires you to log in using your
+[`dashboards.gitlab.net`](https://dashboards.gitlab.net), this requires you to log in using your
 `@gitlab.com` email address. Non-GitLab team-members are advised to set up their
 own Prometheus and Grafana stack.
 
@@ -176,7 +176,7 @@ stackprof tmp/project_policy_spec.rb.dump --graphviz > project_policy_spec.dot
 dot -Tsvg project_policy_spec.dot > project_policy_spec.svg
 ```
 
-To load the profile in [kcachegrind](https://kcachegrind.github.io/):
+To load the profile in [KCachegrind](https://kcachegrind.github.io/):
 
 ```shell
 stackprof tmp/project_policy_spec.rb.dump --callgrind > project_policy_spec.callgrind
@@ -184,7 +184,7 @@ kcachegrind project_policy_spec.callgrind # Linux
 qcachegrind project_policy_spec.callgrind # Mac
 ```
 
-For flamegraphs, enable raw collection first. Note that raw
+For flame graphs, enable raw collection first. Note that raw
 collection can generate a very large file, so increase the `INTERVAL`, or
 run on a smaller number of specs for smaller file size:
 
@@ -192,7 +192,7 @@ run on a smaller number of specs for smaller file size:
 RAW=true bin/rspec-stackprof spec/policies/group_member_policy_spec.rb
 ```
 
-You can then generate, and view the resultant flamegraph. It might take a
+You can then generate, and view the resultant flame graph. It might take a
 while to generate based on the output file size:
 
 ```shell
@@ -251,7 +251,7 @@ In order to enable production profiling for Ruby processes, you can set the `STA
 
 The following configuration options can be configured:
 
-- `STACKPROF_ENABLED`: Enables stackprof signal handler on SIGUSR2 signal.
+- `STACKPROF_ENABLED`: Enables Stackprof signal handler on SIGUSR2 signal.
   Defaults to `false`.
 - `STACKPROF_MODE`: See [sampling modes](https://github.com/tmm1/stackprof#sampling).
   Defaults to `cpu`.
@@ -264,7 +264,7 @@ The following configuration options can be configured:
 - `STACKPROF_TIMEOUT_S`: Profiling timeout in seconds. Profiling will
   automatically stop after this time has elapsed. Defaults to `30`.
 - `STACKPROF_RAW`: Whether to collect raw samples or only aggregates. Raw
-  samples are needed to generate flamegraphs, but they do have a higher memory
+  samples are needed to generate flame graphs, but they do have a higher memory
   and disk overhead. Defaults to `true`.
 
 Once enabled, profiling can be triggered by sending a `SIGUSR2` signal to the
@@ -287,7 +287,7 @@ The Puma master process is not supported. Neither is Unicorn.
 Sending SIGUSR2 to either of those triggers restarts. In the case of Puma,
 take care to only send the signal to Puma workers.
 
-This can be done via `pkill -USR2 puma:`. The `:` disambiguates between `puma
+This can be done via `pkill -USR2 puma:`. The `:` distinguishes between `puma
 4.3.3.gitlab.2 ...` (the master process) from `puma: cluster worker 0: ...` (the
 worker processes), selecting the latter.
 
@@ -296,7 +296,7 @@ For Sidekiq, the signal can be sent to the `sidekiq-cluster` process via `pkill
 children. Alternatively, you can also select a specific pid of interest.
 
 Production profiles can be especially noisy. It can be helpful to visualize them
-as a [flamegraph](https://github.com/brendangregg/FlameGraph). This can be done
+as a [flame graph](https://github.com/brendangregg/FlameGraph). This can be done
 via:
 
 ```shell
@@ -747,5 +747,4 @@ Assuming you are working with ActiveRecord models, you might also find these lin
 
 ### Examples
 
-You may find some useful examples in this snippet:
-<https://gitlab.com/gitlab-org/gitlab-foss/snippets/33946>
+You may find some useful examples in [this snippet](https://gitlab.com/gitlab-org/gitlab-foss/snippets/33946).

doc/development/pipelines.md

@@ -648,7 +648,7 @@ that are scoped to a single [configuration keyword](../ci/yaml/README.md#job-key
 |------------------|-------------|
 | `.default-retry` | Allows a job to [retry](../ci/yaml/README.md#retry) upon `unknown_failure`, `api_failure`, `runner_system_failure`, `job_execution_timeout`, or `stuck_or_timeout_failure`. |
 | `.default-before_script` | Allows a job to use a default `before_script` definition suitable for Ruby/Rails tasks that may need a database running (e.g. tests). |
-| `.setup-test-env-cache` | Allows a job to use a default `cache` definition suitable for setuping test environment for subsequent Ruby/Rails tasks. |
+| `.setup-test-env-cache` | Allows a job to use a default `cache` definition suitable for setting up test environment for subsequent Ruby/Rails tasks. |
 | `.rails-cache` | Allows a job to use a default `cache` definition suitable for Ruby/Rails tasks. |
 | `.static-analysis-cache` | Allows a job to use a default `cache` definition suitable for static analysis tasks. |
 | `.coverage-cache` | Allows a job to use a default `cache` definition suitable for coverage tasks. |

doc/development/stage_group_dashboards.md

@@ -61,7 +61,7 @@ Although most of the metrics displayed in the panels are self-explanatory in the
 
 To inspect the raw data of the panel for further calculation, click on the Inspect button from the dropdown menu of a panel. Queries, raw data, and panel JSON structure are available. Read more at [Grafana panel inspection](https://grafana.com/docs/grafana/latest/panels/inspect-panel/).
 
-All the dashboards are powered by [Grafana](https://grafana.com/), a frontend for displaying metrics. Grafana consumes the data returned from queries to backend Prometheus data source, then presents them under different visualizations. The stage group dashboards are built to serve the most common use cases with a limited set of filters, and pre-built queries. Grafana provides a way to explore and visualize the metrics data with [Grafana Explore](https://grafana.com/docs/grafana/latest/explore/). This would require some knowledge about [Prometheus Promql query language](https://prometheus.io/docs/prometheus/latest/querying/basics/).
+All the dashboards are powered by [Grafana](https://grafana.com/), a frontend for displaying metrics. Grafana consumes the data returned from queries to backend Prometheus data source, then presents them under different visualizations. The stage group dashboards are built to serve the most common use cases with a limited set of filters, and pre-built queries. Grafana provides a way to explore and visualize the metrics data with [Grafana Explore](https://grafana.com/docs/grafana/latest/explore/). This would require some knowledge about [Prometheus PromQL query language](https://prometheus.io/docs/prometheus/latest/querying/basics/).
 
 ## How to debug with the dashboards
 
@@ -83,7 +83,7 @@ All the dashboards are powered by [Grafana](https://grafana.com/), a frontend fo
 
 ## How to customize the dashboard
 
-All Grafana dashboards at GitLab are generated from the [Jsonnet files](https://github.com/grafana/grafonnet-lib) stored in [the runbook project](https://gitlab.com/gitlab-com/runbooks/-/tree/master/dashboards). Particularly, the stage group dashboards definitions are stored in [/dashboards/stage-groups](https://gitlab.com/gitlab-com/runbooks/-/tree/master/dashboards/stage-groups) subfolder in the Runbook. By convention, each group has a corresponding jsonnet file. The dashboards are synced with GitLab [stage group data](https://gitlab.com/gitlab-com/www-gitlab-com/-/raw/master/data/stages.yml) every month. Expansion and customization are one of the key principles used when we designed this system. To customize your group's dashboard, you need to edit the corresponding file and follow the [Runbook workflow](https://gitlab.com/gitlab-com/runbooks/-/tree/master/dashboards#dashboard-source). The dashboard is updated after the MR is merged. Looking at an autogenerated file, for example, [`product_planning.dashboard.jsonnet`](https://gitlab.com/gitlab-com/runbooks/-/blob/master/dashboards/stage-groups/product_planning.dashboard.jsonnet):
+All Grafana dashboards at GitLab are generated from the [Jsonnet files](https://github.com/grafana/grafonnet-lib) stored in [the runbook project](https://gitlab.com/gitlab-com/runbooks/-/tree/master/dashboards). Particularly, the stage group dashboards definitions are stored in [/dashboards/stage-groups](https://gitlab.com/gitlab-com/runbooks/-/tree/master/dashboards/stage-groups) subfolder in the Runbook. By convention, each group has a corresponding Jsonnet file. The dashboards are synced with GitLab [stage group data](https://gitlab.com/gitlab-com/www-gitlab-com/-/raw/master/data/stages.yml) every month. Expansion and customization are one of the key principles used when we designed this system. To customize your group's dashboard, you need to edit the corresponding file and follow the [Runbook workflow](https://gitlab.com/gitlab-com/runbooks/-/tree/master/dashboards#dashboard-source). The dashboard is updated after the MR is merged. Looking at an autogenerated file, for example, [`product_planning.dashboard.jsonnet`](https://gitlab.com/gitlab-com/runbooks/-/blob/master/dashboards/stage-groups/product_planning.dashboard.jsonnet):
 
 ```jsonnet
 // This file is autogenerated using scripts/update_stage_groups_dashboards.rb