<snip>
I also seen that Wikimedia experimented something in that area, apparently there is a wiki page where people can mark them as available to be picked.
Hello,
I wrote that Wikimedia blog post! Let me side track a bit to give
a bit more information.
The context is Wikimedia has been struggling with code review for as long as we had more than a handful of people. Code review is always a hot topic and is causing pain all across the community with various degrees of experience. Some repositories are carefully watched by their maintainers, others have mostly inner team reviews and it might be hard to get a review if you are an outsider.
git blame
An idea we had was to automatically add code reviewer based on `git blame` (which I often relies on). That is how we have added the reviewers by blame plugin. Cause I was super ambitious I went with the default setting and it got enabled on every single repositories. The day after, people complained about being added to reviewers to a random set of patches that touched code that they once touched, most often unrelated to their review capabilities. The huge spam of emails caused us to roll back that deployment and forget about automatically adding reviewers based on blame. It just don't fit within our ecosystem.
I have updated the blog post to highlight we have disabled the
reviewer by blame plugin almost immediately.
homemade tooling
The primary system we use is Reviewer bot. People register their interest on a wiki page https://www.mediawiki.org/wiki/Git/Reviewers for example I can get added for any changes made to a `tox.ini` file on any repo or to any changes made to `ci/*` gerrit repositories. I can't remember the details of the implementation, I think all changes are send to a mailing list, the bot fetches the email, processes them, fetch the wiki page and apply the rules.
The equivalent as a Gerrit plugin would be the reviewers plugin:
We have it installed but I don't think it is used. Last time I checked there is no UI for it and people have to add themselves via a reviewers.config file under refs/meta/config. Needless to say you loose 99% of the audience at that point. Editing a wiki page is way simpler for us.
attention set
Google is well aware of the issue related to find reviewers, or
at least highlighting when a change should be acted on among the
list of changes one is a reviewer for. Gerrit 3.3 introduces a
featured named attention set which is a bit of a turn based, when
one does an action they can bring up to the attention of some of
the reviewers while others are not.
So if Jane asks me to rewrite a test, she will bring my
attention, I will amend my code send a patch and bring attention
back to her. After a while once we both agree the change is now
fine, we will bring it to the attention of the others. I really
like that turn based review among a subset of the reviewers, that
should cut a bit of spam or at least make the dashboard slightly
more helpful.
The feature is better described at https://gerrit-review.googlesource.com/Documentation/user-attention-set.html I have been exposed to it while contributing to Gerrit upstream and it is really an enjoyable system.
And all the above do not address the root causes:
* finding who can review code
* burden put on the shoulder of the few that can actually review, leading to a huge backlog which is most probably ignored as a result
It is a social problem really :-\
--
Antoine "hashar" Musso
Wikimedia Release Engineering