On 2004-01-20 04:54, Clover wrote:
> 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. What about: "This article provides you tips on how 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"? No- this makes the document writers seem a little prejudiced towards newbies. It's too negative. >> 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. Might be a good idea, because it gets even more confusing with the <ul>, which moves some parts of the text even more to the right. > >> 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. "a major release like %%MOZILLA-STABLE-VERSION%%". > >> 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. Maybe this should be emphazied in some way? I believe that this hint is a very important one. 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. True. > > 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 "code errors" , and un-intentionally blocks out new > browsers released after the site goes online. The Tech Evangelism tracks > site issues that are not software problems. "... that are not problems caused by mozilla.org software." Just writing software errors doesn't make it clear enough that it's not Mozilla's fault. > 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. Is it really neccessary to list these keywords when there is a link to the complete list directly above? Surely, these are the most important ones, but still this list is a bit redundant. > >> 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 -- Benedikt Kantus on a Thumperbunny nightly _______________________________________________ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
