> Hi, > > Back in the Bugzilla days, only reviewers were allowed to r+ or r- patches. > Non-reviewers were - of course - encouraged to do informal reviews but they > would do so by leaving comments. They would never r+ / r-. > > Since we?ve moved to Github, it seems we have become a lot more lax about > this and I have seen non-reviewers approve and reject PRs, not just leaving > comments. > My understanding is that there is no way to prevent this with Github but > could we at least make it a policy that non-reviewers should not approve / > reject PRs and only leave comments instead?
To provide some context, one of the reasons I didn’t attempt to exactly replicate Bugzilla’s behavior when porting our review mechanisms to GitHub was that Bugzilla only allows a single reviewer, which meant that an r+ would naturally clobber an r-, regardless of who gave the r- initially. Even in Bugzilla, non-reviewers could give r+es or r-es, it’s just that Commit-Queue wouldn’t respect them. > The reason I would like us to make enforce this rule is that I find it > confusing. We have a lot of new comers in the project and I do not always > know if a person is a reviewer or not yet. I imagine it may be even more > confusing for non-Apple people. I agree with this, especially since folks GitHub usernames are not always obvious. > I have in some cases not reviewed patches because I had seen the "green > check? and thought the PR already had been approved. > I have also seen cases of PRs rejected, asking the author to do more work, > that I didn?t feel was necessary. > There is no easy way from the GitHub UI to tell if the person who > approved/rejected your PR is actually a reviewer, as far as I know. I think it’s fair for a non-reviewer to “Request Changes” on a PR, it’s often the case that a non-reviewer has comments that should block a change from landing. If a reviewer (or even the PR author) thinks that the blocking comment has been addressed, they can “re-request review” which will get-rid of symbol until the account whose review is requested re-reviews the PR. I think this also points to the right way to address the confusion for r+es (which I think are the bigger issue): if we formally make our policy that non-reviewers should not leave a persistent “Approved” checkmark on a PR, we could have EWS listen for PR approvals and simply request a re-review any time a non-reviewer approves a PR. In practice, this will mean that a non-reviewer which approves a PR will have their approval nearly instantly removed by a bot. We could even have the bot comment something like “Unofficial r+ from non-reviewer <github user>” to make exactly what’s going on clear. The issue with a policy change like this one is that it’s WebKit reviewers who deeply understand the policies of the WebKit project, but it’s non-reviewers who need to change their behavior. If we don’t back this policy clarification with a tools change, I think non-reviewers are unlikely to be aware project policy has changed. > > What do you think? > > Thanks, > Chris Dumez.
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
