Split confidential MR page off into its own

doc/user/project/issues/confidential_issues.md

@@ -67,6 +67,12 @@ There is also an indicator on the sidebar denoting confidentiality.
 | :-----------: | :----------: |
 | ![Sidebar confidential issue](img/sidebar_confidential_issue.png) | ![Sidebar not confidential issue](img/sidebar_not_confidential_issue.png) |
 
+## Merge requests for confidential issues
+
+Although you can make issues be confidential in public projects, you cannot make
+confidential merge requests. Learn how to create [merge requests for confidential issues](../merge_requests/confidential.md)
+that prevent leaks of private data.
+
 ## Permissions and access to confidential issues
 
 There are two kinds of level access for confidential issues. The general rule
@@ -82,48 +88,6 @@ sees in the project's search results respectively.
 |:---------------------------------------------------------------------------------------|:---------------------------------------------------------------------------------|
 | ![Confidential issues search by maintainer](img/confidential_issues_search_master.png) | ![Confidential issues search by guest](img/confidential_issues_search_guest.png) |
 
-## Merge Requests for Confidential Issues
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/58583) in GitLab 12.1.
-
-To help prevent confidential information being leaked from a public project
-in the process of resolving a confidential issue, confidential issues can be
-resolved by creating a merge request from a private fork.
-
-The created merge request targets the default branch of the private fork,
-not the default branch of the public upstream project. This prevents the merge
-request, branch, and commits entering the public repository, and revealing
-confidential information prematurely. To make a confidential commit public,
-open a merge request from the private fork to the public upstream project.
-
-Permissions are inherited from parent groups. Developers have the same permissions
-for private forks created in the same group or in a subgroup of the original
-Permissions are inherited from parent groups. When private forks are created
-in the same group or subgroup as the original upstream repository, users
-receive the same permissions in both projects. This inheritance ensures
-Developer users have the needed permissions to both view confidential issues and
-resolve them.
-
-### How it works
-
-On a confidential issue, a **Create confidential merge request** button is
-available. Clicking on it opens a dropdown where you can choose to
-**Create confidential merge request and branch** or **Create branch**:
-
-| Create confidential merge request | Create branch |
-| :-------------------------------: | :-----------: |
-| ![Create Confidential Merge Request Dropdown](img/confidential_mr_dropdown_v12_1.png) | ![Create Confidential Branch Dropdown](img/confidential_mr_branch_dropdown_v12_1.png) |
-
-The **Project** dropdown includes the list of private forks the user is a member
-of as at least a Developer and merge requests are enabled.
-
-Whenever the **Branch name** and **Source (branch or tag)** fields change, the
-availability of the target and source branch are checked. Both branches should
-be available in the selected private fork.
-
-By clicking the **Create confidential merge request** button, GitLab creates
-the branch and merge request in the private fork. When you choose
-**Create branch**, GitLab creates only the branch.
+## Related links
 
-After the branch is created in the private fork, developers can push code to
-that branch to fix the confidential issue.
+- [Merge requests for confidential issues](../merge_requests/confidential.md)

doc/user/project/merge_requests/confidential.md

+---
+stage: Create
+group: Code Review
+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/#assignments
+---
+
+# Merge requests for confidential issues
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/58583) in GitLab 12.1.
+
+Merge requests in a public repository are also public, even when the merge
+request is created for a [confidential issue](../issues/confidential_issues.md).
+To avoid leaking confidential information when working on a confidential issue,
+create your merge request from a private fork.
+
+Roles are inherited from parent groups. If you create your private fork in the
+same group or subgroup as the original (public) repository, developers receive
+the same permissions in your fork. This inheritance ensures:
+
+- Developer users have the needed permissions to view confidential issues and resolve them.
+- You do not need grant individual users access to your fork.
+
+The [security practices for confidential merge requests](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#security-releases-critical-non-critical-as-a-developer) at GitLab are available to read.
+
+## Create a confidential merge request
+
+WARNING:
+To create a confidential merge request, you must create a private fork. This fork
+may expose confidential information, if you create your fork in another namespace
+that may have other members.
+
+Branches are public by default. To protect the confidentiality of your work, you
+must create your changes in a private fork.
+
+Prerequisites:
+
+- You have the Owner or Maintainer role in the public repository, as you need one
+  of these roles to [create a subgroup](../../group/subgroups/index.md).
+- You have [forked](../repository/forking_workflow.md) the public repository.
+- Your fork has a **Visibility level** of _Private_.
+
+To create a confidential merge request:
+
+1. Go to the confidential issue's page. Scroll below the issue description and
+   select **Create confidential merge request**.
+1. Select the item that meets your needs:
+   - *To create both a branch and a merge request,* select
+     **Create confidential merge request and branch**. Your merge request will
+     target the default branch of your fork, *not* the default branch of the
+     public upstream project.
+   - *To create only a branch,* select **Create branch**.
+1. Select a **Project** to use. These projects have merge requests enabled, and
+   you have the Developer role (or greater) in them.
+1. Provide a **Branch name**, and select a **Source (branch or tag)**. GitLab
+   checks whether these branches are available in your private fork, because both
+   branches must be available in your selected fork.
+1. Select **Create**.
+
+If you created a branch in your private fork, users with the Developer role in the
+public repository can push code to that branch in your private fork to fix the
+confidential issue.
+
+As your merge request targets your private fork, not the public upstream project,
+your branch, merge request, and commits do not enter the public repository. This
+prevents prematurely revealing confidential information.
+
+To make a confidential commit public, open a merge request from the private fork
+to the public upstream project.
+
+## Related links
+
+- [Confidential issues](../issues/confidential_issues.md)
+- [Security practices for confidential merge requests](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#security-releases-critical-non-critical-as-a-developer) at GitLab