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) Leave actionable comments. Comments have to be constructive. Unless you have comments which are directly related to reporting, confirming,  evaluating the severity, or fixing the bug, do not add a comment to a report. In reports 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, you can 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 report, for example meta-level discussions on priorities in general, should go to the appropriate mailing lists or wiki talk pages.
 * 3) No obligation. "Free software" means that nobody owns it exclusively, not "all the developers are at my orders." 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. 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. Authority for decisions concerning how and whether WMF technical operations resources will be directed toward fixing particular bugs has been delegated to Tim Starling, Brion Vibber, and Mark Bergsma. Ultimate authority over WMF resources rests with the Wikimedia Foundation Board of Trustees. Those who disagree with WMF decisions are welcome to bring those issues to the board's attention or participate in board elections as a means of bringing about the desired change.
 * 4) Criticize things, not people. A healthy amount of constructive critique helps to improve software. We want to encourage vibrant debate inside of the Wikimedia community. We want you to disagree and effectively argue your case, without making conflicts personal. We require that you criticize things, not people. Examples of things include: interfaces, algorithms, and schedules. Treat people respectfully. Attacking a person may result in your Bugzilla account being disabled.
 * 5) Do things in public. Unless you were asked to email somebody with specific information, place all information relating to bugs in the bug report itself. Avoid sending private email; no-one else can read your mail if you do that. Others may send you private email relating to a bug report; if so, judge whether your response is relevant to everyone (then post it at the bug report) or to the sender of the email only (reply by email).
 * 6) Changing fields
 * 7) Be reluctant to change planning. If you are not the bug assignee, part of their management, or a contributor to the component in question, avoid changing the "Priority" or "Target Milestone" fields yourself. Instead, argue persuasively in the report that the bug has a serious user impact, or provide a patch. If in doubt, read about the meaning of the fields and do not change the fields of bug reports - add a comment instead, suggesting the change and convincing reasons for it.
 * 8) Accept decisions. A maintainer or major contributor to a component marks a bug as WONTFIX if it will not be fixed by anyone. 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. Do not reopen or close bug reports just to reflect your personal view on the issue (examples: as a sign of protest; as a consequence of how your own time will be spent).

Repeated ignoring of these guidelines may result in losing  rights on Bugzilla or 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. 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 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 (CC BY-SA 3.0)
 * https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla