Subject: Re: [boost] [Bug Sprint] Final report for the (late 2010) Bug Sprint
From: Edward Diener (eldiener_at_[hidden])
Date: 2010-12-07 15:35:46
On 12/7/2010 1:44 PM, Roland Bock wrote:
> On 12/07/2010 04:52 PM, Vicente Botet wrote:
>> Marshall Clow-2 wrote:
>>> Well, the bug sprint is over. [ But that doesn't mean you have to stop
>>> fixing bugs if you don't want to! ]
>>> So - what did people think went well during the bug sprint?
>>> What went poorly?
>>> What can we do better next time (assuming that there is a next time)?
>> I hope there will be a next time. I find we need this kind of sprints to
>> decrease the number of tickets.
> As a long distance runner, I'd argue that sprints take you only a few
> meters and than you have to stop and catch your breath. Measured over a
> longer period of time, continuous jogging or even walking will take you
> much further.
> I therefore wonder if there are ways to make it more attractive to fix
> bugs in general. Not only during bug sprints? Maybe we could have some
> "Bug Fixer of the Month" Award? Or let contributors appear in the
> release notes?
> I don't know. In Web2.0, you are the coolest guy if your blogs are
> referenced/read/whatever by the most people or if you have the most
> friends, etc. In the boost community maybe you could gain a certain
> standing by fixing bugs or contributing test cases...
The best way to make fixing bugs in Boost attractive is to know that
once one has tested the fix and created a patch, the fix will not just
sit somewhere and never be applied. Either Boost needs more people who
have access to changing Boost trunk to deal with patches as they are
submitted, or it needs to give access to more trusted people to update
Boost trunk with patches. At the same time, if the latter happens,
anybody who is given access to Boost trunk directly to apply a patch has
to take responsibility in case the patch is in any way incorrect to fix
it or remove it.
As a programmer I would be most discouraged if a patch on which I had
worked hard were never applied to fix a problem. This would induce me
not to make further efforts trying to fix a product. Having been in that
situation, in my last official on-site corporate job some 2+ years ago,
I had much less interest in continuing my efforts to improve the buggy
product(s) on which I was working. Boost is, of course, much better than
the typical corporate software, but I believe the same principle
applies. Programmers get a great deal of impetus and personal
satisfaction in their work when they know that their efforts are being
applied and they are improving a product, even in cases where they
themselves may not be acknowledged.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk