Re: Thunderbird Bugday Planning
Wayne Mery
Wayne Mery
> ...
> We invite you to participate in the discussion of planning bug days in
> mozilla.dev.apps.thunderbird and in the new planning wiki at
> http://wiki.mozilla.org/Thunderbird:Bugdays_Planning -- and of course on
> actual bug days http://wiki.mozilla.org/Thunderbird:QA_Days
>
> We look forward to your participation.
>
> wsmWK
Great news! After 6 bug days completed, thanks to all our bugday
participants we have touched over 650 bugs. And 175 have changed
resolution during a bugday [1]. So our pace is 30 bugs closed per bug
day. That's fantastic work. And the graph continues to go down!
https://bugzilla.mozilla.org/reports.cgi?product=Thunderbird&datasets=UNCONFIRMED%3A
The bad news is short term we are not keeping pace with the number of
bugs being reported. Looking at the four most recent 2-week spans, bugs
reported/closed/unconfirmed are respectively 90/25/30, 70/30/30,
80/45/20, 70/30/30 (bugs created 1d-15d, 15d-29d, 29d-32d). Net result
for bugs reported in the last 8 weeks, 33% remain unconfirmed.
So your ideas are still very much needed on how to improve bugday and
bugday participation, and more generally how to improve the bug process
- reporting, triage, etc.
Please post your suggestions at
http://wiki.mozilla.org/Thunderbird:Bugdays_Planning
[1] We know this because of the great statistics Gary keeps -
http://spreadsheets.google.com/pub?key=p5s-HZTtle5tmH9YD612eEA
Wayne Mery
reported bugs. But I don't want to have bugday participants complicate
or duplicate work that others already doing effectively, and want to
continue doing.
So for those of you who consistently watch the stream of newly reported
bugs and triage some of those bugs (for example philr, magnus, and
hopefully dozens of others), I have these questions:
1. What bugs do you currently watch and act on - is it primarily bugs
that are sev=major+critical?
2. Of the bugs that you currently triage, is there a subset that you
rather would _not_ be doing?
3. Assuming we create for bugday participants a query for "recent bugs",
would you, and if so how would you improve/alter the following query?
- created in last 60 days
- unconfirmed
- no comments other than reporter's
- if created in last 7 days, severity < major
a query which approximates this: http://tinyurl.com/5npdv7
(currently 78 bugs)
Joshua Cranmer
> 1. What bugs do you currently watch and act on - is it primarily bugs
> that are sev=major+critical?
ATM, I watch Core -> Networking: News and Core -> MailNews: Database
(actually, the respective QAs); I will tend to act on "new" bugs that
are moved there and occasionally will go through them again to make sure
I'm doing the right thing. I plan to add some more QAs to watch later,
but this is sufficient for now. Watching Thunderbird -> General or
Thunderbird -> Mail Window Front End (where most misfiled core mailnews
bugs end up) is on my todo list, once I get some more time.
> 3. Assuming we create for bugday participants a query for "recent bugs",
> would you, and if so how would you improve/alter the following query?
>
> - created in last 60 days
> - unconfirmed
> - no comments other than reporter's
> - if created in last 7 days, severity < major
>
> a query which approximates this: http://tinyurl.com/5npdv7
> (currently 78 bugs)
This might be grounds for a second query, but platform-specific
recently-confirmed new bugs might be helpful for cross-platform
verification.
Wayne Mery
xplatform "double check" is an interesting idea. However, a) in
dev/patch-maker experience, how useful would such checking be (IOW
surely not all components need such checking, so what types of bug DO
need such check?), and b) not sure what would constitute a good query -
the starting point being ...
- recently confirmed
- not-OS=ALL
- <what else?>
Gary Kwong
> xplatform "double check" is an interesting idea. However, a) in
> dev/patch-maker experience, how useful would such checking be (IOW
> surely not all components need such checking, so what types of bug DO
> need such check?), and b) not sure what would constitute a good query -
> the starting point being ...
> - recently confirmed
> - not-OS=ALL
> - <what else?>
Something I noticed about x-platform bugs; if they're listed as Windows
/ All, they're most likely x-platform. Linux / Mac bugs tend less to be
x-platform, esp. the Mac ones.
-Gary
ovidiu
> On 4/6/2008 9:02 PM, Wayne Mery wrote:
>> ...
>> We invite you to participate in the discussion of planning bug days in
>> mozilla.dev.apps.thunderbird and in the new planning wiki at
>> http://wiki.mozilla.org/Thunderbird:Bugdays_Planning -- and of course on
>> actual bug days http://wiki.mozilla.org/Thunderbird:QA_Days
>>
>> We look forward to your participation.
>>
>> wsmWK
>
> So your ideas are still very much needed on how to improve bugday and
> bugday participation, and more generally how to improve the bug
> process - reporting, triage, etc.
>
> Please post your suggestions at
> http://wiki.mozilla.org/Thunderbird:Bugdays_Planning
>
1. First thing that comes to mind is creating _Meta Bugs_ or something
alike. (Course, the example of tag meta bug posted here is a trigger..)
But the idea is to have some sort of collections of bugs on specific
features/portions of app so that it makes it not only easier to find
dupes and follow dependencies, but also , when attaking a certain area
to have a better general view. take it as consolidation..
That would become very handy if it would be somehow available /visible
to the reporter at the time of searching and filing. Though I don't see
yet how that is possible without complicating bugzilla ui.
I do consider that also for those bugs that may become obsolete when
versions change and there is a completely new approach to a feature.
[that "tags" meta bug may be an example if there will be a
tag/label/category overhaul ..]
Maybe that metabug will attract some more people on specific interest. ?
Like having some links on this dev ng or even in bugzilla or even in the
how can you help tb pages. Some may become more interesting, especially
front end and usability .. Or having discuss on specific areas ..
2. Another thing, bout new bugs, is that I think work is done in trunk
and some bugs may even be addressed there already, while bugs filed in
tb2 will still wish for some features. This separation is tricky, as you
cannot close/resolve a bug if is worked on tb3 and a have a reporter to
immediately find that.
[For example, I look and search for a "add to bcc" feature in contacts
aside compose window and not! get correspondent bug solution. Simple
search for bcc brings only 2-3 bugs, those resolved, not. See
http://tinyurl.com/5b7pk4 for search on "bcc" and
http://tinyurl.com/6c94fq for "add to bcc" where either I don't see the
precise feature [1] or I see [2] the bugs as invalid or dupe. But there
is add to bcc in tb3! And I cannot find that if I just use 2. I could
then file another one, though is kinda solved. ]
3. May be a search issue also, as above, while wondering how much time
one takes to really search before file a bug. And what search abilities
are needed ..
4. Maybe a movie called Bug Busters! will help making it popular .. :)
Pls disregard ..
I'm still thinking of a productive way of approaching these. Especially
that consolidation ..
if these make any sense (not 4, ok ..) I 'll post on wiki
I'll be back..
Magnus Melin
> I'm considering adding a query for bugdays that focuses on recently
> reported bugs. But I don't want to have bugday participants complicate
> or duplicate work that others already doing effectively, and want to
> continue doing.
>
> So for those of you who consistently watch the stream of newly reported
> bugs and triage some of those bugs (for example philr, magnus, and
> hopefully dozens of others), I have these questions:
>
> 1. What bugs do you currently watch and act on - is it primarily bugs
> that are sev=major+critical?
Severity doesn't affect me much, except the real critical ones...
> 3. Assuming we create for bugday participants a query for "recent bugs",
> would you, and if so how would you improve/alter the following query?
>
> - created in last 60 days
> - unconfirmed
> - no comments other than reporter's
> - if created in last 7 days, severity < major
Really can't say what's good for a bug day, but at least more in general terms I
think it's important to get invalid/duplicate bugs marked as such to get them
off the radar fairly quickly, preferably within the fist week from filing. So
I'd engourage more people wanting to help to also look at the recent bugs.
For regressions, it's so much easier to get them fixed if the cause and/or
regression window is dug out early on.
-Magnus
Wayne Mery
> On 2008-05-11 23:18, Wayne Mery wrote:
>> I'm considering adding a query for bugdays that focuses on recently
>> reported bugs. But I don't want to have bugday participants complicate
>> or duplicate work that others already doing effectively, and want to
>> continue doing.
>>
>> So for those of you who consistently watch the stream of newly reported
>> bugs and triage some of those bugs (for example philr, magnus, and
>> hopefully dozens of others), I have these questions:
>>
>> 1. What bugs do you currently watch and act on - is it primarily bugs
>> that are sev=major+critical?
>
> Severity doesn't affect me much, except the real critical ones...
>
>> 3. Assuming we create for bugday participants a query for "recent bugs",
>> would you, and if so how would you improve/alter the following query?
>>
>> - created in last 60 days
>> - unconfirmed
>> - no comments other than reporter's
>> - if created in last 7 days, severity < major
>
> Really can't say what's good for a bug day
to clarify - my goal for this query is not about bugday participants,
but rather about doing a better job of how we handle new bugs - in
general distributing load, being more timely, etc. And specifically:
a) to identify valid new bugs sooner, so that we ...
b) increase satisfaction of our bug reporters, and avoid having them
feel it's not worth filing bugs or responding to questions in bugs in a
timely manner, so that we ...
c) make the triage/bug resolution process more efficient/less painful
for everyone, as you suggest with the example of regressions, so that we ...
d) get to a state where the crushing mountain of bugs stops rising, i.e.
the rate of new bugs (unconfirmed+confirmed+resolved) doesn't outstrip
our capacity to triage them
but at least more in general
> terms I think it's important to get invalid/duplicate bugs marked as
> such to get them off the radar fairly quickly, preferably within the
> fist week from filing. So I'd engourage more people wanting to help to
> also look at the recent bugs.
>
> For regressions, it's so much easier to get them fixed if the cause
> and/or regression window is dug out early on.
>
> -Magnus
good points