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

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