Policy: detect and unassign blocked reviewers on community merge requests
Problem
The contributor platform can request reviews from GitLab team members whose accounts are later blocked because they have left the company. The review request never reaches anyone, and the merge request can sit idle for weeks before someone notices. In a recent case a community merge request sat idle for five weeks after three suggested reviewers, all since blocked, were requested and never replaced until a team member stepped in.
Context:
- gitlab-com/www-gitlab-com#35556 (root-cause issue, moved from the contributor platform)
- gitlab-org/developer-relations/contributor-success/contributors-gitlab-com!3040 (closed) (platform-side fix for the moment of suggestion)
The platform-side fix stops a blocked account from being suggested or requested in the first place. It does not help a merge request where the reviewer was active at assignment and blocked afterwards. That gap is what this policy would cover.
Proposal
Add a triage-ops policy that, for community contribution merge requests, detects any assigned reviewer whose GitLab account is blocked or no longer exists, leaves a comment noting the stale reviewer, and unassigns them so the merge request surfaces for re-assignment.
Suggested by @leetickett-gitlab in the review of contributors-gitlab-com!3040: "let's create an issue in triage-ops for a policy which checks if any assigned reviewers are blocked... it can comment and unassign them".
Open questions for the Quality team
- Reactive (on a reviewer change) versus scheduled (a sweep over open community merge requests). Scheduled looks more robust, since an account can be blocked after the reviewer is assigned.
- Scope: community-contribution merge requests only, or wider.
- How to read a reviewer's account state from within the triage-ops DSL. A blocked or removed account returns an empty array from
GET /users?username=, which a Ruby condition plugin could use.
Happy to open the merge request once the approach is agreed.