On 05/16, Brett Cannon wrote:
>On Tue, 15 May 2018 at 13:03 Berker Peksağ <berker.peksag@gmail.com> wrote:
>
>> On Tue, May 15, 2018 at 6:12 PM, Stephane Wirtel <stephane@wirtel.be>
>> 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