Author: mumumu
Date: Sat Sep 15 13:17:08 2007
New Revision: 1175

Log:
- translated part of "Consensus-based Democracy" Introduction.


Modified:
   trunk/ja/ch04.xml

Modified: trunk/ja/ch04.xml
==============================================================================
--- trunk/ja/ch04.xml   (original)
+++ trunk/ja/ch04.xml   Sat Sep 15 13:17:08 2007
@@ -168,7 +168,7 @@
     全員がひとりのリーダーに従うこと(もっとも有名な例が、Linux kernel 開発の Linus Torvalds です。)もあるかもしれませんが、
     これは 完全にひねくれているわけでもなく、悪意があるわけでもなく、彼らがそうすることを <emphasis>選んでいる</emphasis> 
からです。
     独裁者がプロジェクトを魔法のように支配しているわけではないのです。
-    オープンソースライセンス全てに当てはまる、鍵となる性質は、
+    全てのオープンソースライセンス当てはまる、鍵となる性質は、
     コードの変更のしかたや、使用方法について、特定の集団を差別しないということです。
     仮に独裁者が突然よくない決断をしはじめたとしましょう。
     その場合不穏な空気が漂い、結局反乱が起きてコードが派生してしまいます。
@@ -296,7 +296,7 @@
     受け入れる能力も必要になるのです。&mdash;
     ですが、この資質は優れた開発者であれば、特にプロジェクトに長い間留まっている人であればなおさら <emphasis>誰でも</emphasis> 
持っているはずの資質にすぎません。
     しかし、優しい独裁者が違う点は、
-    自分の信頼に長い間傷が付いてしまうんじゃないかと心配することなく、
+    自分の信頼に長い間傷が付いてしまうんじゃないかと恐れることなく、
     たびたび間違いを犯す余裕があることです。
     年季が入っていない開発者は、自分が保護されていないと感じているかもしれません。
     だからこそ優しい独裁者は、
@@ -395,7 +395,7 @@
 <para>
     プロジェクトに優しい独裁者がいるべきか、
     中央集権をいくらか緩めた仕組みの方がうまくいくかどうかは、
-    役割を果たす人達がどれだけいるかに依存します。
+    役割を果たす人達がどれだけいるかにかかっています。
     一般的なルールとして、単に優しい独裁者に誰がなってもいいことが明らかな場合は、
     そうするとよいでしょう。しかし、誰もなり手がいないのが明らかな場合は、
     次の節で述べるような分権的な決定プロセスを使うべきでしょう。
@@ -407,6 +407,7 @@
 <sect1 id="consensus-democracy">
 <title>合意に基づく民主主義</title>
 
+<!--
 <para>As projects get older, they tend to move away from the
 benevolent dictatorship model and toward more openly democratic
 systems.  This is not necessarily out of dissatisfaction with a
@@ -426,11 +427,42 @@
 the BD.  Therefore, once a project has moved from leadership by a
 charismatic individual to a more formal, group-based system, it rarely
 moves back.</para>
+-->
+
+<para>
+    プロジェクトが続いていくと、プロジェクトは優しい独裁者モデルから離れ、
+    より開かれた民主主義的なプロセスに移行します。
+    これは特定の優しい独裁者に必ずしも満足していないわけではありません。
+    単にグループ主体の統治の方が、生物学のメタファーを借りて言えば "進化的に安定している" からです。
+    優しい独裁者が身を引いたり、決定を下す権限を多くの人に平等に与えようとするときはいつでも、
+    グループが新しい、独裁的でない仕組みに移行する機会になります &mdash;
+    これは言ってみれば組織化を行うということです。
+    開発者のグループははじめの1、2回はこの機会を利用しませんが、
+    結局は利用することになります。いったんそうしてしまえば、
+    もとの仕組みに戻ることはありません。このことは常識でわかることです。
+    仮に N人 からなるグループがある人に特別な権限を与えていると仮定すると、
+    N&nbsp;-&nbsp;1 人が自分の影響力を弱めることに合意していることになります。
+    独裁的でない仕組みでは、人々は普通特別な権限を欲しいとは思いません。
+    たとえ望んだとしても、結果として行使できる権力は条件付きのものになります。
+    優しい独裁者を任命しても、これは明らかなことですが、
+    グループが後に辞めさせてしまうことができるからです。
+    それゆえに、プロジェクトがいったんカリスマ的な人のリーダーシップをとる仕組みから、
+    より型にはまったグループベースの仕組みに移行すれば、滅多に元に戻ることはないのです。
+</para>
 
+<!--
 <para>The details of how these systems work vary widely, but there are
 two common elements: one, the group works by consensus most of the
 time; two, there is a formal voting mechanism to fall back on when
 consensus cannot be reached.</para>
+-->
+
+<para>
+    こうした仕組みをどう機能させるかの詳細は変化に富んでいますが、
+    共通した要素が二つあります。
+    ひとつは、グループはほとんどいつも合意に基づいて動くこと。
+    ふたつめは、合意に達しないときに投票の仕組みを使うことです。
+</para>
 
 <para><firstterm>Consensus</firstterm> merely means an agreement that
 everyone is willing to live with.  It is not an ambiguous state: a

_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators

Reply via email to