From brett at python.org  Sat Jul 22 15:49:11 2017
From: brett at python.org (Brett Cannon)
Date: Sat, 22 Jul 2017 19:49:11 +0000
Subject: [core-workflow] Auto labeling PRs based on what stage they're in
In-Reply-To: <CAP1=2W6AqaiV26xs0sdD4Dr_2tLKA5MxYMtC=xR501H8Na2h-Q@mail.gmail.com>
References: <CAP1=2W6AqaiV26xs0sdD4Dr_2tLKA5MxYMtC=xR501H8Na2h-Q@mail.gmail.com>
Message-ID: <CAP1=2W4eLzKb3sbg_SHJ=WAMvLv-xNpx=p7CxQXs7_UUwu+1=A@mail.gmail.com>

https://github.com/python/bedevere/pull/33 contains the PR I'm planning to
merge at some point to handle the automatic labeling of  PRs based on their
current stage. The diagram is in the waiting.py file as a string literal so
you can use webgraphviz.com if you want to look at the stages and how they
transition.

Unless someone points out a major flaw or speaks up that they think the
labels or this idea is really bad, I will probably merge it sometime next
week (after I get my test coverage back up).

On Sat, 17 Jun 2017 at 12:07 Brett Cannon <brett at python.org> wrote:

> I don't know about the rest of you, but I want an easy way to glance at a
> pull request and know what it's currently blocking it from being merged (if
> I'm wrong then let me know). I opened
> https://github.com/python/core-workflow/issues/94 for this idea, but I
> figured what the exact stages should be deserves a wider discussion.
>
> The stages I see are:
>
>    1. *Awaiting first review*: no one has reviewed the PR
>    2. *Awaiting core review*: a non-core dev has reviewed the PR, but
>    there still needs to be that initial core review (still not sure if this is
>    worth the distinction or how complex it will make the code, but it may
>    encourage people to help in the reviewing process instead of automatically
>    diving into coding if their review leads to a visible stage change)
>    3. *Awaiting changes*: a review has been done, but changes were
>    requested (probably wouldn't reach this stage for non-core reviews; a bit
>    tough to block on a non-core review as their asks may not be reasonable and
>    so shouldn't automatically signal that what someone that they must do what
>    is requested of them in that instance)
>    4. *Awaiting Nth review/re-review*: the PR submitter believes all the
>    requests have been addressed in all reviews and so is waiting on the
>    reviewer(s) who requested changes to review again (will need to provide a
>    way to leave a message that signals to Bedevere that the submitter feels
>    ready for another review)
>    5. *Awaiting merge*: all reviews approve of the PR (we could also drop
>    the "awaiting core review" stage and go straight here even for non-core
>    reviews that are all approvals, but maybe that's leaning on non-core devs
>    too much and giving false hope to PR submitters?)
>
> Am I missing a step?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170722/e66587c0/attachment.html>