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 <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 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 which has been released. Because sometimes there are no daily nightly builds, especially on tier-2 platforms like Firebird or Camino. >>> 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'. People with 'canconfirm' do not need to read this document. They already know how to write a good bug report or they wouldn't have gotten 'canconfirm' in the first place. They should read the bugzilla privilege guide instead. So we should remove the paragraph talking about the unguided form and only speak of the guided form here. >>> 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. We should remove this. >>> (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. I think another link adds value to this document. This should make the reporter think about where to put his bug report *before* he writes it. >>> 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 :) Right. 5 to 10 is better >>> 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. Use "easily": Otherwise, developers cannot easily search by bug summary, 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
