本文是对 Firefox OS 项目提交 Bug 的指南， 包括 Gaia 和 B2G。
你可以依照 bug 报告撰写指南中的内容来报告优秀的 bug，你也可以在下面发现更多的细节。
在报告新 bug 时，有一些必填域：
清楚地描述情况，一个好的bug报告应该包含有:1.重现的步骤(STR), 2.预期结果(程序本应该出现的结果)和实际结果(因为bug产生的结果), 3.顺便说明出现bug的频率(即:您多次重复这样的步骤后这个bug出现次数)。
|版本信息||进入 设置>设备信息>更多信息 并且将下列信息与bug一并提交:操作系统版本，内部版本号，平台版本，构建标识，更新方式。(如果你有一台带安装了adb功能的运行Mac或者Linux的电脑，你可以直接运行这个脚本，并且黏贴这个脚本的输出结果到bug报告中)。|
|ADB 运行日志||如果你的电脑安装了ADB工具，请将你的设备连接到电脑并且在ADB中运行以下命令|adb logcat|。请将这个命令的输出信息复制到一个文本文档中并且附到bug报告中。|
|旗子||用于追踪的旗子; the most used flag in Firefox OS bugs is blocking-b2g. If a bug is set as blocking-b2g, it means we should pay more attention to it as it threatens to block a release.|
|Security||If a bug is related to personal data security, loss of earnings, and other such issues, you should check the checkbox and it will only be visiable to involved employees.|
To find more information on bugzilla fields, you can view the Bugzilla Fields page on Bugzilla.
下面的表格提供了你将在 Firefox OS 的 bug 报告中经常见到的关键字。
|meta||Indicates that the bug is a status tracking bug. Mozilla uses this tag to tracking multiple bug or user story implementation statuses. Once marked like this, developers should not land patches on top of such bugs. Please be reminded that project managers and QA staff will use meta bugs for tracking.|
|qablocker||Use this keyword for bugs that are blocking testing (manual or automated testing of a feature) and need to be fixed by the next Beta or RC milestone.|
|qawanted||Use this keyword for bugs that need more info, require reproducing or testcasing, or are duplicates (but you can't find the original bug being duplicated). Required QA work progress is recorded in the whiteboard; you should remove this keyword when the required QA work has been completed.|
|regression||This keyword means that the problem was fixed, but then it came back (regressed) and the bug in question is a new bug, filed to track the regression. It can also refer to problems outside those identified in pre-check in and smoke tests, which were found in current builds and that were known to be working in previous builds. Tracking these bugs helps us to identify areas that are fragile, prone to breakage and are good candidates for adding to smoke and pre-check in tests.|
|regressionwindow-wanted||Indicates that the bug is a regression, and would strongly benefit from someone identifying the time period in which it happened, ideally to a specific check in.|
|steps-wanted||Highlights a bug that would greatly benefit from someone identifying the steps to reproduce it.|
|verifyme||Means that this bug is ok to verify with the latest B2G build by someone other than the QA Contact indicated. The bug has specific machine configuration details indicated for verifying the fix. You should try to reproduce the failure, and, if you agree that the resolution of Fixed is correct, mark the Status as Verified.
You should always indicate the build/OS/platform(s) used to verify the bug in the bug comments, before you change the Status to Verified. If the bug is reported on all three platforms and you only have one platform to verify the fix on, go ahead and do so and note it in the bug, but do not mark the bug as Verified. All platforms must be checked before moving Status to Verified.
Finally, if other bugs have been marked as a duplicate of the bug you're verifying, be sure to check and mention those as well. Often developers mark related — but not identical — bugs as duplicates, and these can be overlooked if not checked.
注意：有关 Gaia 开发中对 bug 的处理的更多信息，请见向 Gaia 提交补丁。