Revisions to Create pages

Word and line edits for Create pages, to bring down the number of
Vale warnings.

doc/user/admin_area/settings/account_and_limit_settings.md

@@ -13,7 +13,8 @@ You can change the default maximum number of projects that users can create in t
 Navigate to **Admin Area > Settings > General**, then expand **Account and Limit**.
 You can increase or decrease that `Default projects limit` value.
 
-- If you set `Default projects limit` to 0, users are not allowed to create projects in their users personal namespace. However, projects can still be created within a group.
+- If you set `Default projects limit` to 0, users are not allowed to create projects
+  in their users personal namespace. However, projects can still be created in a group.
 
 ## Max attachment size
 
@@ -22,8 +23,8 @@ Navigate to **Admin Area > Settings > General**, then expand **Account and Limit
 From here, you can increase or decrease by changing the value in `Maximum attachment size (MB)`.
 
 NOTE:
-If you choose a size larger than what is currently configured for the web server,
-you will likely get errors. See the [troubleshooting section](#troubleshooting) for more
+If you choose a size larger than the configured value for the web server,
+you may receive errors. See the [troubleshooting section](#troubleshooting) for more
 details.
 
 ## Max push size
@@ -39,8 +40,8 @@ Navigate to **Admin Area > Settings > General**, then expand **Account and Limit
 From here, you can increase or decrease by changing the value in `Maximum import size (MB)`.
 
 NOTE:
-If you choose a size larger than what is currently configured for the web server,
-you will likely get errors. See the [troubleshooting section](#troubleshooting) for more
+If you choose a size larger than the configured value for the web server,
+you may receive errors. See the [troubleshooting section](#troubleshooting) for more
 details.
 
 ## Personal Access Token prefix
@@ -64,12 +65,9 @@ using the `personal_access_token_prefix` field.
 
 ## Repository size limit **(STARTER ONLY)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/740) in [GitLab Enterprise Edition 8.12](https://about.gitlab.com/releases/2016/09/22/gitlab-8-12-released/#limit-project-size-ee).
-
-Repositories within your GitLab instance can grow quickly, especially if you are
+Repositories in your GitLab instance can grow quickly, especially if you are
 using LFS. Their size can grow exponentially, rapidly consuming available storage.
-
-To avoid this from happening, you can set a hard limit for your repositories' size.
+To prevent this from happening, you can set a hard limit for your repositories' size.
 This limit can be set globally, per group, or per project, with per project limits
 taking the highest priority.
 
@@ -88,7 +86,7 @@ For instance, consider the following workflow:
 Only a GitLab administrator can set those limits. Setting the limit to `0` means
 there are no restrictions.
 
-These settings can be found within:
+These settings can be found in:
 
 - Each project's settings:
   1. From the Project's homepage, navigate to **Settings > General**.
@@ -104,9 +102,9 @@ These settings can be found within:
   1. Fill in the **Size limit per repository (MB)** field.
   1. Click **Save changes**.
 
-The first push of a new project, including LFS objects, will be checked for size
-and **will** be rejected if the sum of their sizes exceeds the maximum allowed
-repository size.
+The first push of a new project, including LFS objects, is checked for size.
+If the sum of their sizes exceeds the maximum allowed repository size, the push
+is rejected.
 
 NOTE:
 The repository size limit includes repository files and LFS, but does not include artifacts, uploads,
@@ -121,12 +119,12 @@ For GitLab.com repository size limits, see [accounts and limit settings](../../g
 
 ### 413 Request Entity Too Large
 
-If you are attaching a file to a comment or reply in GitLab and receive the `413 Request Entity Too Large`
-error, it is likely caused by having a [max attachment size](#max-attachment-size)
-larger than what the web server is configured to allow.
+When attaching a file to a comment or reply in GitLab displays a `413 Request Entity Too Large`
+error, the [max attachment size](#max-attachment-size)
+is probably larger than the web server's allowed value.
 
-If you wanted to increase the max attachment size to 200m in a GitLab
-[Omnibus](https://docs.gitlab.com/omnibus/) install, for example, you might need to
+To increase the max attachment size to 200 MB in a
+[Omnibus GitLab](https://docs.gitlab.com/omnibus/) install, you may need to
 add the line below to `/etc/gitlab/gitlab.rb` before increasing the max attachment size:
 
 ```ruby
@@ -135,15 +133,15 @@ nginx['client_max_body_size'] = "200m"
 
 ## Limiting lifetime of personal access tokens **(ULTIMATE SELF)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3649) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.6.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3649) in GitLab Ultimate 12.6.
 
 Users can optionally specify an expiration date for
 [personal access tokens](../../profile/personal_access_tokens.md).
 This expiration date is not a requirement, and can be set to any arbitrary date.
 
-Since personal access tokens are the only token needed for programmatic access to GitLab,
-organizations with security requirements may want to enforce more protection to require
-regular rotation of these tokens.
+Personal access tokens are the only tokens needed for programmatic access to GitLab.
+However, organizations with security requirements may want to enforce more protection by
+requiring the regular rotation of these tokens.
 
 ### Setting a limit
 
@@ -167,7 +165,7 @@ Once a lifetime for personal access tokens is set, GitLab will:
 
 ## Enforcement of SSH key expiration **(ULTIMATE ONLY)**
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/276221) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.9.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/276221) in GitLab Ultimate 13.9.
 > - It is deployed behind a feature flag, disabled by default.
 > - It is disabled on GitLab.com.
 > - It is not recommended for production use.
@@ -201,13 +199,14 @@ Feature.disable(:ff_enforce_ssh_key_expiration)
 
 ## Optional enforcement of Personal Access Token expiry **(ULTIMATE SELF)**
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214723) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.1.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214723) in GitLab Ultimate 13.1.
 > - It is deployed behind a feature flag, disabled by default.
 > - It is disabled on GitLab.com.
 > - It is not recommended for production use.
 > - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-optional-enforcement-of-personal-access-token-expiry-feature). **(FREE SELF)**
 
-GitLab administrators can choose to prevent personal access tokens from expiring automatically. The tokens will be usable after the expiry date, unless they are revoked explicitly.
+GitLab administrators can choose to prevent personal access tokens from expiring
+automatically. The tokens are usable after the expiry date, unless they are revoked explicitly.
 
 To do this:
 
@@ -244,4 +243,6 @@ To do this:
 1. Check the **Prevent users from changing their profile name** checkbox.
 
 NOTE:
-When this ability is disabled, GitLab administrators will still be able to update the name of any user in their instance via the [Admin UI](../index.md#administering-users) or the [API](../../../api/users.md#user-modification)
+When this ability is disabled, GitLab administrators can still use the
+[Admin UI](../index.md#administering-users) or the
+[API](../../../api/users.md#user-modification) to update usernames.

doc/user/admin_area/settings/visibility_and_access_controls.md

@@ -11,14 +11,14 @@ GitLab allows administrators to enforce specific controls.
 
 To access the visibility and access control options:
 
-1. Log in to GitLab as an admin.
+1. Sign in to GitLab as a user with Administrator [permissions](../../permissions.md).
 1. Go to **Admin Area > Settings > General**.
 1. Expand the **Visibility and access controls** section.
 
 ## Default branch protection
 
 This global option defines the branch protection that applies to every repository's default branch. [Branch protection](../../project/protected_branches.md) specifies which roles can push to branches and which roles can delete
-branches. In this case _Default_ refers to a repository's default branch, which in most cases is _master_.
+branches. In this case _Default_ refers to a repository's default branch, which in most cases is `master`.
 
 This setting applies only to each repositories' default branch. To protect other branches, you must configure branch protection in repository. For details, see [Protected Branches](../../project/protected_branches.md).
 
@@ -62,7 +62,7 @@ For more details, see [Default project-creation level](../../group/index.md#defa
 By default, a project can be deleted by anyone with the **Owner** role, either at the project or
 group level.
 
-To ensure only admin users can delete projects:
+To ensure only Administrator users can delete projects:
 
 1. Check the **Default project deletion protection** checkbox.
 1. Click **Save changes**.
@@ -71,16 +71,16 @@ To ensure only admin users can delete projects:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32935) in GitLab 12.6.
 
-By default, a project marked for deletion will be permanently removed with immediate effect.
-By default, a group marked for deletion will be permanently removed after 7 days.
+By default, a project marked for deletion is permanently removed with immediate effect.
+By default, a group marked for deletion is permanently removed after seven days.
 
 WARNING:
 The default behavior of [Delayed Project deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/32935) in GitLab 12.6 was changed to
 [Immediate deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/220382) in GitLab 13.2.
 
-Projects within a group (but not a personal namespace) can be deleted after a delayed period, by [configuring in Group Settings](../../group/index.md#enabling-delayed-project-removal).
-
-The default period is 7 days, and can be changed. Setting this period to 0 will enable immediate removal
+Projects in a group (but not a personal namespace) can be deleted after a delayed period, by
+[configuring in Group Settings](../../group/index.md#enabling-delayed-project-removal).
+The default period is seven days, and can be changed. Setting this period to `0` enables immediate removal
 of projects or groups.
 
 To change this period:
@@ -149,13 +149,11 @@ For more details, see [Exporting a project and its data](../../../user/project/s
 
 ## Enabled Git access protocols
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/4696) in GitLab 8.10.
-
 With GitLab access restrictions, you can select with which protocols users can communicate with
 GitLab.
 
-Disabling an access protocol does not block access to the server itself via those ports. The ports
-used for the protocol, SSH or HTTP(S), will still be accessible. The GitLab restrictions apply at the
+Disabling an access protocol does not block access to the server itself by using those ports. The ports
+used for the protocol, SSH or HTTP(S), are still accessible. The GitLab restrictions apply at the
 application level.
 
 To specify the enabled Git access protocols:
@@ -170,26 +168,26 @@ When both SSH and HTTP(S) are enabled, users can choose either protocol.
 
 When only one protocol is enabled:
 
-- The project page will only show the allowed protocol's URL, with no option to
+- The project page shows only the allowed protocol's URL, with no option to
   change it.
-- A tooltip will be shown when you hover over the URL's protocol, if an action
-  on the user's part is required, e.g. adding an SSH key, or setting a password.
+- A tooltip is shown when you hover over the URL's protocol, if an action
+  on the user's part is required. For example, adding an SSH key or setting a password.
 
 ![Project URL with SSH only access](img/restricted_url.png)
 
-On top of these UI restrictions, GitLab will deny all Git actions on the protocol
+On top of these UI restrictions, GitLab denies all Git actions on the protocol
 not selected.
 
 WARNING:
-Starting with [GitLab 10.7](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18021),
-HTTP(S) protocol will be allowed for Git clone or fetch requests done by GitLab Runner
-from CI/CD jobs, even if _Only SSH_ was selected.
+GitLab versions [10.7 and later](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18021),
+allow the HTTP(S) protocol for Git clone or fetch requests done by GitLab Runner
+from CI/CD jobs, even if **Only SSH** was selected.
 
 ## Custom Git clone URL for HTTP(S)
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18422) in GitLab 12.4.
 
-You can customize project Git clone URLs for HTTP(S). This will affect the clone
+You can customize project Git clone URLs for HTTP(S), which affects the clone
 panel:
 
 ![Clone panel](img/clone_panel_v12_4.png)
@@ -225,10 +223,9 @@ For more details, see [SSH key restrictions](../../../security/ssh_keys_restrict
 
 ## Allow mirrors to be set up for projects
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3586) in GitLab 10.3.
-
-This option is enabled by default. By disabling it, both [pull and push mirroring](../../project/repository/repository_mirroring.md) will no longer
-work in every repository and can only be re-enabled by an admin on a per-project basis.
+This option is enabled by default. By disabling it, both
+[pull and push mirroring](../../project/repository/repository_mirroring.md) no longer
+work in every repository. They can only be re-enabled by an administrator user on a per-project basis.
 
 ![Mirror settings](img/mirror_settings.png)