Admin Area instructions, unowned docs, 2 of 2

doc/user/admin_area/settings/floc.md

@@ -22,7 +22,8 @@ Permissions-Policy: interest-cohort=()
 
 To enable it:
 
-1. Go to the Admin Area (**{admin}**) and select **Settings > General**.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. In the left sidebar, select **Settings > General**.
 1. Expand **Federated Learning of Cohorts**.
 1. Check the box.
 1. Click **Save changes**.

doc/user/admin_area/settings/help_page.md

@@ -16,7 +16,8 @@ to go for help. You can customize and display this information on the GitLab ser
 You can add a help message, which is shown on the GitLab `/help` page (e.g.,
 <https://gitlab.com/help>) in a new section at the top of the `/help` page:
 
-1. Navigate to **Admin Area > Settings > Preferences**, then expand **Help page**.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. In the left sidebar, select **Settings > Preferences**, then expand **Help page**.
 1. Under **Help page text**, fill in the information you wish to display on `/help`.
 1. Save your changes. You can now see the message on `/help`.
 
@@ -25,7 +26,8 @@ You can add a help message, which is shown on the GitLab `/help` page (e.g.,
 You can add a help message, which is shown on the GitLab login page in a new section
 titled `Need Help?`, located below the login page message:
 
-1. Navigate to **Admin Area > Settings > Preferences**, then expand **Help page**.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. In the left sidebar, select **Settings > Preferences**, then expand **Help page**.
 1. Under **Help text**, fill in the information you wish to display on the login page.
 
    ![help message on login page](img/help_page_help_text_v12_3.png)

doc/user/admin_area/settings/rate_limits_on_raw_endpoints.md

@@ -9,8 +9,11 @@ type: reference
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30829) in GitLab 12.2.
 
-This setting allows you to rate limit the requests to raw endpoints, defaults to `300` requests per minute.
-It can be modified in **Admin Area > Settings > Network > Performance Optimization**.
+This setting defaults to `300` requests per minute, and allows you to rate limit the requests to raw endpoints:
+
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. In the left sidebar, select **Settings > Network**.
+1. Expand **Performance optimization**.
 
 For example, requests over `300` per minute to `https://gitlab.com/gitlab-org/gitlab-foss/raw/master/app/controllers/application_controller.rb` are blocked. Access to the raw file is released after 1 minute.
 

doc/user/admin_area/settings/sign_in_restrictions.md

@@ -13,7 +13,8 @@ You can use **Sign-in restrictions** to customize authentication restrictions fo
 
 To access sign-in restriction settings:
 
-1. Navigate to the **Admin Area > Settings > General**.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. In the left sidebar, select **Settings > General**.
 1. Expand the **Sign-in restrictions** section.
 
 ## Password authentication enabled
@@ -78,7 +79,7 @@ If necessary, you can disable **Admin Mode** as an administrator by using one of
   ```ruby
   ::Gitlab::CurrentSettings.update!(admin_mode: false)
   ```
-  
+
 ## Two-factor authentication
 
 When this feature is enabled, all users must use the [two-factor authentication](../../profile/account/two_factor_authentication.md).
@@ -114,13 +115,14 @@ For example, if you include the following information in the noted text box:
 ```markdown
 # Custom sign-in text
 
-To access this text box, navigate to Admin Area > Settings > General, and expand the "Sign-in restrictions" section.
+To access this text box:
+
+1. On the top bar, select **Menu > Admin**.
+1. In the left sidebar, select **Settings > General**, and expand the **Sign-in restrictions** section.
 ```
 
 Your users see the **Custom sign-in text** when they navigate to the sign-in screen for your
-GitLab instance:
-
-![Sign-in page](img/custom_sign_in_page_v13_6.png)
+GitLab instance.
 
 <!-- ## Troubleshooting
 

doc/user/admin_area/settings/sign_up_restrictions.md

@@ -22,7 +22,8 @@ you do not expect public users to sign up for an account.
 
 To disable sign ups:
 
-1. Go to **Admin Area > Settings > General** and expand **Sign-up restrictions**.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. In the left sidebar, select **Settings > General**, and expand **Sign-up restrictions**.
 1. Clear the **Sign-up enabled** checkbox, then select **Save changes**.
 
 ## Require administrator approval for new sign ups
@@ -34,7 +35,8 @@ When this setting is enabled, any user visiting your GitLab domain and signing u
 
 To require administrator approval for new sign ups:
 
-1. Go to **Admin Area > Settings > General** and expand **Sign-up restrictions**.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. In the left sidebar, select **Settings > General**, and expand **Sign-up restrictions**.
 1. Select the **Require admin approval for new sign-ups** checkbox, then select **Save changes**.
 
 In [GitLab 13.7 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/273258), if an administrator disables this setting, the users in pending approval state are
@@ -47,7 +49,8 @@ their email address before they are allowed to sign in.
 
 To enforce confirmation of the email address used for new sign ups:
 
-1. Go to **Admin Area > Settings > General** and expand **Sign-up restrictions**.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. In the left sidebar, select **Settings > General**, and expand **Sign-up restrictions**.
 1. Select the **Enable email restrictions for sign ups** checkbox, then select **Save changes**.
 
 ## User cap **(FREE SELF)**
@@ -64,7 +67,8 @@ user cap, the users in pending approval state are automatically approved in a ba
 
 ### Set the user cap number
 
-1. Go to  **Admin Area > Settings > General**.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. In the left sidebar, select **Settings > General**.
 1. Expand **Sign-up restrictions**.
 1. Enter a number in **User cap**.
 1. Select **Save changes**.
@@ -73,7 +77,8 @@ New user sign ups are subject to the user cap restriction.
 
 ## Remove the user cap
 
-1. Go to  **Admin Area > Settings > General**.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. In the left sidebar, select **Settings > General**.
 1. Expand **Sign-up restrictions**.
 1. Remove the number from **User cap**.
 1. Select **Save changes**.
@@ -130,7 +135,8 @@ reduce the risk of malicious users creating spam accounts with disposable email
 
 To create an email domain allowlist or denylist:
 
-1. Go to **Admin Area > Settings > General** and expand **Sign-up restrictions**.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. In the left sidebar, select **Settings > General**, and expand **Sign-up restrictions**.
 1. For the allowlist, you must enter the list manually. For the denylist, you can enter the list
    manually or upload a `.txt` file that contains list entries.
 

doc/user/admin_area/settings/terms.md

@@ -7,7 +7,7 @@ type: reference
 
 # Enforce accepting Terms of Service **(FREE SELF)**
 
-An admin can enforce acceptance of a terms of service and privacy policy. When this option is enabled, new and existing users must accept the terms.
+An administrator can enforce acceptance of a terms of service and privacy policy. When this option is enabled, new and existing users must accept the terms.
 
 If configured, the Terms of Service page can be viewed via `https://your-instance.com/-/users/terms` at anytime.
 
@@ -16,7 +16,8 @@ If configured, the Terms of Service page can be viewed via `https://your-instanc
 To enforce acceptance of a Terms of Service and Privacy Policy:
 
 1. Log in to the GitLab instance as an admin user.
-1. Go to **Admin Area > Settings > General**.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. In the left sidebar, select **Settings > General**.
 1. Expand the **Terms of Service and Privacy Policy** section.
 1. Check the **Require all users to accept Terms of Service and Privacy Policy when they access
    GitLab.** checkbox.

doc/user/admin_area/settings/third_party_offers.md

@@ -13,7 +13,11 @@ Within GitLab, we inform users of available third-party offers they might find v
 to enhance the development of their projects. An example is the Google Cloud Platform free credit
 for using [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/).
 
-The display of third-party offers can be toggled in the **Admin Area > Settings** page.
+To toggle the display of third-party offers:
+
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. In the left sidebar, select **Settings**, and expand **Third party offers**.
+1. Select **Do not display offers from third parties within GitLab**.
 
 <!-- ## Troubleshooting
 

doc/user/admin_area/settings/usage_statistics.md

@@ -10,8 +10,12 @@ type: reference
 GitLab Inc. periodically collects information about your instance in order
 to perform various actions.
 
-All statistics are opt-out. You can enable/disable them in the
-**Admin Area > Settings > Metrics and profiling** section **Usage statistics**.
+All statistics are opt-out. To enable or disable them:
+
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. In the left sidebar, select **Settings > Metrics and profiling**, and expand **Usage statistics**.
+1. Enable or disable **Version check** and **Usage ping**.
+1. Select **Save changes**.
 
 ## Network configuration
 
@@ -40,8 +44,12 @@ This information is used, among other things, to identify to which versions
 patches must be backported, making sure active GitLab instances remain
 secure.
 
-If you disable version check, this information isn't collected. Enable or
-disable the version check in **Admin Area > Settings > Metrics and profiling > Usage statistics**.
+If you disable version check, this information isn't collected. To enable or disable it:
+
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. In the left sidebar, select **Settings > Metrics and profiling**, and expand **Usage statistics**.
+1. Enable or disable **Version check**.
+1. Select **Save changes**.
 
 ### Request flow example
 

doc/user/admin_area/settings/user_and_ip_rate_limits.md

@@ -11,20 +11,21 @@ Rate limiting is a common technique used to improve the security and durability
 of a web application. For more details, see
 [Rate limits](../../../security/rate_limits.md).
 
-The following limits can be enforced in **Admin Area > Settings > Network > User and
-IP rate limits**:
+The following limits are disabled by default:
 
 - Unauthenticated requests
 - Authenticated API requests
 - Authenticated web requests
 
-These limits are disabled by default.
+To enforce any or all of them:
 
-NOTE:
-By default, all Git operations are first tried unauthenticated. Because of this, HTTP Git operations
-may trigger the rate limits configured for unauthenticated requests.
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. In the left sidebar, select **Settings > Network**, and expand **User and IP rate limits**:
+   ![user-and-ip-rate-limits](img/user_and_ip_rate_limits.png)
 
-![user-and-ip-rate-limits](img/user_and_ip_rate_limits.png)
+   NOTE:
+   By default, all Git operations are first tried unauthenticated. Because of this, HTTP Git operations
+   may trigger the rate limits configured for unauthenticated requests.
 
 ## Response text
 

doc/user/instance/clusters/index.md

@@ -14,7 +14,10 @@ instance-level Kubernetes clusters allow you to connect a Kubernetes cluster to
 the GitLab instance, which enables you to use the same cluster across multiple
 projects.
 
-The instance level Kubernetes clusters can be found in the top menu by navigating to your instance's **{admin}** **Admin Area > Kubernetes**.
+To view the instance level Kubernetes clusters:
+
+1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. In the left sidebar, select **Kubernetes**.
 
 ## Cluster precedence