| | 8 | == Reporting bugs == |
| | 9 | |
| | 10 | Please consider following guidelines for writing effective bug reports: |
| | 11 | * Please take a moment to check that your problem hasn't already been reported : [search: Search module] |
| | 12 | * Be specific. If you can do the same thing two different ways, state which one you used. “I selected Load” might mean “I clicked on Load” or “I pressed Alt-L”. Say which you did. Sometimes it matters. |
| | 13 | * Be verbose. Give more information rather than less. If you say too much, the programmer can ignore some of it. If you say too little, they have to come back and ask more questions. One bug report I received was a single sentence; every time I asked for more information, the reporter would reply with another single sentence. It took me several weeks to get a useful amount of information, because it turned up one short sentence at a time. |
| | 14 | * Be careful of pronouns. Don’t use words like “it”, or references like “the window”, when it’s unclear what they mean. Consider this: “I started !FooApp. It put up a warning window. I tried to close it and it crashed.” It isn’t clear what the user tried to close. Did they try to close the warning window, or the whole of !FooApp? It makes a difference. Instead, you could say “I started !FooApp, which put up a warning window. I tried to close the warning window, and !FooApp crashed.” This is longer and more repetitive, but also clearer and less easy to misunderstand. |
| | 15 | * Read what you wrote. Read the report back to yourself, and see if you think it’s clear. If you have listed a sequence of actions which should produce the failure, try following them yourself, to see if you missed a step. |
| | 16 | |
