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