Bug priorities (Re: Change in Bugzilla's defaults)

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

Bug priorities (Re: Change in Bugzilla's defaults)

Rob Lanphier
On Wed, Apr 13, 2011 at 12:44 PM, Krinkle <[hidden email]> wrote:
> I agree. Defaulting new bugs to a low priority doesn't seem very
> friendly
> to new users. They don't know (and shouldn't have to know) what the
> bugmeister's organization is.

I thought about replying with a similar response, but then I realized
that if Mark stays on top of incoming bugs (which is his job), he'll
be able to bump bugs up to normal as they come in, which should
actually make those people good, and provide some automatic positive
reinforcement for filing important bugs.  I suspect most people won't
even notice that the bug defaults to "low", and they'll be able to fix
it if they disagree.  I suppose the best thing would be to have a
blank priority (or "triage" as OQ suggests), so that we could query
for the bugs that haven't been explicitly prioritized, but I don't
know if that's possible.

This isn't so narrowly focused on the bugmeister as it is starting to
pay attention to the priority field as a community.  All priorities
should have a meaning for us.  We can debate about what is "correct",
but here's what my thinking is:

1.  "Highest" - this means a bug that someone is either working on
*right now*, or at least should be working on right now.  No developer
should have more than one "highest" priority bug, and anything marked
"highest" priority shouldn't stay unassigned for more than a week.
2.  "High" - this means that a bug is in the relatively-small pool of
bugs that will likely get bumped to "highest" priority.  Bugs at this
priority should, at a minimum, be blockers for the next release of the
software.
3.  "Normal" - these are bugs that really should get fixed for the
next release of the software.  They aren't necessarily blockers, and
we may grit our teeth and have a release or two with this bug, but
there's no way we should go two releases with a "normal" priority bug.
4.  "Low" - these are bugs that we won't actively manage.  They may be
important to some people, and someone may get around to fixing the
problem, but no developer is committed to working on a fix
5.  "Lowest" - these are bugs that pretty much everyone agrees aren't
terribly important (including the reporter).

I'm not wedded to these exact definitions, but I'm pretty wedded to
the idea that we should agree on something.  I don't think we should
consider it "normal" to have bugs go for years without activity.

From a practical perspective, many more bugs than are being marked as
"normal" are actually "normal" by this standard.  Most of the bugs in
our database are probably "low" priority in the sense that we just
can't get around to fixing all of them.  I can see the argument for
making the most common case the default (though I share others
uneasiness with doing so).

Rob

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Bug priorities (Re: Change in Bugzilla's defaults)

Brion Vibber
On Wed, Apr 13, 2011 at 1:15 PM, Rob Lanphier <[hidden email]> wrote:

> From a practical perspective, many more bugs than are being marked as
> "normal" are actually "normal" by this standard.  Most of the bugs in
> our database are probably "low" priority in the sense that we just
> can't get around to fixing all of them.  I can see the argument for
> making the most common case the default (though I share others
> uneasiness with doing so).
>

It may be worth having an "unassigned" initial priority, which we can treat
as equivalent to "low".

-- brion
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Bug priorities (Re: Change in Bugzilla's defaults)

Mark A. Hershberger
Brion Vibber <[hidden email]> writes:

> On Wed, Apr 13, 2011 at 1:15 PM, Rob Lanphier <[hidden email]> wrote:
>
>> From a practical perspective, many more bugs than are being marked as
>> "normal" are actually "normal" by this standard.  Most of the bugs in
>> our database are probably "low" priority in the sense that we just
>> can't get around to fixing all of them.  I can see the argument for
>> making the most common case the default (though I share others
>> uneasiness with doing so).
>
> It may be worth having an "unassigned" initial priority, which we can treat
> as equivalent to "low".

We can do this, I think, by changing the bug's state from “NEW” to
“ASSIGNED”.

Mark.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Bug priorities (Re: Change in Bugzilla's defaults)

Platonides
In reply to this post by Rob Lanphier
> From a practical perspective, many more bugs than are being marked as
> "normal" are actually "normal" by this standard.  Most of the bugs in
> our database are probably "low" priority in the sense that we just
> can't get around to fixing all of them.  I can see the argument for
> making the most common case the default (though I share others
> uneasiness with doing so).

A good thing is that if the default is normal and the bugmeister then
lowers it, that gives a negative feedback to the reporter, whereas if
it's as the default, it doesn't.

Most bugs that are bugs should be normal, but perhaps we don't have the
resources to fix each of them.


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l