Author: mumumu
Date: Tue Aug 28 03:41:52 2007
New Revision: 1118
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 Tue Aug 28 03:41:52 2007
@@ -4194,18 +4194,19 @@
開発者は次第にぶっきらぼうな返事をして問題をクローズしていくようになります。
こういう風潮にならないよう努力しましょう。
ぶっきらぼうにクローズしてもいいことは何もありません。
- バグではない問題を報告したそれぞれのユーザは、以前報告された問題には何の責任もないのですから。
+ バグではない問題を報告したユーザ－は、以前報告された問題には何の責任もないのですから。
それに報告される問題が統計的にどういった傾向にあるかは、
- 開発者のみわかることで、ユーザーにはわかりません。
+ 開発者のみわかることで、ユーザーにはわからないことです。
(<phrase output="printed">この章の後半の</phrase> <xref linkend="bug-filtering"/>
で、
バグではない問題の数を減らすテクニックについて見ていきます)
- また、異なったユーザが繰り返し同じような誤解をする場合は、
+ また、異なったユーザーが繰り返し同じような誤解をする場合は、
誤解を生む部分を再設計する必要があるということかもしれません。
この手のパターンはバグデータベースを監視する問題管理システムがあれば簡単に見つかります。
<phrase output="printed"><xref linkend="managing-volunteers"/> の</phrase>、
<xref linkend="issue-manager"/> を参照してください。
</para>
+<!--
<para>Another common life cycle variation is for the issue to be closed
as a <firstterm>duplicate</firstterm> soon after Step 1. A duplicate
is when someone files an issue that's already known to the project.
@@ -4217,20 +4218,55 @@
track of this relationship bidirectionally, so that reproduction
information in the duplicates is available to the original issue, and
vice versa.</para>
+-->
+
+<para>
+ 別のバリエーションとして、
+ 1. のすぐ後で問題が <firstterm>重複している</firstterm> としてクローズされる場合があります。
+ 重複した問題は、プロジェクトが既に認識している問題を誰かがまた報告すると発生します。
+ 重複した状態は open されている問題で発生するとは限りません。
+ 解決したあとで再び報告される(この状態を <firstterm>regression</firstterm> と呼びます)こともあります。
+ こういう場合は、重複の元となった問題を reopen の状態にして、
+ 重複した問題はクローズしてしまうのが普通は望ましいでしょう。
+ バグ追跡システムは、
+ 問題を再現する情報ははじめに報告された問題で見られるように（逆も同様）、
+ 問題同士の関連を追跡しているはずです。
+</para>
+<!--
<para>A third variation is for the developers to close the issue,
thinking they have fixed it, only to have the original reporter reject
the fix and reopen it. This is usually because the developers simply
don't have access to the environment necessary to reproduce the bug,
or because they didn't test the fix using the exact same reproduction
recipe as the reporter.</para>
+-->
+
+<para>
+ 開発者が問題をクローズする3つ目のバリエーションは、
+ 問題を解決したと思い込んでクローズするパターンです。
+ これは結局、問題を報告した人がそれを拒んで reopen する結果になります。
+ これは開発者が単にバグを再現するのに必要な環境にアクセスできないか、
+ 問題を再現する手順に正確に従ってテストをしなかったために発生します。
+</para>
+<!--
<para>Aside from these variations, there may be other small details of
the life cycle that vary depending on the tracking software. But the
basic shape is the same, and while the life cycle itself is not
specific to open source software, it has implications for how open
source projects use their bug trackers.</para>
+-->
+
+<para>
+ これらのバリエーションのほかにも、
+ バグ追跡システムによっては細かい部分が変わる場合がありますが、
+ 基本的なパターンは同じです。
+ 問題のライフサイクルそのものもオープンソースソフトウェアに特有のものではありませんが、
+ オープンソースプロジェクトのバグ追跡システムの使い方に影響を与えています。
+</para>
+<!--
<para>As Step 1 implies, the tracker is as much a public face of the
project as the mailing lists or web pages. Anyone may file an issue,
anyone may look at an issue, and anyone may browse the list of currently
@@ -4246,6 +4282,24 @@
project's consciousness, in the sense that that developer can be on
the lookout for other instances of the issue, can talk about it with
other developers, etc.</para>
+-->
+
+<para>
+ 1. が暗に示すとおり、
+ バグ追跡システムはメーリングリストやウェブページと同様プロジェクトの顔です。
+ 誰でも問題を報告し、調べることができますし、現在 open されている問題の一覧を見ることができます。
+ よって、報告されている問題の進捗を何人の人が知りたがっているのかが、
+ 開発者にはわからないということになります。
+ 問題が解決される割合は開発者コミュニティの規模やスキルに左右されますが、
+ プロジェクトは少なくとも問題が報告されたらすぐにそれを認識しようとすべきです。
+ たとえ問題が解決されずにしばらく残り続けても、
+ 開発者からの返答は問題を報告する人に引き続き参加する意欲を与えます。
+ なぜなら、自分がやったことが認められたと感じるからです。(問題を報告することは、
+ たとえば電子メールを送ること以上に労力がいることを思い出してください)
+ それ以上に、問題をいったん開発者が見れば、
+ 開発者が報告された問題の他の事例に注意を払ったり、他の開発者と話し合える、などの意味で、
+ プロジェクトが問題を認識したことになります。
+</para>
<para>The need for timely reactions implies two things:
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
