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.