From 2aa557eef7ff3da9eabbaf3d14b4e2a90b94a1ce Mon Sep 17 00:00:00 2001 From: fukachan Date: Sun, 28 Mar 2010 13:40:49 +0000 Subject: clean up --- fml/doc/ja/tutorial/threadtrack/chapter.sgml | 9 ++--- fml/doc/ja/tutorial/threadtrack/db.sgml | 19 +++++----- fml/doc/ja/tutorial/threadtrack/model.sgml | 44 +++++++++++++---------- fml/doc/ja/tutorial/threadtrack/states.sgml | 24 +++++++------ fml/doc/ja/tutorial/threadtrack/tools.sgml | 53 ++++++++++++++++------------ 5 files changed, 85 insertions(+), 64 deletions(-) diff --git a/fml/doc/ja/tutorial/threadtrack/chapter.sgml b/fml/doc/ja/tutorial/threadtrack/chapter.sgml index f0dd664c..6260e362 100644 --- a/fml/doc/ja/tutorial/threadtrack/chapter.sgml +++ b/fml/doc/ja/tutorial/threadtrack/chapter.sgml @@ -1,5 +1,5 @@ @@ -23,9 +23,10 @@ -商業ベースないしは運用ベースで考えるなら、より現実的な方法は、このぱち -もん:) thread tracking system でノウハウをつみ、自分の組織に求められて -いる用件は何か？を見究めることといえます。 +商業ベースないしは運用ベースで考えるなら、 +より現実的な方法は、このぱちもん:) +thread tracking system でノウハウをつみ、 +自分の組織に求められている用件は何か？を見究めることです。 この第一段階があって、はじめて適正な knowledge base や ticket system を 構築/購入することができるに違いありません。 もちろん、こんなもんで十分有用という場合もありえます:D diff --git a/fml/doc/ja/tutorial/threadtrack/db.sgml b/fml/doc/ja/tutorial/threadtrack/db.sgml index 48e7dfcf..88f8d993 100644 --- a/fml/doc/ja/tutorial/threadtrack/db.sgml +++ b/fml/doc/ja/tutorial/threadtrack/db.sgml @@ -1,5 +1,5 @@ @@ -21,13 +21,16 @@ from sender ヘッダの Sender: (めーる＠アドレスの形式) x_sender ヘッダの X-Sender: (めーる＠アドレスの形式) -たとえば、BSD 上であれば status.db といった .db のファイル群 -のセットとなるわけです。 +たとえば、BSD 上であれば +status.db といった .db のファイル群のセットとなるわけです。 これらのファイル群は各ＭＬのホームディレクトリではなく、 +$ml_home_prefix/@db@/ＭＬ名/ + +例 /var/spool/ml/@db@/ＭＬ名/ というディレクトリに作られています。 @@ -35,13 +38,13 @@ x_sender 逆にいえば、現在、ドメインを超えたクロスポストは無視しているわけですね。 -まぁ、あまりそういう要求はないと思いますけど… +まぁ、あまりそういう要求は無いと思いますけど… -にある)ＭＬが相互に参照しあえる拡張機能を想定しているためです。たとえ -ば「support/100 の記事は sales/98 を出発点としている」といった情報を自 -動的にＭＬが教えてくれるような機能を実装するための布石です。残念ながら、 -現在のところは未実装です。 +にある)ＭＬが相互に参照しあう拡張を想定しています。 +たとえば「support/100 の記事は sales/98 を出発点としている」 +といった情報を自動的にＭＬが教える機能を実装するための布石です。 +残念ながら、現在のところは未実装です。 diff --git a/fml/doc/ja/tutorial/threadtrack/model.sgml b/fml/doc/ja/tutorial/threadtrack/model.sgml index 88c33c6e..faa234e8 100644 --- a/fml/doc/ja/tutorial/threadtrack/model.sgml +++ b/fml/doc/ja/tutorial/threadtrack/model.sgml @@ -1,5 +1,5 @@ @@ -14,43 +14,45 @@ - open - チケット番号らしきものを含まないメールが投稿されたら - 自動的に open +open ... +チケット番号らしきものを含まないメールが投稿されたら +自動的に open - going - 誰か返事をしたら、対応中 +going ... +誰か返事をしたら、対応中 - closed - close 宣言がなされたら、クローズ +closed ... +close 宣言がなされたら、クローズ - close 宣言は以下のいずれかの実行である。 + close 宣言は以下のいずれかの実行のはず -1) Subject: が close ではじまる +(1) Subject: が close ではじまる。 - 2) メール本文の行頭が close ではじまる。 - 先頭の空白は無視されます。 - 正規表現では \s*close です。 +(2) メール本文の行頭が close ではじまる。 + - multipart メールの場合は最初の text/plain パートの - 行頭が close で始まる場合です。 + +先頭の空白は無視されます。 +正規表現では \s*close です。 +multipart メールの場合は、 +最初の text/plain パートの行頭が close で始まる場合です。 - 3) メールヘッダで X-Ticket-Pragma: close が指定されていた時 +(3) メールヘッダで X-Ticket-Pragma: close が指定されていた時。 @@ -63,15 +65,19 @@ X-Ticket-Pragma: ignore + - 新たにチケットを割り当てない - すべてのチケットに関する操作を抑制する。 + +新たにチケットを割り当てません。 +すべてのチケットに関する操作を抑制します。 X-Ticket-Pragma: close + - チケットをクローズする。 + +チケットをクローズします。 diff --git a/fml/doc/ja/tutorial/threadtrack/states.sgml b/fml/doc/ja/tutorial/threadtrack/states.sgml index 6dbe66e8..8d3958e6 100644 --- a/fml/doc/ja/tutorial/threadtrack/states.sgml +++ b/fml/doc/ja/tutorial/threadtrack/states.sgml @@ -1,5 +1,5 @@ @@ -12,7 +12,7 @@ 多くの場合『ＭＬにメールを投げる』とは 「こういう問題を解決したい」 とか -「こういう問題があるけど、解決法が分からないから知りたい」 +「こういう問題があるけど解決法が分からないから知りたい」 ということであって、その意味で problem report といえます。 そして、それに対してフォローアップがなされ、 解決策が示されたり、未解決のまま放置されたりすることになります。 @@ -31,9 +31,9 @@ closed ↓ 終りと判断 closed -ただし、「おわり」の判断はそれなりに自動化できますが、 +「おわり」の判断は、それなりに自動化できますが、 ある程度は人間がしないと無理でしょう。 -てきぎ、モデレータなりを任命する必要があります。 +おそらく判断役のモデレータなりを任命する必要があります。 @@ -45,22 +45,24 @@ closed これは普遍的な命題です。 -ところです。誰か(人間)が判断する必要があるわけですし、その人は対象のＭ -Ｌでの会話の内容についてかなり理解をしている必要もあります。 +ところです。 +誰か(人間)が判断する必要があるわけですし、 +その人は対象のＭＬでの会話の内容について、 +ある程度は理解をしている必要もあります。 日本語のあ・うんの呼吸で話が終ったと認定できればよいのですが それほど簡単ではありません。 -もっとも適当なキーワード「終了とかクローズします」などを -基準にして判断することはできなくはないでしょう。 +もっとも適当なキーワード「終了とかクローズします」 +などを基準にして判断することはできなくはないでしょう。 これは将来の TODO です。 -終了の「明示的な」オペレーションは WWW かメールで行なうことを想定して -います。つまりブラウザの上で操作するか、メールの subject や本文に終了 -を意味するキーワードを送り込むことで行ないます。 +終了の「明示的な」オペレーションは WWW かメールで行なうことを想定しています。 +つまりブラウザの上で操作するか、 +メールの subject や本文に終了を意味するキーワードを送り込むことで行ないます。 diff --git a/fml/doc/ja/tutorial/threadtrack/tools.sgml b/fml/doc/ja/tutorial/threadtrack/tools.sgml index b3c8dab2..2b24e2ec 100644 --- a/fml/doc/ja/tutorial/threadtrack/tools.sgml +++ b/fml/doc/ja/tutorial/threadtrack/tools.sgml @@ -1,5 +1,5 @@ @@ -14,8 +14,8 @@ -bug tracking システムとチケットシステムは微妙に目的が違うと思うが、 -ここでは広く problem report という観点でまとめてみようとおもう。 +bug tracking システムとトラブルチケットシステムは微妙に目的が違うと思いますが、 +ここでは広く problem report という観点でまとめています。 @@ -31,17 +31,21 @@ http://www.daveeaton.com/scm/PMTools.html に昔あった？ -がある。特に売りもの一覧についてはここをまず見られたい。 -Free のものもいくつかある。 -最も有名なものは GNATS かもしれないが、 +があります。 +特に売りもの一覧については、ここをまず見るとよいようです… +って、この三年くらい更新してませんね。 + + + +Free のものもいくつかあります。 +最も有名というか歴史のあるツールは GNATS でしょうか。 あとは -jitterbug -がよくみるだろうか？ -他に +jitterbug、 Bugzilla -とか -debuggs (Debian Bug Tracking System) -とか OpenTrack PTS WREK Wreq (?) などというのもある。 +debuggs (Debian Bug Tracking System)、 +OpenTrack PTS WREK Wreq (?) など。 +最近は、なんでもウエブで〜という人たちばかりだからか、 +Bugzilla が多いですかね？ @@ -49,17 +53,18 @@ debuggs (Debian Bug Tracking System) http://linas.org/linux/pm.html -の方がよくまとまってるかもしれない。 +の方がよくまとまってるかも…いえ、これも更新してませんね。 -どちらかというと有名なものは特定のプロジェクトと bind されていて +いずれにせよ、 +たいてい有名なものは特定のプロジェクトと bind されていて そこから派生したという趣が多いようにおもえます。 たとえば perl.org のバグトラックツールである perlbug (CPAN を見よ) は 他であまり使われているような気がしないわけで、 どうも project が発生するたびに、 『既存の bug tracking system は使いにくい、作ろう』 -という project が付随して発生しているような気もします(笑) +という project が付随して発生しているような雰囲気も感じられます(笑)。 @@ -72,18 +77,22 @@ http://linas.org/linux/pm.html Call Tracking は主にお客からの問題の指摘についての扱いであり、 -人の割り当てとステータス管理とレポートを行なう必要があります。 +「人の割り当て」 +「ステータス管理」 +そして +レポートを行なう必要があります。 -一方 Problem Tracking は開発プロセスの管理などであり、その管理対象には -タスクやさまざまな統計やレポートだけでなく、インテグレーションやそのテ -ストまでも含まれえます。 +一方 Problem Tracking は「開発プロセスの管理」などであり、 +その管理対象にはタスクやさまざまな統計、レポートだけでなく、 +インテグレーションやそのテストまでも含まれえます。 -なお Configuration Management という単語も Problem Tracking の -近隣に位置するが、これは CVS などのツール系のことです。 +なお Configuration Management という単語も +Problem Tracking の近隣に位置しますが、 +これは CVS などのツール系のことです。 @@ -250,7 +259,7 @@ diff -u -u -b -r1.93.2.7 pcmciadevs http://samba.anu.edu.au/jitterbug/ を参照。 -割と simple is best 指向なものといえるだろうか。 +割と simple is best 指向なものといえるでしょうか。 もともとは samba の bug tracking をする目的からスタート。 C 言語で、WWW インターフェイスのみ (URL みりゃわかるとおり)。 -- cgit v1.2.1