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

Axel axel.grude at
Wed Jul 11 22:41:14 UTC 2012

> On 7/11/2012 3:19 AM, Tanstaafl wrote:
>> On 2012-07-10 11:37 PM, Kent James <kent at> wrote:
>> ...
>>> 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?...
>> 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...
> These kinds of things don't motivate me, don't know about others. But it is hard for 
> me to picture someone like mconley or jcranmer being motivated by that, and those 
> are the type of people that we need to fix these kinds of bugs. But I could be 
> persuaded if this is motivating to others.
what ever happened to the rolling credits that the older versions of fx / tb used to 
have? i kind of liked that as motivation...

>>> So as an example, we could develop a list of 100 Thunderbird bugs that
>>> at least 3 people are willing to vouch for ...
>> 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)...
> You may be right. But the impressions that you get from the more negative people is 
> that there are lots of long-neglected bugs that are simple one line changes, but I 
> also know from my own experience looking over lists of bugs with lots of bz votes 
> that those are actually quite hard to find. But I myself could do 5 difficult bugs 
> per year, so the number that we choose is partly determined by the number of people 
> who are willing to count themselves in for the effort.
I think there are some complex or fundamental ones like format=flowed which are 
cintinually mentioned on the newsgroup. they kind of sound important although i 
wouldn't know whether they really are. it could also be that some people are more 
persistent in repeating their gripes.
>>> 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.
> My term "vouching" was meant to represent the process of selecting which bugs you 
> think need fixing, and adding your "voucher" to some number of those. I meant it as 
> a plural term for the noun "vote". 
exactly, shouldn't the bug votes somehow be accounted for when prioritizing them? 
guess we will need some sort of committee to decide which bugs are really important.
> That is an important process, and I would welcome your participation, but at this 
> point in time I think that we need to get some committed developers to lead some 
> credibility to the effort. 
funny, just what i said without having read the rest of your post. the thing is i 
would probably have some opinions but i wouldn't feel experienced enough to have 
anything approximating an "informed overview". I think you should be part of such  a 
panel / committee.
> The people with negative attitudes (and haven't we all been there at some point?) 
> need some convincing that this is a serious effort.
> rkent
> _______________________________________________
> tb-planning mailing list
> tb-planning at

More information about the tb-planning mailing list