On 2004-01-18, Clover <[EMAIL PROTECTED]> wrote: > let's continue the editorial stuff :-) > > http://www.mozilla.org/quality/bug-writing-guidelines.html
I'm not sure this doc is one of the most in need of work, really... >> Are you in the right place? > > Are reports from Netscape users still a problem? If not, can we remove > this? We should get into the meat quicker. I haven't seen any Netscape reports recently, but I have seen a Debian report though, so I think that bit does need to be there. >> The Mozilla bug tracking system (Bugzilla) allows any interested >> individuals on the Internet to directly report and track bugs in >> mozilla.org open-source projects like the Mozilla Application Suite >> or Mozilla Firebird. > > Our issue tracking system (Bugzilla) I think the original is better - "The Mozilla bug tracking system..." > allows any interested individual to > report and track issues in mozilla.org products like the Mozilla > Application Suite or Mozilla Firebird. fine. >> Like you, Mozilla QA (Quality Assurance) wants your bug reports to >> result in bug fixes; the more effectively a bug is reported, the >> more likely that an engineer will actually fix it. > > mozilla.org QAs (Quality Assurance) want your bug reports to result in > bug fixes; the clearer and more useful a bug report is, the more likely > that an engineer will fix it. Again, I'm afraid I think the original is better mostly - how about: Mozilla QA (Quality Assurance) wants your bug reports to result in bug fixes; the more effectively a bug is reported, the more likely it is that an engineer will fix it. >> By following these guidelines, you can help ensure that your bugs >> stay at the top of the Mozilla engineers' heap, and get fixed. > > By following these guidelines, you can help ensure that your reports > recieve the proper attention and get resolved. fine, but it's "receive" >> Bugzilla is the preferred method of submitting a bug - the linked >> entry form incorporates parts of these guidelines. > > "the linked entry form" is probably confusing except to the document > writer. Remove this sentence. Also, the first sentence should probably > be merged to the previous paragraph: "...the more likely that an > engineer will actually fix it. By following these guidelines, you can > help ensure that..." Yes, that would be good. The bug entry form is linked further down. [snip some changes that I think are ok] >> If you're crashing on a site, please take the time to isolate >> what on the page is triggering the crash, and include it as an >> HTML snippet in the bug report if possible. > > If you crash on a site, take the time to isolate what on the page is > triggering the crash, and include it as an HTML snippet in the bug > report if possible. I think the original is better - "If you're crashing" implies reproduced crashes, rather than a single crash. I don't see a need to remove the "please" either. >> (Specific bugs have the added bonus of remaining relevant when an >> engineer actually gets to them; in a rapidly changing web, a bug >> report of "foo.com crashes my browser" becomes meaningless after >> the site experiences a half-dozen redesigns and hundreds of content >> changes.) > > remove the brackets. fine > "specific bugs" sounds like "certain bugs". I suppose it can sound that way - I can't say I read it that way. > Explicit bugs have the benefit of remaing relevant. In a rapidly > changing Web, ... browser" may become meaningless after the site > experience re-design or content changes. that's ok, but it should still be "experienceS" >> Let's say you crash at foo.com, and want to write up a bug >> report: > > Let's say you crash at foo.com and want to file a bug report: Well, this bit is really about writing the report, rather than filing it. >> Mozilla crashed each time upon drawing the Foo banner at the top >> of the page. > > nees a "Good:" label No, it's just a continuation of the previous "good". It could be made clearer that the two paragraphs go together, maybe by making "bad" and "good" into headings, rather than using caps and <strong> tags. >> If your problem is Mozilla crashing, Talkback data is very >> helpful in diagnosing the problem. > > If your problem is Mozilla crashing, Talkback data is very helpful for > engineers diagnosing the problem. I'm not sure this is better, but either is fine... >> If you can consistently reproduce the crash, please download >> a build with Talkback and install it. > > If you can consistently reproduce the crash, download and install a > build with Talkback. fine, but again I don't see why we need to drop the "please". >> Then, do what is necessary to reproduce the crash, and follow >> the instructions for sending crash data to the server. > > Then, reproduce the crash and follow the on-screen instruction for > sending crash data to the server I think "do what is necessary to" is better. "on-screen" is good, but it should still be "instructionS". >> Lastly, run the program components/talkback.exe (Win32) > > (Windows) yes, good. >> Before you enter your bug, you need to make sure it has not >> been previously reported. There is a tutorial on the best >> ways of doing this. > > A large number of bug reports are duplcates of previously reported ones. I'm not sure this adds anything really... > Before filing a bug report, make sure it has not been reported. that's not a good sentence - "you need to" or "you should" is better. >> Next, be sure that you've reproduced your bug using a build released >> within the past three days. Our development process moves at lightning >> speed, and the bug you've found may already have been fixed. >> (Nightly builds can be downloaded from the mozilla.org binaries page.) > > Be sure that you can reproduce your bug in a <a > href="http://www.mozilla.org/developer/#builds";>nightly build</a> > released within the past three days. Our development process moves at > lightning speed, and the bug may already have been fixed. that's good. > Is "three days" too much? This guidelines is more for new bug reporters > who tend to be less enthusiastic than most QAs. The time period should > be in line with the start/ page (two week?) 3 days is certainly extreme - could we just leave this as vague and say "recent". I don't think there are many people that use nightly builds that are very old, if they're downloading a build to test their bug, it will be recent anyway. >> If you've discovered a new bug using a current build, report it in >> the guided Bugzilla entry form. > > Remove. People without canconfirm previlege don't know there is an > "unguided version". And those who should use the guided form have to use > it anyway. Well, possibly. But you can't really remove only that, because the next bit says that if you're using the guided form, you don't need to read it. Maybe the rest should be split into a separate doc (or just removed?) seeing as it only applies to people with 'canconfirm'. >> Version: In which product version did you find the bug? >> We're not yet using this field. Just leave the default value as you >> found it. ;) > > is this still true? > and loose the smily No - it's now used for branch/trunk. >> (If they all look meaningless, click on the Component link, which >> links to descriptions of each component, to help you make the best >> choice.) > > Component link should link to > http://bugzilla.mozilla.org/describecomponents.cgi I'm not sure this (and the following bits) need to be links. The point is that they're linked from the form. >> If you encountered the bug on a particular URL, please provide >> it (or, them) here. > > I don't think it's good practice to file a bug report against several > URLs. If the bug exists in many URLs, the reporter should find the one > that best represents the issue and stick it in the URL field. I'll go > with just "it" yeah. > Also, "on a particular Web location" I think URL is fine, given the context talking about URLs. >> Summary: How would you describe the bug, in approximately 60 or >> fewer characters? > > in 10 to 15 words or less 10 to 15 words is too many, unless they're very short words :) >> Otherwise, developers cannot meaningfully query by bug summary, > > what does "query" mean? replace with "search" > I'm not sure about "meaningfully". fantasai, suggestion? I think meaningfully is ok. >> Please provide as detailed of a problem diagnosis in this field >> as possible, including as much as possible of the following >> information: > > Please provide a detailed problem diagnosis, including... I think leave the "in this field" -- Michael _______________________________________________ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
