Re: [boost] is review system in place is extremely slow? (was Re: [rfc] rcpp)

Subject: Re: [boost] is review system in place is extremely slow? (was Re: [rfc] rcpp)
From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2010-02-28 23:52:27

Andrey Semashev wrote:
> On 02/28/2010 07:24 PM, Gennadiy Rozental wrote:
>> Not really. The transition occurs almost automatically and
>> asynchronously. There is no any queue. If one library has bigger support
>> and interest in a community, it will go through the phases much faster.
> 
> Well, the current queue isn't really a queue, as reviews can happen in 
> any order.

Are they? Who is making the decision who comes first? Aside of lack of 
review manager?

>>>> 4. Review process.
>>>> The candidate review can start at any time by the review manager (no
>>>> queue) and should take at least 2-4 month. There can be any number of
>>>> reviewed being run concurrently. The "candidate review" page should
>>>> include abstract, review package, and some kind of review submission
>>>> mechanism (maybe boolean yes/no + an actual review). The review should
>>>> be per person and each reviewer should have an ability to modify the
>>>> review.
>>>> Review discussion mechanism can be web based on rely on mailing list or
>>>> some mixture of these.
>>>
>>> I disagree, in several points.
>>>
>>> * 2-4 months is a very long period.
>>
>> Somehow you are fine with C++ standard changes being reviewed for years,
>> but find 2-4 month for non-trivial C++ library too long?
> 
> Who said that I'm fine with C++ standard evolution paces? :) Really, 
> some things were begging for standardization for years, and the final 
> paper is yet to appear.

Unexpected delays aside I find the current rate of C++ standard changes 
reasonable. We are dealing with non-trivial matters, which requires in 
most cases some time to think about and discuss.

> But we're talking of libraries here, not the standard. It's a much 
> lighter, fluid and flexible matter than any standard, and it should not 
> take that long time to accept.

Well, I do not expect years either. Take Boost.Log for example. I 
honestly expect that for the library to get accepted it should be 
reviewed for period of at least 6 month. Until people try it in actual 
projects, write some code with it, it will never be clear if the 
candidate is viable. No amount of theorization within 1-2 week is going 
to be acceptable IMO.

>>> 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.
> 
> 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 guess it matter of opinion. Sometimes deadlines are good motivational 
tool, sometimes they lead to suboptimal solutions. All participants here 
are volunteers. It's more reasonable to expect them to be able to donate 
several hours a week in a period of 4 month, then expect them to drop 
everything else and dedicate whole week to boost.

> I admit that long reviews give more opportunity to participate but then 
> again, people are not constrained by review period boundaries in order 
> to meet with the library. They can actually start reviewing it before 
> the official period and only express their opinion in written form 
> during the period.

Somehow this does not happened. It's quite possible that person have 
time today to review the candidate, but is not able to attend during the 
review period (even simply to write up the review). I propose to 
formalize and simplify the procedure for reviewers. The boost.org will 
have a list of ongoing reviews and anyone can go to the candidate page 
read the review progress summary and add something.

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

> Ever since I proposed Boost.Log for the review, I considered it ready. 
> There were discussions of it, I made improvements, but I don't think 
> that was the reason for the delay. There was no review manager until 
> recently I explicitly called for one. And the practice shows that even 
> that does not always help.

Look for my other post on the subject, but in general I believe library 
author should be more active in soliciting the review managers. If we 
can split review manager's job in two, the first part can be done by 
someone submitted by the author oneself. Even if we keep the status quo, 
the library author should engage other authoritative figures on a list 
and ask for the help with review. And again, ultimately review wizard 
has to approve the review manager.

>> 3. It should make more people willing to manage the review, given that
>> procedure does not require paying significant attention to the library
>> within the review period.
> 
> Is that so? The manager still has to check if the library meets formal 
> criteria for the review, read through all the reviews (not for a few 
> weeks, but for a few months) and take the final decision, doesn't he?

But the pressure to do this within short period of time is smaller. In 
both cases it's the same amount of work, but spread over the different 
amount of time.

Gennadiy