Add latest changes from gitlab-org/gitlab@master

11 files changed, 12 insertions, 12 deletions

diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index 7b00e3cea0d..471dcba4c2a 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -455,7 +455,7 @@ helped us with overall code quality (using delegation, `&.` those
 types of things), and making the code more robust.
 
 **["Support multiple assignees for merge requests"](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/10161)**:
-A  good example of collaboration on an MR touching multiple parts of the codebase. Nick pointed out interesting edge cases, James Lopes also joined in raising concerns on import/export feature.
+A good example of collaboration on an MR touching multiple parts of the codebase. Nick pointed out interesting edge cases, James Lopes also joined in raising concerns on import/export feature.
 
 ### Credits
 
diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md
index a00f7cff651..7239bd2e52a 100644
--- a/doc/development/contributing/issue_workflow.md
+++ b/doc/development/contributing/issue_workflow.md
@@ -137,7 +137,7 @@ their color is `#A8D695`.
 with `_` replaced with a space.
 
 For instance, the "Continuous Integration" group is represented by the
-~"group::continuous integration"  label in the `gitlab-org` group since its key
+~"group::continuous integration" label in the `gitlab-org` group since its key
 under `stages.manage.groups` is `continuous_integration`.
 
 The current group labels can be found by [searching the labels list for `group::`](https://gitlab.com/groups/gitlab-org/-/labels?search=group::).
diff --git a/doc/development/database_review.md b/doc/development/database_review.md
index 32f67e14fe3..a624abc2929 100644
--- a/doc/development/database_review.md
+++ b/doc/development/database_review.md
@@ -185,6 +185,6 @@ NOTE: **Note:** Keep in mind that all runtimes should be measured against GitLab
 
 | Migration Type | Execution Time Recommended | Notes |
 |----|----|---|
-| Regular migrations on `db/migrate` | `3 minutes` | A valid exception  are index creation as this can take a long time. |
+| Regular migrations on `db/migrate` | `3 minutes` | A valid exception are index creation as this can take a long time. |
 | Post migrations on `db/post_migrate` | `10 minutes` | |
 | Background migrations | --- | Since these are suitable for larger tables, it's not possible to set a precise timing guideline, however, any single query must stay below `1 second` execution time with cold caches. |
diff --git a/doc/development/fe_guide/development_process.md b/doc/development/fe_guide/development_process.md
index 64bc01c181c..92f3c82a6ea 100644
--- a/doc/development/fe_guide/development_process.md
+++ b/doc/development/fe_guide/development_process.md
@@ -4,7 +4,7 @@ You can find more about the organization of the frontend team in the [handbook](
 
 ## Development Checklist
 
-The idea is to remind us about specific topics during the time we build a new feature or start something. This is a common practice in other industries (like pilots) that also use  standardised checklists to reduce problems early on.
+The idea is to remind us about specific topics during the time we build a new feature or start something. This is a common practice in other industries (like pilots) that also use standardised checklists to reduce problems early on.
 
 Copy the content over to your issue or merge request and if something doesn't apply simply remove it from your current list.
 
diff --git a/doc/development/fe_guide/icons.md b/doc/development/fe_guide/icons.md
index 36537a22e67..ea321330c41 100644
--- a/doc/development/fe_guide/icons.md
+++ b/doc/development/fe_guide/icons.md
@@ -65,7 +65,7 @@ export default {
 </template>
 ```
 
-- **name** Name of the Icon in the SVG Sprite  ([Overview is available here][svg-preview]).
+- **name** Name of the Icon in the SVG Sprite ([Overview is available here][svg-preview]).
 - **size (optional)** Number value for the size which is then mapped to a specific CSS class
   (Available Sizes: 8, 12, 16, 18, 24, 32, 48, 72 are mapped to `sXX` css classes)
 - **css-classes (optional)** Additional CSS Classes to add to the svg tag.
diff --git a/doc/development/file_storage.md b/doc/development/file_storage.md
index a4a5f84313a..bc3c16bd45d 100644
--- a/doc/development/file_storage.md
+++ b/doc/development/file_storage.md
@@ -40,7 +40,7 @@ they are still not 100% standardized. You can see them below:
 | Issues/MR/Notes Legacy Markdown attachments | no | uploads/-/system/note/attachment/:id/:filename            | `AttachmentUploader`   | Note       |
 | Design Management design thumbnails (EE) | yes | uploads/-/system/design_management/action/image_v432x230/:id/:filename | `DesignManagement::DesignV432x230Uploader` | DesignManagement::Action |
 | CI Artifacts (CE)                     | yes    | `shared/artifacts/:disk_hash[0..1]/:disk_hash[2..3]/:disk_hash/:year_:month_:date/:job_id/:job_artifact_id` (:disk_hash is SHA256 digest of project_id) | `JobArtifactUploader`  | Ci::JobArtifact  |
-| LFS Objects  (CE)                     | yes    | shared/lfs-objects/:hex/:hex/:object_hash                   | `LfsObjectUploader`    | LfsObject  |
+| LFS Objects (CE)                      | yes    | shared/lfs-objects/:hex/:hex/:object_hash                   | `LfsObjectUploader`    | LfsObject  |
 | External merge request diffs          | yes    | shared/external-diffs/merge_request_diffs/mr-:parent_id/diff-:id | `ExternalDiffUploader` | MergeRequestDiff |
 
 CI Artifacts and LFS Objects behave differently in CE and EE. In CE they inherit the `GitlabUploader`
diff --git a/doc/development/permissions.md b/doc/development/permissions.md
index 9e67079d1bc..bca137337fc 100644
--- a/doc/development/permissions.md
+++ b/doc/development/permissions.md
@@ -9,11 +9,11 @@ anything that deals with permissions, all of them should be considered.
 
 Groups and projects can have the following visibility levels:
 
-- public (20) -  an entity is visible to everyone
+- public (20) - an entity is visible to everyone
 - internal (10) - an entity is visible to logged in users
 - private (0) - an entity is visible only to the approved members of the entity
 
-The visibility level of a group can be changed  only if all subgroups and
+The visibility level of a group can be changed only if all subgroups and
 subprojects have the same or lower visibility level. (e.g., a group can be set
 to internal only if all subgroups and projects are internal or private).
 
diff --git a/doc/development/query_recorder.md b/doc/development/query_recorder.md
index 4963090ef27..f2c5b8b9848 100644
--- a/doc/development/query_recorder.md
+++ b/doc/development/query_recorder.md
@@ -65,7 +65,7 @@ There are multiple ways to find the source of queries.
    `QueryRecorder#occurrences_by_line_method` returns a sorted array based on `data`, sorted by `count`.
 
 1. You can output the call backtrace for the specific `QueryRecorder` instance you want
-   by using `ActiveRecord::QueryRecorder.new(query_recorder_debug: true)`.  The output
+   by using `ActiveRecord::QueryRecorder.new(query_recorder_debug: true)`. The output
    will be in `test.log`
 
 1. Using the environment variable `QUERY_RECORDER_DEBUG`, the call backtrace will be output for all tests.
diff --git a/doc/development/scalability.md b/doc/development/scalability.md
index 3a9f5387b11..b3387526ccd 100644
--- a/doc/development/scalability.md
+++ b/doc/development/scalability.md
@@ -67,7 +67,7 @@ kind of partitioning.
 Sharding is likely more difficult and will require significant changes
 to the schema and application. For example, if we have to store projects
 in many different databases, we immediately run into the question, "How
-can we retrieve data across different projects?"  One answer to this is
+can we retrieve data across different projects?" One answer to this is
 to abstract data access into API calls that abstract the database from
 the application, but this is a significant amount of work.
 
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 97daf4885ca..e1807f2b53f 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 @@ But if the login feature is already covered with end-to-end tests through the GU
 
 Let's say that, on average, the process to perform a successful login through the GUI takes 2 seconds.
 
-Now, realize that almost all tests need the user to be logged in, and that we need every test to run in isolation, meaning that tests cannot interfere with each other. This would  mean that for every test the user needs to log in, and "waste 2 seconds".
+Now, realize that almost all tests need the user to be logged in, and that we need every test to run in isolation, meaning that tests cannot interfere with each other. This would mean that for every test the user needs to log in, and "waste 2 seconds".
 
 Now, multiply the number of tests per 2 seconds, and as your test suite grows, the time to run it grows with it, and this is not sustainable.
 
diff --git a/doc/development/testing_guide/end_to_end/quick_start_guide.md b/doc/development/testing_guide/end_to_end/quick_start_guide.md
index 5d5715df372..e1024eace40 100644
--- a/doc/development/testing_guide/end_to_end/quick_start_guide.md
+++ b/doc/development/testing_guide/end_to_end/quick_start_guide.md
@@ -39,7 +39,7 @@ Sometimes you may notice that there is already good coverage in lower test level
 
 - Take a look at the [How to test at the correct level?](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/development/testing_guide/testing_levels.md#how-to-test-at-the-correct-level) section of the [Testing levels](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/development/testing_guide/testing_levels.md) document
 
-- Look into the frequency in which such a feature is changed  (_Stable features that don't change very often might not be worth covering with end-to-end tests if they're already covered in lower levels_)
+- Look into the frequency in which such a feature is changed (_Stable features that don't change very often might not be worth covering with end-to-end tests if they're already covered in lower levels_)
 
 - Finally, discuss with the developer(s) involved in developing the feature and the tests themselves, to get their feeling