Toggle from Incomplete/Expired when bug reporter responds

Fwiw, for my own purposes with X bugs, I (ab)use the Confirmed state to mean 'Answered'. I know not everyone uses it that way though, so won't suggest that if an Answered state were added, the Confirmed state should go away. But it's a thought.

s/Answered/Responded/g in my previous comment.

I really don't want to add yet another bug status. :-) "Incomplete with response" is just a search condition really. I believe it is the common case to use confirmed in this way, so could we not add some code that toggled the state to confirmed when the original reporter adds a comment to a bug in the incomplete state?

This was make sure no bugs remain incomplete once someone replies.

Would this fix the root problem without adding a new status? Are there problems with this approach?

Cheers,
deryck

On Tue, Apr 27, 2010 at 03:13:43PM -0000, Deryck Hodge wrote:
> I really don't want to add yet another bug status. :-) "Incomplete with
> response" is just a search condition really. I believe it is the
> common case to use confirmed in this way, so could we not add some code
> that toggled the state to confirmed when the original reporter adds a
> comment to a bug in the incomplete state?
>
> This was make sure no bugs remain incomplete once someone replies.
>
> Would this fix the root problem without adding a new status? Are there
> problems with this approach?

Yep, that would be fine (it's pretty much what I do currently).

I was thinking 'Answered' might be a better name than 'Confirmed', but I
guess that's orthogonal to this.

On 28 April 2010 01:13, Deryck Hodge <email address hidden> wrote:
> I really don't want to add yet another bug status. :-)  "Incomplete with
> response" is just a search condition really.    I believe it is the
> common case to use confirmed in this way, so could we not add some code
> that toggled the state to confirmed when the original reporter adds a
> comment to a bug in the incomplete state?
>
> This was make sure no bugs remain incomplete once someone replies.
>
> Would this fix the root problem without adding a new status?  Are there
> problems with this approach?

+1

Alternatively, and perhaps better but perhaps more complicated, take
some ideas from Answers, so that the original responder sees some
buttons like:

"I've provided the needed information" "That solved my problem" "Just
add a comment"

and drive the status from there.

That may save maintainers having to flip it back to Confirmed and also
reduce the frequency of spurious changes. (I guess this overlaps with
bug q&a?)

--
Martin <http://launchpad.net/~mbp/>

Just a follow-up on comment #1: in Ubuntu we usually use "confirmed" to indicate that a second person has successfully replicated the bug (or knows the cause well enough to make replication unnecessary) on a separate install. This helps separate bugs that are specific to a particular install, and possibly due to third-party software or misconfiguration from bugs in the distibuted software. https://wiki.ubuntu.com/Bugs/Status documents our typical use of each status value. According to this, Bryce's use is indeed abuse (although most triagers ignore X bugs due to the efficiency of Bryce's automated workflow).

To match our typical workflow, setting back to "New" would be more appropriate, as this would highlight them for reanalysis and replication attempts. That said, this doesn't work as well with heavily automated bug processing, where the distinction between a newly reported bug and a bug to which the reporter has provided information is useful. I'm unsure of the best compromise value, but would encourage solicitation of feedback from a wide set of bug triagers as part of development of the implementation target.

I think that setting the bug status back to "New" is the most appropriate thing and that having two definitions of Confirmed, somebody else recreated this bug vs the reporter responded, would be quite confusing and make it harder for people to participate in bug triage.

Perhaps instead bugs could have an untouched(?) bit that would distinguish between brand new and needs reanalysis bugs.

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.

I'll update the title here to be more accurate, but I think I want to do a LEP (https://dev.launchpad.net/LEP) and get wider discussion just to make sure we do this correctly.

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

A "New" bug might need further information from the reporter before it is Confirmed. This is true for a bug report that has never changed state. But it is also true (albeit a bit less likely) for a bug report that has been in and out of the "Incomplete" state. The reporter might still not have provided all the information necessary, or they might have raised more questions than answers.

Given that, would there be any *useful* difference between "New with response" and "New without response"? If not, then in fixing this bug, "with response" and "without response" can be removed from Launchpad. Simplification win!

"with response" is very unclear about from whom the response is expected.

"New without response" sounds like you want a response from a developer/triager; "incomplete without response" probably means you want a response from the reporter or someone else experiencing the bug.

Per Bryce at #9 we do see a lot of people who think they're helping by changing a bug from "Triaged" to "Confirmed" because multiple people have hit it. (Let's kill Triaged or change it to Accepted.)

I think the logical states are

0 - Needs assessment by a triager to decide if it's even a bug at all (approximately New)
1 - Needs more information from someone experiencing the bug before it can be triaged (~Incomplete)
2 - Needs more information from someone experiencing the bug before it can be fixed (~Incomplete)
3 - Could be fixed when a developer wants to start on it (~Confirmed)
4 - Bug controllers have decided they actually will try to fix it (~Triaged)

If you want to detangle 1 and 2 you could have New-and-incomplete, or you could have an orthogonal flag for "blocked on getting further information".

To me once the user thinks they have provided the necessary information in state 1 or 2, it makes sense to take it out of that state and have a developer either work on it, or triage it, or to toss it back and say it's still blocked on getting more information. In other words I don't think a separate state of "Needs more information before it can be triaged and the user thinks they have now provided that" is useful, because I doubt bug controllers ever actually want to say "ok this has all the information to be triaged" rather than just actually triaging it.