Use github 'assign PR' functionality instead of 'request reviews'

[iamdanfox]

What happened?

We've been using the new request_review functionality pretty heavily both internally and externally, and it's been very effective in more equally load balancing PRs to members of the team.

I've been recommending team members to use the https://github.com/pulls/review-requested dashboard as an 'inbox' (as people struggle with github notifications). Unfortunately, this dashboard is a bit misleading because PRs disappear from the 'review requested' section after the reviewer just leaves a comment. This can lead to PRs being left unmerged in an ambiguous state about who is responsible for the next action.

What did you want to happen?

I think switching to assigning PRs to people would ensure that these PRs don't disappear from the dashboard, and make the dashboard a lot more useful.

cc @callumr @ferozco @dansanduleac

[asvoboda]

How do you feel about making this an option in the configuration so that users can select if they prefer assignee/review?

Something like adding use_assignee: true in the config?

[iamdanfox]

Instinctively, I would have said let's just switch it over entirely to minimise complexity & maintenance burden in this codebase. However it seems like some gotham folks have started using this functionality too, so we might need to check with them whether they have any reservations.

In general though, I think i'd steer away from boolean config because it can be quite limiting if we need to add another option in the future - if we have to do config, I'd use something like notification_method: (request_review|assign_pr)... this might let us add a third option like comment_mention if we needed to.

[asvoboda]

Sure, a new config option makes sense. I'd prefer an additive change rather than removing the request review ability, since a team cannot be assigned to a PR (but you can request a review from a team).