Bug management/Phabricator etiquette

Please follow these guidelines to ensure that is a productive and collaborative environment for managing bug reports and feature requests.

You must also follow the Code of Conduct.

Bug management/Phabricator etiquette Watch Download PDF Edit < Bug management Other languages:	English • ‎日本語 Please follow these guidelines to ensure that Phabricator 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 "Open main menu

You must also follow the Code of Conduct.

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, wiki talk pages, or separate reports. Criticize ideas, not people.[1] 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. Report status and priority fields summarize and reflect reality and do not cause it. Read about the meaning of the Priority field values and, when in doubt, do not change them, but add a comment suggesting the change and convincing reasons for it. As a general rule, the fastest way to see a bug resolved is to provide a patch (see also Development prioritization). Convincing reasons for raising the priority of a bug include evidence that it affects normal, everyday work significantly. Contrived examples or problems that only appear under unlikely circumstances are generally evidence for treating the problem as "low" or "lowest" priority, since the limits of any non-trivial software can be exceeded if you try hard enough. Only manually assign a task to someone if they have given their prior agreement. It is up to developers (or their product managers) what they plan to work on. If you see someone not following these guidelines or not being productive:

The first step is to contact them. This can be done through pr

vate 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 Phabricator administrator in #wikimedia-releng connect on Wikimedia IRC or contact the bugwrangler and ask them to look into it. In case the disregard can be seen as unacceptable behavior defined by the Code of Conduct, the Code of Conduct committee will be informed. Document inspiration	Edit Bugzilla@Mozilla etiquette Bugzilla dos and don'ts at Mozilla Developer Network Conversation on teampractices mailing list, referring to the use of RESOLVED WONTFIX in Bugzilla (now "declined" in Phabricator) and related problems See also	Edit Why has nobody fixed this issue yet? Why wasn't I consulted about these changes? How I can influence what is worked on? Bug management/Bug report life cycle Similarities and differences between the Bugzilla way and the wiki way Remedies available to users who disagree with Wikimedia Foundation technical decisions How to report a bug Phabricator/Help Expected behavior References	Edit ↑ Failure is Always An Option: How a Blameless Culture Leads to Better Results, Jessica Kahn, September 08, 2016 Last edited 13 days ago by Shirayuki

Content is available under CC BY-SA 3.0 unless otherwise noted. Privacy policy Terms of UseDesktop" https://m.mediawiki.org/wiki/Bug_management/Phabricator_etiquette#:~:text=Open%20main%20menu,Desktop"Open main menu Bug management/Phabricator etiquette Watch Download PDF Edit < Bug management Other languages:	English • ‎日本語 Please follow these guidelines to ensure that Phabricator is a productive and collaborative environment for managing bug reports and feature requests.

You must also follow the Code of Conduct.

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, wiki talk pages, or separate reports. Criticize ideas, not people.[1] 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. Report status and priority fields summarize and reflect reality and do not cause it. Read about the meaning of the Priority field values and, when in doubt, do not change them, but add a comment suggesting the change and convincing reasons for it. As a general rule, the fastest way to see a bug resolved is to provide a patch (see also Development prioritization). Convincing reasons for raising the priority of a bug include evidence that it affects normal, everyday work significantly. Contrived examples or problems that only appear under unlikely circumstances are generally evidence for treating the problem as "low" or "lowest" priority, since the limits of any non-trivial software can be exceeded if you try hard enough. Only manually assign a task to someone if they have given their prior agreement. It is up to developers (or their product managers) what they plan to work on. 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 Phabricator administrator in #wikimedia-releng connect on Wikimedia IRC or contact the bugwrangler and ask them to look into it. In case the disregard can be seen as unacceptable behavior defined by the Code of Conduct, the Code of Conduct committee will be informed. Document inspiration	Edit Bugzilla@Mozilla etiquette Bugzilla dos and don'ts at Mozilla Developer Network Conversation on teampractices mailing list, referring to the use of RESOLVED WONTFIX in Bugzilla (now "declined" in Phabricator) and related problems See also	Edit Why has nobody fixed this issue yet? Why wasn't I consulted about these changes? How I can influence what is worked on? Bug management/Bug report life cycle Similarities and differences between the Bugzilla way and the wiki way Remedies available to users who disagree with Wikimedia Foundation technical decisions How to report a bug Phabricator/Help Expected behavior References	Edit ↑ Failure is Always An Option: How a Blameless Culture Leads to Better Results, Jessica Kahn, September 08, 2016 Last edited 13 days ago by Shirayuki

Content is available under CC BY-SA 3.0 unless otherwise noted. Privacy policy Terms of UseDesktop" https://m.mediawiki.org/wiki/Bug_management/Phabricator_etiquette#:~:text=Open%20main%20menu,Desktop a new extension is wanted at all) should go to the Bug management/Phabricator etiquette - MediaWiki [m:Mailing lists/Overview|appropriate mailing lists]], wiki talk pages, or separate reports.
 * 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.
 * Report status and priority fields summarize and reflect reality and do not cause it. Read about the meaning of the Priority field values and, when Bug management/Phabricator etiquette - MediaWiki doubt, do not change them, but add a comment suggesting the change and convincing reasons for it.
 * As a general rule, the fastest way to see a bug resolved is to provide a patch (see also Development prioritization).
 * Convincing reasons for raising the priority of a bug include evidence that it affects normal, everyday work significantly. Contrived examples or problems that only appear under unlikely circumstances are generally evidence for treating the problem as "low" or "lowest" priority, since the limits of any non-trivial software can be exceeded if you try hard enough.
 * Only manually assign a task to someone if they have given their prior agreement. It is up to developers (or their product managers) what they plan to work on.

If you see someone not following these guidelines or not being productive:


 * 1) 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.
 * 2) *Be informative – Tell what they are doing what they should not do. If pertinent, make them aware of this document.
 * 3) *Be catalytic – Tell what they should do instead. Occasionally this may be encouraging and motivating, better than a dense list of "rules".
 * 4) In the case of persistent disregard of these guidelines, ping a Phabricator administrator in  on Wikimedia IRC or contact the bugwrangler and ask them to look into it. In case the disregard can be seen as unacceptable behavior defined by the Code of Conduct, the Code of Conduct committee will be informed.

Document inspiration

 * Bugzilla@Mozilla etiquette
 * Bugzilla dos and don'ts at Mozilla Developer Network
 * Conversation on teampractices mailing list, referring to the use of RESOLVED WONTFIX in Bugzilla (now "declined" in Phabricator) and related problems