Hacking for Christ

Gerv,

Thank you for posting this information. I'm pleased to learn that bugs closed by this process will be RESOLVED EXPIRED. It addresses my main concern with this process as I will still have a way to search the entire set of "open" bugs.

Gerv, I think the focus on UNCO is one part of this plan that confuses me... The average quality of NEW bugs that haven't really been looked at (and we have plenty of those) and UNCO bugs that are still open after a few years is about the same, in my experience...

I completely second what Boris said above. I just don't see the point. It makes no difference from my point of view to have UNCO "cannot in editor move caret from right to left of image using arrow key" or NEW "cannot in editor move caret from right to left of image using arrow key".
The bug is here, visible from both the developers and the users, and that's what finally matters.
As you said, we lack manpower. Not only on QA. It means that the triage we make, and the priorities/milestones we set are very often approximative, to say the least.
I got a rough 200 bugmails in less than 24 hours, coming from both your automaton and answers. This is not manageable. We're not all Hixie-observes-everything-reads-everything ;-)

Speaking of Hixie, has anyone seen him recently? I think he is under that huge pile of bugmail ;-)

Daniel: the big difference between the two bugs you mention is that the NEW one has been lifted out of the pile of rubbish consisting of all the other UNCO bugs. If you know that bug is a real bug, it should be NEW (possible process improvements and new states aside).

Bugzilla has a number of states for a reason - to help us track and manage bugs. the UNCO state is for bugs which are filed by people who aren't regular bug filers (and so who don't have canconfirm) and so has (or should have) a much higher proportion of rubbish bugs - dupes, invalids, what-on-earth-are-you-talking-abouts. The original idea was that developers would not concern themselves with UNCO at all, and just look at NEW bugs - it was a way of reducing their workload. This distinction seems to have been forgotten along the way.

the next time you add comments like this, can you make it clearer that people should _not_ test using the latest stable release? in various bugs, the reporter confirmed that the behaviour still exists in 1.0.7/1.7.12, which is really a pointless exercise.

biesi: I did add specific download links to 1.5b2 at the bottom of the email... There's not much more I can do! But I'll try and tighten up the wording.

> the big difference between the two bugs you mention is that the NEW one has
> been lifted out of the pile of rubbish

That would be true if people with canconfirm didn't file their rubbish as NEW by default. Given that they do, there's really not much distinction between a NEW no one competent has looked at and an UNCO no one competent has looked at.

> and so has (or should have) a much higher proportion of rubbish bugs

That's been pretty much false every single time Asa has run the numbers. The differences between general UNCO and general NEW were a few percent at best. The differences between the best and UNCO bug filers were about 15-20%, with the best people having 50% "real" bugs while the UNCO was at about 30%. Did this change significantly with Firefox? I'd love to see the new numbers (which we can get out of bugzilla) instead of vague guesses based on should-bes. Here by "rubbish" I mean things that end up dupe, invalid, etc. I'll agree that UNCO has a somewhat higher incidence of the "what are you talking about?" bugs, but even then it might not be by that much -- we have plenty of people with canconfirm (some of them even developers) filing such bugs with various frequencies.

That would be true if people with canconfirm didn't file their rubbish as NEW by default. Given that they do, there's really not much distinction between a NEW no one competent has looked at and an UNCO no one competent has looked at.

Name names! Or even bug numbers. By email if you like.

That's been pretty much false every single time Asa has run the numbers.

Asa's numbers are related to recently-filed bugs. The two sets of stats are not comparable. My point is that, after three months, almost all of the decent bugs in the UNCO pile have been confirmed. See my stats, linked, for details - but basically, the chance of a bug ending up FIXED after it's been UNCO for more than three months is pretty tiny.

Gerv, almost every single person I know of who has canconfirm has been guilty of filing crap bugs that really should have been filed as UNCO at one time or another (myself included here). The one exception might be timeless, who makes an effort to file bugs as UNCO when he really doesn't have enough information.

If you really want me to spend a few days digging up specific bugs, I can do that. I'm just not sure what that would help.

And yes, I did see your data on UNCO. What I'm saying is that the data for NEW would likely look similar -- the chance of a bug that's been NEW for over three months being fixed is not so hot if you just look at the numbers.

As for good UNCO bugs being confirmed, that depends on the component. Again, in all the layout components we have actively been discouraging QA from confirming bugs unless they have a minimal testase. This has been by far the best use of the UNCO status we could make in those components. But as a result there are plenty of real bugs that are UNCO just because they have no testcase yet.

Boris: I can see your point about the UNCO focus; however, we need to start somewhere. Once we have a READY state and it's been in use for a few months, it may be appropriate to do a similar thing for NEWs which are very old - say, nine months old.

I have been a frequent bug filer, but have never got the canconfirm or if I did it was taken away from me.

There are several types of bugs that may be unlikely to get confirmed:
* web evangelism bugs
* bugs that have unique configuration issues but still should be fixed (ie. a specific operating system or with specific operating system feature, in certain networked enviroments)
* bugs without sufficient details

I think you should leave the evangelism componet alone.

--Sam

I have to say, from a non-BugZilla perspective, and just from a tech support and issue triage perspective, this is a perfectly logical move, and I applaud it. "Old unresolved" is one of the hardest classes of issue to fix, for all of the reasons you suggest. If you don't pester the poster about the report, it really will sit there forever. This is a manpower-relieving way of group-pestering and getting useful feedback from the opt-back-in process, both on which bugs are worth fixing, and on which heuristics need adjustment in determining genuine orphaned issues. Learn by doing.

Excellent resource management. :)

Two questions:

1. If a bug is updated later on the same day that you add your automated comment, is that considered "changed since the date the comment was added"?

2. For bug reports that request enhancements, why should a test case be necessary?

Gerv: Inre: your comment to Daniel,
"the big difference between the two bugs you mention is that the NEW one has been lifted out of the pile of rubbish"
Just exactly who makes that determination as to what is garbage is a very important point. Many unconfirmed bugs IMO are the result of someone defacto acknowleging the bug, but determining that his prefs are such that that particular capability should not even be there in the first place. When in fact the bug is indeed valid.
Case in point: https://bugzilla.mozilla.org/show_bug.cgi?id=253435
This should have been marked as New then perhaps WONTFIXME
If that is even an official category.

Sam: Apply for canconfirm. We didn't do Tech Evangelism; I believe they opted out.

David: 1) Yes. 2) It's not - who said it was?

Re: Test cases for RFEs.

The criterion for closing unconfirmed bugs indicates that such bugs will not be closed automatically if they have the keyword "testcase". In general, this means that unconfirmed RFEs will be automatically closed since RFEs usually do not have test cases.

Perhaps RFEs should be handled with different criteria.

As one who has received three of these notices, I also applaud this effort. I was able to re-check these bugs and determine that they are no longer valid due to evolution of the browser.

Good plan, IMO.

I'd like to apologize for the semi-templated comments I made to some b.m.o bugs that were resolved as FIXED as, I thought, a results of this automated process. I didn't realise (until after I'd dealt with several of these) that it wasn't your automated process that was resolving the bugs, but other people in response to the automated process putting its comments in place. (I'd said that, perhaps, the bugs should be automatically resolved as WORKSFORME instead.) Having a completely different automatic resolution (EXPIRED) is a good thing and clearly dilineates between that and other resolutions.

This is all a good thing. It only server to prompt people to say a "negelected bug is either "still alive" or to deal with it properly.

"It only server"? Too late to correct the typo! I can only laugh at myself now. (I'll try not to notice the other typos, of which there is at least one more, since they aren't actually funny...)

Nice nice. A lot of useful here. good work
Thanks for all.

online

I'm with DR - "Perhaps RFEs should be handled with different criteria".

For bug reports that request enhancements, why should a test case be necessary?

hi i want to make following changes in Bugzilla.
1) Versions option should have active version as 1.3 , 1.1, 1.2 etc versions
should be available only for searching purpose in reverce order (should not be available for creating new bugs or modifying old bugs).
2) "Target Milestone" date should always be >= the current date. A user should not be allowed to create bugs with "Target Milestone" 3) Searching options should not be available until a user logs in into Bugzilla
with proper authentication.
4) what seeting need to be done to file Bugs from mail

how to impliment these

Arpan: See the Bugzilla support pages for the right place to ask such questions.