Author: mumumu
Date: Mon Sep 24 17:12:59 2007
New Revision: 1217
Log:
- updated translation.
Modified:
trunk/ja/ch04.xml
Modified: trunk/ja/ch04.xml
==============================================================================
--- trunk/ja/ch04.xml (original)
+++ trunk/ja/ch04.xml Mon Sep 24 17:12:59 2007
@@ -201,7 +201,7 @@
次のふたつのセクションでは、
ほとんどの決断を円滑に行えるようにプロジェクトを統率する方法を調べていきます。
そこではふたつ例をあげていますが、いささか極度に理想的なものです。
- 多くのプロジェクトは、そのふたつの状態の間のどこかに位置しているのです。
+ 多くのプロジェクトは、ふたつの状態の間のどこかに位置しているのです。
</para>
</sect1>
@@ -299,7 +299,7 @@
議論の最初の段階では、
自分の意見に反対するのは的外れだと確信して意見や結論を述べてはいけません。
人々には、たとえ馬鹿げたアイディアであっても自由に述べさせなければいけません。
- もちろん、優しい独裁者であっても必ず愚かな考えをたびたび述べてしまいます。
+ もちろん、優しい独裁者であっても必ず愚かな考えを述べることがあります。
だから、自分が悪い決断を下したときに、それを認識し、
受け入れる能力も必要になるのです。—
ですが、この資質は優れた開発者であれば、
@@ -487,7 +487,7 @@
-->
<para>
- <firstterm>合意</firstterm> とは、単に皆が受け入れようと一致することです。
+ <firstterm>合意</firstterm> とは、皆が受け入れようと一致することです。
これはあいまいな状態ではありません。
誰かが合意に達したんじゃないかと提案し、
それに対して誰も反対を表明しない場合、あるグループは合意に達したといえます。
@@ -516,9 +516,9 @@
ある機能を追加するか、しないか、
プログラムのインターフェイスをどの程度厳密に文書化するか、などです。
合意を基本とした統治は、技術的な議論そのものとよく合うのでうまくいきます。
- 議論が終わるまでに、どの方向性をとるかに関して合意がよく成立します。
+ 議論が終わるまでに、どの方向性をとるかについて合意がよく成立します。
通常は議論を終了するという投稿をし、
- 同時に何が決まるのかをまとめた上で合意に達したのではないかと暗に提案します。
+ 同時に何が決まるのかをまとめた上で、合意に達したよねと暗に提案します。
これが "待った！ 俺は反対だ。もう少し徹底的に話し合う必要があるね。"
と言える最後の機会を与えているのです。
</para>
@@ -549,7 +549,7 @@
他の開発者はわざわざ同意すると口に出して言ったりしません。
なぜなら黙っていることは合意することだからです。
コミットされた修正が、合意を得られないと判明した場合、
- プロジェクトでは単にそれがまだコミットされていないかのように議論されます。
+ プロジェクトではそれがまだコミットされていないかのように議論されます。
このやり方がうまく行く理由は次の節で述べていきます。
</para>
@@ -686,7 +686,7 @@
投票が打開策になります。
投票を行う前には、結論の候補となる選択肢を明確にしなければなりません。
ここで、普段やっている技術的な議論をしてみると、
- これが結論を出す過程と意外によく合っていることが再びわかるでしょう。
+ 結論を出す手続きと意外によく合っていることが再びわかるでしょう。
投票になる論点は、複雑で多面的な問題を含むことがたびたびあります。
こういう複雑な議論では、
<firstterm>仲裁人</firstterm> の役割を果たす人が普通ひとりかふたりはいます。
@@ -727,7 +727,7 @@
選択肢に対する正確な説明がないといった、
投票が正しいものかどうかを心配していることがありますが、
投票によって出る結論が自分の望むものに絶対ならないことを多分知っていて、
- 単に投票を避けようとしている場合もあります。
+ 投票を避けようとしているだけの場合もあります。
この手の妨害行為をどう扱うかは、
<phrase output="printed"><xref linkend="communications"/></phrase> の、
<xref linkend="difficult-people"/> を参照してください。
@@ -760,7 +760,7 @@
一回の投票で済みます。認定投票と他の投票システムの詳細については、
<ulink url="http://en.wikipedia.org/wiki/Voting_system#List_of_systems"/>
を参照してください。
しかしながら、どの投票システムを使うかについて、長く議論するのは避けるようにしましょう。
- （なぜなら、当然のことながら、
+ （当然、
投票システムを決めるのにどの投票システムを使うかを議論することになるからです！）
認定投票が優れた選択となる理由は、反対意見を表明することが難しいからです。
— つまり、投票システムはできるだけ公平であるべきということです。
@@ -808,18 +808,18 @@
-->
<para>
- 投票で最も難しいのは、いつ投票を行うかということです。一般的には、
+ 投票で最も難しいのは、いつ投票を行うかです。一般的には、
投票に実際に踏み切ることは滅多にすべきではありません—
つまり、他のあらゆる手段が失敗したときの最後の手段にすべきです。
投票が議論を解決する素晴らしい手段だと看做さないでください。
- 実際、そうではありません。投票は議論を終結させ、
+ 実際、そうではないのです。投票は議論を終結させ、
それによって問題について創造的に考えることもやめさせてしまうのです。
議論が続いている限り、皆が好む新しい解決策を誰かが思い付く可能性があります。
これは驚くほどたびたび起こります。活発な議論は、
問題について新しい考え方を生み出しますし、結局皆を満足させる提案にも繋がります。
たとえ新しい提案が生まれなくても、投票を行うよりは、
- 妥協案を仲介してもらった方が通常はまだよいです。
- 妥協したあとは、皆ちょっと悲しい思いをします。
+ 妥協案を仲介してもらった方が通常はまだマシです。
+ 妥協したあとは、皆がちょっと悲しい思いをします。
一方で、投票をしたあとは喜ぶ人がいる一方で、悲しい思いをする人もいます。
政治的な観点からは、前者の方が好ましいといえます。
なぜなら、少なくともひとりひとりが自分の悲しい思いに対して対価を支払っているからです。
@@ -848,15 +848,15 @@
<para>
投票の主な利点は、皆が次に進める形で問題を最終的に解決してくれることです。
しかし、投票は皆を理性的な対話によって同じ結論に導くのではなく、
- 頭数で問題を解決してしまいます。オープンソースプロジェクトで経験を積めば積むほど、
+ 頭数で問題を解決してしまいます。私は、オープンソースプロジェクトで経験を積めば積むほど、
人々が問題を投票によって解決したがらなくなるのがわかってきました。
むしろ、以前考えたこともない解決策を探ったり、
- もともと計画よりも厳しい妥協をしようとします。
+ もともとの計画よりも厳しい妥協をしようとします。
早まった投票を避けるために様々なテクニックがあります。もっとも明白なやり方は、
- "まだ投票を実施する段階ではないと思うよ。"といって、何故かを説明することです。
+ "まだ投票を実施する段階ではないと思うよ。" といって、何故かを説明することです。
別のやり方として、非公式に賛成の人は手を挙げてもらう（拘束力はありません）ことがあります。
その反応が明らかに一方に偏っていたら、
- 正式に投票を行うことを避けるために、積極的に妥協することを人々に促すことになるでしょう。
+ 正式に投票を行うのを避けるために、積極的に妥協することを人々に促すことになるでしょう。
もっとも効率的なやり方は、人々が同じ主張を繰り返さずに問題に再び取り組めるように、
新しい解決策や、以前の提案に基づいた新しい視点を示すことです。
</para>
@@ -874,7 +874,7 @@
<para>
まれなケースとして、示された全ての妥協案は、
- 妥協をしていない全ての案よりも劣っていることで全員が一致することがあります。
+ 妥協していない全ての案よりも劣っていることで全員が一致することがあります。
この場合、投票を実施することに反対しにくくなります。なぜなら、
投票の方がより優れた解決に繋がる可能性がありますし、
どのような結果になっても全員が過度に悲しい思いをすることはないからです。
@@ -957,7 +957,7 @@
メーリングリスト上で破壊的な発言をしたり、
プロジェクトを妨害する傾向がある人がいる場合は、
プロジェクトはたとえその人が技術的に優れていたとしても、
- コミット権限を与える際には注意する必要があります。
+ コミット権限を与える際に注意する必要があります。
</para>
<!--
@@ -993,7 +993,7 @@
<para>
完全なコミット権限にせよ、限定的なものにせよ、
- 新しいコミッタを選ぶのには投票システムそのものを使うべきですが、
+ 新しいコミッタを選ぶには投票システムを使うべきですが、
この場合は秘密投票が適切になるまれな事例のひとつです。
コミッタになる可能性がある人について、メーリングリストで投票を行うことはできません。
なぜなら、候補者の感情(評判）を傷つけてしまう可能性があるからです。
@@ -1015,7 +1015,7 @@
もちろん、誰かが明示的にコミット権限が欲しいと頼んできた場合は、その提案について検討し、
受け入れるか拒むかの回答を明示的に行うしかありません。
仮に拒む場合は、はっきりと説明を沿えてできるだけ丁寧に断るべきです。
- たとえば "開発者チームは君のパッチを気に入っているけれども、量がまだ十分でなない" とか、
+ たとえば "開発者チームは君のパッチを気に入っているけれども、量がまだ十分でない。" とか、
"開発チームは君のパッチを全て高く評価しているけど、適用する前にかなり調整が必要なんだ。
だからコミット権限を与えるのが好ましいと思えない。
このことは時間をかけて改善して欲しいと願っている。" という感じです。
@@ -1074,15 +1074,16 @@
-->
<para>
- ある種の投票では、投票権を与える対象を広げて投票を電子化した方がいいかもしれません。
- たとえば開発者が単に、与えられたユーザーインターフェイスが、
- ユーザーのソフトウェアの使い方と合うかどうか決められない場合、
+ ある種の投票では、有権者を広げた方がいいかもしれません。
+ たとえば、
+ 与えられたユーザーインターフェイスがユーザーのソフトウェアの使い方と合うかどうかを、
+ 開発者が決められない場合、
プロジェクトのメーリングリストを購読している人全員に尋ねてみるのがひとつの解になります。
これは投票というよりむしろ <firstterm>世論調査</firstterm> ですが、
- 開発者はその結果を拘束力のあるものとして扱うかもしれません。
- どういった調査であっても必ず、
- 与えられている選択肢以外の回答を記入できることを参加者に明示するようにしましょう。
- 誰かが調査の質問として与えられた選択肢よりも優れた回答を考えている場合に、
+ 開発者はその結果を拘束力のあるものとして扱っても構いません。
+ どういった調査であっても、
+ 与えられている選択肢以外の回答を記入できることを必ず参加者に明示するようにしましょう。
+ 調査の質問として与えられた選択肢よりも優れた回答を考えている人がいる場合、
調査の結果、その回答がもっとも重要だとわかる場合があるからです。
</para>
@@ -1141,7 +1142,7 @@
開発者たちは、もっと議論が必要なときに拒否権を行使することで、
リスクを増やしたくないと考えています。
あなたは、自分自身が拒否権をとても慎重に行使し、
- そして誰かが拒否権を多く行使し続けている場合に、
+ そして拒否権を多く行使し続けている人がいる場合に、
丁寧にそれを指摘することによって拒否権の濫用を防ぐことができます。
必要とあらば、開発者たちが拒否権に拘束力があると長期に渡って賛同している場合にだけ、
拒否権に拘束力を持たせるよう求めることもできます —
@@ -1205,6 +1206,7 @@
<sect1 id="written-rules">
<title>全てを記録しておく</title>
+<!--
<para>At some point, the number of conventions and agreements floating
around in your project may become so great that you need to record it
somewhere. In order to give such a document legitimacy, make it clear
@@ -1216,7 +1218,23 @@
them. Of course, if it is successful, people will start citing it as
a source of authority in itself, but that just means it reflects the
overall will of the group accurately.</para>
+-->
+
+<para>
+ プロジェクトの規約や合意の数が多くなり過ぎるために、
+ ある時点でどこかに記録しておく必要が生じます。
+ 記録を正統なものにするためには、
+ メーリングリストでの議論や既に有効になっている合意をベースにしていることを明示するようにしましょう。
+ 実際に記録するときは、
+ メーリングリストのアーカイブにある関連したスレッドを参照するようにし、
+ 参照すべき場所がわからないときは、周りに尋ねるようにしましょう。
+ 記録した文書には人々を驚かせるようなことを書くべきではありません。
+ たとえば、根拠を書かずに、合意の中身だけを説明するようなことです。
+ もちろん、成功すればそれを権威あるものとして人々が引用しはじめるかもしれませんが、
+ それはプロジェクトの総意を正確に反映しているだけに過ぎません。
+</para>
+<!--
<para>This is the document alluded to in <xref
linkend="developer-guidelines"/><phrase output="printed"> in
<xref linkend="getting-started"/></phrase>. Naturally, when the
@@ -1224,6 +1242,16 @@
the benefit of a long project history to draw on. But as the
development community matures, you can adjust the language to reflect
the way things actually turn out.</para>
+-->
+
+<para>
+ これが <phrase output="printed"><xref linkend="getting-started"/></phrase> の
<xref linkend="developer-guidelines"/> で述べた文書になります。
+ 当然、プロジェクトが若いうちは、
+ 長く続いているプロジェクトの歴史のような、
+ ためになる話抜きでガイドラインを書かねばならないでしょう。
+ しかしプロジェクトが成長するにつれ、
+ 明らかになってきた事柄を反映させた形で、文書を改訂することができます。
+</para>
<para>Don't try to be comprehensive. No document can capture
everything people need to know about participating in a project. Many
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
