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.

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 .

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.

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.

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

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

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.

-> Bugzilla product

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

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

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

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.

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)

I agree with MattyT in comment 6 *** This bug has been marked as a duplicate of 185090 ***