Changing use of normal

Author: Amber Parker

doc/development/gitaly.md

@@ -116,7 +116,7 @@ Please raise an issue in the GitLab CE or EE repositories to report the issue. I
 ~performance ~"technical debt". Please ensure that the issue contains the full stack trace and error message of the
 `TooManyInvocationsError`. Also include any known failing tests if possible.
 
-Isolate the source of the n+1 problem. This is normally a loop that results in Gitaly being called for each
+Isolate the source of the n+1 problem. This is usually a loop that results in Gitaly being called for each
 element in an array. If you are unable to isolate the problem, please contact a member
 of the [Gitaly Team](https://gitlab.com/groups/gl-gitaly/group_members) for assistance.
 
@@ -152,7 +152,7 @@ end
 
 ## Running tests with a locally modified version of Gitaly
 
-Normally, GitLab CE/EE tests use a local clone of Gitaly in
+Usually, GitLab CE/EE tests use a local clone of Gitaly in
 `tmp/tests/gitaly` pinned at the version specified in
 `GITALY_SERVER_VERSION`. The `GITALY_SERVER_VERSION` file supports also
 branches and SHA to use a custom commit in [the repository](https://gitlab.com/gitlab-org/gitaly).

doc/development/graphql_guide/batchloader.md

@@ -161,7 +161,7 @@ you do so, you do not need to manage the lifecycle of lazy values yourself, and
 you are assured accurate results.
 
 GraphQL fields that return lazy values may need these values forced in tests.
-Forcing refers to explicit demands for evaluation, where this would normally
+Forcing refers to explicit demands for evaluation, where this would usually
 be arranged by the framework.
 
 You can force a lazy value with the `GraphqlHelpers#batch_sync` method available in [GraphQLHelpers](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/support/helpers/graphql_helpers.rb), or by using `Gitlab::Graphql::Lazy.force`. For example:

doc/development/internal_analytics/service_ping/implement.md

@@ -783,7 +783,7 @@ By default, it comes with a fully configured Prometheus service that is set up t
 However, it has the following limitations:
 
 - It does not run a `gitlab-exporter` instance, so several `process_*` metrics from services such as Gitaly may be missing.
-- While it runs a `node_exporter`, `docker-compose` services emulate hosts, meaning that it normally reports itself as not associated
+- While it runs a `node_exporter`, `docker-compose` services emulate hosts, meaning that it usually reports itself as not associated
   with any of the other running services. That is not how node metrics are reported in a production setup, where `node_exporter`
   always runs as a process alongside other GitLab components on any given node. For Service Ping, none of the node data would therefore
   appear to be associated to any of the services running, because they all appear to be running on different hosts. To alleviate this problem, the `node_exporter` in GCK was arbitrarily "assigned" to the `web` service, meaning only for this service `node_*` metrics appears in Service Ping.

doc/development/performance.md

@@ -217,7 +217,7 @@ Finished in 18.19 seconds (files took 4.8 seconds to load)
 ```
 
 You can limit the specs that are run by passing any arguments `RSpec` would
-normally take.
+usually take.
 
 ### Using Stackprof in production
 

doc/development/sidekiq/idempotent_jobs.md

@@ -156,7 +156,7 @@ end
 
 ## Setting the deduplication time-to-live (TTL)
 
-Deduplication depends on an idempotent key that is stored in Redis. This is normally
+Deduplication depends on an idempotent key that is stored in Redis. This is usually
 cleared by the configured deduplication strategy.
 
 However, the key can remain until its TTL in certain cases like:

doc/policy/maintenance.md

@@ -102,7 +102,7 @@ accessible.
 
 ### Backporting to older releases
 
-Backporting to more than one stable release is normally reserved for [security releases](#security-releases).
+Backporting to more than one stable release is usually reserved for [security releases](#security-releases).
 In some cases, however, we may need to backport *a bug fix* to more than one stable
 release, depending on the severity of the bug.
 

doc/user/project/file_lock.md

@@ -147,7 +147,7 @@ permissions to the project:
 git lfs unlock --id=123 --force
 ```
 
-You can normally push files to GitLab whether they're locked or unlocked.
+You can push files to GitLab whether they're locked or unlocked.
 
 NOTE:
 Although multi-branch file locks can be created and managed through the Git LFS

doc/user/project/releases/release_evidence.md

@@ -97,7 +97,7 @@ Evidence collection snapshots are visible on the Releases page, along with the t
 
 When you create a release, if [job artifacts](../../../ci/yaml/index.md#artifactsreports) are included in the last pipeline that ran, they are automatically included in the release as release evidence.
 
-Although job artifacts normally expire, artifacts included in release evidence do not expire.
+Although job artifacts usually expire, artifacts included in release evidence do not expire.
 
 To enable job artifact collection you must specify both: