diff options
Diffstat (limited to 'doc/development/code_review.md')
| -rw-r--r-- | doc/development/code_review.md | 8 |
1 files changed, 6 insertions, 2 deletions
diff --git a/doc/development/code_review.md b/doc/development/code_review.md index e9f00b640d9..6aedb18c15d 100644 --- a/doc/development/code_review.md +++ b/doc/development/code_review.md @@ -82,7 +82,7 @@ We make the following assumption with regards to automatically being considered - Team members working in a specific stage/group (for example, create: source code) are considered domain experts for that area of the app they work on. - Team members working on a specific feature (for example, search) are considered domain experts for that feature. -We default to assigning reviews to team members with domain expertise for code reviews. For UX reviews we default to the recommended designer from the Reviewer roulette. +We default to assigning reviews to team members with domain expertise for code reviews. UX reviews default to the recommended reviewer from the Review Roulette. Due to designer capacity limits, areas not supported by a Product Designer will no longer require a UX review unless it is a community contribution. When a suitable [domain expert](#domain-experts) isn't available, you can choose any team member to review the MR, or follow the [Reviewer roulette](#reviewer-roulette) recommendation (see above for UX reviews). To find a domain expert: @@ -106,7 +106,9 @@ Reviewer roulette is an internal tool for use on GitLab.com, and not available f The [Danger bot](dangerbot.md) randomly picks a reviewer and a maintainer for each area of the codebase that your merge request seems to touch. It makes **recommendations** for developer reviewers and you should override it if you think someone else is a better -fit. User-facing changes are also required to have a UX review, even if it's behind a feature flag. Default to the recommended UX reviewer suggested. +fit. + +We only do UX reviews for MRs from teams that include a Product Designer. User-facing changes from these teams are required to have a UX review, even if it's behind a feature flag. Default to the recommended UX reviewer suggested. It picks reviewers and maintainers from the list at the [engineering projects](https://about.gitlab.com/handbook/engineering/projects/) @@ -398,6 +400,8 @@ Maintainers are the DRI of assuring that the acceptance criteria of a merge requ In general, [quality is everyone's responsibility](https://about.gitlab.com/handbook/engineering/quality/), but maintainers of an MR are held responsible for **ensuring** that an MR meets those general quality standards. +This includes [avoiding the creation of technical debt in follow-up issues](contributing/issue_workflow.md#technical-debt-in-follow-up-issues). + If a maintainer feels that an MR is substantial enough, or requires a [domain expert](#domain-experts), maintainers have the discretion to request a review from another reviewer, or maintainer. Here are some examples of maintainers proactively doing this during review: |