Re: [boost] Updating the Boost Review Process Was: [GGL] Bost.Polygon (GTL) vs GGL - rationale

Subject: Re: [boost] Updating the Boost Review Process Was: [GGL] Bost.Polygon (GTL) vs GGL - rationale
From: John Phillips (phillips_at_[hidden])
Date: 2009-11-16 14:30:11

Jose wrote:
> I propose these 3 changes (starting with the word ADD: below) to the
> current review policy in
> http://www.boost.org/community/reviews.html
> 
> I realize that there is no mention to the word "vote" in the review
> policy, just "review comments". See message below for rationale on why
> these may be good changes.
> ...
> 
> regards
> jose
> 

   I'm going to reply to this thread in two different ways, so as to try 
and avoid confusion between my role as a Review Wizard and my personal 
opinions. This reply is as a Wizard.

   The review policy is alway open to revision, based on the needs of 
the community and our understanding of what has worked well and poorly 
in the past. I strongly encourage a discussion of this sort, even if I 
don't agree with some of the suggestions. My voice is in no way final in 
such a discussion, but any substantive changes should include input from 
the Moderators and the Review Wizards, along with input from other Boost 
members.

   The decision not to base acceptance purely on votes predates my 
involvement with Boost (which dates to ~2000), so I can not provide the 
rationale for it when it was made. However, I think it is a good idea 
not to turn the review manager into a vote counter. From my experience 
managing reviews, more important than the count of votes is the 
reasoning given in the reviews. The manager looks at the reasons given 
and tries to determine how deeply they affect the library. Even when 
some persuasive negative reasons are given, the manager may decide that 
the changes to the library needed to address the complaints are not so 
central that they preclude acceptance. Such a decision has to come from 
the manager's understanding of the library, the submitter, and the 
needed changes and I do not think a formal rule for how to make such a 
decision would be a good idea. The manager is selected in part because 
the Wizards think such decisions will be made well. If we make a mistake 
in selecting a manager, then we will have to step in and adjust the 
decision but I am not convinced we made such a mistake.

   There has been talk of parallel reviews of competing libraries. This 
sounds like a decent idea on the surface but it has been tried and it 
did not go well. In the review of the two Thread Pool libraries, I do 
not think anyone involved was happy with how things ran. We discussed it 
as a community in advance and decided to review them together, but the 
reality was just not satisfying.

   A better example of how competing libraries interact well can be 
found in the Lambda and Phoenix libraries. Lambda is a well constructed 
library that has some problems that were only understood well after 
broad use in the community. Phoenix addressed some of the problems in 
the Lambda library, but not everything. Both are available in Boost. The 
two development groups then started working together to incorporate all 
of the lessons learned from both libraries into a merger that is 
noticeably better than either original. However, without the intense use 
in the community given to both libraries such a merger would not be 
possible.

   In general, many of the comments I have seen seem oriented toward a 
stronger central control and planning for Boost. I was not part of the 
founding group of developers, but my understanding has been that such 
centralized design was not chosen intentionally. In fact, given the 
number of different backgrounds and specialties represented in Boost I 
am not sure who could provide such a planning and control service.

                        John Phillips
                        Review Wizard