Boost logo

Boost :

Subject: Re: [boost] [Boost-announce] [metaparse] Review period starts May 25th and ends June 7th
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-06-02 14:58:40

On 2 Jun 2015 at 21:28, Peter Dimov wrote:

> Edward Diener wrote:
> > Sometime during the review process the presentation of what was being
> > reviewed completely changed. A new version of the library was presented
> > using the current Boost directory structure, with a very full
> > documentation set and the link to the tutorial documentation in the
> > original version being reviewed was removed.
> >
> > I am no doubt a bit stodgier than most programmers but this is not
> > acceptable during a Boost review process.
> Several people have explicitly mentioned that they have reservations about
> the fact that the library was not presented in its final Boost-ready form
> and that they would have liked to examine, and vote on, that final form.
> Abel has accommodated their wishes and has done the necessary work to
> present the library in its Boost-ready form. It strikes me as extremely
> unfair to hold that against him. Damned if he does, damned if he doesn't.

The precedent for handling this is very well understood.

If during the early part of review it becomes obvious Rejection votes
are occurring due to presentation problems, the precedent is to
withdraw the library from review, make the fixes, and start the
review again with the fixed edition. I certainly don't like libraries
changing during review, and I also don't like two editions of a
library being reviewed concurrently. It gets very confusing very

I think peer reviews are very like academic paper peer reviews: it's
all about reducing potential for confusion, objection, or any easy to
predict reason to reject a library before you begin. It's about
eliminating as many reasons as is possible for people to reject or
find problem before you begin.

Not submitting a library in the correct directory structure is
guaranteed to create problems for some reviewers, and is easily
predicted before a review begins. Lack of CI testing is another. This
is why I wrote up that Best Practices Handbook so for C++ 11/14
libraries we can hopefully get more of the boxes preticked in the
future before reviews of C++ 11/14 libraries begin.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at