Add latest changes from gitlab-org/gitlab@master

36 files changed, 57 insertions, 57 deletions

diff --git a/doc/development/changelog.md b/doc/development/changelog.md
index 93862f51cc8..7dc3ae0a80b 100644
--- a/doc/development/changelog.md
+++ b/doc/development/changelog.md
@@ -114,7 +114,7 @@ making it both concise and descriptive, err on the side of descriptive.
 
 - **Bad:** Go to a project order.
 - **Good:** Show a user's starred projects at the top of the "Go to project"
-  dropdown.
+  dropdown list.
 
 The first example provides no context of where the change was made, or why, or
 how it benefits the user.
@@ -126,9 +126,9 @@ how it benefits the user.
 Again, the first example is too vague and provides no context.
 
 - **Bad:** Fixes and Improves CSS and HTML problems in mini pipeline graph and
-  builds dropdown.
+  builds dropdown list.
 - **Good:** Fix tooltips and hover states in mini pipeline graph and builds
-  dropdown.
+  dropdown list.
 
 The first example is too focused on implementation details. The user doesn't
 care that we changed CSS and HTML, they care about the _end result_ of those
diff --git a/doc/development/cicd/templates.md b/doc/development/cicd/templates.md
index 4e0baf33ead..85ac58e749d 100644
--- a/doc/development/cicd/templates.md
+++ b/doc/development/cicd/templates.md
@@ -391,7 +391,7 @@ This is useful information for reviewers to make sure the template is safe to be
 ### Make sure the new template can be selected in UI
 
 Templates located under some directories are also [selectable in the **New file** UI](#template-directories).
-When you add a template into one of those directories, make sure that it correctly appears in the dropdown:
+When you add a template into one of those directories, make sure that it correctly appears in the dropdown list:
 
 ![CI/CD template selection](img/ci_template_selection_v13_1.png)
 
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index db0ac4def75..3c129645756 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -57,7 +57,7 @@ We make the following assumption with regards to automatically being considered
 - Team members working on a specific feature (for example, search) are considered domain experts for that feature.
 
 We default to assigning reviews to team members with domain expertise.
-When a suitable [domain expert](#domain-experts) isn't available, you can choose any team member to review the MR, or simply follow the [Reviewer roulette](#reviewer-roulette) recommendation.
+When a suitable [domain expert](#domain-experts) isn't available, you can choose any team member to review the MR, or follow the [Reviewer roulette](#reviewer-roulette) recommendation.
 
 To find a domain expert:
 
diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md
index 93b5dd02374..df337bb2809 100644
--- a/doc/development/contributing/issue_workflow.md
+++ b/doc/development/contributing/issue_workflow.md
@@ -373,7 +373,7 @@ below will make it easy to manage this, without unnecessary overhead.
    which might lead to many hard problems to solve. Changing some text in GitLab
    is probably 1, adding a new Git Hook maybe 4 or 5, big features 7-9.
 1. If something is very large, it should probably be split up in multiple
-   issues or chunks. You can simply not set the weight of a parent issue and set
+   issues or chunks. You can not set the weight of a parent issue and set
    weights to children issues.
 
 ## Regression issues
@@ -432,7 +432,7 @@ original merge request - or not tracked at all!
 The overheads of scheduling, and rate of change in the GitLab codebase, mean
 that the cost of a trivial technical debt issue can quickly exceed the value of
 tracking it. This generally means we should resolve these in the original merge
-request - or simply not create a follow-up issue at all.
+request - or not create a follow-up issue at all.
 
 For example, a typo in a comment that is being copied between files is worth
 fixing in the same MR, but not worth creating a follow-up issue for. Renaming a
diff --git a/doc/development/dangerbot.md b/doc/development/dangerbot.md
index 304d9396670..52503f2d9c8 100644
--- a/doc/development/dangerbot.md
+++ b/doc/development/dangerbot.md
@@ -13,7 +13,7 @@ Danger is a gem that runs in the CI environment, like any other analysis tool.
 What sets it apart from (for example, RuboCop) is that it's designed to allow you to
 easily write arbitrary code to test properties of your code or changes. To this
 end, it provides a set of common helpers and access to information about what
-has actually changed in your environment, then simply runs your code!
+has actually changed in your environment, then runs your code!
 
 If Danger is asking you to change something about your merge request, it's best
 just to make the change. If you want to learn how Danger works, or make changes
diff --git a/doc/development/database/background_migrations.md b/doc/development/database/background_migrations.md
index 3aff7bbe695..8e6f29b9eb8 100644
--- a/doc/development/database/background_migrations.md
+++ b/doc/development/database/background_migrations.md
@@ -86,7 +86,7 @@ migration classes must be defined in the namespace
 
 Scheduling a background migration should be done in a post-deployment
 migration that includes `Gitlab::Database::MigrationHelpers`
-To do so, simply use the following code while
+To do so, use the following code while
 replacing the class name and arguments with whatever values are necessary for
 your migration:
 
@@ -110,7 +110,7 @@ You also need to make sure that newly created data is either migrated, or
 saved in both the old and new version upon creation. For complex and time
 consuming migrations it's best to schedule a background job using an
 `after_create` hook so this doesn't affect response timings. The same applies to
-updates. Removals in turn can be handled by simply defining foreign keys with
+updates. Removals in turn can be handled by defining foreign keys with
 cascading deletes.
 
 ### Rescheduling background migrations
diff --git a/doc/development/database/creating_enums.md b/doc/development/database/creating_enums.md
index 0a882ca7e0f..73c3f546728 100644
--- a/doc/development/database/creating_enums.md
+++ b/doc/development/database/creating_enums.md
@@ -103,7 +103,7 @@ This looks working as a workaround, however, this approach has some downsides th
   Therefore, you need to be careful of that the offset doesn't exceed the maximum value of 2 bytes integer.
 
 As a conclusion, you should define all of the key/value pairs in FOSS.
-For example, you can simply write the following code in the above case:
+For example, you can write the following code in the above case:
 
 ```ruby
 class Pipeline < ApplicationRecord
diff --git a/doc/development/database/insert_into_tables_in_batches.md b/doc/development/database/insert_into_tables_in_batches.md
index c674694f365..78aa793f28b 100644
--- a/doc/development/database/insert_into_tables_in_batches.md
+++ b/doc/development/database/insert_into_tables_in_batches.md
@@ -181,7 +181,7 @@ end
 ```
 
 You can still save relations that are not `BulkInsertSafe` in this block; they
-simply are treated as if you had invoked `save` from outside the block.
+are treated as if you had invoked `save` from outside the block.
 
 ## Known limitations
 
diff --git a/doc/development/database/loose_foreign_keys.md b/doc/development/database/loose_foreign_keys.md
index 24a1f90957d..abf66368548 100644
--- a/doc/development/database/loose_foreign_keys.md
+++ b/doc/development/database/loose_foreign_keys.md
@@ -311,7 +311,7 @@ end
 The "`it has loose foreign keys`" shared example can be used to test the presence of the `ON DELETE` trigger and the
 loose foreign key definitions.
 
-Simply add to the model test file:
+Add to the model test file:
 
 ```ruby
 it_behaves_like 'it has loose foreign keys' do
diff --git a/doc/development/database/pagination_guidelines.md b/doc/development/database/pagination_guidelines.md
index edf15f03287..54b315b9dd9 100644
--- a/doc/development/database/pagination_guidelines.md
+++ b/doc/development/database/pagination_guidelines.md
@@ -50,9 +50,9 @@ When we list records on the page we often provide additional filters and differe
 For the MVC version, consider the following:
 
 - Reduce the number of sort options to the minimum.
-- Reduce the number of filters (dropdown, search bar) to the minimum.
+- Reduce the number of filters (dropdown list, search bar) to the minimum.
 
-To make sorting and pagination efficient, for each sort option we need at least two database indexes (ascending, descending order). If we add filter options (by state or by author), we might need more indexes to maintain good performance. Note that indexes are not free, they can significantly affect the `UPDATE` query timings.
+To make sorting and pagination efficient, for each sort option we need at least two database indexes (ascending, descending order). If we add filter options (by state or by author), we might need more indexes to maintain good performance. Indexes are not free, they can significantly affect the `UPDATE` query timings.
 
 It's not possible to make all filter and sort combinations performant, so we should try optimizing the performance by usage patterns.
 
@@ -154,7 +154,7 @@ Here we're leveraging the ordered property of the b-tree database index. Values
 
 ##### `COUNT(*)` on a large dataset
 
-Kaminari by default executes a count query to determine the number of pages for rendering the page links. Count queries can be quite expensive for a large table. In an unfortunate scenario the queries simply time out.
+Kaminari by default executes a count query to determine the number of pages for rendering the page links. Count queries can be quite expensive for a large table. In an unfortunate scenario the queries time out.
 
 To work around this, we can run Kaminari without invoking the count SQL query.
 
@@ -264,7 +264,7 @@ Looking at the query execution plan, we can see that this query read only 5 rows
 
 ##### No page numbers
 
-Offset pagination provides an easy way to request a specific page. We can simply edit the URL and modify the `page=` URL parameter. Keyset pagination cannot provide page numbers because the paging logic might depend on different columns.
+Offset pagination provides an easy way to request a specific page. We can edit the URL and modify the `page=` URL parameter. Keyset pagination cannot provide page numbers because the paging logic might depend on different columns.
 
 In the previous example, the column is the `id`, so we might see something like this in the `URL`:
 
diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md
index 98b1c4e4ae7..c52b3b5adae 100644
--- a/doc/development/documentation/index.md
+++ b/doc/development/documentation/index.md
@@ -465,7 +465,7 @@ RSpec.describe '<What I am taking screenshots of>', :js do
 
 #### Full page screenshots
 
-To take a full page screenshot simply `visit the page` and perform any expectation on real content (to have capybara wait till the page is ready and not take a white screenshot).
+To take a full page screenshot, `visit the page` and perform any expectation on real content (to have capybara wait till the page is ready and not take a white screenshot).
 
 #### Element screenshot
 
diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md
index 636b5e812e8..2516196d2e0 100644
--- a/doc/development/ee_features.md
+++ b/doc/development/ee_features.md
@@ -824,7 +824,7 @@ end
 
 Sometimes we need EE-specific behavior in some of the APIs. Normally we could
 use EE methods to override CE methods, however API routes are not methods and
-therefore can't be simply overridden. We need to extract them into a standalone
+therefore cannot be overridden. We need to extract them into a standalone
 method, or introduce some "hooks" where we could inject behavior in the CE
 route. Something like this:
 
@@ -875,8 +875,8 @@ end
 
 #### EE `route_setting`
 
-It's very hard to extend this in an EE module, and this is simply storing
-some meta-data for a particular route. Given that, we could simply leave the
+It's very hard to extend this in an EE module, and this is storing
+some meta-data for a particular route. Given that, we could leave the
 EE `route_setting` in CE as it doesn't hurt and we don't use
 those meta-data in CE.
 
@@ -1416,5 +1416,5 @@ to avoid conflicts during CE to EE merge.
 ### GitLab-svgs
 
 Conflicts in `app/assets/images/icons.json` or `app/assets/images/icons.svg` can
-be resolved simply by regenerating those assets with
+be resolved by regenerating those assets with
 [`yarn run svg`](https://gitlab.com/gitlab-org/gitlab-svgs).
diff --git a/doc/development/elasticsearch.md b/doc/development/elasticsearch.md
index ce7df23c178..ab2d241a781 100644
--- a/doc/development/elasticsearch.md
+++ b/doc/development/elasticsearch.md
@@ -461,8 +461,8 @@ _from "Disk-based Shard Allocation | Elasticsearch Reference" [5.6](https://www.
 The use of Elasticsearch in GitLab is only ever as a secondary data store.
 This means that all of the data stored in Elasticsearch can always be derived
 again from other data sources, specifically PostgreSQL and Gitaly. Therefore if
-the Elasticsearch data store is ever corrupted for whatever reason you can
-simply reindex everything from scratch.
+the Elasticsearch data store is ever corrupted for whatever reason you can reindex
+everything from scratch.
 
 If your Elasticsearch index is incredibly large it may be too time consuming or
 cause too much downtime to reindex from scratch. There aren't any built in
diff --git a/doc/development/fe_guide/design_anti_patterns.md b/doc/development/fe_guide/design_anti_patterns.md
index 225ddeb537d..07de86f5810 100644
--- a/doc/development/fe_guide/design_anti_patterns.md
+++ b/doc/development/fe_guide/design_anti_patterns.md
@@ -146,7 +146,7 @@ Even in these scenarios, consider avoiding the Singleton pattern.
 
 #### Utility Functions
 
-When no state needs to be managed, we can simply export utility functions from a module without
+When no state needs to be managed, we can export utility functions from a module without
 messing with any class instantiation.
 
 ```javascript
diff --git a/doc/development/fe_guide/graphql.md b/doc/development/fe_guide/graphql.md
index 1cf4c1d60b1..9ed3e551ff2 100644
--- a/doc/development/fe_guide/graphql.md
+++ b/doc/development/fe_guide/graphql.md
@@ -330,7 +330,7 @@ Along with creating local data, we can also extend existing GraphQL types with `
 
 ##### Mocking API response with local Apollo cache
 
-Using local Apollo Cache is helpful when we have a need to mock some GraphQL API responses, queries, or mutations locally (such as when they're still not added to our actual API).
+Using local Apollo Cache is helpful when we have a reason to mock some GraphQL API responses, queries, or mutations locally (such as when they're still not added to our actual API).
 
 For example, we have a [fragment](#fragments) on `DesignVersion` used in our queries:
 
@@ -341,7 +341,7 @@ fragment VersionListItem on DesignVersion {
 }
 ```
 
-We also need to fetch the version author and the `created at` property to display in the versions dropdown. But, these changes are still not implemented in our API. We can change the existing fragment to get a mocked response for these new fields:
+We also must fetch the version author and the `created at` property to display in the versions dropdown list. But, these changes are still not implemented in our API. We can change the existing fragment to get a mocked response for these new fields:
 
 ```javascript
 fragment VersionListItem on DesignVersion {
@@ -627,7 +627,7 @@ GraphQL entities are not yet part of the schema, or if they are feature-flagged
 ### Manually triggering queries
 
 Queries on a component's `apollo` property are made automatically when the component is created.
-Some components instead want the network request made on-demand, for example a dropdown with lazy-loaded items.
+Some components instead want the network request made on-demand, for example a dropdown list with lazy-loaded items.
 
 There are two ways to do this:
 
diff --git a/doc/development/feature_flags/controls.md b/doc/development/feature_flags/controls.md
index ad7c6d58bb5..bceb7167645 100644
--- a/doc/development/feature_flags/controls.md
+++ b/doc/development/feature_flags/controls.md
@@ -176,7 +176,7 @@ For project level features:
 Feature.enabled?(:feature_ice_cold_projects, project)
 ```
 
-If you are not certain what percentages to use, simply use the following steps:
+If you are not certain what percentages to use, use the following steps:
 
 1. 25%
 1. 50%
diff --git a/doc/development/go_guide/index.md b/doc/development/go_guide/index.md
index 1af0dc616b8..f45ff6b7d7e 100644
--- a/doc/development/go_guide/index.md
+++ b/doc/development/go_guide/index.md
@@ -357,7 +357,7 @@ Every binary ideally must have structured (JSON) logging in place as it helps
 with searching and filtering the logs. At GitLab we use structured logging in
 JSON format, as all our infrastructure assumes that. When using
 [Logrus](https://github.com/sirupsen/logrus) you can turn on structured
-logging simply by using the build in [JSON formatter](https://github.com/sirupsen/logrus#formatters). This follows the
+logging by using the build in [JSON formatter](https://github.com/sirupsen/logrus#formatters). This follows the
 same logging type we use in our [Ruby applications](../logging.md#use-structured-json-logging).
 
 #### How to use Logrus
diff --git a/doc/development/graphql_guide/batchloader.md b/doc/development/graphql_guide/batchloader.md
index bde7ebdbf9c..ef0b97f4f62 100644
--- a/doc/development/graphql_guide/batchloader.md
+++ b/doc/development/graphql_guide/batchloader.md
@@ -134,7 +134,7 @@ z.sync
 ```
 
 NOTE:
-There is no dependency analysis in the use of batch-loading. There is simply
+There is no dependency analysis in the use of batch-loading. There is
 a pending queue of requests, and as soon as any one result is needed, all pending
 requests are evaluated.
 
diff --git a/doc/development/i18n/merging_translations.md b/doc/development/i18n/merging_translations.md
index 0bc7e3ed925..2a086c796c9 100644
--- a/doc/development/i18n/merging_translations.md
+++ b/doc/development/i18n/merging_translations.md
@@ -79,7 +79,7 @@ recreate it with the following steps:
 ## Manually update the translation levels
 
 There's no automated way to pull the translation levels from Crowdin, to display
-this information in the language selection dropdown. Therefore, the translation
+this information in the language selection dropdown list. Therefore, the translation
 levels are hard-coded in the `TRANSLATION_LEVELS` constant in [`i18n.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/i18n.rb),
 and must be regularly updated.
 
diff --git a/doc/development/image_scaling.md b/doc/development/image_scaling.md
index bb9ed671627..4b19c21a457 100644
--- a/doc/development/image_scaling.md
+++ b/doc/development/image_scaling.md
@@ -68,7 +68,7 @@ controller mixin. Upon receiving a request coming from a client through Workhors
 it should trigger the image scaler as per the criteria mentioned above, and if so, render a special response
 header field (`Gitlab-Workhorse-Send-Data`) with the necessary parameters for Workhorse to carry
 out the scaling request. If Rails decides the request does not constitute a valid image scaling request,
-we simply follow the path we take to serve any ordinary upload.
+we follow the path we take to serve any ordinary upload.
 
 ### Workhorse
 
diff --git a/doc/development/import_project.md b/doc/development/import_project.md
index b8415e530d5..b879d635350 100644
--- a/doc/development/import_project.md
+++ b/doc/development/import_project.md
@@ -16,7 +16,7 @@ There are several ways to import a project.
 
 ### Importing via UI
 
-The first option is to simply [import the Project tarball file via the GitLab UI](../user/project/settings/import_export.md#import-a-project-and-its-data):
+The first option is to [import the Project tarball file via the GitLab UI](../user/project/settings/import_export.md#import-a-project-and-its-data):
 
 1. Create the group `qa-perf-testing`
 1. Import the [GitLab FOSS project tarball](https://gitlab.com/gitlab-org/quality/performance-data/-/blob/master/projects_export/gitlabhq_export.tar.gz) into the Group.
@@ -59,7 +59,7 @@ This script was introduced in GitLab 12.6 for importing large GitLab project exp
 
 As part of this script we also disable direct and background upload to avoid situations where a huge archive is being uploaded to GCS (while being inside a transaction, which can cause idle transaction timeouts).
 
-We can simply run this script from the terminal:
+We can run this script from the terminal:
 
 Parameters:
 
diff --git a/doc/development/merge_request_performance_guidelines.md b/doc/development/merge_request_performance_guidelines.md
index cead73a3034..9d1489836fb 100644
--- a/doc/development/merge_request_performance_guidelines.md
+++ b/doc/development/merge_request_performance_guidelines.md
@@ -44,7 +44,7 @@ and running.
 
 Can the queries used potentially take down any critical services and result in
 engineers being woken up in the night? Can a malicious user abuse the code to
-take down a GitLab instance? Do my changes simply make loading a certain page
+take down a GitLab instance? Do my changes make loading a certain page
 slower? Does execution time grow exponentially given enough load or data in the
 database?
 
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md
index 40cc1e58258..f59c1fd8368 100644
--- a/doc/development/migration_style_guide.md
+++ b/doc/development/migration_style_guide.md
@@ -612,7 +612,7 @@ Note that it is not necessary to check if the index exists prior to
 removing it, however it is required to specify the name of the
 index that is being removed. This can be done either by passing the name
 as an option to the appropriate form of `remove_index` or `remove_concurrent_index`,
-or more simply by using the `remove_concurrent_index_by_name` method. Explicitly
+or by using the `remove_concurrent_index_by_name` method. Explicitly
 specifying the name is important to ensure the correct index is removed.
 
 For a small table (such as an empty one or one with less than `1,000` records),
diff --git a/doc/development/refactoring_guide/index.md b/doc/development/refactoring_guide/index.md
index 44beb0623a9..5dd505ff5c6 100644
--- a/doc/development/refactoring_guide/index.md
+++ b/doc/development/refactoring_guide/index.md
@@ -77,7 +77,7 @@ expect(cleanForSnapshot(wrapper.element)).toMatchSnapshot();
 
 - [Pinning test in a Haml to Vue refactor](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/27691#pinning-tests)
 - [Pinning test in isolating a bug](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/32198#note_212736225)
-- [Pinning test in refactoring dropdown](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28173)
+- [Pinning test in refactoring dropdown list](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28173)
 - [Pinning test in refactoring vulnerability_details.vue](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25830/commits)
 - [Pinning test in refactoring notes_award_list.vue](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/29528#pinning-test)
 - <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> [Video of pair programming session on pinning tests](https://youtu.be/LrakPcspBK4)
diff --git a/doc/development/reusing_abstractions.md b/doc/development/reusing_abstractions.md
index c29e7775f8e..2701192137c 100644
--- a/doc/development/reusing_abstractions.md
+++ b/doc/development/reusing_abstractions.md
@@ -63,7 +63,7 @@ do so, but then we'd need as many options as we have features. Every option adds
 two code paths, which means that for four features we have to cover 8 different
 code paths.
 
-A much more reliable (and pleasant) way of dealing with this, is to simply use
+A much more reliable (and pleasant) way of dealing with this, is to use
 the underlying bits that make up `GroupProjectsFinder` directly. This means we
 may need a little bit more code in `IssuableFinder`, but it also gives us much
 more control and certainty. This means we might end up with something like this:
@@ -122,7 +122,7 @@ the various abstractions and what they can (not) reuse:
 
 Everything in `app/controllers`.
 
-Controllers should not do much work on their own, instead they simply pass input
+Controllers should not do much work on their own, instead they pass input
 to other classes and present the results.
 
 ### API endpoints
diff --git a/doc/development/scalability.md b/doc/development/scalability.md
index 140ea2797dd..671086f33b2 100644
--- a/doc/development/scalability.md
+++ b/doc/development/scalability.md
@@ -216,7 +216,7 @@ core. It does not support multi-threading.
 
 Dumb secondaries: Redis secondaries (also known as replicas) don't actually
 handle any load. Unlike PostgreSQL secondaries, they don't even serve
-read queries. They simply replicate data from the primary and take over
+read queries. They replicate data from the primary and take over
 only when the primary fails.
 
 ### Redis Sentinels
diff --git a/doc/development/secure_coding_guidelines.md b/doc/development/secure_coding_guidelines.md
index 11a15f38823..67f7c556055 100644
--- a/doc/development/secure_coding_guidelines.md
+++ b/doc/development/secure_coding_guidelines.md
@@ -1071,7 +1071,7 @@ Symlink attacks makes it possible for an attacker to read the contents of arbitr
 
 #### Ruby
 
-For zip files, the [`rubyzip`](https://rubygems.org/gems/rubyzip) Ruby gem is already patched against symlink attacks as it simply ignores symbolic links, so for this vulnerable example we will extract a `tar.gz` file with `Gem::Package::TarReader`:
+For zip files, the [`rubyzip`](https://rubygems.org/gems/rubyzip) Ruby gem is already patched against symlink attacks as it ignores symbolic links, so for this vulnerable example we will extract a `tar.gz` file with `Gem::Package::TarReader`:
 
 ```ruby
 # Vulnerable tar.gz extraction example!
diff --git a/doc/development/service_ping/implement.md b/doc/development/service_ping/implement.md
index 6625f4e33fe..48bcc07f4e7 100644
--- a/doc/development/service_ping/implement.md
+++ b/doc/development/service_ping/implement.md
@@ -605,7 +605,7 @@ alt_usage_data(value = nil, fallback: -1, &block)
 
 Arguments:
 
-- `value`: a simple static value in which case the value is simply returned.
+- `value`: a static value in which case the value is returned.
 - or a `block`: which is evaluated
 - `fallback: -1`: the common value used for any metrics that are failing.
 
@@ -714,7 +714,7 @@ We also use `#database-lab` and [explain.depesz.com](https://explain.depesz.com/
   - [Example 2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26445)
 - Use defined `start` and `finish`, and simple queries.
   These values can be memoized and reused, as in this [example merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37155).
-- Avoid joins and write the queries as simply as possible,
+- Avoid joins and write the queries as clearly as possible,
   as in this [example merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36316).
 - Set a custom `batch_size` for `distinct_count`, as in this [example merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38000).
 
diff --git a/doc/development/snowplow/index.md b/doc/development/snowplow/index.md
index eba8ceca3ac..7327f18fcaf 100644
--- a/doc/development/snowplow/index.md
+++ b/doc/development/snowplow/index.md
@@ -90,7 +90,7 @@ Each click event provides attributes that describe the event.
 | Attribute | Type    | Required | Description |
 | --------- | ------- | -------- | ----------- |
 | category  | text    | true     | The page or backend section of the application. Unless infeasible, use the Rails page attribute by default in the frontend, and namespace + class name on the backend, for example, `Notes::CreateService`. |
-| action    | text    | true     | The action the user takes, or aspect that's being instrumented. The first word must describe the action or aspect. For example, clicks must be `click`, activations must be `activate`, creations must be `create`. Use underscores to describe what was acted on. For example, activating a form field is `activate_form_input`, an interface action like clicking on a dropdown is `click_dropdown`, a behavior like creating a project record from the backend is `create_project`. |
+| action    | text    | true     | The action the user takes, or aspect that's being instrumented. The first word must describe the action or aspect. For example, clicks must be `click`, activations must be `activate`, creations must be `create`. Use underscores to describe what was acted on. For example, activating a form field is `activate_form_input`, an interface action like clicking on a dropdown list is `click_dropdown`, a behavior like creating a project record from the backend is `create_project`. |
 | label     | text    | false    | The specific element or object to act on. This can be one of the following: the label of the element, for example, a tab labeled 'Create from template' for `create_from_template`; a unique identifier if no text is available, for example, `groups_dropdown_close` for closing the Groups dropdown in the top bar; or the name or title attribute of a record being created. For Service Ping metrics adapted to Snowplow events, this should be the full metric [key path](../service_ping/metrics_dictionary.md#metric-key_path) taken from its definition file. |
 | property  | text    | false    | Any additional property of the element, or object being acted on. For Service Ping metrics adapted to Snowplow events, this should be additional information or context that can help analyze the event. For example, in the case of `usage_activity_by_stage_monthly.create.merge_requests_users`, there are four different possible merge request actions: "create", "merge", "comment", and "close". Each of these would be a possible property value. |
 | value     | decimal | false    | Describes a numeric value (decimal) directly related to the event. This could be the value of an input. For example, `10` when clicking `internal` visibility. |
diff --git a/doc/development/stage_group_observability/dashboards/stage_group_dashboard.md b/doc/development/stage_group_observability/dashboards/stage_group_dashboard.md
index 170bf723a8d..fb5d5bbe379 100644
--- a/doc/development/stage_group_observability/dashboards/stage_group_dashboard.md
+++ b/doc/development/stage_group_observability/dashboards/stage_group_dashboard.md
@@ -54,8 +54,8 @@ description, note the following:
   precision is 2. In some extremely low panels, you can see `0.00`, even though there is still some
   real traffic.
 
-To inspect the raw data of the panel for further calculation, select **Inspect** from the dropdown
-list of a panel. Queries, raw data, and panel JSON structure are available.
+To inspect the raw data of the panel for further calculation, select **Inspect** from the dropdown list of a panel.
+Queries, raw data, and panel JSON structure are available.
 Read more at [Grafana panel inspection](http://grafana.com/docs/grafana/next/panels/query-a-data-source/).
 
 All the dashboards are powered by [Grafana](https://grafana.com/), a frontend for displaying metrics.
diff --git a/doc/development/testing_guide/contract/index.md b/doc/development/testing_guide/contract/index.md
index 7c8f217bdcb..8412a260c7d 100644
--- a/doc/development/testing_guide/contract/index.md
+++ b/doc/development/testing_guide/contract/index.md
@@ -66,7 +66,7 @@ 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 simply named according to the API endpoint they pertain to. Be mindful that this 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 simply name it "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. An easy way to name them is by checking out our [API documentation](../../../api/api_resources.md) and naming it the same way it is named in there. So the [`GET /groups/:id/projects`](../../../api/groups.md#list-a-groups-projects) would be called `List a group’s projects` and [`GET /projects`](../../../api/projects.md#list-all-projects) would be called `List all projects`. Subsequently, the test files are named `list_a_groups_projects_helper.rb` and `list_all_projects_helper.rb` respectively.
+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 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 "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. An easy way to name them is by checking out our [API documentation](../../../api/api_resources.md) and naming it the same way it is named in there. So the [`GET /groups/:id/projects`](../../../api/groups.md#list-a-groups-projects) would be called `List a group’s projects` and [`GET /projects`](../../../api/projects.md#list-all-projects) would be called `List all projects`. Subsequently, the test files are named `list_a_groups_projects_helper.rb` and `list_all_projects_helper.rb` respectively.
 
 There are some cases where the provider being tested may not be documented so, in those cases, fall back to choosing a name that is as descriptive as possible to ensure it's easy to tell what the provider is for.
 
diff --git a/doc/development/testing_guide/end_to_end/best_practices.md b/doc/development/testing_guide/end_to_end/best_practices.md
index 82d2eee0142..3c31fcff610 100644
--- a/doc/development/testing_guide/end_to_end/best_practices.md
+++ b/doc/development/testing_guide/end_to_end/best_practices.md
@@ -10,7 +10,7 @@ This is a tailored extension of the Best Practices [found in the testing guide](
 
 ## Class and module naming
 
-The QA framework uses [Zeitwerk](https://github.com/fxn/zeitwerk) for class and module autoloading. The default Zeitwerk [inflector](https://github.com/fxn/zeitwerk#zeitwerkinflector) simply converts snake_cased file names to PascalCased module or class names. It is advised to stick to this pattern to avoid manual maintenance of inflections.
+The QA framework uses [Zeitwerk](https://github.com/fxn/zeitwerk) for class and module autoloading. The default Zeitwerk [inflector](https://github.com/fxn/zeitwerk#zeitwerkinflector) converts snake_cased file names to PascalCased module or class names. It is advised to stick to this pattern to avoid manual maintenance of inflections.
 
 In case custom inflection logic is needed, custom inflectors are added in the [qa.rb](https://gitlab.com/gitlab-org/gitlab/-/blob/master/qa/qa.rb) file in the `loader.inflector.inflect` method invocation.
 
diff --git a/doc/development/testing_guide/end_to_end/dynamic_element_validation.md b/doc/development/testing_guide/end_to_end/dynamic_element_validation.md
index 36ba2117999..5cc82916cdd 100644
--- a/doc/development/testing_guide/end_to_end/dynamic_element_validation.md
+++ b/doc/development/testing_guide/end_to_end/dynamic_element_validation.md
@@ -48,7 +48,7 @@ click_element(:my_element, Some::Page)
 
 First it is important to define what a "required element" is.
 
-Simply put, a required element is a visible HTML element that appears on a UI component without any user input.
+A required element is a visible HTML element that appears on a UI component without any user input.
 
 "Visible" can be defined as
 
diff --git a/doc/development/testing_guide/frontend_testing.md b/doc/development/testing_guide/frontend_testing.md
index d4e1566e25c..d7627e2064f 100644
--- a/doc/development/testing_guide/frontend_testing.md
+++ b/doc/development/testing_guide/frontend_testing.md
@@ -290,7 +290,7 @@ it('tests a promise rejection', async () => {
 });
 ```
 
-You can also simply return a promise from the test function.
+You can also return a promise from the test function.
 
 Using the `done` and `done.fail` callbacks is discouraged when working with
 promises. They should not be used.
diff --git a/doc/development/testing_guide/review_apps.md b/doc/development/testing_guide/review_apps.md
index 973ec0555f6..d86d1c3c7b4 100644
--- a/doc/development/testing_guide/review_apps.md
+++ b/doc/development/testing_guide/review_apps.md
@@ -101,7 +101,7 @@ the GitLab handbook information for the [shared 1Password account](https://about
 1. [Filter Workloads by your Review App slug](https://console.cloud.google.com/kubernetes/workload?project=gitlab-review-apps). For example, `review-qa-raise-e-12chm0`.
 1. Find and open the `toolbox` Deployment. For example, `review-qa-raise-e-12chm0-toolbox`.
 1. Select the Pod in the "Managed pods" section. For example, `review-qa-raise-e-12chm0-toolbox-d5455cc8-2lsvz`.
-1. Select the `KUBECTL` dropdown, then `Exec` -> `toolbox`.
+1. Select the `KUBECTL` dropdown list, then `Exec` -> `toolbox`.
 1. Replace `-c toolbox -- ls` with `-it -- gitlab-rails console` from the
    default command or
    - Run `kubectl exec --namespace review-qa-raise-e-12chm0 review-qa-raise-e-12chm0-toolbox-d5455cc8-2lsvz -it -- gitlab-rails console` and
diff --git a/doc/development/work_items_widgets.md b/doc/development/work_items_widgets.md
index 67ffdd14b6a..89602d969e6 100644
--- a/doc/development/work_items_widgets.md
+++ b/doc/development/work_items_widgets.md
@@ -88,7 +88,7 @@ To maximize component reusability, widgets should be field wrappers owning the
 work item query and mutation of the attribute it's responsible for.
 
 A field component is a generic and simple component. It has no knowledge of the
-attribute or work item details, such as input field, date selector, or dropdown.
+attribute or work item details, such as input field, date selector, or dropdown list.
 
 Widgets must be configurable to support various use cases, depending on work items.
 When building widgets, use slots to provide extra context while minimizing
@@ -96,18 +96,18 @@ the use of props and injected attributes.
 
 ### Examples
 
-We have a [dropdown field component](https://gitlab.com/gitlab-org/gitlab/-/blob/eea9ad536fa2d28ee6c09ed7d9207f803142eed7/app/assets/javascripts/vue_shared/components/dropdown/dropdown_widget/dropdown_widget.vue)
+We have a [dropdown list component](https://gitlab.com/gitlab-org/gitlab/-/blob/eea9ad536fa2d28ee6c09ed7d9207f803142eed7/app/assets/javascripts/vue_shared/components/dropdown/dropdown_widget/dropdown_widget.vue)
 for use as reference.
 
-Any work item widget can wrap the dropdown component. The widget has knowledge of
+Any work item widget can wrap the dropdown list. The widget has knowledge of
 the attribute it mutates, and owns the mutation for it. Multiple widgets can use
 the same field component. For example:
 
 - Title and description widgets use the input field component.
 - Start and end date use the date selector component.
-- Labels, milestones, and assignees selectors use the dropdown component.
+- Labels, milestones, and assignees selectors use the dropdown list.
 
-Some frontend widgets already use the dropdown component. Use them as a reference
+Some frontend widgets already use the dropdown list. Use them as a reference
 for work items widgets development:
 
 - `ee/app/assets/javascripts/boards/components/assignee_select.vue`