Subject: Re: [boost] Updating the Boost Review Process Was: [GGL] Bost.Polygon (GTL) vs GGL - rationale
From: Jose (jmalv04_at_[hidden])
Date: 2009-11-17 05:03:51
On Mon, Nov 16, 2009 at 9:02 PM, John Phillips
> As promised, a reply with my personal opinions.
All my opinions are as a Boost library user.
> 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.
Yes, this explains it clearly. But fuzzy criteria also leads to
conflict on new situations.
It would be great if you could step in above and try to find a
solution since one of problems seems to be the way the reviews were
scheduled (a different approach is to ignore the problem and make it
bigger than it is).
> I also don't think Boost is a good place for centralized design decisions.
If I understand it correctly, in a community there are no centralized
decisions, but there are roles and yours seems the most important in
> 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
100% in agreement. But the confrontation with different libraries is
something that discourages new authors. As I said before, make it
easier for the one that proposes a library as he is doing the hard
> 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.
Ok, It's a solution, maybe not the best one but I lack the in-depth
> 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
Just read the reviews, and you'll see people mentioning that the
confrontation is not good, how did we get into this mess,
how did this happen .. I know, the easiest is to say there is not a
problem so there is no need for a solution. The schedule was bad and
that could have been fixed, the review could have been cancelled, ..!
I understand that Boost has a close-knit community at its core and
many users like me are spectators, but improving the review process is
good for everybody and others suggestions have come up, not just mine!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk