
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