Managing the review queue

Jonathan M Davis jmdavisProg at gmx.com
Sun Mar 27 22:41:08 PDT 2011


On 2011-03-27 20:53, dsimcha wrote:
>  From observing the review processes for std.parallelism and
> std.net.isemail, I think our review process needs some tweaking.  There
> are two key issues:
> 
> 1.  The pace of reviews is glacial unless there's a vote date near.
> Only 4 people have reviewed std.net.isemail, and that's counting any
> participation in the discussion as "review".  This module doesn't have a
> vote date yet.  IIRC only two people reviewed std.parallelism during its
> first two weeks of review.  Furthermore, it took some time after I
> requested review for the "official" review period to start.  As a
> solution all requests for review should come with a tentative vote date
> to prevent the module from being held in limbo indefinitely and move the
> review queue along.
> 
> 2.  Reviews that prompt major changes right before the vote date are
> stressful.  A looming deadline is not conducive to careful discussion
> and consideration of suggestions, especially those that are non-trivial
> to understand and/or implement.
> 
> I propose that all review periods last one week for small modules or two
> weeks for large modules, subject to extension if the review process is
> still yielding good discussion near the vote date or "stashing" if the
> author needs time to discuss specific issues that were raised and/or
> design and implement changes.  When a module is stashed, it is no longer
> officially in review and the next item in the review queue, if any, can
> begin the process.  As soon as this item is done, review of the stashed
> item is resumed.  Right now, std.parallelism is stashed until
> std.net.isemail is finished.
> 
> To prevent the community from being overwhelmed, multiple reviews may
> not take place concurrently but a review may take place concurrently
> with a vote.  Contention for the review queue is an issue in theory, but
> that's a problem we'd like to have and can work out on an ad-hoc basis
> should it arise.
> 
> More specifically, the pace of reviews for std.net.isemail has been
> glacial.  If everyone who intends to review it has done so, we should
> move on to a vote.  If anyone intends to review this module but hasn't
> yet, please do so or at least state your intention to do so.

Overall, your suggestions are good. Personally, my problem with reviews is 
that I have enough going on and they take enough time and concentration to do 
that I end up setting them aside to do later and then have trouble getting 
around to them. I've been intending to look at both std.parallelism and 
std.net.isemail (Am I the only one who thinks Ishmael when I see that? LOL), 
but I've been busy. Shorter review periods are both good and bad, because they 
force you to take the time to review them rather than putting it off, thereby 
actually encouraging reviews, but if they're too short, some folks will miss 
them entirely or not have the time to come up with solid feedback.

Overall, I think that what you're suggesting is solid.

- Jonathan M Davis


More information about the Digitalmars-d mailing list