D pull request review process -- strawman formal definition, query for tools

[Lars T. Kyllingstad]

On Thursday, 9 May 2013 at 21:10:55 UTC, Steven Schveighoffer 
wrote:
> [...]
>
> I want to define a process for a requester to follow in order 
> to submit a pull request [...]

I agree with most of what you say, except maybe this:

> 2) pull request review process stages
>    a) submitted - pull request awaiting initial verification of 
> pull request prerequisites.
>    b) unassigned - pull request passes prerequisites, and is 
> awaiting assignment to an approved reviewer (process for 
> assignment TBD)
>    c) ready for review - pull request is assigned, but reviewer 
> has not started looking at it.
>    d) official review - pull request in review by reviewer.  
> Next stage can be e - h.
>    e) needs work - pull request needs work to be able to be 
> accepted (only use this stage if original requester is not 
> immediately responsive).  Go back to c after fixed.
>    f) rejected - pull request is rejected.  Can be re-opened by 
> another official contributor.
>    g) approved - pull request is approved for pull.
>    h) conditionally approved - pull request is approved, but 
> with minor changes (e.g. comment or ddoc changes).
>    i) pulled/closed - pull request is approved by second 
> reviewer (this does not need to be an in-depth review)

This seems to require yet another tool besides Bugzilla and 
GitHub, which I think we should avoid.  It's bad enough to have 
information in two places, without scattering it even more.  If 
we can somehow make it work within the current toolset, then I am 
all for it.