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?
Benjamin Smedberg wrote: > I think that if you phrase the discussion this way, you're not going to deal > with the fundamental problems in our bug tracker.
First, an on-topic reply:
Figuring out how to fix the problems you outline is a far larger task than I am attempting here. They may also be more important, but I want to finish (for some value of "finish") one job before starting another.
However, you are absolutely correct that there's a mismatch between bringing issues to the attention of the right people (made easier by lots of small components) and filing issues in the right place (made more difficult by lots of small components).
My general suggestion for this is to fix the bug-filing process to hide the complexity from the bug filer. There have been attempts to make filing easier in the past (e.g. Bugzilla Helper) but we need to go a stage further. I believe KDE have a nice bug-filing wizard, and launchpad has a similar process also.
Gervase Markham wrote: > If all or most of those bugs went into either Firefox/General or > Thunderbird/General and had to be triaged out of there by the QA team, > would it be much more effort overall than the current triage process > where we have to monitor every component for badly-filed bugs, as well > as sorting those that end up in the General components anyway?
Possibly not. I think 50 bugs per person per day for triage is a pretty doable number (this is based on my memories of when I was doing just this sort of thing), so if we have enough people working on this and they don't overlap too much, it could work.
But we need to make a point of moving the bugs, not just commenting on them. Even if QA think the bug needs more info, if they can guess at a component they should move it there, I would think. Right now I see a lot of bugs left in Firefox:General that obviously don't belong there.
Gervase Markham wrote: > If all or most of those bugs went into either Firefox/General or > Thunderbird/General and had to be triaged out of there by the QA team, > would it be much more effort overall than the current triage process > where we have to monitor every component for badly-filed bugs, as well > as sorting those that end up in the General components anyway?
There are often bugs which do fall into the general component because it isn't under the scope of any others. If we changed the concept of the general to an untriaged component, it makes keeping these bugs live difficult.
Also, it's often very hard (at least for Thunderbird) to figure out where the bug belongs. "Copying fails" could refer to either an IMAP problem (Networking: IMAP), a UI disconnect (probably MWFE), a local folders problem (Database or Backend), or some other as-yet undetermined problem. It took one reply for me to determine that it was an IMAP-related problem, and another reply to determine that something borked itself in the middle. So where does it belong?
> My understanding was that the convention is that Version is the > earliest-affected version (and Target Milestone, once the bug is fixed, > is the first non-affected version). But this fails to a certain extent > in the presence of multiple branches. But then again, a lot of Bugzilla > doesn't cope well with multiple branches. There have been proposals to > fix this, but getting the data model and the UI right is Hard.
Two proposals (doable with the status quo): 1. Autofill version from the build identifier. 2. Set version to "Trunk" if it's an enhancement.
> I think people still find OS useful, although we could make an argument > for trimming down the choices. I agree Hardware has probably outlived > its usefulness for us.
+1
> Do individual developers use this field for prioritizing their work?
I categorize mostly on "enhancement" and "normal," occasionally "critical"/"blocker" (i.e. a regression seriously hampering widely-used features). "trivial" seems useless to me, and I have bumped "minor"/"major" before. I don't think you'll get a lot of complaints if you remove "trivial" and perhaps "blocker."
> David E. Ross 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.
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 wrote: >> "Documentation: Help Viewer" is not really useful anymore > <snip>
> Just to be clear: sentences with "might" or "or" in them are not going > to result in any changes to the list of potential changes. When you have > discussed your problem and have consensus, you need to make a concrete, > specific proposal, and make sure that people who own that area (e.g. > KaiRo) have commented to say "Yes, I agree".
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...
Gervase Markham wrote: > We are currently getting 500 bugs a week in Firefox, Thunderbird, Core > and Toolkit (of which 177 or so were filed using the Bugzilla Helper).
How many of those were filed by experienced people who can guess components in many cases (yes, I know, we always have difficult cases)? And how many are filed by people who would not have any other clue than "General"?
Joshua Cranmer wrote: > There are often bugs which do fall into the general component because it > isn't under the scope of any others. If we changed the concept of the > general to an untriaged component, it makes keeping these bugs live > difficult.
No problem - we can have a "Triage" component. Or perhaps another word that more people know. "ToBeFiled"?
> Also, it's often very hard (at least for Thunderbird) to figure out > where the bug belongs.
Well, if that's true, what chance does the poor reporter have?
> "Copying fails" could refer to either an IMAP > problem (Networking: IMAP), a UI disconnect (probably MWFE), a local > folders problem (Database or Backend), or some other as-yet undetermined > problem. It took one reply for me to determine that it was an > IMAP-related problem, and another reply to determine that something > borked itself in the middle. So where does it belong?
Well, you keep it in the triage component until you find out :-)
> Two proposals (doable with the status quo): > 1. Autofill version from the build identifier.
That might lead people to erroneously conclude that it was not present in earlier versions.
There are at least three possible semantics for version:
1) Earliest version affected 2) Latest version affected 3) Version used by filer of bug
One good step would be to pick one and tell everyone to use it.
> 2. Set version to "Trunk" if it's an enhancement.
Robert Kaiser wrote: > Gervase Markham wrote: >> We are currently getting 500 bugs a week in Firefox, Thunderbird, Core >> and Toolkit (of which 177 or so were filed using the Bugzilla Helper).
> How many of those were filed by experienced people who can guess > components in many cases (yes, I know, we always have difficult cases)?
How would you like me to go about determining that number? :-)
David E. Ross wrote: > So something like Mnenhy (for Firefox and SeaMonkey) or Signature Switch > (for Thunderbird) -- both addons -- fall under Server Software although > they actually having nothing to do with servers? Will this not make > reporting bugs against extensions confusing?
I may be wrong, but my understanding is that Bugzilla is not supposed to be the primary bug-tracking application for add-ons. We have this component because sometimes there are bugs in popular add-ons (e.g. "doesn't work with FF3") that we want to track. But day-to-day problems should go to the developer.
>>> 3. The use of "Components" as the parent of "Core", "MailNews Core", >>> "Directory", etc is somewhat confusing. Inherent in the Bugzilla >>> hierarchy, "Components" is the next level below "Product". >> I see the problem; care to propose an alternative?
> Make "Elements" the parent of "Core", etc.
I'm not sure "Elements" is any more understandable than "Components".
Stefan wrote: > Well, your original post said "If your idea isn't on there, please comment in mozilla.dev.planning to > start discussion of it.", so I expect "people who own that area" to comment...
Sure. It wasn't a criticism, just a clarification.
> 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".)
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.
> 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.
> 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.
>> 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.
Justin Dolske wrote: > I find this field fairly useless as-is, but it might be useful with > changes -- split it in 2, into a "last verified in version X" and "fixed > in version X" fields. [Replacing the fixedX.Y.Z keywords used now. And > you'd need a way to have 1 "fixed in" flag per branch.]
On Tue, Aug 26, 2008 at 10:42 AM, David E. Ross <nob...@nowhere.not> wrote:
> >From recent comments in bug #395967, there appears to be no interest in > having any kind of bug-reporting for addons.
...in the Bugzilla install at bugzilla.mozilla.org.
> In other words, what works for Mozdev will not work for Addons.
I'm not sure what this means. Mozdev works if addon authors want to use it. As far as I can tell, there hasn't been a large demand from addon authors for a b.m.o component they can use to track their bugs, and Mozdev's existence surely has something to do with that.
> With some addons, however, reporting a problem directly to the developers > is equivalent to communicating with a black hole. :(
Why would you expect an Addons component on b.m.o to improve that situation? If an extension developer isn't responsive to feedback I don't see how adding another method of submitting feedback will help. It might help extension users consolidate feedback and discussion, but that's not what Bugzilla is meant for.
Mike Beltzner wrote: > On 25-Aug-08, at 7:26 AM, Gervase Markham wrote:
>> Benjamin Smedberg wrote: >>> I think that if you phrase the discussion this way, you're not going >>> to deal >>> with the fundamental problems in our bug tracker.
>> First, an on-topic reply:
>> Figuring out how to fix the problems you outline is a far larger task >> than I am attempting here. They may also be more important, but I want >> to finish (for some value of "finish") one job before starting another.
> I don't know that it is.
Well OK, whatever :-) I'm happy to have the discussion, whether we could it as related to or unrelated to the reorg.
> Perhaps I'm dreaming, but I would love to see a resurgence in the > importance and value of the contributor known as the "triager". This is > a person who looks through UNCO and "General" bugs and tries to move > them along in the right direction. The work queue is easy to set up (we > can put those queries on the front bugzilla page) and it's a great way > to get involved with the project.
I think we may be converging on this truth.
> This would be a great idea, and the Bugzilla Helper can probably be > easily tweaked. Another good way is to reduce the complexity by, as Ben > proposed, removing options that aren't really helpful when tracking and > managing bugs.
Removing entirely? Or removing from the filing process?
David E. Ross wrote: > From recent comments in bug #395967,
(I'm rather surprised no-one thought to CC me on that bug.)
> there appears to be no interest in > having any kind of bug-reporting for addons.
Rather, there appears to be no interest in having mozilla.org host a bug-reporting system for individual addons. That's not the same thing.
> In other words, what works > for Mozdev will not work for Addons. With some addons, however, > reporting a problem directly to the developers is equivalent to > communicating with a black hole. :(
Then putting the problem into bugzilla.mozilla.org is unlikely to have any different effect.
> As an alternative, how about "Kernels"?
That definitely has other, confusing connotations. :-(
>> 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)...
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.
Gervase Markham wrote: >> This would be a great idea, and the Bugzilla Helper can probably be >> easily tweaked. Another good way is to reduce the complexity by, as Ben >> proposed, removing options that aren't really helpful when tracking and >> managing bugs.
> Removing entirely? Or removing from the filing process?
I believe the three fields I proposed should be removed entirely.
Hey Folks. For those who don't know, I'm mkanat from the Bugzilla Project, but Google Groups won't let me send from that email address for some unfathomable reason (even though it's linked to this Google Account).
All of the things that are being discussed in this thread--the removal of fields, creating a simpler bug entry process, dealing with branches--these are all things that we have discussed and planned about extensively within the Project. In addition to the fact that for years I answered vast numbers of mails on the support-bugzilla mailing list, I personally do Bugzilla consulting for a living (the Mozilla Corporation being one of my clients), and I have seen these problems and discussed them broadly with possibly hundreds of organizations.
The Bugzilla developers are almost always available on IRC, in #mozwebtools. In addition, I could probably be personally available to come into the Mountain View office and discuss solutions or make suggestions.
Granted, Bugzilla is not a Mozilla-only system--it's used by thousands of organizations around the world. But we *are* very close as organizations, and if you want to come to us with questions about these things, please do. I doubt we'd be open to authoritarian instructions on how we should proceed with the Project, but we *would* be very open to a statement like, "Hey, here's a real problem that we have, backed up by evidence. We thought about solving it this way, what have you guys thought about?"
As a developer, I'm really opposed to duplication of effort. I think that in many cases, before having a long discussion about "How can we extensively customize bugzilla.mozilla.org to solve our specific problems," it would be valuable to come to us, the Bugzilla Project, and ask "Do you guys have any plans or thoughts about this? When is the next release coming out? Do you need any help?" We have lots of thoughts and ideas about all of these problems, based on very broad experience, and I'm sure we'd be happy to contribute our thoughts.
|
