Editing and polish

Made several style and screen shot changes.

Updated images to focus more closely on designated area.

Click rather than click on.

No need to have descriptor after button name.

Changed split infinitive.

Changed 12.6 onward to 12.6 and later.

Once means one time, not after.

Made button text bold. Fixed format of Note.

Tried to write in present tense.

Removed fork error screenshot bc it's not necc.

Changed case of Submit merge request button.

Added details about creating upstream, because I think it is required.

You can merge from any branch to any other branch.

It doesn’t need to be the **main** branch.

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