Subject: Re: [boost] [review queue] What to do about the library review queue?
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-03-14 23:00:45
On 14.03.2017 17:53, Robert Ramey via Boost wrote:
> "Only those who have managed a boost review can expect their library
> submissions to be to be reviewed."
The qualifications needed to write a boost-grade library and the
qualifications needed to manage a review aren't the same. I don't think
it's sensible to couple the two tasks in the suggested way.
But I'm still concerned that most of the replies to the OP are far too
short-sighted: While I can feel the pain of a developer waiting for a
review, I don't think anything can be done about this, on a strictly
I'd actually be curious to see how many of the existing Boost libraries
are actively being maintained or developed. Far too often a library
managed to get through the review process, only to be orphaned later on
because the original author has lost interest and or there wasn't enough
critical mass in the user/developer community to keep the project going.
In an ideal world, a library would start its life within an existing
community of users and developers, so finding reviewers (including
someone willing to manage the review process) shouldn't be hard.
In contrast, if a library is stalled in the review queue, perhaps that
hints at there not being enough interest to [use, develop, review] it ?
So who would be helped if the review process was accelerated artificially ?
What if the criteria for acceptance (into Boost) would be changed such
that an active user and developer community was a prerequisite, as a way
to predict the project's livelihood ? Again, this would work best if the
library would be much more autonomous, so there was much less
integration work required to bring a library on board. Boost wouldn't
subsequently have to care for maintenance of the library. If a given
library would be unmaintained for an extended period of time, it would
simply be removed from Boost.
No single person (or group of persons) would have to be responsible for
certain tasks involving all of Boost (including but not limited to:
building, testing, releasing), making the overall (umbrella)
organization much simpler to manage and contribute to.
-- ...ich hab' noch einen Koffer in Berlin...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk