Add latest changes from gitlab-org/gitlab@master

23 files changed, 57 insertions, 47 deletions

diff --git a/doc/administration/index.md b/doc/administration/index.md
index 1d8dcd34d68..762441ae2b5 100644
--- a/doc/administration/index.md
+++ b/doc/administration/index.md
@@ -120,7 +120,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 
 - [Creating users](../user/profile/account/create_accounts.md): Create users manually or through authentication integrations.
 - [Libravatar](libravatar.md): Use Libravatar instead of Gravatar for user avatars.
-- [Sign-up restrictions](../user/admin_area/settings/sign_up_restrictions.md): block email addresses of specific domains, or whitelist only specific domains.
+- [Sign-up restrictions](../user/admin_area/settings/sign_up_restrictions.md): block email addresses of specific domains, or allow only specific domains.
 - [Access restrictions](../user/admin_area/settings/visibility_and_access_controls.md#configure-enabled-git-access-protocols): Define which Git access protocols can be used to talk to GitLab (SSH, HTTP, HTTPS).
 - [Authentication and Authorization](auth/index.md): Configure external authentication with LDAP, SAML, CAS, and additional providers.
   - [Sync LDAP](auth/ldap/index.md)
diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index feed5a9bf3b..a574ae6c9bc 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -1170,7 +1170,7 @@ The flow described by the diagram above:
 
 1. A user runs `docker login registry.gitlab.example` on their client. This reaches the web server (or LB) on port 443.
 1. Web server connects to the Registry backend pool (by default, using port 5000). Since the user
-   didn’t provide a valid token, the Registry returns a 401 HTTP code and the URL (`token_realm` from
+   didn't provide a valid token, the Registry returns a 401 HTTP code and the URL (`token_realm` from
    Registry configuration) where to get one. This points to the GitLab API.
 1. The Docker client then connects to the GitLab API and obtains a token.
 1. The API signs the token with the registry key and hands it to the Docker client
diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md
index f144c60fcfe..375bf00389d 100644
--- a/doc/administration/pages/index.md
+++ b/doc/administration/pages/index.md
@@ -1187,7 +1187,8 @@ Rate limits are enforced using the following:
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues
 one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
+important to describe those, too. Think of things that may go wrong and include them in
+the section below.
 This is important to minimize requests for support, and to avoid doc comments with
 questions that you know someone might ask.
 
@@ -1541,7 +1542,7 @@ In GitLab 14.0-14.2 you can temporarily enable legacy storage and configuration
 
 To do that:
 
-1. Please describe the issue you're seeing in [here](https://gitlab.com/gitlab-org/gitlab/-/issues/331699).
+1. Please describe the issue you're seeing in the [migration feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/331699).
 
 1. Edit `/etc/gitlab/gitlab.rb`:
 
diff --git a/doc/administration/reference_architectures/1k_users.md b/doc/administration/reference_architectures/1k_users.md
index 8d5afd732d9..108dc162ebd 100644
--- a/doc/administration/reference_architectures/1k_users.md
+++ b/doc/administration/reference_architectures/1k_users.md
@@ -62,7 +62,7 @@ monitor .[#7FFFD4,norank]--> redis
 @enduml
 ```
 
-The diagram above shows that while GitLab can be installed on a single server, it is internally composed of multiple services. As a GitLab instance is scaled, each of these services are broken out and independently scaled according to the demands placed on them. In some cases PaaS can be leveraged for some services (e.g. Cloud Object Storage for some file systems). For the sake of redundancy some of the services become clusters of nodes storing the same data. In a horizontal configuration of GitLab there are various ancillary services required to coordinate clusters or discover of resources (e.g. PgBouncer for PostgreSQL connection management, Consul for Prometheus end point discovery).
+The diagram above shows that while GitLab can be installed on a single server, it is internally composed of multiple services. As a GitLab instance is scaled, each of these services are broken out and independently scaled according to the demands placed on them. In some cases PaaS can be leveraged for some services (for example, Cloud Object Storage for some file systems). For the sake of redundancy some of the services become clusters of nodes storing the same data. In a horizontal configuration of GitLab there are various ancillary services required to coordinate clusters or discover of resources (for example, PgBouncer for PostgreSQL connection management, Consul for Prometheus end point discovery).
 
 ## Requirements
 
diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md
index 3da5af08a13..aece904787a 100644
--- a/doc/administration/reference_architectures/index.md
+++ b/doc/administration/reference_architectures/index.md
@@ -116,7 +116,7 @@ per 1,000 users:
 ### How to interpret the results
 
 NOTE:
-Read our blog post on [how our QA team leverages GitLab’s performance testing tool](https://about.gitlab.com/blog/2020/02/18/how-were-building-up-performance-testing-of-gitlab/).
+Read our blog post on [how our QA team leverages GitLab performance testing tool](https://about.gitlab.com/blog/2020/02/18/how-were-building-up-performance-testing-of-gitlab/).
 
 Testing is done publicly and all results are shared.
 
diff --git a/doc/api/environments.md b/doc/api/environments.md
index bfc097d44ee..a806d8a50dd 100644
--- a/doc/api/environments.md
+++ b/doc/api/environments.md
@@ -15,12 +15,12 @@ Get all environments for a given project.
 GET /projects/:id/environments
 ```
 
-| Attribute | Type    | Required | Description           |
-| --------- | ------- | -------- | --------------------- |
-| `id`      | integer/string | yes      | The ID or [URL-encoded path of the project](index.md#namespaced-path-encoding) owned by the authenticated user |
-| `name`    | string  | no       | Return the environment with this name. Mutually exclusive with `search` |
-| `search`  | string  | no       | Return list of environments matching the search criteria. Mutually exclusive with `name` |
-| `states`  | string  | no       | List all environments that match a specific state. Accepted values: `available` or `stopped`. If no state value given, returns all environments. |
+| Attribute | Type    | Required | Description                                                                                                                                                 |
+| --------- | ------- | -------- |-------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `id`      | integer/string | yes      | The ID or [URL-encoded path of the project](index.md#namespaced-path-encoding) owned by the authenticated user                                              |
+| `name`    | string  | no       | Return the environment with this name. Mutually exclusive with `search`                                                                                     |
+| `search`  | string  | no       | Return list of environments matching the search criteria. Mutually exclusive with `name`                                                                    |
+| `states`  | string  | no       | List all environments that match a specific state. Accepted values: `available`, `stopping` or `stopped`. If no state value given, returns all environments. |
 
 ```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/environments?name=review%2Ffix-foo"
@@ -382,10 +382,11 @@ It returns `200` if the environment was successfully stopped, and `404` if the e
 POST /projects/:id/environments/:environment_id/stop
 ```
 
-| Attribute | Type    | Required | Description           |
-| --------- | ------- | -------- | --------------------- |
-| `id` | integer/string | yes | The ID or [URL-encoded path of the project](index.md#namespaced-path-encoding) owned by the authenticated user |
-| `environment_id` | integer | yes | The ID of the environment |
+| Attribute        | Type           | Required | Description                                                                                                    |
+|------------------|----------------|----------|----------------------------------------------------------------------------------------------------------------|
+| `id`             | integer/string | yes      | The ID or [URL-encoded path of the project](index.md#namespaced-path-encoding) owned by the authenticated user |
+| `environment_id` | integer        | yes      | The ID of the environment                                                                                      |
+| `force`          | boolean        | no       | Force environment to stop even when `on_stop` action fails                                                     |
 
 ```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/environments/1/stop"
diff --git a/doc/api/project_snippets.md b/doc/api/project_snippets.md
index 90bd2cd6f83..0429c8abe3c 100644
--- a/doc/api/project_snippets.md
+++ b/doc/api/project_snippets.md
@@ -234,8 +234,8 @@ Parameters:
 |:-------------|:---------------|:---------|:----------------------------------------------------------------------------------------------------------------|
 | `id`         | integer or string | yes      | The ID or [URL-encoded path of the project](index.md#namespaced-path-encoding) owned by the authenticated user |
 | `snippet_id` | integer        | yes      | The ID of a project's snippet                                                                                   |
-| `ref`        | string         | yes      | The name of a branch, tag or commit e.g. master                                                                 |
-| `file_path`  | string         | yes      | The URL-encoded path to the file, e.g. snippet%2Erb                                                             |
+| `ref`        | string         | yes      | The name of a branch, tag or commit, for example, main                                                          |
+| `file_path`  | string         | yes      | The URL-encoded path to the file, for example, snippet%2Erb                                                     |
 
 Example request:
 
diff --git a/doc/ci/pipelines/cicd_minutes.md b/doc/ci/pipelines/cicd_minutes.md
index 55a81933e82..ec7d64107fd 100644
--- a/doc/ci/pipelines/cicd_minutes.md
+++ b/doc/ci/pipelines/cicd_minutes.md
@@ -90,6 +90,10 @@ To view CI/CD minutes being used for your group:
 
 ![Group CI/CD minutes quota](img/group_cicd_minutes_quota.png)
 
+The projects list shows projects with CI/CD minute usage or shared runners usage
+in the current month only. The list includes all projects in the namespace and its
+subgroups, sorted in descending order of CI/CD minute usage.
+
 ## View CI/CD minutes used by a personal namespace
 
 > Displaying shared runners duration [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/345795) in GitLab 15.0.
@@ -100,6 +104,10 @@ You can view the number of CI/CD minutes being used by a personal namespace:
 1. Select **Edit profile**.
 1. On the left sidebar, select **Usage Quotas**.
 
+The projects list shows [personal projects](../../user/project/working_with_projects.md#view-personal-projects)
+with CI/CD minutes usage or shared runners usage in the current month only. The list
+is sorted in descending order of CI/CD minute usage.
+
 ## Purchase additional CI/CD minutes **(FREE SAAS)**
 
 If you're using GitLab SaaS, you can purchase additional packs of CI/CD minutes.
diff --git a/doc/ci/pipelines/merge_trains.md b/doc/ci/pipelines/merge_trains.md
index d200dde143c..e0fe59d1ab8 100644
--- a/doc/ci/pipelines/merge_trains.md
+++ b/doc/ci/pipelines/merge_trains.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9186) in GitLab 12.0.
 > - [Squash and merge](../../user/project/merge_requests/squash_and_merge.md) support [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13001) in GitLab 12.6.
 
-For more information about why you might want to use merge trains, read [How merge trains keep your master green](https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-trains/).
+For more information about why you might want to use merge trains, read [How starting merge trains improve efficiency for DevOps](https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-trains/).
 
 When [merged results pipelines](merged_results_pipelines.md) are
 enabled, the pipeline jobs run as if the changes from your source branch have already
diff --git a/doc/development/contributing/verify/index.md b/doc/development/contributing/verify/index.md
index 88f9944dea1..58285877b48 100644
--- a/doc/development/contributing/verify/index.md
+++ b/doc/development/contributing/verify/index.md
@@ -53,7 +53,7 @@ and they serve us and our users well. Some examples of these principles are that
 - The feedback delivered by GitLab CI/CD and data produced by the platform should be accurate.
   If a job fails and we notify a user that it was successful, it can have severe negative consequences.
 - Feedback needs to be available when a user needs it and data can not disappear unexpectedly when engineers need it.
-- It all doesn’t matter if the platform is not secure and we
+- It all doesn't matter if the platform is not secure and we
 are leaking credentials or secrets.
 - When a user provides a set of preconditions in a form of CI/CD configuration, the result should be deterministic each time a pipeline runs, because otherwise the platform might not be trustworthy.
 - If it is fast, simple to use and has a great UX it will serve our users well.
diff --git a/doc/development/pipelines.md b/doc/development/pipelines.md
index b70f07ea7d9..4e79f57ae9f 100644
--- a/doc/development/pipelines.md
+++ b/doc/development/pipelines.md
@@ -67,9 +67,9 @@ In the `detect-tests` job, we use this mapping to identify the minimal tests nee
 In addition, there are a few circumstances where we would always run the full RSpec tests:
 
 - when the `pipeline:run-all-rspec` label is set on the merge request
-- when the merge request is created by an automation (e.g. Gitaly update or MR targeting a stable branch)
+- when the merge request is created by an automation (for example, Gitaly update or MR targeting a stable branch)
 - when the merge request is created in a security mirror
-- when any CI configuration file is changed (i.e. `.gitlab-ci.yml` or `.gitlab/ci/**/*`)
+- when any CI configuration file is changed (for example, `.gitlab-ci.yml` or `.gitlab/ci/**/*`)
 
 ### Jest minimal jobs
 
@@ -83,11 +83,11 @@ In this mode, `jest` would resolve all the dependencies of related to the change
 In addition, there are a few circumstances where we would always run the full Jest tests:
 
 - when the `pipeline:run-all-jest` label is set on the merge request
-- when the merge request is created by an automation (e.g. Gitaly update or MR targeting a stable branch)
+- when the merge request is created by an automation (for example, Gitaly update or MR targeting a stable branch)
 - when the merge request is created in a security mirror
-- when any CI configuration file is changed (i.e. `.gitlab-ci.yml` or `.gitlab/ci/**/*`)
-- when any frontend "core" file is changed (i.e. `package.json`, `yarn.lock`, `babel.config.js`, `jest.config.*.js`, `config/helpers/**/*.js`)
-- when any vendored JavaScript file is changed (i.e. `vendor/assets/javascripts/**/*`)
+- when any CI configuration file is changed (for example, `.gitlab-ci.yml` or `.gitlab/ci/**/*`)
+- when any frontend "core" file is changed (for example, `package.json`, `yarn.lock`, `babel.config.js`, `jest.config.*.js`, `config/helpers/**/*.js`)
+- when any vendored JavaScript file is changed (for example, `vendor/assets/javascripts/**/*`)
 - when any backend file is changed ([see the patterns list for details](https://gitlab.com/gitlab-org/gitlab/-/blob/3616946936c1adbd9e754c1bd06f86ba670796d8/.gitlab/ci/rules.gitlab-ci.yml#L205-216))
 
 ### Fork pipelines
@@ -226,7 +226,7 @@ of `gitlab-org/gitlab-foss`. These jobs are only created in the following cases:
 
 - when the `pipeline:run-as-if-foss` label is set on the merge request
 - when the merge request is created in the `gitlab-org/security/gitlab` project
-- when any CI configuration file is changed (i.e. `.gitlab-ci.yml` or `.gitlab/ci/**/*`)
+- when any CI configuration file is changed (for example, `.gitlab-ci.yml` or `.gitlab/ci/**/*`)
 
 The `* as-if-foss` jobs are run in addition to the regular EE-context jobs. They have the `FOSS_ONLY='1'` variable
 set and get the `ee/` folder removed before the tests start running.
@@ -339,7 +339,7 @@ In general, pipelines for an MR fall into one of the following types (from short
 - [Frontend pipeline](#frontend-pipeline): For MRs that touch frontend code.
 - [End-to-end pipeline](#end-to-end-pipeline): For MRs that touch code in the `qa/` folder.
 
-A "pipeline type" is an abstract term that mostly describes the "critical path" (i.e. the chain of jobs for which the sum
+A "pipeline type" is an abstract term that mostly describes the "critical path" (for example, the chain of jobs for which the sum
 of individual duration equals the pipeline's duration).
 We use these "pipeline types" in [metrics dashboards](https://app.periscopedata.com/app/gitlab/858266/GitLab-Pipeline-Durations)
 in order to detect what types and jobs need to be optimized first.
@@ -719,11 +719,11 @@ This job tries to download a generic package that contains GitLab Workhorse bina
 We also changed the `setup-test-env` job to:
 
 1. First download the GitLab Workhorse generic package build and uploaded by `build-components`.
-1. If the package is retrieved successfully, its content is placed in the right folder (i.e. `tmp/tests/gitlab-workhorse`), preventing the building of the binaries when `scripts/setup-test-env` is run later on.
+1. If the package is retrieved successfully, its content is placed in the right folder (for example, `tmp/tests/gitlab-workhorse`), preventing the building of the binaries when `scripts/setup-test-env` is run later on.
 1. If the package URL returns a 404, the behavior doesn't change compared to the current one: the GitLab Workhorse binaries are built as part of `scripts/setup-test-env`.
 
 NOTE:
-The version of the package is the workhorse tree SHA (i.e. `git rev-parse HEAD:workhorse`).
+The version of the package is the workhorse tree SHA (for example, `git rev-parse HEAD:workhorse`).
 
 ### Pre-clone step
 
diff --git a/doc/development/query_count_limits.md b/doc/development/query_count_limits.md
index fec6f9022ee..49509727337 100644
--- a/doc/development/query_count_limits.md
+++ b/doc/development/query_count_limits.md
@@ -58,7 +58,7 @@ By using a `before_action` you don't have to modify the controller method in
 question, reducing the likelihood of merge conflicts.
 
 For Grape API endpoints there unfortunately is not a reliable way of running a
-hook before a specific endpoint. This means that you have to add the whitelist
+hook before a specific endpoint. This means that you have to add the allowlist
 call directly into the endpoint like so:
 
 ```ruby
diff --git a/doc/development/rails_initializers.md b/doc/development/rails_initializers.md
index 9bf4109f1cb..c1e3d0c4f22 100644
--- a/doc/development/rails_initializers.md
+++ b/doc/development/rails_initializers.md
@@ -24,7 +24,7 @@ Some examples where you would need to do this are:
 ## Database connections in initializers
 
 Ideally, database connections are not opened from Rails initializers. Opening a
-database connection (e.g. checking the database exists, or making a database
+database connection (for example, checking the database exists, or making a database
 query) from an initializer means that tasks like `db:drop`, and
 `db:test:prepare` will fail because an active session prevents the database from
 being dropped.
diff --git a/doc/development/routing.md b/doc/development/routing.md
index 41961c2288f..2b3ecd8127b 100644
--- a/doc/development/routing.md
+++ b/doc/development/routing.md
@@ -104,6 +104,6 @@ To get started, see an [example merge request](https://gitlab.com/gitlab-org/git
 
 ## Useful links
 
-- [Routing improvements master plan](https://gitlab.com/gitlab-org/gitlab/-/issues/215362)
+- [Routing improvements main plan](https://gitlab.com/gitlab-org/gitlab/-/issues/215362)
 - [Scoped routing explained](https://gitlab.com/gitlab-org/gitlab/-/issues/214217)
 - [Removal of deprecated routes](https://gitlab.com/gitlab-org/gitlab/-/issues/28848)
diff --git a/doc/development/secure_coding_guidelines.md b/doc/development/secure_coding_guidelines.md
index b41c440c111..d8e2352bd93 100644
--- a/doc/development/secure_coding_guidelines.md
+++ b/doc/development/secure_coding_guidelines.md
@@ -698,7 +698,7 @@ tls.Config{
 }
 ```
 
-This example was taken [here](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/871b52dc700f1a66f6644fbb1e78a6d463a6ff83/internal/tool/tlstool/tlstool.go#L72).
+This example was taken [from the GitLab Agent](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/871b52dc700f1a66f6644fbb1e78a6d463a6ff83/internal/tool/tlstool/tlstool.go#L72).
 
 For **Ruby**, you can use again [`HTTParty`](https://github.com/jnunemaker/httparty) and specify this time TLS 1.2 version alongside with the recommended ciphers:
 
diff --git a/doc/development/service_ping/index.md b/doc/development/service_ping/index.md
index 1e09dada36e..e776b78b710 100644
--- a/doc/development/service_ping/index.md
+++ b/doc/development/service_ping/index.md
@@ -464,7 +464,7 @@ To generate Service Ping, use [Teleport](https://goteleport.com/docs/) or a deta
 
 1. Get the metrics duration from logs:
 
-Search in Google Console logs for `time_elapsed`. Query example [here](https://cloudlogging.app.goo.gl/nWheZvD8D3nWazNe6).
+Search in Google Console logs for `time_elapsed`. [Query example](https://cloudlogging.app.goo.gl/nWheZvD8D3nWazNe6).
 
 ### Verification (After approx 30 hours)
 
diff --git a/doc/development/testing_guide/end_to_end/resources.md b/doc/development/testing_guide/end_to_end/resources.md
index e2b005d8a1b..dacc428aec6 100644
--- a/doc/development/testing_guide/end_to_end/resources.md
+++ b/doc/development/testing_guide/end_to_end/resources.md
@@ -531,7 +531,7 @@ When you implement a new type of reusable resource there are two `private` metho
 can be validated. They are:
 
 - `reference_resource`: creates a new instance of the resource that can be compared with the one that was used during the tests.
-- `unique_identifiers`: returns an array of attributes that allow the resource to be identified (e.g., name) and that are therefore
+- `unique_identifiers`: returns an array of attributes that allow the resource to be identified (for example, name) and that are therefore
 expected to differ when comparing the reference resource with the resource reused in the tests.
 
 The following example shows the implementation of those two methods in `QA::Resource::ReusableProject`.
diff --git a/doc/install/installation.md b/doc/install/installation.md
index e53ced6c88a..ea1bffe91b0 100644
--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -211,7 +211,7 @@ sudo apt-get install -y libimage-exiftool-perl
 ## 2. Ruby
 
 The Ruby interpreter is required to run GitLab.
-See the [requirements section of this page](#software-requirements) for the minimum
+See the [requirements section](#software-requirements) for the minimum
 Ruby requirements.
 
 The use of Ruby version managers such as [`RVM`](https://rvm.io/), [`rbenv`](https://github.com/rbenv/rbenv) or [`chruby`](https://github.com/postmodern/chruby) with GitLab
diff --git a/doc/subscriptions/index.md b/doc/subscriptions/index.md
index 05fd302d6ee..16bc70792ff 100644
--- a/doc/subscriptions/index.md
+++ b/doc/subscriptions/index.md
@@ -192,9 +192,9 @@ If you have any questions, send an email to `opensource@gitlab.com` for assistan
 
 GitLab for Open Source Program benefits apply to an entire GitLab namespace. To qualify for the GitLab for Open Source Program, **all projects in an applicant's namespace** must carry an [OSI-approved license](https://opensource.org/licenses/).
 
-To add a license: 
+To add a license:
 
-1. On the top bar, select **Menu > Projects** and find your project. 
+1. On the top bar, select **Menu > Projects** and find your project.
 1. On the overview page, select **Add LICENSE**. If the license you want is not available as a license template, manually copy the entire, unaltered [text of your chosen license](https://opensource.org/licenses/alphabetical) into the `LICENSE` file. Note that GitLab defaults to **All rights reserved** if users do not perform this action.
 
 Applicants must add the correct license to each project in their respective groups or namespaces When you're sure you're using OSI-approved licenses for your projects, you can take your screenshots.
@@ -229,7 +229,7 @@ Benefits of the GitLab Open Source Program apply to all projects in a GitLab nam
 
 To be eligible for the GitLab Open Source Program, projects must be publicly visible. To check your project's public visibility settings:
 
-1. On the top bar, select **Menu > Projects** and find your project. 
+1. On the top bar, select **Menu > Projects** and find your project.
 1. From the left sidebar, select **Settings > General**.
 1. Expand **Visibility, project features, permissions**.
 1. From the **Project visibility** dropdown list, select **Public**.
diff --git a/doc/update/zero_downtime.md b/doc/update/zero_downtime.md
index 99457ef98d6..4dd916209a2 100644
--- a/doc/update/zero_downtime.md
+++ b/doc/update/zero_downtime.md
@@ -589,7 +589,7 @@ You can only upgrade one minor release at a time.
 
 This section describes the steps required to upgrade a multi-node / HA
 deployment with Geo. Some steps must be performed on a particular node. This
-node is known as the “deploy node” and is noted through the following
+node is known as the "deploy node" and is noted through the following
 instructions.
 
 Updates must be performed in the following order:
diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md
index ce637530487..d1374cf17be 100644
--- a/doc/user/application_security/dependency_scanning/index.md
+++ b/doc/user/application_security/dependency_scanning/index.md
@@ -95,7 +95,7 @@ is **not** `19.03.0`. See [troubleshooting information](#error-response-from-dae
 
 WARNING:
 Dependency Scanning does not support run-time installation of compilers and interpreters.
-If you have need of this, please explain why by filling out the survey [here](https://docs.google.com/forms/d/e/1FAIpQLScKo7xEYA65rOjPTGIufAyfjPGnCALSJZoTxBlvskfFMEOZMw/viewform).
+If you need it, please explain why by filling out [the survey](https://docs.google.com/forms/d/e/1FAIpQLScKo7xEYA65rOjPTGIufAyfjPGnCALSJZoTxBlvskfFMEOZMw/viewform).
 
 ## Supported languages and package managers
 
@@ -1225,7 +1225,7 @@ version `58.1.0+`, which doesn't support `2to3`. Therefore, a `setuptools` depen
 error in <dependency name> setup command: use_2to3 is invalid
 ```
 
-To work around this error, downgrade the analyzer's version of `setuptools` (e.g. `v57.5.0`):
+To work around this error, downgrade the analyzer's version of `setuptools` (for example, `v57.5.0`):
 
 ```yaml
 gemnasium-python-dependency_scanning:
diff --git a/doc/user/clusters/agent/install/index.md b/doc/user/clusters/agent/install/index.md
index f747c6c0e25..fe408e30320 100644
--- a/doc/user/clusters/agent/install/index.md
+++ b/doc/user/clusters/agent/install/index.md
@@ -136,13 +136,13 @@ GitLab also provides a [KPT package for the agent](https://gitlab.com/gitlab-org
 
 To install a second agent in your cluster, you can follow the [previous steps](#register-the-agent-with-gitlab) a second time. To avoid resource name collisions within the cluster, you must either:
 
-- Use a different release name for the agent, e.g. `second-gitlab-agent`:
+- Use a different release name for the agent, for example, `second-gitlab-agent`:
 
   ```shell
   helm upgrade --install second-gitlab-agent gitlab/gitlab-agent ...
   ```
 
-- Or, install the agent in a different namespace, e.g. `different-namespace`:
+- Or, install the agent in a different namespace, for example, `different-namespace`:
 
   ```shell
   helm upgrade --install gitlab-agent gitlab/gitlab-agent \
@@ -163,7 +163,7 @@ The following example projects can help you get started with the agent.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/340882) in GitLab 14.8, GitLab warns you on the agent's list page to update the agent version installed on your cluster.
 
-For the best experience, the version of the agent installed in your cluster should match the GitLab major and minor version. The previous minor version is also supported. For example, if your GitLab version is v14.9.4 (major version 14, minor version 9), then versions v14.9.0 and v14.9.1 of the agent are ideal, but any v14.8.x version of the agent is also supported. See [this page](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/releases) of releases of the GitLab agent.
+For the best experience, the version of the agent installed in your cluster should match the GitLab major and minor version. The previous minor version is also supported. For example, if your GitLab version is v14.9.4 (major version 14, minor version 9), then versions v14.9.0 and v14.9.1 of the agent are ideal, but any v14.8.x version of the agent is also supported. See [the release page](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/releases) of the GitLab agent.
 
 ### Update the agent version
 
diff --git a/doc/user/profile/preferences.md b/doc/user/profile/preferences.md
index c654eb2b0e8..e99a2dad980 100644
--- a/doc/user/profile/preferences.md
+++ b/doc/user/profile/preferences.md
@@ -91,7 +91,7 @@ Introduced in GitLab 13.6, the themes [Solarized](https://gitlab.com/gitlab-org/
 
 ## Diff colors
 
-A diff compares the old/removed content with the new/added content (e.g. when
+A diff compares the old/removed content with the new/added content (for example, when
 [reviewing a merge request](../project/merge_requests/reviews/index.md#review-a-merge-request) or in a
 [Markdown inline diff](../markdown.md#inline-diff)).
 Typically, the colors red and green are used for removed and added lines in diffs.