3.2. 提示与技巧

3.2.1. 自动链接

Bugzilla 评论是纯文本 - 因此发布 HTML 将导致字面 HTML 标签，而不会被浏览器解释。然而，Bugzilla 会自动将评论中某些类型的文本转换为超链接。例如，文本 http://www.bugzilla.org 将被转换为 http://www.bugzilla.org。其他以显而易见的方式链接的字符串包括

这里的一个推论是，如果您在评论中输入缺陷编号，您应该在它前面加上“bug”这个词，以便为了他人的方便而自动链接。

3.2.2. 快速搜索

快速搜索是一个单文本框查询工具，它使用元字符来指示要搜索的内容。例如，输入“foo|bar”到快速搜索中，将在缺陷的摘要和状态白板中搜索“foo”或“bar”；添加“:BazProduct”将仅在该产品中搜索。

您会在 Bugzilla 的首页上找到快速搜索框，以及一个 帮助 链接，其中详细介绍了如何使用它。

3.2.3. 评论

如果您正在更改缺陷上的字段，仅当您有相关内容要说，或者 Bugzilla 要求时才评论。否则，您可能会不必要地用缺陷邮件给人们发送垃圾邮件。举个例子：用户可以设置他们的帐户来过滤掉那些有人只是将自己添加到缺陷的抄送字段的消息（这种情况经常发生。）如果您也这样做，将自己添加到抄送字段，并添加评论说“将自己添加到抄送”，那么该人会收到一封毫无意义的邮件，否则他们本可以避免。

不要在评论中使用签名。签名您的名字（“Bill”）是可以接受的，特别是如果这成为您的习惯，但完整的邮件/新闻风格的四行 ASCII 艺术创作则不可接受。

3.2.4. 附件

对于大块的 ASCII 数据，例如跟踪、调试输出文件或日志文件，请使用附件而不是评论。这样，它不会为每个想阅读它的人膨胀缺陷，并导致人们收到大量无用的邮件。

裁剪屏幕截图。如果您指出的是单像素问题，则无需显示整个屏幕。

不要将简单的测试用例（例如，一个 HTML 文件、一个 CSS 文件和一个图像）作为 ZIP 文件附加。相反，以相反的顺序上传它们，并编辑引用文件，以便它们指向附加的文件。这样，测试用例就可以立即在缺陷之外工作。

3.2.5. 提交缺陷

尽量确保摘要中说的所有内容也在第一条评论中说明。摘要经常更新，这将确保您的原始信息易于访问。

您无需在 URL 字段中输入“any”或类似的字符串。如果没有与缺陷关联的特定 URL，请将此字段留空。

如果您认为您提交的缺陷被错误地标记为另一个缺陷的副本，请在您的缺陷中提出质疑，而不是在它被复制到的缺陷中提出。如果复制缺陷的人尚未被抄送，请随意抄送他们。