Merge branch 'AniBasu-master-patch-98525' into 'master'

Remove instances of 'simply' from the documentation

See merge request gitlab-org/gitlab!58008

doc/development/fe_guide/design_anti_patterns.md

@@ -30,7 +30,7 @@ const createStore = () => new Vuex.Store({
 // Notice that we are forcing all references to this module to use the same single instance of the store.
 // We are also creating the store at import-time and there is nothing which can automatically dispose of it.
 //
-// As an alternative, we should simply export the `createStore` and let the client manage the
+// As an alternative, we should export the `createStore` and let the client manage the
 // lifecycle and instance of the store.
 export default createStore();
 ```
@@ -129,7 +129,7 @@ Here are some ills that Singletons often produce:
 
 This is because of the limitations of languages like Java where everything has to be wrapped
 in a class. In JavaScript we have things like object and function literals where we can solve
-many problems with a module that simply exports utility functions.
+many problems with a module that exports utility functions.
 
 ### When could the Singleton pattern be actually appropriate?**
 

doc/development/migration_style_guide.md

@@ -254,7 +254,7 @@ end
 
 **Creating a new table with a foreign key:**
 
-We can simply wrap the `create_table` method with `with_lock_retries`:
+We can wrap the `create_table` method with `with_lock_retries`:
 
 ```ruby
 def up
@@ -715,7 +715,7 @@ the `DROP TABLE` statement is likely to stall concurrent traffic until it fails
 Table **has no records** (feature was never in use) and **no foreign
 keys**:
 
-- Simply use the `drop_table` method in your migration.
+- Use the `drop_table` method in your migration.
 
 ```ruby
 def change

doc/development/polymorphic_associations.md

@@ -74,7 +74,7 @@ different columns set) in the same table.
 
 ## The Solution
 
-Fortunately there is a very simple solution to these problems: simply use a
+Fortunately there is a very simple solution to these problems: use a
 separate table for every type you would otherwise store in the same table. Using
 a separate table allows you to use everything a database may provide to ensure
 consistency and query data efficiently, without any additional application logic

doc/development/shell_commands.md

@@ -223,4 +223,4 @@ When importing, GitLab would execute the following command, passing the `import_
 git clone file://git:/tmp/lol
 ```
 
-Git would simply ignore the `git:` part, interpret the path as `file:///tmp/lol`, and import the repository into the new project. This action could potentially give the attacker access to any repository in the system, whether private or not.
+Git ignores the `git:` part, interpret the path as `file:///tmp/lol`, and imports the repository into the new project. This action could potentially give the attacker access to any repository in the system, whether private or not.

doc/development/sidekiq_style_guide.md

@@ -551,7 +551,7 @@ does not account for weights.
 
 As we are [moving towards using `sidekiq-cluster` in
 Free](https://gitlab.com/gitlab-org/gitlab/-/issues/34396), newly-added
-workers do not need to have weights specified. They can simply use the
+workers do not need to have weights specified. They can use the
 default weight, which is 1.
 
 ## Worker context

doc/development/sql.md

@@ -313,9 +313,9 @@ Project.from("(#{union.to_sql}) projects")
 
 ## Ordering by Creation Date
 
-When ordering records based on the time they were created you can simply order
+When ordering records based on the time they were created, you can order
 by the `id` column instead of ordering by `created_at`. Because IDs are always
-unique and incremented in the order that rows are created this will produce the
+unique and incremented in the order that rows are created, doing so will produce the
 exact same results. This also means there's no need to add an index on
 `created_at` to ensure consistent performance as `id` is already indexed by
 default.

doc/development/testing_guide/end_to_end/index.md

@@ -159,9 +159,9 @@ See [Review Apps](../review_apps.md) for more details about Review Apps.
 ## How do I run the tests?
 
 If you are not [testing code in a merge request](#testing-code-in-merge-requests),
-there are two main options for running the tests. If you simply want to run
-the existing tests against a live GitLab instance or against a pre-built Docker image
-you can use the [GitLab QA orchestrator](https://gitlab.com/gitlab-org/gitlab-qa/tree/master/README.md). See also [examples
+there are two main options for running the tests. If you want to run
+the existing tests against a live GitLab instance or against a pre-built Docker image,
+use the [GitLab QA orchestrator](https://gitlab.com/gitlab-org/gitlab-qa/tree/master/README.md). See also [examples
 of the test scenarios you can run via the orchestrator](https://gitlab.com/gitlab-org/gitlab-qa/blob/master/docs/what_tests_can_be_run.md#examples).
 
 On the other hand, if you would like to run against a local development GitLab

doc/development/testing_guide/end_to_end/style_guide.md

@@ -122,7 +122,7 @@ avoid confusion or make the code more readable. For example, if a page object is
 named `New`, it could be confusing to name the block argument `new` because that
 is used to instantiate objects, so `new_page` would be acceptable.
 
-We chose not to simply use `page` because that would shadow the
+We chose not to use `page` because that would shadow the
 Capybara DSL, potentially leading to confusion and bugs.
 
 ### Examples

doc/development/testing_guide/frontend_testing.md

@@ -755,7 +755,7 @@ If a manual mock is needed for a CE module, place it in `spec/frontend/mocks/ce`
   any behavior, only provides a nice es6 compatible wrapper.
 - [`__mocks__/monaco-editor/index.js`](https://gitlab.com/gitlab-org/gitlab/blob/b7f914cddec9fc5971238cdf12766e79fa1629d7/spec/frontend/__mocks__/monaco-editor/index.js) -
   This mock is helpful because the Monaco package is completely incompatible in a Jest environment. In fact, webpack requires a special loader to make it work. This mock
-  simply makes this package consumable by Jest.
+  makes this package consumable by Jest.
 
 ### Keep mocks light
 

doc/development/understanding_explain_plans.md

@@ -280,7 +280,7 @@ FROM users
 WHERE twitter != '';
 ```
 
-This query simply counts the number of users that have a Twitter profile set.
+This query counts the number of users that have a Twitter profile set.
 Let's run this using `EXPLAIN (ANALYZE, BUFFERS)`:
 
 ```sql
@@ -388,7 +388,7 @@ we created the index:
 CREATE INDEX CONCURRENTLY twitter_test ON users (twitter);
 ```
 
-We simply told PostgreSQL to index all possible values of the `twitter` column,
+We told PostgreSQL to index all possible values of the `twitter` column,
 even empty strings. Our query in turn uses `WHERE twitter != ''`. This means
 that the index does improve things, as we don't need to do a sequential scan,
 but we may still encounter empty strings. This means PostgreSQL _has_ to apply a

doc/integration/elasticsearch.md

@@ -679,7 +679,7 @@ Sidekiq processes](../administration/operations/extra_sidekiq_processes.md).
 
 Whenever a change or deletion is made to an indexed GitLab object (a merge request description is changed, a file is deleted from the master branch in a repository, a project is deleted, etc), a document in the index is deleted. However, since these are "soft" deletes, the overall number of "deleted documents", and therefore wasted space, increases. Elasticsearch does intelligent merging of segments in order to remove these deleted documents. However, depending on the amount and type of activity in your GitLab installation, it's possible to see as much as 50% wasted space in the index.
 
-In general, we recommend simply letting Elasticsearch merge and reclaim space automatically, with the default settings. From [Lucene's Handling of Deleted Documents](https://www.elastic.co/blog/lucenes-handling-of-deleted-documents "Lucene's Handling of Deleted Documents"), _"Overall, besides perhaps decreasing the maximum segment size, it is best to leave Lucene's defaults as-is and not fret too much about when deletes are reclaimed."_
+In general, we recommend letting Elasticsearch merge and reclaim space automatically, with the default settings. From [Lucene's Handling of Deleted Documents](https://www.elastic.co/blog/lucenes-handling-of-deleted-documents "Lucene's Handling of Deleted Documents"), _"Overall, besides perhaps decreasing the maximum segment size, it is best to leave Lucene's defaults as-is and not fret too much about when deletes are reclaimed."_
 
 However, some larger installations may wish to tune the merge policy settings:
 
@@ -719,8 +719,7 @@ data).
 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.
 
 ## Troubleshooting
 
@@ -916,7 +915,7 @@ In GitLab 13.9, a change was made where [binary file names are being indexed](ht
 ### Last resort to recreate an index
 
 There may be cases where somehow data never got indexed and it's not in the
-queue, or the index is somehow in a state where migrations just simply cannot
+queue, or the index is somehow in a state where migrations just cannot
 proceed. It is always best to try to troubleshoot the root cause of the problem
 using the above [troubleshooting](#troubleshooting) steps.
 

doc/operations/error_tracking.md

@@ -77,7 +77,7 @@ You can take action on Sentry Errors from within the GitLab UI.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/39665) in GitLab 12.7.
 
-From within the [Error Details](#error-details) page you can ignore a Sentry error by simply clicking the **Ignore** button near the top of the page.
+From within the [Error Details](#error-details) page you can ignore a Sentry error by clicking the **Ignore** button near the top of the page.
 
 Ignoring an error prevents it from appearing in the [Error Tracking List](#error-tracking-list), and silences notifications that were set up within Sentry.
 

doc/topics/git/numerous_undo_possibilities_in_git/index.md

@@ -379,7 +379,7 @@ it also provides a clear timeline and development structure.
 
 ![Use revert to keep branch flowing](img/revert.png)
 
-If you want to revert changes introduced in certain `commit-id` you can simply
+If you want to revert changes introduced in certain `commit-id`, you can 
 revert that `commit-id` (swap additions and deletions) in newly created commit:
 You can do this with
 

doc/user/admin_area/activating_deactivating_users.md

@@ -66,4 +66,4 @@ Activating a user changes the user's state to active and consumes a
 [seat](../../subscriptions/self_managed/index.md#billable-users).
 
 NOTE:
-A deactivated user can also activate their account themselves by simply logging back in via the UI.
+A deactivated user can also activate their account themselves by logging back in via the UI.

doc/user/application_security/api_fuzzing/index.md

@@ -994,7 +994,7 @@ False positives can be handled in two ways:
 Checks perform testing of a specific type and can be turned on and off for specific configuration
 profiles. The provided [configuration files](#configuration-files) define several profiles that you
 can use. The profile definition in the configuration file lists all the checks that are active
-during a scan. To turn off a specific check, simply remove it from the profile definition in the
+during a scan. To turn off a specific check, remove it from the profile definition in the
 configuration file. The profiles are defined in the `Profiles` section of the configuration file.
 
 Example profile definition: