[…] automatically add reviewers to your changes based
on who previously has committed changes to the file.
I'm already overwhelmed with review requests. I'm also one of the
latest contributors in sooo many files that I'm worried the plugin
will add me to dozens per day from now on. This surprising addition
makes me worry very much about my sanity and the usability of my inbox
and Gerrit dashboards. Please, please, tune it down heavily.
Until now, I had a process to find reviewers:
1. For planned changes, it's already obvious who needs to do the
review: my team members. Often they don't even need to be added as
reviewers, or don't want to, but use the "review" column on our
Phabricator board. Automatically adding random *other* people is not
only useless in this situation, it's counterproductive and frustrating
for everybody involved. Other people should not waste their time with
patches like this. When they do, it's frustrating for the one who was
supposed to do the review, as well as for the "auto-reviewer". His
review is not helpful and ultimately not appreciated.
2. For code cleanups in core and codebases my team does not own I open
the list of merged patches on Gerrit to see if I can tell the names of
one or two main contributors. Often, the list will contain nothing but
the Translatewiki bot and a few people doing cross-codebase
maintainance work. These highly active people should *not* be the
first pick as potential reviewers for multiple reasons. Most
importantly, just because someone is very productive it's not ok to
expect him to accept even more workload. This is
super-counterproductive and ultimately leads to people burning out.
Secondly, just because someone updated, let's say, a call to a
deprecated core function does not mean he is familiar with a codebase.
3. I look at the files my patch happens to touch in my PHPStorm IDE,
enable the blame column that shows who touched a line last, and see if
I can find the one who introduced the code I'm touching.
All steps in this process involve *reading* the commit messages and
considering what people did, when and why. This can't be automated.
I do not entirely oppose the idea of adding reviewers automatically,
as long as I (as a reviewer) have a chance to easily tell the
difference between being added manually vs. automatically. For my
sanity, I will most probably setup an email filter that auto-deletes
all automated requests, and only look at these auto-reviews once a
week via my Gerrit dashboard.
Based on all these arguments this is what I, personally, find acceptable:
* Make sure no emails are sent for being automatically added, or make
sure it's possible to turn them off (without also killing the wanted
emails about manually being added).
* Make sure tool accounts like the library-upgrader or Translatewiki
bot are never added as reviewers.
* Never automatically add reviewers if there are other reviewers
already. Most importantly, if people have been added via the reviewer
bot already, that's more than enough.
* Only add 2 reviewers. 2 people will more likely feel like a team. 3
people are much more likely to all think "the other 2 will do it" and
all ignore it.
* Don't just pick the "most recent" contributor. That's most certainly
not the person you want (probably one who fixed a typo, or updated a
library). Implement an algorithm that can either understand who
touched which places in the code, and assigns them to patches that
happen to touch the same place again. Or go for an algorithm that (for
example) analyzes the last year and picks the 2 people who did the
most changes to a file in that time span.
If more than one of these criteria is not met or not possible, the
only solution I see is to make the plugin opt-in per codebase, not
opt-out as of now (because you can't expect me to opt-out from
literally a thousand codebases).
Thank you for keeping my inbox sane.
Best
Thiemo