Add latest changes from gitlab-org/gitlab@master

2 files changed, 18 insertions, 7 deletions

diff --git a/doc/administration/monitoring/prometheus/gitlab_metrics.md b/doc/administration/monitoring/prometheus/gitlab_metrics.md
index 63715df45e1..26b9fac8b79 100644
--- a/doc/administration/monitoring/prometheus/gitlab_metrics.md
+++ b/doc/administration/monitoring/prometheus/gitlab_metrics.md
@@ -52,7 +52,7 @@ The following metrics are available:
 | `gitlab_ci_active_jobs`                                          | Histogram   | 14.2    | Count of active jobs when pipeline is created                                                                         |                                                           |
 | `gitlab_database_transaction_seconds`                            | Histogram   | 12.1    | Time spent in database transactions, in seconds                                                                       |                                                           |
 | `gitlab_method_call_duration_seconds`                            | Histogram   | 10.2    | Method calls real duration                                                                                            | `controller`, `action`, `module`, `method`                |
-| `gitlab_omniauth_login_total`                                    | Counter     | 16.1    | Total number of OmniAuth logins attempts                                                                              | `provider`, `status`                                      |
+| `gitlab_omniauth_login_total`                                    | Counter     | 16.1    | Total number of OmniAuth logins attempts                                                                              | `omniauth_provider`, `status`                             |
 | `gitlab_page_out_of_bounds`                                      | Counter     | 12.8    | Counter for the PageLimiter pagination limit being hit                                                                | `controller`, `action`, `bot`                             |
 | `gitlab_rails_boot_time_seconds`                                 | Gauge       | 14.8    | Time elapsed for Rails primary process to finish startup                                               |                                                           |
 | `gitlab_rails_queue_duration_seconds`                            | Histogram   | 9.4     | Measures latency between GitLab Workhorse forwarding a request to Rails                                               |                                                           |
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index c3f3ea12472..2091af0d9ae 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -564,8 +564,19 @@ Before taking the decision to merge:
 - If the MR contains both Quality and non-Quality-related changes, the MR should be merged by the relevant maintainer for user-facing changes (backend, frontend, or database) after the Quality related changes are approved by a Software Engineer in Test.
 
 At least one maintainer must approve an MR before it can be merged. MR authors and
-people who add commits to an MR are not authorized to approve or merge the MR and
-must seek a maintainer who has not contributed to the MR to approve and merge it.
+people who add commits to an MR are not authorized to approve the MR and
+must seek a maintainer who has not contributed to the MR to approve it. In
+general, the final required approver should merge the MR.
+
+Scenarios in which the final approver might not merge an MR:
+
+- Approver forgets to set auto-merge after approving.
+- Approver doesn't realize that they are the final approver.
+- Approver sets auto-merge but it is un-set by GitLab.
+
+If any of these scenarios occurs, an MR author may merge their own MR if it
+has all required approvals and they have merge rights to the repository.
+This is also in line with the GitLab [bias for action](https://handbook.gitlab.com/handbook/values/#bias-for-action) value.
 
 This policy is in place to satisfy the CHG-04 control of the GitLab
 [Change Management Controls](https://about.gitlab.com/handbook/security/change-management-policy.html).
@@ -576,14 +587,14 @@ settings to ensure MRs get an approval from a top-level CODEOWNERS maintainer:
 - [Prevent approval by author](../user/project/merge_requests/approvals/settings.md#prevent-approval-by-author).
 - [Prevent approvals by users who add commits](../user/project/merge_requests/approvals/settings.md#prevent-approvals-by-users-who-add-commits).
 - [Prevent editing approval rules in merge requests](../user/project/merge_requests/approvals/settings.md#prevent-editing-approval-rules-in-merge-requests).
-- [Remove all approvals when commits are added to the source branch](../user/project/merge_requests/approvals/settings.md#remove-all-approvals-when-commits-are-added-to-the-source-branch)
+- [Remove all approvals when commits are added to the source branch](../user/project/merge_requests/approvals/settings.md#remove-all-approvals-when-commits-are-added-to-the-source-branch).
 
 To update the code owners in the `CODEOWNERS` file for `gitlab-org/gitlab`, follow
 the process explained in the [code owners approvals handbook section](https://about.gitlab.com/handbook/engineering/workflow/code-review/#code-owner-approvals).
 
-  There are scenarios such as rebasing locally or applying suggestions that are considered
-  the same as adding a commit and could reset existing approvals. Approvals are not removed
-  when rebasing from the UI or with the [`/rebase` quick action](../user/project/quick_actions.md).
+Some actions, such as rebasing locally or applying suggestions, are considered
+the same as adding a commit and could reset existing approvals. Approvals are not removed
+when rebasing from the UI or with the [`/rebase` quick action](../user/project/quick_actions.md).
 
 When ready to merge: