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 15:02:35

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

   As promised, a reply with my personal opinions.

   I think the discretion of the review manager is an important 
component in the process. In some of the reviews I have managed or 
participated in there are examples of objections that I consider 
invalid. Part of the job of the manager is to understand that and weigh 
the review with it in mind. This is part of why the policy refers to the 
comments instead of to votes. If the only issue were counting votes, 
there would be no need for a manager at all. Anyone who wants to can 
look at the discussion thread and count the votes, after all.

   I also don't think Boost is a good place for centralized design 
decisions. Our goal is to promote creative and innovative solutions from 
across the community and to assure certain quality standards are met by 
them. If Boost decided as a group that we needed a recursive descent 
parser and because there are many possibilities already in existence 
that we needed to decide the allowed design before allowing a review, 
then it is unlikely that the design of Spirit would have been chosen. 
Even if it was, the later work to create Spirit 2 would then have needed 
further community discussion. I personally liked Spirit, and think 
Spirit 2 is a substantial improvement so I think a process that makes 
its development and inclusion unlikely is a mistake.

   As for whether the Polygon review decision was a mistake, I do not 
think so. One of the things I do as a Wizard is monitor review 
discussions. I think Fernando's result was a reasonable response to that 
discussion when placed in the context of the expectations for the 
library. It is not a complete solution to every geometry issue, but it 
is a strong solution to some such problems and it is an established 
solution for a respected collection of groups who use it. I'm not sure 
if I would have made the same decision if I were running the review (I'm 
really not sure. I have not spent the time thinking about the details to 
form a strong opinion.), but I also lack Fernando's expertise in the 
problem domain.

   I also do not think that the inclusion of Polygon in Boost should 
then exclude GGL. They overlap, but do not have the same set of useful 
cases.  However, if GGL is also included I do have a preferred future 
for the libraries. I would like the developers to work together to 
answer the questions of whether a combination of the solutions that 
applies across both domains (and hopefully even more) is feasible. This 
will include looking at compile time efficiency, run time efficiency, 
correctness, robustness, and quality of the abstractions. My hope is 
that such a combination can learn important lessons from both designs 
and from use by the Boost community to produce something better than 
just the sum of the parts similar to what has been happening with Lambda 
and Phoenix.

   I can imagine situations where the Wizards have to step in and set 
aside a decision, but this is not one. (To my knowledge, this has not 
happened to date.)

   Thanks again for starting this discussion and for everyones 
participation in it.

                        John