[ham] Re: quoting, tasks, semantics

[Christopher Hicks]

On Tue, 14 Sep 2004, Kristis Makris wrote:
> How about proposing to users a convention where task bugs are flagged 
> with a keyword (e.g. TASK or REQ), and have them define custom queries 
> to display tasks. Then a bug can serve both roles, tasks and sub-bugs. 
> And the groupware integration can behave differently when a bug has this 
> keyword set.

There are several reasons.  When I query for "all the bugs in project X" I 
don't want to have to say "that are actually bugs".  When I query for bugs 
I want to get only bugs back.  Something being a bug means something 
different than something that is a task.  I've already got bugs that use a 
keyword and status white board of "ongoing" so I don't have to make and 
kill bugs for small tasks, but I still want to be able to bill the .1 to 
the client.  This has saved much trouble, but its also been frustrating 
because now I have to realize that the ongoing bugs need to be excluded 
from my query.  The other area this already frustrates me is that it 
affects my bug totals.  I like to watch the bug counts go up and down as 
we work on projects for different clients and clean out the accumulation 
of "do it when you get around to it" sorts of bugs.  Now I have to look at 
the graph and say, ok that's 10 high because there are these "not quite 
bugs" in there.  The thought of how awful this would be if every bug had 
0-n tasks associated with it is just too ugly to imagine.  If you don't 
feel that a bug and a task have different semantic meanings and you don't 
pay any attention to bug counts over time then treating a task as a new 
kind of special bug is fine for you.

I'm considering implementation methods and bugxula looks like it has lots 
of potential.  Does the bugxula developer happen to be on this list?  :)

-- 
</chris>

There are two ways of constructing a software design. One way is to make 
it so simple that there are obviously no deficiencies. And the other way 
is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare