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
Am 26.12.2016 um 17:39 schrieb Robert Ramey: 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