On 2004-01-20, Clover <[EMAIL PROTECTED]> wrote: > http://www.mozilla.org/quality/help/beginning-duplicate-finding.html [snip] > 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.
I think the original wording of the end was better - how about: "You can help to get bugs fixed faster by checking the Bugzilla database before submitting your bug report, and not creating a new report if the bug you found has been reported already." I don't think the "This article..." bit adds anything, but if it is going to be there, it should of course be "how" and not "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. I'd say "searching" instead of the first "search skill", and "searches" instead of "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"? I don't think that will help - you could say "If you have additional useful information to add to the bug report, you can add a comment." >> 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. How about putting it in the negative - "if you're not using a recent nightly build". Hopefully people will know that they're not even if they don't understand how things work. > In my experience, it is better to change Resolution field than Status > field. But for new users, Status might be easier. true, but... > We should expand this paragraph to: [snip a long addition] I'm afraid that would just confuse things - keep it simple in this document. That kind of thing might belong in a document of advanced searching tips or something, but I don't think it should go in here. >> In the Product field, you should use: > > This should be moved before Status because in the current layout it > appears before Status. That makes sense. There are mistakes in the Product field text - however, it will need a big change as and when bugzilla is reorganised anyway. > 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. several issues with that. a corrected version: Tech Evangelism: If you are experiencing a problem with a web site, it may not be a browser bug, but a result of the site using proprietary technologies, containing code errors, or unintentionally blocking newer browsers. Tech Evangelism bug reports track issues with these websites. 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:... I think the original was better - nobody will understand "search pattern". >> 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. way too many! and most of those keywords aren't used everywhere they should be. We have a link to the list, there is no need to repeat it all! Maybe just give "crash" and "hang" as examples. >> 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 I think the idea of it is good. maybe just "click on the [Search button] to display the list of matching bugs." -- Michael _______________________________________________ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
