3. 提交 Bug 后该怎么办

3. 提交 Bug 后该怎么办
	附录 B. Bugs 报告与功能加强要求

当 Bug 报告被提交后，都有描述它当前如何被处理的“Status”。下面就是这些可能的状态及其意义。

Unconfirmed(未确认)

这是 Bug 报告的默认状态，只到维护者阅读后决定它是否是个真正有效的 Bug 报告。有时维护者也不能确定，它会保持“Unconfirmed”不变。最坏的情况下，某些 Bug 报告可能在一年或更久都保持未确认状态，不过这被认为是糟糕的并不经常发生。

New

这意味着该 Bug 报告被某个维护者读过了，现在认为它是有效的。但并不表示立即要完成些什么：有些 Bug 报告，特别是功能加强要求，一般都是有效的，但在有人处理它以前可能要经过一段时间。另一方面，也有很多 Bug 在报告后几个小时就被修复了。

Assigned(指定)

这意味着某人统一着手处理该 Bug，但是并不表明这个人要做些什么特别的事，所有实际意义上该状态和“New”几乎是一样的。

Reopened(重新开放)

这意味着在维护者认为该 Bug 报告被解决(即完成)同时，有被新的信息改变了他们的主意：一般是指修改解决了问题，不过还不完全。

Needinfo(需要信息)

您要特别注意该状态。它意味着没有提供解决该问题的足够信息。大多数情况下，对 Bug 报告不会进行任然动作，除非您提供更多的信息(通过添加 comment)。如果很久都没有任何附加信息，该 Bug 报告最终会被认为是“Incomplete”。

Resolved(解决)

这意味着维护者认为他们完成了处理该 Bug 报告的工作。如果您不同意，可以重新开放它，不过您不能强迫任何人让他们处理 Bug，您需要给出一个这样做的合理原因。有多种不同的方式解决 Bug，下面是这些解决方法及其意义：

Fixed(修复): 该 Bug 报告被认为是有效的，通过某种方式修改 GIMP 使该 Bug 被修复了。
Wontfix(未修复): 维护者同意该 Bug 报告是有效的，不过很难修复，相对于其重要性，其问题可以忽略。
Duplicate(重复): 这意味着同一个 Bug 已经被其它人报告过了。如果您看到该解决方法，它还会出现一个指向有更多有用信息的以前 Bug 报告的链结。
Notabug: 这意味着在 Bug 报告中所描述的行为是有正常的。它对您(可能有许多持相同看法的人)可能是 Bug，不过程序是有意这样设计的，并且开发者现阶段不会改变它。
NotGnome: 该 Bug 报告是有效的，不过无法通过修改 GIMP 来解决。问题在操作系统，窗口管理器或 GIMP 依赖库中常常出现这种解决方法。下一个适当的步骤可能就是向出现问题的软件提交 Bug 报告。
Incomplete(不完全): Bug 报告中没有包括解决问题的足够信息，而报告者也没有即时提供附加信息。这种情况的 Bug 报告一般先开放一个或两个月后才使用这种解决方法。
Invalid(无效): 有时 Bug 报告的格式不正确：更常见的是，报告者由于不小心多次提交了相同的 Bug 报告。(对某些网页浏览器这种错误很常见。)那些错误地描述程序行为的 Bug 报告也可能被认为是无效的。

	注意
	如果您不同意一个 Bug 报告的解决方法，通常可用给它添加您的评论。对任何 Bug 报告添加的任何评论，无论是否解决都会通过 Email 发到 GIMP Bugzilla 邮件列表中，所有至少维护者可以看到。当然这并不意味着他们必须对它做出反应。