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
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