Reduce UX clutter in MR approval section for monorepositories

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Problem statement

Our engineers work in a monorepository, meaning that all of our code lives in one repository. Recently, we adopted CODEOWNERS to ensure that changes in particular folders are reviewed by the relevant teams that own these folders. One important characteristic of the monorepository is that the code structure does not (necessarily) mirror the organisation structure. As such, multiple teams can own the same folders, for example when they share a particular implementation of an algorithm both teams rely on in their product.

As a result of this structure, we currently list all teams that own a particular folder:

[Module name]
/module-one/ @team1 @team2

[Another Module name]
/module-two/ @team2 @team3

[Common Module]
/common-module/ @team1 @team2 @team3

In the above example, team2 owns all three folders, whereas team1 and team3 only own two.

Now, when an engineer makes a change in all three folders, GitLab UI will show the following:

In other words: for each folder changed in the MR, GitLab will include 1 line of OWNERS. However, this doesn't necessarily match the full intent of CODEOWNERS. For example, given the following scenario:

[Resources B]
/resources/teamb/ @teamb

[UI B]
/front_end/ui/teamb/ @teamb

[Database B]
/backend/database/teamb/ @teamb

In this case, all three folders are owned by the same team. Often, changes in one folder are accompanied by changes in another folder owned by the same team. In this case, you only need approval of 1 team (team B in this case). However, GitLab will once again show three folders:

In addition, GitLab will claim that it requires 3 approvals, namely 1 approval for each folder. In practice, however, only 1 approval is required from team B.

The examples are contrived, but in our monorepository the GitLab UI can easily grow to dozens of rows (for larger changes) and having 3-5 approvals required are common. In practice, we typically need only 1-2 reviewers, rather than 3-5.

Attempted solution

When we identified the UX clutter, we made some attempts at addressing it. One of our attempts was to add a section per team, rather than per folder:

[Team A]
/backend/service/teama/ @teama
/backend/internal/common/teama/ @teama
/resources/teama/ @teama
/shared/ @teama

[Team B]
/backend/database/teamb/ @teamb
/front_end/ui/teamb/ @teamb
/resources/teamb/ @teamb
/shared/ @teamb

Ideally, GitLab UI would group the necessary approvals per team. However, when we put this in practice, we observed a sum product of all teams and folders: for each folder, for each team, 1 row would be added. In other words, we added more lines than we had before, regressing in UX. We did not adopt this solution.

Ideal solution

We would like the GitLab UI to group CODEOWNERS based on teams, to support monorepositories with code structures that don't necessarily resemble the organisation structure. The UI would then list, for each team, all folders that they can approve. This would mean that if you make changes in folders that team B owns, it would have 1 row for team B, rather than 3 (in the above example).