Add latest changes from gitlab-org/gitlab@13-7-stable-eev13.7.0-rc42

1 files changed, 6 insertions, 6 deletions

diff --git a/doc/user/project/repository/forking_workflow.md b/doc/user/project/repository/forking_workflow.md
index b0aa7569579..75e1aea632f 100644
--- a/doc/user/project/repository/forking_workflow.md
+++ b/doc/user/project/repository/forking_workflow.md
@@ -1,7 +1,7 @@
 ---
 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
+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
 disqus_identifier: 'https://docs.gitlab.com/ee/workflow/forking_workflow.html'
 ---
 
@@ -26,18 +26,18 @@ Forking a project is, in most cases, a two-step process.
 
 1. Click a namespace to fork to. Only namespaces you have Developer and higher [permissions](../../permissions.md) for are shown.
 
-   NOTE: **Note:**
+   NOTE:
    The project path must be unique within the namespace.
 
    ![Choose namespace](img/forking_workflow_choose_namespace_v13_2.png)
 
 The fork is created. The permissions you have in the namespace are the permissions you will have in the fork.
 
-CAUTION: **Caution:**
+WARNING:
 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.
 
-CAUTION: **Caution:**
+WARNING:
 When a public project with the repository feature set to "Members
 only" is forked, the repository will be public in the fork. The owner
 of the fork will need to manually change the visibility. This is being
@@ -52,7 +52,7 @@ The main difference is that with repository mirroring your remote fork will be a
 Without mirroring, to work locally you'll have to use `git pull` to update your local repository
 with the upstream project, then push the changes back to your fork to update it.
 
-CAUTION: **Caution:**
+WARNING:
 With mirroring, before approving a merge request, you'll likely be asked to sync; hence automating it is recommended.
 
 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/).
@@ -63,7 +63,7 @@ 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.
 
-NOTE: **Note:**
+NOTE:
 When creating a merge request, if the forked project's visibility is more restrictive than the parent project (for example the fork is private, the parent is public), the target branch will default to the forked project's default branch. This prevents potentially exposing the private code of the forked project.
 
 ![Selecting branches](img/forking_workflow_branch_select.png)