Automatically expire old unassigned Incomplete bug reports

I've another idea.. After that period of time, mark it as rejected and post an automatic comment with "This bug has expired, if you've relevant information please re-open it".

I think this will decrease the number of bugs on launchpad..

How about to create a blueprint about this feature ?

I talked to Mark about this feature and he thinks It's a good idea.

I want us to do this; it's a nice follow-up to the changes in bug statuses we're doing for this cycle.

Maybe the default message when closing the bug as Rejected for long time no activity can be something like "Bug rejected, because no more information provided by the reporter..."

How about that?

On Sat, Jun 16, 2007 at 10:51:58AM -0000, Marco Rodrigues wrote:
> Maybe the default message when closing the bug as Rejected for long time
> no activity can be something like "Bug rejected, because no more
> information provided by the reporter..."

The message should not make a statement about whether information was
provided, as this cannot be accurately determined by programmatic means.
For example, the information needed may be requested of someone other than
the bug reporter.

--
 - mdz

We should probably take the importance setting into account here as well. Looking at the current Ubuntu bugs, there are 2265 Undecided+Incomplete bugs. The abandoned bugs in this category are prime targets for automatic removal. There are also 589 Lo/Wishlist+Incomplete that we may consider removing and 1156 Medium.

There are 193 High/Critical bugs that are incomplete and I think these all warrant manual inspection, even if they are old.

Imo, its bad to automatically invalidate bugs; instead add a tag like we do in mozillateam: mt-reject-candidate. In this way bug reports will not get drowned in the sink without anybody actually reviewing them.

if you go for automatic closing anyway, please make this an opt-in/opt-out feature, so we can turn off this feature if it doesn't fit in our workflow.

I think some confusion as to how this will be implemented has arisen. I'd like to point out that:

  - We would only expire bugs in the Incomplete status
  - We would only expire bugs which were unassigned

I think it's really important that we do have an auto-expiration feature. The usefulness of a bug goes down dramatically once it has been open for more than a few months, and in my 10 years of experience working with bug trackers I am sure it's better that old bug reports be closed than stay around. Our objective is not to fix all bugs that exist in software (and Dijkstra would smile here): it's to fix the bugs which are most frequent and most relevant.

Note also that expiring a bug is a good way of telling people that if they want their bug fixed, they need to speak up and provide us with concrete information.

The bugs we'd consider for expiration in the Ubuntu context are the ones listed here:

https://bugs.edge.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=Incomplete&assignee_option=none&field.assignee=&field.bug_reporter=&field.bug_contact=&field.component-empty-marker=1&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.tag=&field.has_cve.used=&field.has_no_package.used=

I am only curious right now as to what status the bugtasks should be moved to. A special status Expired? That would at least easily allow us to find and communicate what happened to them.

You many months need a bug to be set Expired with that rules ?

If status Expired will be created (can't be changed by anyone, how to handle this ?). Isn't more easy to add a comment telling the subscribers about the expiration of the bug and telling them what to do ?

On Tue, Jul 10, 2007 at 10:28:23PM -0000, Marco Rodrigues wrote:
> You many months need a bug to be set Expired with that rules ?

I was thinking of something between 1 and 2 months, but maybe more than
that would be a safer bet at first. I think the answer tracker expires
after 2 weeks.

> If status Expired will be created (can't be changed by anyone, how to
> handle this ?).

It would be a terminal status that only the expiration-script would be
allowed to set. IOW, you'd be able to revert back from Expired, but not
set the bug expired manually.

> Isn't more easy to add a comment telling the subscribers about the
> expiration of the bug and telling them what to do ?

I don't think we necessarily /should/ add a comment -- the status
transition to Expired should be enough, if we display it properly,
right?
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3376 0125

Hi!

I think the better should be 3 months, it's an intermediate number between 1 and 6 (every 6 months, there is a new distro release).

Expired bugs will have the same status of a fix released, I mean, doesn't appear in listing, only in search or filebug and don't count for statistics.

I'm excited to see that feature working =)

Thanks for all of your answers.

On Wed, Jul 11, 2007 at 12:52:39PM -0000, Marco Rodrigues wrote:
> I think the better should be 3 months, it's an intermediate number
> between 1 and 6 (every 6 months, there is a new distro release).

I'm okay with starting with 3 months, though I do think it's a pretty
long time.

> Expired bugs will have the same status of a fix released, I mean,
> doesn't appear in listing, only in search or filebug and don't count for
> statistics.

Well, they'll be more similar to Invalid (we could just use the Invalid
status, but I think that's not a very good way of tracking them), but
yes, they won't appear in any default listings, and won't count for
statistics. It'd be an interesting idea to have them match in the
filebug listings though -- hadn't considered that.

Reassigning to Curtis, since I won't have time to tackle this before I go on parental leave.

"We are closing this bug report as it lacks the information, described in the previous comments, we need to investigate the problem further. However, please reopen it if you can give us the missing information and don't hesitate to submit bug reports in the future."

How about a similar message when status change to Expired ?

After discussing this bug with salgado during my pre-implementation call. I have a few remarks.

To be clear, we will only be expiring *unassigned* *Incomplete* bug reports that are *older than 3 months* for projects that use *Malone*. This feature will not affect bugs for projects that use upstream bug trackers.

The expiration period will be configurable so that we can make adjustments after we get some experience with this.

Should this behaviour be toggled [on|off] by the project? Does the project have some say in whether their neglected bugs are expired?

https://wiki.ubuntu.com/Bugs/Responses#head-6ee6466fdaac8c81274185f0316afd794d2ee0b6

Now it's 4 weeks to set a bug to Invalid (manually). more than 3 months isn't too much? how about kiko said ">= 2 months".

I prefer ">= 2 months".

When talking about the age of the bug report is that the age from when the bug was initially reported or the age from when the comment that changed the status to "Incomplete" was made? I think going with the latter makes the most sense.

Another concern of mine is that there is not an Ubuntu team that actively watches "Invalid / Won't Fix / Fix Released" bugs. So in the event that the bug receives traffic after being expired I am not sure when it would be noticed - hopefully before it expired again but with the volume of bug reports that we receive it is hard to say. One solution might be to let bugs auto expire only once and when an expired bug receives a new comment have the status of the bug report change to "Incomplete" again.

Brian:

I think the age should be measured from the last message attached to the bug. We want to measure inactivity. So an old incomplete bug that is getting messages from users will remain open. As long as users are working with the bug, we want to give them an opportunity to come to a resolution on their own.

I think you have a good point regarding messages for expired bugs. I like your rule that a message automatically reopens it.

An alternate rule (like the one used for expired Questions) is expired bugs are not permitted to receive new messages. A user must first reopen the bug first.

There are some ambiguities I need resolved to get the rules right for expiration.

I think we need to make a distinction between the bug (the reported problem) and a bug task (what the bug affects and where it will be fixed).

A bug may have many tasks, each affecting a different thing, a product, product series, a distro, a distro series, a distro source package, a distro binary package. Each task for a hypothetical bug may have a different status. For example in bug <https://bugs.launchpad.net/ubuntu/+source/celestia/+bug/30970>
Baltix is Confirmed, Celestia is Incomplete. Do we Expire Celestia?

A bug task may be fixed in multiple places like in Ubuntu, debian, gnome. For eample in bug
<https://bugs.launchpad.net/ubuntu/+source/gnomescan/+bug/64976>, an upstream task is New, and the Ubuntu task is Incomplete. Do we set the Ubuntu task to Expire?

But all messages are shared by all tasks.
So, it seems to me that all unassigned and incomplete tasks of a bug where last comment is older than N weeks for a project which the bug manager is Malone should be put in state 'Expired' with a message stating that 'any message added to this bug will automatically reopen it (make invalid)'. Of course this message must not in itself reopen the bug :-). And we should never change status of a task on a project not managed by Malone.

Ideally N (number of weeks before expiring a bug) would depend on the project.
I don't know if a reopened bug should be allowed to expire again.

I don't think we need a new Status. It'll probably be good enough with a tag called "Expired" or "auto-expired" or similar. Also, as long as the bug is being worked on, it shouldn't expire.

On Wed, Aug 08, 2007 at 08:45:21AM -0000, Martin Ahnelöv wrote:
> I don't think we need a new Status. It'll probably be good enough with a
> tag called "Expired" or "auto-expired" or similar. Also, as long as the

What an interesting idea -- use a tag. I had not thought of that.
Thanks!

> bug is being worked on, it shouldn't expire.

Definitely true -- assigned bugs should not expire.

Paul, your observation is correct. I am using the recently implemented date_incomplete that will be an accurate record of how long a bug that affects a product or distro been in the incomplete status.

I like you idea Martin. I will be setting the Incomplete bugs to Invalid. I'll look into a tag. I have some doubts since I am not so much expiring bugs, as I am expiring where the bug affects. I bug is effectively expired if everything it affects is set to the Invalid status. Many bugs reports affect more than one product, or sourcepackage, or whatever. I don't want tag the whole bug if only part of what it affects was expired.

On Wed, Aug 08, 2007 at 01:08:54PM -0000, Curtis Hovey wrote:
> sourcepackage, or whatever. I don't want tag the whole bug if only part
> of what it affects was expired.

I think in practice it's the same thing. Bugs won't be expired because
they aren't fixed somewhere in time; they will expire because the
reporter never came back to give us any information (and they became
therefore irrelevant, since you can't even establish what is broken nor
what needs to be fixed).

What would happen in the case where a bug was forwarded upstream and all the activity and comments took place upstream? The bug could have a resolved state upstream and the Malone bug was left "Incomplete" just because people's focus had shifted to the upstream tracker.

Hi. Brian. Only bugs that belong to to projects that officially use official use Malone for bug tracking can be expired. In the case where a bug in xorg is New in the upstream package, and Incomplete in the ubuntu package, the ubuntu would be set to Invalid, but the upstream package will be unchanged.

Right, my concern was the case where it could be "Fix Released" upstream, xorg in your example, and "Incomplete" in Ubuntu and it getting set to "Invalid" which seems incorrect. However, maybe this is a corner case.

This sounds very similar to Bug #35344 ...

How about to set that one duplicate of the other, because it has more
information now and comments.

Sitsofe Wheeler wrote:
> This sounds very similar to Bug #35344 ...
>

--
Marco Rodrigues

http://Marco.Tondela.org

This branch cannot land in RF until Bug 50663 lands in RF at the next DB opening.

Fixed in RF 4833.

Curtis, can you explain here all the items of this new LP feature ?

It will expire or be deleted? just need to comment to re-active the bug? it has any permanent invalid after N expirations ?

When a bug has been in the Incomplete status for 60 days, it's status will be set to Invalid. Any one who has permission to change the status (a bug contact for instance) may change the status if Invalid is wrong. The goal of this feature is to remove distractions of the search results. There are some restrictions to the feature: The bug cannot be assigned to a person. The location of the bug (affect) must use Launchpad to track bugs, and the bug must have been in the incomplete status for 60 days.

An example how these restrictions will play out, consider a bug that affects Ubuntu, Firefox, and Launchpad. Each location has been Incomplete for 60 days, but the Launchpad issue is also assigned to me). When the expiration task runs, The Ubuntu location will be Invalid, Launchpad will be unchanged be I should be working on it. Firefox will still be incomplete too, because we assume we will get a status change from upstream.

This could be dicey. Without automatic flip back to new on bugs that people reply on comments to a bug could time out all by itself due to someone not going back and changing the bug status. Additionally some folks will put a bug into incomplete for testing months before the next stable release of Ubuntu is to be released...

On Tue, Sep 11, 2007 at 06:46:08PM -0000, Sitsofe Wheeler wrote:
> This could be dicey. Without automatic flip back to new on bugs that
> people reply on comments to a bug could time out all by itself due to
> someone not going back and changing the bug status. Additionally some

Well, the person who should flip to Complete is the person who asked the
question, and I expect them to know a bit more about bug tracking in
Launchpad.

IIRC we will be providing a special query to find Incomplete bugs that
people have commented on.

> folks will put a bug into incomplete for testing months before the next
> stable release of Ubuntu is to be released...

This sounds like abuse of Incomplete, though -- it's not meant for post
fix-released QA.

> Well, the person who should flip to Complete is the person who asked the

This frequently doesn't happen. Often a "please provide more information" question is asked, the bug is set to incomplete and then the asker never returns to the bug. The reporter replies but the status is unchanged. I think that Red Hat bugzilla style NEEDINFO_FROM status flipping would alleviate this issue. Drive by bugs happen a lot but so do drive by requests for more information.

I would expect a bug to still be changed from NEEDINFO to OPEN if someone comments on it after being marked NEEDINFO.

Fix released with Launchpad 1.1.9.