Consider to have maintainers with domain expertise
Following my comment in #4386 (comment 174735804):
I think that we could switch to a model where maintainers are domain experts in a given area. We should teach new maintainers towards that. I know that we moved from that model, but currently I don't see where we have a place for domain experts in our workflow. Very often now the developer is working with the external maintainer.
Let's take a look at an example of Linux Kernel. Each source has a list of maintainers that the file needs to pass through before it can be merged (https://github.com/torvalds/linux/blob/master/MAINTAINERS). This is very good, as a person designated that is on that list keeps track of all ongoing changes and understands all decisions made and all potential quirks. Maybe our model should be very similar now with the growing amount of maintainers: we have domain experts that are maintainers responsible for a given area. The given area is deduced automatically based on the changed code. We might need the approval of multiple maintainers if it touches multiple areas. Maintainer stays to be the gatekeeper of code-consistency, but we bring him back the requirement of domain expertise. To consider:
- In that model, we could overprovision a number of maintainers for the given space,
- Technically, being maintainer (having domain expertise) should be way simpler to achieve than being maintainer code-wise,
- It is much easier to introduce interim maintainers as people could be from within the team that work on the given space,
- Domain expertise becomes required, as complexity of codebase is very big, and trying to know all choices that were made in the past is near to impossible, having maintainers to be focues increases GitLab Quality and reduces amount of bugs and regressions,
- We still need a ton of maintainers, but focusing them makes it easier to teach them, and make them more confident in what they do and what they merge,
- Having maintainer from within the team and having been worked on a given domain for a long time is less likely to introduce significant regressions,
- We could have two tiers of maintainers (being more aggressive in delegating them):
codebase maintainers
(people able to review and merge code everywhere) anddomain maintainers
(people best familiar with given domain), having this two-levels allows us to much easier assign todomain maintainers
and promote people over time without the pressure when there's suitable time
Why? This is an example from this morning: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/27503. This fix causes usability regression that is more severe than the fix itself and does not really solve the original problem. This is one example, but we had a few of such cases already in last months.