チケットの使い方

作成されたチケットはどのように使っていくのがよいかを説明します。 筆者の個人的な見解がたぶんに含まれていますのでご注意を。 なので、ここで述べる内容に従わなきゃいけないなんてことはありません。 臨機応変に使っていきましょう。

まずはおおまかに

チケットは単純で、およそ2つの状態と思ってよいでしょう

• new または reopened あるいは accepted などの、チケットが活きている状態
• closed した、つまり完了した状態。

チケットを作成した直後は、状態として new となります。 通常のプロセスで行くと、作業担当者が acccept(担当)し、accepted 状態になります。 そして実際に作業が完了したら "resolved as 'fixed'" として、closed 状態になります。 あるいは、チケットの内容が標準外のelispパッケージによるものでmeadowの問題では無い場合などは "resolved as 'won't fix'" としてクローズします。 このようなチケットの状態や作業の流れを「ワークフロー」なんて呼びます。

他のBTSでは、開発者の修正の後 resolvedという状態になり、報告者の確認を持ってclosedとするものも多いですが、 現在のTracはあまり複雑なワークフローは使えず上のようにシンプルになっています。

※ 近い将来、Tracのワークフローは少し変わる予定 ですが、しばらくは上記のままです。

コメントの書き方

コメントは意見交換の手段でもあるけれど、メモとしても使えます(後述)。 なので、遠慮なくコメント追加していきましょう。

ただ、コメントは基本的には意見交換なわけですが、一般の会話やMLでのやり取りとは違い、 限られたスペースですのである程度の流儀というか、特性がありますので注意が必要になります。

引用は控えめに

コメントではなるべく引用はしないようにしましょう。スレッドではなく直列であるため、 引用したほうが伝わりやすいこともありますが、現在のtracは親コメントへ辿る機能がありますので、 引用しないでも伝わりそうなら、控えたほうが視認性が挙がってよいかも。 引用するにしても、必要最小限のもにしておき、リンクや添付で全体を示すほうがよいでしょう。

リンクを活用せよ

Tracの持つリンクの機能を活用して簡素であっても有用な情報を残せるとベストです。 引用にも関係しますが、コメントは限られたスペースであるであることから多くの情報を 詰め込むには向いていません。なので、他のwikiページや添付を活用したほうがよいでしょう。 逆を言うと、内容を簡素にまとめてリンクを残すことでサマリ的になり、また他の情報への リンク集にもなったりします。 類似の現象のチケットがあるようなら、「関連があるかも」として他のチケットのリンクを はっておけば問題解決は早まるかもしれません。

お礼とか不要

たとえば「そうですね。」や、「ありがとうございます。」のような対話的な内容は不要です。 すこしぶっきらぼうになりがちかもしれませんが、そこはそれ、大丈夫です(何が？)。

チケットはいつ閉じたらいいか？

上記のような指針なので、チケットを閉じるのは開発者が多いでしょう。 とはいえ、開発者以外であってもチケットを閉じてかまいません。

なのでチケットを閉じるにあたっての判断基準が必要になります。 厳密なルールは設けていませんが、基本方針としては以下のようにしたいと思います。

• 確実にcloseしてよいのは、対処が行われ、それによる解消を報告者でも 開発者でも良いから確認できたとき(fixedの場合)。もしくは確実に meadowやemacsの問題ではなかった場合(won't fixとなる)。
• closeしてはならないのはその症状を解消すべき対処が行われていない、 あるいは明らかに未解消のとき。
• 中間的ものは「これで直るはず/と思う」対処を行ったら closeしてもよい。 報告者の環境で現象が直っていなければ reopenする。

こういった運用方針は使用しているBTSの性格やプロジェクトの規模によったりしますが、 meadow開発ではtracを使用しているため複雑なワークフローは使えませんし、 複雑なワークフローはしっかり管理しないとグチャグチャになってしまいそうなので、 上記くらいのシンプルさでいこうと考えてます。

要は、「これで直ったとおもうよ」となったらさっさとクローズしてしまいましょうという方針。 それはすなわち「直ってないようならreopenを！」ということでもあります。 なので、「reopenは遠慮なく」行ってかまいません。 そうやって、チケットを活発に動かしたほうが開発の活性化につながると思ってます。

チケットを閉じるときの resolution はどう選ぶべきか？

チケットを閉じる際に resolved as xxxx として解決方法を選択する必要がありますが、 それについての指針を挙げておきます。

5種類の選択肢がありますが、使用するのは主に fixed, duplicate, invalidでしょう。 wontfixやworksformeもつかいますが、稀でしょうし、なかなか使い方が難しかったりします。 ともあれ、以下のように判断して使う方針としておきます。 要点としては報告内容の良否と対処内容の実施の組み合わせと考えればよいかと。

• 報告内容に対して対処がなされて完了したのならば "fixed"
• 報告内容が間違ったものであった場合や勘違いであった場合は "invalid"
• 報告内容の真偽はともかく、対処しないと判断した場合は "wontfix"
• 報告内容が他のチケットと重複しているか、それに含まれる場合は "duplicate"
• 報告内容が報告者以外で確認できないような場合や、うやむやになったなら "worksforme"

wontfix って？

wontfix は "won't fix" で、「(報告された内容は認識しているが)修正するつもりは無い」 という結論に使います。ちょっと使い方が難しいですし、あまり多くは使われないだろうと思います。 これを使うようなケースはたとえば、既に未サポートの古いバージョンのmeadowにのみ起きる不具合報告 があった場合などが相当するでしょう。closeする理由としては「現在のバージョンのmeadowでは その問題は発生しないため、古いサポート外のmeadowに対する修正は行いません。あしからず。」 などといったものになるでしょう。

worksformeって？

worksforme は "works for me" で、「私のところでは正常に動作しています」 という意味です。これもちょっと使いにくい選択肢ですし、あまり使わないほうがよいでしょう。

あえてつかうとすれば、報告者以外の環境では再現せず、検討の結果としても不具合とは 判断できないような場合に使います。「この件はこちらでは以上追うことが出来そうに無いのでなかったことにする」 といった意思表示となります。ある意味ギブアップともいえるかもしれません。 もしくは、あまりに放置されていていつの間にか直ってしまっている不具合などに使おうと思ってます。 いずれにせよ、ちょっと使いにくい選択肢です。

コメントのもっと有効な使い方

チケットのコメントはおよそ意見の交換というか会話的に使われるのは 容易に思いつきますが、それにこだわる必要はありません。 そのチケットに関する備忘録として使うのも正しいです。 関連する情報を書き留めておく雑記帳と考えたほうがよいかもしれません。

経過を記録してみる

備忘録的に使う例として、例えばMLで挙がった例を挙げておきます。 #314はチケットとしてmeadowの不具合が報告され、 調べてみたところそれは本家Emacsの不具合であることがわかりました。 それを mule-ja MLに報告した段階で、その旨として「本家の問題のようなので、mule-jaに報告済み」などと 書き残しておくとよいでしょう。 原因がわかってemacs-cvsでは対処がなされたが、 meadowにはまだ取り込まれていない状態ならば、 さらにコメントに「emacs-cvsでは対処済み。次回(r4105以降)のsync-upで解消予定。」 などと書き残しておきます(r4105というのは、その時点での最新revのこと)。 そうすることで、別の人がsync-up作業を行って、そのときにクローズし忘れたとしても、 この件は既に解決済みであることがわかりやすく、r4105以降のsyncが実施済みであることさえ わかればクローズしていいものだと判断できます。

独り言をいってみる

あるいは、作業の途中経過を書き残しておくのでもよいでしょう。 「xxxをやってみたところ変化なかった」であるとか、 「どうもxxxxかxxxあたりがおかしそう。そこまではたどり着いたが...」であるとか、 「foo.cとbar.cはチェック済み。残るはbaz.cのみだが、今週はここまで。」 といったこと。これらは最終的な情報ではありませんが、経過を残しておくことで それを読んだほかの人からアドバイスがもらえるかもしれません。 あるいは作業者がちょっとの間作業を中断したとしても、次に何をやればを思い出しやすいでしょう。

倉庫にしちゃう

同じように、添付ファイルも存分に使ってよいでしょう。 テストで使用したスクリプトやelispコードを添付しておけば、他の人が同じコトを試してみるのも 容易になるでしょう。テストログを残しておけば、他の人が解析できるかもしれませんし、 作業している当人も、「あのときのログはどれだっけ？」なんてことになっても大丈夫。 あるいは正常時や異常時の画面イメージを添付しておくのもよいでしょう。

チケットを使わないほうがよいケースは？

チケットで対話するよりMLで議論したほうがよいケースや、Wikiページにまとめたほうがよいこともあります。 漠然とした話題や、多くの意見を欲しい場合などはMLの方が適しているでしょう。

チケットからMLへの移行

チケットを作ったが議論が膨らんだり発散してくることもあるでしょう。 その場合はMLでの議論に移行したり、 その場合はMLでどのチケットに関する件かをSubject: に書いて議論するとよいでしょう。 ある程度の結論が出たらそのまとめをチケットに書き戻すとなおよいでしょう。 あとでチケットを見たさいに、MLを追いかけなくても結論がわかるので。 MLに移動したのならばチケットに「MLにて検討中 (Subject: xxxxx)」などと書き残しておくと さらによいでしょう。そうすることで、議論内容を追いたいときにはMLの記事に飛ぶ助けになります。

チケットとWikiページの併用

たとえば新機能要求としてチケットを作ったが、それを実現するにあたって機能詳細を検討する 必要が出てくることがあるでしょう。新機能実現には議論が必要だったり、議論をまとめた仕様、 アイディアを説明する文書などが必要になることはよくあることです。 そういう場合は遠慮なくWikiページを作るべきでしょう。

そうした場合はチケットのコメントにWikiページのリンクを書き、 Wikiページにもチケットのリンクを書いておくことで、相互の関連を残しておくのがよいでしょう。

Wikiページの作成は遠慮無用です。 階層構造とか、ページ名とか、いざ新ページを書くとなると気になるところはあるでしょうけど、 思い切って作ってしまってかまいません。必要ならばあとで整理しますです。