On Mon, Nov 16, 2009 at 8:30 PM, John Phillips <phillips@mps.ohio-state.edu> wrote:
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.
Thanks for getting involved!
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
Just to make it clear, my proposal is not based on using votes. The idea is that if there is clearly two different overall opinions, and the NOs are not going to be reversed by the changes anyway, then the reasoning for the acceptance has to be well justified OR the judgement of the review manager should be questioned. Otherwise, you're ignoring the No group! With broad libraries covering different application domains, it seems obvious that the above might happen, and it's not a question of one vs the other but of broadening the purpose of the library (if technically possible!) The earlier boost libraries were more fundamental and broadly useful but some of the newer libraries are specific to application domains, not to all boost/c++ users.
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.
Well, maybe you made a mistake! If not, then please take action and FIX the situation. Also, the reviewer has to acknowledge that he has time to give a timely decision and engage all reviewers. This takes a lot of time !! If you look at the specific case, the reviewer is very experienced and has given lots of advice to one author, as acknowledged in one boostcon paper but the other application domain has been mostly ignored. From a generic library viewpoint you need to try to reconcile views that are from different applications domains, you can not just ignore half of the potential users!
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.
Nobody is suggesting more competition. I think there are times only library proposal doesn't cut the mustard and the submitter realizes this and abandons the proposal. A different case, the current case, is that different proposals are overlapping, competition has been fostered and you actually want someone experienced to guide the cooperation to get a single library.
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.
As stated above, some libraries tackle fundamental problems and multiple approaches make sense. But imagine multiple BGL-related libraries, multiple asio-related libraries, multiple GIL-related libraries, multiple geometry libraries .. I think that would be a huge mess and as a user I would be discouraged!
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.
I don't have a clear opinion on this. It looks like the Wizard has the most control over the process and maybe should be acknowledged to take some decisions on behalf of the community. If nobody owns to problem, nobody comes up with a solution. My main point is that boost has to make an effort to attract more libraries and make it easier for the new authors to get the libraies in (if the proposal makes sense!). Sometimes I find a great c++ library and encourage the author to consider submitting it to Boost but they see the cost (docs, examples, ..) but don't see the benefits as clearly (and the benefits are there in terms of peer-review driven quality, ...). Also, it would be useful to know what libraries people think are needed in boost. This could guide what needs to get in, rather than reviewing only everything that is submitted. I think many are interested in geometry-related domains so a FIX to the current situation is important. regards