Add latest changes from gitlab-org/gitlab@13-2-stable-ee

20 files changed, 598 insertions, 147 deletions

diff --git a/doc/user/project/merge_requests/accessibility_testing.md b/doc/user/project/merge_requests/accessibility_testing.md
index 417b85a6082..f3a0aac9ff4 100644
--- a/doc/user/project/merge_requests/accessibility_testing.md
+++ b/doc/user/project/merge_requests/accessibility_testing.md
@@ -1,4 +1,7 @@
 ---
+stage: Verify
+group: Testing
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
 type: reference, howto
 ---
 
@@ -20,7 +23,10 @@ analyzed to a file called `accessibility`.
 
 ## Accessibility Merge Request widget
 
-[Since GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/39425), in addition to the report artifact that is created, GitLab will also show the
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/39425) in GitLab 13.0 behind the disabled [feature flag](../../../administration/feature_flags.md) `:accessibility_report_view`.
+> - [Feature Flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/217372) in GitLab 13.1.
+
+In addition to the report artifact that is created, GitLab will also show the
 Accessibility Report in the merge request widget area:
 
 ![Accessibility Merge Request Widget](img/accessibility_mr_widget_v13_0.png)
diff --git a/doc/user/project/merge_requests/browser_performance_testing.md b/doc/user/project/merge_requests/browser_performance_testing.md
index 390d480724d..10457e40e0b 100644
--- a/doc/user/project/merge_requests/browser_performance_testing.md
+++ b/doc/user/project/merge_requests/browser_performance_testing.md
@@ -1,4 +1,7 @@
 ---
+stage: Verify
+group: Testing
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
 type: reference, howto
 ---
 
@@ -7,20 +10,16 @@ type: reference, howto
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3507) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.3.
 
 If your application offers a web interface and you're using
-[GitLab CI/CD](../../../ci/README.md), you can quickly determine the performance
-impact of pending code changes.
+[GitLab CI/CD](../../../ci/README.md), you can quickly determine the rendering performance
+impact of pending code changes in the browser.
 
 ## Overview
 
 GitLab uses [Sitespeed.io](https://www.sitespeed.io), a free and open source
-tool, for measuring the performance of web sites. GitLab has built a simple
-[Sitespeed plugin](https://gitlab.com/gitlab-org/gl-performance) which outputs
-the performance score for each page analyzed in a file called `performance.json`.
-The [Sitespeed.io performance score](https://examples.sitespeed.io/6.0/2017-11-23-23-43-35/help.html)
-is a composite value based on best practices.
-
-GitLab can [show the Performance report](#how-browser-performance-testing-works)
-in the merge request widget area.
+tool, for measuring the rendering performance of web sites. The
+[Sitespeed plugin](https://gitlab.com/gitlab-org/gl-performance) that GitLab built outputs
+the performance score for each page analyzed in a file called `browser-performance.json`
+this data can be shown on Merge Requests.
 
 ## Use cases
 
@@ -38,7 +37,7 @@ Consider the following workflow:
 ## How browser performance testing works
 
 First, define a job in your `.gitlab-ci.yml` file that generates the
-[Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsperformance-premium).
+[Browser Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsperformance-premium).
 GitLab then checks this report, compares key performance metrics for each page
 between the source and target branches, and shows the information in the merge request.
 
@@ -46,12 +45,13 @@ For an example Performance job, see
 [Configuring Browser Performance Testing](#configuring-browser-performance-testing).
 
 NOTE: **Note:**
-If the Performance report has no data to compare, such as when you add the
-Performance job in your `.gitlab-ci.yml` for the very first time, no information
-displays in the merge request widget area. Consecutive merge requests will have data for
-comparison, and the Performance report will be shown properly.
+If the Browser Performance report has no data to compare, such as when you add the
+Browser Performance job in your `.gitlab-ci.yml` for the very first time,
+the Browser Performance report widget won't show. It must have run at least
+once on the target branch (`master`, for example), before it will display in a
+merge request targeting that branch.
 
-![Performance Widget](img/browser_performance_testing.png)
+![Browser Performance Widget](img/browser_performance_testing.png)
 
 ## Configuring Browser Performance Testing
 
@@ -61,21 +61,7 @@ using Docker-in-Docker.
 
 1. First, set up GitLab Runner with a
    [Docker-in-Docker build](../../../ci/docker/using_docker_build.md#use-docker-in-docker-workflow-with-docker-executor).
-1. After configuring the Runner, add a new job to `.gitlab-ci.yml` that generates
-   the expected report.
-1. Define the `performance` job according to your version of GitLab:
-
-   - For GitLab 12.4 and later - [include](../../../ci/yaml/README.md#includetemplate) the
-     [`Browser-Performance.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Verify/Browser-Performance.gitlab-ci.yml) provided as a part of your GitLab installation.
-   - For GitLab versions earlier than 12.4 - Copy and use the job as defined in the
-     [`Browser-Performance.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Verify/Browser-Performance.gitlab-ci.yml).
-
-   CAUTION: **Caution:**
-   The job definition provided by the template does not support Kubernetes yet.
-   For a complete example of a more complex setup that works in Kubernetes, see
-   [`Browser-Performance-Testing.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Browser-Performance-Testing.gitlab-ci.yml).
-
-1. Add the following to your `.gitlab-ci.yml` file:
+1. Configure the default Browser Performance Testing CI job as follows in your `.gitlab-ci.yml` file:
 
    ```yaml
    include:
@@ -86,24 +72,32 @@ using Docker-in-Docker.
        URL: https://example.com
    ```
 
-   CAUTION: **Caution:**
-   The job definition provided by the template is supported in GitLab 11.5 and later versions.
-   It also requires GitLab Runner 11.5 or later. For earlier versions, use the
-   [previous job definitions](#previous-job-definitions).
+NOTE: **Note:**
+For versions before 12.4, see the information for [older GitLab versions](#gitlab-versions-123-and-older).
+If you are using a Kubernetes cluster, use [`template: Jobs/Browser-Performance-Testing.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Browser-Performance-Testing.gitlab-ci.yml)
+instead.
 
 The above example creates a `performance` job in your CI/CD pipeline and runs
 sitespeed.io against the webpage you defined in `URL` to gather key metrics.
-The [GitLab plugin for sitespeed.io](https://gitlab.com/gitlab-org/gl-performance)
-is downloaded to save the report as a [Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsperformance-premium)
-that you can later download and analyze. Due to implementation limitations, we always
-take the latest Performance artifact available.
 
-The full HTML sitespeed.io report is saved as an artifact, and if
-[GitLab Pages](../pages/index.md) is enabled, it can be viewed directly in your browser.
+The example uses a CI/CD template that is included in all GitLab installations since
+12.4, but it will not work with Kubernetes clusters. If you are using GitLab 12.3
+or older, you must [add the configuration manually](#gitlab-versions-123-and-older)
+
+The template uses the [GitLab plugin for sitespeed.io](https://gitlab.com/gitlab-org/gl-performance),
+and it saves the full HTML sitespeed.io report as a [Browser Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsperformance-premium)
+that you can later download and analyze. This implementation always takes the latest
+Browser Performance artifact available. If [GitLab Pages](../pages/index.md) is enabled,
+you can view the report directly in your browser.
+
+You can also customize the jobs with environment variables:
+
+- `SITESPEED_IMAGE`: Configure the Docker image to use for the job (default `sitespeedio/sitespeed.io`), but not the image version.
+- `SITESPEED_VERSION`: Configure the version of the Docker image to use for the job (default `13.3.0`).
+- `SITESPEED_OPTIONS`: Configure any additional sitespeed.io options as required (default `nil`). Refer to the [sitespeed.io documentation](https://www.sitespeed.io/documentation/sitespeed.io/configuration/) for more details.
 
-You can also customize options by setting the `SITESPEED_OPTIONS` variable.
 For example, you can override the number of runs sitespeed.io
-makes on the given URL:
+makes on the given URL, and change the version:
 
 ```yaml
 include:
@@ -111,18 +105,11 @@ include:
 
 performance:
   variables:
-    URL: https://example.com
+    URL: https://www.sitespeed.io/
+    SITESPEED_VERSION: 13.2.0
     SITESPEED_OPTIONS: -n 5
 ```
 
-For further customization options for sitespeed.io, including the ability to provide a
-list of URLs to test, please see the
-[Sitespeed.io Configuration](https://www.sitespeed.io/documentation/sitespeed.io/configuration/)
-documentation.
-
-TIP: **Tip:**
-Key metrics are automatically extracted and shown in the merge request widget.
-
 ### Configuring degradation threshold
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27599) in GitLab 13.0.
@@ -149,15 +136,12 @@ The above CI YAML configuration is great for testing against static environments
 be extended for dynamic environments, but a few extra steps are required:
 
 1. The `performance` job should run after the dynamic environment has started.
-1. In the `review` job, persist the hostname and upload it as an artifact so
-   it's available to the `performance` job. The same can be done for static
-   environments like staging and production to unify the code path. You can save it
-   as an artifact with `echo $CI_ENVIRONMENT_URL > environment_url.txt`
-   in your job's `script`.
-1. In the `performance` job, read the previous artifact into an environment
-   variable. In this case, use `$URL` because the sitespeed.io command
-   uses it for the URL parameter. Because Review App URLs are dynamic, define
-   the `URL` variable through `before_script` instead of `variables`.
+1. In the `review` job:
+    1. Generate a URL list file with the dynamic URL.
+    1. Save the file as an artifact, for example with `echo $CI_ENVIRONMENT_URL > environment_url.txt`
+    in your job's `script`.
+    1. Pass the list as the URL environment variable (which can be a URL or a file containing URLs)
+    to the `performance` job.
 1. You can now run the sitespeed.io container against the desired hostname and
    paths.
 
@@ -190,20 +174,21 @@ review:
 performance:
   dependencies:
     - review
-  before_script:
-    - export URL=$(cat environment_url.txt)
+  variables:
+    URL: environment_url.txt
 ```
 
-### Previous job definitions
+### GitLab versions 12.3 and older
 
-CAUTION: **Caution:**
-Before GitLab 11.5, the Performance job and artifact had to be named specifically
-to automatically extract report data and show it in the merge request widget.
-While these old job definitions are still maintained, they have been deprecated
-and may be removed in next major release, GitLab 12.0.
-GitLab recommends you update your current `.gitlab-ci.yml` configuration to reflect that change.
+Browser Performance Testing has gone through several changes since it's introduction.
+In this section we'll detail these changes and how you can run the test based on your
+GitLab version:
 
-For GitLab 11.4 and earlier, the job should look like:
+- In GitLab 12.4 [a job template was made available](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Verify/Browser-Performance.gitlab-ci.yml).
+- In 13.2 the feature was renamed from `Performance` to `Browser Performance` with
+additional template variables. The job name in the template is still `performance`
+for compatibility reasons, but may be renamed to match in a future iteration.
+- For 11.5 to 12.3 no template is available and the job has to be defined manually as follows:
 
 ```yaml
 performance:
@@ -211,28 +196,45 @@ performance:
   image: docker:git
   variables:
     URL: https://example.com
+    SITESPEED_VERSION: 13.3.0
+    SITESPEED_OPTIONS: ''
   services:
     - docker:stable-dind
   script:
     - mkdir gitlab-exporter
     - wget -O ./gitlab-exporter/index.js https://gitlab.com/gitlab-org/gl-performance/raw/master/index.js
     - mkdir sitespeed-results
-    - docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:6.3.1 --plugins.add ./gitlab-exporter --outputFolder sitespeed-results $URL
+    - docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:$SITESPEED_VERSION --plugins.add ./gitlab-exporter --outputFolder sitespeed-results $URL $SITESPEED_OPTIONS
     - mv sitespeed-results/data/performance.json performance.json
   artifacts:
     paths:
       - performance.json
       - sitespeed-results/
+    reports:
+      performance: performance.json
 ```
 
-<!-- ## Troubleshooting
+- For 11.4 and earlier the job should be defined as follows:
 
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-questions that you know someone might ask.
+```yaml
+performance:
+  stage: performance
+  image: docker:git
+  variables:
+    URL: https://example.com
+  services:
+    - docker:stable-dind
+  script:
+    - mkdir gitlab-exporter
+    - wget -O ./gitlab-exporter/index.js https://gitlab.com/gitlab-org/gl-performance/raw/master/index.js
+    - mkdir sitespeed-results
+    - docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:6.3.1 --plugins.add ./gitlab-exporter --outputFolder sitespeed-results $URL
+    - mv sitespeed-results/data/performance.json performance.json
+  artifacts:
+    paths:
+      - performance.json
+      - sitespeed-results/
+```
 
-Each scenario can be a third-level heading, e.g. `### Getting error message X`.
-If you have none to add when creating a doc, leave this section in place
-but commented out to help encourage others to add to it in the future. -->
+Upgrading to the latest version and using the templates is recommended, to ensure
+you receive the latest updates, including updates to the sitespeed.io versions.
diff --git a/doc/user/project/merge_requests/code_quality.md b/doc/user/project/merge_requests/code_quality.md
index 7b4d4b668d5..36acba032ff 100644
--- a/doc/user/project/merge_requests/code_quality.md
+++ b/doc/user/project/merge_requests/code_quality.md
@@ -1,8 +1,11 @@
 ---
+stage: Verify
+group: Testing
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
 type: reference, howto
 ---
 
-# Code Quality **(STARTER)**
+# Code Quality
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1984) in [GitLab Starter](https://about.gitlab.com/pricing/) 9.3.
 
@@ -22,8 +25,13 @@ Code Quality:
   DevOps](../../../topics/autodevops/stages.md#auto-code-quality-starter).
 - Can be extended through [Analysis Plugins](https://docs.codeclimate.com/docs/list-of-engines) or a [custom tool](#implementing-a-custom-tool).
 
+## Code Quality Widget
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1984) in [GitLab Starter](https://about.gitlab.com/pricing/) 9.3.
+> - Made [available in all tiers](https://gitlab.com/gitlab-org/gitlab/-/issues/212499) in 13.2.
+
 Going a step further, GitLab can show the Code Quality report right
-in the merge request widget area:
+in the merge request widget area if a report from the target branch is available to compare to:
 
 ![Code Quality Widget](img/code_quality.png)
 
@@ -79,7 +87,7 @@ include:
 
 The above example will create a `code_quality` job in your CI/CD pipeline which
 will scan your source code for code quality issues. The report will be saved as a
-[Code Quality report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportscodequality-starter)
+[Code Quality report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportscodequality)
 that you can later download and analyze.
 
 It's also possible to override the URL to the Code Quality image by
@@ -237,7 +245,7 @@ do this:
 
 1. Define a job in your `.gitlab-ci.yml` file that generates the
    [Code Quality report
-   artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportscodequality-starter).
+   artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportscodequality).
 1. Configure your tool to generate the Code Quality report artifact as a JSON
    file that implements a subset of the [Code Climate
    spec](https://github.com/codeclimate/platform/blob/master/spec/analyzers/SPEC.md#data-types).
@@ -273,11 +281,11 @@ NOTE: **Note:**
 Although the Code Climate spec supports more properties, those are ignored by
 GitLab.
 
-## Code Quality reports
+## Code Quality reports **(STARTER)**
 
 Once the Code Quality job has completed:
 
-- The full list of code quality violations generated by a pipeline is available in the
+- The full list of code quality violations generated by a pipeline is shown in the
   Code Quality tab of the Pipeline Details page.
 - Potential changes to code quality are shown directly in the merge request.
   The Code Quality widget in the merge request compares the reports from the base and head of the branch,
@@ -286,8 +294,43 @@ Once the Code Quality job has completed:
   [downloadable artifact](../../../ci/pipelines/job_artifacts.md#downloading-artifacts)
   for the `code_quality` job.
 
+## Extending functionality
+
+### Using Analysis Plugins
+
+Should there be a need to extend the default functionality provided by Code Quality, as stated in [Code Quality](#code-quality), [Analysis Plugins](https://docs.codeclimate.com/docs/list-of-engines) are available.
+
+For example, to use the [SonarJava analyzer](https://docs.codeclimate.com/docs/sonar-java),
+add a file named `.codeclimate.yml` containing the [enablement code](https://docs.codeclimate.com/docs/sonar-java#enable-the-plugin)
+for the plugin to the root of your repository:
+
+```yaml
+version: "2"
+plugins:
+  sonar-java:
+    enabled: true
+```
+
+This adds SonarJava to the `plugins:` section of the [default `.codeclimate.yml`](https://gitlab.com/gitlab-org/ci-cd/codequality/-/blob/master/codeclimate_defaults/.codeclimate.yml)
+included in your project.
+
+Changes to the `plugins:` section do not affect the `exclude_patterns` section of the
+defeault `.codeclimate.yml`. See the Code Climate documentation for
+[excluding files and folders](https://docs.codeclimate.com/docs/excluding-files-and-folders)
+for more details.
+
+Here's [an example project](https://gitlab.com/jheimbuck_gl/jh_java_example_project) that uses Code Quality with a `.codeclimate.yml` file.
+
 ## Troubleshooting
 
+### Changing the default configuration has no effect
+
+A common issue is that the terms `Code Quality` (GitLab specific) and `Code Climate`
+(Engine used by GitLab) are very similar. You must add a **`.codeclimate.yml`** file
+to change the default configuration, **not** a `.codequality.yml` file. If you use
+the wrong filename, the [default `.codeclimate.yml`](https://gitlab.com/gitlab-org/ci-cd/codequality/-/blob/master/codeclimate_defaults/.codeclimate.yml)
+is still used.
+
 ### No Code Quality report is displayed in a Merge Request
 
 This can be due to multiple reasons:
@@ -295,6 +338,7 @@ This can be due to multiple reasons:
 - You just added the Code Quality job in your `.gitlab-ci.yml`. The report does not
   have anything to compare to yet, so no information can be displayed. Future merge
   requests will have something to compare to.
+- Your pipeline is not set to run the code quality job on your default branch. If there is no report generated from the default branch, your MR branch reports will not have anything to compare to.
 - If no [degradation or error is detected](https://docs.codeclimate.com/docs/maintainability#section-checks),
   nothing will be displayed.
 - The [`artifacts:expire_in`](../../../ci/yaml/README.md#artifactsexpire_in) CI/CD
diff --git a/doc/user/project/merge_requests/fail_fast_testing.md b/doc/user/project/merge_requests/fail_fast_testing.md
new file mode 100644
index 00000000000..619a6d04577
--- /dev/null
+++ b/doc/user/project/merge_requests/fail_fast_testing.md
@@ -0,0 +1,87 @@
+---
+stage: Verify
+group: Testing
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+type: reference, howto
+---
+
+# Fail Fast Testing **(PREMIUM)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/198550) in GitLab 13.1.
+
+For applications that use RSpec for running tests, we've introduced the `Verify/Failfast`
+[template to run subsets of your test suite](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Verify/FailFast.gitlab-ci.yml),
+based on the changes in your merge request.
+
+The template uses the [test_file_finder (`tff`) gem](https://gitlab.com/gitlab-org/ci-cd/test_file_finder/)
+that accepts a list of files as input, and returns a list of spec (test) files
+that it believes to be relevant to the input files.
+
+`tff` is designed for Ruby on Rails projects, so the `Verify/FailFast` template is
+configured to run when changes to Ruby files are detected. By default, it runs in
+the [`.pre` stage](../../../ci/yaml/README.md#pre-and-post) of a GitLab CI/CD pipeline,
+before all other stages.
+
+## Example use case
+
+Fail fast testing is useful when adding new functionality to a project and adding
+new automated tests.
+
+Your project could have hundreds of thousands of tests that take a long time to complete.
+You may be confident that a new test will pass, but you have to wait for all the tests
+to complete to verify it. This could take an hour or more, even when using parallelization.
+
+Fail fast testing gives you a faster feedback loop from the pipeline. It lets you
+know quickly that the new tests are passing and the new functionality did not break
+other tests.
+
+## Requirements
+
+This template requires:
+
+- A project built in Rails that uses RSpec for testing.
+- CI/CD configured to:
+  - Use a Docker image with Ruby available.
+  - Use [Pipelines for Merge Requests](../../../ci/merge_request_pipelines/index.md#configuring-pipelines-for-merge-requests)
+- [Pipelines for Merged Results](../../../ci/merge_request_pipelines/pipelines_for_merged_results/index.md#enable-pipelines-for-merged-results)
+  enabled in the project settings.
+
+## Configure Fast RSpec Failure
+
+We'll use the following plain RSpec configuration as a starting point. It installs all the
+project gems and executes `rspec`, on merge request pipelines only.
+
+```yaml
+rspec-complete:
+  stage: test
+  rules:
+    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
+  script:
+    - bundle install
+    - bundle exec rspec
+```
+
+To run the most relevant specs first instead of the whole suite, [`include`](../../../ci/yaml/README.md#include)
+the template by adding the following to your CI/CD configuration:
+
+```yaml
+include:
+  - template: Verify/FailFast.gitlab-ci.yml
+```
+
+### Example test loads
+
+For illustrative purposes, let's say our Rails app spec suite consists of 100 specs per model for ten models.
+
+If no Ruby files are changed:
+
+- `rspec-rails-modified-paths-specs` will not run any tests.
+- `rspec-complete` will run the full suite of 1000 tests.
+
+If one Ruby model is changed, for example `app/models/example.rb`, then `rspec-rails-modified-paths-specs`
+will run the 100 tests for `example.rb`:
+
+- If all of these 100 tests pass, then the full `rspec-complete` suite of 1000 tests is allowed to run.
+- If any of these 100 tests fail, they will fail quickly, and `rspec-complete` will not run any tests.
+
+The final case saves resources and time as the full 1000 test suite does not run.
diff --git a/doc/user/project/merge_requests/getting_started.md b/doc/user/project/merge_requests/getting_started.md
index 32eb0c73ed4..9ac0f3ee42e 100644
--- a/doc/user/project/merge_requests/getting_started.md
+++ b/doc/user/project/merge_requests/getting_started.md
@@ -57,7 +57,7 @@ request's page at the top-right side:
 - [Close issues automatically](#merge-requests-to-close-issues) when they are merged.
 - Enable the [delete source branch when merge request is accepted](#deleting-the-source-branch) option to keep your repository clean.
 - Enable the [squash commits when merge request is accepted](squash_and_merge.md) option to combine all the commits into one before merging, thus keep a clean commit history in your repository.
-- Set the merge request as a [Work In Progress (WIP)](work_in_progress_merge_requests.md) to avoid accidental merges before it is ready.
+- Set the merge request as a [**Draft**](work_in_progress_merge_requests.md) to avoid accidental merges before it is ready.
 
 Once you have created the merge request, you can also:
 
diff --git a/doc/user/project/merge_requests/img/browser_performance_testing.png b/doc/user/project/merge_requests/img/browser_performance_testing.png
index eea77fb8b93..c270462f7a8 100644
--- a/doc/user/project/merge_requests/img/browser_performance_testing.png
+++ b/doc/user/project/merge_requests/img/browser_performance_testing.png
diff --git a/doc/user/project/merge_requests/img/draft_blocked_merge_button_v13_2.png b/doc/user/project/merge_requests/img/draft_blocked_merge_button_v13_2.png
new file mode 100644
index 00000000000..beb12c581d6
--- /dev/null
+++ b/doc/user/project/merge_requests/img/draft_blocked_merge_button_v13_2.png
diff --git a/doc/user/project/merge_requests/img/file_by_file_v13_2.png b/doc/user/project/merge_requests/img/file_by_file_v13_2.png
new file mode 100644
index 00000000000..e3114ebabad
--- /dev/null
+++ b/doc/user/project/merge_requests/img/file_by_file_v13_2.png
diff --git a/doc/user/project/merge_requests/img/load_performance_testing.png b/doc/user/project/merge_requests/img/load_performance_testing.png
new file mode 100644
index 00000000000..3a58e9c28d4
--- /dev/null
+++ b/doc/user/project/merge_requests/img/load_performance_testing.png
diff --git a/doc/user/project/merge_requests/img/merge_when_pipeline_succeeds_only_if_succeeds_msg.png b/doc/user/project/merge_requests/img/merge_when_pipeline_succeeds_only_if_succeeds_msg.png
deleted file mode 100644
index 761690d1e0c..00000000000
--- a/doc/user/project/merge_requests/img/merge_when_pipeline_succeeds_only_if_succeeds_msg.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/wip_blocked_accept_button.png b/doc/user/project/merge_requests/img/wip_blocked_accept_button.png
deleted file mode 100644
index ab2c8425b83..00000000000
--- a/doc/user/project/merge_requests/img/wip_blocked_accept_button.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/index.md b/doc/user/project/merge_requests/index.md
index 5d2813f5bfc..f68fc7d7b45 100644
--- a/doc/user/project/merge_requests/index.md
+++ b/doc/user/project/merge_requests/index.md
@@ -19,7 +19,7 @@ A. Consider you're a software developer working in a team:
 
 1. You checkout a new branch, and submit your changes through a merge request
 1. You gather feedback from your team
-1. You work on the implementation optimizing code with [Code Quality reports](code_quality.md) **(STARTER)**
+1. You work on the implementation optimizing code with [Code Quality reports](code_quality.md)
 1. You verify your changes with [JUnit test reports](../../../ci/junit_test_reports.md) in GitLab CI/CD
 1. You avoid using dependencies whose license is not compatible with your project with [License Compliance reports](../../compliance/license_compliance/index.md) **(ULTIMATE)**
 1. You request the [approval](merge_request_approvals.md) from your manager **(STARTER)**
diff --git a/doc/user/project/merge_requests/load_performance_testing.md b/doc/user/project/merge_requests/load_performance_testing.md
new file mode 100644
index 00000000000..3239269109d
--- /dev/null
+++ b/doc/user/project/merge_requests/load_performance_testing.md
@@ -0,0 +1,197 @@
+---
+stage: Verify
+group: Testing
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+type: reference, howto
+---
+
+# Load Performance Testing **(PREMIUM)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10683) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.2.
+
+With Load Performance Testing, you can test the impact of any pending code changes
+to your application's backend in [GitLab CI/CD](../../../ci/README.md).
+
+GitLab uses [k6](https://k6.io/), a free and open source
+tool, for measuring the system performance of applications under
+load.
+
+Unlike [Browser Performance Testing](browser_performance_testing.md), which is
+used to measure how web sites perform in client browsers, Load Performance Testing
+can be used to perform various types of [load tests](https://k6.io/docs/#use-cases)
+against application endpoints such as APIs, Web Controllers, and so on.
+This can be used to test how the backend or the server performs at scale.
+
+For example, you can use Load Performance Testing to perform many concurrent
+GET calls to a popular API endpoint in your application to see how it performs.
+
+## How Load Performance Testing works
+
+First, define a job in your `.gitlab-ci.yml` file that generates the
+[Load Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsload_performance-premium).
+GitLab checks this report, compares key load performance metrics
+between the source and target branches, and then shows the information in a merge request widget:
+
+![Load Performance Widget](img/load_performance_testing.png)
+
+Next, you need to configure the test environment and write the k6 test.
+
+The key performance metrics that the merge request widget shows after the test completes are:
+
+- Checks: The percentage pass rate of the [checks](https://k6.io/docs/using-k6/checks) configured in the k6 test.
+- TTFB P90: The 90th percentile of how long it took to start receiving responses, aka the [Time to First Byte](https://en.wikipedia.org/wiki/Time_to_first_byte) (TTFB).
+- TTFB P95: The 95th percentile for TTFB.
+- RPS: The average requests per second (RPS) rate the test was able to achieve.
+
+NOTE: **Note:**
+If the Load Performance report has no data to compare, such as when you add the
+Load Performance job in your `.gitlab-ci.yml` for the very first time,
+the Load Performance report widget won't show. It must have run at least
+once on the target branch (`master`, for example), before it will display in a
+merge request targeting that branch.
+
+## Configure the Load Performance Testing job
+
+Configuring your Load Performance Testing job can be broken down into several distinct parts:
+
+- Determine the test parameters such as throughput, and so on.
+- Set up the target test environment for load performance testing.
+- Design and write the k6 test.
+
+### Determine the test parameters
+
+The first thing you need to do is determine the [type of load test](https://k6.io/docs/test-types/introduction)
+you want to run, and how it will run (for example, the number of users, throughput, and so on).
+
+Refer to the [k6 docs](https://k6.io/docs/), especially the [k6 testing guides](https://k6.io/docs/testing-guides),
+for guidance on the above and more.
+
+### Test Environment setup
+
+A large part of the effort around load performance testing is to prepare the target test environment
+for high loads. You should ensure it's able to handle the
+[throughput](https://k6.io/blog/monthly-visits-concurrent-users) it will be tested with.
+
+It's also typically required to have representative test data in the target environment
+for the load performance test to use.
+
+We strongly recommend [not running these tests against a production environment](https://k6.io/our-beliefs#load-test-in-a-pre-production-environment).
+
+### Write the load performance test
+
+After the environment is prepared, you can write the k6 test itself. k6 is a flexible
+tool and can be used to run [many kinds of performance tests](https://k6.io/docs/test-types/introduction).
+Refer to the [k6 documentation](https://k6.io/docs/) for detailed information on how to write tests.
+
+### Configure the test in GitLab CI/CD
+
+When your k6 test is ready, the next step is to configure the load performance
+testing job in GitLab CI/CD. The easiest way to do this is to use the
+[`Verify/Load-Performance-Testing.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Verify/Load-Performance-Testing.gitlab-ci.yml)
+template that is included with GitLab.
+
+NOTE: **Note:**
+For large scale k6 tests you need to ensure the GitLab Runner instance performing the actual
+test is able to handle running the test. Refer to [k6's guidance](https://k6.io/docs/testing-guides/running-large-tests#hardware-considerations)
+for spec details. The [default shared GitLab.com runners](../../gitlab_com/#linux-shared-runners)
+likely have insufficient specs to handle most large k6 tests.
+
+This template runs the
+[k6 Docker container](https://hub.docker.com/r/loadimpact/k6/) in the job and provides several ways to customize the
+job.
+
+An example configuration workflow:
+
+1. Set up a GitLab Runner that can run Docker containers, such as a Runner using the
+   [Docker-in-Docker workflow](../../../ci/docker/using_docker_build.md#use-docker-in-docker-workflow-with-docker-executor).
+1. Configure the default Load Performance Testing CI job in your `.gitlab-ci.yml` file.
+   You need to include the template and configure it with variables:
+
+   ```yaml
+   include:
+     template: Verify/Load-Performance-Testing.gitlab-ci.yml
+
+   load_performance:
+     variables:
+       K6_TEST_FILE: <PATH TO K6 TEST FILE IN PROJECT>
+   ```
+
+The above example creates a `load_performance` job in your CI/CD pipeline that runs
+the k6 test.
+
+NOTE: **Note:**
+For Kubernetes setups a different template should be used: [`Jobs/Load-Performance-Testing.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Load-Performance-Testing.gitlab-ci.yml).
+
+k6 has [various options](https://k6.io/docs/using-k6/options) to configure how it will run tests, such as what throughput (RPS) to run with,
+how long the test should run, and so on. Almost all options can be configured in the test itself, but as
+you can also pass command line options via the `K6_OPTIONS` variable.
+
+For example, you can override the duration of the test with a CLI option:
+
+```yaml
+  include:
+    template: Verify/Load-Performance-Testing.gitlab-ci.yml
+
+  load_performance:
+    variables:
+      K6_TEST_FILE: <PATH TO K6 TEST FILE IN PROJECT>
+      K6_OPTIONS: '--duration 30s'
+```
+
+GitLab only displays the key performance metrics in the MR widget if k6's results are saved
+via [summary export](https://k6.io/docs/results-visualization/json#summary-export)
+as a [Load Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsload_performance-premium).
+The latest Load Performance artifact available is always used.
+
+If [GitLab Pages](../pages/index.md) is enabled, you can view the report directly in your browser.
+
+### Load Performance testing in Review Apps
+
+The CI/CD YAML configuration example above works for testing against static environments,
+but it can be extended to work with [review apps](../../../ci/review_apps) or
+[dynamic environments](../../../ci/environments) with a few extra steps.
+
+The best approach is to capture the dynamic URL into a custom environment variable that
+is then [inherited](../../../ci/variables/README.md#inherit-environment-variables)
+by the `load_performance` job. The k6 test script to be run should then be configured to
+use that environment URL, such as: ``http.get(`${__ENV.ENVIRONMENT_URL`})``.
+
+For example:
+
+1. In the `review` job:
+    1. Capture the dynamic URL and save it into a `.env` file, e.g. `echo "ENVIRONMENT_URL=$CI_ENVIRONMENT_URL" >> review.env`.
+    1. Set the `.env` file to be an [`artifacts:reports:dotenv` report](../../../ci/variables/README.md#inherit-environment-variables).
+1. Set the `load_performance` job to depend on the review job, so it inherits the environment variable.
+1. Configure the k6 test script to use the environment variable in it's steps.
+
+Your `.gitlab-ci.yml` file might be similar to:
+
+```yaml
+stages:
+  - deploy
+  - performance
+
+include:
+  template: Verify/Load-Performance-Testing.gitlab-ci.yml
+
+review:
+  stage: deploy
+  environment:
+    name: review/$CI_COMMIT_REF_NAME
+    url: http://$CI_ENVIRONMENT_SLUG.example.com
+  script:
+    - run_deploy_script
+    - echo "ENVIRONMENT_URL=$CI_ENVIRONMENT_URL" >> review.env
+  artifacts:
+    reports:
+      dotenv:
+        review.env
+  rules:
+    - if: '$CI_COMMIT_BRANCH'  # Modify to match your pipeline rules, or use `only/except` if needed.
+
+load_performance:
+  dependencies:
+    - review
+  rules:
+    - if: '$CI_COMMIT_BRANCH'  # Modify to match your pipeline rules, or use `only/except` if needed.
+```
diff --git a/doc/user/project/merge_requests/merge_request_dependencies.md b/doc/user/project/merge_requests/merge_request_dependencies.md
index a1012e27d32..65f3cb1e0d5 100644
--- a/doc/user/project/merge_requests/merge_request_dependencies.md
+++ b/doc/user/project/merge_requests/merge_request_dependencies.md
@@ -38,15 +38,15 @@ the `awesome-project` merge request before the `awesome-lib` one would
 break the `master`branch.
 
 The `awesome-project` merge request could be [marked as
-WIP](work_in_progress_merge_requests.md),
-and the reason for the WIP stated included in the comments. However, this
+**Draft**](work_in_progress_merge_requests.md),
+and the reason for the draft stated included in the comments. However, this
 requires the state of the `awesome-lib` merge request to be manually
 tracked, and doesn't scale well if the `awesome-project` merge request
 depends on changes to **several** other projects.
 
 By making the `awesome-project` merge request depend on the
 `awesome-lib` merge request instead, this relationship is
-automatically tracked by GitLab, and the WIP state can be used to
+automatically tracked by GitLab, and the draft state can be used to
 communicate the readiness of the code in each individual merge request
 instead.
 
diff --git a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
index d45ccdc9be9..7d90c9f3cd7 100644
--- a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
+++ b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
@@ -1,36 +1,38 @@
 ---
+stage: Create
+group: Source Code
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
 type: reference, concepts
 ---
 
 # Merge when pipeline succeeds
 
-When reviewing a merge request that looks ready to merge but still has one or
-more CI jobs running, you can set it to be merged automatically when the
-jobs pipeline succeeds. This way, you don't have to wait for the jobs to
+When reviewing a merge request that looks ready to merge but still has a
+pipeline running, you can set it to merge automatically when the
+pipeline succeeds. This way, you don't have to wait for the pipeline to
 finish and remember to merge the request manually.
 
 ![Enable](img/merge_when_pipeline_succeeds_enable.png)
 
 ## How it works
 
-When you hit the "Merge When Pipeline Succeeds" button, the status of the merge
-request will be updated to represent the impending merge. If you cannot wait
-for the pipeline to succeed and want to merge immediately, this option is
-available in the dropdown menu on the right of the main button.
+When you click "Merge When Pipeline Succeeds", the status of the merge
+request is updated to show the impending merge. If you can't wait
+for the pipeline to succeed, you can choose **Merge immediately**
+in the dropdown menu on the right of the main button.
 
-Both team developers and the author of the merge request have the option to
-cancel the automatic merge if they find a reason why it shouldn't be merged
-after all.
+The author of the merge request and project members with developer permissions can
+cancel the automatic merge at any time before the pipeline finishes.
 
 ![Status](img/merge_when_pipeline_succeeds_status.png)
 
-When the pipeline succeeds, the merge request will automatically be merged.
+When the pipeline succeeds, the merge request is automatically merged.
 When the pipeline fails, the author gets a chance to retry any failed jobs,
 or to push new commits to fix the failure.
 
 When the jobs are retried and succeed on the second try, the merge request
-will automatically be merged after all. When the merge request is updated with
-new commits, the automatic merge is automatically canceled to allow the new
+is automatically merged. When the merge request is updated with
+new commits, the automatic merge is canceled to allow the new
 changes to be reviewed.
 
 ## Only allow merge requests to be merged if the pipeline succeeds
@@ -42,7 +44,7 @@ or if there are threads to be resolved. This works for both:
 - Pipelines run from an [external CI integration](../integrations/overview.md#integrations-listing)
 
 As a result, [disabling GitLab CI/CD pipelines](../../../ci/enable_or_disable_ci.md)
-will not disable this feature, as it will still be possible to use pipelines from external
+does not disable this feature, as it is possible to use pipelines from external
 CI providers with this feature. To enable it, you must:
 
 1. Navigate to your project's **Settings > General** page.
@@ -50,14 +52,40 @@ CI providers with this feature. To enable it, you must:
 1. In the **Merge checks** subsection, select the **Pipelines must succeed** checkbox.
 1. Press **Save** for the changes to take effect.
 
-NOTE: **Note:** This setting also prevents merge requests from being merged if there is no pipeline.
+This setting also prevents merge requests from being merged if there is no pipeline.
 
-![Pipelines must succeed settings](img/merge_when_pipeline_succeeds_only_if_succeeds_settings.png)
+### Limitations
+
+When this setting is enabled, a merge request is prevented from being merged if there
+is no pipeline. This may conflict with some use cases where [`only/except`](../../../ci/yaml/README.md#onlyexcept-advanced)
+or [`rules`](../../../ci/yaml/README.md#rules) are used and they don't generate any pipelines.
+
+You should ensure that [there is always a pipeline](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/54226)
+and that it's successful.
+
+If both a branch pipeline and a merge request pipeline are triggered for a single
+merge request, only the success or failure of the *merge request pipeline* is checked.
+If the merge request pipeline is configured with fewer jobs than the branch pipeline,
+it could allow code that fails tests to be merged:
+
+```yaml
+branch-pipeline-job:
+  rules:
+    - if: '$CI_PIPELINE_SOURCE == "push"'
+  script:
+    - echo "Code testing scripts here, for example."
 
-From now on, every time the pipeline fails you will not be able to merge the
-merge request from the UI, until you make all relevant jobs pass.
+merge-request-pipeline-job:
+  rules:
+    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
+  script:
+    - echo "No tests run, but this pipeline always succeeds and enables merge."
+    - echo true
+```
 
-![Only allow merge if pipeline succeeds message](img/merge_when_pipeline_succeeds_only_if_succeeds_msg.png)
+You should avoid configuration like this, and only use branch (`push`) pipelines
+or merge request pipelines, when possible. See [`rules` documentation](../../../ci/yaml/README.md#differences-between-rules-and-onlyexcept)
+for details on avoiding two pipelines for a single merge request.
 
 ### Skipped pipelines
 
@@ -72,20 +100,10 @@ merge requests from being merged. To change this behavior:
 1. In the **Merge checks** subsection, select the **Skipped pipelines are considered successful** checkbox.
 1. Press **Save** for the changes to take effect.
 
-### Limitations
-
-When this setting is enabled, a merge request is prevented from being merged if there is no pipeline. This may conflict with some use cases where [`only/except`](../../../ci/yaml/README.md#onlyexcept-advanced) rules are used and they don't generate any pipelines.
-
-Users that expect to be able to merge a merge request in this scenario should ensure that [there is always a pipeline](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/54226) and that it's successful.
+## From the command line
 
-For example, to that on merge requests there is always a passing job even though `only/except` rules may not generate any other jobs:
-
-```yaml
-enable_merge:
-  only: [merge_requests]
-  script:
-    - echo true
-```
+You can use [Push Options](../push_options.md) to enable merge when pipeline succeeds
+for a merge request when pushing from the command line.
 
 <!-- ## Troubleshooting
 
@@ -98,8 +116,3 @@ questions that you know someone might ask.
 Each scenario can be a third-level heading, e.g. `### Getting error message X`.
 If you have none to add when creating a doc, leave this section in place
 but commented out to help encourage others to add to it in the future. -->
-
-## Use it from the command line
-
-You can use [Push Options](../push_options.md) to trigger this feature when
-pushing.
diff --git a/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md b/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md
index a3ad41d8dd8..162ebdf157d 100644
--- a/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md
+++ b/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md
@@ -64,6 +64,43 @@ list.
 
 ![Merge request diff file navigation](img/merge_request_diff_file_navigation.png)
 
+### File-by-file diff navigation
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/222790) in GitLab 13.2.
+> - It's deployed behind a feature flag, disabled by default.
+> - It's enabled on GitLab.com.
+> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-file-by-file-diff-navigation-core-only).
+
+For larger merge requests it might sometimes be useful to review single files at a time. To enable,
+from your avatar on the top-right navbar, click **Settings**, and go to **Preferences** on the left
+sidebar. Scroll down to the **Behavior** section and select **Show one file at a time on merge request's Changes tab**.
+Click **Save changes** to apply.
+
+From there, when reviewing merge requests' **Changes** tab, you will see only one file at a time. You can then click the buttons **Prev** and **Next** to view the other files changed.
+
+![File-by-file diff navigation](img/file_by_file_v13_2.png)
+
+#### Enable or disable file-by-file diff navigation **(CORE ONLY)**
+
+File-by-file diff navigation is under development but ready for production use. It is
+deployed behind a feature flag that is **disabled by default**.
+[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
+can enable it for your instance.
+
+To enable it:
+
+```ruby
+# Instance-wide
+Feature.enable(:view_diffs_file_by_file)
+```
+
+To disable it:
+
+```ruby
+# Instance-wide
+Feature.disable(:view_diffs_file_by_file>)
+```
+
 ### Merge requests commit navigation
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/18140) in GitLab 13.0.
diff --git a/doc/user/project/merge_requests/squash_and_merge.md b/doc/user/project/merge_requests/squash_and_merge.md
index 924334055b9..79eec059293 100644
--- a/doc/user/project/merge_requests/squash_and_merge.md
+++ b/doc/user/project/merge_requests/squash_and_merge.md
@@ -85,6 +85,60 @@ it. This is because squashing is only available when accepting a merge request,
 so a merge request may need to be rebased before squashing, even though
 squashing can itself be considered equivalent to rebasing.
 
+## Squash Commits Options
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/17613) in GitLab 13.2.
+> - It's deployed behind a feature flag, disabled by default.
+> - It's disabled on GitLab.com.
+> - It's not recommended for production use.
+> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-squash-commit-options-core-only). **(CORE ONLY)**
+
+With Squash Commits Options you can configure the behavior of Squash and Merge for your project.
+To set it up, navigate to your project's **Settings > General** and expand **Merge requests**.
+You will find the following options to choose, which will affect existing and new merge requests
+submitted to your project:
+
+- **Do not allow**: users cannot use Squash and Merge to squash all the commits immediately before
+  merging. The checkbox to enable or disable it will be unchecked and hidden from the users.
+- **Allow**: users will have the option to enable Squash and Merge on a merge request basis.
+  The checkbox will be unchecked (disabled) by default, but and the user is allowed to enable it.
+- **Encourage**: users will have the option to enable Squash and Merge on a merge request basis.
+  The checkbox will be checked (enabled) by default to encourage its use, but the user is allowed to
+  disable it.
+- **Require**: Squash and Merge is enabled for all merge requests, so it will always be performed.
+  The checkbox to enable or disable it will be checked and hidden from the users.
+
+The Squash and Merge checkbox is displayed when you create a merge request and when you edit the description of an existing one, except when Squash Commit Options is set to **Do not allow** or **Require**.
+
+NOTE: **Note:**
+If your project is set to **Do not allow** Squash and Merge, the users still have the option to
+squash commits locally through the command line and force-push to their remote branch before merging.
+
+### Enable or disable Squash Commit Options **(CORE ONLY)**
+
+Squash Commit Options is under development and not ready for production use. It is
+deployed behind a feature flag that is **disabled by default**.
+[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
+can enable it for your instance. Squash Commit Options can be enabled or disabled per-project.
+
+To enable it:
+
+```ruby
+# Instance-wide
+Feature.enable(:squash_options)
+# or by project
+Feature.enable(:squash_options, Project.find(<project id>))
+```
+
+To disable it:
+
+```ruby
+# Instance-wide
+Feature.disable(:squash_options)
+# or by project
+Feature.disable(:squash_options, Project.find(<project id>))
+```
+
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues
diff --git a/doc/user/project/merge_requests/test_coverage_visualization.md b/doc/user/project/merge_requests/test_coverage_visualization.md
index 1c0e698aba5..12194423a00 100644
--- a/doc/user/project/merge_requests/test_coverage_visualization.md
+++ b/doc/user/project/merge_requests/test_coverage_visualization.md
@@ -1,4 +1,7 @@
 ---
+stage: Verify
+group: Testing
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
 type: reference, howto
 ---
 
diff --git a/doc/user/project/merge_requests/testing_and_reports_in_merge_requests.md b/doc/user/project/merge_requests/testing_and_reports_in_merge_requests.md
index f7614ed7996..e5ebc46d58f 100644
--- a/doc/user/project/merge_requests/testing_and_reports_in_merge_requests.md
+++ b/doc/user/project/merge_requests/testing_and_reports_in_merge_requests.md
@@ -1,4 +1,7 @@
 ---
+stage: Verify
+group: Testing
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
 type: index
 description: "Test your code and display reports in merge requests"
 ---
@@ -11,8 +14,9 @@ or link to useful information directly from merge requests:
 | Feature                                                                                                | Description                                                                                                                                                                                               |
 |--------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | [Accessibility Testing](accessibility_testing.md)                                                      | Automatically report A11y violations for changed pages in merge requests.                                                                                                                                |
-| [Browser Performance Testing](browser_performance_testing.md) **(PREMIUM)**                            | Quickly determine the performance impact of pending code changes.                                                                                                                                         |
-| [Code Quality](code_quality.md) **(STARTER)**                                                          | Analyze your source code quality using the [Code Climate](https://codeclimate.com/) analyzer and show the Code Climate report right in the merge request widget area.                                     |
+| [Browser Performance Testing](browser_performance_testing.md) **(PREMIUM)**                            | Quickly determine the browser performance impact of pending code changes.                                                                                                                                         |
+| [Load Performance Testing](load_performance_testing.md) **(PREMIUM)**                                  | Quickly determine the server performance impact of pending code changes.                                                                                                                                         |
+| [Code Quality](code_quality.md)                                                                        | Analyze your source code quality using the [Code Climate](https://codeclimate.com/) analyzer and show the Code Climate report right in the merge request widget area.                                     |
 | [Display arbitrary job artifacts](../../../ci/yaml/README.md#artifactsexpose_as)                       | Configure CI pipelines with the `artifacts:expose_as` parameter to directly link to selected [artifacts](../../../ci/pipelines/job_artifacts.md) in merge requests.                                                |
 | [GitLab CI/CD](../../../ci/README.md)                                                                  | Build, test, and deploy your code in a per-branch basis with built-in CI/CD.                                                                                                                              |
 | [JUnit test reports](../../../ci/junit_test_reports.md)                                                | Configure your CI jobs to use JUnit test reports, and let GitLab display a report on the merge request so that it’s easier and faster to identify the failure without having to check the entire job log. |
diff --git a/doc/user/project/merge_requests/work_in_progress_merge_requests.md b/doc/user/project/merge_requests/work_in_progress_merge_requests.md
index 8ac4131e10b..ece5e7868dc 100644
--- a/doc/user/project/merge_requests/work_in_progress_merge_requests.md
+++ b/doc/user/project/merge_requests/work_in_progress_merge_requests.md
@@ -2,42 +2,46 @@
 type: reference, concepts
 ---
 
-# "Work In Progress" merge requests
+# Draft merge requests
 
 If a merge request is not yet ready to be merged, perhaps due to continued development
 or open threads, you can prevent it from being accepted before it's ready by flagging
-it as a **Work In Progress**. This will disable the "Merge" button, preventing it from
-being merged, and it will stay disabled until the "WIP" flag has been removed.
+it as a **Draft**. This will disable the "Merge" button, preventing it from
+being merged, and it will stay disabled until the "Draft" flag has been removed.
 
-![Blocked Accept Button](img/wip_blocked_accept_button.png)
+![Blocked Merge Button](img/draft_blocked_merge_button_v13_2.png)
 
-## Adding the "Work In Progress" flag to a merge request
+## Adding the "Draft" flag to a merge request
 
-There are several ways to flag a merge request as a Work In Progress:
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32692) in GitLab 13.2, Work-In-Progress (WIP) merge requests were renamed to **Draft**. Support for using **WIP** will be removed in GitLab 14.0.
 
-- Add `[WIP]` or `WIP:` to the start of the merge request's title. Clicking on
-  **Start the title with WIP:**, under the title box, when editing the merge request's
+There are several ways to flag a merge request as a Draft:
+
+- Add `[Draft]`, `Draft:` or `(Draft)` to the start of the merge request's title. Clicking on
+  **Start the title with Draft:**, under the title box, when editing the merge request's
   description will have the same effect.
+- **Deprecated** Add `[WIP]` or `WIP:` to the start of the merge request's title.
+  **WIP** still works but was deprecated in favor of **Draft**. It will be removed in the next major version (GitLab 14.0).
 - Add the `/wip` [quick action](../quick_actions.md#quick-actions-for-issues-merge-requests-and-epics)
   in a comment in the merge request. This is a toggle, and can be repeated
   to change the status back. Note that any other text in the comment will be discarded.
-- Add "wip" or "WIP" to the start of a commit message targeting the merge request's
+- Add `draft:` or `Draft:` to the start of a commit message targeting the merge request's
   source branch. This is not a toggle, and doing it again in another commit will have
   no effect.
 
-## Removing the "Work In Progress" flag from a merge request
+## Removing the "Draft" flag from a merge request
 
 Similar to above, when a Merge Request is ready to be merged, you can remove the
-"Work in Progress" flag in several ways:
+`Draft` flag in several ways:
 
-- Remove `[WIP]` or `WIP:` from the start of the merge request's title. Clicking on
-  **Remove the WIP: prefix from the title**, under the title box, when editing the merge
+- Remove `[Draft]`, `Draft:` or `(Draft)` from the start of the merge request's title. Clicking on
+  **Remove the Draft: prefix from the title**, under the title box, when editing the merge
   request's description, will have the same effect.
 - Add the `/wip` [quick action](../quick_actions.md#quick-actions-for-issues-merge-requests-and-epics)
   in a comment in the merge request. This is a toggle, and can be repeated
   to change the status back. Note that any other text in the comment will be discarded.
-- Click on the **Resolve WIP status** button near the bottom of the merge request description,
-  next to the "Merge" button (see [image above](#work-in-progress-merge-requests)).
+- Click on the **Resolve Draft status** button near the bottom of the merge request description,
+  next to the **Merge** button (see [image above](#draft-merge-requests)).
   Must have at least Developer level permissions on the project for the button to
   be visible.