Author: mumumu
Date: Wed Aug 22 05:29:00 2007
New Revision: 1064
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 Wed Aug 22 05:29:00 2007
@@ -342,7 +342,7 @@
</listitem>
</varlistentry>
-->
- <varlistentry><term>バグトラッカー</term>
+ <varlistentry><term>バグ追跡システム</term>
<listitem>
<para>
開発者が自分の作業内容を確認したり、
@@ -3033,7 +3033,7 @@
それが バグ追跡システム です。
バグデータベースは編集可能なデータを大量に保持していますが、
技術的な理由により、このデータをバージョン管理することはできません
- (バグトラッカーの中には、ちょっとしたバージョン管理機能を独自に実装しているものもあります。
+ (バグ追跡システムの中には、ちょっとしたバージョン管理機能を独自に実装しているものもあります。
しかし、これはプロジェクトのメインリポジトリとは独立したものとなります)。
</para>
@@ -3928,11 +3928,11 @@
<para>
バグ追跡 は扱う範囲が広い話題です。
- この本では バグ追跡 についての様々な側面を議論しています。
- ここでは バグ追跡システム をセットアップすることと、
+ この本では バグ追跡についての様々な側面を議論しています。
+ ここでは バグ追跡システムをセットアップすることと、
その作業に関する技術的な考察をすることに集中しようと思います。
- その話題に入る前に、バグ追跡 の方針に関する質問から始めましょう。
- : 具体的にどんな情報を バグ追跡システム に保存すべきなのでしょうか?
+ その話題に入る前に、バグ追跡の方針に関する質問から始めましょう。
+ : 具体的にどの情報を バグ追跡システム に保存すべきなのでしょうか?
</para>
<!--
@@ -3951,16 +3951,16 @@
<para>
<firstterm>バグ追跡システム</firstterm> は、誤解を招きやすい用語です。
- バグ追跡システム は、新しい機能要望や、一度限りのタスク、
+ バグ追跡システムは、新しい機能要望や、一度限りのタスク、
送られてきたパッチ — はじまりと終わりの状態があるすべてのもの、
存在している間に情報が発生するすべてのものを追跡するためによく使われます。
- このため、バグ追跡システム は、
+ このため、バグ追跡システムは、
<firstterm>問題追跡システム</firstterm>、
<firstterm>不具合追跡システム</firstterm>、
<firstterm>影響追跡システム</firstterm>、
<firstterm>要望追跡システム</firstterm>、
<firstterm>チケットシステム</firstterm> などとも呼ばれています。
- バグ追跡システム のソフトウェアの一覧は、<xref linkend="bug-trackers"/> を参照してください。
+ バグ追跡システムのソフトウェアの一覧は、<xref linkend="bug-trackers"/> を参照してください。
</para>
<!--
@@ -3978,15 +3978,16 @@
<para>
この本では "バグ追跡システム" という用語を、
物事を追跡するソフトウェアを指すものとして使うことにします。
- なぜなら、殆どの人が バグ追跡システム と呼んでいるからです。
- しかし、バグ追跡システム のデータベースに登録される個々のアイテムを指すものとして、
+ なぜなら、殆どの人がバグ追跡システムと呼んでいるからです。
+ しかし、バグ追跡システムのデータベースに登録される個々のアイテムを指すものとして、
<firstterm>問題</firstterm> という用語を使います。
これによってユーザーが遭遇するソフトウェアの変な振る舞い（つまり、バグです）と、
バグの発見、診断、解決に関する <emphasis>記録</emphasis> を区別できるからです。
- 殆どの 問題 は実際に起こったバグに関するものですが、
- 他のタスクに関することでも 問題 という用語が使えるということを覚えておいてください。
+ 殆どの問題は実際に起こったバグに関するものですが、
+ 他のタスクに関することでも問題という用語が使えるということを覚えておいてください。
</para>
+<!--
<para>The classic issue life cycle looks like this:
<orderedlist>
@@ -4066,6 +4067,81 @@
</orderedlist>
</para>
+-->
+
+<para>問題の典型的なライフサイクルは次のようなものです。:
+
+<orderedlist>
+ <listitem><para>誰かが問題をバグデータベースに記録します。
+ この記録には、問題の要点、問題の説明(もしあれば、問題を再現させるための手順;
+ ユーザに優れたバグ報告をさせる方法については、
+ <phrase output="printed"><xref
linkend="managing-volunteers"/></phrase> の <xref
linkend="users-to-volunteers"/> を参照してください)
+ 、バグ追跡システムが求めているその他の情報が全て含まれています。
+ 問題を報告した人は、プロジェクトについて全く知らないかもしれません。—
+ ユーザーのコミュニティと開発者達から、同じくらいの割合でバグ報告や機能要望があがってきます。</para>
+
+ <para>いったん問題が報告されると、その問題は <firstterm>open</firstterm>な状態にあるといいます。
+ なぜなら、それに対して何らアクションがとられていないからです。
+ バグ追跡システムによっては、
+ <firstterm>unverified</firstterm> とか
<firstterm>unstarted</firstterm> といったラベルを付与するものもあります。
+ まだ誰もこの問題を担当していません。; システムによっては、
+ 担当が決まっていないことを表すためにダミーの担当者をあてがうものもあります。
+ この時点では、問題は一時的な領域に置かれています。つまり、
+ システムに記録されてはいるが、プロジェクトがまだ関心を持っていないということです。</para>
+ </listitem>
+ <listitem><para>Others read the issue, add comments to it, and
+ perhaps ask the original filer for clarification on some
+ points.</para>
+ </listitem>
+ <listitem><para>The bug gets <firstterm>reproduced</firstterm>.
+ This may be the most important moment in its
+ life cycle. Although the bug is not actually fixed yet,
+ the fact that someone besides the original filer was able
+ to make it happen proves that it is genuine, and, no less
+ importantly, confirms to the original filer that they've
+ contributed to the project by reporting a real bug.</para>
+ </listitem>
+ <listitem><para>The bug gets <firstterm>diagnosed</firstterm>: its
+ cause is identified, and if possible, the effort required
+ to fix it is estimated. Make sure these things get
+ recorded in the issue; if the person who diagnosed the
+ bug suddenly has to step away from the project for a
+ while (as can often happen with volunteer developers),
+ someone else should be able to pick up where she left
+ off.</para>
+
+ <para>In this stage, or sometimes the previous one, a
+ developer may "take ownership" of the issue and
+ <firstterm>assign</firstterm> it to herself (<xref
+ linkend="delegation-assignment"/><phrase
+ output="printed"> in
+ <xref linkend="managing-volunteers"/></phrase>
+ examines the assignment process in more detail). The issue's
+ <firstterm>priority</firstterm> may also be set at this
+ stage. For example, if it is so severe that it should
+ delay the next release, that fact needs to be identified
+ early, and the tracker should have some way of noting
+ it.</para>
+ </listitem>
+ <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>
+ </listitem>
+ <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>
+ </listitem>
+</orderedlist>
+
+</para>
+
<para>There are some common variations on this life cycle. Sometimes
an issue is closed very soon after being filed, because it turns out
@@ -4427,7 +4503,7 @@
どのチャンネルで喋ればよいかは言うまでもなく、
利用できる全てのチャンネルを知らせるにはどうしたらよいでしょうか?
そしてチャットをするとき、
- プロジェクトに特有の決まりを知らせるにはどうすればよいでしょうか?
+ プロジェクトに特有の決まりごとを知らせるにはどうすればよいでしょうか?
</para>
<!--
@@ -4556,7 +4632,7 @@
-->
<para>
- 今ではたくさんの無料な貼り付けサイトが利用できますし、
+ 今ではたくさんの貼り付けサイトが無料で利用できますし、
まとめて示すには数が多すぎますが、
私が使われているのを見たことがあるサイトをいくつか以下に示します:
<ulink url="http://www.nomorepasting.com/"/>,
@@ -4915,7 +4991,7 @@
うまくいっている wiki の良い例は Wikipedia ですが、これは、
（百科事典の項目という）内容が本来 wiki のフォーマットとよく合っているからというのが理由のひとつです。
しかし、Wikipedia をよく調べてみると、
- 管理者達が <emphasis>とても</emphasis> 周到な協力の基盤を築いていることがわかるでしょう。
+ 管理者達が お互いが協力するために<emphasis>とても</emphasis>周到に準備をしていることがわかるでしょう。
新しい項目を追加する方法、適切な観点で編集する方法、どのような編集を行なうべきか、避けるべきか、
編集合戦にまつわる論争を解決するプロセス（ある段階では、最終的な調停も含みます）、
などにまつわる外部文書が存在します。
@@ -5129,14 +5205,14 @@
-->
<para>
- SourceForge のページ設計の背後には、きっと — 広告のように、
+ SourceForge のページ設計の裏には、きっと — 広告のように、
SourceForge の立場からすれば尤もな理由があるのでしょう。しかし、
- 個々のプロジェクトの立場から見れば、その結果理想のウェブページとはかけ離れたものになるかもしれません。
+ プロジェクトの立場から見れば、その結果が理想のウェブページとはかけ離れたものになるかもしれません。
私は SourceForge を非難するつもりで言っているのではありません。
似たような懸念は多くのホスティングサイトにも当てはまります。
重要なのは、トレードオフが存在するということです。
プロジェクトのウェブサイトを維持するための技術的な重荷から解放されますが、
- 他人のやり方を受け入れることとひきかえにしてはじめて恩恵を受けられるのです。
+ 他人のやり方を受け入れることとひきかえにはじめて恩恵を受けられるのです。
</para>
<!--
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
