Boost logo

Boost :

Subject: Re: [boost] Improving review process
From: John Phillips (phillips_at_[hidden])
Date: 2011-01-13 22:03:16


On 1/13/2011 8:25 AM, Vladimir Prus wrote:
>
> Recently, there were various comments about current review process, and its
> possible improvements. However, I wanted to start with a small point.
>
> <snip> ...
>
> Can we set a policy that:
>
> - A library can only be added in the review schedule if the author has time in
> near future to have a review, where near future is, say, 3 months.
> - A review manager is only assigned if a review date is set at the same time,
> where the date should be in near future -- say, 3 months again.
>
> I think such a policy might not improve our overall review speed too much,
> but surely will make the situation a bit clear, and allow to understand the
> real problems with the review system.
>
> Thanks,
>

   I like the idea of having a clearly defined schedule table that
really is the reviews that are on the schedule, and not other things.
There are some other things the Wizards need to maintain, but keeping
the separate appeals to me.

   As for assigning a review manager, the sequence usually runs the
opposite way. A Manager attaches to a library, and then the manager and
author come up with a few possible dates and make a request to the
Wizards. We don't have a pool of potential managers sitting around from
which we make assignments. The managers volunteer with specific
libraries in mind, and we work with the combination of author and
manager to get things moving from there.

   Also - Thank you to Volodya for starting this thread, and to the
other participants for your opinions. Hopefully we, as a community can
build enough of a consensus about how to improve the review process that
we have a good basis for taking action and improving things for
everyone. This topic comes up in various forms every few months, but
building a real plan of action from the discussions is not usually easy.
Ron and I make the day to day Wizard decisions without consulting the
community, but we do not feel it is our role to make major changes to
Boost policies without some fairly strong support from the active
participants.

                        John


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk