Add latest changes from gitlab-org/gitlab@master

30 files changed, 109 insertions, 76 deletions

diff --git a/doc/administration/consul.md b/doc/administration/consul.md
index e1f2bd90e05..5a6358be0f9 100644
--- a/doc/administration/consul.md
+++ b/doc/administration/consul.md
@@ -80,13 +80,13 @@ Nodes should be:
 - Upgraded one node at a time.
 
 Identify any existing health issues in the cluster by running the following command
-within each node. The command will return an empty array if the cluster is healthy:
+within each node. The command returns an empty array if the cluster is healthy:
 
 ```shell
 curl "http://127.0.0.1:8500/v1/health/state/critical"
 ```
 
-If the Consul version has changed, you'll see a notice at the end of `gitlab-ctl reconfigure`
+If the Consul version has changed, you see a notice at the end of `gitlab-ctl reconfigure`
 informing you that Consul needs to be restarted for the new version to be used.
 
 Restart Consul one node at a time:
@@ -149,7 +149,7 @@ To be safe, it's recommended that you only restart Consul in one node at a time
 ensure the cluster remains intact. For larger clusters, it is possible to restart
 multiple nodes at a time. See the
 [Consul consensus document](https://www.consul.io/docs/architecture/consensus#deployment-table)
-for the number of failures it can tolerate. This will be the number of simultaneous
+for the number of failures it can tolerate. This is the number of simultaneous
 restarts it can sustain.
 
 To restart Consul:
diff --git a/doc/administration/housekeeping.md b/doc/administration/housekeeping.md
index 93409b54c0d..31b7ac9fd3e 100644
--- a/doc/administration/housekeeping.md
+++ b/doc/administration/housekeeping.md
@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Housekeeping **(FREE SELF)**
 
-GitLab supports and automates housekeeping tasks within your current repository such as:
+GitLab supports and automates housekeeping tasks in your current repository such as:
 
 - Compressing Git objects.
 - Removing unreachable objects.
diff --git a/doc/administration/instance_limits.md b/doc/administration/instance_limits.md
index 09f61e57b9e..5149d97e36c 100644
--- a/doc/administration/instance_limits.md
+++ b/doc/administration/instance_limits.md
@@ -7,7 +7,7 @@ type: reference
 
 # GitLab application limits **(FREE SELF)**
 
-GitLab, like most large applications, enforces limits within certain features to maintain a
+GitLab, like most large applications, enforces limits in certain features to maintain a
 minimum quality of performance. Allowing some features to be limitless could affect security,
 performance, data, or could even exhaust the allocated resources for the application.
 
@@ -309,7 +309,7 @@ Blocked recursive webhook calls are logged in `auth.log` with the message `"Recu
 The [minimum wait time between pull refreshes](../user/project/repository/mirror/index.md)
 defaults to 300 seconds (5 minutes). For example, a pull refresh only runs once in a given 300 second period, regardless of how many times you trigger it.
 
-This setting applies in the context of pull refreshes invoked via the [projects API](../api/projects.md#start-the-pull-mirroring-process-for-a-project), or when forcing an update by selecting the **Update now** (**{retry}**) button within **Settings > Repository > Mirroring repositories**. This setting has no effect on the automatic 30 minute interval schedule used by Sidekiq for [pull mirroring](../user/project/repository/mirror/pull.md).
+This setting applies in the context of pull refreshes invoked via the [projects API](../api/projects.md#start-the-pull-mirroring-process-for-a-project), or when forcing an update by selecting **Update now** (**{retry}**) in **Settings > Repository > Mirroring repositories**. This setting has no effect on the automatic 30 minute interval schedule used by Sidekiq for [pull mirroring](../user/project/repository/mirror/pull.md).
 
 To change this limit for a self-managed installation, run the following in the
 [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
@@ -342,7 +342,7 @@ and to limit memory consumption.
 When using offset-based pagination in the REST API, there is a limit to the maximum
 requested offset into the set of results. This limit is only applied to endpoints that
 support keyset-based pagination. More information about pagination options can be
-found in the [API docs section on pagination](../api/index.md#pagination).
+found in the [API documentation section on pagination](../api/index.md#pagination).
 
 To set this limit for a self-managed installation, run the following in the
 [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
@@ -944,7 +944,7 @@ The maximum allowed [push size](../user/admin_area/settings/account_and_limit_se
 Total number of changes (branches or tags) in a single push. If changes are more
 than the specified limit, hooks are not executed.
 
-More information can be found in these docs:
+More information can be found in these documentations:
 
 - [Webhooks push events](../user/project/integrations/webhook_events.md#push-events)
 - [Project services push hooks limit](../user/project/integrations/index.md#push-hooks-limit)
@@ -1040,7 +1040,7 @@ In addition to application-based limits, GitLab.com is configured to use Cloudfl
 
 ## Container Repository tag deletion limit
 
-Container repository tags are in the Container Registry and, as such, each tag deletion will trigger network requests to the Container Registry. Because of this, we limit the number of tags that a single API call can delete to 20.
+Container repository tags are in the Container Registry and, as such, each tag deletion triggers network requests to the Container Registry. Because of this, we limit the number of tags that a single API call can delete to 20.
 
 ## Project-level Secure Files API limits
 
diff --git a/doc/administration/monitoring/prometheus/web_exporter.md b/doc/administration/monitoring/prometheus/web_exporter.md
index f3ad826565c..fe140b15ed2 100644
--- a/doc/administration/monitoring/prometheus/web_exporter.md
+++ b/doc/administration/monitoring/prometheus/web_exporter.md
@@ -54,6 +54,8 @@ Metrics can now be served and scraped from `localhost:8083/metrics`.
 
 ## Enable HTTPS
 
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/364771) in GitLab 15.2.
+
 To serve metrics via HTTPS instead of HTTP, enable TLS in the exporter settings:
 
 1. Edit `/etc/gitlab/gitlab.rb` to add (or find and uncomment) the following lines:
diff --git a/doc/administration/operations/extra_sidekiq_routing.md b/doc/administration/operations/extra_sidekiq_routing.md
index 2a14fa1d312..792d142cd95 100644
--- a/doc/administration/operations/extra_sidekiq_routing.md
+++ b/doc/administration/operations/extra_sidekiq_routing.md
@@ -137,7 +137,7 @@ GitLab Enterprise Edition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee
 to lowest precedence:
 
 - `|` - the logical `OR` operator. For example, `query_a|query_b` (where `query_a`
-  and `query_b` are queries made up of the other operators here) will include
+  and `query_b` are queries made up of the other operators here) includes
   queues that match either query.
 - `&` - the logical `AND` operator. For example, `query_a&query_b` (where
   `query_a` and `query_b` are queries made up of the other operators here) will
@@ -181,7 +181,7 @@ sidekiq['routing_rules'] = [
 ]
 ```
 
-These queues will also need to be included in at least one [Sidekiq
+These queues must also be included in at least one [Sidekiq
 queue group](extra_sidekiq_processes.md#start-multiple-processes).
 
 The following table shows the workers that should have their own queue:
diff --git a/doc/administration/operations/index.md b/doc/administration/operations/index.md
index fe531407eb2..97b9c4b8c42 100644
--- a/doc/administration/operations/index.md
+++ b/doc/administration/operations/index.md
@@ -24,7 +24,7 @@ Keep your GitLab instance up and running smoothly.
   of SSH certificates](ssh_certificates.md).
 - [File System Performance Benchmarking](filesystem_benchmarking.md): File system
   performance can have a big impact on GitLab performance, especially for actions
-  that read or write Git repositories. This information will help benchmark
+  that read or write Git repositories. This information helps benchmark
   file system performance against known good and bad real-world systems.
 - [The Rails Console](rails_console.md): Provides a way to interact with your GitLab instance from the command line.
   Used for troubleshooting a problem or retrieving some data that can only be done through direct access to GitLab.
diff --git a/doc/administration/operations/ssh_certificates.md b/doc/administration/operations/ssh_certificates.md
index 3141312612e..a777f5484fd 100644
--- a/doc/administration/operations/ssh_certificates.md
+++ b/doc/administration/operations/ssh_certificates.md
@@ -96,7 +96,7 @@ Match User git
     AuthorizedPrincipalsCommand /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-authorized-principals-check %i sshUsers
 ```
 
-This command will emit output that looks something like:
+This command emits output that looks something like:
 
 ```shell
 command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell username-{KEY_ID}",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty {PRINCIPAL}
diff --git a/doc/administration/package_information/postgresql_versions.md b/doc/administration/package_information/postgresql_versions.md
index 8aab4121a0b..f1c0a011222 100644
--- a/doc/administration/package_information/postgresql_versions.md
+++ b/doc/administration/package_information/postgresql_versions.md
@@ -31,7 +31,7 @@ Read more about update policies and warnings in the PostgreSQL
 | -------------- | --------------------- | ---------------------------------- | ---------------------------- | ----- |
 | 15.0 | 12.10, 13.6 | 13.6 | 12.10 | For upgrades, users can manually upgrade to 13.6 following the [upgrade docs](https://docs.gitlab.com/omnibus/settings/database.html#gitlab-150-and-later). |
 | 14.1 | 12.7, 13.3 | 12.7 | 12.7 | PostgreSQL 13 available for fresh installations if not using [Geo](../geo/index.md#requirements-for-running-geo) or [Patroni](../postgresql/index.md#postgresql-replication-and-failover-with-omnibus-gitlab).
-| 14.0 | 12.7       | 12.7 | 12.7 | HA installations with repmgr are no longer supported and will be prevented from upgrading to Omnibus GitLab 14.0 |
+| 14.0 | 12.7       | 12.7 | 12.7 | HA installations with repmgr are no longer supported and are prevented from upgrading to Omnibus GitLab 14.0 |
 | 13.8 | 11.9, 12.4 | 12.4 | 12.4 | Package upgrades automatically performed PostgreSQL upgrade for nodes that are not part of a Geo or HA cluster.). |
 | 13.7 | 11.9, 12.4 | 12.4 | 11.9 | For upgrades users can manually upgrade to 12.4 following the [upgrade docs](https://docs.gitlab.com/omnibus/settings/database.html#gitlab-133-and-later). |
 | 13.4 | 11.9, 12.4 | 11.9 | 11.9 | Package upgrades aborted if users not running PostgreSQL 11 already |
diff --git a/doc/administration/raketasks/maintenance.md b/doc/administration/raketasks/maintenance.md
index 14efa7b98cf..6de47c37957 100644
--- a/doc/administration/raketasks/maintenance.md
+++ b/doc/administration/raketasks/maintenance.md
@@ -234,7 +234,7 @@ sudo -u git -H bundle exec rake cache:clear RAILS_ENV=production
 Sometimes during version upgrades you might end up with some wrong CSS or
 missing some icons. In that case, try to precompile the assets again.
 
-This only applies to source installations and does NOT apply to
+This only applies to source installations and does not apply to
 Omnibus packages.
 
 **Source Installation**
diff --git a/doc/administration/raketasks/smtp.md b/doc/administration/raketasks/smtp.md
index bc78d54aa1b..49274501809 100644
--- a/doc/administration/raketasks/smtp.md
+++ b/doc/administration/raketasks/smtp.md
@@ -55,7 +55,7 @@ bundle exec rake gitlab:smtp:secret:edit RAILS_ENV=production EDITOR=vim
 
 ### Write raw secret
 
-Write new secret content by providing it on STDIN.
+Write new secret content by providing it on `STDIN`.
 
 **Omnibus Installation**
 
diff --git a/doc/administration/redis/standalone.md b/doc/administration/redis/standalone.md
index 6e0e1eb886e..bd5b30efb7b 100644
--- a/doc/administration/redis/standalone.md
+++ b/doc/administration/redis/standalone.md
@@ -44,7 +44,7 @@ Omnibus GitLab:
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 1. Note the Redis node's IP address or hostname, port, and
-   Redis password. These will be necessary when [configuring the GitLab application servers](#set-up-the-gitlab-rails-application-instance).
+   Redis password. These are necessary when [configuring the GitLab application servers](#set-up-the-gitlab-rails-application-instance).
 
 [Advanced configuration options](https://docs.gitlab.com/omnibus/settings/redis.html)
 are supported and can be added if needed.
diff --git a/doc/administration/redis/troubleshooting.md b/doc/administration/redis/troubleshooting.md
index 4426adc5d51..b922fe5ae13 100644
--- a/doc/administration/redis/troubleshooting.md
+++ b/doc/administration/redis/troubleshooting.md
@@ -41,7 +41,7 @@ You can check if everything is correct by connecting to each server using
 /opt/gitlab/embedded/bin/redis-cli -h <redis-host-or-ip> -a '<redis-password>' info replication
 ```
 
-When connected to a `Primary` Redis, you will see the number of connected
+When connected to a `Primary` Redis, you see the number of connected
 `replicas`, and a list of each with connection details:
 
 ```plaintext
@@ -56,7 +56,7 @@ repl_backlog_first_byte_offset:206989083
 repl_backlog_histlen:1048576
 ```
 
-When it's a `replica`, you will see details of the primary connection and if
+When it's a `replica`, you see details of the primary connection and if
 its `up` or `down`:
 
 ```plaintext
@@ -138,7 +138,7 @@ there may be something wrong with your configuration files or it can be related
 to [this upstream issue](https://github.com/redis/redis-rb/issues/531).
 
 You must make sure that `resque.yml` and `sentinel.conf` are configured correctly,
-otherwise `redis-rb` will not work properly.
+otherwise `redis-rb` does not work properly.
 
 The `master-group-name` (`gitlab-redis`) defined in (`sentinel.conf`)
 **must** be used as the hostname in GitLab (`resque.yml`):
diff --git a/doc/administration/reference_architectures/troubleshooting.md b/doc/administration/reference_architectures/troubleshooting.md
index ce14e0f96ef..6e0aaacd598 100644
--- a/doc/administration/reference_architectures/troubleshooting.md
+++ b/doc/administration/reference_architectures/troubleshooting.md
@@ -54,20 +54,20 @@ This can result in some of the following problems:
 
 - If GitLab is using non-secure HTTP to access the object storage, clients may generate
 `https->http` downgrade errors and refuse to process the redirect. The solution to this
-is for GitLab to use HTTPS. LFS, for example, will generate this error:
+is for GitLab to use HTTPS. LFS, for example, generates this error:
 
    ```plaintext
    LFS: lfsapi/client: refusing insecure redirect, https->http
    ```
 
-- Clients will need to trust the certificate authority that issued the object storage
+- Clients must trust the certificate authority that issued the object storage
 certificate, or may return common TLS errors such as:
 
    ```plaintext
    x509: certificate signed by unknown authority
    ```
 
-- Clients will need network access to the object storage. Errors that might result
+- Clients need network access to the object storage. Errors that might result
 if this access is not in place include:
 
    ```plaintext
@@ -113,7 +113,7 @@ You can check if everything is correct by connecting to each server using
 /opt/gitlab/embedded/bin/redis-cli -h <redis-host-or-ip> -a '<redis-password>' info replication
 ```
 
-When connected to a `Primary` Redis, you will see the number of connected
+When connected to a `Primary` Redis, you see the number of connected
 `replicas`, and a list of each with connection details:
 
 ```plaintext
@@ -128,7 +128,7 @@ repl_backlog_first_byte_offset:206989083
 repl_backlog_histlen:1048576
 ```
 
-When it's a `replica`, you will see details of the primary connection and if
+When it's a `replica`, you see details of the primary connection and if
 its `up` or `down`:
 
 ```plaintext
@@ -254,7 +254,7 @@ To start a session:
 sudo gitlab-ctl pgb-console
 ```
 
-The password you will be prompted for is the `pgbouncer_user_password`
+The password you are prompted for is the `pgbouncer_user_password`
 
 To get some basic information about the instance, run
 
@@ -315,7 +315,7 @@ sudo gitlab-ctl tail patroni
 
 ### Consul and PostgreSQL with Patroni changes not taking effect
 
-Due to the potential impacts, `gitlab-ctl reconfigure` only reloads Consul and PostgreSQL, it will not restart the services. However, not all changes can be activated by reloading.
+Due to the potential impacts, `gitlab-ctl reconfigure` only reloads Consul and PostgreSQL, it does not restart the services. However, not all changes can be activated by reloading.
 
 To restart either service, run `gitlab-ctl restart consul` or `gitlab-ctl restart patroni` respectively.
 
@@ -335,7 +335,7 @@ PG::ConnectionBad: ERROR:  pgbouncer cannot connect to server
 The problem may be that your PgBouncer node's IP address is not included in the
 `trust_auth_cidr_addresses` setting in `/etc/gitlab/gitlab.rb` on the database nodes.
 
-You can confirm that this is the issue by checking the PostgreSQL log on the master
+You can confirm that this is the issue by checking the PostgreSQL log on the primary
 database node. If you see the following error then `trust_auth_cidr_addresses`
 is the problem.
 
diff --git a/doc/administration/sidekiq.md b/doc/administration/sidekiq.md
index c8f20e819e1..479e78ba0dc 100644
--- a/doc/administration/sidekiq.md
+++ b/doc/administration/sidekiq.md
@@ -193,6 +193,8 @@ To configure the metrics server:
 
 ### Enable HTTPS
 
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/364771) in GitLab 15.2.
+
 To serve metrics via HTTPS instead of HTTP, enable TLS in the exporter settings:
 
 1. Edit `/etc/gitlab/gitlab.rb` to add (or find and uncomment) the following lines:
@@ -206,7 +208,7 @@ To serve metrics via HTTPS instead of HTTP, enable TLS in the exporter settings:
 1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure)
    for the changes to take effect.
 
-When TLS is enabled, the same `port` and `address` will be used as described above.
+When TLS is enabled, the same `port` and `address` are used as described above.
 The metrics server cannot serve both HTTP and HTTPS at the same time.
 
 ## Configure health checks
diff --git a/doc/administration/troubleshooting/debug.md b/doc/administration/troubleshooting/debug.md
index b88a96a560d..53c71996493 100644
--- a/doc/administration/troubleshooting/debug.md
+++ b/doc/administration/troubleshooting/debug.md
@@ -28,7 +28,7 @@ session by running:
 ActiveRecord::Base.logger = Logger.new($stdout)
 ```
 
-This will show information about database queries triggered by any Ruby code
+This shows information about database queries triggered by any Ruby code
 you may run in the console. To turn off logging again, run:
 
 ```ruby
@@ -44,8 +44,8 @@ session by running:
 ActiveRecord::Base.connection.execute('SET statement_timeout TO 0')
 ```
 
-This change only affects the current Rails console session and will
-not be persisted in the GitLab production environment or in the next Rails
+This change only affects the current Rails console session and is
+not persisted in the GitLab production environment or in the next Rails
 console session.
 
 ### Output Rails console session history
@@ -163,7 +163,7 @@ in Omnibus, run as root:
 
 ## Common Problems
 
-Many of the tips to diagnose issues below apply to many different situations. We'll use one
+Many of the tips to diagnose issues below apply to many different situations. We use one
 concrete example to illustrate what you can do to learn what is going wrong.
 
 ### 502 Gateway Timeout after Unicorn spins at 100% CPU
@@ -213,7 +213,7 @@ downtime. Otherwise skip to the next section.
    ```
 
 If the Puma process terminates before you are able to run these
-commands, GDB will report an error. To buy more time, you can always raise the
+commands, GDB reports an error. To buy more time, you can always raise the
 Puma worker timeout. For omnibus users, you can edit `/etc/gitlab/gitlab.rb` and
 increase it from 60 seconds to 600:
 
diff --git a/doc/administration/troubleshooting/log_parsing.md b/doc/administration/troubleshooting/log_parsing.md
index c5702bdf106..e73bc09b7df 100644
--- a/doc/administration/troubleshooting/log_parsing.md
+++ b/doc/administration/troubleshooting/log_parsing.md
@@ -47,7 +47,7 @@ grep <TERM> <FILE> | jq .
 jq -cR 'fromjson?' file.json | jq <COMMAND>
 ```
 
-By default `jq` will error out when it encounters a line that is not valid JSON.
+By default `jq` errors out when it encounters a line that is not valid JSON.
 This skips over all invalid lines and parses the rest.
 
 #### Print a JSON log's time range
diff --git a/doc/administration/troubleshooting/ssl.md b/doc/administration/troubleshooting/ssl.md
index d82567baebb..7800ae5ad3c 100644
--- a/doc/administration/troubleshooting/ssl.md
+++ b/doc/administration/troubleshooting/ssl.md
@@ -236,7 +236,7 @@ remote server that is serving only HTTP.
 
 One scenario is that you're using [object storage](../object_storage.md), which
 isn't served under HTTPS. GitLab is misconfigured and attempts a TLS handshake,
-but the object storage will respond with plain HTTP.
+but the object storage responds with plain HTTP.
 
 ## `schannel: SEC_E_UNTRUSTED_ROOT`
 
diff --git a/doc/administration/troubleshooting/test_environments.md b/doc/administration/troubleshooting/test_environments.md
index 94d17ba714e..d240103a51c 100644
--- a/doc/administration/troubleshooting/test_environments.md
+++ b/doc/administration/troubleshooting/test_environments.md
@@ -45,7 +45,7 @@ docker run --name gitlab_saml -p 8080:8080 -p 8443:8443 \
 -d jamedjo/test-saml-idp
 ```
 
-The following will also need to go in your `/etc/gitlab/gitlab.rb`. See [our SAML docs](../../integration/saml.md)
+The following must also go in your `/etc/gitlab/gitlab.rb`. See [our SAML docs](../../integration/saml.md)
 for more, as well as the list of [default usernames, passwords, and emails](https://hub.docker.com/r/jamedjo/test-saml-idp/#usage).
 
 ```ruby
diff --git a/doc/administration/troubleshooting/tracing_correlation_id.md b/doc/administration/troubleshooting/tracing_correlation_id.md
index fed3604057b..418dd729066 100644
--- a/doc/administration/troubleshooting/tracing_correlation_id.md
+++ b/doc/administration/troubleshooting/tracing_correlation_id.md
@@ -32,7 +32,7 @@ documentation for some popular browsers.
 
 To locate a relevant request and view its correlation ID:
 
-1. Enable persistent logging in your network monitor. Some actions in GitLab will redirect you quickly after you submit a form, so this will help capture all relevant activity.
+1. Enable persistent logging in your network monitor. Some actions in GitLab redirect you quickly after you submit a form, so this helps capture all relevant activity.
 1. To help isolate the requests you are looking for, you can filter for `document` requests.
 1. Select the request of interest to view further detail.
 1. Go to the **Headers** section and look for **Response Headers**. There you should find an `x-request-id` header with a
@@ -121,7 +121,7 @@ find /var/log/gitlab -type f -mtime 0 -exec grep 'LOt9hgi1TV4' '{}' '+'
 ### Searching in distributed architectures
 
 If you have done some horizontal scaling in your GitLab infrastructure, then
-you will need to search across _all_ of your GitLab nodes. You can do this with
+you must search across _all_ of your GitLab nodes. You can do this with
 some sort of log aggregation software like Loki, ELK, Splunk, or others.
 
 You can use a tool like Ansible or PSSH (parallel SSH) that can execute identical commands across your servers in
diff --git a/doc/administration/uploads.md b/doc/administration/uploads.md
index e618c4787ab..0bd46193d10 100644
--- a/doc/administration/uploads.md
+++ b/doc/administration/uploads.md
@@ -66,7 +66,7 @@ For source installations the following settings are nested under `uploads:` and
 | Setting | Description | Default |
 |---------|-------------|---------|
 | `enabled` | Enable/disable object storage | `false` |
-| `remote_directory` | The bucket name where Uploads will be stored| |
+| `remote_directory` | The bucket name where Uploads are stored| |
 | `proxy_download` | Set to `true` to enable proxying all files served. Option allows to reduce egress traffic as this allows clients to download directly from remote storage instead of proxying all data | `false` |
 | `connection` | Various connection options described below | |
 
diff --git a/doc/development/omnibus.md b/doc/development/omnibus.md
index b62574e34e5..4e2f2b0c763 100644
--- a/doc/development/omnibus.md
+++ b/doc/development/omnibus.md
@@ -21,7 +21,7 @@ For example, the `git` user is allowed to write in the `log/` directory, in
 `public/uploads`, and they are allowed to rewrite the `db/structure.sql` file.
 
 In other cases, the reconfigure script tricks GitLab into not trying to write a
-file. For instance, GitLab will generate a `.secret` file if it cannot find one
+file. For instance, GitLab generates a `.secret` file if it cannot find one
 and write it to the Rails root. In the Omnibus packages, reconfigure writes the
 `.secret` file first, so that GitLab never tries to write it.
 
diff --git a/doc/development/secure_coding_guidelines.md b/doc/development/secure_coding_guidelines.md
index d8e2352bd93..9048da77071 100644
--- a/doc/development/secure_coding_guidelines.md
+++ b/doc/development/secure_coding_guidelines.md
@@ -1278,3 +1278,31 @@ This sensitive data must be handled carefully to avoid leaks which could lead to
 - Avoid sending credentials in URL parameters, as these can be more easily logged inadvertently during transit.
 
 In the event of credential leak through an MR, issue, or any other medium, [reach out to SIRT team](https://about.gitlab.com/handbook/engineering/security/security-operations/sirt/#-engaging-sirt).
+
+## Serialization
+
+Serialization of active record models can leak sensitive attributes if they are not protected.
+
+Using the [`prevent_from_serialization`](https://gitlab.com/gitlab-org/gitlab/-/blob/d7b85128c56cc3e669f72527d9f9acc36a1da95c/app/models/concerns/sensitive_serializable_hash.rb#L11)
+method protects the attributes when the object is serialized with `serializable_hash`.
+When an attribute is protected with `prevent_from_serialization`, it is not included with
+`serializable_hash`, `to_json`, or `as_json`.
+
+For more guidance on serialization:
+
+- [Why using a serializer is important](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/serializers/README.md#why-using-a-serializer-is-important).
+- Always use [Grape entities](../../ee/development/api_styleguide.md#entities) for the API.
+
+To `serialize` an `ActiveRecord` column:
+
+- You can use `app/serializers`.
+- You cannot use `to_json / as_json`.
+- You cannot use `serialize :some_colum`.
+
+### Serialization example
+
+The following is an example used for the [`TokenAuthenticatable`](https://gitlab.com/gitlab-org/gitlab/-/blob/9b15c6621588fce7a80e0438a39eeea2500fa8cd/app/models/concerns/token_authenticatable.rb#L30) class:
+
+```ruby
+prevent_from_serialization(*strategy.token_fields) if respond_to?(:prevent_from_serialization)
+```
diff --git a/doc/update/package/index.md b/doc/update/package/index.md
index 02dd5811bf7..bf1154d1cf5 100644
--- a/doc/update/package/index.md
+++ b/doc/update/package/index.md
@@ -305,7 +305,7 @@ To fix this issue:
 
 ### Error `Failed to connect to the internal GitLab API` on a separate GitLab Pages server
 
-Please see [GitLab Pages troubleshooting](../../administration/pages/index.md#failed-to-connect-to-the-internal-gitlab-api).
+See [GitLab Pages troubleshooting](../../administration/pages/index.md#failed-to-connect-to-the-internal-gitlab-api).
 
 ### Error `An error occurred during the signature verification` when running `apt-get update`
 
diff --git a/doc/update/patch_versions.md b/doc/update/patch_versions.md
index dc09f6063c8..b7c148045bd 100644
--- a/doc/update/patch_versions.md
+++ b/doc/update/patch_versions.md
@@ -11,11 +11,11 @@ comments: false
 
 Make sure you view [this update guide](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/update/patch_versions.md) from the tag (version) of GitLab you would like to install.
 In most cases this should be the highest numbered production tag (without `rc` in it).
-You can select the tag in the version dropdown in the top left corner of GitLab (below the menu bar).
+You can select the tag in the version dropdown list in the top left corner of GitLab (below the menu bar).
 
 ### 0. Backup
 
-It's useful to make a backup just in case things go south. Depending on the installation method, backup commands vary. See the [backing up and restoring GitLab](../raketasks/backup_restore.md) documentation.
+Make a backup just in case things go south. Depending on the installation method, backup commands vary. See the [backing up and restoring GitLab](../raketasks/backup_restore.md) documentation.
 
 ### 1. Stop server
 
@@ -107,7 +107,7 @@ sudo -u git -H make
 
 ### 8. Install/Update `gitlab-elasticsearch-indexer` **(PREMIUM SELF)**
 
-Please follow the [install instruction](../integration/advanced_search/elasticsearch.md#install-elasticsearch).
+Follow the [install instruction](../integration/advanced_search/elasticsearch.md#install-elasticsearch).
 
 ### 9. Start application
 
diff --git a/doc/update/upgrading_from_ce_to_ee.md b/doc/update/upgrading_from_ce_to_ee.md
index 288fb1b161b..b953194b4cf 100644
--- a/doc/update/upgrading_from_ce_to_ee.md
+++ b/doc/update/upgrading_from_ce_to_ee.md
@@ -21,7 +21,7 @@ GitLab edition you are using (Community or Enterprise), see the
 
 This guide assumes you have a correctly configured and tested installation of
 GitLab Community Edition. If you run into any trouble or if you have any
-questions please contact us at `support@gitlab.com`.
+questions contact us at `support@gitlab.com`.
 
 In all examples, replace `EE_BRANCH` with the Enterprise Edition branch for the
 version you are using, and `CE_BRANCH` with the Community Edition branch.
@@ -88,7 +88,7 @@ sudo -u git -H bundle exec rake cache:clear RAILS_ENV=production
 
 ### 4. Install `gitlab-elasticsearch-indexer` **(PREMIUM SELF)**
 
-Please follow the [install instruction](../integration/advanced_search/elasticsearch.md#install-elasticsearch).
+Follow the [install instruction](../integration/advanced_search/elasticsearch.md#install-elasticsearch).
 
 ### 5. Start application
 
diff --git a/doc/update/upgrading_from_source.md b/doc/update/upgrading_from_source.md
index 4280a761dd5..8b921f6d0ce 100644
--- a/doc/update/upgrading_from_source.md
+++ b/doc/update/upgrading_from_source.md
@@ -8,12 +8,12 @@ comments: false
 # Upgrading Community Edition and Enterprise Edition from source **(FREE SELF)**
 
 Make sure you view this update guide from the branch (version) of GitLab you
-would like to install (for example, `11.8`). You can select the required version of documentation in the dropdown at the top right corner of GitLab documentation page.
+would like to install (for example, `11.8`). You can select the required version of documentation in the dropdown list at the top right corner of GitLab documentation page.
 
 In each of the following examples, replace `BRANCH` with the branch of the version you upgrading to (for example, `11-8-stable` for `11.8`). Replace `PREVIOUS_BRANCH` with the
 branch for the version you are upgrading from (for example, `11-7-stable` for `11.7`).
 
-If the highest number stable branch is unclear please check the
+If the highest number stable branch is unclear check the
 [GitLab Blog](https://about.gitlab.com/blog/archives.html) for installation
 guide links by version.
 
@@ -24,7 +24,7 @@ the [Upgrading from CE to EE](upgrading_from_ce_to_ee.md) documentation.
 
 Major versions are reserved for backwards incompatible changes. We recommend that
 you first upgrade to the latest available minor version of your current major version.
-Please follow the [Upgrade Recommendations](../policy/maintenance.md#upgrade-recommendations)
+Follow the [Upgrade Recommendations](../policy/maintenance.md#upgrade-recommendations)
 to identify the ideal upgrade path.
 
 Before upgrading to a new major version, you should ensure that any background
@@ -225,7 +225,7 @@ NGINX configuration to continue using it. This is because the GitLab application
 sets it.
 
 If you are using Apache instead of NGINX see the updated [Apache templates](https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/web-server/apache).
-Also note that because Apache does not support upstreams behind Unix sockets you
+Also because Apache does not support upstreams behind Unix sockets you
 must let GitLab Workhorse listen on a TCP port. You can do this
 via [`/etc/default/gitlab`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/support/init.d/gitlab.default.example#L38).
 
@@ -428,7 +428,7 @@ Additional instructions here.
 ### 15.0.0
 
 Support for more than one database has been added to GitLab. [As part of this](https://gitlab.com/gitlab-org/gitlab/-/issues/338182),
-`config/database.yml` needs to include a database name in the database configuration.
+`config/database.yml` must include a database name in the database configuration.
 The `main: database` must be first. If an invalid or deprecated syntax is used, an error is generated
 during application start:
 
@@ -447,7 +447,7 @@ production:
   ...
 ```
 
-Starting with GitLab 15.0, it needs to define a `main` database first:
+Starting with GitLab 15.0, it must define a `main` database first:
 
 ```yaml
 production:
@@ -492,7 +492,7 @@ for the previous version.
 
 For example, if you have upgraded to GitLab 12.6 and want to revert back to
 12.5, follow the guides for upgrading from 12.4 to 12.5. You can
-use the version dropdown at the top of the page to select the right version.
+use the version dropdown list at the top of the page to select the right version.
 
 When reverting, you should **not** follow the database migration guides, as the
 backup has already been migrated to the previous version.
diff --git a/doc/update/with_downtime.md b/doc/update/with_downtime.md
index cf1435f9337..c6ad854fd0f 100644
--- a/doc/update/with_downtime.md
+++ b/doc/update/with_downtime.md
@@ -15,12 +15,12 @@ there are a number of constraints. In particular, you can upgrade to only one mi
 at a time, for example, from 14.6 to 14.7, then to 14.8, etc.
 
 If you want to upgrade to more than one minor release at a time (for example, from 14.6 to 14.9),
-you need to take your GitLab instance offline, which implies downtime.
+you must take your GitLab instance offline, which implies downtime.
 Before starting this process, verify the
 [version specific upgrading instructions](index.md#version-specific-upgrading-instructions)
 relevant to your [upgrade path](index.md#upgrade-paths).
 
-For a single node installation, you only need to [uprgade the GitLab package](package/index.md).
+For a single node installation, you must only [upgrade the GitLab package](package/index.md).
 
 The process for upgrading a number of components of a multi-node GitLab
 installation is the same as for zero downtime upgrades.
@@ -86,11 +86,11 @@ for Gitaly cluster.
 
 If you are using Amazon Machine Images (AMIs) on AWS, the Gitaly nodes
 **should not be upgraded via the AMI process**. Gitaly nodes should **only**
-be upgraded using the package upgrade. This is because:
+be upgraded using the package upgrade because:
 
 - Praefect tracks replicas of Git repositories by server hostname.
-- Redeployment using AMIs will issue the nodes with new hostnames.
-- Even though the storage will be the same, Gitaly cluster will not work after this.
+- Redeployment using AMIs issues the nodes with new hostnames.
+- Even though the storage is the same, Gitaly cluster does not work after this.
 
 The Praefect nodes, however, can be upgraded via an AMI redeployment process:
 
@@ -100,7 +100,7 @@ The Praefect nodes, however, can be upgraded via an AMI redeployment process:
   1. The first node to be redeployed with the upgraded image should be your
      deploy node.
   1. After it's deployed, set `praefect['auto_migrate'] = true` in `gitlab.rb`
-     and apply with `gitlab-ctl reconfigure`. This will run the database
+     and apply with `gitlab-ctl reconfigure`. This runs the database
      migrations.
   1. Redeploy your other Praefect nodes.
 
@@ -142,7 +142,7 @@ For unclustered PostgreSQL servers:
 
 ## Upgrade the Patroni node
 
-Patroni is used to achiece high availabilty with PostgreSQL.
+Patroni is used to achieve high availability with PostgreSQL.
 
 If a PostgreSQL major version upgrade is required,
 [follow the major version process](../administration/postgresql/replication_and_failover.md#upgrading-postgresql-major-version-in-a-patroni-cluster).
@@ -150,7 +150,7 @@ If a PostgreSQL major version upgrade is required,
 The upgrade process for all other versions is performed on all replicas first.
 After they're upgraded, a cluster failover occurs from the leader to one of the upgraded
 replicas. This ensures that only one failover is needed, and once complete the new
-leader will be upgraded.
+leader is upgraded.
 
 Follow the following process:
 
@@ -232,7 +232,7 @@ All the Puma and Sidekiq processes were previously shut down. On each node:
    ps -ef | egrep 'puma: | puma | sidekiq '
    ```
 
-Select one node that runs Puma. This will be your deploy node, and is responsible for
+Select one node that runs Puma. This is your deploy node, and is responsible for
 running all database migrations. On the deploy node:
 
 1. Ensure the server is configured to permit regular migrations. Check that
diff --git a/doc/update/zero_downtime.md b/doc/update/zero_downtime.md
index 2f04861589b..bfef6fff5be 100644
--- a/doc/update/zero_downtime.md
+++ b/doc/update/zero_downtime.md
@@ -34,7 +34,7 @@ If you meet all the requirements above, follow these instructions in order. Ther
 
 Each type of deployment requires that you hot reload the `puma` and `sidekiq` processes on all nodes running these
 services after you've upgraded. The reason for this is that those processes each load the GitLab Rails application which reads and loads
-the database schema into memory when starting up. Each of these processes needs to be reloaded (or restarted in the case of `sidekiq`)
+the database schema into memory when starting up. Each of these processes must be reloaded (or restarted in the case of `sidekiq`)
 to re-read any database changes that have been made by post-deployment migrations.
 
 Most of the time you can safely upgrade from a patch release to the next minor
@@ -313,7 +313,7 @@ node throughout the process.
 
 - If you're using PgBouncer:
 
-  You need to bypass PgBouncer and connect directly to the database leader
+  You must bypass PgBouncer and connect directly to the database leader
   before running migrations.
 
   Rails uses an advisory lock when attempting to run a migration to prevent
@@ -395,11 +395,11 @@ HA.
 
 #### In the application node
 
-According to [official Redis docs](https://redis.io/topics/admin#upgrading-or-restarting-a-redis-instance-without-downtime),
+According to [official Redis documentation](https://redis.io/topics/admin#upgrading-or-restarting-a-redis-instance-without-downtime),
 the easiest way to update an HA instance using Sentinel is to upgrade the
 secondaries one after the other, perform a manual failover from current
 primary (running old version) to a recently upgraded secondary (running a new
-version), and then upgrade the original primary. For this, we need to know
+version), and then upgrade the original primary. For this, we must know
 the address of the current Redis primary.
 
 - If your application node is running GitLab 12.7.0 or later, you can use the
@@ -444,8 +444,8 @@ following command to get address of current Redis primary
 
 #### In the Redis primary node
 
-Before upgrading the Redis primary node, we need to perform a failover so that
-one of the recently upgraded secondary nodes becomes the new primary. Once the
+Before upgrading the Redis primary node, we must perform a failover so that
+one of the recently upgraded secondary nodes becomes the new primary. After the
 failover is complete, we can go ahead and upgrade the original primary node.
 
 1. Stop Redis service in Redis primary node so that it fails over to a secondary
@@ -625,7 +625,7 @@ Updates must be performed in the following order:
 
 ### Step 1: Choose a "deploy node" for each deployment
 
-You now need to choose:
+You now must choose:
 
 - One instance for use as the **primary** "deploy node" on the Geo **primary** multi-node deployment.
 - One instance for use as the **secondary** "deploy node" on each Geo **secondary** multi-node deployment.
@@ -698,7 +698,7 @@ sudo touch /etc/gitlab/skip-auto-reconfigure
 
 1. If you're using PgBouncer:
 
-   You need to bypass PgBouncer and connect directly to the database leader
+   You must bypass PgBouncer and connect directly to the database leader
    before running migrations.
 
    Rails uses an advisory lock when attempting to run a migration to prevent
diff --git a/doc/user/project/repository/managing_large_repositories.md b/doc/user/project/repository/managing_large_repositories.md
index 76f66f41297..7d6c18b8cb0 100644
--- a/doc/user/project/repository/managing_large_repositories.md
+++ b/doc/user/project/repository/managing_large_repositories.md
@@ -16,7 +16,7 @@ On this page we detail several best practices to improve performance with these
 
 It's *strongly* recommended in any Git system that binary or blob files (for example, packages, audio, video, graphics, etc.) are stored as Large File Storage (LFS) objects. In such setup, the Objects are stored elsewhere, such as in Object Storage, and this can reduce the repository size significantly, thus improving performance.
 
-Refer to the [Git LFS docs for more information](../../../topics/git/lfs/index.md).
+Refer to the [Git LFS documentation for more information](../../../topics/git/lfs/index.md).
 
 ## Gitaly Pack Objects Cache
 
@@ -34,7 +34,7 @@ In these types of setups it's recommended that the GitLab environment used match
 
 Gitaly Cluster can notably improve large repository performance as it holds multiple replicas of the repository across several nodes. As a result, Gitaly Cluster can load balance read requests against those repositories and is also fault tolerant.
 
-It's recommended for large repositories, however, Gitaly Cluster is a large solution with additional complexity of setup and management. Refer to the [Gitaly Cluster docs for more information](../../../administration/gitaly/index.md), specifically the [Before deploying Gitaly Cluster](../../../administration/gitaly/index.md#before-deploying-gitaly-cluster) section.
+It's recommended for large repositories, however, Gitaly Cluster is a large solution with additional complexity of setup and management. Refer to the [Gitaly Cluster documentation for more information](../../../administration/gitaly/index.md), specifically the [Before deploying Gitaly Cluster](../../../administration/gitaly/index.md#before-deploying-gitaly-cluster) section.
 
 ## Keep GitLab up to date
 
@@ -48,4 +48,4 @@ CI/CD loads tend to be concurrent as pipelines are scheduled during set times. A
 
 When designing CI/CD pipelines, it's advisable to reduce their concurrency by staggering them to run at different times, for example, a set running at one time and then another set running several minutes later.
 
-There's several other actions that can be explored to improve CI/CD performance with large repositories. Refer to the [Runner docs for more information](../../../ci/large_repositories/index.md).
+There's several other actions that can be explored to improve CI/CD performance with large repositories. Refer to the [Runner documentation for more information](../../../ci/large_repositories/index.md).
diff --git a/doc/user/tasks.md b/doc/user/tasks.md
index 5112e1afaa8..306afd85261 100644
--- a/doc/user/tasks.md
+++ b/doc/user/tasks.md
@@ -6,7 +6,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Tasks **(FREE)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/334812) in GitLab 14.5 [with a flag](../administration/feature_flags.md) named `work_items`. Disabled by default.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/334812) in GitLab 14.5 [with a flag](../administration/feature_flags.md) named `work_items`. Disabled by default.
+> - [Creating, editing, and deleting tasks](https://gitlab.com/groups/gitlab-org/-/epics/7169) introduced in GitLab 15.0.
 
 FLAG:
 On self-managed GitLab, by default this feature is not available. To make it available,
@@ -41,7 +42,7 @@ To edit a task:
 1. In the issue description, view the task links.
 1. Select a link. The task is displayed.
    - To edit the description, select **Edit**, then select **Save**.
-   - To edit the title or state, make your changes, then click outside the field. The changes are saved automatically.
+   - To edit the title or state, make your changes, then select any area outside the field. The changes are saved automatically.
 
 ## Delete a task