Re: [boost] Updating the Boost Review Process Was: [GGL] Bost.Polygon (GTL) vs GGL - rationale

Subject: Re: [boost] Updating the Boost Review Process Was: [GGL] Bost.Polygon (GTL) vs GGL - rationale
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2009-11-16 10:20:28

On Mon, Nov 16, 2009 at 7:56 AM, Scott McMurray <me22.ca+boost_at_[hidden]>wrote:

> 2009/11/16 Jose <jmalv04_at_[hidden]>:
> >
> > 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.