## Description Sometimes/often an MR author may seek out more reviews than what's actually required/needed. This is highly inefficient, meaning that something about our processes is going against one of our core values. <details> <summary> Lots of approvals for a simple change! </summary>  </details> Let's see what we can do to increase our awareness of this problem and improve our efficiency :smile: ## Observations ### 1. There's a matrix of review decisions - Do we need initial review or can this MR go straight to maintainer? - What **domains** (for example ~backend, ~frontend, ~"devops::verify", ~database) are needed? Our communication (across handbook and Dangerbot) should be clear and simple, such that it informs: - MR authors to make the most **optimal** decisions. - MR maintainers to be confident the process requirements are met. ## Proposals Let's use this issue to discuss and brainstorm. As the discussion gravitates towards a solution, we'll create a spin-off issue for that. ### Brainstorm 1 - Change Dangerbot's communication Is there something about Dangerbot that makes it seem like more approvals are required than necessary? See also https://gitlab.com/groups/gitlab-org/quality/quality-engineering/-/epics/44 ### Brainstorm 2 - Introduce an official "trivial MR" process Let's separate non-trivial MR's from trivial ones. If an author feels that an MR is trivial they can follow a "Trivial MR approval process" that goes straight to a single maintainer. The single maintainer could either: 1. Request 1 or more other reviews 2. Determine that the MR is **not** "trivial" and kick off the "Normal MR approval process" 3. Determine that the MR is trivial and acceptable, then simply approve and merge ## Evidences I've seen us practice this inefficiency a lot. I'll start collecting examples here, but feel free to contribute your own :smile: - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/160471+