隐错管理/Phabricator礼仪

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

你还须遵守行為準則的规定。

• 评论应该与提报、确认、评估严重程度或修复隐错直接相关。 与报告主题无关的想法（例如，关于一般情況下优先级的元级的讨论或关于是否需要一个新扩展的讨论）应该變成為适当的邮件列表、wiki讨论页或单独的报告。
  • 批评想法，而不是批评人。 健康的建设性批评和活跃的辩论有助于改善我们的软件，我们鼓励这样做。
  • 開大門走大路。 除非你报告的是一个安全问题，或者你被要求给某人发电子邮件提供具体信息，否则请将所有与隐错报告有关的技术信息放在报告本身中。
• 报告状态和优先级字段，总结和「反映出现实」，請「不要」導致它。 请阅读有关优先级字段值的含义，在有疑问时，不要改变它们，但要添加一个建议改变的评论和有说服力的理由。
  • 一般来说，看到隐错得到解决的最快方法是提供补丁（另见开发的优先级）。
  • 提高一个隐错的优先级的有說服力的理由，應包括：能表明它會对正常的、日常的工作有很大影响的证据。 伪造的例子或只會出现在不太可能的情况下的问题，這通常就是将问题视为 "低 "优先级的证据，因为只要你足够努力，任何非微不足道的软件的极限都可以被超越。
  • 不要发表类似于“现在解决这个”的投票或留言。
• 只有在他們事先同意的情况下，才可以手动分配任务給某個人。 他们打算做什么，這取决于开发人员（或他们的产品经理）。
• 倾向于使用Phabricator的用户名（如@username），而不是一个人的真实姓名或其他个人的識別碼。 为了解決隐私和不必要的混乱的擔心，在交流各种任务、粘贴、phame帖子等时，请使用Phabricator用户名。 即使你在个人层面上认识真的个人（真实姓名...等等），他们可能不希望将这些信息与他们的Phabricator用户名相关联。 这也给其他不知道某人的真实姓名或其他个人識別碼的Phabricator用户呈現另一层的混乱。
• Use notification features (such as mentions, subscriptions, and Herald rules) with care and respect for others. Prefer rules which follow specific items (project tags, tasks, etc.) rather than individual users. Avoid creating Herald rules which subscribe you to an individual users' activity unless there is a clear and shared reason for doing so (for example, mentorship or collaboration). If you are asked to stop such activity, take steps to narrow or disable such activity. Persisting after such a request can become unwanted attention or hounding as defined in the 行为准则 .
• Carefully review your AI (Artificial intelligence)- or LLM (Large language model)-assisted report. When creating and submitting a task or a comment, you are fully responsible for its content. Your text must be accurate, factually correct, and represent your own understanding of the topic. You must review and verify any such content before its submission. Always disclose the use of LLM/AI tools when creating and submitting a task or a non-trivial comment.

如果你看到有人不遵守这些准则或没有成效：

1. 第一步是与他们联系。 在小的情况下，可以通过私人电子邮件进行，在大的情况下，可以公开进行，以避免以後对可容忍的行为有任何的假设。
   • 要提供有用的信息 – 告诉他们正在做的事情是不应该做的。 若算是恰當，请让他们了解本文件。
   • 要起催化的作用 – 告诉他们应该怎么做，作為替代。 偶尔，这可能是鼓励和激励，比密密麻麻的 "规则 "清单更好。
2. 在持续无视这些准则的情况下，请在Wikimedia IRC上呼唤一个在#wikimedia-releng ^在线的Phabricator管理员，或者联系牧「碼」人，请他们调查一下。 假使有不理會的行為出現，被视为是行为守则所定义的不可接受的行为，将會通知行为守则委员会。

絕妙好文

• Mozilla禮儀
• 在Mozilla開發網路裏Bugzilla的當為與不當為
• 在teamractices邮件列表中的对话，提到在Bugzilla中使用RESOLVED WONTFIX（现在在Phabricator中「被拒绝」）和相关问题

参阅

• 为什么还没有人解决这个问题？为什么没有人征求我对这些变化的意见？我怎样才能影响所做的工作？
• 隐错报告的生命周期
• Bugzilla方式和wiki方式的异同点
• 如何提交程序漏洞
• Phabricator/帮助
• 预期的行为