A few comments on Phabricator and Lando: Phabricator has two types of review requests: "reviewer" and "blocking reviewer". These are only really differentiated if there is more than one reviewer on a revision. In that case, if there is a blocking reviewer, the revision is only marked "accepted" when the blocking reviewer(s) have accepted it. If there are only nonblocking reviewers, the revision is marked accepted when any one accepts it, as long as no others have requested changes.
How we might use blocking reviewers in our workflow is still open, but it could be used for training up reviewers, in which case the trainee would be a regular reviewer and the module peer/owner would be a blocking reviewer. We have some plans to add enforced reviewers to Lando, meaning a patch can only be landed if it has a review from an appropriate module peer or owner. This is still hazy right now because it requires some changes to the module system, most notably making it machine readable. There's a somewhat related thread in governance on this. Mark On Friday, 20 April 2018 17:23:44 UTC-4, Kris Maglione wrote: > I can't remember the last time I saw a super-review request, but > it's still documented as a policy[1]. Is it still a thing? Do we > want it to still be a thing? > > The reason that I ask is that I have a problem that I think I > might be able to solve by co-opting the super-review flag, but I > don't want to trample on it if we're still using it as > originally designed. > > My problem is essentially that, for a few areas of code, I'm the > final arbiter, or at least the main blocker, for a lot of large > or critical architectural or API changes. The upshot of that is > that I get a lot of review requests for patches in those areas, > and most of the patches that make it into my queue are large > and/or complicated. This situation gets exhausting after a > while. And since people know that I tend to be busy, they also > avoid flagging me to review smaller patches, even when I really > *should* look at those patches (and therefore notice issues with > them only when I read code later). > > For a lot of these patches, my opinion is only really critical > for certain architectural aspects, or implementation aspects at > a few critical points. There are other reviewers who are > perfectly qualified to do a more detailed review of the > specifics of the patch, and have more spare cycles to devote to > it. Essentially, what's needed from me in these cases is a > super-review, which I can do fairly easily, but instead I become > a bottleneck for the code review as well. > > So, for the areas where I have this responsibility, I'd like to > institute a policy that certain types of changes need a final > super-review from me, but should get a detailed code review from > another qualified reviewer when that makes sense. > > > Does anyone have any objection to this plan? Or any suggestions > for another way to go about it? > > -Kris > > [1]: https://www.mozilla.org/en-US/about/governance/policies/reviewers/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
