-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Thursday, December 30, 2010 12:08 PM To: boost@lists.boost.org 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 +44 1539 561830 07714330204 pbristow@hetp.u-net.com