clean up

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