### Problem to solve [Microsoft found](https://www.microsoft.com/en-us/research/publication/characteristics-of-useful-code-reviews-an-empirical-study-at-microsoft/) that reviewers with experience reviewing or editing the file provided more useful feedback. > Code review usefulness is negatively correlated with the size of a code review. That is, the more files there are in a single review, the lower the overall rate of useful feedback. The decrease however only starts to be noticeable for reviews with 20 or more changed files. Low quality feedback reduces the value of performing a code review. ### Intended users * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> From https://gitlab.com/gitlab-org/gitlab-design/issues/441. How can we encourage the best practice of small changes that are easier to review and merge? One possibility is showing that big merge requests take X amount of time on average to review. > Large, complex changes are among the most popular reasons for confusion […]. As a strategy to deal with this issue, developers suggest to split big changes into smaller, clearer ones. This is consistent with the earlier findings, envisioning the emergence of tools enabling early detection of splittable changes, i.e., before the pull request is submitted, in order to both avoid spending additional time in identifying such patches and asking the author re-work the change to reduce its complexity and likelihood of the discussion. — [Confusion in Code Reviews: Reasons, Impacts, and Coping Strategies](https://www.win.tue.nl/~aserebre/SANER2019Felipe.pdf) > Another point raised during the interviews is that large patch sets are difficult to review and require a lot of time to read [P1−4, FG1−3], thus this may delay the acceptance of the patches. […] Interestingly, all the interviewees agreed that tools could help reviewers and authors in solving this need: for example, when submitting a large patch, the tool could suggest the author to split it into more parts to ease the reviewing process. — [Information Needs in Contemporary Code Review](https://dibt.unimol.it/staff/fpalomba/documents/C41.pdf) > Observation 4 shows that as we conjecture, churn shares an increasing relationship with the likelihood that a patch will be discussed. Recent studies also report that the patch size is a good indicator of patch acceptance (Weißgerberet al., 2008; Jianget al.,2013). Intuitively, the large patches are likely to be discussed since they can contain more problems than the small patches. On the other hand, smaller patches have less code to critique, and thus are less likely to receive comments from reviewers. This observation is also consistent with the findings of Baysalet al.(2015) who find that large patches tend to have more revisions than small patches […]. — [Review Participation in Modern Code Review](https://sail.cs.queensu.ca/Downloads/EMSE2016_ReviewParticipationInModernCodeReviewAnEmpiricalStudyOfTheAndroidQtAndOpenStackProjects.pdf) ### Proposal Show a warning when a merge request changes more than 20 files. This should: 1. warn the author and encourage them to split the change into smaller merge requests 2. warn any reviewer that their review is less likely to catch all errors The warning should create social pressure against large changes which reduce velocity and quality. ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?--> ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. --> ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further help: https://about.gitlab.com/handbook/engineering/quality/test-engineering/ --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### What is the type of buyer? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ### Links / references