Add latest changes from gitlab-org/gitlab@master

15 files changed, 31 insertions, 28 deletions

diff --git a/doc/administration/geo/setup/external_database.md b/doc/administration/geo/setup/external_database.md
index e4cd05a2b73..eabed7c10f3 100644
--- a/doc/administration/geo/setup/external_database.md
+++ b/doc/administration/geo/setup/external_database.md
@@ -69,8 +69,7 @@ To set up an external database, you can either:
 
 Given you have a primary site set up on AWS EC2 that uses RDS.
 You can now just create a read-only replica in a different region and the
-replication process is managed by AWS. Make sure you've set Network ACL (Access Control List), Subnet, and
-Security Group according to your needs, so the secondary Rails node(s) can access the database.
+replication process is managed by AWS. Make sure you've set Network ACL (Access Control List), Subnet, and Security Group according to your needs, so the secondary Rails nodes can access the database.
 
 The following instructions detail how to create a read-only replica for common
 cloud providers:
diff --git a/doc/architecture/blueprints/pods/index.md b/doc/architecture/blueprints/pods/index.md
index de5c12c3c70..00f57a8cbac 100644
--- a/doc/architecture/blueprints/pods/index.md
+++ b/doc/architecture/blueprints/pods/index.md
@@ -143,7 +143,7 @@ We should likely position this as a push for GitLab workspaces and not talk abou
 
 What are other distinct advantages of workspaces that could be shipped?
 
-- Easier admin controls
+- Easier administrator controls
 - Better permission management
 - Instance-like UX
 
diff --git a/doc/architecture/blueprints/rate_limiting/index.md b/doc/architecture/blueprints/rate_limiting/index.md
index 692cef4b11d..2d2fe6ac511 100644
--- a/doc/architecture/blueprints/rate_limiting/index.md
+++ b/doc/architecture/blueprints/rate_limiting/index.md
@@ -357,7 +357,7 @@ hierarchy. Choosing a proper solution will require a thoughtful research.
 1. Build application limits API in a way that it can be easily extracted to a separate service.
 1. Build application limits definition in a way that is independent from the Rails application.
 1. Build tooling that produce consistent behavior and results across programming languages.
-1. Build the new framework in a way that we can extend to allow self-managed admins to customize limits.
+1. Build the new framework in a way that we can extend to allow self-managed administrators to customize limits.
 1. Maintain consistent features and behavior across SaaS and self-managed codebase.
 1. Be mindful about a cognitive load added by the hierarchical limits, aim to reduce it.
 
diff --git a/doc/development/audit_event_guide/index.md b/doc/development/audit_event_guide/index.md
index 27a56d7904f..5c8938aa46a 100644
--- a/doc/development/audit_event_guide/index.md
+++ b/doc/development/audit_event_guide/index.md
@@ -19,7 +19,7 @@ actions performed across the application.
 While any events could trigger an Audit Event, not all events should. In general, events that are not good candidates for audit events are:
 
 - Not attributable to one specific user.
-- Not of specific interest to an admin or owner persona.
+- Not of specific interest to an administrator or owner persona.
 - Are tracking information for product feature adoption.
 - Are covered in the direction page's discussion on [what is not planned](https://about.gitlab.com/direction/manage/compliance/audit-events/#what-is-not-planned-right-now).
 
diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md
index 13cdf2c0c08..d3908e4e293 100644
--- a/doc/development/ee_features.md
+++ b/doc/development/ee_features.md
@@ -72,7 +72,7 @@ To guard your licensed feature:
    ```
 
 1. Optional. If your global feature is also available to namespaces with a paid plan, combine two
-feature identifiers to allow both admins and group users. For example:
+feature identifiers to allow both administrators and group users. For example:
 
     ```ruby
     License.feature_available?(:my_feature_name) || group.licensed_feature_available?(:my_feature_name_for_namespace) # Both admins and group members can see this EE feature
diff --git a/doc/development/sidekiq/index.md b/doc/development/sidekiq/index.md
index b94a9df8e32..547e740a4cf 100644
--- a/doc/development/sidekiq/index.md
+++ b/doc/development/sidekiq/index.md
@@ -186,3 +186,9 @@ default weight, which is 1.
 
 Each Sidekiq worker must be tested using RSpec, just like any other class. These
 tests should be placed in `spec/workers`.
+
+## Interacting with Sidekiq Redis
+
+The application should minimise interaction with of any `Sidekiq.redis`. Directly interacting with `Sidekiq.redis` in generic logic should be abstracted to a [Sidekiq middleware](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/sidekiq_middleware) for re-use across teams. By decoupling application logic from Sidekiq's datastore, it allows for greater freedom when horizontally scaling the GitLab background processing setup.
+
+Some exceptions to this rule would be migration-related logic or administration operations.
diff --git a/doc/integration/arkose.md b/doc/integration/arkose.md
index 84b30d69db4..aa27e3ba4a4 100644
--- a/doc/integration/arkose.md
+++ b/doc/integration/arkose.md
@@ -29,7 +29,7 @@ user doesn't need to take any additional action and can sign in as usual.
 ## How do we treat malicious sign-in attempts?
 
 Users are not denied access if Arkose Protect considers they are malicious. However,
-their risk score is exposed in the admin console so that we can make more informed decisions when it
+their risk score is exposed in the administrator console so that we can make more informed decisions when it
 comes to manually blocking users. When we decide to block a user, feedback is sent to ArkoseLabs to
 improve their risk prediction model.
 
diff --git a/doc/integration/mattermost/index.md b/doc/integration/mattermost/index.md
index 36a04f423a7..04b0157b737 100644
--- a/doc/integration/mattermost/index.md
+++ b/doc/integration/mattermost/index.md
@@ -272,7 +272,7 @@ There are 4 users on local instance
 ### Use `mmctl` through a remote connection
 
 For remote connections or local connections where the socket cannot be used,
-create a non SSO user and give that user admin privileges. Those credentials
+create a non SSO user and give that user administrator privileges. Those credentials
 can then be used to authenticate `mmctl`:
 
 ```shell
diff --git a/doc/user/application_security/dast/checks/16.5.md b/doc/user/application_security/dast/checks/16.5.md
index 9f9c3292ba4..285cc753523 100644
--- a/doc/user/application_security/dast/checks/16.5.md
+++ b/doc/user/application_security/dast/checks/16.5.md
@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 ## Description
 
-The target website returns AspNet header(s) and version information of this website. By
+The target website returns AspNet headers and version information of this website. By
 exposing these values attackers may attempt to identify if the target software is vulnerable to known
 vulnerabilities, or catalog known sites running particular versions to exploit in the future when a
 vulnerability is identified in the particular version.
diff --git a/doc/user/application_security/dast/checks/16.6.md b/doc/user/application_security/dast/checks/16.6.md
index c6297d477fa..c6705b2ec7f 100644
--- a/doc/user/application_security/dast/checks/16.6.md
+++ b/doc/user/application_security/dast/checks/16.6.md
@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 ## Description
 
-The target website returns AspNet header(s) along with version information of this website. By
+The target website returns AspNet headers along with version information of this website. By
 exposing these values attackers may attempt to identify if the target software is vulnerable to known
 vulnerabilities. Or catalog known sites running particular versions to exploit in the future when a
 vulnerability is identified in the particular version.
diff --git a/doc/user/group/saml_sso/troubleshooting_scim.md b/doc/user/group/saml_sso/troubleshooting_scim.md
index 2862d3c9125..f98b6c61e11 100644
--- a/doc/user/group/saml_sso/troubleshooting_scim.md
+++ b/doc/user/group/saml_sso/troubleshooting_scim.md
@@ -30,7 +30,7 @@ It is important that this SCIM `id` and SCIM `externalId` are configured to the
 
 ## How do I verify user's SAML NameId matches the SCIM externalId
 
-Admins can use the Admin Area to [list SCIM identities for a user](../../admin_area/index.md#user-identities).
+Administrators can use the Admin Area to [list SCIM identities for a user](../../admin_area/index.md#user-identities).
 
 Group owners can see the list of users and the `externalId` stored for each user in the group SAML SSO Settings page.
 
diff --git a/doc/user/infrastructure/clusters/migrate_to_gitlab_agent.md b/doc/user/infrastructure/clusters/migrate_to_gitlab_agent.md
index 04d8870cc22..b2b5da61a81 100644
--- a/doc/user/infrastructure/clusters/migrate_to_gitlab_agent.md
+++ b/doc/user/infrastructure/clusters/migrate_to_gitlab_agent.md
@@ -26,7 +26,7 @@ you can use the [CI/CD workflow](../../clusters/agent/ci_cd_workflow.md).
 This workflow uses an agent to connect to your cluster. The agent:
 
 - Is not exposed to the internet.
-- Does not require full cluster-admin access to GitLab.
+- Does not require full [`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) access to GitLab.
 
 NOTE:
 The certificate-based integration was used for popular GitLab features like
diff --git a/doc/user/project/merge_requests/reviews/data_usage.md b/doc/user/project/merge_requests/reviews/data_usage.md
index 460841838bc..60fc54facf3 100644
--- a/doc/user/project/merge_requests/reviews/data_usage.md
+++ b/doc/user/project/merge_requests/reviews/data_usage.md
@@ -9,35 +9,35 @@ type: index, reference
 
 ## How it works
 
-Suggested Reviewers is the first user-facing GitLab machine learning (ML) powered feature. It leverages a project's contribution graph to generate suggestions. This data already exists within GitLab including merge request metadata, source code files, and GitLab user account metadata. 
+Suggested Reviewers is the first user-facing GitLab machine learning (ML) powered feature. It leverages a project's contribution graph to generate suggestions. This data already exists within GitLab including merge request metadata, source code files, and GitLab user account metadata.
 
 ### Enabling the feature
 
 When a Project Maintainer or Owner enables Suggested Reviewers in project settings GitLab kicks off a data extraction job for the project which leverages the Merge Request API to understand pattern of review including recency, domain experience, and frequency to suggest an appropriate reviewer.
 
-This data extraction job can take a few hours to complete (possibly up to a day), which is largely dependent on the size of the project. The process is automated and no action is needed during this process. Once data extraction is complete, you will start getting suggestions in merge requests. 
+This data extraction job can take a few hours to complete (possibly up to a day), which is largely dependent on the size of the project. The process is automated and no action is needed during this process. Once data extraction is complete, you will start getting suggestions in merge requests.
 
 ### Generating suggestions
 
-Once Suggested Reviewers is enabled and the data extraction is complete, new merge requests or new commits to existing merge requests will automatically trigger a Suggested Reviewers ML model inference and generate up to 5 suggested reviewers. These suggestions are contextual to the changes in the merge request. Additional commits to merge requests may change the reviewer suggestions which will automatically update in the reviewer dropdown. 
+Once Suggested Reviewers is enabled and the data extraction is complete, new merge requests or new commits to existing merge requests will automatically trigger a Suggested Reviewers ML model inference and generate up to 5 suggested reviewers. These suggestions are contextual to the changes in the merge request. Additional commits to merge requests may change the reviewer suggestions which will automatically update in the reviewer dropdown.
 
 ## Progressive enhancement
 
-This feature is designed as a progressive enhancement to the existing GitLab Reviewers functionality. The GitLab Reviewer UI will only offer suggestions if the ML engine is able to provide a recommendation. In the event of an issue or model inference failure, the feature will gracefully degrade. At no point with the usage of Suggested Reviewers prevent a user from being able to manually set a reviewer. 
+This feature is designed as a progressive enhancement to the existing GitLab Reviewers functionality. The GitLab Reviewer UI will only offer suggestions if the ML engine is able to provide a recommendation. In the event of an issue or model inference failure, the feature will gracefully degrade. At no point with the usage of Suggested Reviewers prevent a user from being able to manually set a reviewer.
 
 ## Model Accuracy
 
-Organizations use many different processes for code review. Some focus on senior engineers reviewing junior engineer's code, others have hierarchical organizational structure based reviews. Suggested Reviewers is focused on contextual reviewers based on historical merge request activity by users. While we will continue evolving the underlying ML model to better serve various code review use cases and processes Suggested Reviewers does not replace the usage of other code review features like Code Owners and [Approval Rules](../approvals/rules.md). Reviewer selection is highly subjective therefore, we do not expect Suggested Reviewers to provide perfect suggestions everytime. 
+Organizations use many different processes for code review. Some focus on senior engineers reviewing junior engineer's code, others have hierarchical organizational structure based reviews. Suggested Reviewers is focused on contextual reviewers based on historical merge request activity by users. While we will continue evolving the underlying ML model to better serve various code review use cases and processes Suggested Reviewers does not replace the usage of other code review features like Code Owners and [Approval Rules](../approvals/rules.md). Reviewer selection is highly subjective therefore, we do not expect Suggested Reviewers to provide perfect suggestions everytime.
 
 Through analysis of beta customer usage, we find that the Suggested Reviewers ML model provides suggestions that are adopted in 60% of cases. We will be introducing a feedback mechanism into the Suggested Reviewers feature in the future to allow users to flag bad reviewer suggestions to help improve the model. Additionally we will be offering an opt-in feature in the future which will allow the model to use your project's data for training the underlying model.
 
 ## Off by default
 
-Suggested Reviewers is off by default and requires a Project Owner or Admin to enable the feature. 
+Suggested Reviewers is off by default and requires a Project Owner or Admin to enable the feature.
 
 ## Data privacy
 
-Suggested Reviewers operates completely within the GitLab.com infrastructure providing the same level of [privacy](https://about.gitlab.com/privacy/) and [security](https://about.gitlab.com/security/) of any other feature of GitLab.com. 
+Suggested Reviewers operates completely within the GitLab.com infrastructure providing the same level of [privacy](https://about.gitlab.com/privacy/) and [security](https://about.gitlab.com/security/) of any other feature of GitLab.com.
 
 No new additional data is collected to enable this feature, simply GitLab is inferencing your merge request against a trained machine learning model. The content of your source code is not used as training data. Your data also never leaves GitLab.com, all training and inference is done within GitLab.com infrastructure.
 
diff --git a/doc/user/tasks.md b/doc/user/tasks.md
index df0d88a18f0..c8124229653 100644
--- a/doc/user/tasks.md
+++ b/doc/user/tasks.md
@@ -115,7 +115,7 @@ To change the assignee on a task:
 1. In the issue description, in the **Tasks** section, select the title of the task you want to edit.
    The task window opens.
 1. Next to **Assignees**, select **Add assignees**.
-1. From the dropdown list, select the user(s) to add as an assignee.
+1. From the dropdown list, select the users to add as an assignee.
 1. Select any area outside the dropdown list.
 
 ## Set a start and due date
diff --git a/doc/user/usage_quotas.md b/doc/user/usage_quotas.md
index 2060a029833..e123f537424 100644
--- a/doc/user/usage_quotas.md
+++ b/doc/user/usage_quotas.md
@@ -13,7 +13,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 ## Namespace storage limit
 
 Namespaces on GitLab SaaS have a storage limit. For more information, see our [pricing page](https://about.gitlab.com/pricing/).
-This limit is not visible on the Usage quotas page, but will be prior to [enforcement](#namespace-storage-limit-enforcement-schedule). Self-managed deployments are not affected.
+This limit is not visible on the Usage quotas page, but will be prior to the limit being [applied](#namespace-storage-limit-application-schedule). Self-managed deployments are not affected.
 
 Storage types that add to the total namespace storage are:
 
@@ -38,16 +38,14 @@ To prevent exceeding the namespace storage quota, you can:
 - [Start a trial](https://about.gitlab.com/free-trial/) or [upgrade to GitLab Premium or Ultimate](https://about.gitlab.com/pricing) which include higher limits and features that enable growing teams to ship faster without sacrificing on quality.
 - [Talk to an expert](https://page.gitlab.com/usage_limits_help.html) to learn more about your options and ask questions.
 
-### Namespace storage limit enforcement schedule
+### Namespace storage limit application schedule
 
-Storage limits for GitLab SaaS Free tier namespaces will not be enforced prior to 2022-10-19. Storage limits for GitLab SaaS Paid tier namespaces will not be enforced for prior to 2023-02-15. Enforcement will not occur until all storage types are accurately measured, including deduplication of forks for [Git](https://gitlab.com/gitlab-org/gitlab/-/issues/371671) and [LFS](https://gitlab.com/gitlab-org/gitlab/-/issues/370242).
+Information on when namespace-level storage limits will be applied is available on these FAQ pages for the [Free](https://about.gitlab.com/pricing/faq-efficient-free-tier/#storage-limits-on-gitlab-saas-free-tier) and [Paid](https://about.gitlab.com/pricing/faq-paid-storage-transfer/) tier.  
 
-Impacted users are notified by email and through in-app notifications at least 60 days prior to enforcement.
-
-### Project storage limit
+## Project storage limit
 
 Projects on GitLab SaaS have a 10GB storage limit on their Git repository and LFS storage.
-After namespace-level storage limits are enforced, the project limit is removed. A namespace has either a namespace-level storage limit or a project-level storage limit, but not both.
+After namespace-level storage limits are applied, the project limit will be removed. A namespace has either a namespace-level storage limit or a project-level storage limit, but not both.
 
 When a project's repository and LFS reaches the quota, the project is locked.
 You cannot push changes to a locked project. To monitor the size of each
@@ -102,7 +100,7 @@ Depending on your role, you can also use the following methods to manage or redu
 
 ## Excess storage usage
 
-Excess storage usage is the amount that a project's repository and LFS exceeds the free storage quota. If no
+Excess storage usage is the amount that a project's repository and LFS exceeds the [project storage limit](#project-storage-limit). If no
 purchased storage is available the project is locked. You cannot push changes to a locked project.
 To unlock a project you must [purchase more storage](../subscriptions/gitlab_com/index.md#purchase-more-storage-and-transfer)
 for the namespace. When the purchase is completed, locked projects are automatically unlocked. The