Koshinuke memo

Issue.txt

マイルストーン > タスク > チケット

マイルストーンはマスタースケジュール、これをタスクに分割する。
マイルストーンの名前でリリース用のブランチが自動的に作成される。
マイルストーンを完了するとマイルストーンの名前で自動的にtagが作成される。


タスクは個人の作業単位、最小のタスクは最大でも1週間程度で終わる先の見える見積もり可能な大きさの作業になる。
要件を具体的な作業単位に落とす中間的なタスクが存在する。つまり、タスクはタスク間の関連性をN:Mマッピング出来る。

タスクは遅くともCloseするまでに、マイルストーンと紐付ける必要がある。
つまり、マイルストーン:タスクは、1:N。
タスクを定義する際に工数の見積もりをした上でマイルストーンと紐付けると、ガントチャートが自動的に出来る(と良いな)。
タスク間の循環参照を検知出来る(と良いな)。

タスクの名前で自動的にトピックブランチが作成される。
このトピックブランチに、おまじないコメントを付けてプッシュすると、
コードの検査(lint系のアレとか)とテストの実行に加えてレビュー依頼が発生する。

タスクのライフサイクルは、
Opened >  Progress > Await > Closed
 > Rejected
と言う風に変化する。
タスクが定義されると、Opend
タスクの作業者がアサインされるとProgress。
認証ベースがあるのなら作業者がアサインされ、その作業者がブランチをCloneした所で状態が遷移する(かも。)
タスクの作業者がリポジトリにコードやドキュメントををPushするとAwait。つまり、レビュー待ち状態になる。
レビューによって、問題が解決されマイルストーンブランチにタスクのトピックブランチがマージされると、Closeされる。
レビューによって、問題が発見され差し戻されると、Progressになる。
Rejectedには、Closed以外の任意の状態から遷移する。


チケットは個人の作業単位、最大でも数時間以内に終わる作業。
チケット駆動開発的なアレ。使いたい人だけが使う感じ。
チケットはタスクを分割する事で作成される。つまり、タスク:チケットは、1:N。

チケットのID(連番?)で自動的にトピックブランチが作成される。
このトピックブランチに、おまじないコメントを付けてプッシュすると、チケットがCloseされる。

チケットは兎に角テンポ感が大切でその為にインターフェースを考える必要がある。
RESTなAPIだとか、エディタのプラグインだとか、gitコマンド拡張だとか、そういうもの。