Subject: Re: [boost] Your Boost Needs You!
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2010-12-30 13:27:56
> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of John Maddock
> Sent: Thursday, December 30, 2010 12:08 PM
> To: boost_at_[hidden]
> Subject: [boost] Your Boost Needs You!
> There's been a lot of discussion lately about improving participation in
> this is a call to arms for a *small* initial experiment which I hope will
> something bigger, perhaps after some tweaking to the initial experiment.
> aim is to merge the ideas put forward for a Boost Guild, with mine for a
> hit squad to tackle neglected libraries. It goes like this:
> * Someone, lets call him a manager/mentor/maintainer puts forward a
> that has a large number of open tickets against it and which maybe hasn't
> maintenance in some time.
> * The manager creates a copy of that library in the sandbox for folks to
> * The volunteers either submit patches or - preferably - commit patches
> the sandbox copy. Work continues for a month or two until everyone agrees
> that they have a release ready update (tested locally by the volunteers).
> * The manager reviews the changes and either: merges the changes to Trunk,
> files a clear list of things to do to make the update acceptable.
> * If the Trunk tests don't pass (and the fix isn't obvious/trivial) the
> throws the problem back to the volunteers, otherwise merges to Release.
> The aim is to:
> * Minimize the "manager/maintainer/mentor" bottleneck by having one review
> of a whole set of changes to one library, rather than having to deal with
> little patches from all the over the place.
> * Maximize the chances that the volunteers achieve something meaningful in
> defined set of time, by defining clear goals from the outset, and
> manageable target from the many folks could choose - currently we suffer
> the "too much to choose from or do, so why do anything" dilemma.
> * The manager undertakes the responsibility for stewarding the update
> to the release branch - frankly this is only possible by the mentor
> one library at a time, otherwise the "many small patches"
> problem quickly becomes overwhelming.
> * Give recognition to volunteers for their efforts, first by providing the
> that" feeling from working towards a specific target, second by adding
> acknowledgements or in the case of partial (or complete!) rewrites, co-
> authorship to the docs.
> Like I said the aim is to start small with an experiment (low risk, low
> expectations) to see how it goes... then refine the process... and hope we
> grow it into something larger over time.
> For this I'm prepared to act as the mentor/manager for an update to the
> library (though I'm certainly open to other suggestions, and if someone
> would like to take on the manager/mentor role then by all means fell free!
> :-) ). I chose this library because it's seen essentially no maintenance
> certainly no maintainer) since it was written, and because on the face of
> looks to be a manageable task for folks to take on.
> So... let me know if you're interested, and if there's enough people I'll
> goals and get things started,
This seems an excellent structure (provided we can get enough - preferably
competent! - 'managers').
I've not been willing to volunteer because of the risk of messing-up -
perhaps big-time, and very publicly!
But this seems to reduce the risk to acceptable levels.
(And perhaps we can take the opportunity to improve documentation while we
are at it).
--- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk