Important bugs list, "The List", version 2

Wayne Mery (d531) vseerror at Lehigh.EDU
Thu Dec 27 12:55:49 UTC 2012

from the archives

On 12/26/2012 6:37 AM, Tanstaafl wrote:
> Anyone? Is there even an official 'path' to getting one of these on the
> official list?
> Would appreciate a response, even if it is 'go away'...
> On 2012-12-21 8:49 AM, Tanstaafl <tanstaafl at> wrote:
>> Back in October, I sent an email asking how to add nominations for
>> papercuts...
>> 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)"
>> and
>> "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.
>> _______________________________________________
>> tb-planning mailing list
>> tb-planning at
> _______________________________________________
> tb-planning mailing list
> tb-planning at

More information about the tb-planning mailing list