Ticket Workflow (ja) » 履歴 » バージョン 5
バージョン 4 (Kousuke Ebihara, 2009-10-03 19:51) → バージョン 5/6 (kaoru n, 2014-10-21 13:17)
h1. チケットのワークフロー
h2. 概要
すべてのチケットはステータスを持っています。
チケットのステータスはチケットの更新ページで変更することができます。
利用可能なステータスには様々な理由による制限が設けられます。たとえば、報告者は「着手」ステータスを使えなかったり、「差し戻し」ステータスから「修正済み」ステータスに変更できなかったりします。
h2. ステータスについての説明
作業の進捗状況によってチケットのステータスを適宜更新してください。
h3. New（新規）
チケットの初期状態です。作られたばかりのチケットはこの状態になります。
h3. Pending Fixing（修正待ち）
再現チームにより再現確認がおこなわれたあとのステータスです。充分な再現確認がおこなわれていて、修正に必要な情報が揃っていることを、開発者にアピールすることができます。
このステータスはバグチケットにのみ使われます。
h3. Accepted（着手）
開発者がチケットの対応を開始したことを示すステータスです。このステータスにすることで、「対応が進んでいる」ということをアピールするほかに、他の開発者が同じ作業をしてしまうことを防ぎます。
h3. Pending Review（レビュー待ち）
開発者がチケットの対応を完了し、レビューを依頼していることを示すステータスです。
このステータスにする際は、「修正コードがプルリクエスト済みである」という条件を満たしていなければなければなりません。
条件を満たしていない場合、レビューを行うことができず、「Rejected（差し戻し）」となる場合があります。 このステータスにする際は、「git://github.com/openpne/OpenPNE3.git の master もしくはリリースブランチにコードがマージされている」「チケットに関連するコミットが紐づけられているか、記載されている」という条件を満たしていなければなければなりません。条件を満たしていない場合、レビューを行うことができず、「Rejected（差し戻し）」となる場合があります。
プルリクエストについては"こちら":https://redmine.openpne.jp/projects/op3/wiki/Pull_Request_Policy_%28ja%29 をご確認ください。
h3. Pending Testing（テスト待ち）
コードレビューが完了し、テスターにテストを依頼していることを示すステータスです。
h3. Pending Merge（マージ待ち）
テスターがテストを完了し、プルリクエストのマージを依頼していることを示すステータスです。
h3. Rejected（差し戻し）
コードレビューもしくはテストにおいて何かしらの問題が生じたことを示すステータスです。チケットの担当者はこのステータスになっているチケットを優先的に処理し、再び「Pending Review（レビュー待ち）」にステータスを変更できるようにしてください。
h3. Fixed（完了）
チケットへの対処が完了したことを示すステータスです。
h3. Works for me（再現せず）
チケットで報告されている現象が再現チームによって再現できなかったことを示すステータスです。
このステータスが使われる場合、報告が間違っているか、不備がある可能性が高いです。チケットが誤りでないと思われる場合、報告の内容を見直し、再度ステータスを「New（新規）」に変更してください。
h3. Invalid（無効）
チケットが誤って作られたことを示すステータスです。
h3. Won't fix（対応せず）
チケットへの対応をおこなわない場合に用いられます。たとえばプラグインで対処するべきアプリケーション側の機能に関する要望などに用いられます。
h2. ワークフローについての詳細な説明
h3. バグ
以下の画像はバグチケットにおけるワークフローを説明しています。
!2-1.png! !スライド2.png!
h3. 改善
以下の画像は改善チケットにおけるワークフローを説明しています。
!4-1.png! !スライド4.png!
h3. バックポート
バックポートチケットは、複数バージョンのためのバグチケットか改善チケットのために使われます。
そのようなチケットはまず現在の開発版にて扱い、対応し、レビューし、テストし、そして古いバージョンにバックポートするためのチケットを作らなければなりません。
最新の開発版のためのチケットを「元チケット」と呼びます。元チケットは通常のバグチケットや改善チケットと同じように扱われなければなりません。
バックポートチケットもまた通常のチケットと同じように扱われます。これはバックポートチケットのための変更が、レビューされ、テストされることを意味します。なぜならその変更は、たとえ元のバージョンで動いていたとしても古いバージョンでは正常に動作しないことがあるからです。
以下の画像はバックポートチケットにおけるワークフローを説明しています。
!6-1.png! !スライド6.png!
h2. 概要
すべてのチケットはステータスを持っています。
チケットのステータスはチケットの更新ページで変更することができます。
利用可能なステータスには様々な理由による制限が設けられます。たとえば、報告者は「着手」ステータスを使えなかったり、「差し戻し」ステータスから「修正済み」ステータスに変更できなかったりします。
h2. ステータスについての説明
作業の進捗状況によってチケットのステータスを適宜更新してください。
h3. New（新規）
チケットの初期状態です。作られたばかりのチケットはこの状態になります。
h3. Pending Fixing（修正待ち）
再現チームにより再現確認がおこなわれたあとのステータスです。充分な再現確認がおこなわれていて、修正に必要な情報が揃っていることを、開発者にアピールすることができます。
このステータスはバグチケットにのみ使われます。
h3. Accepted（着手）
開発者がチケットの対応を開始したことを示すステータスです。このステータスにすることで、「対応が進んでいる」ということをアピールするほかに、他の開発者が同じ作業をしてしまうことを防ぎます。
h3. Pending Review（レビュー待ち）
開発者がチケットの対応を完了し、レビューを依頼していることを示すステータスです。
このステータスにする際は、「修正コードがプルリクエスト済みである」という条件を満たしていなければなければなりません。
条件を満たしていない場合、レビューを行うことができず、「Rejected（差し戻し）」となる場合があります。 このステータスにする際は、「git://github.com/openpne/OpenPNE3.git の master もしくはリリースブランチにコードがマージされている」「チケットに関連するコミットが紐づけられているか、記載されている」という条件を満たしていなければなければなりません。条件を満たしていない場合、レビューを行うことができず、「Rejected（差し戻し）」となる場合があります。
プルリクエストについては"こちら":https://redmine.openpne.jp/projects/op3/wiki/Pull_Request_Policy_%28ja%29 をご確認ください。
h3. Pending Testing（テスト待ち）
コードレビューが完了し、テスターにテストを依頼していることを示すステータスです。
h3. Pending Merge（マージ待ち）
テスターがテストを完了し、プルリクエストのマージを依頼していることを示すステータスです。
h3. Rejected（差し戻し）
コードレビューもしくはテストにおいて何かしらの問題が生じたことを示すステータスです。チケットの担当者はこのステータスになっているチケットを優先的に処理し、再び「Pending Review（レビュー待ち）」にステータスを変更できるようにしてください。
h3. Fixed（完了）
チケットへの対処が完了したことを示すステータスです。
h3. Works for me（再現せず）
チケットで報告されている現象が再現チームによって再現できなかったことを示すステータスです。
このステータスが使われる場合、報告が間違っているか、不備がある可能性が高いです。チケットが誤りでないと思われる場合、報告の内容を見直し、再度ステータスを「New（新規）」に変更してください。
h3. Invalid（無効）
チケットが誤って作られたことを示すステータスです。
h3. Won't fix（対応せず）
チケットへの対応をおこなわない場合に用いられます。たとえばプラグインで対処するべきアプリケーション側の機能に関する要望などに用いられます。
h2. ワークフローについての詳細な説明
h3. バグ
以下の画像はバグチケットにおけるワークフローを説明しています。
!2-1.png! !スライド2.png!
h3. 改善
以下の画像は改善チケットにおけるワークフローを説明しています。
!4-1.png! !スライド4.png!
h3. バックポート
バックポートチケットは、複数バージョンのためのバグチケットか改善チケットのために使われます。
そのようなチケットはまず現在の開発版にて扱い、対応し、レビューし、テストし、そして古いバージョンにバックポートするためのチケットを作らなければなりません。
最新の開発版のためのチケットを「元チケット」と呼びます。元チケットは通常のバグチケットや改善チケットと同じように扱われなければなりません。
バックポートチケットもまた通常のチケットと同じように扱われます。これはバックポートチケットのための変更が、レビューされ、テストされることを意味します。なぜならその変更は、たとえ元のバージョンで動いていたとしても古いバージョンでは正常に動作しないことがあるからです。
以下の画像はバックポートチケットにおけるワークフローを説明しています。
!6-1.png! !スライド6.png!