|
Boost : |
Subject: Re: [boost] is review system in place is extremely slow? (wasRe: [rfc] rcpp)
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-03-01 12:13:00
Hi,
----- Original Message -----
From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, March 01, 2010 5:48 PM
Subject: Re: [boost] is review system in place is extremely slow? (wasRe: [rfc] rcpp)
>
> Gennadiy Rozental wrote:
>> Andrey Semashev wrote:
>> > On 02/28/2010 07:24 PM, Gennadiy Rozental wrote:
>>
>> >>> I disagree, in several points.
>> >>>
>> >>> * 2-4 months is a very long period.
>
> I agree that the usual review period is too short for non-trivial libraries. Many reviews are extended and many reviewers or would-be reviewers express problems with lack of time. I'm not sure four months (or six as suggested elsewhere) is warranted however.
I suggested up to six month for the support period during which the author receives enough interest on the library, not the review period.
> As Andrey noted elsewhere, reviewers can submit, or at least write, reviews before the review period. If a reviewer won't have list access during the review period, then submit the review early. Unfortunately, that's not done.
I think this is not done because the library to review is not fixed.
> Reviews are typically announced a month or more ahead of time now, so the review manager can call for reviews beginning immediately, making it clear that early submissions are welcome. Doing so effectively extends the review period back a month before the official start time. Gennadiy's longer review period idea would simply make that unofficial start (the announcement and call for early reviews) an official part of the review period.
Do you think we can demand the library is fixed as soon as the review date is fixed?
>> >>> You can't expect review manager and the library authors
>> >>> focused on the review that long.
>> >>
>> >> Actually the point was to decrease the pressure. Longer time period
>> >> means that both reviewers and author can take their time doing
>> >> their job. I expect short short period of times with high
>> >> activity with some
>> >> gaps in between, where sides consider the matter.
>
> I agree that a longer period means the review period will be more relaxed. The author must look for an respond to queries and concerns about the library over a longer period, but that's no different than what follows acceptance.
>
>> > It's much easier for the author and review manager to
>> > schedule their
>> > time for a few weeks to pay more attention to a short but
>> > active review,
>> > than try to do that for several months.
>
> I disagree. The heightened attention demanded by the current approach is almost impossible to support. Lengthening the review period means one can take a day or two, rather than hours, to respond to a post.
I agree. I think that the quality of exchanges will increase if people can take the time to respond to a post.
>> >>> * Concurrent reviews is wrong. We don't have enough reviewers and
>> >>> wizards to make sequential reviews. Allowing parallel
>> >>> reviews won't
>> >>> make it better. The review quality will also drop.
>> >>
>> >> Even in rare situation where the same person is interested
>> >> in several
>> >> concurrent reviews, long review period should give one a chance to
>> >> participate in both.
>> >
>> > It also requires more review managers. I don't think
>> > sharing a review
>> > manager between several parallel reviews is a good idea.
>>
>> I do not see why we need a strict rule here. If person is
>> willing and/or
>> if, for example, there is one month left in one review one can start
>> another one taking 4 month... Ultimately review wizard has to approve
>> the review manager.
>
> Concurrent reviews won't be a problem is the review periods are longer and if a subsequent review must follow the current review by, say, a month. IOW, if non-trivial reviews are two months, then they would only overlap by one month.
maybe we need to limit the number of parallel reviews, but two will be to restrictive.
Best,
Vicente
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk