"Incomplete" status difficult to understand

A simpler solution would be to change any Incomplete status to New whenever the reporter comments in a bug report. That would require no extra e-mail notifications and no extra prompts, and it would make Launchpad simpler than it is now because it would abolish the "Incomplete (with response)" pseudo-status.

Matthew Paul Thomas's simpler suggestion would be equivalent in perhaps
75% of such cases I've seen: the others tend to be when the original
reporter never replies and someone else comes in with (usually) the same
problem and effectively begins acting as the reporter.

I favour using a tooltip or secondary text to explain the meaning of the status.

I've mentioned in a different bug report (not easily at hand) that moving the bug status back to new has a downside, in that it would become difficult to differentiate between untriaged bugs and bugs that are in the process of being triaged.

In other words, 'Incomplete (with response)' is useful as a queue of bug-triager discussions already under way, so that you can focus on clearing that queue before turning attention to bugs that have not yet started being triaged.

For packages with few bug reports (less than a hundred), this probably seems like a needless distinction, but for larger packages like linux or xorg where there are tons of new bug reports filed each week, having a way to split the queue into "untriaged" and "being triaged" is valuable.

But anyway, I do agree that 'Incomplete (with response)' is a confusing status for many people. I would prefer seeing it renamed rather than just making the bugs 'New', though. (Or alternatively, if there was some way when doing searches or api queries to identify New bugs that have had a non-New state previously, from those which haven't, then I'd be ok with eliminating Incomplete (with response) in favor of that.

As it has been mentioned before, how about a comment box, like the one I am typing in right now :) under the status incomplete, so if you choose incomplete as the status, you explain clearly why that has been done so.

FTR - I really value 'incomplete' vs 'new' for the reasons Bryce
mentions - even in smallish projects.

The current "incomplete" status is highly annoying, as the bug progress usually goes like this:

1. Report bug
2. Maintainer sets status to incomplete with clear or unclear request for information
3. The requested information is provided by the reporter
4. The bug times out! <- This MUST be prevented somehow

I also suggest renaming "incomplete" to "need info", as it's much more descriptive. "Incomplete" makes it sound like the bug is in progress of being fixed, but not yet done.

On Thu, Nov 11, 2010 at 07:00:20PM -0000, tsg1zzn wrote:
> I also suggest renaming "incomplete" to "need info", as it's much more
> descriptive. "Incomplete" makes it sound like the bug is in progress of
> being fixed, but not yet done.

"Needs info" is a good suggestion.

Ah the swings and roundabouts (we used to have NEEDSINFO). As it
happens I agree - incomplete is more general, but coupled with the bug
expiry logic quite unsatisfying.

Perhaps we can do some user testing on this and get a more data driven answer.

Bug 971 records "NeedInfo" becoming "Needs Info" in January 2006. And bug 50663 records a pre-implementation call where "Needs Info" became "Incomplete" in July 2007. It's not clear why that happened (though Jeroen might remember), but it was simultaneous with the introduction of the "(without response)" and "(with response)" pseudo-statuses.

@mpt - any advice here?

I spent a few minutes yesterday imagining: Would Bugs work well without "Incomplete"? What would happen if it didn't exist? Triagers would still ask questions necessary for them to be able to reproduce a bug. Usually, they'd leave the report in "New" status while they waited for an answer. Occasionally they might use "Invalid" instead, with instructions for the reporter to reopen the report if they got around to providing the missing information. A little time would be wasted whenever a triager opened a "New" bug report and discovered that another triager had already asked for more information only a short time ago. So, that's the first function of "Incomplete": to save triagers a little time.

After some period without response, triagers would mark these reports as Invalid. The period would be inconsistent between projects and triagers (some might just mark reports as Invalid immediately), and individual reporters might get upset with those triagers. So, that's the second function of "Incomplete": to make the expiry process consistent and impersonal.

Finally, sometimes reporters would provide the missing information for a report that had only recently been marked Invalid, but would not remember (or know how) to reopen it, and their response would be forgotten. So that's the third function of "Incomplete": to automate reopening when missing information is provided.

These functions lead me to two conclusions: (1) if the reporter comments in an Incomplete bug report, it should always reopen, and (2) if they don't, it should always expire. We shouldn't need project-specific flags for those things; if that's not the behavior you want, there's little reason for you to use "Incomplete" in the first place.

I think that would solve, as Mary Gardiner said, 75% of the problem. Much of the other 25% could be caught by some sort of "Reopen in {project name}" checkbox, appearing for non-reporters below the comment field when commenting on an Incomplete bug report. I don't think there needs to be anything more elaborate, like a special field for what information is required. (After all, if a triager *doesn't* properly explain what information is required, and the reporter replies by saying "I don't understand what you're asking for", that comment will automatically reopen the bug report anyway.)

There are other problems that fall under the general heading of "Incomplete" being difficult to understand, mainly people abusing it for "this needs design work" or "I know it's a bug but I'm expecting the reporter to tell me how to fix it". But I don't think that's what this bug is about, so it can wait for another day.

On Thu, Nov 18, 2010 at 08:47:46PM -0000, Matthew Paul Thomas wrote:
> I spent a few minutes yesterday imagining: Would Bugs work well without
> "Incomplete"?

I like (and agree with) your analysis.

> After some period without response, triagers would mark these reports as
> Invalid.

'Expired' is a clearer end-state in this case. Although, you can only
set it to that state via the API currently (probably for good reason).

> Finally, sometimes reporters would provide the missing information for a
> report that had only recently been marked Invalid, but would not
> remember (or know how) to reopen it, and their response would be
> forgotten. So that's the third function of "Incomplete": to automate
> reopening when missing information is provided.

I definitely agree auto-reopening of Expired bugs when the original
reporter comments is a good idea. I'm uncertain if the same should be
done for Invalid. I don't think this auto-reopening should occur on
comments from random strangers that hadn't ever commented on the bug
before. But this is straying from the topic at hand.

> There are other problems that fall under the general heading of
> "Incomplete" being difficult to understand, mainly people abusing it for
> "this needs design work" or "I know it's a bug but I'm expecting the
> reporter to tell me how to fix it". But I don't think that's what this
> bug is about, so it can wait for another day.

I think the question raised was about your analysis on the terminology
"Needs Info" vs. "Incomplete". Would some of the confusion leading to
the issues in your above paragraph be avoided more easily if the former
term was in use? Would it cause other confusion or issues?

I think "Needs Info" would be more confusing than "Incomplete", not less. See bug 4201, where -- at least five months, probably more, after "NeedInfo" had been introduced -- even Launchpad developers themselves disagreed with each other about what it meant.

(And just in case anyone thought my suggestion in this bug report was particularly novel, there's Brad Bollenbach suggesting a similar thing five years ago: "what do you guys think of automatically flipping the status back to what it was before being set to "Needs Info" when a comment is added to a Needs Info bug?" And Björn Tillenius getting even closer: "...the status should probably be New, given that most likely information was lacking from the bug report, and the bug triagers should decide if the information is enough or not." The only change in my suggestion is restricting that behavior to comments from the reporter.)

(And now I reread Björn's comment, I realize he suggested exactly that restriction too.)

So, on the auto state changing stuff I complete agree, its well
thought out and a no-brainer.

What appears to give us grief at the moment is the ambiguity between
'will the reporter please tell us XXX'
and
'some discussion or something needs to happen'
which incomplete, like needsinfo, does not address.

Perhaps renaming incomplete to 'reporter asked' or something would help.

Or perhaps the status shouldn't change at all but we should have a set
of Questions which need answering for the bug - targeted to e.g. 'the
filer', 'the package maintainer', 'the driver' etc... and a bug with
outstanding questions to the reporter expires.

/me handwaves

On 19 November 2010 03:22, Robert Collins <email address hidden> wrote:
> Or perhaps the status shouldn't change at all but we should have a set
> of Questions which need answering for the bug - targeted to e.g. 'the
> filer', 'the package maintainer', 'the driver' etc... and a bug with
> outstanding questions to the reporter expires.
>

This is essentially the bug Q&A story that we've been talking about
for a while, I think. I believe it's consistently one of the next
items on the list of things to do when we've finished the subscription
story.

On Fri, Nov 19, 2010 at 2:32 AM, Graham Binns <email address hidden> wrote:
> On 19 November 2010 03:22, Robert Collins <email address hidden> wrote:
>> Or perhaps the status shouldn't change at all but we should have a set
>> of Questions which need answering for the bug - targeted to e.g. 'the
>> filer', 'the package maintainer', 'the driver' etc... and a bug with
>> outstanding questions to the reporter expires.
>>
>
> This is essentially the bug Q&A story that we've been talking about
> for a while, I think. I believe it's consistently one of the next
> items on the list of things to do when we've finished the subscription
> story.
>

I very much would like us to work on Bug Q&A and argue for it at every
chance. Whether or not jml and our stakeholders agree is another
matter. I don't think others are interested in new features at this
point, which I understand. So I don't expect to work on it anytime
soon. I will still argue for it as a game changing feature for the
bugs app, especially for projects with large numbers of bugs.

As for the questions here about status, I think it's useful to not
confuse "status" and "state," which is part of what Bug Q&A attempts
to do. Status is a work flow flag -- it says, where in the
development work flow is this bug? Bug state can be conveyed in any
number of ways in addition to the status field. I think we could do
with simpler, better understood statuses generally (as mpt outlines in
https://dev.launchpad.net/IssueTracker) and convey any additional
state questions like reporter requirements in other ways. If we did
these two things, I think the confusion over the naming of
"Incomplete" gets better and possibly goes away completely.

I'm also highly in favor of auto-toggling status from Incomplete based
on reporter comments. There's a bug somewhere about this already.

Cheers,
deryck

The bug that Deryck referred to, auto-toggling Incomplete back to New when the reporter comments, is bug 196590.