Add latest changes from gitlab-org/gitlab@master

12 files changed, 22 insertions, 22 deletions

diff --git a/doc/administration/geo/replication/multiple_servers.md b/doc/administration/geo/replication/multiple_servers.md
index 5be7d40890c..155fefb2dbf 100644
--- a/doc/administration/geo/replication/multiple_servers.md
+++ b/doc/administration/geo/replication/multiple_servers.md
@@ -81,7 +81,7 @@ After making these changes, [reconfigure GitLab](../../restart_gitlab.md#omnibus
 
 NOTE:
 PostgreSQL and Redis should have already been disabled on the
-application nodes during normal GitLab multi-node setup. Connections
+application nodes during typical GitLab multi-node setup. Connections
 from the application nodes to services on the backend nodes should
 have also been configured. See multi-node configuration documentation for
 [PostgreSQL](../../postgresql/replication_and_failover.md#configuring-the-application-nodes)
@@ -100,7 +100,7 @@ major differences:
 - There is an additional GitLab service [`geo-logcursor`](../index.md#geo-log-cursor)
 
 Therefore, we set up the multi-node components one by one and include deviations
-from the normal multi-node setup. However, we highly recommend configuring a
+from the typical multi-node setup. However, we highly recommend configuring a
 brand-new GitLab site first, as if it were not part of a Geo setup. This allows
 verifying that it is a working GitLab site. And only then should it be modified
 for use as a Geo **secondary** site. This helps to separate Geo setup problems from
diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
index 8b4750b299d..abcd26cae1b 100644
--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -802,7 +802,7 @@ To complete this section you need:
   These should be dedicated nodes, do not run other services on these nodes.
 
 Every Gitaly server assigned to the Praefect cluster needs to be configured. The
-configuration is the same as a normal [standalone Gitaly server](index.md),
+configuration is the same as a standard [standalone Gitaly server](index.md),
 except:
 
 - The storage names are exposed to Praefect, not GitLab
diff --git a/doc/administration/instance_limits.md b/doc/administration/instance_limits.md
index 433d5cea789..8cdf27b58e8 100644
--- a/doc/administration/instance_limits.md
+++ b/doc/administration/instance_limits.md
@@ -182,7 +182,7 @@ Read more about [pipeline creation rate limits](../user/admin_area/settings/rate
 
 ## Gitaly concurrency limit
 
-Clone traffic can put a large strain on your Gitaly service. To prevent such workloads from overwhelming your Gitaly server, you can set concurrency limits in Gitaly's configuration file.
+Clone traffic can put a large strain on your Gitaly service. To prevent such workloads from overwhelming your Gitaly server, you can set concurrency limits in the Gitaly configuration file.
 
 Read more about [Gitaly concurrency limits](gitaly/configure_gitaly.md#limit-rpc-concurrency).
 
diff --git a/doc/administration/nfs.md b/doc/administration/nfs.md
index 972db315268..7349e8ad9ba 100644
--- a/doc/administration/nfs.md
+++ b/doc/administration/nfs.md
@@ -101,7 +101,7 @@ specifically test NFSv3.
 When you define your NFS exports, we recommend you also add the following
 options:
 
-- `no_root_squash` - NFS normally changes the `root` user to `nobody`. This is
+- `no_root_squash` - NFS usually changes the `root` user to `nobody`. This is
   a good security measure when NFS shares are accessed by many different
   users. However, in this case only GitLab uses the NFS share so it
   is safe. GitLab recommends the `no_root_squash` setting because we need to
@@ -279,7 +279,7 @@ to store the data on an NFS mount.
 
 Bind mounts provide a way to specify just one NFS mount and then
 bind the default GitLab data locations to the NFS mount. Start by defining your
-single NFS mount point as you normally would in `/etc/fstab`. Let's assume your
+single NFS mount point as you typically would in `/etc/fstab`. Let's assume your
 NFS mount point is `/gitlab-nfs`. Then, add the following bind mounts in
 `/etc/fstab`:
 
diff --git a/doc/administration/operations/ssh_certificates.md b/doc/administration/operations/ssh_certificates.md
index 401451d58b4..bdd1045f7a7 100644
--- a/doc/administration/operations/ssh_certificates.md
+++ b/doc/administration/operations/ssh_certificates.md
@@ -74,7 +74,7 @@ $ ssh-add -L | grep cert | ssh-keygen -L -f -
 ```
 
 Technically that's not strictly true, for example, it could be
-`prod-aearnfjord` if it's a SSH certificate you'd normally sign in to
+`prod-aearnfjord` if it's a SSH certificate you'd usually sign in to
 servers as the `prod-aearnfjord` user, but then you must specify your
 own `AuthorizedPrincipalsCommand` to do that mapping instead of using
 our provided default.
@@ -122,7 +122,7 @@ You can supply as many principals as you want, these are turned
 into multiple lines of `authorized_keys` output, as described in the
 `AuthorizedPrincipalsFile` documentation in `sshd_config(5)`.
 
-Normally when using the `AuthorizedKeysCommand` with OpenSSH the
+Usually when using the `AuthorizedKeysCommand` with OpenSSH the
 principal is some "group" that's allowed to sign in to that
 server. However with GitLab it's only used to appease OpenSSH's
 requirement for it, we effectively only care about the "key ID" being
@@ -145,13 +145,13 @@ authenticate the user, OpenSSH falls back on
 
 Therefore there may still be a reason to use the [Fast lookup of authorized SSH keys in the database](fast_ssh_key_lookup.md) method
 in conjunction with this. Since you are using SSH certificates for
-all your normal users, and relying on the `~/.ssh/authorized_keys`
+all your typical users, and relying on the `~/.ssh/authorized_keys`
 fallback for deploy keys, if you make use of those.
 
 But you may find that there's no reason to do that, since all your
-normal users use the fast `AuthorizedPrincipalsCommand` path, and
+typical users use the fast `AuthorizedPrincipalsCommand` path, and
 only automated deployment key access falls back on
-`~/.ssh/authorized_keys`, or that you have a lot more keys for normal
+`~/.ssh/authorized_keys`, or that you have a lot more keys for typical
 users (especially if they're renewed) than you have deploy keys.
 
 ## Other security caveats
diff --git a/doc/administration/raketasks/maintenance.md b/doc/administration/raketasks/maintenance.md
index ba095b33bf5..1cc3de868be 100644
--- a/doc/administration/raketasks/maintenance.md
+++ b/doc/administration/raketasks/maintenance.md
@@ -374,7 +374,7 @@ The following index types are not supported:
 
 Optionally, this Rake task sends annotations to a Grafana (4.6 or later) endpoint. Use the following custom environment variables to enable annotations:
 
-1. `GRAFANA_API_URL` - Grafana's base URL, for example `http://some-host:3000`.
+1. `GRAFANA_API_URL` - The base URL for Grafana, for example `http://some-host:3000`.
 1. `GRAFANA_API_KEY` - Grafana API key with at least `Editor role`.
 
 You can also [enable reindexing as a regular cron job](https://docs.gitlab.com/omnibus/settings/database.html#automatic-database-reindexing).
diff --git a/doc/administration/repository_storage_types.md b/doc/administration/repository_storage_types.md
index 77a5eae3747..ab95887380d 100644
--- a/doc/administration/repository_storage_types.md
+++ b/doc/administration/repository_storage_types.md
@@ -208,7 +208,7 @@ CI/CD artifacts are:
 #### LFS objects
 
 [LFS Objects in GitLab](../topics/git/lfs/index.md) implement a similar
-storage pattern using two characters and two-level folders, following Git's own implementation:
+storage pattern using two characters and two-level folders, following the Git implementation:
 
 ```ruby
 "shared/lfs-objects/#{oid[0..1}/#{oid[2..3]}/#{oid[4..-1]}"
diff --git a/doc/administration/sidekiq/extra_sidekiq_processes.md b/doc/administration/sidekiq/extra_sidekiq_processes.md
index d5007e9a3e9..2a29b6bda1b 100644
--- a/doc/administration/sidekiq/extra_sidekiq_processes.md
+++ b/doc/administration/sidekiq/extra_sidekiq_processes.md
@@ -55,7 +55,7 @@ To view the Sidekiq processes in GitLab:
 
 By default each process defined under `sidekiq` starts with a number of threads
 that equals the number of queues, plus one spare thread, up to a maximum of 50.
-For example, a process that handles all queues will use 50 threads by default.
+For example, a process that handles all queues uses 50 threads by default.
 
 These threads run inside a single Ruby process, and each process can only use a
 single CPU core. The usefulness of threading depends on the work having some
@@ -117,7 +117,7 @@ for more details.
 
 ## Modify the check interval
 
-To modify Sidekiq's health check interval for the additional Sidekiq
+To modify the Sidekiq health check interval for the additional Sidekiq
 processes:
 
 1. Edit `/etc/gitlab/gitlab.rb`:
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 60b7577df0d..d2d6d2f4fc5 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -216,7 +216,7 @@ Returns [`Issue`](#issue).
 
 ### `Query.issues`
 
-Find issues visible to the current user. At least one filter must be provided. Returns `null` if the `root_level_issues_query` feature flag is disabled.
+Find issues visible to the current user. At least one filter must be provided.
 
 WARNING:
 **Introduced** in 15.6.
diff --git a/doc/ci/interactive_web_terminal/index.md b/doc/ci/interactive_web_terminal/index.md
index 44c081b9d7f..c7fb94535ff 100644
--- a/doc/ci/interactive_web_terminal/index.md
+++ b/doc/ci/interactive_web_terminal/index.md
@@ -54,7 +54,7 @@ Not all executors are
 NOTE:
 The `docker` executor does not keep running
 after the build script is finished. At that point, the terminal automatically
-disconnects and does not wait for the user to finish. Please follow
+disconnects and does not wait for the user to finish. Follow
 [this issue](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3605) for updates on
 improving this behavior.
 
@@ -66,7 +66,7 @@ for the current job.
 ![Example of job running with terminal available](img/interactive_web_terminal_running_job.png)
 
 When selected, a new tab opens to the terminal page where you can access
-the terminal and type commands like a normal shell.
+the terminal and type commands like in a standard shell.
 
 ![terminal of the job](img/interactive_web_terminal_page.png)
 
diff --git a/doc/integration/arkose.md b/doc/integration/arkose.md
index 24bdba7931b..9c8f6cdfb6a 100644
--- a/doc/integration/arkose.md
+++ b/doc/integration/arkose.md
@@ -13,7 +13,7 @@ Arkose Protect on GitLab.com. While this feature is theoretically usable in self
 is not recommended at the moment.
 
 GitLab integrates [Arkose Protect](https://www.arkoselabs.com/arkose-protect/) to guard against
-credential stuffing and bots in the sign-in form. GitLab will trigger Arkose Protect if the user:
+credential stuffing and bots in the sign-in form. GitLab triggers Arkose Protect if the user:
 
 - Has never signed in before.
 - Has failed to sign in twice in a row.
@@ -98,8 +98,8 @@ KQL: json.message:"Challenge was not solved" AND json.username:replace_username_
 Several GitLab QA test suites need to sign in to the app to test its features. This can conflict
 with Arkose Protect as it would identify QA users as being malicious because they are being run with
 a headless browser. To work around this, ArkoseLabs has allowlisted the unique token
-that serves as QA session's User Agent. While this doesn't guarantee that the session won't be
-flagged as malicious, Arkose's API returns a specific telltale when we verify the sign in
+that serves as QA session's User Agent. While this doesn't guarantee that the session is not
+flagged as malicious, the Arkose API returns a specific telltale when we verify the sign in
 attempt's token. We are leveraging this telltale to bypass the verification step entirely so that the
 test suite doesn't fail. This bypass is done in the `UserVerificationService` class.
 
diff --git a/doc/user/group/import/index.md b/doc/user/group/import/index.md
index c31840a233d..a4a9c71eb3b 100644
--- a/doc/user/group/import/index.md
+++ b/doc/user/group/import/index.md
@@ -84,7 +84,7 @@ GitLab maps users and their contributions correctly provided:
 
 - Users already exist on the target GitLab instance.
 - Users have a public email on the source GitLab instance that matches their primary email on the target GitLab instance.
-- Users' primary email addresses on the target GitLab instance are confirmed. Most users receives an email asking them to confirm their email address.
+- Users' primary email addresses on the target GitLab instance are confirmed. Most users receive an email asking them to confirm their email address.
 - When using an OmniAuth provider like SAML, GitLab and SAML accounts of users on GitLab must be linked. All users on the target GitLab instance must sign in
   and verify their account on the target GitLab instance.