Bug Importance

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

Re: Bug Importance

Justin Wood (Callek)-2
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.
>

Outside of Core:: It is used (for some teams) quite heavily. e.g. IT
uses it to prioritize to a degree. such that depending on the importance
and the overall length a bug was open, etc. it might start paging people.

That is to say, if we can hide it for most of the project and only show
it where needed (or hide it and create a new field where
needed/makes-more-sense that could work as well)

--
~Justin Wood (Callek)

_______________________________________________
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 Frédéric Buclin
On 4/4/12 3:46 PM, Frédéric Buclin wrote:
> 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. ;)

You don't understand.  It's users, especially bugzilla newbies, who keep
complaining that the fields are "set wrong".  The product managers are
not the problem here.

The right solution is to hide the field in components where it's not
being used.

-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

Gavin Sharp-3
In reply to this post by Frédéric Buclin
2012/4/4 Frédéric Buclin <[hidden email]>:
> 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.

To you. Not to other users of b.m.o. We hit this wall every time
someone suggests making a change to b.m.o - there are many different
teams/projects sharing the one Bugzilla instance, and they all have
different habits, workflows, and norms. I think improving Bugzilla
would be a lot easier if proposed changes were implementable at the
Bugzilla "product" level, rather than site-wide. It shouldn't be
impossible to only hide certain fields for the
Core/Firefox/Toolkit/etc. products.

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

Re: Bug Platform

Steve Fink-4
In reply to this post by David Bruant-5
On 04/04/2012 11:25 AM, David Bruant wrote:

> 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.

Platform means two totally different things, and neither is relevant
very often. (The two things are what platform was used to file the bug,
and what platform is believed to be affected by the bug.) It seems like
the best solution would be to split up those two meanings, and only set
the affected platform when explicitly deciding that it is relevant. So I
would propose: (1) have a custom field "reporter-platform" that is
automatically filled in when reporting a bug; (2) default the current
Architecture and Platform fields to 'unknown' or 'unset' (not 'all');
and (3) encourage people to only set the platform when it is believed to
be relevant. I'd prefer it if reporter-platform showed up in the inline
history display but nowhere else by default.

Then again, platform is so rarely relevant to me personally that fixing
any of this is low priority, so I'm just throwing out that proposal as
an idea for anyone who cares. I'd also note that "platform" is
unavoidably a rough approximation; sometimes the platform should be "any
POSIX system" or "system without hardware OpenGL acceleration" or
whatever. (In fact, this is the first I've noticed that architecture and
platform are separate, which is cool.)

I should note that I'm one of the jerks who regularly files a bug
observed on one system into bugzilla running on another system on a
different platform, and many bugs I file these days I do through a
script that doesn't bother with the platform at all. I will set the
platform when it is relevant, though, but there's no way to distinguish
those now.

>
> 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

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

Re: Bug Importance

Steve Fink-4
In reply to this post by Frédéric Buclin
On a previous project where we actively made use of the priority field,
*only* the assignee would ever set priority. So really priority was only
meaningful within the subset of bugs assigned to a given developer. If
you took over somebody's bug, you'd set the priority according to your
personal prioritization (or reset it to the default if you didn't want
to think about it yet.) In that way, the priority field could be used
both as a personal TODO list as well as a communication mechanism for
people who wondered when a given bug was likely to be fixed. Managers
and users would never set the field. Well, ok, they would, but then it'd
be wrong and either reset or ignored. If they felt a bug was important
to be fixed, they'd set 'severity' accordingly.

I sort of assumed that was the standard bugzilla policy.

It seems like a workable system, and far better than attempting to do
product management via bugzilla priority fields. That generally seems to
produce way too much bug churn, and our product managers liked juggling
spreadsheets far better anyway.

On 04/04/2012 12:46 PM, Frédéric Buclin wrote:

> 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

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

Re: Bug Importance

Scott Johnson-22
On Wed 04 Apr 2012 01:17:44 PM PDT, Steve Fink wrote:

> On a previous project where we actively made use of the priority field,
> *only* the assignee would ever set priority. So really priority was only
> meaningful within the subset of bugs assigned to a given developer. If
> you took over somebody's bug, you'd set the priority according to your
> personal prioritization (or reset it to the default if you didn't want
> to think about it yet.) In that way, the priority field could be used
> both as a personal TODO list as well as a communication mechanism for
> people who wondered when a given bug was likely to be fixed. Managers
> and users would never set the field. Well, ok, they would, but then it'd
> be wrong and either reset or ignored. If they felt a bug was important
> to be fixed, they'd set 'severity' accordingly.

This is how I've been using the priority field, too. Should I stop
doing this? What method is used to prioritize bugs within a developer's
task list? I would hope the spreadsheet approach isn't the most widely
used...

> On 04/04/2012 12:46 PM, Frédéric Buclin wrote:
>> 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
>
> _______________________________________________
> 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

Mike Hommey
In reply to this post by Justin Wood (Callek)-2
On Wed, Apr 04, 2012 at 03:47:18PM -0400, Justin Wood (Callek) wrote:

> 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.
> >
>
> Outside of Core:: It is used (for some teams) quite heavily. e.g. IT
> uses it to prioritize to a degree. such that depending on the
> importance and the overall length a bug was open, etc. it might
> start paging people.
>
> That is to say, if we can hide it for most of the project and only
> show it where needed (or hide it and create a new field where
> needed/makes-more-sense that could work as well)

Or default to an empty value. If it is set, then you know it is meant to
be useful (or an expression of the annoying behaviour of bugzilla with
session restore).

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

Re: Bug Importance

David E. Ross-3
In reply to this post by Boris Zbarsky
On 4/4/12 12:51 PM, Boris Zbarsky wrote:

> On 4/4/12 3:46 PM, Frédéric Buclin wrote:
>> 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. ;)
>
> You don't understand.  It's users, especially bugzilla newbies, who keep
> complaining that the fields are "set wrong".  The product managers are
> not the problem here.
>
> The right solution is to hide the field in components where it's not
> being used.
>
> -Boris

Which components are those?

--

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

Gavin Sharp-3
On Wed, Apr 4, 2012 at 2:32 PM, David E. Ross <[hidden email]> wrote:
>> The right solution is to hide the field in components where it's not
>> being used.
>>
>> -Boris
>
> Which components are those?

All of the "Core" Mozilla product components - Core, Firefox,
Thunderbird, Toolkit, etc.

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

Re: Bug Importance

David E. Ross-3
In reply to this post by David E. Ross-3
On 4/4/12 2:37 PM, Gavin Sharp wrote:

> On Wed, Apr 4, 2012 at 2:32 PM, David E. Ross <[hidden email]> wrote:
>>> The right solution is to hide the field in components where it's not
>>> being used.
>>>
>>> -Boris
>>
>> Which components are those?
>
> All of the "Core" Mozilla product components - Core, Firefox,
> Thunderbird, Toolkit, etc.
>
> Gavin

So even end-users such as I am can submit RFE bug reports for new or
changed features and mark them Normal instead of Enhancement?

--

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

Gavin Sharp-3
On Wed, Apr 4, 2012 at 4:34 PM, David E. Ross <[hidden email]> wrote:
> So even end-users such as I am can submit RFE bug reports for new or
> changed features and mark them Normal instead of Enhancement?

You (or anyone else) can mark them however you'd like - that field
just doesn't change anyone's behavior in any significant way, so its
value is ignored in practice.

Gavin
_______________________________________________
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 12:00:08 PM UTC-7, Ben Bucksch wrote:
> 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.

I wanted to avoid cluttering bugs with more weird notations, but I may end up having to do that in order to keep things straight.
_______________________________________________
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 L. David Baron
"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?"

+1. I have started trying to comment more in bugs about what we're planning, but that doesn't scale to all the bugs.

On Wednesday, April 4, 2012 12:08:48 PM UTC-7, 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}
>
> 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

Alexander Surkov
In reply to this post by L. David Baron
I track bugs having major importance in accessibility module. This
flag is used for bugs crucial for ATs. So in general I need two
importance values: normal and major. If crashes would be mapped to
major importance then it's still ok, excepting top crashers perhaps
(but I don't use importance field for those). But anyway I definitely
miss importance field if you get rid it at all.

Thanks.
Alex.


On Thu, Apr 5, 2012 at 3:06 AM, L. David Baron <[hidden email]> 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

Dave Townsend
In reply to this post by L. David Baron
On 04/04/12 17:40, Dave Mandelin wrote:
> "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?"
>
> +1. I have started trying to comment more in bugs about what we're planning, but that doesn't scale to all the bugs.

In the Add-on SDK product we keep things pretty simple. We ignore the
severity field but use the priority field P1-P3 to mean need/want/nice
to have. The problem of course is that even though we weekly triage new
bugs to assign these, those values often get outdated.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

glob
In reply to this post by Gavin Sharp-3
Gavin Sharp wrote:
> On Wed, Apr 4, 2012 at 2:32 PM, David E. Ross<[hidden email]>  wrote:
>>> The right solution is to hide the field in components where it's not
>>> being used.
>> Which components are those?
> All of the "Core" Mozilla product components - Core, Firefox,
> Thunderbird, Toolkit, etc.
hiding the fields on a per-product basis would be an easy change to both
the non-guided enter_bug and show_bug forms.
i've filed bug 742634 to track this.

hiding the field on a per-component basis is non-trivial and probably
won't happen.


David Bruant wrote:
> 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 feel the crux of the problem is the dual usage of the platform field;
it's used to track both "the reporter's platform" and "this bug applies
to this platform".

note users who are new to bugzilla get a completely different bug entry
form/experience from what you're probably seeing (try switching to the
bugzilla helper from the enter_bug page).  the guided bug entry form
(aka bugzilla helper) always prepends the reporter's user-agent to
comment 0, and performs platform/os detection on a limited subset of
products (firefox, fennec, seamonkey, camino, core, and thunderbird).  
on all other products the platform/os is set to "all".  firefox bugs are
forced into an "untriaged bugs" component, which enables some triage
love so there's a reasonable chance the platform/os fields will have
saner values by after triage.

non-guided bug management is yet to be updated.

possible changes for non-guided bug entry is to always prepend the
reporter's user agent to comment 0, and default the platform to "all"
for all products.
or add a read-only field (shudder, more fields) which captures the
reporter's user agent, and default the platform to "all".
or assume that if someone isn't using the guided form, they know what
they are doing, and default platform/os to "all" without capturing the
reporter's platform information.


--
byron - irc:glob - bugzilla.mozilla.org team -

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

Re: Bug Importance

Justin Dolske-2
In reply to this post by Boris Zbarsky
On 4/4/12 12:51 PM, Boris Zbarsky wrote:

> On 4/4/12 3:46 PM, Frédéric Buclin wrote:
>> 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. ;)
>
> You don't understand. It's users, especially bugzilla newbies, who keep
> complaining that the fields are "set wrong". The product managers are
> not the problem here.
>
> The right solution is to hide the field in components where it's not
> being used.

Yes. Though there are two problems intertwined here:

The immediate issue is that we have many components (effectively most of
the things that ship in Firefox) where these fields are meaningless and
unused. We should hide them, and eliminate an obvious point of confusion.

The more idealistic issue is finding the right degree of homogeneity
across bugzilla. It would suck for users to have to deal with or
understand multiple systems for how bugs are managed; but OTOH it also
seems a bit unfair to require everyone to conform to one system. Not
sure what the answer is here. It feels a bit like dueling goals... We
have enough diversity in BMO products/components that multiple ways of
managing could make sense, but at the same time the bigger Mozilla gets
the more useful it is to have consistency across areas. Perhaps the
answer lies in a clear difference between fields of relevance to
end-users vs those who drive a component. The blocking/tracking/approval
flags are, loosely, and example of this.

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

Re: Bug Importance - Simplifying

Mark Banner-4
In reply to this post by David E. Ross-3
On 04/04/2012 22:37, Gavin Sharp wrote:

> On Wed, Apr 4, 2012 at 2:32 PM, David E. Ross<[hidden email]>  wrote:
>>> The right solution is to hide the field in components where it's not
>>> being used.
>>>
>>> -Boris
>>
>> Which components are those?
>
> All of the "Core" Mozilla product components - Core, Firefox,
> Thunderbird, Toolkit, etc.

Err wrong. Thunderbird, MailNews Core use at least the enhancement and
normal levels of Importance (we also use critical for crashes, but that
tends to be duplicated by the "crash" keyword.

Minor/Major and Blocking do get used, but not that extensively IMO.

Off the top of my head, I'd say we could probably remove that severity
field and replace it by one checkbox: enhancement.

Although I realise not everyone uses the enhancement field, we do get
lots of requests for enhancement, and I'd rather keep that distinction.

The other options would be either obsolete or indicated by keywords.

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

Re: Bug Platform

Mounir Lamouri-3
In reply to this post by Steve Fink-4
On 04/04/2012 10:06 PM, Steve Fink wrote:

> Platform means two totally different things, and neither is relevant
> very often. (The two things are what platform was used to file the bug,
> and what platform is believed to be affected by the bug.) It seems like
> the best solution would be to split up those two meanings, and only set
> the affected platform when explicitly deciding that it is relevant. So I
> would propose: (1) have a custom field "reporter-platform" that is
> automatically filled in when reporting a bug; (2) default the current
> Architecture and Platform fields to 'unknown' or 'unset' (not 'all');
> and (3) encourage people to only set the platform when it is believed to
> be relevant. I'd prefer it if reporter-platform showed up in the inline
> history display but nowhere else by default.

IIRC, when you do not have certain bits enabled on your account, you
have to go trough a special form to file a bug and this form will
automatically add the UA used to file the bug. This is this same UA that
is used by bugzilla to set the 'Platform' fields so the information is
redundant in that case.
If you have the specific bit enabled, that means you know how to file a
bug and you will very likely add that information if it seems relevant.
In addition, setting the platform using the current UA means nothing
because I might see a bug on a system and file it with another. For
example, I do not file bugs with my phone.

Given that, IMO, we should always set the 'Platform' field to ALL/ALL by
default.

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

Re: Bug Platform

Philip Chee
In reply to this post by Steve Fink-4
On Thu, 05 Apr 2012 11:12:56 +0200, Mounir Lamouri wrote:

> Given that, IMO, we should always set the 'Platform' field to ALL/ALL by
> default.

At the risk of bike-shedding, may I suggest instead
UNSPECIFIED/UNSPECIFIED (or Undefined or TBD)?

Phil

--
Philip Chee <[hidden email]>, <[hidden email]>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12345