Add latest changes from gitlab-org/gitlab@master

14 files changed, 18 insertions, 18 deletions

diff --git a/doc/development/contributing/verify/index.md b/doc/development/contributing/verify/index.md
index 09b206d59aa..e94b7583904 100644
--- a/doc/development/contributing/verify/index.md
+++ b/doc/development/contributing/verify/index.md
@@ -52,7 +52,7 @@ and they serve us and our users well. Some examples of these principles are that
 
 - The feedback delivered by GitLab CI/CD and data produced by the platform should be accurate.
   If a job fails and we notify a user that it was successful, it can have severe negative consequences.
-- Feedback needs to be available when a user needs it and data can not disappear unexpectedly when engineers need it.
+- Feedback needs to be available when a user needs it and data cannot disappear unexpectedly when engineers need it.
 - It all doesn't matter if the platform is not secure and we
 are leaking credentials or secrets.
 - When a user provides a set of preconditions in a form of CI/CD configuration, the result should be deterministic each time a pipeline runs, because otherwise the platform might not be trustworthy.
@@ -62,7 +62,7 @@ are leaking credentials or secrets.
 
 ### Measure before you optimize, and make data-informed decisions
 
-It is very difficult to optimize something that you can not measure. How would you
+It is very difficult to optimize something that you cannot measure. How would you
 know if you succeeded, or how significant the success was? If you are working on
 a performance or reliability improvement, make sure that you measure things before
 you optimize them.
diff --git a/doc/development/database/background_migrations.md b/doc/development/database/background_migrations.md
index b1e8fc84038..3aff7bbe695 100644
--- a/doc/development/database/background_migrations.md
+++ b/doc/development/database/background_migrations.md
@@ -44,7 +44,7 @@ into this category.
 
 ## Isolation
 
-Background migrations must be isolated and can not use application code (for example,
+Background migrations must be isolated and cannot use application code (for example,
 models defined in `app/models` except the `ApplicationRecord` classes). Since these migrations
 can take a long time to run it's possible for new versions to be deployed while they are still running.
 
diff --git a/doc/development/database/batched_background_migrations.md b/doc/development/database/batched_background_migrations.md
index 9730d767eed..a48a9c42e27 100644
--- a/doc/development/database/batched_background_migrations.md
+++ b/doc/development/database/batched_background_migrations.md
@@ -41,7 +41,7 @@ into this category.
 
 ## Isolation
 
-Batched background migrations must be isolated and can not use application code (for example,
+Batched background migrations must be isolated and cannot use application code (for example,
 models defined in `app/models` except the `ApplicationRecord` classes).
 Because these migrations can take a long time to run, it's possible
 for new versions to deploy while the migrations are still running.
diff --git a/doc/development/database/not_null_constraints.md b/doc/development/database/not_null_constraints.md
index 9e11db074cb..dccaff2df00 100644
--- a/doc/development/database/not_null_constraints.md
+++ b/doc/development/database/not_null_constraints.md
@@ -93,7 +93,7 @@ We only want to enforce the `NOT NULL` constraint without setting a default, as
 that all epics should have a user-generated description.
 
 After checking our production database, we know that there are `epics` with `NULL` descriptions,
-so we can not add and validate the constraint in one step.
+so we cannot add and validate the constraint in one step.
 
 NOTE:
 Even if we did not have any epic with a `NULL` description, another instance of GitLab could have
diff --git a/doc/development/database/strings_and_the_text_data_type.md b/doc/development/database/strings_and_the_text_data_type.md
index a431268f89a..02adcfacf02 100644
--- a/doc/development/database/strings_and_the_text_data_type.md
+++ b/doc/development/database/strings_and_the_text_data_type.md
@@ -15,7 +15,7 @@ When adding new columns to store strings or other textual information:
 the `#text ... limit: 100` helper (see below) when creating a table, or by using the `add_text_limit`
 when altering an existing table.
 
-The standard Rails `text` column type can not be defined with a limit, but we extend `create_table` to
+The standard Rails `text` column type cannot be defined with a limit, but we extend `create_table` to
 add a `limit: 255` option. Outside of `create_table`, `add_text_limit` can be used to add a [check constraint](https://www.postgresql.org/docs/11/ddl-constraints.html)
 to an already existing column.
 
@@ -131,7 +131,7 @@ Issues is a pretty busy and large table with more than 25 million rows, so we do
 other processes that try to access it while running the update.
 
 Also, after checking our production database, we know that there are `issues` with more characters in
-their title than the 1024 character limit, so we can not add and validate the constraint in one step.
+their title than the 1024 character limit, so we cannot add and validate the constraint in one step.
 
 NOTE:
 Even if we did not have any record with a title larger than the provided limit, another
diff --git a/doc/development/database/understanding_explain_plans.md b/doc/development/database/understanding_explain_plans.md
index d4b29a72af2..fff9d755e9a 100644
--- a/doc/development/database/understanding_explain_plans.md
+++ b/doc/development/database/understanding_explain_plans.md
@@ -546,7 +546,7 @@ improve this query, other than _not_ running it at all.
 What is important here is that while some may recommend to straight up add an
 index the moment you see a sequential scan, it is _much more important_ to first
 understand what your query does, how much data it retrieves, and so on. After
-all, you can not optimize something you do not understand.
+all, you cannot optimize something you do not understand.
 
 ### Cardinality and selectivity
 
diff --git a/doc/development/graphql_guide/graphql_pro.md b/doc/development/graphql_guide/graphql_pro.md
index fd6e519a6fc..0b17f9c14b6 100644
--- a/doc/development/graphql_guide/graphql_pro.md
+++ b/doc/development/graphql_guide/graphql_pro.md
@@ -16,6 +16,6 @@ The main purpose is for support. Per the website:
 > creator and maintainer. Get prioritized support for issues and requests.
 
 Note that we **cannot** use the Pro version directly in our product, since we are
-an Open Core product - we can not require customers to purchase the Pro version, nor can we ship it.
+an Open Core product - we cannot require customers to purchase the Pro version, nor can we ship it.
 
 Details on the billing account and gem licensing can be found in the Engineering 1Password vault.
diff --git a/doc/development/import_project.md b/doc/development/import_project.md
index 83fcf500a5d..b8415e530d5 100644
--- a/doc/development/import_project.md
+++ b/doc/development/import_project.md
@@ -111,7 +111,7 @@ The specified project export file in `archive_path` is missing.
 
 ##### `Exception: Permission denied @ rb_sysopen - (filename)`
 
-The specified project export file can not be accessed by the `git` user.
+The specified project export file cannot be accessed by the `git` user.
 
 Setting the file owner to `git:git`, changing the file permissions to `0400`, and moving it to a
 public folder (for example `/tmp/`) fixes the issue.
diff --git a/doc/development/internal_api/index.md b/doc/development/internal_api/index.md
index e7dfcd58af6..151ad3df074 100644
--- a/doc/development/internal_api/index.md
+++ b/doc/development/internal_api/index.md
@@ -7,7 +7,7 @@ type: reference, api
 
 # Internal API **(FREE)**
 
-The internal API is used by different GitLab components, it can not be
+The internal API is used by different GitLab components, it cannot be
 used by other consumers. This documentation is intended for people
 working on the GitLab codebase.
 
@@ -21,7 +21,7 @@ Before adding a new internal endpoint, consider if the API would potentially be
 useful to the wider GitLab community and can be made externally accessible.
 
 One reason we might favor internal API endpoints sometimes is when using such an endpoint requires
-internal data that external actors can not have. For example, in the internal Pages API we might use
+internal data that external actors cannot have. For example, in the internal Pages API we might use
 a secret token that identifies a request as internal or sign a request with a public key that is
 not available to a wider community.
 
diff --git a/doc/development/issue_types.md b/doc/development/issue_types.md
index 21e3fda7401..465f539e026 100644
--- a/doc/development/issue_types.md
+++ b/doc/development/issue_types.md
@@ -42,7 +42,7 @@ issues or when linking objects of the type from Epics. It should use the same
   - You can't close it from a commit or a merge request.
   - You can't mark it as related to another issue.
 
-If an Issue type can not be used you can still define a first-class type and
+If an Issue type cannot be used you can still define a first-class type and
 then include concerns such as `Issuable` or `Noteable` to reuse functionality
 which is common for all our issue-related resources. But you still need to
 define the interface for working with the new resource and update some other
diff --git a/doc/development/permissions.md b/doc/development/permissions.md
index 48e751bbb34..cc7c1229e50 100644
--- a/doc/development/permissions.md
+++ b/doc/development/permissions.md
@@ -37,7 +37,7 @@ Groups and projects can have the following visibility levels:
 - private (`0`) - an entity is visible only to the approved members of the entity
 
 By default, subgroups can **not** have higher visibility levels.
-For example, if you create a new private group, it can not include a public subgroup.
+For example, if you create a new private group, it cannot include a public subgroup.
 
 The visibility level of a group can be changed only if all subgroups and
 sub-projects have the same or lower visibility level. For example, a group can be set
diff --git a/doc/development/profiling.md b/doc/development/profiling.md
index 6fda781e569..01db208f1cf 100644
--- a/doc/development/profiling.md
+++ b/doc/development/profiling.md
@@ -244,7 +244,7 @@ Example output:
 ```
 
 NOTE:
-This endpoint is only available for Rails web workers. Sidekiq workers can not be inspected this way.
+This endpoint is only available for Rails web workers. Sidekiq workers cannot be inspected this way.
 
 ## Settings that impact performance
 
diff --git a/doc/development/reusing_abstractions.md b/doc/development/reusing_abstractions.md
index 893924dc365..c29e7775f8e 100644
--- a/doc/development/reusing_abstractions.md
+++ b/doc/development/reusing_abstractions.md
@@ -96,7 +96,7 @@ This is just a sketch, but it shows the general idea: we would use whatever the
 ## End goal
 
 The guidelines in this document are meant to foster _better_ code reuse, by
-clearly defining what can be reused where, and what to do when you can not reuse
+clearly defining what can be reused where, and what to do when you cannot reuse
 something. Clearly separating abstractions makes it harder to use the wrong one,
 makes it easier to debug the code, and (hopefully) results in fewer performance
 problems.
@@ -265,7 +265,7 @@ For example: `:job_not_retriable`, `:duplicate_package`, `:merge_request_not_mer
 
 Everything in `app/finders`, typically used for retrieving data from a database.
 
-Finders can not reuse other finders in an attempt to better control the SQL
+Finders cannot reuse other finders in an attempt to better control the SQL
 queries they produce.
 
 Finders' `execute` method should return `ActiveRecord::Relation`. Exceptions
diff --git a/doc/development/service_ping/implement.md b/doc/development/service_ping/implement.md
index 30503bbbdc2..6625f4e33fe 100644
--- a/doc/development/service_ping/implement.md
+++ b/doc/development/service_ping/implement.md
@@ -179,7 +179,7 @@ As the HyperLogLog algorithm is probabilistic, the **results always include erro
 The highest encountered error rate is 4.9%.
 
 When correctly used, the `estimate_batch_distinct_count` method enables efficient counting over
-columns that contain non-unique values, which can not be assured by other counters.
+columns that contain non-unique values, which cannot be assured by other counters.
 
 ##### estimate_batch_distinct_count method