Add latest changes from gitlab-org/gitlab@master

8 files changed, 51 insertions, 32 deletions

diff --git a/doc/user/project/operations/error_tracking.md b/doc/user/project/operations/error_tracking.md
index 47b153ddd7e..685fdefe0c6 100644
--- a/doc/user/project/operations/error_tracking.md
+++ b/doc/user/project/operations/error_tracking.md
@@ -61,9 +61,9 @@ By default, a **Create issue** button is displayed:
 
 ![Error Details without Issue Link](img/error_details_v12_7.png)
 
-If you create a GitLab issue from the error, the **Create issue** button will change to a **View issue** button:
+If you create a GitLab issue from the error, the **Create issue** button will change to a **View issue** button and a link to the GitLab issue will surface within the error detail section:
 
-![Error Details with Issue Link](img/error_details_with_issue_v12_7.png)
+![Error Details with Issue Link](img/error_details_with_issue_v12_8.png)
 
 ## Taking Action on errors
 
diff --git a/doc/user/project/operations/img/error_details_with_issue_v12_8.png b/doc/user/project/operations/img/error_details_with_issue_v12_8.png
new file mode 100644
index 00000000000..0536861b070
--- /dev/null
+++ b/doc/user/project/operations/img/error_details_with_issue_v12_8.png
diff --git a/doc/user/project/releases/img/upcoming_release_v12_7.png b/doc/user/project/releases/img/upcoming_release_v12_7.png
new file mode 100644
index 00000000000..4ff8fad98f9
--- /dev/null
+++ b/doc/user/project/releases/img/upcoming_release_v12_7.png
diff --git a/doc/user/project/releases/index.md b/doc/user/project/releases/index.md
index d9eda5cf6a4..04667e2adfe 100644
--- a/doc/user/project/releases/index.md
+++ b/doc/user/project/releases/index.md
@@ -107,6 +107,16 @@ For private projects, the number of Releases is displayed to users with Reporter
 [permissions](../../permissions.md#releases-permissions) or higher. For public projects,
 it is displayed to every user regardless of their permission level.
 
+### Upcoming Releases
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/38105) in GitLab 12.1.
+
+A Release may be created ahead of time by specifying a future `released_at` date. Until
+the `released_at` date and time is reached, an **Upcoming Release** badge will appear next to the
+Release tag. Once the `released_at` date and time has passed, the badge is automatically removed.
+
+![An upcoming release](img/upcoming_release_v12_7.png)
+
 ## Editing a release
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/26016) in GitLab 12.6.
@@ -245,6 +255,19 @@ Please note that Release Evidence's data is collected regardless of this
 feature flag, which only enables or disables the display of the data on the
 Releases page.
 
+### Scheduled Evidence creation
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/23697) in GitLab 12.8.
+
+When the `released_at` date and time is not provided, the date and time of Release
+creation is used. The Evidence collection background job is immediately executed.
+
+If a future `released_at` is specified, the Release becomes an **Upcoming Release**. In this
+case, the Evidence is scheduled to be collected at the `released_at` date and time, via a
+background job.
+
+If a past `released_at` is used, no Evidence is collected for the Release.
+
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues
diff --git a/doc/user/project/repository/forking_workflow.md b/doc/user/project/repository/forking_workflow.md
index cd23f0bd434..45a32655f96 100644
--- a/doc/user/project/repository/forking_workflow.md
+++ b/doc/user/project/repository/forking_workflow.md
@@ -5,60 +5,56 @@ disqus_identifier: 'https://docs.gitlab.com/ee/workflow/forking_workflow.html'
 # Project forking workflow
 
 Forking a project to your own namespace is useful if you have no write
-access to the project you want to contribute to. If you do have write
+access to the project you want to contribute to. Even if you do have write
 access or can request it, we recommend working together in the same
 repository since it is simpler. See our [GitLab Flow](../../../topics/gitlab_flow.md)
 document more information about using branches to work together.
 
 ## Creating a fork
 
-Forking a project is in most cases a two-step process.
+Forking a project is, in most cases, a two-step process.
 
-1. Click on the fork button located in between the star and clone buttons on the project's home page.
+1. On the project's home page, in the top right, click the **Fork** button.
 
    ![Fork button](img/forking_workflow_fork_button.png)
 
-1. Once you do that, you'll be presented with a screen where you can choose
-   the namespace to fork to. Only namespaces (groups and your own
-   namespace) where you have write access to, will be shown. Click on the
-   namespace to create your fork there.
+1. Click a namespace to fork to. Only namespaces you have Developer and higher [permissions](../../permissions.md) for are shown.
+
+   NOTE: **Note:**
+   The project path must be unique within the namespace.
 
    ![Choose namespace](img/forking_workflow_choose_namespace.png)
 
-   **Note:**
-   If the namespace you chose to fork the project to has another project with
-   the same path name, you will be presented with a warning that the forking
-   could not be completed. Try to resolve the error before repeating the forking
-   process.
+The fork is created. The permissions you have in the namespace are the permissions you will have in the fork.
+
+CAUTION: **CAUTION:**
+In GitLab 12.6 and later, when project owners [reduce a project's visibility](../../../public_access/public_access.md#reducing-visibility),
+it **removes the relationship** between a project and all its forks.
 
-   ![Path taken error](img/forking_workflow_path_taken_error.png)
+## Repository mirroring
 
-After the forking is done, you can start working on the newly created
-repository. There, you will have full [Owner](../../permissions.md)
-access, so you can set it up as you please.
+You can use [repository mirroring](repository_mirroring.md) to keep your fork synced with the original repository. You can also use `git remote add upstream` to achieve the same result.
 
-CAUTION: **CAUTION:**
-From GitLab 12.6 onward, if the [visibility of an upstream project is reduced](../../../public_access/public_access.md#reducing-visibility)
-in any way, the fork relationship with all its forks will be removed.
+The main difference is that with repository mirroring your remote fork will be automatically kept up-to-date.
+
+Without mirroring, to work locally you'll have to user `git pull` to update your local repo with the fork on GitLab. You'll have to fetch locally and push it back to the remote repo to update it.
 
 CAUTION: **Caution:**
-[Repository mirroring](repository_mirroring.md) will help to keep your fork synced with the original repository.
-Before approving a merge request you'll likely to be asked to sync before getting approval, hence automating it is recommend.
+With mirroring, before approving a merge request you'll likely to be asked to sync, hence automating it is recommend.
+
+Read more about [How to keep your fork up to date with its origin](https://about.gitlab.com/blog/2016/12/01/how-to-keep-your-fork-up-to-date-with-its-origin/).
 
 ## Merging upstream
 
-Once you are ready to send your code back to the main project, you need
-to create a merge request. Choose your forked project's main branch as
-the source and the original project's main branch as the destination and
-create the [merge request](../merge_requests/index.md).
+When you are ready to send your code back to the upstream project,
+[create a merge request](../merge_requests/creating_merge_requests.md). For **Source branch**,
+choose your forked project's branch. For **Target branch**, choose the original project's branch.
 
 ![Selecting branches](img/forking_workflow_branch_select.png)
 
-You can then assign the merge request to someone to have them review
-your changes. Upon pressing the 'Submit Merge Request' button, your
-changes will be added to the repository and branch you're merging into.
-
-![New merge request](img/forking_workflow_merge_request.png)
+Then you can add labels, a milestone, and assign the merge request to someone who can review
+your changes. Then click **Submit merge request** to conclude the process. When successfully merged, your
+changes are added to the repository and branch you're merging into.
 
 ## Removing a fork relationship
 
diff --git a/doc/user/project/repository/img/forking_workflow_fork_button.png b/doc/user/project/repository/img/forking_workflow_fork_button.png
index 7fb07529b6d..74b68a7e61c 100644
--- a/doc/user/project/repository/img/forking_workflow_fork_button.png
+++ b/doc/user/project/repository/img/forking_workflow_fork_button.png
diff --git a/doc/user/project/repository/img/forking_workflow_merge_request.png b/doc/user/project/repository/img/forking_workflow_merge_request.png
deleted file mode 100644
index 43851203f3f..00000000000
--- a/doc/user/project/repository/img/forking_workflow_merge_request.png
+++ /dev/null
diff --git a/doc/user/project/repository/img/forking_workflow_path_taken_error.png b/doc/user/project/repository/img/forking_workflow_path_taken_error.png
deleted file mode 100644
index ef62d0ab6a9..00000000000
--- a/doc/user/project/repository/img/forking_workflow_path_taken_error.png
+++ /dev/null