Can some projects configure auto addition of reviewers to changes?

[Sorin Sbarnea]

As I observed that proposed changes can easily be ignored for months if the
original submitter did not manually added anyone or missed to do the
footwork of chasing cores on irc, I wonder if it would not be possible for
*some* projects to enable a feature to auto-add reviewers.

On the dark side of the world I seen the "codeowners
<https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners>"
features being quite successful in assigning reviewers, as a simple file
can define the pool of potential reviewers. Based on how the repository is
configured it does randomly pick a limited number of candidates. Github
mentions in their release notes from 2017 that their inspiration for that
feature was the OWNERS file used by chromium team (gerrit users).  I also
seen that Wikimedia experimented something
<https://phabricator.wikimedia.org/phame/live/1/post/139/gerrit_now_automatically_adds_reviewers/>
in that area, apparently there is a wiki page where people can mark them as
available to be picked.

The watched project feature in Gerrit is useless for this purpose as it
does not randomly pick some of a pool of possible candidates. It may be
practical to use if there are projects with only 2-3 core reviewers.

There are two aspects I am looking to address, at least partially:

A) Improve random external contributors first-contribution experience -
right now, even if they propose a perfectly valid change, there is high
chance it will not get noticed. As you can imagine this lowers the chance
they would try again, or to become an active contributor.

B) Spread the review burden on cores and avoid "punishing" those that are
more active from being assaulted by review requests.

The current secret source for getting reviews on a project where you do not
know anyone involves looking at recent changes to spot people that did
reviews or at least have core powers and try to contact those. Even if this
works or not, it puts extra pressure on active people. That is why I would
see an automatic round-robin approach more appropriate.

As some may no longer be involved with the project, this could prove to be
an opportunity to revise the core list, or to gently remove yourself from
the list of cores.

C) How to deter people from adding reviewers before CI jobs report green?

I have no idea how to educate people not to add reviewers to changes that
are not yet green. I know there are valid cases where this is needed, but
likely is more like on less than one 1:5.

As no hard limit would work, maybe there is a way to display some kind of
message in the UI, advising user not to assign reviewers until CI reports
green. The same issue applies even to automatic reviewer assignment, which
should not happen right after a review is created. Ideally this should
happen when it passed CI, but it could also be ok if it would happen when
a review is moved from WIP to ready-for-review. I personally use a default
where any change I create is marked as WIP and this default can also be
changed at server level if we want.

--
/zbr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/service-discuss/attachments/20210305/e3440b20/attachment.html>