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: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-02-28 18:45:26

----- Original Message ----- 
From: "Andrey Semashev" <andrey.semashev_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, February 28, 2010 11:14 PM
Subject: Re: [boost] is review system in place is extremely slow? (was Re: [rfc] rcpp)

> 
> On 02/28/2010 07:24 PM, Gennadiy Rozental wrote:
>>> Voting is good. I appreciated the feature on SourceForge. Although I
>>> don't think that the right to vote should be tied with posting a
>>> review later. I consider voting as afeedback mechanism, nothing more.
>>
>> I am not gonna push this point. IMO it's fair to expect people who
>> seconded the submission to provide a review within rather extended
>> review period. On the other hand we can't really put a "requirement"
>> clause to the support vote.
> 
> Yes, you can expect a voter to write a review, but forcing it is not 
> correct. There will be no votes then.
> 
> I think, a silver bullet would be sending an invitation e-mail to all 
> voters when the review begins.

I think that the review managers do this already to the people that presneted an interest on the library through the ML.
 
>>> It's not clear how it's transformed and in what way. Regarding the
>>> review scheduling, it's pretty much like it happens nowdays.
>>
>> 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.

Yes, but as the period is short, people tries to avoid holidays, other reviews, Quarter Boost releases, ...
With a 2-4 month period, these do not enter in consideration, as during this period you will have holidays, other reviews in parallel and boos releases.
 
>>> 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 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.

I think that this is also a test over the continuity of the Boost candidate. Maitinaing a Boost library is a long work. We don't expect to have an answer to a question some hours later, but that the future Boost author manage the discussions related to his library within a short interval of time (2 or 3 days).
 
>>> On the other hand, I agree that a few weeks may not be enough for some
>>> larger scaled libraries. Which leads me to conclusion that the review
>>> duration should be individual, decided by the author, review manager
>>> and review wizards, taking into account other reviews.
>>
>> Ultimately yes, but only if library qualify for fast track review.
>> Otherwise I do not see basis for review wizard to warrant it.
> 
> I think, the review wizard is already required to have some expertise in 
> the domain of the library under review. I believe, he and the author 
> will be able to work out a suitable amount of time for the review.

I think that you are talking of the review manager,not the review wizard.
 
>>> * 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.

I think that people are not interested on all the specific libraries. I'm sure that there will be people participating in the Lexer library that don't want to participate in the Shifted pointer library or viceversa, for example. 

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

This don't require more review managers, at least not more than now (1 by library)

> I don't think sharing a review 
> manager between several parallel reviews is a good idea.

I agree, but I don't think this would be a problem, we can expect that we don't need the same review manager to run two review in parallel.

>>> * Review mechanism should be convenient for both the reviewers and the
>>> author/review manager. It should allow an easy conversation between
>>> the reviewers and the author. Mailing list is good enough, I think.
>>
>> IMO review mechanism can be much better. Ideally coming to the one
>> should have a change to get a summary of current discussions, open
>> issues and author comments to them. Not sure if we can automate the
>> procedure or it should be a review manager job. Maybe we can combine
>> active discussion going on mailing list with summaries appearing on
>> candidate review page.
> 
> I'm fine with keeping some king of a summary of the ongoing review 
> somewhere public (perhaps, on the proposed candidate page). I just think 
> that the discussion should stay on the ML.

I agree.
 
>>>> 7. If there is no review manager found within a year, the library is
>>>> rejected due to lack of support.
>>>
>>> I think, there are several useful libraries in the queue that fit that
>>> criteria. My Boost.Log was surely longer than a year without a review
>>> manager, and I can't say there's no interest.
>>
>> I do not believe the Boost.Log waiting for review solely due to the lack
>> of the review manager. I managed last one. And I believe there were
>> couple candidates for the job for new take.
> 
> 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.

Andrey, I think that 1 year is a good compromise. This let the author the time to find a review manager, and make some preasure on s/he to look for activiely, requesting interested people to manage the review, ...

I would add even that if the library has not been integrated on a release before a year, since his acceptation, to reject the library.
 
>> 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?

Of course, but you can accept easier to review a library if you don't have to be present every day of a short period, but present from time to time during a longer period.

Maybe we can let the choice of the duration to the review manager.

Best,
Vicente