| 13 | |
| 14 | 1. Do not set a due date for bug reports - I don't think that is appropriate, especially when you set it to *today*. The due date field is for developers, not to express your expectations. |
| 15 | |
| 16 | 2. Do not expect bugs being solved when your report is being modified for triage - especially not if the developer asks you back for more details. |
| 17 | |
| 18 | Instead, be so kind and answer the questions that you get back on your report (=comments in the report) within 2 weeks - otherwise we're unable to do anything else than to close the report as "invalid". |
| 19 | |
| 20 | 3. Please do not either expect that by closing a bug report as "fixed" the respective fix does immediately get applied to your testing site. |
| 21 | |
| 22 | If a bug report is being closed, you should not immediately re-open it just because the fix has not yet reached your test server. It is very distracting to try to identify bugs that I have actually fixed yesterday - so, please give a minimum delay of 5 days before re-opening a "fixed" report or re-submitting the same issue. |
| 23 | |
| 24 | 4. Do not either expect a bug being removed when we're closing it as "duplicate". If we identify and close your report in module XXX as a |
| 25 | duplicate of a similar report in module YYY, then you should not re-open it with the comment "but this has been seen in XXX". |
| 26 | |
| 27 | Please do understand that from the architecture of our software it can very well be the same problem which just affects multiple modules - and if we identify it as a duplicate, then that is usually true. |
| 28 | |
| 29 | 5. If anyhow possible, please try to check whether your problem has already been reported. We're experiencing up to 10 different reports for one and the same issue, with just different wording, sometimes by the same tester. |
| 30 | |
| 31 | Of course we do not expect you to always manage to identify duplicates, but if it is obvious, then you can help us more by avoiding needless extra work. |
| 32 | |
| 33 | 6. Please *do* always specify the component you found the issue in, but do *not* set it back if *we* changed your setting. |