Re: [boost] [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue member requirements

Subject: Re: [boost] [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue member requirements
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-04-02 09:13:09

On 1 Apr 2015 at 23:31, John Phillips wrote:

>    I think I can speak for both Ron and myself when I say that our 
> opinion has been that we run the review system the Boost community wants 
> to have much more than we decide what the review system should be.
> 
>    Historically, we have long had libraries that were in the queue, but 
> not scheduled for a review, that were not yet Boost ready. In a sense 
> they were placeholders that made it clear someone was trying to create a 
> library for task X. The queue was where they could be visible to a large 
> fraction of the community and start discussions about implementation 
> decisions and other useful questions.

I had thought that the historical placeholder page was 
https://svn.boost.org/trac/boost/wiki/ReviewScheduleLibraries?

Whereas the page at 
http://www.boost.org/community/review_schedule.html was for 
supposedly "Boost ready" libraries?

>    The more recent creation of the incubator probably makes this 
> practice outdated, and I expect newer libraries under development will 
> receive more valuable attention in the incubator than in the queue. As a 
> community member, I would support moving such libraries out of the queue 
> and into the incubator, but preferably with developer agreement.

I would far prefer a scoreboard based system which shows a ranked 
list of libraries by quality score. Auto generated from a database, 
of course.

I also think that Boost 2.0 should be about being a single stop 
portal for "Boost quality" libraries rather than Boost libraries. I 
was recently working with eggs.variant for example, and that is Boost 
quality written to Boost guidelines and yet I understand there is 
zero interest in it entering Boost, despite it being superior to 
Boost.Variant in almost every way. Same goes for HPX and plenty more.

Anyway, I'll elaborate during the Boost 2.0 talk.

>    Testing policy is a more difficult question in my mind. It has not 
> been the history of Boost to require any specific testing infrastructure 
> (or most other sorts of infrastructure) for libraries. There have been 
> times when this non-requirement has increased complexity, but there have 
> also been times when experimentation has found better solutions. As a 
> community member, I'm wary of forcing standardization, and would need 
> some pretty persuasive arguments to support it.

Requiring Travis support does not cause the exclusion of any other 
form of testing, it just sets an absolute minimum bar to pass - a 
minimum bar that I might add is increasingly becoming the bar for ALL 
open source projects, so by not requiring it Boost looks behind the 
times to the wider open source community. It does require people to 
use github which is a bit locked in alright, but the huge advantage 
of git is that you can have github auto mirror a git repo elsewhere 
to avail of the github-specific free tooling.

>    One thing I strongly support is community discussions on how to 
> improve our review process. Thanks to Niall for starting one, and to all 
> the other participants, as well.

By the end of this week I'll post the list of forthcoming C++ 11/14 
only Boost libraries I'll be reviewing in my C++ Now talk. I am 
currently building a "traffic light" matrix of "Boost readiness" of 
the C++ 11/14 only libraries that I know of ordered by closeness to 
entering Boost. I think it'll be surprisingly interesting to the 
list, I was a bit surprised myself.

What would be really great is if the formal review schedule at 
http://www.boost.org/community/review_schedule.html could be enhanced 
to also show the same traffic light matrix of "Boost readiness" of 
its entrants. Actually, I'd personally like such a traffic light 
matrix for *all* Boost libraries, because it would illuminate just 
how badly maintained some of them are (and hopefully encourage their 
timely removal).

Niall

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