62093 - Stale Bug Chaser and Keyword

Status: RESOLVED DUPLICATE of bug 185090

(Bugzilla :: Administration, task, P3)

Description

[Barry Marshall]

I'm not sure where the next version of Bugzilla is sitting, but if you're 
looking for suggestions....  how about having a function in Bugzilla that will 
search out stale bugs and get people to input a status on them?

For example, let's take something like 
Http://bugzilla.mozilla.org/show_bug.cgi?id=25699.  This bug had been idle for a 
couple of months until I poked Bill about it.  No big deal doing that, but I'm 
beginning to wonder how many other stale bugs there are in the system.

I asked Gervase about this and he said that if you do a search using boolean 
charts and do lastchangeddate > 90 (say) and milestone is not Future, there are 
currently about 1444 of them.

Maybe Bugzilla could send out an email asking the assignee for status after 3-4 
months?  If there was no response in a week or two  (maybe the person left or 
change email addresses, for example), then send the same note to the assignee, 
the cc'ers and the QA person a note to re-sync the bug?

Could the same also be setup for resolved bugs?  Maybe with a lower threshold, 
such as 1 month or so?

This would seem like a good chance for some automation, rather than having 
people chase every single one of these down...although the personal touch would 
probably get better results.

Comment 1

[Barry Marshall]

Also, perhaps a STALE keyword could be added in to flag these bugs as stale as 
well.  This would hopefully preserve the "Last Change Date", but still allow 
people to generate a report easily, like is done for 
http://bugzilla.mozilla.org/describekeywords.cgi .

Comment 2

[Barry Marshall]

The final nice thing to add would be if there could be an additional boolean 
query option "Days since bug changed by Assignee", since this would hopefully 
raise a flag to allow QA people to transfer a bug to someone else if the person 
left the job if they found a huge gap.

Gervase probably has some thoughts on the subject, so we'll add him in on cc.

Comment 3

[Matthew Tuck [:CodeMachine]]

This sounds good to me but I have a few comments.

I'm not sure a keyword is the best option.

- There's currently no concept of a hardcoded keyword in Bugzilla that you need
to have defined in all installation and can't change.  I don't see why there
couldn't be, but in this case I think it would be suboptimal.
- No other keyword is automatically changed by the system.  Again, it could be.
- No other keyword would not be allowed to be changed by users.  But I think
keyword security is a desirable feature anyway, so allowing no users to change
it is a logical extension.
- No other keyword change would not alter the last changed date.

The combination of all these put together suggests it's probably best not as a
keyword.

Furthermore, I think there are some installations out there that have versions
of Bugzilla that support keywords but choose not to enable the feature (I
believe it can be disabled).  Hard to believe anyone would do that, sure, but if
the feature's there it needs to be supported.  It should be fairly easy to just
not use the keyword in this circumstance.  The only problem is if the
implementation requires this keyword on stale bugs for some sort of tracking
purpose, rather than the just the users using it.  Better to split the feature
off I think.

Perhaps this is best off as "Last Changed By Assignee/QA: Date (STALE)" next to
the "Opened" message just above the description.

Advanced query should probably be something like "If bug is stale".  This allows
the staleness policy to be changed by the database owner and automatically
change all bookmarks out there.

Although the QA reminders sounds fine (and similar things are already done with
assignees for NEW status bugs), I shudder to think what would happen if my
Bugzilla-bugs-to-QA list (that I inherited with hundreds of bugs and it still
has that many) got scanned.  I guess a mass-delete is fairly easy.

Comment 4

[Barry Marshall]

For the keyword, I was just thinking that it could be used to fire off the cgi 
reports and leave the rest up to the system to enforce the policy...  although 
the ideas for lockable status words are probably desirable  (esp. after the RTM 
stuff and people trying to give themselves automatic RTM+'s).

Does Mozilla log the dates that the ownership of a bug changes?  Presumably you 
could query on that date to keep the e-mails down.

I've read about the "New mail" spam problem that happened.  I would think that 
if you proded the owner first and then waited a couple of weeks before asking QA 
to take a look, you'd probably avoid too many false problems.   

The above being said, there's some pretty bogus data in the system, which really 
needs to be cleaned up.  You could even apply this function gradually to not 
**** off too many people at once.  Even if you take a look at stuff that's 
"active" and hasn't been changed in 270 days ( 
http://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bu
g_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned
_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&c
hangedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=&short_desc
_type=substring&long_desc=&long_desc_type=substring&bug_file_loc=&bug_file_loc_t
ype=substring&status_whiteboard=&status_whiteboard_type=substring&keywords=&keyw
ords_type=anywords&field0-0-0=%28to_days%28now%28%29%29+-+to_days%28bugs.delta_t
s%29%29&type0-0-0=greaterthan&value0-0-0=270&cmdtype=doit&order=Reuse+same+sort+
as+last+time ) as of today it's 116 problems.  You gotta think we're in the area 
of missing assignee people now.
   
The worst case would be if someone was away for a while, so they wouldn't be 
able to work on the problem.  Maybe an "I'm away on vacation/sabatical" message 
would help keep people's expectations in line...

Comment 5

[Gervase Markham [:gerv]]

As I se it, the correct "process" here is that the QA contacts are responsible 
for periodically checking that a given bug is still present (and, if not,
closing it.) It's all very well being able to find the stale bugs, but there's 
no point if no-one is going to do anything about them. 

Mailing the QA Contacts of a bug list is definitely something that should be 
added to the bottom of the bug listing page. 

I don't think we need a special query for "stale" bugs because the query to find 
them is as simple as I said earlier - query for "not changed in 3 months and not 
Future" (roughly; "not changed" actually means "not commented on".)

Gerv

Comment 6

[Matthew Tuck [:CodeMachine]]

It might be best to send out periodic reports to people, using bug #73004. 
Using that the admin can choose who they want the reports to go to.  They might
be reports to the assignee & QA, or they might go to just one person.

Comment 7

[Dave Miller [:justdave]]

-> Bugzilla product

Comment 8

[xyzzy]

Heh, this bug is now stale!  ;)  See also bug 119305 more discussion of handling
stale bugs and custom statuses for this.

Comment 9

[Dave Miller [:justdave]]

*** Bug 155225 has been marked as a duplicate of this bug. ***

Comment 10

[Lee]

I agree to the automation part.What I would like to suggest is a new field
called timeout or something simlilar.

After the inactivity timeout
bugzilla should automatically send an email to the reporter,to ask whether he is
still experiencing the problem in current builds.

The no of days/months should be configurable.
Release specific bugs should  timeout when the next release occurs.
Other bugs can have timeouts from 1 month to no of months.

There may also be easier methods.
Anyway there are a lot of bugs out there which are open, only because the
repoter no longer checks his email, or he cannot test using a newer build
(download problems).

Comment 11

[Dave Miller [:justdave]]

Reassigning all of my "future" targetted bugs to indicate that I'm not presently
working on them, and someone else could feel free to work on them.

Comment 12

[Dave Miller [:justdave]]

Reassigning all of my "future" targetted bugs to indicate that I'm not presently
working on them, and someone else could feel free to work on them. (sorry for
the spam if you got this twice, it didn't take right the first time)

Comment 13

[Frédéric Buclin]

I agree with MattyT in comment 6

*** This bug has been marked as a duplicate of 185090 ***