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