Re: Bugzilla semantics: marking bugs as triaged

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2009-07-17 at 13:12 -0700, Adam Williamson wrote:
> On Fri, 2009-07-17 at 16:03 -0400, Christopher Beland wrote:
> > On Fri, 2009-07-17 at 11:50 -0700, Adam Williamson wrote:
> > > If, say, I'd seen an issue reported
> > > twice but not yet with sufficient info, I might set it to CONFIRMED, but
> > > it's not yet been triaged.
> > 
> > What would have to happen is that the person setting "CONFIRMED" would
> > mark the other bugs as duplicates, do whatever small remaining triage
> > work there is to do, request the missing info and set the bug to
> > CONFIRMED+NEEDINFO.
> > 
> > This violates the "it's not finished being triaged if it's missing info
> > from the reporter" rule, but I never really liked that rule, anyway.  8)
> 
> Unless you're setting the new Triaged flag, I don't see how it violates
> that rule. But we're getting ahead of ourselves, we haven't even decided
> what changes we want to *ask* for yet. We should probably discuss this
> at the next meeting.

Well, I was trying to clearly articulate an alternative that would *not*
involve a Triaged flag, only the three states NEW, TRIAGED, and
CONFIRMED.

I probably won't be at the meeting, and I don't have a strong opinion
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.)

The upside of using only states is that there are fewer permutations to
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.

-B.

-- 
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe: 
https://www.redhat.com/mailman/listinfo/fedora-test-list

[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux