Michał Górny posted on Mon, 07 Mar 2011 09:34:55 +0100 as excerpted: > I'd say, both to UNCONFIRMED. Before, we used to set 'NEW' for newly- > added bugs and didn't use UNCONFIRMED often. Right now, it seems logical > to use UNCONFIRMED for the new bugs and let devs (re-)confirm them as > necessary.
I've wondered about that choice in the past, but tended to simply leave it at the default (new), figuring (while having my doubts about viability) if they were both available and new was the default, unconfirmed must be an intentional downgrade available for users who weren't sure yet, and were going to follow up later after further tests. > I think it might be even a good idea to limit the possibility of setting > 'CONFIRMED' to devs. Otherwise, I see users bumping each of their bugs > to 'CONFIRMED' immediately. Is it possible to leave that option for users, but block it such that the original filer can't flip it? If so, IMO that would be best, as a second user could then "confirm" it. If it's not possible to block, unconfirmed could at least be made the default and the wranglers could complain about (and change) bugs filed as "confirmed" as they assign them. The message should eventually get out, and having a second user confirm the bug could actually be quite useful for busy devs trying to prioritize their bugs. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
