[Gitlab-Org] Improve Review Requirement Efficiency
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.
Lots of approvals for a simple change!
Let's see what we can do to increase our awareness of this problem and improve our efficiency
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, devopsverify, 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 gitlab-org/quality/quality-engineering&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:
- Request 1 or more other reviews
- Determine that the MR is not "trivial" and kick off the "Normal MR approval process"
- 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