Re: bug writing guidelines
And on the seventh day Michael Lefevre spoke: [I agree with all those paragraphs, Michael, to which I said nothing.] >> 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... Better to improve an already good doc, instead of doing nothing. >>> 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. I agree. Netscape 7.1 has only been out for seven months and the 1.4 branch is still actively maintained. So this should stay at least until the 1.4 branch is abandoned. >>> 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..." I like "issue tracking system" because a lot of the bugs in bugzilla are no real bugs, but issues. Perhaps "The Mozilla issue tracking system..." >>> 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. I like this. But i think we should change the "engineer" to "developer" here, because "developer" is much more often used in mozilla.org documentation. We need to be consistent here. >I don't see a need to remove the "please" either. I agree. The small word "please" creates a much more friednly environment for the reader. >> "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" I hate the "explicit" as much as I hate the "specific". IMO there is simply no single adjective to explain what we want to say here. Just say: Bugs with an explicit testcase... >>> 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 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 we want to use the second text, please use "developer" instead of "engineer". >>> 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". Yes. >>> 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". I like Daniel's suggestion. Nut of course with "instructions" :-) >> 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. You didn't criticize that on my document. I used that all the time :-) >> 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. I agree that we shouldn't use a specific number of days here, but "recent" is too vague IMO. We should use "current" instead, which implies using a build of today or yesterday or using the latest nightly build whi
Re: bug writing guidelines
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 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 "i
Re: bug writing guidelines
And on the seventh day Clover spoke: >let's continue the editorial stuff :-) Please post a note about this discussion in the netscape.public.mozilla.qa newsgroups. Probably not all people there read *this* newsgroup. Simon -- Rusty: You scared? Linus: You suicidal? Rusty: Only in the morning. (Ocean's Eleven) ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
