Bug Importance

classic Classic list List threaded Threaded
84 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Bug Importance

David E. Ross-3
I am seeing a number of bugzilla.mozilla.org bug reports submitted by
Mozilla developers with the Importance set at Normal.

The stated definition of "Normal" is a software error that involves
"some loss of functionality under specific circumstances" while these
bug reports clearly fail to identify any software error at all.  Instead
these bug reports involve a "request for enhancement", which has the
Importance set at Enhancement.

Is no one monitoring this situation?

--

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

Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
© 1997 by David E. Ross
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Boris Zbarsky
On 4/4/12 1:41 PM, David E. Ross wrote:
> Is no one monitoring this situation?

Yep.  I certainly pretty much ignore the Importance field, both when
filing and when prioritizing bugs, since it's usually noise, except when
explicitly set to blocker or critical.  And even then it's often noise.

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Kevin Brosnan-2
In reply to this post by David E. Ross-3
On Wednesday, April 04, 2012 10:41:24, David E. Ross wrote:

> I am seeing a number of bugzilla.mozilla.org bug reports submitted by
> Mozilla developers with the Importance set at Normal.
>
> The stated definition of "Normal" is a software error that involves
> "some loss of functionality under specific circumstances" while these
> bug reports clearly fail to identify any software error at all.  Instead
> these bug reports involve a "request for enhancement", which has the
> Importance set at Enhancement.
>
> Is no one monitoring this situation?
>

Different products have different rules for how they manage bugs. For
example the mobile group, anything in Fennec/Fennec Native, only uses
the priority field in Bugzilla for tracking how important a fix is.

Kevin
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

L. David Baron
In reply to this post by David E. Ross-3
On Wednesday 2012-04-04 10:41 -0700, David E. Ross wrote:

> I am seeing a number of bugzilla.mozilla.org bug reports submitted by
> Mozilla developers with the Importance set at Normal.
>
> The stated definition of "Normal" is a software error that involves
> "some loss of functionality under specific circumstances" while these
> bug reports clearly fail to identify any software error at all.  Instead
> these bug reports involve a "request for enhancement", which has the
> Importance set at Enhancement.
>
> Is no one monitoring this situation?

I think the best solution would be to remove the Importance field
from bugzilla.mozilla.org.  My impression is that the Importance
field is generally ignored, so suggesting to people that they should
spend time setting it correctly is wasting their time.

-David

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Ben Bucksch
In reply to this post by David E. Ross-3
On 04.04.2012 19:41, David E. Ross wrote:
> I am seeing a number of bugzilla.mozilla.org bug reports submitted by
> Mozilla developers with the Importance set at Normal.
> ...these bug reports involve a "request for enhancement"
>
> Is no one monitoring this situation?

I also closely monitor the fact that people file bugs with OS: Linux,
although the bug applies to all operating systems and CPUs. This is
directly discriminating those other OSes, and I object to that.

In addition, I also monitor people who post from "nowhere". This is an
unbearable situation.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Boris Zbarsky
In reply to this post by David E. Ross-3
On 4/4/12 2:06 PM, L. David Baron wrote:
> I think the best solution would be to remove the Importance field
> from bugzilla.mozilla.org.

Amen.

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Jeff Hammel-2
In reply to this post by Ben Bucksch
On 04/04/2012 11:07 AM, Ben Bucksch wrote:

> On 04.04.2012 19:41, David E. Ross wrote:
>> I am seeing a number of bugzilla.mozilla.org bug reports submitted by
>> Mozilla developers with the Importance set at Normal.
>> ...these bug reports involve a "request for enhancement"
>>
>> Is no one monitoring this situation?
>
> I also closely monitor the fact that people file bugs with OS: Linux,
> although the bug applies to all operating systems and CPUs. This is
> directly discriminating those other OSes, and I object to that.
I also have a bit of an allergy to people that don't put in platform
correctly.  I understand why the default is there -- to get as much info
as possible from people who may not be filling out a bug report
correctly, typically those new to bugzilla.  But, especially (?) not
working on mozilla-central, I see many things that are blatantly
misfiled.  This wouldn't matter so much if it weren't for another class
of bugs: bugs that *could* be for a particular platform, but that I
highly *suspect* are not.  Then I'm forced to ask in the bug if the
platform was actually meant, and if it was I have sometimes been met
with a harsh reply. </rant>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Joshua Cranmer-2
In reply to this post by David E. Ross-3
On 4/4/2012 12:41 PM, David E. Ross wrote:

> I am seeing a number of bugzilla.mozilla.org bug reports submitted by
> Mozilla developers with the Importance set at Normal.
>
> The stated definition of "Normal" is a software error that involves
> "some loss of functionality under specific circumstances" while these
> bug reports clearly fail to identify any software error at all.  Instead
> these bug reports involve a "request for enhancement", which has the
> Importance set at Enhancement.
>
> Is no one monitoring this situation?
>
The distinction between an RFE and a bug is extremely fuzzy (which one
would 'not supporting the latest version of some protocol' fall under?).
The main rationale for the Importance is to indicate how critical it is
to be fixed, but we already track priority of fixes via other means. If
a developer is being paid to work on something, it doesn't matter all
that much if a bug is an enhancement or normal. I only make a
distinction in queries sometimes to exclude UNCONFIRMED enhancements
from aggregate counts since these are largely feature proposals that
will probably never got fixed but no one wants to actually discuss if it
would be WONTFIX or not.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Dave Mandelin-2
In reply to this post by Boris Zbarsky
On Wednesday, April 4, 2012 10:57:57 AM UTC-7, Boris Zbarsky wrote:
> On 4/4/12 1:41 PM, David E. Ross wrote:
> > Is no one monitoring this situation?
>
> Yep.  I certainly pretty much ignore the Importance field, both when
> filing and when prioritizing bugs, since it's usually noise, except when
> explicitly set to blocker or critical.  And even then it's often noise.
>
> -Boris

In JS, I completely ignore that field as noise.

It's kind of a problem because making sure the important bugs gets fixed does require tracking bug importance. A free-for-all importance field doesn't generate valid data, though, at least not with the current set of norms and practices.

I keep a text file on the side to track important bugs, but that's not a very good system either--I'd love to be able to share that info more easily.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Bug Platform (was: Re: Bug Importance)

David Bruant-5
In reply to this post by Jeff Hammel-2
Le 04/04/2012 20:15, Jeff Hammel a écrit :

> On 04/04/2012 11:07 AM, Ben Bucksch wrote:
>> On 04.04.2012 19:41, David E. Ross wrote:
>>> I am seeing a number of bugzilla.mozilla.org bug reports submitted by
>>> Mozilla developers with the Importance set at Normal.
>>> ...these bug reports involve a "request for enhancement"
>>>
>>> Is no one monitoring this situation?
>>
>> I also closely monitor the fact that people file bugs with OS: Linux,
>> although the bug applies to all operating systems and CPUs. This is
>> directly discriminating those other OSes, and I object to that.
> I also have a bit of an allergy to people that don't put in platform
> correctly.  I understand why the default is there -- to get as much
> info as possible from people who may not be filling out a bug report
> correctly, typically those new to bugzilla.  But, especially (?) not
> working on mozilla-central, I see many things that are blatantly
> misfiled.  This wouldn't matter so much if it weren't for another
> class of bugs: bugs that *could* be for a particular platform, but
> that I highly *suspect* are not.  Then I'm forced to ask in the bug if
> the platform was actually meant, and if it was I have sometimes been
> met with a harsh reply. </rant>
Could it be consider to set the platform field to "all" by default?
Or maybe the platform detected, but only for people who are new to Bugzilla?
I file bugs mostly on the JS engine or recently on devtools and these
issues are rarely related to one platform.

Also, some components (evangelism, documentation, marketing, websites,
etc.) don't need a platform at all.

I think it certainly made sense at the beginnings of Firefox to fill
this component, but I'm under the impression that platform-specific
issues have mostly been worked around and solutions for them are mature,
so fewer bugs are platform-specific now. Maybe it makes sense to default
to "all platform".

David
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Dave Mandelin-2
In reply to this post by Ben Bucksch
On Wednesday, April 4, 2012 11:15:19 AM UTC-7, Jeff Hammel wrote:

> On 04/04/2012 11:07 AM, Ben Bucksch wrote:
> > On 04.04.2012 19:41, David E. Ross wrote:
> >> I am seeing a number of bugzilla.mozilla.org bug reports submitted by
> >> Mozilla developers with the Importance set at Normal.
> >> ...these bug reports involve a "request for enhancement"
> >>
> >> Is no one monitoring this situation?
> >
> > I also closely monitor the fact that people file bugs with OS: Linux,
> > although the bug applies to all operating systems and CPUs. This is
> > directly discriminating those other OSes, and I object to that.
> I also have a bit of an allergy to people that don't put in platform
> correctly.  I understand why the default is there -- to get as much info
> as possible from people who may not be filling out a bug report
> correctly, typically those new to bugzilla.  But, especially (?) not
> working on mozilla-central, I see many things that are blatantly
> misfiled.  This wouldn't matter so much if it weren't for another class
> of bugs: bugs that *could* be for a particular platform, but that I
> highly *suspect* are not.  Then I'm forced to ask in the bug if the
> platform was actually meant, and if it was I have sometimes been met
> with a harsh reply. </rant>

+1. For user-sourced bugs, it can be useful to know the system of the reporters, but you can get that info just by asking. And if multiple users are giving info in the bug, you can *only* get the system of the other users by asking.

Cryptic aside: the way *all* key information (importance, affected platforms, etc.) is tracked in bugzilla feels hopelessly 20th-century-old-school-small-project to me.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Ben Bucksch
In reply to this post by Ben Bucksch
On 04.04.2012 20:15, Jeff Hammel wrote:
> bugs that *could* be for a particular platform, but that I highly
> *suspect* are not.  Then I'm forced to ask in the bug if the platform
> was actually meant, and if it was I have sometimes been met with a
> harsh reply.

In those cases, the "pp" (= platform parity) keyword should be added. I
also like the platform in the bug summary, e.g. "[Mac] Toolbar is too
high", as I think both add significant clarity.

(For the record, my post before was ironic.)
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Platform

Daniel Holbert-3
In reply to this post by David Bruant-5
On 04/04/2012 11:25 AM, David Bruant wrote:
> Could it be consider to set the platform field to "all" by default?
[...]
> I think it certainly made sense at the beginnings of Firefox to fill
> this component, but I'm under the impression that platform-specific
> issues have mostly been worked around and solutions for them are mature,

I still see bugs for platform-specific rendering issues. (whether
they're from graphics / printing / font differences / UA-sniffing)

I'd make two claims about the platform field:

 (1) For a lot of bugs (e.g. "Implement New Feature X") it's not
important what the field's default value is -- it's not going to cause
confusion.

 (2) For the bugs where the Platform field _might_ actually be relevant
(e.g. "Firefox prints/renders this page incorrectly"), then Bugzilla's
existing default (the bug-reporter's platform) is clearly the right
behavior.  The bug could turn out to be cross-platform, but we shouldn't
assume that until it's been reproduced on another platform.  (otherwise
someone might come along, misinterpret platform="All", and resolve the
bug as WORKSFORME since they can't reproduce it on their system)

On 04/04/2012 11:38 AM, Ben Bucksch wrote:
> (For the record, my post before was ironic.)

That's what I suspected.  But now look what you've started! ;)

~Daniel
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Ben Bucksch
In reply to this post by Dave Mandelin-2
On 04.04.2012 20:24, Dave Mandelin wrote:
> I keep a text file on the side to track important bugs, but that's not a very good system either--I'd love to be able to share that info more easily.

If you're a manager, the currently used hack is to use the whiteboard to
add [Dave:Cri] or similar. Of course, that doesn't scale.

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Alexander Keybl
In reply to this post by L. David Baron
That sounds like a chicken and egg problem - if we think that there could be significant value in the field, then we just need to start using it more. We need to make sure we understand what it's offering us now (hardly anything) and what it could do for us (more granularity, transparency, and better prioritization) before removing it entirely from bugzilla.mozilla.org. For sake of clarity, we'd be giving up on

        Importance: P1-P5, {blocker, critical, major, normal, minor, trivial, enhancement}

and presumably continuing to rely upon tracking/status flags, feature pages, whiteboard entries, and offline methods for prioritization. Shouldn't we strive for greater transparency into the priorities of our engineering teams, both for the sake of our community as well as our project managers?

-Alex

On Apr 4, 2012, at 11:06 AM, L. David Baron wrote:

> On Wednesday 2012-04-04 10:41 -0700, David E. Ross wrote:
>> I am seeing a number of bugzilla.mozilla.org bug reports submitted by
>> Mozilla developers with the Importance set at Normal.
>>
>> The stated definition of "Normal" is a software error that involves
>> "some loss of functionality under specific circumstances" while these
>> bug reports clearly fail to identify any software error at all.  Instead
>> these bug reports involve a "request for enhancement", which has the
>> Importance set at Enhancement.
>>
>> Is no one monitoring this situation?
>
> I think the best solution would be to remove the Importance field
> from bugzilla.mozilla.org.  My impression is that the Importance
> field is generally ignored, so suggesting to people that they should
> spend time setting it correctly is wasting their time.
>
> -David
>
> --
> 𝄞   L. David Baron                         http://dbaron.org/   𝄂
> 𝄢   Mozilla                           http://www.mozilla.org/   𝄂
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

L. David Baron
On Wednesday 2012-04-04 12:08 -0700, Alex Keybl wrote:
> That sounds like a chicken and egg problem - if we think that there could be significant value in the field, then we just need to start using it more. We need to make sure we understand what it's offering us now (hardly anything) and what it could do for us (more granularity, transparency, and better prioritization) before removing it entirely from bugzilla.mozilla.org. For sake of clarity, we'd be giving up on
>
> Importance: P1-P5, {blocker, critical, major, normal, minor, trivial, enhancement}

Sorry, I meant to say the "Severity" field is what we should remove.
I think developers usefully use Priority, and it also defaults to
unset, which is a reasonable default, rather than a randomly chosen
value, which confuses people.

(Alternatively, we could make Severity default to unset.)

-David

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Benjamin Smedberg
In reply to this post by Alexander Keybl
On 4/4/2012 3:08 PM, Alex Keybl wrote:

Note that the field we're talking about is the *Severity* field. The
Importance field is P1-P5. The severity field is blocker->enhancement.
The new bugzilla UI has hidden the label for the Severity so most people
assume that they are the same. Most people see the field and assume that
the Importance field actually means something about how important the
bug is to fix. But in many cases it is more valuable/important to fix a
minor issue that affects lots of people than to fix a crasher which
affects almost nobody. So *sorting* by the field isn't that important,
and querying by the field seems equally unhelpful in almost all cases.
So then it's just human-readable metadata, which we might as well just
put into nice human-readable forms like the whiteboard.

> That sounds like a chicken and egg problem - if we think that there could be significant value in the field, then we just need to start using it more. We need to make sure we understand what it's offering us now (hardly anything) and what it could do for us (more granularity, transparency, and better prioritization) before removing it entirely from bugzilla.mozilla.org. For sake of clarity, we'd be giving up on
You also have to understand the potential costs of actually keeping the
data in the field correct, and the bugmail costs of having people argue
about/keep changing the field (which happened a lot when I first started
with the project).

--BDS

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

L. David Baron
On Wednesday 2012-04-04 15:17 -0400, Benjamin Smedberg wrote:
> On 4/4/2012 3:08 PM, Alex Keybl wrote:
>
> Note that the field we're talking about is the *Severity* field. The
> Importance field is P1-P5. The severity field is

Actually, to be clear, the P1-P5 is the "Priority" field.  That
shows up in the advanced query form.

> blocker->enhancement. The new bugzilla UI has hidden the label for
> the Severity so most people assume that they are the same. Most

The new bugzilla UI grouped the Priority and Severity fields into a
thing called "Importance".  I believe the P1-P5 was previously
consistently labeled as Priority, and blocker-enhancement as
Severity.

-David

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Alexander Keybl
In reply to this post by Benjamin Smedberg
> Note that the field we're talking about is the *Severity* field


Yep, I understand the differentiation you all are making now.

>> That sounds like a chicken and egg problem - if we think that there could be significant value in the field, then we just need to start using it more. We need to make sure we understand what it's offering us now (hardly anything) and what it could do for us (more granularity, transparency, and better prioritization) before removing it entirely from bugzilla.mozilla.org. For sake of clarity, we'd be giving up on
> You also have to understand the potential costs of actually keeping the data in the field correct, and the bugmail costs of having people argue about/keep changing the field (which happened a lot when I first started with the project).


Since we're now just talking about the severity, I don't have very strong feelings either way. If we had a more complete triage process in place, setting the severity would be a good first step (along with status/tracking flags) followed by setting the priority once assigned. Arguments could probably be avoided by only allowing the triagers and assignee to change the field.

-Alex

On Apr 4, 2012, at 12:17 PM, Benjamin Smedberg wrote:

> On 4/4/2012 3:08 PM, Alex Keybl wrote:
>
> Note that the field we're talking about is the *Severity* field. The Importance field is P1-P5. The severity field is blocker->enhancement. The new bugzilla UI has hidden the label for the Severity so most people assume that they are the same. Most people see the field and assume that the Importance field actually means something about how important the bug is to fix. But in many cases it is more valuable/important to fix a minor issue that affects lots of people than to fix a crasher which affects almost nobody. So *sorting* by the field isn't that important, and querying by the field seems equally unhelpful in almost all cases. So then it's just human-readable metadata, which we might as well just put into nice human-readable forms like the whiteboard.
>
>> That sounds like a chicken and egg problem - if we think that there could be significant value in the field, then we just need to start using it more. We need to make sure we understand what it's offering us now (hardly anything) and what it could do for us (more granularity, transparency, and better prioritization) before removing it entirely from bugzilla.mozilla.org. For sake of clarity, we'd be giving up on
> You also have to understand the potential costs of actually keeping the data in the field correct, and the bugmail costs of having people argue about/keep changing the field (which happened a lot when I first started with the project).
>
> --BDS
>

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Frédéric Buclin
In reply to this post by David E. Ross-3
Le 04. 04. 12 20:06, L. David Baron a écrit :
> I think the best solution would be to remove the Importance field
> from bugzilla.mozilla.org.

I disagree. As Kevin said, different products (teams) have different
rules to track bugs. A critical bug is not the same as a minor bug, and
also not the same as a request for enhancement. This distinction remains
important. As a product manager, you can decide that such or such RFE is
very valuable and should really be implemented, without being a blocker
(i.e. "we should really have it, but we won't block the next release on
it"). In that case, this bug would have a severity of enhancement, but
with priority P1 or P2. Then some real bug could be somewhat major, but
not critical, and then only with priority P3. And another bug could be
pretty minor (e.g. a typo in a web page, but very visible because it's
in the title of an often visited page) and marked as P1 anyway. So both
fields are not directly related.

You may then say that looking at the priority of a bug is enough and is
the field which contains the relevant information, but the priority
field is only useful to paid people who are forced to fix bugs in the
order you prioritize them. Free contributors, such as me, are probably
more interested by the severity of a bug to decide which ones to fix
during their free time, independently of the priority set to it. For
instance, I'm the main triager for the Bugzilla team, and all bugs with
severity major or above are closely watched. This doesn't mean they are
top priority, but they are important bugs to fix and should remain in
our mind, and when a clever idea/solution comes to mind, we should
implement it or at least describe it in the bug asap. At this point, the
bug may get a higher priority because we know how to fix it in a clean
and clever way. As a consequence, we have no bugs with severity blocker
or critical, and only 5 bugs with severity major.


> My impression is that the Importance
> field is generally ignored, so suggesting to people that they should
> spend time setting it correctly is wasting their time.

Your approach is wrong: stop suggesting people to fix this field if your
team ignores it. This is also valid for the platform/OS fields. Stop
asking users to fix these fields if you ignore them. Also, don't include
them in your queries if you don't care about them. You are blaming
Bugzilla when you should blame the product managers. ;)


LpSolit
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12345