Merge branch 'no-more-bosses' into 'master' 27019-merge-when-pipeline-succeeds-visible-if-approvals-are-pending

Rename endboss -> maintainer, miniboss -> reviewer

See merge request !8719

2 files changed, 10 insertions, 10 deletions

diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index 1ef34c79971..e4a0e0b92bc 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -9,7 +9,7 @@ code is effective, understandable, and maintainable.
 
 Any developer can, and is encouraged to, perform code review on merge requests
 of colleagues and contributors. However, the final decision to accept a merge
-request is up to one of our merge request "endbosses", denoted on the
+request is up to one the project's maintainers, denoted on the
 [team page](https://about.gitlab.com/team).
 
 ## Everyone
@@ -81,15 +81,15 @@ balance in how deep the reviewer can interfere with the code created by a
 reviewee.
 
 - Learning how to find the right balance takes time; that is why we have
-  minibosses that become merge request endbosses after some time spent on
-  reviewing merge requests.
+  reviewers that become maintainers after some time spent on reviewing merge
+  requests.
 - Finding bugs and improving code style is important, but thinking about good
   design is important as well. Building abstractions and good design is what
   makes it possible to hide complexity and makes future changes easier.
 - Asking the reviewee to change the design sometimes means the complete rewrite
-  of the contributed code. It's usually a good idea to ask another merge
-  request endboss before doing it, but have the courage to do it when you
-  believe it is important.
+  of the contributed code. It's usually a good idea to ask another maintainer or
+  reviewer before doing it, but have the courage to do it when you believe it is
+  important.
 - There is a difference in doing things right and doing things right now.
   Ideally, we should do the former, but in the real world we need the latter as
   well. A good example is a security fix which should be released as soon as
diff --git a/doc/development/merge_request_performance_guidelines.md b/doc/development/merge_request_performance_guidelines.md
index 0363bf8c1d5..8232a0a113c 100644
--- a/doc/development/merge_request_performance_guidelines.md
+++ b/doc/development/merge_request_performance_guidelines.md
@@ -3,7 +3,7 @@
 To ensure a merge request does not negatively impact performance of GitLab
 _every_ merge request **must** adhere to the guidelines outlined in this
 document. There are no exceptions to this rule unless specifically discussed
-with and agreed upon by merge request endbosses and performance specialists.
+with and agreed upon by backend maintainers and performance specialists.
 
 To measure the impact of a merge request you can use
 [Sherlock](profiling.md#sherlock). It's also highly recommended that you read
@@ -40,9 +40,9 @@ section below for more information.
 about the impact.
 
 Sometimes it's hard to assess the impact of a merge request. In this case you
-should ask one of the merge request (mini) endbosses to review your changes. You
-can find a list of these endbosses at <https://about.gitlab.com/team/>. An
-endboss in turn can request a performance specialist to review the changes.
+should ask one of the merge request reviewers to review your changes. You can
+find a list of these reviewers at <https://about.gitlab.com/team/>. A reviewer
+in turn can request a performance specialist to review the changes.
 
 ## Query Counts