[sf-perl] Bug management / time management

[Steve Fink]

One thing I'm surprised nobody has brought up is the distinction
between severity and priority. (Those are the bugzilla terms, but the
exact words aren't important. What is important is that they are two
independent concepts.)

Severity is how big of a problem the issue is. With a bug, that means
whether the submitter is prevented from accomplishing the task, or
whether it's just a small annoyance. In your case, it's similar -- the
requester needs something in order to accomplish *anything* vs they're
totally blocked on one task vs "wouldn't it be nice if..."

Priority is when the team is going to have it fixed/done. If you are
somebody at the receiving end of the task queue, then you will only
work on P1s until they are all gone, then you'll work on P2s. (Ok,
maybe there's only one P1 and somebody else is working on it, but
that's the idea.)

Or, in other words, severity is the priority of the task *to the
requester*, and priority is the priority of the task to the developer
(sysadmin, ...).

Many people do not make the distinction, and wonder why bugzilla
bothers to have two redundant fields. Admittedly, bugzilla messes up
by allowing the requester to set the priority, not just the severity.
If you stick to the intended meanings of the two fields, this makes no
sense. The requester can at most request a desired priority, but
obviously they're not going to take into account everyone else's
requests (and probably not their own past requests, either.)

Similarly, the developers/sysadmins/peons should normally not adjust
the severity. The severity is part of the description of what the
problem or task is from the point of view of the requester, so
adjusting the severity is destroying information even if you disagree
with it. The only time it makes sense to modify is if the requester
misunderstood what was going on and agrees with the change (in which
case, it would be better for the requester to change it himself, but
they'll probably never bother to so someone else may as well.)

If you're leaving severity alone and setting priority, then it *is*
useful to periodically do a scan for high-severity issues with low
priority. Those generally are (1) forgotten problems that should have
their priority raised, (2) disagreements over the nature or best
resolution of the issue, or (3) outdated or invalid requests. Don't
think you have to "fix" all of these, though; you'll see them often
enough in the next scan, until you're annoyed enough to go talk the
requester out of their unrealistic ideas. :-)

So you'll need to do regular triage meetings to establish the priority
of all of the tasks. Some people prefer for the resulting priorities
to give exactly the order of tasks in importance, but personally I
think that if you do that you'll needlessly create a discrepancy
between the issue database and reality. You're better off making the
priorities accurately reflect what order people are actually going to
work on things in. Sometimes that means boosting the priority of a
seemingly tiny issue just because it's easier for the developer to do
it in connection with another high-priority issue, or because it lays
the groundwork for other high-priority items.

Also, I'd recommend making a new bugzilla priority and severity named
"unassigned". Allowing them to have default values is dumb and loses
important information.

As for being swamped with work, think of it this way: you're going to
do X amount of work in a day. It's not going to go up if you have a
bigger backlog. So you're not actually swamped, you just feel that
way. (Ok, you can work nights and weekends, but productivity has this
tricky way of balancing out in the long run anyway...)

The only thing worth stressing about is whether you're working on the
*right* issues. You're never going to get that exactly right, either,
but if you do periodic triage and prioritization reviews, you can get
closer to the imaginary perfect ordering. As long as you're actively
balancing the amount of backlog management and actual task execution,
you're doing as well as you can.