x-post to qa.general and documentation post replies to documentation http://www.mozilla.org/quality/help/beginning-duplicate-finding.html
Just updated the how to find previous reported bugs page for the new (actually, old) query layout: http://www.mozilla.org/webtools/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=beginning-duplicate-finding.html&branch=&root=/cvsroot&subdir=mozilla-org/html/quality/help&command=DIFF_FRAMESET&rev1=1.6&rev2=1.7
Other changes I want to do:
The Mozilla developers want to hear about every specific and reproducible bug that happens when you use Mozilla, but it does not help to have the same bug reported many times. You can help to get more bugs fixed faster by checking the Bugzilla database before submitting your bug report, and not creating a duplicate report if the bug you found has been reported already.
This page should also be targeted to new QAs who would like to improve their bug query skills:
If you are:
*A bug reporter* : The Mozilla developers want to hear about every specific, reproducible bug you find, but having the same bug reported many times does not help. You can help to get bugs fixed faster by checking the Bugzilla database before submitting your bug report, thus avoiding duplicate reports. This article shows you know.
*A QA contributor* : Effective search skill can save valuable time tracking down the bugs you would like to find. This article show you tips to improve your bug search skills.
If you find that the problem you identified has already been reported, do not report it again, but if you have something useful to contribute, please do add a comment to the existing report.
If you find that the problem has already been reported, do not report it again. However, if you have something useful to contribute, please do add a comment to the existing report.
should there be <em> around "useful"?
Doing the Query
The Bugzilla Query Form looks dauntingly complex - it is complex and powerful - ...
I would like to remove the left margin. I think <dd> is mis-used here.
But if you're using a milestone build,
This page should be targeted to new users who may not know terminologies used in mozilla.org. We should use something other than "milestone", but I can't think of an alternative now.
The Status field is set by default to find NEW, ASSIGNED, and REOPENED bugs—the unfixed bugs. But if you're using a milestone build, you should add RESOLVED and maybe VERIFIED (use Ctrl-click on MS-Windows, Command-click on MacOS), especially if the milestone is a few weeks old, since many bugs will have been fixed since your build was released.
In my experience, it is better to change Resolution field than Status field. But for new users, Status might be easier.
We should expand this paragraph to:
*Status*
This field is set by default to find NEW, ASSIGNED, and REOPENED bugs—the unfixed bugs. If you are using a non-development build, you should add RESOLVED and VERIFIED, since many bugs will have been fixed since your build was released (to select multiple items, use Ctrl-click on Windows and Linux, and Command-click on Mac).
*Tip*: The *Resolution* field can sometimes be more helpful. For example, if you want to search for both fixed and open bugs using the status field, you practically need to check all status items, and the results may include many irrelevent INVALID and WONTFIX bugs. You can do this easily by matching for --- and FIXED resolution.
Note if Status and Resolution are both set, they may interfere with each other. Normally it is safe to clear the Status field and set Resolution only. To clear an item, press Shift and click the item.
Resolution Use
--- Open bugs, including UNCONFIRMED, NEW, ASSIGNED, and REOPENED
DUPLICATE Useful if cannot find the relevant open bug, but you
know/suspect that many users have experienced it and have
reported it many times.WONTFIX Useful if your bug is an enhancement and you want to find out
if it has already been decided not to be done.INVALID WORKSFORME These are normally useful only for special cases.
In the Product field, you should use:
This should be moved before Status because in the current layout it appears before Status.
We should add Tech Evangelism:
Tech Evangelism: If you are experiencing problem with a Web site, it may be because the site uses proprietary technologies specific to certain browsers, contains code error, and un-intentionally blocks out new browsers released after the site goes online. The Tech Evangelism tracks site issues that are not software problems. Use the URL field in combination with this product.
Enter a word or short phrase that identifies the problem you saw as uniquely as possible in the Summary field. Examples: view source, auto proxy, drag drop, png image. If you enter more than one word and they are not a phrase, change the type of matching for the Summary field from contains the string to contains all of the words/strings or contains any of the words/strings, as appropriate (just to the left of the text-entry field).
*Summary*
Enter a word or short phrase that identifies the problem. The search pattern should be as unique as possible. Examples:...
Don't use the Keywords field without first clicking on the word <a>Keywords</a>: you can't type just anything in there. If you try to use this for keywords that are not on the list, it won't work, but some of the defined keywords may be useful to narrow down your search.
*Keywords*
Only certain terms are allowed in this field. You should check with <a>keyword list</a> if you want to use it. Keywords can be helpful for certain bugs:
crash - for software or system crash
hang - for problem where the software becomes unresponsive
temporarily or permenantly
4xp - for features in Netscape 4.x but not in Mozilla 1.x
intl - for internationalization issues
css1
css2
css3
dom0
dom1
dom2 - for CSS and DOM problems
regression
- for issues that do not occur in earilier builds/versions but
occur recently.When you have done all that, click on the [Search] button. A new page will load, and on it you should see a list of bugs that match your query.
Wordy. remove the 2nd sentence _______________________________________________ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
