diff options
| author | Rémy Coutable <remy@rymai.me> | 2016-10-07 16:17:28 +0200 |
|---|---|---|
| committer | Rémy Coutable <remy@rymai.me> | 2016-10-07 16:17:28 +0200 |
| commit | 52ca9bf600235459721fbcf16e4f582b839b3b37 (patch) | |
| tree | b8e503a4ba27007e387eddb0fbecea5b76483d46 | |
| parent | 2f7e28d1f700e1cdafb7771d4a61d8f71b68df04 (diff) | |
| download | gitlab-ce-improve-contributing.tar.gz | |
Fix typo and add he MWBS accronym for "Merge When Build Succeeds"improve-contributing
Signed-off-by: Rémy Coutable <remy@rymai.me>
| -rw-r--r-- | doc/development/code_review.md | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/doc/development/code_review.md b/doc/development/code_review.md index 98279948888..c5c23b5c0b8 100644 --- a/doc/development/code_review.md +++ b/doc/development/code_review.md @@ -35,7 +35,7 @@ request is up to one of our merge request "endbosses", denoted on the ## Having your code reviewed Please keep in mind that code review is a process that can take multiple -iterations, and reviewer may spot things later that they may not have seen the +iterations, and reviewers may spot things later that they may not have seen the first time. - The first reviewer of your code is _you_. Before you perform that first push @@ -69,9 +69,9 @@ experience, refactors the existing code). Then: someone else would be confused by it as well. - After a round of line notes, it can be helpful to post a summary note such as "LGTM :thumbsup:", or "Just a couple things to address." -- Avoid accepting a merge request before the build succeeds ("Merge when build - succeeds" is fine). -- If you set the MR to "Merge when build succeeds", you should take over +- Avoid accepting a merge request before the build succeeds. Of course, "Merge + When Build Succeeds" (MWBS) is fine. +- If you set the MR to "Merge When Build Succeeds", you should take over subsequent revisions for anything that would be spotted after that. ## Credits |