Fix login and signin grammar errors

Expand vale rule to catch known bad grammar for
login and signin, and fix all examples

doc/.vale/gitlab/Substitutions.yml

@@ -25,5 +25,13 @@ swap:
   self hosted: self-managed
   self-hosted: self-managed
   styleguide: style guide
+  to login: to log in
+  can login: can log in
+  to log-in: to log in
+  can log-in: can log in
+  to signin: to sign in
+  can signin: can sign in
+  to sign-in: to sign in
+  can sign-in: can sign in
   x509: X.509
   yaml: YAML

doc/administration/auth/crowd.md

@@ -82,6 +82,8 @@ If you see an error message like the one below when you sign in after Crowd auth
 could not authorize you from Crowd because invalid credentials
 ```
 
-Please make sure the Crowd users who need to login to GitLab are authorized to [the application](#configure-a-new-crowd-application) in the step of **Authorisation**. This could be verified by try "Authentication test" for Crowd as of 2.11.
+Ensure the Crowd users who need to sign in to GitLab are authorized to the
+[application](#configure-a-new-crowd-application) in the **Authorisation** step.
+This could be verified by trying "Authentication test" for Crowd (as of 2.11).
 
 ![Example Crowd application authorisation configuration](img/crowd_application_authorisation.png)

doc/administration/auth/ldap/index.md

@@ -97,7 +97,8 @@ library. `start_tls` corresponds to StartTLS, not to be confused with regular TL
 Normally, if you specify `simple_tls` it will be on port 636, while `start_tls` (StartTLS)
 would be on port 389. `plain` also operates on port 389. Removed values: `tls` was replaced with `start_tls` and `ssl` was replaced with `simple_tls`.
 
-LDAP users must have an email address set, regardless of whether it is used to sign-in.
+LDAP users must have a set email address, regardless of whether or not it's used
+to sign in.
 
 ### Example Configurations **(CORE ONLY)**
 
@@ -444,10 +445,10 @@ account control attribute (`userAccountControl:1.2.840.113556.1.4.803`)
 has bit 2 set.
 For more information, see <https://ctovswild.com/2009/09/03/bitmask-searches-in-ldap/>
 
-The user will be set to `ldap_blocked` state in GitLab if the above conditions
-fail. This means the user will not be able to sign-in or push/pull code.
+The user is set to an `ldap_blocked` state in GitLab if the previous conditions
+fail. This means the user won't be able to sign in or push/pull code.
 
-The process will also update the following user information:
+The process also updates the following user information:
 
 - Email address.
 - If `sync_ssh_keys` is set, SSH public keys.

doc/administration/auth/ldap/ldap-troubleshooting.md

@@ -103,16 +103,16 @@ A user can have trouble signing in for any number of reasons. To get started,
 here are some questions to ask yourself:
 
 - Does the user fall under the [configured `base`](index.md#configuration) in
-  LDAP? The user must fall under this `base` to sign-in.
+  LDAP? The user must fall under this `base` to sign in.
 - Does the user pass through the [configured `user_filter`](index.md#set-up-ldap-user-filter)?
   If one is not configured, this question can be ignored. If it is, then the
-  user must also pass through this filter to be allowed to sign-in.
+  user must also pass through this filter to be allowed to sign in.
   - Refer to our docs on [debugging the `user_filter`](#debug-ldap-user-filter).
 
 If the above are both okay, the next place to look for the problem is
 the logs themselves while reproducing the issue.
 
-- Ask the user to sign-in and let it fail.
+- Ask the user to sign in and let it fail.
 - [Look through the output](#gitlab-logs) for any errors or other
   messages about the sign-in. You may see one of the other error messages on
   this page, in which case that section can help resolve the issue.
@@ -159,7 +159,7 @@ The user should now be able to sign in.
 
 #### Email has already been taken
 
-A user tries to sign-in with the correct LDAP credentials, is denied access,
+A user tries to sign in with the correct LDAP credentials, is denied access,
 and the [production.log](../../logs.md#productionlog) shows an error that looks like this:
 
 ```plaintext

doc/administration/geo/replication/configuration.md

@@ -229,8 +229,8 @@ replicating missing data from the **primary** node in a process known as **backf
 Meanwhile, the **primary** node will start to notify each **secondary** node of any changes, so
 that the **secondary** node can act on those notifications immediately.
 
-Make sure the **secondary** node is running and accessible.
-You can login to the **secondary** node with the same credentials as used for the **primary** node.
+Be sure the _secondary_ node is running and accessible. You can sign in to the
+_secondary_ node with the same credentials as were used with the _primary_ node.
 
 ### Step 4. Enabling Hashed Storage
 
@@ -262,10 +262,10 @@ method to be enabled. Navigate to **Admin Area > Settings**
 
 Your **secondary** node is now configured!
 
-You can login to the **secondary** node with the same credentials you used for the
-**primary** node. Visit the **secondary** node's **Admin Area > Geo**
-(`/admin/geo/nodes`) in your browser to check if it's correctly identified as a
-**secondary** Geo node and if Geo is enabled.
+You can sign in to the _secondary_ node with the same credentials you used with
+the _primary_ node. Visit the _secondary_ node's **Admin Area > Geo**
+(`/admin/geo/nodes`) in your browser to determine if it's correctly identified
+as a _secondary_ Geo node, and if Geo is enabled.
 
 The initial replication, or 'backfill', will probably still be in progress. You
 can monitor the synchronization process on each Geo node from the **primary**

doc/administration/operations/fast_ssh_key_lookup.md

@@ -196,7 +196,8 @@ the database. The following instructions can be used to build OpenSSH 7.5:
    yes | cp pam-ssh-conf-$timestamp /etc/pam.d/sshd
    ```
 
-1. Verify the installed version. In another window, attempt to login to the server:
+1. Verify the installed version. In another window, attempt to sign in to the
+   server:
 
    ```shell
    ssh -v <your-centos-machine>
@@ -204,7 +205,7 @@ the database. The following instructions can be used to build OpenSSH 7.5:
 
    You should see a line that reads: "debug1: Remote protocol version 2.0, remote software version OpenSSH_7.5"
 
-   If not, you may need to restart `sshd` (e.g. `systemctl restart sshd.service`).
+   If not, you may need to restart `sshd` (for example, `systemctl restart sshd.service`).
 
 1. *IMPORTANT!* Open a new SSH session to your server before exiting to make
    sure everything is working! If you need to downgrade, simple install the

doc/administration/packages/container_registry.md

@@ -170,7 +170,7 @@ If your certificate provider provides the CA Bundle certificates, append them to
 1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
 1. Make the relevant changes in NGINX as well (domain, port, TLS certificates path).
 
-Users should now be able to login to the Container Registry with their GitLab
+Users should now be able to sign in to the Container Registry with their GitLab
 credentials using:
 
 ```shell
@@ -234,7 +234,7 @@ registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/certificate.key"
 1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
 1. Make the relevant changes in NGINX as well (domain, port, TLS certificates path).
 
-Users should now be able to login to the Container Registry using their GitLab
+Users should now be able to sign in to the Container Registry using their GitLab
 credentials:
 
 ```shell
@@ -1234,8 +1234,8 @@ This will launch the Docker daemon and proxy all connections through mitmproxy.
 
 #### Running the Docker client
 
-Now that we have mitmproxy and Docker running, we can attempt to login and push
-a container image. You may need to run as root to do this. For example:
+Now that we have mitmproxy and Docker running, we can attempt to sign in and
+push a container image. You may need to run as root to do this. For example:
 
 ```shell
 docker login s3-testing.myregistry.com:5050

doc/administration/postgresql/replication_and_failover.md

@@ -579,18 +579,19 @@ in the Troubleshooting section before proceeding.
 
 ### Ensure GitLab is running
 
-At this point, your GitLab instance should be up and running. Verify you are
-able to login, and create issues and merge requests. If you have troubles check
+At this point, your GitLab instance should be up and running. Verify you're able
+to sign in, and create issues and merge requests. If you encounter issues, see
 the [Troubleshooting section](#troubleshooting).
 
 ## Example configuration
 
-Here we'll show you some fully expanded example configurations.
+This section describes several fully expanded example configurations.
 
 ### Example recommended setup
 
-This example uses 3 Consul servers, 3 PgBouncer servers (with associated internal load balancer),
-3 PostgreSQL servers, and 1 application node.
+This example uses three Consul servers, three PgBouncer servers (with an
+associated internal load balancer), three PostgreSQL servers, and one
+application node.
 
 We start with all servers on the same 10.6.0.0/16 private network range, they
 can connect to each freely other on those addresses.

doc/ci/docker/using_docker_images.md

@@ -561,10 +561,11 @@ See below for examples of each.
 
 #### Determining your `DOCKER_AUTH_CONFIG` data
 
-As an example, let's assume that you want to use the `registry.example.com:5000/private/image:latest`
-image which is private and requires you to login into a private container registry.
+As an example, let's assume you want to use the `registry.example.com:5000/private/image:latest`
+image, which is private and requires you to sign in to a private container
+registry.
 
-Let's also assume that these are the login credentials:
+Let's also assume that these are the sign-in credentials:
 
 | Key      | Value                       |
 |:---------|:----------------------------|
@@ -572,9 +573,9 @@ Let's also assume that these are the login credentials:
 | username | `my_username`               |
 | password | `my_password`               |
 
-There are two ways to determine the value of `DOCKER_AUTH_CONFIG`:
+Use one of the following methods to determine the value of `DOCKER_AUTH_CONFIG`:
 
-- **First way -** Do a `docker login` on your local machine:
+- Do a `docker login` on your local machine:
 
   ```shell
   docker login registry.example.com:5000 --username my_username --password my_password
@@ -589,12 +590,11 @@ There are two ways to determine the value of `DOCKER_AUTH_CONFIG`:
   docker logout registry.example.com:5000
   ```
 
-- **Second way -** In some setups, it's possible that Docker client
-  uses the available system key store to store the result of `docker
-  login`. In that case, it's impossible to read `~/.docker/config.json`,
-  so you need to prepare the required base64-encoded version of
-  `${username}:${password}` and create the Docker configuration JSON manually.
-  Open a terminal and execute the following command:
+- In some setups, it's possible that Docker client uses the available system key
+  store to store the result of `docker login`. In that case, it's impossible to
+  read `~/.docker/config.json`, so you need to prepare the required
+  base64-encoded version of `${username}:${password}` and create the Docker
+  configuration JSON manually. Open a terminal and execute the following command:
 
   ```shell
   # The use of "-n" - prevents encoding a newline in the password.

doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md

@@ -103,27 +103,27 @@ Hub](https://hub.docker.com/). We've also added the [`only`
 clause](../../yaml/README.md#onlyexcept-basic)
 to ensure our deployments only happen when we push to the master branch.
 
-Now, since the steps defined in `.gitlab-ci.yml` require credentials to login
-to CF, you'll need to add your CF credentials as [environment
-variables](../../variables/README.md#predefined-environment-variables)
-on GitLab CI/CD. To set the environment variables, navigate to your project's
-**Settings > CI/CD** and expand **Variables**. Name the variables
+Because the steps defined in `.gitlab-ci.yml` require credentials to sign in to
+CF, you'll need to add your CF credentials as
+[environment variables](../../variables/README.md#predefined-environment-variables)
+in GitLab CI/CD. To set the environment variables, navigate to your project's
+**Settings > CI/CD**, and then expand **Variables**. Name the variables
 `CF_USERNAME` and `CF_PASSWORD` and set them to the correct values.
 
 ![Variable Settings in GitLab](img/cloud_foundry_variables.png)
 
-Once set up, GitLab CI/CD will deploy your app to CF at every push to your
-repository's default branch. To see the build logs or watch your builds running
-live, navigate to **CI/CD > Pipelines**.
+After set up, GitLab CI/CD deploys your app to CF at every push to your
+repository's default branch. To review the build logs or watch your builds
+running live, navigate to **CI/CD > Pipelines**.
 
 CAUTION: **Caution:**
-It is considered best practice for security to create a separate deploy
-user for your application and add its credentials to GitLab instead of using
-a developer's credentials.
+It's considered best practice for security to create a separate deploy user for
+your application and add its credentials to GitLab instead of using a
+developer's credentials.
 
 To start a manual deployment in GitLab go to **CI/CD > Pipelines** then click
-on **Run Pipeline**. After the app is finished deploying it will display the URL
-of your application in the logs for the `production` job like:
+on **Run Pipeline**. After the app is finished deploying, it will display the
+URL of your application in the logs for the `production` job like:
 
 ```shell
 requested state: started

doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md

@@ -238,7 +238,11 @@ run: ./services/tunnel_gitlab: (pid 2650) 10875s, normally down; run: log: (pid
 run: ./services/tunnel_registry: (pid 2651) 10875s, normally down; run: log: (pid 65155) 177993s
 ```
 
-Also, restarting Docker and then, on the Terminal, issue the command  `docker login https://[YOUR-REGISTRY-PORT].qa-tunnel.gitlab.info:443` and use the GDK credentials to login. Note that the Registry port and GDK port are not the same. When configuring Auto DevOps in GDK, the `gdk reconfigure` command outputs the port of the Registry:
+Also, restarting Docker and then, on the Terminal, issue the command
+`docker login https://[YOUR-REGISTRY-PORT].qa-tunnel.gitlab.info:443` and use
+the GDK credentials to sign in. Note that the Registry port and GDK port aren't
+the same. When configuring Auto DevOps in GDK, the `gdk reconfigure` command
+outputs the port of the Registry:
 
 ```shell
 *********************************************

doc/install/azure/index.md

@@ -347,8 +347,8 @@ connect to it using SSH ([Secure Shell](https://en.wikipedia.org/wiki/Secure_She
 If you're running Windows, you'll need to connect using [PuTTY](https://www.putty.org) or an equivalent Windows SSH client.
 If you're running Linux or macOS, then you already have an SSH client installed.
 
-Remember that you will need to login with the username and password you specified
-[when you created](#basics) your Azure VM.
+Remember to sign in with the username and password you specified when you
+[created your Azure VM](#basics).
 
 If you need to reset your VM password, read
 [how to reset SSH credentials for a user on an Azure VM](https://docs.microsoft.com/en-us/azure/virtual-machines/troubleshooting/troubleshoot-ssh-connection).
@@ -375,20 +375,20 @@ read on [using PuTTY in Windows](https://mediatemple.net/community/products/dv/2
 
 ### Updating GitLab
 
-Once you've logged in via SSH, enter the following command to update GitLab to the latest
-version:
+After signing in by using SSH, enter the following command to update GitLab to
+the latest version:
 
 ```shell
 sudo apt-get update && sudo apt-get install gitlab-ce
 ```
 
-This command will update GitLab and its associated components to the latest versions, so it will
-take a little time to complete. You'll see various update tasks being completed in your SSH
-terminal window:
+This command updates GitLab and its associated components to the latest versions,
+so it will take a little time to complete. You'll see various update tasks being
+completed in your SSH terminal window:
 
 ![GitLab updating](img/gitlab-ssh-update-in-progress.png)
 
-Once the update process has completed, you'll see a message like this:
+After the update process is complete, you'll see a message like this:
 
 ```plaintext
 Upgrade complete! If your GitLab server is misbehaving try running

doc/install/openshift_and_gitlab/index.md

@@ -183,9 +183,9 @@ Using the all-in-one VM gives you the ability to test OpenShift whenever you
 want. That means you get to play with it, shutdown the VM, and pick up where
 you left off.
 
-Sometimes though, you may encounter some issues, like OpenShift not running
-when booting up the VM. The web UI may not responding or you may see issues
-when trying to login with `oc`, like:
+Occasionally, you may encounter issues, like OpenShift not running when booting
+up the VM. The web UI may not respond, or you may see issues when trying to sign
+in with `oc`, like:
 
 ```plaintext
 The connection to the server 10.2.2.2:8443 was refused - did you specify the right host or port?
@@ -213,8 +213,7 @@ In that case, the OpenShift service might not be running, so in order to fix it:
    systemctl status openshift -l
    ```
 
-Now you will be able to login using `oc` (like we did before) and visit the web
-console.
+You can now sign in by using `oc` (like we did before) and visit the web console.
 
 ## Deploy GitLab
 
@@ -497,14 +496,13 @@ oc adm policy add-scc-to-user anyuid system:serviceaccount:gitlab:gitlab-ce-user
 
 ## Conclusion
 
-By now, you should have an understanding of the basic OpenShift Origin concepts
-and a sense of how things work using the web console or the CLI.
+You should now have an understanding of the basic OpenShift Origin concepts, and
+a sense of how things work using the web console or the CLI.
 
-GitLab was hard to install in previous versions of OpenShift,
-but now that belongs to the past. Upload a template, create a project, add an
-application and you are done. You are ready to login to your new GitLab instance.
+Upload a template, create a project, add an application, and you're done. You're
+ready to sign in to your new GitLab instance.
 
-And remember that in this tutorial we just scratched the surface of what Origin
-is capable of. As always, you can refer to the detailed
-[documentation](https://docs.okd.io) to learn more about deploying your own OpenShift
-PaaS and managing your applications with the ease of containers.
+Remember that this tutorial doesn't address all that Origin is capable of. As
+always, refer to the detailed [documentation](https://docs.okd.io) to learn more
+about deploying your own OpenShift PaaS and managing your applications with
+containers.

doc/integration/github.md

@@ -6,7 +6,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Integrate your GitLab instance with GitHub
 
-You can integrate your GitLab instance with GitHub.com as well as GitHub Enterprise to enable users to import projects from GitHub and/or to login to your GitLab instance with your GitHub account.
+You can integrate your GitLab instance with GitHub.com and GitHub Enterprise to
+enable users to import projects from GitHub or sign in to your GitLab instance
+with your GitHub account.
 
 ## Enabling GitHub OAuth
 
@@ -24,11 +26,11 @@ See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration)
 
 Once you have configured the GitHub provider, you'll need the following information, which you'll need to substitute in the GitLab configuration file, in the steps shown next.
 
-| Setting from GitHub  |  Substitute in the GitLab configuration file | Description |
-|:---------------------|:-----------------------------------------------|:------------|
-| Client ID            | `YOUR_APP_ID`     |  OAuth 2 Client ID     |
-| Client Secret        | `YOUR_APP_SECRET` |  OAuth 2 Client Secret |
-| URL                  | `https://github.example.com/` |  GitHub Deployment URL |
+| Setting from GitHub  | Substitute in the GitLab configuration file  | Description |
+|:---------------------|:---------------------------------------------|:------------|
+| Client ID            | `YOUR_APP_ID`                                | OAuth 2 Client ID |
+| Client Secret        | `YOUR_APP_SECRET`                            | OAuth 2 Client Secret |
+| URL                  | `https://github.example.com/`                | GitHub Deployment URL |
 
 Follow these steps to incorporate the GitHub OAuth 2 app in your GitLab server:
 

doc/integration/kerberos.md

@@ -96,18 +96,17 @@ to authenticate with Kerberos tokens.
 The Administrative user can navigate to **Admin > Users > Example User > Identities**
 and attach a Kerberos account. Existing GitLab users can go to **Profile > Account**
 and attach a Kerberos account. If you want to allow users without a GitLab
-account to login, you should enable the option `allow_single_sign_on` as
-described in the [Configure GitLab](#configure-gitlab) section. Then, the first
-time a user signs in with Kerberos credentials, GitLab will create a new GitLab
-user associated with the email, which is built from the Kerberos username and
-realm. User accounts will be created automatically when authentication was
-successful.
+account to sign in, enable the `allow_single_sign_on` option, as described in the
+[Configure GitLab](#configure-gitlab) section. The first time a user signs in
+with Kerberos credentials, GitLab will create a new GitLab user associated with
+the email, which is built from the Kerberos username and realm. User accounts are
+created after successful authentications.
 
 ## Linking Kerberos and LDAP accounts together
 
-If your users log in with Kerberos, but you also have [LDAP integration](../administration/auth/ldap/index.md)
-enabled, then your users will be automatically linked to their LDAP accounts on
-first login. For this to work, some prerequisites must be met:
+If your users sign in with Kerberos, but you also have [LDAP integration](../administration/auth/ldap/index.md)
+enabled, your users will be linked to their LDAP accounts on their first sign-in.
+For this to work, some prerequisites must be met:
 
 The Kerberos username must match the LDAP user's UID. You can choose which LDAP
 attribute is used as the UID in GitLab's [LDAP configuration](../administration/auth/ldap/index.md#configuration)
@@ -125,10 +124,10 @@ LDAP Distinguished Names look like `sAMAccountName=foo,dc=ad,dc=example,dc=com`.
 
 [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/9962) in GitLab 13.5.
 
-You can configure custom allowed realms when
-the user's Kerberos realm doesn't match the domain from the user's LDAP DN. The
-configuration value must specify all domains that users may be expected to
-have. Any other domains will be ignored and an LDAP identity will not be linked.
+You can configure custom allowed realms when the user's Kerberos realm doesn't
+match the domain from the user's LDAP DN. The configuration value must specify
+all domains that users may be expected to have. Any other domains will be
+ignored and an LDAP identity won't be linked.
 
 **For Omnibus installations**
 

doc/integration/omniauth.md

@@ -88,8 +88,8 @@ To change these settings:
 
   ```ruby
   # CAUTION!
-  # This allows users to login without having a user account first. Define the allowed providers
-  # using an array, e.g. ["saml", "twitter"], or as true/false to allow all providers or none.
+  # This allows users to sign in without having a user account first. Define the allowed providers
+  # using an array, for example, ["saml", "twitter"], or as true/false to allow all providers or none.
   # User accounts will be created automatically when authentication was successful.
   gitlab_rails['omniauth_allow_single_sign_on'] = ['saml', 'twitter']
   gitlab_rails['omniauth_auto_link_ldap_user'] = true
@@ -111,13 +111,13 @@ To change these settings:
   ```yaml
   ## OmniAuth settings
   omniauth:
-    # Allow login via Twitter, Google, etc. using OmniAuth providers
+    # Allow sign-in by using Twitter, Google, etc. using OmniAuth providers
     # Versions prior to 11.4 require this to be set to true
     # enabled: true
 
     # CAUTION!
-    # This allows users to login without having a user account first. Define the allowed providers
-    # using an array, e.g. ["saml", "twitter"], or as true/false to allow all providers or none.
+    # This allows users to sign in without having a user account first. Define the allowed providers
+    # using an array, for example, ["saml", "twitter"], or as true/false to allow all providers or none.
     # User accounts will be created automatically when authentication was successful.
     allow_single_sign_on: ["saml", "twitter"]
 
@@ -177,9 +177,9 @@ like `google_oauth2` for Google. Refer to the examples for the full names of the
 supported providers.
 
 NOTE: **Note:**
-If you decide to remove an OmniAuth provider from the external providers list
-you will need to manually update the users that use this method to login, if you
-want their accounts to be upgraded to full internal accounts.
+If you decide to remove an OmniAuth provider from the external providers list,
+you must manually update the users that use this method to sign in if you want
+their accounts to be upgraded to full internal accounts.
 
 **For Omnibus installations**
 
@@ -302,13 +302,13 @@ omniauth:
 
 ## Bypassing two factor authentication
 
-Starting with GitLab 12.3, this allows users to login with the specified
-providers without two factor authentication.
+In GitLab 12.3 or later, users can sign in with specified providers _without_
+using two factor authentication.
 
-Define the allowed providers using an array, e.g. `["twitter", 'google_oauth2']`, or as
-`true`/`false` to allow all providers or none. This option should only be configured
-for providers which already have two factor authentication (default: false).
-This configuration dose not apply to SAML.
+Define the allowed providers using an array (for example, `["twitter", 'google_oauth2']`),
+or as `true` or `false` to allow all providers (or none). This option should be
+configured only for providers which already have two factor authentication
+(default: false). This configuration doesn't apply to SAML.
 
 ```ruby
 gitlab_rails['omniauth_allow_bypass_two_factor'] = ['twitter', 'google_oauth2']
@@ -323,13 +323,12 @@ omniauth:
 
 ## Automatically sign in with provider
 
-You can add the `auto_sign_in_with_provider` setting to your
-GitLab configuration to automatically redirect login requests
-to your OmniAuth provider for authentication, thus removing the need to click a button
-before actually signing in.
+You can add the `auto_sign_in_with_provider` setting to your GitLab
+configuration to redirect login requests to your OmniAuth provider for
+authentication, removing the need to click a button before actually signing in.
 
-For example, when using the Azure integration, you would set the following
-to enable auto sign in.
+For example, when using the Azure integration, set the following to enable auto
+sign-in:
 
 For Omnibus package:
 
@@ -344,13 +343,15 @@ omniauth:
   auto_sign_in_with_provider: azure_oauth2
 ```
 
-Please keep in mind that every sign in attempt will be redirected to the OmniAuth provider,
-so you will not be able to sign in using local credentials. Make sure that at least one
-of the OmniAuth users has admin permissions.
+Keep in mind that every sign-in attempt will be redirected to the OmniAuth
+provider; you won't be able to sign in using local credentials. Ensure at least
+one of the OmniAuth users has admin permissions.
 
-You may also bypass the auto signin feature by browsing to
+You may also bypass the auto sign in feature by browsing to
 `https://gitlab.example.com/users/sign_in?auto_sign_in=false`.
 
 ## Passwords for users created via OmniAuth
 
-The [Generated passwords for users created through integrated authentication](../security/passwords_for_integrated_authentication_methods.md) guide provides an overview of how GitLab generates and sets passwords for users created via OmniAuth.
+The [Generated passwords for users created through integrated authentication](../security/passwords_for_integrated_authentication_methods.md)
+guide provides an overview about how GitLab generates and sets passwords for
+users created with OmniAuth.

doc/integration/saml.md

@@ -369,18 +369,18 @@ omniauth:
   auto_sign_in_with_provider: saml
 ```
 
-Please keep in mind that every sign in attempt will be redirected to the SAML server,
-so you will not be able to sign in using local credentials. Make sure that at least one
-of the SAML users has admin permissions.
+Keep in mind that every sign in attempt will be redirected to the SAML server;
+you won't be able to sign in using local credentials. Ensure at least one of the
+SAML users has admin permissions.
 
-You may also bypass the auto signin feature by browsing to
+You may also bypass the auto sign-in feature by browsing to
 `https://gitlab.example.com/users/sign_in?auto_sign_in=false`.
 
 ### `attribute_statements`
 
 NOTE: **Note:**
-This setting should only be used to map attributes that are part of the
-OmniAuth `info` hash schema.
+This setting should be used only to map attributes that are part of the OmniAuth
+`info` hash schema.
 
 `attribute_statements` is used to map Attribute Names in a SAMLResponse to entries
 in the OmniAuth [`info` hash](https://github.com/omniauth/omniauth/wiki/Auth-Hash-Schema#schema-10-and-later).
@@ -541,9 +541,14 @@ This integration uses the `certificate` and `private_key` settings for both asse
 
 ## Request signing (optional)
 
-Another optional configuration is to sign SAML authentication requests. GitLab SAML Requests uses the SAML redirect binding so this is not necessary, unlike the SAML POST binding where signing is required to prevent intermediaries tampering with the requests.
+Another optional configuration is to sign SAML authentication requests. GitLab
+SAML Requests use the SAML redirect binding, so this isn't necessary (unlike the
+SAML POST binding, where signing is required to prevent intermediaries from
+tampering with the requests).
 
-In order to sign, you need to create a private key and public certificate pair for your GitLab instance to use for SAML. The settings related to signing can be set in the `security` section of the configuration.
+To sign, you need to create a private key and public certificate pair for your
+GitLab instance to use for SAML. The settings for signing can be set in the
+`security` section of the configuration.
 
 For example:
 
@@ -648,13 +653,14 @@ If you only need a SAML provider for testing, a [quick start guide to start a Do
 
 ### 500 error after login
 
-If you see a "500 error" in GitLab when you are redirected back from the SAML sign in page,
-this likely indicates that GitLab could not get the email address for the SAML user.
+If you see a "500 error" in GitLab when you are redirected back from the SAML
+sign-in page, this likely indicates that GitLab couldn't get the email address
+for the SAML user.
 
-Make sure the IdP provides a claim containing the user's email address, using claim name
-`email` or `mail`.
+Ensure the IdP provides a claim containing the user's email address, using the
+claim name `email` or `mail`.
 
-### Redirect back to login screen with no evident error
+### Redirect back to the login screen with no evident error
 
 If after signing in into your SAML server you are redirected back to the sign in page and
 no error is displayed, check your `production.log` file. It will most likely contain the

doc/integration/vault.md

@@ -106,13 +106,17 @@ The following assumes you already have Vault installed and running.
    vault login -method=oidc port=8250 role=demo
    ```
 
-   Here is a short explanation of what this command does:
+   Here's a short explanation of what this command does:
 
-   1. In the **Write the OIDC Role Config** (step 4), we created a role called `demo`. We set `role=demo` so Vault knows which configuration we'd like to login in with.
+   1. In the **Write the OIDC Role Config** (step 4), we created a role called
+      `demo`. We set `role=demo` so Vault knows which configuration we'd like to
+      sign in with.
    1. To set Vault to use the `OIDC` sign-in method, we set `-method=oidc`.
-   1. To set the port that GitLab should redirect to, we set `port=8250` or another port number that matches the port given to GitLab when listing [Redirect URIs](https://www.vaultproject.io/docs/auth/jwt#redirect-uris).
+   1. To set the port that GitLab should redirect to, we set `port=8250` or
+      another port number that matches the port given to GitLab when listing
+      [Redirect URIs](https://www.vaultproject.io/docs/auth/jwt#redirect-uris).
 
-   Once you run the command above, it will present a link in the terminal.
+   After running the command, it will present a link in the terminal.
    Click the link in the terminal and a tab will open in the browser confirming you're signed into Vault via OIDC:
 
    ![Signed into Vault via OIDC](img/signed_into_vault_via_oidc_v12_6.png)

doc/security/reset_user_password.md

@@ -56,14 +56,15 @@ Don't forget to save the changes.
 user.save!
 ```
 
-Exit the console and try to login with your new password.
+Exit the console, and then try to sign in with your new password.
 
 NOTE: **Note:**
-Passwords can also be reset via the [Users API](../api/users.md#user-modification)
+You can also reset passwords by using the [Users API](../api/users.md#user-modification).
 
 ### Reset your root password
 
-The steps described above can also be used to reset the root password. But first, identify the root user, with an `id` of `1`. To do so, run the following command:
+The previously described steps can also be used to reset the root password. First,
+identify the root user, with an `id` of `1`. To do so, run the following command:
 
 ```shell
 user = User.where(id: 1).first

doc/security/two_factor_authentication.md

@@ -8,22 +8,22 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Enforce Two-factor Authentication (2FA)
 
 Two-factor Authentication (2FA) provides an additional level of security to your
-users' GitLab account. Once enabled, in addition to supplying their username and
-password to login, they'll be prompted for a code generated by an application on
-their phone.
+users' GitLab account. After being enabled, in addition to supplying their
+username and password to sign in, they'll be prompted for a code generated by an
+application on their phone.
 
 You can read more about it here:
 [Two-factor Authentication (2FA)](../user/profile/account/two_factor_authentication.md)
 
 ## Enforcing 2FA for all users
 
-Users on GitLab, can enable it without any admin's intervention. If you want to
-enforce everyone to set up 2FA, you can choose from two different ways:
+Users on GitLab can enable it without any administrator's intervention. If you
+want to enforce everyone to set up 2FA, you can choose from two different ways:
 
 - Enforce on next login.
 - Suggest on next login, but allow a grace period before enforcing.
 
-After the configured grace period has elapsed, users will be able to log in but
+After the configured grace period has elapsed, users will be able to sign in but
 won't be able to leave the 2FA configuration area at `/profile/two_factor_auth`.
 
 To enable 2FA for all users:
@@ -32,15 +32,17 @@ To enable 2FA for all users:
    (`/admin/application_settings/general`).
 1. Expand the **Sign-in restrictions** section, where you can configure both.
 
-If you want 2FA enforcement to take effect on next login, change the grace
-period to `0`.
+If you want 2FA enforcement to take effect during the next sign-in attempt,
+change the grace period to `0`.
 
 ## Enforcing 2FA for all users in a group
 
 If you want to enforce 2FA only for certain groups, you can:
 
-1. Enable it in the group's **Settings > General** page. Navigate to **Permissions, LFS, 2FA > Two-factor authentication**.
-You can then check the **Require all users in this group to setup Two-factor authentication** option.
+1. Enable it in the group's **Settings > General** page. Navigate to
+   **Permissions, LFS, 2FA > Two-factor authentication**. You can then select
+   the **Require all users in this group to setup Two-factor authentication**
+   option.
 1. You can also specify a grace period in the **Time before enforced** option.
 
 To change this setting, you need to be administrator or owner of the group.

doc/system_hooks/system_hooks.md

@@ -31,11 +31,18 @@ Your GitLab instance can perform HTTP POST requests on the following events:
 - `user_update_for_group`
 - `user_update_for_team`
 
-The triggers for most of these are self-explanatory, but `project_update` and `project_rename` deserve some clarification: `project_update` is fired any time an attribute of a project is changed (name, description, tags, etc.) *unless* the `path` attribute is also changed. In that case, a `project_rename` is triggered instead (so that, for instance, if all you care about is the repository URL, you can just listen for `project_rename`).
-
-`user_failed_login` is sent whenever a **blocked** user attempts to login and denied access.
-
-System hooks can be used, e.g. for logging or changing information in a LDAP server.
+The triggers for most of these are self-explanatory, but `project_update` and
+`project_rename` deserve some clarification: `project_update` is fired any time
+an attribute of a project is changed (including name, description, and tags)
+_unless_ the `path` attribute is also changed. In that case, a `project_rename`
+is triggered instead (so that, for instance, if all you care about is the
+repository URL, you can just listen for `project_rename`).
+
+`user_failed_login` is sent whenever a _blocked_ user attempts to sign in and is
+denied access.
+
+System hooks can be used, for example, for logging or changing information in an
+LDAP server.
 
 NOTE: **Note:**
 We follow the same structure and deprecations as [Webhooks](../user/project/integrations/webhooks.md)

doc/user/admin_area/settings/index.md

@@ -23,7 +23,7 @@ Access the default page for admin area settings by navigating to **Admin Area >
 | [Account and limit](account_and_limit_settings.md) **(STARTER)** | Set projects and maximum size limits, session duration, user options, and check feature availability for namespace plan. |
 | [Diff limits](../diff_limits.md) | Diff content limits. |
 | [Sign-up restrictions](sign_up_restrictions.md) | Configure the way a user creates a new account. |
-| [Sign in restrictions](sign_in_restrictions.md) | Set requirements for a user to sign-in. Enable mandatory two-factor authentication. |
+| [Sign in restrictions](sign_in_restrictions.md) | Set requirements for a user to sign in. Enable mandatory two-factor authentication. |
 | [Terms of Service and Privacy Policy](terms.md) | Include a Terms of Service agreement and Privacy Policy that all users must accept. |
 | [External Authentication](external_authorization.md#configuration) | External Classification Policy Authorization |
 | [Web terminal](../../../administration/integration/terminal.md#limiting-websocket-connection-time) | Set max session time for web terminal. |

doc/user/profile/account/two_factor_authentication.md

@@ -8,12 +8,13 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Two-factor authentication
 
 Two-factor authentication (2FA) provides an additional level of security to your
-GitLab account. Once enabled, in addition to supplying your username and
-password to login, you'll be prompted for a code generated by your one time password
-authenticator. For example, a password manager on one of your devices.
+GitLab account. After being enabled, in addition to supplying your username and
+password to sign in, you'll be prompted for a code generated by your one-time
+password authenticator (for example, a password manager on one of your devices).
 
-By enabling 2FA, the only way someone other than you can log into your account
-is to know your username and password *and* have access to your one time password secret.
+By enabling 2FA, the only way someone other than you can sign in to your account
+is to know your username and password _and_ have access to your one-time
+password secret.
 
 ## Overview
 
@@ -41,10 +42,10 @@ or a U2F / WebAuthn device.
 To enable 2FA:
 
 1. **In GitLab:**
-   1. Log in to your GitLab account.
+   1. Sign in to your GitLab account.
    1. Go to your [**Profile settings**](../index.md#profile-settings).
    1. Go to **Account**.
-   1. Click **Enable Two-factor Authentication**.
+   1. Select **Enable Two-factor Authentication**.
 1. **On your device (usually your phone):**
    1. Install a compatible application, like:
       - [Authenticator](https://mattrubin.me/authenticator/): open source app for iOS devices.
@@ -59,11 +60,11 @@ To enable 2FA:
 1. **In GitLab:**
    1. Enter the six-digit pin number from the entry on your device into the **Pin
       code** field.
-   1. Click **Submit**.
+   1. Select **Submit**.
 
 If the pin you entered was correct, you'll see a message indicating that
 two-factor authentication has been enabled, and you'll be presented with a list
-of [recovery codes](#recovery-codes). Make sure you download them and keep them
+of [recovery codes](#recovery-codes). Be sure to download them and keep them
 in a safe place.
 
 ### One-time password via FortiAuthenticator

doc/user/project/deploy_tokens/index.md

@@ -13,57 +13,61 @@ type: howto
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/29280) from **Settings > CI / CD** in GitLab 12.10.1.
 > - [Added package registry scopes](https://gitlab.com/gitlab-org/gitlab/-/issues/213566) in GitLab 13.0.
 
-Deploy tokens allow you to download (`git clone`) or push and pull packages and container registry images of a project without having a user and a password.
+Deploy tokens allow you to download (`git clone`) or push and pull packages and
+container registry images of a project without having a user and a password.
 
 Deploy tokens can be managed by [maintainers only](../../permissions.md).
 
-If you have a key pair, you might want to use [deploy keys](../../../ssh/README.md#deploy-keys) instead.
+If you have a key pair, you might want to use [deploy keys](../../../ssh/README.md#deploy-keys)
+instead.
 
 ## Creating a Deploy Token
 
-You can create as many deploy tokens as you like from the settings of your project. Alternatively, you can also create [group-scoped deploy tokens](#group-deploy-token).
+You can create as many deploy tokens as you need from the settings of your
+project. Alternatively, you can also create [group-scoped deploy tokens](#group-deploy-token).
 
-1. Log in to your GitLab account.
+1. Sign in to your GitLab account.
 1. Go to the project (or group) you want to create Deploy Tokens for.
 1. Go to **Settings > Repository**.
 1. Click on "Expand" on **Deploy Tokens** section.
 1. Choose a name, expiry date (optional), and username (optional) for the token.
 1. Choose the [desired scopes](#limiting-scopes-of-a-deploy-token).
-1. Click on **Create deploy token**.
-1. Save the deploy token somewhere safe. Once you leave or refresh
+1. Select **Create deploy token**.
+1. Save the deploy token somewhere safe. After you leave or refresh
    the page, **you won't be able to access it again**.
 
 ![Personal access tokens page](img/deploy_tokens.png)
 
 ## Deploy token expiration
 
-Deploy tokens expire on the date you define, at midnight UTC.
+Deploy tokens expire at midnight UTC on the date you define.
 
 ## Revoking a deploy token
 
-At any time, you can revoke any deploy token by just clicking the
-respective **Revoke** button under the 'Active deploy tokens' area.
+At any time, you can revoke any deploy token by just clicking the respective
+**Revoke** button under the 'Active deploy tokens' area.
 
 ## Limiting scopes of a deploy token
 
-Deploy tokens can be created with different scopes that allow various
-actions that a given token can perform. The available scopes are depicted in
-the following table along with GitLab version it was introduced in.
+Deploy tokens can be created with different scopes that allow various actions
+that a given token can perform. The available scopes are depicted in the
+following table along with GitLab version it was introduced in:
 
-| Scope | Description | Introduced in GitLab Version |
-| ----- | ----------- | ------ |
-| `read_repository` | Allows read-access to the repository through `git clone` | 10.7 |
-| `read_registry` | Allows read-access to [container registry](../../packages/container_registry/index.md) images if a project is private and authorization is required. | 10.7 |
-| `write_registry` | Allows write-access (push) to [container registry](../../packages/container_registry/index.md). | 12.10 |
-| `read_package_registry` | Allows read access to the package registry. | 13.0 |
+| Scope                    | Description | Introduced in GitLab Version |
+|--------------------------|-------------|------------------------------|
+| `read_repository`        | Allows read-access to the repository through `git clone` | 10.7 |
+| `read_registry`          | Allows read-access to [container registry](../../packages/container_registry/index.md) images if a project is private and authorization is required. | 10.7 |
+| `write_registry`         | Allows write-access (push) to [container registry](../../packages/container_registry/index.md). | 12.10 |
+| `read_package_registry`  | Allows read access to the package registry. | 13.0 |
 | `write_package_registry` | Allows write access to the package registry. | 13.0 |
 
 ## Deploy token custom username
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/29639) in GitLab 12.1.
 
-The default username format is `gitlab+deploy-token-#{n}`. Some tools or platforms may not support this format,
-in such case you can specify custom username to be used when creating the deploy token.
+The default username format is `gitlab+deploy-token-#{n}`. Some tools or
+platforms may not support this format; in this case you can specify a custom
+username to be used when creating the deploy token.
 
 ## Usage
 
@@ -87,13 +91,13 @@ To read the container registry images, you'll need to:
 
 1. Create a Deploy Token with `read_registry` as a scope.
 1. Take note of your `username` and `token`.
-1. Log in to GitLab’s Container Registry using the deploy token:
+1. Sign in to GitLab’s Container Registry using the deploy token:
 
 ```shell
 docker login -u <username> -p <deploy_token> registry.example.com
 ```
 
-Just replace `<username>` and `<deploy_token>` with the proper values. Then you can simply
+Replace `<username>` and `<deploy_token>` with the proper values. You can now
 pull images from your Container Registry.
 
 ### Push Container Registry images
@@ -104,13 +108,13 @@ To push the container registry images, you'll need to:
 
 1. Create a Deploy Token with `write_registry` as a scope.
 1. Take note of your `username` and `token`.
-1. Log in to GitLab’s Container Registry using the deploy token:
+1. Sign in to GitLab’s Container Registry using the deploy token:
 
    ```shell
    docker login -u <username> -p <deploy_token> registry.example.com
    ```
 
-Just replace `<username>` and `<deploy_token>` with the proper values. Then you can simply
+Replace `<username>` and `<deploy_token>` with the proper values. You can now
 push images to your Container Registry.
 
 ### Read or pull packages
@@ -121,7 +125,8 @@ To pull packages in the GitLab package registry, you'll need to:
 
 1. Create a Deploy Token with `read_package_registry` as a scope.
 1. Take note of your `username` and `token`.
-1. For the [package type of your choice](../../packages/index.md), follow the authentication instructions for deploy tokens.
+1. For the [package type of your choice](../../packages/index.md), follow the
+   authentication instructions for deploy tokens.
 
 ### Push or upload packages
 
@@ -131,7 +136,8 @@ To upload packages in the GitLab package registry, you'll need to:
 
 1. Create a Deploy Token with `write_package_registry` as a scope.
 1. Take note of your `username` and `token`.
-1. For the [package type of your choice](../../packages/index.md), follow the authentication instructions for deploy tokens.
+1. For the [package type of your choice](../../packages/index.md), follow the
+   authentication instructions for deploy tokens.
 
 ### Group Deploy Token
 
@@ -158,10 +164,10 @@ apply consistently when cloning the repository of related projects.
 
 There's a special case when it comes to Deploy Tokens. If a user creates one
 named `gitlab-deploy-token`, the username and token of the Deploy Token will be
-automatically exposed to the CI/CD jobs as environment variables: `CI_DEPLOY_USER` and
-`CI_DEPLOY_PASSWORD`, respectively.
+automatically exposed to the CI/CD jobs as environment variables: `CI_DEPLOY_USER`
+and `CI_DEPLOY_PASSWORD`, respectively.
 
-After you create the token, you can login to the Container Registry using
+After you create the token, you can sign in to the Container Registry by using
 those variables:
 
 ```shell
@@ -169,4 +175,7 @@ docker login -u $CI_DEPLOY_USER -p $CI_DEPLOY_PASSWORD $CI_REGISTRY
 ```
 
 NOTE: **Note:**
-The special handling for the `gitlab-deploy-token` deploy token is not currently implemented for group deploy tokens. For the deploy token to be available for CI/CD jobs, it must be created at the project level. See [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/214014) for details.
+The special handling for the `gitlab-deploy-token` deploy token is not currently
+implemented for group deploy tokens. For the deploy token to be available for
+CI/CD jobs, it must be created at the project level. For details, see
+[this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/214014).