Add latest changes from gitlab-org/gitlab@master

2 files changed, 15 insertions, 31 deletions

diff --git a/doc/administration/moderate_users.md b/doc/administration/moderate_users.md
index 4e012bdc9bd..b30294c5fe0 100644
--- a/doc/administration/moderate_users.md
+++ b/doc/administration/moderate_users.md
@@ -57,9 +57,7 @@ To approve or reject a user sign up:
 1. Select **Admin Area**.
 1. Select **Overview > Users**.
 1. Select the **Pending approval** tab.
-1. Optional. Select a user.
-1. Select the **{settings}** **User administration** dropdown list.
-1. Select **Approve** or **Reject**.
+1. For the user sign up you want to approve or reject, select the vertical ellipsis (**{ellipsis_v}**), then **Approve** or **Reject**.
 
 Approving a user:
 
@@ -88,7 +86,7 @@ To block a user:
 1. On the left sidebar, select **Search or go to**.
 1. Select **Admin Area**.
 1. Select **Overview > Users**.
-1. For the user you want to deactivate, select the vertical ellipsis (**{ellipsis_v}**) and then **Block**.
+1. For the user you want to block, select the vertical ellipsis (**{ellipsis_v}**), then **Block**.
 
 To report abuse from other users, see [report abuse](../user/report_abuse.md). For more information on abuse reports in the Admin area, see [resolving abuse reports](../administration/review_abuse_reports.md#resolving-abuse-reports).
 
@@ -100,9 +98,7 @@ A blocked user can be unblocked from the Admin Area. To do this:
 1. Select **Admin Area**.
 1. Select **Overview > Users**.
 1. Select the **Blocked** tab.
-1. Optional. Select a user.
-1. Select the **{settings}** **User administration** dropdown list.
-1. Select **Unblock**.
+1. For the user you want to unblock, select the vertical ellipsis (**{ellipsis_v}**), then **Unblock**.
 
 The user's state is set to active and they consume a
 [seat](../subscriptions/self_managed/index.md#billable-users).
@@ -137,7 +133,7 @@ The user you deactivate must be dormant. When you deactivate a user, their proje
 - Cannot use slash commands. For more information, see [slash commands](../user/project/integrations/gitlab_slack_application.md#slash-commands).
 - Does not occupy a seat. For more information, see [billable users](../subscriptions/self_managed/index.md#billable-users).
 
-Deactiviation is similar to blocking, but there are a few important differences. Deactivating a user does not prohibit the user from signing into the GitLab UI. A deactivated user can become active again by signing in. 
+Deactivation is similar to blocking, but there are a few important differences. Deactivating a user does not prohibit the user from signing into the GitLab UI. A deactivated user can become active again by signing in.
 
 To deactivate a user from the Admin Area:
 
@@ -220,9 +216,7 @@ To do this:
 1. Select **Admin Area**.
 1. Select **Overview > Users**.
 1. Select the **Deactivated** tab.
-1. Optional. Select a user.
-1. Select the **{settings}** **User administration** dropdown list.
-1. Select **Activate**.
+1. For the user you want to activate, select the vertical ellipsis (**{ellipsis_v}**), then **Activate**.
 
 The user's state is set to active and they consume a
 [seat](../subscriptions/self_managed/index.md#billable-users).
@@ -250,9 +244,7 @@ Users can be banned using the Admin Area. To do this:
 1. On the left sidebar, select **Search or go to**.
 1. Select **Admin Area**.
 1. Select **Overview > Users**.
-1. Optional. Select a user.
-1. Select the **{settings}** **User administration** dropdown list.
-1. Select **Ban user**.
+1. For the user you want to ban, select the vertical ellipsis (**{ellipsis_v}**), then **Ban user**.
 
 The banned user does not consume a [seat](../subscriptions/self_managed/index.md#billable-users).
 
@@ -264,24 +256,19 @@ A banned user can be unbanned using the Admin Area. To do this:
 1. Select **Admin Area**.
 1. Select **Overview > Users**.
 1. Select the **Banned** tab.
-1. Optional. Select a user.
-1. Select the **{settings}** **User administration** dropdown list.
-1. Select **Unban user**.
+1. For the user you want to unban, select the vertical ellipsis (**{ellipsis_v}**), then **Unban user**.
 
 The user's state is set to active and they consume a
 [seat](../subscriptions/self_managed/index.md#billable-users).
 
-### Delete a user
+## Delete a user
 
 Use the Admin Area to delete users.
 
 1. On the left sidebar, select **Search or go to**.
 1. Select **Admin Area**.
 1. Select **Overview > Users**.
-1. Select the **Banned** tab.
-1. Optional. Select a user.
-1. Select the **{settings}** **User administration** dropdown list.
-1. Select **Delete user**.
+1. For the user you want to delete, select the vertical ellipsis (**{ellipsis_v}**), then **Delete user**.
 1. Type the username.
 1. Select **Delete user**.
 
@@ -293,10 +280,7 @@ You can also delete a user and their contributions, such as merge requests, issu
 1. On the left sidebar, select **Search or go to**.
 1. Select **Admin Area**.
 1. Select **Overview > Users**.
-1. Select the **Banned** tab.
-1. Optional. Select a user.
-1. Select the **{settings}** **User administration** dropdown list.
-1. Select **Delete user and contributions**.
+1. For the user you want to delete, select the vertical ellipsis (**{ellipsis_v}**), then **Delete user and contributions**.
 1. Type the username.
 1. Select **Delete user and contributions**.
 
diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md
index 8f201e0a5ab..731142d4a44 100644
--- a/doc/administration/reference_architectures/index.md
+++ b/doc/administration/reference_architectures/index.md
@@ -214,7 +214,7 @@ See [Recommended cloud providers and services](index.md#recommended-cloud-provid
 
 The reference architectures were tested with repositories of varying sizes that follow best practices.
 
-**However, [large monorepos](../../user/project/repository/managing_large_repositories.md) (several gigabytes or more) can significantly impact the performance of Git and in turn the environment itself.**
+**However, [large monorepos](../../user/project/repository/monorepos/optimize_settings.md) (several gigabytes or more) can significantly impact the performance of Git and in turn the environment itself.**
 Their presence, as well as how they are used, can put a significant strain on the entire system from Gitaly through to the underlying infrastructure.
 
 WARNING:
@@ -223,12 +223,12 @@ If this applies to you, we strongly recommended referring to the linked document
 As such, large monorepos come with notable cost. If you have such a repository we strongly recommend
 the following guidance is followed to ensure the best chance of good performance and to keep costs in check:
 
-- [Optimize the large monorepo](../../user/project/repository/managing_large_repositories.md#optimize-gitlab-settings). Using features such as
-  [LFS](../../user/project/repository/managing_large_repositories.md#use-lfs-for-large-blobs) to not store binaries, and other approaches for reducing repository size, can
+- [Optimize the large monorepo](../../user/project/repository/monorepos/optimize_settings.md#optimize-gitlab-settings). Using features such as
+  [LFS](../../user/project/repository/monorepos/optimize_settings.md#use-lfs-for-large-blobs) to not store binaries, and other approaches for reducing repository size, can
   dramatically improve performance and reduce costs.
 - Depending on the monorepo, increased environment specifications may be required to compensate. Gitaly in particular will likely require additional resources along with Praefect, GitLab Rails, and Load Balancers. This depends notably on the monorepo itself and the usage against it.
 - When the monorepo is significantly large (20 gigabytes or more) further additional strategies maybe required such as even further increased specifications or in some cases a separate Gitaly backend for the monorepo alone.
-- Network and disk bandwidth is another potential consideration with large monorepos. In very heavy cases, it's possible to see bandwidth saturation if there's a high amount of concurrent clones (such as with CI). It's strongly recommended [reducing full clones wherever possible](../../user/project/repository/managing_large_repositories.md#reduce-concurrent-clones-in-cicd) in this scenario. Otherwise, additional environment specifications may be required to increase bandwidth, but this differs between cloud providers.
+- Network and disk bandwidth is another potential consideration with large monorepos. In very heavy cases, it's possible to see bandwidth saturation if there's a high amount of concurrent clones (such as with CI). It's strongly recommended [reducing full clones wherever possible](../../user/project/repository/monorepos/optimize_settings.md#reduce-concurrent-clones-in-cicd) in this scenario. Otherwise, additional environment specifications may be required to increase bandwidth, but this differs between cloud providers.
 
 ### Additional workloads
 
@@ -239,7 +239,7 @@ However, additional workloads can multiply the impact of operations by triggerin
 You may need to adjust the suggested specifications to compensate if you use, for example:
 
 - Security software on the nodes.
-- Hundreds of concurrent CI jobs for [large repositories](../../user/project/repository/managing_large_repositories.md).
+- Hundreds of concurrent CI jobs for [large repositories](../../user/project/repository/monorepos/optimize_settings.md).
 - Custom scripts that [run at high frequency](../logs/log_parsing.md#print-top-api-user-agents).
 - [Integrations](../../integration/index.md) in many large projects.
 - [Server hooks](../server_hooks.md).