Merge branch '284446-unassigned-pages-futuretense-1' into 'master'

Fix future-tense issues in unassigned pages

See merge request gitlab-org/gitlab!48170

doc/integration/README.md

@@ -64,7 +64,7 @@ Integration with services such as Campfire, Flowdock, HipChat, Pivotal Tracker,
 
 ### SSL certificate errors
 
-When trying to integrate GitLab with services that are using self-signed certificates, it is very likely that SSL certificate errors will occur in different parts of the application, most likely Sidekiq.
+When trying to integrate GitLab with services that are using self-signed certificates, it is very likely that SSL certificate errors occur in different parts of the application, most likely Sidekiq.
 
 There are two approaches you can take to solve this:
 

doc/integration/facebook.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Facebook OAuth2 OmniAuth Provider
 
-To enable the Facebook OmniAuth provider you must register your application with Facebook. Facebook will generate an app ID and secret key for you to use.
+To enable the Facebook OmniAuth provider you must register your application with Facebook. Facebook generates an app ID and secret key for you to use.
 
 1. Sign in to the [Facebook Developer Platform](https://developers.facebook.com/).
 
@@ -101,4 +101,4 @@ To enable the Facebook OmniAuth provider you must register your application with
 1. [Reconfigure](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart GitLab](../administration/restart_gitlab.md#installations-from-source) for the changes to take effect if you
    installed GitLab via Omnibus or from source respectively.
 
-On the sign in page there should now be a Facebook icon below the regular sign in form. Click the icon to begin the authentication process. Facebook will ask the user to sign in and authorize the GitLab application. If everything goes well the user will be returned to GitLab and will be signed in.
+On the sign in page there should now be a Facebook icon below the regular sign in form. Click the icon to begin the authentication process. Facebook asks the user to sign in and authorize the GitLab application. If everything goes well the user is returned to GitLab and signed in.

doc/integration/github.md

@@ -12,9 +12,9 @@ with your GitHub account.
 
 ## Enabling GitHub OAuth
 
-To enable the GitHub OmniAuth provider, you'll need an OAuth 2 Client ID and Client Secret from GitHub. To get these credentials, sign into GitHub and follow their procedure for [Creating an OAuth App](https://developer.github.com/apps/building-oauth-apps/creating-an-oauth-app/).
+To enable the GitHub OmniAuth provider, you need an OAuth 2 Client ID and Client Secret from GitHub. To get these credentials, sign into GitHub and follow their procedure for [Creating an OAuth App](https://developer.github.com/apps/building-oauth-apps/creating-an-oauth-app/).
 
-When you create an OAuth 2 app in GitHub, you'll need the following information:
+When you create an OAuth 2 app in GitHub, you need the following information:
 
 - The URL of your GitLab instance, such as `https://gitlab.example.com`.
 - The authorization callback URL; in this case, `https://gitlab.example.com/users/auth`. Include the port number if your GitLab instance uses a non-default port.
@@ -24,7 +24,7 @@ To prevent an [OAuth2 covert redirect](https://oauth.net/advisories/2014-1-cover
 
 See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
 
-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.
+After you have configured the GitHub provider, you need the following information, which you must substitute in the GitLab configuration file, in the steps shown next.
 
 | Setting from GitHub  | Substitute in the GitLab configuration file  | Description |
 |:---------------------|:---------------------------------------------|:------------|
@@ -101,12 +101,12 @@ Follow these steps to incorporate the GitHub OAuth 2 app in your GitLab server:
 
 1. Refresh the GitLab sign in page. You should now see a GitHub icon below the regular sign in form.
 
-1. Click the icon to begin the authentication process. GitHub will ask the user to sign in and authorize the GitLab application.
+1. Click the icon to begin the authentication process. GitHub asks the user to sign in and authorize the GitLab application.
 
 ## GitHub Enterprise with self-signed Certificate
 
 If you are attempting to import projects from GitHub Enterprise with a self-signed
-certificate and the imports are failing, you will need to disable SSL verification.
+certificate and the imports are failing, you must disable SSL verification.
 It should be disabled by adding `verify_ssl` to `false` in the provider configuration
 and changing the global Git `sslVerify` option to `false` in the GitLab server.
 
@@ -125,7 +125,7 @@ gitlab_rails['omniauth_providers'] = [
 ]
 ```
 
-You will also need to disable Git SSL verification on the server hosting GitLab.
+You must also disable Git SSL verification on the server hosting GitLab.
 
 ```ruby
 omnibus_gitconfig['system'] = { "http" => ["sslVerify = false"] }
@@ -142,7 +142,7 @@ For installation from source:
     args: { scope: 'user:email' } }
 ```
 
-You will also need to disable Git SSL verification on the server hosting GitLab.
+You must also disable Git SSL verification on the server hosting GitLab.
 
 ```shell
 git config --global http.sslVerify false

doc/integration/gitlab.md

@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 Import projects from GitLab.com and login to your GitLab instance with your GitLab.com account.
 
 To enable the GitLab.com OmniAuth provider you must register your application with GitLab.com.
-GitLab.com will generate an application ID and secret key for you to use.
+GitLab.com generates an application ID and secret key for you to use.
 
 1. Sign in to GitLab.com
 
@@ -85,5 +85,5 @@ GitLab.com will generate an application ID and secret key for you to use.
    installed GitLab via Omnibus or from source respectively.
 
 On the sign in page there should now be a GitLab.com icon below the regular sign in form.
-Click the icon to begin the authentication process. GitLab.com will ask the user to sign in and authorize the GitLab application.
-If everything goes well the user will be returned to your GitLab instance and will be signed in.
+Click the icon to begin the authentication process. GitLab.com asks the user to sign in and authorize the GitLab application.
+If everything goes well the user is returned to your GitLab instance and is signed in.

doc/integration/gmail_action_buttons_for_gitlab.md

@@ -8,15 +8,14 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 GitLab supports [Google actions in email](https://developers.google.com/gmail/markup/actions/actions-overview).
 
-If correctly set up, emails that require an action will be marked in Gmail.
+If correctly set up, emails that require an action are marked in Gmail.
 
 ![gmail_actions_button.png](img/gmail_action_buttons_for_gitlab.png)
 
 To get this functioning, you need to be registered with Google. For instructions, see
 [Register with Google](https://developers.google.com/gmail/markup/registering-with-google).
 
-*This process has a lot of steps so make sure that you fulfill all requirements set by Google.*
-*Your application will be rejected by Google if you fail to do so.*
+*This process has a lot of steps so make sure that you fulfill all requirements set by Google to avoid your application being rejected by Google.*
 
 In particular, note:
 
@@ -25,6 +24,6 @@ In particular, note:
     (order of hundred emails a day minimum to Gmail) for a few weeks at least".
   - Have a very low rate of spam complaints from users.
 - Emails must be authenticated via DKIM or SPF.
-- Before sending the final form ("Gmail Schema Whitelist Request"), you must send a real email from your production server. This means that you will have to find a way to send this email from the email address you are registering. You can do this by, for example, forwarding the real email from the email address you are registering or going into the rails console on the GitLab server and triggering the email sending from there.
+- Before sending the final form ("Gmail Schema Whitelist Request"), you must send a real email from your production server. This means that you must find a way to send this email from the email address you are registering. You can do this by, for example, forwarding the real email from the email address you are registering or going into the rails console on the GitLab server and triggering the email sending from there.
 
 You can check how it looks going through all the steps laid out in the "Registering with Google" doc in [this GitLab.com issue](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/1517).

doc/integration/google.md

@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Google OAuth2 OmniAuth Provider
 
 To enable the Google OAuth2 OmniAuth provider you must register your application
-with Google. Google will generate a client ID and secret key for you to use.
+with Google. Google generates a client ID and secret key for you to use.
 
 ## Enabling Google OAuth
 
@@ -40,7 +40,7 @@ In Google's side:
      ```
 
 1. You should now be able to see a Client ID and Client secret. Note them down
-   or keep this page open as you will need them later.
+   or keep this page open as you need them later.
 1. To enable projects to access [Google Kubernetes Engine](../user/project/clusters/index.md), you must also
    enable these APIs:
    - Google Kubernetes Engine API
@@ -98,7 +98,7 @@ On your GitLab server:
 
 1. Change `YOUR_APP_ID` to the client ID from the Google Developer page
 1. Similarly, change `YOUR_APP_SECRET` to the client secret
-1. Make sure that you configure GitLab to use an FQDN as Google will not accept
+1. Make sure that you configure GitLab to use a fully-qualified domain name, as Google doesn't accept
    raw IP addresses.
 
    For Omnibus packages:
@@ -119,6 +119,6 @@ On your GitLab server:
    installed GitLab via Omnibus or from source respectively.
 
 On the sign in page there should now be a Google icon below the regular sign in
-form. Click the icon to begin the authentication process. Google will ask the
+form. Click the icon to begin the authentication process. Google asks the
 user to sign in and authorize the GitLab application. If everything goes well
-the user will be returned to GitLab and will be signed in.
+the user is returned to GitLab and is signed in.

doc/integration/jenkins_deprecated.md

@@ -41,7 +41,7 @@ In GitLab, perform the following steps.
 
 Jenkins needs read access to the GitLab repository. We already specified a
 private key to use in Jenkins, now we need to add a public one to the GitLab
-project. For that case we will need a Deploy key. Read the documentation on
+project. For that case we need a Deploy key. Read the documentation on
 [how to set up a Deploy key](../ssh/README.md#deploy-keys).
 
 ### Jenkins service
@@ -50,14 +50,13 @@ Now navigate to GitLab services page and activate Jenkins
 
 ![screen](img/jenkins_gitlab_service.png)
 
-Done! Now when you push to GitLab - it will create a build for Jenkins.
-And also you will be able to see merge request build status with a link to the Jenkins build.
+Done! Now when you push to GitLab - it creates a build for Jenkins, and you can view the merge request build status with a link to the Jenkins build.
 
 ### Multi-project Configuration
 
 The GitLab Hook plugin in Jenkins supports the automatic creation of a project
-for each feature branch. After configuration GitLab will trigger feature branch
-builds and a corresponding project will be created in Jenkins.
+for each feature branch. After configuration GitLab triggers feature branch
+builds and a corresponding project is created in Jenkins.
 
 Configure the GitLab Hook plugin in Jenkins. Go to 'Manage Jenkins' and then
 'Configure System'. Find the 'GitLab Web Hook' section and configure as shown below.

doc/integration/oauth2_generic.md

@@ -20,7 +20,7 @@ This strategy is designed to allow configuration of the simple OmniAuth SSO proc
 
 ## Limitations of this Strategy
 
-- It can only be used for Single Sign on, and will not provide any other access granted by any OAuth provider
+- It can only be used for Single Sign on, and doesn't provide any other access granted by any OAuth provider
   (importing projects or users, etc)
 - It only supports the Authorization Grant flow (most common for client-server applications, like GitLab)
 - It is not able to fetch user information from more than one URL
@@ -37,7 +37,7 @@ This strategy is designed to allow configuration of the simple OmniAuth SSO proc
    ```
 
 1. You should now be able to get a Client ID and Client Secret.
-   Where this shows up will differ for each provider.
+   Where this shows up differs for each provider.
    This may also be called Application ID and Secret
 
 1. On your GitLab server, open the configuration file.
@@ -64,6 +64,6 @@ This strategy is designed to allow configuration of the simple OmniAuth SSO proc
 1. Restart GitLab for the changes to take effect
 
 On the sign in page there should now be a new button below the regular sign in form.
-Click the button to begin your provider's authentication process. This will direct
+Click the button to begin your provider's authentication process. This directs
 the browser to your OAuth2 Provider's authentication page. If everything goes well
-the user will be returned to your GitLab instance and will be signed in.
+the user is returned to your GitLab instance and is signed in.

doc/integration/oauth_provider.md

@@ -48,12 +48,12 @@ In order to add a new application via your profile, navigate to
 ![New OAuth application](img/oauth_provider_user_wide_applications.png)
 
 In the application form, enter a **Name** (arbitrary), and make sure to set up
-correctly the **Redirect URI** which is the URL where users will be sent after
+correctly the **Redirect URI** which is the URL where users are sent after
 they authorize with GitLab.
 
 ![New OAuth application form](img/oauth_provider_application_form.png)
 
-When you hit **Submit** you will be provided with the application ID and
+When you click **Submit** you are provided with the application ID and
 the application secret which you can then use with your application that
 connects to GitLab.
 
@@ -71,7 +71,7 @@ the user authorization step is automatically skipped for this application.
 
 ## Authorized applications
 
-Every application you authorized to use your GitLab credentials will be shown
+Every application you authorized to use your GitLab credentials is shown
 in the **Authorized applications** section under **Profile Settings > Applications**.
 
 ![Authorized_applications](img/oauth_provider_authorized_application.png)

doc/integration/omniauth.md

@@ -51,23 +51,23 @@ that are in common for all providers that we need to consider.
 
 NOTE: **Note:**
 Starting from GitLab 11.4, OmniAuth is enabled by default. If you're using an
-earlier version, you'll need to explicitly enable it.
+earlier version, you must explicitly enable it.
 
 - `allow_single_sign_on` allows you to specify the providers you want to allow to
   automatically create an account. It defaults to `false`. If `false` users must
-  be created manually or they will not be able to sign in via OmniAuth.
+  be created manually or they can't sign in via OmniAuth.
 - `auto_link_ldap_user` can be used if you have [LDAP / ActiveDirectory](../administration/auth/ldap/index.md)
   integration enabled. It defaults to `false`. When enabled, users automatically
-  created through an OmniAuth provider will have their LDAP identity created in GitLab as well.
+  created through an OmniAuth provider have their LDAP identity created in GitLab as well.
 - `block_auto_created_users` defaults to `true`. If `true` auto created users will
-  be blocked by default and will have to be unblocked by an administrator before
+  be blocked by default and must be unblocked by an administrator before
   they are able to sign in.
 
 NOTE: **Note:**
 If you set `block_auto_created_users` to `false`, make sure to only
 define providers under `allow_single_sign_on` that you are able to control, like
 SAML, Shibboleth, Crowd or Google, or set it to `false` otherwise any user on
-the Internet will be able to successfully sign in to your GitLab without
+the Internet can successfully sign in to your GitLab without
 administrative approval.
 
 NOTE: **Note:**
@@ -141,8 +141,8 @@ OmniAuth provider for an existing user.
 1. Go to profile settings (the silhouette icon in the top right corner).
 1. Select the "Account" tab.
 1. Under "Connected Accounts" select the desired OmniAuth provider, such as Twitter.
-1. The user will be redirected to the provider. Once the user authorized GitLab
-   they will be redirected back to GitLab.
+1. The user is redirected to the provider. After the user authorizes GitLab,
+   they are redirected back to GitLab.
 
 The chosen OmniAuth provider is now active and can be used to sign in to GitLab from then on.
 
@@ -171,8 +171,8 @@ omniauth:
 > Introduced in GitLab 8.7.
 
 You can define which OmniAuth providers you want to be `external` so that all users
-**creating accounts, or logging in via these providers** will not be able to have
-access to internal projects. You will need to use the full name of the provider,
+**creating accounts, or logging in via these providers** can't have
+access to internal projects. You must use the full name of the provider,
 like `google_oauth2` for Google. Refer to the examples for the full names of the
 supported providers.
 
@@ -206,7 +206,7 @@ these cases you can use the OmniAuth provider.
 
 ### Steps
 
-These steps are fairly general and you will need to figure out the exact details
+These steps are fairly general and you must figure out the exact details
 from the OmniAuth provider's documentation.
 
 - Stop GitLab:
@@ -343,8 +343,8 @@ omniauth:
   auto_sign_in_with_provider: azure_oauth2
 ```
 
-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
+Keep in mind that every sign-in attempt is redirected to the OmniAuth
+provider; you can't sign in using local credentials. Ensure at least
 one of the OmniAuth users has admin permissions.
 
 You may also bypass the auto sign in feature by browsing to

doc/integration/salesforce.md

@@ -82,8 +82,8 @@ To get the credentials (a pair of Client ID and Client Secret), you must [create
 1. [Reconfigure GitLab]( ../administration/restart_gitlab.md#omnibus-gitlab-reconfigure ) or [restart GitLab]( ../administration/restart_gitlab.md#installations-from-source ) for the changes to take effect if you installed GitLab via Omnibus or from source respectively.
 
 On the sign in page, there should now be a Salesforce icon below the regular sign in form.
-Click the icon to begin the authentication process. Salesforce will ask the user to sign in and authorize the GitLab application.
-If everything goes well, the user will be returned to GitLab and will be signed in.
+Click the icon to begin the authentication process. Salesforce asks the user to sign in and authorize the GitLab application.
+If everything goes well, the user is returned to GitLab and is signed in.
 
 NOTE: **Note:**
-GitLab requires the email address of each new user. Once the user is logged in using Salesforce, GitLab will redirect the user to the profile page where they will have to provide the email and verify the email.
+GitLab requires the email address of each new user. Once the user is logged in using Salesforce, GitLab redirects the user to the profile page where they must provide the email and verify the email.

doc/integration/shibboleth.md

@@ -54,10 +54,10 @@ The following changes are needed to enable Shibboleth:
 
    NOTE: **Note:**
    Starting from GitLab 11.4, OmniAuth is enabled by default. If you're using an
-   earlier version, you'll need to explicitly enable it in `/etc/gitlab/gitlab.rb`.
+   earlier version, you must explicitly enable it in `/etc/gitlab/gitlab.rb`.
 
 1. In addition, add Shibboleth to `/etc/gitlab/gitlab.rb` as an OmniAuth provider.
-   User attributes will be sent from the
+   User attributes are sent from the
    Apache reverse proxy to GitLab as headers with the names from the Shibboleth
    attribute mapping. Therefore the values of the `args` hash
    should be in the form of `"HTTP_ATTRIBUTE"`. The keys in the hash are arguments
@@ -100,12 +100,12 @@ The following changes are needed to enable Shibboleth:
 1. [Reconfigure](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart](../administration/restart_gitlab.md#installations-from-source) GitLab for the changes to take effect if you
    installed GitLab via Omnibus or from source respectively.
 
-On the sign in page, there should now be a "Sign in with: Shibboleth" icon below the regular sign in form. Click the icon to begin the authentication process. You will be redirected to IdP server (depends on your Shibboleth module configuration). If everything goes well the user will be returned to GitLab and will be signed in.
+On the sign in page, there should now be a "Sign in with: Shibboleth" icon below the regular sign in form. Click the icon to begin the authentication process. You are redirected to IdP server (depends on your Shibboleth module configuration). If everything goes well the user is returned to GitLab and is signed in.
 
 ## Apache 2.4 / GitLab 8.6 update
 
 The order of the first 2 Location directives is important. If they are reversed,
-you will not get a Shibboleth session!
+requesting a Shibboleth session fails!
 
 ```plaintext
 <Location />

doc/integration/slash_commands.md

@@ -37,11 +37,11 @@ It is possible to create new issue, display issue details and search up to 5 iss
 
 ## Deploy command
 
-In order to deploy to an environment, GitLab will try to find a deployment
+In order to deploy to an environment, GitLab tries to find a deployment
 manual action in the pipeline.
 
-If there is only one action for a given environment, it is going to be triggered.
-If there is more than one action defined, GitLab will try to find an action
+If there is only one action for a given environment, it is triggered.
+If there is more than one action defined, GitLab tries to find an action
 which name equals the environment name we want to deploy to.
 
-Command will return an error when no matching action has been found.
+The command returns an error when no matching action has been found.

doc/integration/trello_power_up.md

@@ -13,7 +13,7 @@ GitLab **merge requests** to Trello cards.
 
 ## Configuring the Power-Up
 
-In order to get started, you will need to configure your Power-Up.
+In order to get started, you must configure your Power-Up.
 
 In Trello:
 
@@ -23,19 +23,19 @@ In Trello:
 1. Select the `Settings` (gear) icon
 1. In the popup menu, select `Authorize Account`
 
-In this popup, fill in your `API URL` and `Personal Access Token`. After that, you will be able to attach any merge request to any Trello card on your selected Trello board.
+In this popup, fill in your `API URL` and `Personal Access Token`. After that, you can attach any merge request to any Trello card on your selected Trello board.
 
 ## What is my API URL?
 
 Your API URL should be your GitLab instance URL with `/api/v4` appended in the end of the URL.
 For example, if your GitLab instance URL is `https://gitlab.com`, your API URL would be `https://gitlab.com/api/v4`.
-If your instance's URL is `https://example.com`, your API URL will be `https://example.com/api/v4`.
+If your instance's URL is `https://example.com`, your API URL is `https://example.com/api/v4`.
 
 ![configure GitLab Trello PowerUp in Trello](img/enable_trello_powerup.png)
 
 ## What is my Personal Access Token?
 
-Your GitLab's personal access token will enable your GitLab account to be accessed
+Your GitLab's personal access token enables your GitLab account to be accessed
 from Trello.
 
 > Find it in GitLab by clicking on your avatar (upright corner), from which you access

doc/integration/twitter.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Twitter OAuth2 OmniAuth Provider
 
-To enable the Twitter OmniAuth provider you must register your application with Twitter. Twitter will generate a client ID and secret key for you to use.
+To enable the Twitter OmniAuth provider you must register your application with Twitter. Twitter generates a client ID and secret key for you to use.
 
 1. Sign in to [Twitter Application Management](https://developer.twitter.com/apps).
 
@@ -85,4 +85,4 @@ To enable the Twitter OmniAuth provider you must register your application with
 1. [Reconfigure](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart GitLab](../administration/restart_gitlab.md#installations-from-source) for the changes to take effect if you
    installed GitLab via Omnibus or from source respectively.
 
-On the sign in page there should now be a Twitter icon below the regular sign in form. Click the icon to begin the authentication process. Twitter will ask the user to sign in and authorize the GitLab application. If everything goes well the user will be returned to GitLab and will be signed in.
+On the sign in page there should now be a Twitter icon below the regular sign in form. Click the icon to begin the authentication process. Twitter asks the user to sign in and authorize the GitLab application. If everything goes well the user is returned to GitLab and signed in.

doc/user/admin_area/settings/help_page.md

@@ -13,7 +13,7 @@ to go for help. You can customize and display this information on the GitLab ser
 
 ## Adding a help message to the help page
 
-You can add a help message, which will be shown on the GitLab `/help` page (e.g.,
+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**.
@@ -27,7 +27,7 @@ You can add a help message, which will be shown on the GitLab `/help` page (e.g.
 
 ## Adding a help message to the login page **(STARTER)**
 
-You can add a help message, which will be shown on the GitLab login page in a new section
+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**.

doc/user/admin_area/settings/rate_limits_on_raw_endpoints.md

@@ -12,7 +12,7 @@ type: reference
 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**.
 
-For example, requests over `300` per minute to `https://gitlab.com/gitlab-org/gitlab-foss/raw/master/app/controllers/application_controller.rb` will be blocked. Access to the raw file will be released after 1 minute.
+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.
 
 ![Rate limits on raw endpoints](img/rate_limits_on_raw_endpoints.png)
 

doc/user/admin_area/settings/sign_in_restrictions.md

@@ -25,9 +25,9 @@ You can restrict the password authentication for web interface and Git over HTTP
 
 ## Two-factor authentication
 
-When this feature enabled, all users will have to use the [two-factor authentication](../../profile/account/two_factor_authentication.md).
+When this feature enabled, all users must use the [two-factor authentication](../../profile/account/two_factor_authentication.md).
 
-Once the two-factor authentication is configured as mandatory, the users will be allowed
+Once the two-factor authentication is configured as mandatory, the users are allowed
 to skip forced configuration of two-factor authentication for the configurable grace
 period in hours.
 
@@ -44,13 +44,13 @@ see [Email notification for unknown sign-ins](../../profile/unknown_sign_in_noti
 
 ## Sign-in information
 
-All users that are not logged-in will be redirected to the page represented by the configured
-"Home page URL" if value is not empty.
+All users that are not logged in are redirected to the page represented by the configured
+**Home page URL** if value is not empty.
 
-All users will be redirect to the page represented by the configured "After sign out path"
+All users are redirected to the page represented by the configured **After sign out path**
 after sign out if value is not empty.
 
-In the Sign-in restrictions section, scroll to the "Sign-in text" text box. You can add a
+In the **Sign-in restrictions** section, scroll to the **Sign-in text** field. You can add a
 custom message for your users in Markdown format.
 
 For example, if you include the following information in the noted text box:
@@ -61,7 +61,7 @@ For example, if you include the following information in the noted text box:
 To access this text box, navigate to Admin Area > Settings > General, and expand the "Sign-in restrictions" section.
 ```
 
-Your users will see the "Custom sign-in text" when they navigate to the sign-in screen for your
+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)

doc/user/admin_area/settings/usage_statistics.md

@@ -7,7 +7,7 @@ type: reference
 
 # Usage statistics **(CORE ONLY)**
 
-GitLab Inc. will periodically collect information about your instance in order
+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
@@ -22,7 +22,7 @@ If your GitLab instance is behind a proxy, set the appropriate [proxy configurat
 
 ## Version Check **(CORE ONLY)**
 
-If enabled, version check will inform you if a new version is available and the
+If enabled, version check informs you if a new version is available and the
 importance of it through a status. This is shown on the help page (i.e. `/help`)
 for all signed in users, and on the admin pages. The statuses are:
 
@@ -37,10 +37,10 @@ GitLab Inc. collects your instance's version and hostname (through the HTTP
 referer) as part of the version check. No other information is collected.
 
 This information is used, among other things, to identify to which versions
-patches will need to be backported, making sure active GitLab instances remain
+patches must be backported, making sure active GitLab instances remain
 secure.
 
-If you disable version check, this information will not be collected. Enable or
+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**.
 
 ### Request flow example
@@ -65,8 +65,8 @@ See [Usage Ping guide](../../../development/product_analytics/usage_ping.md).
 
 ## Instance-level statistics **(CORE ONLY)**
 
-Once usage ping is enabled, GitLab will gather data from other instances and
-will be able to show [usage statistics](../analytics/index.md)
+After usage ping is enabled, GitLab gathers data from other instances and
+can show [usage statistics](../analytics/index.md)
 of your instance to your admins in **Admin Area > Analytics**.
 
 <!-- ## Troubleshooting

doc/user/admin_area/settings/user_and_ip_rate_limits.md

@@ -53,7 +53,7 @@ users to not set that header and bypass the GitLab rate limiter.
 Note that the bypass only works if the header is set to `1`.
 
 Requests that bypassed the rate limiter because of the bypass header
-will be marked with `"throttle_safelist":"throttle_bypass_header"` in
+are marked with `"throttle_safelist":"throttle_bypass_header"` in
 [`production_json.log`](../../../administration/logs.md#production_jsonlog).
 
 To disable the bypass mechanism, make sure the environment variable