Add latest changes from gitlab-org/gitlab@master

45 files changed, 254 insertions, 227 deletions

diff --git a/app/assets/javascripts/projects/settings/access_dropdown.js b/app/assets/javascripts/projects/settings/access_dropdown.js
index 3ca5bca4bf2..cb4fd5265da 100644
--- a/app/assets/javascripts/projects/settings/access_dropdown.js
+++ b/app/assets/javascripts/projects/settings/access_dropdown.js
@@ -48,11 +48,12 @@ export default class AccessDropdown {
       clicked: options => {
         const { $el, e } = options;
         const item = options.selectedObj;
+        const fossWithMergeAccess = !this.hasLicense && this.accessLevel === ACCESS_LEVELS.MERGE;
 
         e.preventDefault();
 
-        if (!this.hasLicense) {
-          // We're not multiselecting quite yet with FOSS:
+        if (fossWithMergeAccess) {
+          // We're not multiselecting quite yet in "Merge" access dropdown, on FOSS:
           // remove all preselected items before selecting this item
           // https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37499
           this.accessLevelsData.forEach(level => {
@@ -62,7 +63,7 @@ export default class AccessDropdown {
 
         if ($el.is('.is-active')) {
           if (this.noOneObj) {
-            if (item.id === this.noOneObj.id && this.hasLicense) {
+            if (item.id === this.noOneObj.id && !fossWithMergeAccess) {
               // remove all others selected items
               this.accessLevelsData.forEach(level => {
                 if (level.id !== item.id) {
diff --git a/app/models/clusters/cluster.rb b/app/models/clusters/cluster.rb
index 3cf5542ae76..a34d8a6b98d 100644
--- a/app/models/clusters/cluster.rb
+++ b/app/models/clusters/cluster.rb
@@ -149,8 +149,8 @@ module Clusters
 
     scope :for_project_namespace, -> (namespace_id) { joins(:projects).where(projects: { namespace_id: namespace_id }) }
     scope :with_application_prometheus, -> { includes(:application_prometheus).joins(:application_prometheus) }
-    scope :with_project_alert_service_data, -> (project_ids) do
-      conditions = { projects: { alerts_service: [:data] } }
+    scope :with_project_http_integrations, -> (project_ids) do
+      conditions = { projects: :alert_management_http_integrations }
       includes(conditions).joins(conditions).where(projects: { id: project_ids })
     end
 
diff --git a/app/models/concerns/protected_ref.rb b/app/models/concerns/protected_ref.rb
index cddca72f91f..65195a8d5aa 100644
--- a/app/models/concerns/protected_ref.rb
+++ b/app/models/concerns/protected_ref.rb
@@ -12,6 +12,10 @@ module ProtectedRef
     delegate :matching, :matches?, :wildcard?, to: :ref_matcher
 
     scope :for_project, ->(project) { where(project: project) }
+
+    def allow_multiple?(type)
+      false
+    end
   end
 
   def commit
@@ -29,7 +33,7 @@ module ProtectedRef
         # to fail.
         has_many :"#{type}_access_levels", inverse_of: self.model_name.singular
 
-        validates :"#{type}_access_levels", length: { is: 1, message: "are restricted to a single instance per #{self.model_name.human}." }
+        validates :"#{type}_access_levels", length: { is: 1, message: "are restricted to a single instance per #{self.model_name.human}." }, unless: -> { allow_multiple?(type) }
 
         accepts_nested_attributes_for :"#{type}_access_levels", allow_destroy: true
       end
diff --git a/app/models/concerns/protected_ref_access.rb b/app/models/concerns/protected_ref_access.rb
index 28dc3366e51..5e38ce7cad8 100644
--- a/app/models/concerns/protected_ref_access.rb
+++ b/app/models/concerns/protected_ref_access.rb
@@ -45,6 +45,7 @@ module ProtectedRefAccess
   end
 
   def check_access(user)
+    return false unless user
     return true if user.admin?
 
     user.can?(:push_code, project) &&
diff --git a/app/models/protected_branch.rb b/app/models/protected_branch.rb
index 599c174ddd7..ad418a47476 100644
--- a/app/models/protected_branch.rb
+++ b/app/models/protected_branch.rb
@@ -48,6 +48,10 @@ class ProtectedBranch < ApplicationRecord
 
     where(fuzzy_arel_match(:name, query.downcase))
   end
+
+  def allow_multiple?(type)
+    type == :push
+  end
 end
 
 ProtectedBranch.prepend_if_ee('EE::ProtectedBranch')
diff --git a/app/models/protected_branch/push_access_level.rb b/app/models/protected_branch/push_access_level.rb
index 5ae9c7030bf..f28440f2444 100644
--- a/app/models/protected_branch/push_access_level.rb
+++ b/app/models/protected_branch/push_access_level.rb
@@ -37,8 +37,6 @@ class ProtectedBranch::PushAccessLevel < ApplicationRecord
   end
 
   def enabled_deploy_key_for_user?(deploy_key, user)
-    return false unless deploy_key.user_id == user.id
-
-    DeployKey.with_write_access_for_project(protected_branch.project, deploy_key: deploy_key).any?
+    deploy_key.user_id == user.id && DeployKey.with_write_access_for_project(protected_branch.project, deploy_key: deploy_key).any?
   end
 end
diff --git a/app/services/clusters/applications/prometheus_health_check_service.rb b/app/services/clusters/applications/prometheus_health_check_service.rb
index e609d9f0b7b..843202ab6ff 100644
--- a/app/services/clusters/applications/prometheus_health_check_service.rb
+++ b/app/services/clusters/applications/prometheus_health_check_service.rb
@@ -63,8 +63,10 @@ module Clusters
 
       def send_notification(project)
         notification_payload = build_notification_payload(project)
-        token = project.alerts_service.data.token
-        Projects::Alerting::NotifyService.new(project, nil, notification_payload).execute(token)
+        integration = project.alert_management_http_integrations.active.first
+
+        Projects::Alerting::NotifyService.new(project, nil, notification_payload).execute(integration&.token, integration)
+
         @logger.info(message: 'Successfully notified of Prometheus newly unhealthy', cluster_id: @cluster.id, project_id: project.id)
       end
 
diff --git a/app/views/shared/projects/protected_branches/_update_protected_branch.html.haml b/app/views/shared/projects/protected_branches/_update_protected_branch.html.haml
index eafc402f210..cb954c20b48 100644
--- a/app/views/shared/projects/protected_branches/_update_protected_branch.html.haml
+++ b/app/views/shared/projects/protected_branches/_update_protected_branch.html.haml
@@ -1,3 +1,5 @@
+- select_mode_for_dropdown = Feature.enabled?(:deploy_keys_on_protected_branches, protected_branch.project) ? 'js-multiselect' : ''
+
 - merge_access_levels = protected_branch.merge_access_levels.for_role
 - push_access_levels = protected_branch.push_access_levels.for_role
 
@@ -23,7 +25,7 @@
 %td.push_access_levels-container
   = hidden_field_tag "allowed_to_push_#{protected_branch.id}", push_access_levels.first&.access_level
   = dropdown_tag( (push_access_levels.first&.humanize || 'Select') ,
-                 options: { toggle_class: 'js-allowed-to-push', dropdown_class: 'dropdown-menu-selectable js-allowed-to-push-container capitalize-header',
+    options: { toggle_class: "js-allowed-to-push #{select_mode_for_dropdown}", dropdown_class: 'dropdown-menu-selectable js-allowed-to-push-container capitalize-header',
                  data: { field_name: "allowed_to_push_#{protected_branch.id}", preselected_items: access_levels_data(push_access_levels) }})
   - if user_push_access_levels.any?
     %p.small
diff --git a/app/workers/clusters/applications/check_prometheus_health_worker.rb b/app/workers/clusters/applications/check_prometheus_health_worker.rb
index 2e8ee739946..cf9534c9a78 100644
--- a/app/workers/clusters/applications/check_prometheus_health_worker.rb
+++ b/app/workers/clusters/applications/check_prometheus_health_worker.rb
@@ -20,7 +20,7 @@ module Clusters
         demo_project_ids = Gitlab::Monitor::DemoProjects.primary_keys
 
         clusters = Clusters::Cluster.with_application_prometheus
-          .with_project_alert_service_data(demo_project_ids)
+          .with_project_http_integrations(demo_project_ids)
 
         # Move to a seperate worker with scoped context if expanded to do work on customer projects
         clusters.each { |cluster| Clusters::Applications::PrometheusHealthCheckService.new(cluster).execute }
diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index 5a9041dad60..667595bc1f9 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -1137,6 +1137,12 @@ and a simple solution would be to enable relative URLs in the Registry.
 
 ### Enable the Registry debug server
 
+You can use the Container Registry debug server to diagnose problems. The debug endpoint can monitor metrics and health, as well as do profiling.
+
+CAUTION: **Warning:**
+Sensitive information may be available from the debug endpoint.
+Access to the debug endpoint must be locked down in a production environment.
+
 The optional debug server can be enabled by setting the registry debug address
 in your `gitlab.rb` configuration.
 
diff --git a/doc/development/documentation/styleguide/index.md b/doc/development/documentation/styleguide/index.md
index ac0b7ab9c64..017deb6b737 100644
--- a/doc/development/documentation/styleguide/index.md
+++ b/doc/development/documentation/styleguide/index.md
@@ -1551,7 +1551,7 @@ This is something to note.
 ### Warning
 
 Use a warning to indicate deprecated features, or to provide a warning about
-procedures that have the potential for data loss. 
+procedures that have the potential for data loss.
 
 ```markdown
 WARNING:
@@ -1799,25 +1799,8 @@ in the GitLab product documentation.
 
 ### Avoid line breaks in names
 
-Product names, feature names, and non-GitLab products that contain spaces
-shouldn't be split across lines.
-For example: GitLab Community Edition or Amazon Web Services.
-Splitting product or feature names across lines makes searching for these items
-more difficult, and can cause problems if names change.
-
-For example, the following Markdown content is _not_ formatted correctly:
-
-```markdown
-When entering a product or feature name that includes a space (such as GitLab
-Community Edition), don't split the product or feature name across lines.
-```
-
-Instead, it should appear similar to the following:
-
-```markdown
-When entering a product or feature name that includes a space (such as
-GitLab Community Edition), don't split the product or feature name across lines.
-```
+If a feature or product name contains spaces, don't split the name with a line break.
+When names change, it is more complicated to search or grep text that has line breaks.
 
 ### Product tier badges
 
diff --git a/doc/development/i18n/externalization.md b/doc/development/i18n/externalization.md
index eae5db2994b..c5ed07fe24c 100644
--- a/doc/development/i18n/externalization.md
+++ b/doc/development/i18n/externalization.md
@@ -10,7 +10,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 For working with internationalization (i18n),
 [GNU gettext](https://www.gnu.org/software/gettext/) is used given it's the most
-used tool for this task and there are a lot of applications that will help us to
+used tool for this task and there are a lot of applications that help us
 work with it.
 
 TIP: **Tip:**
@@ -376,7 +376,7 @@ Namespaces should be PascalCase.
   s_('OpenedNDaysAgo|Opened')
   ```
 
-  In case the translation is not found it will return `Opened`.
+  In case the translation is not found it returns `Opened`.
 
 - In JavaScript:
 
@@ -417,12 +417,12 @@ To include formatting in the translated string, we can do the following:
 
   See the section on [interpolation](#interpolation).
 
-When [this translation helper issue](https://gitlab.com/gitlab-org/gitlab/-/issues/217935) is complete, we'll update the
+When [this translation helper issue](https://gitlab.com/gitlab-org/gitlab/-/issues/217935) is complete, we plan to update the
 process of including formatting in translated strings.
 
 #### Including Angle Brackets
 
-If a string contains angles brackets (`<`/`>`) that are not used for HTML, it will still be flagged by the
+If a string contains angles brackets (`<`/`>`) that are not used for HTML, it is still flagged by the
 `rake gettext:lint` linter.
 To avoid this error, use the applicable HTML entity code (`&lt;` or `&gt;`) instead:
 
@@ -473,7 +473,7 @@ This makes use of [`Intl.DateTimeFormat`](https://developer.mozilla.org/en-US/do
   1. **Through the `l` helper**, i.e. `l(active_session.created_at, format: :short)`. We have some predefined formats for
      [dates](https://gitlab.com/gitlab-org/gitlab/blob/4ab54c2233e91f60a80e5b6fa2181e6899fdcc3e/config/locales/en.yml#L54) and [times](https://gitlab.com/gitlab-org/gitlab/blob/4ab54c2233e91f60a80e5b6fa2181e6899fdcc3e/config/locales/en.yml#L262).
      If you need to add a new format, because other parts of the code could benefit from it,
-     you'll need to add it to [en.yml](https://gitlab.com/gitlab-org/gitlab/blob/master/config/locales/en.yml) file.
+     you can add it to [en.yml](https://gitlab.com/gitlab-org/gitlab/blob/master/config/locales/en.yml) file.
   1. **Through `strftime`**, i.e. `milestone.start_date.strftime('%b %-d')`. We use `strftime` in case none of the formats
      defined on [en.yml](https://gitlab.com/gitlab-org/gitlab/blob/master/config/locales/en.yml) matches the date/time
      specifications we need, and if there is no need to add it as a new format because is very particular (i.e. it's only used in a single view).
@@ -504,7 +504,7 @@ Examples:
 - Mappings for a dropdown list
 - Error messages
 
-To store these kinds of data, using a constant seems like the best choice, however this won't work for translations.
+To store these kinds of data, using a constant seems like the best choice, however this doesn't work for translations.
 
 Bad, avoid it:
 
@@ -518,7 +518,7 @@ class MyPresenter
 end
 ```
 
-The translation method (`_`) will be called when the class is loaded for the first time and translates the text to the default locale. Regardless of what's the user's locale, these values will not be translated again.
+The translation method (`_`) is called when the class is loaded for the first time and translates the text to the default locale. Regardless of the user's locale, these values are not translated a second time.
 
 Similar thing happens when using class methods with memoization.
 
@@ -536,7 +536,7 @@ class MyModel
 end
 ```
 
-This method will memoize the translations using the locale of the user, who first "called" this method.
+This method memorizes the translations using the locale of the user, who first "called" this method.
 
 To avoid these problems, keep the translations dynamic.
 
@@ -700,9 +700,9 @@ Now that the new content is marked for translation, we need to update
 bin/rake gettext:regenerate
 ```
 
-This command will update `locale/gitlab.pot` file with the newly externalized
+This command updates `locale/gitlab.pot` file with the newly externalized
 strings and remove any strings that aren't used anymore. You should check this
-file in. Once the changes are on master, they will be picked up by
+file in. Once the changes are on master, they are picked up by
 [CrowdIn](https://translate.gitlab.com) and be presented for
 translation.
 
@@ -719,7 +719,7 @@ running on CI as part of the `static-analysis` job.
 
 To lint the adjustments in PO files locally you can run `rake gettext:lint`.
 
-The linter will take the following into account:
+The linter takes the following into account:
 
 - Valid PO-file syntax
 - Variable usage
@@ -758,7 +758,7 @@ aren't in the message with ID `1 pipeline`.
 
 NOTE:
 [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/221012) in GitLab 13.3:
-Languages with less than 2% of translations won't be available in the UI.
+Languages with less than 2% of translations are not available in the UI.
 
 Let's suppose you want to add translations for a new language, let's say French.
 
diff --git a/doc/development/i18n/index.md b/doc/development/i18n/index.md
index 8790a17913b..eb435dd5ac0 100644
--- a/doc/development/i18n/index.md
+++ b/doc/development/i18n/index.md
@@ -9,13 +9,13 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 The text in GitLab's user interface is in American English by default.
 Each string can be translated to other languages.
 As each string is translated, it is added to the languages translation file,
-and will be available in future releases of GitLab.
+and is made available in future releases of GitLab.
 
 Contributions to translations are always needed.
 Many strings are not yet available for translation because they have not been externalized.
 Helping externalize strings benefits all languages.
 Some translations are incomplete or inconsistent.
-Translating strings will help complete and improve each language.
+Translating strings helps complete and improve each language.
 
 ## How to contribute
 
@@ -37,7 +37,7 @@ See [Externalization for GitLab](externalization.md).
 
 The translation process is managed at <https://translate.gitlab.com>
 using [CrowdIn](https://crowdin.com/).
-You will need to create an account before you can submit translations.
+You need to create an account before you can submit translations.
 Once you are signed in, select the language you wish to contribute translations to.
 
 Voting for translations is also valuable, helping to confirm good and flag inaccurate translations.
@@ -48,7 +48,7 @@ See [Translation guidelines](translation.md).
 
 Proofreading helps ensure the accuracy and consistency of translations. All
 translations are proofread before being accepted. If a translations requires
-changes, you will be notified with a comment explaining why.
+changes, you are notified with a comment explaining why.
 
 See [Proofreading Translations](proofreader.md) for more information on who's
 able to proofread and instructions on becoming a proofreader yourself.
diff --git a/doc/development/i18n/merging_translations.md b/doc/development/i18n/merging_translations.md
index 65e5c379961..582c1428bdd 100644
--- a/doc/development/i18n/merging_translations.md
+++ b/doc/development/i18n/merging_translations.md
@@ -27,8 +27,8 @@ If there are validation errors, the easiest solution is to disapprove
 the offending string in CrowdIn, leaving a comment with what is
 required to fix the offense. There is an
 [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/23256)
-suggesting to automate this process. Disapproving will exclude the
-invalid translation, the merge request will be updated within a few
+suggesting to automate this process. Disapproving excludes the
+invalid translation, the merge request is then updated within a few
 minutes.
 
 If the translation has failed validation due to angle brackets `<` or `>`
@@ -52,7 +52,7 @@ We are discussing [automating this entire process](https://gitlab.com/gitlab-org
 ## Recreate the merge request
 
 CrowdIn creates a new merge request as soon as the old one is closed
-or merged. But it won't recreate the `master-i18n` branch every
+or merged. But it does not recreate the `master-i18n` branch every
 time. To force CrowdIn to recreate the branch, close any [open merge
 request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&author_username=gitlab-crowdin-bot)
 and delete the
diff --git a/doc/development/i18n/proofreader.md b/doc/development/i18n/proofreader.md
index 674d7b213dc..a15eb4c3bc2 100644
--- a/doc/development/i18n/proofreader.md
+++ b/doc/development/i18n/proofreader.md
@@ -147,9 +147,9 @@ of contributing translations to the GitLab project.
    In the merge request description, include links to any projects you have
    previously translated.
 
-1. Your request to become a proofreader will be considered on the merits of
+1. Your request to become a proofreader is considered on the merits of
    your previous translations by [GitLab team members](https://about.gitlab.com/company/team/)
    or [Core team members](https://about.gitlab.com/community/core-team/) who are fluent in
    the language or current proofreaders.
    - When a request is made for the first proofreader for a language and there are no [GitLab team members](https://about.gitlab.com/company/team/)
-   or [Core team members](https://about.gitlab.com/community/core-team/) who speak the language, we will request links to previous translation work in other communities or projects.
+   or [Core team members](https://about.gitlab.com/community/core-team/) who speak the language, we shall request links to previous translation work in other communities or projects.
diff --git a/doc/development/i18n/translation.md b/doc/development/i18n/translation.md
index 11220e7f276..b5839926e25 100644
--- a/doc/development/i18n/translation.md
+++ b/doc/development/i18n/translation.md
@@ -23,7 +23,7 @@ You may create a new account or use any of their supported sign in services.
 GitLab is being translated into many languages.
 
 1. Select the language you would like to contribute translations to by clicking the flag
-1. You will see a list of files and folders.
+1. Next, you can view list of files and folders.
   Click `gitlab.pot` to open the translation editor.
 
 ### Translation Editor
@@ -34,7 +34,7 @@ The online translation editor is the easiest way to contribute translations.
 
 1. Strings for translation are listed in the left panel
 1. Translations are entered into the central panel.
-  Multiple translations will be required for strings that contains plurals.
+  Multiple translations are required for strings that contains plurals.
   The string to be translated is shown above with glossary terms highlighted.
   If the string to be translated is not clear, you can 'Request Context'
 
diff --git a/doc/development/import_export.md b/doc/development/import_export.md
index 6e3f6a49152..fd795880d2d 100644
--- a/doc/development/import_export.md
+++ b/doc/development/import_export.md
@@ -42,7 +42,7 @@ SIDEKIQ_MEMORY_KILLER_HARD_LIMIT_RSS = 3000000
 SIDEKIQ_MEMORY_KILLER_GRACE_TIME = 900
 ```
 
-An import status `started`, and the following Sidekiq logs will signal a memory issue:
+An import status `started`, and the following Sidekiq logs signal a memory issue:
 
 ```shell
 WARN: Work still in progress <struct with JID>
@@ -218,7 +218,7 @@ for compatibility when importing and exporting projects.
 
 ### When to bump the version up
 
-We will have to bump the version if we rename model/columns or perform any format
+If we rename model/columns or perform any format, we need to bump the version
 modifications in the JSON structure or the file structure of the archive file.
 
 We do not need to bump the version up in any of the following cases:
@@ -227,7 +227,7 @@ We do not need to bump the version up in any of the following cases:
 - Remove a column or model (unless there is a DB constraint)
 - Export new things (such as a new type of upload)
 
-Every time we bump the version, the integration specs will fail and can be fixed with:
+Every time we bump the version, the integration specs fail and can be fixed with:
 
 ```shell
 bundle exec rake gitlab:import_export:bump_version
@@ -355,7 +355,7 @@ The tools to generate the NDJSON tree from the human-readable JSON files live in
 
 **Please use `legacy-project-json-to-ndjson.sh` to generate the NDJSON tree.**
 
-The NDJSON tree will look like this:
+The NDJSON tree looks like:
 
 ```shell
 tree
@@ -389,7 +389,7 @@ tree
 
 **Please use `legacy-group-json-to-ndjson.rb` to generate the NDJSON tree.**
 
-The NDJSON tree will look like this:
+The NDJSON tree looks like this:
 
 ```shell
 tree
diff --git a/doc/development/permissions.md b/doc/development/permissions.md
index fae8a516e6f..35f0941b756 100644
--- a/doc/development/permissions.md
+++ b/doc/development/permissions.md
@@ -72,7 +72,7 @@ is stored in the `project_authorizations` table.
 
 WARNING:
 Due to [an issue](https://gitlab.com/gitlab-org/gitlab/-/issues/219299),
-projects in personal namespace will not show owner (`50`) permission in
+projects in personal namespace do not show owner (`50`) permission in
 `project_authorizations` table. Note however that [`user.owned_projects`](https://gitlab.com/gitlab-org/gitlab/blob/0d63823b122b11abd2492bca47cc26858eee713d/app/models/user.rb#L906-916)
 is calculated properly.
 
@@ -98,7 +98,7 @@ In the case of a complex resource, it should be broken into smaller pieces of in
 and each piece should be granted a different permission.
 
 A good example in this case is the _Merge Request widget_ and the _Security reports_.
-Depending on the visibility level of the _Pipelines_, the _Security reports_ will be either visible
+Depending on the visibility level of the _Pipelines_, the _Security reports_ are either visible
 in the widget or not. So, the _Merge Request widget_, the _Pipelines_, and the _Security reports_,
 have separate permissions. Moreover, the permissions for the _Merge Request widget_
 and the _Pipelines_ are dependencies of the _Security reports_.
diff --git a/doc/development/policies.md b/doc/development/policies.md
index 866dc2e585d..b60a101f564 100644
--- a/doc/development/policies.md
+++ b/doc/development/policies.md
@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 The DeclarativePolicy framework is designed to assist in performance of policy checks, and to enable ease of extension for EE. The DSL code in `app/policies` is what `Ability.allowed?` uses to check whether a particular action is allowed on a subject.
 
-The policy used is based on the subject's class name - so `Ability.allowed?(user, :some_ability, project)` will create a `ProjectPolicy` and check permissions on that.
+The policy used is based on the subject's class name - so `Ability.allowed?(user, :some_ability, project)` creates a `ProjectPolicy` and check permissions on that.
 
 ## Managing Permission Rules
 
@@ -16,7 +16,7 @@ Permissions are broken into two parts: `conditions` and `rules`. Conditions are
 
 ### Conditions
 
-Conditions are defined by the `condition` method, and are given a name and a block. The block will be executed in the context of the policy object - so it can access `@user` and `@subject`, as well as call any methods defined on the policy. Note that `@user` may be nil (in the anonymous case), but `@subject` is guaranteed to be a real instance of the subject class.
+Conditions are defined by the `condition` method, and are given a name and a block. The block is executed in the context of the policy object - so it can access `@user` and `@subject`, as well as call any methods defined on the policy. Note that `@user` may be nil (in the anonymous case), but `@subject` is guaranteed to be a real instance of the subject class.
 
 ```ruby
 class FooPolicy < BasePolicy
@@ -34,9 +34,9 @@ class FooPolicy < BasePolicy
 end
 ```
 
-When you define a condition, a predicate method is defined on the policy to check whether that condition passes - so in the above example, an instance of `FooPolicy` will also respond to `#is_public?` and `#thing?`.
+When you define a condition, a predicate method is defined on the policy to check whether that condition passes - so in the above example, an instance of `FooPolicy` also responds to `#is_public?` and `#thing?`.
 
-Conditions are cached according to their scope. Scope and ordering will be covered later.
+Conditions are cached according to their scope. Scope and ordering is covered later.
 
 ### Rules
 
@@ -69,7 +69,7 @@ Within the rule DSL, you can use:
 
 ## Scores, Order, Performance
 
-To see how the rules get evaluated into a judgment, it is useful in a console to use `policy.debug(:some_ability)`. This will print the rules in the order they are evaluated.
+To see how the rules get evaluated into a judgment, it is useful in a console to use `policy.debug(:some_ability)`. This prints the rules in the order they are evaluated.
 
 For example, let's say you wanted to debug `IssuePolicy`. You might run
 the debugger in this way:
@@ -109,9 +109,9 @@ When a policy is asked whether a particular ability is allowed
 compute all the conditions on the policy. First, only the rules relevant
 to that particular ability are selected. Then, the execution model takes
 advantage of short-circuiting, and attempts to sort rules based on a
-heuristic of how expensive they will be to calculate. The sorting is
-dynamic and cache-aware, so that previously calculated conditions will
-be considered first, before computing other conditions.
+heuristic of how expensive they are to calculate. The sorting is
+dynamic and cache-aware, so that previously calculated conditions are
+considered first, before computing other conditions.
 
 Note that the score is chosen by a developer via the `score:` parameter
 in a `condition` to denote how expensive evaluating this rule would be
@@ -119,7 +119,7 @@ relative to other rules.
 
 ## Scope
 
-Sometimes, a condition will only use data from `@user` or only from `@subject`. In this case, we want to change the scope of the caching, so that we don't recalculate conditions unnecessarily. For example, given:
+Sometimes, a condition only uses data from `@user` or only from `@subject`. In this case, we want to change the scope of the caching, so that we don't recalculate conditions unnecessarily. For example, given:
 
 ```ruby
 class FooPolicy < BasePolicy
@@ -135,10 +135,10 @@ Naively, if we call `Ability.allowed?(user1, :some_ability, foo)` and `Ability.a
   condition(:expensive_condition, scope: :subject) { @subject.expensive_query? }
 ```
 
-then the result of the condition will be cached globally only based on the subject - so it will not be calculated repeatedly for different users. Similarly, `scope: :user` will cache only based on the user.
+then the result of the condition is cached globally only based on the subject - so it is not calculated repeatedly for different users. Similarly, `scope: :user` caches only based on the user.
 
 **DANGER**: If you use a `:scope` option when the condition actually uses data from
-both user and subject (including a simple anonymous check!) your result will be cached at too global of a scope and will result in cache bugs.
+both user and subject (including a simple anonymous check!) your result is cached at too global of a scope and results in cache bugs.
 
 Sometimes we are checking permissions for a lot of users for one subject, or a lot of subjects for one user. In this case, we want to set a *preferred scope* - i.e. tell the system that we prefer rules that can be cached on the repeated parameter. For example, in `Ability.users_that_can_read_project`:
 
@@ -150,7 +150,7 @@ def users_that_can_read_project(users, project)
 end
 ```
 
-This will, for example, prefer checking `project.public?` to checking `user.admin?`.
+This, for example, prefers checking `project.public?` to checking `user.admin?`.
 
 ## Delegation
 
@@ -162,7 +162,7 @@ class FooPolicy < BasePolicy
 end
 ```
 
-will include all rules from `ProjectPolicy`. The delegated conditions will be evaluated with the correct delegated subject, and will be sorted along with the regular rules in the policy. Note that only the relevant rules for a particular ability will actually be considered.
+includes all rules from `ProjectPolicy`. The delegated conditions are evaluated with the correct delegated subject, and are sorted along with the regular rules in the policy. Note that only the relevant rules for a particular ability are actually considered.
 
 ### Overrides
 
@@ -203,7 +203,7 @@ end
 
 But the food preferences one is harder - because of the `prevent` call in the
 parent policy, if the parent dislikes it, even calling `enable` in the child
-will not enable `:eat_broccoli`.
+does not enable `:eat_broccoli`.
 
 We could remove the `prevent` call in the parent policy, but that still doesn't
 help us, since the rules are different: parents get to eat what they like, and
@@ -226,7 +226,7 @@ class ChildPolicy < BasePolicy
 end
 ```
 
-With this definition, the `ChildPolicy` will _never_ look in the `ParentPolicy` to
+With this definition, the `ChildPolicy` _never_ looks in the `ParentPolicy` to
 satisfy `:eat_broccoli`, but it _will_ use it for any other abilities. The child
 policy can then define `:eat_broccoli` in a way that makes sense for `Child` and not
 `Parent`.
@@ -243,7 +243,7 @@ Other approaches can include for example using different ability names. Choosing
 to eat a food and eating foods you are given are semantically distinct, and they
 could be named differently (perhaps `chooses_to_eat_broccoli` and
 `eats_what_is_given` in this case). It can depend on how polymorphic the call
-site is. If you know that we will always check the policy with a `Parent` or a
+site is. If you know that we always check the policy with a `Parent` or a
 `Child`, then we can choose the appropriate ability name. If the call site is
 polymorphic, then we cannot do that.
 
@@ -260,4 +260,4 @@ class Foo
 end
 ```
 
-This will use & check permissions on the `SomeOtherPolicy` class rather than the usual calculated `FooPolicy` class.
+This uses and checks permissions on the `SomeOtherPolicy` class rather than the usual calculated `FooPolicy` class.
diff --git a/doc/development/value_stream_analytics.md b/doc/development/value_stream_analytics.md
index 265e46d62e9..b3692bd1d2c 100644
--- a/doc/development/value_stream_analytics.md
+++ b/doc/development/value_stream_analytics.md
@@ -32,7 +32,7 @@ These events play a key role in the duration calculation.
 
 Formula: `duration = end_event_time - start_event_time`
 
-To make the duration calculation flexible, each `Event` is implemented as a separate class. They're responsible for defining a timestamp expression that will be used in the calculation query.
+To make the duration calculation flexible, each `Event` is implemented as a separate class. They're responsible for defining a timestamp expression that is used in the calculation query.
 
 #### Implementing an `Event` class
 
@@ -41,12 +41,12 @@ There are a few methods that are required to be implemented, the `StageEvent` ba
 - `object_type`
 - `timestamp_projection`
 
-The `object_type` method defines which domain object will be queried for the calculation. Currently two models are allowed:
+The `object_type` method defines which domain object is queried for the calculation. Currently two models are allowed:
 
 - `Issue`
 - `MergeRequest`
 
-For the duration calculation the `timestamp_projection` method will be used.
+For the duration calculation the `timestamp_projection` method is used.
 
 ```ruby
 def timestamp_projection
@@ -92,7 +92,7 @@ Some start/end event pairs are not "compatible" with each other. For example:
 The `StageEvents` module describes the allowed `start_event` and `end_event` pairings (`PAIRING_RULES` constant). If a new event is added, it needs to be registered in this module.
 ​To add a new event:​
 
-1. Add an entry in `ENUM_MAPPING` with a unique number, it'll be used in the `Stage` model as `enum`.
+1. Add an entry in `ENUM_MAPPING` with a unique number, which is used in the `Stage` model as `enum`.
 1. Define which events are compatible with the event in the `PAIRING_RULES` hash.
 
 Supported start/end event pairings:
@@ -185,19 +185,19 @@ Currently supported parents:
 1. User navigates to the value stream analytics page.
 1. User selects a group.
 1. Backend loads the defined stages for the selected group.
-1. Additions and modifications to the stages will be persisted within the selected group only.
+1. Additions and modifications to the stages are persisted within the selected group only.
 
 ### Default stages
 
 The [original implementation](https://gitlab.com/gitlab-org/gitlab/-/issues/847) of value stream analytics defined 7 stages. These stages are always available for each parent, however altering these stages is not possible.
 ​
-To make things efficient and reduce the number of records created, the default stages are expressed as in-memory objects (not persisted). When the user creates a custom stage for the first time, all the stages will be persisted. This behavior is implemented in the value stream analytics service objects.
+To make things efficient and reduce the number of records created, the default stages are expressed as in-memory objects (not persisted). When the user creates a custom stage for the first time, all the stages are persisted. This behavior is implemented in the value stream analytics service objects.
 ​
 The reason for this was that we'd like to add the abilities to hide and order stages later on.
 
 ## Data Collector
 
-`DataCollector` is the central point where the data will be queried from the database. The class always operates on a single stage and consists of the following components:
+`DataCollector` is the central point where the data is queried from the database. The class always operates on a single stage and consists of the following components:
 
 - `BaseQueryBuilder`:
   - Responsible for composing the initial query.
@@ -238,7 +238,7 @@ SELECT (START_EVENT_TIME-END_EVENT_TIME) as duration, END_EVENT.timestamp
 ## High-level overview
 
 - Rails Controller (`Analytics::CycleAnalytics` module): Value stream analytics exposes its data via JSON endpoints, implemented within the `analytics` workspace. Configuring the stages are also implements JSON endpoints (CRUD).
-- Services (`Analytics::CycleAnalytics` module): All `Stage` related actions will be delegated to respective service objects.
+- Services (`Analytics::CycleAnalytics` module): All `Stage` related actions are delegated to respective service objects.
 - Models (`Analytics::CycleAnalytics` module): Models are used to persist the `Stage` objects `ProjectStage` and `GroupStage`.
 - Feature classes (`Gitlab::Analytics::CycleAnalytics` module):
   - Responsible for composing queries and define feature specific business logic.
@@ -248,7 +248,7 @@ SELECT (START_EVENT_TIME-END_EVENT_TIME) as duration, END_EVENT.timestamp
 
 Since we have a lots of events and possible pairings, testing each pairing is not possible. The rule is to have at least one test case using an `Event` class.
 
-Writing a test case for a stage using a new `Event` can be challenging since data must be created for both events. To make this a bit simpler, each test case must be implemented in the `data_collector_spec.rb` where the stage is tested through the `DataCollector`. Each test case will be turned into multiple tests, covering the following cases:
+Writing a test case for a stage using a new `Event` can be challenging since data must be created for both events. To make this a bit simpler, each test case must be implemented in the `data_collector_spec.rb` where the stage is tested through the `DataCollector`. Each test case is turned into multiple tests, covering the following cases:
 
 - Different parents: `Group` or `Project`
 - Different calculations: `Median`, `RecordsFetcher` or `DataForDurationChart`
diff --git a/doc/install/digitaloceandocker.md b/doc/install/digitaloceandocker.md
index 9b582297389..edd081c66c1 100644
--- a/doc/install/digitaloceandocker.md
+++ b/doc/install/digitaloceandocker.md
@@ -12,7 +12,7 @@ recommended for ease of future upgrades or keeping the data you create.
 
 ## Initial setup
 
-In this guide you'll configure a Digital Ocean droplet and set up Docker
+This guide configures a Digital Ocean droplet and sets up Docker
 locally on either macOS or Linux.
 
 ### On macOS
@@ -39,10 +39,10 @@ The rest of the steps are identical for macOS and Linux.
 1. Login to Digital Ocean.
 1. Generate a new API token at <https://cloud.digitalocean.com/settings/api/tokens>.
 
-   This command will create a new DO droplet called `gitlab-test-env-do` that will act as a Docker host.
+   This command creates a new Digital Ocean droplet called `gitlab-test-env-do` that acts as a Docker host.
 
    NOTE:
-   4GB is the minimum requirement for a Docker host that will run more than one GitLab instance.
+   4GB is the minimum requirement for a Docker host that runs more than one GitLab instance.
 
    - RAM: 4GB
    - Name: `gitlab-test-env-do`
@@ -70,7 +70,7 @@ Resource: <https://docs.docker.com/machine/drivers/digital-ocean/>.
 
 ### Connect your shell to the new machine
 
-In this example we'll create a GitLab EE 8.10.8 instance.
+This example creates a GitLab EE 8.10.8 instance.
 
 First connect the Docker client to the Docker host you created previously.
 
diff --git a/doc/install/pivotal/index.md b/doc/install/pivotal/index.md
index de3fad584f1..1ac667898ab 100644
--- a/doc/install/pivotal/index.md
+++ b/doc/install/pivotal/index.md
@@ -10,7 +10,7 @@ WARNING:
 As of September 13, 2017, the GitLab Enterprise Plus for Pivotal Cloud Foundry
 tile on Pivotal Network has reached its End of Availability (“EoA”) and is no
 longer available for download or sale through Pivotal. Current customers with
-active subscriptions will continue to receive support from GitLab through their
+active subscriptions continue to receive support from GitLab through their
 subscription term. Pivotal and GitLab are collaborating on creating a new
 Kubernetes-based tile for the Pivotal Container Service. Please contact GitLab
 support with any questions regarding GitLab Enterprise Plus for Pivotal Cloud Foundry.
diff --git a/doc/security/webhooks.md b/doc/security/webhooks.md
index 939cd529f05..0bb8e90d38f 100644
--- a/doc/security/webhooks.md
+++ b/doc/security/webhooks.md
@@ -40,9 +40,9 @@ to endpoints like `http://localhost:123/some-resource/delete`.
 
 To prevent this type of exploitation from happening, starting with GitLab 10.6,
 all Webhook requests to the current GitLab instance server address and/or in a
-private network will be forbidden by default. That means that all requests made
+private network are forbidden by default. That means that all requests made
 to `127.0.0.1`, `::1` and `0.0.0.0`, as well as IPv4 `10.0.0.0/8`, `172.16.0.0/12`,
-`192.168.0.0/16` and IPv6 site-local (`ffc0::/10`) addresses won't be allowed.
+`192.168.0.0/16` and IPv6 site-local (`ffc0::/10`) addresses aren't allowed.
 
 This behavior can be overridden by enabling the option *"Allow requests to the
 local network from web hooks and services"* in the *"Outbound requests"* section
@@ -75,9 +75,9 @@ The allowlist can hold a maximum of 1000 entries. Each entry can be a maximum of
 255 characters.
 
 You can allow a particular port by specifying it in the allowlist entry.
-For example `127.0.0.1:8080` will only allow connections to port 8080 on `127.0.0.1`.
+For example `127.0.0.1:8080` only allows connections to port 8080 on `127.0.0.1`.
 If no port is mentioned, all ports on that IP/domain are allowed. An IP range
-will allow all ports on all IPs in that range.
+allows all ports on all IPs in that range.
 
 Example:
 
diff --git a/doc/system_hooks/system_hooks.md b/doc/system_hooks/system_hooks.md
index f590e6752a8..b3a74e62ba8 100644
--- a/doc/system_hooks/system_hooks.md
+++ b/doc/system_hooks/system_hooks.md
@@ -249,7 +249,7 @@ Please refer to `group_rename` and `user_rename` for that case.
 }
 ```
 
-If the user is blocked via LDAP, `state` will be `ldap_blocked`.
+If the user is blocked via LDAP, `state` is `ldap_blocked`.
 
 **User renamed:**
 
diff --git a/doc/tools/email.md b/doc/tools/email.md
index 71ebc400468..302279401f6 100644
--- a/doc/tools/email.md
+++ b/doc/tools/email.md
@@ -8,13 +8,13 @@ type: howto, reference
 # Email from GitLab **(STARTER ONLY)**
 
 GitLab provides a simple tool to administrators for emailing all users, or users of
-a chosen group or project, right from the Admin Area. Users will receive the email
+a chosen group or project, right from the Admin Area. Users receive the email
 at their primary email address.
 
 ## Use-cases
 
 - Notify your users about a new project, a new feature, or a new product launch.
-- Notify your users about a new deployment, or that will be downtime expected
+- Notify your users about a new deployment, or that downtime is expected
   for a particular reason.
 
 ## Sending emails to users from within GitLab
@@ -24,9 +24,9 @@ at their primary email address.
 
    ![admin users](email1.png)
 
-1. Compose an email and choose where it will be sent (all users or users of a
+1. Compose an email and choose where to send it (all users or users of a
    chosen group or project). The email body only supports plain text messages.
-   HTML, Markdown, and other rich text formats are not supported, and will be
+   HTML, Markdown, and other rich text formats are not supported, and is
    sent as plain text to users.
 
    ![compose an email](email2.png)
@@ -40,7 +40,7 @@ Users can choose to unsubscribe from receiving emails from GitLab by following
 the unsubscribe link in the email. Unsubscribing is unauthenticated in order
 to keep this feature simple.
 
-On unsubscribe, users will receive an email notification that unsubscribe happened.
+On unsubscribe, users receive an email notification that unsubscribe happened.
 The endpoint that provides the unsubscribe option is rate-limited.
 
 <!-- ## Troubleshooting
diff --git a/doc/update/mysql_to_postgresql.md b/doc/update/mysql_to_postgresql.md
index 98ff84632fd..613df2c3a84 100644
--- a/doc/update/mysql_to_postgresql.md
+++ b/doc/update/mysql_to_postgresql.md
@@ -51,7 +51,7 @@ For other distributions, follow the instructions in PostgreSQL's
 [download page](https://www.postgresql.org/download/) to add their repository
 and then install `pgloader`.
 
-If you are migrating to a Docker based installation, you will need to install
+If you are migrating to a Docker based installation, you must install
 pgloader within the container as it is not included in the container image.
 
 1. Start a shell session in the context of the running container:
@@ -69,7 +69,7 @@ pgloader within the container as it is not included in the container image.
 
 ## Omnibus GitLab installations
 
-For [Omnibus GitLab packages](https://about.gitlab.com/install/), you'll first
+For [Omnibus GitLab packages](https://about.gitlab.com/install/), you first
 need to enable the bundled PostgreSQL:
 
 1. Stop GitLab:
@@ -84,13 +84,13 @@ need to enable the bundled PostgreSQL:
    postgresql['enable'] = true
    ```
 
-1. Edit `/etc/gitlab/gitlab.rb` to use the bundled PostgreSQL. Please check
-   all the settings beginning with `db_`, such as `gitlab_rails['db_adapter']`
-   and alike. You could just comment all of them out so that we'll just use
-   the defaults.
+1. Edit `/etc/gitlab/gitlab.rb` to use the bundled PostgreSQL. Review all of the
+   settings beginning with `db_` (such as `gitlab_rails['db_adapter']`). To use
+   the default values, you can comment all of them out.
 
 1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure)
    for the changes to take effect.
+
 1. Start Unicorn and PostgreSQL so that we can prepare the schema:
 
    ```shell
@@ -110,9 +110,9 @@ need to enable the bundled PostgreSQL:
    sudo gitlab-ctl stop unicorn
    ```
 
-After these steps, you'll have a fresh PostgreSQL database with up-to-date schema.
+After these steps, you have a fresh PostgreSQL database with up-to-date schema.
 
-Next, we'll use `pgloader` to migrate the data from the old MySQL database to the
+Next, use `pgloader` to migrate the data from the old MySQL database to the
 new PostgreSQL one:
 
 1. Save the following snippet in a `commands.load` file, and edit with your
@@ -178,7 +178,7 @@ You can now verify that everything works as expected by visiting GitLab.
 
 ## Source installations
 
-For installations from source that use MySQL, you'll first need to
+For installations from source that use MySQL, you must first
 [install PostgreSQL and create a database](../install/installation.md#6-database).
 
 After the database is created, go on with the following steps:
@@ -211,9 +211,9 @@ After the database is created, go on with the following steps:
    sudo -u git -H bundle exec rake db:create db:migrate RAILS_ENV=production
    ```
 
-After these steps, you'll have a fresh PostgreSQL database with up-to-date schema.
+After these steps, you have a fresh PostgreSQL database with up-to-date schema.
 
-Next, we'll use `pgloader` to migrate the data from the old MySQL database to the
+Next, use `pgloader` to migrate the data from the old MySQL database to the
 new PostgreSQL one:
 
 1. Save the following snippet in a `commands.load` file, and edit with your
diff --git a/doc/update/restore_after_failure.md b/doc/update/restore_after_failure.md
index 6944479833b..0625cc5a68f 100644
--- a/doc/update/restore_after_failure.md
+++ b/doc/update/restore_after_failure.md
@@ -65,7 +65,7 @@ sudo gitlab-rake gitlab:db:mark_migration_complete[20151103134857]
 ```
 
 Once the migration is successfully marked, run the Rake `db:migrate` task again.
-You will likely have to repeat this process several times until all failed
+You might need to repeat this process several times until all failed
 migrations are marked complete.
 
 ### GitLab < 8.6
@@ -86,5 +86,5 @@ exit
 ```
 
 Once the migration is successfully marked, run the Rake `db:migrate` task again.
-You will likely have to repeat this process several times until all failed
+You might need to repeat this process several times until all failed
 migrations are marked complete.
diff --git a/doc/update/upgrading_from_ce_to_ee.md b/doc/update/upgrading_from_ce_to_ee.md
index 8e517534ef6..9a75326009c 100644
--- a/doc/update/upgrading_from_ce_to_ee.md
+++ b/doc/update/upgrading_from_ce_to_ee.md
@@ -128,7 +128,7 @@ sudo -u git -H bundle exec rake gitlab:backup:restore RAILS_ENV=production
 
 Certain versions of GitLab may require you to perform additional steps when
 upgrading from Community Edition to Enterprise Edition. Should such steps be
-necessary, they will listed per version below.
+necessary, they are listed per version below.
 
 <!--
 Example:
diff --git a/doc/update/upgrading_from_source.md b/doc/update/upgrading_from_source.md
index 13c13f60a30..2c8a8c3dda4 100644
--- a/doc/update/upgrading_from_source.md
+++ b/doc/update/upgrading_from_source.md
@@ -8,7 +8,7 @@ comments: false
 # Upgrading Community Edition and Enterprise Edition from source
 
 NOTE:
-Users wishing to upgrade to 12.0.0 will have to take some extra steps. See the
+Users wishing to upgrade to 12.0.0 must take some extra steps. See the
 version specific upgrade instructions for 12.0.0 for more details.
 
 Make sure you view this update guide from the branch (version) of GitLab you
@@ -284,12 +284,12 @@ longer handles setting it.
 
 If you are using Apache instead of NGINX see the updated [Apache templates](https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/web-server/apache).
 Also note that because Apache does not support upstreams behind Unix sockets you
-will need to let GitLab Workhorse listen on a TCP port. You can do this
+must let GitLab Workhorse listen on a TCP port. You can do this
 via [`/etc/default/gitlab`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/support/init.d/gitlab.default.example#L38).
 
 #### SMTP configuration
 
-If you're installing from source and use SMTP to deliver mail, you will need to
+If you're installing from source and use SMTP to deliver mail, you must
 add the following line to `config/initializers/smtp_settings.rb`:
 
 ```ruby
diff --git a/doc/update/upgrading_postgresql_using_slony.md b/doc/update/upgrading_postgresql_using_slony.md
index 38bc9d9600d..a512fc303d1 100644
--- a/doc/update/upgrading_postgresql_using_slony.md
+++ b/doc/update/upgrading_postgresql_using_slony.md
@@ -11,12 +11,12 @@ to the latest version without the need for hours of downtime. This guide assumes
 you have two database servers: one database server running an older version of
 PostgreSQL (e.g. 9.2.18) and one server running a newer version (e.g. 9.6.0).
 
-For this process we'll use a PostgreSQL replication tool called
+For this process we use a PostgreSQL replication tool called
 ["Slony"](https://www.slony.info/). Slony allows replication between different
 PostgreSQL versions and as such can be used to upgrade a cluster with a minimal
 amount of downtime.
 
-In various places we'll refer to the user `gitlab-psql`. This user should be the
+In various places we refer to the user `gitlab-psql`. This user should be the
 user used to run the various PostgreSQL OS processes. If you're using a
 different user (e.g. `postgres`) you should replace `gitlab-psql` with the name
 of said user. This guide also assumes your database is called
@@ -28,8 +28,8 @@ change this accordingly.
 Slony only replicates data and not any schema changes. As a result we must
 ensure that all databases have the same database structure.
 
-To do so we'll generate a dump of our current database. This dump will only
-contain the structure, not any data. To generate this dump run the following
+To do so, generate a dump of the current database. This dump only
+contains the structure, not any data. To generate this dump run the following
 command on your active database server:
 
 ```shell
@@ -49,20 +49,20 @@ command on your active database server:
 sudo -u gitlab-psql /opt/gitlab/embedded/bin/pg_dump -h /var/opt/gitlab/postgresql/ -p 5432 -U gitlab-psql -a -t schema_migrations -f /tmp/migrations.sql gitlabhq_production
 ```
 
-Next we'll need to move these files somewhere accessible by the new database
-server. The easiest way is to simply download these files to your local system:
+Next, move these files somewhere accessible by the new database
+server. The easiest way is to download these files to your local system:
 
 ```shell
 scp your-user@production-database-host:/tmp/*.sql /tmp
 ```
 
-This will copy all the SQL files located in `/tmp` to your local system's
+This copies all the SQL files located in `/tmp` to your local system's
 `/tmp` directory. Once copied you can safely remove the files from the database
 server.
 
 ## Installing Slony
 
-Slony will be used to upgrade the database without requiring a long downtime.
+Use Slony to upgrade the database without requiring a long downtime.
 Slony can be downloaded from <https://www.slony.info/>. If you have installed
 PostgreSQL using your operating system's package manager you may also be able to
 install Slony using said package manager.
@@ -94,7 +94,7 @@ test -f /opt/gitlab/embedded/bin/slonik_init_cluster && echo 'Slony Perl tools a
 ```
 
 This assumes Slony was installed to `/opt/gitlab/embedded`. If Slony was
-installed properly the output of these commands will be (the mentioned `slonik`
+installed properly the output of these commands is (the mentioned `slonik`
 version may be different):
 
 ```plaintext
@@ -106,8 +106,8 @@ slonik version 2.2.5
 ## Slony User
 
 Next we must set up a PostgreSQL user that Slony can use to replicate your
-database. To do so, log in to your production database using `psql` using a
-super user account. Once done run the following SQL queries:
+database. To do so, sign in to your production database using `psql` using a
+super-user account. After signing in, run the following SQL queries:
 
 ```sql
 CREATE ROLE slony WITH SUPERUSER LOGIN REPLICATION ENCRYPTED PASSWORD 'password string here';
@@ -115,20 +115,20 @@ ALTER ROLE slony SET statement_timeout TO 0;
 ```
 
 Make sure you replace "password string here" with the actual password for the
-user. A password is *required*. This user must be created on _both_ the old and
+user. A password is required. This user must be created on both the old and
 new database server using the same password.
 
-Once the user has been created make sure you note down the password as we will
-need it later on.
+After creating the user, be sure to note the password, as the password is needed
+later.
 
 ## Configuring Slony
 
-Now we can finally start configuring Slony. Slony uses a configuration file for
-most of the work so we'll need to set this one up. This configuration file
+We can now start configuring Slony. Slony uses a configuration file for
+most of the work so we need to set this one up. This configuration file
 specifies where to put log files, how Slony should connect to the databases,
 etc.
 
-First we'll need to create some required directories and set the correct
+First, create some required directories and set the correct
 permissions. To do so, run the following commands on both the old and new
 database server:
 
@@ -199,8 +199,7 @@ appropriate path to the `psql` executable.
 
 The above command outputs a list of tables in a format that can be copy-pasted
 directly into the above configuration file. Make sure to _replace_ `TABLES` with
-this output, don't just append it below it. Once done you'll end up with
-something like this:
+this output, don't just append it below it. The result looks like this:
 
 ```perl
 "pkeyedtables" => [
@@ -251,14 +250,14 @@ following:
  ... more rows here ...
 ```
 
-Now we can initialize the required tables and what not that Slony will use for
+Now we can initialize the required tables and what not that Slony uses for
 its replication process. To do so, run the following on the old database:
 
 ```shell
 sudo -u gitlab-psql /opt/gitlab/embedded/bin/slonik_init_cluster --conf /var/opt/gitlab/postgresql/slony/slon_tools.conf | /opt/gitlab/embedded/bin/slonik
 ```
 
-If all went well this will produce something along the lines of:
+If all went well this produces something along the lines of:
 
 ```plaintext
 <stdin>:10: Set up replication nodes
@@ -274,7 +273,7 @@ following on the old database:
 sudo -u gitlab-psql /opt/gitlab/embedded/bin/slon_start 1 --conf /var/opt/gitlab/postgresql/slony/slon_tools.conf
 ```
 
-If all went well this will produce output such as:
+If all went well this produces output such as:
 
 ```plaintext
 Invoke slon for node 1 - /opt/gitlab/embedded/bin/slon -p /var/run/slony1/slony_replication_node1.pid -s 1000 -d2  slony_replication 'host=192.168.0.7 dbname=gitlabhq_production user=slony port=5432 password=hieng8ezohHuCeiqu0leeghai4aeyahp' > /var/log/gitlab/slony/node1/gitlabhq_production-2016-10-06.log 2>&1 &
@@ -289,7 +288,7 @@ Next we need to run the following command on the _new_ database server:
 sudo -u gitlab-psql /opt/gitlab/embedded/bin/slon_start 2 --conf /var/opt/gitlab/postgresql/slony/slon_tools.conf
 ```
 
-This will produce similar output if all went well.
+This produces similar output if all went well.
 
 Next we need to tell the new database server what it should replicate. This can
 be done by running the following command on the _new_ database server:
@@ -324,7 +323,7 @@ This should produce the following output:
 <stdin>:6: Subscribed nodes to set 1
 ```
 
-At this point the new database server will start replicating the data of the old
+At this point the new database server starts replicating the data of the old
 database server. This process can take anywhere from a few minutes to hours, if
 not days. Unfortunately Slony itself doesn't really provide a way of knowing
 when the two databases are in sync. To get an estimate of the progress you can
@@ -357,19 +356,19 @@ function main {
 main
 ```
 
-This script will compare the sizes of the old and new database every minute and
+This script compares the sizes of the old and new database every minute and
 print the result to STDOUT as well as logging it to a file. Make sure to replace
 `SLONY_PASSWORD`, `OLD_HOST`, and `NEW_HOST` with the correct values.
 
 ## Stopping Replication
 
-At some point the two databases are in sync. Once this is the case you'll need
-to plan for a few minutes of downtime. This small downtime window is used to
-stop the replication process, remove any Slony data from both databases, restart
-GitLab so it can use the new database, etc.
+At some point, the two databases are in sync. If this is the case, you must plan
+for a few minutes of downtime. This small downtime window is used to stop the
+replication process, remove any Slony data from both databases, and restart
+GitLab so it can use the new database.
 
 First, let's stop all of GitLab. Omnibus users can do so by running the
-following on their GitLab server(s):
+following on their GitLab servers:
 
 ```shell
 sudo gitlab-ctl stop unicorn
@@ -377,14 +376,14 @@ sudo gitlab-ctl stop sidekiq
 sudo gitlab-ctl stop mailroom
 ```
 
-If you have any other processes that use PostgreSQL you should also stop those.
+If you have any other processes that use PostgreSQL, you should also stop those.
 
-Once everything has been stopped you should update any configuration settings,
-DNS records, etc so they all point to the new database.
+After everything has been stopped, be sure to update any configuration settings
+and DNS records so they all point to the new database.
 
-Once the settings have been taken care of we need to stop the replication
-process. It's crucial that no new data is written to the databases at this point
-as this data will be lost.
+When the settings have been taken care of, we need to stop the replication
+process. It's crucial that no new data is written to the databases at this point,
+as this data is discarded.
 
 To stop replication, run the following on both database servers:
 
@@ -392,7 +391,7 @@ To stop replication, run the following on both database servers:
 sudo -u gitlab-psql /opt/gitlab/embedded/bin/slon_kill --conf /var/opt/gitlab/postgresql/slony/slon_tools.conf
 ```
 
-This will stop all the Slony processes on the host the command was executed on.
+This stops all the Slony processes on the host the command was executed on.
 
 ## Resetting Sequences
 
@@ -469,7 +468,7 @@ Upload this script to the _target_ server and execute it as follows:
 bash path/to/the/script/above.sh
 ```
 
-This will correct the ownership of sequences and reset the next value for the
+This corrects the ownership of sequences and reset the next value for the
 `id` column to the next available value.
 
 ## Removing Slony
diff --git a/doc/user/group/epics/index.md b/doc/user/group/epics/index.md
index e87a5f4a801..af6c5c22ec3 100644
--- a/doc/user/group/epics/index.md
+++ b/doc/user/group/epics/index.md
@@ -15,15 +15,19 @@ that share a theme across projects and milestones.
 
 An epic's page contains the following tabs:
 
-- **Epics and Issues**: epics and issues added to this epic. Child epics, and their issues, are
-  shown in a tree view.
-  - Click the chevron (**>**) next to a parent epic to reveal the child epics and issues.
-  - Hover over the total counts to see a breakdown of open and closed items.
+- **Issues**: issues added to this epic.
+- **Epics and Issues**: epics and issues added to this epic.
+  Appears instead of the **Issues** tab if you have access to [multi-level epics](#multi-level-child-epics).
+  Child epics and their issues are shown in a tree view.
 
-  NOTE:
-  The number provided here includes all epics associated with this project. The number includes epics for which users may not yet have permission.
+  - To reveal the child epics and issues, select the chevron (**>**) next to a parent epic.
+  - To see a breakdown of open and closed items, hover over the total counts.
 
-- **Roadmap**: a roadmap view of child epics which have start and due dates.
+    The number provided here includes all epics associated with this project. The number includes
+    epics for which users may not yet have permission.
+
+- [**Roadmap**](#roadmap-in-epics): a roadmap view of child epics which have start and due dates.
+  Appears if you have access to [multi-level epics](#multi-level-child-epics).
 
 ![epic view](img/epic_view_v13.0.png)
 
@@ -143,7 +147,7 @@ Because the epic's dates can inherit dates from its children, the start date and
 If the start date of a child epic on the lowest level changes, that becomes the earliest possible start date for its parent epic.
 The parent epic's start date then reflects this change and propagates upwards to the top epic.
 
-## Roadmap in epics
+## Roadmap in epics **(ULTIMATE)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/7327) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.10.
 
diff --git a/doc/user/packages/conan_repository/index.md b/doc/user/packages/conan_repository/index.md
index 429effb974f..f4005f1b304 100644
--- a/doc/user/packages/conan_repository/index.md
+++ b/doc/user/packages/conan_repository/index.md
@@ -316,7 +316,7 @@ Prerequisites:
 1. Install the dependencies listed in `conanfile.txt`:
 
    ```shell
-   conan install <options>
+   conan install .. <options>
    ```
 
 NOTE:
diff --git a/doc/user/profile/account/two_factor_authentication.md b/doc/user/profile/account/two_factor_authentication.md
index 34fef0c3216..d5605240cbe 100644
--- a/doc/user/profile/account/two_factor_authentication.md
+++ b/doc/user/profile/account/two_factor_authentication.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Two-factor authentication (2FA) provides an additional level of security to your
 GitLab account. After being enabled, in addition to supplying your username and
-password to sign in, you'll be prompted for a code generated by your one-time
+password to sign in, you are prompted for a code generated by your one-time
 password authenticator (for example, a password manager on one of your devices).
 
 By enabling 2FA, the only way someone other than you can sign in to your account
@@ -22,20 +22,21 @@ TIP: **Tip:**
 When you enable 2FA, don't forget to back up your [recovery codes](#recovery-codes)!
 
 In addition to time-based one time passwords (TOTP), GitLab supports U2F
-(universal 2nd factor) and WebAuthn (experimental) devices as the second factor of authentication. Once
-enabled, in addition to supplying your username and password to log in, you'll
-be prompted to activate your U2F / WebAuthn device (usually by pressing a button on it),
-and it will perform secure authentication on your behalf.
+(universal 2nd factor) and WebAuthn (experimental) devices as the second factor
+of authentication. After being enabled, in addition to supplying your username
+and password to sign in, you're prompted to activate your U2F / WebAuthn device
+(usually by pressing a button on it) which performs secure authentication on
+your behalf.
 
-It is highly recommended that you set up 2FA with both a
-[one-time password authenticator](#one-time-password) or use [FortiAuthenticator](#one-time-password-via-fortiauthenticator)
-and a [U2F device](#u2f-device) or a [WebAuthn device](#webauthn-device), so you can still access your account
-if you lose your U2F / WebAuthn device.
+It's highly recommended that you set up 2FA with both a [one-time password authenticator](#one-time-password)
+or use [FortiAuthenticator](#one-time-password-via-fortiauthenticator) and a
+[U2F device](#u2f-device) or a [WebAuthn device](#webauthn-device), so you can
+still access your account if you lose your U2F / WebAuthn device.
 
 ## Enabling 2FA
 
-There are multiple ways to enable two-factor authentication: via a one time password authenticator
-or a U2F / WebAuthn device.
+There are multiple ways to enable two-factor authentication: by using a one-time
+password authenticator or a U2F / WebAuthn device.
 
 ### One-time password
 
@@ -62,8 +63,8 @@ To enable 2FA:
       code** field.
    1. Select **Submit**.
 
-If the pin you entered was correct, you'll see a message indicating that
-two-factor authentication has been enabled, and you'll be presented with a list
+If the pin you entered was correct, a message displays indicating that
+two-factor authentication has been enabled, and you're shown a list
 of [recovery codes](#recovery-codes). Be sure to download them and keep them
 in a safe place.
 
@@ -77,7 +78,7 @@ You can use FortiAuthenticator as an OTP provider in GitLab. Users must exist in
 both FortiAuthenticator and GitLab with the exact same username, and users must
 have FortiToken configured in FortiAuthenticator.
 
-You'll also need a username and access token for FortiAuthenticator. The
+You need a username and access token for FortiAuthenticator. The
 `access_token` in the code samples shown below is the FortAuthenticator access
 key. To get the token, see the `REST API Solution Guide` at
 [`Fortinet Document Library`](https://docs.fortinet.com/document/fortiauthenticator/6.2.0/rest-api-solution-guide/158294/the-fortiauthenticator-api).
@@ -170,9 +171,9 @@ To set up 2FA with a U2F device:
 1. Click **Enable Two-Factor Authentication**.
 1. Connect your U2F device.
 1. Click on **Set up New U2F Device**.
-1. A light will start blinking on your device. Activate it by pressing its button.
+1. A light begins blinking on your device. Activate it by pressing its button.
 
-You will see a message indicating that your device was successfully set up.
+A message displays, indicating that your device was successfully set up.
 Click on **Register U2F Device** to complete the process.
 
 ### WebAuthn device
@@ -208,7 +209,7 @@ To set up 2FA with a WebAuthn compatible device:
 1. Select **Set up New WebAuthn Device**.
 1. Depending on your device, you might need to press a button or touch a sensor.
 
-You will see a message indicating that your device was successfully set up.
+A message displays, indicating that your device was successfully set up.
 Recovery codes are not generated for WebAuthn devices.
 
 ## Recovery codes
@@ -219,12 +220,12 @@ Recovery codes are not generated for U2F / WebAuthn devices.
 WARNING:
 Each code can be used only once to log in to your account.
 
-Immediately after successfully enabling two-factor authentication, you'll be
+Immediately after successfully enabling two-factor authentication, you're
 prompted to download a set of generated recovery codes. Should you ever lose access
 to your one-time password authenticator, you can use one of these recovery codes to log in to
 your account. We suggest copying and printing them, or downloading them using
 the **Download codes** button for storage in a safe place. If you choose to
-download them, the file will be called `gitlab-recovery-codes.txt`.
+download them, the file is called `gitlab-recovery-codes.txt`.
 
 If you lose the recovery codes or just want to generate new ones, you can do so
 from the [two-factor authentication account settings page](#regenerate-2fa-recovery-codes) or
@@ -233,8 +234,8 @@ from the [two-factor authentication account settings page](#regenerate-2fa-recov
 ## Logging in with 2FA Enabled
 
 Logging in with 2FA enabled is only slightly different than a normal login.
-Enter your username and password credentials as you normally would, and you'll
-be presented with a second prompt, depending on which type of 2FA you've enabled.
+Enter your username and password credentials as you normally would, and you're
+presented with a second prompt, depending on which type of 2FA you've enabled.
 
 ### Log in via a one-time password
 
@@ -246,19 +247,19 @@ recovery code to log in.
 To log in via a U2F device:
 
 1. Click **Login via U2F Device**.
-1. A light will start blinking on your device. Activate it by touching/pressing
+1. A light begins blinking on your device. Activate it by touching/pressing
    its button.
 
-You will see a message indicating that your device responded to the authentication
-request and you will be automatically logged in.
+A message displays, indicating that your device responded to the authentication
+request, and you're automatically logged in.
 
 ### Log in via WebAuthn device
 
 In supported browsers you should be automatically prompted to activate your WebAuthn device
 (e.g. by touching/pressing its button) after entering your credentials.
 
-You will see a message indicating that your device responded to the authentication
-request and you will be automatically logged in.
+A message displays, indicating that your device responded to the authentication
+request and you're automatically logged in.
 
 ## Disabling 2FA
 
@@ -269,7 +270,7 @@ If you ever need to disable 2FA:
 1. Go to **Account**.
 1. Click **Disable**, under **Two-Factor Authentication**.
 
-This will clear all your two-factor authentication registrations, including mobile
+This clears all your two-factor authentication registrations, including mobile
 applications and U2F / WebAuthn devices.
 
 ## Personal access tokens
@@ -312,7 +313,7 @@ a new set of recovery codes with SSH:
    ssh git@gitlab.example.com 2fa_recovery_codes
    ```
 
-1. You will then be prompted to confirm that you want to generate new codes.
+1. You are prompted to confirm that you want to generate new codes.
    Continuing this process invalidates previously saved codes:
 
    ```shell
@@ -358,13 +359,13 @@ To regenerate 2FA recovery codes, you need access to a desktop browser:
 1. In the **Register Two-Factor Authenticator** pane, click **Regenerate recovery codes**.
 
 NOTE:
-If you regenerate 2FA recovery codes, save them. You won't be able to use any previously created 2FA codes.
+If you regenerate 2FA recovery codes, save them. You can't use any previously created 2FA codes.
 
 ### Ask a GitLab administrator to disable two-factor authentication on your account
 
 If you cannot use a saved recovery code or generate new recovery codes, ask a
 GitLab global administrator to disable two-factor authentication for your
-account. This will temporarily leave your account in a less secure state.
+account. This temporarily leaves your account in a less secure state.
 Sign in and re-enable two-factor authentication as soon as possible.
 
 ## Note to GitLab administrators
diff --git a/doc/user/profile/index.md b/doc/user/profile/index.md
index d8c766fbf6b..7c644afbb7d 100644
--- a/doc/user/profile/index.md
+++ b/doc/user/profile/index.md
@@ -305,7 +305,7 @@ you are asked to sign in again to verify your identity for security reasons.
 NOTE:
 When any session is signed out, or when a session is revoked
 via [Active Sessions](active_sessions.md), all **Remember me** tokens are revoked.
-While other sessions will remain active, the **Remember me** feature will not restore
+While other sessions remain active, the **Remember me** feature doesn't restore
 a session if the browser is closed or the existing session expires.
 
 ### Increased sign-in time
diff --git a/doc/user/profile/notifications.md b/doc/user/profile/notifications.md
index 0a2a48db955..8974505cf02 100644
--- a/doc/user/profile/notifications.md
+++ b/doc/user/profile/notifications.md
@@ -21,7 +21,7 @@ You receive notifications for one of the following reasons:
 While notifications are enabled, you receive notification of actions occurring in that issue, merge request, or epic.
 
 NOTE:
-Notifications can be blocked by an admin, preventing them from being sent.
+Notifications can be blocked by an administrator, preventing them from being sent.
 
 ## Tuning your notifications
 
diff --git a/doc/user/project/description_templates.md b/doc/user/project/description_templates.md
index 7217839141f..27ccd36d9ae 100644
--- a/doc/user/project/description_templates.md
+++ b/doc/user/project/description_templates.md
@@ -26,7 +26,7 @@ are added to the root directory of a GitLab project's repository.
 
 Description templates must be written in [Markdown](../markdown.md) and stored
 in your project's repository under a directory named `.gitlab`. Only the
-templates of the default branch will be taken into account.
+templates of the default branch are taken into account.
 
 ## Use-cases
 
@@ -53,7 +53,7 @@ To create a Markdown file:
     example `feature_request.md` or `Feature Request.md`.
  1. Commit and push to your default branch.
 
-If you don't have a `.gitlab/issue_templates` directory in your repository, you'll need to create it.
+If you don't have a `.gitlab/issue_templates` directory in your repository, you need to create it.
 
 To create the `.gitlab/issue_templates` directory:
 
@@ -74,10 +74,10 @@ push to your default branch.
 ## Using the templates
 
 Let's take for example that you've created the file `.gitlab/issue_templates/Bug.md`.
-This will enable the `Bug` dropdown option when creating or editing issues. When
-`Bug` is selected, the content from the `Bug.md` template file will be copied
-to the issue description field. The 'Reset template' button will discard any
-changes you made after picking the template and return it to its initial status.
+This enables the `Bug` dropdown option when creating or editing issues. When
+`Bug` is selected, the content from the `Bug.md` template file is copied
+to the issue description field. The **Reset template** button discards any
+changes you made after picking the template and returns it to its initial status.
 
 TIP: **Tip:**
 You can create short-cut links to create an issue using a designated template. For example: `https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20proposal`.
@@ -92,7 +92,7 @@ You can create short-cut links to create an issue using a designated template. F
 
 The visibility of issues and/or merge requests should be set to either "Everyone
 with access" or "Only Project Members" in your project's **Settings / Visibility, project features, permissions** section, otherwise the
-template text areas won't show. This is the default behavior so in most cases
+template text areas don't show. This is the default behavior, so in most cases
 you should be fine.
 
 1. Go to your project's **Settings**.
@@ -108,7 +108,7 @@ you should be fine.
 ![Default issue description templates](img/description_templates_issue_settings.png)
 
 After you add the description, hit **Save changes** for the settings to take
-effect. Now, every time a new merge request or issue is created, it will be
+effect. Now, every time a new merge request or issue is created, it is 
 pre-filled with the text you entered in the template(s).
 
 ## Description template example
@@ -119,7 +119,7 @@ for some examples.
 
 TIP: **Tip:**
 It's possible to use [quick actions](quick_actions.md) within description templates to quickly add
-labels, assignees, and milestones. The quick actions will only be executed if the user submitting
+labels, assignees, and milestones. The quick actions are only executed if the user submitting
 the issue or merge request has the permissions to perform the relevant actions.
 
 Here is an example of a Bug report template:
diff --git a/doc/user/project/import/github.md b/doc/user/project/import/github.md
index a41230fa9bf..2c57edc8845 100644
--- a/doc/user/project/import/github.md
+++ b/doc/user/project/import/github.md
@@ -23,6 +23,8 @@ The following aspects of a project are imported:
 - Labels (GitLab.com & 8.7+)
 - Release note descriptions (GitLab.com & 8.12+)
 - Pull request review comments (GitLab.com & 10.2+)
+- Pull request reviews (GitLab.com & 13.7+)
+- Pull request "merged by" information (GitLab.com & 13.7+)
 - Regular issue and pull request comments
 - [Git Large File Storage (LFS) Objects](../../../topics/git/lfs/index.md)
 
@@ -59,9 +61,9 @@ For this association to succeed, each GitHub author and assignee in the reposito
 must meet one of the following conditions prior to the import:
 
 - Have previously logged in to a GitLab account using the GitHub icon.
-- Have a GitHub account with a
-  [primary email address](https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address)
-  that matches their GitLab account's email address.
+- Have a GitHub account with a publicly visible
+  [primary email address](https://docs.github.com/en/free-pro-team@latest/rest/reference/users#get-a-user)
+  on their profile that matches their GitLab account's email address.
 
 If a user referenced in the project is not found in GitLab's database, the project creator (typically the user
 that initiated the import process) is set as the author/assignee, but a note on the issue mentioning the original
@@ -89,7 +91,7 @@ Before you begin, ensure that any GitHub users who you want to map to GitLab use
 
 - A GitLab account that has logged in using the GitHub icon
   \- or -
-- A GitLab account with an email address that matches the [public email address](https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address) of the GitHub user
+- A GitLab account with an email address that matches the [publicly visible email address](https://docs.github.com/en/free-pro-team@latest/rest/reference/users#get-a-user) in the profile of the GitHub user
 
 User-matching attempts occur in that order, and if a user is not identified either way, the activity is associated with
 the user account that is performing the import.
diff --git a/doc/user/todos.md b/doc/user/todos.md
index be4b6cc0c5a..be50e3b1567 100644
--- a/doc/user/todos.md
+++ b/doc/user/todos.md
@@ -72,7 +72,7 @@ prevent data loss, in the case where a user's access is accidentally revoked.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7926) in GitLab 9.0.
 
-If you're mentioned at the start of a line, the to-do item you receive will be
+If you're mentioned at the start of a line, the to-do item you receive is 
 listed as *directly addressed*. For example, in the following comment:
 
 ```markdown
@@ -104,7 +104,7 @@ You can also add the following to your To-Do List by clicking the **Add a to do*
 
 ## Marking a to-do item as done
 
-Any action to an issue or merge request (or epic **(ULTIMATE)**) will mark its
+Any action to an issue or merge request (or epic **(PREMIUM)**) marks its
 corresponding to-do item as done.
 
 Actions that dismiss to-do items include:
diff --git a/lib/gitlab/checks/push_check.rb b/lib/gitlab/checks/push_check.rb
index 7cc5bc56cbb..4ee53eea25a 100644
--- a/lib/gitlab/checks/push_check.rb
+++ b/lib/gitlab/checks/push_check.rb
@@ -14,7 +14,7 @@ module Gitlab
       private
 
       def can_push?
-        user_access.can_do_action?(:push_code) ||
+        user_access.can_push_to_branch?(ref) ||
           project.branch_allows_collaboration?(user_access.user, branch_name)
       end
     end
diff --git a/lib/gitlab/git_access.rb b/lib/gitlab/git_access.rb
index 5ed4322341e..5216643b351 100644
--- a/lib/gitlab/git_access.rb
+++ b/lib/gitlab/git_access.rb
@@ -319,11 +319,11 @@ module Gitlab
     end
 
     def check_change_access!
-      # Deploy keys with write access can push anything
-      return if deploy_key?
+      return if deploy_key? && !deploy_keys_on_protected_branches_enabled?
 
       if changes == ANY
-        can_push = user_can_push? ||
+        can_push = (deploy_key? && deploy_keys_on_protected_branches_enabled?) ||
+                   user_can_push? ||
           project&.any_branch_allows_collaboration?(user_access.user)
 
         unless can_push
@@ -449,6 +449,8 @@ module Gitlab
                          CiAccess.new
                        elsif user && request_from_ci_build?
                          BuildAccess.new(user, container: container)
+                       elsif deploy_key? && deploy_keys_on_protected_branches_enabled?
+                         DeployKeyAccess.new(deploy_key, container: container)
                        else
                          UserAccess.new(user, container: container)
                        end
@@ -526,6 +528,10 @@ module Gitlab
     def size_checker
       container.repository_size_checker
     end
+
+    def deploy_keys_on_protected_branches_enabled?
+      Feature.enabled?(:deploy_keys_on_protected_branches, project)
+    end
   end
 end
 
diff --git a/spec/lib/gitlab/checks/push_check_spec.rb b/spec/lib/gitlab/checks/push_check_spec.rb
index 45ab13cf0cf..3ec38ec83bb 100644
--- a/spec/lib/gitlab/checks/push_check_spec.rb
+++ b/spec/lib/gitlab/checks/push_check_spec.rb
@@ -12,7 +12,7 @@ RSpec.describe Gitlab::Checks::PushCheck do
 
     context 'when the user is not allowed to push to the repo' do
       it 'raises an error' do
-        expect(user_access).to receive(:can_do_action?).with(:push_code).and_return(false)
+        expect(user_access).to receive(:can_push_to_branch?).and_return(false)
         expect(project).to receive(:branch_allows_collaboration?).with(user_access.user, 'master').and_return(false)
 
         expect { subject.validate! }.to raise_error(Gitlab::GitAccess::ForbiddenError, 'You are not allowed to push code to this project.')
diff --git a/spec/models/clusters/cluster_spec.rb b/spec/models/clusters/cluster_spec.rb
index ed74a841044..a8f81cba285 100644
--- a/spec/models/clusters/cluster_spec.rb
+++ b/spec/models/clusters/cluster_spec.rb
@@ -262,14 +262,14 @@ RSpec.describe Clusters::Cluster, :use_clean_rails_memory_store_caching do
     end
   end
 
-  describe '.with_project_alert_service_data' do
-    subject { described_class.with_project_alert_service_data(project_id) }
+  describe '.with_project_http_integrations' do
+    subject { described_class.with_project_http_integrations(project_id) }
 
     let!(:cluster) { create(:cluster, :project) }
     let!(:project_id) { cluster.first_project.id }
 
     context 'project has alert service data' do
-      let!(:alerts_service) { create(:alerts_service, project: cluster.clusterable) }
+      let!(:integration) { create(:alert_management_http_integration, project: cluster.clusterable) }
 
       it { is_expected.to include(cluster) }
     end
diff --git a/spec/models/protected_branch/push_access_level_spec.rb b/spec/models/protected_branch/push_access_level_spec.rb
index 0688df057a4..051cb78a6b6 100644
--- a/spec/models/protected_branch/push_access_level_spec.rb
+++ b/spec/models/protected_branch/push_access_level_spec.rb
@@ -75,4 +75,18 @@ RSpec.describe ProtectedBranch::PushAccessLevel do
       end
     end
   end
+
+  describe '#type' do
+    let(:push_level_access) { build(:protected_branch_push_access_level) }
+
+    it 'returns :deploy_key when a deploy key is tied to the protected branch' do
+      push_level_access.deploy_key = create(:deploy_key)
+
+      expect(push_level_access.type).to eq(:deploy_key)
+    end
+
+    it 'returns :role by default' do
+      expect(push_level_access.type).to eq(:role)
+    end
+  end
 end
diff --git a/spec/services/clusters/applications/prometheus_health_check_service_spec.rb b/spec/services/clusters/applications/prometheus_health_check_service_spec.rb
index fc5a80688e6..ee47d00f700 100644
--- a/spec/services/clusters/applications/prometheus_health_check_service_spec.rb
+++ b/spec/services/clusters/applications/prometheus_health_check_service_spec.rb
@@ -18,7 +18,7 @@ RSpec.describe Clusters::Applications::PrometheusHealthCheckService, '#execute'
   RSpec.shared_examples 'sends alert' do
     it 'sends an alert' do
       expect_next_instance_of(Projects::Alerting::NotifyService) do |notify_service|
-        expect(notify_service).to receive(:execute).with(alerts_service.token)
+        expect(notify_service).to receive(:execute).with(integration.token, integration)
       end
 
       subject
@@ -40,8 +40,8 @@ RSpec.describe Clusters::Applications::PrometheusHealthCheckService, '#execute'
   end
 
   context 'when cluster is project_type' do
-    let_it_be(:alerts_service) { create(:alerts_service) }
-    let_it_be(:project) { create(:project, alerts_service: alerts_service) }
+    let_it_be(:project) { create(:project) }
+    let_it_be(:integration) { create(:alert_management_http_integration, project: project) }
     let(:applications_prometheus_healthy) { true }
     let(:prometheus) { create(:clusters_applications_prometheus, status: prometheus_status_value, healthy: applications_prometheus_healthy) }
     let(:cluster) { create(:cluster, :project, application_prometheus: prometheus, projects: [project]) }
diff --git a/spec/workers/clusters/applications/check_prometheus_health_worker_spec.rb b/spec/workers/clusters/applications/check_prometheus_health_worker_spec.rb
index 5a37031a55a..fb779bf3b01 100644
--- a/spec/workers/clusters/applications/check_prometheus_health_worker_spec.rb
+++ b/spec/workers/clusters/applications/check_prometheus_health_worker_spec.rb
@@ -8,7 +8,7 @@ RSpec.describe Clusters::Applications::CheckPrometheusHealthWorker, '#perform' d
   it 'triggers health service' do
     cluster = create(:cluster)
     allow(Gitlab::Monitor::DemoProjects).to receive(:primary_keys)
-    allow(Clusters::Cluster).to receive_message_chain(:with_application_prometheus, :with_project_alert_service_data).and_return([cluster])
+    allow(Clusters::Cluster).to receive_message_chain(:with_application_prometheus, :with_project_http_integrations).and_return([cluster])
 
     service_instance = instance_double(Clusters::Applications::PrometheusHealthCheckService)
     expect(Clusters::Applications::PrometheusHealthCheckService).to receive(:new).with(cluster).and_return(service_instance)