Bug management/Phabricator etiquette

Based on this conversation on teampractices@ (refering to the use of RESOLVED WONTFIX and related problems), this is a draft for behavior expectations in Wikimedia Bugzilla. It is based on Mozilla's Bugzilla etiquette. Please feel free to add comments to the Discussion page. --AKlapper (WMF) (talk) 16:10, 15 November 2013 (UTC)

Draft
There are a number of things to avoid when using Wikimedia's bug tracking tool Bugzilla. Please follow these guidelines in order to keep Bugzilla a productive and constructive environment for collaboration on managing bug reports and feature requests:


 * 1) Commenting
 * 2) No pointless comments. Unless you have something constructive and helpful to say, do not add a comment to a bug. In bugs where there is a heated debate going on, you should be even more inclined not to add a comment. Unless you have something new to contribute, then the bug owner is aware of all the issues, and will make a judgement as to what to do. If you agree the bug should be fixed, vote for it by using the "(vote)" link. An additional "I also see this problem" or "It works for me" comment including information about your browser and the web address is welcome if nobody else has confirmed the problem yet. However, further such comments are unnecessary unless they are about a different software version or different browser. Constructive and helpful thoughts unrelated to the topic of the bug report, for example meta-level discussions on priorities in general, should go to the appropriate mailing lists or wiki talk pages.
 * 3) No obligation. "Open Source" is not the same as "the developers must do my bidding." Everyone here wants to help, but no one else has any obligation to fix the bugs you want fixed. Therefore, you should not act as if you expect someone to fix a bug by a particular date or release. Aggressive or repeated demands will not be received well and will almost certainly diminish the impact and interest in your suggestions.
 * 4) No abusing people. A healthy amount of constructive critique helps improving software. We want to encourage vibrant debate inside of the Wikimedia community. We want you to disagree and effectively argue your case. However, we require that in the process, you attack things, not people. Examples of things include: interfaces, algorithms, and schedules. Examples of people include: developers, designers and users. Attacking a person may result in your Bugzilla account being disabled.
 * 5) No private email. Unless the bug owner or another respected project contributor has asked you to email them with specific information, please place all information relating to bugs in the bug report itself. Do not send them by private email; no-one else can read them if you do that.
 * 6) Changing Fields
 * 7) No messing with other people's bugs. Unless you are the bug assignee, have some say over the use of their time, or a contributor to the component in question, never change the "Priority" or "Target Milestone" fields. If in doubt, do not change the fields of bug reports that you are not the assignee of - add a comment instead, suggesting the change and the reasons for it.
 * 8) No whining about decisions. If a maintainer or major contributor to a component has marked a bug as WONTFIX, then it will not be fixed. Unless you have further important evidence, do not post a comment arguing that an INVALID or WONTFIX bug report should be reopened. If you think there is an important reason that has not been considered, you can add a comment to the bug report without reverting the status or resolution of the bug report.
 * 9) Applicability
 * 10) Some of these rules may not apply to you. If they do not, you will know exactly which ones do not, and why they do not apply. If you are not sure, then they definitely all apply to you.

Repeated ignoring of these guidelines may result in your Bugzilla account being disabled.

If you see someone not following these rules, the first step is to make them aware of this document, preferably via private email to avoid criticizing in public. In the case of persistent offending, ping a Bugzilla administrator on Wikimedia IRC or send an email to the bug wrangler and ask them to look into it.

The Wikimedia Foundation Code of Conduct provides further helpful guidelines.

Inspiration for this Wikimedia Bugzilla etiquette

 * https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
 * https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla