diff options
Diffstat (limited to 'doc/development/code_review.md')
| -rw-r--r-- | doc/development/code_review.md | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/doc/development/code_review.md b/doc/development/code_review.md index dada6adcce7..9f18cbaff25 100644 --- a/doc/development/code_review.md +++ b/doc/development/code_review.md @@ -283,6 +283,8 @@ first time. you forget to remove any debugging code? - Consider providing instructions on how to test the merge request. This can be helpful for reviewers not familiar with the product feature or area of the codebase. +- If you know your change depends on another being merged first, note it in the + description and set an [merge request dependency](../user/project/merge_requests/merge_request_dependencies.md). - Be grateful for the reviewer's suggestions. (`Good call. I'll make that change.`) - Don't take it personally. The review is of the code, not of you. - Explain why the code exists. ("It's like that because of these reasons. Would @@ -345,6 +347,8 @@ experience, refactors the existing code). Then: - For non-mandatory suggestions, decorate with (non-blocking) so the author knows they can optionally resolve within the merge request or follow-up at a later stage. - There's a [Chrome/Firefox add-on](https://gitlab.com/conventionalcomments/conventional-comments-button) which you can use to apply [Conventional Comment](https://conventionalcomments.org/) prefixes. +- Ensure there are no open dependencies. Check [related issues](../user/project/issues/related_issues.md) for blockers. Clarify with the author(s) +if necessary. If blocked by one or more open MRs, set an [MR dependency](../user/project/merge_requests/merge_request_dependencies.md). - After a round of line notes, it can be helpful to post a summary note such as "Looks good to me", or "Just a couple things to address." - Assign the merge request to the author if changes are required following your |