BMO Reorg Phase 2
Gervase Markham
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
> 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
> * 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
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
> 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
> 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
>
>
> 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
> 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
> 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
> 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
> 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
>> 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
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
> 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.
>
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
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
> 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
>
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
> 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
> 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
> From: ge...@mozilla.org
> Sent: Thu, 21 Aug 2008 16:23:09 +0100
> To: dev-pl...@lists.mozilla.org
> Subject: BMO Reorg Phase 2
>
> 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
Agreed.
There are a fair amount of OS specific bugs. The amount varies a lot between
components though I guess.
-Magnus
Justin Dolske
> 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
>
> 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
> 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
> "Documentation: Help Viewer" is not really useful anymore
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
> "Mozilla Localizations: sv / Swedish"
Are you on the Swedish l10n team? If not, can you get consent from one
of them?
Thanks,
Gerv
Gervase Markham
> 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
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
> 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
>> * 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
> 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
> 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
> 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
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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
>
> 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
<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.
>>
>
> 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
> 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
> >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
> 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
> 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
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
>> 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
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
> 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
> 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.
>
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
> 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
> [...] having a "ToBeFiled" component would further
> 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
>
> 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
> 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.
>
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
> 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
> 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. :)
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
> 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
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
Joshua Cranmer
> 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
> 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 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.
I'm coming at this from the opinion that we need, as a matter of
policy, to accept unhelpful comments on any bug at any stage of its
life. The bug system isn't just for the developers; it is also one of
the only venues where users affected by a problem can find each other
and commiserate, discuss workarounds, vent, &c. I see intrinsic value
in providing that venue *even if* it doesn't help get bugs fixed.
If that means we need technical measures whereby individual bugzilla
users can do something to filter out the comments they see as
distraction, well, let's make that happen. (I think it's okay if, in a
bug like, oh, 915, all the venting goes unanswered by developers.)
> 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.
Only if there is a crystal-clear, public policy defining vandalism.
Otherwise we're going to get accused of censorship. (I have yet to see
actual spam on bugs, or the sort of thing you see on Slashdot at -1,
and I'm not sure I would delete anything short of that.)
zw
Martijn
> 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.
50 bugs per day? Are you talking about only moving bugs in a
different, more likely to be correct, component or actually triaging?
Suppose I would triage 50 bugs a day and would take 5 minutes a bug,
that would mean 4 hours in total.
But usually, isn't finished after first triage. I keep getting bugmail
for days after that, with further things that perhaps need to be done
in that bug.
And when trying to get a minimized testcase for a bug, it takes much
longer for me.
> 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.
Well, we could create a new bugzilla component for all the bugs that
need to be moved in the right component, e.g. an "ToBeFiled"
component.
But I don't see the use of it much, because that's basically the
function that Firefox:General has now, afaict.
Wasn't the Core->General component created for this? (or for a similar reason?)
Regards,
Martijn
> -Boris
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
--
Martijn Wargers - Help Mozilla!
http://weblogs.mozillazine.org/qa/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22
Daniel Veditz
> 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
That sounds good, but also fairly complex to implement. Is anyone
working on it? Will it be usable on BMO before Firefox 3.0 is
end-of-lifed? A solution like bug 336790 seems like it would be a simple
table we could hack into BMO in fairly short order -- not perfect, but
at least we'd be able to use it.
Boris Zbarsky
> 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.
The alternative currently is to have developers who might actually be
able to fix the bug either uncc themselves or filter out all mail
(including relevant mail) from the bug.
In fact, that's more or less the alternative no matter what; it's just a
matter of what sort of UI Bugzilla provides for it.
> and the "me too"s
> can obscure any actual technical discussion that might get the bug
> solved
This is a really serious problem, actually.
> but too often I see that turning into hostility to users
That's bad, yes. The right response is usually to privately mail the
offender with a link to the Bugzilla etiquette guide.
> A 'leave us alone' response to a 'hey this is still a problem for me'
> comment
I think there is a difference between "leave us alone" and "yes, I know,
and so do the 200 other people you just e-mailed". When put the latter
way, a lot of people quickly see the problem from our point of view,
actually.
> 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. :-/
If I might ask, how much bugmail do you get? Is it over about 500 per
day yet? That's where I was last I counted. I can cut it to about 80
per day by savagely removing myself from cc lists whenever someone adds
me to ask me a question and not watching any components. I could even
cut it to 0 by ignoring bugmail altogether. But I think it's a good
thing that I'm able to respond quickly when XBL bugs (say) get filed. I
do wish I could _just_ get mail for new XBL bugs (and then require an
explicit cc to get more mail). That would make it a lot more feasible
to watch components for new bugs while not dealing with the huge volume
of noise on existing bugs.
-Boris
P.S. Note that some components are a _lot_ noisier than others. Layout
is one of the ones where there is actually a quite small amount of
noise, compared to some.
Boris Zbarsky
> I think we have a situation where people feel responsible to get things
> triaged, but just can't keep up, given their other responsibilities.
Sounds like we need more people who feel that they're responsible for
this, then.
> The first proposal here sounded like we wanted to push that responsibility
> to the QA team (corporate QA team + active triaging community)
I've been out of this loop for a while, so I have to ask: how many
people are we talking about here for the latter nowadays?
> and I didn't see how that would scale.
Having the community involved in triage is the only way it can possibly
scale, in my opinion. That's been true for years.
> 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.
Agreed. We absolutely need such people, but they don't have to do the
final organizing. They just need to give the bug a push in the right
direction. Then we need to have a way for people who care to be
notified when a bug is moved into a given component or filed in it, and
people watching particular components for such notifications.
> 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"
Note that we've had such things in the past, more or less. Asa may be
able to provide some details, since he was pretty heavily involved...
In fact, that's how I got involved in this project.
> it would also give people a great place to get
> started on the project and elevate the role of "triager".
Amen.
> 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.
It sounds like we're on the same page. ;)
-Boris
Boris Zbarsky
> but there are 7000 open bugs in
> Firefox General, and 6200 of them are UNCOnfirmed, and those numbers are
> going up all the time).
This is an interesting data point. Here's a graph of uncofirmed bugs
over time over all products:
https://bugzilla.mozilla.org/reports.cgi?product=-All-&datasets=UNCONFIRMED%3A
It looks sad, I know. I'd like you to look at the part of the graph
from about 9/2/00 to 3/30/01. Yes, I realize that's ancient history.
;) In that time period, UNCO bugs went up to nearly 1000, which was
widely viewed as a Bad Thing. A few people (more or less 3, I seem to
recall), working over a period of several weeks, got the number to under
100. Now they couldn't keep it there, both because the volume of bugs
being filed was increasing and because they couldn't spend that much
time on UNCO triage on a consistent basis (in fact, one of them had to
stop Mozilla work for a while, for various reasons).
So this isn't a 3-person job. I do think it's not unreasonable as a
30-person job, at much lower time commitment (say 10 hours a week
instead of the 30 that those 3 people were putting in). Yes, I realize
that 10 hours a week is still a significant commitment. :(
> I'm not sure throwing people at the current system would work too well
> either.
Do you have specific concerns?
> 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? :)
Development doesn't necessarily parallelize as well as triage, and the
learning curve for development is a bit steeper. It's also a lot easier
to do useful triage even if you're doing just a little bit. That's
harder with bugfixing, and _really_ hard with the kind of arch changes
we're probably talking for Firefox 4. And yes, I realize you were
joking, but I think it's a legitimate question.
-Boris
Boris Zbarsky
> I'm coming at this from the opinion that we need, as a matter of
> policy, to accept unhelpful comments on any bug at any stage of its
> life. The bug system isn't just for the developers; it is also one of
> the only venues where users affected by a problem can find each other
> and commiserate, discuss workarounds, vent, &c.
We have forums on mozillazine for the latter, no? I think we should be
directing users who want to do those things there, honestly...
> I see intrinsic value in providing that venue *even if* it doesn't help get bugs fixed.
I do too, but I don't see value in providing it if it keeps bugs from
getting fixed. Hence the existence of a different venue.
> If that means we need technical measures whereby individual bugzilla
> users can do something to filter out the comments they see as
> distraction, well, let's make that happen.
It's really hard to solve this problem, actually. If you have a
workable proposal, I'm all ears. All the ones I've thought of so far
come down to having a secretary filtering your bug stuff for you. I
don't think AI is far enough along for that yet....
> Only if there is a crystal-clear, public policy defining vandalism.
I thought we had one somewhere, but I can't find it.
> (I have yet to see
> actual spam on bugs, or the sort of thing you see on Slashdot at -1,
> and I'm not sure I would delete anything short of that.)
We do have some people who delete bug comments that are just link-spam
in some cases, for what it's worth. And yes, it does happen.
-Boris
Boris Zbarsky
> 50 bugs per day? Are you talking about only moving bugs in a
> different, more likely to be correct, component or actually triaging?
In the context of the 50 number, some of both. Triage the ones that I
know something about (probably about 1/3 to 1/2), move the rest.
> Suppose I would triage 50 bugs a day and would take 5 minutes a bug,
> that would mean 4 hours in total.
That's true. The 50 bugs number was for basically an 8-hour day.
> But usually, isn't finished after first triage. I keep getting bugmail
> for days after that, with further things that perhaps need to be done
> in that bug.
That's true; see below.
> And when trying to get a minimized testcase for a bug, it takes much
> longer for me.
I think creating a minimized testcase isn't something that needs to
happen as part of the initial "is this sorta valid, not a dup, and which
component should it be in?" triage. Nor something that needs to be done
by the same people as the ones doing the triage (though it can be). The
skill sets involved are somewhat distinct: knowing where bugs should
live based on the info given vs knowing how to reduce gmail to a 5-line
HTML file that shows the bug. ;)
> Well, we could create a new bugzilla component for all the bugs that
> need to be moved in the right component, e.g. an "ToBeFiled"
> component.
> But I don't see the use of it much, because that's basically the
> function that Firefox:General has now, afaict.
Yeah. The key isn't what the component is called but what we do with it.
The proposal of the ToBeFiled component was that _all_ bugs would go in
there, so reporters can't misfile by accident, more or less.
-Boris
Joshua Cranmer
> So this isn't a 3-person job. I do think it's not unreasonable as a
> 30-person job, at much lower time commitment (say 10 hours a week
> instead of the 30 that those 3 people were putting in). Yes, I realize
> that 10 hours a week is still a significant commitment. :(
My 2¢:
I am going to speak of my experience with TB bug triage. I'm sure Wayne
or Gary could explain better, but I'll try my best.
First off, the graph:
<https://bugzilla.mozilla.org/reports.cgi?product=Thunderbird&datasets=NEW%3AUNCONFIRMED>
Starting around March, TB adopted bugdays, responsible for removing (as
in, confirm or resolve) about 1200 UNCO bugs (by estimated trend). With
about an average of 7-8 (?) people each working about 2 hours once a
week, about 2500 bugs were triaged, and 1000 changed (numbers
approximate because I'm trying to extract TB bugs from a combination TB
+ core mailnews statistics).
Now, about 400-ish bugs were closed as a result of an aggressive closeme
strategy to clean up old bugs. I think about 150-200 of those were
generated by mass bug changes. Another 100-ish are probably
double-counted in above statistics.
Crunching the numbers, it means that the average bug took approximately
8-10 minutes to triage. What I most want here is statistics on the
average age of the resolved bugs, but my sense is that many of the bugs
tackled where older.
Now, from personal experience:
My record for bug triage seems to be about 4 minutes per bug. And these
are bugs which are a) old and b) easy to triage. My overall average for
a bug is probably around 7 minutes. But this average is probably
inaccurate as I do very few bugs that are complex to triage.
Assuming that it takes 7 minutes to triage a bug, then. Bugzilla says
that 582 bugs were filed in the past week for the combination of Core,
Toolkit, and Firefox components. Crunching the numbers some more, that
means we can expect about 68 man-hours per week to just triage incoming
bugs for Firefox. For the aforementioned products, there are presently
14,697 UNCO bugs and 24,281 NEW bugs. Assuming an input of 300
man-triage-hours per week (68 of which are triaging incoming bugs), it
would take 7.4 weeks to bring the UNCO count to 0.
But those numbers mean little. They fail to take into account the fact
that a bug might be "triaged" multiple times, or, put another way, they
assume that 7 minutes of a triager's time is sufficient to bring a bug
to the closure process (i.e., (someone picks up) -> ASSI -> RESO FIXED).
For complex bugs, this is obviously not the case.
More statistics: Once again, for the aforementioned products, 100 bugs
created in the past week were resolved as either DUPL, INCO, or INVA,
and are probably triageable in one pass. An additional 12 bugs were
closed as WONTFIX or WFM (side note: 1 was about removing the
awesomebar). I'm hesitant to include these as one-pass-triageable,
because they may involve more communication. In the interest of being on
the safe side, I'll include them anyways.
As for other bugs, my sense is that three triages (or about 21 minutes)
is a good average for the complexity of bugs).
Crunching (again), 20% of non-legacy bugs are 1-pass triageable. Total
time per week more than doubles to about 178 man-triage-hours. Just to
keep up. So only 40% of the allocated 300 man-triage-hours/week is
devoted to working on the 15,000-bug backlog.
Calculating for Thunderbird, at least 84 bugs were filed in the past
week for MailNews Core and Thunderbird (I think a few were moved to
Core, but certainly no more than 90 were filed). Of these, 26 are UNCO
right now (I don't know how many were filed as UNCO). Even with bugdays
and at least 20 man-triage-hours per week, keeping up is problematic:
about a third of newly-filed bugs over the past four weeks are still
UNCO. To get to this level for Firefox requires about 140
man-triage-hours per week. I'm estimating that--if present levels stay
consistent--it would take 280 man-triage-hours to get down to
near-complete coverage for Firefox alone. Which makes the margin rather
small for near-certain future increase.
So I'd say that a 30-person job would be cutting it thin.
>> I'm not sure throwing people at the current system would work too well
>> either.
>
> Do you have specific concerns?
One concern I have is scalability. Note that I don't have any proposed
solution. It's quite possible that there is no right answer, that there
is just too much incoming data to be filtered properly.
Okay, maybe I had more than 2¢ in this post....
Bernd
> So this isn't a 3-person job. I do think it's not unreasonable as a
> 30-person job, at much lower time commitment (say 10 hours a week
For me the proposal that a web based organization resorts to manual
interaction rather than to process automation and considers to waste
peoples time on standard tasks is unbelievable.
However after having turned down the proposal when a bug reporter enters
a url in the guided bug form to remind that the bug is probably better
filed in a core component (bug 272140) I am skeptical that things will
move in the right direction.
I would rather like a discussion where we can automagically help people
to file in the right component and how we can convert experienced
triagers in to people who finally fix the bugs. Triaging the 15th dupe
is noble but it is a waste of time compared to fixing the bug.
Bernd
Gervase Markham
> 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.
That's not true - we are not forcing people to use it.
Is it easier to distribute bugs from a single known component to the
right places, or gather them up from a scattering of random incorrect
components and put them in the right places?
> 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.
I'm not sure what you mean here. Triage is a QA activity.
If you're saying "we will no longer get the benefit of the triage done
by irritated developers kicking misfiled bugs out of their components"
then I guess that's true. :-)
> 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.
Hendrix was designed specifically as a place for feedback which did
_not_ need triage. If people are triaging and acting on a significant
percentage of Hendrix feedback then a) I pity them, and b) they should
stop :-)
Gerv
Gervase Markham
> 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.)
Both of those things can be fixed. File a bug on b.m.o. about box size,
and file bugs in each component with a cryptic description, saying "Dear
owner: your description is cryptic" :-)
> 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 says it on all the entry points to the Bugzilla Helper too.
We really need a single page which all bug/issue filing is funnelled
through, which distributes people to Bugzilla, to the broken website
tool or to Hendrix - and then we should never link to those tools directly.
The front page of Hendrix might actually be that place.
Gerv
Gary Kwong
closemes (less time per bug) and / or dedicated per-bug triage
(significantly more time per bug), sometimes things still get
mis-handled / mis-resolved due to the vast ratio of bugs-to-TB-triagers
involved.
Fx admittedly has more triagers, but their numbers of bugs being filed
are also higher, so the ratio for both Firefox and Thunderbird may end
up being similar.
Always look to scale; the bugdays started off with a wee bit of 2-3
triagers, and 5 months later, the figure has gone up by 3-4 times. I'm
sure bugdays can prove their worth to Firefox as it has for Thunderbird.
-Gary
Robert Kaiser
> For me the proposal that a web based organization resorts to manual
> interaction rather than to process automation and considers to waste
> peoples time on standard tasks is unbelievable.
I don't think that anything in bug triage can actually be automated.
Those are reports manually filled out by real people, with problems they
apparently saw. How would any automation know what to do with those
correctly? It's often even hard for a human to decide if a bug is valid,
invalid, wontfix, or whatever.
Robert Kaiser
Gervase Markham
> I don't think that anything in bug triage can actually be automated.
> Those are reports manually filled out by real people, with problems they
> apparently saw. How would any automation know what to do with those
> correctly? It's often even hard for a human to decide if a bug is valid,
> invalid, wontfix, or whatever.
There are some limited classes of bugs where we do what is effectively
automated triage. Crashes are one (with Breakpad), broken websites are
another (with Reporter).
I agree that it's hard to do this for arbitrary bugs. But are there
other classes of bug where this approach might work?
Gerv
Michael Lefevre
> Michael Lefevre wrote:
>> [stuff]
> So this isn't a 3-person job. I do think it's not unreasonable as a
> 30-person job, at much lower time commitment (say 10 hours a week
> instead of the 30 that those 3 people were putting in). Yes, I realize
> that 10 hours a week is still a significant commitment. :(
>
>> I'm not sure throwing people at the current system would work too well
>> either.
>
> Do you have specific concerns?
No, not really :) The points you made about triaging parallelizing (I'm
sure that's not a word!) better than development are valid. Improving
the system would clearly be a good thing to do before throwing people at
the problem, and also I was thinking along the lines you mention above -
that more people (quite possibly people not paid by MoCo) committing
smaller amounts of time would be better than MoCo going out and hiring
several people to do triage as a full time job (I'm not sure that the
parent post was actually suggesting that, but it seemed to be heading in
that direction...)
--
Michael
Boris Zbarsky
> Crunching the numbers, it means that the average bug took approximately
> 8-10 minutes to triage.
That sounds about right to me, yeah.
> Bugzilla says that 582 bugs were filed in the past week for the combination of Core,
> Toolkit, and Firefox components. Crunching the numbers some more, that
> means we can expect about 68 man-hours per week to just triage incoming
> bugs for Firefox.
Agreed.
> For the aforementioned products, there are presently
> 14,697 UNCO bugs and 24,281 NEW bugs. Assuming an input of 300
> man-triage-hours per week (68 of which are triaging incoming bugs), it
> would take 7.4 weeks to bring the UNCO count to 0.
My "30 person" number was predicated on just keeping up with the stated
500-bug-per-week inflow, while slowly working on the backlog. 7.4 weeks
to work through the backlog would be quite miraculous at this point!
> More statistics: Once again, for the aforementioned products, 100 bugs
> created in the past week were resolved as either DUPL, INCO, or INVA,
> and are probably triageable in one pass.
Agreed.
> An additional 12 bugs were
> closed as WONTFIX or WFM (side note: 1 was about removing the
> awesomebar). I'm hesitant to include these as one-pass-triageable,
> because they may involve more communication. In the interest of being on
> the safe side, I'll include them anyways.
I think those sort of things are one-pass gettable to the right module
owner, typically.
> As for other bugs, my sense is that three triages (or about 21 minutes)
> is a good average for the complexity of bugs).
I can live with this as a SWAG, sure.
> Crunching (again), 20% of non-legacy bugs are 1-pass triageable.
What fraction of non-legacy bugs are filed directly into the NEW status
(and possibly the right component) by developers, by the way? I'd guess
no more than 10%, but worth checking if we can.
> To get to this level for Firefox requires about 140
> man-triage-hours per week. I'm estimating that--if present levels stay
> consistent--it would take 280 man-triage-hours to get down to
> near-complete coverage for Firefox alone.
Where does the 280 estimate come from? You're saying Firefox should
need about 180 man-hours above, and that the equivalent of Firefox
getting 140 man-hours is not enough for tbird, by about a third. That's
pretty consistent with needing about 200 man-hours per week on triage.
But let's take the 280 number.
> Which makes the margin rather small for near-certain future increase.
Yeah. The 30-person estimate was based on current numbers. It seems
that your estimates are not far off from it.
> One concern I have is scalability.
Yeah, agreed. But I don't see a better solution than having a
non-centralized triage setup that can scale with the community growth.
-Boris
Boris Zbarsky
> For me the proposal that a web based organization resorts to manual
> interaction rather than to process automation and considers to waste
> peoples time on standard tasks is unbelievable.
Which task are we talking about here? If we can automate something, we
certainly should!
> I would rather like a discussion where we can automagically help people
> to file in the right component
If we can do this, great. I think ideally we'd automagic some bugs into
place, then funnel the rest.
-Boris
Joshua Cranmer
> Joshua Cranmer wrote:
>> Crunching (again), 20% of non-legacy bugs are 1-pass triageable.
>
> What fraction of non-legacy bugs are filed directly into the NEW status
> (and possibly the right component) by developers, by the way? I'd guess
> no more than 10%, but worth checking if we can.
One thing I would love to see for bugzilla would be some form of power
query utility, especially one that could show results over time. I'm
sure this is doable with an SQL query or two, but I'm not sure how
accessible the queries would be from UI.
> > To get to this level for Firefox requires about 140
>> man-triage-hours per week. I'm estimating that--if present levels stay
>> consistent--it would take 280 man-triage-hours to get down to
>> near-complete coverage for Firefox alone.
>
> Where does the 280 estimate come from? You're saying Firefox should
> need about 180 man-hours above, and that the equivalent of Firefox
> getting 140 man-hours is not enough for tbird, by about a third. That's
> pretty consistent with needing about 200 man-hours per week on triage.
> But let's take the 280 number.
My thought process was that the remaining 1/3 of bugs would represent
harder ones to triage, I think (it was late at night). Whether such a
justification is correct is up to debate, but I would like to remind
people that the numbers aren't terribly valid anywheres because I have
low numbers of data points.
Also, I originally approached this with the thesis of showing that the
30-person estimate was low, so expectation bias may be creeping in. In
any case, I think it's sufficient to say that it would be worthwhile to
track some of these numbers if it could be easily done.
>> One concern I have is scalability.
>
> Yeah, agreed. But I don't see a better solution than having a
> non-centralized triage setup that can scale with the community growth.
I think what most people seem to conclude is that the only way to handle
the bug explosion is to foist more triage responsibilities on reporters.
I know of two different reasons why newsgroup unread counts may be
wrong--both of which are easily verifiable by the user. Asking the user
to verify that the issue is separate from these two known, common bugs
before filing the bug takes much less time for all parties involved.
Many newly filed bugs (but probably not most) are duplicates of bugs
that can be found by merely quicksearching the keywords. If we required
users to do this before filing new bugs, that might cut down on the
avalanche, at least for a while.
Smokey Ardisson
> 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.
We have several areas of code where there is a good bit of platform-
specific code that lives in modules/Bugzilla components that are
platform-generic. The biggest example of this, I think, is Gfx:Thebes
(but also, as Stefan mentioned, *:Themes, Core:File Handling, NSPR,
and so forth). I have a query specifically set to pull out Mac OS X
bugs filed in Gfx:Thebes, because there's a chance I can do something
useful on them. As far as I can tell, these are all Mac-specific bugs
and the OS field has been used correctly to provide something of
value. I enjoy trying to be helpful there, but I don't have enough
time in my life to weed through (and then somehow track) all of
Gfx:Thebes on a daily or weekly basis. If I can't look at just the
Mac-specific bugs (or, very occasionally, the bugs that someone might
think are Mac-specific), I won't be able to keep helping in Gfx.
Hardware I agree has pretty much outlived up its usefulness in most of
the user-facing components; most often it seems like it's used as a
way to torture reed ;-) I do wonder, though, if some areas that have
pretty hardware-specific parts like XPConnect and NSPR use it heavily?
In Camino the default for Version is "unspecified," which is correct
>90% of the time and which reporters tend to leave alone. When the
version is set to something else (for us, it's only ever changed by
either an experienced reporter or by QA), it's very easy to figure out
where to hone in for further QA or for a fix.
In Camino we also make specific use of both the Priority and Severity
fields. Priority is used for major release planning; bugs that are P1
will block a release, P2 bugs we might hold for, depending on the
patch state, P3 is nice-to-have, and so forth. I can't imagine trying
to run a release without specific fields for that. As far as
severity, most of our bugs are normal, but it's very easy to find
critical/blocker/enhancements in bug lists thanks to the highlighting
they get; this is useful both in daily triage of new bugs and in
following up on older bugs. I wouldn't cry if the 7 severity options
were reduced to 5, but we do use all 7 and there's only very
occasional argument over the severity. (I also know that Mozilla's IT
uses severity to determine whether or not they get paged at 3am or not
and other sorts of things like where on the totem pole your bug
falls.) For Camino, at least, the two "Importance" fields aren't
really combinable or replaceable.
If we resort to removing a bunch of fields, parts or all of the
project are inevitably going to start overloading the status
whiteboard or summary fields, which are harder to search/track
accurately than a field dedicated to the purpose of tracking
information of type foo.
Also, I realize that Firefox and Gecko are the ones suffering most
from bug overload, but Bugzilla is a shared system for the entire
Mozilla project, and the elimination of certain fields entirely is one
area where what's best for Fx/Gecko _may_ not be best for all of the
other consumers of bugzilla.mozilla.org. If the consensus is that
Firefox and Gecko don't need Version, OS, Hardware, Priority and/or
Severity, I'd advocate hiding them, if at all possible, in those
components, as well as exploring other options (only letting certain
classes of users touch severity, as Stefan suggested earlier, or
setting the default version to "unspecified" if the initial version
information is not useful, etc.) to address problems with specific
fields, rather than removing those fields entirely across the entire
bmo installation.
Joshua Cranmer
> Bernd wrote:
>> For me the proposal that a web based organization resorts to manual
>> interaction rather than to process automation and considers to waste
>> peoples time on standard tasks is unbelievable.
>
> Which task are we talking about here? If we can automate something, we
> certainly should!
There are certainly some questions that could be asked first. One easy
one (for products other than FF) would be what version (last week,
somebody actually filed a bug on TB 1.5...). A common TB question that
triagers often ask is whether or not the user is using IMAP or POP (or
NNTP, in some cases); another one is to provide a log. For crashes, a
stack trace or relevant crash reporter ID would be another good question.
Those common triage questions are probably better asked during the
filing process.
Max Kanat-Alexander
> That sounds good, but also fairly complex to implement. Is anyone
> working on it? Will it be usable on BMO before Firefox 3.0 is
> end-of-lifed?
Currently there's a chance that MoCo may fund Everything Solved to
implement it. Putting in your "vote" here would help:
https://wiki.mozilla.org/Bugzilla_Fixup (note that this is already
listed in Stage 2 [which is where we are], but it hasn't been actually
contracted yet or anything like that).
-Max
Justin Dolske
> My "30 person" number was predicated on just keeping up with the stated
> 500-bug-per-week inflow, while slowly working on the backlog. 7.4 weeks
> to work through the backlog would be quite miraculous at this point!
(Random Thought)
It would probably help to start off to target 100% triage on only *some*
components, instead of everything. Especially in areas where triagers
and module owners are willing to keep things under control.
Back in mid-2007 QA made a push to reduce the number of UNCO bugs
(http://blog.mozilla.com/dolske/2007/07/19/zarro-boogs/), but it seems
the results were short-lived in most areas. I think I'd rather see
efforts targeted on modules where triage can make a long-term difference.
For example, I'd like to work on improving the Form Manager but even
with "just" 50 UNCO and 100 NEW (which, realistically, probably need
retriaged), it's hard to know where to start and get traction.
Justin
Bernd
> If we can do this, great. I think ideally we'd automagic some bugs into
> place, then funnel the rest.
What we are trying to do here is to determine the species of a bug. This
problem has been tackled 200 years ago already by biologist. They simply
asked differential questions to determine the bug species. So our
problem is nowhere new and using their experience might help.
Example:
Does your problem appear in a browser or in the mail application?
browser
Do you have a problem with a specific website or with the behavior of
the browser in general?
website
Is that a mozilla website or another site?
other
Do you have a testcase for the broken behavior (see
http://developer.mozilla.org/en/Reducing_testcases what we think a
testcase is)
No -> Does it crash
-> yes breakpad
-> no reporter (bye)
yes -> cool this is what we want and we probably have a developer in
front of us, so we can pitch harder
please attach the test case
from this point we would have a much easier job since triaging with a
test case is much easier.
and now would come the differentiation between the core components maybe
with some thrash cans where we cant yet decide what it is, but the bugs
would be pretty close where they already belong.
I would then force people without canconfirm through this.
I left the component differentiation out, but thats how biology evolved
you get some evidence and tweak the questions and see how the flow
changes. And you tweak till your hypothesis and the experiment coincide.
Bernd
dolphinling
>> 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?
How about just "Core"? I doubt the duplication would be a problem.
--
dolphinling
<http://dolphinling.net/>
dolphinling
> 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.
>
What about always trunk unless it's only on a branch? That makes most sense
conceptually to me.
But then, I'm in favor of removing it unless someone says they actually use it
(or would use it if it had a certain meaning).
--
dolphinling
<http://dolphinling.net/>
Bernd
wizard I am volunteering to create and maintain for while such a tree
for everything that links into libgklayout.
While that means to leave for a while the most coziest place in our
tree, I know that table bugs are not wolfs, they don't run into the trees.
Bernd
Gervase Markham
> Currently there's a chance that MoCo may fund Everything Solved to
> implement it. Putting in your "vote" here would help:
> https://wiki.mozilla.org/Bugzilla_Fixup (note that this is already
> listed in Stage 2 [which is where we are], but it hasn't been actually
> contracted yet or anything like that).
Max,
There are some features there which are crossed out - does that mean
"implemented and deployed on b.m.o."?
How has search clobbering been fixed? Are we going to be hiding any past
milestones any time soon? Are all these new reports the ones listed on
report.cgi?
Gerv
Gervase Markham
> It would probably help to start off to target 100% triage on only *some*
> components, instead of everything. Especially in areas where triagers
> and module owners are willing to keep things under control.
Perhaps we could persuade every QA community member to adopt a
component, and be responsible for triage of UNCO and NEW bugs which end
up in that component?
We could call it... QA Contacts.
Seriously, the % of components so adopted would be a good measure of how
close we are to getting a handle on this.
Gerv
Gervase Markham
> How about just "Core"? I doubt the duplication would be a problem.
I think it would be in conversation.
Gerv
Gavin Sharp
> Perhaps we could persuade every QA community member to adopt a
> component, and be responsible for triage of UNCO and NEW bugs which end
> up in that component?
There have been attempts to do that. See
https://wiki.mozilla.org/QA/Community/Bug_Watchers
(Using Bugzilla user watching instead of explicit QA contacts)
I'm not sure how up to date that page is, though. I know that not all
watchers are able to stay on top of the components they're watching
due to the sheer volume of incoming bugs. It would be great to be able
to enlist more people to help, of course...
Gavin
Benjamin Smedberg
> Joshua Cranmer <Pidg...@verizon.net> wrote:
>> 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 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.
>
> I'm coming at this from the opinion that we need, as a matter of
> policy, to accept unhelpful comments on any bug at any stage of its
> life. The bug system isn't just for the developers; it is also one of
> the only venues where users affected by a problem can find each other
> in providing that venue *even if* it doesn't help get bugs fixed.
I strongly disagree. I believe that the purpose of bugzilla ought to be
strongly focused on tracking issues.
One of the reasons we have so many (too many!) bugzilla components already
is that people are dying under the bugmail load. Even if you provide some
kind of kline tool to ignore comments, that only takes effect after you've
seen the useless commenter at least once. Encouraging discussion which isn't
targeted at fixing a bug places a burden on the tool that it wasn't designed
to accommodate.
Another reason that we should actively discourage offtopic bug comments is
that they make the bug webpage much harder to read, and therefore harder to
fix. Sifting through a bug with 50 comments to find the 10 relevant ones is
a significant waste of time, especially if I have to refer back to comment
0, 1, 7, 13, 43, and 47. Adding a personal kline tool for comments doesn't
help this situation: it only works if a triager/bug owner can "hide"
irrelevant comments by default that you could avoid this kind of clutter.
We have fora, probably too many fora, for users to come together: there are
the support newsgroups, the mozillazine mess, SUMO (does it have its own
newsgroups/mailing lists? I'm not sure).
Bugzilla can be a great tool to get people involved in our project: I
started out in the project triaging new bugs, learning from Matti how it was
done. But let's not confuse "directed tool for solving issue-tracking" with
"forum for expression of discontent, advocacy, or general malaise".
--BDS
us...@domain.invalid
Benjamin Smedberg wrote:
>
> Another reason that we should actively discourage offtopic bug comments is
> that they make the bug webpage much harder to read, and therefore harder to
> fix. Sifting through a bug with 50 comments to find the 10 relevant ones is
> a significant waste of time, especially if I have to refer back to comment
> 0, 1, 7, 13, 43, and 47. Adding a personal kline tool for comments doesn't
> help this situation: it only works if a triager/bug owner can "hide"
> irrelevant comments by default that you could avoid this kind of clutter.
>
Maybe a system like the one used on youtube could be implemented. People with
editbugs privileges (or something of similar value, let's not pick on details
right now) could give a thumb down to unhelpful comments; a filter could just
collapse automatically those comments.
mmc
Gervase Markham
> Maybe a system like the one used on youtube could be implemented. People with
> editbugs privileges (or something of similar value, let's not pick on details
> right now) could give a thumb down to unhelpful comments; a filter could just
> collapse automatically those comments.
This is work to implement, and in the ten years Bugzilla has existed,
no-one has done it (even though this has been a 'problem' for ages). We
should have no problem with taking more severe action than "modding down".
Gerv
Clint Talbert
> I do wish I could _just_ get mail for new XBL bugs (and then require an
> explicit cc to get more mail). That would make it a lot more feasible
> to watch components for new bugs while not dealing with the huge volume
> of noise on existing bugs.
I was asking around about that about a week ago, and was pointed to this
bug: https://bugzilla.mozilla.org/show_bug.cgi?id=417290
So, that support is coming. :-)
Clint
AC
> David E. Ross wrote:
>> 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?
Some brainstorms...
Names for set Names for set
{Core, Toolkit, etc.} {Core/DOM, Toolkit/Autocomplete, etc.}
------------------------- ---------------------------------------
Libraries Components
Components Subcomponents
Supercomponents
Shared components internal components
Platform components Project components
Platform libraries
Platform APIs
Foundations
Commons
Component products product components
Two siblings of left column set have two-word names:
Client Software, Server Software
https://bugzilla.mozilla.org/enter_bug.cgi?full=1
To pick one, how about "Platform Libraries"
(for left-hand set, and keep "Components" for right-hand set) ?
Max Kanat-Alexander
> There are some features there which are crossed out - does that mean
> "implemented and deployed on b.m.o."?
It means implemented.
> How has search clobbering been fixed?
It was fixed, and various users objected to the fix, so it was
backed out.
> Are we going to be hiding any past milestones any time soon?
Sure, you can do that whenever you'd like.
> Are all these new reports the ones listed on report.cgi?
Yep.
-Max
Gervase Markham
> I
> do wish I could _just_ get mail for new XBL bugs (and then require an
> explicit cc to get more mail). That would make it a lot more feasible
> to watch components for new bugs while not dealing with the huge volume
> of noise on existing bugs.
Does Bugzilla provide sufficient headers on the mail for you to set up
client-side filters?
Gerv
Gervase Markham
> Gervase Markham wrote:
>> David E. Ross wrote:
>>> 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?
>
> Some brainstorms...
The second set basically has to be called Components - that usage is too
established.
> Names for set Names for set
> {Core, Toolkit, etc.}
We're not looking for a name for the _set_ this set is called
"Classification". My understanding was that people were looking for a
new name for the "Core" classification.
Gerv
dolphinling
> David E. Ross wrote:
>> 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?
Another suggestion, "Internals"?
--
dolphinling
<http://dolphinling.net/>
Martijn
> Clint Talbert wrote:
>> 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.
>
> Hendrix was designed specifically as a place for feedback which did
> _not_ need triage. If people are triaging and acting on a significant
> percentage of Hendrix feedback then a) I pity them, and b) they should
> stop :-)
>From what I've seen from Hendrix feedback, is that there are a people
that are posting there are at least expecting some kind of response.
Often they have some kind of support question.
But I've also seen reports where they've basically written a very good
bug report, complete with testcase.
Regards,
Martijn
> Gerv
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
--
Martijn Wargers - Help Mozilla!
http://weblogs.mozillazine.org/qa/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22