Add latest changes from gitlab-org/gitlab@master

4 files changed, 25 insertions, 15 deletions

diff --git a/doc/user/analytics/value_stream_analytics.md b/doc/user/analytics/value_stream_analytics.md
index 718367dc69d..71863b8b643 100644
--- a/doc/user/analytics/value_stream_analytics.md
+++ b/doc/user/analytics/value_stream_analytics.md
@@ -78,8 +78,8 @@ Each stage of Value Stream Analytics is further described in the table below.
 | Plan      | Measures the median time between the action you took for the previous stage, and pushing the first commit to the branch. The very first commit of the branch is the one that triggers the separation between **Plan** and **Code**, and at least one of the commits in the branch needs to contain the related issue number (e.g., `#42`). If none of the commits in the branch mention the related issue number, it is not considered to the measurement time of the stage. |
 | Code      | Measures the median time between pushing a first commit (previous stage) and creating a merge request (MR) related to that commit. The key to keep the process tracked is to include the [issue closing pattern](../project/issues/managing_issues.md#closing-issues-automatically) to the description of the merge request (for example, `Closes #xxx`, where `xxx` is the number of the issue related to this merge request). If the issue closing pattern is not present in the merge request description, the MR is not considered to the measurement time of the stage. |
 | Test      | Measures the median time to run the entire pipeline for that project. It's related to the time GitLab CI 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 closing issue pattern, between its creation and until it's merged. |
-| Staging   | Measures the median time between merging the merge request with 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 configuration. If there isn't a production environment, this is not tracked. |
+| 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 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:
diff --git a/doc/user/profile/account/two_factor_authentication.md b/doc/user/profile/account/two_factor_authentication.md
index 72ef8de7a3c..56261d13395 100644
--- a/doc/user/profile/account/two_factor_authentication.md
+++ b/doc/user/profile/account/two_factor_authentication.md
@@ -39,7 +39,7 @@ To enable 2FA:
 
 1. **In GitLab:**
    1. Log in to your GitLab account.
-   1. Go to your **Profile Settings**.
+   1. Go to your [**Profile settings**](../index.md#profile-settings).
    1. Go to **Account**.
    1. Click **Enable Two-factor Authentication**.
 1. **On your device (usually your phone):**
@@ -84,7 +84,7 @@ Search for `security.webauth.u2f` and double click on it to toggle to `true`.
 To set up 2FA with a U2F device:
 
 1. Log in to your GitLab account.
-1. Go to your **Profile Settings**.
+1. Go to your [**Profile settings**](../index.md#profile-settings).
 1. Go to **Account**.
 1. Click **Enable Two-Factor Authentication**.
 1. Plug in your U2F device.
@@ -139,7 +139,7 @@ request and you will be automatically logged in.
 If you ever need to disable 2FA:
 
 1. Log in to your GitLab account.
-1. Go to your **Profile Settings**.
+1. Go to your [**Profile settings**](../index.md#profile-settings).
 1. Go to **Account**.
 1. Click **Disable**, under **Two-Factor Authentication**.
 
@@ -226,7 +226,7 @@ To regenerate 2FA recovery codes, you need access to a desktop browser:
 
 1. Navigate to GitLab.
 1. Sign in to your GitLab account.
-1. Go to your [Profile settings](../index.md#profile-settings).
+1. Go to your [**Profile settings**](../index.md#profile-settings).
 1. Select **{account}** **Account > Two-Factor Authentication (2FA)**.
 1. If you've already configured 2FA, click **Manage two-factor authentication**.
 1. In the **Register Two-Factor Authenticator** pane, click **Regenerate recovery codes**.
diff --git a/doc/user/project/issues/index.md b/doc/user/project/issues/index.md
index 615af1d8b84..fe50ec62d2c 100644
--- a/doc/user/project/issues/index.md
+++ b/doc/user/project/issues/index.md
@@ -6,9 +6,14 @@ Issues are the fundamental medium for collaborating on ideas and planning work i
 
 The GitLab issue tracker is an advanced tool for collaboratively developing ideas, solving problems, and planning work.
 
-Issues can allow you and your team to share and discuss proposals
-before, and during, their implementation. However, they can be used for a variety of
-other purposes, customized to your needs and workflow.
+Issues can allow sharing and discussion of proposals before, and during,
+their implementation between:
+
+- You and your team.
+- Outside collaborators.
+
+They can also be used for a variety of other purposes, customized to your
+needs and workflow.
 
 Issues are always associated with a specific project, but if you have multiple projects in a group,
 you can also view all the issues collectively at the group level.
diff --git a/doc/user/project/pipelines/schedules.md b/doc/user/project/pipelines/schedules.md
index 0a86247042e..360897b530d 100644
--- a/doc/user/project/pipelines/schedules.md
+++ b/doc/user/project/pipelines/schedules.md
@@ -116,12 +116,17 @@ The next time a pipeline is scheduled, your credentials will be used.
 
 ![Schedules list](img/pipeline_schedules_ownership.png)
 
-NOTE: **Note:**
-If the owner of a pipeline schedule doesn't have the ability to create pipelines
-on the target branch, the schedule will stop creating new pipelines. This can
-happen if the owner is blocked or removed from the project, or
-the target branch or tag is protected. In this case, someone with sufficient
-privileges must take ownership of the schedule.
+If the owner of a pipeline schedule doesn't have the ability to create
+pipelines on the target branch, the schedule will stop creating new
+pipelines.
+
+This can happen if, for example:
+
+- The owner is blocked or removed from the project.
+- The target branch or tag is protected.
+
+In this case, someone with sufficient privileges must take ownership of the
+schedule.
 
 <!-- ## Troubleshooting