Papercuts remixed (was Re: What's the status of papercuts?)

Tanstaafl tanstaafl at libertytrek.org
Wed Jul 11 10:19:02 UTC 2012


On 2012-07-10 11:37 PM, Kent James <kent at caspia.com> wrote:
> I've often been concerned about the lack of attention within Thunderbird
> to long-standing bugs myself, and that also seems to be the source of a
> lot of the negative energy that sometimes surrounds the project. But
> honestly, I don't have a good feel for how important that is. I do know
> that some individuals have a lot of passion and frustration around
> certain unfixed bugs, and can generate a lot of negative energy over
> that issue.

I agree this is probably the single largest source of negativity I've 
seen in my years of using Thunderbird (and participating in these lists 
and the forums).

> But let me propose an idea. What if we were to make a list of
> well-recognized bugs (not enhancements) in Thunderbird, and make that
> the focus of an initial effort for the developer community that is
> starting to gel around Thunderbird? That would go against the
> conventional wisdom of course that developers are mostly interested in
> jazzy new features, but perhaps being different could start to build
> some positive energy. I could imagine trying to develop a list of a
> certain number of bugs (not enhancements), and set the goal of fixing
> them all in some period of time.

I love this idea, and think it would go well with a bug bounty system - 
as you pointed out, since fixing bugs isn't really considered the 
sexiest aspect of programming, this would provide a different incentive.

Also, I'd suggest adding something like a 'Bug Wrangler Heros' page, 
where people who successfully tackle these long standing bugs would be 
honored - these pages should be long lived (Mozilla should promise to 
maintain them as long as they are relevant), so that these devs could 
use these pages in their resumes if they wanted...

> So as an example, we could develop a list of 100 Thunderbird bugs that
> at least 3 people are willing to vouch for (with a limited number of
> vouchers per person, and perhaps some vetting by a benevolent dictator),
> and recruit a group of community developers to tackle those in a year.

Personally, I think 100 is too many, at least to start with. I say this 
because the usual reason given that a long standing bug is long 
standing, is because it is a big job that requires a lot of work to fix 
(properly).

So, I'd suggest starting with a much lower number (10?), and look for 
someone who can manage them properly (coordinate the people willing to 
take them on, divide the bug into sub bugs, etc)...

> Count me in, if other people are also willing to be involved.

Not sure what you mean by 'vouching' above, but if you mean 
testing/confirming bugs (and testing fixes, although I can't create my 
own builds), I'm happy to help with that.



More information about the tb-planning mailing list