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
