On Sun, Oct 8, 2023 at 1:26 PM Klemens Morgenstern < klemensdavidmorgenstern@gmail.com> wrote:
Should I have rejected boost.url, which had the same amount of reviews?
Perhaps, you could have, and it would not have bothered me in the slightest, because Boost.URL *already had users* and there were more coming every day. In other words Boost.URL offered such compelling usability and utility that it did not *need* to be part of the official Boost distribution in order for other projects
I also find the question "does it belong in boost" misguided. If it passed review, it belongs in boost.
That is probably true and helpful for most reviews but we are talking about outliers. I was never given any instructions on what belongs in Boost. There is no place anyone can go to answer this question for themselves. For example, does a library with no users, no field experience, whose API is not based on any other model, for which the intention is to "shove it in Boost and see who uses it" qualify as "belonging in Boost?" I wish we knew. The simple formula of "if it passed review, it belongs in boost" is unfortunately not a healthy or sustainable model. Libraries akin to async have been around in other languages for a very long
time.... How big does the user-base need to be and how would this be measured
On this, we agree. That there is a need for *something* along the lines of Boost.Klemens.Async, is not disputed. In fact, one could say that the demand is so high, that Not-In-Boost.Klemens.Async should gain traction on its own even without the need to be included in the distribution.
Which grounds? Too few reviews? Because all the other things you brought up should be addressed during review
I would really like a review wizard to clarify what valid grounds for disputing a review are.
Again I find myself in agreement here. The review process most of the time "just works" but every so often we get just the right combination of review manager, author, library, and "direct to Boost" philosophy on a controversial tech that answering the question of "does this belong in Boost" suddenly is not simple. And we end up with reviews that proclaim acceptance if for no other reason than "coroutines are important and Boost has to _do something_ about them" without any practical experience. I want to stress that I am not saying every library needs field experience. This is different from WG21 - where I believe that ANY proposed library-only solution should bake for years. For Boost we do not need such a high bar. But a controversial library from a particular author with a particular review manager in a particular subject for which there is little to no field experience, I think that it needs to prove itself. If it was me proposing Boost.Async, and someone said "hey Vinnie you need to get some users" I would simply withdraw my library from consideration and spend the next year getting those users. That you are arguing with me and not putting in the work to market your library and work with other projects to get them to use it, is a red flag. I would make sure that when my library goes up for review there is a cadre of existing users standing with me and making their presence felt virtually ("accept this library or we will become loud!"). Boost.Klemens.Async has no cadre of existing users. No other project uses it. Basically this library is like an unhoused person asking for handouts "please accept my library even though I have no users." As a matter of pride I would never allow my hard work to limp into a review with no support. Thanks