Re: [boost] Improving review process

Subject: Re: [boost] Improving review process
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2011-01-13 13:29:52

vicente.botet wrote:

> I don't know if these dependent libraries should be removed. Maybe it is worth to state cleary in
> the page why the review is not yet scheduled.

I think you're right.

>> - The library author does not have the time for review. In that case, the
>> library should also be removed from the list, because Boost is not responsible
>> if the author is busy.
>> - The review manager does not have the time for review. In that case, he
>> should not be listed as assigned, and should not block others.
> 
> There is a particular case for the Boost.Log, which has a review manager but that links yet to
> the version that was rejected.

Just to clarify -- you mean Boost.Logging? There's Boost.Log as well, which is accepted (provisionally).
It would be nice to sort out Boost.Logging situation, indeed.

>> 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.
> 
> IMO this was already the case. the author can be ready but without review manager.
> 
>> - 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 would say that the author and the review manager must set a date in the near future, let say 3
> months and that this date must be in the near future, let say 3 months.
> 
> IMO, a library that has no review manager before let me say 6 month should be removed from the
> list as there is no hard interest.

This might be controversial. Maybe, some poking on the mailing list should be done before
declaring that no review manager can be found?

>> 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.
> 
> I agree and will add that the best we can do is to know why the review is not scheduled or
> released, A library in the list could be in one of the following states:
> 
> * locking for review manager (up to 6 months -- to force the author to probe the lib is
> interesting) 
> * locking for a date and making it ready for review (up to 3 months -- needed as the
> review manager could have some specific requests to the author before the lib is ready for
> review) 
> * scheduled (up to 3 months -- tomanage with author and review manager specific
> imperatives) 
> * review ongoing 
> * result pending (up to 1 month -- to force a rapid veredict)
> * accepted but not yet in trunk (up to 2 months -- the time to setup all the needed
> infrastructure) 
> * moved to trunk (up to 3 months -- the time to make the library portable)
> * moved to release branch (up to 3 months -- the time of a release)

This might be a bit too many states for one table. How about having several tables:

1. Scheduled. Libraries that have review manager, were examined by review manager for
obvious issues, and have a review date set (within next 3 months).

2. Ready. Libraries that were submitted for review, are considered ready by their authors,
and only wait for a review manager. 

3. Already reviewed.

This set excludes your 'making it ready for review' state. It seems to me that if the library
is not ready for review -- for example because it was submitted but somebody found serious
problems with it -- should not be tracked by review wizards at all.

- Volodya

-- 
Vladimir Prus
Mentor Graphics
[phone]