Author: mumumu
Date: Mon Sep 17 16:14:37 2007
New Revision: 1192
Log:
- self review.
Modified:
trunk/ja/ch04.xml
Modified: trunk/ja/ch04.xml
==============================================================================
--- trunk/ja/ch04.xml (original)
+++ trunk/ja/ch04.xml Mon Sep 17 16:14:37 2007
@@ -18,7 +18,7 @@
<para>
通常、フリーソフトウェアについて人々がする最初の質問は "プロジェクトはどういう仕組みで動くの？
プロジェクトを維持しているものは何？ 誰に決定権があるの？" といったものです。
- 私は、実力主義や、協力の精神、自己説明的なコード、 などについて当たり障りなく答えて、
+ 私は、実力主義や、協力の精神、読めば何をやっているかわかるコード、 などについて当たり障りなく答えて、
いつも釈然としない思いがします。 実のところ、こうした質問に答えるのは簡単ではありません。
実力主義、協力、そして動くコードは全て答えの一部ではありますが、
日々の単位でプロジェクトがどう動いているかについて殆ど説明していませんし、
@@ -42,15 +42,17 @@
-->
<para>
- この章では、成功しているオープンソースプロジェクトが共通して持っている構造的な基盤を示そうと思います。
- "成功している" というのは、ただ技術的に質が高いだけではなく、
+ この章では、
+ 成功しているオープンソースプロジェクトが共通して持っている構造的な基盤を示そうと思います。
+ "成功している" というのは、ただ技術的に質が高いだけでなく、
プロジェクトが健全に運営されており、生き残る力が強いことを言います。
新しいコードや開発者を受け入れたり、
バグレポートに素早く反応することを継続できていれば、
プロジェクトは健全に運営されているといえます。
- 特定の個人やスポンサーにも依存しなくてもプロジェクトを続けられれば、
- 生き残る力が強いといえます。— プロジェクトを立ち上げたメンバー全員が他に移ったとしても、
- プロジェクトが存続するか、といったことを考えてみてください。
+ 特定の個人やスポンサーに依存しなくてもプロジェクトを続けられれば、
+ 生き残る力が強いといえます。—
+ プロジェクトを立ち上げたメンバー全員が他に移ったとしても、
+ プロジェクトが生き残る可能性があるかを考えてみてください。
技術的に成功することは難しくありません。
しかし開発者の層が薄かったり、社会的な基盤が弱かったりすると、
プロジェクトが初期段階で成功して膨張したり、
@@ -73,19 +75,20 @@
-->
<para>
- これらの観点から成功を収める方法はたくさんあります。
+ 構造的な基盤という意味で、プロジェクトを成功させる方法はたくさんあります。
議論をまとめたり、新しい開発者を勧誘したり（時には追い出したり）、
新しい機能を企画するなどの、
- 型にはまった管理の仕組みに関するものもあれば、
- 型にはまっているものではありませんが、
- <foreignphrase>デファクト</foreignphrase> な統率の方法だと人々が信頼できる公平な雰囲気を作り出すために、
+ 型にはまった管理の仕組みに関するものがあります。
+ 一方で、形として表れないものですが、
+ メンバーが信頼し、事実上プロジェクトを支配する公平な雰囲気を作り出すために、
より意識的に自制することも含まれます。
- 参加している人達がよく理解している習慣や手続きに支えられて、
- 組織がずっと続いていくという意味で、
- どちらのやり方も行き着くところは同じです。
- これらの方法は、中央集権的な組織より、自然に発展していく組織でより重要になります。
- なぜならそうした組織では、
- よくないものが全体に影響することを少なくともしばらくは皆が意識しているからです。
+ プロジェクトは、
+ 参加する人達がよく理解している習慣や手続きに支えられて存続するという意味で、
+ どちらも行き着くところは同じです。
+ これらの方法は、中央集権的なプロジェクトより、
+ 自発的に成長するプロジェクトで重要になります。
+ 自発的に成長するプロジェクトでは、少なくともしばらくは、
+ よくないことが全体に影響することを皆が意識しているからです。
</para>
<sect1 id="forkability">
@@ -110,7 +113,7 @@
<para>
開発者をフリーソフトウェアプロジェクトにつなぎ止め、
必要な時に妥協してもらうのに不可欠な要素は、
- コードを <firstterm>派生させることができる</firstterm> ことです。
+ コードが <firstterm>派生する</firstterm> ことです。
逆説的なのは、コードが派生する <emphasis>可能性</emphasis> の方が、
まれながら実際に派生することよりも、
フリーソフトウェアプロジェクトにとって大きな力になるということです。
@@ -135,9 +138,9 @@
<para>
コードが派生すること、いやむしろ派生する可能性と言った方がよいでしょう。
- この可能性こそが、フリーソフトウェアプロジェクトには本当の意味での独裁者が存在しない理由になっています。
+ この可能性こそが、フリーソフトウェアプロジェクトに本当の意味での独裁者が存在しない理由になっています。
これはオープンソースプロジェクトで "独裁者" とか "暴君" と呼ばれる人がいるとよく聞くことを思えば、突飛な主張かもしれません。
- しかし、この手の "圧政" という言葉は特別なもので、伝統的に理解されている圧政の意味とは違うものです。
+ しかし、この手の "暴政" という言葉は特別なもので、伝統的に理解されている暴政の意味とは違うものです。
いつでも自分の王国をコピーでき、
いいように支配するためにそのコピーを持ち歩ける家来がいる王様を想像してみてください。
そんな王様が、自分が何をしようと家来が自分の支配下にいると決まっている王様と同じ振舞いをするでしょうか？ するはずがないですよね。
@@ -189,11 +192,14 @@
-->
<para>
- しかし、コードを派生できることがプロジェクトで権力を行使することに歯止めをかけているからといって、
+ しかし、
+ コードを派生できることがプロジェクトで権力を行使することに歯止めをかけているからといって、
プロジェクトを統率するやり方に重大な違いがあるわけではありません。
決断をするたびに、誰かコードを派生させようと思ってる人いる？ と質問したくはないはずです。
- そんなことをすればすぐに疲れてしまい、仕事をすると活力が失われていきます。
-
次のふたつの節では、ほとんどの決断を円滑に行えるようにプロジェクトを統率する方法を調べていきます。そこではふたつ例をあげていますが、いささか極度に理想的なものです。
+ そんなことをすればすぐに疲れてしまい、仕事をする活力が失われていきます。
+ 次のふたつの節では、
+ ほとんどの決断を円滑に行えるようにプロジェクトを統率する方法を調べていきます。
+ そこではふたつ例をあげていますが、いささか極度に理想的なものです。
多くのプロジェクトは、そのふたつの状態の間のどこかに位置しているのです。
</para>
@@ -216,7 +222,7 @@
<firstterm>優しい独裁者</firstterm> モデルとは、
正確には次のようなものです。
つまり、最終的な決断を行う権限が、
- 人柄や経験が優れているという理由で、
+ 人格や経験が優れているという理由で、
賢明に権限を行使できるひとりの人に委ねられていることです。
</para>
@@ -243,19 +249,20 @@
-->
<para>
- "優しい独裁者" （または略して <firstterm>BD</firstterm> ともいいます）という言葉は、
+ "優しい独裁者" （略して <firstterm>BD</firstterm> ともいいます）という言葉は、
こうした役割に対して標準的に使われる用語ですが、
むしろ "コミュニティーが認めた調停者" もしくは "審判" と考えた方がいいでしょう。
- 一般的に、優しい独裁者が実際に全ての、もしくはほとんどの決定を行っているわけではありません。
+ 一般的に、優しい独裁者が実際に全ての、
+ もしくはほとんどの決定を行っているわけではありません。
ある人がプロジェクトの全ての領域に渡って、
優れた決断を一貫して行う十分な技能があることはまれです。
そして優れた開発者は、プロジェクトの方向性に影響を及ぼすことがなければ、
結局プロジェクトに留まり続けたりはしません。
- それゆえに、優しい独裁者は普通多く指示を出したりはしません。
- むしろ、いつでも可能な限り、議論や実験を通して働くのは開発者に任せておきます。
- 彼らは議論そのものには参加しますが、普通の開発者として、
+ よって、優しい独裁者は普通多く指示を出したりはしません。
+ むしろ、いつでも可能な限り、議論や実験を通じて働くのを開発者に任せておきます。
+ 優しい独裁者は議論そのものには参加しますが、普通の開発者として、
自分より優れた技能を持つメンテナの領域では、たびたび彼らに従います。
- 結論が出ず、ほとんどのグループが開発を続けるために誰かが判断の指針を示すことを <emphasis>望んでいる</emphasis>
のが明らかな場合にだけ、
+ 結論が出ず、ほとんどのグループが開発を続けるために誰かが判断の指針を示すことを明確に <emphasis>望んでいる</emphasis> 場合だけ、
彼らは敢えて異を唱えてこういうのです。「これがあるべき方向性だ」と。
命令することで決定するのを我慢するのは、
成功している優しい独裁者に事実上共通する特性です。
@@ -289,18 +296,19 @@
まず第一に、自分自身がプロジェクトに及ぼす影響について感覚を研ぎ澄ますこと、
これは言い替えれば自制を働かせるということです。
議論の最初の段階では、
- 自分の意見に反対するのは的外れだと他の人が思っていると確信して意見や結論を述べてはいけません。
+ 自分の意見に反対するのは的外れだと確信して意見や結論を述べてはいけません。
人々には、たとえ馬鹿げたアイディアであっても自由に述べさせなければいけません。
- もちろん、優しい独裁者もたびたび愚かなな考えを述べることも避けられません。
+ もちろん、優しい独裁者もたびたび愚かな考えを述べることも避けられません。
だから、自分が悪い決断を下したときに、それを認識し、
受け入れる能力も必要になるのです。—
- ですが、この資質は優れた開発者であれば、特にプロジェクトに長い間留まっている人であればなおさら <emphasis>誰でも</emphasis>
持っているはずの資質にすぎません。
+ ですが、この資質は優れた開発者であれば、
+ 特にプロジェクトに長い間留まっている人であればなおさら <emphasis>誰でも</emphasis> 持っているはずの資質にすぎません。
しかし、優しい独裁者が違う点は、
自分の信頼に長い間傷が付いてしまうんじゃないかと恐れることなく、
たびたび間違いを犯す余裕があることです。
年季が入っていない開発者は、自分が保護されていないと感じているかもしれません。
だからこそ優しい独裁者は、
- 技術的な面でも精神的な面でも自分の言葉が伝える重みに敏感になって、
+ 技術的な面でも精神的な面でも、自分の言葉が伝える重みに敏感になって、
批判をしたり反対意見を述べるべきなのです。
</para>
@@ -320,9 +328,10 @@
優しい独裁者は、
プロジェクトにいる誰よりも技術的なスキルが優れている必要は <emphasis>ありません</emphasis>。
コードを書く能力に十分優れ、
- コードに加えられたあらゆる変更を理解し、思いやりをもってそれにコメントしなければいけませんが、たったそれだけです。
+ コードに加えられたあらゆる変更を理解し、
+ 思いやりをもってそれにコメントしなければいけませんが、それだけです。
優しい独裁者の立場は、誰かから教わって得たものではありませんし、
- コードを書くスキルが恐ろしいほどあるという理由で得たものでもありません。
+ コードを書くスキルが恐ろしくあるという理由で得たものでもありません。
<emphasis>重要なのは</emphasis> 経験と総合的な設計センスです。—
必要に応じて優れた設計を生み出す能力ではなく、
優れた設計をソースコードから認識する能力なのです。
@@ -370,14 +379,14 @@
優しい独裁者は他の人と同様、容易にプロジェクトを派生させることができますし、
大多数の開発者が望んでいるプロジェクトの方向性が、
自分が望むものと違っていると感じたときは、
- 時折優しい独裁者以外の人もそうすることがあります。
+ 時折優しい独裁者以外の人もコードを派生させることがあります。
コードを派生させることができるので、
優しい独裁者がプロジェクトのメインサーバーの root 権限（システム管理者の権限）を持っているかどうかは問題になりません。
人によっては、サーバの管理権限を持っていることがプロジェクトの最終的な権限の源であるかのように話すひとがいますが、実際は無関係です。
ある特定のサーバで開発者のコミットパスワードを追加したり、削除したりできる権限は、
そのサーバにあるプロジェクトのコピーにのみ影響します。
そうした権限に関する苦情が、優しい独裁者や他の開発者かどうかに関係なく長期間続くと、
- 開発が他のサーバに単に移っていくだけです。
+ 単に開発が他のサーバに移っていくだけです。
</para>
</sect2>
@@ -393,12 +402,12 @@
-->
<para>
- プロジェクトに優しい独裁者がいるべきか、
- 中央集権をいくらか緩めた仕組みの方がうまくいくかどうかは、
+ プロジェクトに優しい独裁者がいる方がうまくいくか、
+ 中央集権をいくらか緩めた仕組みの方がうまくいくかは、
役割を果たす人達がどれだけいるかにかかっています。
- 一般的なルールとして、単に優しい独裁者に誰がなってもいいことが明らかな場合は、
+ 一般的なルールとして、優しい独裁者に誰がなってもいいことが明らかな場合は、
そうするとよいでしょう。しかし、誰もなり手がいないのが明らかな場合は、
- 次の節で述べるような分権的な決定プロセスを使うべきでしょう。
+ 次の節で述べる分権的な決定プロセスを使うべきでしょう。
</para>
</sect1>
@@ -432,17 +441,19 @@
<para>
プロジェクトが続いていくと、プロジェクトは優しい独裁者モデルから離れ、
より開かれた民主主義的なプロセスに移行します。
- これは特定の優しい独裁者に必ずしも満足していないわけではありません。
- 単にグループ主体の統治の方が、生物学のメタファーを借りて言えば "進化的に安定している" からです。
- 優しい独裁者が身を引いたり、決定を下す権限を多くの人に平等に与えようとするときはいつでも、
+ これは特定の優しい独裁者に必ずしも満足していないからではありません。
+ 単にグループ主体の統治の方が、
+ 生物学のメタファーを借りて言えば "進化的に安定している" からです。
+ 優しい独裁者が身を引いたり、
+ 決定する権限を多くの人に平等に与えようとするときはいつでも、
グループが新しい、独裁的でない仕組みに移行する機会になります —
これは言ってみれば組織化を行うということです。
開発者のグループは最初の1、2回はこの機会を利用しませんが、
結局は利用することになります。いったんそうしてしまえば、
- もとの仕組みに戻ることはありません。このことは常識でわかることです。
- 仮に N人 からなるグループがある人に特別な権限を与えていると仮定すると、
+ もとの仕組みに戻ることはありません。何故かは常識でわかることです。
+ 仮に N人 からなるグループが、ある人に特別な権限を与えていると仮定すると、
N - 1 人が自分の影響力を弱めることに合意していることになります。
- 独裁的でない仕組みでは、人々は普通特別な権限を欲しいとは思いません。
+ 独裁的でない仕組みでは、普通特別な権限を特定の人に与えたいとは思いません。
たとえ望んだとしても、結果として行使できる権力は条件付きのものになります。
優しい独裁者を任命しても、これは明らかなことですが、
グループが後に辞めさせてしまうことができるからです。
@@ -458,7 +469,8 @@
-->
<para>
- こうした仕組みをどう機能させるかの詳細は変化に富んでいますが、
+ こうした仕組みがどう機能するかを詳細に見ていくと、
+ 中身は変化に富んでいますが、
共通した要素が二つあります。
ひとつは、グループはほとんどいつも合意に基づいて動くこと。
ふたつめは、合意に達しないときに投票の仕組みを使うことです。
@@ -482,7 +494,7 @@
合意に達したんじゃないかと提案する人は、
合意とは何かということと、
仮に明らかでない場合は、
- 合意の結果どのような行動がとられるのかを具体的に述べるべきです。
+ 合意の結果どのような行動をとるのかを具体的に述べるべきです。
</para>
<!--
@@ -504,10 +516,11 @@
ある機能を追加するか、しないか、
プログラムのインターフェイスをどの程度厳密に文書化するか、などといったものです。
合意を基本とした統治は、技術的な議論そのものとよく合うのでうまくいきます。
- 議論が終わるまでに、どの方向性を採るかに関して合意がよく成立します。
+ 議論が終わるまでに、どの方向性をとるかに関して合意がよく成立します。
通常は議論を終了するという投稿をし、
- 同時に何が決まるのかをまとめた上で合意に達したことを暗に提案します。
- これが "待った！ 俺は反対だ。もう少し徹底的に話し合う必要があるね。" と言える最後の機会を与えているのです。
+ 同時に何が決まるのかをまとめた上で合意に達したのではないかと暗に提案します。
+ これが "待った！ 俺は反対だ。もう少し徹底的に話し合う必要があるね。"
+ と言える最後の機会を与えているのです。
</para>
<!--
@@ -525,7 +538,7 @@
-->
<para>
- 小規模で、議論に値しない事柄を決めるときは、
+ 規模が小さく、議論に値しない事柄を決めるときは、
合意に達したという提案も暗黙に行われます。
たとえば、開発者がバグ修正を自発的にコミットした場合、
そのコミット自体が合意に達したことを提案することになります。
@@ -563,11 +576,11 @@
-->
<para>
- プロジェクトのソースコードがバージョン管理下にあるということは、
+ プロジェクトのソースコードがバージョン管理されているということは、
ほとんどの決定が元に戻せるということを意味します。
変更を元に戻す原因としてよくあるのが、
皆にとって良いものだと間違って思い込み、変更をコミットするというものですが、
- これは結局コミットした後に反対されることになります。
+ これは結局コミットした後に反対意見が出てくることになります。
こうした反対意見は決まって、
以前の議論を見逃したことを詫びることから始まりますが、
反対する人がメーリングリストのアーカイブにこれにあたる議論を見つけられなかった場合は省略されます。
@@ -630,8 +643,8 @@
議論中の事項と、既に実行されて効果が表れている決定事項の間には、
いくら技術的に元に戻せるとはいっても精神的な差があります。
開発者達は勢いが行動に繋がるといつも思っていますし、
- はじめに変更するのをやめさせることより、
- 行われた変更を元に戻すことの方がちょっと気が進まないでしょう。
+ 実際に行われた変更を元に戻すのは、
+ はじめに変更するのをやめさせるほど、気が進まないものです。
ある開発者がこの事実を悪用し、議論が必要かもしれない変更を急いでコミットする場合、
他の開発者達は文句を言えますし、言うべきです。
そして事態が好転するまで、より厳しい基準をその開発者に守らせるべきでしょう。
@@ -874,10 +887,11 @@
<para>
プロジェクトによっては、
<firstterm>拒否権</firstterm> として知られる特別な投票権を許しています。
- 拒否権は性急、または思いつきで行われた変更で、
+ 拒否権は性急に、または思いつきで行われた変更で、
少なくとも皆でもっと議論する時間が必要な場合に、
開発者がそれをやめさせる手段になります。
- 拒否権は、とても強い反対と、議事の進行を妨害することの中間に位置すると考えるとよいでしょう。
+ 拒否権は、とても強い反対と、
+ 議事の進行を妨害することの中間に位置すると考えるとよいでしょう。
正確な意味はプロジェクトによって異なります。
プロジェクトによっては拒否権を無効にするのがとても難しいところもありますし、
おそらくは、
@@ -909,7 +923,7 @@
そして誰かが拒否権を多く行使し続けている場合に、
丁寧にそれを指摘することによって拒否権の濫用を防ぐことができます。
必要とあらば、開発者たちが拒否権に拘束力があると長期に渡って賛同している場合にだけ、
- 拒否権に拘束力を持たせるように求めることもできます —
+ 拒否権に拘束力を持たせるよう求めることもできます —
結局は、明らかに大多数の開発者が X を望んでいる場合は、
その X が将来何かにつけ発生するでしょうから。
その場合は、拒否権を行使している開発者がそれを取り下げるか、
@@ -935,10 +949,10 @@
これについては <ulink url="http://www.apache.org/foundation/voting.html"/>
に説明があります。
Apache プロジェクトの基準は他のプロジェクトにも広まっているので、
オープンソース界の多くの場所で、
- 彼らの規約が程度を変えて使われているのを見ることになるでしょう。
+ 彼らの規約が形を変えて使われているのを見ることになるでしょう。
技術的には、Apache プロジェクトの基準に照らしても、
- "-1" という表現が必ずしも正式に拒否権を行使していることを示すわけではありません。
- しかし、非公式には拒否権の発動、
+ "-1" という表現が正式に拒否権を行使していることを必ずしも表すわけではありません。
+ しかし、非公式には拒否権を行使している、
もしくは少なくとも強い反対の意志を示していると普通は受け取られます。
</para>
@@ -952,11 +966,11 @@
-->
<para>
- 投票のように、拒否権の効果は遡って適用できます。
+ 投票と同じく、拒否権の効果は遡って適用できます。
疑問が持たれている変更が既にコミットされている、
もしくはアクションが既に起こされているという理由で、
（既にプレスリリースが出ている場合のように、
- 取り返しが付かないものでなければ） 拒否権に対して異議を唱えるのはよくありません。
+ 取り返しが付かないものでなければ） 拒否権に対して異を唱えるのはよくありません。
言いかえれば、何週間、何ヶ月もたったあとに拒否権が行使されても、
それが真面目に取り上げられる可能性は少ないですし、
真面目に取り上げるべきでもありません。
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
