Bug management/Phabricator etiquette/zh

请遵循这些准则，以确保是一个管理错误报告和功能请求的富有成效和协作的环境.

你还必须遵守的规定.


 * 评论应该与提报、确认、评估严重程度或修复隐错直接相关.  与报告主题无关的想法（例如，关于一般情況下优先级的元级的讨论或关于是否需要一个新扩展的讨论）应该變成為适当的邮件列表、wiki讨论页或单独的报告.
 * 批评想法，而不是批评人. 健康的建设性批评和活跃的辩论有助于改善我们的软件，我们鼓励这样做.
 * 開大門走大路. 除非你报告的是一个安全问题，或者你被要求给某人发电子邮件提供具体信息，否则请将所有与隐错报告有关的技术信息放在报告本身中.
 * 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.
 * Prefer using Phabricator usernames (e.g. @username) over a person's real name or other personal identifiers. To address both concerns regarding privacy and unnecessary confusion, when communicating on various tasks, pastes, phame posts, etc, please use Phabricator usernames. Even if you know individuals on a personal level (real name, etc.) they may not wish to have that information associated with their Phabricator username. It also presents a layer of confusion for other Phabricator users who are not aware of someone's real name or other personal identifiers.

如果您發現有人沒有遵照指引，請


 * 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.



文档声明

 * 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



參見

 * Why has nobody fixed this issue yet? Why wasn't I consulted about these changes? How I can influence what is worked on?
 * 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
 * Expected behavior
 * Expected behavior
 * Expected behavior