Incomplete report "will be marked for expiration" even if reporter has followed up

Hi Andrew, thanks for the bug report.
The workflow should be like:
Someone reports a bug
A triager ask some question and set the status to Incomplete
The reporter adds the information the triager asks and sets the status back to new

When the reporter set the status back to new, the expiry counting stops.
Also when you add a comment to an incomplete bug but don't set the status back to new, the counting is automatically reset to 60 days.

I feel like there is still a point to this bug though. You are giving a workflow but how do you know that's actually what's going on? Often times a triager sets the status to Incomplete, somebody comments, and the bug just sits there waiting for a triager/developer to return. I know you guys are trying to make Incomplete a temporary state but my experience so far indicates it's often not. How are we supposed to indicate a bug that is really incomplete without worrying that it'll expire?

I think the point of this bug report is to say that this might be seen as punishing bug reporters for a lack of activity by developers/triagers. Is that right Andrew?

Jordan, that was my point.

I wouldn't use the word "punishment" though.

Here's a concise restatement "A bug report shouldn't get lost just because a developer/triager was busy for a month or two, and didn't get around to looking at the new information."

I suppose a good solution would be to automatically change the status from incomplete => new whenever a comment is added.

This bug is valid, as shown in bug 176735: the reporter has commented, but Launchpad still claims that the bug report is going to expire.

Bug reporters are less familiar with how to use bug statuses than other Launchpad users and may not know that they should set the status of a bug they have responded to back to New. Additionally, when adding a comment via the web interface, which one would do at the bottom of the bug report, or replying to a bug via e-mail it isn't easy or intuitive to change a bug's status back to New. Subsequently, I believe that bug reports that are "Incomplete w/ response" should not be eligible for expiration.

Well, what happens after a person replies is that the inactive counter is cleared out. I think that's the right thing, too; if a reply is never looked at and the status updated, expiration is a good way of raising attention to it.

How would the attention be raised? If it is by sending e-mail to the bug subscribers, I'm not convinced that would be very effective for bug reports that are already marked for expiration. However, going forward that seems reasonable.

I'd rather there were a way to look for bugs that can expire and are "Incomplete w/ response" or ones where the "inactive counter" has been reset. That way anyone can look for those bug reports instead of just the bug subscribers. I think this report should be a subset of the +expirable-bugs report given the large quantity of bugs about Ubuntu.

Attention would be raised in the expiration email itself, which would be sent to bug subscribers, yes.

I'm in favor of having a search option that lets you do what you want, though.

You can now use eg <https://bugs.edge.launchpad.net/bzr/+expirable-bugs> to see bugs in this state -- though I think there's no link to this page in the ui?

> if a reply is never looked at and the status updated, expiration is a good way of raising
> attention to it.

Maybe so. At present expiry only happens when it's the 'fault' of the reporter, rather than the developer. In practice at present this state means "if the reporter doesn't respond, we can't do anything else with this bug."

It would be interesting (perhaps extremely interesting ;-) to also expire bugs if they've had feedback from the user and the developer has not responded. You should presumably then also expire New bugs if the developer has not responded, because the situation is analogous, and it might even be logical to expire _all_ bugs if they're inactive for a long time, though that's probably taking it so far. It's useful to have old bugs still easily findable.

Expiry is quite aggressive in Answers and I think there it works reasonably well.

This would be less annoying in Bugs if it took the idea from answers of controlling state changes by single-click buttons next to the normal entry form. "Yes, this was the information we needed" vs "this bug is still incomplete".

We've no immediate plans to tweak expiry; this bug is probably solvable in a simple fashion by making sure the docs and the code match. Beyond that, @poolie's comments about using expiry in more circumstances are interesting (but possibly contentious :))