オープン・ステータス課題: 次のステータス値は「オープン」ステータスで、処理方法はありません。
RESOLVED（解決済み）ステータス課題: 次のステータス値は「RESOLVED（解決済み）」ステータスで、処理方法はありません。
注意: RESOLVED（解決済み）ステータスの課題は、次の解決値を持つことができます。
課題がREOPENED（再開）されたときに行われる処理は、誰がREOPENED（再開）したかによって異なります。 既定では、IssueZilla に報告された課題 (入力された課題) はUNCONFIRMED（未確認）ステータスになります。
これは、品質管理担当者またはプロジェクトの適切な権限を持つ誰かによって、この課題をNEW（新規）ステータスに変更する前に課題が正しいものであるかを確認する必要があることを意味します。 issues-subscribe@<projectname>.domain.com に E-Mail を送信して、課題への全変更を通知できます。 それから、課題に対する作業を閲覧するために課題追跡機能を使用します。
プロジェクトの開発者/ユーザ/テスト担当者である場合は、NEW（新規）ステータスの課題を作成して、ほかの開発者に割り当てることができます。課題のステータスがNEW（新規）になると、課題に割り当てられた開発者が課題を受け入れるか、ほかの開発者に再度割り当てます。課題がNEW（新規）で放置され、1 週間経っても何も行われなかった場合は、IssueZilla が課題のオーナに何らかの行動を起こすように E-Mail を送信します。 課題が再度割り当てられたり、そのコンポーネントが変更されると、ステータスがNEW（新規）に戻されます。NEW（新規）ステータスとは、課題が新しく報告されたのではなく、特定の開発者の担当として新しく追加されたことを意味します。NEW（新規）ステータスの課題は、返信を必要とする重要な E-Mail であると考えてください。ただし、返信は IssueZilla を通して行います。このツールを使って課題の進行状況を E-Mail を使用するよりも効果的に追跡することができます。
より高い権限を持つプロジェクトのメンバーは、課題の全フィールドを変更することができます。 (既定の権限は、限られたフィールドのみを変更できます。 (詳しくは、IssueZilla の権限を参照してください。) 課題のフィールドを変更する場合は、変更内容とその理由についての説明を追加することをお勧めします。次のことを行う場合には、[コメント] フィールドにメモを入力します。
課題への変更、コメントの追加が行われると、そのユーザが CC リストに追加され、オーナ、報告者、CC リストにあるユーザが課題の変更を通知する E-Mail を受信します。 この E-Mail は、課題が変更された場所および新しいコメントを示す「diff」形式を使って変更を報告します。
課題が
RESOLVED（解決済み）としてマークされた場合は、プロジェクト/コンポ-ネントのオーナはこの課題を見て、適切な動作が行われたかどうかを確認します。適切な動作が行われたと認められた場合は、VERIFIED（検証済み）課題をとしてマークします。課題は製品またはバージョンがリリースされて課題がCLOSED（処理済み）とマークされるまでこのステータスのまま残ります。課題はREOPENED（再開）されて再度操作の対象となることがあります。
自分の課題ではない課題のステータスを変更する場合は注意してください。この場合は、ステータスを変更する代わりに、まずコメントとして提案のメモを作成し、課題のオーナに提案を提出してオーナにステータスを変更してもらうように依頼することをお勧めします。たとえば、課題がほかの課題の重複であると思われる場合は、この課題の 「追加コメント」セクションにメモを入力します。
ほかの課題に対して多くの有益なコメントを入力すると、ほかのユーザからの信頼を得ることができ、変更を加える権限が与えられることとなります。このような変更権限が与えられるまでは、追加コメントセクションへのコメント入力を賢く活用してください。