Re: [boost] Your Boost Needs You!

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
Boost,
> 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.
The
> aim is to merge the ideas put forward for a Boost Guild, with mine for a
roving
> hit squad to tackle neglected libraries.  It goes like this:
> 
> * Someone, lets call him a manager/mentor/maintainer puts forward a
library
> that has a large number of open tickets against it and which maybe hasn't
seen
> 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,
or
> 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
manager
> 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
a
> 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
from
> the "too much to choose from or do, so why do anything" dilemma.
> * The manager undertakes the responsibility for stewarding the update
through
> 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
can
> grow it into something larger over time.
> 
> For this I'm prepared to act as the mentor/manager for an update to the
pool
> library (though I'm certainly open to other suggestions, and if someone
else
> 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
(and
> 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

---
Paul A. Bristow,
Prizet Farmhouse, Kendal LA8 8AB  UK
[phone]  07714330204
pbristow_at_[hidden]