Author: mumumu
Date: Sat Sep 22 04:36:04 2007
New Revision: 1195
Log:
- self review part 2.
Modified:
trunk/ja/ch04.xml
Modified: trunk/ja/ch04.xml
==============================================================================
--- trunk/ja/ch04.xml (original)
+++ trunk/ja/ch04.xml Sat Sep 22 04:36:04 2007
@@ -16,7 +16,8 @@
-->
<para>
- 通常、フリーソフトウェアについて人々がする最初の質問は "プロジェクトはどういう仕組みで動くの？
+ フリーソフトウェアについて人々がよくする最初の質問は、
+ "プロジェクトはどういう仕組みで動くの？
プロジェクトを維持しているものは何？ 誰に決定権があるの？" といったものです。
私は、実力主義や、協力の精神、読めば何をやっているかわかるコード、 などについて当たり障りなく答えて、
いつも釈然としない思いがします。 実のところ、こうした質問に答えるのは簡単ではありません。
@@ -42,8 +43,8 @@
-->
<para>
- この章では、
- 成功しているオープンソースプロジェクトが共通して持っている構造的な基盤を示そうと思います。
+ この章では、成功しているオープンソースプロジェクトに共通している、
+ 基本的な仕組みを説明します。
"成功している" というのは、ただ技術的に質が高いだけでなく、
プロジェクトが健全に運営されており、生き残る力が強いことを言います。
新しいコードや開発者を受け入れたり、
@@ -56,7 +57,7 @@
技術的に成功することは難しくありません。
しかし開発者の層が薄かったり、社会的な基盤が弱かったりすると、
プロジェクトが初期段階で成功して膨張したり、
- カリスマ的な人がいなくなったときに、対処できないかもしれません。
+ カリスマ的な人がいなくなったときに、対応できないかもしれません。
</para>
<!--
@@ -75,11 +76,11 @@
-->
<para>
- 構造的な基盤という意味で、プロジェクトを成功させる方法はたくさんあります。
+ オープンソースプロジェクトを成功させる方法はたくさんあります。
議論をまとめたり、新しい開発者を勧誘したり（時には追い出したり）、
新しい機能を企画するなどの、
- 型にはまった管理の仕組みに関するものがあります。
- 一方で、形として表れないものですが、
+ 型にはまった統治の仕組みもあれば、
+ 形になって表れないものとして、
メンバーが信頼し、事実上プロジェクトを支配する公平な雰囲気を作り出すために、
より意識的に自制することも含まれます。
プロジェクトは、
@@ -88,7 +89,7 @@
これらの方法は、中央集権的なプロジェクトより、
自発的に成長するプロジェクトで重要になります。
自発的に成長するプロジェクトでは、少なくともしばらくは、
- よくないことが全体に影響することを皆が意識しているからです。
+ よくないことが全体に影響することを参加する人が意識しているからです。
</para>
<sect1 id="forkability">
@@ -111,7 +112,7 @@
-->
<para>
- 開発者をフリーソフトウェアプロジェクトにつなぎ止め、
+ 開発者をフリーソフトウェアプロジェクトに繋ぎ止め、
必要な時に妥協してもらうのに不可欠な要素は、
コードが <firstterm>派生する</firstterm> ことです。
逆説的なのは、コードが派生する <emphasis>可能性</emphasis> の方が、
@@ -167,7 +168,7 @@
そんなわけで、民主主義に従って組織化されていないプロジェクトでさえ、
重要な決定をする段になると民主主義の仕組みを使います。
コードを複製できるということは、コードを派生できるということです。
- コードを派生できるということは、妥協を生むことを意味しています。
+ コードを派生できるということは、それを避けるために合意が形成されることを意味しています。
全員がひとりのリーダーに従うこと（もっとも有名な例が、Linux kernel 開発の Linus Torvalds です）もあるかもしれませんが、
これは 完全にひねくれているわけでもなく、悪意があるわけでもなく、彼らがそうすることを <emphasis>選んでいる</emphasis>
からです。
独裁者がプロジェクトを魔法のように支配しているわけではないのです。
@@ -197,7 +198,7 @@
プロジェクトを統率するやり方に重大な違いがあるわけではありません。
決断をするたびに、誰かコードを派生させようと思ってる人いる？ と質問したくはないはずです。
そんなことをすればすぐに疲れてしまい、仕事をする活力が失われていきます。
- 次のふたつの節では、
+ 次のふたつのセクションでは、
ほとんどの決断を円滑に行えるようにプロジェクトを統率する方法を調べていきます。
そこではふたつ例をあげていますが、いささか極度に理想的なものです。
多くのプロジェクトは、そのふたつの状態の間のどこかに位置しているのです。
@@ -252,14 +253,14 @@
"優しい独裁者" （略して <firstterm>BD</firstterm> ともいいます）という言葉は、
こうした役割に対して標準的に使われる用語ですが、
むしろ "コミュニティーが認めた調停者" もしくは "審判" と考えた方がいいでしょう。
- 一般的に、優しい独裁者が実際に全ての、
+ 一般的には、優しい独裁者が実際に全ての、
もしくはほとんどの決定を行っているわけではありません。
ある人がプロジェクトの全ての領域に渡って、
優れた決断を一貫して行う十分な技能があることはまれです。
- そして優れた開発者は、プロジェクトの方向性に影響を及ぼすことがなければ、
- 結局プロジェクトに留まり続けたりはしません。
+ そして優れた開発者は、プロジェクトの方向性に影響を与えられなければ、
+ 結局プロジェクトから去ってしまいます。
よって、優しい独裁者は普通多く指示を出したりはしません。
- むしろ、いつでも可能な限り、議論や実験を通じて働くのを開発者に任せておきます。
+ むしろいつでも可能な限り、議論や実験を行う作業を開発者に任せておきます。
優しい独裁者は議論そのものには参加しますが、普通の開発者として、
自分より優れた技能を持つメンテナの領域では、たびたび彼らに従います。
結論が出ず、ほとんどのグループが開発を続けるために誰かが判断の指針を示すことを明確に <emphasis>望んでいる</emphasis> 場合だけ、
@@ -298,12 +299,12 @@
議論の最初の段階では、
自分の意見に反対するのは的外れだと確信して意見や結論を述べてはいけません。
人々には、たとえ馬鹿げたアイディアであっても自由に述べさせなければいけません。
- もちろん、優しい独裁者もたびたび愚かな考えを述べることも避けられません。
+ もちろん、優しい独裁者であっても必ず愚かな考えをたびたび述べてしまいます。
だから、自分が悪い決断を下したときに、それを認識し、
受け入れる能力も必要になるのです。—
ですが、この資質は優れた開発者であれば、
特にプロジェクトに長い間留まっている人であればなおさら <emphasis>誰でも</emphasis> 持っているはずの資質にすぎません。
- しかし、優しい独裁者が違う点は、
+ しかし、優しい独裁者が違うのは、
自分の信頼に長い間傷が付いてしまうんじゃないかと恐れることなく、
たびたび間違いを犯す余裕があることです。
年季が入っていない開発者は、自分が保護されていないと感じているかもしれません。
@@ -470,8 +471,7 @@
<para>
こうした仕組みがどう機能するかを詳細に見ていくと、
- 中身は変化に富んでいますが、
- 共通した要素が二つあります。
+ 中身は変化に富んでいますが、共通した要素が二つあります。
ひとつは、グループはほとんどいつも合意に基づいて動くこと。
ふたつめは、合意に達しないときに投票の仕組みを使うことです。
</para>
@@ -512,9 +512,9 @@
<para>
プロジェクトで交わされるほとんどの会話は技術的な話題です。
- たとえば、バグを直す正しい方法に関するものとか、
+ たとえば、正しくバグを直す方法とか、
ある機能を追加するか、しないか、
- プログラムのインターフェイスをどの程度厳密に文書化するか、などといったものです。
+ プログラムのインターフェイスをどの程度厳密に文書化するか、などです。
合意を基本とした統治は、技術的な議論そのものとよく合うのでうまくいきます。
議論が終わるまでに、どの方向性をとるかに関して合意がよく成立します。
通常は議論を終了するという投稿をし、
@@ -549,7 +549,7 @@
他の開発者はわざわざ同意すると口に出して言ったりしません。
なぜなら黙っていることは合意することだからです。
コミットされた修正が、合意を得られないと判明した場合、
- プロジェクトでは単にまだそれがコミットされていないかのように議論されます。
+ プロジェクトでは単にそれがまだコミットされていないかのように議論されます。
このやり方がうまく行く理由は次の節で述べていきます。
</para>
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
