Re: [boost] [Boost-announce] [metaparse] Review period starts May 25th and ends June 7th

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 
quickly.

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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/