[core-workflow] self-approving pull requests

[Nick Coghlan]

On 18 February 2017 at 05:12, Senthil Kumaran <senthil at uthcode.com> wrote:
> On Fri, Feb 17, 2017 at 3:32 PM, Barry Warsaw <barry at python.org> wrote:
>> As you say, reviewer bandwidth is a bottleneck
>
> Would anyone consider  "Requiring a review from another
> core-developer" is actually a helpful thing?

No, because we don't have anything close to the reviewer bandwidth
needed to keep the previous "single review needed" process running
smoothly, let alone a "double review needed (even on backports)"
process.

> The positives I see are:
>
> 1) Forcing other developers with commit rights to act soon and review
> each other's code more often.

Are you offering to pay everyone for the time spent on these
additional reviews? Remember, disallowing self-review will come close
to doubling the aggregate review bandwidth required for the core
development process (especially with backports requiring a
PR-per-branch).

> 2) As a result of 1, the developers are incentivized to stay involved
> either in reviews, by reading code and subsequently will be fast in
> contributing code.

What incentive? I'm *less* inclined to contribute right now, and less
inclined to mentor people, since I can get very little done on my own,
and instead even the simplest of tasks can drag on for 24 or 48 hours
(There are relatively few other core developers in my time zone, so
folks in the US and Europe saying "I don't have any trouble finding
extra reviewers" doesn't carry a lot of weight with me on this point).

I'm +1 for turning on required status checks though - giving us a
strong incentive to get the test suite stable and keep it that way is
an unequivocally good thing, and I do want to keep the "PR required,
even for core developers" experiment going for at least another few
weeks.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia