Important bugs list, "The List", version 2

Wayne Mery (d531) vseerror at Lehigh.EDU
Thu Dec 27 17:17:33 UTC 2012


I'll post a followup in the papercuts thread.


On 12/27/2012 7:55 AM, Wayne Mery (d531) wrote:
> from the archives
> https://mail.mozilla.org/pipermail/tb-planning/2012-July/001791.html
>
>
> 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 libertytrek.org> 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)
>>> 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.
>>>
>>>
>>> _______________________________________________
>>> tb-planning mailing list
>>> tb-planning at mozilla.org
>>> https://mail.mozilla.org/listinfo/tb-planning
>>
>> _______________________________________________
>> tb-planning mailing list
>> tb-planning at mozilla.org
>> https://mail.mozilla.org/listinfo/tb-planning
>>
>>
>
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning
>




More information about the tb-planning mailing list