On Wed, 23 May 2018 at 06:59 Stephane Wirtel
On 05/16, Brett Cannon wrote:
On Tue, 15 May 2018 at 13:03 Berker Peksağ
wrote: On Tue, May 15, 2018 at 6:12 PM, Stephane Wirtel
wrote: For me, normally, the label should be on "awaiting changes" and after a new commit/message from the author, the label should be "awaiting review"
The reviewer wasn't a core developer so we need to get a approval/review from a core developer before moving to the next step (for example, a core developer may disagree with the non-core reviewer's comments or suggest a different approach)
And the reason we want a core review is we have no idea if the review by a non-core reviewer is reasonable. E.g. someone might be extremely pedantic about PEP 8 when a core dev wouldn't be in all situations, so holding up a PR for that wouldn't be fair for the PR submitter. +1 I do understand and make sense
Is there an intermediate status, like 'non-core reviewer' where the reviewer could requests changes on a PR and keep the status 'await changes' or 'await review'?
By the way, maybe we could increase the number of reviewers and improve the quality of the reviews. The core dev would be more "confident" with the reviews from a 'reviewer'.
For the rewiews of code, the workflow could be this one "Contributor" -> "Reviewer" -> "Core-Dev" ?
It would require creating a list somewhere of GitHub usernames that Bedevere can read from to determine who the "reviewers" are whose reviews we trust. Then again, if someone gets that far we might want to just give them commit rights at that point. -Brett
-- Stéphane Wirtel - http://wirtel.be - @matrixise