Re: [boost] [metaparse] Review Manager

Subject: Re: [boost] [metaparse] Review Manager
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-03-18 17:17:32

On 3/18/2015 3:40 PM, Robert Ramey wrote:
> christophe.j.henry wrote
>> Hmmm, wouldn't that mean setting the bar higher? Isn't it already high
>> enough? It's not for me to decide but I don't favor this. Seeing the
>> incubator as a
>> way to get more reviews is ok for me, but as prerequisite?
>
> OK - let me state it another way.
>
> I would like to avoid situations that have occurred in the past whereby
> libraries were reviewed with only a very small number of reviews.  We could
> discuss what "small" is.  I think we'd agree that 2 is "small" where 10 is
> not "small".   FWIW my pick would be 5.
>
> If a library is rejected for lack of reviews, we've wasted time of the
> review manager and a two week review window - both scarce resources.
>
> If the first couple of reviews highlight some show stopping problem which
> forces the author either to retract his review request or accede to
> significant re-design - the review resources have also been wasted.
>
> if the review period falls at an inconvenient time for some key reviewers
> and they can't make a review in that time frame we've also lost good
> opportunity to maximize the effectiveness of the review.
>
> Now look at the incubator NOT as a pre-requisite but rather as  way to
> minimize the possibility of a library getting rejected due to not getting
> enough serious reviews. Or maximizing the number of quality reviews. So I
> would encourage the libraries advocates to post their reviews on the
> incubator in advance of the formal review date.  That's all I want to do ...
> (for now).  I'll leave open the question of whether it's an effective usage
> of scarce resources to do a formal review if there are no existing reviews
> in he incubator.
>
>> Hmmm, wouldn't that mean setting the bar higher? Isn't it already high
>> enough?
>
> YES - it needs to be HIGHER!!!  AND C++ needs MORE libraries.
>
> I'm aware that these two goals seem to conflict - that is why we need to
> evolve our procedures.
>
> As a user of boost - it seems that many, many, many times I want to look at
> a library and find way too much effort is required to understand and use the
> library.  A big, recurring problem is poor documentation.  Library authors
> consider it an afterthought rather than an integral part of the library.
> Another big recurring problem is library interface design.  This results in
> a number of libraries where the authors state that they can't specify
> concepts because ....  well I don't know.  Usually it comes down to the fact
> that the library interface isn't really designed - it seems to just sort of
> "happen".
>
> Declining to raise our standards is a one way ticket to irrelevance.

The problem is that almost no one is using the incubator to show 
interest in a Boost library which may be on the review schedule. Unless 
a review is scheduled, which brings the attention of the library to 
others who may be interested in it, there is little personal interest 
from developers or users to look at some library. Once a review is 
scheduled and an announcement is made that library X will be reviewed 
shortly programmers become interested in that library.

I agree there are cases where interest in a possible library occurs but 
that is almost always because it is mentioned in this mailing list and 
talked about by other developers or end-users. Hana is a recent case 
like that. But unfortunately merely adding a library to the incubator is 
not getting anybody interested in it. This is not a criticism of your 
work setting up the incubator but it is more about the fact that 
discussions on the Boost mailing lists pique people's interest much more 
than just adding a library to the incubator.

So unless there is some fairly coninuous way of getting information 
about libraries on the incubator into the Boost mailing lists I do not 
see that requiring incubator interest in a library in order for that 
library to be reviewed is a viable path to go.

I do agree with you completely that poor or haphazard attention to 
documentation, as in "I've developed library X which I might be 
interested to submit as a Boost library but as present there is no or 
little documentation, but what do you think about it since the source is 
at http:xxx and it is about Y and Z" does not personally interest me in 
any library. I am with you that without basic documentation a library 
could be the most brilliant thing since the theory of relativity and I 
would still have no interest in it. But that is separate from the issue 
of requirements of whether a library should be reviewed or not.