Author: mumumu
Date: Fri Aug 31 10:05:49 2007
New Revision: 1130

Log:
- translated part of ch03.xml


Modified:
   trunk/ja/ch03.xml

Modified: trunk/ja/ch03.xml
==============================================================================
--- trunk/ja/ch03.xml   (original)
+++ trunk/ja/ch03.xml   Fri Aug 31 10:05:49 2007
@@ -4477,7 +4477,7 @@
     こうすることでしばらくは報告されてくる問題のノイズは下げられますが、
     ユーザーが増えてくるにつれてこの問題は結局再燃します。
     このことでユーザーを責めることはできません。
-    ひとりひとりのユーザーはただプロジェクトをよいものにするために貢献しようとしているだけですし、
+    ひとりひとりのユーザーはただプロジェクトをよくするために貢献しようとしているだけですし、
     たとえ彼らのバグ報告がはじめは役に立たなかったとしても、
     あなたは彼らにひき続きプロジェクトに参加してもらって将来はよりよいバグ報告をして欲しいと思うでしょう。
     しばらくの間は、バグ追跡システムに自由にバグを報告させ続ける必要があります。
@@ -4495,9 +4495,11 @@
     この問題を避けるために何より実行すべきことがふたつあります。
     バグではない問題や、
     重複したバグ報告を報告されたらすぐにクローズできる十分な知識がある人にバグ報告システムを見張ってもらうこと。
-    そしてバグ報告システムにバグを報告する前に他の人とバグかどうかを確認するようユーザーに求める(または強く勧める)ことです。
+    そしてバグ報告システムにバグを報告する前に、
+    他の人とバグかどうかを確認するようユーザーに求める(または強く勧める)ことです。
 </para>
 
+<!--
 <para>The first technique seems to be used universally.  Even projects
 with huge issue databases (say, the Debian bug tracker at
 <ulink url="http://bugs.debian.org/"/>, which contained 315,929 issues
@@ -4513,6 +4515,22 @@
 guesses right or wrong when filing, issue watching is still
 distributed more or less evenly among the developers, so each issue is
 able to receive a timely response.</para>
+-->
+
+<para>
+    はじめのテクニックはあらゆるところで使われているようです。
+    巨大なバグデータベースを持つ(たとえば <ulink url="http://bugs.debian.org/"/> にある Debian 
のバグ追跡システムは、執筆時点で315,929個のバグ情報があります)プロジェクトでも、バグが報告されるたびに 
<emphasis>誰かが</emphasis> 見張るようにシステムを改造しています。
+    問題のカテゴリによって見張る人は違うかもしれません。
+    たとえばDebianプロジェクトはソフトウェアパッケージの集合体なので、
+    自動的にそれぞれの問題を適切なパッケージメンテナに転送しています。
+    もちろん、ユーザーがときどき問題のカテゴリを誤解することもありえます。
+    そういう場合は、そのバグははじめは間違った人に転送されるので、
+    転送された人が再度転送し直さなければなりません。
+    しかし重要なのは、その負担が共有されているということです
+    &mdash; ユーザーがバグを報告するときに正しいか間違っているかを推測しようがすまいが、
+    報告されたバグを見張る役目は多かれ少なかれ開発者に分散されています。
+    よって問題が報告されるたびに、適切なタイミングで応答することができるのです。
+</para>
 
 <para>The second technique is less widespread, probably because it's
 harder to automate.  The essential idea is that every new issue gets

_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators

Reply via email to