Important bugs list, "The List", version 2

Tanstaafl tanstaafl at libertytrek.org
Fri Dec 21 13:49:49 UTC 2012


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)
https://bugzilla.mozilla.org/show_bug.cgi?id=543827

"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)"
https://bugzilla.mozilla.org/show_bug.cgi?id=545906

and

"more meaningful status bar information when mass moving messages 
between IMAP accounts"
https://bugzilla.mozilla.org/show_bug.cgi?id=644713

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:
>> https://bugzilla.mozilla.org/page.cgi?id=fields.html#bug_severity
>>
>> #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: http://tinyurl.com/bq5xcxf
>>
>> 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]
>> https://groups.google.com/forum/?fromgroups=#!msg/tb-planning/nq3K1pIGTZg/RblSSfCbK7gJ
>>
>
> Just in time for the holidays...
>
> version 2 of The List: http://tinyurl.com/bvzc7nt     22 bugs
> version 2 with papercuts*: http://tinyurl.com/c59k55b 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