On Mon, Nov 16, 2009 at 7:56 AM, Scott McMurray <me22.ca+boost@gmail.com>wrote:
2009/11/16 Jose <jmalv04@gmail.com>:
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.
I strongly dislike the idea of "voting" and a correspondingly purely objective acceptance criterion, since then you have to define whether someone is permitted to vote, which is necessarily exclusive.
I'd be far more interested in a 2-stage process where there's a limited review for whether something is usable, at which point is gets into the official distribution, but under a "proposed" subdirectory. These might not be the optimal implementations or interfaces, nor would they need to be at all orthogonal. A later review like the current would then decide whether it's the correct form for the functionality, at which point it would be promoted.
I actually like the idea of only reviewing new libraries for inclusion in Boost at a small number of fixed dates each year. For example, Boost could adopt a policy such as: "New libraries go up for review every February and October". This would have eliminated the problems like what occured with GGL going up for review 1 week after the other was accepted. Now we're in the unfortunate situation of either a) having 2 libraries that have massive overlap but each providing something unique, b) withdrawing a library that has already been accepted (although in reality this won't happen), or c) rejecting a library which, if compared directly against the other library may have been preferable if users had initially been asked to choose only one. In general I'm against having too much overlap in libraries. There's the discussion of [msm] and Boost.StateChart going on right now that I feel is largely similar. Although that situation is slightly different since StateChart has been around for some time. Should there be a way to deprecate old libraries when something better comes along, even if the owner of said library is still actively maintaining it (note that this says nothing about any 2 libraries in particular, including the one just mentioned in the previous sentence, I only used that as an example to lead into the situation of competing libraries)? Yea, this sucks for the original library author, I completely agree, but the person we should be caring for is the end user, not the library maintainer. Or maybe what would really be the best for the community is if people knowledgeable about the subject domain could easily and freely make changes to existing libraries without having to worry about the "library ownership" model that goes on. Or maybe if it's not one's own library that they've put their blood, sweat, and tears into they will have little to no motivation to extend / enhance it. Either way, 10 years from now I don't want to look at Boost and see 3-5 of every library just because people with well written libraries came along and wanted to offer 90% of the same functionality as what's already there, but in their own format. Perhaps one possible idea is to say that once a library for solving problems in domain X has been accepted, *that is the library, there is no other* for a set amount of time, say 3 years. At that time, there will be a process by which other competing libraries can be submitted for review, and either 1 or 0 of them will be selected to replace existing library. The key here is organization and fairness. None of the following are fair to say to someone: - [To library author] Hey your library got rejected even though it's amazing, if you had only been a week earlier... :( - [To user of boost] Since we now have a library for doing X, this will be the library forever, even if significantly better libraries come along. - [To user of boost] You have to choose between these 5 libraries, all of which solve the same problem completely differently. Likely you'll need to spend 3-5 hours reading the documentation of each one to figure out which one suits you best. As long as there is communication, set expectations, and deadlines, I think the system can be completely fair to everyone. For example, had the two competing geometry library authors known a year ago that reviews for geometry libraries would happen the first week of November 2009 then they could have both submitted at exactly the same time and could be reviewed in parallel. This way only one (or 0) could have been chosen, and it would clearly have been the best. Then if there was a library replacement procedure, the author who got rejected could have (at his choosing) opted to resubmit his library some time later, say 2-3 years. But as long as this expectation is known by all parties, the original author would have the same opportunity to improve his library so that when it is compared again later it is on fair ground. Does this make sense? If I had to summarize this, I'd say that the problems are: - lack of organization of review process - lack of communication between library authors - somewhat arbitrary review process - no fixed timelines.