Author: mumumu
Date: Thu Aug 23 17:05:59 2007
New Revision: 1082
Log:
- translated part of bug tracking section.
Modified:
trunk/ja/ch03.xml
Modified: trunk/ja/ch03.xml
==============================================================================
--- trunk/ja/ch03.xml (original)
+++ trunk/ja/ch03.xml Thu Aug 23 17:05:59 2007
@@ -3977,12 +3977,12 @@
<para>
この本では "バグ追跡システム" という用語を、
- 物事を追跡するソフトウェアを指すものとして使うことにします。
+ 物事を追跡するソフトウェアを指すものとします。
なぜなら、殆どの人がバグ追跡システムと呼んでいるからです。
しかし、バグ追跡システムのデータベースに登録される個々のアイテムを指すものとして、
<firstterm>問題</firstterm> という用語を使います。
これによってユーザーが遭遇するソフトウェアの変な振る舞い（つまり、バグです）と、
- バグの発見、診断、解決に関する <emphasis>記録</emphasis> を区別できるからです。
+ バグの発見、診断、解決の <emphasis>記録</emphasis> を区別できるからです。
殆どの問題は実際に起こったバグに関するものですが、
他のタスクに関することでも問題という用語が使えるということを覚えておいてください。
</para>
@@ -4050,7 +4050,7 @@
<para>
誰か他の人が問題を読み、コメントを付けます。
- おそらく問題を報告をした人に、不明な点について説明を求めるでしょう。
+ おそらく問題を報告した人に、不明な点について説明を求めるでしょう。
</para>
</listitem>
<listitem>
@@ -4069,7 +4069,7 @@
これは問題のライフサイクルの中で最も重要なものかもしれません。これは、
まだ解決されたわけではないが、
報告した人以外の誰かが問題を再現でき、
- この問題が本物であると証明したことをいいます。
+ この問題が本物だと証明したことをいいます。
そして同じくらい重要なことですが、
報告した人が本物のバグを報告することで、
プロジェクトに貢献したと確認することでもあります。
@@ -4092,7 +4092,7 @@
問題の原因が特定され、可能なら解決に必要な労力が見積もられます。
これらのことは必ず追跡システムに記録するようにしましょう。
原因を調べた人が突然しばらくプロジェクトを離れなければならない（これはボランティアの開発者にはよくあることです）場合に、
- 誰かがその穴を埋められるようにしておくべきだからです。
+ 誰かが穴を埋められるようにしておくべきだからです。
</para>
<!--
@@ -4111,8 +4111,8 @@
-->
<para>
- この段階、もしくはひとつ前の段階で、
- ある開発者が問題の "所有権を得て" 自分自身を <firstterm>アサイン</firstterm> するかもしれません。
+ この段階か、もうひとつ前の段階で、
+ 開発者が問題の "所有権を得て" 自分自身を <firstterm>アサイン</firstterm> するかもしれません。
(アサインの手続きをさらに詳細に調べるには
<phrase output="printed"><xref
linkend="managing-volunteers"/>の</phrase>、
<xref linkend="delegation-assignment"/> を参照してください)
@@ -4122,20 +4122,43 @@
よって、追跡システムはそれを記録する何らかの方法を備えるべきということになります。
</para>
</listitem>
- <listitem><para>The issue gets scheduled for resolution.
+ <listitem>
+ <!--
+ <para>The issue gets scheduled for resolution.
Scheduling doesn't necessarily mean naming a date by which
it will be fixed. Sometimes it just means deciding which
future release (not necessarily the next one) the bug
should be fixed by, or deciding that it need not block any
particular release. Scheduling may also be dispensed
with, if the bug is quick to fix.</para>
+ -->
+
+ <para>
+ 問題をいつ解決するかという予定が立てられます。
+ 予定を決めるということは、
+ いつまでに直すという日程を決めることとは限りません。
+ 将来のどのリリース（次のバージョンとは限りません）で直すかを決めるだけのこともありますし、
+ 特定のリリースで直すと決めない場合もあります。
+ バグが素早く直せる場合には、予定を立てないこともあります。
+ </para>
</listitem>
- <listitem><para>The bug gets fixed (or the task completed, or
+ <listitem>
+ <!--
+ <para>The bug gets fixed (or the task completed, or
the patch applied, or whatever). The change or set of
changes that fixed it should be recorded in a comment in
the issue, after which the issue is
<firstterm>closed</firstterm> and/or marked as
<firstterm>resolved</firstterm>.</para>
+ -->
+
+ <para>
+ 問題は解決されます。（タスクが終了したり、
+ パッチが適用されたりとか、そういったものです）
+ 行った変更は、問題が<firstterm>クローズされた</firstterm>り、
+ <firstterm>resolved</firstterm> とマークされたあとに、
+ コメントとして記録するようにしましょう。
+ </para>
</listitem>
</orderedlist>
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
