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: Jose (jmalv04_at_[hidden])
Date: 2009-11-17 04:37:09

On Mon, Nov 16, 2009 at 8:30 PM, John Phillips
<phillips_at_[hidden]> 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