Approvers based on code history

Similar to https://gitlab.com/gitlab-org/gitlab-ee/issues/1012, in that GitLab will assign approvers for you.
In #1012 (closed), GitLab assigns approvers based on you manually maintaining a mapping of users to specific parts of code. In this issue, GitLab assigns or suggests approvers based on the code history itself.

Given the files that have changed in the latest update of the source branch of the merge request, look at the history of those files and see who have made commits. Based on some algorithm/specification, update the merge request approvers based on those people who have made commits in the past. For example, one idea is looking at the latest commit of a changed file in the target branch. The author of that commit becomes an approver in this case.
In #1012 (closed) GitLab does the assignment for you because code ownership is an explicit signal for the purpose of approvers. In this case, GitLab is being "smarter" by predicting who should be an approver. So for this case, GitLab should probably not automatically assign for you, but have a flow to suggest an updated approvers list and have the user confirm that list.
Not clear how that suggestion flow should work. One idea is that every time you push code, GitLab re-asks you to confirm if there are net new suggestions. (For example, a new file was changed.)
Many of the edge cases will be similar to https://gitlab.com/gitlab-org/gitlab-ee/issues/1012

You can already defined reviewers "Add an approver suggestion for each merge request" for merge request approvals http://doc.gitlab.com/ee/workflow/merge_request_approvals.html

It would be nice to be able to specify a file regexp filters. Any matching files would automatically get certain people assigned. See https://www.reviewboard.org/docs/manual/dev/admin/configuration/default-reviewers/

Edited Jan 23, 2018 by Victor Wu