Boost logo

Boost :

Subject: Re: [boost] Review quality [ was stack trace review]
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-12-26 13:08:09

Am 26.12.2016 um 17:39 schrieb Robert Ramey:
> On 12/25/16 7:18 PM, Andrey Semashev wrote:
>> Second, it's not like the library does not exist before it is
>> accepted. Users and the author have every opportunity to try the
>> library in the field, if they want to. There is as
>> well.
> Indeed, the ability to make a library visible in a convenient way for
> usage and experimentation in advance of the formal review was one of
> the main goals of the inclubator. The hope was that the authors would
> get enough feedback to detect and make adjustments for obvious issues
> in advance of the formal review. The hope was that this would make
> the review process run smoother and diminish the number of libraries
> rejected in the review process.
> To my disappointment it hasn't worked out that way. Libraries get
> very little feedback on the blincubator or anywhere else for that
> matter. I understand this as it's actualy a fair bit of work to
> review a library. But that doesn't keep me from being disappointed
> though.
> Library authors are anxious to get their library on to the review
> queue and feel compelled to find a reviewer to accept the task. I
> understand this as well. But still I'd like to see more "pre-review"
> feedback.
Since I recently went through the review process, I would like to share
my thoughts on that: it is very, very difficult to get feedback before
the review. This does however make sense from the perspective of the
reviewer, since he doesn't want to invest hours into a library that
might look completely different. That leads to the rather unfortunate
situation, that library authors are operating in the dark before the
review; you actually only have to have the feedback of one person, the
review manager.

Secondly it seems to me, that the conditions of acceptance are not
clearly defined, i.e. what an approving review actually means. Some say
yes because they think the design is alright, others say no, because the
implementation is not as good as they wish. For me the criteria would
be: it solves a problem, the design is sound, the implementation works,
and we have sufficient reason to believe, that further improvements will
not break code using it. I think this could be more clearly statet, i.e.
at which point a library should be accepted into boost.

> And a few authors have declined to post their library on the
> blincubator at all. I'm sure they have their reasons, but I'm
> disappointed that they don't find it compelling or necessary.
> I should say I received very little feedback on my safe numerics
> library. BUT I found it to be very, very, useful. It made me realize
> that that I had to make a strong case for the necessity for such a
> library. In hindsight it's incredible that this had never occurred to
> me. Up to that point I had always assumed that the whole world was
> anxiously awaiting my solution to the very obvious and glaring problem
> with computing which has been around since it's inception.
> So I am interested in receiving feedback on the incubator. On the
> other hand, making changes of the incubator requires understanding of
> modern web tools which are very, very, depressing to use for the
> compable C++ programmer. Oh well.
I think the incubator can only solve that problem, if there is some
incentive to actually use it. Currently it is in the way I've seen it
only a list of libraries that people have proposed for boost. That is
not meant to say it's bad, but all the interaction is going on on the
mailing lists and thus there is not much attention put on the incubator.
At least by me.

Here's what I would do, which might create an incentive for people to
pay more attention:

The libraries on the incubator should be in a late phase of their
development, thus they have to be filtered. They need to solve a
problem, have a documentation & test. As a condition, there might be a
poll, and if 3 or 5 boost contributors approve it is added. Then it has
a time-limit, of let's say one year. If it doesn't reach review then or
gets an extension approved, it gets removed, thus keeping the incubator
current. If you look a the incubator list, there are just way to many
libraries that don't have a review date. boost.proces was 2 years on it,
without anything moving. I don't have a problem, with development being
paused, but if you have an incubator, it should be making progress.

So the way I'd see it: a library in the incubator is partially usable
and in active development. That way the libraries in the incubator would
actually be interesting; instead of a list of planned developments it
would be a list of stuff I could try out. Thus there would be more
interest, I'd think.

Now if we had that approach, we could go one step further: have a
boost-incubator release/github-branch which would give libraries in the
incubator more publicity (if put on the website).

Btw.: the incubator is also outdated, hana, fiber, metaparse are already
released with boost.

> Robert Ramey
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at