Add latest changes from gitlab-org/gitlab@master

73 files changed, 564 insertions, 358 deletions

diff --git a/doc/development/README.md b/doc/development/README.md
index e8bebc79124..0d1168c4450 100644
--- a/doc/development/README.md
+++ b/doc/development/README.md
@@ -14,7 +14,7 @@ description: 'Learn how to contribute to GitLab.'
 
 ## Processes
 
-- [GitLab core team & GitLab Inc. contribution process](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/PROCESS.md)
+- [GitLab core team & GitLab Inc. contribution process](https://gitlab.com/gitlab-org/gitlab/blob/master/PROCESS.md)
 - [Generate a changelog entry with `bin/changelog`](changelog.md)
 - [Code review guidelines](code_review.md) for reviewing code and having code reviewed
 - [Database review guidelines](database_review.md) for reviewing database-related changes and complex SQL queries
@@ -142,6 +142,12 @@ description: 'Learn how to contribute to GitLab.'
 - [Externalization](i18n/externalization.md)
 - [Translation](i18n/translation.md)
 
+## Event tracking guides
+
+- [Introduction](event_tracking/index.md)
+- [Frontend tracking guide](event_tracking/frontend.md)
+- [Backend tracking guide](event_tracking/backend.md)
+
 ## Build guides
 
 - [Building a package for testing purposes](build_test_package.md)
diff --git a/doc/development/api_styleguide.md b/doc/development/api_styleguide.md
index 3f81440791e..e3c8c860062 100644
--- a/doc/development/api_styleguide.md
+++ b/doc/development/api_styleguide.md
@@ -14,7 +14,7 @@ Always use an [Entity] to present the endpoint's payload.
 ## Methods and parameters description
 
 Every method must be described using the [Grape DSL](https://github.com/ruby-grape/grape#describing-methods)
-(see <https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/api/environments.rb>
+(see <https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/api/environments.rb>
 for a good example):
 
 - `desc` for the method summary. You should pass it a block for additional
@@ -104,6 +104,6 @@ For instance:
 - endpoint = expose_path(api_v4_projects_issues_related_merge_requests_path(id: @project.id, issue_iid: @issue.iid))
 ```
 
-[Entity]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/api/entities.rb
+[Entity]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/api/entities.rb
 [validation, and coercion of the parameters]: https://github.com/ruby-grape/grape#parameter-validation-and-coercion
 [installing GitLab under a relative URL]: https://docs.gitlab.com/ee/install/relative_url.html
diff --git a/doc/development/architecture.md b/doc/development/architecture.md
index e30b9d27f46..75562f692ad 100644
--- a/doc/development/architecture.md
+++ b/doc/development/architecture.md
@@ -6,7 +6,7 @@ table_display_block: true
 
 ## Software delivery
 
-There are two software distributions of GitLab: the open source [Community Edition](https://gitlab.com/gitlab-org/gitlab-ce/) (CE), and the open core [Enterprise Edition](https://gitlab.com/gitlab-org/gitlab-ee/) (EE). GitLab is available under [different subscriptions](https://about.gitlab.com/pricing/).
+There are two software distributions of GitLab: the open source [Community Edition](https://gitlab.com/gitlab-org/gitlab-foss/) (CE), and the open core [Enterprise Edition](https://gitlab.com/gitlab-org/gitlab/) (EE). GitLab is available under [different subscriptions](https://about.gitlab.com/pricing/).
 
 New versions of GitLab are released in stable branches and the master branch is for bleeding edge development.
 
@@ -16,7 +16,7 @@ Both EE and CE require some add-on components called GitLab Shell and Gitaly. Th
 
 ## Components
 
-A typical install of GitLab will be on GNU/Linux. It uses Nginx or Apache as a web front end to proxypass the Unicorn web server. By default, communication between Unicorn and the front end is via a Unix domain socket but forwarding requests via TCP is also supported. The web front end accesses `/home/git/gitlab/public` bypassing the Unicorn server to serve static pages, uploads (e.g. avatar images or attachments), and precompiled assets. GitLab serves web pages and a [GitLab API](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc/api) using the Unicorn web server. It uses Sidekiq as a job queue which, in turn, uses redis as a non-persistent database backend for job information, meta data, and incoming jobs.
+A typical install of GitLab will be on GNU/Linux. It uses Nginx or Apache as a web front end to proxypass the Unicorn web server. By default, communication between Unicorn and the front end is via a Unix domain socket but forwarding requests via TCP is also supported. The web front end accesses `/home/git/gitlab/public` bypassing the Unicorn server to serve static pages, uploads (e.g. avatar images or attachments), and precompiled assets. GitLab serves web pages and a [GitLab API](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/doc/api) using the Unicorn web server. It uses Sidekiq as a job queue which, in turn, uses redis as a non-persistent database backend for job information, meta data, and incoming jobs.
 
 We also support deploying GitLab on Kubernetes using our [GitLab Helm chart](https://docs.gitlab.com/charts/).
 
@@ -78,11 +78,11 @@ graph TB
   PgBouncerExporter[PgBouncer Exporter] --> PgBouncer
   Prometheus -- TCP 9187 --> PostgreSQLExporter
   Prometheus -- TCP 9100 --> NodeExporter[Node Exporter]
-  Prometheus -- TCP 9168 --> GitLabMonitor[GitLab Monitor]
+  Prometheus -- TCP 9168 --> GitLabExporter[GitLab Exporter]
   Prometheus -- TCP 9127 --> PgBouncerExporter
-  GitLabMonitor --> PostgreSQL
-  GitLabMonitor --> GitLabShell
-  GitLabMonitor --> Sidekiq
+  GitLabExporter --> PostgreSQL
+  GitLabExporter --> GitLabShell
+  GitLabExporter --> Sidekiq
   PgBouncer --> Consul
   PostgreSQL --> Consul
   PgBouncer --> PostgreSQL
@@ -147,7 +147,7 @@ Component statuses are linked to configuration documentation for each component.
 | [Redis Exporter](#redis-exporter) | Prometheus endpoint with Redis metrics | [✅][redis-exporter-omnibus] | [✅][redis-exporter-charts] | [✅][redis-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
 | [Postgres Exporter](#postgres-exporter) | Prometheus endpoint with PostgreSQL metrics | [✅][postgres-exporter-omnibus] | [✅][postgres-exporter-charts] | [✅][postgres-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
 | [PgBouncer Exporter](#pgbouncer-exporter) | Prometheus endpoint with PgBouncer metrics | [⚙][pgbouncer-exporter-omnibus] | [❌][pgbouncer-exporter-charts] | [❌][pgbouncer-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
-| [GitLab Monitor](#gitlab-monitor) | Generates a variety of GitLab metrics | [✅][gitlab-monitor-omnibus] | [✅][gitlab-monitor-charts] | [✅][gitlab-monitor-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
+| [GitLab Exporter](#gitlab-exporter) | Generates a variety of GitLab metrics | [✅][gitlab-exporter-omnibus] | [✅][gitlab-exporter-charts] | [✅][gitlab-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
 | [Node Exporter](#node-exporter) | Prometheus endpoint with system metrics | [✅][node-exporter-omnibus] | [❌][node-exporter-charts] | [❌][node-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
 | [Mattermost](#mattermost) | Open-source Slack alternative | [⚙][mattermost-omnibus] | [⤓][mattermost-charts] | [⤓][mattermost-charts] | [⤓](../user/project/integrations/mattermost.md) | ❌ | ❌ | CE & EE |
 | [MinIO](#minio) | Object storage service | [⤓][minio-omnibus] | [✅][minio-charts] | [✅][minio-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/#storage-architecture) | ❌ | [⚙][minio-gdk] | CE & EE |
@@ -185,7 +185,7 @@ GitLab can be considered to have two layers from a process perspective:
 - Layer: Monitoring
 - Process: `alertmanager`
 
-[Alert manager](https://prometheus.io/docs/alerting/alertmanager/) is a tool provided by Prometheus that _"handles alerts sent by client applications such as the Prometheus server. It takes care of deduplicating, grouping, and routing them to the correct receiver integration such as email, PagerDuty, or OpsGenie. It also takes care of silencing and inhibition of alerts."_ You can read more in [issue #45740](https://gitlab.com/gitlab-org/gitlab-ce/issues/45740) about what we will be alerting on.
+[Alert manager](https://prometheus.io/docs/alerting/alertmanager/) is a tool provided by Prometheus that _"handles alerts sent by client applications such as the Prometheus server. It takes care of deduplicating, grouping, and routing them to the correct receiver integration such as email, PagerDuty, or OpsGenie. It also takes care of silencing and inhibition of alerts."_ You can read more in [issue #45740](https://gitlab.com/gitlab-org/gitlab-foss/issues/45740) about what we will be alerting on.
 
 #### Certificate management
 
@@ -228,14 +228,14 @@ Gitaly is a service designed by GitLab to remove our need for NFS for Git storag
 - Configuration: [Omnibus][geo-omnibus], [Charts][geo-charts], [GDK][geo-gdk]
 - Layer: Core Service (Processor)
 
-#### GitLab Monitor
+#### Gitlab Exporter
 
-- [Project page](https://gitlab.com/gitlab-org/gitlab-monitor)
-- Configuration: [Omnibus][gitlab-monitor-omnibus], [Charts][gitlab-monitor-charts]
+- [Project page](https://gitlab.com/gitlab-org/gitlab-exporter)
+- Configuration: [Omnibus][gitlab-exporter-omnibus], [Charts][gitlab-exporter-charts]
 - Layer: Monitoring
-- Process: `gitlab-monitor`
+- Process: `gitlab-exporter`
 
-GitLab Monitor is a process designed in house that allows us to export metrics about GitLab application internals to Prometheus. You can read more [in the project's readme](https://gitlab.com/gitlab-org/gitlab-monitor).
+GitLab Exporter is a process designed in house that allows us to export metrics about GitLab application internals to Prometheus. You can read more [in the project's readme](https://gitlab.com/gitlab-org/gitlab-exporter).
 
 #### GitLab Pages
 
@@ -432,7 +432,7 @@ Sidekiq is a Ruby background job processor that pulls jobs from the redis queue
 
 #### Unicorn
 
-- [Project page](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/README.md)
+- [Project page](https://gitlab.com/gitlab-org/gitlab/blob/master/README.md)
 - Configuration: [Omnibus][unicorn-omnibus], [Charts][unicorn-charts], [Source][unicorn-source], [GDK][gitlab-yml]
 - Layer: Core Service (Processor)
 - Process: `unicorn`
@@ -614,7 +614,7 @@ GitLab Shell has a configuration file at `/home/git/gitlab-shell/config.yml`.
 
 ### Maintenance Tasks
 
-[GitLab](https://gitlab.com/gitlab-org/gitlab-ce/tree/master) provides rake tasks with which you see version information and run a quick check on your configuration to ensure it is configured properly within the application. See [maintenance rake tasks](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/raketasks/maintenance.md).
+[GitLab](https://gitlab.com/gitlab-org/gitlab/tree/master) provides rake tasks with which you see version information and run a quick check on your configuration to ensure it is configured properly within the application. See [maintenance rake tasks](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/doc/raketasks/maintenance.md).
 In a nutshell, do the following:
 
 ```
@@ -638,7 +638,7 @@ We've also detailed [our architecture of GitLab.com](https://about.gitlab.com/ha
 [unicorn-omnibus]: https://docs.gitlab.com/omnibus/settings/unicorn.html
 [unicorn-charts]: https://docs.gitlab.com/charts/charts/gitlab/unicorn/
 [unicorn-source]: ../install/installation.md#configure-it
-[gitlab-yml]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/config/gitlab.yml.example
+[gitlab-yml]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/config/gitlab.yml.example
 [sidekiq-omnibus]: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template
 [sidekiq-charts]: https://docs.gitlab.com/charts/charts/gitlab/sidekiq/
 [gitaly-omnibus]: ../administration/gitaly/index.md
@@ -684,8 +684,8 @@ We've also detailed [our architecture of GitLab.com](https://about.gitlab.com/ha
 [postgres-exporter-charts]: https://github.com/helm/charts/tree/master/stable/postgresql
 [pgbouncer-exporter-omnibus]: ../administration/monitoring/prometheus/pgbouncer_exporter.md
 [pgbouncer-exporter-charts]: https://docs.gitlab.com/charts/installation/deployment.html#postgresql
-[gitlab-monitor-omnibus]: ../administration/monitoring/prometheus/gitlab_monitor_exporter.md
-[gitlab-monitor-charts]: https://docs.gitlab.com/charts/charts/gitlab/gitlab-monitor/index.html
+[gitlab-exporter-omnibus]: ../administration/monitoring/prometheus/gitlab_exporter.md
+[gitlab-exporter-charts]: https://docs.gitlab.com/charts/charts/gitlab/gitlab-exporter/index.html
 [node-exporter-omnibus]: ../administration/monitoring/prometheus/node_exporter.md
 [node-exporter-charts]: https://gitlab.com/gitlab-org/charts/gitlab/issues/1332
 [mattermost-omnibus]: https://docs.gitlab.com/omnibus/gitlab-mattermost/
diff --git a/doc/development/automatic_ce_ee_merge.md b/doc/development/automatic_ce_ee_merge.md
index c2700461467..f7816091b49 100644
--- a/doc/development/automatic_ce_ee_merge.md
+++ b/doc/development/automatic_ce_ee_merge.md
@@ -174,9 +174,9 @@ Now, every time you create an MR for CE and EE:
 ## How we run the Automatic CE->EE merge at GitLab
 
 At GitLab, we use the [Merge Train](https://gitlab.com/gitlab-org/merge-train)
-project to keep our [GitLab EE](https://gitlab.com/gitlab-org/gitlab-ee)
+project to keep our [GitLab EE](https://gitlab.com/gitlab-org/gitlab)
 repository updated with commits from
-[GitLab CE](https://gitlab.com/gitlab-org/gitlab-ce).
+[GitLab CE](https://gitlab.com/gitlab-org/gitlab-foss).
 
 We have a mirror of the [Merge Train](https://gitlab.com/gitlab-org/merge-train)
 project [configured](https://ops.gitlab.net/gitlab-org/merge-train) to run an
diff --git a/doc/development/background_migrations.md b/doc/development/background_migrations.md
index 606ee431c3e..364e276b6cc 100644
--- a/doc/development/background_migrations.md
+++ b/doc/development/background_migrations.md
@@ -315,7 +315,7 @@ for more details.
    more pressure on DB than you expect (measure on staging,
    or ask someone to measure on production).
 
-[migrations-readme]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/spec/migrations/README.md
-[issue-rspec-hooks]: https://gitlab.com/gitlab-org/gitlab-ce/issues/35351
-[reliable-sidekiq]: https://gitlab.com/gitlab-org/gitlab-ce/issues/36791
+[migrations-readme]: https://gitlab.com/gitlab-org/gitlab/blob/master/spec/migrations/README.md
+[issue-rspec-hooks]: https://gitlab.com/gitlab-org/gitlab-foss/issues/35351
+[reliable-sidekiq]: https://gitlab.com/gitlab-org/gitlab-foss/issues/36791
 [import-export]: ../user/project/settings/import_export.md
diff --git a/doc/development/changelog.md b/doc/development/changelog.md
index afc18885a80..cd09438e7c7 100644
--- a/doc/development/changelog.md
+++ b/doc/development/changelog.md
@@ -27,8 +27,8 @@ valid options are: added, fixed, changed, deprecated, removed, security, perform
 Community contributors and core team members are encouraged to add their name to
 the `author` field. GitLab team members **should not**.
 
-[changelog.md]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG.md
-[unreleased]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/changelogs/
+[changelog.md]: https://gitlab.com/gitlab-org/gitlab/blob/master/CHANGELOG.md
+[unreleased]: https://gitlab.com/gitlab-org/gitlab-foss/tree/master/changelogs/
 [YAML]: https://en.wikipedia.org/wiki/YAML
 
 ## What warrants a changelog entry?
@@ -284,7 +284,7 @@ and then compiling the entries into the overall `CHANGELOG.md` file during the
 
 [boring solution]: https://about.gitlab.com/handbook/values/#boring-solutions
 [release managers]: https://gitlab.com/gitlab-org/release/docs/blob/master/quickstart/release-manager.md
-[started brainstorming]: https://gitlab.com/gitlab-org/gitlab-ce/issues/17826
+[started brainstorming]: https://gitlab.com/gitlab-org/gitlab-foss/issues/17826
 [release process]: https://gitlab.com/gitlab-org/release-tools
 
 ---
diff --git a/doc/development/chatops_on_gitlabcom.md b/doc/development/chatops_on_gitlabcom.md
index 3b681880401..09d6638924a 100644
--- a/doc/development/chatops_on_gitlabcom.md
+++ b/doc/development/chatops_on_gitlabcom.md
@@ -9,6 +9,7 @@ tasks such as:
 
 - Configuring feature flags.
 - Running `EXPLAIN` queries against the GitLab.com production replica.
+- Get deployment status of all of our environments or for a specific commit: `/chatops run auto_deploy status [commit_sha]`
 
 To request access to Chatops on GitLab.com:
 
diff --git a/doc/development/code_comments.md b/doc/development/code_comments.md
index 827a610efa2..c1d58c1bd4b 100644
--- a/doc/development/code_comments.md
+++ b/doc/development/code_comments.md
@@ -9,6 +9,6 @@ Examples:
 
 ```rb
 # Deprecated scope until code_owner column has been migrated to rule_type.
-# To be removed with https://gitlab.com/gitlab-org/gitlab-ee/issues/11834.
+# To be removed with https://gitlab.com/gitlab-org/gitlab/issues/11834.
 scope :code_owner, -> { where(code_owner: true).or(where(rule_type: :code_owner)) }
 ```
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index ce9f794c1a3..f616eb90bda 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -185,6 +185,7 @@ without duly verifying them.
 
 ### Everyone
 
+- Be kind.
 - Accept that many programming decisions are opinions. Discuss tradeoffs, which
   you prefer, and reach a resolution quickly.
 - Ask questions; don't make demands. ("What do you think about naming this
@@ -231,6 +232,9 @@ first time.
 - Push commits based on earlier rounds of feedback as isolated commits to the
   branch. Do not squash until the branch is ready to merge. Reviewers should be
   able to read individual updates based on their earlier feedback.
+- Assign the merge request back to the reviewer once you are ready for another round of
+  review. If you do not have the ability to assign merge requests, `@`
+  mention the reviewer instead.
 
 ### Assigning a merge request for a review
 
@@ -254,7 +258,7 @@ even when this may negatively impact their other tasks and priorities.
 Doing so allows everyone involved in the merge request to iterate faster as the
 context is fresh in memory, improves contributors' experiences significantly,
 and gives authors more time to address feedback and iterate on their work before
-the [feature freeze](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/PROCESS.md#feature-freeze-on-the-7th-for-the-release-on-the-22nd).
+the [feature freeze](https://gitlab.com/gitlab-org/gitlab/blob/master/PROCESS.md#feature-freeze-on-the-7th-for-the-release-on-the-22nd).
 
 A turnaround time of two working days is usually acceptable, since engineers
 will typically have other things to work on while they're waiting for review,
@@ -262,7 +266,7 @@ but don't hesitate to ask the author if it's unclear what time frame would be
 acceptable, how urgent the review is, or how significant the blockage. Authors
 are also encouraged to provide this information up-front to reviewers, but are
 expected to be mindful of the [guidelines on when to ask for review on MRs that
-are intended to go in before the feature freeze](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/PROCESS.md#between-the-1st-and-the-7th),
+are intended to go in before the feature freeze](https://gitlab.com/gitlab-org/gitlab/blob/master/PROCESS.md#between-the-1st-and-the-7th),
 and realistic in their expectations if these were not followed.
 
 If you don't think you'll be able to review a merge request within a reasonable
@@ -290,6 +294,10 @@ experience, refactors the existing code). Then:
 - Seek to understand the author's perspective.
 - If you don't understand a piece of code, _say so_. There's a good chance
   someone else would be confused by it as well.
+- Do prefix your comment with "Not blocking:" if you have a small,
+  non-mandatory improvement you wish to suggest. This lets the author
+  know that they can optionally resolve this issue in this merge request
+  or follow-up at a later stage.
 - After a round of line notes, it can be helpful to post a summary note such as
   "LGTM :thumbsup:", or "Just a couple things to address."
 - Assign the merge request to the author if changes are required following your
@@ -393,25 +401,25 @@ Enterprise Edition instance. This has some implications:
 
 How code reviews are conducted can surprise new contributors. Here are some examples of code reviews that should help to orient you as to what to expect.
 
-**["Modify `DiffNote` to reuse it for Designs"](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/13703):**
+**["Modify `DiffNote` to reuse it for Designs"](https://gitlab.com/gitlab-org/gitlab/merge_requests/13703):**
 It contained everything from nitpicks around newlines to reasoning
 about what versions for designs are, how we should compare them
 if there was no previous version of a certain file (parent vs.
 blank `sha` vs empty tree).
 
-**["Support multi-line suggestions"](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/25211)**:
+**["Support multi-line suggestions"](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/25211)**:
 The MR itself consists of a collaboration between FE and BE,
 and documenting comments from the author for the reviewer.
 There's some nitpicks, some questions for information, and
 towards the end, a security vulnerability.
 
-**["Allow multiple repositories per project"](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10251)**:
+**["Allow multiple repositories per project"](https://gitlab.com/gitlab-org/gitlab/merge_requests/10251)**:
 ZJ referred to the other projects (workhorse) this might impact,
 suggested some improvements for consistency. And James' comments
 helped us with overall code quality (using delegation, `&.` those
 types of things), and making the code more robust.
 
-**["Support multiple assignees for merge requests"](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10161)**:
+**["Support multiple assignees for merge requests"](https://gitlab.com/gitlab-org/gitlab/merge_requests/10161)**:
 A  good example of collaboration on an MR touching multiple parts of the codebase. Nick pointed out interesting edge cases, James Lopes also joined in raising concerns on import/export feature.
 
 ### Credits
diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md
index 887f17b05b8..694f8d2cb45 100644
--- a/doc/development/contributing/index.md
+++ b/doc/development/contributing/index.md
@@ -16,7 +16,7 @@ abbreviation.
 To get an overview of GitLab community membership including those that would be reviewing or merging your contributions, please visit [the community roles page](community_roles.md).
 
 If you want to know how the GitLab [core team]
-operates please see [the GitLab contributing process](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/PROCESS.md).
+operates please see [the GitLab contributing process](https://gitlab.com/gitlab-org/gitlab/blob/master/PROCESS.md).
 
 [GitLab Inc engineers should refer to the engineering workflow document](https://about.gitlab.com/handbook/engineering/workflow/)
 
diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md
index 8b5d380ad9e..810d03e82c5 100644
--- a/doc/development/contributing/issue_workflow.md
+++ b/doc/development/contributing/issue_workflow.md
@@ -2,12 +2,12 @@
 
 ## Issue tracker guidelines
 
-**[Search the issue tracker](https://gitlab.com/gitlab-org/gitlab-ce/issues)** for similar entries before
+**[Search the issue tracker](https://gitlab.com/gitlab-org/gitlab-foss/issues)** for similar entries before
 submitting your own, there's a good chance somebody else had the same issue or
 feature proposal. Show your support with an award emoji and/or join the
 discussion.
 
-Please submit bugs using the ['Bug' issue template](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab/issue_templates/Bug.md) provided on the issue tracker.
+Please submit bugs using the ['Bug' issue template](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/issue_templates/Bug.md) provided on the issue tracker.
 The text in the parenthesis is there to help you with what to include. Omit it
 when submitting the actual issue. You can copy-paste it and then edit as you
 see fit.
@@ -16,7 +16,7 @@ see fit.
 
 Our issue triage policies are [described in our handbook](https://about.gitlab.com/handbook/engineering/issue-triage/).
 You are very welcome to help the GitLab team triage issues.
-We also organize [issue bash events](https://gitlab.com/gitlab-org/gitlab-ce/issues/17815)
+We also organize [issue bash events](https://gitlab.com/gitlab-org/gitlab-foss/issues/17815)
 once every quarter.
 
 The most important thing is making sure valid issues receive feedback from the
@@ -34,7 +34,7 @@ running on [quality/triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops
 ## Labels
 
 To allow for asynchronous issue handling, we use [milestones](https://gitlab.com/groups/gitlab-org/-/milestones)
-and [labels](https://gitlab.com/gitlab-org/gitlab-ce/-/labels). Leads and product managers handle most of the
+and [labels](https://gitlab.com/gitlab-org/gitlab-foss/-/labels). Leads and product managers handle most of the
 scheduling into milestones. Labelling is a task for everyone.
 
 Most issues will have labels for at least one of the following:
@@ -52,7 +52,7 @@ Most issues will have labels for at least one of the following:
 - Severity: ~S1, ~S2, ~S3, ~S4
 
 All labels, their meaning and priority are defined on the
-[labels page](https://gitlab.com/gitlab-org/gitlab-ce/-/labels).
+[labels page](https://gitlab.com/gitlab-org/gitlab-foss/-/labels).
 
 If you come across an issue that has none of these, and you're allowed to set
 labels, you can _always_ add the team and type, and often also the subject.
@@ -360,18 +360,18 @@ features from GitLab EE to GitLab CE, related issues would be labelled with
 ~"stewardship".
 
 A recent example of this was the issue for
-[bringing the time tracking API to GitLab CE](https://gitlab.com/gitlab-org/gitlab-ce/issues/25517#note_20019084).
+[bringing the time tracking API to GitLab CE](https://gitlab.com/gitlab-org/gitlab-foss/issues/25517#note_20019084).
 
 ## Feature proposals
 
 To create a feature proposal for CE, open an issue on the
-[issue tracker of CE](https://gitlab.com/gitlab-org/gitlab-ce/issues).
+[issue tracker of CE](https://gitlab.com/gitlab-org/gitlab-foss/issues).
 
 For feature proposals for EE, open an issue on the
-[issue tracker of EE](https://gitlab.com/gitlab-org/gitlab-ee/issues).
+[issue tracker of EE](https://gitlab.com/gitlab-org/gitlab/issues).
 
 In order to help track the feature proposals, we have created a
-[`feature`](https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name=feature) label. For the time being, users that are not members
+[`feature`](https://gitlab.com/gitlab-org/gitlab-foss/issues?label_name=feature) label. For the time being, users that are not members
 of the project cannot add labels. You can instead ask one of the [core team](https://about.gitlab.com/community/core-team/)
 members to add the label ~feature to the issue or add the following
 code snippet right after your description in a new line: `~feature`.
@@ -379,7 +379,7 @@ code snippet right after your description in a new line: `~feature`.
 Please keep feature proposals as small and simple as possible, complex ones
 might be edited to make them small and simple.
 
-Please submit Feature Proposals using the ['Feature Proposal' issue template](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab/issue_templates/Feature%20proposal.md) provided on the issue tracker.
+Please submit Feature Proposals using the ['Feature Proposal' issue template](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/issue_templates/Feature%20proposal.md) provided on the issue tracker.
 
 For changes in the interface, it is helpful to include a mockup. Issues that add to, or change, the interface should
 be given the ~"UX" label. This will allow the UX team to provide input and guidance. You may
@@ -427,13 +427,13 @@ and the merge request.
 The release manager will [update the notes] in the regression issue as fixes are
 addressed.
 
-[8.3 Regressions]: https://gitlab.com/gitlab-org/gitlab-ce/issues/4127
+[8.3 Regressions]: https://gitlab.com/gitlab-org/gitlab-foss/issues/4127
 [update the notes]: https://gitlab.com/gitlab-org/release-tools/blob/master/doc/pro-tips.md#update-the-regression-issue
 
 ## Technical and UX debt
 
 In order to track things that can be improved in GitLab's codebase,
-we use the ~"technical debt" label in [GitLab's issue tracker](https://gitlab.com/gitlab-org/gitlab-ce/issues).
+we use the ~"technical debt" label in [GitLab's issue tracker](https://gitlab.com/gitlab-org/gitlab-foss/issues).
 For missed user experience requirements, we use the ~"UX debt" label.
 
 These labels should be added to issues that describe things that can be improved,
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index bdb026d498d..1931dda7151 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -15,8 +15,8 @@ to be marked as `Accepting Merge Requests`. Please include screenshots or
 wireframes of the proposed feature if it will also change the UI.
 
 Merge requests should be submitted to the appropriate project at GitLab.com, for example
-[GitLab CE](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests),
-[GitLab EE](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests),
+[GitLab CE](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests),
+[GitLab EE](https://gitlab.com/gitlab-org/gitlab/merge_requests),
 [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests),
 [GitLab Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests), etc.
 
@@ -140,7 +140,7 @@ When writing commit messages, please follow the guidelines below:
 - The merge request must not contain more than 10 commit messages.
 
 If the guidelines are not met, the MR will not pass the
-[Danger checks](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/danger/commit_messages/Dangerfile).
+[Danger checks](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/danger/commit_messages/Dangerfile).
 For more information see [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/).
 
 Example commit message template that can be used on your machine that embodies the above (guide for [how to apply template](https://codeinthehole.com/tips/a-useful-template-for-commit-messages/)):
@@ -244,5 +244,5 @@ request:
 1. [The upgrade guide](../../update/upgrading_from_source.md).
 1. The [GitLab Installation Guide](../../install/installation.md#1-packages-and-dependencies).
 1. The [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit).
-1. The [CI environment preparation](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/scripts/prepare_build.sh).
+1. The [CI environment preparation](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/scripts/prepare_build.sh).
 1. The [Omnibus package creator](https://gitlab.com/gitlab-org/omnibus-gitlab).
diff --git a/doc/development/dangerbot.md b/doc/development/dangerbot.md
index 6bf59209d21..a6650a50878 100644
--- a/doc/development/dangerbot.md
+++ b/doc/development/dangerbot.md
@@ -15,9 +15,9 @@ to the existing rules, then this is the document for you.
 
 ## Operation
 
-On startup, Danger reads a [`Dangerfile`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/Dangerfile)
+On startup, Danger reads a [`Dangerfile`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/Dangerfile)
 from the project root. GitLab's Danger code is decomposed into a set of helpers
-and plugins, all within the [`danger/`](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/danger/)
+and plugins, all within the [`danger/`](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/danger/)
 subdirectory, so ours just tells Danger to load it all. Danger will then run
 each plugin against the merge request, collecting the output from each. A plugin
 may output notifications, warnings, or errors, all of which are copied to the
diff --git a/doc/development/database_merge_request_checklist.md b/doc/development/database_merge_request_checklist.md
index 48864c81592..09dece27e8d 100644
--- a/doc/development/database_merge_request_checklist.md
+++ b/doc/development/database_merge_request_checklist.md
@@ -9,7 +9,7 @@ To use the checklist, create a new merge request and click on the "Choose a
 template" dropdown, then click "Database changes".
 
 An example of this checklist can be found at
-<https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12463>.
+<https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12463>.
 
 The source code of the checklist can be found in at
-<https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab/merge_request_templates/Database%20changes.md>
+<https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/merge_request_templates/Database%20changes.md>
diff --git a/doc/development/database_review.md b/doc/development/database_review.md
index 157c64b514c..57cdc2135aa 100644
--- a/doc/development/database_review.md
+++ b/doc/development/database_review.md
@@ -36,7 +36,7 @@ A Merge Request author's role is to:
 
 - Decide whether a database review is needed.
 - If database review is needed, add the ~database label.
-- Use the [database changes](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab/merge_request_templates/Database%20changes.md)
+- Use the [database changes](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/merge_request_templates/Database%20changes.md)
   merge request template, or include the appropriate items in the MR description.
 - [Prepare the merge request for a database review](#how-to-prepare-the-merge-request-for-a-database-review).
 
@@ -59,7 +59,7 @@ A database **maintainer**'s role is to:
 ### Distributing review workload
 
 Review workload is distributed using [reviewer roulette](code_review.md#reviewer-roulette)
-([example](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/25181#note_147551725)).
+([example](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/25181#note_147551725)).
 The MR author should then co-assign the suggested database
 **reviewer**. When they give their sign-off, they will hand over to
 the suggested database **maintainer**.
diff --git a/doc/development/documentation/feature-change-workflow.md b/doc/development/documentation/feature-change-workflow.md
index 38ccae41df4..4512b0fc987 100644
--- a/doc/development/documentation/feature-change-workflow.md
+++ b/doc/development/documentation/feature-change-workflow.md
@@ -69,7 +69,7 @@ To follow a consistent workflow every month, documentation changes
 involve the Product Managers, the developer who shipped the feature,
 and the technical writer for the DevOps stage. Each role is described below.
 
-The Documentation items in the GitLab CE/EE [Feature Proposal issue template](https://gitlab.com/gitlab-org/gitlab-ce/raw/master/.gitlab/issue_templates/Feature%20proposal.md)
+The Documentation items in the GitLab CE/EE [Feature Proposal issue template](https://gitlab.com/gitlab-org/gitlab/raw/master/.gitlab/issue_templates/Feature%20proposal.md)
 and default merge request template will assist you with following this process.
 
 ### Product Manager role
@@ -112,7 +112,7 @@ For feature issues requiring documentation, follow the process below unless othe
   in your issue or MR, or write within `#docs` on the GitLab Slack.
 - If you are working on documentation in a separate MR, ensure that if the code is merged by the 17th, the docs are as well, per the [Engineering Workflow](https://about.gitlab.com/handbook/engineering/workflow/). If the docs are not ready, the PM can approve merging the code if the engineer and tech writer commit to get documentation merged by the 21st. Otherwise the feature is not considered complete, and should not be merged.
 - A policy for documenting feature-flagged
-  issues is forthcoming and you are welcome to join the [discussion](https://gitlab.com/gitlab-org/gitlab-ce/issues/56813).
+  issues is forthcoming and you are welcome to join the [discussion](https://gitlab.com/gitlab-org/gitlab-foss/issues/56813).
 
 #### Reviews and merging
 
@@ -131,10 +131,10 @@ All reviewers can help ensure accuracy, clarity, completeness, and adherence to
        the maintainer can merge the current doc changes (if complete) and create a follow-up doc review issue.
      - The technical writer can also help decide what docs to merge before the freeze and whether to work on further changes in a follow up MR.
      - **To request a pre-merge technical writer review**, assign the writer listed for the applicable [DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages).
-     - **To request a post-merge technical writer review**, [create an issue for one using the Doc Review template](https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issuable_template=Doc%20Review) and link it from the MR that makes the doc change.
+     - **To request a post-merge technical writer review**, [create an issue for one using the Doc Review template](https://gitlab.com/gitlab-org/gitlab-foss/issues/new?issuable_template=Doc%20Review) and link it from the MR that makes the doc change.
   1. **The maintainer** who is assigned to merge the MR, to verify clarity, completeness, and quality, to the best of their ability.
 
-- Upon merging, if a technical writer review has not been performed and there is not yet a linked issue for a follow-up review, the maintainer should [create an issue using the Doc Review template](https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issuable_template=Doc%20Review), link it from the MR, and
+- Upon merging, if a technical writer review has not been performed and there is not yet a linked issue for a follow-up review, the maintainer should [create an issue using the Doc Review template](https://gitlab.com/gitlab-org/gitlab-foss/issues/new?issuable_template=Doc%20Review), link it from the MR, and
   mention the original MR author in the new issue. Alternatively, the maintainer can ask the MR author to create and link this issue before the MR is merged.
 
 - After merging, documentation changes are reviewed by:
diff --git a/doc/development/documentation/improvement-workflow.md b/doc/development/documentation/improvement-workflow.md
index 80fbd4b6427..9f3b789712f 100644
--- a/doc/development/documentation/improvement-workflow.md
+++ b/doc/development/documentation/improvement-workflow.md
@@ -47,17 +47,17 @@ The process can involve the following parties/phases, and is replicated in the `
 **1. Primary Reviewer** - Review by a [code reviewer](https://about.gitlab.com/handbook/engineering/projects/) or other appropriate colleague to confirm accuracy, clarity, and completeness. This can be skipped for minor fixes without substantive content changes.
 
 **2. Technical Writer** - Optional - If not requested for this MR, must be scheduled post-merge. To request a pre-merge review, assign the writer listed for the applicable [DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages).
-To request a post-merge review, [create an issue for one using the Doc Review template](https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issuable_template=Doc%20Review) and link it from the MR that makes the doc change.
+To request a post-merge review, [create an issue for one using the Doc Review template](https://gitlab.com/gitlab-org/gitlab-foss/issues/new?issuable_template=Doc%20Review) and link it from the MR that makes the doc change.
 
 **3. Maintainer**
 
 1. Review by assigned maintainer, who can always request/require the above reviews. Maintainer review can occur before or after a technical writer review.
 1. Ensure a release milestone of the format XX.Y is set. If the freeze for that release has begun, add the label `pick into <XX.Y>` unless this change is not required for the release. In that case, simply change the milestone.
 1. If EE and CE MRs exist, merge the EE MR first, then the CE MR.
-1. After merging, if there has not been a technical writer review and an issue for a follow-up review was not already created and linked from the MR, [create the issue using the Doc Review template](https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issuable_template=Doc%20Review) and link it from the MR.
+1. After merging, if there has not been a technical writer review and an issue for a follow-up review was not already created and linked from the MR, [create the issue using the Doc Review template](https://gitlab.com/gitlab-org/gitlab-foss/issues/new?issuable_template=Doc%20Review) and link it from the MR.
 
 ## Other ways to help
 
 If you have ideas for further documentation resources that would be best
-considered/handled by technical writers, devs, and other SMEs, please [create an issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issuable_template=Documentation)
+considered/handled by technical writers, devs, and other SMEs, please [create an issue](https://gitlab.com/gitlab-org/gitlab-foss/issues/new?issuable_template=Documentation)
 using the Documentation template.
diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md
index 87892722d5e..4ad24d08d17 100644
--- a/doc/development/documentation/index.md
+++ b/doc/development/documentation/index.md
@@ -28,7 +28,7 @@ The source of the documentation exists within the codebase of each GitLab applic
 | --- | --- |
 | [GitLab](https://gitlab.com/gitlab-org/gitlab/) | [`/doc`](https://gitlab.com/gitlab-org/gitlab/tree/master/doc) |
 | [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/) | [`/docs`](https://gitlab.com/gitlab-org/gitlab-runner/tree/master/docs) |
-| [Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/) | [`/doc`](https://gitlab.com/gitlab-org/gitlab-ee/tree/master/doc) |
+| [Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/) | [`/doc`](https://gitlab.com/gitlab-org/gitlab/tree/master/doc) |
 
 Documentation issues and merge requests are part of their respective repositories and all have the label `Documentation`.
 
diff --git a/doc/development/documentation/styleguide.md b/doc/development/documentation/styleguide.md
index 39b5e191a7b..79797107a5b 100644
--- a/doc/development/documentation/styleguide.md
+++ b/doc/development/documentation/styleguide.md
@@ -124,8 +124,8 @@ Because we want documentation to be a SSOT, we should [organize by topic, not by
 
 ### Folder structure overview
 
-The documentation is separated by top-level audience folders [`user`](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc/user),
-[`administration`](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc/administration), and [`development`](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc/development) (contributing) folders.
+The documentation is separated by top-level audience folders [`user`](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/doc/user),
+[`administration`](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/doc/administration), and [`development`](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/doc/development) (contributing) folders.
 
 Beyond that, we primarily follow the structure of the GitLab user interface or API.
 
@@ -503,7 +503,7 @@ Instead:
 Example:
 
 ```md
-For more information, see the [confidential issue](../../user/project/issues/confidential_issues.md) `https://gitlab.com/gitlab-org/gitlab-ce/issues/<issue_number>`.
+For more information, see the [confidential issue](../../user/project/issues/confidential_issues.md) `https://gitlab.com/gitlab-org/gitlab-foss/issues/<issue_number>`.
 ```
 
 ## Navigation
@@ -526,7 +526,7 @@ To indicate the steps of navigation through the UI:
   number corresponding to the release milestone the image was added to,
   or corresponding to the release the screenshot was taken from, using the
   format `image_name_vX_Y.png`.
-  ([Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/61027) in GitLab 12.1.)
+  ([Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/61027) in GitLab 12.1.)
 - For example, for a screenshot taken from the pipelines page of
   GitLab 11.1, a valid name is `pipelines_v11_1.png`. If you're
   adding an illustration that does not include parts of the UI,
@@ -1175,5 +1175,5 @@ curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" --data "domain_
 [cURL]: http://curl.haxx.se/ "cURL website"
 [single spaces]: http://www.slate.com/articles/technology/technology/2011/01/space_invaders.html
 [gfm]: ../../user/markdown.md#newlines "GitLab flavored markdown documentation"
-[ce-1242]: https://gitlab.com/gitlab-org/gitlab-ce/issues/1242
+[ce-1242]: https://gitlab.com/gitlab-org/gitlab-foss/issues/1242
 [doc-restart]: ../../administration/restart_gitlab.md "GitLab restart documentation"
diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md
index 391361a4b8f..d34c3ce5ba1 100644
--- a/doc/development/ee_features.md
+++ b/doc/development/ee_features.md
@@ -20,11 +20,11 @@ should be added for EE. Licensed features can be stubbed using the
 spec helper `stub_licensed_features` in `EE::LicenseHelpers`.
 
 You can force Webpack to act as CE by either deleting the `ee/` directory or by
-setting the [`IS_GITLAB_EE` environment variable](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/config/helpers/is_ee_env.js)
+setting the [`IS_GITLAB_EE` environment variable](https://gitlab.com/gitlab-org/gitlab/blob/master/config/helpers/is_ee_env.js)
 to something that evaluates as `false`. The same works for running tests
 (for example `IS_GITLAB_EE=0 yarn jest`).
 
-[ee-as-ce]: https://gitlab.com/gitlab-org/gitlab-ee/issues/2500
+[ee-as-ce]: https://gitlab.com/gitlab-org/gitlab/issues/2500
 
 ## Separation of EE code
 
@@ -36,7 +36,7 @@ implement EE features.
 Instead, all EE code should be put inside the `ee/` top-level directory. The
 rest of the code should be as close to the CE files as possible.
 
-[single code base]: https://gitlab.com/gitlab-org/gitlab-ee/issues/2952#note_41016454
+[single code base]: https://gitlab.com/gitlab-org/gitlab/issues/2952#note_41016454
 
 ### EE-specific comments
 
@@ -93,7 +93,7 @@ For instance, it was decided that moving EE-only files from `qa/` to `ee/qa/`
 would make it difficult to build the `gitLab-{ce,ee}-qa` Docker images and it
 was [not worth the complexity].
 
-[not worth the complexity]: https://gitlab.com/gitlab-org/gitlab-ee/issues/4997#note_59764702
+[not worth the complexity]: https://gitlab.com/gitlab-org/gitlab/issues/4997#note_59764702
 
 ### EE-only features
 
@@ -120,7 +120,7 @@ This works because for every path that are present in CE's eager-load/auto-load
 paths, we add the same `ee/`-prepended path in [`config/application.rb`].
 This also applies to views.
 
-[`config/application.rb`]: https://gitlab.com/gitlab-org/gitlab-ee/blob/925d3d4ebc7a2c72964ce97623ae41b8af12538d/config/application.rb#L42-52
+[`config/application.rb`]: https://gitlab.com/gitlab-org/gitlab/blob/925d3d4ebc7a2c72964ce97623ae41b8af12538d/config/application.rb#L42-52
 
 ### EE features based on CE features
 
@@ -170,7 +170,7 @@ still having access the class's implementation with `super`.
 
 There are a few gotchas with it:
 
-- you should always [`extend ::Gitlab::Utils::Override`](utilities.md#overridehttpsgitlabcomgitlab-orggitlab-ceblobmasterlibgitlabutilsoverriderb) and use `override` to
+- you should always [`extend ::Gitlab::Utils::Override`](utilities.md#overridehttpsgitlabcomgitlab-orggitlab-fossblobmasterlibgitlabutilsoverriderb) and use `override` to
   guard the "overrider" method to ensure that if the method gets renamed in
   CE, the EE override won't be silently forgotten.
 - when the "overrider" would add a line in the middle of the CE
@@ -347,8 +347,8 @@ end
 See [CE MR][ce-mr-full-private] and [EE MR][ee-mr-full-private] for
 full implementation details.
 
-[ce-mr-full-private]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12373
-[ee-mr-full-private]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2199
+[ce-mr-full-private]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12373
+[ee-mr-full-private]: https://gitlab.com/gitlab-org/gitlab/merge_requests/2199
 
 ### Code in `config/routes`
 
@@ -958,7 +958,7 @@ import mixin from 'ee_else_ce/path/mixin';
 - Computed Properties/methods and getters only used in the child import still need a counterpart in CE
 
 - For store modules, we will need a CE counterpart too.
-- You can see an MR with an example [here](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9762)
+- You can see an MR with an example [here](https://gitlab.com/gitlab-org/gitlab/merge_requests/9762)
 
 #### `template` tag
 
diff --git a/doc/development/elasticsearch.md b/doc/development/elasticsearch.md
index f3ea55d3d5d..1475e356b5b 100644
--- a/doc/development/elasticsearch.md
+++ b/doc/development/elasticsearch.md
@@ -59,15 +59,15 @@ Additionally, if you need large repos or multiple forks for testing, please cons
 
 ## How does it work?
 
-The Elasticsearch integration depends on an external indexer. We ship an [indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). The user must trigger the initial indexing via a rake task but, after this is done, GitLab itself will trigger reindexing when required via `after_` callbacks on create, update, and destroy that are inherited from [/ee/app/models/concerns/elastic/application_search.rb](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/ee/app/models/concerns/elastic/application_search.rb).
+The Elasticsearch integration depends on an external indexer. We ship an [indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). The user must trigger the initial indexing via a rake task but, after this is done, GitLab itself will trigger reindexing when required via `after_` callbacks on create, update, and destroy that are inherited from [/ee/app/models/concerns/elastic/application_search.rb](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/app/models/concerns/elastic/application_search.rb).
 
 All indexing after the initial one is done via `ElasticIndexerWorker` (sidekiq jobs).
 
-Search queries are generated by the concerns found in [ee/app/models/concerns/elastic](https://gitlab.com/gitlab-org/gitlab-ee/tree/master/ee/app/models/concerns/elastic). These concerns are also in charge of access control, and have been a historic source of security bugs so please pay close attention to them!
+Search queries are generated by the concerns found in [ee/app/models/concerns/elastic](https://gitlab.com/gitlab-org/gitlab/tree/master/ee/app/models/concerns/elastic). These concerns are also in charge of access control, and have been a historic source of security bugs so please pay close attention to them!
 
 ## Existing Analyzers/Tokenizers/Filters
 
-These are all defined in <https://gitlab.com/gitlab-org/gitlab-ee/blob/master/ee/lib/elasticsearch/git/model.rb>
+These are all defined in <https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/elasticsearch/git/model.rb>
 
 ### Analyzers
 
diff --git a/doc/development/emails.md b/doc/development/emails.md
index 5676c3b32f4..91b9e11f7f6 100644
--- a/doc/development/emails.md
+++ b/doc/development/emails.md
@@ -19,7 +19,7 @@ The previews live in [`app/mailers/previews`][previews] and can be viewed at
 
 See the [Rails guides] for more info.
 
-[previews]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/app/mailers/previews
+[previews]: https://gitlab.com/gitlab-org/gitlab-foss/tree/master/app/mailers/previews
 [Rails guides]: http://guides.rubyonrails.org/action_mailer_basics.html#previewing-emails
 
 ## Incoming email
diff --git a/doc/development/event_tracking/backend.md b/doc/development/event_tracking/backend.md
new file mode 100644
index 00000000000..c571439af8a
--- /dev/null
+++ b/doc/development/event_tracking/backend.md
@@ -0,0 +1,34 @@
+# Backend tracking guide
+
+GitLab provides `Gitlab::Tracking`, an interface that wraps the [Snowplow Ruby Tracker](https://github.com/snowplow/snowplow/wiki/ruby-tracker) for tracking custom events.
+
+## Tracking in Ruby
+
+Custom event tracking and instrumentation can be added by directly calling the `GitLab::Tracking.event` class method, which accepts the following arguments:
+
+| argument   | type   | default value              | description |
+|:-----------|:-------|:---------------------------|:------------|
+| `category` | string | 'application'              | Area or aspect of the application. This could be `HealthCheckController` or `Lfs::FileTransformer` for instance. |
+| `action`   | string | 'generic'                  | The action being taken, which can be anything from a controller action like `create` to something like an Active Record callback. |
+| `data`     | object | {}                         | Additional data such as `label`, `property`, `value`, and `context` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy). These will be set as empty strings if you don't provide them. |
+
+Tracking can be viewed as either tracking user behavior, or can be utilized for instrumentation to monitor and visual performance over time in an area or aspect of code.
+
+For example:
+
+```ruby
+class Projects::CreateService < BaseService
+  def execute
+    project = Project.create(params)
+
+    Gitlab::Tracking.event('Projects::CreateService', 'create_project',
+      label: project.errors.full_messages.to_sentence,
+      value: project.valid?
+    )
+  end
+end
+```
+
+### Performance
+
+We use the [AsyncEmitter](https://github.com/snowplow/snowplow/wiki/Ruby-Tracker#52-the-asyncemitter-class) when tracking events, which allows for instrumentation calls to be run in a background thread. This is still an active area of development.
diff --git a/doc/development/event_tracking/frontend.md b/doc/development/event_tracking/frontend.md
new file mode 100644
index 00000000000..cdc2e94bf9e
--- /dev/null
+++ b/doc/development/event_tracking/frontend.md
@@ -0,0 +1,143 @@
+# Frontend tracking guide
+
+GitLab provides `Tracking`, an interface that wraps the [Snowplow Javascript Tracker](https://github.com/snowplow/snowplow/wiki/javascript-tracker) for tracking custom events. There are a few ways to utilizing tracking, but each generally requires at minimum, a `category` and an `action`. Additional data can be provided that adheres to our [Feature instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy).
+
+| field      | type   | default value              | description |
+|:-----------|:-------|:---------------------------|:------------|
+| `category` | string | document.body.dataset.page | Page or subsection of a page that events are being captured within. |
+| `action`   | string | 'generic'                  | Action the user is taking. Clicks should be `click` and activations should be `activate`, so for example, focusing a form field would be `activate_form_input`, and clicking a button would be `click_button`. |
+| `data`     | object | {}                         | Additional data such as `label`, `property`, `value`, and `context` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy). |
+
+## Tracking in HAML (or Vue Templates)
+
+When working within HAML (or Vue templates) we can add `data-track-*` attributes to elements of interest. All elements that have a `data-track-event` attribute will automatically have event tracking bound on clicks.
+
+Below is an example of `data-track-*` attributes assigned to a button:
+
+```haml
+%button.btn{ data: { track: { event: "click_button", label: "template_preview", property: "my-template" } } }
+```
+
+```html
+<button class="btn"
+  data-track-event="click_button"
+  data-track-label="template_preview"
+  data-track-property="my-template"
+/>
+```
+
+Event listeners are bound at the document level to handle click events on or within elements with these data attributes. This allows for them to be properly handled on rerendering and changes to the DOM, but it's important to know that because of the way these events are bound, click events shouldn't be stopped from propagating up the DOM tree. If for any reason click events are being stopped from propagating, you'll need to implement your own listeners and follow the instructions in [Tracking in raw Javascript](#tracking-in-raw-javascript).
+
+Below is a list of supported `data-track-*` attributes:
+
+| attribute             | required | description |
+|:----------------------|:---------|:------------|
+| `data-track-event`    | true     | Action the user is taking. Clicks must be prepended with `click` and activations must be prepended with `activate`. For example, focusing a form field would be `activate_form_input` and clicking a button would be `click_button`. |
+| `data-track-label`    | false    | The `label` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy). |
+| `data-track-property` | false    | The `property` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy). |
+| `data-track-value`    | false    | The `value` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy). If omitted, this will be the elements `value` property or an empty string. For checkboxes, the default value will be the element's checked attribute or `false` when unchecked. |
+| `data-track-context`  | false    | The `context` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy). |
+
+## Tracking within Vue components
+
+There's a tracking Vue mixin that can be used in components if more complex tracking is required. To use it, first import the `Tracking` library and request a mixin.
+
+```javascript
+import Tracking from '~/tracking';
+const trackingMixin = Tracking.mixin({ label: 'right_sidebar' });
+```
+
+You can provide default options that will be passed along whenever an event is tracked from within your component. For instance, if all events within a component should be tracked with a given `label`, you can provide one at this time. Available defaults are `category`, `label`, `property`, and `value`. If no category is specified, `document.body.dataset.page` is used as the default.
+
+You can then use the mixin normally in your component with the `mixin`, Vue declaration. The mixin also provides the ability to specify tracking options in `data` or `computed`. These will override any defaults and allows the values to be dynamic from props, or based on state.
+
+```javascript
+export default {
+  mixins: [trackingMixin],
+  // ...[component implementation]...
+  data() {
+    return {
+      expanded: false,
+      tracking: {
+        label: 'left_sidebar'
+      }
+    };
+  },
+}
+```
+
+The mixin provides a `track` method that can be called within the template, or from component methods. An example of the whole implementation might look like the following.
+
+```javascript
+export default {
+  mixins: [Tracking.mixin({ label: 'right_sidebar' })],
+  data() {
+    return {
+      expanded: false,
+    };
+  },
+  methods: {
+    toggle() {
+      this.expanded = !this.expanded;
+      this.track('click_toggle', { value: this.expanded })
+    }
+  }
+};
+```
+
+And if needed within the template, you can use the `track` method directly as well.
+
+```html
+<template>
+  <div>
+    <a class="toggle" @click.prevent="toggle">Toggle</a>
+    <div v-if="expanded">
+      <p>Hello world!</p>
+      <a @click.prevent="track('click_action')">Track an event</a>
+    </div>
+  </div>
+</template>
+```
+
+## Tracking in raw Javascript
+
+Custom event tracking and instrumentation can be added by directly calling the `Tracking.event` static function. The following example demonstrates tracking a click on a button by calling `Tracking.event` manually.
+
+```javascript
+import Tracking from `~/tracking`;
+
+const button = document.getElementById('create_from_template_button');
+button.addEventListener('click', () => {
+  Tracking.event('dashboard:projects:index', 'click_button', {
+    label: 'create_from_template',
+    property: 'template_preview',
+    value: 'rails',
+  });
+})
+```
+
+## Tests and test helpers
+
+In Karma tests, you can use the following:
+
+```javascript
+import { mockTracking, triggerEvent } from 'spec/helpers/tracking_helper';
+
+describe('my component', () => {
+  let trackingSpy;
+  
+  beforeEach(() => {
+    const vm = mountComponent(MyComponent);
+    trackingSpy = mockTracking('_category_', vm.$el, spyOn);
+  });
+  
+  it('tracks an event when toggled', () => {
+    triggerEvent('a.toggle');
+
+    expect(trackingSpy).toHaveBeenCalledWith('_category_', 'click_edit_button', {
+      label: 'right_sidebar',
+      property: 'confidentiality',
+    });
+  });
+});
+```
diff --git a/doc/development/event_tracking/index.md b/doc/development/event_tracking/index.md
new file mode 100644
index 00000000000..efc61d13cb0
--- /dev/null
+++ b/doc/development/event_tracking/index.md
@@ -0,0 +1,74 @@
+# Event tracking
+
+At GitLab, we encourage event tracking so we can iterate on and improve the project and user experience.
+
+We do this by running experiments, and collecting analytics for features and feature variations. This is:
+
+- So we generally know engagement.
+- A way to approach A/B testing.
+
+As developers, we should attempt to add tracking and instrumentation where possible. This enables the Product team to better understand:
+
+- User engagement.
+- Usage patterns.
+- Other metrics that can potentially be improved on.
+
+To maintain consistency, and not adversely effect performance, we have some basic tracking functionality exposed at both the frontend and backend layers that can be utilized while building new features or updating existing features.
+
+We also encourage users to enable tracking, and we embrace full transparency with our tracking approach so it can be easily understood and trusted. By enabling tracking, users can:
+
+- Contribute back to the wider community.
+- Help GitLab improve on the product.
+
+## Implementing tracking
+
+Event tracking can be implemented on either the frontend or the backend layers, and each can be approached slightly differently since they have slightly different concerns.
+
+In GitLab, many actions can be initiated via the web interface, but they can also be initiated via an API client (an iOS applications is a good example of this), or via `git` directly. Crucially, this means that tracking should be considered holistically for the feature that's being instrumented.
+
+The data team should be involved when defining analytics and can be consulted when coming up with ways of presenting data that's being tracked. This allows our event data to be considered carefully and presented in ways that may reveal details about user engagement that may not be fully understood or interactions where we can make improvements. You can [contact the data team](https://about.gitlab.com/handbook/business-ops/data-team/#contact-us) and consult with them when defining tracking strategies.
+
+### Frontend
+
+Generally speaking, the frontend can track user actions and events, like:
+
+- Clicking links or buttons.
+- Submitting forms.
+- Other typically interface-driven actions.
+
+See [Frontend tracking guide](frontend.md).
+
+### Backend
+
+From the backend, the events that are tracked will likely consist of things like the creation or deletion of records and other events that might be triggered from layers that aren't necessarily only available in the interface.
+
+See [Backend tracking guide](backend.md).
+
+## Enabling tracking
+
+Tracking can be enabled at:
+
+- The instance level, which will enable tracking on both the frontend and backend layers.
+- User level, though user tracking can be disabled on a per-user basis. GitLab tracking respects the [Do Not Track](https://www.eff.org/issues/do-not-track) standard, so any user who has enabled the Do Not Track option in their browser will also not be tracked from a user level.
+
+We utilize Snowplow for the majority of our tracking strategy, and it can be enabled by navigating to:
+
+- **Admin area > Settings > Integrations** in the UI.
+- `admin/application_settings/integrations` in your browser.
+
+The following configuration is required:
+
+| Name          | Value                     |
+| ------------- | ------------------------- |
+| Collector     | `snowplow.trx.gitlab.net` |
+| Site ID       | `gitlab`                  |
+| Cookie domain | `.gitlab.com`             |
+
+Once enabled, tracking events can be inspected locally by either:
+
+- Looking at the network panel of the browser's development tools
+- Using the [Snowplow Chrome Extension](https://chrome.google.com/webstore/detail/snowplow-inspector/maplkdomeamdlngconidoefjpogkmljm).
+
+## Additional libraries
+
+Session tracking is handled by [Pendo](https://www.pendo.io/), which is a purely client library and is a relatively minor development concern but is worth including in this documentation.
diff --git a/doc/development/fe_guide/components.md b/doc/development/fe_guide/components.md
index 096ce8ca25a..e88827f78c1 100644
--- a/doc/development/fe_guide/components.md
+++ b/doc/development/fe_guide/components.md
@@ -44,7 +44,7 @@ See also the [corresponding UX guide](https://design.gitlab.com/#/components/dro
 
 See also the [corresponding UX guide](https://design.gitlab.com/#/components/modals).
 
-We have a reusable Vue component for modals: [vue_shared/components/gl_modal.vue](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/vue_shared/components/gl_modal.vue)
+We have a reusable Vue component for modals: [vue_shared/components/gl_modal.vue](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/assets/javascripts/vue_shared/components/gl_modal.vue)
 
 Here is an example of how to use it:
 
diff --git a/doc/development/fe_guide/design_patterns.md b/doc/development/fe_guide/design_patterns.md
index 2f372f783f5..0893299540f 100644
--- a/doc/development/fe_guide/design_patterns.md
+++ b/doc/development/fe_guide/design_patterns.md
@@ -77,4 +77,4 @@ new Foo({ container: '.my-element' });
 
 You can find an example of the above in this [class][container-class-example];
 
-[container-class-example]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/mini_pipeline_graph_dropdown.js
+[container-class-example]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/assets/javascripts/mini_pipeline_graph_dropdown.js
diff --git a/doc/development/fe_guide/development_process.md b/doc/development/fe_guide/development_process.md
index 9224a2548ab..41513e6d57e 100644
--- a/doc/development/fe_guide/development_process.md
+++ b/doc/development/fe_guide/development_process.md
@@ -23,7 +23,7 @@ Please use your best judgement when to use it and please contribute new points t
 - [ ] Are all necessary UX specifications available that you will need in order to implement? Are there new UX components/patterns in the designs? Then contact the UI component team early on. How should error messages or validation be handled?
 - [ ] **Library usage** Use Vuex as soon as you have even a medium state to manage, use Vue router if you need to have different views internally and want to link from the outside. Check what libraries we already have for which occasions.
 - [ ] **Plan your implementation:**
-  - [ ] **Architecture plan:** Create a plan aligned with GitLab's architecture, how you are going to do the implementation, for example Vue application setup and its components (through [onion skinning](https://gitlab.com/gitlab-org/gitlab-ce/issues/35873#note_39994091)), Store structure and data flow, which existing Vue components can you reuse. It's a good idea to go through your plan with another engineer to refine it.
+  - [ ] **Architecture plan:** Create a plan aligned with GitLab's architecture, how you are going to do the implementation, for example Vue application setup and its components (through [onion skinning](https://gitlab.com/gitlab-org/gitlab-foss/issues/35873#note_39994091)), Store structure and data flow, which existing Vue components can you reuse. It's a good idea to go through your plan with another engineer to refine it.
   - [ ] **Backend:** The best way is to kickoff the implementation in a call and discuss with the assigned Backend engineer what you will need from the backend and also when. Can you reuse existing API's? How is the performance with the planned architecture? Maybe create together a JSON mock object to already start with development.
   - [ ] **Communication:** It also makes sense to have for bigger features an own slack channel (normally called #f_{feature_name}) and even weekly demo calls with all people involved.
   - [ ] **Dependency Plan:** Are there big dependencies in the plan between you and others, then maybe create an execution diagram to show what is blocking which part and the order of the different parts.
diff --git a/doc/development/fe_guide/event_tracking.md b/doc/development/fe_guide/event_tracking.md
index 1b417d4c8c2..13f107eebb1 100644
--- a/doc/development/fe_guide/event_tracking.md
+++ b/doc/development/fe_guide/event_tracking.md
@@ -1,88 +1,5 @@
-# Event tracking
+---
+redirect_to: '../event_tracking/index.md'
+---
 
-GitLab provides `Tracking`, an interface that wraps
-[Snowplow](https://github.com/snowplow/snowplow) for tracking custom events.
-It uses Snowplow's custom event tracking functions.
-
-The tracking interface can be imported in JS files as follows:
-
-```javascript
-import Tracking from `~/tracking`;
-```
-
-## Tracking in HAML or Vue templates
-
-To avoid having to do create a bunch of custom javascript event handlers, when working within HAML or Vue templates, we can add `data-track-*` attributes to elements of interest. This way, all elements that have a `data-track-event` attribute to automatically have event tracking bound.
-
-Below is an example of `data-track-*` attributes assigned to a button in HAML:
-
-```haml
-%button.btn{ data: { track_event: "click_button", track_label: "template_preview", track_property: "my-template", track_value: "" } }
-```
-
-We can then setup tracking for large sections of a page, or an entire page by telling the Tracking interface to bind to it.
-
-```javascript
-import Tracking from '~/tracking';
-
-// for the entire document
-new Tracking().bind();
-
-// for a container element
-document.addEventListener('DOMContentLoaded', () => {
-  new Tracking('my_category').bind(document.getElementById('my-container'));
-});
-
-```
-
-When you instantiate a Tracking instance you can provide a category. If none is provided, `document.body.dataset.page` will be used. When you bind the Tracking instance you can provide an element. If no element is provided to bind to, the `document` is assumed.
-
-Below is a list of supported `data-track-*` attributes:
-
-| attribute             | required | description |
-|:----------------------|:---------|:------------|
-| `data-track-event`    | true     | Action the user is taking. Clicks should be `click` and activations should be `activate`, so for example, focusing a form field would be `activate_form_input`, and clicking a button would be `click_button`. |
-| `data-track-label`    | false    | The `label` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy). |
-| `data-track-property` | false    | The `property` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy). |
-| `data-track-value`    | false    | The `value` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy). If omitted, this will be the elements `value` property or an empty string. For checkboxes, the default value will be the element's checked attribute or `false` when unchecked. |
-
-## Tracking in raw Javascript
-
-Custom events can be tracked by directly calling the `Tracking.event` static function, which accepts the following arguments:
-
-| argument   | type   | default value              | description |
-|:-----------|:-------|:---------------------------|:------------|
-| `category` | string | document.body.dataset.page | Page or subsection of a page that events are being captured within. |
-| `event`    | string | 'generic'                  | Action the user is taking. Clicks should be `click` and activations should be `activate`, so for example, focusing a form field would be `activate_form_input`, and clicking a button would be `click_button`. |
-| `data`     | object | {}                         | Additional data such as `label`, `property`, and `value` as described [in our Feature Instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy). These will be set as empty strings if you don't provide them. |
-
-Tracking can be programmatically added to an event of interest in Javascript, and the following example demonstrates tracking a click on a button by calling `Tracking.event` manually.
-
-```javascript
-import Tracking from `~/tracking`;
-
-document.getElementById('my_button').addEventListener('click', () => {
-  Tracking.event('dashboard:projects:index', 'click_button', {
-    label: 'create_from_template',
-    property: 'template_preview',
-    value: 'rails',
-  });
-})
-```
-
-## Toggling tracking on or off
-
-Snowplow can be enabled by navigating to:
-
-- **Admin area > Settings > Integrations** in the UI.
-- `admin/application_settings/integrations` in your browser.
-
-The following configuration is required:
-
-| Name          | Value                     |
-| ------------- | ------------------------- |
-| Collector     | `snowplow.trx.gitlab.net` |
-| Site ID       | `gitlab`                  |
-| Cookie domain | `.gitlab.com`             |
-
-Now the implemented tracking events can be inspected locally by looking at the network panel of the browser's development tools.
+This document was moved to [another location](../event_tracking/frontend.md).
diff --git a/doc/development/fe_guide/frontend_faq.md b/doc/development/fe_guide/frontend_faq.md
index 0d2aeffeac0..2ec3f8017a1 100644
--- a/doc/development/fe_guide/frontend_faq.md
+++ b/doc/development/fe_guide/frontend_faq.md
@@ -17,6 +17,8 @@
 
 ### How do I find the Rails route for a page?
 
+#### Check the 'page' data attribute
+
 The easiest way is to type the following in the browser while on the page in
 question:
 
@@ -24,7 +26,16 @@ question:
 document.body.dataset.page
 ```
 
-Find here the [source code setting the attribute](https://gitlab.com/gitlab-org/gitlab-ce/blob/cc5095edfce2b4d4083a4fb1cdc7c0a1898b9921/app/views/layouts/application.html.haml#L4).
+Find here the [source code setting the attribute](https://gitlab.com/gitlab-org/gitlab-foss/blob/cc5095edfce2b4d4083a4fb1cdc7c0a1898b9921/app/views/layouts/application.html.haml#L4).
+
+#### Rails routes
+
+The `rake routes` command can be used to list all the routes available in the application, piping the output into `grep`, we can perform a search through the list of available routes.
+The output includes the request types available, route parameters and the relevant controller.
+
+```sh
+bundle exec rake routes | grep "issues"
+```
 
 ### `modal_copy_button` vs `clipboard_button`
 
diff --git a/doc/development/fe_guide/graphql.md b/doc/development/fe_guide/graphql.md
index 4fc5dfc8c3d..366c2894b81 100644
--- a/doc/development/fe_guide/graphql.md
+++ b/doc/development/fe_guide/graphql.md
@@ -119,6 +119,6 @@ Read more about the [Apollo] client in the [Apollo documentation](https://www.ap
 [Apollo]: https://www.apollographql.com/
 [vue-apollo]: https://github.com/Akryum/vue-apollo/
 [feature-flags]: ../feature_flags.md
-[default-client]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/lib/graphql.js
+[default-client]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/assets/javascripts/lib/graphql.js
 [vue-test-utils]: https://vue-test-utils.vuejs.org/
 [apollo-link-state]: https://www.apollographql.com/docs/link/links/state.html
diff --git a/doc/development/fe_guide/index.md b/doc/development/fe_guide/index.md
index deaef8e768b..4cccd4aa5fb 100644
--- a/doc/development/fe_guide/index.md
+++ b/doc/development/fe_guide/index.md
@@ -69,10 +69,6 @@ How we use SVG for our Icons and Illustrations.
 
 How we use UI components.
 
-## [Event Tracking](event_tracking.md)
-
-How we use Snowplow to track custom events.
-
 ## Frontend FAQ
 
 Read the [frontend's FAQ](frontend_faq.md) for common small pieces of helpful information.
diff --git a/doc/development/fe_guide/performance.md b/doc/development/fe_guide/performance.md
index 3a8ea04407f..bcd22a170e1 100644
--- a/doc/development/fe_guide/performance.md
+++ b/doc/development/fe_guide/performance.md
@@ -65,7 +65,7 @@ within the `pages` directory correspond to Rails controllers and actions. These
 auto-generated bundles will be automatically included on the corresponding
 pages.
 
-For example, if you were to visit [gitlab.com/gitlab-org/gitlab-ce/issues](https://gitlab.com/gitlab-org/gitlab-ce/issues),
+For example, if you were to visit [gitlab.com/gitlab-org/gitlab-foss/issues](https://gitlab.com/gitlab-org/gitlab-foss/issues),
 you would be accessing the `app/controllers/projects/issues_controller.rb`
 controller with the `index` action. If a corresponding file exists at
 `pages/projects/issues/index/index.js`, it will be compiled into a webpack
diff --git a/doc/development/fe_guide/style_guide_js.md b/doc/development/fe_guide/style_guide_js.md
index 125b11afcd0..db076243812 100644
--- a/doc/development/fe_guide/style_guide_js.md
+++ b/doc/development/fe_guide/style_guide_js.md
@@ -7,7 +7,7 @@ See the relevant style guides for our guidelines and for information on linting:
 We defer to [Airbnb][airbnb-js-style-guide] on most style-related
 conventions and enforce them with eslint.
 
-See [our current .eslintrc](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.eslintrc.yml) for specific rules and patterns.
+See [our current .eslintrc](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/.eslintrc.yml) for specific rules and patterns.
 
 ### Common
 
@@ -392,7 +392,7 @@ Please check this [rules][eslint-plugin-vue-rules] for more documentation.
    <component my-prop="prop" />
    ```
 
-[#34371]: https://gitlab.com/gitlab-org/gitlab-ce/issues/34371
+[#34371]: https://gitlab.com/gitlab-org/gitlab-foss/issues/34371
 
 #### Alignment
 
@@ -713,7 +713,7 @@ The goal of this accord is to make sure we are all on the same page.
 - [SCSS](style_guide_scss.md)
 
 [airbnb-js-style-guide]: https://github.com/airbnb/javascript
-[eslintrc]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.eslintrc
+[eslintrc]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/.eslintrc
 [eslint-plugin-vue]: https://github.com/vuejs/eslint-plugin-vue
 [eslint-plugin-vue-rules]: https://github.com/vuejs/eslint-plugin-vue#bulb-rules
 [vue-order]: https://github.com/vuejs/eslint-plugin-vue/blob/master/docs/rules/order-in-components.md
diff --git a/doc/development/fe_guide/style_guide_scss.md b/doc/development/fe_guide/style_guide_scss.md
index 95c4a094c04..d5af19e0ea4 100644
--- a/doc/development/fe_guide/style_guide_scss.md
+++ b/doc/development/fe_guide/style_guide_scss.md
@@ -13,12 +13,12 @@ led by the [GitLab UI WG](https://gitlab.com/gitlab-com/www-gitlab-com/merge_req
 #### Where are utility classes defined?
 
 - [Bootstrap's Utility Classes](https://getbootstrap.com/docs/4.3/utilities/)
-- [`common.scss`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/stylesheets/framework/common.scss) (old)
-- [`utilities.scss`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/stylesheets/utilities.scss) (new)
+- [`common.scss`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/assets/stylesheets/framework/common.scss) (old)
+- [`utilities.scss`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/assets/stylesheets/utilities.scss) (new)
 
 #### Where should I put new utility classes?
 
-New utility classes should be added to [`utilities.scss`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/stylesheets/utilities.scss). Existing classes include:
+New utility classes should be added to [`utilities.scss`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/assets/stylesheets/utilities.scss). Existing classes include:
 
 | Name | Pattern | Example |
 |------|---------|---------|
@@ -41,8 +41,8 @@ This encourages an organic growth of component classes and prevents the creation
 
 Examples of component classes that were created using "utility-first" include:
 
-- [`.circle-icon-container`](https://gitlab.com/gitlab-org/gitlab-ce/blob/579fa8b8ec7eb38d40c96521f517c9dab8c3b97a/app/assets/stylesheets/framework/icons.scss#L85)
-- [`.d-flex-center`](https://gitlab.com/gitlab-org/gitlab-ce/blob/900083d89cd6af391d26ab7922b3f64fa2839bef/app/assets/stylesheets/framework/common.scss#L425)
+- [`.circle-icon-container`](https://gitlab.com/gitlab-org/gitlab-foss/blob/579fa8b8ec7eb38d40c96521f517c9dab8c3b97a/app/assets/stylesheets/framework/icons.scss#L85)
+- [`.d-flex-center`](https://gitlab.com/gitlab-org/gitlab-foss/blob/900083d89cd6af391d26ab7922b3f64fa2839bef/app/assets/stylesheets/framework/common.scss#L425)
 
 Inspiration:
 
diff --git a/doc/development/fe_guide/vue.md b/doc/development/fe_guide/vue.md
index 421b7265613..396467b47d1 100644
--- a/doc/development/fe_guide/vue.md
+++ b/doc/development/fe_guide/vue.md
@@ -6,9 +6,9 @@ To get started with Vue, read through [their documentation][vue-docs].
 
 What is described in the following sections can be found in these examples:
 
-- web ide: <https://gitlab.com/gitlab-org/gitlab-ce/tree/master/app/assets/javascripts/ide/stores>
-- security products: <https://gitlab.com/gitlab-org/gitlab-ee/tree/master/ee/app/assets/javascripts/vue_shared/security_reports>
-- registry: <https://gitlab.com/gitlab-org/gitlab-ce/tree/master/app/assets/javascripts/registry/stores>
+- web ide: <https://gitlab.com/gitlab-org/gitlab-foss/tree/master/app/assets/javascripts/ide/stores>
+- security products: <https://gitlab.com/gitlab-org/gitlab/tree/master/ee/app/assets/javascripts/vue_shared/security_reports>
+- registry: <https://gitlab.com/gitlab-org/gitlab-foss/tree/master/app/assets/javascripts/registry/stores>
 
 ## Vue architecture
 
@@ -246,8 +246,8 @@ One should apply to be a Vue.js expert by opening an MR when the Merge Request's
 - Knowledge about the existing Vue and Vuex applications and existing reusable components
 
 [vue-docs]: http://vuejs.org/guide/index.html
-[issue-boards]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/app/assets/javascripts/boards
-[environments-table]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/app/assets/javascripts/environments
+[issue-boards]: https://gitlab.com/gitlab-org/gitlab-foss/tree/master/app/assets/javascripts/boards
+[environments-table]: https://gitlab.com/gitlab-org/gitlab-foss/tree/master/app/assets/javascripts/environments
 [page_specific_javascript]: ./performance.md#page-specific-javascript
 [component-system]: https://vuejs.org/v2/guide/#Composing-with-Components
 [state-management]: https://vuejs.org/v2/guide/state-management.html#Simple-State-Management-from-Scratch
diff --git a/doc/development/fe_guide/vuex.md b/doc/development/fe_guide/vuex.md
index 336ef4ab278..bb131746ecf 100644
--- a/doc/development/fe_guide/vuex.md
+++ b/doc/development/fe_guide/vuex.md
@@ -26,7 +26,7 @@ When using Vuex at GitLab, separate these concerns into different files to impro
 ```
 
 The following example shows an application that lists and adds users to the state.
-(For a more complex example implementation take a look at the security applications store in [here](https://gitlab.com/gitlab-org/gitlab-ee/tree/master/ee/app/assets/javascripts/vue_shared/security_reports/store))
+(For a more complex example implementation take a look at the security applications store in [here](https://gitlab.com/gitlab-org/gitlab/tree/master/ee/app/assets/javascripts/vue_shared/security_reports/store))
 
 ### `index.js`
 
diff --git a/doc/development/feature_flags/development.md b/doc/development/feature_flags/development.md
index 98773026122..b338a191f76 100644
--- a/doc/development/feature_flags/development.md
+++ b/doc/development/feature_flags/development.md
@@ -47,9 +47,9 @@ feature flag once the feature has reached general availability.
 You'd still want to use an explicit `Feature.enabled?` check if your new feature
 isn't gated by a License or Plan.
 
-[project-fa]: https://gitlab.com/gitlab-org/gitlab-ee/blob/4cc1c62918aa4c31750cb21dfb1a6c3492d71080/app/models/project_feature.rb#L63-68
-[namespace-fa]: https://gitlab.com/gitlab-org/gitlab-ee/blob/4cc1c62918aa4c31750cb21dfb1a6c3492d71080/ee/app/models/ee/namespace.rb#L71-85
-[license-fa]: https://gitlab.com/gitlab-org/gitlab-ee/blob/4cc1c62918aa4c31750cb21dfb1a6c3492d71080/ee/app/models/license.rb#L293-300
+[project-fa]: https://gitlab.com/gitlab-org/gitlab/blob/4cc1c62918aa4c31750cb21dfb1a6c3492d71080/app/models/project_feature.rb#L63-68
+[namespace-fa]: https://gitlab.com/gitlab-org/gitlab/blob/4cc1c62918aa4c31750cb21dfb1a6c3492d71080/ee/app/models/ee/namespace.rb#L71-85
+[license-fa]: https://gitlab.com/gitlab-org/gitlab/blob/4cc1c62918aa4c31750cb21dfb1a6c3492d71080/ee/app/models/license.rb#L293-300
 
 An important side-effect of the implicit feature flags mentioned above is that
 unless the feature is explicitly disabled or limited to a percentage of users,
diff --git a/doc/development/feature_flags/process.md b/doc/development/feature_flags/process.md
index 28d6080ce87..c64b14a05a4 100644
--- a/doc/development/feature_flags/process.md
+++ b/doc/development/feature_flags/process.md
@@ -54,9 +54,16 @@ absolutely no way to use the feature until it is enabled.
 In order to build a final release and present the feature for self-hosted
 users, the feature flag should be at least defaulted to **on**. If the feature
 is deemed stable and there is confidence that removing the feature flag is safe,
-consider removing the feature flag altogether. Take into consideration that such
-action can make the feature available on GitLab.com shortly after the change to
-the feature flag is merged.
+consider removing the feature flag altogether.
+
+The process for enabling features that are disabled by default can take 5-6 days
+from when the merge request is first reviewed to when the change is deployed to
+GitLab.com. However, it is recommended to allow 10-14 days for this activity to
+account for unforeseen problems.
+
+NOTE: **Note:**
+Take into consideration that such action can make the feature available on
+GitLab.com shortly after the change to the feature flag is merged.
 
 Changing the default state or removing the feature flag has to be done before
 the 22nd of the month, _at least_ 2 working days before, in order for the change
diff --git a/doc/development/file_storage.md b/doc/development/file_storage.md
index 44af2b020a4..8d486df9a8a 100644
--- a/doc/development/file_storage.md
+++ b/doc/development/file_storage.md
@@ -146,4 +146,4 @@ end
 [CarrierWave]: https://github.com/carrierwaveuploader/carrierwave
 [Hashed Storage]: ../administration/repository_storage_types.md
 [all-in-one rake task]: ../administration/raketasks/uploads/migrate.md
-[category list]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/uploads/migrate.rake
+[category list]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/tasks/gitlab/uploads/migrate.rake
diff --git a/doc/development/filtering_by_label.md b/doc/development/filtering_by_label.md
index dd8944ff1c8..6aa7e7a5293 100644
--- a/doc/development/filtering_by_label.md
+++ b/doc/development/filtering_by_label.md
@@ -40,14 +40,14 @@ In particular, note that:
 
 This is more complicated than is ideal. It makes the query construction more
 prone to errors (such as
-[issue #15557](https://gitlab.com/gitlab-org/gitlab-ce/issues/15557)).
+[issue #15557](https://gitlab.com/gitlab-org/gitlab-foss/issues/15557)).
 
 ## Attempt A: WHERE EXISTS
 
 ### Attempt A1: use multiple subqueries with WHERE EXISTS
 
-In [issue #37137](https://gitlab.com/gitlab-org/gitlab-ce/issues/37137)
-and its associated [merge request](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14022),
+In [issue #37137](https://gitlab.com/gitlab-org/gitlab-foss/issues/37137)
+and its associated [merge request](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/14022),
 we tried to replace the `GROUP BY` with multiple uses of `WHERE EXISTS`. For the
 example above, this would give:
 
@@ -83,7 +83,7 @@ Having [removed MySQL support in GitLab 12.1](https://about.gitlab.com/2019/06/2
 using [Postgres's arrays](https://www.postgresql.org/docs/9.6/arrays.html) became more
 tractable as we didn't have to support two databases. We discussed denormalizing
 the `label_links` table for querying in
-[issue #49651](https://gitlab.com/gitlab-org/gitlab-ce/issues/49651),
+[issue #49651](https://gitlab.com/gitlab-org/gitlab-foss/issues/49651),
 with two options: label IDs and titles.
 
 We can think of both of those as array columns on `issues`, `merge_requests`,
@@ -147,7 +147,7 @@ WHERE
     label_titles @> ARRAY['Plan', 'backend']
 ```
 
-And our [tests in issue #49651](https://gitlab.com/gitlab-org/gitlab-ce/issues/49651#note_188777346)
+And our [tests in issue #49651](https://gitlab.com/gitlab-org/gitlab-foss/issues/49651#note_188777346)
 showed that this could be fast.
 
 However, at present, the disadvantages outweigh the advantages.
diff --git a/doc/development/geo.md b/doc/development/geo.md
index cc3e2d1ccc5..446d85fceed 100644
--- a/doc/development/geo.md
+++ b/doc/development/geo.md
@@ -192,8 +192,8 @@ needs to be applied to the tracking database on each **secondary** node.
 
 ### Configuration
 
-The database configuration is set in [`config/database_geo.yml`](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/config/database_geo.yml.postgresql).
-The directory [`ee/db/geo`](https://gitlab.com/gitlab-org/gitlab-ee/tree/master/ee/db/geo)
+The database configuration is set in [`config/database_geo.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/config/database_geo.yml.postgresql).
+The directory [`ee/db/geo`](https://gitlab.com/gitlab-org/gitlab/tree/master/ee/db/geo)
 contains the schema and migrations for this database.
 
 To write a migration for the database, use the `GeoMigrationGenerator`:
@@ -311,7 +311,7 @@ project_registry_table.join(fdw_project_table)
 
 ## Finders
 
-Geo uses [Finders](https://gitlab.com/gitlab-org/gitlab-ee/tree/master/app/finders),
+Geo uses [Finders](https://gitlab.com/gitlab-org/gitlab/tree/master/app/finders),
 which are classes take care of the heavy lifting of looking up
 projects/attachments/etc. in the tracking database and main database.
 
@@ -432,7 +432,7 @@ The process running on the **secondary** node that looks for new
 ### `Gitlab::Geo` utilities
 
 Small utility methods related to Geo go into the
-[`ee/lib/gitlab/geo.rb`](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/ee/lib/gitlab/geo.rb)
+[`ee/lib/gitlab/geo.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/gitlab/geo.rb)
 file.
 
 Many of these methods are cached using the `RequestStore` class, to
diff --git a/doc/development/gitaly.md b/doc/development/gitaly.md
index 592fc13873b..792ddeed201 100644
--- a/doc/development/gitaly.md
+++ b/doc/development/gitaly.md
@@ -81,7 +81,7 @@ While Gitaly can handle all Git access, many of GitLab customers still
 run Gitaly atop NFS. The legacy Rugged implementation for Git calls may
 be faster than the Gitaly RPC due to N+1 Gitaly calls and other
 reasons. See [the
-issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/57317) for more
+issue](https://gitlab.com/gitlab-org/gitlab-foss/issues/57317) for more
 details.
 
 Until GitLab has eliminated most of these inefficiencies or the use of
diff --git a/doc/development/go_guide/index.md b/doc/development/go_guide/index.md
index 2df0e846671..1e230a54023 100644
--- a/doc/development/go_guide/index.md
+++ b/doc/development/go_guide/index.md
@@ -85,7 +85,7 @@ go lint:
     - golint -set_exit_status $(go list ./... | grep -v "vendor/")
 ```
 
-Once [recursive includes](https://gitlab.com/gitlab-org/gitlab-ce/issues/56836)
+Once [recursive includes](https://gitlab.com/gitlab-org/gitlab-foss/issues/56836)
 become available, you will be able to share job templates like this
 [analyzer](https://gitlab.com/gitlab-org/security-products/ci-templates/raw/master/includes-dev/analyzer.yml).
 
diff --git a/doc/development/gotchas.md b/doc/development/gotchas.md
index 10e8008bad3..e492b8ea7c9 100644
--- a/doc/development/gotchas.md
+++ b/doc/development/gotchas.md
@@ -147,7 +147,7 @@ refresh_service.execute(oldrev, newrev, ref)
 See ["Why is it bad style to `rescue Exception => e` in Ruby?"][Exception].
 
 _**Note:** This rule is [enforced automatically by
-Rubocop](https://gitlab.com/gitlab-org/gitlab-ce/blob/8-4-stable/.rubocop.yml#L911-914)._
+Rubocop](https://gitlab.com/gitlab-org/gitlab-foss/blob/8-4-stable/.rubocop.yml#L911-914)._
 
 [Exception]: http://stackoverflow.com/q/10048173/223897
 
@@ -156,7 +156,7 @@ Rubocop](https://gitlab.com/gitlab-org/gitlab-ce/blob/8-4-stable/.rubocop.yml#L9
 Using the inline `:javascript` Haml filters comes with a
 performance overhead. Using inline JavaScript is not a good way to structure your code and should be avoided.
 
-_**Note:** We've [removed these two filters](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/config/initializers/hamlit.rb)
+_**Note:** We've [removed these two filters](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/config/initializers/hamlit.rb)
 in an initializer._
 
 ### Further reading
diff --git a/doc/development/i18n/externalization.md b/doc/development/i18n/externalization.md
index 141f5a8d6d9..b5e1641abcb 100644
--- a/doc/development/i18n/externalization.md
+++ b/doc/development/i18n/externalization.md
@@ -1,6 +1,6 @@
 # Internationalization for GitLab
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10669) in GitLab 9.2.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10669) in GitLab 9.2.
 
 For working with internationalization (i18n),
 [GNU gettext](https://www.gnu.org/software/gettext/) is used given it's the most
@@ -9,7 +9,7 @@ work with it.
 
 ## Setting up GitLab Development Kit (GDK)
 
-In order to be able to work on the [GitLab Community Edition](https://gitlab.com/gitlab-org/gitlab-ce)
+In order to be able to work on the [GitLab Community Edition](https://gitlab.com/gitlab-org/gitlab-foss)
 project you must download and configure it through [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/set-up-gdk.md).
 
 Once you have the GitLab project ready, you can start working on the translation.
@@ -236,11 +236,11 @@ This makes use of [`Intl.DateTimeFormat`].
 - In Ruby/HAML, we have two ways of adding format to dates and times:
 
   1. **Through the `l` helper**, i.e. `l(active_session.created_at, format: :short)`. We have some predefined formats for
-     [dates](https://gitlab.com/gitlab-org/gitlab-ce/blob/v11.7.0/config/locales/en.yml#L54) and [times](https://gitlab.com/gitlab-org/gitlab-ce/blob/v11.7.0/config/locales/en.yml#L261).
+     [dates](https://gitlab.com/gitlab-org/gitlab-foss/blob/v11.7.0/config/locales/en.yml#L54) and [times](https://gitlab.com/gitlab-org/gitlab-foss/blob/v11.7.0/config/locales/en.yml#L261).
      If you need to add a new format, because other parts of the code could benefit from it,
-     you'll need to add it to [en.yml](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/config/locales/en.yml) file.
+     you'll need to add it to [en.yml](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/config/locales/en.yml) file.
   1. **Through `strftime`**, i.e. `milestone.start_date.strftime('%b %-d')`. We use `strftime` in case none of the formats
-     defined on [en.yml](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/config/locales/en.yml) matches the date/time
+     defined on [en.yml](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/config/locales/en.yml) matches the date/time
      specifications we need, and if there is no need to add it as a new format because is very particular (i.e. it's only used in a single view).
 
 ## Best practices
diff --git a/doc/development/i18n/merging_translations.md b/doc/development/i18n/merging_translations.md
index eadf1cd74c5..7a8046ccdd9 100644
--- a/doc/development/i18n/merging_translations.md
+++ b/doc/development/i18n/merging_translations.md
@@ -5,7 +5,7 @@ added translations to the community of translators.
 
 At the same time, it creates a merge request to merge all newly added
 & approved translations. Find the [merge request created by
-`gitlab-crowdin-bot`](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&author_username=gitlab-crowdin-bot)
+`gitlab-crowdin-bot`](https://gitlab.com/gitlab-org/gitlab/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&author_username=gitlab-crowdin-bot)
 to see new and merged merge requests. They are created in EE and need
 to be ported to CE manually.
 
@@ -15,13 +15,13 @@ By default Crowdin commits translations with `[skip ci]` in the commit
 message. This is done to avoid a bunch of pipelines being run. Before
 merging translations, make sure to trigger a pipeline to validate
 translations, we have static analysis validating things Crowdin
-doesn't do. Create a [new pipeline](https://gitlab.com/gitlab-org/gitlab-ee/pipelines/new) for the
+doesn't do. Create a [new pipeline](https://gitlab.com/gitlab-org/gitlab/pipelines/new) for the
 `master-i18n` branch.
 
 If there are validation errors, the easiest solution is to disapprove
 the offending string in Crowdin, leaving a comment with what is
 required to fix the offense. There is an
-[issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/49208)
+[issue](https://gitlab.com/gitlab-org/gitlab-foss/issues/49208)
 suggesting to automate this process. Disapproving will exclude the
 invalid translation, the merge request will be updated within a few
 minutes.
@@ -32,7 +32,7 @@ clicking `Pause sync` on the [Crowdin integration settings
 page](https://translate.gitlab.com/project/gitlab-ee/settings#integration).
 
 When all failures are resolved, the translations need to be double
-checked once more as discussed in [confidential issue](../../user/project/issues/confidential_issues.md) `https://gitlab.com/gitlab-org/gitlab-ce/issues/37850`.
+checked once more as discussed in [confidential issue](../../user/project/issues/confidential_issues.md) `https://gitlab.com/gitlab-org/gitlab-foss/issues/37850`.
 
 ## Merging translations
 
@@ -44,16 +44,16 @@ source branch` checkbox, so Crowdin recreates the `master-i18n` from
 master after the new translation was merged.
 
 We are discussing automating this entire process
-[here](https://gitlab.com/gitlab-org/gitlab-ce/issues/39309).
+[here](https://gitlab.com/gitlab-org/gitlab-foss/issues/39309).
 
 ## Recreate the merge request
 
 Crowdin creates a new merge request as soon as the old one is closed
 or merged. But it won't recreate the `master-i18n` branch every
 time. To force Crowdin to recreate the branch, close any [open merge
-request](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&author_username=gitlab-crowdin-bot)
+request](https://gitlab.com/gitlab-org/gitlab/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&author_username=gitlab-crowdin-bot)
 and delete the
-[`master-18n`](https://gitlab.com/gitlab-org/gitlab-ee/branches/all?utf8=%E2%9C%93&search=master-i18n).
+[`master-18n`](https://gitlab.com/gitlab-org/gitlab/branches/all?utf8=%E2%9C%93&search=master-i18n).
 
 This might be needed when the merge request contains failures that
 have been fixed on master.
diff --git a/doc/development/i18n/proofreader.md b/doc/development/i18n/proofreader.md
index 492e3d48164..db15633fc73 100644
--- a/doc/development/i18n/proofreader.md
+++ b/doc/development/i18n/proofreader.md
@@ -134,4 +134,4 @@ are very appreciative of the work done by translators and proofreaders!
    - When a request is made for the first proofreader for a language and there are no [GitLab team members](https://about.gitlab.com/team/)
    or [Core team members](https://about.gitlab.com/core-team/) who speak the language, we will request links to previous translation work in other communities or projects.
 
-[proofreader-src]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/i18n/proofreader.md
+[proofreader-src]: https://gitlab.com/gitlab-org/gitlab/blob/master/doc/development/i18n/proofreader.md
diff --git a/doc/development/i18n/translation.md b/doc/development/i18n/translation.md
index 15b1af1aa8f..1793afcd86d 100644
--- a/doc/development/i18n/translation.md
+++ b/doc/development/i18n/translation.md
@@ -83,7 +83,7 @@ Therefore "create a new user" would translate into "Benutzer(in) anlegen".
 ### Updating the glossary
 
 To propose additions to the glossary please
-[open an issue](https://gitlab.com/gitlab-org/gitlab-ce/issues).
+[open an issue](https://gitlab.com/gitlab-org/gitlab-foss/issues).
 
 ## French Translation Guidelines
 
diff --git a/doc/development/import_export.md b/doc/development/import_export.md
index 0c343bc22e4..fcfb9bf4915 100644
--- a/doc/development/import_export.md
+++ b/doc/development/import_export.md
@@ -77,11 +77,11 @@ Marked stuck import jobs as failed. JIDs: xyz
 
 | Problem | Possible solutions |
 | -------- | -------- |
-| [Slow JSON](https://gitlab.com/gitlab-org/gitlab-ce/issues/54084) loading/dumping models from the database | [split the worker](https://gitlab.com/gitlab-org/gitlab-ce/issues/54085) |
+| [Slow JSON](https://gitlab.com/gitlab-org/gitlab-foss/issues/54084) loading/dumping models from the database | [split the worker](https://gitlab.com/gitlab-org/gitlab-foss/issues/54085) |
 | | Batch export
 | | Optimize SQL
 | | Move away from `ActiveRecord` callbacks (difficult)
-| High memory usage (see also some [analysis](https://gitlab.com/gitlab-org/gitlab-ce/issues/35389) | DB Commit sweet spot that uses less memory |
+| High memory usage (see also some [analysis](https://gitlab.com/gitlab-org/gitlab-foss/issues/35389) | DB Commit sweet spot that uses less memory |
 | | [Netflix Fast JSON API](https://github.com/Netflix/fast_jsonapi) may help |
 | | Batch reading/writing to disk and any SQL
 
@@ -96,7 +96,7 @@ importing big projects, using a foreground import:
 ## Security
 
 The Import/Export feature is constantly updated (adding new things to export), however
-the code hasn't been refactored in a long time. We should perform a [code audit](https://gitlab.com/gitlab-org/gitlab-ce/issues/42135)
+the code hasn't been refactored in a long time. We should perform a [code audit](https://gitlab.com/gitlab-org/gitlab-foss/issues/42135)
 to make sure its dynamic nature does not increase the number of security concerns.
 
 ### Security in the code
diff --git a/doc/development/kubernetes.md b/doc/development/kubernetes.md
index f4528667814..5265e5b11cd 100644
--- a/doc/development/kubernetes.md
+++ b/doc/development/kubernetes.md
@@ -21,7 +21,7 @@ are created within the `gitlab-managed-apps` namespace.
 
 In terms of code organization, we generally add objects that represent
 Kubernetes resources in
-[`lib/gitlab/kubernetes`](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/lib/gitlab/kubernetes).
+[`lib/gitlab/kubernetes`](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/lib/gitlab/kubernetes).
 
 ### Client library
 
@@ -29,12 +29,12 @@ We use the [`kubeclient`](https://rubygems.org/gems/kubeclient) gem to
 perform Kubernetes API calls. As the `kubeclient` gem does not support
 different API Groups (e.g. `apis/rbac.authorization.k8s.io`) from a
 single client, we have created a wrapper class,
-[`Gitlab::Kubernetes::KubeClient`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/kubernetes/kube_client.rb)
+[`Gitlab::Kubernetes::KubeClient`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/kubernetes/kube_client.rb)
 that will enable you to achieve this.
 
 Selected Kubernetes API groups are currently supported. Do add support
 for new API groups or methods to
-[`Gitlab::Kubernetes::KubeClient`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/kubernetes/kube_client.rb)
+[`Gitlab::Kubernetes::KubeClient`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/kubernetes/kube_client.rb)
 if you need to use them. New API groups or API group versions can be
 added to `SUPPORTED_API_GROUPS` - internally, this will create an
 internal client for that group. New methods can be added as a delegation
@@ -54,7 +54,7 @@ worker](sidekiq_style_guide.md).
 There are instances where you would like to make calls to Kubernetes and
 return the response and as such a background worker does not seem to be
 a good fit. For such cases you should make use of [reactive
-caching](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/models/concerns/reactive_caching.rb).
+caching](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/models/concerns/reactive_caching.rb).
 For example:
 
 ```ruby
@@ -72,7 +72,7 @@ For example:
 ### Testing
 
 We have some Webmock stubs in
-[`KubernetesHelpers`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/spec/support/helpers/kubernetes_helpers.rb)
+[`KubernetesHelpers`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/spec/support/helpers/kubernetes_helpers.rb)
 which can help with mocking out calls to Kubernetes API in your tests.
 
 ## Security
@@ -87,7 +87,7 @@ a cluster.
 Mitigation strategies include:
 
 1. Not allowing redirects to attacker controller resources:
-   [`Kubeclient::KubeClient`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/kubernetes/kube_client.rb#)
+   [`Kubeclient::KubeClient`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/kubernetes/kube_client.rb#)
    can be configured to disallow any redirects by passing in
    `http_max_redirects: 0` as an option.
 1. Not exposing error messages: by doing so, we
@@ -111,7 +111,7 @@ Logs related to the Kubernetes integration can be found in
 GDK install, this will be present in `log/kubernetes.log`.
 
 Some services such as
-[`Clusters::Applications::InstallService`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/services/clusters/applications/install_service.rb#L18)
+[`Clusters::Applications::InstallService`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/services/clusters/applications/install_service.rb#L18)
 rescues `StandardError` which can make it harder to debug issues in an
 development environment. The current workaround is to temporarily
 comment out the `rescue` in your local development source.
diff --git a/doc/development/licensing.md b/doc/development/licensing.md
index 0db90d2872f..538c8f2039b 100644
--- a/doc/development/licensing.md
+++ b/doc/development/licensing.md
@@ -1,6 +1,6 @@
 # GitLab Licensing and Compatibility
 
-[GitLab Community Edition](https://gitlab.com/gitlab-org/gitlab-ce/) (CE) is licensed [under the terms of the MIT License][CE]. [GitLab Enterprise Edition](https://gitlab.com/gitlab-org/gitlab-ee/) (EE) is licensed under "[The GitLab Enterprise Edition (EE) license][EE]" wherein there are more restrictions.
+[GitLab Community Edition](https://gitlab.com/gitlab-org/gitlab-foss/) (CE) is licensed [under the terms of the MIT License][CE]. [GitLab Enterprise Edition](https://gitlab.com/gitlab-org/gitlab/) (EE) is licensed under "[The GitLab Enterprise Edition (EE) license][EE]" wherein there are more restrictions.
 
 ## Automated Testing
 
@@ -106,8 +106,8 @@ Dependencies which are only used in development or test environment are exempt f
 
 **NOTE:** This document is **not** legal advice, nor is it comprehensive. It should not be taken as such.
 
-[CE]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/LICENSE
-[EE]: https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE
+[CE]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/LICENSE
+[EE]: https://gitlab.com/gitlab-org/gitlab/blob/master/LICENSE
 [license_finder]: https://github.com/pivotal/LicenseFinder
 [MIT]: http://choosealicense.com/licenses/mit/
 [LGPL]: http://choosealicense.com/licenses/lgpl-3.0/
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md
index 4740cf4de7b..5fded9e3aed 100644
--- a/doc/development/migration_style_guide.md
+++ b/doc/development/migration_style_guide.md
@@ -303,7 +303,7 @@ end
 ```
 
 If a computed update is needed, the value can be wrapped in `Arel.sql`, so Arel
-treats it as an SQL literal. It's also a required deprecation for [Rails 6](https://gitlab.com/gitlab-org/gitlab-ce/issues/61451).
+treats it as an SQL literal. It's also a required deprecation for [Rails 6](https://gitlab.com/gitlab-org/gitlab-foss/issues/61451).
 
 The below example is the same as the one above, but
 the value is set to the product of the `bar` and `baz` columns:
diff --git a/doc/development/module_with_instance_variables.md b/doc/development/module_with_instance_variables.md
index 443eee0b62c..1687a9f5ed4 100644
--- a/doc/development/module_with_instance_variables.md
+++ b/doc/development/module_with_instance_variables.md
@@ -30,11 +30,11 @@ People are saying multiple inheritance is bad. Mixing multiple modules with
 multiple instance variables scattering everywhere suffer from the same issue.
 The same applies to `ActiveSupport::Concern`. See:
 [Consider replacing concerns with dedicated classes & composition](
-https://gitlab.com/gitlab-org/gitlab-ce/issues/23786)
+https://gitlab.com/gitlab-org/gitlab-foss/issues/23786)
 
 There's also a similar idea:
 [Use decorators and interface segregation to solve overgrowing models problem](
-https://gitlab.com/gitlab-org/gitlab-ce/issues/13484)
+https://gitlab.com/gitlab-org/gitlab-foss/issues/13484)
 
 Note that `included` doesn't solve the whole issue. They define the
 dependencies, but they still allow each modules to talk implicitly via the
diff --git a/doc/development/namespaces_storage_statistics.md b/doc/development/namespaces_storage_statistics.md
index 2c7e5935435..f8aea10097d 100644
--- a/doc/development/namespaces_storage_statistics.md
+++ b/doc/development/namespaces_storage_statistics.md
@@ -14,18 +14,18 @@ storage consumed by a group, and allow easy management.
 ## Problem
 
 In GitLab, we update the project storage statistics through a
-[callback](https://gitlab.com/gitlab-org/gitlab-ce/blob/v12.2.0.pre/app/models/project.rb#L90)
+[callback](https://gitlab.com/gitlab-org/gitlab-foss/blob/v12.2.0.pre/app/models/project.rb#L90)
 every time the project is saved.
 
 The summary of those statistics per namespace is then retrieved
-by [`Namespaces#with_statistics`](https://gitlab.com/gitlab-org/gitlab-ce/blob/v12.2.0.pre/app/models/namespace.rb#L70) scope. Analyzing this query we noticed that:
+by [`Namespaces#with_statistics`](https://gitlab.com/gitlab-org/gitlab-foss/blob/v12.2.0.pre/app/models/namespace.rb#L70) scope. Analyzing this query we noticed that:
 
 - It takes up to `1.2` seconds for namespaces with over `15k` projects.
 - It can't be analyzed with [ChatOps](chatops_on_gitlabcom.md), as it times out.
 
 Additionally, the pattern that is currently used to update the project statistics
 (the callback) doesn't scale adequately. It is currently one of the largest
-[database queries transactions on production](https://gitlab.com/gitlab-org/gitlab-ce/issues/62488)
+[database queries transactions on production](https://gitlab.com/gitlab-org/gitlab-foss/issues/62488)
 that takes the most time overall.  We can't add one more query to it as
 it will increase the transaction's length.
 
@@ -131,7 +131,7 @@ WHERE namespace_id IN (
 
 Even though this approach would make aggregating much easier, it has some major downsides:
 
-- We'd have to migrate **all namespaces** by adding and filling a new column. Because of the size of the table, dealing with time/cost will not be great. The background migration will take approximately `153h`, see <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/29772>.
+- We'd have to migrate **all namespaces** by adding and filling a new column. Because of the size of the table, dealing with time/cost will not be great. The background migration will take approximately `153h`, see <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/29772>.
 - Background migration has to be shipped one release before, delaying the functionality by another milestone.
 
 ### Attempt E (final): Update the namespace storage statistics in async way
@@ -142,7 +142,7 @@ but we refresh them through Sidekiq jobs and in different transactions:
 1. Create a second table (`namespace_aggregation_schedules`) with two columns `id` and `namespace_id`.
 1. Whenever the statistics of a project changes, insert a row into `namespace_aggregation_schedules`
    - We don't insert a new row if there's already one related to the root namespace.
-   - Keeping in mind the length of the transaction that involves updating `project_statistics`(<https://gitlab.com/gitlab-org/gitlab-ce/issues/62488>), the insertion should be done in a different transaction and through a Sidekiq Job.
+   - Keeping in mind the length of the transaction that involves updating `project_statistics`(<https://gitlab.com/gitlab-org/gitlab-foss/issues/62488>), the insertion should be done in a different transaction and through a Sidekiq Job.
 1. After inserting the row, we schedule another worker to be executed async at two different moments:
    - One enqueued for immediate execution and another one scheduled in `1.5h` hours.
    - We only schedule the jobs, if we can obtain a `1.5h` lease on Redis on a key based on the root namespace ID.
@@ -162,7 +162,7 @@ This implementation has the following benefits:
 
 The only downside of this approach is that namespaces' statistics are updated up to `1.5` hours after the change is done,
 which means there's a time window in which the statistics are inaccurate. Because we're still not
-[enforcing storage limits](https://gitlab.com/gitlab-org/gitlab-ce/issues/30421), this is not a major problem.
+[enforcing storage limits](https://gitlab.com/gitlab-org/gitlab-foss/issues/30421), this is not a major problem.
 
 ## Conclusion
 
@@ -171,8 +171,8 @@ performant approach of aggregating the root namespaces.
 
 All the details regarding this use case can be found on:
 
-- <https://gitlab.com/gitlab-org/gitlab-ce/issues/62214>
-- Merge Request with the implementation: <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/28996>
+- <https://gitlab.com/gitlab-org/gitlab-foss/issues/62214>
+- Merge Request with the implementation: <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/28996>
 
 Performance of the namespace storage statistics were measured in staging and production (GitLab.com). All results were posted
-on <https://gitlab.com/gitlab-org/gitlab-ce/issues/64092>: No problem has been reported so far.
+on <https://gitlab.com/gitlab-org/gitlab-foss/issues/64092>: No problem has been reported so far.
diff --git a/doc/development/new_fe_guide/modules/dirty_submit.md b/doc/development/new_fe_guide/modules/dirty_submit.md
index 217743ea395..2ad6b8b60a3 100644
--- a/doc/development/new_fe_guide/modules/dirty_submit.md
+++ b/doc/development/new_fe_guide/modules/dirty_submit.md
@@ -1,6 +1,6 @@
 # Dirty Submit
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21115) in GitLab 11.3.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/21115) in GitLab 11.3.
 
 ## Summary
 
@@ -8,7 +8,7 @@ Prevent submitting forms with no changes.
 
 Currently handles `input`, `textarea` and `select` elements.
 
-Also, see [the code](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/dirty_submit/)
+Also, see [the code](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/assets/javascripts/dirty_submit/)
 within the GitLab project.
 
 ## Usage
diff --git a/doc/development/packages.md b/doc/development/packages.md
index 3d209c4a93c..2474392db62 100644
--- a/doc/development/packages.md
+++ b/doc/development/packages.md
@@ -9,9 +9,9 @@ package system support by solely backend changes. This guide is superficial and
 not cover the way the code should be written. However, you can find a good example
 by looking at existing merge requests with Maven and NPM support:
 
-- [NPM registry support](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8673).
-- [Maven repository](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6607).
-- [Instance level endpoint for Maven repository](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8757)
+- [NPM registry support](https://gitlab.com/gitlab-org/gitlab/merge_requests/8673).
+- [Maven repository](https://gitlab.com/gitlab-org/gitlab/merge_requests/6607).
+- [Instance level endpoint for Maven repository](https://gitlab.com/gitlab-org/gitlab/merge_requests/8757)
 
 ## General information
 
diff --git a/doc/development/performance.md b/doc/development/performance.md
index 6e6c80b7a7c..39fcc8ff806 100644
--- a/doc/development/performance.md
+++ b/doc/development/performance.md
@@ -425,8 +425,8 @@ might find using these gems more convenient:
 ### Examples
 
 You may find some useful examples in this snippet:
-<https://gitlab.com/gitlab-org/gitlab-ce/snippets/33946>
+<https://gitlab.com/gitlab-org/gitlab-foss/snippets/33946>
 
-[#15607]: https://gitlab.com/gitlab-org/gitlab-ce/issues/15607
+[#15607]: https://gitlab.com/gitlab-org/gitlab-foss/issues/15607
 [yorickpeterse]: https://gitlab.com/yorickpeterse
 [anti-pattern]: https://en.wikipedia.org/wiki/Anti-pattern
diff --git a/doc/development/polling.md b/doc/development/polling.md
index b664ddb9888..bc178f8cb21 100644
--- a/doc/development/polling.md
+++ b/doc/development/polling.md
@@ -56,4 +56,4 @@ For more information see:
 
 - [`Poll-Interval` header](fe_guide/performance.md#realtime-components)
 - [RFC 7232](https://tools.ietf.org/html/rfc7232)
-- [ETag proposal](https://gitlab.com/gitlab-org/gitlab-ce/issues/26926)
+- [ETag proposal](https://gitlab.com/gitlab-org/gitlab-foss/issues/26926)
diff --git a/doc/development/prometheus_metrics.md b/doc/development/prometheus_metrics.md
index 2a34851d21c..eecce9f4f11 100644
--- a/doc/development/prometheus_metrics.md
+++ b/doc/development/prometheus_metrics.md
@@ -2,7 +2,7 @@
 
 ## Adding to the library
 
-We strive to support the 2-4 most important metrics for each common system service that supports Prometheus. If you are looking for support for a particular exporter which has not yet been added to the library, additions can be made [to the `common_metrics.yml`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/config/prometheus/common_metrics.yml) file.
+We strive to support the 2-4 most important metrics for each common system service that supports Prometheus. If you are looking for support for a particular exporter which has not yet been added to the library, additions can be made [to the `common_metrics.yml`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/config/prometheus/common_metrics.yml) file.
 
 ### Query identifier
 
@@ -53,7 +53,7 @@ to monitor itself.
 ### Adding a new metric
 
 This section describes how to add new metrics for self-monitoring
-([example](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/15440)).
+([example](https://gitlab.com/gitlab-org/gitlab/merge_requests/15440)).
 
 1. Select the [type of metric](https://gitlab.com/gitlab-org/prometheus-client-mmap#metrics):
 
diff --git a/doc/development/query_recorder.md b/doc/development/query_recorder.md
index 3787e2ef187..3ed75c87f6f 100644
--- a/doc/development/query_recorder.md
+++ b/doc/development/query_recorder.md
@@ -2,7 +2,7 @@
 
 QueryRecorder is a tool for detecting the [N+1 queries problem](https://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations) from tests.
 
-> Implemented in [spec/support/query_recorder.rb](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/spec/support/helpers/query_recorder.rb) via [9c623e3e](https://gitlab.com/gitlab-org/gitlab-ce/commit/9c623e3e5d7434f2e30f7c389d13e5af4ede770a)
+> Implemented in [spec/support/query_recorder.rb](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/spec/support/helpers/query_recorder.rb) via [9c623e3e](https://gitlab.com/gitlab-org/gitlab-foss/commit/9c623e3e5d7434f2e30f7c389d13e5af4ede770a)
 
 As a rule, merge requests [should not increase query counts](merge_request_performance_guidelines.md#query-counts). If you find yourself adding something like `.includes(:author, :assignee)` to avoid having `N+1` queries, consider using QueryRecorder to enforce this with a test. Without this, a new feature which causes an additional model to be accessed will silently reintroduce the problem.
 
@@ -38,7 +38,7 @@ end
 
 ## Use request specs instead of controller specs
 
-Use a [request spec](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/spec/requests) when writing a N+1 test on the controller level.
+Use a [request spec](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/spec/requests) when writing a N+1 test on the controller level.
 
 Controller specs should not be used to write N+1 tests as the controller is only initialized once per example.
 This could lead to false successes where subsequent "requests" could have queries reduced (e.g. because of memoization).
diff --git a/doc/development/routing.md b/doc/development/routing.md
index a25eb48b73c..0b95477974b 100644
--- a/doc/development/routing.md
+++ b/doc/development/routing.md
@@ -70,4 +70,4 @@ you can help us migrate more of them! To migrate project routes:
 1. Add redirects for legacy routes by using `Gitlab::Routing.redirect_legacy_paths`.
 1. Create a technical debt issue to remove deprecated routes in later releases.
 
-To get started, see an [example merge request](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/28435).
+To get started, see an [example merge request](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/28435).
diff --git a/doc/development/shell_scripting_guide/index.md b/doc/development/shell_scripting_guide/index.md
index 0809f8b1a0a..60678497bb2 100644
--- a/doc/development/shell_scripting_guide/index.md
+++ b/doc/development/shell_scripting_guide/index.md
@@ -98,7 +98,7 @@ in GitLab Runner. This [may change](https://github.com/mvdan/sh/issues/68#issuec
 NOTE: **Note:**
 This is a work in progress.
 
-It is an [ongoing effort](https://gitlab.com/gitlab-org/gitlab-ce/issues/64016) to evaluate different tools for the
+It is an [ongoing effort](https://gitlab.com/gitlab-org/gitlab-foss/issues/64016) to evaluate different tools for the
 automated testing of shell scripts (like [BATS](https://github.com/sstephenson/bats)).
 
 ## Code Review
diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md
index 0f982c3a48b..a8cbf3aaa5b 100644
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@@ -148,7 +148,7 @@ Add `screenshot_and_open_image` in a `:js` spec to screenshot what Capybara
 
 The HTML dumps created by this are missing CSS.
 This results in them looking very different from the actual application.
-There is a [small hack](https://gitlab.com/gitlab-org/gitlab-ce/snippets/1718469) to add CSS which makes debugging easier.
+There is a [small hack](https://gitlab.com/gitlab-org/gitlab-foss/snippets/1718469) to add CSS which makes debugging easier.
 
 ### Fast unit tests
 
@@ -538,7 +538,7 @@ GitLab uses [factory_bot] as a test fixture replacement.
 - When instantiating from a factory, don't supply attributes that aren't
   required by the test.
 - Factories don't have to be limited to `ActiveRecord` objects.
-  [See example](https://gitlab.com/gitlab-org/gitlab-ce/commit/0b8cefd3b2385a21cfed779bd659978c0402766d).
+  [See example](https://gitlab.com/gitlab-org/gitlab-foss/commit/0b8cefd3b2385a21cfed779bd659978c0402766d).
 
 [factory_bot]: https://github.com/thoughtbot/factory_bot
 [traits]: http://www.rubydoc.info/gems/factory_bot/file/GETTING_STARTED.md#Traits
diff --git a/doc/development/testing_guide/end_to_end/index.md b/doc/development/testing_guide/end_to_end/index.md
index c00be77ce8c..9685a61d0c1 100644
--- a/doc/development/testing_guide/end_to_end/index.md
+++ b/doc/development/testing_guide/end_to_end/index.md
@@ -112,7 +112,7 @@ of the test scenarios you can run via the orchestrator](https://gitlab.com/gitla
 
 On the other hand, if you would like to run against a local development GitLab
 environment, you can use the [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit/).
-Please refer to the instructions in the [QA README](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/qa/README.md#how-can-i-use-it)
+Please refer to the instructions in the [QA README](https://gitlab.com/gitlab-org/gitlab/tree/master/qa/README.md#how-can-i-use-it)
 and the section below.
 
 ## How do I write tests?
@@ -147,10 +147,10 @@ you can find an issue you would like to work on in
 [review-apps]: ../review_apps.md
 [gitlab-qa-architecture]: https://gitlab.com/gitlab-org/gitlab-qa/blob/master/docs/architecture.md
 [gitlab-qa-issues]: https://gitlab.com/gitlab-org/gitlab-qa/issues?label_name%5B%5D=new+scenario
-[gitlab-ce-issues]: https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name[]=QA&label_name[]=test
-[gitlab-ee-issues]: https://gitlab.com/gitlab-org/gitlab-ee/issues?label_name[]=QA&label_name[]=test
+[gitlab-ce-issues]: https://gitlab.com/gitlab-org/gitlab-foss/issues?label_name[]=QA&label_name[]=test
+[gitlab-ee-issues]: https://gitlab.com/gitlab-org/gitlab/issues?label_name[]=QA&label_name[]=test
 [test environment orchestration scenarios]: https://gitlab.com/gitlab-org/gitlab-qa/tree/master/lib/gitlab/qa/scenario
-[instance-level scenarios]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/qa/qa/specs/features
-[Page objects documentation]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/qa/qa/page/README.md
-[instance-qa-readme]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/qa/README.md
-[instance-qa-examples]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/qa/qa
+[instance-level scenarios]: https://gitlab.com/gitlab-org/gitlab-foss/tree/master/qa/qa/specs/features
+[Page objects documentation]: https://gitlab.com/gitlab-org/gitlab/tree/master/qa/qa/page/README.md
+[instance-qa-readme]: https://gitlab.com/gitlab-org/gitlab/tree/master/qa/README.md
+[instance-qa-examples]: https://gitlab.com/gitlab-org/gitlab-foss/tree/master/qa/qa
diff --git a/doc/development/testing_guide/end_to_end/quick_start_guide.md b/doc/development/testing_guide/end_to_end/quick_start_guide.md
index d52d6db38b9..f5a46d574b0 100644
--- a/doc/development/testing_guide/end_to_end/quick_start_guide.md
+++ b/doc/development/testing_guide/end_to_end/quick_start_guide.md
@@ -24,7 +24,7 @@ If you don't exactly understand what we mean by **not everything needs to happen
 
 ### 0. Are end-to-end tests needed?
 
-At GitLab we respect the [test pyramid](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/testing_guide/testing_levels.md), and so, we recommend you check the code coverage of a specific feature before writing end-to-end tests, for both [CE](https://gitlab-org.gitlab.io/gitlab-ce/coverage-ruby/#_AllFiles) and [EE](https://gitlab-org.gitlab.io/gitlab-ee/coverage-ruby/#_AllFiles) projects.
+At GitLab we respect the [test pyramid](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/development/testing_guide/testing_levels.md), and so, we recommend you check the code coverage of a specific feature before writing end-to-end tests, for both [CE](https://gitlab-org.gitlab.io/gitlab-ce/coverage-ruby/#_AllFiles) and [EE](https://gitlab-org.gitlab.io/gitlab-ee/coverage-ruby/#_AllFiles) projects.
 
 Sometimes you may notice that there is already good coverage in other test levels, and we can stay confident that if we break a feature, we will still have quick feedback about it, even without having end-to-end tests.
 
@@ -32,7 +32,7 @@ If after this analysis you still think that end-to-end tests are needed, keep re
 
 ### 1. Identifying the DevOps stage
 
-The GitLab QA end-to-end tests are organized by the different [stages in the DevOps lifecycle](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/qa/qa/specs/features/browser_ui), and so, if you are creating tests for issue creation, for instance, you would locate the spec files under the `qa/qa/specs/features/browser_ui/2_plan/` directory since issue creation is part of the Plan stage.
+The GitLab QA end-to-end tests are organized by the different [stages in the DevOps lifecycle](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/qa/qa/specs/features/browser_ui), and so, if you are creating tests for issue creation, for instance, you would locate the spec files under the `qa/qa/specs/features/browser_ui/2_plan/` directory since issue creation is part of the Plan stage.
 
  In another case of a test for listing merged merge requests (MRs), the test should go under the `qa/qa/specs/features/browser_ui/3_create/` directory since merge requests are a feature from the Create stage.
 
@@ -40,9 +40,9 @@ The GitLab QA end-to-end tests are organized by the different [stages in the Dev
 
 Now, let's say we want to create tests for the [scoped labels](https://about.gitlab.com/2019/04/22/gitlab-11-10-released/#scoped-labels) feature, available on GitLab EE Premium (this feature is part of the Plan stage.)
 
-> Because these tests are for a feature available only on GitLab EE, we need to create them in the [EE repository](https://gitlab.com/gitlab-org/gitlab-ee).
+> Because these tests are for a feature available only on GitLab EE, we need to create them in the [EE repository](https://gitlab.com/gitlab-org/gitlab).
 
-Since [there is no specific directory for this feature](https://gitlab.com/gitlab-org/gitlab-ee/tree/master/qa/qa/specs/features/browser_ui/2_plan), we should create a sub-directory for it.
+Since [there is no specific directory for this feature](https://gitlab.com/gitlab-org/gitlab/tree/master/qa/qa/specs/features/browser_ui/2_plan), we should create a sub-directory for it.
 
 Under `.../browser_ui/2_plan/`, let's create a sub-directory called `ee_scoped_labels/`.
 
@@ -222,7 +222,7 @@ As the pre-conditions for our test suite, the things that needs to happen before
 - A project being created with an issue and labels already set;
 - The issue page being opened with only one scoped label applied to it.
 
-> When running end-to-end tests as part of the GitLab's continuous integration process [a license is already set as an environment variable](https://gitlab.com/gitlab-org/gitlab-ee/blob/1a60d926740db10e3b5724713285780a4f470531/qa/qa/ee/strategy.rb#L20). For running tests locally you can set up such license by following the document [what tests can be run?](https://gitlab.com/gitlab-org/gitlab-qa/blob/master/docs/what_tests_can_be_run.md), based on the [supported GitLab environment variables](https://gitlab.com/gitlab-org/gitlab-qa/blob/master/docs/what_tests_can_be_run.md#supported-gitlab-environment-variables).
+> When running end-to-end tests as part of the GitLab's continuous integration process [a license is already set as an environment variable](https://gitlab.com/gitlab-org/gitlab/blob/1a60d926740db10e3b5724713285780a4f470531/qa/qa/ee/strategy.rb#L20). For running tests locally you can set up such license by following the document [what tests can be run?](https://gitlab.com/gitlab-org/gitlab-qa/blob/master/docs/what_tests_can_be_run.md), based on the [supported GitLab environment variables](https://gitlab.com/gitlab-org/gitlab-qa/blob/master/docs/what_tests_can_be_run.md#supported-gitlab-environment-variables).
 
 #### Implementation
 
@@ -357,15 +357,15 @@ In the following we describe the changes needed in each of the resource files me
 
 Now, let's make it possible to create an issue resource through the API.
 
-First, in the [issue resource](https://gitlab.com/gitlab-org/gitlab-ee/blob/d3584e80b4236acdf393d815d604801573af72cc/qa/qa/resource/issue.rb), let's expose its id and labels attributes.
+First, in the [issue resource](https://gitlab.com/gitlab-org/gitlab/blob/d3584e80b4236acdf393d815d604801573af72cc/qa/qa/resource/issue.rb), let's expose its id and labels attributes.
 
-Add the following `attribute :id` and `attribute :labels` right above the [`attribute :title`](https://gitlab.com/gitlab-org/gitlab-ee/blob/d3584e80b4236acdf393d815d604801573af72cc/qa/qa/resource/issue.rb#L15).
+Add the following `attribute :id` and `attribute :labels` right above the [`attribute :title`](https://gitlab.com/gitlab-org/gitlab/blob/d3584e80b4236acdf393d815d604801573af72cc/qa/qa/resource/issue.rb#L15).
 
 > This line is needed to allow for the issue fabrication, and for labels to be automatically added to the issue when fabricating it via API.
 >
 > We add the attributes above the existing attribute to keep them alphabetically organized.
 
-Then, let's initialize an instance variable for labels to allow an empty array as default value when such information is not passed during the resource fabrication, since this optional. [Between the attributes and the `fabricate!` method](https://gitlab.com/gitlab-org/gitlab-ee/blob/1a1f1408728f19b2aa15887cd20bddab7e70c8bd/qa/qa/resource/issue.rb#L18), add the following:
+Then, let's initialize an instance variable for labels to allow an empty array as default value when such information is not passed during the resource fabrication, since this optional. [Between the attributes and the `fabricate!` method](https://gitlab.com/gitlab-org/gitlab/blob/1a1f1408728f19b2aa15887cd20bddab7e70c8bd/qa/qa/resource/issue.rb#L18), add the following:
 
 ```ruby
 def initialize
@@ -373,7 +373,7 @@ def initialize
 end
 ```
 
-Next, add the following code right below the [`fabricate!`](https://gitlab.com/gitlab-org/gitlab-ee/blob/d3584e80b4236acdf393d815d604801573af72cc/qa/qa/resource/issue.rb#L27) method.
+Next, add the following code right below the [`fabricate!`](https://gitlab.com/gitlab-org/gitlab/blob/d3584e80b4236acdf393d815d604801573af72cc/qa/qa/resource/issue.rb#L27) method.
 
 ```ruby
 def api_get_path
@@ -392,15 +392,15 @@ def api_post_body
 end
 ```
 
-By defining the `api_get_path` method, we allow the [`ApiFabricator`](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/qa/qa/resource/api_fabricator.rb) module to know which path to use to get a single issue.
+By defining the `api_get_path` method, we allow the [`ApiFabricator`](https://gitlab.com/gitlab-org/gitlab/blob/master/qa/qa/resource/api_fabricator.rb) module to know which path to use to get a single issue.
 
 > This `GET` path can be found in the [public API documentation](../../../api/issues.md#single-issue).
 
-By defining the `api_post_path` method, we allow the [`ApiFabricator`](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/qa/qa/resource/api_fabricator.rb) module to know which path to use to create a new issue in a specific project.
+By defining the `api_post_path` method, we allow the [`ApiFabricator`](https://gitlab.com/gitlab-org/gitlab/blob/master/qa/qa/resource/api_fabricator.rb) module to know which path to use to create a new issue in a specific project.
 
 > This `POST` path can be found in the [public API documentation](../../../api/issues.md#new-issue).
 
-By defining the `api_post_body` method, we allow the [`ApiFabricator.api_post`](https://gitlab.com/gitlab-org/gitlab-ee/blob/a9177ca1812bac57e2b2fa4560e1d5dd8ffac38b/qa/qa/resource/api_fabricator.rb#L68) method to know which data to send when making the `POST` request.
+By defining the `api_post_body` method, we allow the [`ApiFabricator.api_post`](https://gitlab.com/gitlab-org/gitlab/blob/a9177ca1812bac57e2b2fa4560e1d5dd8ffac38b/qa/qa/resource/api_fabricator.rb#L68) method to know which data to send when making the `POST` request.
 
 > Notice that we pass both `labels` and `title` attributes in the `api_post_body`, where `labels` receives an array of labels, and [`title` is required](../../../api/issues.md#new-issue). Also, notice that we keep them alphabetically organized.
 
@@ -408,7 +408,7 @@ By defining the `api_post_body` method, we allow the [`ApiFabricator.api_post`](
 
 Finally, let's make it possible to create label resources through the API.
 
-Add the following code right below the [`fabricate!`](https://gitlab.com/gitlab-org/gitlab-ee/blob/a9177ca1812bac57e2b2fa4560e1d5dd8ffac38b/qa/qa/resource/label.rb#L36) method.
+Add the following code right below the [`fabricate!`](https://gitlab.com/gitlab-org/gitlab/blob/a9177ca1812bac57e2b2fa4560e1d5dd8ffac38b/qa/qa/resource/label.rb#L36) method.
 
 ```ruby
 def resource_web_url(resource)
@@ -433,13 +433,13 @@ def api_post_body
 end
 ```
 
-By defining the `resource_web_url(resource)` method, we override the one from the [`ApiFabricator`](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/qa/qa/resource/api_fabricator.rb#L44) module. We do that to avoid failing the test due to this particular resource not exposing a `web_url` property.
+By defining the `resource_web_url(resource)` method, we override the one from the [`ApiFabricator`](https://gitlab.com/gitlab-org/gitlab/blob/master/qa/qa/resource/api_fabricator.rb#L44) module. We do that to avoid failing the test due to this particular resource not exposing a `web_url` property.
 
-By defining the `api_get_path` method, we **would** allow for the [`ApiFabricator`](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/qa/qa/resource/api_fabricator.rb) module to know which path to use to get a single label, but since there's no path available for that in the publich API, we raise a `NotImplementedError` instead.
+By defining the `api_get_path` method, we **would** allow for the [`ApiFabricator`](https://gitlab.com/gitlab-org/gitlab/blob/master/qa/qa/resource/api_fabricator.rb) module to know which path to use to get a single label, but since there's no path available for that in the publich API, we raise a `NotImplementedError` instead.
 
-By defining the `api_post_path` method, we allow for the [`ApiFabricator`](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/qa/qa/resource/api_fabricator.rb) module to know which path to use to create a new label in a specific project.
+By defining the `api_post_path` method, we allow for the [`ApiFabricator`](https://gitlab.com/gitlab-org/gitlab/blob/master/qa/qa/resource/api_fabricator.rb) module to know which path to use to create a new label in a specific project.
 
-By defining the `api_post_body` method, we we allow for the [`ApiFabricator.api_post`](https://gitlab.com/gitlab-org/gitlab-ee/blob/a9177ca1812bac57e2b2fa4560e1d5dd8ffac38b/qa/qa/resource/api_fabricator.rb#L68) method to know which data to send when making the `POST` request.
+By defining the `api_post_body` method, we we allow for the [`ApiFabricator.api_post`](https://gitlab.com/gitlab-org/gitlab/blob/a9177ca1812bac57e2b2fa4560e1d5dd8ffac38b/qa/qa/resource/api_fabricator.rb#L68) method to know which data to send when making the `POST` request.
 
 > Notice that we pass both `color` and `name` attributes in the `api_post_body` since [those are required](../../../api/labels.md#create-a-new-label). Also, notice that we keep them alphabetically organized.
 
@@ -447,7 +447,7 @@ By defining the `api_post_body` method, we we allow for the [`ApiFabricator.api_
 
 Page Objects are used in end-to-end tests for maintenance reasons, where a page's elements and methods are defined to be reused in any test.
 
-> Page Objects are auto-loaded in the [`qa/qa.rb`](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/qa/qa.rb) file and available in all the test files (`*_spec.rb`).
+> Page Objects are auto-loaded in the [`qa/qa.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/qa/qa.rb) file and available in all the test files (`*_spec.rb`).
 
 Take a look at the [Page Objects] documentation.
 
@@ -495,7 +495,7 @@ Let's now update the Issue Page Object.
 
 > Page Objects are located in the `qa/qa/page/` directory, and its sub-directories.
 
-The file we will have to change is the [Issue Page Object](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/qa/qa/page/project/issue/show.rb).
+The file we will have to change is the [Issue Page Object](https://gitlab.com/gitlab-org/gitlab/blob/master/qa/qa/page/project/issue/show.rb).
 
 First, add the following code right below the definition of an already implemented view (keep in mind that view's definitions and their elements should be alphabetically ordered):
 
@@ -554,7 +554,7 @@ The `text_of_labels_block` method is a simple method that returns the `:labels_b
 
 Now let's change the view and the `dropdowns_helper` files to add the selectors that relate to the [Page Objects].
 
-In  [`app/views/shared/issuable/_sidebar.html.haml:105`](https://gitlab.com/gitlab-org/gitlab-ee/blob/7ca12defc7a965987b162a6ebef302f95dc8867f/app/views/shared/issuable/_sidebar.html.haml#L105), add a `data: { qa_selector: 'edit_link_labels' }` data attribute.
+In  [`app/views/shared/issuable/_sidebar.html.haml:105`](https://gitlab.com/gitlab-org/gitlab/blob/7ca12defc7a965987b162a6ebef302f95dc8867f/app/views/shared/issuable/_sidebar.html.haml#L105), add a `data: { qa_selector: 'edit_link_labels' }` data attribute.
 
 The code should look like this:
 
@@ -562,7 +562,7 @@ The code should look like this:
 = link_to _('Edit'), '#', class: 'js-sidebar-dropdown-toggle edit-link float-right', data: { qa_selector: 'edit_link_labels' }
 ```
 
-In the same file, on [line 121](https://gitlab.com/gitlab-org/gitlab-ee/blob/7ca12defc7a965987b162a6ebef302f95dc8867f/app/views/shared/issuable/_sidebar.html.haml#L121), add a `data: { qa_selector: 'dropdown_menu_labels' }` data attribute.
+In the same file, on [line 121](https://gitlab.com/gitlab-org/gitlab/blob/7ca12defc7a965987b162a6ebef302f95dc8867f/app/views/shared/issuable/_sidebar.html.haml#L121), add a `data: { qa_selector: 'dropdown_menu_labels' }` data attribute.
 
 The code should look like this:
 
@@ -570,7 +570,7 @@ The code should look like this:
 .dropdown-menu.dropdown-select.dropdown-menu-paging.dropdown-menu-labels.dropdown-menu-selectable.dropdown-extended-height{ data: { qa_selector: 'dropdown_menu_labels' } }
 ```
 
-In [`app/helpers/dropdowns_helper.rb:94`](https://gitlab.com/gitlab-org/gitlab-ee/blob/7ca12defc7a965987b162a6ebef302f95dc8867f/app/helpers/dropdowns_helper.rb#L94), add a `data: { qa_selector: 'dropdown_input_field' }` data attribute.
+In [`app/helpers/dropdowns_helper.rb:94`](https://gitlab.com/gitlab-org/gitlab/blob/7ca12defc7a965987b162a6ebef302f95dc8867f/app/helpers/dropdowns_helper.rb#L94), add a `data: { qa_selector: 'dropdown_input_field' }` data attribute.
 
 The code should look like this:
 
@@ -581,7 +581,7 @@ filter_output = search_field_tag search_id, nil, class: "dropdown-input-field",
 > `data-qa-*` data attributes and CSS classes starting with `qa-` are used solely for the purpose of QA and testing.
 > By defining these, we add **testability** to the application.
 >
-> When defining a data attribute like: `qa_selector: 'labels_block'`, it should match the element definition: `element :labels_block`. We use a [sanity test](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/qa/qa/page#how-did-we-solve-fragile-tests-problem) to check that defined elements have their respective selectors in the specified views.
+> When defining a data attribute like: `qa_selector: 'labels_block'`, it should match the element definition: `element :labels_block`. We use a [sanity test](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/qa/qa/page#how-did-we-solve-fragile-tests-problem) to check that defined elements have their respective selectors in the specified views.
 
 #### Updates in the `QA::Page::Base` class
 
diff --git a/doc/development/testing_guide/flaky_tests.md b/doc/development/testing_guide/flaky_tests.md
index eb0bf6fc563..8e73b3d9ae9 100644
--- a/doc/development/testing_guide/flaky_tests.md
+++ b/doc/development/testing_guide/flaky_tests.md
@@ -48,51 +48,51 @@ examples in a JSON report file on `master` (`retrieve-tests-metadata` and `updat
 is detected in any other branch (`flaky-examples-check` job). In the future, the
 `flaky-examples-check` job will not be allowed to fail.
 
-This was originally implemented in: <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13021>.
+This was originally implemented in: <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/13021>.
 
 [rspec-retry]: https://github.com/NoRedInk/rspec-retry
-[`spec/spec_helper.rb`]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/spec/spec_helper.rb
+[`spec/spec_helper.rb`]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/spec/spec_helper.rb
 
 ## Problems we had in the past at GitLab
 
-- [`rspec-retry` is bitting us when some API specs fail](https://gitlab.com/gitlab-org/gitlab-ce/issues/29242): <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9825>
-- [Sporadic RSpec failures due to `PG::UniqueViolation`](https://gitlab.com/gitlab-org/gitlab-ce/issues/28307#note_24958837): <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9846>
-  - Follow-up: <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10688>
-  - [Capybara.reset_session! should be called before requests are blocked](https://gitlab.com/gitlab-org/gitlab-ce/issues/33779): <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12224>
+- [`rspec-retry` is bitting us when some API specs fail](https://gitlab.com/gitlab-org/gitlab-foss/issues/29242): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/9825>
+- [Sporadic RSpec failures due to `PG::UniqueViolation`](https://gitlab.com/gitlab-org/gitlab-foss/issues/28307#note_24958837): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/9846>
+  - Follow-up: <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10688>
+  - [Capybara.reset_session! should be called before requests are blocked](https://gitlab.com/gitlab-org/gitlab-foss/issues/33779): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12224>
 - FFaker generates funky data that tests are not ready to handle (and tests should be predictable so that's bad!):
-  - [Make `spec/mailers/notify_spec.rb` more robust](https://gitlab.com/gitlab-org/gitlab-ce/issues/20121): <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10015>
-  - [Transient failure in spec/requests/api/commits_spec.rb](https://gitlab.com/gitlab-org/gitlab-ce/issues/27988#note_25342521): <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9944>
-  - [Replace FFaker factory data with sequences](https://gitlab.com/gitlab-org/gitlab-ce/issues/29643): <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10184>
-  - [Transient failure in spec/finders/issues_finder_spec.rb](https://gitlab.com/gitlab-org/gitlab-ce/issues/30211#note_26707685): <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10404>
+  - [Make `spec/mailers/notify_spec.rb` more robust](https://gitlab.com/gitlab-org/gitlab-foss/issues/20121): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10015>
+  - [Transient failure in spec/requests/api/commits_spec.rb](https://gitlab.com/gitlab-org/gitlab-foss/issues/27988#note_25342521): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/9944>
+  - [Replace FFaker factory data with sequences](https://gitlab.com/gitlab-org/gitlab-foss/issues/29643): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10184>
+  - [Transient failure in spec/finders/issues_finder_spec.rb](https://gitlab.com/gitlab-org/gitlab-foss/issues/30211#note_26707685): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10404>
 
 ### Time-sensitive flaky tests
 
-- <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10046>
-- <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10306>
+- <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10046>
+- <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10306>
 
 ### Array order expectation
 
-- <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10148>
+- <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10148>
 
 ### Feature tests
 
-- [Be sure to create all the data the test need before starting exercize](https://gitlab.com/gitlab-org/gitlab-ce/issues/32622#note_31128195): <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12059>
-- [Bis](https://gitlab.com/gitlab-org/gitlab-ce/issues/34609#note_34048715): <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12604>
-- [Bis](https://gitlab.com/gitlab-org/gitlab-ce/issues/34698#note_34276286): <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12664>
-- [Assert against the underlying database state instead of against a page's content](https://gitlab.com/gitlab-org/gitlab-ce/issues/31437): <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10934>
+- [Be sure to create all the data the test need before starting exercize](https://gitlab.com/gitlab-org/gitlab-foss/issues/32622#note_31128195): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12059>
+- [Bis](https://gitlab.com/gitlab-org/gitlab-foss/issues/34609#note_34048715): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12604>
+- [Bis](https://gitlab.com/gitlab-org/gitlab-foss/issues/34698#note_34276286): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12664>
+- [Assert against the underlying database state instead of against a page's content](https://gitlab.com/gitlab-org/gitlab-foss/issues/31437): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10934>
 
 #### Capybara viewport size related issues
 
-- [Transient failure of spec/features/issues/filtered_search/filter_issues_spec.rb](https://gitlab.com/gitlab-org/gitlab-ce/issues/29241#note_26743936): <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10411>
+- [Transient failure of spec/features/issues/filtered_search/filter_issues_spec.rb](https://gitlab.com/gitlab-org/gitlab-foss/issues/29241#note_26743936): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10411>
 
 #### Capybara JS driver related issues
 
-- [Don't wait for AJAX when no AJAX request is fired](https://gitlab.com/gitlab-org/gitlab-ce/issues/30461): <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10454>
-- [Bis](https://gitlab.com/gitlab-org/gitlab-ce/issues/34647): <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12626>
+- [Don't wait for AJAX when no AJAX request is fired](https://gitlab.com/gitlab-org/gitlab-foss/issues/30461): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10454>
+- [Bis](https://gitlab.com/gitlab-org/gitlab-foss/issues/34647): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12626>
 
 #### PhantomJS / WebKit related issues
 
-- Memory is through the roof! (TL;DR: Load images but block images requests!): <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12003>
+- Memory is through the roof! (TL;DR: Load images but block images requests!): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12003>
 
 ## Resources
 
diff --git a/doc/development/testing_guide/frontend_testing.md b/doc/development/testing_guide/frontend_testing.md
index 91004bf177d..da843218d8b 100644
--- a/doc/development/testing_guide/frontend_testing.md
+++ b/doc/development/testing_guide/frontend_testing.md
@@ -35,10 +35,10 @@ which could arise (especially with testing against browser specific features).
 
 ### Differences to Karma
 
-- Jest runs in a Node.js environment, not in a browser. Support for running Jest tests in a browser [is planned](https://gitlab.com/gitlab-org/gitlab-ce/issues/58205).
+- Jest runs in a Node.js environment, not in a browser. Support for running Jest tests in a browser [is planned](https://gitlab.com/gitlab-org/gitlab-foss/issues/58205).
 - Because Jest runs in a Node.js environment, it uses [jsdom](https://github.com/jsdom/jsdom) by default. See also its [limitations](#limitations-of-jsdom) below.
 - Jest does not have access to Webpack loaders or aliases.
-  The aliases used by Jest are defined in its [own config](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/jest.config.js).
+  The aliases used by Jest are defined in its [own config](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/jest.config.js).
 - All calls to `setTimeout` and `setInterval` are mocked away. See also [Jest Timer Mocks](https://jestjs.io/docs/en/timer-mocks).
 - `rewire` is not required because Jest supports mocking modules. See also [Manual Mocks](https://jestjs.io/docs/en/manual-mocks).
 - No [context object](https://jasmine.github.io/tutorials/your_first_suite#section-The_%3Ccode%3Ethis%3C/code%3E_keyword) is passed to tests in Jest.
@@ -58,7 +58,7 @@ This comes with a number of limitations, namely:
 - [No element sizes or positions](https://github.com/jsdom/jsdom/blob/15.1.1/lib/jsdom/living/nodes/Element-impl.js#L334-L371)
 - [No layout engine](https://github.com/jsdom/jsdom/issues/1322) in general
 
-See also the issue for [support running Jest tests in browsers](https://gitlab.com/gitlab-org/gitlab-ce/issues/58205).
+See also the issue for [support running Jest tests in browsers](https://gitlab.com/gitlab-org/gitlab-foss/issues/58205).
 
 ### Debugging Jest tests
 
@@ -67,13 +67,13 @@ Running `yarn jest-debug` will run Jest in debug mode, allowing you to debug/ins
 ### Timeout error
 
 The default timeout for Jest is set in
-[`/spec/frontend/test_setup.js`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/spec/frontend/test_setup.js).
+[`/spec/frontend/test_setup.js`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/spec/frontend/test_setup.js).
 
 If your test exceeds that time, it will fail.
 
 If you cannot improve the performance of the tests, you can increase the timeout
 for a specific test using
-[`setTestTimeout`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/spec/frontend/helpers/timeout.js).
+[`setTestTimeout`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/spec/frontend/helpers/timeout.js).
 
 ```javascript
 import { setTestTimeout } from 'helpers/timeout';
@@ -321,8 +321,7 @@ it('waits for an Ajax call', done => {
 });
 ```
 
-If you are not able to register handlers to the `Promise`—for example because it is executed in a synchronous Vue life
-cycle hook—you can flush all pending `Promise`s:
+If you are not able to register handlers to the `Promise`, for example because it is executed in a synchronous Vue life cycle hook, please take a look at the [waitFor](#wait-until-axios-requests-finish) helpers or you can flush all pending `Promise`s:
 
 **in Jest:**
 
@@ -389,7 +388,7 @@ it('renders something', done => {
 ##### `setTimeout()` / `setInterval()` in application
 
 If the application itself is waiting for some time, mock await the waiting. In Jest this is already
-[done by default](https://gitlab.com/gitlab-org/gitlab-ce/blob/a2128edfee799e49a8732bfa235e2c5e14949c68/jest.config.js#L47)
+[done by default](https://gitlab.com/gitlab-org/gitlab-foss/blob/a2128edfee799e49a8732bfa235e2c5e14949c68/jest.config.js#L47)
 (see also [Jest Timer Mocks](https://jestjs.io/docs/en/timer-mocks)). In Karma you can use the
 [Jasmine mock clock](https://jasmine.github.io/api/2.9/Clock.html).
 
@@ -617,10 +616,10 @@ Tests relevant for frontend development can be found at the following places:
 - `spec/features/` which are run by RSpec and contain
   - [feature tests](#feature-tests)
 
-All tests in `spec/javascripts/` will eventually be migrated to `spec/frontend/` (see also [#52483](https://gitlab.com/gitlab-org/gitlab-ce/issues/52483)).
+All tests in `spec/javascripts/` will eventually be migrated to `spec/frontend/` (see also [#52483](https://gitlab.com/gitlab-org/gitlab-foss/issues/52483)).
 
 In addition, there used to be feature tests in `features/`, run by Spinach.
-These were removed from the codebase in May 2018 ([#23036](https://gitlab.com/gitlab-org/gitlab-ce/issues/23036)).
+These were removed from the codebase in May 2018 ([#23036](https://gitlab.com/gitlab-org/gitlab-foss/issues/23036)).
 
 See also [Notes on testing Vue components](../fe_guide/vue.html#testing-vue-components).
 
@@ -1049,7 +1048,7 @@ testAction(
 );
 ```
 
-Check an example in [spec/javascripts/ide/stores/actions_spec.jsspec/javascripts/ide/stores/actions_spec.js](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/spec/javascripts/ide/stores/actions_spec.js).
+Check an example in [spec/javascripts/ide/stores/actions_spec.jsspec/javascripts/ide/stores/actions_spec.js](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/spec/javascripts/ide/stores/actions_spec.js).
 
 ### Vue Helper: `mountComponent`
 
@@ -1088,6 +1087,16 @@ afterEach(() => {
 });
 ```
 
+### Wait until axios requests finish
+
+The axios utils mock module located in `spec/frontend/mocks/ce/lib/utils/axios_utils.js` contains two helper methods for Jest tests that spawn HTTP requests.
+These are very useful if you don't have a handle to the request's Promise, for example when a Vue component does a request as part of its life cycle.
+
+- `waitFor(url, callback)`: Runs `callback` after a request to `url` finishes (either successfully or unsuccessfully).
+- `waitForAll(callback)`: Runs `callback` once all pending requests have finished. If no requests are pending, runs `callback` on the next tick.
+
+Both functions run `callback` on the next tick after the requests finish (using `setImmediate()`), to allow any `.then()` or `.catch()` handlers to run.
+
 ## Testing with older browsers
 
 Some regressions only affect a specific browser version. We can install and test in particular browsers with either Firefox or Browserstack using the following steps:
diff --git a/doc/development/testing_guide/review_apps.md b/doc/development/testing_guide/review_apps.md
index 8698a1e4c2d..8ce25376a05 100644
--- a/doc/development/testing_guide/review_apps.md
+++ b/doc/development/testing_guide/review_apps.md
@@ -1,8 +1,7 @@
 # Review Apps
 
-Review Apps are automatically deployed by each pipeline, both in
-[CE](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22010) and
-[EE](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6665).
+Review Apps are automatically deployed by [the
+pipeline](https://gitlab.com/gitlab-org/gitlab/merge_requests/6665).
 
 ## How does it work?
 
@@ -190,8 +189,8 @@ that the `review-apps-ce/ee` cluster is unhealthy. Leading indicators may be hea
 
 The following items may help diagnose this:
 
-- [Instance group CPU Utilization in GCP](https://console.cloud.google.com/compute/instanceGroups/details/us-central1-a/gke-review-apps-ce-preemp-n1-standard-a4c9571c-grp?project=gitlab-review-apps&tab=monitoring&graph=GCE_CPU&duration=PT12H) - helpful to identify if nodes are problematic or the entire cluster is trending towards unhealthy
-- [Instance Group size in GCP](https://console.cloud.google.com/compute/instanceGroups/details/us-central1-a/gke-review-apps-ce-preemp-n1-standard-a4c9571c-grp?project=gitlab-review-apps&tab=monitoring&graph=GCE_SIZE&duration=PT12H) - aids in identifying load spikes on the cluster. Kubernetes will add nodes up to 220 based on total resource requests.
+- [Instance group CPU Utilization in GCP](https://console.cloud.google.com/compute/instanceGroups/details/us-central1-b/gke-review-apps-ee-preemp-n1-standard-8affc0f5-grp?project=gitlab-review-apps&tab=monitoring&graph=GCE_CPU&duration=P30D) - helpful to identify if nodes are problematic or the entire cluster is trending towards unhealthy
+- [Instance Group size in GCP](https://console.cloud.google.com/compute/instanceGroups/details/us-central1-b/gke-review-apps-ee-preemp-n1-standard-8affc0f5-grp?project=gitlab-review-apps&tab=monitoring&graph=GCE_SIZE&duration=P30D) - aids in identifying load spikes on the cluster. Kubernetes will add nodes up to 220 based on total resource requests.
 - `kubectl top nodes --sort-by=cpu` - can identify if node spikes are common or load on specific nodes which may get rebalanced by the Kubernetes scheduler.
 - `kubectl top pods --sort-by=cpu` -
 - [K9s] - K9s is a powerful command line dashboard which allows you to filter by labels. This can help identify trends with apps exceeding the [review-app resource requests](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/scripts/review_apps/base-config.yaml). Kubernetes will schedule pods to nodes based on resource requests and allow for CPU usage up to the limits.
@@ -206,7 +205,7 @@ The following items may help diagnose this:
 
 #### Finding the problem
 
-[In the past](https://gitlab.com/gitlab-org/gitlab-ce/issues/62834), it happened
+[In the past](https://gitlab.com/gitlab-org/gitlab-foss/issues/62834), it happened
 that the `dns-gitlab-review-app-external-dns` Deployment was in a pending state,
 effectively preventing all the Review Apps from getting a DNS record assigned,
 making them unreachable via domain name.
@@ -299,10 +298,10 @@ find a way to limit it to only us.**
 - [Stern](https://github.com/wercker/stern) - enables cross pod log tailing based on label/field selectors
 
 [charts-1068]: https://gitlab.com/gitlab-org/charts/gitlab/issues/1068
-[gitlab-pipeline]: https://gitlab.com/gitlab-org/gitlab-ce/pipelines/44362587
-[gitlab:assets:compile]: https://gitlab.com/gitlab-org/gitlab-ce/-/jobs/149511610
-[review-build-cng]: https://gitlab.com/gitlab-org/gitlab-ce/-/jobs/149511623
-[review-deploy]: https://gitlab.com/gitlab-org/gitlab-ce/-/jobs/149511624
+[gitlab-pipeline]: https://gitlab.com/gitlab-org/gitlab-foss/pipelines/44362587
+[gitlab:assets:compile]: https://gitlab.com/gitlab-org/gitlab-foss/-/jobs/149511610
+[review-build-cng]: https://gitlab.com/gitlab-org/gitlab-foss/-/jobs/149511623
+[review-deploy]: https://gitlab.com/gitlab-org/gitlab-foss/-/jobs/149511624
 [cng-mirror]: https://gitlab.com/gitlab-org/build/CNG-mirror
 [cng]: https://gitlab.com/gitlab-org/build/CNG
 [cng-mirror-pipeline]: https://gitlab.com/gitlab-org/build/CNG-mirror/pipelines/44364657
@@ -310,13 +309,13 @@ find a way to limit it to only us.**
 [helm-chart]: https://gitlab.com/gitlab-org/charts/gitlab/
 [review-apps-ce]: https://console.cloud.google.com/kubernetes/clusters/details/us-central1-a/review-apps-ce?project=gitlab-review-apps
 [review-apps-ee]: https://console.cloud.google.com/kubernetes/clusters/details/us-central1-b/review-apps-ee?project=gitlab-review-apps
-[review-apps.sh]: https://gitlab.com/gitlab-org/gitlab-ee/blob/master/scripts/review_apps/review-apps.sh
-[automated_cleanup.rb]: https://gitlab.com/gitlab-org/gitlab-ee/blob/master/scripts/review_apps/automated_cleanup.rb
-[Auto-DevOps.gitlab-ci.yml]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml
-[gitlab-ci-yml]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab-ci.yml
+[review-apps.sh]: https://gitlab.com/gitlab-org/gitlab/blob/master/scripts/review_apps/review-apps.sh
+[automated_cleanup.rb]: https://gitlab.com/gitlab-org/gitlab/blob/master/scripts/review_apps/automated_cleanup.rb
+[Auto-DevOps.gitlab-ci.yml]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml
+[gitlab-ci-yml]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/.gitlab-ci.yml
 [gitlab-k8s-integration]: ../../user/project/clusters/index.md
-[password-bug]: https://gitlab.com/gitlab-org/gitlab-ce/issues/53621
 [K9s]: https://github.com/derailed/k9s
+[password-bug]: https://gitlab.com/gitlab-org/gitlab-foss/issues/53621
 
 ---
 
diff --git a/doc/development/testing_guide/smoke.md b/doc/development/testing_guide/smoke.md
index c9d3238fbe9..5a144b43478 100644
--- a/doc/development/testing_guide/smoke.md
+++ b/doc/development/testing_guide/smoke.md
@@ -12,6 +12,7 @@ Currently, our suite consists of this basic functionality coverage:
 - Project simple creation
 - Project creation with Auto-DevOps enabled
 - Issue creation
+- Issue user mentions
 - Merge Request creation
 - Snippet creation
 
diff --git a/doc/development/testing_guide/testing_levels.md b/doc/development/testing_guide/testing_levels.md
index 1aee306f492..b9436abf856 100644
--- a/doc/development/testing_guide/testing_levels.md
+++ b/doc/development/testing_guide/testing_levels.md
@@ -44,7 +44,7 @@ records should use stubs/doubles as much as possible.
 | `config/routes.rb`, `config/routes/` | `spec/routing/` | RSpec | |
 | `config/puma.example.development.rb`, `config/unicorn.rb.example` | `spec/rack_servers/` | RSpec | |
 | `db/` | `spec/db/` | RSpec | |
-| `db/{post_,}migrate/` | `spec/migrations/` | RSpec | More details at [`spec/migrations/README.md`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/spec/migrations/README.md). |
+| `db/{post_,}migrate/` | `spec/migrations/` | RSpec | More details at [`spec/migrations/README.md`](https://gitlab.com/gitlab-org/gitlab/blob/master/spec/migrations/README.md). |
 | `Gemfile` | `spec/dependencies/`, `spec/sidekiq/` | RSpec | |
 | `lib/` | `spec/lib/` | RSpec | |
 | `lib/tasks/` | `spec/tasks/` | RSpec | |
@@ -81,7 +81,7 @@ controller.instance_variable_set(:@user, user)
 
 and use methods which are deprecated in Rails 5 ([#23768]).
 
-[#23768]: https://gitlab.com/gitlab-org/gitlab-ce/issues/23768
+[#23768]: https://gitlab.com/gitlab-org/gitlab-foss/issues/23768
 
 ### About Karma
 
@@ -190,8 +190,8 @@ confused with the application's [unit tests](#unit-tests) or
 [GitLab Pages]: https://gitlab.com/gitlab-org/gitlab-pages
 [GitLab Runner]: https://gitlab.com/gitlab-org/gitlab-runner
 [GitLab Omnibus]: https://gitlab.com/gitlab-org/omnibus-gitlab
-[part of GitLab Rails]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/qa
-[test plan]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/.gitlab/issue_templates/Test%20plan.md
+[part of GitLab Rails]: https://gitlab.com/gitlab-org/gitlab-foss/tree/master/qa
+[test plan]: https://gitlab.com/gitlab-org/gitlab/tree/master/.gitlab/issue_templates/Test%20plan.md
 [Product category]: https://about.gitlab.com/handbook/product/categories/
 
 ### Smoke tests
diff --git a/doc/development/uploads.md b/doc/development/uploads.md
index 681ce9d9fe8..1af3e9db954 100644
--- a/doc/development/uploads.md
+++ b/doc/development/uploads.md
@@ -209,8 +209,8 @@ This is the more advanced acceleration technique we have in place.
 Workhorse asks rails for temporary pre-signed object storage URLs and directly uploads to object storage.
 
 In this setup an extra rails route needs to be implemented in order to handle authorization,
-you can see an example of this in [`Projects::LfsStorageController`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/controllers/projects/lfs_storage_controller.rb)
-and [its routes](https://gitlab.com/gitlab-org/gitlab-ce/blob/v12.2.0/config/routes/git_http.rb#L31-32).
+you can see an example of this in [`Projects::LfsStorageController`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/app/controllers/projects/lfs_storage_controller.rb)
+and [its routes](https://gitlab.com/gitlab-org/gitlab-foss/blob/v12.2.0/config/routes/git_http.rb#L31-32).
 
 **note:** this will fallback to _Workhorse disk acceleration_ when object storage is not enabled in the gitlab instance. The answer to the `/authorize` call will only contain a file system path.
 
diff --git a/doc/development/utilities.md b/doc/development/utilities.md
index 4021756343c..11de0d56ef3 100644
--- a/doc/development/utilities.md
+++ b/doc/development/utilities.md
@@ -2,7 +2,7 @@
 
 We developed a number of utilities to ease development.
 
-## [`MergeHash`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/utils/merge_hash.rb)
+## [`MergeHash`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/utils/merge_hash.rb)
 
 - Deep merges an array of hashes:
 
@@ -45,7 +45,7 @@ We developed a number of utilities to ease development.
   [:hello, "world", :this, :crushes, "an entire", "hash"]
   ```
 
-## [`Override`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/utils/override.rb)
+## [`Override`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/utils/override.rb)
 
 - This utility could help us check if a particular method would override
   another method or not. It has the same idea of Java's `@Override` annotation
@@ -90,7 +90,7 @@ We developed a number of utilities to ease development.
     end
     ```
 
-## [`StrongMemoize`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/utils/strong_memoize.rb)
+## [`StrongMemoize`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/utils/strong_memoize.rb)
 
 - Memoize the value even if it is `nil` or `false`.
 
@@ -136,7 +136,7 @@ We developed a number of utilities to ease development.
   Find.new.clear_memoization(:result)
   ```
 
-## [`RequestCache`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/cache/request_cache.rb)
+## [`RequestCache`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/cache/request_cache.rb)
 
 This module provides a simple way to cache values in RequestStore,
 and the cache key would be based on the class name, method name,