Re: [boost] Improving review process

Subject: Re: [boost] Improving review process
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2011-01-13 11:49:08

----- Original Message ----- 
From: "Vladimir Prus" <ghost_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, January 13, 2011 2:25 PM
Subject: [boost] Improving review process

> 
> Recently, there were various comments about current review process, and its 
> possible improvements. However, I wanted to start with a small point.
> 
> Looking at:
> 
> http://www.boost.org/community/review_schedule.html
> 
> it seems that a few libraries have a review manager assigned, but there's no
> date. This means that:
> 
> - It looks like our review schedule is full, because the item is there, and
> - It prevents anybody to volunteer as review manager for such library.
> 
> I think there might be several reasons why a library does not have a review
> date:
> 
> - The library is not actually ready. In that case, it should not be in that 
> table at all.

+1.

Another case could be that the library depends on another library not yet scheduled.

I'm the review manager for Boost.Task (which was Boost.ThreadPool when I proposed myself). Boost.Task depends now on Boost.Fiber and Boost.Context (In addition these libraries depend as a implementation detail on Boost.Atomic which is not on the review Schedule.

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. 

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

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

Of course all the periods are subject to discussion, but the fact to have them should surely improve the time between the moment the author propose the library and the time the lib is released.

Best,
Vicente