Add latest changes from gitlab-org/gitlab@master

19 files changed, 66 insertions, 63 deletions

diff --git a/doc/development/advanced_search.md b/doc/development/advanced_search.md
index 73a8191b789..30e1874f1ed 100644
--- a/doc/development/advanced_search.md
+++ b/doc/development/advanced_search.md
@@ -167,7 +167,7 @@ These proxy objects would talk to Elasticsearch server directly (see top half of
 
 ![Elasticsearch Architecture](img/elasticsearch_architecture.svg)
 
-In the planned new design, each model would have a pair of corresponding sub-classed proxy objects, in which model-specific logic is located. For example, `Snippet` would have `SnippetClassProxy` and `SnippetInstanceProxy` (being subclass of `Elasticsearch::Model::Proxy::ClassMethodsProxy` and `Elasticsearch::Model::Proxy::InstanceMethodsProxy`, respectively).
+In the planned new design, each model would have a pair of corresponding sub-classed proxy objects, in which model-specific logic is located. For example, `Snippet` would have `SnippetClassProxy` being a subclass of `Elasticsearch::Model::Proxy::ClassMethodsProxy`. `Snippet` would have `SnippetInstanceProxy` being a subclass of `Elasticsearch::Model::Proxy::InstanceMethodsProxy`.
 
 `__elasticsearch__` would represent another layer of proxy object, keeping track of multiple actual proxy objects. It would forward method calls to the appropriate index. For example:
 
diff --git a/doc/development/fe_guide/content_editor.md b/doc/development/fe_guide/content_editor.md
index 25140a067ca..fdeabc99ea4 100644
--- a/doc/development/fe_guide/content_editor.md
+++ b/doc/development/fe_guide/content_editor.md
@@ -4,27 +4,27 @@ group: Knowledge
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Content Editor development guidelines
+# Rich text editor development guidelines
 
-The Content Editor is a UI component that provides a WYSIWYG editing
+The rich text editor is a UI component that provides a WYSIWYG editing
 experience for [GitLab Flavored Markdown](../../user/markdown.md) in the GitLab application.
 It also serves as the foundation for implementing Markdown-focused editors
 that target other engines, like static site generators.
 
 We use [Tiptap 2.0](https://tiptap.dev/) and [ProseMirror](https://prosemirror.net/)
-to build the Content Editor. These frameworks provide a level of abstraction on top of
+to build the rich text editor. These frameworks provide a level of abstraction on top of
 the native
 [`contenteditable`](https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content) web technology.
 
 ## Usage guide
 
-Follow these instructions to include the Content Editor in a feature.
+Follow these instructions to include the rich text editor in a feature.
 
-1. [Include the Content Editor component](#include-the-content-editor-component).
+1. [Include the rich text editor component](#include-the-rich-text-editor-component).
 1. [Set and get Markdown](#set-and-get-markdown).
 1. [Listen for changes](#listen-for-changes).
 
-### Include the Content Editor component
+### Include the rich text editor component
 
 Import the `ContentEditor` Vue component. We recommend using asynchronous named imports to
 take advantage of caching, as the ContentEditor is a big dependency.
@@ -43,7 +43,7 @@ export default {
 </script>
 ```
 
-The Content Editor requires two properties:
+The rich text editor requires two properties:
 
 - `renderMarkdown` is an asynchronous function that returns the response (String) of invoking the
 [Markdown API](../../api/markdown.md).
@@ -95,7 +95,7 @@ export default {
 
 ### Listen for changes
 
-You can still react to changes in the Content Editor. Reacting to changes helps
+You can still react to changes in the rich text editor. Reacting to changes helps
 you know if the document is empty or dirty. Use the `@change` event handler for
 this purpose.
 
@@ -131,7 +131,7 @@ export default {
 
 ## Implementation guide
 
-The Content Editor is composed of three main layers:
+The rich text editor is composed of three main layers:
 
 - **The editing tools UI**, like the toolbar and the table structure editor. They
   display the editor's state and mutate it by dispatching commands.
@@ -163,7 +163,7 @@ We implement [node views](https://tiptap.dev/guide/node-views/vue/#node-views-wi
 to provide inline editing tools for some content types, like tables and images. Node views
 allow separating the presentation of a content type from its
 [model](https://prosemirror.net/docs/guide/#doc.data_structures). Using a Vue component in
-the presentation layer enables sophisticated editing experiences in the Content Editor.
+the presentation layer enables sophisticated editing experiences in the rich text editor.
 Node views are located in `~/content_editor/components/wrappers`.
 
 #### Dispatch commands
@@ -248,19 +248,19 @@ export default {
 
 The Tiptap [Editor](https://tiptap.dev/api/editor) class manages
 the editor's state and encapsulates all the business logic that powers
-the Content Editor. The Content Editor constructs a new instance of this class and
+the rich text editor. The rich text editor constructs a new instance of this class and
 provides all the necessary extensions to support
 [GitLab Flavored Markdown](../../user/markdown.md).
 
 #### Implement new extensions
 
-Extensions are the building blocks of the Content Editor. You can learn how to implement
+Extensions are the building blocks of the rich text editor. You can learn how to implement
 new ones by reading [the Tiptap guide](https://tiptap.dev/guide/custom-extensions).
 We recommend checking the list of built-in [nodes](https://tiptap.dev/api/nodes) and
 [marks](https://tiptap.dev/api/marks) before implementing a new extension
 from scratch.
 
-Store the Content Editor extensions in the `~/content_editor/extensions` directory.
+Store the rich text editor extensions in the `~/content_editor/extensions` directory.
 When using a Tiptap built-in extension, wrap it in a ES6 module inside this directory:
 
 ```javascript
@@ -313,11 +313,11 @@ by first rendering the Markdown as HTML using the [Markdown API endpoint](../../
 
 ```mermaid
 sequenceDiagram
-    participant A as Content Editor
-    participant E as Tiptap Object
-    participant B as Markdown Serializer
+    participant A as rich text editor
+    participant E as Tiptap object
+    participant B as Markdown serializer
     participant C as Markdown API
-    participant D as ProseMirror Parser
+    participant D as ProseMirror parser
     A->>B: deserialize(markdown)
     B->>C: render(markdown)
     C-->>B: html
@@ -343,13 +343,13 @@ classes documentation before implementing a serializer:
 
 ```mermaid
 sequenceDiagram
-    participant A as Content Editor
-    participant B as Markdown Serializer
+    participant A as rich text editor
+    participant B as Markdown serializer
     participant C as ProseMirror Markdown
     A->>B: serialize(document)
     B->>C: serialize(document, serializers)
-    C-->>A: markdown string
+    C-->>A: Markdown string
 ```
 
 `prosemirror-markdown` requires implementing a serializer function for each content type supported
-by the Content Editor. We implement serializers in `~/content_editor/services/markdown_serializer.js`.
+by the rich text editor. We implement serializers in `~/content_editor/services/markdown_serializer.js`.
diff --git a/doc/development/fe_guide/graphql.md b/doc/development/fe_guide/graphql.md
index 915877d3980..00c7bb5d6c8 100644
--- a/doc/development/fe_guide/graphql.md
+++ b/doc/development/fe_guide/graphql.md
@@ -591,8 +591,7 @@ pageInfo {
 
 Here:
 
-- `startCursor` and `endCursor` display the cursor of the first and last items
-  respectively.
+- `startCursor` displays the cursor of the first items and `endCursor` displays the cursor of the last items.
 - `hasPreviousPage` and `hasNextPage` allow us to check if there are more pages
   available before or after the current page.
 
diff --git a/doc/development/fe_guide/index.md b/doc/development/fe_guide/index.md
index 3d05d395ef1..c9e8a38f63b 100644
--- a/doc/development/fe_guide/index.md
+++ b/doc/development/fe_guide/index.md
@@ -108,8 +108,8 @@ How we implement [keyboard shortcuts](keyboard_shortcuts.md) that can be customi
 
 ## Editors
 
-GitLab text editing experiences are provided by the [Source Editor](source_editor.md) and
-the [Content Editor](content_editor.md).
+GitLab text editing experiences are provided by the [source editor](source_editor.md) and
+the [rich text editor](content_editor.md).
 
 ## Frontend FAQ
 
diff --git a/doc/development/fe_guide/logging.md b/doc/development/fe_guide/logging.md
index 30cf290fbe8..b2b0771d9e5 100644
--- a/doc/development/fe_guide/logging.md
+++ b/doc/development/fe_guide/logging.md
@@ -22,7 +22,7 @@ Whenever a `catch(e)` exists, and `e` is something unexpected, log the details.
 
 ### What makes an error unexpected?
 
-Sometimes a caught exception can be part of normal operations. For instance, third-party
+Sometimes a caught exception can be part of standard operations. For instance, third-party
 libraries might throw an exception based on certain inputs. If we can gracefully
 handle these exceptions, then they are expected. Don't log them noisily.
 For example:
@@ -50,7 +50,7 @@ try {
 
 We have a helpful `~/lib/logger` module which encapsulates how we can
 consistently log runtime errors in GitLab. Import `logError` from this
-module, and use it as you normally would `console.error`. Pass the actual `Error`
+module, and use it as you typically would `console.error`. Pass the actual `Error`
 object, so the stack trace and other details can be captured in the log:
 
 ```javascript
diff --git a/doc/development/fe_guide/merge_request_widget_extensions.md b/doc/development/fe_guide/merge_request_widget_extensions.md
index 07029aec015..f5bf9049db1 100644
--- a/doc/development/fe_guide/merge_request_widget_extensions.md
+++ b/doc/development/fe_guide/merge_request_widget_extensions.md
@@ -261,8 +261,10 @@ important not to alter the status code and headers.
 
 If `fetchCollapsedData()` or `fetchFullData()` methods throw an error:
 
-- The loading state of the extension is updated to `LOADING_STATES.collapsedError`
-  and `LOADING_STATES.expandedError` respectively.
+- The loading state of the extension is updated to `LOADING_STATES.collapsedError` if
+  `fetchCollapsedData()` method throws an error.
+- The loading state of the extension is updated to `LOADING_STATES.expandedError` if
+  `fetchFullData()` method throws an error.
 - The extensions header displays an error icon and updates the text to be either:
   - The text defined in `$options.i18n.error`.
   - "Failed to load" if `$options.i18n.error` is not defined.
diff --git a/doc/development/git_object_deduplication.md b/doc/development/git_object_deduplication.md
index e98ebe5efe1..961bfca0d9b 100644
--- a/doc/development/git_object_deduplication.md
+++ b/doc/development/git_object_deduplication.md
@@ -56,7 +56,7 @@ identical to) the fork networks that get formed when users fork
 projects.
 
 At the Git level, pool repositories are created and managed using Gitaly
-RPC calls. Just like with normal repositories, the authority on which
+RPC calls. Just like with typical repositories, the authority on which
 pool repositories exist, and which repositories borrow from them, lies
 at the Rails application level in SQL.
 
@@ -144,7 +144,7 @@ are as follows:
 
 ### Consequences
 
-- If a normal Project participating in a pool gets moved to another
+- If a typical Project participating in a pool gets moved to another
   Gitaly storage shard, its "belongs to PoolRepository" relation will
   be broken. Because of the way moving repositories between shard is
   implemented, we get a fresh self-contained copy
diff --git a/doc/development/gitlab_flavored_markdown/specification_guide/index.md b/doc/development/gitlab_flavored_markdown/specification_guide/index.md
index ae78daa3687..ba37c858b63 100644
--- a/doc/development/gitlab_flavored_markdown/specification_guide/index.md
+++ b/doc/development/gitlab_flavored_markdown/specification_guide/index.md
@@ -124,7 +124,7 @@ to report this.
 
 #### Official specifications vs internal extensions
 
-Within GFM and GLFM respectively, both GitHub and GitLab have two "sets" of Markdown they support:
+GFM for GitHub and GLFM for GitLab have two "sets" of Markdown they support:
 
 - Official specification
 - Internal extensions
@@ -297,9 +297,9 @@ The Markdown dialect used in the GitLab application has a dual requirement for r
 1. Rendering to static read-only HTML format, to be displayed in various
    places throughout the application.
 1. Rendering editable content in the
-   [Content Editor](https://about.gitlab.com/direction/plan/knowledge/content_editor/),
+   [rich text editor](https://about.gitlab.com/direction/plan/knowledge/content_editor/),
    a ["What You See Is What You Get" (WYSIWYG)](https://en.wikipedia.org/wiki/WYSIWYG)
-   editor. The Content Editor supports real-time instant switching between an editable
+   editor. The rich text editor supports real-time instant switching between an editable
    Markdown source and an editable WYSIWYG document.
 
 These requirements means that GitLab has two independent parser and renderer
@@ -312,14 +312,14 @@ implementations:
    GitHub's fork of the reference parser for CommonMark. `libcmark-gfm` is an extended
    version of the C reference implementation of [CommonMark](https://commonmark.org/)
 1. The frontend parser / renderer supports parsing and _WYSIWYG_ rendering for
-   the Content Editor. It is implemented in JavaScript. Parsing is based on the
+   the rich text editor. It is implemented in JavaScript. Parsing is based on the
    [Remark](https://github.com/remarkjs/remark) Markdown parser, which produces a
    MDAST Abstract Syntax Tree (MDAST). Rendering is the process of turning
    an MDAST into a [ProseMirror document](../../fe_guide/content_editor.md). Then,
    ProseMirror is used to render a ProseMirror document to WYSIWYG HTML. In this
    document, we refer to the process of turning Markdown into an MDAST as the
    _frontend / JavaScript parser_, and the entire process of rendering Markdown
-   to WYSIWYG HTML in ProseMirror as the _Content Editor_. Several
+   to WYSIWYG HTML in ProseMirror as the _rich text editor_. Several
    requirements drive the need for an independent frontend parser / renderer
    implementation, including:
    1. Lack of necessary support for accurate source mapping in the HTML renderer
@@ -356,7 +356,7 @@ used when running [Markdown snapshot testing](#markdown-snapshot-testing).
 
 #### WYSIWYG HTML
 
-**WYSIWYG HTML** is HTML produced by the frontend (JavaScript) Content Editor,
+**WYSIWYG HTML** is HTML produced by the frontend (JavaScript) rich text editor,
 which includes parsing and rendering logic. It is used to present an editable document
 in the ProseMirror WYSIWYG editor.
 
@@ -472,7 +472,7 @@ generating the HTML for footnote examples. Even though it is in the production c
 no effect unless it is explicitly set, therefore it is innocuous. It allows us to avoid
 the more-complex regex-based normalization described below.
 
-The current example of this is when normally random footnote IDs are overridden to be deterministic
+The current example of this is when footnote IDs that are usually random are overridden to be deterministic
 by setting `GITLAB_TEST_FOOTNOTE_ID`. It is set along with the fixtures setup in the
 [`spec/support/shared_contexts/glfm/example_snapshot_fixtures.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/spec/support/shared_contexts/glfm/example_snapshot_fixtures.rb)
 shared context.
@@ -554,9 +554,9 @@ specification and testing infrastructure:
    1. The frontend (JavaScript) parser and renderer (which includes GitLab custom
       code and Remark) can convert Markdown to the expected ProseMirror JSON
       representing a ProseMirror document.
-   1. The **Content Editor** (which includes the frontend (JavaScript) parser and renderer,
+   1. The **rich text editor** (which includes the frontend (JavaScript) parser and renderer,
       and ProseMirror) can convert Markdown to the expected custom WYSIWYG HTML as rendered by ProseMirror.
-   1. The **Content Editor** can complete a round-trip test, which involves converting
+   1. The **rich text editor** can complete a round-trip test, which involves converting
       from Markdown, to MDAST, to ProseMirror Document, then back to Markdown. It ensures
       the resulting Markdown is exactly identical, with no differences.
 
@@ -734,10 +734,10 @@ Markdown snapshot testing RSpec and Jest `*_spec` files (from main app `spec` fo
 which are driven by `example_snapshot` YAML files.
 
 The actual RSpec and Jest test `*_spec` files (frontend and backend) live
-under the normal relevant locations under `spec`, matching the location of their
+under the usual relevant locations under `spec`, matching the location of their
 corresponding implementations. They can be run either:
 
-- As part of the normal pipelines.
+- As part of the standard pipelines.
 - From the command line or an IDE, just like any other file under `spec`.
 
 However, they are spread across four different locations:
@@ -1329,7 +1329,7 @@ Three types of entries exist, with different HTML for each:
 - **WYSIWYG**
   - The WYSIWYG (frontend, JavaScript-generated) HTML for each entry in
     `glfm_specification/output_example_snapshots/examples_index.yml`.
-  - It is generated (or updated) from the frontend Content Editor implementation via the
+  - It is generated (or updated) from the frontend rich text editor implementation via the
     `update-example-snapshots.rb` script. It can be manually updated for WYSIWYG
     examples with incomplete implementations.
 
@@ -1411,5 +1411,5 @@ This section describes how the scripts can be used to manage the GLFM specificat
 1. Visually inspect and confirm any resulting changes to the [example snapshot files](#output-example-snapshot-files).
 1. Run [`run-snapshot-tests.sh`](#run-snapshot-testssh-script) as a convenience script to run all relevant frontend (RSpec) and backend (Jest) tests which use the example snapshots.
    1. Any frontend or backend snapshot test may also be run individually.
-   1. All frontend and backend tests are also run as part of the continuous integration suite, as they normally are.
+   1. All frontend and backend tests are also run as part of the continuous integration suite, as they typically are.
 1. Commit any changes to the [input specification files](#input-specification-files), [output specification files](#output-specification-files), or [example snapshot files](#output-example-snapshot-files).
diff --git a/doc/development/integrations/secure.md b/doc/development/integrations/secure.md
index 08316230954..09778127050 100644
--- a/doc/development/integrations/secure.md
+++ b/doc/development/integrations/secure.md
@@ -577,8 +577,8 @@ All other attributes are optional.
 
 ##### SAST
 
-The `location` of a SAST vulnerability must have a `file` and a `start_line` field,
-giving the path of the affected file, and the affected line number, respectively.
+The `location` of a SAST vulnerability must have a `file` that gives the path of the affected file and 
+a `start_line` field with the affected line number.
 It may also have an `end_line`, a `class`, and a `method`.
 
 For instance, here is the `location` object for a security flaw found
diff --git a/doc/development/internal_analytics/snowplow/troubleshooting.md b/doc/development/internal_analytics/snowplow/troubleshooting.md
index 885f4e0c16f..e274a4da926 100644
--- a/doc/development/internal_analytics/snowplow/troubleshooting.md
+++ b/doc/development/internal_analytics/snowplow/troubleshooting.md
@@ -31,7 +31,7 @@ While on CloudWatch dashboard set time range to last 4 weeks, to get better pict
 
 ### Troubleshooting GitLab application layer
 
-Drop occurring at application layer can be symptom of some issue, but it might be also a result of normal application lifecycle, intended changes done to analytics instrumentation or experiments tracking
+Drop occurring at application layer can be symptom of some issue, but it might be also a result of typical application lifecycle, intended changes done to analytics instrumentation or experiments tracking
 or even a result of a public holiday in some regions of the world with a larger user-base. To verify if there is an underlying problem to solve, you can check following things:
 
 1. Check `about.gitlab.com` website traffic on [Google Analytics](https://analytics.google.com/analytics/web/) to verify if some public holiday might impact overall use of GitLab system
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md
index 0cfdf7fb4ea..55884152075 100644
--- a/doc/development/migration_style_guide.md
+++ b/doc/development/migration_style_guide.md
@@ -138,7 +138,7 @@ This will generate:
 
 Changes to the schema should be committed to `db/structure.sql`. This
 file is automatically generated by Rails when you run
-`bundle exec rails db:migrate`, so you normally should not
+`bundle exec rails db:migrate`, so you typically should not
 edit this file by hand. If your migration is adding a column to a
 table, that column is added at the bottom. Please do not reorder
 columns manually for existing tables as this causes confusion to
@@ -722,7 +722,7 @@ same migration, as the migrations run before the model code is updated and
 models will have an old schema cache, meaning they won't know about this column
 and won't be able to set it. In this case it's recommended to:
 
-1. Add the column with default value in a normal migration.
+1. Add the column with default value in a standard migration.
 1. Remove the default in a post-deployment migration.
 
 The post-deployment migration happens after the application restarts,
diff --git a/doc/development/packages/new_format_development.md b/doc/development/packages/new_format_development.md
index f730d4f9476..66e6cb89661 100644
--- a/doc/development/packages/new_format_development.md
+++ b/doc/development/packages/new_format_development.md
@@ -221,7 +221,7 @@ implemented in the same file.
 After the route has been added, you must add an additional `/authorize` version of the upload endpoint to your API file.
 [This example](https://gitlab.com/gitlab-org/gitlab/-/blob/398fef1ca26ae2b2c3dc89750f6b20455a1e5507/ee/lib/api/maven_packages.rb#L164)
 shows the additional endpoint added for Maven. The `/authorize` endpoint verifies and authorizes the request from workhorse,
-then the normal upload endpoint is implemented below, consuming the metadata that Workhorse provides to
+then the typical upload endpoint is implemented below, consuming the metadata that Workhorse provides to
 create the package record. Workhorse provides a variety of file metadata such as type, size, and different checksum formats.
 
 For testing purposes, you may want to [enable object storage](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/object_storage.md)
diff --git a/doc/development/policies.md b/doc/development/policies.md
index 65f96ccea4e..38f1fc54bf4 100644
--- a/doc/development/policies.md
+++ b/doc/development/policies.md
@@ -104,8 +104,9 @@ An example debug output would look as follows:
 
 Each line represents a rule that was evaluated. There are a few things to note:
 
-1. The `-` or `+` symbol indicates whether the rule block was evaluated to be
-   `false` or `true`, respectively.
+1. The `-` symbol indicates the rule block was evaluated to be
+   `false`. A `+` symbol indicates the rule block was evaluated to be
+   `true`.
 1. The number inside the brackets indicates the score.
 1. The last part of the line (for example, `@john : Issue/1`) shows the username
    and subject for that rule.
diff --git a/doc/development/product_qualified_lead_guide/index.md b/doc/development/product_qualified_lead_guide/index.md
index 9f5a1a1110f..2b78f012159 100644
--- a/doc/development/product_qualified_lead_guide/index.md
+++ b/doc/development/product_qualified_lead_guide/index.md
@@ -15,7 +15,7 @@ A hand-raise PQL is a user who requests to speak to sales from within the produc
 1. Set up GDK with a connection to your local CustomersDot instance.
 1. Set up CustomersDot to talk to a staging instance of Workato.
 
-1. Set up CustomersDot using the [normal install instructions](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/doc/setup/installation_steps.md).
+1. Set up CustomersDot using the [standard install instructions](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/staging/doc/setup/installation_steps.md).
 1. Set the `CUSTOMER_PORTAL_URL` environment variable to your local (or ngrok) URL of your CustomersDot instance.
 1. Place `export CUSTOMER_PORTAL_URL='https://XXX.ngrok.io/'` in your shell `rc` script (`~/.zshrc` or `~/.bash_profile` or `~/.bashrc`) and restart GDK.
 1. Enter the credentials on CustomersDot development to Workato in your `/config/secrets.yml` and restart. Credentials for the Workato Staging are in the 1Password Subscription portal vault. The URL for staging is `https://apim.workato.com/gitlab-dev/services/marketo/lead`.
diff --git a/doc/development/project_templates.md b/doc/development/project_templates.md
index cc53ef77c62..da933c8a009 100644
--- a/doc/development/project_templates.md
+++ b/doc/development/project_templates.md
@@ -19,8 +19,8 @@ To make the project template available when creating a new project, the vendorin
 
 1. Create a working template ([example](https://gitlab.com/gitlab-org/project-templates/dotnetcore))
    - 2 types of built-in templates are available within GitLab:
-     - **Normal templates**: Available in GitLab Core, Starter and above (this is the most common type of built-in template).
-       - To contribute a normal template:
+     - **Standard templates**: Available in GitLab Core, Starter and above (this is the most common type of built-in template).
+       - To contribute a standard template:
          - Add details of the template in the `localized_templates_table` method in `gitlab/lib/gitlab/project_template.rb`,
          - Add details of the template in `spec/lib/gitlab/project_template_spec.rb`, in the test for the `all` method, and
          - Add details of the template in `gitlab/app/assets/javascripts/projects/default_project_templates.js`.
diff --git a/doc/development/reactive_caching.md b/doc/development/reactive_caching.md
index 9e3b1f58abe..d0652c85c6d 100644
--- a/doc/development/reactive_caching.md
+++ b/doc/development/reactive_caching.md
@@ -197,9 +197,8 @@ There are some `class_attribute` options which can be tweaked.
   self.reactive_cache_key = -> (record) { [model_name.singular, record.id] }
   ```
 
-- The `data` and `alive` cache keys in this case are `"ExampleModel:1:arg1:arg2"`
-  and `"ExampleModel:1:arg1:arg2:alive"` respectively, where `ExampleModel` is the
-  name of the model, `1` is the ID of the record, `arg1` and `arg2` are parameters
+- The `data` cache key is `"ExampleModel:1:arg1:arg2"` and `alive` cache keys is `"ExampleModel:1:arg1:arg2:alive"`,
+  where `ExampleModel` is the name of the model, `1` is the ID of the record, `arg1` and `arg2` are parameters
   passed to `with_reactive_cache`.
 - If you're including this concern in an integration (`app/models/integrations/`) instead, you must override
   the default by adding the following to your integration:
diff --git a/doc/development/secure_coding_guidelines.md b/doc/development/secure_coding_guidelines.md
index c5e7a58af0d..8d6f36bb189 100644
--- a/doc/development/secure_coding_guidelines.md
+++ b/doc/development/secure_coding_guidelines.md
@@ -333,7 +333,7 @@ XSS issues are commonly classified in three categories, by their delivery method
 
 ### Impact
 
-The injected client-side code is executed on the victim's browser in the context of their current session. This means the attacker could perform any same action the victim would normally be able to do through a browser. The attacker would also have the ability to:
+The injected client-side code is executed on the victim's browser in the context of their current session. This means the attacker could perform any same action the victim would typically be able to do through a browser. The attacker would also have the ability to:
 
 - <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> [log victim keystrokes](https://youtu.be/2VFavqfDS6w?t=1367)
 - launch a network scan from the victim's browser
@@ -524,7 +524,7 @@ of these behaviors.
 
 The Ruby method [`Pathname.join`](https://ruby-doc.org/stdlib-2.7.4/libdoc/pathname/rdoc/Pathname.html#method-i-join)
 joins path names. Using methods in a specific way can result in a path name typically prohibited in
-normal use. In the examples below, we see attempts to access `/etc/passwd`, which is a sensitive file:
+typical use. In the examples below, we see attempts to access `/etc/passwd`, which is a sensitive file:
 
 ```ruby
 require 'pathname'
diff --git a/doc/development/sidekiq/compatibility_across_updates.md b/doc/development/sidekiq/compatibility_across_updates.md
index d20f4230fc8..1d8b9d15cc6 100644
--- a/doc/development/sidekiq/compatibility_across_updates.md
+++ b/doc/development/sidekiq/compatibility_across_updates.md
@@ -205,6 +205,6 @@ end
 
 ```
 
-You must rename the queue in a post-deployment migration not in a normal
+You must rename the queue in a post-deployment migration not in a standard
 migration. Otherwise, it runs too early, before all the workers that
 schedule these jobs have stopped running. See also [other examples](../database/post_deployment_migrations.md#use-cases).
diff --git a/doc/development/testing_guide/contract/index.md b/doc/development/testing_guide/contract/index.md
index cf23792e239..577699fa828 100644
--- a/doc/development/testing_guide/contract/index.md
+++ b/doc/development/testing_guide/contract/index.md
@@ -78,7 +78,9 @@ As mentioned in the [folder structure section](#consumer-tests), consumer tests
 
 #### Provider naming
 
-These are the API endpoints that provides the data to the consumer so they are named according to the API endpoint they pertain to. Be mindful that this begins with the HTTP request method and the rest of the name is as descriptive as possible. For example, if we're writing a test for the `GET /groups/:id/projects` endpoint, we don't want to name it "GET projects endpoint" as there is a `GET /projects` endpoint as well that also fetches a list of projects the user has access to across all of GitLab. To choose an appropriate name, we can start by checking out our [API documentation](../../../api/api_resources.md) and naming it the same way it is named in there while making sure to keep the name in sentence case. So the [`GET /groups/:id/projects`](../../../api/groups.md#list-a-groups-projects) would be called `GET list a group's projects` and [`GET /projects`](../../../api/projects.md#list-all-projects) would be called `GET list all projects`. Subsequently, the test files are named `get_list_a_groups_projects_helper.rb` and `get_list_all_projects_helper.rb` respectively.
+These are the API endpoints that provide the data to the consumer so they are named according to the API endpoint they pertain to. Be mindful that this begins with the HTTP request method and the rest of the name is as descriptive as possible. For example, if we're writing a test for the `GET /groups/:id/projects` endpoint, we don't want to name it "GET projects endpoint" as there is a `GET /projects` endpoint as well that also fetches a list of projects the user has access to across all of GitLab.
+
+To choose an appropriate name, we can start by checking out our [API documentation](../../../api/api_resources.md) and naming it the same way it is named in there while making sure to keep the name in sentence case. So [`GET /groups/:id/projects`](../../../api/groups.md#list-a-groups-projects) would be called `GET list a group's projects` and the test file name is `get_list_a_groups_projects_helper.rb`. [`GET /projects`](../../../api/projects.md#list-all-projects) would be called `GET list all projects`, and the test file name `get_list_all_projects_helper.rb`.
 
 There are some cases where the provider being tested may not be documented so, in those cases, fall back to starting with the HTTP request method followed by a name that is as descriptive as possible to ensure it's easy to tell what the provider is for.