fml8 の問題意識は 「MLを走らせたら、スレッドのまとめくらい宜しくやって欲しい」 ということです。 あえていえば、インチキ knowledge database のようなものです。
つまり楽ができるかわりにインチキです :-) が、大真面目に knowledge データベースだ、チケットシステムだ! とかいうと何億のシステム提案の世界らしいので、 そんなのは欲しくありません(個人で使いたくないし、使えるわけない)。
商業ベースないしは運用ベースで考えるなら、より現実的な方法は、このぱち もん:) thread tracking system でノウハウをつみ、自分の組織に求められて いる用件は何か?を見究めることといえます。 この第一段階があって、はじめて適正な knowledge base や ticket system を 構築/購入することができるに違いありません。 もちろん、こんなもんで十分有用という場合もありえます:D
Problem Report System のまとめ については付録を参照して下さい。
趣味の話をしあうMLは別として、 多くの場合『MLにメールを投げる』とは 「こういう問題を解決したい」 とか 「こういう問題があるけど、解決法が分からないから知りたい」 ということであって、その意味で problem report といえます。 そして、それに対してフォローアップがなされ、 解決策が示されたり、未解決のまま放置されたりすることになります。
これをモデル化すると、
open メールが投稿された時 対応中 誰か返事をしたら、対応中 closed この問題について解決されたと判断された時 メールの投稿 → open ↓ フォローアップ→ 対応中 ↓ 終りと判断 closedただし、「おわり」の判断はそれなりに自動化できますが、 ある程度は人間がしないと無理でしょう。 てきぎ、モデレータなりを任命する必要があります。
この点が最もつらい [1] ところです。誰か(人間)が判断する必要があるわけですし、その人は対象のM Lでの会話の内容についてかなり理解をしている必要もあります。
日本語のあ・うんの呼吸で話が終ったと認定できればよいのですが それほど簡単ではありません。 もっとも適当なキーワード「終了とかクローズします」などを 基準にして判断することはできなくはないでしょう。 これは将来の TODO です。
終了の「明示的な」オペレーションは WWW かメールで行なうことを想定して います。つまりブラウザの上で操作するか、メールの subject や本文に終了 を意味するキーワードを送り込むことで行ないます。
[1] | どうしてもこれは必要で、結局いつものように『最後は人』です。 つまり運用に携わる人間が一番大事だということです。 これは普遍的な命題です。 |
author's homepage is www.fml.org/home/fukachan/.
Also, visit nuinui's world :) at www.nuinui.net.
For questions about FML, e-mail <fml-bugs@fml.org>.