| 1 |
On 16/06/16 09:47 AM, Michał Górny wrote: |
| 2 |
> On Thu, 16 Jun 2016 16:22:32 +0300 |
| 3 |
> Andrew Savchenko <bircoph@g.o> wrote: |
| 4 |
>> |
| 5 |
>> CONFIRMED state is useful, it means that dev or powerful user |
| 6 |
>> confirmed this bug and gives it more value. I'd like to keep it. |
| 7 |
> |
| 8 |
> Are you saying that bugs that haven't been marked as CONFIRMED have |
| 9 |
> less value? Maybe they don't have to be handled at all, unless someone |
| 10 |
> you consider more worthy confirms them? |
| 11 |
> |
| 12 |
|
| 13 |
To me it's not about increased or decreased value per se, it's about |
| 14 |
workflow: |
| 15 |
|
| 16 |
- An UNCONFIRMED bug I have to reproduce myself and diagnose to |
| 17 |
determine if it's really a bug or if it's something else. |
| 18 |
|
| 19 |
- A CONFIRMED bug to me means this has already been done (by myself, |
| 20 |
others in the project, or dev's that should know the difference) and I |
| 21 |
can skip directly to identifying and fixing the issue. |
| 22 |
|
| 23 |
So when I look at the list of bugs for firefox I know what the state |
| 24 |
is more or less for things that are outstanding. If I have just a |
| 25 |
little bit of time to hack away at things I'd rather try to close a |
| 26 |
CONFIRMED bug than half-diagnose an UNCONFIRMED one. Similarly if I |
| 27 |
don't have access to my dev system but have plenty of time, I may well |
| 28 |
try and triage UNCONFIRMED bugs. |
| 29 |
|
| 30 |
IN_PROGRESS to me is something that should be reserved for when the |
| 31 |
fix is ready to go and just hasn't been fully applied or is readily |
| 32 |
available to all users (say, the fix is on an overlay for testing) -- |
| 33 |
I would prefer not to start using that instead of CONFIRMED, but if |
| 34 |
that's what the new meaning would be after UNCONFIRMED/CONFIRMED is |
| 35 |
merged to OPEN, I guess I could live with it. |
Archives