Managing the review queue

Walter Bright newshound2 at digitalmars.com
Mon Mar 28 12:01:22 PDT 2011


On 3/27/2011 8:53 PM, 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.

I know that reviews can be frustratingly slow. It's mainly because we have a 
smallish community.


> 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.

Different people have interests in different things. I don't think a person 
interested in std.parallelism would necessarily have any interest in 
std.net.isemail, and vice versa, so those can be done in parallel (!).

A further issue with the review process is that the bulk of people won't look at 
something until it is actually released. I think the only way to deal with this 
is to be willing to correct deficiencies found after release.


More information about the Digitalmars-d mailing list