<div dir="ltr"><a href="https://github.com/python/bedevere/pull/33">https://github.com/python/bedevere/pull/33</a> 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 <a href="http://webgraphviz.com">webgraphviz.com</a> if you want to look at the stages and how they transition.<div><br></div><div>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).<br><br><div class="gmail_quote"><div dir="ltr">On Sat, 17 Jun 2017 at 12:07 Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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 <a href="https://github.com/python/core-workflow/issues/94" target="_blank">https://github.com/python/core-workflow/issues/94</a> for this idea, but I figured what the exact stages should be deserves a wider discussion.<div><br></div><div>The stages I see are:</div><div><ol><li><b>Awaiting first review</b>: no one has reviewed the PR<br></li><li><b>Awaiting core review</b>: 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)<br></li><li><b>Awaiting changes</b>: 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)<br></li><li><b>Awaiting N<i style="color:rgb(34,34,34);font-size:14px"><sup style="line-height:1;font-size:11.2px">th</sup></i> review/re-review</b>: 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)<br></li><li><b>Awaiting merge</b>: 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?)<br></li></ol><div>Am I missing a step?</div></div></div></blockquote></div></div></div>