BMO Reorg Phase 2

1 view
Skip to first unread message

Gervase Markham

unread,
Aug 21, 2008, 11:23:09 AM8/21/08
to
Having returned from holiday, I am instigating a period of discussion
about what further changes might usefully be made to
bugzilla.mozilla.org's product and component hierarchy. I expect this
set of changes to be far less extensive than the first set.

A wiki page tracks all the currently-suggested ideas:
https://wiki.mozilla.org/BMO_Reorg_Phase_2
If your idea isn't on there, please comment in mozilla.dev.planning to
start discussion of it. Please let me know of any bugs filed on things
to change which have not made it on there either.

Concrete proposals are everything - don't expect your idea to make it on
to the wiki page unless you make one.

Gerv

Benjamin Smedberg

unread,
Aug 22, 2008, 10:04:27 AM8/22/08
to
Gervase Markham wrote:
> Having returned from holiday, I am instigating a period of discussion
> about what further changes might usefully be made to
> bugzilla.mozilla.org's product and component hierarchy. I expect this
> set of changes to be far less extensive than the first set.

I think that if you phrase the discussion this way, you're not going to deal
with the fundamental problems in our bug tracker.

There are, as I see it, at least three major uses that a bug tracker needs
to fulfill:

A: issues (old and new!) need to be brought to the attention of the correct
people
B: the bug system needs to accurately represent the status of each issue
being tracked
C: the bug system is used to track groups of bugs relevant to another bug, a
release, a milestone, etc

We traditionally have many small components to satisfy A: we have many small
DOM and layout components because different people are responsible for
different parts of the DOM. These people don't want to get mail for bugs
they aren't actively interested in. See, for evidence:
http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/38a79a7a71e08bee?tvc=2

Having many small components makes B a nightmare. People are presented with
so many components that they can't figure out an appropriate component and
give up. I believe that this is a lot of useless taxonomy, but that it's
less important that fixing the bugzilla UI.

Let's assume, for the moment, that we don't remove any components at all:
what can/should we do to make it easier to file bugs and get them noticed by
the right people?

I: find the right component

I.A.:
The first question people get asked when filing a bug is "What product".
This misleading question means that core bugs are consitently mis-filed
because you can't file a core bug from the "Firefox" page.

Include Firefox/Toolkit/Core in the Firefox bugfiling page
Include Thunderbird/Mailnews Core/Toolkit/Core in the Thunderbird bugfiling page
etc...

I.B: Display the component description on the bugfiling page

The component titles don't (and can't) give enough information... when
somebody selects a component, we should display the component description so
they can sanity-check their choice.

I.C: All people to type keywords to search for components

The little select box for choosing a component is awful. You can't see all
of your choices. Point of amazement: there are 131 components in "Core"! We
should have a search box to make it easier to find an appropriate component.

e.g. Typing "table" in a box should come up with "Layout: Tables", and
"edit" would come up with editor stuff... the component titles and
descriptions would be displayed, so you can choose one intelligently.

I.D: Provide a default component for "I have no clue"

Be it Firefox: General or something else, it should be relatively easy for
bug filers to choose a "I don't know, please don't make me choose" component
so that experienced triagers can move it as appropriate.

II: get rid of the following fields in bugzilla:

* Version

Most bugs affect multiple versions. If it only affects particular versions,
this is easy enough to indicate in the bug description or whiteboard.

* Hardware
* OS

The vast majority of bugs are not specific to particular hardware/OS. If
it's important, we can indicate that in the bug description/whiteboard.

* Severity

Other than "blocker", this field seems to exist mainly so that people can
argue about it and change it back and forth. Let's remove it. blocker can be
a keyword if it is actionable (e.g. closes the tree, or pages IT in the
middle of the night)

--BDS

Joshua Cranmer

unread,
Aug 22, 2008, 10:24:19 AM8/22/08
to
Benjamin Smedberg wrote:
> * Severity
>
> Other than "blocker", this field seems to exist mainly so that people can
> argue about it and change it back and forth. Let's remove it. blocker can be
> a keyword if it is actionable (e.g. closes the tree, or pages IT in the
> middle of the night)

There is a second useful severity: enhancement.

David E. Ross

unread,
Aug 22, 2008, 10:35:36 AM8/22/08
to

1. Rename [Client Software > SeaMonkey > Download & File Handling] and
[Client Software > Camino > Downloading] to have the last term "File
Handling". This would be consistent with [Client Software > Firefox >
File Handling]. At least with SeaMonkey, it would also be more correct
since the component also includes uploading; see bug #451290.

2. Addons under Server Software indicates that bugs for the Addons
product relate to the server hosting Addons. Per bug #395967, a product
is needed for reporting bugs against individual addons. No this doesn't
require a component for each addon; by convention, the name of the
affected addon could be indicated in brackets at the beginning of a
bug's summary. As described in comment #9 of bug #395967, this new
product would not belong under Server Software since addons are not
servers. It would belong under either Client Software or Other.

3. The use of "Components" as the parent of "Core", "MailNews Core",
"Directory", etc is somewhat confusing. Inherent in the Bugzilla
hierarchy, "Components" is the next level below "Product".

--
David E. Ross
<http://www.rossde.com/>

Go to Mozdev at <http://www.mozdev.org/> for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications. You can access Mozdev much
more quickly than you can Mozilla Add-Ons.

Stefan

unread,
Aug 22, 2008, 11:33:36 AM8/22/08
to dev-pl...@lists.mozilla.org
> -----Original Message-----
> From: ge...@mozilla.org
> Sent: Thu, 21 Aug 2008 16:23:09 +0100
> To: dev-pl...@lists.mozilla.org
> Subject: BMO Reorg Phase 2
>
> Having returned from holiday, I am instigating a period of discussion
> about what further changes might usefully be made to
> bugzilla.mozilla.org's product and component hierarchy. I expect this
> set of changes to be far less extensive than the first set.
>
> A wiki page tracks all the currently-suggested ideas:
> https://wiki.mozilla.org/BMO_Reorg_Phase_2
> If your idea isn't on there, please comment in mozilla.dev.planning to

"Documentation: Help Viewer" is not really useful anymore - I propose we graveyard it and move all the open bugs to "SeaMonkey: Help". Or just graveyard it and then I can move bugs that are open and relevant to the SeaMonkey component. There are actually a bunch of (open) bugs in "Documentation: Help Viewer" that doesn't belong in there - I think it's a leftover from a bmo reorg a couple of years ago.

Having said that, we might also want to rename "SeaMonkey: Help" to something like "SeaMonkey: Help Documentation", since SeaMonkey currently use toolkit's help viewer (if SM would use its own viewer, I think we'd need 2 separate components anyway).

(No bugs filed)

/Stefan

____________________________________________________________
GET FREE 5GB EMAIL - Check out spam free email with many cool features!
Visit http://www.inbox.com/email to find out more!

John J. Barton

unread,
Aug 22, 2008, 11:57:22 AM8/22/08
to
Benjamin Smedberg wrote:

> I.D: Provide a default component for "I have no clue"
>
> Be it Firefox: General or something else, it should be relatively easy for
> bug filers to choose a "I don't know, please don't make me choose" component
> so that experienced triagers can move it as appropriate.

(I think Ben is on the right track)

I've filed maybe a hundred bugs. I've never found a component choice I
could figure out. I always pick "General".

jjb

stefanh

unread,
Aug 22, 2008, 12:16:57 PM8/22/08
to dev-pl...@lists.mozilla.org
Benjamin Smedberg skriver:

>
>
> II: get rid of the following fields in bugzilla:
>
> * Version
>
> Most bugs affect multiple versions. If it only affects particular versions,
> this is easy enough to indicate in the bug description or whiteboard.
>
> * Hardware
> * OS
>
> The vast majority of bugs are not specific to particular hardware/OS. If
> it's important, we can indicate that in the bug description/whiteboard.
>

I don't think the Hardware/OS field makes it more difficult for a user
to file a bug. It's filled in automatically, so the user doesn't really
have to do anything. I'd also find it quite hard to track OS-specific
bugs if this field went away.


> * Severity
>
> Other than "blocker", this field seems to exist mainly so that people can
> argue about it and change it back and forth. Let's remove it. blocker can be
> a keyword if it is actionable (e.g. closes the tree, or pages IT in the
> middle of the night)
>

This field is also prefilled, so it's nothing you have to worry about
when filing a bug. Maybe I'm too much used to it, but I find this field
quite useful - it helps me, for example, to sort out the "not so
important ones".

/Stefan

Robert Kaiser

unread,
Aug 22, 2008, 12:22:59 PM8/22/08
to
Benjamin Smedberg wrote:
> I think that if you phrase the discussion this way, you're not going to deal
> with the fundamental problems in our bug tracker.

I don't think that Gerv even intends to change how Bugzilla works in
this effort. What I think he wants to do is finishing the work of
regrouping components and products that was started with the first bmo
reorg done during the Summit.

What you discuss here sounds more like changing how the Bugzilla tool
itself is organizing/representing things, not how our particular
installation of it is being organized.

Robert Kaiser

Robert Kaiser

unread,
Aug 22, 2008, 12:25:25 PM8/22/08
to
David E. Ross wrote:
> 1. Rename [Client Software> SeaMonkey> Download& File Handling]

No. It's intended to have both in there. Most people wouldn't even
realize that "File Handling" would have something to do with a "Download
Manager" in the application. The SeaMonkey name is correct for the
SeaMonkey component.

Robert Kaiser

Robert Kaiser

unread,
Aug 22, 2008, 12:29:08 PM8/22/08
to
Stefan wrote:
> Having said that, we might also want to rename "SeaMonkey: Help" to something like "SeaMonkey: Help Documentation", since SeaMonkey currently use toolkit's help viewer (if SM would use its own viewer, I think we'd need 2 separate components anyway).

Well, I think SeaMonkey is the only remaining user of the toolkit help
viewer though - or the only one we know of. We probably need to figure
out how to deal with that.

If there are toolkit users out there that find it helpful (pun
intended), we probably should talk to them and maybe keep it in toolkit
but do some reworking, else we might want to build a reworked version in
comm-central/suite (note that those RDF files with L10n stuff in them
are e.g. a particular problem with the current code).

Robert Kaiser

Benjamin Smedberg

unread,
Aug 22, 2008, 12:36:09 PM8/22/08
to stefanh
stefanh wrote:

> I don't think the Hardware/OS field makes it more difficult for a user
> to file a bug. It's filled in automatically, so the user doesn't really
> have to do anything. I'd also find it quite hard to track OS-specific
> bugs if this field went away.

In what way would you find it hard to track? The field is currently mis-used
the vast majority of the time, since for most bugs the correct values are
All/All. So if you see a bug where the OS is "Windows 95" it could mean

1) this bug was originally reported on windows 95
2) this bug is specific to windows 95 (but not Windows XP)
3) this bug only appears on windows in general

And in most cases, it just doesn't matter anyway. If it's an OS-specific
bug, it will probably become clear during the process, and we can add
"Windows-only" or "Windows Vista only" to the status whiteboard.

> This field is also prefilled, so it's nothing you have to worry about
> when filing a bug. Maybe I'm too much used to it, but I find this field
> quite useful - it helps me, for example, to sort out the "not so
> important ones".

How do you do that? By looking for "blocker" and "critical" bugs? By weeding
out "trivial" and "enhancement"? I've seen numerous arguments that a bug
should be marked "critical" if it

Benjamin Smedberg

unread,
Aug 22, 2008, 12:43:09 PM8/22/08
to
Benjamin Smedberg wrote:

>> This field is also prefilled, so it's nothing you have to worry about
>> when filing a bug. Maybe I'm too much used to it, but I find this field
>> quite useful - it helps me, for example, to sort out the "not so
>> important ones".
>
> How do you do that? By looking for "blocker" and "critical" bugs? By weeding
> out "trivial" and "enhancement"? I've seen numerous arguments that a bug
> should be marked "critical" if it

argh, hit send before I was done.

Treating "severity" as a synonym for "important" is exactly the problem. A
bug that crashes OS/2 or Windows 95 but nowhere else is, overall, not very
important, compared with a feature or other "less critical" bugfix. We
already have a way to prioritize bugs (with P1-P5), when we want to use it,
and the severity field is poor substitute for that.

We already have keyword synonyms for most severity fields in any case:
"critical" severity == "crash" or "hang" keyword.

--BDS

David E. Ross

unread,
Aug 22, 2008, 1:22:22 PM8/22/08
to

Then it should be "Download, Upload, & File Handling". I wrote bug
#451290 against [SeaMonkey> Download & File Handling] even though it's
an uploading problem because I could find no other appropriate component
for the bug report.

Stefan

unread,
Aug 22, 2008, 1:23:00 PM8/22/08
to dev-pl...@lists.mozilla.org
Benjamin Smedberg skriver:

> stefanh wrote:
>
>
>> I don't think the Hardware/OS field makes it more difficult for a user
>> to file a bug. It's filled in automatically, so the user doesn't really
>> have to do anything. I'd also find it quite hard to track OS-specific
>> bugs if this field went away.
>>
>
> In what way would you find it hard to track? The field is currently mis-used
> the vast majority of the time, since for most bugs the correct values are
> All/All. So if you see a bug where the OS is "Windows 95" it could mean
>
> 1) this bug was originally reported on windows 95
> 2) this bug is specific to windows 95 (but not Windows XP)
> 3) this bug only appears on windows in general
>
> And in most cases, it just doesn't matter anyway. If it's an OS-specific
> bug, it will probably become clear during the process, and we can add
> "Windows-only" or "Windows Vista only" to the status whiteboard.
>
I often track mac-specific bugs. Bugs that are filed by mac users tend
in my opinion to often end up as mac-specific. This depends of the
compent, of course. But in my case, since I'm often looking for themes
or widget related issues, it's very often the case. But I guess you
could also say that I'm generally interested in bugs that are filed by
mac users (of course I then look for the most recent ones or rely on the
fact that the field isn't changed)

The field is mis-used - but if people triaging bugs changed the field
that wouldn't be a problem.


>
>> This field is also prefilled, so it's nothing you have to worry about
>> when filing a bug. Maybe I'm too much used to it, but I find this field
>> quite useful - it helps me, for example, to sort out the "not so
>> important ones".
>>
>
> How do you do that? By looking for "blocker" and "critical" bugs? By weeding
> out "trivial" and "enhancement"? I've seen numerous arguments that a bug
> should be marked "critical" if it
>

A crasher would be critical. Everyone triaging bugs should know that.
Searching for blocker/critical bugs should give me the most important
ones. Maybe the field shouldn't be editable for users?

/Stefan
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
>
>

____________________________________________________________
Receive Notifications of Incoming Messages
Easily monitor multiple email accounts & access them with a click.
Visit http://www.inbox.com/notifier and check it out!

chris hofmann

unread,
Aug 22, 2008, 1:44:12 PM8/22/08
to Benjamin Smedberg, dev-pl...@lists.mozilla.org

Benjamin Smedberg wrote:
> Benjamin Smedberg wrote:
>
>
>>> This field is also prefilled, so it's nothing you have to worry about
>>> when filing a bug. Maybe I'm too much used to it, but I find this field
>>> quite useful - it helps me, for example, to sort out the "not so
>>> important ones".
>>>
>> How do you do that? By looking for "blocker" and "critical" bugs? By weeding
>> out "trivial" and "enhancement"? I've seen numerous arguments that a bug
>> should be marked "critical" if it
>>
>
> argh, hit send before I was done.
>
> Treating "severity" as a synonym for "important" is exactly the problem. A
> bug that crashes OS/2 or Windows 95 but nowhere else is, overall, not very
> important, compared with a feature or other "less critical" bugfix. We
> already have a way to prioritize bugs (with P1-P5), when we want to use it,
> and the severity field is poor substitute for that.
>
>

yeah, "visibility level" might be a better term than "important", but
its true that "blockers" have elements of many things like:

-visibility level (how many/which kinds of users might be affected)
-criticality/severity level (when the problem hits how bad is it)
-recovery level (how easy or hard is to recover from)
-regression (is this a new problem, or has it been around a while)
-feasibility (is there a patch, or could there be a patch, in a
reasonable amount of time)
-ownership (is someone on the bug, or could there be? nob...@mozilla.org)
-...

often release managers go dumster diving for these keywords to find
interesting bugs to place on the blocker list, and the reverse where
these attributes are used to help evaluate the characteristics of a
bug. some systems that help or automate these kinds of rollups,
dissection, and triage might help things be a bit more consistent and
streamlined.

some reports that showed
visibility level=10 (wide spread)
severity level=10 (ugly)
recovery level=10 (hard)
regression=yes
feasibility=?
owned by=nobody

sounds like at great list to have lots of eyes on, and variations of
this kind of list could help to understand overall levels of quality and
assign some statistics to over time...

-chofmann


> We already have keyword synonyms for most severity fields in any case:
> "critical" severity == "crash" or "hang" keyword.
>
> --BDS

Stefan

unread,
Aug 22, 2008, 1:56:33 PM8/22/08
to dev-pl...@lists.mozilla.org
Benjamin Smedberg skriver:

> Benjamin Smedberg wrote:
>
>
>>> This field is also prefilled, so it's nothing you have to worry about
>>> when filing a bug. Maybe I'm too much used to it, but I find this field
>>> quite useful - it helps me, for example, to sort out the "not so
>>> important ones".
>>>
>> How do you do that? By looking for "blocker" and "critical" bugs? By weeding
>> out "trivial" and "enhancement"? I've seen numerous arguments that a bug
>> should be marked "critical" if it
>>
>
> argh, hit send before I was done.
>
> Treating "severity" as a synonym for "important" is exactly the problem. A
> bug that crashes OS/2 or Windows 95 but nowhere else is, overall, not very
> important, compared with a feature or other "less critical" bugfix. We
>
Combined with the OS field you'll get the importance ;) Anyway, I get
the point. You think the field opens up for debate etc and that it
doesn't reflect the actual importance. I still think they say something,
though.

/Stefan

____________________________________________________________
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!

Joshua Cranmer

unread,
Aug 22, 2008, 2:19:32 PM8/22/08
to
Benjamin Smedberg wrote:
> stefanh wrote:
>
>> I don't think the Hardware/OS field makes it more difficult for a user
>> to file a bug. It's filled in automatically, so the user doesn't really
>> have to do anything. I'd also find it quite hard to track OS-specific
>> bugs if this field went away.
>
> In what way would you find it hard to track? The field is currently mis-used
> the vast majority of the time, since for most bugs the correct values are
> All/All. So if you see a bug where the OS is "Windows 95" it could mean
>
> 1) this bug was originally reported on windows 95
> 2) this bug is specific to windows 95 (but not Windows XP)
> 3) this bug only appears on windows in general

I think there's little point to the Hardware field as there are very few
places where PPC or x86 make a difference, with the possible exception
of code not being 64-bit compatible, which doesn't really need a
Hardware field.

OS is different, though, IMO. There are many more areas where problems
may be OS-specific. It's also nice to be able to look for a specific OS
to find bugs for, since it may be more obvious from a title that a bug
is not OS-specific than if it is OS-specific.

I'm also one for being able to select "Windows" instead having to decide
whether to file as "Windows XP", "Windows Vista", etc.

Robert Kaiser

unread,
Aug 22, 2008, 2:44:01 PM8/22/08
to
David E. Ross wrote:
> On 8/22/2008 9:25 AM, Robert Kaiser wrote:
>> David E. Ross wrote:
>>> 1. Rename [Client Software> SeaMonkey> Download& File Handling]
>> No. It's intended to have both in there. Most people wouldn't even
>> realize that "File Handling" would have something to do with a "Download
>> Manager" in the application. The SeaMonkey name is correct for the
>> SeaMonkey component.
>>
>> Robert Kaiser
>
> Then it should be "Download, Upload,& File Handling".

Fix the bug about commas in component names failing in searches, and
tell me that enough reporters that are regularly doing uploads don't
know about that being "file handling" (Joe User doesn't even know he can
upload stuff with SeaMonkey!), and then come back and we can continue
this discussion. Until then, I accuse you of nitpicking.

Robert Kaiser

Stefan

unread,
Aug 22, 2008, 2:57:12 PM8/22/08
to dev-pl...@lists.mozilla.org
> -----Original Message-----
> From: ge...@mozilla.org
> Sent: Thu, 21 Aug 2008 16:23:09 +0100
> To: dev-pl...@lists.mozilla.org
> Subject: BMO Reorg Phase 2
>
> Having returned from holiday, I am instigating a period of discussion
> about what further changes might usefully be made to
> bugzilla.mozilla.org's product and component hierarchy. I expect this
> set of changes to be far less extensive than the first set.
>
> A wiki page tracks all the currently-suggested ideas:
> https://wiki.mozilla.org/BMO_Reorg_Phase_2
> If your idea isn't on there, please comment in mozilla.dev.planning to
> start discussion of it.

I now remember that I noted it in the reorg doc, and I don't really have any excuse for not yelling then. But iirc it was in a late stage, so I might have felt that it was too late. Anyway:

"Mozilla Localizations: sv / Swedish"

This is actually wrong, because the current localization is named sv-SE, so I propose to change it back to "Mozilla Localizations: sv-SE / Swedish".

/Stefan

Magnus Melin

unread,
Aug 22, 2008, 5:16:27 PM8/22/08
to

Agreed.

There are a fair amount of OS specific bugs. The amount varies a lot between
components though I guess.

-Magnus

Justin Dolske

unread,
Aug 22, 2008, 9:50:34 PM8/22/08
to
Benjamin Smedberg wrote:

> I think that if you phrase the discussion this way, you're not going to deal
> with the fundamental problems in our bug tracker.

Sure, but it doesn't have to all be tackled at the first time.

> II: get rid of the following fields in bugzilla:
>
> * Version
>
> Most bugs affect multiple versions. If it only affects particular versions,
> this is easy enough to indicate in the bug description or whiteboard.

I find this field fairly useless as-is, but it might be useful with
changes -- split it in 2, into a "last verified in version X" and "fixed
in version X" fields. [Replacing the fixedX.Y.Z keywords used now. And
you'd need a way to have 1 "fixed in" flag per branch.]

> * Hardware
> * OS
>
> The vast majority of bugs are not specific to particular hardware/OS. If
> it's important, we can indicate that in the bug description/whiteboard.

Yeah. Back when the UI got cleanup up in late 2006 (?), I suggested
moving towards a single "Platform" field. Maybe we could do that (with
default = "All") as an intermediate step towards getting rid of it
entirely. Or get rid of it in some but not all components?

Justin

David E. Ross

unread,
Aug 24, 2008, 7:55:03 PM8/24/08
to
On 8/21/2008 8:23 AM, Gervase Markham wrote [in part]:
>
> A wiki page tracks all the currently-suggested ideas:
> https://wiki.mozilla.org/BMO_Reorg_Phase_2
> If your idea isn't on there, please comment in mozilla.dev.planning to
> start discussion of it. Please let me know of any bugs filed on things
> to change which have not made it on there either.
>

I don't seem to be able to navigate to the Wiki page from
<http://www.mozilla.org/> or even from
<https://wiki.mozilla.org/Main_Page>.

Gervase Markham

unread,
Aug 25, 2008, 7:05:51 AM8/25/08
to
David E. Ross wrote:
> 2. Addons under Server Software indicates that bugs for the Addons
> product relate to the server hosting Addons. Per bug #395967, a product
> is needed for reporting bugs against individual addons. No this doesn't
> require a component for each addon; by convention, the name of the
> affected addon could be indicated in brackets at the beginning of a
> bug's summary. As described in comment #9 of bug #395967, this new
> product would not belong under Server Software since addons are not
> servers. It would belong under either Client Software or Other.

This exact function, in this exact fashion, is fulfilled by the
"Add-ons" component of the addons.mozilla.org product.

> 3. The use of "Components" as the parent of "Core", "MailNews Core",
> "Directory", etc is somewhat confusing. Inherent in the Bugzilla
> hierarchy, "Components" is the next level below "Product".

I see the problem; care to propose an alternative?

Gerv

Gervase Markham

unread,
Aug 25, 2008, 7:08:06 AM8/25/08
to
Stefan wrote:
> "Documentation: Help Viewer" is not really useful anymore
<snip>

Just to be clear: sentences with "might" or "or" in them are not going
to result in any changes to the list of potential changes. When you have
discussed your problem and have consensus, you need to make a concrete,
specific proposal, and make sure that people who own that area (e.g.
KaiRo) have commented to say "Yes, I agree".

Gerv

Gervase Markham

unread,
Aug 25, 2008, 7:08:55 AM8/25/08
to
Stefan wrote:
> "Mozilla Localizations: sv / Swedish"
> -> "Mozilla Localizations: sv-SE / Swedish".

Are you on the Swedish l10n team? If not, can you get consent from one
of them?

Thanks,

Gerv

Gervase Markham

unread,
Aug 25, 2008, 7:09:32 AM8/25/08
to
David E. Ross wrote:
> I don't seem to be able to navigate to the Wiki page from
> <http://www.mozilla.org/> or even from
> <https://wiki.mozilla.org/Main_Page>.

No, it's not linked from anywhere - just the blogpost and newsgroup
post. Feel free to add links in places you think need them.

Gerv

Gervase Markham

unread,
Aug 25, 2008, 7:23:21 AM8/25/08
to
And now, an off-topic response:

Benjamin Smedberg wrote:
> I: find the right component
>
> I.A.:
> The first question people get asked when filing a bug is "What product".
> This misleading question means that core bugs are consitently mis-filed
> because you can't file a core bug from the "Firefox" page.
>
> Include Firefox/Toolkit/Core in the Firefox bugfiling page
> Include Thunderbird/Mailnews Core/Toolkit/Core in the Thunderbird bugfiling page
> etc...

An alternative solution would be to stop asking the Component question
completely.

We are currently getting 500 bugs a week in Firefox, Thunderbird, Core
and Toolkit (of which 177 or so were filed using the Bugzilla Helper).

If all or most of those bugs went into either Firefox/General or
Thunderbird/General and had to be triaged out of there by the QA team,
would it be much more effort overall than the current triage process
where we have to monitor every component for badly-filed bugs, as well
as sorting those that end up in the General components anyway?

Now that we have the mega force that is Bug Days, and a lively QA
community, we should consult them on whether switching to this model
makes more sense.

> II: get rid of the following fields in bugzilla:
>
> * Version
>
> Most bugs affect multiple versions. If it only affects particular versions,
> this is easy enough to indicate in the bug description or whiteboard.

My understanding was that the convention is that Version is the
earliest-affected version (and Target Milestone, once the bug is fixed,
is the first non-affected version). But this fails to a certain extent
in the presence of multiple branches. But then again, a lot of Bugzilla
doesn't cope well with multiple branches. There have been proposals to
fix this, but getting the data model and the UI right is Hard.

> * Hardware
> * OS
>
> The vast majority of bugs are not specific to particular hardware/OS. If
> it's important, we can indicate that in the bug description/whiteboard.

I think people still find OS useful, although we could make an argument
for trimming down the choices. I agree Hardware has probably outlived
its usefulness for us.

> * Severity
>
> Other than "blocker", this field seems to exist mainly so that people can
> argue about it and change it back and forth. Let's remove it. blocker can be
> a keyword if it is actionable (e.g. closes the tree, or pages IT in the
> middle of the night)

Do individual developers use this field for prioritizing their work?

Gerv

Gervase Markham

unread,
Aug 25, 2008, 7:26:26 AM8/25/08
to
Benjamin Smedberg wrote:
> I think that if you phrase the discussion this way, you're not going to deal
> with the fundamental problems in our bug tracker.

First, an on-topic reply:

Figuring out how to fix the problems you outline is a far larger task
than I am attempting here. They may also be more important, but I want
to finish (for some value of "finish") one job before starting another.

However, you are absolutely correct that there's a mismatch between
bringing issues to the attention of the right people (made easier by
lots of small components) and filing issues in the right place (made
more difficult by lots of small components).

My general suggestion for this is to fix the bug-filing process to hide
the complexity from the bug filer. There have been attempts to make
filing easier in the past (e.g. Bugzilla Helper) but we need to go a
stage further. I believe KDE have a nice bug-filing wizard, and
launchpad has a similar process also.

Gerv

Serge Gautherie

unread,
Aug 25, 2008, 8:08:49 AM8/25/08
to
Gervase Markham wrote:

>> * Version


>
> My understanding was that the convention is that Version is the earliest-affected version

I think it's rather the latest-affected: usually Trunk, else 1.9.0 and
going backward.

Or, it may be the version the reporter was using: mostly for people not
using Trunk (nightlies)...

> (and Target Milestone, once the bug is fixed, is the first non-affected version).

Yes; though it's often not filed.

Boris Zbarsky

unread,
Aug 25, 2008, 8:41:23 AM8/25/08
to
Gervase Markham wrote:
> If all or most of those bugs went into either Firefox/General or
> Thunderbird/General and had to be triaged out of there by the QA team,
> would it be much more effort overall than the current triage process
> where we have to monitor every component for badly-filed bugs, as well
> as sorting those that end up in the General components anyway?

Possibly not. I think 50 bugs per person per day for triage is a pretty
doable number (this is based on my memories of when I was doing just
this sort of thing), so if we have enough people working on this and
they don't overlap too much, it could work.

But we need to make a point of moving the bugs, not just commenting on
them. Even if QA think the bug needs more info, if they can guess at a
component they should move it there, I would think. Right now I see a
lot of bugs left in Firefox:General that obviously don't belong there.

-Boris

Joshua Cranmer

unread,
Aug 25, 2008, 9:44:28 AM8/25/08
to
Gervase Markham wrote:
> If all or most of those bugs went into either Firefox/General or
> Thunderbird/General and had to be triaged out of there by the QA team,
> would it be much more effort overall than the current triage process
> where we have to monitor every component for badly-filed bugs, as well
> as sorting those that end up in the General components anyway?

There are often bugs which do fall into the general component because it
isn't under the scope of any others. If we changed the concept of the
general to an untriaged component, it makes keeping these bugs live
difficult.

Also, it's often very hard (at least for Thunderbird) to figure out
where the bug belongs. "Copying fails" could refer to either an IMAP
problem (Networking: IMAP), a UI disconnect (probably MWFE), a local
folders problem (Database or Backend), or some other as-yet undetermined
problem. It took one reply for me to determine that it was an
IMAP-related problem, and another reply to determine that something
borked itself in the middle. So where does it belong?

> My understanding was that the convention is that Version is the
> earliest-affected version (and Target Milestone, once the bug is fixed,
> is the first non-affected version). But this fails to a certain extent
> in the presence of multiple branches. But then again, a lot of Bugzilla
> doesn't cope well with multiple branches. There have been proposals to
> fix this, but getting the data model and the UI right is Hard.

Two proposals (doable with the status quo):
1. Autofill version from the build identifier.
2. Set version to "Trunk" if it's an enhancement.

> I think people still find OS useful, although we could make an argument
> for trimming down the choices. I agree Hardware has probably outlived
> its usefulness for us.

+1

> Do individual developers use this field for prioritizing their work?

I categorize mostly on "enhancement" and "normal," occasionally
"critical"/"blocker" (i.e. a regression seriously hampering widely-used
features). "trivial" seems useless to me, and I have bumped
"minor"/"major" before. I don't think you'll get a lot of complaints if
you remove "trivial" and perhaps "blocker."

David E. Ross

unread,
Aug 25, 2008, 10:25:52 AM8/25/08
to
On 8/25/2008 4:05 AM, Gervase Markham wrote:
> David E. Ross wrote:
>> 2. Addons under Server Software indicates that bugs for the Addons
>> product relate to the server hosting Addons. Per bug #395967, a product
>> is needed for reporting bugs against individual addons. No this doesn't
>> require a component for each addon; by convention, the name of the
>> affected addon could be indicated in brackets at the beginning of a
>> bug's summary. As described in comment #9 of bug #395967, this new
>> product would not belong under Server Software since addons are not
>> servers. It would belong under either Client Software or Other.
>
> This exact function, in this exact fashion, is fulfilled by the
> "Add-ons" component of the addons.mozilla.org product.

So something like Mnenhy (for Firefox and SeaMonkey) or Signature Switch
(for Thunderbird) -- both addons -- fall under Server Software although
they actually having nothing to do with servers? Will this not make
reporting bugs against extensions confusing?


>> 3. The use of "Components" as the parent of "Core", "MailNews Core",
>> "Directory", etc is somewhat confusing. Inherent in the Bugzilla
>> hierarchy, "Components" is the next level below "Product".
>
> I see the problem; care to propose an alternative?

Make "Elements" the parent of "Core", etc. I worked on a large software
system for operating a variety of unmanned space satellites. The
hierarchy was something like [System > Configuration Item > Element >
Computer Program Component > Computer Program]. Since it was more than
20 years ago, I might have these in the wrong order.

Stefan

unread,
Aug 25, 2008, 10:29:15 AM8/25/08
to dev-pl...@lists.mozilla.org

Well, your original post said "If your idea isn't on there, please comment in mozilla.dev.planning to
start discussion of it.", so I expect "people who own that area" to comment...

Robert Kaiser

unread,
Aug 25, 2008, 10:45:25 AM8/25/08
to
Gervase Markham wrote:
> We are currently getting 500 bugs a week in Firefox, Thunderbird, Core
> and Toolkit (of which 177 or so were filed using the Bugzilla Helper).

How many of those were filed by experienced people who can guess
components in many cases (yes, I know, we always have difficult cases)?
And how many are filed by people who would not have any other clue than
"General"?

Robert Kaiser

Gervase Markham

unread,
Aug 26, 2008, 5:35:33 AM8/26/08
to
Joshua Cranmer wrote:
> There are often bugs which do fall into the general component because it
> isn't under the scope of any others. If we changed the concept of the
> general to an untriaged component, it makes keeping these bugs live
> difficult.

No problem - we can have a "Triage" component. Or perhaps another word
that more people know. "ToBeFiled"?

> Also, it's often very hard (at least for Thunderbird) to figure out
> where the bug belongs.

Well, if that's true, what chance does the poor reporter have?

> "Copying fails" could refer to either an IMAP
> problem (Networking: IMAP), a UI disconnect (probably MWFE), a local
> folders problem (Database or Backend), or some other as-yet undetermined
> problem. It took one reply for me to determine that it was an
> IMAP-related problem, and another reply to determine that something
> borked itself in the middle. So where does it belong?

Well, you keep it in the triage component until you find out :-)

> Two proposals (doable with the status quo):
> 1. Autofill version from the build identifier.

That might lead people to erroneously conclude that it was not present
in earlier versions.

There are at least three possible semantics for version:

1) Earliest version affected
2) Latest version affected
3) Version used by filer of bug

One good step would be to pick one and tell everyone to use it.

> 2. Set version to "Trunk" if it's an enhancement.

That would be sensible.

Gerv

Gervase Markham

unread,
Aug 26, 2008, 5:35:54 AM8/26/08
to
Robert Kaiser wrote:
> Gervase Markham wrote:
>> We are currently getting 500 bugs a week in Firefox, Thunderbird, Core
>> and Toolkit (of which 177 or so were filed using the Bugzilla Helper).
>
> How many of those were filed by experienced people who can guess
> components in many cases (yes, I know, we always have difficult cases)?

How would you like me to go about determining that number? :-)

Gerv

Gervase Markham

unread,
Aug 26, 2008, 5:37:36 AM8/26/08
to
David E. Ross wrote:
> So something like Mnenhy (for Firefox and SeaMonkey) or Signature Switch
> (for Thunderbird) -- both addons -- fall under Server Software although
> they actually having nothing to do with servers? Will this not make
> reporting bugs against extensions confusing?

I may be wrong, but my understanding is that Bugzilla is not supposed to
be the primary bug-tracking application for add-ons. We have this
component because sometimes there are bugs in popular add-ons (e.g.
"doesn't work with FF3") that we want to track. But day-to-day problems
should go to the developer.

>>> 3. The use of "Components" as the parent of "Core", "MailNews Core",
>>> "Directory", etc is somewhat confusing. Inherent in the Bugzilla
>>> hierarchy, "Components" is the next level below "Product".
>> I see the problem; care to propose an alternative?
>
> Make "Elements" the parent of "Core", etc.

I'm not sure "Elements" is any more understandable than "Components".

Gerv

Gervase Markham

unread,
Aug 26, 2008, 5:37:59 AM8/26/08
to
Stefan wrote:
> Well, your original post said "If your idea isn't on there, please comment in mozilla.dev.planning to
> start discussion of it.", so I expect "people who own that area" to comment...

Sure. It wasn't a criticism, just a clarification.

Gerv

David E. Ross

unread,
Aug 26, 2008, 10:42:14 AM8/26/08
to
On 8/26/2008 2:37 AM, Gervase Markham wrote:
> David E. Ross wrote:
>> So something like Mnenhy (for Firefox and SeaMonkey) or Signature Switch
>> (for Thunderbird) -- both addons -- fall under Server Software although
>> they actually having nothing to do with servers? Will this not make
>> reporting bugs against extensions confusing?
>
> I may be wrong, but my understanding is that Bugzilla is not supposed to
> be the primary bug-tracking application for add-ons. We have this
> component because sometimes there are bugs in popular add-ons (e.g.
> "doesn't work with FF3") that we want to track. But day-to-day problems
> should go to the developer.

From recent comments in bug #395967, there appears to be no interest in
having any kind of bug-reporting for addons. In other words, what works
for Mozdev will not work for Addons. With some addons, however,
reporting a problem directly to the developers is equivalent to
communicating with a black hole. :(


>>>> 3. The use of "Components" as the parent of "Core", "MailNews Core",
>>>> "Directory", etc is somewhat confusing. Inherent in the Bugzilla
>>>> hierarchy, "Components" is the next level below "Product".
>>> I see the problem; care to propose an alternative?
>> Make "Elements" the parent of "Core", etc.
>
> I'm not sure "Elements" is any more understandable than "Components".

It's not. However, "Element" is not used by Bugzilla in a different
context while "Component" is used by Bugzilla to indicate the
hierarchical level just below Product. Thus, while not more
understandable, "Elements" would be less confusing. (Think of the "Core
component of Components" versus the "Core component of Elements".)

As an alternative, how about "Kernels"?

Mike Beltzner

unread,
Aug 26, 2008, 10:36:54 AM8/26/08
to Gervase Markham, dev-pl...@lists.mozilla.org
On 25-Aug-08, at 7:26 AM, Gervase Markham wrote:

> Benjamin Smedberg wrote:
>> I think that if you phrase the discussion this way, you're not
>> going to deal
>> with the fundamental problems in our bug tracker.
>
> First, an on-topic reply:
>
> Figuring out how to fix the problems you outline is a far larger task
> than I am attempting here. They may also be more important, but I want
> to finish (for some value of "finish") one job before starting
> another.

I don't know that it is. Ben was pretty careful to talk about how we
could make things better in the context of a Bugzilla component
reorganization, correctly limiting his scope to things that did *not*
require new UI to be built into Bugzilla. While I'm sure he'd love
multiple version targets, etc, etc, I noted that he refrained from
suggesting that much, and talked about what fields are useful and not
so useful.

> However, you are absolutely correct that there's a mismatch between
> bringing issues to the attention of the right people (made easier by
> lots of small components) and filing issues in the right place (made
> more difficult by lots of small components).

Perhaps I'm dreaming, but I would love to see a resurgence in the
importance and value of the contributor known as the "triager". This
is a person who looks through UNCO and "General" bugs and tries to
move them along in the right direction. The work queue is easy to set
up (we can put those queries on the front bugzilla page) and it's a
great way to get involved with the project.


> My general suggestion for this is to fix the bug-filing process to
> hide
> the complexity from the bug filer. There have been attempts to make
> filing easier in the past (e.g. Bugzilla Helper) but we need to go a
> stage further. I believe KDE have a nice bug-filing wizard, and
> launchpad has a similar process also.

This would be a great idea, and the Bugzilla Helper can probably be
easily tweaked. Another good way is to reduce the complexity by, as
Ben proposed, removing options that aren't really helpful when
tracking and managing bugs. Yet another way is re-ordering the entries
in drop downs so that the defaults will "just work" (ie: "untriaged"
at the top, "unspecified" for hardware) and can be refined by users
that know how.

cheers,
mike

David Ascher

unread,
Aug 26, 2008, 12:03:38 PM8/26/08
to Gervase Markham, dev-pl...@lists.mozilla.org
Gervase Markham wrote:
>
> There are at least three possible semantics for version:
>
> 1) Earliest version affected
> 2) Latest version affected
> 3) Version used by filer of bug
>
> One good step would be to pick one and tell everyone to use it.
>

The only one that makes sense to me is 3), which is trivial for the
reporter, and very useful to the developer. 1) and 2) are basically
impossible for anyone to find out in a finite amount of time -- they
would be useful to know in theory, but not if they're not filled in
correctly, which is way, way too hard for pretty much everyone.

I'd very much like for us to pick 3)...

--david

Mike Shaver

unread,
Aug 26, 2008, 4:13:25 PM8/26/08
to David Ascher, dev-pl...@lists.mozilla.org, Gervase Markham
On Tue, Aug 26, 2008 at 9:03 AM, David Ascher
<das...@mozillamessaging.com> wrote:

> Gervase Markham wrote:
>>
>> There are at least three possible semantics for version:
>>
>> 1) Earliest version affected
>> 2) Latest version affected
>> 3) Version used by filer of bug
>>
>> One good step would be to pick one and tell everyone to use it.
>>
>
> The only one that makes sense to me is 3), which is trivial for the
> reporter, and very useful to the developer. 1) and 2) are basically
> impossible for anyone to find out in a finite amount of time -- they
> would be useful to know in theory, but not if they're not filled in
> correctly, which is way, way too hard for pretty much everyone.
>
> I'd very much like for us to pick 3)...

What David said, yes.

Mike

Daniel Veditz

unread,
Aug 26, 2008, 4:42:38 PM8/26/08
to Justin Dolske
Justin Dolske wrote:
> I find this field fairly useless as-is, but it might be useful with
> changes -- split it in 2, into a "last verified in version X" and "fixed
> in version X" fields. [Replacing the fixedX.Y.Z keywords used now. And
> you'd need a way to have 1 "fixed in" flag per branch.]

https://bugzilla.mozilla.org/show_bug.cgi?id=336790 is pretty much that,
WONTFIXed by the bugzilla-powers-that-be in favor of bug cloning :-(

Gavin Sharp

unread,
Aug 26, 2008, 6:44:56 PM8/26/08
to David E. Ross, dev-pl...@lists.mozilla.org
On Tue, Aug 26, 2008 at 10:42 AM, David E. Ross <nob...@nowhere.not> wrote:
> >From recent comments in bug #395967, there appears to be no interest in
> having any kind of bug-reporting for addons.

...in the Bugzilla install at bugzilla.mozilla.org.

> In other words, what works for Mozdev will not work for Addons.

I'm not sure what this means. Mozdev works if addon authors want to
use it. As far as I can tell, there hasn't been a large demand from
addon authors for a b.m.o component they can use to track their bugs,
and Mozdev's existence surely has something to do with that.

> With some addons, however, reporting a problem directly to the developers
> is equivalent to communicating with a black hole. :(

Why would you expect an Addons component on b.m.o to improve that
situation? If an extension developer isn't responsive to feedback I
don't see how adding another method of submitting feedback will help.
It might help extension users consolidate feedback and discussion, but
that's not what Bugzilla is meant for.

Gavin

Gervase Markham

unread,
Aug 27, 2008, 5:24:11 AM8/27/08
to
Mike Beltzner wrote:
> On 25-Aug-08, at 7:26 AM, Gervase Markham wrote:
>
>> Benjamin Smedberg wrote:
>>> I think that if you phrase the discussion this way, you're not going
>>> to deal
>>> with the fundamental problems in our bug tracker.
>>
>> First, an on-topic reply:
>>
>> Figuring out how to fix the problems you outline is a far larger task
>> than I am attempting here. They may also be more important, but I want
>> to finish (for some value of "finish") one job before starting another.
>
> I don't know that it is.

Well OK, whatever :-) I'm happy to have the discussion, whether we could
it as related to or unrelated to the reorg.

> Perhaps I'm dreaming, but I would love to see a resurgence in the
> importance and value of the contributor known as the "triager". This is
> a person who looks through UNCO and "General" bugs and tries to move
> them along in the right direction. The work queue is easy to set up (we
> can put those queries on the front bugzilla page) and it's a great way
> to get involved with the project.

I think we may be converging on this truth.

> This would be a great idea, and the Bugzilla Helper can probably be
> easily tweaked. Another good way is to reduce the complexity by, as Ben
> proposed, removing options that aren't really helpful when tracking and
> managing bugs.

Removing entirely? Or removing from the filing process?

Gerv

Gervase Markham

unread,
Aug 27, 2008, 5:27:52 AM8/27/08
to
David E. Ross wrote:
> From recent comments in bug #395967,

(I'm rather surprised no-one thought to CC me on that bug.)

> there appears to be no interest in
> having any kind of bug-reporting for addons.

Rather, there appears to be no interest in having mozilla.org host a
bug-reporting system for individual addons. That's not the same thing.

> In other words, what works
> for Mozdev will not work for Addons. With some addons, however,
> reporting a problem directly to the developers is equivalent to
> communicating with a black hole. :(

Then putting the problem into bugzilla.mozilla.org is unlikely to have
any different effect.

> As an alternative, how about "Kernels"?

That definitely has other, confusing connotations. :-(

Gerv

Simon Paquet

unread,
Aug 27, 2008, 5:57:26 AM8/27/08
to

I'd very much like us to abandon that field all together. It's
misused or misfiled for over 95% of all the bug reports that I triage.
So in essence it's totally useless.

Simon

--
Thunderbird/Calendar Localization (L10n) Coordinator
Calendar website maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar

Benjamin Smedberg

unread,
Aug 27, 2008, 7:48:49 AM8/27/08
to
Gervase Markham wrote:

>> This would be a great idea, and the Bugzilla Helper can probably be
>> easily tweaked. Another good way is to reduce the complexity by, as Ben
>> proposed, removing options that aren't really helpful when tracking and
>> managing bugs.
>
> Removing entirely? Or removing from the filing process?

I believe the three fields I proposed should be removed entirely.

--BDS

Max Kanat-Alexander

unread,
Aug 28, 2008, 11:24:00 PM8/28/08
to
Hey Folks. For those who don't know, I'm mkanat from the Bugzilla
Project, but Google Groups won't let me send from that email address
for some unfathomable reason (even though it's linked to this Google
Account).

All of the things that are being discussed in this thread--the
removal of fields, creating a simpler bug entry process, dealing with
branches--these are all things that we have discussed and planned
about extensively within the Project. In addition to the fact that for
years I answered vast numbers of mails on the support-bugzilla mailing
list, I personally do Bugzilla consulting for a living (the Mozilla
Corporation being one of my clients), and I have seen these problems
and discussed them broadly with possibly hundreds of organizations.

The Bugzilla developers are almost always available on IRC, in
#mozwebtools. In addition, I could probably be personally available to
come into the Mountain View office and discuss solutions or make
suggestions.

Granted, Bugzilla is not a Mozilla-only system--it's used by
thousands of organizations around the world. But we *are* very close
as organizations, and if you want to come to us with questions about
these things, please do. I doubt we'd be open to authoritarian
instructions on how we should proceed with the Project, but we *would*
be very open to a statement like, "Hey, here's a real problem that we
have, backed up by evidence. We thought about solving it this way,
what have you guys thought about?"

As a developer, I'm really opposed to duplication of effort. I think
that in many cases, before having a long discussion about "How can we
extensively customize bugzilla.mozilla.org to solve our specific
problems," it would be valuable to come to us, the Bugzilla Project,
and ask "Do you guys have any plans or thoughts about this? When is
the next release coming out? Do you need any help?" We have lots of
thoughts and ideas about all of these problems, based on very broad
experience, and I'm sure we'd be happy to contribute our thoughts.

-Max

Max Kanat-Alexander

unread,
Aug 28, 2008, 11:26:24 PM8/28/08
to
On Aug 26, 1:42 pm, Daniel Veditz <dved...@mozilla.com> wrote:
> https://bugzilla.mozilla.org/show_bug.cgi?id=336790is pretty much that,
> WONTFIXed by thebugzilla-powers-that-be in favor of bug cloning :-(

Not at all "in favor of bug cloning." There's an entire
specification here:

https://bugzilla.mozilla.org/attachment.cgi?id=304328

And that's attached to this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=bz-branch

-Max

Clint Talbert

unread,
Aug 29, 2008, 1:46:36 PM8/29/08
to
Boris Zbarsky wrote:
> Gervase Markham wrote:
>> If all or most of those bugs went into either Firefox/General or
>> Thunderbird/General and had to be triaged out of there by the QA team,
>> would it be much more effort overall than the current triage process
>> where we have to monitor every component for badly-filed bugs, as well
>> as sorting those that end up in the General components anyway?
>
> Possibly not. I think 50 bugs per person per day for triage is a pretty
> doable number (this is based on my memories of when I was doing just
> this sort of thing), so if we have enough people working on this and
> they don't overlap too much, it could work.
>
I disagree. QA does a fair amount of triage already. And still bugs are
languishing far longer than they need to. I think that this is going to
complicate the issue because even bugs that would have been filed in the
correct places would then all be filed in the "ToBeFiled" component.

Furthermore, simply having a "ToBeFiled" component would further
dichotomize the work, almost codifying the triage as a QA role, which I
don't think is going to scale. QA & the community already do triage on
many of the components. And when a bug is properly filed, or even
sometimes in the "general" component, folks from the development
community will also help triage them. I think we will lose that
versatility with a "ToBeFiled" component as people will think "It's not
my job to triage bugs". And we'll just get further behind.

Furthermore, I think the 500 new bugs/week is not a valid measuring
stick. There may be only 500 *new* bugs, but there are hundreds more
bug comment messages that must also all be read, and must also all be
dealt with in some way (by someone, not always qa, but qa still gets all
those mails too). QA is also solely responsible for triaging the
incoming Hendrix and crashreporter feedback as well, so I think the
problem of "things needing triage" is something we deal with on a far
larger scale than you are anticipating.

Any way we can improve the process for managing the incoming deluge of
mail and the triage of those bugs would definitely be a worthy goal and
an improvement over the current state. I'm just not convinced this
proposal will achieve that goal.

Clint

Boris Zbarsky

unread,
Aug 29, 2008, 2:17:30 PM8/29/08
to
Clint Talbert wrote:
> I disagree. QA does a fair amount of triage already. And still bugs are
> languishing far longer than they need to.

OK. Why? That is, what is preventing the bugs either being reassigned
to the right component or having someone cced who would be able to
further direct them? I was under the impression that we were just in a
situation where no one in particular feels responsible for making sure
the bug gets out of Firefox:General, and if that impression was wrong
I'd really like it to be corrected.

> Furthermore, simply having a "ToBeFiled" component would further
> dichotomize the work, almost codifying the triage as a QA role, which I
> don't think is going to scale.

Why exactly would this codify the triage as a QA role?

Triage basically needs to be multi-pass, imo, given the volume of
incoming bugs. Incremental movement of the bug closer to the right
place, where someone who might be able to better tell where it belongs
will see it, is the way to go. I'm not sure why this has to be
something QA does; in the past it's worked reasonably (though at about
2x fewer bugs filed daily, but also with fewer people available, I
think) with just community involvement.

> QA & the community already do triage on
> many of the components. And when a bug is properly filed, or even
> sometimes in the "general" component, folks from the development
> community will also help triage them.

Sounds like the way it should work, yes.

> I think we will lose that
> versatility with a "ToBeFiled" component as people will think "It's not
> my job to triage bugs".

It's everyone's job to triage some subset of bugs, ideally. The only
question is what subset...

> Furthermore, I think the 500 new bugs/week is not a valid measuring
> stick. There may be only 500 *new* bugs, but there are hundreds more
> bug comment messages that must also all be read, and must also all be
> dealt with in some way (by someone, not always qa, but qa still gets all
> those mails too).

I think we should make a clear separation here between the pool of
triagers and "QA" in the sense you use it (I assume you mean the Mozilla
Corporation QA team? Or something else?).

The point of a ToBeFiled component would be to make it clear which bugs
seriously need directing somewhere useful. Perhaps Firefox:General
fills that need now, but the idea would have to be that bugs must not
stay in ToBeFiled any longer than absolutely necessary (ideally measured
in days, or a most a week or two, for asking the reporter any needed
questions).

> Any way we can improve the process for managing the incoming deluge of
> mail and the triage of those bugs would definitely be a worthy goal and
> an improvement over the current state. I'm just not convinced this
> proposal will achieve that goal.

I think the goal of this proposal is to make it clearer which bugs need
initial direction and which don't, and to make it more likely that bugs
find their way to the right people. I seriously doubt this proposal
will do anything about the amount of bugmail, and if that's being a
serious problem we probably need some other solution for that.

-Boris

Zack Weinberg

unread,
Aug 29, 2008, 3:51:36 PM8/29/08
to dev-pl...@lists.mozilla.org
Clint Talbert <ctal...@mozilla.com> wrote:
> [...] having a "ToBeFiled" component would further
> dichotomize the work, almost codifying the triage as a QA role, which
> I don't think is going to scale. QA & the community already do
> triage on many of the components. And when a bug is properly filed,
> or even sometimes in the "general" component, folks from the
> development community will also help triage them. I think we will
> lose that versatility with a "ToBeFiled" component as people will
> think "It's not my job to triage bugs". And we'll just get further
> behind.

Okay, but I want to raise a couple of counterpoints. First off, I, a
developer, frequently have trouble figuring out which component I ought
to file a bug under, especially when it's not in one of the areas I
work on - which is when it's most important for me to get it right, so
that it comes to the attention of people who do work on that area. It
doesn't help that, for any given bug, I might be supposed to file it
under Firefox or under Core, *each of which* has a dauntingly long list
that you have to scroll through via a five-line selection box. (I was
hoping that the 3.2 upgrade would at least give me a bigger box, but
it didn't; showing the descriptions is nice but often the descriptions
are just as cryptic to me as the names themselves.)

I happened to be complaining about this last night and my SO, who is a
web designer, said that she'd completely given up on reporting bugs to
us because she had *no idea* what product and component to select, and
the new-bug form gave the impression that if you didn't get that right
you might as well not bother filing the bug at all! -- She now has me
proxy bug reports for her, which is fine and all but doesn't scale. :)
And if someone who already knows HTML from CSS from JavaScript and the
difference between Firefox and Gecko can't figure out how to label her
bug reports, how can we possibly expect less informed users to?

So I think the user-facing problem -- the product+component space is too
big and daunting -- is more serious than the possibility that QA won't
scale to handle increased triage responsibilities. If MozCo needs to
hire some (more?) people whose entire job is to triage bugs, well, I
have the impression there's room in the budget for that. :)

Now, the component list isn't the only daunting thing about the new-bug
form. I'm looking at it now, and to get to the important part -- the
description-of-bug box -- I have to scroll past an entire screenful of
form fields. And I have a huge monitor. And I know that most of the
time I can leave all those fields blank. The "bugzilla helper" is
even worse; the first thing you see is a giant confusing table of
already-filed bugs. I appreciate the attempt to reduce the number of
dupes but I'd bet a dollar that lots of users see that and give up
without even reading it!

Oh, and halfway down the bugzilla helper it tells you to report broken
websites a totally different way. It's good that we have a guided
wizard built into firefox for that - but it's *very bad* to let someone
get halfway down the page before telling them, no, wait, stop, do
something totally different! It's also bad to demand that the user go
try the latest development version before they do anything else, and
for the first thing they see when they open the wizard (presumably
first time only, but still) to be a minuscule box containing over a
thousand words of legalese.

I think we could make life easier for both users and QA by doing some
serious user interface redesign on the new bug forms. I'm imagining a
directed question-and-answer session with no more than seven (plus or
minus two) options at each stage, eventually leading up to one or two
freeform entry boxes. The goal of this would be to do a rough-cut
categorization that makes less work for human triagers, and at the same
time tries to get enough information out of the user that we don't need
to go back for more. It should be clear to people unfamiliar with the
terms, but not insulting to experienced users; I think if we do it
right it would be easier for *everyone* than the current form.

For developers it might be good to have a special mode for when you're
filing a bug to describe a specific chunk of work that's already
planned. This could do things like deduce the correct component and
suggest reviewers/cc: subscribers from file names or bug numbers
mentioned in the description, or even in the patch that you're
attaching as you file the bug.

> Furthermore, I think the 500 new bugs/week is not a valid measuring
> stick. There may be only 500 *new* bugs, but there are hundreds more
> bug comment messages that must also all be read, and must also all be
> dealt with in some way (by someone, not always qa, but qa still gets
> all those mails too).

This is getting pretty far offtopic, but I'd also like to bring up a
pet peeve of mine: I don't think we should *ever* tell people to stop
commenting on a bug. I do realize that when there are widely-cc:ed,
widely-commented-on, long-standing, not-gonna-be-fixed-soon bugs, it's
no fun to be on the receiving end of all that mail, and the "me too"s
can obscure any actual technical discussion that might get the bug
solved, but too often I see that turning into hostility to users. A
'leave us alone' response to a 'hey this is still a problem for me'
comment is a great way to ensure that that person never reports a
bug again.

I think there *ought* to be a way for a bug to host a deeply technical
conversation about how to fix it and a long train of "me too"s *at the
same time*, but I don't have any great ideas, probably because I read
too fast for it to be a serious problem for me. :-/

zw

Tim Riley

unread,
Aug 29, 2008, 4:31:22 PM8/29/08
to Gervase Markham
Gervase Markham wrote:

>
> Now that we have the mega force that is Bug Days, and a lively QA
> community, we should consult them on whether switching to this model
> makes more sense.
>

Wow, Bug Day mega force! I'd like to see that huge army of QA community
members! ;) The reality is that they do great work on verifying bug
fixed, confirming bugs, adding STRs, identifying regression ranges,
helping with qawanted. But this only adds up to a few people-*days*
worth of work per week. Not the maybe 10 people-*weeks* worth of effort
needed just to keep up with the hundreds incoming bugs per week.

The bottom line is: There is no easy way to simply throw people at this
without dramatically impacting other equally as important activities
like adding STRs, testing features, etc.

This may sound fatalistic. I do not mean that. I think we can improve
the situation by setting up the right teams (dev, QA, and support?) or
cycling people through the task of reviewing incoming bugs like we do
for sheriffs and tiger team testing.

--Tim

Clint Talbert

unread,
Aug 29, 2008, 5:33:37 PM8/29/08
to
Boris Zbarsky wrote:
> Clint Talbert wrote:
>> I disagree. QA does a fair amount of triage already. And still bugs
>> are languishing far longer than they need to.
>
> OK. Why? That is, what is preventing the bugs either being reassigned
> to the right component or having someone cced who would be able to
> further direct them? I was under the impression that we were just in a
> situation where no one in particular feels responsible for making sure
> the bug gets out of Firefox:General, and if that impression was wrong
> I'd really like it to be corrected.
>
I think we have a situation where people feel responsible to get things
triaged, but just can't keep up, given their other responsibilities.
The first proposal here sounded like we wanted to push that
responsibility to the QA team (corporate QA team + active triaging
community) and I didn't see how that would scale.

>> Furthermore, simply having a "ToBeFiled" component would further
>> dichotomize the work, almost codifying the triage as a QA role, which
>> I don't think is going to scale.
>
> Why exactly would this codify the triage as a QA role?
>

That's how I read the original post. As an organizational strategy,
putting stuff into a pile "to be organized later" never really works
unless there are dedicated people to organize that stuff on continuing
basis. The original proposal sounded to me like we were volunteering QA
to be that set of dedicated people, which is why I was saying it
wouldn't scale. I've since walked away from the discussion for a moment
and come up with an idea on how to handle this a bit, I'll propose it at
the end.

> Triage basically needs to be multi-pass, imo, given the volume of
> incoming bugs. Incremental movement of the bug closer to the right
> place, where someone who might be able to better tell where it belongs
> will see it, is the way to go. I'm not sure why this has to be
> something QA does; in the past it's worked reasonably (though at about
> 2x fewer bugs filed daily, but also with fewer people available, I
> think) with just community involvement.
>

..snip..

> It's everyone's job to triage some subset of bugs, ideally. The only
> question is what subset...
>

> I think we should make a clear separation here between the pool of
> triagers and "QA" in the sense you use it (I assume you mean the Mozilla
> Corporation QA team? Or something else?).
>
> The point of a ToBeFiled component would be to make it clear which bugs
> seriously need directing somewhere useful. Perhaps Firefox:General
> fills that need now, but the idea would have to be that bugs must not
> stay in ToBeFiled any longer than absolutely necessary (ideally measured
> in days, or a most a week or two, for asking the reporter any needed
> questions).
>

This thought gets me much closer to a the solution I came up with when I
walked away for a bit. I agree with you (and Zack's point in his follow
on post) that the user facing side of the Component Organization stuff
is completely, hopelessly too complicated for users to figure out.

Hence the need for this ToBeFiled component. But the question is who
are the triagers? I don't think we should have a component like that
unless we have folks lined up to handle it.

My thought is to build this team out of the community. We already have
quite a few dedicated community triagers out there. If we recognize
them by making them the leaders of this team, and formalize the
institution into something like a "Mozilla Bug Corps" or some such, we
ought to be able to recruit folks to help us. As I think Beltzner noted
elsewhere in this post, it would also give people a great place to get
started on the project and elevate the role of "triager".

This isn't a way to excuse QA (or dev) from triage, that's not my
intent. I think that the early triage task is a solid part of the
responsibility of QA. My intention is to find a way to solve the
problem (it's too hard for people to file bugs) in a way that we can
sustain and scale.

If we have a component like this, then we must also plan for how to work
with it. I think having a dedicated team to this task that works in
concert with the QA effort will achieve this. Members of the current QA
team (company + community) would likely rotate in and out of the triage
team, or be permanent members of it as need dictates.

I'll support this "ToBeFiled" component, because it is needed. Making
bugzilla easier to use benefits us all, for certain. But, we must think
about how to use the component, otherwise it will become another
"Firefox General", and I know we don't want that. This idea may be one
way to handle it. There may be others too. I'll take my proposal for a
triage team to another thread so as not to hijack this one.

Thanks,

Clint

Michael Lefevre

unread,
Aug 29, 2008, 5:37:16 PM8/29/08
to
Zack Weinberg wrote:
> So I think the user-facing problem -- the product+component space is too
> big and daunting -- is more serious than the possibility that QA won't
> scale to handle increased triage responsibilities. If MozCo needs to
> hire some (more?) people whose entire job is to triage bugs, well, I
> have the impression there's room in the budget for that. :)

I wouldn't say that it's a future possibility that QA (or rather
"current triaging work") won't scale. It failed to scale some time ago
and is nowhere near keeping up - lots of bug reports never get triaged
usefully and go nowhere (unless there has been some miraculous catching
up recently that I haven't noticed, but there are 7000 open bugs in
Firefox General, and 6200 of them are UNCOnfirmed, and those numbers are
going up all the time).

I'm not sure throwing people at the current system would work too well
either... Although if that kind of thing is possible and there's room in
the budget, can we hire a whole bunch of developers instead and get
Firefox 4 finished next month? :)

> [...] I'd bet a dollar that lots of users see that and give up
> without even reading it!

With the current state of things, I'm afraid I don't necessarily think
that's bad. Obviously it's a pretty horrible way of doing it, but
scaring away some people who don't try as hard at making bugzilla work
means you have got rid of a pile of useless reports before they have
been made - maybe you lose a few good ones too, but if you simplified
the interface such that they all came in, without doing something about
the system they fall into, you're just increasing the number of reports
that never get triaged.

> This is getting pretty far offtopic, but I'd also like to bring up a
> pet peeve of mine: I don't think we should *ever* tell people to stop
> commenting on a bug.

...


> I think there *ought* to be a way for a bug to host a deeply technical
> conversation about how to fix it and a long train of "me too"s *at the
> same time*, but I don't have any great ideas, probably because I read
> too fast for it to be a serious problem for me. :-/

It would be nice if there was (and I think there are some bugs on
bugzilla requesting comment scoring, comment removal, filtering and
stuff), but there isn't, so obviously some good idea would need to be
implemented before you could stop telling people to not comment.

Reading fast doesn't scale either - maybe it only takes you 6 minutes a
day to wade through the nonsense comments, but if you get 10 times as
many "me too" comments, will you read 10 times faster, or will you be
losing an hour a day instead?

--
Michael

Clint Talbert

unread,
Aug 29, 2008, 5:57:27 PM8/29/08
to
Zack Weinberg wrote:
> So I think the user-facing problem -- the product+component space is too
> big and daunting -- is more serious than the possibility that QA won't
> scale to handle increased triage responsibilities. If MozCo needs to
> hire some (more?) people whose entire job is to triage bugs, well, I
> have the impression there's room in the budget for that. :)
I would agree with you. I'll propose my traige team post and we can try
to understand how to deal with this scale.
>
>
..snip..

> I think we could make life easier for both users and QA by doing some
> serious user interface redesign on the new bug forms. I'm imagining a
> directed question-and-answer session with no more than seven (plus or
> minus two) options at each stage, eventually leading up to one or two
> freeform entry boxes. The goal of this would be to do a rough-cut
> categorization that makes less work for human triagers, and at the same
> time tries to get enough information out of the user that we don't need
> to go back for more. It should be clear to people unfamiliar with the
> terms, but not insulting to experienced users; I think if we do it
> right it would be easier for *everyone* than the current form.

I like your idea about a set of questions. The current form tries to do
that, but it could ask better questions.


>
> This is getting pretty far offtopic, but I'd also like to bring up a
> pet peeve of mine: I don't think we should *ever* tell people to stop
> commenting on a bug. I do realize that when there are widely-cc:ed,
> widely-commented-on, long-standing, not-gonna-be-fixed-soon bugs, it's
> no fun to be on the receiving end of all that mail, and the "me too"s
> can obscure any actual technical discussion that might get the bug
> solved, but too often I see that turning into hostility to users. A
> 'leave us alone' response to a 'hey this is still a problem for me'
> comment is a great way to ensure that that person never reports a
> bug again.
>

I agree with you. The fact that people comment isn't the problem. I
would never tell people not to comment -- those comments are where the
rubber meets the road in terms of a FOSS project. I'm just stating that
it is a lot to deal with, so the 500 number is a little low.

> I think there *ought* to be a way for a bug to host a deeply technical
> conversation about how to fix it and a long train of "me too"s *at the
> same time*, but I don't have any great ideas, probably because I read
> too fast for it to be a serious problem for me. :-/

I think we do this with the current system. I don't think that part is
broken.

Clint

Zack Weinberg

unread,
Aug 29, 2008, 6:57:48 PM8/29/08
to dev-pl...@lists.mozilla.org
Michael Lefevre <ne...@michaellefevre.com> wrote:

> Zack Weinberg wrote:
> > If MozCo needs to hire some (more?) people whose entire job is to
> > triage bugs, well, I have the impression there's room in the budget
> > for that. :)
> I wouldn't say that it's a future possibility that QA (or rather
> "current triaging work") won't scale. It failed to scale some time ago
> and is nowhere near keeping up...

I didn't realize how bad it was already - thanks.

> I'm not sure throwing people at the current system would work too well
> either... Although if that kind of thing is possible and there's room
> in the budget, can we hire a whole bunch of developers instead and get
> Firefox 4 finished next month? :)

Under these conditions, I'd argue that hiring more customer-support
people would be a better use of available funds than hiring more devs.
I'd much rather see us be able to sort, assign, and fix all of those
bugs than get a few more features for FF.next.

> > [...] I'd bet a dollar that lots of users see that and give up
> > without even reading it!
>
> With the current state of things, I'm afraid I don't necessarily think
> that's bad. Obviously it's a pretty horrible way of doing it, but
> scaring away some people who don't try as hard at making bugzilla work
> means you have got rid of a pile of useless reports before they have
> been made

I hear you, but I don't think it's necessary to scare people away in
order to reduce the influx of useless reports. We can ask the same
questions, or effectively so, in a more subtle way. For instance, the
attached file is a suggestion for how the "please don't re-report these
bugs" screen could be better.

...
> > I think there *ought* to be a way for a bug to host a deeply
> > technical conversation about how to fix it and a long train of "me
> > too"s *at the same time*, but I don't have any great ideas,
> > probably because I read too fast for it to be a serious problem for
> > me. :-/

...


> Reading fast doesn't scale either - maybe it only takes you 6 minutes
> a day to wade through the nonsense comments, but if you get 10 times
> as many "me too" comments, will you read 10 times faster, or will you
> be losing an hour a day instead?

I don't know. Ask me again after I'm getting 10 times as much
bugmail. :)

zw

sample-friendly-dupe-bugs.html

Joshua Cranmer

unread,
Aug 29, 2008, 7:26:58 PM8/29/08
to
Zack Weinberg wrote:
> This is getting pretty far offtopic, but I'd also like to bring up a
> pet peeve of mine: I don't think we should *ever* tell people to stop
> commenting on a bug. I do realize that when there are widely-cc:ed,
> widely-commented-on, long-standing, not-gonna-be-fixed-soon bugs, it's
> no fun to be on the receiving end of all that mail, and the "me too"s
> can obscure any actual technical discussion that might get the bug
> solved, but too often I see that turning into hostility to users. A
> 'leave us alone' response to a 'hey this is still a problem for me'
> comment is a great way to ensure that that person never reports a
> bug again.

As I see it, a bug has several stages:
1. The first stage, where developers haven't really picked it up. This
combines both UNCO and early NEW stages.
2. The second stage, where developers have looked at it and are
pondering how to implement it. Late NEW and early ASSIGNED.
3. The third stage, where the bug is going through review cycles. I'm
including in this stage cases where the fix was backed out and then put
back in, so that it doesn't really end until it "sticks." Mostly the
ASSIGNED and REOPENED (maybe) stages.
4. The last stage, where people find regressions, etc. from the bug.

(This only deals with bugs which are ultimately fixed. Other bug types
have different cycles).

I can tolerate the "me too," etc., comments in stage 1. By the later
stages, though, people complaining about the lack of the fix (or the
time it took to fix) are really aggravating, since it makes technical
discussion difficult. Also not helpful are where a bug of high
complexity spawns real work into dependencies and people comment on
already-decided issues in the pseudo-meta bug. A recent example is the
font-face bug where the implementor split work off into two dependency
bugs and people still wondered about when it was going to be implemented
afterwards.

That said, there are certainly cases where the stern comments are
correct--i.e., bug vandalism. The ability to de-vandalize bugs would be
helpful.

Zack Weinberg

unread,
Aug 29, 2008, 8:22:30 PM8/29/08