Bug management/Bugzilla etiquette
Please follow these guidelines to ensure that Bugzilla is a productive and collaborative environment for managing bug reports and feature requests.
- Comments should be directly related to reporting, confirming, evaluating the severity, or fixing the bug. Thoughts unrelated to the topic of the report (for example, meta-level discussions on priorities in general or on whether a new extension is wanted at all) should go to the appropriate mailing lists or wiki talk pages.
- Criticize ideas, not people. A healthy amount of constructive criticism and vibrant debate helps to improve our software and is encouraged.
- Act in public. Unless you are reporting a security issue or you were asked to email somebody with specific information, place all technical information relating to a bug report in the report itself.
- Bug status, priority, and target milestone fields summarize and reflect reality and do not cause it. Read about the meaning of the fields and, when in doubt, do not change them, but add a comment suggesting the change and convincing reasons for it.
If you see someone not following these guidelines or not being productive:
- The first step is to contact them. This can be done through private email in minor cases, or in public in major cases to avoid any later assumptions of tolerated behavior.
- Be informative — Tell what they are doing what they should not do. If pertinent, make them aware of this document.
- Be catalytic — Tell what they should do instead. Occasionally this may be encouraging and motivating, better than a dense list of "rules".
- In the case of persistent disregard of these guidelines, ping a Bugzilla administrator on Wikimedia IRC or send an email to the bugwrangler and ask him or her to look into it.
Document inspiration[edit | edit source]
- Bugzilla@Mozilla etiquette
- Bugzilla dos and don'ts at Mozilla Developer Network
- Conversation on teampractices mailing list, referring to the use of RESOLVED WONTFIX and related problems