-- -Simply put, the more effectively you report [% terms.abug %], the more - likely an engineer will actually fix it. This tutorial teaches novice and - intermediate [% terms.bug %] reporters how to write effective - [% terms.bug %] reports.
-
Effective [% terms.bug %] reports are the most likely to be fixed. + These guidelines explain how to write such reports. -
-- -Useful [% terms.bug %] reports get [% terms.bugs %] fixed. - A useful [% terms.bug %] report has two qualities:
+Principles
-
-- It's Reproducible. Engineers usually prefer to fix [% terms.bugs %] - they can actually see. If an engineer can't reproduce the [% terms.bug %], - it'll probably be stamped "[% get_resolution("WORKSFORME") FILTER html %]" or - "[% get_resolution("INVALID") FILTER html %]".
- -
-
-- It's Specific. The quicker an engineer isolates the - [% terms.bug %] to a specific area, the more likely it'll be fixed. (If the - engineer must decipher your [% terms.bug %], - he or she will waste time cursing you instead.)
+
-- Be precise
+- Be clear - explain it so others can reproduce the [% terms.bug %]
+- One [% terms.bug %] per report
+- No [% terms.bug %] is too trivial to report - + small [% terms.bugs %] may hide big [% terms.bugs %]
+- Clearly separate fact from speculation
-Can't find your [% terms.bug %] in [% terms.Bugzilla %]? And you can reproduce -it in a recent build? Let's report it. -+
If you have reproduced the [% terms.bug %] in a recent build and +no-one else appears to have reported it, then:
Where did you find the [% terms.bug %]?
--- -Product: In which product did you find it?
- -
- You just specified this on the last page, so you can't edit it - here.Version: In which product version did you find - it?
- -
- (If applicable)Component: In which component does it +
Component: In which sub-part of the software does it exist?
+ This field is required. + Click the word "Component" to see a description of each + component. If none seems appropriate, look for a "General" component.
- [% terms.Bugzilla %] requires that you select a component to enter - [% terms.abug %]. (Click the Component link to see a description of each - component.)OS: On which operating system (OS) did you find it? (e.g. Linux, Windows XP, Mac OS X.)
-
- If the [% terms.bug %] happens on all operating systems, choose "All". - Otherwise, select the OS, or "Other" if your OS isn't listed.
How important is the [% terms.bug %]?
- --- -Severity: How damaging is it?
-
- The default is 'normal' severity. (Click on the Severity link to see - a description of each severity rating.
-
Who will be following up on the [% terms.bug %]?
+ If you know the [% terms.bug %] happens on more than one type of + operating system, choose "All". + If your OS isn't listed, choose Other. --- -Assigned To: Which engineer should be responsible for fixing - it?
- -
- [% terms.Bugzilla %] automatically assigns the [% terms.bug %] to a - default engineer upon submitting [% terms.abug %] report. If you'd prefer - to directly assign the [% terms.bug %] to someone else, enter the person's - e-mail address. (To see the list of default engineers for each - component, click the Component link.)Cc: Who else should receive e-mail updates on changes to this - [% terms.bug %]?
-
- List the e-mail addresses of other people who should receive - an update whenever the [% terms.bug %] report changes. Enter as many e-mail - addresses as you'd like, separating them by spaces or - commas. Important: You can only enter people who have - [% terms.Bugzilla %] accounts.
What else can you tell the engineer about the [% terms.bug %]?
- -Summary: How would you describe the [% terms.bug %], in approximately 60 or fewer characters?
+ report. It should explain the problem, not your suggested solution.
A good summary should quickly and uniquely identify [% terms.abug %] - report. If an engineer can't identify your - [% terms.bug %] by its summary, it may be ignored when skimming through a - 10-page list.
-
- A useful summary is "Cancelling a File Copy dialog crashes Nautilus". - Examples of bad summaries would be "Software crashes" or "copy problem".
-
- Description:
- Provide a detailed problem report. [% terms.aBug %]'s recipients usually - expect the following information:
++
+ + Description: + The details of your problem report, including:- Good: "Cancelling a File Copy dialog crashes + File Manager"
+- Bad: "Software crashes"
+- Bad: "Browser should work with my web site"
+--Overview Description: More detailed restatement of +
Overview: More detailed restatement of summary.
@@ -189,7 +111,8 @@ Drag-selecting any page crashes Mac builds in NSGetFactory-Drag-selecting any page crashes Mac builds in NSGetFactory +Drag-selecting any page crashes Mac builds in the NSGetFactory function.--1) View any web page. (I used the default sample page, resource:/res/samples/test0.html) +1) View any web page. (I used the default sample page, +resource:/res/samples/test0.html) 2) Drag-select the page. (Specifically, while holding down the mouse button, drag the mouse pointer downwards from any @@ -232,116 +155,28 @@ Build 2006-08-10 on Mac OS 10.4.3--- Doesn't Occur On Build 2006-08-10 on Windows XP Home (Service Pack 2) +Doesn't Occur On Build 2006-08-10 on Windows XP Home (Service Pack 2)Additional Information: Any other debugging information. - For crashing [% terms.bugs %]:
+Additional Information: Any other useful information. +
For crashing [% terms.bugs %]:-
- Windows: Note the type of the crash, and the module that the application crashed in (e.g. access violation in apprunner.exe).
-- Mac OS X: Attach the "Crash Reporter" log that appears upon crash. - Only include the section directly below the crashing thread, usually titled - "Thread 0 Crashed". Please do not paste the entire log!
- +- Mac OS X: Attach the "Crash Reporter" log that appears + upon crash. + Only include the section directly below the crashing thread, usually + titled "Thread 0 Crashed". Please do not paste the entire log!
You're done!
-
- After double-checking your entries for any possible errors, press the - "Commit" button. Your [% terms.bug %] report will now be in +Double-check your report for errors and omissions, then press "Commit". + Your [% terms.bug %] report will now be in the [% terms.Bugzilla %] database.
- -More Information on Writing Good [% terms.Bugs %]
- --[% INCLUDE global/footer.html.tmpl %] -- cgit v1.2.3-24-g4f1b1. General Tips for a Useful [% terms.Bug %] - Report
- --- -Use an explicit structure, so your [% terms.bug %] reports are easy - to skim. [% terms.Bug %] report users often need immediate access to - specific sections of your [% terms.bug %]. Follow the structure - recommended above.
- -Avoid cuteness if it costs clarity. Nobody will be laughing - at your funny [% terms.bug %] title at 3:00 AM when they can't remember how - to find your [% terms.bug %].
- -One [% terms.bug %] per report. Completely different people - typically fix, verify, and prioritize different [% terms.bugs %]. If you - mix a handful of [% terms.bugs %] into a single report, the right people - probably won't discover your [% terms.bugs %] in a timely fashion, if at - all. Certain [% terms.bugs %] are also more important than others. It's - impossible to prioritize [% terms.abug %] report when - it contains four different issues, all of differing importance.
- -No [% terms.bug %] is too trivial to report. Unless you're - reading the source code, you can't see actual software [% terms.bugs %], - like a dangling pointer -- you'll see their visible manifestations, such - as the segfault when the application finally crashes. Severe software - problems can manifest themselves in superficially trivial ways. File them - anyway.
-
-2. How and Why to Write Good [% terms.Bug %] - Summaries
- ---You want to make a good first impression on the [% terms.bug %] - recipient. Just like a New York Times headline guides readers - towards a relevant article from dozens of choices, will - your [% terms.bug %] summary suggest that your [% terms.bug %] report is - worth reading from dozens or hundreds of choices?
- -Conversely, a vague [% terms.bug %] summary like install - problem forces anyone reviewing installation [% terms.bugs %] to waste - time opening up your [% terms.bug %] to determine whether it matters.
- -Your [% terms.bug %] will often be searched by its summary. Just - as you'd find web pages with Google by searching with keywords, so will other - people locate your [% terms.bugs %]. Descriptive [% terms.bug %] summaries are - naturally keyword-rich and easier to find.
- -For example, you'll find [% terms.abug %] titled "Dragging icons - from List View to gnome-terminal doesn't paste path" if you search on - "List", "terminal", or "path". Those search keywords wouldn't have - found [% terms.abug %] titled "Dragging icons doesn't paste".
- -Ask yourself, "Would someone understand my [% terms.bug %] from just - this summary?" If so, you've succeeded.
- -Don't write titles like these:
- --
- -- "Can't install" - Why can't you install? What happens when you - try to install?
- -- "Severe Performance Problems" - ...and they occur when you do - what?
- -- "back button does not work" - Ever? At all?
-Good [% terms.bug %] titles:
- --
-- "Save button disabled after failed post attempt" - - Explains the problem and context.
- -- "Enter & Escape have no effect in 'Upload Photos' dialog" - - Also explains the problem and context.
-