kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Rename endboss -> maintainer, miniboss -> reviewer

Browse source 
We want to describe these roles in a way that is more understandable to
people not familiar with GitLab.
This commit is contained in:
Sean McGivern 2017-01-13 16:12:02 +00:00
parent 4b43126d08
commit e2585e642a
2 changed files with 10 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
doc/development/code_review.md
View file

@ -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

8
doc/development/merge_request_performance_guidelines.md
View file

@ -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