Multiple reviewer roles don't work well with "must review" list in Differential?

We require reviews from projects “Peer review” and “Security review” to accept a diff.

These are different kinds of reviews and we don’t think it’s really possible to do a good job of both at once, so in general these two approvals should be from different people even though all people in the “Security review” project are also in the “Peer review” project.

However, when viewing the “active revisions” view bucketed by “required action” or the home page of Differential, diffs that a reviewer has approved on behalf of one project will still show up as “Must review”. This is kind of annoying as it’s hard to tell the reason why something is showing up and it can be easy to miss cases where review is actually required.

Does anyone have a suggestion for how to improve this experience?

My ideal solution would be to allow reviewers to exclude themselves from a project for a single review (i.e. “I’m resigning from this review as a peer reviewer, but I want to be informed if changes are made that require a security re-review though”). This would also help with the scenario where things are not getting peer reviewed and it’s because a bunch of people have decided that they didn’t know enough about the code involved, but there was no way they could say through the interface “yes I’m a peer reviewer, but I don’t think I should peer review this”. But this would be a feature request and I’d like some ideas for what I can do now.

Does anyone have a suggestion for how to improve this experience?

Perhaps copy or modify DifferentialRevisionRequiredActionResultBucket.php to split the “Must Review” bucket into “Needs Security Review” and “Needs Peer Review” or similar.

Upstream, https://secure.phabricator.com/T731 discusses some planned changes to acceptance conditions, but we have no outstanding requests for multiple different types of accepts from reviewer sub-roles and this use case seems a bit specialized so I’d be surprised if anything changes in the upstream to provide much/any support for it in the foreseeable future.

…we don’t think it’s really possible to do a good job of both [types of review] at once, so in general these two approvals should be from different people…

This, particularly, is a specialized requirement given feedback we’ve received from other installs/organizations.

In most environments I’ve interacted with or seen feedback from, a reviewer who is qualified to review aspect A (say, performance implications) and aspect B (say, security implications) of a change individually can also competently review both A + B together, so whatever is driving this requirement in your environment is fairly uncommon.