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 19:18:06

On 2 Jun 2015 at 12:59, Paul Fultz II wrote:

> > 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 think that is a huge waste of everyone's time for something as trivial as
> moving folders around.

Thing is, it may or may not actually be trivial. In the past I've 
thought something was as simple as a find and replace, and then it 
turned into something quite tricky because the find and replace 
exposed a deeper design problem. The OP has demonstrated that isn't a 
problem in this case, hence I withdrew my objection.

> > I think peer reviews are very like academic paper peer reviews: 
> 
> Except most of the time, its a volunteer effort, so I think its important to
> be respectful of everyone's time.

Academic journal peer reviews are usually a volunteer effort too.

> > 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. 
> 
> Perhaps Boost could agree on some minimum list of requirements for a
> library before it goes into review, but I doubt it will be same in your
> Best Practices Handbook. 

Agreed. My aim wasn't to write up the requirements, but to write up 
examples of what I thought was best practice with the later aim of 
scoring them via automated script. Very different goals.

> However, having some official list can help make this clearer in the
> future. 

The existing requirements documentation is long in the tooth. Someone 
ought to write up an official document and run it through multiple 
rounds of peer review until it's canonical.

Niall

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