Boost logo

Boost :

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
grow into
> 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
work on.
> * The volunteers either submit patches or - preferably - commit patches
direct to
> 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
lots of
> 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
selecting a
> 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
dealing with
> 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
"I did
> 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
it, it
> 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
define the
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at