Re: [boost] review system in place is extremely slow? (was Re: [rfc] rcpp)

Subject: Re: [boost] review system in place is extremely slow? (was Re: [rfc] rcpp)
From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2010-02-24 12:10:28

On Wed, Feb 24, 2010 at 7:56 AM, Paul A. Bristow
<pbristow_at_[hidden]> wrote:
>
>> -----Original Message-----
>> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On
> Behalf Of
>> Mathias Gaunard
>>
>> What I suggest is creating an unstable branch where all libraries that
>> satisfy simple quality criteria can be added, with the same layout as
>> the trunk, with some automatic tests being run, a bug tracker etc.
>> That way they get exposure, usage, and thus become easier to review
>> later on. Authors also feel more involved, and work is not done in
>> isolation as the branch contains the whole of boost.
>> A library may then get elected to the stable branch, which means you
>> simply have to merge it to the trunk.
>>
>> It could be said it is just a glorified sandbox, but I believe the
>> changes from the sandbox are enough to make it significantly different.
>>
>> What the "simple quality criteria" are remains to be defined, but it
>> should be something that only requires review from one single person
>> within the pool of approved reviewers and that isn't too time-consuming.
>> You would also probably need a community coordinator to make sure the
>> unstable branch doesn't become too much of a mess.
>
> This is in essence what I have been muttering about for some time - a collection
> of what one might describe as 'candidate libraries'.
>
> Libraries that have passed a first hurdle - being in a useful, usable state.
>
> (Their documentation might use a 'Proposed for Boost' or 'Candidate for Boost'
> logo? -see attached.)
>
> This has the considerable potential advantage - encouraging a user base.
>
> Users (both naive and expert) will smoke out many bugs and weaknesses in design
> and implementation. Â And allow those users to provide informed full reviews
> later.
>
> I also believe that  this will encourage developers to work on documentation, if
> only to reduce the burden of responding to user queries.

I think Mathias has come to the same conclusion that you arrived at a
while ago, Paul.  I remember hearing your ideas a few months before
and then again when the logo discussion came up.  Both of you are on
to something IMHO.

If I may add another suggestion:

A candidate library should have its own webpage on the boost site,
where people can Rate it and leave a review, just like a product page
at an online store (e.g. Amazon).  Any library that reaches N number
of reviews is now ready to be reviewed for official status as a Boost
library.  I think Robert Ramey also proposed something similar.

> But those who manage the sandbox and trunk, and testing, might regard it as too
> much work?

Setting up the web backends for all of this sounds like a lot of work,
but the end result is that there is no longer a review manager
required until N number of reviews have been received.  At that point,
a few review managers might read over the reviews and make the
decision as to whether to promote the library or not, or maybe that
means it goes to formal review.

If there was a graph on the website showing how many cycles you have
donated to testing, it might encourage more people to set up old boxes
as testing resources.  I know I have an older box just sitting in
storage doing nothing and I just recycled 2 other ones - how many
other people are like that?

--Michael Fawcett