Add latest changes from gitlab-org/gitlab@master

doc/api/templates/gitignores.md

@@ -12,10 +12,12 @@ information on `gitignore`, see the
 
 Get all `.gitignore` templates.
 
-```
+```plaintext
 GET /templates/gitignores
 ```
 
+Example request:
+
 ```bash
 curl https://gitlab.example.com/api/v4/templates/gitignores
 ```
@@ -111,14 +113,16 @@ Example response:
 
 Get a single `.gitignore` template.
 
-```
+```plaintext
 GET /templates/gitignores/:key
 ```
 
-| Attribute  | Type   | Required | Description |
-| ---------- | ------ | -------- | ----------- |
+| Attribute  | Type   | Required | Description                          |
+| ---------- | ------ | -------- | ------------------------------------ |
 | `key`      | string | yes      | The key of the `.gitignore` template |
 
+Example request:
+
 ```bash
 curl https://gitlab.example.com/api/v4/templates/gitignores/Ruby
 ```

doc/ci/yaml/README.md

@@ -2017,6 +2017,10 @@ test:
   timeout: 3h 30m
 ```
 
+The job-level timeout can exceed the
+[project-level timeout](../../user/project/pipelines/settings.md#timeout) but can not
+exceed the Runner-specific timeout.
+
 ### `parallel`
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/22631) in GitLab 11.5.

doc/integration/elasticsearch.md

@@ -42,7 +42,7 @@ updated automatically.
 
 ## Elasticsearch repository indexer (beta)
 
-In order to improve elasticsearch indexing performance, GitLab has made available a [new indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer).
+In order to improve Elasticsearch indexing performance, GitLab has made available a [new indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer).
 This will replace the included Ruby indexer in the future but should be considered beta software for now, so there may be some bugs.
 
 The Elasticsearch Go indexer is included in Omnibus for GitLab 11.8 and newer.
@@ -110,7 +110,7 @@ Example:
 PREFIX=/usr sudo -E make install
 ```
 
-Once installed, enable it under your instance's elasticsearch settings explained [below](#enabling-elasticsearch).
+Once installed, enable it under your instance's Elasticsearch settings explained [below](#enabling-elasticsearch).
 
 ## System Requirements
 
@@ -402,7 +402,7 @@ There are several rake tasks available to you via the command line:
     - `sudo gitlab-rake gitlab:elastic:index_projects`
     - `sudo gitlab-rake gitlab:elastic:index_snippets`
 - [`sudo gitlab-rake gitlab:elastic:index_projects`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/tasks/gitlab/elastic.rake)
-  - This iterates over all projects and queues sidekiq jobs to index them in the background.
+  - This iterates over all projects and queues Sidekiq jobs to index them in the background.
 - [`sudo gitlab-rake gitlab:elastic:index_projects_status`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/tasks/gitlab/elastic.rake)
   - This determines the overall status of the indexing. It is done by counting the total number of indexed projects, dividing by a count of the total number of projects, then multiplying by 100.
 - [`sudo gitlab-rake gitlab:elastic:create_empty_index`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/tasks/gitlab/elastic.rake)

doc/integration/jenkins_deprecated.md

@@ -14,7 +14,7 @@ Integration includes:
 Requirements:
 
 - [Jenkins GitLab Hook plugin](https://wiki.jenkins.io/display/JENKINS/GitLab+Hook+Plugin)
-- Git clone access for Jenkins from GitLab repo (via ssh key)
+- Git clone access for Jenkins from GitLab repo (via SSH key)
 
 ## Jenkins
 

doc/integration/kerberos.md

@@ -203,7 +203,7 @@ remove the OmniAuth provider named `kerberos` from your `gitlab.yml` /
 
 **For installations from source**
 
-1. Edit [`gitlab.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/config/gitlab.yml.example) and remove the `- { name: 'kerberos' }` line under omniauth
+1. Edit [`gitlab.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/config/gitlab.yml.example) and remove the `- { name: 'kerberos' }` line under OmniAuth
    providers:
 
    ```yaml

doc/integration/omniauth.md

@@ -35,7 +35,7 @@ contains some settings that are common for all providers.
 - [JWT](../administration/auth/jwt.md)
 - [OpenID Connect](../administration/auth/oidc.md)
 - [UltraAuth](ultra_auth.md)
-- [SalesForce](salesforce.md)
+- [Salesforce](salesforce.md)
 
 ## Initial OmniAuth Configuration
 
@@ -43,7 +43,7 @@ Before configuring individual OmniAuth providers there are a few global settings
 that are in common for all providers that we need to consider.
 
 > **NOTE:**
-> Starting from GitLab 11.4, Omniauth is enabled by default. If you're using an
+> Starting from GitLab 11.4, OmniAuth is enabled by default. If you're using an
 > earlier version, you'll need to explicitly enable it.
 
 - `allow_single_sign_on` allows you to specify the providers you want to allow to
@@ -171,20 +171,20 @@ omniauth:
   external_providers: ['twitter', 'google_oauth2']
 ```
 
-## Using Custom Omniauth Providers
+## Using Custom OmniAuth Providers
 
 >**Note:**
 The following information only applies for installations from source.
 
-GitLab uses [Omniauth](https://github.com/omniauth/omniauth) for authentication and already ships
+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.
+these cases you can use the OmniAuth provider.
 
 ### Steps
 
 These steps are fairly general and you will need to figure out the exact details
-from the Omniauth provider's documentation.
+from the OmniAuth provider's documentation.
 
 - Stop GitLab:
 
@@ -198,7 +198,7 @@ from the Omniauth provider's documentation.
   gem "omniauth-your-auth-provider"
   ```
 
-- Install the new Omniauth provider gem by running the following command:
+- Install the new OmniAuth provider gem by running the following command:
 
   ```sh
   sudo -u git -H bundle install --without development test mysql --path vendor/bundle --no-deployment
@@ -238,13 +238,13 @@ In order to enable/disable an OmniAuth provider, go to Admin Area -> Settings ->
 
 ![Enabled OAuth Sign-In sources](img/enabled-oauth-sign-in-sources.png)
 
-## Disabling Omniauth
+## Disabling OmniAuth
 
-Starting from version 11.4 of GitLab, Omniauth is enabled by default. This only
+Starting from version 11.4 of GitLab, OmniAuth is enabled by default. This only
 has an effect if providers are configured and [enabled](#enable-or-disable-sign-in-with-an-omniauth-provider-without-disabling-import-sources).
 
-If omniauth providers are causing problems even when individually disabled, you
-can disable the entire omniauth subsystem by modifying the configuration file:
+If OmniAuth providers are causing problems even when individually disabled, you
+can disable the entire OmniAuth subsystem by modifying the configuration file:
 
 **For Omnibus installations**
 

doc/integration/openid_connect_provider.md

@@ -13,7 +13,7 @@ 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-openid-connect] for Rails
+On the client side, you can use [OmniAuth::OpenIDConnect](https://github.com/jjbohn/omniauth-openid-connect/) for Rails
 applications, or any of the other available [client implementations](https://openid.net/developers/libraries/#connect).
 
 GitLab's implementation uses the [doorkeeper-openid_connect] gem, refer
@@ -48,4 +48,3 @@ Only the `sub` and `sub_legacy` claims are included in the ID token, all other c
 
 [doorkeeper-openid_connect]: https://github.com/doorkeeper-gem/doorkeeper-openid_connect "Doorkeeper::OpenidConnect website"
 [OAuth guide]: oauth_provider.md "GitLab as OAuth2 authentication service provider"
-[omniauth-openid-connect]: https://github.com/jjbohn/omniauth-openid-connect/ "OmniAuth::OpenIDConnect website"

doc/integration/recaptcha.md

@@ -12,7 +12,7 @@ To use reCAPTCHA, first you must create a site and private key.
 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`).
-1. Fill all recaptcha fields with keys from previous steps.
+1. Fill all reCAPTCHA fields with keys from previous steps.
 1. Check the `Enable reCAPTCHA` checkbox.
 1. Save the configuration.
 

doc/integration/salesforce.md

@@ -21,7 +21,7 @@ To get the credentials (a pair of Client ID and Client Secret), you must [create
 1. Select **API (Enable OAuth Settings)** and click on **Enable OAuth Settings**.
 1. Fill in the application details into the following fields:
    - **Callback URL**: The callback URL of your GitLab installation. For example, `https://gitlab.example.com/users/auth/salesforce/callback`.
-   - **Selected OAuth Scopes**: Move **Access your basic information (id, profile, email, address, phone)** and **Allow access to your unique identifier (openid)** to the right column.
+   - **Selected OAuth Scopes**: Move **Access your basic information (id, profile, email, address, phone)** and **Allow access to your unique identifier (OpenID)** to the right column.
 
    ![Salesforce Oauth App Details](img/salesforce_oauth_app_details.png)
 

doc/integration/saml.md

@@ -111,7 +111,7 @@ in your SAML IdP:
 1. Change the values of `idp_cert_fingerprint`, `idp_sso_target_url`,
    `name_identifier_format` to match your IdP. If a fingerprint is used it must
    be a SHA1 fingerprint; check
-   [the omniauth-saml documentation](https://github.com/omniauth/omniauth-saml)
+   [the OmniAuth SAML documentation](https://github.com/omniauth/omniauth-saml)
    for more details on these options.
 
 1. Change the value of `issuer` to a unique name, which will identify the application
@@ -133,7 +133,7 @@ https://gitlab.example.com/users/auth/saml/metadata
 At a minimum the IdP *must* provide a claim containing the user's email address, using
 claim name `email` or `mail`. The email will be used to automatically generate the GitLab
 username. GitLab will also use claims with name `name`, `first_name`, `last_name`
-(see [the omniauth-saml gem](https://github.com/omniauth/omniauth-saml/blob/master/lib/omniauth/strategies/saml.rb)
+(see [the OmniAuth SAML gem](https://github.com/omniauth/omniauth-saml/blob/master/lib/omniauth/strategies/saml.rb)
 for supported claims).
 
 On the sign in page there should now be a SAML button below the regular sign in form.

doc/integration/shibboleth.md

@@ -2,9 +2,9 @@
 
 NOTE: **Note:**
 The preferred approach for integrating a Shibboleth authentication system
-with Gitlab 10 or newer is to use [GitLab's SAML integration](saml.md). This documentation is for Omnibus GitLab 9.x installs or older.
+with GitLab 10 or newer is to use [GitLab's 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.
+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 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.
@@ -14,7 +14,7 @@ You can find Apache config in [GitLab Recipes](https://gitlab.com/gitlab-org/git
 
 The following changes are needed to enable Shibboleth:
 
-1. Protect Omniauth Shibboleth callback URL:
+1. Protect OmniAuth Shibboleth callback URL:
 
    ```
    <Location /users/auth/shibboleth/callback>

doc/integration/slack.md

@@ -2,4 +2,4 @@
 redirect_to: '../user/project/integrations/slack.md'
 ---
 
-This document was moved to [project_services/slack.md](../user/project/integrations/slack.md).
+This document was moved to [another location](../user/project/integrations/slack.md).

doc/topics/git/migrate_to_git_lfs/index.md

@@ -15,7 +15,7 @@ will not actually reduce the size of your repository because
 the files are still referenced by previous commits.
 
 Through the method described on this document, first migrate
-to Git LFS with [BFG](https://rtyley.github.io/bfg-repo-cleaner/)
+to Git LFS with a tool such as the open source community-maintained [BFG](https://rtyley.github.io/bfg-repo-cleaner/)
 through a mirror repo, then clean up the repository's history,
 and lastly create LFS tracking rules to prevent new binary files
 from being added.

doc/topics/git/numerous_undo_possibilities_in_git/index.md

@@ -487,9 +487,9 @@ git filter-branch --tree-filter 'rm filename' HEAD
 Since `git filter-branch` command might be slow on big repositories, there are
 tools that can use some of Git specifics to enable faster execution of common
 tasks (which is exactly what removing sensitive information file is about).
-An alternative is [BFG Repo-cleaner][bfg-repo-cleaner]. Keep in mind that these
-tools are faster because they do not provide a same fully feature set as `git filter-branch`
-does, but focus on specific use cases.
+An alternative is the open source community-maintained tool [BFG][bfg-repo-cleaner].  
+Keep in mind that these tools are faster because they do not provide the same  
+feature set as `git filter-branch` does, but focus on specific use cases.
 
 ## Conclusion
 

doc/user/project/import/bitbucket_server.md

@@ -4,7 +4,7 @@
 in GitLab 11.2.
 
 NOTE: **Note:**
-The Bitbucket Server importer does not work with Bitbucket Cloud (aka bitbucket.org).
+The Bitbucket Server importer does not work with [Bitbucket Cloud](https://bitbucket.org).
 Use the [Bitbucket Cloud importer](bitbucket.md) for that.
 
 Import your projects from Bitbucket Server to GitLab with minimal effort.

doc/user/project/import/github.md

@@ -82,7 +82,7 @@ If you are using a self-hosted GitLab instance or if you are importing from GitH
 
 1. From the top navigation bar, click **+** and select **New project**.
 1. Select the **Import project** tab and then select **GitHub**.
-1. Select the first button to **List your GitHub repositories**. You are redirected to a page on github.com to authorize the GitLab application.
+1. Select the first button to **List your GitHub repositories**. You are redirected to a page on [GitHub](https://github.com) to authorize the GitLab application.
 1. Click **Authorize gitlabhq**. You are redirected back to GitLab's Import page and all of your GitHub repositories are listed.
 1. Continue on to [selecting which repositories to import](#selecting-which-repositories-to-import).
 

doc/user/project/import/index.md

 # Migrating projects to a GitLab instance
 
-1. [From Bitbucket Cloud (aka bitbucket.org)](bitbucket.md)
-1. [From Bitbucket Server (aka Stash)](bitbucket_server.md)
+1. [From Bitbucket Cloud](bitbucket.md)
+1. [From Bitbucket Server (also known as Stash)](bitbucket_server.md)
 1. [From ClearCase](clearcase.md)
 1. [From CVS](cvs.md)
 1. [From FogBugz](fogbugz.md)
@@ -24,7 +24,7 @@ There is also the option of [connecting your external repository to get CI/CD be
 
 ## Migrating from self-hosted GitLab to GitLab.com
 
-If you only need to migrate git repos, you can [import each project by URL](repo_by_url.md), but issues and merge requests can't be imported.
+If you only need to migrate Git repos, you can [import each project by URL](repo_by_url.md), but issues and merge requests can't be imported.
 
 If you want to retain all metadata like issues and merge requests, you can use
 the [import/export feature](../settings/import_export.md) to export projects from self-hosted GitLab and import those projects into GitLab.com.
@@ -34,7 +34,7 @@ This approach assumes all users from the self-hosted instance have already been
 If the users haven't been migrated yet, the user conducting the import
 will take the place of all references to the missing user(s).
 
-If you need to migrate all data over, you can leverage our [api](../../../api/README.md) to migrate from self-hosted to GitLab.com.
+If you need to migrate all data over, you can leverage our [API](../../../api/README.md) to migrate from self-hosted to GitLab.com.
 The order of assets to migrate from a self-hosted instance to GitLab is the following:
 
 1. [Users](../../../api/users.md)

doc/user/project/import/perforce.md

@@ -45,8 +45,8 @@ submit back from Git to Perforce.
 
 Here's a few links to get you started:
 
-- [git-p4 manual page](https://www.kernel.org/pub/software/scm/git/docs/git-p4.html)
-- [git-p4 example usage](https://git.wiki.kernel.org/index.php/Git-p4_Usage)
+- [`git-p4` manual page](https://www.kernel.org/pub/software/scm/git/docs/git-p4.html)
+- [`git-p4` example usage](https://git.wiki.kernel.org/index.php/Git-p4_Usage)
 - [Git book migration guide](https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git#_perforce_import)
 
 Note that `git p4` and `git filter-branch` are not very good at

doc/user/project/integrations/bamboo.md

@@ -25,9 +25,9 @@ need to be configured in a Bamboo build plan before GitLab can integrate.
    whitelist of IP addresses that are allowed to trigger Bamboo builds.
 1. Save the trigger.
 1. In the left pane, select a build stage. If you have multiple build stages
-   you want to select the last stage that contains the git checkout task.
+   you want to select the last stage that contains the Git checkout task.
 1. Select the 'Miscellaneous' tab.
-1. Under 'Pattern Match Labelling' put '${bamboo.repository.revision.number}'
+1. Under 'Pattern Match Labelling' put `${bamboo.repository.revision.number}`
    in the 'Labels' box.
 1. Save
 

doc/user/project/integrations/irker.md

@@ -15,7 +15,7 @@ repository on <https://gitlab.com/esr/irker>:
 git clone https://gitlab.com/esr/irker.git
 ```
 
-Once you have downloaded the code, you can run the python script named `irkerd`.
+Once you have downloaded the code, you can run the Python script named `irkerd`.
 This script is the gateway script, it acts both as an IRC client, for sending
 messages to an IRC server obviously, and as a TCP server, for receiving messages
 from the GitLab service.

doc/user/project/integrations/jira.md

@@ -45,7 +45,7 @@ In order to enable the Jira service in GitLab, you need to first configure the p
 
 #### Jira Server
 
-When connecting to **Jira Server**, which supports basic authentication, a **username and password** are required. Note that connecting to a Jira server via CAS is not possible. [Set up a user in Jira Server](jira_server_configuration.md) first and then proceed to [Configuring GitLab](#configuring-gitlab).
+When connecting to **Jira Server**, which supports basic authentication, a **username and password** are required. Note that connecting to Jira Server via CAS is not possible. [Set up a user in Jira Server](jira_server_configuration.md) first and then proceed to [Configuring GitLab](#configuring-gitlab).
 
 #### Jira Cloud
 

doc/user/project/integrations/mattermost_slash_commands.md

@@ -131,12 +131,12 @@ The available slash commands are:
 
 | Command | Description | Example |
 | ------- | ----------- | ------- |
-| <kbd>/&lt;trigger&gt; issue new &lt;title&gt; <kbd>⇧ Shift</kbd>+<kbd>↵ Enter</kbd> &lt;description&gt;</kbd> | Create a new issue in the project that `<trigger>` is tied to. `<description>` is optional. | <samp>/gitlab issue new We need to change the homepage</samp> |
-| <kbd>/&lt;trigger&gt; issue show &lt;issue-number&gt;</kbd> | Show the issue with ID `<issue-number>` from the project that `<trigger>` is tied to. | <samp>/gitlab issue show 42</samp> |
-| <kbd>/&lt;trigger&gt; deploy &lt;environment&gt; to &lt;environment&gt;</kbd> | Start the CI job that deploys from one environment to another, for example `staging` to `production`. CI/CD must be [properly configured][ciyaml]. | <samp>/gitlab deploy staging to production</samp> |
+| <kbd>/&lt;trigger&gt; issue new &lt;title&gt; <kbd>⇧ Shift</kbd>+<kbd>↵ Enter</kbd> &lt;description&gt;</kbd> | Create a new issue in the project that `<trigger>` is tied to. `<description>` is optional. | `/gitlab issue new We need to change the homepage` |
+| <kbd>/&lt;trigger&gt; issue show &lt;issue-number&gt;</kbd> | Show the issue with ID `<issue-number>` from the project that `<trigger>` is tied to. | `/gitlab issue show 42` |
+| <kbd>/&lt;trigger&gt; deploy &lt;environment&gt; to &lt;environment&gt;</kbd> | Start the CI job that deploys from one environment to another, for example `staging` to `production`. CI/CD must be [properly configured][ciyaml]. | `/gitlab deploy staging to production` |
 
 To see a list of available commands to interact with GitLab, type the
-trigger word followed by <kbd>help</kbd>. Example: <samp>/gitlab help</samp>
+trigger word followed by <kbd>help</kbd>. Example: `/gitlab help`
 
 ![Mattermost bot available commands](img/mattermost_bot_available_commands.png)
 

doc/user/project/integrations/prometheus_library/nginx_ingress.md

@@ -4,7 +4,7 @@
 
 NOTE: **Note:** NGINX Ingress versions prior to 0.16.0 offer an included [VTS Prometheus metrics exporter](nginx_ingress_vts.md), which exports metrics different than the built-in metrics.
 
-GitLab has support for automatically detecting and monitoring the Kubernetes NGINX ingress controller. This is provided by leveraging the built-in Prometheus metrics included starting with [version 0.16.0](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0160).
+GitLab has support for automatically detecting and monitoring the Kubernetes NGINX Ingress controller. This is provided by leveraging the built-in Prometheus metrics included with Kubernetes NGINX Ingress controller [version 0.16.0](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0160) onward.
 
 ## Requirements
 
@@ -18,7 +18,7 @@ GitLab has support for automatically detecting and monitoring the Kubernetes NGI
 | Latency (ms) | `sum(rate(nginx_ingress_controller_ingress_upstream_latency_seconds_sum{namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m])) / sum(rate(nginx_ingress_controller_ingress_upstream_latency_seconds_count{namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m])) * 1000` |
 | HTTP Error Rate (%) | `sum(rate(nginx_ingress_controller_requests{status=~"5.*",namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m])) / sum(rate(nginx_ingress_controller_requests{namespace="%{kube_namespace}",ingress=~".*%{ci_environment_slug}.*"}[2m])) * 100` |
 
-## Configuring NGINX ingress monitoring
+## Configuring NGINX Ingress monitoring
 
 If you have deployed NGINX Ingress using GitLab's [Kubernetes cluster integration](../../clusters/index.md#installing-applications), it will [automatically be monitored](#about-managed-nginx-ingress-deployments) by Prometheus.
 
@@ -42,14 +42,14 @@ When used in conjunction with the GitLab deployed Prometheus service, response m
 
 ### Manually setting up NGINX Ingress for Prometheus monitoring
 
-Version 0.9.0 and above of [NGINX ingress](https://github.com/kubernetes/ingress-nginx) have built-in support for exporting Prometheus metrics. To enable, a ConfigMap setting must be passed: `enable-vts-status: "true"`. Once enabled, a Prometheus metrics endpoint will start running on port 10254.
+Version 0.9.0 and above of [NGINX Ingress](https://github.com/kubernetes/ingress-nginx) have built-in support for exporting Prometheus metrics. To enable, a ConfigMap setting must be passed: `enable-vts-status: "true"`. Once enabled, a Prometheus metrics endpoint will start running on port 10254.
 
-Next, the ingress needs to be annotated for Prometheus monitoring. Two new annotations need to be added:
+Next, the Ingress needs to be annotated for Prometheus monitoring. Two new annotations need to be added:
 
 - `prometheus.io/scrape: "true"`
 - `prometheus.io/port: "10254"`
 
-Managing these settings depends on how NGINX ingress has been deployed. If you have deployed via the [official Helm chart](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress), metrics can be enabled with `controller.stats.enabled` along with the required annotations. Alternatively it is possible edit the NGINX ingress YML directly in the [Kubernetes dashboard](https://github.com/kubernetes/dashboard).
+Managing these settings depends on how NGINX Ingress has been deployed. If you have deployed via the [official Helm chart](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress), metrics can be enabled with `controller.stats.enabled` along with the required annotations. Alternatively it is possible to edit the NGINX Ingress YML directly in the [Kubernetes dashboard](https://github.com/kubernetes/dashboard).
 
 ## Specifying the Environment label
 

doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md

@@ -4,7 +4,7 @@
 
 NOTE: **Note:** [NGINX Ingress version 0.16](nginx_ingress.md) and above have built-in Prometheus metrics, which are different than the VTS based metrics.
 
-GitLab has support for automatically detecting and monitoring the Kubernetes NGINX ingress controller. This is provided by leveraging the included VTS Prometheus metrics exporter in [version 0.9.0](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#09-beta1) through [0.15.x](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0150).
+GitLab has support for automatically detecting and monitoring the Kubernetes NGINX Ingress controller. This is provided by leveraging the included VTS Prometheus metrics exporter in [version 0.9.0](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#09-beta1) through [0.15.x](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0150).
 
 ## Requirements
 
@@ -18,7 +18,7 @@ GitLab has support for automatically detecting and monitoring the Kubernetes NGI
 | Latency (ms) | `avg(nginx_upstream_response_msecs_avg{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"})` |
 | HTTP Error Rate (%) | `sum(rate(nginx_upstream_responses_total{status_code="5xx", upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[2m])) / sum(rate(nginx_upstream_responses_total{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[2m])) * 100` |
 
-## Configuring NGINX ingress monitoring
+## Configuring NGINX Ingress monitoring
 
 If you have deployed NGINX Ingress using GitLab's [Kubernetes cluster integration](../../clusters/index.md#installing-applications), it will [automatically be monitored](#about-managed-nginx-ingress-deployments) by Prometheus.
 
@@ -42,14 +42,14 @@ When used in conjunction with the GitLab deployed Prometheus service, response m
 
 ### Manually setting up NGINX Ingress for Prometheus monitoring
 
-Version 0.9.0 and above of [NGINX ingress](https://github.com/kubernetes/ingress-nginx) have built-in support for exporting Prometheus metrics. To enable, a ConfigMap setting must be passed: `enable-vts-status: "true"`. Once enabled, a Prometheus metrics endpoint will start running on port 10254.
+Version 0.9.0 and above of [NGINX Ingress](https://github.com/kubernetes/ingress-nginx) has built-in support for exporting Prometheus metrics. To enable, a ConfigMap setting must be passed: `enable-vts-status: "true"`. Once enabled, a Prometheus metrics endpoint will start running on port 10254.
 
-Next, the ingress needs to be annotated for Prometheus monitoring. Two new annotations need to be added:
+Next, the Ingress needs to be annotated for Prometheus monitoring. Two new annotations need to be added:
 
 - `prometheus.io/scrape: "true"`
 - `prometheus.io/port: "10254"`
 
-Managing these settings depends on how NGINX ingress has been deployed. If you have deployed via the [official Helm chart](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress), metrics can be enabled with `controller.stats.enabled` along with the required annotations. Alternatively it is possible edit the NGINX ingress YML directly in the [Kubernetes dashboard](https://github.com/kubernetes/dashboard).
+Managing these settings depends on how NGINX Ingress has been deployed. If you have deployed via the [official Helm chart](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress), metrics can be enabled with `controller.stats.enabled` along with the required annotations. Alternatively it is possible edit the NGINX Ingress YAML directly in the [Kubernetes dashboard](https://github.com/kubernetes/dashboard).
 
 ## Specifying the Environment label
 

doc/user/project/integrations/redmine.md

@@ -14,7 +14,7 @@
 
    Once you have configured and enabled Redmine you'll see the Redmine link on the GitLab project pages that takes you to the appropriate Redmine project.
 
-   As an example, below is a configuration for a project named gitlab-ci.
+   As an example, below is a configuration for a project named `gitlab-ci`.
 
    ![Redmine configuration](img/redmine_configuration.png)
 

doc/user/project/integrations/webhooks.md

@@ -1251,8 +1251,8 @@ its description:
 ```
 
 It will appear in the webhook body as the below (assuming that GitLab is
-installed at gitlab.example.com, and the project is at
-example-group/example-project):
+installed at `gitlab.example.com`, and the project is at
+`example-group/example-project`):
 
 ```markdown
 ![image](https://gitlab.example.com/example-group/example-project/uploads/$sha/image.png)

doc/user/project/repository/reducing_the_repo_size_using_git.md

@@ -19,7 +19,8 @@ Unfortunately, it's not so easy and that workflow won't work. Deleting files in
 a commit doesn't actually reduce the size of the repo since the earlier commits
 and blobs are still around. What you need to do is rewrite history with Git's
 [`filter-branch` option](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#The-Nuclear-Option:-filter-branch),
-or a tool like the [BFG Repo-Cleaner](https://rtyley.github.io/bfg-repo-cleaner/).
+or an open source community-maintained tool like the  
+[BFG](https://rtyley.github.io/bfg-repo-cleaner/).
 
 Note that even with that method, until `git gc` runs on the GitLab side, the
 "removed" commits and blobs will still be around. You also need to be able to
@@ -34,8 +35,9 @@ temporarily increase it for you, your only option is to prune all the unneeded
 stuff locally, and then create a new project on GitLab and start using that
 instead.
 
-If you can continue to use the original project, we recommend [using the
-BFG Repo-Cleaner](#using-the-bfg-repo-cleaner). It's faster and simpler than
+If you can continue to use the original project, we recommend [using
+BFG](#using-the-bfg-repo-cleaner), a tool that's built and
+maintained by the open source community. It's faster and simpler than
 `git filter-branch`, and GitLab can use its account of what has changed to clean
 up its own internal state, maximizing the space saved.
 
@@ -54,7 +56,7 @@ removed from the repository.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/19376) in GitLab 11.6.
 
-1. [Install BFG](https://rtyley.github.io/bfg-repo-cleaner/).
+1. [Install BFG](https://rtyley.github.io/bfg-repo-cleaner/) from its open source community repository.
 
 1. Navigate to your repository: