1 files changed, 33 insertions, 0 deletions
diff --git a/files/ja/orphaned/bugzilla-jp/guide/lifecycle/index.html b/files/ja/orphaned/bugzilla-jp/guide/lifecycle/index.html
new file mode 100644
index 0000000000..6ebe17962e
--- /dev/null
+++ b/files/ja/orphaned/bugzilla-jp/guide/lifecycle/index.html
@@ -0,0 +1,33 @@
+---
+title: LifeCycle
+slug: Bugzilla-jp/Guide/LifeCycle
+---
+<h3 id=".E3.83.90.E3.82.B0.E3.81.AE.E3.83.A9.E3.82.A4.E3.83.95.E3.82.B5.E3.82.A4.E3.82.AF.E3.83.AB" name=".E3.83.90.E3.82.B0.E3.81.AE.E3.83.A9.E3.82.A4.E3.83.95.E3.82.B5.E3.82.A4.E3.82.AF.E3.83.AB">バグのライフサイクル</h3>
+<p>各バグはステータスによって状態を管理されています。ステータスには以下のものがあります。</p>
+<h4 id="UNCONFIRMED" name="UNCONFIRMED">UNCONFIRMED</h4>
+<p>通常のアカウントから報告された直後のバグの状態です。つまり、そのバグは未だに関係者によって再現が確認されていません。バグ報告としてはまだ成立していない状態ですので、再現しにくいバグの場合、報告者の助けが重要なウエイトを占めることがあります。もし、報告者の協力が得られない場合は、そのままバグを閉じられてしまうことも多々あります。</p>
+<h4 id="NEW" name="NEW">NEW</h4>
+<p>バグの存在が確認された状態です。UNCONFIRMEDの状態のバグがスタッフによって確認された場合にこの状態に変更されます。</p>
+<p>また、スタッフや、canconfirm権限のあるアカウントで報告された場合は最初からこの状態になっています。</p>
+<h4 id="ASSIGNED" name="ASSIGNED">ASSIGNED</h4>
+<p>バグについて担当者が作業を開始した場合にこの状態に変更されます。担当者が行う作業はプロダクトごとに異なっています。詳しくは次ページ以降を参照してください。</p>
+<h4 id="RESOLVED" name="RESOLVED">RESOLVED</h4>
+<p>そのバグに対して何らかの決着がついたことを示す状態です。 一般的には、そのバグに対する作業が終了したことを示しています。 この時、同時に処理方法がFIXED、INVALID、WONTFIX、LATER、REMIND、WORKSFORME、DUPLICATEのいずれかに設定されます。DUPLICATE以外の処理方法の意味は、プロダクトによって異なってきますので、詳細はページ末尾からリンクしているプロダクトごとの解説を参照してください。</p>
+<p>DUPLICATEとなった場合、そのバグは別の登録されているバグと同じものでした。報告者はこの時、同時に同じ内容だった別のバグへとCCされます。もし、重複が誤りであると思うのであれば、<b>自分が報告した方のバグ</b>に何らかのコメントを付けてください。決して、この目的でもうひとつのバグの方にコメントを付けないように注意してください。</p>
+<h4 id="VERIFIED" name="VERIFIED">VERIFIED</h4>
+<p>RESOLVEDとなったバグに対して、 別のスタッフか報告者がその事実を確認した状態です。 この状態になっていれば、そのバグは完全に決着が着いた状態であると言えます。</p>
+<h4 id="REOPENED" name="REOPENED">REOPENED</h4>
+<p>VERIFIEDとなったバグが、実はまだ解決していなかったことが分かった場合にこの状態になります。この際に、設定されていた処理方法はリセットされ、空白に戻ります。</p>
+<p>多くの場合、RESOLVEDになった時に設定された処理方法が適切ではなかった場合に、一度REOPENEDとなり、適切な処理方法を再設定して、RESOLVEDに戻すために利用されます。</p>
+<p>バグの修正が不十分だった場合にREOPENEDになることもありますが、実際にはそれは希です。大抵、修正が不十分だった場合は別の問題が発覚したということなので、新たにバグが登録されるからです。</p>
+<p>なお、一度修正されたバグが再発しても、REOPENEDにはなりません。バグの再発は異なる原因で再発していることが大半だからです。また、バグの担当者は既にBugzilla-jpでは作業していないかもしれません。このような場合、REOPENEDは適当な処理とは言えません。この場合も新たにバグを登録しなおすのが適当です。</p>
+<hr>
+<p>ステータスはバグの管理において、最も重要な要素のうちのひとつです。Bugzilla-jpでの運用経験の少ないアカウントはこれを変更してはいけません。もし、ステータスが変更されるべきなのにスタッフ、もしくは開発者のミスで変更が行われない場合、コメントでその旨をスタッフに伝えて、スタッフの判断を待ってください。</p>
+<p>プロダクトごとのより細かいライフサイクルと、処理方法の意味は以下のドキュメントを参考にしてください。</p>
+<ol>
+  <li><a href="LifeCycle/Mozilla">Mozilla関連製品に関するバグのライフサイクル</a></li>
+  <li><a href="LifeCycle/WebStandard">Web標準化プロダクトに関するバグのライフサイクル</a></li>
+  <li><a href="LifeCycle/WebTools">Webtoolsプロダクトに関するバグのライフサイクル</a></li>
+  <li><a href="LifeCycle/MozillaGumi">もじら組のコンテンツに関するバグのライフサイクル</a></li>
+  <li><a href="LifeCycle/QAMozilla">談話室ばぐじらに関するバグのライフサイクル</a></li>
+</ol>