Boost logo

Boost :

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

   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

   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

Boost list run by bdawes at, gregod at, cpdaniel at, john at