Subject: Re: [boost] encouraging review managers -- was Re: Review Request:Variadic Macro Data library
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2011-02-21 01:38:03
On 2/20/2011 9:55 PM, Gordon Woodhull wrote:
> Yes, this works great and I hope that I'm emphasizing that side enough.
> If a library is rejected, the author can rewrite and seek a second review with (IMO?) a different review manager if necessary.
> Ed's concern is with the far thornier issue of, what if you think a library was improperly *accepted*, if the review manager was too biased in favor of the library?
> Aside from authors of competing libraries (who are free to submit theirs or try to get their features merged), and Luddites, have you ever seen someone severely angered by a result of acceptance?
> I'm not saying it can't happen, and I want to be sure there is a mechanism to resolve conflicts in case of incompetent or over-favoring review managers.
If anyone can ever make a reasonable claim that
there's been a serious problem, we can deal
with it then. We don't need any formalized
process to deal with hypothetical problems.
> If we admit that Review Wizards can't tell beforehand whether a Review Manager is going to do a good job, as Joachim and I are arguing, then people should just volunteer to manage reviews and not bother registering with the Wizards for a nonexistent queue.
> But it is possible that these volunteers could be nincompoops or shills, and the Review Wizards and the whole community need the power to remove a bad manager or nullify the results.
> The classic case might be, what if some bad company submitted a library that would lock everyone using C++ into their products (not sure how this would happen, but bear with me) and then "volunteered" one of their employees to manage the review? At that point I think someone should complain to the Wizards, who have the authority to reject managers. (I doubt this is exactly what Ed is worried about, just musing.)
This would clearly violate the license requirements.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk