Merge branch 'master' into 'docs-hard-tabs'docs-hard-tabs

# Conflicts:
#   doc/administration/pseudonymizer.md
#   doc/administration/uploads.md

34 files changed, 236 insertions, 222 deletions

diff --git a/doc/development/api_styleguide.md b/doc/development/api_styleguide.md
index 4fc38a460f8..0866d3baeeb 100644
--- a/doc/development/api_styleguide.md
+++ b/doc/development/api_styleguide.md
@@ -53,7 +53,7 @@ allowed.
 
 ### Exclude params from parent namespaces!
 
-> By default `declared(params) `includes parameters that were defined in all
+> By default `declared(params)`includes parameters that were defined in all
 parent namespaces.
 
 – <https://github.com/ruby-grape/grape#include-parent-namespaces>
diff --git a/doc/development/architecture.md b/doc/development/architecture.md
index 8319603fea2..b645a72567c 100644
--- a/doc/development/architecture.md
+++ b/doc/development/architecture.md
@@ -484,9 +484,11 @@ When making a request to an HTTP Endpoint (think `/users/sign_in`) the request w
 Below we describe the different pathing that HTTP vs. SSH Git requests will take. There is some overlap with the Web Request Cycle but also some differences.
 
 ### Web Request (80/443)
+
 TODO
 
 ### SSH Request (22)
+
 TODO
 
 ## System Layout
@@ -505,7 +507,9 @@ To summarize here's the [directory structure of the `git` user home directory](.
 
 ### Processes
 
-    ps aux | grep '^git'
+```sh
+ps aux | grep '^git'
+```
 
 GitLab has several components to operate. As a system user (i.e. any user that is not the `git` user) it requires a persistent database (MySQL/PostreSQL) and redis database. It also uses Apache httpd or Nginx to proxypass Unicorn. As the `git` user it starts Sidekiq and Unicorn (a simple ruby HTTP server running on port `8080` by default). Under the GitLab user there are normally 4 processes: `unicorn_rails master` (1 process), `unicorn_rails worker` (2 processes), `sidekiq` (1 process).
 
diff --git a/doc/development/chatops_on_gitlabcom.md b/doc/development/chatops_on_gitlabcom.md
index de942c0ae94..3b681880401 100644
--- a/doc/development/chatops_on_gitlabcom.md
+++ b/doc/development/chatops_on_gitlabcom.md
@@ -13,10 +13,10 @@ tasks such as:
 To request access to Chatops on GitLab.com:
 
 1. Log into <https://ops.gitlab.net/users/sign_in> using the same username as for GitLab.com.
-1. Ask [anyone in the `chatops` project](https://gitlab.com/gitlab-com/chatops/project_members) to add you by running `/chatops run member add <username> gitlab-com/chatops --ops`.
+1. Ask [anyone in the `chatops` project](https://gitlab.com/gitlab-com/chatops/-/project_members) to add you by running `/chatops run member add <username> gitlab-com/chatops --ops`.
 
 ## See also
 
- - [Chatops Usage](../ci/chatops/README.md)
- - [Understanding EXPLAIN plans](understanding_explain_plans.md)
- - [Feature Groups](feature_flags/development.md#feature-groups)
+- [Chatops Usage](../ci/chatops/README.md)
+- [Understanding EXPLAIN plans](understanding_explain_plans.md)
+- [Feature Groups](feature_flags/development.md#feature-groups)
diff --git a/doc/development/code_comments.md b/doc/development/code_comments.md
index 36962eb46d4..827a610efa2 100644
--- a/doc/development/code_comments.md
+++ b/doc/development/code_comments.md
@@ -1,11 +1,11 @@
 # Code comments
 
-Whenever you add comment to the code that is expected to be addressed at any time 
-in future, please create a technical debt issue for it. Then put a link to it 
+Whenever you add comment to the code that is expected to be addressed at any time
+in future, please create a technical debt issue for it. Then put a link to it
 to the code comment you've created. This will allow other developers to quickly
 check if a comment is still relevant and what needs to be done to address it.
 
-Examples: 
+Examples:
 
 ```rb
 # Deprecated scope until code_owner column has been migrated to rule_type.
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index 6123f9f845a..e60800f1ab7 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -319,7 +319,7 @@ reviewee.
 ### GitLab-specific concerns
 
 GitLab is used in a lot of places. Many users use
-our [Omnibus packages](https://about.gitlab.com/installation/), but some use
+our [Omnibus packages](https://about.gitlab.com/install/), but some use
 the [Docker images](https://docs.gitlab.com/omnibus/docker/), some are
 [installed from source](../install/installation.md),
 and there are other installation methods available. GitLab.com itself is a large
diff --git a/doc/development/contributing/community_roles.md b/doc/development/contributing/community_roles.md
index b9c369286d2..3296cb173d7 100644
--- a/doc/development/contributing/community_roles.md
+++ b/doc/development/contributing/community_roles.md
@@ -4,8 +4,8 @@ GitLab community members and their privileges/responsibilities.
 
 | Roles | Responsibilities | Requirements |
 |-------|------------------|--------------|
-| Maintainer | Accepts merge requests on several GitLab projects | Added to the [team page](https://about.gitlab.com/team/). An expert on code reviews and knows the product/code base |
-| Reviewer | Performs code reviews on MRs | Added to the [team page](https://about.gitlab.com/team/) |
+| Maintainer | Accepts merge requests on several GitLab projects | Added to the [team page](https://about.gitlab.com/company/team/). An expert on code reviews and knows the product/code base |
+| Reviewer | Performs code reviews on MRs | Added to the [team page](https://about.gitlab.com/company/team/) |
 | Developer |Has access to GitLab internal infrastructure & issues (e.g. HR-related) | GitLab employee or a Core Team member (with an NDA) |
 | Contributor | Can make contributions to all GitLab public projects | Have a GitLab.com account |
 
diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md
index 59cf5014da4..853882e8642 100644
--- a/doc/development/contributing/index.md
+++ b/doc/development/contributing/index.md
@@ -4,7 +4,7 @@ Thank you for your interest in contributing to GitLab. This guide details how
 to contribute to GitLab in a way that is easy for everyone.
 
 For a first-time step-by-step guide to the contribution process, please see
-["Contributing to GitLab"](https://about.gitlab.com/contributing/).
+["Contributing to GitLab"](https://about.gitlab.com/community/contribute/).
 
 Looking for something to work on? Look for issues with the label [`Accepting merge requests`](#i-want-to-contribute).
 
diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md
index 27c349c03aa..910f9f4bf7a 100644
--- a/doc/development/contributing/issue_workflow.md
+++ b/doc/development/contributing/issue_workflow.md
@@ -1,7 +1,7 @@
 # Workflow labels
 
 To allow for asynchronous issue handling, we use [milestones][milestones-page]
-and [labels][labels-page]. Leads and product managers handle most of the
+and [labels](https://gitlab.com/gitlab-org/gitlab-ce/-/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:
@@ -18,7 +18,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][labels-page].
+[labels page](https://gitlab.com/gitlab-org/gitlab-ce/-/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.
@@ -38,7 +38,7 @@ makes them float to the top, depending on their importance.
 Type labels are always lowercase, and can have any color, besides blue (which is
 already reserved for subject labels).
 
-The descriptions on the [labels page][labels-page] explain what falls under each type label.
+The descriptions on the [labels page](https://gitlab.com/gitlab-org/gitlab-ce/-/labels) explain what falls under each type label.
 
 ## Subject labels
 
@@ -89,7 +89,7 @@ The following team labels are **true** teams per our [organization structure](ht
 - ~Delivery
 - ~Documentation
 
-The descriptions on the [labels page][labels-page] explain what falls under the
+The descriptions on the [labels page](https://gitlab.com/gitlab-org/gitlab-ce/-/labels) explain what falls under the
 responsibility of each team.
 
 Within those team labels, we also have the ~backend and ~frontend labels to
@@ -500,7 +500,6 @@ A recent example of this was the issue for
 
 [Return to Contributing documentation](index.md)
 
-[labels-page]: https://gitlab.com/gitlab-org/gitlab-ce/labels
 [ce-tracker]: https://gitlab.com/gitlab-org/gitlab-ce/issues
 [ee-tracker]: https://gitlab.com/gitlab-org/gitlab-ee/issues
 [inferred-labels]: https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/155
diff --git a/doc/development/contributing/style_guides.md b/doc/development/contributing/style_guides.md
index 87e61a7476f..5c6ea1f469d 100644
--- a/doc/development/contributing/style_guides.md
+++ b/doc/development/contributing/style_guides.md
@@ -1,11 +1,11 @@
 # Style guides
 
-1. [Ruby](https://github.com/bbatsov/ruby-style-guide).
+1. [Ruby](https://github.com/rubocop-hq/ruby-style-guide).
    Important sections include [Source Code Layout][rss-source] and
    [Naming][rss-naming]. Use:
    - multi-line method chaining style **Option A**: dot `.` on the second line
    - string literal quoting style **Option A**: single quoted by default
-1. [Rails](https://github.com/bbatsov/rails-style-guide)
+1. [Rails](https://github.com/rubocop-hq/rails-style-guide)
 1. [Newlines styleguide][newlines-styleguide]
 1. [Testing][testing]
 1. [JavaScript styleguide][js-styleguide]
@@ -13,7 +13,7 @@
 1. [Shell commands (Ruby)](../shell_commands.md) created by GitLab
    contributors to enhance security
 1. [Database Migrations](../migration_style_guide.md)
-1. [Markdown](http://www.cirosantilli.com/markdown-styleguide)
+1. [Markdown](https://cirosantilli.com/markdown-style-guide/)
 1. [Documentation styleguide](../documentation/styleguide.md)
 1. Interface text should be written subjectively instead of objectively. It
    should be the GitLab core team addressing a person. It should be written in
@@ -25,7 +25,7 @@
 1. [Python](../python_guide/index.md)
 
 This is also the style used by linting tools such as
-[RuboCop](https://github.com/bbatsov/rubocop) and [Hound CI](https://houndci.com).
+[RuboCop](https://github.com/rubocop-hq/rubocop) and [Hound CI](https://houndci.com).
 
 ---
 
diff --git a/doc/development/documentation/styleguide.md b/doc/development/documentation/styleguide.md
index 7127efb7405..d9cea0614c3 100644
--- a/doc/development/documentation/styleguide.md
+++ b/doc/development/documentation/styleguide.md
@@ -518,7 +518,7 @@ you have your MR reviewed and approved by a technical writer.
 ```html
 leave a blank line here
 <div class="video-fallback">
-  See the video: [Video title](https://www.youtube.com/watch?v=MqL6BMOySIQ).
+  See the video: <a href="https://www.youtube.com/watch?v=MqL6BMOySIQ">Video title</a>.
 </div>
 <figure class="video-container">
   <iframe src="https://www.youtube.com/embed/MqL6BMOySIQ" frameborder="0" allowfullscreen="true"> </iframe>
@@ -529,7 +529,7 @@ leave a blank line here
 This is how it renders on docs.gitlab.com:
 
 <div class="video-fallback">
-  See the video: [What is GitLab](https://www.youtube.com/watch?v=enMumwvLAug).
+  See the video: <a href="https://www.youtube.com/watch?v=enMumwvLAug">What is GitLab</a>.
 </div>
 <figure class="video-container">
   <iframe src="https://www.youtube.com/embed/MqL6BMOySIQ" frameborder="0" allowfullscreen="true"> </iframe>
diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md
index dc17b59a9a0..7131b717353 100644
--- a/doc/development/ee_features.md
+++ b/doc/development/ee_features.md
@@ -182,52 +182,52 @@ There are a few gotchas with it:
   pattern](https://en.wikipedia.org/wiki/Template_method_pattern).
   For example, given this base:
 
-    ```ruby
-      class Base
-        def execute
-          return unless enabled?
+  ```ruby
+    class Base
+      def execute
+        return unless enabled?
 
-          # ...
-          # ...
-        end
+        # ...
+        # ...
       end
-    ```
+    end
+  ```
 
-    Instead of just overriding `Base#execute`, we should update it and extract
-    the behaviour into another method:
+  Instead of just overriding `Base#execute`, we should update it and extract
+  the behaviour into another method:
 
-    ```ruby
-      class Base
-        def execute
-          return unless enabled?
+  ```ruby
+    class Base
+      def execute
+        return unless enabled?
 
-          do_something
-        end
+        do_something
+      end
 
-        private
+      private
 
-        def do_something
-          # ...
-          # ...
-        end
+      def do_something
+        # ...
+        # ...
       end
-    ```
+    end
+  ```
 
-    Then we're free to override that `do_something` without worrying about the
-    guards:
+  Then we're free to override that `do_something` without worrying about the
+  guards:
 
-    ```ruby
-      module EE::Base
-        extend ::Gitlab::Utils::Override
+  ```ruby
+    module EE::Base
+      extend ::Gitlab::Utils::Override
 
-        override :do_something
-        def do_something
-          # Follow the above pattern to call super and extend it
-        end
+      override :do_something
+      def do_something
+        # Follow the above pattern to call super and extend it
       end
-    ```
+    end
+  ```
 
-    This would require updating CE first, or make sure this is back ported to CE.
+  This would require updating CE first, or make sure this is back ported to CE.
 
 When prepending, place them in the `ee/` specific sub-directory, and
 wrap class or module in `module EE` to avoid naming conflicts.
@@ -1038,8 +1038,8 @@ to avoid conflicts during CE to EE merge.
 Until the work completed to merge the ce and ee codebases, which is tracked on [epic &802](https://gitlab.com/groups/gitlab-org/-/epics/802), there exists times in which some changes for EE require specific changes to the CE
 code base.  Examples of backports include the following:
 
-* Features intended or originally built for EE that are later decided to move to CE
-* Sometimes some code in CE may impact the EE feature
+- Features intended or originally built for EE that are later decided to move to CE
+- Sometimes some code in CE may impact the EE feature
 
 Here is a workflow to make sure those changes end up backported safely into CE too.
 
diff --git a/doc/development/emails.md b/doc/development/emails.md
index 8baf343b133..e6af075a282 100644
--- a/doc/development/emails.md
+++ b/doc/development/emails.md
@@ -26,57 +26,57 @@ See the [Rails guides] for more info.
    feature and fill in the details for your specific IMAP server and email
    account:
 
-    Configuration for Gmail / Google Apps, assumes mailbox gitlab-incoming@gmail.com
-
-    ```yaml
-    incoming_email:
-      enabled: true
-
-      # The email address including the `%{key}` placeholder that will be replaced to reference the item being replied to.
-      # The placeholder can be omitted but if present, it must appear in the "user" part of the address (before the `@`).
-      address: "gitlab-incoming+%{key}@gmail.com"
-
-      # Email account username
-      # With third party providers, this is usually the full email address.
-      # With self-hosted email servers, this is usually the user part of the email address.
-      user: "gitlab-incoming@gmail.com"
-      # Email account password
-      password: "[REDACTED]"
-
-      # IMAP server host
-      host: "imap.gmail.com"
-      # IMAP server port
-      port: 993
-      # Whether the IMAP server uses SSL
-      ssl: true
-      # Whether the IMAP server uses StartTLS
-      start_tls: false
-
-      # The mailbox where incoming mail will end up. Usually "inbox".
-      mailbox: "inbox"
-      # The IDLE command timeout.
-      idle_timeout: 60
-    ```
-
-    As mentioned, the part after `+` is ignored, and this will end up in the mailbox for `gitlab-incoming@gmail.com`.
+   Configuration for Gmail / Google Apps, assumes mailbox `gitlab-incoming@gmail.com`:
+
+   ```yaml
+   incoming_email:
+     enabled: true
+
+     # The email address including the `%{key}` placeholder that will be replaced to reference the item being replied to.
+     # The placeholder can be omitted but if present, it must appear in the "user" part of the address (before the `@`).
+     address: "gitlab-incoming+%{key}@gmail.com"
+
+     # Email account username
+     # With third party providers, this is usually the full email address.
+     # With self-hosted email servers, this is usually the user part of the email address.
+     user: "gitlab-incoming@gmail.com"
+     # Email account password
+     password: "[REDACTED]"
+
+     # IMAP server host
+     host: "imap.gmail.com"
+     # IMAP server port
+     port: 993
+     # Whether the IMAP server uses SSL
+     ssl: true
+     # Whether the IMAP server uses StartTLS
+     start_tls: false
+
+     # The mailbox where incoming mail will end up. Usually "inbox".
+     mailbox: "inbox"
+     # The IDLE command timeout.
+     idle_timeout: 60
+   ```
+
+   As mentioned, the part after `+` is ignored, and this will end up in the mailbox for `gitlab-incoming@gmail.com`.
 
 1. Run this command in the GitLab root directory to launch `mail_room`:
 
-    ```sh
-    bundle exec mail_room -q -c config/mail_room.yml
-    ```
+   ```sh
+   bundle exec mail_room -q -c config/mail_room.yml
+   ```
 
 1. Verify that everything is configured correctly:
 
-    ```sh
-    bundle exec rake gitlab:incoming_email:check RAILS_ENV=development
-    ```
+   ```sh
+   bundle exec rake gitlab:incoming_email:check RAILS_ENV=development
+   ```
 
 1. Reply by email should now be working.
 
 ## Email namespace
 
-As of GitLab 11.7, we support a new format for email handler addresses.  This was done to 
+As of GitLab 11.7, we support a new format for email handler addresses.  This was done to
 support catch-all mailboxes.
 
 If you need to implement a feature which requires a new email handler, follow these rules
@@ -91,10 +91,10 @@ for the format of the email key:
 
 Examples of valid email keys:
 
- - `gitlab-org-gitlab-ce-20-Author_Token12345678-issue` (create a new issue)
- - `gitlab-org-gitlab-ce-20-Author_Token12345678-merge-request` (create a new merge request)
- - `1234567890abcdef1234567890abcdef-unsubscribe` (unsubscribe from a conversation)
- - `1234567890abcdef1234567890abcdef` (reply to a conversation)
+- `gitlab-org-gitlab-ce-20-Author_Token12345678-issue` (create a new issue)
+- `gitlab-org-gitlab-ce-20-Author_Token12345678-merge-request` (create a new merge request)
+- `1234567890abcdef1234567890abcdef-unsubscribe` (unsubscribe from a conversation)
+- `1234567890abcdef1234567890abcdef` (reply to a conversation)
 
 Please note that the action `-issue-` is used in GitLab Premium as the handler for the Service Desk feature.
 
@@ -103,10 +103,10 @@ Please note that the action `-issue-` is used in GitLab Premium as the handler f
 Although we continue to support the older legacy format, no new features should use a legacy format.
 These are the only valid legacy formats for an email handler:
 
- - `path/to/project+namespace`
- - `path/to/project+namespace+action`
- - `namespace`
- - `namespace+action`
+- `path/to/project+namespace`
+- `path/to/project+namespace+action`
+- `namespace`
+- `namespace+action`
 
 Please note that `path/to/project` is used in GitLab Premium as handler for the Service Desk feature.
 
diff --git a/doc/development/fe_guide/architecture.md b/doc/development/fe_guide/architecture.md
index c67389b169e..49b74b5ebcf 100644
--- a/doc/development/fe_guide/architecture.md
+++ b/doc/development/fe_guide/architecture.md
@@ -11,7 +11,7 @@ Architectural decisions should be accessible to everyone, so please document
 them in the relevant Merge Request discussion or by updating our documentation
 when appropriate.
 
-You can find the Frontend Architecture experts on the [team page](https://about.gitlab.com/team).
+You can find the Frontend Architecture experts on the [team page](https://about.gitlab.com/company/team).
 
 ## Examples
 
diff --git a/doc/development/fe_guide/emojis.md b/doc/development/fe_guide/emojis.md
index 38794c47965..6d324d4c4a0 100644
--- a/doc/development/fe_guide/emojis.md
+++ b/doc/development/fe_guide/emojis.md
@@ -3,10 +3,10 @@
 GitLab supports native unicode emojis and fallsback to image-based emojis selectively
 when your platform does not support it.
 
-# How to update Emojis
+## How to update Emojis
 
  1. Update the `gemojione` gem
- 1. Update `fixtures/emojis/index.json` from [Gemojione](https://github.com/jonathanwiesel/gemojione/blob/master/config/index.json).
+ 1. Update `fixtures/emojis/index.json` from [Gemojione](https://github.com/bonusly/gemojione/blob/master/config/index.json).
     In the future, we could grab the file directly from the gem.
     We should probably make a PR on the Gemojione project to get access to
     all emojis after being parsed or just a raw path to the `json` file itself.
diff --git a/doc/development/fe_guide/graphql.md b/doc/development/fe_guide/graphql.md
index 9fcd32fddfa..55b719227e5 100644
--- a/doc/development/fe_guide/graphql.md
+++ b/doc/development/fe_guide/graphql.md
@@ -55,7 +55,6 @@ It is possible to manage an application state with Apollo by passing
 in a resolvers object when creating the default client. The default state can be set by writing
 to the cache after setting up the default client.
 
-
 ```javascript
 import Vue from 'vue';
 import VueApollo from 'vue-apollo';
@@ -115,13 +114,12 @@ defaultClient.query(query)
   .then(result => console.log(result));
 ```
 
-Read more about the [Apollo] client in the [Apollo documentation][apollo-client-docs].
+Read more about the [Apollo] client in the [Apollo documentation](https://www.apollographql.com/docs/tutorial/client/).
 
 [Apollo]: https://www.apollographql.com/
 [vue-apollo]: https://github.com/Akryum/vue-apollo/
 [vue-apollo-docs]: https://akryum.github.io/vue-apollo/
 [feature-flags]: ../feature_flags.md
 [default-client]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/lib/graphql.js
-[apollo-client-docs]: https://www.apollographql.com/docs/tutorial/client.html
 [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/gotchas.md b/doc/development/gotchas.md
index 1b9ebb50c29..13dda17bb7d 100644
--- a/doc/development/gotchas.md
+++ b/doc/development/gotchas.md
@@ -101,10 +101,10 @@ end
   in a prepended module, which is very likely the case in EE. We could see
   error like this:
 
-    ```
-    1.1) Failure/Error: expect_any_instance_of(ApplicationSetting).to receive_messages(messages)
-         Using `any_instance` to stub a method (elasticsearch_indexing) that has been defined on a prepended module (EE::ApplicationSetting) is not supported.
-    ```
+  ```
+  1.1) Failure/Error: expect_any_instance_of(ApplicationSetting).to receive_messages(messages)
+       Using `any_instance` to stub a method (elasticsearch_indexing) that has been defined on a prepended module (EE::ApplicationSetting) is not supported.
+  ```
 
 ### Alternative: `expect_next_instance_of`
 
diff --git a/doc/development/integrations/jira_connect.md b/doc/development/integrations/jira_connect.md
index 5bf43d320c6..9ba3b922fd8 100644
--- a/doc/development/integrations/jira_connect.md
+++ b/doc/development/integrations/jira_connect.md
@@ -4,7 +4,7 @@ The following are required to install and test the app:
 
 1. A Jira Cloud instance
 
-   Atlassian provides free instances for development and testing. [Click here to sign up](http://go.atlassian.com/cloud-dev).
+   Atlassian provides free instances for development and testing. [Click here to sign up](https://developer.atlassian.com/platform/marketplace/getting-started/#free-developer-instances-to-build-and-test-your-app).
 
 1. A GitLab instance available over the internet
 
@@ -15,7 +15,7 @@ The following are required to install and test the app:
 
 > This feature is currently behind the `:jira_connect_app` feature flag
 
-# Installing the app in Jira
+## Installing the app in Jira
 
 1. Enable Jira development mode to install apps that are not from the Atlassian Marketplace
 
diff --git a/doc/development/licensed_feature_availability.md b/doc/development/licensed_feature_availability.md
index 7d0a6f6acda..80ec7b8c0cf 100644
--- a/doc/development/licensed_feature_availability.md
+++ b/doc/development/licensed_feature_availability.md
@@ -1,18 +1,18 @@
 # Licensed feature availability **(STARTER)**
 
-As of GitLab 9.4, we've been supporting a simplified version of licensed 
-feature availability checks via `ee/app/models/license.rb`, both for 
+As of GitLab 9.4, we've been supporting a simplified version of licensed
+feature availability checks via `ee/app/models/license.rb`, both for
 on-premise or GitLab.com plans and features.
 
 ## Restricting features scoped by namespaces or projects
 
 GitLab.com plans are persisted on user groups and namespaces, therefore, if you're adding a
-feature such as [Related issues](../user/project/issues/related_issues.md) or 
-[Service desk](../user/project/service_desk.md), 
+feature such as [Related issues](../user/project/issues/related_issues.md) or
+[Service desk](../user/project/service_desk.md),
 it should be restricted on namespace scope.
 
-1. Add the feature symbol on `EES_FEATURES`, `EEP_FEATURES` or `EEU_FEATURES` constants in 
-  `ee/app/models/license.rb`. Note on `ee/app/models/ee/namespace.rb` that _Bronze_ GitLab.com 
+1. Add the feature symbol on `EES_FEATURES`, `EEP_FEATURES` or `EEU_FEATURES` constants in
+  `ee/app/models/license.rb`. Note on `ee/app/models/ee/namespace.rb` that _Bronze_ GitLab.com
   features maps to on-premise _EES_, _Silver_ to _EEP_ and _Gold_ to _EEU_.
 2. Check using:
 
@@ -22,12 +22,12 @@ project.feature_available?(:feature_symbol)
 
 ## Restricting global features (instance)
 
-However, for features such as [Geo](../administration/geo/replication/index.md) and 
-[Load balancing](../administration/database_load_balancing.md), which cannot be restricted 
-to only a subset of projects or namespaces, the check will be made directly in 
+However, for features such as [Geo](../administration/geo/replication/index.md) and
+[Load balancing](../administration/database_load_balancing.md), which cannot be restricted
+to only a subset of projects or namespaces, the check will be made directly in
 the instance license.
 
-1. Add the feature symbol on `EES_FEATURES`, `EEP_FEATURES` or `EEU_FEATURES` constants in 
+1. Add the feature symbol on `EES_FEATURES`, `EEP_FEATURES` or `EEU_FEATURES` constants in
   `ee/app/models/license.rb`.
 2. Add the same feature symbol to `GLOBAL_FEATURES`
 3. Check using:
diff --git a/doc/development/logging.md b/doc/development/logging.md
index d61441813b2..4f63c84fc0e 100644
--- a/doc/development/logging.md
+++ b/doc/development/logging.md
@@ -30,8 +30,8 @@ Completed 200 OK in 166ms (Views: 117.4ms | ActiveRecord: 27.2ms)
 These logs suffer from a number of problems:
 
 1. They often lack timestamps or other contextual information (e.g. project ID, user)
-2. They may span multiple lines, which make them hard to find via Elasticsearch.
-3. They lack a common structure, which make them hard to parse by log
+1. They may span multiple lines, which make them hard to find via Elasticsearch.
+1. They lack a common structure, which make them hard to parse by log
    forwarders, such as Logstash or Fluentd. This also makes them hard to
    search.
 
@@ -67,46 +67,46 @@ importer progresses. Here's what to do:
    make it easy for people to search pertinent logs in one place. For
    example, `geo.log` contains all logs pertaining to GitLab Geo.
    To create a new file:
-    1. Choose a filename (e.g. `importer_json.log`).
-    1. Create a new subclass of `Gitlab::JsonLogger`:
-
-        ```ruby
-        module Gitlab
-          module Import
-            class Logger < ::Gitlab::JsonLogger
-              def self.file_name_noext
-                'importer'
-              end
+   1. Choose a filename (e.g. `importer_json.log`).
+   1. Create a new subclass of `Gitlab::JsonLogger`:
+
+      ```ruby
+      module Gitlab
+        module Import
+          class Logger < ::Gitlab::JsonLogger
+            def self.file_name_noext
+              'importer'
             end
-           end
-        end
-        ```
+          end
+         end
+      end
+      ```
 
-    1. In your class where you want to log, you might initialize the logger as an instance variable:
+   1. In your class where you want to log, you might initialize the logger as an instance variable:
 
-        ```ruby
-        attr_accessor :logger
+      ```ruby
+      attr_accessor :logger
 
-        def initialize
-          @logger = Gitlab::Import::Logger.build
-        end
-        ```
+      def initialize
+        @logger = Gitlab::Import::Logger.build
+      end
+      ```
 
-        Note that it's useful to memoize this because creating a new logger
-        each time you log will open a file, adding unnecessary overhead.
+      Note that it's useful to memoize this because creating a new logger
+      each time you log will open a file, adding unnecessary overhead.
 
 1. Now insert log messages into your code. When adding logs,
    make sure to include all the context as key-value pairs:
 
-    ```ruby
-    # BAD
-    logger.info("Unable to create project #{project.id}")
-    ```
+   ```ruby
+   # BAD
+   logger.info("Unable to create project #{project.id}")
+   ```
 
-    ```ruby
-    # GOOD
-    logger.info(message: "Unable to create project", project_id: project.id)
-    ```
+   ```ruby
+   # GOOD
+   logger.info(message: "Unable to create project", project_id: project.id)
+   ```
 
 1. Be sure to create a common base structure of your log messages. For example,
    all messages might have `current_user_id` and `project_id` to make it easier
@@ -116,16 +116,16 @@ importer progresses. Here's what to do:
    logs properly if you [mix integer and string
    types](https://www.elastic.co/guide/en/elasticsearch/guide/current/mapping.html#_avoiding_type_gotchas):
 
-    ```ruby
-    # BAD
-    logger.info(message: "Import error", error: 1)
-    logger.info(message: "Import error", error: "I/O failure")
-    ```
+   ```ruby
+   # BAD
+   logger.info(message: "Import error", error: 1)
+   logger.info(message: "Import error", error: "I/O failure")
+   ```
 
-    ```ruby
-    # GOOD
-    logger.info(message: "Import error", error_code: 1, error: "I/O failure")
-    ```
+   ```ruby
+   # GOOD
+   logger.info(message: "Import error", error_code: 1, error: "I/O failure")
+   ```
 
 ## Additional steps with new log files
 
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md
index 9b26f691b55..0c7601b415e 100644
--- a/doc/development/migration_style_guide.md
+++ b/doc/development/migration_style_guide.md
@@ -21,7 +21,7 @@ When downtime is necessary the migration has to be approved by:
 1. A Database Specialist
 
 An up-to-date list of people holding these titles can be found at
-<https://about.gitlab.com/team/>.
+<https://about.gitlab.com/company/team/>.
 
 When writing your migrations, also consider that databases might have stale data
 or inconsistencies and guard for that. Try to make as few assumptions as
diff --git a/doc/development/new_fe_guide/development/components.md b/doc/development/new_fe_guide/development/components.md
index 963ce53423b..cebdc87eab9 100644
--- a/doc/development/new_fe_guide/development/components.md
+++ b/doc/development/new_fe_guide/development/components.md
@@ -13,7 +13,7 @@ D3 is very popular across many projects outside of GitLab:
 
 - [The New York Times](https://archive.nytimes.com/www.nytimes.com/interactive/2012/02/13/us/politics/2013-budget-proposal-graphic.html)
 - [plot.ly](https://plot.ly/)
-- [Droptask](https://www.droptask.com/)
+- [Droptask](https://www.ayoa.com/previously-droptask/)
 
 Within GitLab, D3 has been used for the following notable features
 
diff --git a/doc/development/new_fe_guide/development/performance.md b/doc/development/new_fe_guide/development/performance.md
index 640a8d64176..c54b8305991 100644
--- a/doc/development/new_fe_guide/development/performance.md
+++ b/doc/development/new_fe_guide/development/performance.md
@@ -2,10 +2,10 @@
 
 ## Monitoring
 
-We have a performance dashboard available in one of our [grafana instances](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://sitespeed.io) every 6 hours. These changes are displayed after a set number of pages are aggregated.
+We have a performance dashboard available in one of our [grafana instances](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://www.sitespeed.io/) every 6 hours. These changes are displayed after a set number of pages are aggregated.
 
 These pages can be found inside a text file in the gitlab-build-images [repository](https://gitlab.com/gitlab-org/gitlab-build-images) called [gitlab.txt](https://gitlab.com/gitlab-org/gitlab-build-images/blob/master/scripts/gitlab.txt)
-Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing urls of pages from this text file. Please have a [frontend monitoring expert](https://about.gitlab.com/team) review your changes before assigning to a maintainer of the `gitlab-build-images` project. The changes will go live on the next scheduled run after the changes are merged into `master`.
+Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing urls of pages from this text file. Please have a [frontend monitoring expert](https://about.gitlab.com/company/team) review your changes before assigning to a maintainer of the `gitlab-build-images` project. The changes will go live on the next scheduled run after the changes are merged into `master`.
 
 There are 3 recommended high impact metrics to review on each page:
 
diff --git a/doc/development/new_fe_guide/development/testing.md b/doc/development/new_fe_guide/development/testing.md
index 8441089418e..2b62c2a41fe 100644
--- a/doc/development/new_fe_guide/development/testing.md
+++ b/doc/development/new_fe_guide/development/testing.md
@@ -261,7 +261,7 @@ scenario 'successfully', :js do
 end
 ```
 
-The steps of each test are written using capybara methods ([documentation](http://www.rubydoc.info/gems/capybara/2.15.1)).
+The steps of each test are written using capybara methods ([documentation](https://www.rubydoc.info/gems/capybara/2.15.1)).
 
 Bear in mind <abbr title="XMLHttpRequest">XHR</abbr> calls might require you to use `wait_for_requests` in between steps, like so:
 
@@ -277,7 +277,7 @@ expect(page).not_to have_selector('.card')
 
 ### Vuex Helper: `testAction`
 
-We have a helper available to make testing actions easier, as per [official documentation](https://vuex.vuejs.org/en/testing.html):
+We have a helper available to make testing actions easier, as per [official documentation](https://vuex.vuejs.org/guide/testing.html):
 
 ```
 testAction(
diff --git a/doc/development/new_fe_guide/style/html.md b/doc/development/new_fe_guide/style/html.md
index e8c9c2ccebf..1445da3f0e1 100644
--- a/doc/development/new_fe_guide/style/html.md
+++ b/doc/development/new_fe_guide/style/html.md
@@ -16,7 +16,7 @@ Button tags requires a `type` attribute according to the [W3C HTML specification
 
 ### Button role
 
-If an HTML element has an `onClick` handler but is not a button, it should have `role="button"`. This is [more accessible](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_button_role).
+If an HTML element has an `onClick` handler but is not a button, it should have `role="button"`. This is [more accessible](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role).
 
 ```html
 // bad
diff --git a/doc/development/newlines_styleguide.md b/doc/development/newlines_styleguide.md
index 5f7210020b6..a13adc2f13e 100644
--- a/doc/development/newlines_styleguide.md
+++ b/doc/development/newlines_styleguide.md
@@ -11,7 +11,7 @@ def method
 
   issue.save
 
-  render json: issue 
+  render json: issue
 end
 ```
 
@@ -21,7 +21,7 @@ def method
   issue = Issue.new
   issue.save
 
-  render json: issue 
+  render json: issue
 end
 ```
 
diff --git a/doc/development/packages.md b/doc/development/packages.md
index 418efd9eef9..08aa0b08525 100644
--- a/doc/development/packages.md
+++ b/doc/development/packages.md
@@ -5,11 +5,11 @@ This document will guide you through adding another [package management system](
 See already supported package types in [Packages documentation](../administration/packages.md)
 
 Since GitLab packages' UI is pretty generic, it is possible to add new
-package system support by solely backend changes. This guide is superficial and does 
-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: 
+package system support by solely backend changes. This guide is superficial and does
+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). 
+- [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)
 
@@ -17,44 +17,44 @@ by looking at existing merge requests with Maven and NPM support:
 
 The existing database model requires the following:
 
-- Every package belongs to a project. 
+- Every package belongs to a project.
 - Every package file belongs to a package.
 - A package can have one or more package files.
 - The package model is based on storing information about the package and its version.
 
 ## API endpoints
 
-Package systems work with GitLab via API. For example `ee/lib/api/npm_packages.rb` 
-implements API endpoints to work with NPM clients. So, the first thing to do is to 
-add a new `ee/lib/api/your_name_packages.rb` file with API endpoints that are 
-necessary to make the package system client to work. Usually that means having 
-endpoints like: 
+Package systems work with GitLab via API. For example `ee/lib/api/npm_packages.rb`
+implements API endpoints to work with NPM clients. So, the first thing to do is to
+add a new `ee/lib/api/your_name_packages.rb` file with API endpoints that are
+necessary to make the package system client to work. Usually that means having
+endpoints like:
 
 - GET package information.
 - GET package file content.
 - PUT upload package.
 
 Since the packages belong to a project, it's expected to have project-level endpoint
-for uploading and downloading them. For example: 
+for uploading and downloading them. For example:
 
 ```
 GET https://gitlab.com/api/v4/projects/<your_project_id>/packages/npm/
 PUT https://gitlab.com/api/v4/projects/<your_project_id>/packages/npm/
 ```
 
-Group-level and instance-level endpoints are good to have but are optional. 
+Group-level and instance-level endpoints are good to have but are optional.
 
 NOTE: **Note:**
-To avoid name conflict for instance-level endpoints we use 
+To avoid name conflict for instance-level endpoints we use
 [the package naming convention](../user/project/packages/npm_registry.md#package-naming-convention)
 
 ## Configuration
 
-GitLab has a `packages` section in its configuration file (`gitlab.rb`). 
-It applies to all package systems supported by GitLab. Usually you don't need 
-to add anything there. 
+GitLab has a `packages` section in its configuration file (`gitlab.rb`).
+It applies to all package systems supported by GitLab. Usually you don't need
+to add anything there.
 
-Packages can be configured to use object storage, therefore your code must support it. 
+Packages can be configured to use object storage, therefore your code must support it.
 
 ## Database
 
@@ -63,6 +63,6 @@ Every time you upload a new package, you can either create a new record of `Pack
 or add files to existing record. `PackageFile` should be able to store all file-related
 information like the file `name`, `side`, `sha1`, etc.
 
-If there is specific data necessary to be stored for only one package system support, 
-consider creating a separate metadata model. See `packages_maven_metadata` table 
+If there is specific data necessary to be stored for only one package system support,
+consider creating a separate metadata model. See `packages_maven_metadata` table
 and `Packages::MavenMetadatum` model as example for package specific data.
diff --git a/doc/development/profiling.md b/doc/development/profiling.md
index 795523b82aa..e1d1d2e33fa 100644
--- a/doc/development/profiling.md
+++ b/doc/development/profiling.md
@@ -95,7 +95,9 @@ Sherlock is a custom profiling tool built into GitLab. Sherlock is _only_
 available when running GitLab in development mode _and_ when setting the
 environment variable `ENABLE_SHERLOCK` to a non empty value. For example:
 
-    ENABLE_SHERLOCK=1 bundle exec rails s
+```sh
+ENABLE_SHERLOCK=1 bundle exec rails s
+```
 
 Recorded transactions can be found by navigating to `/sherlock/transactions`.
 
@@ -106,7 +108,9 @@ Bullet adds quite a bit of logging noise it's disabled by default. To enable
 Bullet, set the environment variable `ENABLE_BULLET` to a non-empty value before
 starting GitLab. For example:
 
-    ENABLE_BULLET=true bundle exec rails s
+```sh
+ENABLE_BULLET=true bundle exec rails s
+```
 
 Bullet will log query problems to both the Rails log as well as the Chrome
 console.
diff --git a/doc/development/python_guide/index.md b/doc/development/python_guide/index.md
index 6025dc9ebf2..a80bee27d4a 100644
--- a/doc/development/python_guide/index.md
+++ b/doc/development/python_guide/index.md
@@ -36,7 +36,7 @@ You can read more about it in: <https://github.com/pyenv/pyenv-installer#prerequ
 Pyenv installation will add required changes to Bash. If you use a different shell,
 check for any additional steps required for it.
 
-For Fish, you can install a plugin for [Fisherman](https://github.com/fisherman/fisherman):
+For Fish, you can install a plugin for [Fisher](https://github.com/jorgebucaran/fisher):
 
 ```bash
 fisher add fisherman/pyenv
@@ -76,4 +76,3 @@ pipenv shell
 
 After running that command, you can run GitLab on the same shell and it will be using the Python and dependencies
 installed from the `pipenv install` command.
-
diff --git a/doc/development/query_recorder.md b/doc/development/query_recorder.md
index 2167ed57428..a6b60149ea4 100644
--- a/doc/development/query_recorder.md
+++ b/doc/development/query_recorder.md
@@ -1,6 +1,6 @@
 # QueryRecorder
 
-QueryRecorder is a tool for detecting the [N+1 queries problem](http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations) from tests.
+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)
 
@@ -86,4 +86,4 @@ QueryRecorder SQL: SELECT COUNT(*) FROM "issues" WHERE "issues"."deleted_at" IS
 
 - [Bullet](profiling.md#Bullet) For finding `N+1` query problems
 - [Performance guidelines](performance.md)
-- [Merge request performance guidelines](merge_request_performance_guidelines.md#query-counts)
\ No newline at end of file
+- [Merge request performance guidelines](merge_request_performance_guidelines.md#query-counts)
diff --git a/doc/development/routing.md b/doc/development/routing.md
index e9c0ad8d4e8..a25eb48b73c 100644
--- a/doc/development/routing.md
+++ b/doc/development/routing.md
@@ -7,11 +7,15 @@ support subgroups, GitLab project and group routes use the wildcard
 character to match project and group routes. For example, we might have
 a path such as:
 
-    /gitlab-com/customer-success/north-america/west/customerA
+```
+/gitlab-com/customer-success/north-america/west/customerA
+```
 
 However, paths can be ambiguous. Consider the following example:
 
-    /gitlab-com/edit
+```
+/gitlab-com/edit
+```
 
 It's ambiguous whether there is a subgroup named `edit` or whether
 this is a special endpoint to edit the `gitlab-com` group.
@@ -25,8 +29,10 @@ number of [reserved names](../user/reserved_names.md).
 
 We have a number of global routes. For example:
 
-    /-/health
-    /-/metrics
+```
+/-/health
+/-/metrics
+```
 
 ## Group routes
 
@@ -34,10 +40,12 @@ Every group route must be under the `/-/` scope.
 
 Examples:
 
-    gitlab-org/-/edit
-    gitlab-org/-/activity
-    gitlab-org/-/security/dashboard
-    gitlab-org/serverless/-/activity
+```
+gitlab-org/-/edit
+gitlab-org/-/activity
+gitlab-org/-/security/dashboard
+gitlab-org/serverless/-/activity
+```
 
 To achieve that, use the `scope '-'` method.
 
@@ -48,10 +56,12 @@ client or other software requires something different.
 
 Examples:
 
-    gitlab-org/gitlab-ce/-/activity
-    gitlab-org/gitlab-ce/-/jobs/123
-    gitlab-org/gitlab-ce/-/settings/repository
-    gitlab-org/serverless/runtimes/-/settings/repository
+```
+gitlab-org/gitlab-ce/-/activity
+gitlab-org/gitlab-ce/-/jobs/123
+gitlab-org/gitlab-ce/-/settings/repository
+gitlab-org/serverless/runtimes/-/settings/repository
+```
 
 Currently, only some project routes are placed under the `/-/` scope. However,
 you can help us migrate more of them! To migrate project routes:
diff --git a/doc/development/sql.md b/doc/development/sql.md
index edeca7fb298..a256fd46c09 100644
--- a/doc/development/sql.md
+++ b/doc/development/sql.md
@@ -94,7 +94,9 @@ on the amount of data indexed).
 To keep naming of these indexes consistent please use the following naming
 pattern:
 
-    index_TABLE_on_COLUMN_trigram
+```
+index_TABLE_on_COLUMN_trigram
+```
 
 For example, a GIN/trigram index for `issues.title` would be called
 `index_issues_on_title_trigram`.
diff --git a/doc/development/testing_guide/index.md b/doc/development/testing_guide/index.md
index c4b18391cb2..aadbea1a540 100644
--- a/doc/development/testing_guide/index.md
+++ b/doc/development/testing_guide/index.md
@@ -11,7 +11,7 @@ importance.
 
 ## Overview
 
-GitLab is built on top of [Ruby on Rails][rails], and we're using [RSpec] for all
+GitLab is built on top of [Ruby on Rails](https://rubyonrails.org/), and we're using [RSpec] for all
 the backend tests, with [Capybara] for end-to-end integration testing.
 On the frontend side, we're using [Karma] and [Jasmine] for JavaScript unit and
 integration testing.
@@ -80,7 +80,6 @@ Everything you should know about how to run end-to-end tests using
 
 [Return to Development documentation](../README.md)
 
-[rails]: http://rubyonrails.org/
 [RSpec]: https://github.com/rspec/rspec-rails#feature-specs
 [Capybara]: https://github.com/teamcapybara/capybara
 [Karma]: http://karma-runner.github.io/
diff --git a/doc/development/understanding_explain_plans.md b/doc/development/understanding_explain_plans.md
index bfbb7be70e3..11aafd7b639 100644
--- a/doc/development/understanding_explain_plans.md
+++ b/doc/development/understanding_explain_plans.md
@@ -654,7 +654,6 @@ and related tools such as:
 - <https://explain.depesz.com/>
 - <http://tatiyants.com/postgres-query-plan-visualization/>
 
-
 ## Producing query plans
 
 There are a few ways to get the output of a query plan. Of course you
diff --git a/doc/development/ux_guide/resources.md b/doc/development/ux_guide/resources.md
index baec235a8dd..ae092246d05 100644
--- a/doc/development/ux_guide/resources.md
+++ b/doc/development/ux_guide/resources.md
@@ -1,5 +1,5 @@
 ---
-redirect_to: 'https://design.gitlab.com/resources/design-resources'
+redirect_to: 'https://design.gitlab.com/resources/design-resources/'
 ---
 
-The content of this document was moved into the [GitLab Design System](https://design.gitlab.com/).
+The content of this document was moved into the [GitLab Design System](https://design.gitlab.com/resources/design-resources/).