Automatic merge of gitlab-org/gitlab-ce master

doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md

@@ -32,7 +32,7 @@ For example, [Active Directory](https://technet.microsoft.com/en-us/library/hh83
 
 We won't cover the installation and configuration of Windows Server or Active Directory Domain Services in this tutorial. There are a number of resources online to guide you through this process:
 
-- Install Windows Server 2012  - (_technet.microsoft.com_) - [Installing Windows Server 2012 ](https://technet.microsoft.com/en-us/library/jj134246(v=ws.11).aspx)
+- Install Windows Server 2012  - (_technet.microsoft.com_) - [Installing Windows Server 2012](https://technet.microsoft.com/en-us/library/jj134246(v=ws.11).aspx)
 
 - Install Active Directory Domain Services (AD DS) (_technet.microsoft.com_)- [Install Active Directory Domain Services](https://technet.microsoft.com/windows-server-docs/identity/ad-ds/deploy/install-active-directory-domain-services--level-100-#BKMK_PS)
 
@@ -249,7 +249,7 @@ After configuring LDAP, basic authentication will be available. Users can then l
 
 Users that are removed from the LDAP base group (e.g `OU=GitLab INT,DC=GitLab,DC=org`) will be **blocked** in GitLab. [More information](../ldap.md#security) on LDAP security.
 
-If `allow_username_or_email_login` is enabled in the LDAP configuration, GitLab will ignore everything after the first '@' in the LDAP username used on login. Example: The username `` jon.doe@example.com `` is converted to `jon.doe` when authenticating with the LDAP server. Disable this setting if you use `userPrincipalName` as the `uid`.
+If `allow_username_or_email_login` is enabled in the LDAP configuration, GitLab will ignore everything after the first '@' in the LDAP username used on login. Example: The username `jon.doe@example.com` is converted to `jon.doe` when authenticating with the LDAP server. Disable this setting if you use `userPrincipalName` as the `uid`.
 
 ## LDAP extended features on GitLab EE
 

doc/administration/auth/okta.md

@@ -98,20 +98,20 @@ Now that the Okta app is configured, it's time to enable it in GitLab.
    >**Notes:**
    >
    >- Change the value for `assertion_consumer_service_url` to match the HTTPS endpoint
-      of GitLab (append `users/auth/saml/callback` to the HTTPS URL of your GitLab
-      installation to generate the correct value).
+   >  of GitLab (append `users/auth/saml/callback` to the HTTPS URL of your GitLab
+   >  installation to generate the correct value).
    >
    >- To get the `idp_cert_fingerprint` fingerprint, first download the
-      certificate from the Okta app you registered and then run:
-      `openssl x509 -in okta.cert -noout -fingerprint`. Substitute `okta.cert`
-      with the location of your certificate.
+   >  certificate from the Okta app you registered and then run:
+   >  `openssl x509 -in okta.cert -noout -fingerprint`. Substitute `okta.cert`
+   >  with the location of your certificate.
    >
    >- Change the value of `idp_sso_target_url`, with the value of the
-      **Identity Provider Single Sign-On URL** from the step when you
-      configured the Okta app.
+   >  **Identity Provider Single Sign-On URL** from the step when you
+   >  configured the Okta app.
    >
    >- Change the value of `issuer` to the value of the **Audience Restriction** from your Okta app configuration. This will identify GitLab
-      to the IdP.
+   >  to the IdP.
    >
    >- Leave `name_identifier_format` as-is.
 

doc/administration/geo/disaster_recovery/index.md

@@ -297,7 +297,7 @@ for another **primary** node. All the old replication settings will be overwritt
 
 ## Troubleshooting
 
-### I followed the disaster recovery instructions and now two-factor auth is broken!
+### I followed the disaster recovery instructions and now two-factor auth is broken
 
 The setup instructions for Geo prior to 10.5 failed to replicate the
 `otp_key_base` secret, which is used to encrypt the two-factor authentication

doc/administration/geo/replication/troubleshooting.md

@@ -538,7 +538,7 @@ can simply reset the existing tracking database with:
 sudo gitlab-rake geo:db:reset
 ```
 
-### Geo node has a database that is writable which is an indication it is not configured for replication with the primary node.
+### Geo node has a database that is writable which is an indication it is not configured for replication with the primary node
 
 This error refers to a problem with the database replica on a **secondary** node,
 which Geo expects to have access to. It usually means, either:
@@ -552,7 +552,7 @@ PostgreSQL instances:
 - A read-only replica of the **primary** node.
 - A regular, writable instance that holds replication metadata. That is, the Geo tracking database.
 
-### Geo node does not appear to be replicating the database from the primary node.
+### Geo node does not appear to be replicating the database from the primary node
 
 The most common problems that prevent the database from replicating correctly are:
 

doc/administration/gitaly/index.md

@@ -185,7 +185,7 @@ Check the directory layout on your Gitaly server to be sure.
    ```
 
 1. Append the following to `/etc/gitlab/gitlab.rb` for each respective server:
-   
+
    For `gitaly1.internal`:
 
    ```
@@ -194,7 +194,7 @@ Check the directory layout on your Gitaly server to be sure.
      { 'name' => 'storage1' },
    ]
    ```
-   
+
    For `gitaly2.internal`:
 
    ```
@@ -226,7 +226,7 @@ Check the directory layout on your Gitaly server to be sure.
    ```
 
 1. Append the following to `/home/git/gitaly/config.toml` for each respective server:
-   
+
    For `gitaly1.internal`:
 
    ```toml
@@ -236,7 +236,7 @@ Check the directory layout on your Gitaly server to be sure.
    [[storage]]
    name = 'storage1'
    ```
-   
+
    For `gitaly2.internal`:
 
    ```toml
@@ -262,12 +262,12 @@ Additionally, you need to
 [disable Rugged if previously manually enabled](../high_availability/nfs.md#improving-nfs-performance-with-gitlab).
 
 We assume that your `gitaly1.internal` Gitaly server can be reached at
-`gitaly1.internal:8075` from your GitLab server, and that Gitaly server 
+`gitaly1.internal:8075` from your GitLab server, and that Gitaly server
 can read and write to `/mnt/gitlab/default` and `/mnt/gitlab/storage1`.
 
 We assume also that your `gitaly2.internal` Gitaly server can be reached at
-`gitaly2.internal:8075` from your GitLab server, and that Gitaly server 
-can read and write to `/mnt/gitlab/storage2`. 
+`gitaly2.internal:8075` from your GitLab server, and that Gitaly server
+can read and write to `/mnt/gitlab/storage2`.
 
 **For Omnibus GitLab**
 
@@ -540,6 +540,7 @@ gitaly['concurrency'] = [
   }
 ]
 ```
+
 This will limit the number of in-flight RPC calls for the given RPC's.
 The limit is applied per repository. In the example above, each on the
 Gitaly server can have at most 20 simultaneous PostUploadPack calls in
@@ -729,4 +730,4 @@ To remove the proxy setting, run the following commands (depending on which vari
 ```bash
 unset http_proxy
 unset https_proxy
-```
+```
\ No newline at end of file

doc/administration/high_availability/gitlab.md

@@ -4,9 +4,9 @@ type: reference
 
 # Configuring GitLab for Scaling and High Availability
 
-> **Note:** There is some additional configuration near the bottom for
-  additional GitLab application servers. It's important to read and understand
-  these additional steps before proceeding with GitLab installation.
+NOTE: **Note:** There is some additional configuration near the bottom for
+additional GitLab application servers. It's important to read and understand
+these additional steps before proceeding with GitLab installation.
 
 1. If necessary, install the NFS client utility packages using the following
    commands:
@@ -82,19 +82,19 @@ type: reference
 
 1. [Enable monitoring](#enable-monitoring)
 
-   > **Note:** To maintain uniformity of links across HA clusters, the `external_url`
+   NOTE: **Note:** To maintain uniformity of links across HA clusters, the `external_url`
    on the first application server as well as the additional application
    servers should point to the external url that users will use to access GitLab.
    In a typical HA setup, this will be the url of the load balancer which will
    route traffic to all GitLab application servers in the HA cluster.
-   >
-   > **Note:** When you specify `https` in the `external_url`, as in the example
+
+   NOTE: **Note:** When you specify `https` in the `external_url`, as in the example
    above, GitLab assumes you have SSL certificates in `/etc/gitlab/ssl/`. If
    certificates are not present, Nginx will fail to start. See
    [Nginx documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
    for more information.
-   >
-   > **Note:** It is best to set the `uid` and `gid`s prior to the initial reconfigure
+
+   NOTE: **Note:** It is best to set the `uid` and `gid`s prior to the initial reconfigure
    of GitLab. Omnibus will not recursively `chown` directories if set after the initial reconfigure.
 
 ## First GitLab application server
@@ -105,8 +105,8 @@ Do not run this on additional application servers.
 1. Initialize the database by running `sudo gitlab-rake gitlab:setup`.
 1. Run `sudo gitlab-ctl reconfigure` to compile the configuration.
 
-> **WARNING:** Only run this setup task on **NEW** GitLab instances because it
-  will wipe any existing data.
+   CAUTION: **WARNING:** Only run this setup task on **NEW** GitLab instances because it
+   will wipe any existing data.
 
 ## Extra configuration for additional GitLab application servers
 
@@ -173,9 +173,10 @@ If you enable Monitoring, it must be enabled on **all** GitLab servers.
 
 1. Run `sudo gitlab-ctl reconfigure` to compile the configuration.
 
-> **Warning:** After changing `unicorn['listen']` in `gitlab.rb`, and running `sudo gitlab-ctl reconfigure`,
-  it can take an extended period of time for unicorn to complete reloading after receiving a `HUP`.
-  For more information, see the [issue](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4401).
+   CAUTION: **Warning:**
+   After changing `unicorn['listen']` in `gitlab.rb`, and running `sudo gitlab-ctl reconfigure`,
+   it can take an extended period of time for unicorn to complete reloading after receiving a `HUP`.
+   For more information, see the [issue](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4401).
 
 ## Troubleshooting
 

doc/administration/pages/source.md

@@ -343,21 +343,6 @@ world. Custom domains and TLS are supported.
 1. Restart NGINX
 1. [Restart GitLab][restart]
 
-## Change storage path
-
-Follow the steps below to change the default path where GitLab Pages' contents
-are stored.
-
-1. Pages are stored by default in `/var/opt/gitlab/gitlab-rails/shared/pages`.
-   If you wish to store them in another location you must set it up in
-   `/etc/gitlab/gitlab.rb`:
-
-   ```ruby
-   gitlab_rails['pages_path'] = "/mnt/storage/pages"
-   ```
-
-1. [Reconfigure GitLab][reconfigure]
-
 ## NGINX caveats
 
 >**Note:**
@@ -468,7 +453,6 @@ than GitLab to prevent XSS attacks.
 [NGINX configs]: https://gitlab.com/gitlab-org/gitlab-ee/tree/8-5-stable-ee/lib/support/nginx
 [pages-readme]: https://gitlab.com/gitlab-org/gitlab-pages/blob/master/README.md
 [pages-userguide]: ../../user/project/pages/index.md
-[reconfigure]: ../restart_gitlab.md#omnibus-gitlab-reconfigure
 [restart]: ../restart_gitlab.md#installations-from-source
 [gitlab-pages]: https://gitlab.com/gitlab-org/gitlab-pages/tree/v0.4.0
 [gl-example]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/support/init.d/gitlab.default.example

doc/administration/raketasks/github_import.md

 # GitHub import
 
->  [Introduced]( https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10308) in GitLab 9.1.
+> [Introduced]( https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10308) in GitLab 9.1.
 
 In order to retrieve and import GitHub repositories, you will need a
 [GitHub personal access token](https://github.com/settings/tokens).

doc/administration/raketasks/ldap.md

@@ -19,8 +19,6 @@ sudo gitlab-rake gitlab:ldap:check
 sudo -u git -H bundle exec rake gitlab:ldap:check RAILS_ENV=production
 ```
 
-------
-
 By default, the task will return a sample of 100 LDAP users. Change this
 limit by passing a number to the check task:
 
@@ -135,8 +133,6 @@ What is the old provider? Ex. 'ldapmain': ldapmain
 What is the new provider? Ex. 'ldapcustom': ldapmycompany
 ```
 
-------
-
 This tasks also accepts the `force` environment variable which will skip the
 confirmation dialog:
 

doc/administration/raketasks/maintenance.md

@@ -260,7 +260,7 @@ To check the status of migrations, you can use the following rake task:
 sudo gitlab-rake db:migrate:status
 ```
 
-This will output a table with a `Status` of `up` or `down` for 
+This will output a table with a `Status` of `up` or `down` for
 each Migration ID.
 
 ```bash
@@ -269,4 +269,4 @@ database: gitlabhq_production
  Status   Migration ID    Migration Name
 --------------------------------------------------
    up     migration_id    migration_name
-```
+```
\ No newline at end of file

doc/administration/raketasks/uploads/migrate.md

@@ -108,7 +108,7 @@ sudo -u git -H bundle exec rake "gitlab:uploads:migrate[FileUploader, MergeReque
 
 > Introduced in GitLab 12.3.
 
-To migrate all uploads created by legacy uploaders, run: 
+To migrate all uploads created by legacy uploaders, run:
 
 ```shell
 bundle exec rake gitlab:uploads:legacy:migrate

doc/administration/troubleshooting/elasticsearch.md

@@ -266,9 +266,9 @@ ElasticSearch administrator.
 
 Generally speaking, ensure:
 
-* The ElasticSearch server **is not** running on the same node as GitLab.
-* The ElasticSearch server have enough RAM and CPU cores.
-* That sharding **is** being used.
+- The ElasticSearch server **is not** running on the same node as GitLab.
+- The ElasticSearch server have enough RAM and CPU cores.
+- That sharding **is** being used.
 
 Going into some more detail here, if ElasticSearch is running on the same server as GitLab, resource contention is **very** likely to occur. Ideally, ElasticSearch, which requires ample resources, should be running on its own server (maybe coupled with logstash and kibana).
 

doc/administration/troubleshooting/sidekiq.md

@@ -96,8 +96,9 @@ corresponding Ruby code where this is happening.
 `gdb` can be another effective tool for debugging Sidekiq. It gives you a little
 more interactive way to look at each thread and see what's causing problems.
 
-> **Note:** Attaching to a process with `gdb` will suspends the normal operation
-  of the process (Sidekiq will not process jobs while `gdb` is attached).
+NOTE: **Note:**
+Attaching to a process with `gdb` will suspends the normal operation
+of the process (Sidekiq will not process jobs while `gdb` is attached).
 
 Start by attaching to the Sidekiq PID:
 
@@ -280,10 +281,10 @@ has number of drawbacks, as mentioned in [Why Ruby’s Timeout is dangerous (and
 
 > This is where the implications get interesting, and terrifying. This means that an exception can get raised:
 >
-> * during a network request (ok, as long as the surrounding code is prepared to catch Timeout::Error)
-> * during the cleanup for the network request
-> * during a rescue block
-> * while creating an object to save to the database afterwards
-> * in any of your code, regardless of whether it could have possibly raised an exception before
+> - during a network request (ok, as long as the surrounding code is prepared to catch Timeout::Error)
+> - during the cleanup for the network request
+> - during a rescue block
+> - while creating an object to save to the database afterwards
+> - in any of your code, regardless of whether it could have possibly raised an exception before
 >
 > Nobody writes code to defend against an exception being raised on literally any line. That’s not even possible. So Thread.raise is  basically like a sneak attack on your code that could result in almost anything. It would probably be okay if it were pure-functional code that did not modify any state. But this is Ruby, so that’s unlikely :)

doc/api/graphql/reference/index.md

@@ -516,4 +516,3 @@ The API can be explored interactively using the [GraphiQL IDE](../index.md#graph
 | `username` | String! |  |
 | `avatarUrl` | String! |  |
 | `webUrl` | String! |  |
-

doc/ci/directed_acyclic_graph/index.md

@@ -36,7 +36,7 @@ It has a pipeline that looks like the following:
 | ----- | ---- | ------ |
 | build_a | test_a | deploy_a |
 | build_b | test_b | deploy_b |
-| build_c | test_c | deploy_c | 
+| build_c | test_c | deploy_c |
 | build_d | test_d | deploy_d |
 
 Using a DAG, you can relate the `_a` jobs to each other separately from the `_b` jobs,

doc/ci/jenkins/index.md

@@ -32,7 +32,7 @@ There are some high level differences between the products worth mentioning:
 
 ## Groovy vs. YAML
 
-Jenkins Pipelines are based on [Groovy](https://groovy-lang.org/), so the pipeline specification is written as code. 
+Jenkins Pipelines are based on [Groovy](https://groovy-lang.org/), so the pipeline specification is written as code.
 GitLab works a bit differently, we use the more highly structured [YAML](https://yaml.org/) format, which
 places scripting elements inside of `script:` blocks separate from the pipeline specification itself.
 
@@ -56,7 +56,7 @@ rspec:
     - .in-docker
   script:
     - rake rspec
-```      
+```
 
 ## Artifact publishing
 
@@ -143,7 +143,7 @@ default:
 
 GitLab CI also lets you define stages, but is a little bit more free-form to configure. The GitLab [`stages` keyword](../yaml/README.md#stages)
 is a top level setting that enumerates the list of stages, but you are not required to nest individual jobs underneath
-the `stages` section. Any job defined in the `.gitlab-ci.yml` can be made a part of any stage through use of the 
+the `stages` section. Any job defined in the `.gitlab-ci.yml` can be made a part of any stage through use of the
 [`stage:` keyword](../yaml/README.md#stage).
 
 Note that, unless otherwise specified, every pipeline is instantiated with a `build`, `test`, and `deploy` stage
@@ -229,4 +229,4 @@ our very powerful [`only/except` rules system](../yaml/README.md#onlyexcept-basi
 ```yaml
 my_job:
   only: branches
-```
+```
\ No newline at end of file

doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md

@@ -141,4 +141,4 @@ please ask administrator to execute the following commands:
 > sudo gitlab-rails console                         # Login to Rails console of GitLab instance.
 > Feature.enabled?(:merge_trains_enabled)           # Check if it's enabled or not.
 > Feature.disable(:merge_trains_enabled)            # Disable the feature flag.
-```
+```
\ No newline at end of file

doc/ci/services/mysql.md

@@ -27,8 +27,8 @@ variables:
 
 NOTE: **Note:**
 The `MYSQL_DATABASE` and `MYSQL_ROOT_PASSWORD` variables can't be set in the GitLab UI.
-To set them, assign them to a variable [in the UI](../variables/README.md#via-the-ui), 
-and then assign that variable to the 
+To set them, assign them to a variable [in the UI](../variables/README.md#via-the-ui),
+and then assign that variable to the
 `MYSQL_DATABASE` and `MYSQL_ROOT_PASSWORD` variables in your `.gitlab-ci.yml`.
 
 And then configure your application to use the database, for example:

doc/ci/triggers/README.md

@@ -58,8 +58,7 @@ Read more about the [pipelines trigger API][trigapi].
 
 #### When a pipeline depends on the artifacts of another pipeline **(PREMIUM)**
 
-> The use of `CI_JOB_TOKEN` in the artifacts download API was [introduced][ee-2346]
-  in [GitLab Premium][ee] 9.5.
+> The use of `CI_JOB_TOKEN` in the artifacts download API was [introduced][ee-2346] in [GitLab Premium][ee] 9.5.
 
 With the introduction of dependencies between different projects, one of
 them may need to access artifacts created by a previous one. This process
@@ -271,7 +270,7 @@ Old triggers, created before GitLab 9.0 will be marked as legacy.
 
 Triggers with the legacy label do not have an associated user and only have
 access to the current project. They are considered deprecated and will be
-removed with one of the future versions of GitLab. 
+removed with one of the future versions of GitLab.
 
 [ee-2017]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2017
 [ee-2346]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2346

doc/development/contributing/index.md

@@ -65,7 +65,7 @@ Sign up for the mailing list, answer GitLab questions on StackOverflow or
 respond in the IRC channel. You can also sign up on [CodeTriage][codetriage] to help with
 the remaining issues on the GitHub issue tracker.
 
-## I want to contribute!
+## I want to contribute
 
 If you want to contribute to GitLab,
 [issues with the `Accepting merge requests` label](issue_workflow.md#label-for-community-contributors)

doc/development/documentation/styleguide.md

@@ -783,8 +783,6 @@ For multiple paragraphs, use the symbol `>` before every line:
 >
 > - This is a list item
 > - Second item in the list
->
-> ### This is an `h3`
 ```
 
 Which renders to:
@@ -795,9 +793,6 @@ Which renders to:
 >
 > - This is a list item
 > - Second item in the list
->
-> ### This is an `h3`
->{:.no_toc}
 
 ## Terms
 

doc/development/fe_guide/performance.md

@@ -81,7 +81,7 @@ bundle and included on the page.
 > can find this out by inspecting `document.body.dataset.page` within your
 > browser's developer console while on any page within gitlab.
 
-#### Important Considerations:
+#### Important Considerations
 
 - **Keep Entry Points Lite:**
   Page-specific javascript entry points should be as lite as possible.  These

doc/development/i18n/translation.md

@@ -92,4 +92,3 @@ To propose additions to the glossary please
 In French, the "écriture inclusive" is now over (see on [Legifrance](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000036068906&categorieLien=id)).
 So, to include both genders, write “Utilisateurs et utilisatrices” instead of “Utilisateur·rice·s”.
 When space is missing, the male gender should be used alone.
-

doc/development/new_fe_guide/dependencies.md

 # Dependencies
 
-## Adding Dependencies.
+## Adding Dependencies
 
 GitLab uses `yarn` to manage dependencies. These dependencies are defined in
 two groups within `package.json`, `dependencies` and `devDependencies`. For

doc/development/new_fe_guide/development/testing.md

@@ -3,4 +3,3 @@ redirect_to: '../../testing_guide/frontend_testing.md'
 ---
 
 This document was moved to [another location](../../testing_guide/frontend_testing.md).
-

doc/development/testing_guide/end_to_end/quick_start_guide.md

@@ -10,7 +10,7 @@ It's important to understand that end-to-end tests of isolated features, such as
 
 If you don't exactly understand what we mean by **not everything needs to happen through the GUI,** please make sure you've read the [best practices](best_practices.md) before moving on.
 
-## This document covers the following items:
+## This document covers the following items
 
 - [0.](#0-are-end-to-end-tests-needed) Identifying if end-to-end tests are really needed
 - [1.](#1-identifying-the-devops-stage) Identifying the [DevOps stage](https://about.gitlab.com/stages-devops-lifecycle/) of the feature that you are going to cover with end-to-end tests

doc/development/testing_guide/end_to_end/style_guide.md

@@ -141,4 +141,4 @@ Resource::MergeRequest.fabricate! do |merge_request_page|
 end
 ```
 
-> Besides the advantage of having a standard in place, by following this standard we also write shorter lines of code.
+> Besides the advantage of having a standard in place, by following this standard we also write shorter lines of code.
\ No newline at end of file

doc/development/testing_guide/review_apps.md

@@ -132,7 +132,7 @@ to prevent other pods from being scheduled on this node pool.
 This is to ensure Tiller isn't affected by "noisy" neighbors that could put
 their node under pressure.
 
-## How to:
+## How to
 
 ### Log into my Review App
 

doc/development/testing_guide/testing_levels.md

@@ -126,7 +126,7 @@ possible).
 | ---------- | -------------- | ----- |
 | `spec/features/` | [Capybara] + [RSpec] | If your test has the `:js` metadata, the browser driver will be [Poltergeist], otherwise it's using [RackTest]. |
 
-### Consider **not** writing a system test!
+### Consider **not** writing a system test
 
 If we're confident that the low-level components work well (and we should be if
 we have enough Unit & Integration tests), we shouldn't need to duplicate their

doc/user/project/operations/feature_flags.md

@@ -85,7 +85,7 @@ NOTE: **NOTE**
 We'd highly recommend you to use the [Environment](../../../ci/environments.md)
 feature in order to quickly assess which flag is enabled per environment.
 
-## Rollout Strategy
+## Rollout strategy
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/8240) in GitLab 12.2.
 
@@ -97,33 +97,38 @@ However, a feature will be enabled for 50% of logged-in users if the matching en
 
 ### All users
 
-Enables the feature for all users.
-
-**All users** is implemented using the Unleash [default](https://unleash.github.io/docs/activation_strategy#default) activation strategy.
+Enables the feature for all users. It is implemented using the Unleash
+[`default`](https://unleash.github.io/docs/activation_strategy#default)
+activation strategy.
 
 ### Percent rollout (logged in users)
 
-**Percent rollout (logged in users)** enables the feature for a percentage of authenticated users. Set a value of 15%, for example, to enable the feature for 15% of authenticated users.
+Enables the feature for a percentage of authenticated users. It is
+implemented using the Unleash
+[`gradualRolloutUserId`](https://unleash.github.io/docs/activation_strategy#gradualrolloutuserid)
+activation strategy.
+
+Set a value of 15%, for example, to enable the feature for 15% of authenticated users.
 
 A rollout percentage may be between 0% and 100%.
 
 CAUTION: **Caution:**
-If this strategy is selected, then the Unleash client **must** be given a user id for the feature to be enabled. See the [Ruby example](#ruby-application-example) below.
+If this strategy is selected, then the Unleash client **must** be given a user
+ID for the feature to be enabled. See the [Ruby example](#ruby-application-example) below.
 
-**Percent rollout (logged in users)** is implemented using the Unleash [gradualRolloutUserId](https://unleash.github.io/docs/activation_strategy#gradualrolloutuserid) activation strategy.
-
-## Target Users
+## Target users
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/8240) in GitLab 12.2.
 
-A feature flag may be enabled for a list of target users.
+A feature flag may be enabled for a list of target users. It is implemented
+using the Unleash [`userWithId`](https://unleash.github.io/docs/activation_strategy#userwithid)
+activation strategy.
 
 ![Feature flag target users](img/target_users_v12_2.png)
 
 CAUTION: **Caution:**
-The Unleash client **must** be given a user id for the feature to be enabled for target users. See the [Ruby example](#ruby-application-example) below.
-
-**Target users** is implemented using the Unleash [userWithId](https://unleash.github.io/docs/activation_strategy#userwithid) activation strategy.
+The Unleash client **must** be given a user ID for the feature to be enabled for
+target users. See the [Ruby example](#ruby-application-example) below.
 
 ## Integrating with your application