Author: mumumu
Date: Sat Sep 15 16:06:18 2007
New Revision: 1180
Log:
- minor fix
Modified:
trunk/ja/ch04.xml
Modified: trunk/ja/ch04.xml
==============================================================================
--- trunk/ja/ch04.xml (original)
+++ trunk/ja/ch04.xml Sat Sep 15 16:06:18 2007
@@ -437,7 +437,7 @@
優しい独裁者が身を引いたり、決定を下す権限を多くの人に平等に与えようとするときはいつでも、
グループが新しい、独裁的でない仕組みに移行する機会になります —
これは言ってみれば組織化を行うということです。
- 開発者のグループははじめの1、2回はこの機会を利用しませんが、
+ 開発者のグループは最初の1、2回はこの機会を利用しませんが、
結局は利用することになります。いったんそうしてしまえば、
もとの仕組みに戻ることはありません。このことは常識でわかることです。
仮に N人 からなるグループがある人に特別な権限を与えていると仮定すると、
@@ -482,7 +482,7 @@
合意に達したんじゃないかと提案する人は、
合意とは何かということと、
仮に明らかでない場合は、
- 合意の結果どのような行動がとられるのかについて具体的に述べるべきです。
+ 合意の結果どのような行動がとられるのかを具体的に述べるべきです。
</para>
<!--
@@ -501,8 +501,8 @@
<para>
プロジェクトで交わされるほとんどの会話は技術的な話題です。
たとえば、バグを直す正しい方法に関するものとか、
- ある機能を追加すべきかしないべきかとか、
- プログラムのインターフェイスをどの程度厳密に文書化すべきか、などといったものです。
+ ある機能を追加するか、しないか、
+ プログラムのインターフェイスをどの程度厳密に文書化するか、などといったものです。
合意を基本とした統治は、技術的な議論そのものとよく合うのでうまくいきます。
議論が終わるまでに、どの方向性を採るかに関して合意がよく成立します。
通常は議論を終了するという投稿をし、
@@ -535,8 +535,8 @@
彼はただ修正をコミットしただけですし、
他の開発者はわざわざ同意すると口に出して言ったりしません。
なぜなら黙っていることは合意することだからです。
- 誰かがコミットした修正が、合意を得られないと判明した場合、
- まだそれがコミットされていないかのようにプロジェクトでは議論されるだけです。
+ コミットされた修正が、合意を得られないと判明した場合、
+ プロジェクトでは単にまだそれがコミットされていないかのように議論されます。
このやり方がうまく行く理由は次の節で述べていきます。
</para>
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
