Re: [boost] Review quality [ was stack trace review]

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 blincubator.com 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 boost.org website).

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

> Robert Ramey
>
>
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost