Reduce Vale warnings in Create docset

Reduce Vale warnings on Create docs in the integration directory.

doc/integration/README.md

@@ -25,7 +25,7 @@ GitLab can be configured to authenticate access requests with the following auth
 - Enable sign in via [LDAP](../administration/auth/ldap/index.md).
 - Enable [OAuth2 provider](oauth_provider.md) application creation.
 - Use [OmniAuth](omniauth.md) to enable sign in via Twitter, GitHub, GitLab.com, Google,
-  Bitbucket, Facebook, Shibboleth, SAML, Crowd, Azure or Authentiq ID.
+  Bitbucket, Facebook, Shibboleth, SAML, Crowd, Azure, or Authentiq ID.
 - Use GitLab as an [OpenID Connect](openid_connect_provider.md) identity provider.
 - Authenticate to [Vault](vault.md) through GitLab OpenID Connect.
 - Configure GitLab as a [SAML](saml.md) 2.0 Service Provider.

doc/integration/bitbucket.md

@@ -10,8 +10,8 @@ NOTE:
 Starting from GitLab 11.4, OmniAuth is enabled by default. If you're using an
 earlier version, you must explicitly enable it.
 
-You can set up Bitbucket.org as an OAuth2 provider so that you can use your
-Bitbucket.org account credentials to sign into GitLab or import your projects from
+You can set up Bitbucket.org as an OAuth2 provider to use your
+Bitbucket.org account credentials to sign in to GitLab, or import your projects from
 Bitbucket.org.
 
 - To use Bitbucket.org as an OmniAuth provider, follow the

doc/integration/github.md

@@ -6,9 +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 and GitHub Enterprise to
-enable users to import projects from GitHub or sign in to your GitLab instance
-with your GitHub account.
+You can integrate your GitLab instance with GitHub.com and GitHub Enterprise. This integration
+enables users to import projects from GitHub, or sign in to your GitLab instance
+with their GitHub account.
 
 ## Enabling GitHub OAuth
 
@@ -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.
 
-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.
+After you have configured the GitHub provider, you need the following information. You must substitute that information in the GitLab configuration file in these next steps.
 
 | Setting from GitHub  | Substitute in the GitLab configuration file  | Description |
 |:---------------------|:---------------------------------------------|:------------|

doc/integration/gitlab.md

@@ -11,7 +11,7 @@ Import projects from GitLab.com and login to your GitLab instance with your GitL
 To enable the GitLab.com OmniAuth provider you must register your application with GitLab.com.
 GitLab.com generates an application ID and secret key for you to use.
 
-1. Sign in to GitLab.com
+1. Sign in to GitLab.com.
 
 1. On the upper right corner, click on your avatar and go to your **Settings**.
 

doc/integration/gmail_action_buttons_for_gitlab.md

@@ -24,6 +24,11 @@ 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 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.
+- 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 forwarding the real email from the email address you are
+  registering. You can also go into the Rails console on the GitLab server and
+  trigger sending the email 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/jenkins.md

@@ -64,7 +64,7 @@ Grant a GitLab user access to the select GitLab projects.
 1. Grant the user permission to the GitLab projects.
 
    If you're integrating Jenkins with many GitLab projects, consider granting the user global
-   Admin permission. Otherwise, add the user to each project, and grant Developer permission.
+   Administrator permission. Otherwise, add the user to each project, and grant Developer permission.
 
 ## Configure GitLab API access
 
@@ -166,7 +166,7 @@ to integrate GitLab and Jenkins.
 1. In the configuration of your Jenkins job, in the GitLab configuration section, click **Advanced**.
 1. Click the **Generate** button under the **Secret Token** field.
 1. Copy the resulting token, and save the job configuration.
-1. In GitLab, create a webhook for your project, enter the trigger URL (e.g. `https://JENKINS_URL/project/YOUR_JOB`) and paste the token in the **Secret Token** field.
+1. In GitLab, create a webhook for your project, enter the trigger URL (such as `https://JENKINS_URL/project/YOUR_JOB`) and paste the token in the **Secret Token** field.
 1. After you add the webhook, click the **Test** button, and it should succeed.
 
 ## Troubleshooting
@@ -205,8 +205,8 @@ which is set to 10 seconds by default.
 To fix this the `gitlab_rails['webhook_timeout']` value must be increased
 in the `gitlab.rb` configuration file, followed by the [`gitlab-ctl reconfigure` command](../administration/restart_gitlab.md).
 
-If you don't find the errors above, but do find *duplicate* entries like below (in `/var/log/gitlab/gitlab-rail`), this
-could also indicate that [webhook requests are timing out](../user/project/integrations/webhooks.md#webhook-fails-or-multiple-webhook-requests-are-triggered):
+If you don't find the errors above, but do find *duplicate* entries like below (in `/var/log/gitlab/gitlab-rail`),
+[webhook requests may be timing out](../user/project/integrations/webhooks.md#webhook-fails-or-multiple-webhook-requests-are-triggered):
 
 ```plaintext
 2019-10-25_04:22:41.25630 2019-10-25T04:22:41.256Z 1584 TID-ovowh4tek WebHookWorker JID-941fb7f40b69dff3d833c99b INFO: start

doc/integration/jira_development_panel.md

@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/2381) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.0.
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/233149) to [GitLab Core](https://about.gitlab.com/pricing/) in 13.4.
 
-The Jira Development Panel integration allows you to reference Jira issues within GitLab, displaying
+The Jira Development Panel integration allows you to reference Jira issues in GitLab, displaying
 activity in the [Development panel](https://support.atlassian.com/jira-software-cloud/docs/view-development-information-for-an-issue/)
 in the issue.
 
@@ -35,7 +35,7 @@ See the [Configuration](#configuration) section for details.
 
 With this integration, you can access related GitLab merge requests, branches, and commits directly from a Jira issue, reflecting your work in GitLab. From the Development panel, you can open a detailed view and take actions including creating a new merge request from a branch. For more information, see [Usage](#usage).
 
-This integration connects all GitLab projects to projects in the Jira instance within either:
+This integration connects all GitLab projects to projects in the Jira instance in either:
 
 - A top-level group. A top-level GitLab group is one that does not have any parent group itself. All
   the projects of that top-level group, as well as projects of the top-level group's subgroups nesting
@@ -211,7 +211,7 @@ The requested scope is invalid, unknown, or malformed.
 
 Potential resolutions:
 
-- Verify the URL shown in the browser after being redirected from Jira in step 5 of [Jira DVCS Connector Setup](#jira-dvcs-connector-setup) includes `scope=api` within the query string.
+- Verify the URL shown in the browser after being redirected from Jira in step 5 of [Jira DVCS Connector Setup](#jira-dvcs-connector-setup) includes `scope=api` in the query string.
 - If `scope=api` is missing from the URL, return to [GitLab account configuration](#gitlab-account-configuration-for-dvcs) and ensure the application you created in step 1 has the `api` box checked under scopes.
 
 ##### Jira error adding account and no repositories listed
@@ -314,6 +314,6 @@ For more information on using Jira Smart Commits to track time against an issue,
 
 ## Limitations
 
-This integration is currently not supported on GitLab instances under a
+This integration is not supported on GitLab instances under a
 [relative URL](https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-a-relative-url-for-gitlab).
 For example, `http://example.com/gitlab`.

doc/integration/oauth2_generic.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Sign into GitLab with (almost) any OAuth2 provider
 
-The `omniauth-oauth2-generic` gem allows Single Sign On between GitLab and your own OAuth2 provider
+The `omniauth-oauth2-generic` gem allows Single Sign-On between GitLab and your own OAuth2 provider
 (or any OAuth2 provider compatible with this gem)
 
 This strategy is designed to allow configuration of the simple OmniAuth SSO process outlined below:

doc/integration/oauth_provider.md

@@ -20,15 +20,14 @@ If you want to use:
 ## Introduction to OAuth
 
 [OAuth](https://oauth.net/2/) provides to client applications a 'secure delegated access' to server
-resources on behalf of a resource owner. In fact, OAuth allows an authorization
+resources on behalf of a resource owner. OAuth allows an authorization
 server to issue access tokens to third-party clients with the approval of the
 resource owner, or the end-user.
 
 OAuth is mostly used as a Single Sign-On service (SSO), but you can find a
 lot of different uses for this functionality. For example, you can allow users
-to sign in to your application with their GitLab.com account, or GitLab.com
-can be used for authentication to your GitLab instance
-(see [GitLab OmniAuth](gitlab.md)).
+to sign in to your application with their GitLab.com account. You can also use GitLab.com
+for authentication to your GitLab instance (see [GitLab OmniAuth](gitlab.md)).
 
 The 'GitLab Importer' feature is also using the OAuth protocol to give access
 to repositories without sharing user credentials to your GitLab.com account.
@@ -37,7 +36,7 @@ GitLab supports two ways of adding a new OAuth2 application to an instance. You
 can either add an application as a regular user or add it in the Admin Area.
 What this means is that GitLab can actually have instance-wide and a user-wide
 applications. There is no difference between them except for the different
-permission levels they are set (user/admin). The default callback URL is
+permission levels they are set (user or administrator). The default callback URL is
 `http://your-gitlab.example.com/users/auth/gitlab/callback`
 
 ## Adding an application through the profile
@@ -64,7 +63,7 @@ connects to GitLab.
 To create an application that does not belong to a certain user, you can create
 it from the Admin Area.
 
-![OAuth admin_applications](img/oauth_provider_admin_application.png)
+![OAuth administrator applications](img/oauth_provider_admin_application.png)
 
 You're also able to mark an application as _trusted_ when creating it through the Admin Area. By doing that,
 the user authorization step is automatically skipped for this application.
@@ -77,7 +76,7 @@ in the **Authorized applications** section under **Profile Settings > Applicatio
 ![Authorized_applications](img/oauth_provider_authorized_application.png)
 
 The GitLab OAuth applications support scopes, which allow various actions that any given
-application can perform. The available scopes are depicted in the following table. 
+application can perform. The available scopes are depicted in the following table.
 
 | Scope              | Description |
 | ------------------ | ----------- |
@@ -88,9 +87,9 @@ application can perform. The available scopes are depicted in the following tabl
 | `write_repository` | Grants read-write access to repositories on private projects using Git-over-HTTP (not using the API). |
 | `read_registry`    |  Grants read-only access to container registry images on private projects. |
 | `write_registry`   | Grants read-only access to container registry images on private projects. |
-| `sudo`             | Grants permission to perform API actions as any user in the system, when authenticated as an admin user. |
+| `sudo`             | Grants permission to perform API actions as any user in the system, when authenticated as an administrator user. |
 | `openid`           | Grants permission to authenticate with GitLab using [OpenID Connect](openid_connect_provider.md). Also gives read-only access to the user's profile and group memberships. |
 | `profile`          |  Grants read-only access to the user's profile data using [OpenID Connect](openid_connect_provider.md). |
 | `email`            |  Grants read-only access to the user's primary email address using [OpenID Connect](openid_connect_provider.md). |
 
-At any time you can revoke any access by just clicking **Revoke**.
+At any time you can revoke any access by clicking **Revoke**.

doc/integration/omniauth.md

@@ -55,7 +55,7 @@ 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 can't sign in via OmniAuth.
+  be created manually or they can't sign in by using 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 have their LDAP identity created in GitLab as well.
@@ -66,7 +66,7 @@ earlier version, you must explicitly enable it.
 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
+SAML, Shibboleth, Crowd, or Google, or set it to `false` otherwise any user on
 the Internet can successfully sign in to your GitLab without
 administrative approval.
 
@@ -170,8 +170,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** can't have
+You can define which OmniAuth providers you want to be `external`. Users
+creating accounts, or logging in by using these `external` providers cannot 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.
@@ -200,9 +200,9 @@ NOTE:
 The following information only applies for installations from source.
 
 GitLab uses [OmniAuth](https://github.com/omniauth/omniauth) for authentication and already ships
-with a few providers pre-installed (e.g. LDAP, GitHub, Twitter). But sometimes that
-is not enough and you need to integrate with other authentication solutions. For
-these cases you can use the OmniAuth provider.
+with a few providers pre-installed, such as LDAP, GitHub, and Twitter. You may also
+need to integrate with other authentication solutions. For
+these cases, you can use the OmniAuth provider.
 
 ### Steps
 
@@ -251,10 +251,10 @@ we'd like to at least help those with specific needs.
 
 > Introduced in GitLab 8.8.
 
-Administrators are able to enable or disable Sign In via some OmniAuth providers.
+Administrators are able to enable or disable Sign In by using some OmniAuth providers.
 
 NOTE:
-By default Sign In is enabled via all the OAuth Providers that have been configured in `config/gitlab.yml`.
+By default Sign In is enabled by using all the OAuth Providers that have been configured in `config/gitlab.yml`.
 
 In order to enable/disable an OmniAuth provider, go to Admin Area -> Settings -> Sign-in Restrictions section -> Enabled OAuth Sign-In sources and select the providers you want to enable or disable.
 
@@ -345,7 +345,7 @@ omniauth:
 
 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.
+one of the OmniAuth users has administrator permissions.
 
 You may also bypass the auto sign in feature by browsing to
 `https://gitlab.example.com/users/sign_in?auto_sign_in=false`.

doc/integration/openid_connect_provider.md

@@ -12,11 +12,13 @@ to sign in to other services.
 ## Introduction to OpenID Connect
 
 [OpenID Connect](https://openid.net/connect/) \(OIDC) is a simple identity layer on top of the
-OAuth 2.0 protocol. It allows clients to verify the identity of the end-user
-based on the authentication performed by GitLab, as well as to obtain
-basic profile information about the end-user in an interoperable and
-REST-like manner. OIDC performs many of the same tasks as OpenID 2.0,
-but does so in a way that is API-friendly, and usable by native and
+OAuth 2.0 protocol. It allows clients to:
+
+- Verify the identity of the end-user based on the authentication performed by GitLab.
+- Obtain basic profile information about the end-user in an interoperable and REST-like manner.
+
+OIDC performs many of the same tasks as OpenID 2.0,
+but does so in a way that is API-friendly and usable by native and
 mobile applications.
 
 On the client side, you can use [OmniAuth::OpenIDConnect](https://github.com/jjbohn/omniauth-openid-connect/) for Rails
@@ -34,7 +36,7 @@ is select the `openid` scope in the application settings.
 
 ## Shared information
 
-Currently the following user information is shared with clients:
+The following user information is shared with clients:
 
 | Claim            | Type      | Description |
 |:-----------------|:----------|:------------|

doc/integration/recaptcha.md

@@ -14,7 +14,7 @@ to confirm that a real user, not a bot, is attempting to create an account.
 
 To use reCAPTCHA, first you must create a site and private key.
 
-1. Go to the URL: <https://www.google.com/recaptcha/admin>.
+1. Go to the [Google reCAPTCHA page](https://www.google.com/recaptcha/admin).
 1. Fill out the form necessary to obtain reCAPTCHA v2 keys.
 1. Log in to your GitLab server, with administrator credentials.
 1. Go to Reporting Applications Settings in the Admin Area (`admin/application_settings/reporting`).
@@ -26,7 +26,7 @@ To use reCAPTCHA, first you must create a site and private key.
    return `recaptcha_html`.
 
 NOTE:
-Make sure you are viewing an issuable in a project that is public, and if you're working with an issue, the issue is public.
+Make sure you are viewing an issuable in a project that is public. If you're working with an issue, the issue is public.
 
 ## Enabling reCAPTCHA for user logins via passwords
 

doc/integration/salesforce.md

@@ -86,4 +86,6 @@ Click the icon to begin the authentication process. Salesforce asks the user to
 If everything goes well, the user is returned to GitLab and is signed in.
 
 NOTE:
-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.
+GitLab requires the email address of each new user. After the user is signed 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

@@ -10,17 +10,17 @@ NOTE:
 The preferred approach for integrating a Shibboleth authentication system
 with GitLab 10 or newer is to use the [GitLab SAML integration](saml.md). This documentation is for Omnibus GitLab 9.x installs or older.
 
-In order to enable Shibboleth support in GitLab we need to use Apache instead of NGINX (It may be possible to use NGINX, however this is difficult to configure using the bundled NGINX provided in the Omnibus GitLab package). Apache uses mod_shib2 module for Shibboleth authentication and can pass attributes as headers to OmniAuth Shibboleth provider.
+To enable Shibboleth support in GitLab we need to use Apache instead of NGINX. (It may be possible to use NGINX, however this is difficult to configure using the bundled NGINX provided in the Omnibus GitLab package.) Apache uses `mod_shib2` module for Shibboleth authentication and can pass attributes as headers to OmniAuth Shibboleth provider.
 
 To enable the Shibboleth OmniAuth provider you must configure Apache Shibboleth module.
 The installation and configuration of the module itself is out of the scope of this document.
-Check <https://wiki.shibboleth.net/confluence/display/SP3/Apache> for more information.
+Check [the Shibboleth documentation](https://wiki.shibboleth.net/confluence/display/SP3/Apache) for more information.
 
 You can find Apache configuration in [GitLab Recipes](https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/web-server/apache).
 
 The following changes are needed to enable Shibboleth:
 
-1. Protect OmniAuth Shibboleth callback URL:
+1. Protect the OmniAuth Shibboleth callback URL:
 
    ```apache
    <Location /users/auth/shibboleth/callback>
@@ -53,7 +53,7 @@ The following changes are needed to enable Shibboleth:
    ```
 
    NOTE:
-   Starting from GitLab 11.4, OmniAuth is enabled by default. If you're using an
+   In GitLab versions 11.4 and later, OmniAuth is enabled by default. If you're using an
    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.
@@ -100,7 +100,7 @@ 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 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.
+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
 

doc/integration/slash_commands.md

@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > The `run` command was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/4466) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.6. [Moved](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24780) to [GitLab Core](https://about.gitlab.com/pricing/) in 11.9.
 
-Slash commands in Mattermost and Slack allow you to control GitLab and view GitLab content right inside your chat client, without having to leave it. For Slack, this requires an [integration configuration](../user/project/integrations/slack_slash_commands.md). Simply type the command as a message in your chat client to activate it.
+Slash commands in Mattermost and Slack allow you to control GitLab and view GitLab content right inside your chat client, without having to leave it. For Slack, this requires an [integration configuration](../user/project/integrations/slack_slash_commands.md). Type the command as a message in your chat client to activate it.
 
 Commands are scoped to a project, with a trigger term that is specified during configuration.
 
@@ -28,8 +28,8 @@ Taking the trigger term as `project-name`, the commands are:
 | `/project-name deploy <from> to <to>` | Deploy from the `<from>` environment to the `<to>` environment |
 | `/project-name run <job name> <arguments>` | Execute [ChatOps](../ci/chatops/README.md) job `<job name>` on `master` |
 
-Note that if you are using the [GitLab Slack application](../user/project/integrations/gitlab_slack_application.md) for
-your GitLab.com projects, you need to [add the `gitlab` keyword at the beginning of the command](../user/project/integrations/gitlab_slack_application.md#usage).
+If you are using the [GitLab Slack application](../user/project/integrations/gitlab_slack_application.md) for
+your GitLab.com projects, [add the `gitlab` keyword at the beginning of the command](../user/project/integrations/gitlab_slack_application.md#usage).
 
 ## Issue commands
 

doc/integration/sourcegraph.md

@@ -25,7 +25,7 @@ you can choose to enable Sourcegraph [through your user preferences](#enable-sou
 
 ## Set up for self-managed GitLab instances **(CORE ONLY)**
 
-Before you can enable Sourcegraph code intelligence in GitLab you will need to:
+Before you can enable Sourcegraph code intelligence in GitLab you must:
 
 - Enable the `sourcegraph` feature flag for your GitLab instance.
 - Configure a Sourcegraph instance with your GitLab instance as an external service.
@@ -33,7 +33,7 @@ Before you can enable Sourcegraph code intelligence in GitLab you will need to:
 ### Enable the Sourcegraph feature flag
 
 NOTE:
-If you are running a self-managed instance, the Sourcegraph integration will not be available
+If you are running a self-managed instance, the Sourcegraph integration is unavailable
 unless the feature flag `sourcegraph` is enabled. This can be done from the Rails console
 by instance administrators.
 
@@ -64,7 +64,7 @@ Feature.enable(:sourcegraph, Project.find_by_full_path('my_group/my_project'))
 
 If you are new to Sourcegraph, head over to the [Sourcegraph installation documentation](https://docs.sourcegraph.com/admin) and get your instance up and running.
 
-If you are using an HTTPS connection to GitLab, you will need to [configure HTTPS](https://docs.sourcegraph.com/admin/http_https_configuration) for your Sourcegraph instance.
+If you are using an HTTPS connection to GitLab, you must [configure HTTPS](https://docs.sourcegraph.com/admin/http_https_configuration) for your Sourcegraph instance.
 
 ### Connect your Sourcegraph instance to your GitLab instance
 
@@ -79,9 +79,9 @@ You can skip this step if you already have your GitLab repositories searchable i
 1. In GitLab, go to **Admin Area > Settings > General**.
 1. Expand the **Sourcegraph** configuration section.
 1. Check **Enable Sourcegraph**.
-1. Set the Sourcegraph URL to your Sourcegraph instance, e.g., `https://sourcegraph.example.com`.
+1. Set the Sourcegraph URL to your Sourcegraph instance, such as `https://sourcegraph.example.com`.
 
-![Sourcegraph admin settings](img/sourcegraph_admin_v12_5.png)
+![Sourcegraph administration settings](img/sourcegraph_admin_v12_5.png)
 
 ## Enable Sourcegraph in user preferences
 
@@ -95,7 +95,7 @@ If a GitLab administrator has enabled Sourcegraph, you can enable this feature i
 
 ## Using Sourcegraph code intelligence
 
-Once enabled, participating projects will have a code intelligence popover available in
+Once enabled, participating projects display a code intelligence popover available in
 the following code views:
 
 - Merge request diffs
@@ -114,7 +114,7 @@ When visiting one of these views, you can now hover over a code reference to see
 
 Sourcegraph powered code intelligence is available for all public projects on GitLab.com.
 
-Support for private projects is currently not available for GitLab.com;
+Support for private projects is not yet available for GitLab.com;
 follow the epic [&2201](https://gitlab.com/groups/gitlab-org/-/epics/2201)
 for updates.
 
@@ -122,7 +122,7 @@ for updates.
 
 ### Sourcegraph isn't working
 
-If you enabled Sourcegraph for your project but still it doesn't look like it's working, it might be because Sourcegraph has not indexed the project yet. You can check for Sourcegraph's availability of your project by visiting `https://sourcegraph.com/gitlab.com/<project-path>`replacing `<project-path>` with the path to your GitLab project.
+If you enabled Sourcegraph for your project but it isn't working, Sourcegraph may not have indexed the project yet. You can check for Sourcegraph's availability of your project by visiting `https://sourcegraph.com/gitlab.com/<project-path>`replacing `<project-path>` with the path to your GitLab project.
 
 ## Sourcegraph and Privacy
 
@@ -130,5 +130,5 @@ From Sourcegraph's [extension documentation](https://docs.sourcegraph.com/integr
 engine behind the native GitLab integration:
 
 > Sourcegraph integrations never send any logs, pings, usage statistics, or telemetry to Sourcegraph.com.
-> They will only connect to Sourcegraph.com as required to provide code intelligence or other functionality on public code.
+> They connect only to Sourcegraph.com as required to provide code intelligence or other functionality on public code.
 > As a result, no private code, private repository names, usernames, or any other specific data is sent to Sourcegraph.com.