Merge branch 'master' into 11711-add-dep-scanner-var11711-add-dep-scanner-var

4 files changed, 5 insertions, 3 deletions

diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index 86f17f4ecdb..b9d55a9395c 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -36,7 +36,7 @@ include a regression test are merged quickly, while new features without proper
 tests might be slower to receive feedback. The workflow to make a merge
 request is as follows:
 
-1. [Fork](../../workflow/forking_workflow.md#creating-a-fork) the project into
+1. [Fork](../../user/project/repository/forking_workflow.md) the project into
    your personal namespace (or group) on GitLab.com.
 1. Create a feature branch in your fork (don't work off `master`).
 1. Write [tests](../rake_tasks.md#run-tests) and code.
diff --git a/doc/development/git_object_deduplication.md b/doc/development/git_object_deduplication.md
index e8af6346524..6d9eb90d482 100644
--- a/doc/development/git_object_deduplication.md
+++ b/doc/development/git_object_deduplication.md
@@ -1,6 +1,6 @@
 # How Git object deduplication works in GitLab
 
-When a GitLab user [forks a project](../workflow/forking_workflow.md),
+When a GitLab user [forks a project](../user/project/repository/forking_workflow.md),
 GitLab creates a new Project with an associated Git repository that is a
 copy of the original project at the time of the fork. If a large project
 gets forked often, this can lead to a quick increase in Git repository
diff --git a/doc/development/pipelines.md b/doc/development/pipelines.md
index cd23ab9226f..8d83cea8c7b 100644
--- a/doc/development/pipelines.md
+++ b/doc/development/pipelines.md
@@ -15,6 +15,8 @@ as much as possible.
 
 The current stages are:
 
+- `sync`: This stage is used to synchronize changes from gitlab-org/gitlab to
+  gitlab-org/gitlab-foss.
 - `prepare`: This stage includes jobs that prepare artifacts that are needed by
   jobs in subsequent stages.
 - `quick-test`: This stage includes test jobs that should run first and fail the
diff --git a/doc/development/repository_mirroring.md b/doc/development/repository_mirroring.md
index 8521d6fcd30..0a0c91821cf 100644
--- a/doc/development/repository_mirroring.md
+++ b/doc/development/repository_mirroring.md
@@ -5,6 +5,6 @@
 In December 2018, Tiago Botelho hosted a [Deep Dive] on GitLab's [Pull Repository Mirroring functionality] to share his domain specific knowledge with anyone who may work in this part of the code base in the future. You can find the [recording on YouTube], and the slides in [PDF]. Everything covered in this deep dive was accurate as of GitLab 11.6, and while specific details may have changed since then, it should still serve as a good introduction.
 
 [Deep Dive]: https://gitlab.com/gitlab-org/create-stage/issues/1
-[Pull Repository Mirroring functionality]: ../workflow/repository_mirroring.md#pulling-from-a-remote-repository-starter
+[Pull Repository Mirroring functionality]: ../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository-starter
 [recording on YouTube]: https://www.youtube.com/watch?v=sSZq0fpdY-Y
 [PDF]: https://gitlab.com/gitlab-org/create-stage/uploads/8693404888a941fd851f8a8ecdec9675/Gitlab_Create_-_Pull_Mirroring_Deep_Dive.pdf