Re: [boost] [Bug Sprint] Final report for the (late 2010) Bug Sprint

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)?
>>>
>>>
>> Hi,
>>
>> 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.