fml 5.0 の問題意識は 「ＭＬを走らせたら、スレッドのまとめくらい宜しくやって欲しい」 ということです。 あえていえば、インチキ knowledge database のようなものです。 つまり楽ができるかわりにインチキです :-) が、大真面目に knowledge データベースだ、チケットシステムだ！ とかいうと何億のシステム提案の世界らしいので、 そんなのは欲しくありません(個人で使いたくないし、使える分けない)。 商業ベースないしは運用ベースで考えるなら、より現実的な方法は、このぱち もん:) thread tracking system でノウハウをつみ、自分の組織に求められて いる用件は何か？を見究めることといえます。 この第一段階があって、はじめて適正な knowledge base やticket system を 構築/購入することができるに違いありません。 もちろん、こんなもんで十分有用という場合もありえます:D 趣味の話をし合うＭＬは別として、 多くの場合、『ＭＬにメールを投げる』とは 「こういう問題を解決したい」 とか 「こういう問題があるけど、解決法が分からないから知りたい」 ということであって、その意味で problem report といえます。 そして、それに対してフォローアップがなされ、 解決策が示されたり、未解決のまま放置されたりすることになります。 これをモデル化すると、 open メールが投稿された時 対応中 誰か返事をしたら、対応中 closed この問題について解決されたと判断された時 メールの投稿 → open ↓ フォローアップ→ 対応中 ↓ 終りと判断 closed 判断はモデレータなりを任命する必要があります。 この点が最もつらい どうしてもこれは必要で結局いつものように『最後は人』です。 つまり運用に携わる人間が一番大事だということです。 これは普遍的な命題です。 ところです。 誰か(人間)が判断する必要があるわけですし、 その人は対象のＭＬでの会話の内容についてかなり理解を している必要もあります。 日本語のあ・うんの呼吸で話が終ったと認定できればよいのですが それほど簡単ではありません。 もっとも適当なキーワード「終了とかクローズします」などを 基準にして判断することはできなくはないでしょう。 これは将来の TODO といえるでしょう。 終了のオペレーションは WWW かメールで行なうことを想定しています。 つまりブラウザの上で操作するか、 メールの subject や本文に終了を意味する キーワードを送り込むことで行ないます。 open チケット番号らしきものを含まないメールが投稿されたら 自動的に open going 誰か返事をしたら、対応中 closed close 宣言がなされたら、クローズ 1) Subject: が close ではじまる 2) メール本文の行頭が close ではじまる。 先頭の空白は無視されます。 正規表現では \s*close です。 multipart メールの場合は最初の text/plain パートの 行頭が close で始まる場合です。 3) メールヘッダで X-Ticket-Pragma: close が指定されていた時 X-Ticket-Pragma: ignore 新たにチケットを割り当てない すべてのチケットに関する操作を抑制する。 X-Ticket-Pragma: close チケットをクローズする。