Important bugs list, "The List", version 2

Tanstaafl tanstaafl at
Fri Dec 21 13:49:49 UTC 2012

Back in October, I sent an email asking how to add nominations for 

I have 3 near and dear to my heart...

I added them to the wiki as nominations, but no response...

Any chance of getting these approved/added to the official list?

Here they are again:

"Option to use same credentials for outgoing as incoming"
(cannot imagine why this one wouldn't be brain-dead simple)

"Make column pickers sticky/persistent (menu should behave like a panel, 
i.e. stay open for selecting multiple columns until user clicks outside 
or ESC)"


"more meaningful status bar information when mass moving messages 
between IMAP accounts"

Thanks as always to the devs, and Merry Christmas to all...

On 2012-12-20 4:48 PM, Wayne Mery (d531) <vseerror at Lehigh.EDU> wrote:
> On 9/21/2012 6:23 PM, Wayne Mery (d531) wrote:
>> The QA breakout at mozcamp [1] discussed making a list of high value,
>> i.e. "most important" bugs list for developer attention and action. This
>> is to be a small, selective set of bugs, culled from a larger set of
>> bugs, to serve as a managable "grab bag" for developers.  The idea is,
>> as bugs on the list are fixed they are removed from the list, and other
>> bugs added to the list.  ("important bugs" is not an official name - so
>> let's not haggle yet over names)
>> This is not a list to make everyone happy; not every user will see one
>> of their issues here. The goal is to tackle a focused list, and add to
>> and subtract from it as progress is made.
>> Per the meeting, there are 4 dimensions to categorizing bugs for this
>> list:
>> 1. How many people are likely to be affected
>> 2. How serious is the effect when it occurs (workaround? consequences)
>>     [severity as defined by bugzilla]
>> 3. How much effort to fix this bug?
>> 4. How reproducible it is
>> To summarize what I think is the current situation
>> #1 is going to be a judgment call by QA, in come cases informed by
>> feedback from support forum - feedback which we currently don't have
>> except the unweighted [gs] whiteboard item
>> #2 we know from bugzilla - unless the severity setting is incorrect.
>> When you touch a bug you should check the severity and change it if you
>> feel it isn't accurate. Ref:
>> #3 can be judged by developers, and for some bugs probably by trigers.
>> To what extent it affects whether a bug gets on the list remains to be
>> seen.
>> #4 well, presumably every confirmed bug is reproducible to some extent.
>> But we know this is not true. If we continue to feel this is an
>> important factor to a bug being on the list, know that it will require
>> *signficant* manpower to accomplish as it will require reasessing a high
>> percentage of our bugs.
>> It will be weeks I think until we are in a position to create a list
>> based on the above 4 elements and a process to go with it. And even then
>> it will likely be iterative - starting with an imperfect process that
>> doesn't cover all the criteria and working toward a better process, that
>> may or may not cover all of the criteria.
>> So I have created an interim ~top 30 list:
>> Most of these bugs are deserving of attention for multiple reasons. I
>> used criteria #1 and #2. For #3 I have merely eyeballed and made a best
>> judgement that the bug (or it's blockers in the case of a meta) probably
>> doesn't require more than a weeks time or major architecutral changes. I
>> have not attempted to assess "reproducibility" in this cut.  I created
>> this list a week ago when I was still sick, so I don't claim it is
>> unbiased or proper in any particular way - it is my interpretation of a
>> top 30.  But I will welcome private email as to the suitability of any
>> bug to be on the list - and summarize later for the group so it can be
>> used to improve whatever future process we put in place.
>> For my own sanity I excluded large numbers of bugs, like address book
>> and filters because the former will hopefully be revamped in the next
>> year/in our lifetime, and the later because it has already been heavily
>> triaged in recent months due to the efforts of aceman and others. I
>> excluded international, build, security either because I have no
>> experience in those areas or because the area is highly specialized and
>> likely not of interest to the average developer. I excluded
>> severity=minor and severity=normal.
>> Many are dataloss or datalossy. Some are assigned and/or well in
>> progress. Many are not.
>> - I heavily favored bugs that have recent activity (on a sliding scale),
>> let's say the last 120 days.
>> - I have not yet examined most hang and performance bugs - but I am
>> pretty sure we have no hang bugs that are pervasive amongst users
>> - I did not use prior bug lists (for example paper-cuts or various
>> wanted flags) to either include or exclude any bugs.
>> Use in good health.
>> [1]
> Just in time for the holidays...
> version 2 of The List:     22 bugs
> version 2 with papercuts*: 27 bugs
> This list represents some of our most pressing needs. Missing however
> are any maildir bugs which probably should be added RSN if there is to
> be any hope of getting users to adopt maildir in the TB24 era.
> The List version 1 was 32 bugs. 12 closed as follows: 9 fixed, 2 WFM, 1
> dup to a fixed bug.
> In version 2, 787618 is removed and added to tb-enterprise. four are
> added: 794303, 794303, 815012, 471492.  These were culled from confirmed
> bugs only created since The List version 1 as follows:
> severity=major+critical, regressions with sev=normal.
> * Note: it is still the case that not all papercut bugs are labeled as
> such in bugzilla. So "version 2 with papercuts" is incomplete with
> respect to papercuts.  It would be good for someone to take on that task.

More information about the tb-planning mailing list