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

8 files changed, 100 insertions, 60 deletions

diff --git a/doc/user/analytics/code_review_analytics.md b/doc/user/analytics/code_review_analytics.md
index 8c4c54153bb..89acb430a9f 100644
--- a/doc/user/analytics/code_review_analytics.md
+++ b/doc/user/analytics/code_review_analytics.md
@@ -10,40 +10,45 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/38062) in [GitLab Starter](https://about.gitlab.com/pricing/) 12.7.
 
-Code Review Analytics makes it easy to view the longest-running reviews among open merge requests,
-enabling you to take action on individual merge requests and reduce overall cycle time.
+Code Review Analytics makes it easy to view the longest-running reviews among open merge requests and
+enables you to:
+
+1. Take action on individual merge requests.
+1. Reduce overall cycle time.
 
 NOTE: **Note:**
-Initially, no data will appear. Data is populated as users comment on open merge requests.
+Initially, no data appears. Data is populated as users comment on open merge requests.
 
 ## Overview
 
 Code Review Analytics displays a table of open merge requests that have at least one non-author comment. The review time is measured from the time the first non-author comment was submitted.
-The code review period for a merge request is automatically identified as the time since the first non-author comment.
 
-To access Code Review Analytics, from your project's menu, go to **{chart}** **Project Analytics > Code Review**.
+To access Code Review Analytics, from your project's menu, go to **Project Analytics > Code Review**.
+
+You can filter the list of merge requests by milestone and label.
 
 ![Code Review Analytics](img/code_review_analytics_v12_8.png "List of code reviews; oldest review first.")
 
-- The table is sorted by review duration, helping you quickly find the longest-running reviews which may need intervention or to be broken down into smaller parts.
-- You can filter the list of MRs by milestone and label.
-- Columns to display the author, approvers, comment count, and line change (-/+) counts.
+The table is sorted by:
+
+- **Review time**: Helping you to quickly find the longest-running reviews which may need intervention
+  or to be broken down into smaller parts.
+- Other columns: Display the author, approvers, comment count, and line change (-/+) counts.
 
 ## Use cases
 
 This feature is designed for [development team leaders](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead)
-and others who want to understand broad code review dynamics, and identify patterns to help explain them.
-
-You can use Code Review Analytics to expose your team's unique challenges with code review, and
-identify improvements that might substantially accelerate your development cycle.
+and others who want to understand broad code review dynamics, and identify patterns to explain them.
 
-Code Review Analytics can be used when:
+You can use Code Review Analytics to:
 
+- Expose your team's unique challenges with code review.
+- Identify improvements that might substantially accelerate your development cycle.
 - Your team agrees that code review is moving too slow.
 - The [Value Stream Analytics feature](value_stream_analytics.md) shows that reviews are your team's most time-consuming step.
+- Analyze the patterns and trends of different types of work that are moving slow.
 
-You can use Code Review Analytics to see the types of work that are currently moving the slowest, and analyze the patterns
-and trends between them. For example:
+For example:
 
 - Lots of comments or commits? Maybe the code is too complex.
 - A particular author is involved? Maybe more training is required.
diff --git a/doc/user/analytics/img/delete_value_stream_v13.4.png b/doc/user/analytics/img/delete_value_stream_v13.4.png
new file mode 100644
index 00000000000..c97fcb76343
--- /dev/null
+++ b/doc/user/analytics/img/delete_value_stream_v13.4.png
diff --git a/doc/user/analytics/img/merge_request_analytics_v13_3.png b/doc/user/analytics/img/merge_request_analytics_v13_3.png
deleted file mode 100644
index f90f3625a51..00000000000
--- a/doc/user/analytics/img/merge_request_analytics_v13_3.png
+++ /dev/null
diff --git a/doc/user/analytics/img/mr_throughput_chart_v13_3.png b/doc/user/analytics/img/mr_throughput_chart_v13_3.png
new file mode 100644
index 00000000000..04fa54f323c
--- /dev/null
+++ b/doc/user/analytics/img/mr_throughput_chart_v13_3.png
diff --git a/doc/user/analytics/img/mr_throughput_table_v13_3.png b/doc/user/analytics/img/mr_throughput_table_v13_3.png
new file mode 100644
index 00000000000..63ffb9389f4
--- /dev/null
+++ b/doc/user/analytics/img/mr_throughput_table_v13_3.png
diff --git a/doc/user/analytics/index.md b/doc/user/analytics/index.md
index 47852cb0498..044b9eb3e64 100644
--- a/doc/user/analytics/index.md
+++ b/doc/user/analytics/index.md
@@ -6,15 +6,15 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Analytics
 
-## Analytics workspace
+## Instance-level analytics
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12077) in GitLab 12.2.
 
-The Analytics workspace will make it possible to aggregate analytics across
+Instance-level analytics make it possible to aggregate analytics across
 GitLab, so that users can view information across multiple projects and groups
 in one place.
 
-To access the Analytics workspace, click on **More > Analytics** in the top navigation bar.
+[Learn more about instance-level analytics](../admin_area/analytics/index.md).
 
 ## Group-level analytics
 
@@ -38,7 +38,8 @@ The following analytics features are available at the project level:
 - [Code Review](code_review_analytics.md). **(STARTER)**
 - [Insights](../group/insights/index.md). **(ULTIMATE)**
 - [Issue](../group/issues_analytics/index.md). **(PREMIUM)**
-- [Merge Request](merge_request_analytics.md). **(STARTER)**
+- [Merge Request](merge_request_analytics.md), enabled with the `project_merge_request_analytics`
+  [feature flag](../../development/feature_flags/development.md#enabling-a-feature-flag-locally-in-development). **(STARTER)**
 - [Repository](repository_analytics.md).
 - [Value Stream](value_stream_analytics.md), enabled with the `cycle_analytics`
   [feature flag](../../development/feature_flags/development.md#enabling-a-feature-flag-locally-in-development). **(STARTER)**
diff --git a/doc/user/analytics/merge_request_analytics.md b/doc/user/analytics/merge_request_analytics.md
index 01295ae888b..6a18d46fd1a 100644
--- a/doc/user/analytics/merge_request_analytics.md
+++ b/doc/user/analytics/merge_request_analytics.md
@@ -5,7 +5,6 @@ group: Analytics
 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
 ---
 
-
 # Merge Request Analytics **(STARTER)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/229045) in [GitLab Starter](https://about.gitlab.com/pricing/) 13.3.
@@ -14,16 +13,14 @@ Merge Request Analytics helps you understand the efficiency of your code review
 
 ## Overview
 
-Merge Request Analytics displays information about all accepted merge requests.
+Merge Request Analytics displays information that will help you evaluate the efficiency and productivity of your merge request process.
 
-The Throughput chart shows the number of completed merge requests, by month. Merge request throughput is
+The Throughput chart shows the number of merge requests merged, by month. Merge request throughput is
 a common measure of productivity in software engineering. Although imperfect, the average throughput can
 be a meaningful benchmark of your team's overall productivity.
 
 To access Merge Request Analytics, from your project's menu, go to **Analytics > Merge Request**.
 
-![Merge Request Analytics](img/merge_request_analytics_v13_3.png "Merge Request Analytics - Throughput chart")
-
 ## Use cases
 
 This feature is designed for [development team leaders](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead)
@@ -37,6 +34,57 @@ Merge Request Analytics could be used when:
 - You want to know if you were more productive this month than last month, or 12 months ago.
 - You want to drill into low- or high-productivity months to understand the work that took place.
 
+## Visualizations and data
+
+The following visualizations and data are available, representing all merge requests that were merged in the past 12 months.
+
+### Throughput chart
+
+The throughput chart shows the number of merge requests merged per month.
+
+![Throughput chart](img/mr_throughput_chart_v13_3.png "Merge Request Analytics - Throughput chart showing merge requests merged in the past 12 months")
+
+### Throughput table
+
+Data table displaying a maximum of the 100 most recent merge requests merged for the time period.
+
+![Throughput table](img/mr_throughput_table_v13_3.png "Merge Request Analytics - Throughput table listing the 100 merge requests most recently merged")
+
+## Filter the data
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/229266) in GitLab 13.4
+
+You can filter the data that is presented on the page based on the following parameters:
+
+- Author
+- Assignees
+- Labels
+- Milestones
+
+To filter results:
+
+1. Click on the filter bar.
+1. Select a parameter to filter by.
+1. Select a value from the autocompleted results, or enter search text to refine the results.
+
 ## Permissions
 
-- On [Starter or Bronze tier](https://about.gitlab.com/pricing/) and above.
+The **Merge Request Analytics** feature can be accessed only:
+
+- On [Starter](https://about.gitlab.com/pricing/) and above.
+- By users with [Reporter access](../permissions.md) and above.
+
+## Enable and disable related feature flags
+
+Merge Request Analytics is disabled by default but can be enabled using the following
+[feature flag](../../development/feature_flags/development.md#enabling-a-feature-flag-locally-in-development):
+
+- `project_merge_request_analytics`
+
+A GitLab administrator can:
+
+- Enable this feature by running the following command in a Rails console:
+
+  ```ruby
+  Feature.enable(:project_merge_request_analytics)
+  ```
diff --git a/doc/user/analytics/value_stream_analytics.md b/doc/user/analytics/value_stream_analytics.md
index 9114b6de6bc..14012d4a28d 100644
--- a/doc/user/analytics/value_stream_analytics.md
+++ b/doc/user/analytics/value_stream_analytics.md
@@ -45,8 +45,6 @@ There are seven stages that are tracked as part of the Value Stream Analytics ca
   - Time spent on code review
 - **Staging** (Continuous Deployment)
   - Time between merging and deploying to production
-- **Total** (Total)
-  - Total lifecycle time. That is, the velocity of the project or team. [Previously known](https://gitlab.com/gitlab-org/gitlab/-/issues/38317) as **Production**.
 
 ## Filter the analytics data
 
@@ -95,7 +93,7 @@ Note: A commit is associated with an issue by [crosslinking](../project/issues/c
 ## How the stages are measured
 
 Value Stream Analytics records stage time and data based on the project issues with the
-exception of the staging and total stages, where only data deployed to
+exception of the staging stage, where only data deployed to
 production are measured.
 
 Specifically, if your CI is not set up and you have not defined a `production`
@@ -112,7 +110,6 @@ Each stage of Value Stream Analytics is further described in the table below.
 | Test      | Measures the median time to run the entire pipeline for that project. It's related to the time GitLab CI/CD takes to run every job for the commits pushed to that merge request defined in the previous stage. It is basically the start->finish time for all pipelines. |
 | Review    | Measures the median time taken to review the merge request that has a closing issue pattern, between its creation and until it's merged. |
 | Staging   | Measures the median time between merging the merge request with a closing issue pattern until the very first deployment to production. It's tracked by the environment set to `production` or matching `production/*` (case-sensitive, `Production` won't work) in your GitLab CI/CD configuration. If there isn't a production environment, this is not tracked. |
-| Total | The sum of all time (medians) taken to run the entire process, from issue creation to deploying the code to production. [Previously known](https://gitlab.com/gitlab-org/gitlab/-/issues/38317) as **Production**. |
 
 How this works, behind the scenes:
 
@@ -131,7 +128,7 @@ Value Stream Analytics dashboard will not present any data for:
 
 - Merge requests that do not close an issue.
 - Issues not labeled with a label present in the Issue Board or for issues not assigned a milestone.
-- Staging and production stages, if the project has no `production` or `production/*`
+- Staging stage, if the project has no `production` or `production/*`
   environment.
 
 ## Example workflow
@@ -158,9 +155,6 @@ environments is configured.
    request at 19:00. (stop of **Review** stage / start of **Staging** stage).
 1. Now that the merge request is merged, a deployment to the `production`
    environment starts and finishes at 19:30 (stop of **Staging** stage).
-1. The cycle completes and the sum of the median times of the previous stages
-   is recorded to the **Total** stage. That is the time between creating an
-   issue and deploying its relevant merge request to production.
 
 From the above example you can conclude the time it took each stage to complete
 as long as their total time:
@@ -171,10 +165,6 @@ as long as their total time:
 - **Test**: 5min
 - **Review**: 5h (19:00 - 14:00)
 - **Staging**: 30min (19:30 - 19:00)
-- **Total**: Since this stage measures the sum of median time of all
-  previous stages, we cannot calculate it if we don't know the status of the
-  stages before. In case this is the very first cycle that is run in the project,
-  then the **Total** time is 10h 30min (19:30 - 09:00)
 
 A few notes:
 
@@ -267,7 +257,7 @@ Once a custom stage has been added, you can "drag and drop" stages to rearrange
 The pre-defined start and end events can cover many use cases involving both issues and merge requests.
 
 For supporting more complex workflows, use stages based on group labels. These events are based on
-labels being added or removed. In particular, [scoped labels](../project/labels.md#scoped-labels-premium)
+labels being added or removed. In particular, [scoped labels](../project/labels.md#scoped-labels)
 are useful for complex workflows.
 
 In this example, we'd like to measure more accurate code review times. The workflow is the following:
@@ -313,6 +303,19 @@ To create a value stream:
 
 ![New value stream](img/new_value_stream_v13_3.png "Creating a new value stream")
 
+### Deleting a value stream
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/221205) in GitLab 13.4.
+
+To delete a custom value stream:
+
+1. Navigate to your group's **Analytics > Value Stream**.
+1. Click the Value stream dropdown and select the value stream you would like to delete.
+1. Click the **Delete (name of value stream)**.
+1. Click the **Delete** button to confirm.
+
+![Delete value stream](img/delete_value_stream_v13.4.png "Deleting a custom value stream")
+
 ### Disabling custom value streams
 
 Custom value streams are enabled by default. If you have a self-managed instance, an
@@ -324,7 +327,8 @@ Feature.disable(:value_stream_analytics_create_multiple_value_streams)
 
 ## Days to completion chart
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/21631) in GitLab 12.6.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/21631) in GitLab 12.6.
+> - [Chart median line removed](https://gitlab.com/gitlab-org/gitlab/-/issues/235455) in GitLab 13.4.
 
 This chart visually depicts the total number of days it takes for cycles to be completed.
 
@@ -332,15 +336,6 @@ This chart uses the global page filters for displaying data based on the selecte
 group, projects, and timeframe. In addition, specific stages can be selected
 from within the chart itself.
 
-### Chart median line
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/36675) in GitLab 12.7.
-
-The median line on the chart displays data that is offset by the number of days selected.
-For example, if 30 days worth of data has been selected (for example, 2019-12-16 to 2020-01-15) the
-median line will represent the previous 30 days worth of data (2019-11-16 to 2019-12-16)
-as a metric to compare against.
-
 ### Disabling chart
 
 This chart is enabled by default. If you have a self-managed instance, an
@@ -350,18 +345,9 @@ administrator can open a Rails console and disable it with the following command
 Feature.disable(:cycle_analytics_scatterplot_enabled)
 ```
 
-### Disabling chart median line
-
-This chart's median line is enabled by default. If you have a self-managed instance, an
-administrator can open a Rails console and disable it with the following command:
-
-```ruby
-Feature.disable(:cycle_analytics_scatterplot_median_enabled)
-```
-
-## Type of work - Tasks by type chart
+## Type of work - Tasks by type chart **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32421) in GitLab 12.10.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32421) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.10.
 
 This chart shows a cumulative count of issues and merge requests per day.
 
@@ -380,7 +366,7 @@ The current permissions on the Project Value Stream Analytics dashboard are:
 - Internal projects - any authenticated user can access.
 - Private projects - any member Guest and above can access.
 
-You can [read more about permissions](../../ci/yaml/README.md) in general.
+You can [read more about permissions](../../user/permissions.md) in general.
 
 For Value Stream Analytics functionality introduced in GitLab 12.3 and later: