From b8e272100415ae1a550a455f4ad091fccb692a1e Mon Sep 17 00:00:00 2001
From: GitLab Bot <gitlab-bot@gitlab.com>
Date: Thu, 19 Nov 2020 00:09:41 +0000
Subject: [PATCH] Add latest changes from gitlab-org/gitlab@master

---
 .../New End To End Test.md                    |  26 ++++
 .../groups/components/group_item.vue          |  30 +++-
 app/assets/javascripts/groups/index.js        |   3 +-
 .../javascripts/groups/store/groups_store.js  |   5 +-
 app/assets/javascripts/groups/store/utils.js  |  27 ++++
 app/finders/ci/commit_statuses_finder.rb      |   2 +-
 app/helpers/user_callouts_helper.rb           |   5 +-
 app/views/groups/_home_panel.html.haml        |   6 +-
 .../groups/_subgroups_and_projects.html.haml  |   2 +-
 app/views/groups/show.html.haml               |   1 +
 .../shared/_new_project_item_select.html.haml |   2 +-
 .../273751-fj-structured-data-for-groups.yml  |   5 +
 .../unreleased/283825-split-button-gap-mr.yml |   5 +
 ...pen-registration-callout-on-gitlab-com.yml |   5 +
 doc/.vale/gitlab/SubstitutionSuggestions.yml  |   1 +
 doc/.vale/gitlab/spelling-exceptions.txt      |   4 +-
 doc/administration/instance_review.md         |   4 +-
 .../gitlab_self_monitoring_project/index.md   |   4 +-
 doc/administration/terraform_state.md         |   2 +-
 doc/api/group_clusters.md                     |   6 +-
 doc/api/instance_clusters.md                  |   6 +-
 doc/api/invitations.md                        |   2 +-
 doc/api/project_clusters.md                   |   4 +-
 doc/ci/yaml/README.md                         | 130 +++++++-----------
 doc/development/experiment_guide/index.md     |  10 +-
 doc/development/logging.md                    |   6 +-
 doc/development/product_analytics/snowplow.md |   2 +-
 .../product_analytics/usage_ping.md           |  36 ++---
 .../incident_management/alert_integrations.md |   2 +-
 doc/topics/autodevops/customize.md            |  66 ++++-----
 doc/topics/autodevops/index.md                |  12 +-
 doc/topics/autodevops/quick_start_guide.md    |  28 ++--
 doc/topics/autodevops/requirements.md         |  12 +-
 doc/topics/autodevops/stages.md               |  16 +--
 doc/topics/autodevops/upgrading_postgresql.md |  14 +-
 doc/user/clusters/applications.md             |  12 +-
 doc/user/clusters/cost_management.md          |   2 +-
 doc/user/clusters/management_project.md       |   8 +-
 doc/user/group/clusters/index.md              |   6 +-
 doc/user/group/epics/index.md                 |   4 +-
 doc/user/project/clusters/add_eks_clusters.md |  29 ++--
 doc/user/project/clusters/add_gke_clusters.md |  12 +-
 doc/user/project/clusters/runbooks/index.md   |   8 +-
 doc/user/project/clusters/serverless/aws.md   |  26 ++--
 doc/user/project/clusters/serverless/index.md |  50 +++----
 doc/user/project/issue_board.md               |  86 +++++++-----
 lib/microsoft_teams/notifier.rb               |  11 +-
 spec/features/groups/show_spec.rb             |  65 +++++++++
 .../finders/ci/commit_statuses_finder_spec.rb |   8 +-
 spec/frontend/groups/components/app_spec.js   |   2 +-
 .../groups/components/group_item_spec.js      |  49 +++++++
 .../groups/store/groups_store_spec.js         |  27 ++--
 spec/frontend/groups/store/utils_spec.js      |  44 ++++++
 spec/helpers/user_callouts_helper_spec.rb     |  17 ++-
 spec/lib/microsoft_teams/notifier_spec.rb     |   4 +-
 .../projects/tags/index.html.haml_spec.rb     |   9 ++
 56 files changed, 619 insertions(+), 351 deletions(-)
 create mode 100644 .gitlab/merge_request_templates/New End To End Test.md
 create mode 100644 app/assets/javascripts/groups/store/utils.js
 create mode 100644 changelogs/unreleased/273751-fj-structured-data-for-groups.yml
 create mode 100644 changelogs/unreleased/283825-split-button-gap-mr.yml
 create mode 100644 changelogs/unreleased/hide-open-registration-callout-on-gitlab-com.yml
 create mode 100644 spec/frontend/groups/store/utils_spec.js

diff --git a/.gitlab/merge_request_templates/New End To End Test.md b/.gitlab/merge_request_templates/New End To End Test.md
new file mode 100644
index 00000000000..9bd7f11d4a5
--- /dev/null
+++ b/.gitlab/merge_request_templates/New End To End Test.md	
@@ -0,0 +1,26 @@
+## Description of the test
+
+<!--
+Please link to the respective test case in the testcases project
+-->
+
+### Check-list
+
+- [ ] Confirm the test has a [`testcase:` tag linking to an existing test case](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/best_practices.html#link-a-test-to-its-test-case-issue) in the test case project.
+- [ ] Note if the test is intended to run in specific scenarios. If a scenario is new, add a link to the MR that adds the new scenario.
+- [ ] Follow the end-to-end tests [style guide](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/style_guide.html) and [best practices](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/best_practices.html).
+- [ ] Use the appropriate [RSpec metadata tag(s)](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/rspec_metadata_tests.html#rspec-metadata-for-end-to-end-tests).
+- [ ] Ensure that a created resource is removed after test execution.
+- [ ] Verify the tags to ensure it runs on the desired test environments.
+- [ ] If this MR has a dependency on another MR, such as a GitLab QA MR, specify the order in which the MRs should be merged.
+- [ ] (If applicable) Create a follow-up issue to document [the special setup](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/running_tests_that_require_special_setup.html) necessary to run the test: ISSUE_LINK 
+
+<!-- Base labels. -->
+/label ~"Quality" ~"QA" ~test
+
+<!-- If the test is addressing a test gap, select a label according to the feature under test, please use just one. -->
+
+/label ~"Quality:test-gap" ~"Quality:EE test gaps"
+
+<!-- Select the appropriate feature label, ~"feature::addition" for tests added for new features, ~"feature::maintenance" for tests added for existing features -->
+/label ~"feature::addition" ~"feature::maintenance" 
diff --git a/app/assets/javascripts/groups/components/group_item.vue b/app/assets/javascripts/groups/components/group_item.vue
index 6e99b6ad4fa..ef58b93c049 100644
--- a/app/assets/javascripts/groups/components/group_item.vue
+++ b/app/assets/javascripts/groups/components/group_item.vue
@@ -74,6 +74,9 @@ export default {
     visibilityTooltip() {
       return GROUP_VISIBILITY_TYPE[this.group.visibility];
     },
+    microdata() {
+      return this.group.microdata || {};
+    },
   },
   mounted() {
     if (this.group.name === 'Learn GitLab') {
@@ -99,7 +102,15 @@ export default {
 </script>
 
 <template>
-  <li :id="groupDomId" :class="rowClass" class="group-row" @click.stop="onClickRowGroup">
+  <li
+    :id="groupDomId"
+    :class="rowClass"
+    class="group-row"
+    :itemprop="microdata.itemprop"
+    :itemtype="microdata.itemtype"
+    :itemscope="microdata.itemscope"
+    @click.stop="onClickRowGroup"
+  >
     <div
       :class="{ 'project-row-contents': !isGroup }"
       class="group-row-contents d-flex align-items-center py-2 pr-3"
@@ -118,7 +129,13 @@ export default {
         class="avatar-container rect-avatar s32 d-none flex-grow-0 flex-shrink-0 "
       >
         <a :href="group.relativePath" class="no-expand">
-          <img v-if="hasAvatar" :src="group.avatarUrl" class="avatar s40" />
+          <img
+            v-if="hasAvatar"
+            :src="group.avatarUrl"
+            data-testid="group-avatar"
+            class="avatar s40"
+            :itemprop="microdata.imageItemprop"
+          />
           <identicon v-else :entity-id="group.id" :entity-name="group.name" size-class="s40" />
         </a>
       </div>
@@ -127,9 +144,11 @@ export default {
           <div class="d-flex align-items-center flex-wrap title namespace-title gl-mr-3">
             <a
               v-gl-tooltip.bottom
+              data-testid="group-name"
               :href="group.relativePath"
               :title="group.fullName"
               class="no-expand gl-mt-3 gl-mr-3 gl-text-gray-900!"
+              :itemprop="microdata.nameItemprop"
               >{{
                 // ending bracket must be by closing tag to prevent
                 // link hover text-decoration from over-extending
@@ -146,7 +165,12 @@ export default {
             </span>
           </div>
           <div v-if="group.description" class="description">
-            <span v-html="group.description"> </span>
+            <span
+              :itemprop="microdata.descriptionItemprop"
+              data-testid="group-description"
+              v-html="group.description"
+            >
+            </span>
           </div>
         </div>
         <div v-if="isGroupPendingRemoval">
diff --git a/app/assets/javascripts/groups/index.js b/app/assets/javascripts/groups/index.js
index 522f1d16df2..e11c3aaf984 100644
--- a/app/assets/javascripts/groups/index.js
+++ b/app/assets/javascripts/groups/index.js
@@ -47,8 +47,9 @@ export default (containerId = 'js-groups-tree', endpoint, action = '') => {
     data() {
       const { dataset } = dataEl || this.$options.el;
       const hideProjects = parseBoolean(dataset.hideProjects);
+      const showSchemaMarkup = parseBoolean(dataset.showSchemaMarkup);
       const service = new GroupsService(endpoint || dataset.endpoint);
-      const store = new GroupsStore(hideProjects);
+      const store = new GroupsStore({ hideProjects, showSchemaMarkup });
 
       return {
         action,
diff --git a/app/assets/javascripts/groups/store/groups_store.js b/app/assets/javascripts/groups/store/groups_store.js
index 6a1197fa163..b6cea38e87f 100644
--- a/app/assets/javascripts/groups/store/groups_store.js
+++ b/app/assets/javascripts/groups/store/groups_store.js
@@ -1,11 +1,13 @@
 import { normalizeHeaders, parseIntPagination } from '../../lib/utils/common_utils';
+import { getGroupItemMicrodata } from './utils';
 
 export default class GroupsStore {
-  constructor(hideProjects) {
+  constructor({ hideProjects = false, showSchemaMarkup = false } = {}) {
     this.state = {};
     this.state.groups = [];
     this.state.pageInfo = {};
     this.hideProjects = hideProjects;
+    this.showSchemaMarkup = showSchemaMarkup;
   }
 
   setGroups(rawGroups) {
@@ -94,6 +96,7 @@ export default class GroupsStore {
       starCount: rawGroupItem.star_count,
       updatedAt: rawGroupItem.updated_at,
       pendingRemoval: rawGroupItem.marked_for_deletion,
+      microdata: this.showSchemaMarkup ? getGroupItemMicrodata(rawGroupItem) : {},
     };
   }
 
diff --git a/app/assets/javascripts/groups/store/utils.js b/app/assets/javascripts/groups/store/utils.js
new file mode 100644
index 00000000000..371b3aa9d52
--- /dev/null
+++ b/app/assets/javascripts/groups/store/utils.js
@@ -0,0 +1,27 @@
+export const getGroupItemMicrodata = ({ type }) => {
+  const defaultMicrodata = {
+    itemscope: true,
+    itemtype: 'https://schema.org/Thing',
+    itemprop: 'owns',
+    imageItemprop: 'image',
+    nameItemprop: 'name',
+    descriptionItemprop: 'description',
+  };
+
+  switch (type) {
+    case 'group':
+      return {
+        ...defaultMicrodata,
+        itemtype: 'https://schema.org/Organization',
+        itemprop: 'subOrganization',
+        imageItemprop: 'logo',
+      };
+    case 'project':
+      return {
+        ...defaultMicrodata,
+        itemtype: 'https://schema.org/SoftwareSourceCode',
+      };
+    default:
+      return defaultMicrodata;
+  }
+};
diff --git a/app/finders/ci/commit_statuses_finder.rb b/app/finders/ci/commit_statuses_finder.rb
index 3c465eb88f3..d49ec7ebb40 100644
--- a/app/finders/ci/commit_statuses_finder.rb
+++ b/app/finders/ci/commit_statuses_finder.rb
@@ -12,7 +12,7 @@ module Ci
     end
 
     def execute
-      return [] unless Ability.allowed?(@current_user, :read_pipeline, @project)
+      return {} unless Ability.allowed?(@current_user, :read_pipeline, @project)
 
       commit_statuses
     end
diff --git a/app/helpers/user_callouts_helper.rb b/app/helpers/user_callouts_helper.rb
index e93c1b82cd7..a06a31ddf32 100644
--- a/app/helpers/user_callouts_helper.rb
+++ b/app/helpers/user_callouts_helper.rb
@@ -57,7 +57,10 @@ module UserCalloutsHelper
   end
 
   def show_registration_enabled_user_callout?
-    current_user&.admin? && signup_enabled? && !user_dismissed?(REGISTRATION_ENABLED_CALLOUT)
+    !Gitlab.com? &&
+    current_user&.admin? &&
+    signup_enabled? &&
+    !user_dismissed?(REGISTRATION_ENABLED_CALLOUT)
   end
 
   private
diff --git a/app/views/groups/_home_panel.html.haml b/app/views/groups/_home_panel.html.haml
index ee08829d990..67f278a06f3 100644
--- a/app/views/groups/_home_panel.html.haml
+++ b/app/views/groups/_home_panel.html.haml
@@ -6,10 +6,10 @@
   .row.mb-3
     .home-panel-title-row.col-md-12.col-lg-6.d-flex
       .avatar-container.rect-avatar.s64.home-panel-avatar.gl-mr-3.float-none
-        = group_icon(@group, class: 'avatar avatar-tile s64', width: 64, height: 64)
+        = group_icon(@group, class: 'avatar avatar-tile s64', width: 64, height: 64, itemprop: 'logo')
       .d-flex.flex-column.flex-wrap.align-items-baseline
         .d-inline-flex.align-items-baseline
-          %h1.home-panel-title.gl-mt-3.gl-mb-2
+          %h1.home-panel-title.gl-mt-3.gl-mb-2{ itemprop: 'name' }
             = @group.name
             %span.visibility-icon.text-secondary.gl-ml-2.has-tooltip{ data: { container: 'body' }, title: visibility_icon_description(@group) }
               = visibility_level_icon(@group.visibility_level, options: {class: 'icon'})
@@ -34,7 +34,7 @@
   - if @group.description.present?
     .group-home-desc.mt-1
       .home-panel-description
-        .home-panel-description-markdown.read-more-container
+        .home-panel-description-markdown.read-more-container{ itemprop: 'description' }
           = markdown_field(@group, :description)
         %button.btn.btn-blank.btn-link.js-read-more-trigger.d-lg-none{ type: "button" }
           = _("Read more")
diff --git a/app/views/groups/_subgroups_and_projects.html.haml b/app/views/groups/_subgroups_and_projects.html.haml
index cb15fe339e1..d9ab828a83b 100644
--- a/app/views/groups/_subgroups_and_projects.html.haml
+++ b/app/views/groups/_subgroups_and_projects.html.haml
@@ -3,6 +3,6 @@
     = render "shared/groups/empty_state"
 
   %section{ data: { hide_projects: 'false', group_id: group.id, path: group_path(group) } }
-    .js-groups-list-holder
+    .js-groups-list-holder{ data: { show_schema_markup: 'true'} }
       .loading-container.text-center.prepend-top-20
         .spinner.spinner-md
diff --git a/app/views/groups/show.html.haml b/app/views/groups/show.html.haml
index 9d5ec5008dc..a6a66467b47 100644
--- a/app/views/groups/show.html.haml
+++ b/app/views/groups/show.html.haml
@@ -1,5 +1,6 @@
 - breadcrumb_title _("Details")
 - @content_class = "limit-container-width" unless fluid_layout
+- page_itemtype    'https://schema.org/Organization'
 
 - if show_thanks_for_purchase_banner?
   = render_if_exists 'shared/thanks_for_purchase_banner', plan_title: plan_title, quantity: params[:purchased_quantity].to_i
diff --git a/app/views/shared/_new_project_item_select.html.haml b/app/views/shared/_new_project_item_select.html.haml
index 4340a34dc26..b327b6f7ee8 100644
--- a/app/views/shared/_new_project_item_select.html.haml
+++ b/app/views/shared/_new_project_item_select.html.haml
@@ -2,6 +2,6 @@
   .project-item-select-holder.btn-group.gl-ml-auto.gl-mr-auto.gl-py-3.gl-relative.gl-display-flex.gl-overflow-hidden
     %a.btn.gl-button.btn-success.new-project-item-link.block-truncated.qa-new-project-item-link{ href: '', data: { label: local_assigns[:label], type: local_assigns[:type] }, class: "gl-m-0!" }
       = loading_icon(color: 'light')
-    = project_select_tag :project_path, class: "project-item-select gl-absolute gl-visibility-hidden", data: { include_groups: local_assigns[:include_groups], order_by: 'last_activity_at', relative_path: local_assigns[:path], with_shared: local_assigns[:with_shared], include_projects_in_subgroups: local_assigns[:include_projects_in_subgroups] }, with_feature_enabled: local_assigns[:with_feature_enabled]
+    = project_select_tag :project_path, class: "project-item-select gl-absolute! gl-visibility-hidden", data: { include_groups: local_assigns[:include_groups], order_by: 'last_activity_at', relative_path: local_assigns[:path], with_shared: local_assigns[:with_shared], include_projects_in_subgroups: local_assigns[:include_projects_in_subgroups] }, with_feature_enabled: local_assigns[:with_feature_enabled]
     %button.btn.dropdown-toggle.btn-success.btn-md.gl-button.gl-dropdown-toggle.dropdown-toggle-split.new-project-item-select-button.qa-new-project-item-select-button.gl-p-0.gl-w-100{ class: "gl-m-0!", 'aria-label': _('Toggle project select') }
       = sprite_icon('chevron-down')
diff --git a/changelogs/unreleased/273751-fj-structured-data-for-groups.yml b/changelogs/unreleased/273751-fj-structured-data-for-groups.yml
new file mode 100644
index 00000000000..aaaf4034998
--- /dev/null
+++ b/changelogs/unreleased/273751-fj-structured-data-for-groups.yml
@@ -0,0 +1,5 @@
+---
+title: Add SEO structured markup for groups
+merge_request: 47374
+author:
+type: added
diff --git a/changelogs/unreleased/283825-split-button-gap-mr.yml b/changelogs/unreleased/283825-split-button-gap-mr.yml
new file mode 100644
index 00000000000..d18be8bdd4c
--- /dev/null
+++ b/changelogs/unreleased/283825-split-button-gap-mr.yml
@@ -0,0 +1,5 @@
+---
+title: Fix project select split button bug
+merge_request: 48065
+author:
+type: fixed
diff --git a/changelogs/unreleased/hide-open-registration-callout-on-gitlab-com.yml b/changelogs/unreleased/hide-open-registration-callout-on-gitlab-com.yml
new file mode 100644
index 00000000000..3db65d06754
--- /dev/null
+++ b/changelogs/unreleased/hide-open-registration-callout-on-gitlab-com.yml
@@ -0,0 +1,5 @@
+---
+title: Hide open registration user callout on gitlab.com
+merge_request: 47865
+author:
+type: changed
diff --git a/doc/.vale/gitlab/SubstitutionSuggestions.yml b/doc/.vale/gitlab/SubstitutionSuggestions.yml
index df68961b1ce..3fc22dc0d53 100644
--- a/doc/.vale/gitlab/SubstitutionSuggestions.yml
+++ b/doc/.vale/gitlab/SubstitutionSuggestions.yml
@@ -15,3 +15,4 @@ swap:
   once that: after that
   once the: after the
   once you: after you
+  within: in
diff --git a/doc/.vale/gitlab/spelling-exceptions.txt b/doc/.vale/gitlab/spelling-exceptions.txt
index a8ee7f8dbcc..90d6d4190e8 100644
--- a/doc/.vale/gitlab/spelling-exceptions.txt
+++ b/doc/.vale/gitlab/spelling-exceptions.txt
@@ -231,8 +231,8 @@ Kubesec
 Laravel
 LDAP
 ldapsearch
-Leiningen
 Lefthook
+Leiningen
 Libravatar
 liveness
 Lograge
@@ -477,6 +477,8 @@ substrings
 subtree
 subtrees
 sudo
+swimlane
+swimlanes
 syslog
 tcpdump
 Thanos
diff --git a/doc/administration/instance_review.md b/doc/administration/instance_review.md
index b00586b281b..6af016c873d 100644
--- a/doc/administration/instance_review.md
+++ b/doc/administration/instance_review.md
@@ -21,5 +21,5 @@ you qualify for a free Instance Review.
 1. GitLab redirects you to a form with prefilled data obtained from your instance.
 1. Click **Submit** to see the initial report.
 
-A GitLab team member will contact you for further review, to provide suggestions
-that will help you improve your usage of GitLab.
+You will be contacted by a GitLab team member for further review, to provide suggestions
+intended to help you improve your usage of GitLab.
diff --git a/doc/administration/monitoring/gitlab_self_monitoring_project/index.md b/doc/administration/monitoring/gitlab_self_monitoring_project/index.md
index c02634fb932..e4a4e9663ff 100644
--- a/doc/administration/monitoring/gitlab_self_monitoring_project/index.md
+++ b/doc/administration/monitoring/gitlab_self_monitoring_project/index.md
@@ -39,8 +39,8 @@ metrics exposed by the [GitLab exporter](../prometheus/gitlab_metrics.md#metrics
 ## Deleting the self monitoring project
 
 CAUTION: **Warning:**
-If you delete the self monitoring project, you will lose any changes made to the
-project. If you create the project again, it is created in its default state.
+Deleting the self monitoring project removes any changes made to the project. If
+you create the project again, it's created in its default state.
 
 1. Navigate to **Admin Area > Settings > Metrics and profiling**, and expand the **Self monitoring** section.
 1. Toggle the **Create Project** button off.
diff --git a/doc/administration/terraform_state.md b/doc/administration/terraform_state.md
index 55e166d2bf7..cf30090d45c 100644
--- a/doc/administration/terraform_state.md
+++ b/doc/administration/terraform_state.md
@@ -68,7 +68,7 @@ The following settings are:
 | Setting | Description | Default |
 |---------|-------------|---------|
 | `enabled` | Enable/disable object storage | `false` |
-| `remote_directory` | The bucket name where Terraform state files will be stored | |
+| `remote_directory` | The bucket name where Terraform state files are stored | |
 | `connection` | Various connection options described below | |
 
 ### S3-compatible connection settings
diff --git a/doc/api/group_clusters.md b/doc/api/group_clusters.md
index 0ad3528fa19..aba7187bf59 100644
--- a/doc/api/group_clusters.md
+++ b/doc/api/group_clusters.md
@@ -164,8 +164,8 @@ Parameters:
 | `name`                                               | string         | yes      | The name of the cluster                                                                             |
 | `domain`                                             | string         | no       | The [base domain](../user/group/clusters/index.md#base-domain) of the cluster                       |
 | `management_project_id`                              | integer        | no       | The ID of the [management project](../user/clusters/management_project.md) for the cluster          |
-| `enabled`                                            | boolean        | no       | Determines if cluster is active or not, defaults to true                                            |
-| `managed`                                            | boolean        | no       | Determines if GitLab will manage namespaces and service accounts for this cluster, defaults to true |
+| `enabled`                                            | boolean        | no       | Determines if cluster is active or not, defaults to `true`                                            |
+| `managed`                                            | boolean        | no       | Determines if GitLab manages namespaces and service accounts for this cluster. Defaults to `true` |
 | `platform_kubernetes_attributes[api_url]`            | string         | yes      | The URL to access the Kubernetes API                                                                |
 | `platform_kubernetes_attributes[token]`              | string         | yes      | The token to authenticate against Kubernetes                                                        |
 | `platform_kubernetes_attributes[ca_cert]`            | string         | no       | TLS certificate. Required if API is using a self-signed TLS certificate.                            |
@@ -237,7 +237,7 @@ Parameters:
 | `domain`                                  | string         | no       | The [base domain](../user/group/clusters/index.md#base-domain) of the cluster              |
 | `management_project_id`                   | integer        | no       | The ID of the [management project](../user/clusters/management_project.md) for the cluster |
 | `enabled`                                 | boolean        | no       | Determines if cluster is active or not                                                     |
-| `managed`                                 | boolean        | no       | Determines if GitLab will manage namespaces and service accounts for this cluster          |
+| `managed`                                 | boolean        | no       | Determines if GitLab manages namespaces and service accounts for this cluster          |
 | `platform_kubernetes_attributes[api_url]` | string         | no       | The URL to access the Kubernetes API                                                       |
 | `platform_kubernetes_attributes[token]`   | string         | no       | The token to authenticate against Kubernetes                                               |
 | `platform_kubernetes_attributes[ca_cert]` | string         | no       | TLS certificate. Required if API is using a self-signed TLS certificate.                   |
diff --git a/doc/api/instance_clusters.md b/doc/api/instance_clusters.md
index f57a61474dc..56bd09fbb6c 100644
--- a/doc/api/instance_clusters.md
+++ b/doc/api/instance_clusters.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36001) in GitLab 13.2.
 
 NOTE: **Note:**
-User will need admin access to use these endpoints.
+Users need admin access to use these endpoints.
 
 Use these API endpoints with your instance clusters, which enable you to use the same cluster across multiple projects. [More information](../user/instance/clusters/index.md)
 
@@ -164,7 +164,7 @@ Parameters:
 | `environment_scope`                                  | string  | no       | The associated environment to the cluster. Defaults to `*`                                            |
 | `management_project_id`                              | integer | no       | The ID of the [management project](../user/clusters/management_project.md) for the cluster            |
 | `enabled`                                            | boolean | no       | Determines if cluster is active or not, defaults to `true`                                            |
-| `managed`                                            | boolean | no       | Determines if GitLab will manage namespaces and service accounts for this cluster, defaults to `true` |
+| `managed`                                            | boolean | no       | Determines if GitLab manages namespaces and service accounts for this cluster. Defaults to `true` |
 | `platform_kubernetes_attributes[api_url]`            | string  | yes      | The URL to access the Kubernetes API                                                                  |
 | `platform_kubernetes_attributes[token]`              | string  | yes      | The token to authenticate against Kubernetes                                                          |
 | `platform_kubernetes_attributes[ca_cert]`            | string  | no       | TLS certificate. Required if API is using a self-signed TLS certificate.                              |
@@ -232,7 +232,7 @@ Parameters:
 | `environment_scope`                         | string  | no       | The associated environment to the cluster                                                  |
 | `management_project_id`                     | integer | no       | The ID of the [management project](../user/clusters/management_project.md) for the cluster |
 | `enabled`                                   | boolean | no       | Determines if cluster is active or not                                                     |
-| `managed`                                   | boolean | no       | Determines if GitLab will manage namespaces and service accounts for this cluster          |
+| `managed`                                   | boolean | no       | Determines if GitLab manages namespaces and service accounts for this cluster          |
 | `platform_kubernetes_attributes[api_url]`   | string  | no       | The URL to access the Kubernetes API                                                       |
 | `platform_kubernetes_attributes[token]`     | string  | no       | The token to authenticate against Kubernetes                                               |
 | `platform_kubernetes_attributes[ca_cert]`   | string  | no       | TLS certificate. Required if API is using a self-signed TLS certificate.                   |
diff --git a/doc/api/invitations.md b/doc/api/invitations.md
index 6fd2b26d80f..b6dc83201a8 100644
--- a/doc/api/invitations.md
+++ b/doc/api/invitations.md
@@ -23,7 +23,7 @@ levels are defined in the `Gitlab::Access` module. Currently, these levels are v
 
 CAUTION: **Caution:**
 Due to [an issue](https://gitlab.com/gitlab-org/gitlab/-/issues/219299),
-projects in personal namespaces will not show owner (`50`) permission.
+projects in personal namespaces don't show owner (`50`) permission.
 
 ## Invite by email to group or project
 
diff --git a/doc/api/project_clusters.md b/doc/api/project_clusters.md
index 44b16e188af..16b3839b61c 100644
--- a/doc/api/project_clusters.md
+++ b/doc/api/project_clusters.md
@@ -190,7 +190,7 @@ Parameters:
 | `domain`                                             | string  | no       | The [base domain](../user/project/clusters/index.md#base-domain) of the cluster                       |
 | `management_project_id`                              | integer | no       | The ID of the [management project](../user/clusters/management_project.md) for the cluster            |
 | `enabled`                                            | boolean | no       | Determines if cluster is active or not, defaults to `true`                                            |
-| `managed`                                            | boolean | no       | Determines if GitLab will manage namespaces and service accounts for this cluster, defaults to `true` |
+| `managed`                                            | boolean | no       | Determines if GitLab manages namespaces and service accounts for this cluster. Defaults to `true` |
 | `platform_kubernetes_attributes[api_url]`            | string  | yes      | The URL to access the Kubernetes API                                                                  |
 | `platform_kubernetes_attributes[token]`              | string  | yes      | The token to authenticate against Kubernetes                                                          |
 | `platform_kubernetes_attributes[ca_cert]`            | string  | no       | TLS certificate. Required if API is using a self-signed TLS certificate.                              |
@@ -287,7 +287,7 @@ Parameters:
 | `domain`                                    | string  | no       | The [base domain](../user/project/clusters/index.md#base-domain) of the cluster            |
 | `management_project_id`                     | integer | no       | The ID of the [management project](../user/clusters/management_project.md) for the cluster |
 | `enabled`                                   | boolean | no       | Determines if cluster is active or not                                                     |
-| `managed`                                   | boolean | no       | Determines if GitLab will manage namespaces and service accounts for this cluster          |
+| `managed`                                   | boolean | no       | Determines if GitLab manages namespaces and service accounts for this cluster          |
 | `platform_kubernetes_attributes[api_url]`   | string  | no       | The URL to access the Kubernetes API                                                       |
 | `platform_kubernetes_attributes[token]`     | string  | no       | The token to authenticate against Kubernetes                                               |
 | `platform_kubernetes_attributes[ca_cert]`   | string  | no       | TLS certificate. Required if API is using a self-signed TLS certificate.                   |
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index 065716c9a64..e323da3ff28 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -631,8 +631,6 @@ job:
 
 #### `before_script`
 
-> Introduced in GitLab 8.7 and requires GitLab Runner v1.2.
-
 `before_script` is used to define commands that should run before each job, including
 deploy jobs, but after the restoration of any [artifacts](#artifacts). This must be an array.
 
@@ -661,8 +659,6 @@ You can use [YAML anchors with `before_script`](#yaml-anchors-for-scripts).
 
 #### `after_script`
 
-Introduced in GitLab 8.7 and requires GitLab Runner v1.2.
-
 `after_script` is used to define commands that run after each job, including failed
 jobs. This must be an array.
 
@@ -1063,7 +1059,7 @@ In this example:
 - If the pipeline is **not** for a merge request, the first rule doesn't match, and the
   second rule is evaluated.
 - If the pipeline is a scheduled pipeline, the second rule matches, and the job
-  is added to the scheduled pipeline. Since no attributes were defined, it is added
+  is added to the scheduled pipeline. No attributes were defined, so it is added
   with:
   - `when: on_success` (default)
   - `allow_failure: false` (default)
@@ -1194,7 +1190,7 @@ See the [related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/201845) fo
 #### `rules:if`
 
 `rules:if` clauses determine whether or not jobs are added to a pipeline by evaluating
-a simple `if` statement. If the `if` statement is true, the job is either included
+an `if` statement. If the `if` statement is true, the job is either included
 or excluded from a pipeline. In plain English, `if` rules can be interpreted as one of:
 
 - "If this rule evaluates to true, add the job" (default).
@@ -1291,8 +1287,8 @@ Other commonly used variables for `if` clauses:
 - `if: $CI_COMMIT_BRANCH`: If changes are pushed to any branch.
 - `if: '$CI_COMMIT_BRANCH == "master"'`: If changes are pushed to `master`.
 - `if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'`: If changes are pushed to the default
-  branch (usually `master`). Useful if reusing the same configuration in multiple
-  projects with potentially different default branches.
+  branch (usually `master`). Use when you want to have the same configuration in multiple
+  projects with different default branches.
 - `if: '$CI_COMMIT_BRANCH =~ /regex-expression/'`: If the commit branch matches a regular expression.
 - `if: '$CUSTOM_VARIABLE !~ /regex-expression/'`: If the [custom variable](../variables/README.md#custom-environment-variables)
   `CUSTOM_VARIABLE` does **not** match a regular expression.
@@ -1786,8 +1782,8 @@ job1:
 Using the `changes` keyword with `only` or `except` makes it possible to define if
 a job should be created based on files modified by a Git push event.
 
-The `only:changes` policy is only useful for pipelines triggered by the following
-refs:
+Use the `only:changes` policy for pipelines triggered by the following
+refs only:
 
 - `branches`
 - `external_pull_requests`
@@ -2221,7 +2217,7 @@ failure.
 1. `on_failure` - execute job only when at least one job from prior stages
     fails.
 1. `always` - execute job regardless of the status of jobs from prior stages.
-1. `manual` - execute job manually (added in GitLab 8.10). Read about
+1. `manual` - execute job manually. Read about
     [manual jobs](#whenmanual) below.
 1. `delayed` - execute job after a certain period (added in GitLab 11.14).
     Read about [delayed jobs](#whendelayed) below.
@@ -2277,10 +2273,6 @@ The above script:
 
 #### `when:manual`
 
-> - Introduced in GitLab 8.10.
-> - Blocking manual jobs were introduced in GitLab 9.0.
-> - Protected actions were introduced in GitLab 9.2.
-
 A manual job is a type of job that is not executed automatically and must be explicitly
 started by a user. You might want to use manual jobs for things like deploying to production.
 
@@ -2358,8 +2350,8 @@ stages by triggering the blocking manual job.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/51352) in GitLab 11.4.
 
-Delayed job are for executing scripts after a certain period.
-This is useful if you want to avoid jobs entering `pending` state immediately.
+Use `when: delayed` to execute scripts after a waiting period, or if you want to avoid
+jobs immediately entering the `pending` state.
 
 You can set the period with `start_in` key. The value of `start_in` key is an elapsed time in seconds, unless a unit is
 provided. `start_in` key must be less than or equal to one week. Examples of valid values include:
@@ -2394,11 +2386,7 @@ Soon GitLab Runner picks up and starts the job.
 
 ### `environment`
 
-> - Introduced in GitLab 8.9.
-> - You can read more about environments and find more examples in the
->   [documentation about environments](../environments/index.md).
-
-`environment` is used to define that a job deploys to a specific environment.
+Use `environment` to define the [environment](../environments/index.md) that a job deploys to.
 If `environment` is specified and no environment under that name exists, a new
 one is created automatically.
 
@@ -2416,13 +2404,10 @@ deployment to the `production` environment.
 
 #### `environment:name`
 
-> - Introduced in GitLab 8.11.
-> - Before GitLab 8.11, the name of an environment could be defined as a string like
->   `environment: production`. The recommended way now is to define it under the
->   `name` keyword.
-> - The `name` keyword can use any of the defined CI variables,
->   including predefined, secure variables and `.gitlab-ci.yml` [`variables`](#variables).
->   You however can't use variables defined under `script`.
+The `environment: name` keyword can use any of the defined CI variables,
+including predefined, secure, or `.gitlab-ci.yml` [`variables`](#variables).
+
+You can't use variables defined in a `script` section.
 
 The `environment` name can contain:
 
@@ -2453,12 +2438,10 @@ deploy to production:
 
 #### `environment:url`
 
-> - Introduced in GitLab 8.11.
-> - Before GitLab 8.11, the URL could be added only in GitLab's UI. The
->   recommended way now is to define it in `.gitlab-ci.yml`.
-> - The `url` keyword can use any of the defined CI variables,
->   including predefined, secure variables and `.gitlab-ci.yml` [`variables`](#variables).
->   You however can't use variables defined under `script`.
+The `url` keyword can use any of the defined CI variables,
+including predefined, secure, or `.gitlab-ci.yml` [`variables`](#variables).
+
+You can't use variables defined in a `script` section.
 
 This optional value exposes buttons that take you to the defined URL
 
@@ -2610,9 +2593,8 @@ To follow progress on support for GitLab-managed clusters, see the
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/21971) in GitLab 8.12 and GitLab Runner 1.6.
 > - The `$CI_ENVIRONMENT_SLUG` was [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/22864) in GitLab 8.15.
-> - The `name` and `url` keywords can use any of the defined CI variables,
->   including predefined, secure variables and `.gitlab-ci.yml` [`variables`](#variables).
->   You however can't use variables defined under `script`.
+
+Use CI/CD [variables](../variables/README.md) to dynamically name environments.
 
 For example:
 
@@ -2637,17 +2619,11 @@ This implies that the underlying server that hosts the application
 is properly configured.
 
 The common use case is to create dynamic environments for branches and use them
-as Review Apps. You can see a simple example using Review Apps at
+as Review Apps. You can see an example that uses Review Apps at
 <https://gitlab.com/gitlab-examples/review-apps-nginx/>.
 
 ### `cache`
 
-> - Introduced in GitLab Runner v0.7.0.
-> - `cache` can be set globally and per-job.
-> - From GitLab 9.0, caching is enabled and shared between pipelines and jobs
->   by default.
-> - From GitLab 9.2, caches are restored before [artifacts](#artifacts).
-
 `cache` is used to specify a list of files and directories that should be
 cached between jobs. You can only use paths that are within the local working
 copy.
@@ -2655,6 +2631,8 @@ copy.
 If `cache` is defined outside the scope of jobs, it means it's set
 globally and all jobs use that definition.
 
+Caching is shared between pipelines and jobs. Caches are restored before [artifacts](#artifacts).
+
 Read how caching works and find out some good practices in the
 [caching dependencies documentation](../caching/index.md).
 
@@ -2713,7 +2691,7 @@ including caching data between different jobs or even different branches.
 The `cache:key` variable can use any of the
 [predefined variables](../variables/README.md). The default key, if not
 set, is just literal `default`, which means everything is shared between
-pipelines and jobs by default, starting from GitLab 9.0.
+pipelines and jobs by default.
 
 For example, to enable per-branch caching:
 
@@ -2880,8 +2858,6 @@ rspec:
 
 #### `cache:policy`
 
-> Introduced in GitLab 9.4.
-
 The default behavior of a caching job is to download the files at the start of
 execution, and to re-upload them at the end. Any changes made by the
 job are persisted for future runs. This behavior is known as the `pull-push` cache
@@ -2927,12 +2903,6 @@ To do so, add `policy: push` to the job.
 
 ### `artifacts`
 
-> - Introduced in GitLab Runner v0.7.0 for non-Windows platforms.
-> - Windows support was added in GitLab Runner v.1.0.0.
-> - From GitLab 9.2, caches are restored before artifacts.
-> - Not all executors are [supported](https://docs.gitlab.com/runner/executors/#compatibility-chart).
-> - Job artifacts are only collected for successful jobs by default.
-
 `artifacts` is used to specify a list of files and directories that are
 attached to the job when it [succeeds, fails, or always](#artifactswhen).
 
@@ -2940,6 +2910,11 @@ The artifacts are sent to GitLab after the job finishes. They are
 available for download in the GitLab UI if the size is not
 larger than the [maximum artifact size](../../user/gitlab_com/index.md#gitlab-cicd).
 
+Job artifacts are only collected for successful jobs by default, and
+artifacts are restored after [caches](#cache).
+
+[Not all executors can use caches](https://docs.gitlab.com/runner/executors/#compatibility-chart).
+
 [Read more about artifacts](../pipelines/job_artifacts.md).
 
 #### `artifacts:paths`
@@ -3075,11 +3050,8 @@ Note the following:
 
 #### `artifacts:name`
 
-> Introduced in GitLab 8.6 and GitLab Runner v1.1.0.
-
 Use the `name` directive to define the name of the created artifacts
-archive. You can specify a unique name for every archive, which can be
-useful when you want to download the archive from GitLab. The `artifacts:name`
+archive. You can specify a unique name for every archive. The `artifacts:name`
 variable can make use of any of the [predefined variables](../variables/README.md).
 The default name is `artifacts`, which becomes `artifacts.zip` when you download it.
 
@@ -3186,8 +3158,6 @@ artifacts:
 
 #### `artifacts:when`
 
-> Introduced in GitLab 8.9 and GitLab Runner v1.3.0.
-
 `artifacts:when` is used to upload artifacts on job failure or despite the
 failure.
 
@@ -3207,8 +3177,6 @@ job:
 
 #### `artifacts:expire_in`
 
-> Introduced in GitLab 8.9 and GitLab Runner v1.3.0.
-
 Use `expire_in` to specify how long artifacts are active before they
 expire and are deleted.
 
@@ -3260,27 +3228,25 @@ It also exposes these reports in GitLab's UI (merge requests, pipeline views, an
 
 These are the available report types:
 
-| Keyword                                                                                                                            | Description |
-|--------------------------------------------------------------------------------------------------------------------------------------|-------------|
-| [`artifacts:reports:cobertura`](../pipelines/job_artifacts.md#artifactsreportscobertura)                                             | The `cobertura` report collects Cobertura coverage XML files.                    |
-| [`artifacts:reports:codequality`](../pipelines/job_artifacts.md#artifactsreportscodequality)                                         | The `codequality` report collects CodeQuality issues.                            |
+| Keyword                                                                                                                     | Description                                                                      |
+|-----------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------|
+| [`artifacts:reports:cobertura`](../pipelines/job_artifacts.md#artifactsreportscobertura)                                    | The `cobertura` report collects Cobertura coverage XML files.                    |
+| [`artifacts:reports:codequality`](../pipelines/job_artifacts.md#artifactsreportscodequality)                                | The `codequality` report collects CodeQuality issues.                            |
 | [`artifacts:reports:container_scanning`](../pipelines/job_artifacts.md#artifactsreportscontainer_scanning) **(ULTIMATE)**   | The `container_scanning` report collects Container Scanning vulnerabilities.     |
 | [`artifacts:reports:dast`](../pipelines/job_artifacts.md#artifactsreportsdast) **(ULTIMATE)**                               | The `dast` report collects Dynamic Application Security Testing vulnerabilities. |
 | [`artifacts:reports:dependency_scanning`](../pipelines/job_artifacts.md#artifactsreportsdependency_scanning) **(ULTIMATE)** | The `dependency_scanning` report collects Dependency Scanning vulnerabilities.   |
-| [`artifacts:reports:dotenv`](../pipelines/job_artifacts.md#artifactsreportsdotenv)                                                   | The `dotenv` report collects a set of environment variables.                     |
-| [`artifacts:reports:junit`](../pipelines/job_artifacts.md#artifactsreportsjunit)                                                     | The `junit` report collects JUnit XML files.                                     |
+| [`artifacts:reports:dotenv`](../pipelines/job_artifacts.md#artifactsreportsdotenv)                                          | The `dotenv` report collects a set of environment variables.                     |
+| [`artifacts:reports:junit`](../pipelines/job_artifacts.md#artifactsreportsjunit)                                            | The `junit` report collects JUnit XML files.                                     |
 | [`artifacts:reports:license_management`](../pipelines/job_artifacts.md#artifactsreportslicense_management) **(ULTIMATE)**   | The `license_management` report collects Licenses (*removed from GitLab 13.0*).  |
 | [`artifacts:reports:license_scanning`](../pipelines/job_artifacts.md#artifactsreportslicense_scanning) **(ULTIMATE)**       | The `license_scanning` report collects Licenses.                                 |
-| [`artifacts:reports:load_performance`](../pipelines/job_artifacts.md#artifactsreportsload_performance) **(PREMIUM)**         | The `load_performance` report collects load performance metrics.                 |
-| [`artifacts:reports:metrics`](../pipelines/job_artifacts.md#artifactsreportsmetrics) **(PREMIUM)**                           | The `metrics` report collects Metrics.                                           |
-| [`artifacts:reports:performance`](../pipelines/job_artifacts.md#artifactsreportsperformance) **(PREMIUM)**                   | The `performance` report collects Browser Performance metrics.                   |
+| [`artifacts:reports:load_performance`](../pipelines/job_artifacts.md#artifactsreportsload_performance) **(PREMIUM)**        | The `load_performance` report collects load performance metrics.                 |
+| [`artifacts:reports:metrics`](../pipelines/job_artifacts.md#artifactsreportsmetrics) **(PREMIUM)**                          | The `metrics` report collects Metrics.                                           |
+| [`artifacts:reports:performance`](../pipelines/job_artifacts.md#artifactsreportsperformance) **(PREMIUM)**                  | The `performance` report collects Browser Performance metrics.                   |
 | [`artifacts:reports:sast`](../pipelines/job_artifacts.md#artifactsreportssast) **(ULTIMATE)**                               | The `sast` report collects Static Application Security Testing vulnerabilities.  |
-| [`artifacts:reports:terraform`](../pipelines/job_artifacts.md#artifactsreportsterraform)                                             | The `terraform` report collects Terraform `tfplan.json` files.                   |
+| [`artifacts:reports:terraform`](../pipelines/job_artifacts.md#artifactsreportsterraform)                                    | The `terraform` report collects Terraform `tfplan.json` files.                   |
 
 #### `dependencies`
 
-> Introduced in GitLab 8.6 and GitLab Runner v1.1.1.
-
 By default, all [`artifacts`](#artifacts) from previous [stages](#stages)
 are passed to each job. However, you can use the `dependencies` keyword to
 define a limited list of jobs to fetch artifacts from. You can also set a job to download no artifacts at all.
@@ -3361,7 +3327,7 @@ surrounding `/` is mandatory to consistently and explicitly represent
 a regular expression string. You must escape special characters if you want to
 match them literally.
 
-A simple example:
+For example:
 
 ```yaml
 job1:
@@ -3494,7 +3460,7 @@ test:
 Parallelize tests suites across parallel jobs.
 Different languages have different tools to facilitate this.
 
-A simple example using [Semaphore Test Boosters](https://github.com/renderedtext/test-boosters) and RSpec to run some Ruby tests:
+For example, using [Semaphore Test Boosters](https://github.com/renderedtext/test-boosters) and RSpec to run some Ruby tests:
 
 ```ruby
 # Gemfile
@@ -3513,7 +3479,7 @@ test:
 ```
 
 CAUTION: **Caution:**
-Please be aware that semaphore_test_boosters reports usages statistics to the author.
+Test Boosters reports usages statistics to the author.
 
 You can then navigate to the **Jobs** tab of a new pipeline build and see your RSpec
 job split into three separate jobs.
@@ -3755,7 +3721,7 @@ Set jobs as interruptible that can be safely canceled once started (for instance
 
 Pending jobs are always considered interruptible.
 
-Here is a simple example:
+For example:
 
 ```yaml
 stages:
@@ -3805,7 +3771,7 @@ If multiple jobs belonging to the same resource group are enqueued simultaneousl
 only one of the jobs is picked by the runner. The other jobs wait until the
 `resource_group` is free.
 
-Here is a simple example:
+For example:
 
 ```yaml
 deploy-to-production:
@@ -4086,7 +4052,7 @@ requirements below must be met:
 - Any static content must be placed under a `public/` directory.
 - `artifacts` with a path to the `public/` directory must be defined.
 
-The example below simply moves all files from the root of the project to the
+The example below moves all files from the root of the project to the
 `public/` directory. The `.public` workaround is so `cp` does not also copy
 `public/` to itself in an infinite loop:
 
@@ -4186,8 +4152,6 @@ need to be used to merge arrays.
 
 ### Anchors
 
-> Introduced in GitLab 8.6 and GitLab Runner v1.1.1.
-
 YAML has a feature called 'anchors' that you can use to duplicate
 content across your document.
 
@@ -4375,8 +4339,6 @@ job_no_git_strategy:
 
 ### Hide jobs
 
-> Introduced in GitLab 8.6 and GitLab Runner v1.1.1.
-
 If you want to temporarily 'disable' a job, rather than commenting out all the
 lines where the job is defined:
 
diff --git a/doc/development/experiment_guide/index.md b/doc/development/experiment_guide/index.md
index 3b2f1d21463..6d5f18fb8c5 100644
--- a/doc/development/experiment_guide/index.md
+++ b/doc/development/experiment_guide/index.md
@@ -6,17 +6,17 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Experiment Guide
 
-Experiments can be conducted by any GitLab team, most often the teams from the [Growth Sub-department](https://about.gitlab.com/handbook/engineering/development/growth/). Experiments are not tied to releases because they will primarily target GitLab.com.
+Experiments can be conducted by any GitLab team, most often the teams from the [Growth Sub-department](https://about.gitlab.com/handbook/engineering/development/growth/). Experiments are not tied to releases because they primarily target GitLab.com.
 
-Experiments will be run as an A/B test and will be behind a feature flag to turn the test on or off. Based on the data the experiment generates, the team will decide if the experiment had a positive impact and will be the new default or rolled back.
+Experiments are run as an A/B test and are behind a feature flag to turn the test on or off. Based on the data the experiment generates, the team decides if the experiment had a positive impact and should be made the new default or rolled back.
 
 ## Experiment tracking issue
 
 Each experiment should have an [Experiment tracking](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=growth%20experiment&search=%22Experiment+tracking%22) issue to track the experiment from roll-out through to cleanup/removal. Immediately after an experiment is deployed, the due date of the issue should be set (this depends on the experiment but can be up to a few weeks in the future).
 After the deadline, the issue needs to be resolved and either:
 
-- It was successful and the experiment will be the new default.
-- It was not successful and all code related to the experiment will be removed.
+- It was successful and the experiment becomes the new default.
+- It was not successful and all code related to the experiment is removed.
 
 In either case, an outcome of the experiment should be posted to the issue with the reasoning for the decision.
 
@@ -80,7 +80,7 @@ addressed.
       end
       ```
 
-      The above will check whether the experiment is enabled and push the result to the frontend.
+      The above checks whether the experiment is enabled and push the result to the frontend.
 
       You can check the state of the feature flag in JavaScript:
 
diff --git a/doc/development/logging.md b/doc/development/logging.md
index 4ddb0e5f5cf..f81dd3e6438 100644
--- a/doc/development/logging.md
+++ b/doc/development/logging.md
@@ -131,8 +131,8 @@ data.
 
 Unless a field type is explicitly mapped, Elasticsearch infers the type from
 the first instance of that field value it sees. Subsequent instances of that
-field value with different types will either fail to be indexed, or in some
-cases (scalar/object conflict), the whole log line will be dropped.
+field value with different types either fail to be indexed, or in some
+cases (scalar/object conflict), the whole log line is dropped.
 
 GitLab.com's logging Elasticsearch sets
 [`ignore_malformed`](https://www.elastic.co/guide/en/elasticsearch/reference/current/ignore-malformed.html),
@@ -311,7 +311,7 @@ It should be noted that manual logging of exceptions is not allowed, as:
 1. Very often manually logged exception needs to be tracked to Sentry as well,
 1. Manually logged exceptions does not use `correlation_id`, which makes hard
    to pin them to request, user and context in which this exception was raised,
-1. It is very likely that manually logged exceptions will end-up across
+1. Manually logged exceptions often end up across
    multiple files, which increases burden scraping all logging files.
 
 To avoid duplicating and having consistent behavior the `Gitlab::ErrorTracking`
diff --git a/doc/development/product_analytics/snowplow.md b/doc/development/product_analytics/snowplow.md
index c5f48994d5c..4f62fefbf7b 100644
--- a/doc/development/product_analytics/snowplow.md
+++ b/doc/development/product_analytics/snowplow.md
@@ -98,7 +98,7 @@ sequenceDiagram
 
 ## Structured event taxonomy
 
-When adding new click events, we should add them in a way that's internally consistent. If we don't, it'll be very painful to perform analysis across features since each feature will be capturing events differently.
+When adding new click events, we should add them in a way that's internally consistent. If we don't, it is very painful to perform analysis across features since each feature captures events differently.
 
 The current method provides several attributes that are sent on each click event. Please try to follow these guidelines when specifying events to capture:
 
diff --git a/doc/development/product_analytics/usage_ping.md b/doc/development/product_analytics/usage_ping.md
index 893814c5f0d..66d431c2bb0 100644
--- a/doc/development/product_analytics/usage_ping.md
+++ b/doc/development/product_analytics/usage_ping.md
@@ -31,15 +31,15 @@ More useful links:
 - The usage data is primarily composed of row counts for different tables in the instance’s database. By comparing these counts month over month (or week over week), we can get a rough sense for how an instance is using the different features within the product. In addition to counts, other facts
     that help us classify and understand GitLab installations are collected.
 - Usage ping is important to GitLab as we use it to calculate our Stage Monthly Active Users (SMAU) which helps us measure the success of our stages and features.
-- While usage ping is enabled, GitLab will gather data from the other instances and will be able to show usage statistics of your instance to your users.
+- While usage ping is enabled, GitLab gathers data from the other instances and can show usage statistics of your instance to your users.
 
 ### Why should we enable Usage Ping?
 
 - The main purpose of Usage Ping is to build a better GitLab. Data about how GitLab is used is collected to better understand feature/stage adoption and usage, which helps us understand how GitLab is adding value and helps our team better understand the reasons why people use GitLab and with this knowledge we're able to make better product decisions.
 - As a benefit of having the usage ping active, GitLab lets you analyze the users’ activities over time of your GitLab installation.
 - As a benefit of having the usage ping active, GitLab provides you with The DevOps Report,which gives you an overview of your entire instance’s adoption of Concurrent DevOps from planning to monitoring.
-- You will get better, more proactive support. (assuming that our TAMs and support organization used the data to deliver more value)
-- You will get insight and advice into how to get the most value out of your investment in GitLab. Wouldn't you want to know that a number of features or values are not being adopted in your organization?
+- You get better, more proactive support. (assuming that our TAMs and support organization used the data to deliver more value)
+- You get insight and advice into how to get the most value out of your investment in GitLab. Wouldn't you want to know that a number of features or values are not being adopted in your organization?
 - You get a report that illustrates how you compare against other similar organizations (anonymized), with specific advice and recommendations on how to improve your DevOps processes.
 - Usage Ping is enabled by default. To disable it, see [Disable Usage Ping](#disable-usage-ping).
 
@@ -189,7 +189,7 @@ Arguments:
 - `relation` the ActiveRecord_Relation to perform the count
 - `column` the column to perform the distinct count, by default is the primary key
 - `batch`: default `true` in order to use batch counting
-- `batch_size`: if none set it will use default value 10000 from `Gitlab::Database::BatchCounter`
+- `batch_size`: if none set it uses default value 10000 from `Gitlab::Database::BatchCounter`
 - `start`: custom start of the batch counting in order to avoid complex min calculations
 - `end`: custom end of the batch counting in order to avoid complex min calculations
 
@@ -213,7 +213,7 @@ Arguments:
 
 - `relation` the ActiveRecord_Relation to perform the operation
 - `column` the column to sum on
-- `batch_size`: if none set it will use default value 1000 from `Gitlab::Database::BatchCounter`
+- `batch_size`: if none set it uses default value 1000 from `Gitlab::Database::BatchCounter`
 - `start`: custom start of the batch counting in order to avoid complex min calculations
 - `end`: custom end of the batch counting in order to avoid complex min calculations
 
@@ -304,7 +304,7 @@ Implemented using Redis methods [PFADD](https://redis.io/commands/pfadd) and [PF
      access to a group of events.
    - `redis_slot`: optional Redis slot; default value: event name. Used if needed to calculate totals
      for a group of metrics. Ensure keys are in the same slot. For example:
-     `i_compliance_credential_inventory` with `redis_slot: 'compliance'` will build Redis key
+     `i_compliance_credential_inventory` with `redis_slot: 'compliance'` builds Redis key
      `i_{compliance}_credential_inventory-2020-34`. If `redis_slot` is not defined the Redis key will
      be `{i_compliance_credential_inventory}-2020-34`.
    - `expiry`: expiry time in days. Default: 29 days for daily aggregation and 6 weeks for weekly
@@ -574,7 +574,7 @@ NOTE: **Note:**
 Prometheus as a data source for Usage Ping is currently only available for single-node Omnibus installations
 that are running the [bundled Prometheus](../../administration/monitoring/prometheus/index.md) instance.
 
-In order to query Prometheus for metrics, a helper method is available that will `yield` a fully configured
+To query Prometheus for metrics, a helper method is available to `yield` a fully configured
 `PrometheusClient`, given it is available as per the note above:
 
 ```ruby
@@ -613,7 +613,7 @@ Gitlab::UsageData.distinct_count(::Note.with_suggestions.where(time_period), :au
 
 ### 3. Generate the SQL query
 
-Your Rails console will return the generated SQL queries.
+Your Rails console returns the generated SQL queries.
 
 Example:
 
@@ -670,7 +670,7 @@ Ensure you comply with the [Changelog entries guide](../changelog.md).
 
 ### 9. Ask for a Product Analytics Review
 
-On GitLab.com, we have DangerBot setup to monitor Product Analytics related files and DangerBot will recommend a Product Analytics review. Mention `@gitlab-org/growth/product_analytics/engineers` in your MR for a review.
+On GitLab.com, we have DangerBot setup to monitor Product Analytics related files and DangerBot recommends a Product Analytics review. Mention `@gitlab-org/growth/product_analytics/engineers` in your MR for a review.
 
 ### 10. Verify your metric
 
@@ -696,10 +696,10 @@ This is the recommended approach to test Prometheus based Usage Ping.
 The easiest way to verify your changes is to build a new Omnibus image from your code branch via CI, then download the image
 and run a local container instance:
 
-1. From your merge request, click on the `qa` stage, then trigger the `package-and-qa` job. This job will trigger an Omnibus
+1. From your merge request, click on the `qa` stage, then trigger the `package-and-qa` job. This job triggers an Omnibus
 build in a [downstream pipeline of the `omnibus-gitlab-mirror` project](https://gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/-/pipelines).
 1. In the downstream pipeline, wait for the `gitlab-docker` job to finish.
-1. Open the job logs and locate the full container name including the version. It will take the following form: `registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:<VERSION>`.
+1. Open the job logs and locate the full container name including the version. It takes the following form: `registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:<VERSION>`.
 1. On your local machine, make sure you are logged in to the GitLab Docker registry. You can find the instructions for this in
 [Authenticate to the GitLab Container Registry](../../user/packages/container_registry/index.md#authenticate-with-the-container-registry).
 1. Once logged in, download the new image via `docker pull registry.gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/gitlab-ee:<VERSION>`
@@ -720,7 +720,7 @@ but with the following limitations:
 - While it runs a `node_exporter`, `docker-compose` services emulate hosts, meaning that it would normally report itself to not be associated
 with any of the other services that are running. That is not how node metrics are reported in a production setup, where `node_exporter`
 always runs as a process alongside other GitLab components on any given node. From Usage Ping's perspective none of the node data would therefore
-appear to be associated to any of the services running, since they all appear to be running on different hosts. To alleviate this problem, the `node_exporter` in GCK was arbitrarily "assigned" to the `web` service, meaning only for this service `node_*` metrics will appear in Usage Ping.
+appear to be associated to any of the services running, since they all appear to be running on different hosts. To alleviate this problem, the `node_exporter` in GCK was arbitrarily "assigned" to the `web` service, meaning only for this service `node_*` metrics appears in Usage Ping.
 
 ## Aggregated metrics
 
@@ -733,14 +733,14 @@ This feature is intended solely for internal GitLab use.
 
 In order to add data for aggregated metrics into Usage Ping payload you should add corresponding definition into  [`aggregated_metrics.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/aggregated_metrics.yml) file. Each aggregate definition includes following parts:
 
-- name: unique name under which aggregate metric will be added to Usage Ping payload
-- operator: operator that defines how aggregated metric data will be counted. Available operators are:
+- name: unique name under which aggregate metric is added to Usage Ping payload
+- operator: operator that defines how aggregated metric data is counted. Available operators are:
   - `OR`: removes duplicates and counts all entries that triggered any of listed events
   - `AND`: removes duplicates and counts all elements that were observed triggering all of following events
 - events: list of events names (from [`known_events.yml`](#known-events-in-usage-data-payload)) to aggregate into metric. All events in this list must have the same `redis_slot` and `aggregation` attributes.
-- feature_flag: name of [development feature flag](../feature_flags/development.md#development-type) that will be checked before
-metrics aggregation is performed. Corresponding feature flag should have `default_enabled` attribute set to `false`. 
-`feature_flag` attribute is **OPTIONAL**  and can be omitted, when `feature_flag` is missing no feature flag will be checked.
+- feature_flag: name of [development feature flag](../feature_flags/development.md#development-type) that is checked before
+metrics aggregation is performed. Corresponding feature flag should have `default_enabled` attribute set to `false`.
+`feature_flag` attribute is **OPTIONAL**  and can be omitted, when `feature_flag` is missing no feature flag is checked.
 
 Example aggregated metric entries:
 
@@ -754,7 +754,7 @@ Example aggregated metric entries:
   feature_flag: example_aggregated_metric
 ```
 
-Aggregated metrics will be added under `aggregated_metrics` key in both `counts_weekly` and `counts_monthly` top level keys in Usage Ping payload.
+Aggregated metrics are added under `aggregated_metrics` key in both `counts_weekly` and `counts_monthly` top level keys in Usage Ping payload.
 
 ```ruby
 {
diff --git a/doc/operations/incident_management/alert_integrations.md b/doc/operations/incident_management/alert_integrations.md
index 650c4fea645..c983216fda8 100644
--- a/doc/operations/incident_management/alert_integrations.md
+++ b/doc/operations/incident_management/alert_integrations.md
@@ -174,7 +174,7 @@ DANGER: **Deprecated:**
 We are building deeper integration with Opsgenie and other alerting tools through
 [HTTP endpoint integrations](#generic-http-endpoint) so you can see alerts within
 the GitLab interface. As a result, the previous direct link to Opsgenie Alerts from
-the GitLab alerts list will be deprecated following the 13.7 release on December 22, 2020.
+the GitLab alerts list is scheduled for deprecation following the 13.7 release on December 22, 2020.
 
 > [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3066) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.2.
 
diff --git a/doc/topics/autodevops/customize.md b/doc/topics/autodevops/customize.md
index 95b6241583f..7cd33766c32 100644
--- a/doc/topics/autodevops/customize.md
+++ b/doc/topics/autodevops/customize.md
@@ -38,7 +38,7 @@ For example:
 ### Multiple buildpacks
 
 Using multiple buildpacks is not fully supported by Auto DevOps, because Auto Test
-won't work when using the `.buildpacks` file. The buildpack
+can't use the `.buildpacks` file. The buildpack
 [heroku-buildpack-multi](https://github.com/heroku/heroku-buildpack-multi/), used
 in the backend to parse the `.buildpacks` file, does not provide the necessary commands
 `bin/test-compile` and `bin/test`.
@@ -133,7 +133,7 @@ You can override the Helm chart used by bundling up a chart into your project
 repository or by specifying a project variable:
 
 - **Bundled chart** - If your project has a `./chart` directory with a `Chart.yaml`
-  file in it, Auto DevOps will detect the chart and use it instead of the
+  file in it, Auto DevOps detects the chart and uses it instead of the
   [default chart](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/tree/master/assets/auto-deploy-app), enabling
   you to control exactly how your application is deployed.
 - **Project variable** - Create a [project variable](../../ci/variables/README.md#gitlab-cicd-environment-variables)
@@ -143,7 +143,7 @@ repository or by specifying a project variable:
 
 ## Customize values for Helm Chart
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30628) in GitLab 12.6, `.gitlab/auto-deploy-values.yaml` will be used by default for Helm upgrades.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30628) in GitLab 12.6, `.gitlab/auto-deploy-values.yaml` is used by default for Helm upgrades.
 
 You can override the default values in the `values.yaml` file in the
 [default Helm chart](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/tree/master/assets/auto-deploy-app) by either:
@@ -190,7 +190,7 @@ include:
   - template: Auto-DevOps.gitlab-ci.yml
 ```
 
-Add your changes, and your additions will be merged with the
+Add your changes, and your additions are merged with the
 [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)
 using the behavior described for [`include`](../../ci/yaml/README.md#include).
 
@@ -243,9 +243,9 @@ include:
 
 See the [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) for information on available jobs.
 
-CAUTION: **Deprecation:**
+DANGER: **Deprecated:**
 Auto DevOps templates using the [`only`](../../ci/yaml/README.md#onlyexcept-basic) or
-[`except`](../../ci/yaml/README.md#onlyexcept-basic) syntax will switch
+[`except`](../../ci/yaml/README.md#onlyexcept-basic) syntax have switched
 to the [`rules`](../../ci/yaml/README.md#rules) syntax, starting in
 [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/213336).
 If your `.gitlab-ci.yml` extends these Auto DevOps templates and override the `only` or
@@ -295,12 +295,12 @@ You must define environment-scoped variables for `POSTGRES_ENABLED` and
 
 1. Disable the built-in PostgreSQL installation for the required environments using
    scoped [environment variables](../../ci/environments/index.md#scoping-environments-with-specs).
-   For this use case, it's likely that only `production` will need to be added to this
+   For this use case, it's likely that only `production` must be added to this
    list. The built-in PostgreSQL setup for Review Apps and staging is sufficient.
 
    ![Auto Metrics](img/disable_postgres.png)
 
-1. Define the `DATABASE_URL` CI variable as a scoped environment variable that will be
+1. Define the `DATABASE_URL` CI variable as a scoped environment variable that is
    available to your application. This should be a URL in the following format:
 
    ```yaml
@@ -328,14 +328,14 @@ applications.
 | `AUTO_DEVOPS_ATOMIC_RELEASE`            | As of GitLab 13.0, Auto DevOps uses [`--atomic`](https://v2.helm.sh/docs/helm/#options-43) for Helm deployments by default. Set this variable to `false` to disable the use of `--atomic` |
 | `AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED`   | When set to a non-empty value and no `Dockerfile` is present, Auto Build builds your application using Cloud Native Buildpacks instead of Herokuish. [More details](stages.md#auto-build-using-cloud-native-buildpacks-beta). |
 | `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER`   | The builder used when building with Cloud Native Buildpacks. The default builder is `heroku/buildpacks:18`. [More details](stages.md#auto-build-using-cloud-native-buildpacks-beta). |
-| `AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS`    | Extra arguments to be passed to the `docker build` command. Note that using quotes won't prevent word splitting. [More details](#passing-arguments-to-docker-build). |
+| `AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS`    | Extra arguments to be passed to the `docker build` command. Note that using quotes doesn't prevent word splitting. [More details](#passing-arguments-to-docker-build). |
 | `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` | A [comma-separated list of CI variable names](#forward-ci-variables-to-the-build-environment) to be forwarded to the build environment (the buildpack builder or `docker build`). |
 | `AUTO_DEVOPS_CHART`                     | Helm Chart used to deploy your apps. Defaults to the one [provided by GitLab](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/tree/master/assets/auto-deploy-app). |
 | `AUTO_DEVOPS_CHART_REPOSITORY`          | Helm Chart repository used to search for charts. Defaults to `https://charts.gitlab.io`. |
 | `AUTO_DEVOPS_CHART_REPOSITORY_NAME`     | From GitLab 11.11, used to set the name of the Helm repository. Defaults to `gitlab`. |
 | `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME` | From GitLab 11.11, used to set a username to connect to the Helm repository. Defaults to no credentials. Also set `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD`. |
 | `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD` | From GitLab 11.11, used to set a password to connect to the Helm repository. Defaults to no credentials. Also set `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME`. |
-| `AUTO_DEVOPS_DEPLOY_DEBUG`              | From GitLab 13.1, if this variable is present, Helm will output debug logs. |
+| `AUTO_DEVOPS_DEPLOY_DEBUG`              | From GitLab 13.1, if this variable is present, Helm outputs debug logs. |
 | `AUTO_DEVOPS_ALLOW_TO_FORCE_DEPLOY_V<N>` | From [auto-deploy-image](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image) v1.0.0, if this variable is present, a new major version of chart is forcibly deployed. For more information, see [Ignore warnings and continue deploying](upgrading_auto_deploy_dependencies.md#ignore-warnings-and-continue-deploying). |
 | `AUTO_DEVOPS_MODSECURITY_SEC_RULE_ENGINE` | From GitLab 12.5, used in combination with [ModSecurity feature flag](../../user/clusters/applications.md#web-application-firewall-modsecurity) to toggle [ModSecurity's `SecRuleEngine`](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#SecRuleEngine) behavior. Defaults to `DetectionOnly`. |
 | `BUILDPACK_URL`                         | Buildpack's full URL. Can point to either [a Git repository URL or a tarball URL](#custom-buildpacks). |
@@ -345,9 +345,9 @@ applications.
 | `DOCKERFILE_PATH`                       | From GitLab 13.2, allows overriding the [default Dockerfile path for the build stage](#custom-dockerfile) |
 | `HELM_RELEASE_NAME`                     | From GitLab 12.1, allows the `helm` release name to be overridden. Can be used to assign unique release names when deploying multiple projects to a single namespace. |
 | `HELM_UPGRADE_VALUES_FILE`              | From GitLab 12.6, allows the `helm upgrade` values file to be overridden. Defaults to `.gitlab/auto-deploy-values.yaml`. |
-| `HELM_UPGRADE_EXTRA_ARGS`               | From GitLab 11.11, allows extra options in `helm upgrade` commands when deploying the application. Note that using quotes won't prevent word splitting. |
+| `HELM_UPGRADE_EXTRA_ARGS`               | From GitLab 11.11, allows extra options in `helm upgrade` commands when deploying the application. Note that using quotes doesn't prevent word splitting. |
 | `INCREMENTAL_ROLLOUT_MODE`              | From GitLab 11.4, if present, can be used to enable an [incremental rollout](#incremental-rollout-to-production) of your application for the production environment. Set to `manual` for manual deployment jobs or `timed` for automatic rollout deployments with a 5 minute delay each one. |
-| `K8S_SECRET_*`                          | From GitLab 11.7, any variable prefixed with [`K8S_SECRET_`](#application-secret-variables) will be made available by Auto DevOps as environment variables to the deployed application. |
+| `K8S_SECRET_*`                          | From GitLab 11.7, any variable prefixed with [`K8S_SECRET_`](#application-secret-variables) is made available by Auto DevOps as environment variables to the deployed application. |
 | `KUBE_INGRESS_BASE_DOMAIN`              | From GitLab 11.8, can be used to set a domain per cluster. See [cluster domains](../../user/project/clusters/index.md#base-domain) for more information. |
 | `PRODUCTION_REPLICAS`                   | Number of replicas to deploy in the production environment. Takes precedence over `REPLICAS` and defaults to 1. For zero downtime upgrades, set to 2 or greater. |
 | `REPLICAS`                              | Number of replicas to deploy. Defaults to 1. |
@@ -377,7 +377,7 @@ The following table lists variables related to the database.
 | `POSTGRES_USER`                         | The PostgreSQL user. Defaults to `user`. Set it to use a custom username. |
 | `POSTGRES_PASSWORD`                     | The PostgreSQL password. Defaults to `testing-password`. Set it to use a custom password. |
 | `POSTGRES_DB`                           | The PostgreSQL database name. Defaults to the value of [`$CI_ENVIRONMENT_SLUG`](../../ci/variables/README.md#predefined-environment-variables). Set it to use a custom database name. |
-| `POSTGRES_VERSION`                      | Tag for the [`postgres` Docker image](https://hub.docker.com/_/postgres) to use. Defaults to `9.6.16` for tests and deployments as of GitLab 13.0 (previously `9.6.2`). If `AUTO_DEVOPS_POSTGRES_CHANNEL` is set to `1`, deployments will use the default version `9.6.2`. |
+| `POSTGRES_VERSION`                      | Tag for the [`postgres` Docker image](https://hub.docker.com/_/postgres) to use. Defaults to `9.6.16` for tests and deployments as of GitLab 13.0 (previously `9.6.2`). If `AUTO_DEVOPS_POSTGRES_CHANNEL` is set to `1`, deployments uses the default version `9.6.2`. |
 
 ### Disable jobs
 
@@ -385,18 +385,18 @@ The following table lists variables used to disable jobs.
 
 | **Variable**                            | **Description**                    |
 |-----------------------------------------|------------------------------------|
-| `CODE_QUALITY_DISABLED`                 | From GitLab 11.0, used to disable the `codequality` job. If the variable is present, the job won't be created. |
-| `CONTAINER_SCANNING_DISABLED`           | From GitLab 11.0, used to disable the `sast:container` job. If the variable is present, the job won't be created. |
-| `DAST_DISABLED`                         | From GitLab 11.0, used to disable the `dast` job. If the variable is present, the job won't be created. |
-| `DEPENDENCY_SCANNING_DISABLED`          | From GitLab 11.0, used to disable the `dependency_scanning` job. If the variable is present, the job won't be created. |
-| `LICENSE_MANAGEMENT_DISABLED`           | From GitLab 11.0, used to disable the `license_management` job. If the variable is present, the job won't be created. |
-| `PERFORMANCE_DISABLED`                  | From GitLab 11.0, used to disable the browser `performance` job. If the variable is present, the job won't be created. |
-| `LOAD_PERFORMANCE_DISABLED`             | From GitLab 13.2, used to disable the `load_performance` job. If the variable is present, the job won't be created. |
-| `REVIEW_DISABLED`                       | From GitLab 11.0, used to disable the `review` and the manual `review:stop` job. If the variable is present, these jobs won't be created. |
-| `SAST_DISABLED`                         | From GitLab 11.0, used to disable the `sast` job. If the variable is present, the job won't be created. |
-| `TEST_DISABLED`                         | From GitLab 11.0, used to disable the `test` job. If the variable is present, the job won't be created. |
-| `SECRET_DETECTION_DISABLED`             | From GitLab 13.1, used to disable the `secret_detection` job. If the variable is present, the job won't be created. |
-| `CODE_INTELLIGENCE_DISABLED`            | From GitLab 13.6, used to disable the `code_intelligence` job. If the variable is present, the job won't be created. |
+| `CODE_QUALITY_DISABLED`                 | From GitLab 11.0, used to disable the `codequality` job. If the variable is present, the job isn't created. |
+| `CONTAINER_SCANNING_DISABLED`           | From GitLab 11.0, used to disable the `sast:container` job. If the variable is present, the job isn't created. |
+| `DAST_DISABLED`                         | From GitLab 11.0, used to disable the `dast` job. If the variable is present, the job isn't created. |
+| `DEPENDENCY_SCANNING_DISABLED`          | From GitLab 11.0, used to disable the `dependency_scanning` job. If the variable is present, the job isn't created. |
+| `LICENSE_MANAGEMENT_DISABLED`           | From GitLab 11.0, used to disable the `license_management` job. If the variable is present, the job isn't created. |
+| `PERFORMANCE_DISABLED`                  | From GitLab 11.0, used to disable the browser `performance` job. If the variable is present, the job isn't created. |
+| `LOAD_PERFORMANCE_DISABLED`             | From GitLab 13.2, used to disable the `load_performance` job. If the variable is present, the job isn't created. |
+| `REVIEW_DISABLED`                       | From GitLab 11.0, used to disable the `review` and the manual `review:stop` job. If the variable is present, these jobs isn't created. |
+| `SAST_DISABLED`                         | From GitLab 11.0, used to disable the `sast` job. If the variable is present, the job isn't created. |
+| `TEST_DISABLED`                         | From GitLab 11.0, used to disable the `test` job. If the variable is present, the job isn't created. |
+| `SECRET_DETECTION_DISABLED`             | From GitLab 13.1, used to disable the `secret_detection` job. If the variable is present, the job isn't created. |
+| `CODE_INTELLIGENCE_DISABLED`            | From GitLab 13.6, used to disable the `code_intelligence` job. If the variable is present, the job isn't created. |
 
 ### Application secret variables
 
@@ -418,7 +418,7 @@ To configure your application variables:
 1. Run an Auto DevOps pipeline, either by manually creating a new
    pipeline or by pushing a code change to GitLab.
 
-Auto DevOps pipelines will take your application secret variables to
+Auto DevOps pipelines take your application secret variables to
 populate a Kubernetes secret. This secret is unique per environment.
 When deploying your application, the secret is loaded as environment
 variables in the container running the application. Following the
@@ -444,7 +444,7 @@ type: Opaque
 
 Environment variables are generally considered immutable in a Kubernetes pod.
 If you update an application secret without changing any code, then manually
-create a new pipeline, you will find any running application pods won't have
+create a new pipeline, any running application pods don't receive
 the updated secrets. To update the secrets, either:
 
 - Push a code update to GitLab to force the Kubernetes deployment to recreate pods.
@@ -465,7 +465,7 @@ enabling you to define your own variables for scaling the pod's replicas:
 
 - `TRACK`: The capitalized value of the `track`
   [Kubernetes label](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
-  in the Helm Chart app definition. If not set, it won't be taken into account
+  in the Helm Chart app definition. If not set, it isn't taken into account
   to the variable name.
 - `ENV`: The capitalized environment name of the deploy job, set in
   `.gitlab-ci.yml`.
@@ -547,7 +547,7 @@ check how the application is behaving before manually increasing the rollout up
 If `INCREMENTAL_ROLLOUT_MODE` is set to `manual` in your project, then instead
 of the standard `production` job, 4 different
 [manual jobs](../../ci/pipelines/index.md#add-manual-interaction-to-your-pipeline)
-will be created:
+are created:
 
 1. `rollout 10%`
 1. `rollout 25%`
@@ -556,7 +556,7 @@ will be created:
 
 The percentage is based on the `REPLICAS` variable, and defines the number of
 pods you want to have for your deployment. If the value is `10`, and you run the
-`10%` rollout job, there will be `1` new pod + `9` old ones.
+`10%` rollout job, there is `1` new pod and `9` old ones.
 
 To start a job, click the play icon (**{play}**) next to the job's name. You're not
 required to go from `10%` to `100%`, you can jump to whatever job you want.
@@ -566,7 +566,7 @@ back by redeploying the old version using the
 [rollback button](../../ci/environments/index.md#retrying-and-rolling-back) in the
 environment page.
 
-Below, you can see how the pipeline will look if the rollout or staging
+Below, you can see how the pipeline appears if the rollout or staging
 variables are defined.
 
 Without `INCREMENTAL_ROLLOUT_MODE` and without `STAGING_ENABLED`:
@@ -585,9 +585,9 @@ With `INCREMENTAL_ROLLOUT_MODE` set to `manual` and with `STAGING_ENABLED`
 
 ![Rollout and staging enabled](img/rollout_staging_enabled.png)
 
-CAUTION: **Caution:**
+WARNING: **Deprecation:**
 Before GitLab 11.4, the presence of the `INCREMENTAL_ROLLOUT_ENABLED` environment
-variable enabled this feature. This configuration is deprecated, and will be
+variable enabled this feature. This configuration is deprecated, and is scheduled to be
 removed in the future.
 
 ### Timed incremental rollout to production **(PREMIUM)**
diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md
index 014690c4cdf..f34c8c947e1 100644
--- a/doc/topics/autodevops/index.md
+++ b/doc/topics/autodevops/index.md
@@ -49,7 +49,7 @@ runs on pipelines automatically only if a [`Dockerfile` or matching buildpack](s
 exists.
 
 If a [CI/CD configuration file](../../ci/yaml/README.md) is present in the project,
-it will continue to be used, whether or not Auto DevOps is enabled.
+it continues to be used, whether or not Auto DevOps is enabled.
 
 ## Quick start
 
@@ -146,7 +146,7 @@ any of the following places:
 The base domain variable `KUBE_INGRESS_BASE_DOMAIN` follows the same order of precedence
 as other environment [variables](../../ci/variables/README.md#priority-of-environment-variables).
 If the CI/CD variable is not set and the cluster setting is left blank, the instance-wide **Auto DevOps domain**
-setting will be used if set.
+setting is used if set.
 
 TIP: **Tip:**
 If you use the [GitLab managed app for Ingress](../../user/clusters/applications.md#ingress),
@@ -236,7 +236,7 @@ Auto DevOps at the group and project level, respectively.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/38542) in GitLab 11.0.
 
-You can change the deployment strategy used by Auto DevOps by going to your
+You can change the deployment strategy used by Auto DevOps by visiting your
 project's **Settings > CI/CD > Auto DevOps**. The following options
 are available:
 
@@ -372,7 +372,7 @@ To fix this issue, you must either:
 
 ### Failure to create a Kubernetes namespace
 
-Auto Deploy will fail if GitLab can't create a Kubernetes namespace and
+Auto Deploy fails if GitLab can't create a Kubernetes namespace and
 service account for your project. For help debugging this issue, see
 [Troubleshooting failed deployment jobs](../../user/project/clusters/index.md#troubleshooting).
 
@@ -476,7 +476,7 @@ that works for this problem. Follow these steps to use the tool in Auto DevOps:
 ### Error: error initializing: Looks like "https://kubernetes-charts.storage.googleapis.com" is not a valid chart repository or cannot be reached
 
 As [announced in the official CNCF blogpost](https://www.cncf.io/blog/2020/10/07/important-reminder-for-all-helm-users-stable-incubator-repos-are-deprecated-and-all-images-are-changing-location/),
-the stable Helm chart repository will be deprecated and removed on November 13th, 2020.
+the stable Helm chart repository was deprecated and removed on November 13th, 2020.
 You may encounter this error after that date.
 
 Some GitLab features had dependencies on the stable chart. To mitigate the impact, we changed them
@@ -495,7 +495,7 @@ include:
   image: "registry.gitlab.com/gitlab-org/cluster-integration/auto-deploy-image:v1.0.5"
 ```
 
-Keep in mind that this approach will eventually stop working when the stable repository is removed,
+Keep in mind that this approach stops working when the stable repository is removed,
 so you must eventually fix your custom chart.
 
 To fix your custom chart:
diff --git a/doc/topics/autodevops/quick_start_guide.md b/doc/topics/autodevops/quick_start_guide.md
index 3531035eb67..b19cb5eeb86 100644
--- a/doc/topics/autodevops/quick_start_guide.md
+++ b/doc/topics/autodevops/quick_start_guide.md
@@ -6,15 +6,15 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Getting started with Auto DevOps
 
-This step-by-step guide will help you use [Auto DevOps](index.md) to
+This step-by-step guide helps you use [Auto DevOps](index.md) to
 deploy a project hosted on GitLab.com to Google Kubernetes Engine.
 
-You will use GitLab's native Kubernetes integration, so you won't need
+You are using GitLab's native Kubernetes integration, so you don't need
 to create a Kubernetes cluster manually using the Google Cloud Platform console.
-You will create and deploy a simple application that you create from a GitLab template.
+You are creating and deploying a simple application that you create from a GitLab template.
 
-These instructions will also work for a self-managed GitLab instance; you'll just
-need to ensure your own [runners are configured](../../ci/runners/README.md) and
+These instructions also work for a self-managed GitLab instance;
+ensure your own [runners are configured](../../ci/runners/README.md) and
 [Google OAuth is enabled](../../integration/google.md).
 
 ## Configure your Google account
@@ -38,7 +38,7 @@ and apply for credit.
 
 ## Create a new project from a template
 
-We will use one of GitLab's project templates to get started. As the name suggests,
+We are using one of GitLab's project templates to get started. As the name suggests,
 those projects provide a bare-bones application built on some well-known frameworks.
 
 1. In GitLab, click the plus icon (**{plus-square}**) at the top of the navigation bar, and select
@@ -57,7 +57,7 @@ those projects provide a bare-bones application built on some well-known framewo
 
 1. Click **Create project**.
 
-Now that you've created a project, you'll next create the Kubernetes cluster
+Now that you've created a project, create the Kubernetes cluster
 to deploy this project to.
 
 ## Create a Kubernetes cluster from within GitLab
@@ -98,30 +98,30 @@ to deploy this project to.
 
 1. Click **Create Kubernetes cluster**.
 
-After a couple of minutes, the cluster will be created. You can also see its
+After a couple of minutes, the cluster is created. You can also see its
 status on your [GCP dashboard](https://console.cloud.google.com/kubernetes).
 
-Next, you will install some applications on your cluster that are needed
+Next, install some applications on your cluster that are needed
 to take full advantage of Auto DevOps.
 
 ## Install Ingress and Prometheus
 
-After your cluster is running, you can install your first applications.
-In this guide, we will install Ingress and Prometheus:
+After your cluster is running, you can install your first applications,
+Ingress and Prometheus:
 
 - Ingress - Provides load balancing, SSL termination, and name-based virtual hosting,
   using NGINX behind the scenes.
 - Prometheus - An open-source monitoring and alerting system used to supervise the
   deployed application.
 
-We won't install GitLab Runner in this quick start guide, as this guide uses the
+We aren't installing GitLab Runner in this quick start guide, as this guide uses the
 shared runners provided by GitLab.com.
 
 To install the applications:
 
 - Click the **Install** button for **Ingress**.
 - When the **Ingress Endpoint** is displayed, copy the IP address.
-- Add your **Base domain**. For this guide, we will use the domain suggested by GitLab.
+- Add your **Base domain**. For this guide, use the domain suggested by GitLab.
 - Click **Save changes**.
 
 ![Cluster Base Domain](img/guide_base_domain_v12_3.png)
@@ -251,7 +251,7 @@ a few more that run only on branches other than `master`.
 
 ![Merge request](img/guide_merge_request_v12_3.png)
 
-After a few minutes you'll notice a test failed, which means a test was
+After a few minutes a test fails, which means a test was
 'broken' by your change. Click on the failed `test` job to see more information
 about it:
 
diff --git a/doc/topics/autodevops/requirements.md b/doc/topics/autodevops/requirements.md
index acec7b79d6b..671d85066f9 100644
--- a/doc/topics/autodevops/requirements.md
+++ b/doc/topics/autodevops/requirements.md
@@ -46,7 +46,7 @@ To make full use of Auto DevOps with Kubernetes, you need:
   [Auto Deploy](stages.md#auto-deploy), and [Auto Monitoring](stages.md#auto-monitoring))
 
   You need a domain configured with wildcard DNS, which all of your Auto DevOps
-  applications will use. If you're using the
+  applications use. If you're using the
   [GitLab-managed app for Ingress](../../user/clusters/applications.md#ingress),
   the URL endpoint is automatically configured for you.
 
@@ -111,7 +111,7 @@ After all requirements are met, you can [enable Auto DevOps](index.md#enablingdi
 
 You can choose to target [AWS ECS](../../ci/cloud_deployment/index.md) as a deployment platform instead of using Kubernetes.
 
-To get started on Auto DevOps to AWS ECS, you'll have to add a specific Environment
+To get started on Auto DevOps to AWS ECS, you must add a specific Environment
 Variable. To do so, follow these steps:
 
 1. In your project, go to **Settings > CI / CD** and expand the **Variables**
@@ -124,19 +124,19 @@ Variable. To do so, follow these steps:
 
 When you trigger a pipeline, if you have Auto DevOps enabled and if you have correctly
 [entered AWS credentials as environment variables](../../ci/cloud_deployment/index.md#deploy-your-application-to-the-aws-elastic-container-service-ecs),
-your application will be deployed to AWS ECS.
+your application is deployed to AWS ECS.
 
 [GitLab Managed Apps](../../user/clusters/applications.md) are not available when deploying to AWS ECS.
 You must manually configure your application (such as Ingress or Help) on AWS ECS.
 
 If you have both a valid `AUTO_DEVOPS_PLATFORM_TARGET` variable and a Kubernetes cluster tied to your project,
-only the deployment to Kubernetes will run.
+only the deployment to Kubernetes runs.
 
 CAUTION: **Warning:**
-Setting the `AUTO_DEVOPS_PLATFORM_TARGET` variable to `ECS` will trigger jobs
+Setting the `AUTO_DEVOPS_PLATFORM_TARGET` variable to `ECS` triggers jobs
 defined in the [`Jobs/Deploy/ECS.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy/ECS.gitlab-ci.yml).
 However, it's not recommended to [include](../../ci/yaml/README.md#includetemplate)
 it on its own. This template is designed to be used with Auto DevOps only. It may change
 unexpectedly causing your pipeline to fail if included on its own. Also, the job
 names within this template may also change. Do not override these jobs' names in your
-own pipeline, as the override will stop working when the name changes.
+own pipeline, as the override stops working when the name changes.
diff --git a/doc/topics/autodevops/stages.md b/doc/topics/autodevops/stages.md
index f2d3b78e2b0..b2be2038db6 100644
--- a/doc/topics/autodevops/stages.md
+++ b/doc/topics/autodevops/stages.md
@@ -64,7 +64,7 @@ value. The default builder is `heroku/buildpacks:18` but a different builder
 can be selected using the CI variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER`.
 
 Cloud Native Buildpacks (CNBs) are an evolution of Heroku buildpacks, and
-will eventually supersede Herokuish-based builds within Auto DevOps. For more
+GitLab expects them to eventually supersede Herokuish-based builds within Auto DevOps. For more
 information, see [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/212692).
 
 Builds using Cloud Native Buildpacks support the same options as builds using
@@ -150,7 +150,7 @@ out. The merge request widget also displays any
 Static Application Security Testing (SAST) uses the
 [SAST Docker image](https://gitlab.com/gitlab-org/security-products/sast) to run static
 analysis on the current code, and checks for potential security issues. The
-Auto SAST stage will be skipped on licenses other than
+Auto SAST stage is skipped on licenses other than
 [Ultimate](https://about.gitlab.com/pricing/), and requires
 [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 or above.
 
@@ -387,16 +387,16 @@ in the first place, and thus not realize that it needs to re-apply the old confi
 [GitLab Deploy Tokens](../../user/project/deploy_tokens/index.md#gitlab-deploy-token)
 are created for internal and private projects when Auto DevOps is enabled, and the
 Auto DevOps settings are saved. You can use a Deploy Token for permanent access to
-the registry. After you manually revoke the GitLab Deploy Token, it won't be
+the registry. After you manually revoke the GitLab Deploy Token, it isn't
 automatically created.
 
 If the GitLab Deploy Token can't be found, `CI_REGISTRY_PASSWORD` is
 used.
 
 NOTE: **Note:**
-`CI_REGISTRY_PASSWORD` is only valid during deployment. Kubernetes will be able
-to successfully pull the container image during deployment, but if the image must
-be pulled again, such as after pod eviction, Kubernetes will fail to do so
+`CI_REGISTRY_PASSWORD` is only valid during deployment. Kubernetes can
+successfully pull the container image during deployment, but if the image must
+be pulled again, such as after pod eviction, Kubernetes cannot do so
 as it attempts to fetch the image using `CI_REGISTRY_PASSWORD`.
 
 ### Kubernetes 1.16+
@@ -455,7 +455,7 @@ initialization completes, GitLab deploys a second release with the application
 deployment as normal.
 
 Note that a post-install hook means that if any deploy succeeds,
-`DB_INITIALIZE` won't be processed thereafter.
+`DB_INITIALIZE` isn't processed thereafter.
 
 If present, `DB_MIGRATE` is run as a shell command within an application pod as
 a Helm pre-upgrade hook.
@@ -492,7 +492,7 @@ the standard health checks, which expect a successful HTTP response on port
 the [`sidekiq_alive` gem](https://rubygems.org/gems/sidekiq_alive).
 
 To work with Sidekiq, you must also ensure your deployments have
-access to a Redis instance. Auto DevOps won't deploy this instance for you, so
+access to a Redis instance. Auto DevOps doesn't deploy this instance for you, so
 you must:
 
 - Maintain your own Redis instance.
diff --git a/doc/topics/autodevops/upgrading_postgresql.md b/doc/topics/autodevops/upgrading_postgresql.md
index a3c9f562f5e..6a13a036d49 100644
--- a/doc/topics/autodevops/upgrading_postgresql.md
+++ b/doc/topics/autodevops/upgrading_postgresql.md
@@ -79,7 +79,7 @@ being modified after the database dump is created.
     deployment.extensions/production scaled
     ```
 
-1. You also will need to set replicas to zero for workers if you have any.
+1. You must also set replicas to zero for workers if you have any.
 
 ## Backup
 
@@ -112,7 +112,7 @@ being modified after the database dump is created.
    - `USERNAME` is the username you have configured for PostgreSQL. The default is `user`.
    - `DATABASE_NAME` is usually the environment name.
 
-   - You will be asked for the database password, the default is `testing-password`.
+   - When prompted for the database password, the default is `testing-password`.
 
     ```shell
     ## Format is:
@@ -169,7 +169,7 @@ pvc-9085e3d3-5239-11ea-9c8d-42010a8e0096   8Gi        RWO            Retain
 ## Install new PostgreSQL
 
 CAUTION: **Caution:**
-Using the newer version of PostgreSQL will delete
+Using the newer version of PostgreSQL deletes
 the older 0.7.1 PostgreSQL. To prevent the underlying data from being
 deleted, you can choose to retain the [persistent volume](#retain-persistent-volumes).
 
@@ -196,9 +196,9 @@ higher*. This is the
    `XDB_INITIALIZE` or the `XDB_MIGRATE` to effectively disable them.
 1. Run a new CI pipeline for the branch. In this case, we run a new CI
    pipeline for `master`.
-1. Once the pipeline is successful, your application will now be upgraded
-   with the new PostgreSQL installed. There will also be zero replicas
-   which means no traffic will be served for your application (to prevent
+1. After the pipeline is successful, your application is upgraded
+   with the new PostgreSQL installed. Zero replicas exist at this time, so
+   no traffic is served for your application (to prevent
    new data from coming in).
 
 ## Restore
@@ -226,7 +226,7 @@ higher*. This is the
 
 1. Once connected to the pod, run the following command to restore the database.
 
-   - You will be asked for the database password, the default is `testing-password`.
+   - When asked for the database password, the default is `testing-password`.
    - `USERNAME` is the username you have configured for PostgreSQL. The default is `user`.
    - `DATABASE_NAME` is usually the environment name.
 
diff --git a/doc/user/clusters/applications.md b/doc/user/clusters/applications.md
index 6de32b16767..42e4cd58885 100644
--- a/doc/user/clusters/applications.md
+++ b/doc/user/clusters/applications.md
@@ -78,7 +78,7 @@ in a pod within the `gitlab-managed-apps` namespace inside the cluster.
   to [GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/issues/209736), GitLab
   used an in-cluster Tiller server in the `gitlab-managed-apps` namespace. You
   can safely uninstall the server from GitLab's application page if you have
-  previously installed it. This will not affect your other applications.
+  previously installed it. This doesn't affect your other applications.
 
 GitLab's Helm integration does not support installing applications behind a proxy,
 but a [workaround](../../topics/autodevops/index.md#install-applications-behind-a-proxy)
@@ -233,7 +233,7 @@ rules that allow external access to your deployed applications.
   ```
 
   If EKS is used, an [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/)
-  is also created, which will incur additional AWS costs.
+  is also created, which incurs additional AWS costs.
 
 - For Istio/Knative, the command is different:
 
@@ -258,7 +258,7 @@ a wildcard DNS CNAME record for the desired domain name. For example,
 
 By default, an ephemeral external IP address is associated to the cluster's load
 balancer. If you associate the ephemeral IP with your DNS and the IP changes,
-your apps won't be reachable, and you'd have to change the DNS record again.
+your apps aren't reachable, and you'd have to change the DNS record again.
 To avoid that, change it into a static reserved IP.
 
 Read how to [promote an ephemeral external IP address in GKE](https://cloud.google.com/compute/docs/ip-addresses/reserve-static-external-ip-address#promote_ephemeral_ip).
@@ -439,7 +439,7 @@ The [`knative/knative`](https://storage.googleapis.com/triggermesh-charts)
 chart is used to install this application.
 
 During installation, you must enter a wildcard domain where your applications
-will be exposed. Configure your DNS server to use the external IP address for that
+are exposed. Configure your DNS server to use the external IP address for that
 domain. Applications created and installed are accessible as
 `<program_name>.<kubernetes_namespace>.<domain_name>`, which requires
 your Kubernetes cluster to have
@@ -668,8 +668,8 @@ is saved as a [CI job artifact](../../ci/pipelines/job_artifacts.md).
 For GitLab versions 13.5 and below, the Ingress, Fluentd, Prometheus,
 and Sentry apps are fetched from the central Helm [stable
 repository](https://kubernetes-charts.storage.googleapis.com/), which
-will be [deleted](https://github.com/helm/charts#deprecation-timeline)
-on November 13, 2020. This will cause the installation CI/CD pipeline to
+is [scheduled for deletion](https://github.com/helm/charts#deprecation-timeline)
+on November 13, 2020. This causes the installation CI/CD pipeline to
 fail. Upgrade to GitLab 13.6, or alternatively, you can
 use the following `.gitlab-ci.yml`, which has been tested on GitLab
 13.5:
diff --git a/doc/user/clusters/cost_management.md b/doc/user/clusters/cost_management.md
index f13be15c6bc..d6d39e59870 100644
--- a/doc/user/clusters/cost_management.md
+++ b/doc/user/clusters/cost_management.md
@@ -58,7 +58,7 @@ file or creating similar dashboard configuration files. To learn more, read abou
 
 #### Available metrics
 
-Metrics contain both instance and node labels. The instance label will be deprecated in a future version.
+Metrics contain both instance and node labels. The instance label is scheduled for deprecation in a future version.
 
 - `node_cpu_hourly_cost` - Hourly cost per vCPU on this node.
 - `node_gpu_hourly_cost` - Hourly cost per GPU on this node.
diff --git a/doc/user/clusters/management_project.md b/doc/user/clusters/management_project.md
index f7241444a6b..7b174fadceb 100644
--- a/doc/user/clusters/management_project.md
+++ b/doc/user/clusters/management_project.md
@@ -4,7 +4,7 @@ group: Configure
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
 ---
 
-# Cluster management project (alpha)
+# Cluster management project
 
 CAUTION: **Warning:**
 This is an _alpha_ feature, and it is subject to change at any time without
@@ -25,8 +25,8 @@ This can be useful for:
 
 ## Permissions
 
-Only the management project will receive `cluster-admin` privileges. All
-other projects will continue to receive [namespace scoped `edit` level privileges](../project/clusters/add_remove_clusters.md#rbac-cluster-resources).
+Only the management project receives `cluster-admin` privileges. All
+other projects continue to receive [namespace scoped `edit` level privileges](../project/clusters/add_remove_clusters.md#rbac-cluster-resources).
 
 Management projects are restricted to the following:
 
@@ -92,7 +92,7 @@ to a management project:
 | Production  | `production`      |
 
 The following environments set in
-[`.gitlab-ci.yml`](../../ci/yaml/README.md) will deploy to the
+[`.gitlab-ci.yml`](../../ci/yaml/README.md) deploy to the
 Development, Staging, and Production cluster respectively.
 
 ```yaml
diff --git a/doc/user/group/clusters/index.md b/doc/user/group/clusters/index.md
index 1a62d67e468..7fbff8d1202 100644
--- a/doc/user/group/clusters/index.md
+++ b/doc/user/group/clusters/index.md
@@ -58,11 +58,11 @@ differentiate the new cluster from your other clusters.
 > - Became [optional](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/26565) in GitLab 11.11.
 
 You can choose to allow GitLab to manage your cluster for you. If GitLab manages
-your cluster, resources for your projects will be automatically created. See the
+your cluster, resources for your projects are automatically created. See the
 [Access controls](../../project/clusters/add_remove_clusters.md#access-controls)
 section for details on which resources GitLab creates for you.
 
-For clusters not managed by GitLab, project-specific resources won't be created
+For clusters not managed by GitLab, project-specific resources aren't created
 automatically. If you're using [Auto DevOps](../../../topics/autodevops/index.md)
 for deployments with a cluster not managed by GitLab, you must ensure:
 
@@ -97,7 +97,7 @@ To clear the cache:
 
 Domains at the cluster level permit support for multiple domains
 per [multiple Kubernetes clusters](#multiple-kubernetes-clusters) When specifying a domain,
-this will be automatically set as an environment variable (`KUBE_INGRESS_BASE_DOMAIN`) during
+this is automatically set as an environment variable (`KUBE_INGRESS_BASE_DOMAIN`) during
 the [Auto DevOps](../../../topics/autodevops/index.md) stages.
 
 The domain should have a wildcard DNS configured to the Ingress IP address.
diff --git a/doc/user/group/epics/index.md b/doc/user/group/epics/index.md
index e98c4b416fe..faae1c68392 100644
--- a/doc/user/group/epics/index.md
+++ b/doc/user/group/epics/index.md
@@ -10,8 +10,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.2.
 > - Single-level Epics [were moved](https://gitlab.com/gitlab-org/gitlab/-/issues/37081) to [GitLab Premium](https://about.gitlab.com/pricing/) in 12.8.
 
-Epics let you manage your portfolio of projects more efficiently by tracking groups of issues that
-share a theme across projects and milestones.
+Epics let you manage your portfolio of projects more efficiently by tracking groups of [issues](../../project/issues/index.md)
+that share a theme across projects and milestones.
 
 An epic's page contains the following tabs:
 
diff --git a/doc/user/project/clusters/add_eks_clusters.md b/doc/user/project/clusters/add_eks_clusters.md
index c3f2b96ce9f..1ba70c96dcd 100644
--- a/doc/user/project/clusters/add_eks_clusters.md
+++ b/doc/user/project/clusters/add_eks_clusters.md
@@ -23,9 +23,9 @@ requirements are met:
 ### Additional requirements for self-managed instances **(CORE ONLY)**
 
 If you are using a self-managed GitLab instance, GitLab must first be configured with a set of
-Amazon credentials. These credentials will be used to assume an Amazon IAM role provided by the user
+Amazon credentials. These credentials are used to assume an Amazon IAM role provided by the user
 creating the cluster. Create an IAM user and ensure it has permissions to assume the role(s) that
-your users will use to create EKS clusters.
+your users need to create EKS clusters.
 
 For example, the following policy document allows assuming a role whose name starts with
 `gitlab-eks-` in account `123456789012`:
@@ -60,7 +60,7 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
    - Group's **Kubernetes** page, for a group-level cluster.
    - **Admin Area > Kubernetes**, for an instance-level cluster.
 1. Click **Add Kubernetes cluster**.
-1. Under the **Create new cluster** tab, click **Amazon EKS**. You will be provided with an
+1. Under the **Create new cluster** tab, click **Amazon EKS** to display an
    `Account ID` and `External ID` needed for later steps.
 1. In the [IAM Management Console](https://console.aws.amazon.com/iam/home), create an IAM policy:
    1. From the left panel, select **Policies**.
@@ -137,9 +137,9 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
    1. Click **Next: Tags**, and optionally enter any tags you wish to associate with this role.
    1. Click **Next: Review**.
    1. Enter a role name and optional description into the fields provided.
-   1. Click **Create role**, the new role name will appear at the top. Click on its name and copy the `Role ARN` from the newly created role.
+   1. Click **Create role**, the new role name displays at the top. Click on its name and copy the `Role ARN` from the newly created role.
 1. In GitLab, enter the copied role ARN into the `Role ARN` field.
-1. In the **Cluster Region** field, enter the [region](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) you plan to use for your new cluster. GitLab will authenticate you have access to this region when authenticating your role.
+1. In the **Cluster Region** field, enter the [region](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) you plan to use for your new cluster. GitLab confirms you have access to this region when authenticating your role.
 1. Click **Authenticate with AWS**.
 1. Choose your cluster's settings:
    - **Kubernetes cluster name** - The name you wish to give the cluster.
@@ -158,7 +158,7 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
    - **VPC** - Select a [VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
      to use for your EKS Cluster resources.
    - **Subnets** - Choose the [subnets](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html)
-     in your VPC where your worker nodes will run. You must select at least two.
+     in your VPC where your worker nodes run. You must select at least two.
    - **Security group** - Choose the [security group](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)
      to apply to the EKS-managed Elastic Network Interfaces that are created in your worker node subnets.
    - **Instance type** - The [instance type](https://aws.amazon.com/ec2/instance-types/) of your worker nodes.
@@ -167,11 +167,11 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
      See the [Managed clusters section](index.md#gitlab-managed-clusters) for more information.
 1. Finally, click the **Create Kubernetes cluster** button.
 
-After about 10 minutes, your cluster will be ready to go. You can now proceed
+After about 10 minutes, your cluster is ready to go. You can now proceed
 to install some [pre-defined applications](index.md#installing-applications).
 
 NOTE: **Note:**
-You will need to add your AWS external ID to the
+You must add your AWS external ID to the
 [IAM Role in the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html#cli-configure-role-xaccount)
 to manage your cluster using `kubectl`.
 
@@ -219,9 +219,9 @@ For information on adding an existing EKS cluster, see
 ### Create a default Storage Class
 
 Amazon EKS doesn't have a default Storage Class out of the box, which means
-requests for persistent volumes will not be automatically fulfilled. As part
+requests for persistent volumes are not automatically fulfilled. As part
 of Auto DevOps, the deployed PostgreSQL instance requests persistent storage,
-and without a default storage class it will fail to start.
+and without a default storage class it cannot start.
 
 If a default Storage Class doesn't already exist and is desired, follow Amazon's
 [guide on storage classes](https://docs.aws.amazon.com/eks/latest/userguide/storage-classes.html)
@@ -239,18 +239,17 @@ to build, test, and deploy the app.
 [Enable Auto DevOps](../../../topics/autodevops/index.md#at-the-project-level)
 if not already enabled. If a wildcard DNS entry was created resolving to the
 Load Balancer, enter it in the `domain` field under the Auto DevOps settings.
-Otherwise, the deployed app will not be externally available outside of the cluster.
+Otherwise, the deployed app isn't externally available outside of the cluster.
 
 ![Deploy Pipeline](img/pipeline.png)
 
-A new pipeline will automatically be created, which will begin to build, test,
-and deploy the app.
+GitLab creates a new pipeline, which begins to build, test, and deploy the app.
 
-After the pipeline has finished, your app will be running in EKS and available
+After the pipeline has finished, your app runs in EKS, and is available
 to users. Click on **CI/CD > Environments**.
 
 ![Deployed Environment](img/environment.png)
 
-You will see a list of the environments and their deploy status, as well as
+GitLab displays a list of the environments and their deploy status, as well as
 options to browse to the app, view monitoring metrics, and even access a shell
 on the running pod.
diff --git a/doc/user/project/clusters/add_gke_clusters.md b/doc/user/project/clusters/add_gke_clusters.md
index 720f9bdf253..c4bfddb092a 100644
--- a/doc/user/project/clusters/add_gke_clusters.md
+++ b/doc/user/project/clusters/add_gke_clusters.md
@@ -33,7 +33,7 @@ Note the following:
   created by GitLab are RBAC-enabled. Take a look at the [RBAC section](add_remove_clusters.md#rbac-cluster-resources) for
   more information.
 - Starting from [GitLab 12.5](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18341), the
-  cluster's pod address IP range will be set to /16 instead of the regular /14. /16 is a CIDR
+  cluster's pod address IP range is set to `/16` instead of the regular `/14`. `/16` is a CIDR
   notation.
 - GitLab requires basic authentication enabled and a client certificate issued for the cluster to
   set up an [initial service account](add_remove_clusters.md#access-controls). In [GitLab versions
@@ -57,20 +57,20 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
    - **Kubernetes cluster name** - The name you wish to give the cluster.
    - **Environment scope** - The [associated environment](index.md#setting-the-environment-scope) to this cluster.
    - **Google Cloud Platform project** - Choose the project you created in your GCP
-     console that will host the Kubernetes cluster. Learn more about
+     console to host the Kubernetes cluster. Learn more about
      [Google Cloud Platform projects](https://cloud.google.com/resource-manager/docs/creating-managing-projects).
    - **Zone** - Choose the [region zone](https://cloud.google.com/compute/docs/regions-zones/)
-     under which the cluster will be created.
+     under which to create the cluster.
    - **Number of nodes** - Enter the number of nodes you wish the cluster to have.
    - **Machine type** - The [machine type](https://cloud.google.com/compute/docs/machine-types)
-     of the Virtual Machine instance that the cluster will be based on.
+     of the Virtual Machine instance to base the cluster on.
    - **Enable Cloud Run for Anthos** - Check this if you want to use Cloud Run for Anthos for this cluster.
      See the [Cloud Run for Anthos section](#cloud-run-for-anthos) for more information.
    - **GitLab-managed cluster** - Leave this checked if you want GitLab to manage namespaces and service accounts for this cluster.
      See the [Managed clusters section](index.md#gitlab-managed-clusters) for more information.
 1. Finally, click the **Create Kubernetes cluster** button.
 
-After a couple of minutes, your cluster will be ready to go. You can now proceed
+After a couple of minutes, your cluster is ready. You can now proceed
 to install some [pre-defined applications](index.md#installing-applications).
 
 ### Cloud Run for Anthos
@@ -79,7 +79,7 @@ to install some [pre-defined applications](index.md#installing-applications).
 
 You can choose to use Cloud Run for Anthos in place of installing Knative and Istio
 separately after the cluster has been created. This means that Cloud Run
-(Knative), Istio, and HTTP Load Balancing will be enabled on the cluster at
+(Knative), Istio, and HTTP Load Balancing are enabled on the cluster at
 create time and cannot be [installed or uninstalled](../../clusters/applications.md) separately.
 
 ## Existing GKE cluster
diff --git a/doc/user/project/clusters/runbooks/index.md b/doc/user/project/clusters/runbooks/index.md
index c1e4e821efd..7dfca5314da 100644
--- a/doc/user/project/clusters/runbooks/index.md
+++ b/doc/user/project/clusters/runbooks/index.md
@@ -37,7 +37,7 @@ for an overview of how this is accomplished in GitLab!
 
 ## Requirements
 
-To create an executable runbook, you will need:
+To create an executable runbook, you need:
 
 - **Kubernetes** - A Kubernetes cluster is required to deploy the rest of the
   applications. The simplest way to get started is to add a cluster using one
@@ -71,7 +71,7 @@ the components outlined above and the pre-loaded demo runbook.
    ![install ingress](img/ingress-install.png)
 
 1. After Ingress has been installed successfully, click the **Install** button next
-   to the **JupyterHub** application. You will need the **Jupyter Hostname** provided
+   to the **JupyterHub** application. You need the **Jupyter Hostname** provided
    here in the next step.
 
    ![install JupyterHub](img/jupyterhub-install.png)
@@ -84,8 +84,8 @@ the components outlined above and the pre-loaded demo runbook.
 
    ![authorize Jupyter](img/authorize-jupyter.png)
 
-1. Click **Authorize**, and you will be redirected to the JupyterHub application.
-1. Click **Start My Server**, and the server will start in a few seconds.
+1. Click **Authorize**, and GitLab redirects you to the JupyterHub application.
+1. Click **Start My Server** to start the server in a few seconds.
 1. To configure the runbook's access to your GitLab project, you must enter your
    [GitLab Access Token](../../../profile/personal_access_tokens.md)
    and your Project ID in the **Setup** section of the demo runbook:
diff --git a/doc/user/project/clusters/serverless/aws.md b/doc/user/project/clusters/serverless/aws.md
index 0de0fd38336..6dce37877c6 100644
--- a/doc/user/project/clusters/serverless/aws.md
+++ b/doc/user/project/clusters/serverless/aws.md
@@ -29,7 +29,7 @@ Alternatively, you can quickly [create a new project with a template](../../../.
 
 ### Example
 
-In the following example, you will:
+This example shows you how to:
 
 1. Create a basic AWS Lambda Node.js function.
 1. Link the function to an API Gateway `GET` endpoint.
@@ -49,7 +49,7 @@ Lets take it step by step.
 
 #### Creating a Lambda handler function
 
-Your Lambda function will be the primary handler of requests. In this case we will create a very simple Node.js `hello` function:
+Your Lambda function is the primary handler of requests. In this case, create a very simple Node.js `hello` function:
 
 ```javascript
 'use strict';
@@ -72,13 +72,13 @@ Place this code in the file `src/handler.js`.
 
 `src` is the standard location for serverless functions, but is customizable should you desire that.
 
-In our case, `module.exports.hello` defines the `hello` handler that will be referenced later in the `serverless.yml`
+In our case, `module.exports.hello` defines the `hello` handler to reference later in the `serverless.yml`.
 
 You can learn more about the AWS Lambda Node.js function handler and all its various options here: <https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-handler.html>
 
 #### Creating a `serverless.yml` file
 
-In the root of your project, create a `serverless.yml` file that will contain configuration specifics for the Serverless Framework.
+In the root of your project, create a `serverless.yml` file containing configuration specifics for the Serverless Framework.
 
 Put the following code in the file:
 
@@ -97,9 +97,9 @@ functions:
 
 Our function contains a handler and a event.
 
-The handler definition will provision the Lambda function using the source code located `src/handler.hello`.
+The handler definition provisions the Lambda function using the source code located `src/handler.hello`.
 
-The `events` declaration will create a AWS API Gateway `GET` endpoint to receive external requests and hand them over to the Lambda function via a service integration.
+The `events` declaration creates an AWS API Gateway `GET` endpoint to receive external requests and hand them over to the Lambda function via a service integration.
 
 You can read more about the [available properties and additional configuration possibilities](https://www.serverless.com/framework/docs/providers/aws/guide/serverless.yml/) of the Serverless Framework.
 
@@ -141,10 +141,10 @@ For more information please see [Create a custom variable in the UI](../../../..
 
 #### Deploying your function
 
-`git push` the changes to your GitLab repository and the GitLab build pipeline will automatically deploy your function.
+`git push` the changes to your GitLab repository and the GitLab build pipeline deploys your function.
 
-In your GitLab deploy stage log, there will be output containing your AWS Lambda endpoint URL.
-The log line will look similar to this:
+Your GitLab deploy stage log contains output containing your AWS Lambda endpoint URL,
+with log lines similar to this:
 
 ```plaintext
 endpoints:
@@ -227,7 +227,7 @@ provider:
 ```
 
 From there, you can reference them in your functions as well.
-Remember to add `A_VARIABLE` to your GitLab CI/CD variables under **Settings > CI/CD > Variables**, and it will get picked up and deployed with your function.
+Remember to add `A_VARIABLE` to your GitLab CI/CD variables under **Settings > CI/CD > Variables** to be picked up and deployed with your function.
 
 NOTE: **Note:**
 Anyone with access to the AWS environment may be able to see the values of those
@@ -309,7 +309,7 @@ GitLab allows developers to build and deploy serverless applications using the c
 
 ### Example
 
-In the following example, you will:
+This example shows you how to:
 
 - Install SAM CLI.
 - Create a sample SAM application including a Lambda function and API Gateway.
@@ -414,8 +414,8 @@ Let’s examine the configuration file more closely:
 
 ### Deploying your application
 
-Push changes to your GitLab repository and the GitLab build pipeline will automatically
-deploy your application. If your:
+Push changes to your GitLab repository and the GitLab build pipeline
+deploys your application. If your:
 
 - Build and deploy are successful, [test your deployed application](#testing-the-deployed-application).
 - Build fails, look at the build log to see why the build failed. Some common reasons
diff --git a/doc/user/project/clusters/serverless/index.md b/doc/user/project/clusters/serverless/index.md
index 603c4bd73b1..6625a6b314f 100644
--- a/doc/user/project/clusters/serverless/index.md
+++ b/doc/user/project/clusters/serverless/index.md
@@ -39,9 +39,9 @@ With GitLab Serverless, you can deploy both functions-as-a-service (FaaS) and se
 
 ## Prerequisites
 
-To run Knative on GitLab, you will need:
+To run Knative on GitLab, you need:
 
-1. **Existing GitLab project:** You will need a GitLab project to associate all resources. The simplest way to get started:
+1. **Existing GitLab project:** You need a GitLab project to associate all resources. The simplest way to get started:
    - If you are planning on [deploying functions](#deploying-functions),
      clone the [functions example project](https://gitlab.com/knative-examples/functions) to get
      started.
@@ -51,19 +51,19 @@ To run Knative on GitLab, you will need:
 1. **Kubernetes Cluster:** An RBAC-enabled Kubernetes cluster is required to deploy Knative.
    The simplest way to get started is to add a cluster using GitLab's [GKE integration](../add_remove_clusters.md).
    The set of minimum recommended cluster specifications to run Knative is 3 nodes, 6 vCPUs, and 22.50 GB memory.
-1. **GitLab Runner:** A runner is required to run the CI jobs that will deploy serverless
+1. **GitLab Runner:** A runner is required to run the CI jobs that deploy serverless
    applications or functions onto your cluster. You can install GitLab Runner
    onto the existing Kubernetes cluster. See [Installing Applications](../index.md#installing-applications) for more information.
-1. **Domain Name:** Knative will provide its own load balancer using Istio. It will provide an
-   external IP address or hostname for all the applications served by Knative. You will be prompted to enter a
-   wildcard domain where your applications will be served. Configure your DNS server to use the
+1. **Domain Name:** Knative provides its own load balancer using Istio, and an
+   external IP address or hostname for all the applications served by Knative. Enter a
+   wildcard domain to serve your applications. Configure your DNS server to use the
    external IP address or hostname for that domain.
 1. **`.gitlab-ci.yml`:** GitLab uses [Kaniko](https://github.com/GoogleContainerTools/kaniko)
    to build the application. We also use [GitLab Knative tool](https://gitlab.com/gitlab-org/gitlabktl)
    CLI to simplify the deployment of services and functions to Knative.
 1. **`serverless.yml`** (for [functions only](#deploying-functions)): When using serverless to deploy functions, the `serverless.yml` file
-   will contain the information for all the functions being hosted in the repository as well as a reference to the
-   runtime being used.
+   contains the information for all the functions being hosted in the repository as well as a reference
+   to the runtime being used.
 1. **`Dockerfile`** (for [applications only](#deploying-serverless-applications)): Knative requires a
    `Dockerfile` in order to build your applications. It should be included at the root of your
    project's repository and expose port `8080`. `Dockerfile` is not require if you plan to build serverless functions
@@ -92,7 +92,7 @@ memory. **RBAC must be enabled.**
    For clusters created on GKE, see [GKE Cluster Access](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl),
    for other platforms [Install kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
 
-1. The Ingress is now available at this address and will route incoming requests to the proper service based on the DNS
+1. The Ingress is now available at this address and routes incoming requests to the proper service based on the DNS
    name in the request. To support this, a wildcard DNS record should be created for the desired domain name. For example,
    if your Knative base domain is `knative.info` then you need to create an A record or CNAME record with domain `*.knative.info`
    pointing the IP address or hostname of the Ingress.
@@ -107,7 +107,7 @@ on a given project, but not both. The current implementation makes use of a
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/58941) in GitLab 12.0.
 
-The _invocations_ monitoring feature of GitLab serverless won't work when
+The _invocations_ monitoring feature of GitLab serverless is unavailable when
 adding an existing installation of Knative.
 
 It's also possible to use GitLab Serverless with an existing Kubernetes cluster
@@ -121,7 +121,7 @@ which already has Knative installed. You must do the following:
    - For a non-GitLab managed cluster, ensure that the service account for the token
      provided can manage resources in the `serving.knative.dev` API group.
    - For a GitLab managed cluster, if you added the cluster in [GitLab 12.1 or later](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30235),
-     then GitLab will already have the required access and you can proceed to the next step.
+     then GitLab already has the required access and you can proceed to the next step.
 
      Otherwise, you need to manually grant GitLab's service account the ability to manage
      resources in the `serving.knative.dev` API group. Since every GitLab service account
@@ -234,12 +234,12 @@ Follow these steps to deploy a function using the Node.js runtime to your
 Knative instance (you can skip these steps if you've cloned the example
 project):
 
-1. Create a directory that will house the function. In this example we will
+1. Create a directory to house the function. In this example we will
    create a directory called `echo` at the root of the project.
 
-1. Create the file that will contain the function code. In this example, our file is called `echo.js` and is located inside the `echo` directory. If your project is:
+1. Create the file to contain the function code. In this example, our file is called `echo.js` and is located inside the `echo` directory. If your project is:
    - Public, continue to the next step.
-   - Private, you will need to [create a GitLab deploy token](../../deploy_tokens/index.md#creating-a-deploy-token) with `gitlab-deploy-token` as the name and the `read_registry` scope.
+   - Private, you must [create a GitLab deploy token](../../deploy_tokens/index.md#creating-a-deploy-token) with `gitlab-deploy-token` as the name and the `read_registry` scope.
 
 1. `.gitlab-ci.yml`: this defines a pipeline used to deploy your functions.
    It must be included at the root of your repository:
@@ -304,7 +304,7 @@ Explanation of the fields used above:
 
 | Parameter | Description |
 |-----------|-------------|
-| `service` | Name for the Knative service which will serve the function. |
+| `service` | Name for the Knative service which serves the function. |
 | `description` | A short description of the `service`. |
 
 ### `provider`
@@ -349,9 +349,9 @@ The optional `runtime` parameter can refer to one of the following runtime alias
 | `openfaas/classic/ruby` | OpenFaaS |
 
 After the `gitlab-ci.yml` template has been added and the `serverless.yml` file
-has been created, pushing a commit to your project will result in a CI pipeline
-being executed which will deploy each function as a Knative service. Once the
-deploy stage has finished, additional details for the function will appear
+has been created, pushing a commit to your project results in a CI pipeline
+being executed which deploys each function as a Knative service. After the
+deploy stage has finished, additional details for the function display
 under **Operations > Serverless**.
 
 ![serverless page](img/serverless-page.png)
@@ -482,7 +482,7 @@ A `serverless.yml` file is not required when deploying serverless applications.
 
 ### Deploy the application with Knative
 
-With all the pieces in place, the next time a CI pipeline runs, the Knative application will be deployed. Navigate to
+With all the pieces in place, the next time a CI pipeline runs the Knative application deploys. Navigate to
 **CI/CD > Pipelines** and click the most recent pipeline.
 
 ### Function details
@@ -498,13 +498,13 @@ rows to bring up the function details page.
 
 ![function_details](img/function-details-loaded.png)
 
-The pod count will give you the number of pods running the serverless function instances on a given cluster.
+The pod count gives you the number of pods running the serverless function instances on a given cluster.
 
 For the Knative function invocations to appear,
 [Prometheus must be installed](../index.md#installing-applications).
 
 Once Prometheus is installed, a message may appear indicating that the metrics data _is
-loading or is not available at this time._  It will appear upon the first access of the
+loading or is not available at this time._  It appears upon the first access of the
 page, but should go away after a few seconds. If the message does not disappear, then it
 is possible that GitLab is unable to connect to the Prometheus instance running on the
 cluster.
@@ -558,7 +558,7 @@ Or:
 
 ## Enabling TLS for Knative services
 
-By default, a GitLab serverless deployment will be served over `http`. To serve
+By default, a GitLab serverless deployment is served over `http`. To serve
 over `https`, you must manually obtain and install TLS certificates.
 
 12345678901234567890123456789012345678901234567890123456789012345678901234567890
@@ -647,7 +647,7 @@ or with other versions of Python.
    ```
 
 1. Create certificate and private key files. Using the contents of the files
-   returned by Certbot, we'll create two files in order to create the
+   returned by Certbot, create two files in order to create the
    Kubernetes secret:
 
    Run the following command to see the contents of `fullchain.pem`:
@@ -828,8 +828,8 @@ or with other versions of Python.
    ```
 
    After your changes are running on your Knative cluster, you can begin using the HTTPS protocol for secure access your deployed Knative services.
-   In the event a mistake is made during this process and you need to update the cert, you will need to edit the gateway `knative-ingress-gateway`
-   to switch back to `PASSTHROUGH` mode. Once corrections are made, edit the file again so the gateway will use the new certificates.
+   In the event a mistake is made during this process and you need to update the cert, you must edit the gateway `knative-ingress-gateway`
+   to switch back to `PASSTHROUGH` mode. Once corrections are made, edit the file again so the gateway uses the new certificates.
 
 ## Using an older version of `gitlabktl`
 
diff --git a/doc/user/project/issue_board.md b/doc/user/project/issue_board.md
index dfe608df18d..5f938d25363 100644
--- a/doc/user/project/issue_board.md
+++ b/doc/user/project/issue_board.md
@@ -51,11 +51,54 @@ To learn more, visit [GitLab Enterprise features for issue boards](#gitlab-enter
 Watch a [video presentation](https://youtu.be/vjccjHI7aGI) of
 the Issue Board feature.
 
+## Multiple issue boards
+
+> - [Introduced](https://about.gitlab.com/releases/2016/10/22/gitlab-8-13-released/) in GitLab 8.13.
+> - Multiple issue boards per project [moved](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53811) to [GitLab Core](https://about.gitlab.com/pricing/) in GitLab 12.1.
+> - Multiple issue boards per group are available in [GitLab Premium](https://about.gitlab.com/pricing/).
+
+Multiple issue boards allow for more than one issue board for a given project **(CORE)** or group **(PREMIUM)**.
+This is great for large projects with more than one team or when a repository hosts the code of multiple products.
+
+Using the search box at the top of the menu, you can filter the listed boards.
+
+When you have ten or more boards available, a **Recent** section is also shown in the menu, with
+shortcuts to your last four visited boards.
+
+![Multiple issue boards](img/issue_boards_multiple_v13_6.png)
+
+When you're revisiting an issue board in a project or group with multiple boards,
+GitLab automatically loads the last board you visited.
+
+### Create an issue board
+
+To create a new issue board:
+
+1. Click the dropdown with the current board name in the upper left corner of the Issue Boards page.
+1. Click **Create new board**.
+1. Enter the new board's name and select its scope: milestone, labels, assignee, or weight.
+
+### Delete an issue board
+
+To delete the currently active issue board:
+
+1. Click the dropdown with the current board name in the upper left corner of the Issue Boards page.
+1. Click **Delete board**.
+1. Click **Delete** to confirm.
+
 ## Issue boards use cases
 
 You can tailor GitLab issue boards to your own preferred workflow.
 Here are some common use cases for issue boards.
 
+For examples of using issue boards along with [epics](../group/epics/index.md) **(PREMIUM)**,
+[issue health status](issues/index.md#health-status) **(ULTIMATE)**, and
+[scoped labels](labels.md#scoped-labels) **(PREMIUM)** for various Agile frameworks, check:
+
+- The [How to use GitLab for Agile portfolio planning and project management](https://about.gitlab.com/blog/2020/11/11/gitlab-for-agile-portfolio-planning-project-management/) blog post (November 2020)
+- <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
+[Cross-project Agile work management with GitLab](https://www.youtube.com/watch?v=5J0bonGoECs) (15 min, July 2020)
+
 ### Use cases for a single issue board
 
 With the GitLab Workflow you can discuss proposals in issues, label
@@ -122,7 +165,10 @@ to improve their workflow with multiple boards.
 
 #### Quick assignments
 
-Create lists for each of your team members and quickly drag issues onto each team member's list.
+To quickly assign issues to your team members:
+
+1. Create [assignee lists](#assignee-lists) for each team member.
+1. Drag an issue onto the team member's list.
 
 ## Issue board terminology
 
@@ -185,41 +231,6 @@ and vice versa.
 GitLab issue boards are available on GitLab Core and GitLab.com Free tiers, but some
 advanced functionality is present in [higher tiers only](https://about.gitlab.com/pricing/).
 
-### Multiple issue boards
-
-> - [Introduced](https://about.gitlab.com/releases/2016/10/22/gitlab-8-13-released/) in GitLab 8.13.
-> - Multiple issue boards per project [moved](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53811) to [GitLab Core](https://about.gitlab.com/pricing/) in GitLab 12.1.
-> - Multiple issue boards per group are available in [GitLab Premium](https://about.gitlab.com/pricing/).
-
-Multiple issue boards allow for more than one issue board for a given project or group.
-This is great for large projects with more than one team or when a repository hosts the code of multiple products.
-
-Using the search box at the top of the menu, you can filter the listed boards.
-
-When you have ten or more boards available, a **Recent** section is also shown in the menu, with
-shortcuts to your last four visited boards.
-
-![Multiple issue boards](img/issue_boards_multiple_v13_6.png)
-
-When you're revisiting an issue board in a project or group with multiple boards,
-GitLab automatically loads the last board you visited.
-
-#### Create an issue board
-
-To create a new issue board:
-
-1. Click the dropdown with the current board name in the upper left corner of the Issue Boards page.
-1. Click **Create new board**.
-1. Enter the new board's name and select its scope: milestone, labels, assignee, or weight.
-
-#### Delete an issue board
-
-To delete the currently active issue board:
-
-1. Click the dropdown with the current board name in the upper left corner of the Issue Boards page.
-1. Click **Delete board**.
-1. Click **Delete** to confirm.
-
 ### Configurable issue boards **(STARTER)**
 
 > [Introduced](https://about.gitlab.com/releases/2017/11/22/gitlab-10-2-released/#issue-boards-configuration) in [GitLab Starter](https://about.gitlab.com/pricing/) 10.2.
@@ -315,6 +326,9 @@ With swimlanes you can visualize issues grouped by epic.
 Your issue board keeps all the other features, but with a different visual organization of issues.
 This feature is available both at the project and group level.
 
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
+For a video overview, see [Epics Swimlanes Walkthrough - 13.6](https://www.youtube.com/watch?v=nHC7-kz5P2g) (November 2020).
+
 To group issues by epic in an issue board:
 
 1. Select the **Group by** dropdown button.
diff --git a/lib/microsoft_teams/notifier.rb b/lib/microsoft_teams/notifier.rb
index 0b21c355a54..39005f56dcb 100644
--- a/lib/microsoft_teams/notifier.rb
+++ b/lib/microsoft_teams/notifier.rb
@@ -14,7 +14,7 @@ module MicrosoftTeams
         response = Gitlab::HTTP.post(
           @webhook.to_str,
           headers: @header,
-          body: body(options)
+          body: body(**options)
         )
 
         result = true if response
@@ -27,14 +27,13 @@ module MicrosoftTeams
 
     private
 
-    def body(options = {})
+    def body(title: nil, summary: nil, attachments: nil, activity:)
       result = { 'sections' => [] }
 
-      result['title'] = options[:title]
-      result['summary'] = options[:summary]
-      result['sections'] << MicrosoftTeams::Activity.new(options[:activity]).prepare
+      result['title'] = title
+      result['summary'] = summary
+      result['sections'] << MicrosoftTeams::Activity.new(**activity).prepare
 
-      attachments = options[:attachments]
       unless attachments.blank?
         result['sections'] << { text: attachments }
       end
diff --git a/spec/features/groups/show_spec.rb b/spec/features/groups/show_spec.rb
index 97732374eb9..3a42fd508b4 100644
--- a/spec/features/groups/show_spec.rb
+++ b/spec/features/groups/show_spec.rb
@@ -193,4 +193,69 @@ RSpec.describe 'Group show page' do
 
     it_behaves_like 'page meta description', 'Lorem ipsum dolor sit amet'
   end
+
+  context 'structured schema markup' do
+    let_it_be(:group) { create(:group, :public, :with_avatar, description: 'foo') }
+    let_it_be(:subgroup) { create(:group, :public, :with_avatar, parent: group, description: 'bar') }
+    let_it_be_with_reload(:project) { create(:project, :public, :with_avatar, namespace: group, description: 'foo') }
+    let_it_be(:subproject) { create(:project, :public, :with_avatar, namespace: subgroup, description: 'bar') }
+
+    it 'shows Organization structured markup', :js do
+      visit path
+      wait_for_all_requests
+
+      aggregate_failures do
+        expect(page).to have_selector('.content[itemscope][itemtype="https://schema.org/Organization"]')
+
+        page.within('.group-home-panel') do
+          expect(page).to have_selector('img.avatar[itemprop="logo"]')
+          expect(page).to have_selector('[itemprop="name"]', text: group.name)
+          expect(page).to have_selector('[itemprop="description"]', text: group.description)
+        end
+
+        page.within('[itemprop="owns"][itemtype="https://schema.org/SoftwareSourceCode"]') do
+          expect(page).to have_selector('img.avatar[itemprop="image"]')
+          expect(page).to have_selector('[itemprop="name"]', text: project.name)
+          expect(page).to have_selector('[itemprop="description"]', text: project.description)
+        end
+
+        # Finding the subgroup row and expanding it
+        el = find('[itemprop="subOrganization"][itemtype="https://schema.org/Organization"]')
+        el.click
+        wait_for_all_requests
+        page.within(el) do
+          expect(page).to have_selector('img.avatar[itemprop="logo"]')
+          expect(page).to have_selector('[itemprop="name"]', text: subgroup.name)
+          expect(page).to have_selector('[itemprop="description"]', text: subgroup.description)
+
+          page.within('[itemprop="owns"][itemtype="https://schema.org/SoftwareSourceCode"]') do
+            expect(page).to have_selector('img.avatar[itemprop="image"]')
+            expect(page).to have_selector('[itemprop="name"]', text: subproject.name)
+            expect(page).to have_selector('[itemprop="description"]', text: subproject.description)
+          end
+        end
+      end
+    end
+
+    it 'does not include structured markup in shared projects tab', :js do
+      other_project = create(:project, :public)
+      other_project.project_group_links.create!(group: group)
+
+      visit group_shared_path(group)
+      wait_for_all_requests
+
+      expect(page).to have_selector('li.group-row')
+      expect(page).not_to have_selector('[itemprop="owns"][itemtype="https://schema.org/SoftwareSourceCode"]')
+    end
+
+    it 'does not include structured markup in archived projects tab', :js do
+      project.update!(archived: true)
+
+      visit group_archived_path(group)
+      wait_for_all_requests
+
+      expect(page).to have_selector('li.group-row')
+      expect(page).not_to have_selector('[itemprop="owns"][itemtype="https://schema.org/SoftwareSourceCode"]')
+    end
+  end
 end
diff --git a/spec/finders/ci/commit_statuses_finder_spec.rb b/spec/finders/ci/commit_statuses_finder_spec.rb
index 1aa9cb12432..05a1a98cfe0 100644
--- a/spec/finders/ci/commit_statuses_finder_spec.rb
+++ b/spec/finders/ci/commit_statuses_finder_spec.rb
@@ -152,8 +152,8 @@ RSpec.describe Ci::CommitStatusesFinder, '#execute' do
         project.project_feature.update!(builds_access_level: ProjectFeature::PRIVATE)
       end
 
-      it 'returns nil' do
-        expect(subject).to be_empty
+      it 'returns a blank hash' do
+        expect(subject).to eq({})
       end
     end
 
@@ -170,8 +170,8 @@ RSpec.describe Ci::CommitStatusesFinder, '#execute' do
           status: :running)
       end
 
-      it 'returns nil' do
-        expect(private_subject).to be_empty
+      it 'returns a blank hash' do
+        expect(private_subject).to eq({})
       end
     end
   end
diff --git a/spec/frontend/groups/components/app_spec.js b/spec/frontend/groups/components/app_spec.js
index 691f8896d74..72d8e23f28b 100644
--- a/spec/frontend/groups/components/app_spec.js
+++ b/spec/frontend/groups/components/app_spec.js
@@ -35,7 +35,7 @@ describe('AppComponent', () => {
   let mock;
   let getGroupsSpy;
 
-  const store = new GroupsStore(false);
+  const store = new GroupsStore({ hideProjects: false });
   const service = new GroupsService(mockEndpoint);
 
   const createShallowComponent = (hideProjects = false) => {
diff --git a/spec/frontend/groups/components/group_item_spec.js b/spec/frontend/groups/components/group_item_spec.js
index 83acbb152b5..32bae812c86 100644
--- a/spec/frontend/groups/components/group_item_spec.js
+++ b/spec/frontend/groups/components/group_item_spec.js
@@ -2,6 +2,7 @@ import Vue from 'vue';
 import mountComponent from 'helpers/vue_mount_component_helper';
 import groupItemComponent from '~/groups/components/group_item.vue';
 import groupFolderComponent from '~/groups/components/group_folder.vue';
+import { getGroupItemMicrodata } from '~/groups/store/utils';
 import eventHub from '~/groups/event_hub';
 import * as urlUtilities from '~/lib/utils/url_utility';
 import { mockParentGroupItem, mockChildren } from '../mock_data';
@@ -30,6 +31,11 @@ describe('GroupItemComponent', () => {
     vm.$destroy();
   });
 
+  const withMicrodata = group => ({
+    ...group,
+    microdata: getGroupItemMicrodata(group),
+  });
+
   describe('computed', () => {
     describe('groupDomId', () => {
       it('should return ID string suffixed with group ID', () => {
@@ -212,4 +218,47 @@ describe('GroupItemComponent', () => {
       expect(vm.$el.querySelector('.group-list-tree')).toBeDefined();
     });
   });
+  describe('schema.org props', () => {
+    describe('when showSchemaMarkup is disabled on the group', () => {
+      it.each(['itemprop', 'itemtype', 'itemscope'], 'it does not set %s', attr => {
+        expect(vm.$el.getAttribute(attr)).toBeNull();
+      });
+      it.each(
+        ['.js-group-avatar', '.js-group-name', '.js-group-description'],
+        'it does not set `itemprop` on sub-nodes',
+        selector => {
+          expect(vm.$el.querySelector(selector).getAttribute('itemprop')).toBeNull();
+        },
+      );
+    });
+    describe('when group has microdata', () => {
+      beforeEach(() => {
+        const group = withMicrodata({
+          ...mockParentGroupItem,
+          avatarUrl: 'http://foo.bar',
+          description: 'Foo Bar',
+        });
+
+        vm = createComponent(group);
+      });
+
+      it.each`
+        attr           | value
+        ${'itemscope'} | ${'itemscope'}
+        ${'itemtype'}  | ${'https://schema.org/Organization'}
+        ${'itemprop'}  | ${'subOrganization'}
+      `('it does set correct $attr', ({ attr, value } = {}) => {
+        expect(vm.$el.getAttribute(attr)).toBe(value);
+      });
+
+      it.each`
+        selector                               | propValue
+        ${'[data-testid="group-avatar"]'}      | ${'logo'}
+        ${'[data-testid="group-name"]'}        | ${'name'}
+        ${'[data-testid="group-description"]'} | ${'description'}
+      `('it does set correct $selector', ({ selector, propValue } = {}) => {
+        expect(vm.$el.querySelector(selector).getAttribute('itemprop')).toBe(propValue);
+      });
+    });
+  });
 });
diff --git a/spec/frontend/groups/store/groups_store_spec.js b/spec/frontend/groups/store/groups_store_spec.js
index 7d12f73d270..8ac5d7099f1 100644
--- a/spec/frontend/groups/store/groups_store_spec.js
+++ b/spec/frontend/groups/store/groups_store_spec.js
@@ -1,4 +1,5 @@
 import GroupsStore from '~/groups/store/groups_store';
+import { getGroupItemMicrodata } from '~/groups/store/utils';
 import {
   mockGroups,
   mockSearchedGroups,
@@ -17,9 +18,9 @@ describe('ProjectsStore', () => {
       expect(Object.keys(store.state).length).toBe(2);
       expect(Array.isArray(store.state.groups)).toBeTruthy();
       expect(Object.keys(store.state.pageInfo).length).toBe(0);
-      expect(store.hideProjects).not.toBeDefined();
+      expect(store.hideProjects).toBeFalsy();
 
-      store = new GroupsStore(true);
+      store = new GroupsStore({ hideProjects: true });
 
       expect(store.hideProjects).toBeTruthy();
     });
@@ -86,22 +87,30 @@ describe('ProjectsStore', () => {
 
   describe('formatGroupItem', () => {
     it('should parse group item object and return updated object', () => {
-      let store;
-      let updatedGroupItem;
-
-      store = new GroupsStore();
-      updatedGroupItem = store.formatGroupItem(mockRawChildren[0]);
+      const store = new GroupsStore();
+      const updatedGroupItem = store.formatGroupItem(mockRawChildren[0]);
 
       expect(Object.keys(updatedGroupItem).indexOf('fullName')).toBeGreaterThan(-1);
       expect(updatedGroupItem.childrenCount).toBe(mockRawChildren[0].children_count);
       expect(updatedGroupItem.isChildrenLoading).toBe(false);
       expect(updatedGroupItem.isBeingRemoved).toBe(false);
+      expect(updatedGroupItem.microdata).toEqual({});
+    });
 
-      store = new GroupsStore(true);
-      updatedGroupItem = store.formatGroupItem(mockRawChildren[0]);
+    it('with hideProjects', () => {
+      const store = new GroupsStore({ hideProjects: true });
+      const updatedGroupItem = store.formatGroupItem(mockRawChildren[0]);
 
       expect(Object.keys(updatedGroupItem).indexOf('fullName')).toBeGreaterThan(-1);
       expect(updatedGroupItem.childrenCount).toBe(mockRawChildren[0].subgroup_count);
+      expect(updatedGroupItem.microdata).toEqual({});
+    });
+
+    it('with showSchemaMarkup', () => {
+      const store = new GroupsStore({ showSchemaMarkup: true });
+      const updatedGroupItem = store.formatGroupItem(mockRawChildren[0]);
+
+      expect(updatedGroupItem.microdata).toEqual(getGroupItemMicrodata(mockRawChildren[0]));
     });
   });
 
diff --git a/spec/frontend/groups/store/utils_spec.js b/spec/frontend/groups/store/utils_spec.js
new file mode 100644
index 00000000000..0961d4c72b4
--- /dev/null
+++ b/spec/frontend/groups/store/utils_spec.js
@@ -0,0 +1,44 @@
+import { getGroupItemMicrodata } from '~/groups/store/utils';
+
+describe('~/groups/store/utils', () => {
+  describe('getGroupItemMetadata', () => {
+    it('has default type', () => {
+      expect(getGroupItemMicrodata({ type: 'silly' })).toMatchInlineSnapshot(`
+        Object {
+          "descriptionItemprop": "description",
+          "imageItemprop": "image",
+          "itemprop": "owns",
+          "itemscope": true,
+          "itemtype": "https://schema.org/Thing",
+          "nameItemprop": "name",
+        }
+      `);
+    });
+
+    it('has group props', () => {
+      expect(getGroupItemMicrodata({ type: 'group' })).toMatchInlineSnapshot(`
+        Object {
+          "descriptionItemprop": "description",
+          "imageItemprop": "logo",
+          "itemprop": "subOrganization",
+          "itemscope": true,
+          "itemtype": "https://schema.org/Organization",
+          "nameItemprop": "name",
+        }
+      `);
+    });
+
+    it('has project props', () => {
+      expect(getGroupItemMicrodata({ type: 'project' })).toMatchInlineSnapshot(`
+        Object {
+          "descriptionItemprop": "description",
+          "imageItemprop": "image",
+          "itemprop": "owns",
+          "itemscope": true,
+          "itemtype": "https://schema.org/SoftwareSourceCode",
+          "nameItemprop": "name",
+        }
+      `);
+    });
+  });
+});
diff --git a/spec/helpers/user_callouts_helper_spec.rb b/spec/helpers/user_callouts_helper_spec.rb
index 4ab3be877b4..250aedda906 100644
--- a/spec/helpers/user_callouts_helper_spec.rb
+++ b/spec/helpers/user_callouts_helper_spec.rb
@@ -167,8 +167,20 @@ RSpec.describe UserCalloutsHelper do
 
     subject { helper.show_registration_enabled_user_callout? }
 
+    context 'when on gitlab.com' do
+      before do
+        allow(::Gitlab).to receive(:com?).and_return(true)
+        allow(helper).to receive(:current_user).and_return(admin)
+        stub_application_setting(signup_enabled: true)
+        allow(helper).to receive(:user_dismissed?).with(described_class::REGISTRATION_ENABLED_CALLOUT) { false }
+      end
+
+      it { is_expected.to be false }
+    end
+
     context 'when `current_user` is not an admin' do
       before do
+        allow(::Gitlab).to receive(:com?).and_return(false)
         allow(helper).to receive(:current_user).and_return(user)
         stub_application_setting(signup_enabled: true)
         allow(helper).to receive(:user_dismissed?).with(described_class::REGISTRATION_ENABLED_CALLOUT) { false }
@@ -179,6 +191,7 @@ RSpec.describe UserCalloutsHelper do
 
     context 'when signup is disabled' do
       before do
+        allow(::Gitlab).to receive(:com?).and_return(false)
         allow(helper).to receive(:current_user).and_return(admin)
         stub_application_setting(signup_enabled: false)
         allow(helper).to receive(:user_dismissed?).with(described_class::REGISTRATION_ENABLED_CALLOUT) { false }
@@ -189,6 +202,7 @@ RSpec.describe UserCalloutsHelper do
 
     context 'when user has dismissed callout' do
       before do
+        allow(::Gitlab).to receive(:com?).and_return(false)
         allow(helper).to receive(:current_user).and_return(admin)
         stub_application_setting(signup_enabled: true)
         allow(helper).to receive(:user_dismissed?).with(described_class::REGISTRATION_ENABLED_CALLOUT) { true }
@@ -197,8 +211,9 @@ RSpec.describe UserCalloutsHelper do
       it { is_expected.to be false }
     end
 
-    context 'when `current_user` is an admin, signup is enabled, and user has not dismissed callout' do
+    context 'when not gitlab.com, `current_user` is an admin, signup is enabled, and user has not dismissed callout' do
       before do
+        allow(::Gitlab).to receive(:com?).and_return(false)
         allow(helper).to receive(:current_user).and_return(admin)
         stub_application_setting(signup_enabled: true)
         allow(helper).to receive(:user_dismissed?).with(described_class::REGISTRATION_ENABLED_CALLOUT) { false }
diff --git a/spec/lib/microsoft_teams/notifier_spec.rb b/spec/lib/microsoft_teams/notifier_spec.rb
index c35d7e8420c..3b7892334dd 100644
--- a/spec/lib/microsoft_teams/notifier_spec.rb
+++ b/spec/lib/microsoft_teams/notifier_spec.rb
@@ -51,11 +51,11 @@ RSpec.describe MicrosoftTeams::Notifier do
 
   describe '#body' do
     it 'returns Markdown-based body when HTML was passed' do
-      expect(subject.send(:body, options)).to eq(body.to_json)
+      expect(subject.send(:body, **options)).to eq(body.to_json)
     end
 
     it 'fails when empty Hash was passed' do
-      expect { subject.send(:body, {}) }.to raise_error(ArgumentError)
+      expect { subject.send(:body, **{}) }.to raise_error(ArgumentError)
     end
   end
 end
diff --git a/spec/views/projects/tags/index.html.haml_spec.rb b/spec/views/projects/tags/index.html.haml_spec.rb
index 8cc86b75873..dc008875062 100644
--- a/spec/views/projects/tags/index.html.haml_spec.rb
+++ b/spec/views/projects/tags/index.html.haml_spec.rb
@@ -81,5 +81,14 @@ RSpec.describe 'projects/tags/index.html.haml' do
 
       expect(page.all('.tags .content-list li')).not_to have_css 'svg.s24'
     end
+
+    it 'shows no build status or placeholder when pipelines are private' do
+      project.project_feature.update!(builds_access_level: ProjectFeature::PRIVATE)
+      assign(:tag_pipeline_statuses, Ci::CommitStatusesFinder.new(project, project.repository, build(:user), tags).execute)
+
+      render
+
+      expect(page.all('.tags .content-list li')).not_to have_css 'svg.s24'
+    end
   end
 end