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.