package shepherding

[Mike A. Harris]

On Thu, 4 Mar 2004, Alexander Larsson wrote:

>> > I tend to not rely on them much. The problem with them is that the
>> > reporter often sets this to what he thinks, which is always high of
>> > course. I've had several people changing it back to high when i've
>> > changed it to a lower priority.
>> 
>> Really? Then tell them not to. That should not happen, and the fact that
>> some reporters do this should not stop us from putting these tags (or at
>> least the tag severity) to good use.
>
>Telling someone not to do that sometimes help, but only for that
>particular person. I have better things to do with my extremely limited
>time than educating the whole world about what bugzilla is used for.
>Each time I need to explain bugzilla to someone its time taken from
>fixing other bugs or implementing new features. Its sad, but thats my
>reallity.

Exactly.  The problem with the bugzilla priority field is that 
there is no real definition of what "priority" means.  Priority 
to WHOM?

Bug reporters generally consider the priority field to mean "what 
priority do you want Red Hat to treat this bug as".  That is 
almost always never a piece of useful information on the 
receiving side however.  Others use the priority field to 
indicate "how bad of a problem is this on a scale of 1-3".  That 
also isn't really useful information from a developer standpoint, 
because we are capable of reading a bug report and deducing on 
our own how bad the problem is on a scale of 1-10.

I find it much more useful for the person to explain the problem 
clearly in detail, and then perhaps state how important it is to 
them in the bug report itself.

That is a nice fantasy, but it will never happen, because each 
person is different and does things in their own special way.
Bugzilla is - by definition, a developer/engineer tool first and 
foremost, and a user defect submission tool second or third.  

What the overwhelming majority of people reporting bugs do not 
realize, is that engineers receiving the bug reports, do not sit 
in bugzilla 24/7 just fixing bugs.  We have our own workloads, 
some of which is developing new software, or developing new 
features for existing software, evaluating software, doing 
erratum releases, security releases, OS engineering planning, 
debugging, troubleshooting, testing, and a whole host of other 
tasks.  Our priorities are dependant on all of the tasks that we 
have to do within a certain time frame.   So when we look at any 
given bug report, the priority of that bug report will not be an 
/absolute/ priority, but rather a /relative/ priority.  Relative 
that is, compared to all other open bugs, and also weighed 
against all other work priorities that have nothing to do with 
fixing bugs also.

Initially, I tried to use the priority field in bugzilla to 
reflect where a given bug fit in my current task list stacked up 
against all other issues.  I flagged issues that I considered to 
be things I should investigate ASAP "high priority" and issues 
that could wait, or had reasonable workarounds as lower 
priorities.  Also, bugs that would consume an entire week of 
engineering time, say to fix a single issue that causes Quake 3 
to crash, while they may be a high priority to Joe gamer dude, 
they're Priority -=10000 from a Red Hat business perspective, 
especially since those types of bugs may take a week or two 
nonstop to track down and fix.

Since we have finite limited resources, we have absolutely no
choice but to prioritize bugs compared to all other bugs and
tasks, and then work on the absolute most important issues.  
Some lesser important things will get fixed along the way which
are very quick fixes, or which patches are available, etc.  
There's no real golden rule that applies to all situations of
course, it is a case by case thing.

In 3 years of experience on the receiving end of bug reports, and 
having played "bug-priority-tag" with at least one or two people 
a month for the first 6-8 months, I realized the priority field 
was useless for the purposes that *I* was trying to use it for, 
which was to indicate what priority the bug DOES have.

Since the priority field is so useless, I just totally stopped
ever even looking at it period.

Now I examine a bug, request info, etc. and then I add my own 
priority tags to the developer whiteboard or other fields, or add 
the bug to my personal tracker.  That lets me keep track of a 
small reasonable number of issues that are manageable.

One needs to do that because it is impossible to try and manage a 
2000 item "TODO" list.


-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat