[HOME] [github] [twitter] [blog] [fml4] [fml8] [北海道] Powered by NetBSD and [nuinui.net] .

MLの話の筋(スレッド)の追跡 (Thread Tracking System ?)

Table of Contents
MLの状態遷移
[素案?] fml8 (minimal_states モデル版)チケットシステム
スレッドシステムのデータベース

fml8 に期待する動作の一つに 「MLのスレッドまとめくらいやって欲しいなぁ」 というのがあります。 あえていえば、インチキ knowledge database のようなものです。

つまり楽ができるかわりにインチキです :-) 大真面目に knowledge データベースだ、チケットシステムだ! とかいうと何億円のシステム提案の世界になってしまいそうですが、 そんなのは欲しくありません(個人で使いたくないし、使えるわけない)。

商業ベースないしは運用ベースで考えるなら、 より現実的な方法は、このぱちもん:) thread tracking system でノウハウをつみ、 自分の組織に求められている用件は何か?を見究めることです。 この第一段階があって、 はじめて、 適正な knowledge base や ticket system を構築/購入することができます。 もちろん、こんなもんで十分有用という場合もありえます:D

Problem Report System のまとめ については付録を参照して下さい。

MLの状態遷移

趣味の話をしあうMLは別として、 たいていの場合「MLにメールを送信する」のは、 「こういう問題を解決したい」 とか 「こういう問題があるけど解決法が分からないから知りたい」 ということであって、その意味で problem report といえます。 そして、 それに対してフォローアップがなされ、 解決策が示されたり、 未解決のまま放置されたりすることになります。

これをモデル化すると、

open    メールが投稿された時
対応中  誰か返事をしたら、対応中
closed  この問題について解決されたと判断された時

メールの投稿  →   open
                    ↓
フォローアップ→  対応中
                    ↓
終りと判断        closed
「おわり」の判断は、それなりに自動化できますが、 ある程度は人間がしないと無理でしょう。 おそらく判断役のモデレータなりを任命する必要があります。

この点が最もつらい [1] ところです。 誰か(人間)が判断する必要があるわけですし、 その人は対象のMLでの会話の内容について、 ある程度は理解をしている必要もあります。

日本語のあ・うんの呼吸で話が終ったと認定できればよいのですが それほど簡単ではありません。 もっとも適当なキーワード「終了とかクローズします」 などを基準にして判断することはできなくはないでしょう。 これは将来の TODO です。

終了の「明示的な」オペレーションは WWW かメールで行なうことを想定しています。 つまりブラウザの上で操作するか、 メールの subject や本文に終了を意味するキーワードを送り込むことで行ないます。

Notes

[1]

どうしてもこれは必要で、結局いつものように『最後は人』です。 つまり運用にたずさわる人間が一番大事だということです。 これは普遍的な命題です。

[HOME] [github] [twitter] [blog] [fml4] [fml8] [北海道] Powered by NetBSD and [nuinui.net] .
Copyright (C) 1993-2022 Ken'ichi Fukamachi mail:< fukachan at fml.org >