On Fri, 2009-07-17 at 17:59 -0400, Christopher Beland wrote:
Well, I was trying to clearly articulate an alternative that would
involve a Triaged flag, only the three states NEW, TRIAGED, and
Ah, I see - sorry, I'd lost the thread.
I probably won't be at the meeting, and I don't have a strong
about whether to use a flag or a state. The upside of using a flag is
that "triaged" and "confirmed" can be indicated separately. The
downside is that certain UI stuff that's geared toward states would need
to be improved to also indicate flags in order to maintain convenience
for triagers. (Which might be useful to do anyway, since NEEDINFO
visibility is convenient for triagers.)
Yeah, lack of visibility in search results (for e.g.) is a bit of a pain
with keywords. (I'd rather use a keyword than a flag, here; flag doesn't
fit the use case).
The upside of using only states is that there are fewer permutations
worry about. The downside is that procedurally, any bug that is
confirmed-but-not triaged would just need to be triaged on the spot when
it was marked CONFIRMED.
> Bugs without sufficient information have not been triaged. Ensuring
> sufficient information is present in the report is one of the most
> important parts of triage.
Well, I agree that *requesting* missing information is an important part
of triage. I suppose there are some bugs that you need an explanation
from the reporter before you can make heads or tails of them. But
normally, once the checklist has been completed and a request for any
missing info has been filed, I pretty much consider the triage over.
Either the reporter will add the requested info and the package
maintainer can take a look, or they won't and it will continue to be
marked NEEDINFO. If they unset the NEEDINFO flag without supplying the
requested info, or if their reply indicates further triage action is
needed (e.g. it's now clear the bug is reported against the wrong
component) I'll get an email, so in the meantime there's no need for the
bug to show up on my "not triaged" list. I assume it's clear to
maintainers they might not be able to take action on bugs marked
NEEDINFO, though in many cases they can.
Well, I find that as a matter of course on many bugs, you have to go
through a round or two of interaction with the reporter to make sure the
information is fully available. But overall I don't really disagree,
you're right that requesting info is the important step.
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org