Add latest changes from gitlab-org/gitlab@master

15 files changed, 61 insertions, 63 deletions

diff --git a/doc/integration/README.md b/doc/integration/README.md
index 25e8c1a51c1..acf37374c30 100644
--- a/doc/integration/README.md
+++ b/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:
 
diff --git a/doc/integration/facebook.md b/doc/integration/facebook.md
index bb699fa90b7..c53e81bf50b 100644
--- a/doc/integration/facebook.md
+++ b/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.
diff --git a/doc/integration/github.md b/doc/integration/github.md
index 8407920c631..b6a8de42beb 100644
--- a/doc/integration/github.md
+++ b/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
diff --git a/doc/integration/gitlab.md b/doc/integration/gitlab.md
index c618d226290..29d0fa02570 100644
--- a/doc/integration/gitlab.md
+++ b/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.
diff --git a/doc/integration/gmail_action_buttons_for_gitlab.md b/doc/integration/gmail_action_buttons_for_gitlab.md
index 72196fd0f52..fccb190d529 100644
--- a/doc/integration/gmail_action_buttons_for_gitlab.md
+++ b/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).
diff --git a/doc/integration/google.md b/doc/integration/google.md
index cd40aaff30a..c4607d6b9f2 100644
--- a/doc/integration/google.md
+++ b/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.
diff --git a/doc/integration/jenkins_deprecated.md b/doc/integration/jenkins_deprecated.md
index 63d5ac48765..d68923ed137 100644
--- a/doc/integration/jenkins_deprecated.md
+++ b/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.
diff --git a/doc/integration/oauth2_generic.md b/doc/integration/oauth2_generic.md
index 5957af292ab..cfa846decf8 100644
--- a/doc/integration/oauth2_generic.md
+++ b/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.
diff --git a/doc/integration/oauth_provider.md b/doc/integration/oauth_provider.md
index 68d10a3135e..0819e949915 100644
--- a/doc/integration/oauth_provider.md
+++ b/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)
diff --git a/doc/integration/omniauth.md b/doc/integration/omniauth.md
index eebafab2693..95d672ee89d 100644
--- a/doc/integration/omniauth.md
+++ b/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
diff --git a/doc/integration/salesforce.md b/doc/integration/salesforce.md
index 3290f18e2cb..4f4f9b3e3d1 100644
--- a/doc/integration/salesforce.md
+++ b/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.
diff --git a/doc/integration/shibboleth.md b/doc/integration/shibboleth.md
index 59374d8ad6f..d59ecca0b8d 100644
--- a/doc/integration/shibboleth.md
+++ b/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 />
diff --git a/doc/integration/slash_commands.md b/doc/integration/slash_commands.md
index ea2c4b3e93f..502475931b6 100644
--- a/doc/integration/slash_commands.md
+++ b/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.
diff --git a/doc/integration/trello_power_up.md b/doc/integration/trello_power_up.md
index 22481e14236..4ad9d2c2b3a 100644
--- a/doc/integration/trello_power_up.md
+++ b/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
diff --git a/doc/integration/twitter.md b/doc/integration/twitter.md
index bfe18c43e9d..507d2b965a4 100644
--- a/doc/integration/twitter.md
+++ b/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.