Merge branch 'no-more-bosses' into 'master'
Rename endboss -> maintainer, miniboss -> reviewer See merge request !8719
This commit is contained in:
commit
2d3fcf9048
|
@ -9,7 +9,7 @@ code is effective, understandable, and maintainable.
|
||||||
|
|
||||||
Any developer can, and is encouraged to, perform code review on merge requests
|
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
|
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).
|
[team page](https://about.gitlab.com/team).
|
||||||
|
|
||||||
## Everyone
|
## Everyone
|
||||||
|
@ -81,15 +81,15 @@ balance in how deep the reviewer can interfere with the code created by a
|
||||||
reviewee.
|
reviewee.
|
||||||
|
|
||||||
- Learning how to find the right balance takes time; that is why we have
|
- 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
|
reviewers that become maintainers after some time spent on reviewing merge
|
||||||
reviewing merge requests.
|
requests.
|
||||||
- Finding bugs and improving code style is important, but thinking about good
|
- Finding bugs and improving code style is important, but thinking about good
|
||||||
design is important as well. Building abstractions and good design is what
|
design is important as well. Building abstractions and good design is what
|
||||||
makes it possible to hide complexity and makes future changes easier.
|
makes it possible to hide complexity and makes future changes easier.
|
||||||
- Asking the reviewee to change the design sometimes means the complete rewrite
|
- 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
|
of the contributed code. It's usually a good idea to ask another maintainer or
|
||||||
request endboss before doing it, but have the courage to do it when you
|
reviewer before doing it, but have the courage to do it when you believe it is
|
||||||
believe it is important.
|
important.
|
||||||
- There is a difference in doing things right and doing things right now.
|
- 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
|
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
|
well. A good example is a security fix which should be released as soon as
|
||||||
|
|
|
@ -3,7 +3,7 @@
|
||||||
To ensure a merge request does not negatively impact performance of GitLab
|
To ensure a merge request does not negatively impact performance of GitLab
|
||||||
_every_ merge request **must** adhere to the guidelines outlined in this
|
_every_ merge request **must** adhere to the guidelines outlined in this
|
||||||
document. There are no exceptions to this rule unless specifically discussed
|
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
|
To measure the impact of a merge request you can use
|
||||||
[Sherlock](profiling.md#sherlock). It's also highly recommended that you read
|
[Sherlock](profiling.md#sherlock). It's also highly recommended that you read
|
||||||
|
@ -40,9 +40,9 @@ section below for more information.
|
||||||
about the impact.
|
about the impact.
|
||||||
|
|
||||||
Sometimes it's hard to assess the impact of a merge request. In this case you
|
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
|
should ask one of the merge request reviewers to review your changes. You can
|
||||||
can find a list of these endbosses at <https://about.gitlab.com/team/>. An
|
find a list of these reviewers at <https://about.gitlab.com/team/>. A reviewer
|
||||||
endboss in turn can request a performance specialist to review the changes.
|
in turn can request a performance specialist to review the changes.
|
||||||
|
|
||||||
## Query Counts
|
## Query Counts
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue