Papercuts remixed (was Re: What's the status of papercuts?)
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
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