[sf-perl] Bug management / time management

[Steve Fink]

On 5/9/07, Andy Lester <andy at petdance.com> wrote:
>
> On May 9, 2007, at 4:27 PM, Steve Fink wrote:
>
> > One thing I'm surprised nobody has brought up is the distinction
> > between severity and priority.
>
> Severity can help drive priority, but it's not the only determinant.
> A bug might cause your Apache to crash, but only once a year on New
> Years Eve.  It's a severe bug, but might not be a high priority.

I fully agree. That's why it's useful to keep both fields separately.

Although with your specific example, I would hope that the requester
would mark the annual crash bug as lower severity than the bad data
one. Severity is intended to be the impact on the user, not some
objective measure of how hard the system goes down when the issue is
encountered.

In your terms, severity is the cost of having the bug still be there,
and that is used in conjunction with the cost of fixing the bug to
determine the priority. Or, if you're not explicitly tracking
priority, the two together determine when someone gets around to
fixing it. :-) Of course, I'd usually leave it up to the development
team to make those decisions, with the understanding that if they
don't take the severity into account when choosing priorities (==
deciding what to work on, and in what order), that they aren't serving
the needs of their users very well and might want to start stealing
more office supplies in case they don't have the opportunity too much
longer...

But depending on your setup, it may work fine for someone else to do
the prioritization, as long as the developers pay attention to it.