Bug management/Phabricator etiquette

Please follow these guidelines in order to keep Bugzilla a productive, constructive and collaborative environment for managing bug reports and feature requests.

Leave actionable comments. Comments should be constructive. That is, comments should be directly related to reporting, confirming, evaluating the severity, or fixing the bug. Constructive and helpful thoughts unrelated to the topic of the report (for example, meta-level discussions on priorities in general, on whether a new extension is wanted at all, or on any decisions made by WMF management) should go to the appropriate mailing lists or wiki talk pages.

No obligation. We're all here because we care, but your desires don't translate into an obligation for anyone other than you to work on them. Therefore, you should not act as if you expect someone to fix a bug by a particular date or release, nor as if bug reporters and commenters have an obligation to become professional testers for you. Aggressive or repeated demands will not be received well and will almost certainly diminish the impact and interest in your suggestions. Providing a patch often helps to speed up fixing a bug; +2 is one policy for approving proposed code.

Criticize ideas, not people. A healthy amount of constructive criticism helps to improve software. Vibrant debate inside of the Wikimedia community is encouraged. In cases of disagreement, effectively argue your case without making conflicts personal and always treat people respectfully. Focus on development matters such as interfaces, algorithms and implementation details, rather than on specific individuals.

Act in public. Unless you were asked to email somebody with specific information, place all technical information relating to a bug report in the report itself.

Bug fields aim for realism. Bug status, priority and milestone should reflect (summarise) reality, they don't cause it. Avoid changing them if you don't have experience doing so in the component in question: instead, argue persuasively in the report that the bug has a serious user impact, or provide a patch. In general: if in doubt, read about the meaning of the fields and do not change them, but add a comment suggesting the change and convincing reasons for it.

Be willing to accept decisions. Bugs and enhancement requests may be set by the development team to higher or lower priorities than you would like, or they may be closed as WONTFIX if they are changes that those with authority over the matter have decided should not be made. You may disagree with these decisions, but do not fight the decision by re-opening (or closing) reports or by posting rants. Further technical information may still be submitted in Bugzilla. Efforts to persuade others that the wrong decision was made should take place outside of Bugzilla.

Repeatedly ignoring these guidelines may result in losing  rights on Bugzilla or in your Bugzilla account being disabled.

If you see someone not following these guidelines, the first step is to make them aware of this document. This can be done via private email in minor cases, or in public in major cases to avoid the assumption of tolerated behavior. In the case of persistent disregard of these guidelines, ping a Bugzilla administrator on Wikimedia IRC or send an email to the bug wrangler and ask him or her to look into it.

Document inspiration

 * https://bugzilla.mozilla.org/page.cgi?id=etiquette.html (CC BY-SA 3.0)
 * https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla
 * conversation on teampractices@, referring to the use of RESOLVED WONTFIX and related problems