Launchpad itself

Bug #569298
Comment #9

Comment 9 for bug 569298

Revision history for this message

Bryce Harrington (bryce) wrote on 2010-04-30: Re: [Bug 569298] Re: Toggle to CONFIRMED for bugs with response from bug reporter

On Fri, Apr 30, 2010 at 12:53:30PM -0000, Deryck Hodge wrote:
> Okay, so I feel convinced that toggling to New is better than Confirmed;
> however, I'm not a fan of having an untouched bit. That just moves the
> Incomplete (with response) search to New (with response), which is not
> terrible but does it fix the original bug here that people can work out
> what's going on? Maybe it does in that people can see a status change
> when they comment. But it does lend some weight to Bryce's original
> suggestion of an explicit status for responded. I really don't want
> more statuses, though.
>
> Really, really, really don't want. :-) We have a lot of confusion now
> over all the statuses and we should be consolidating on fewer, not
> adding more, IMO.

Personally I'd argue we already have a state here, it's just not
explicitly shown to the user. We already have to have code for handling
"Incomplete with response" in the API, on the search page, etc. etc. So
making it into an explicit state seems to me to be more like a rename
than an addition.

Maybe the idea to hide the "Incomplete with response" state from being
explicit was with the belief that fewer states means less confusion for
users. I think in practice, actually this tends to result in the
opposite, and it would be more intuitive for users if they see the bug
go to Answered when they provide the information.

I know other people use Confirmed to mean something separate from
Answered. To me it seems completely redundant with "Affects me too" and
looking at #dupes. But then, with X and linux we get a lot of false
confirmations, so this state has no value to me. Thus, I've repurposed
it to mean, "Passed the validation tests", to indicate the bug report is
ready for human review.

My main concern with changing "Incomplete with response" into "New with
response" is that my bug tests use status "New" to mean "unprocessed".
As long as there is a corresponding "New without response" I think I
could make it work. However it seems kind of a convoluted solution...

On Fri, Apr 30, 2010 at 12:53:30PM -0000, Deryck Hodge wrote:
> Okay, so I feel convinced that toggling to New is better than Confirmed;
> however, I'm not a fan of having an untouched bit.  That just moves the
> Incomplete (with response) search to New (with response), which is not
> terrible but does it fix the original bug here that people can work out
> what's going on?  Maybe it does in that people can see a status change
> when they comment.  But it does lend some weight to Bryce's original
> suggestion of an explicit status for responded.  I really don't want
> more statuses, though.
> 
> Really, really, really don't want. :-)  We have a lot of confusion now
> over all the statuses and we should be consolidating on fewer, not
> adding more, IMO.

Personally I'd argue we already have a state here, it's just not
explicitly shown to the user.  We already have to have code for handling
"Incomplete with response" in the API, on the search page, etc. etc.  So
making it into an explicit state seems to me to be more like a rename
than an addition.

Maybe the idea to hide the "Incomplete with response" state from being
explicit was with the belief that fewer states means less confusion for
users.  I think in practice, actually this tends to result in the
opposite, and it would be more intuitive for users if they see the bug
go to Answered when they provide the information.

I know other people use Confirmed to mean something separate from
Answered.  To me it seems completely redundant with "Affects me too" and
looking at #dupes.  But then, with X and linux we get a lot of false
confirmations, so this state has no value to me.  Thus, I've repurposed
it to mean, "Passed the validation tests", to indicate the bug report is
ready for human review.