Author: mumumu
Date: Sat Aug 9 18:46:57 2008
New Revision: 1484
Log:
- translated "Money Can't Buy You Love" section.
Modified:
trunk/ja/ch05.xml
Modified: trunk/ja/ch05.xml
==============================================================================
--- trunk/ja/ch05.xml (original)
+++ trunk/ja/ch05.xml Sat Aug 9 18:46:57 2008
@@ -802,7 +802,7 @@
顧客から自分のことを秘密にしてほしいと頼まれることもありますが、
その場合は匿名で事例を紹介させてもらえるかどうかを少なくとも聞くようにします。
開発コミュニティがあなたがやりたいことの <emphasis>動機</emphasis> を知れば知るほど、
- あなたが何を提案しても違和感がより少なくなります。
+ あなたが何を提案しても違和感が少なくなります。
</para>
<!--
@@ -831,7 +831,7 @@
仮に望むことだけを主張して、その理由となる具体例を述べなければ、
その主張は弱くなってしまいますし、隠れた意図があるのではないかと疑われてしまいます。
しかし、現実世界のシナリオを 2,3 述べ、提案している新機能がなぜ重要なのかを示すだけで、
- 議論する上で劇的な効果があるのです。
+ 議論する上で劇的な効果があります。
</para>
<!--
@@ -879,7 +879,7 @@
<para>
大量の顧客データを持つ組織として、あなたにはそういった議論を止めるチャンスがあります。
他の人が開発コミュニティに伝えることができない情報へのパイプ役になれるのです。
- あなたが望むことをを支えている情報は恥ずかしいものでも何でもないのです。
+ あなたが望むことの根拠になる情報は恥ずかしいものでも何でもないのです。
ほとんどの開発者は自分が書いたソフトウェアがどのように使われているのかについて、
広い見聞を持っているわけではありません。開発者はめいめいが、
自分独自のやり方でソフトウェアを使っているのです。そして他の使い方については、
@@ -1018,8 +1018,9 @@
<!-- ======================== subsection ============================== -->
<sect1 id="money-vs-love">
-<title>Money Can't Buy You Love</title>
+<title>カネで愛は買えない</title>
+<!--
<para>If you're a paid developer on a project, then set guidelines
early on about what the money can and cannot buy. This does not mean
you need to post twice a day to the mailing lists reiterating your
@@ -1028,7 +1029,19 @@
<emphasis>could</emphasis> be created by money. You don't need to
start out assuming that the tensions are there; you do need to
demonstrate an awareness that they have the potential to arise.</para>
+-->
+
+<para>
+ あなたがカネを貰って雇われている開発者なら、
+ カネで買えるものと買えないものに関する基準を早い段階から設定するようにしましょう。
+ これは、あなたの気高くて侵し得ない性分について、
+ 1日に2回はメーリングリストに繰り返し投稿することではありません。
+ カネが作り出す <emphasis>可能性がある</emphasis> 葛藤を鎮める機会を探っておくべき、
+ というだけです。そういった葛藤が既にあるものとして考える必要はありませんが、
+ カネによってそういうことが起きるかもしれない、ということを認識しておく必要はあります。
+</para>
+<!--
<para>A perfect example of this came up in the Subversion project.
Subversion was started in 2000 by <ulink
url="http://www.collab.net/";>CollabNet</ulink>, which has been the
@@ -1038,7 +1051,19 @@
effort. By then, coding had already started. Although Subversion was
still very much in the early stages, it already had a development
community with a set of basic ground rules.</para>
+-->
+
+<para>
+ そういった葛藤の良い例が Subversion プロジェクトで起こりました。
+ Subversion は、プロジェクト開始時からのカネを出していて、
+ 何人かの開発者 (お断り: 筆者もそのうちのひとりです) に給料を支払っていた <ulink
url="http://www.collab.net/";>CollabNet</ulink> が始めたものです。
+ プロジェクトが始まってすぐ、CollabNet は Mike Pilato という別の開発者を雇いました。
+ 彼を雇うまでに、コーディングは既に始まっていました。
+ Subversion はまだ開発の初期段階でしたが、
+ 既に基本的なルールを備えた開発コミュニティが出来上がっていたのです。
+</para>
+<!--
<para>Mike's arrival raised an interesting question. Subversion
already had a policy about how a new developer gets commit access.
First, he submits some patches to the development mailing list. After
@@ -1048,7 +1073,22 @@
linkend="committers"/>). Assuming the committers agree, one of
them mails the new developer and offers him direct commit access to
the project's repository.</para>
+-->
+
+<para>
+ Mike を雇うことで、面白い疑問が出てきました。
+ Subversion プロジェクトには、
+ 新しい開発者にコミット権限をどうやって与えるかに関するルールが既にありました。
+ まず、彼は開発用メーリングリストに修正プログラムをいくつか投稿しました。
+ 十分な量の修正が彼の修正プログラムによって行われ、他のコミッタ達は、
+ 彼が自分がしていることをよく理解していることを知りました。
+ その後、Mikeは直接コミットしたらいいじゃないかと提案した人がいました(<xref linkend="committers"/>
で説明していますが、
+ この提案は非公式なものでした)。
+ そして提案をした人の一人が彼にメールを送り、既にいるコミッタ達が同意するものと見做して、
+ プロジェクトリポジトリへのコミット権限を与えたのです。
+</para>
+<!--
<para>CollabNet had hired Mike specifically to work on Subversion.
Among those who already knew him, there was no doubt about his coding
skills or his readiness to work on the project. Furthermore, the
@@ -1062,7 +1102,25 @@
the non-salaried developers feeling disenfranchised. Other people
have to earn their commit access—CollabNet just buys
it.</para>
+-->
+
+<para>
+ CollabNet は Subversion プロジェクトで専ら働いてもらうために Mike を雇いました。
+ 彼を知っている人達のうち、
+ 彼のコーディング技術やプロジェクトですぐに働けるかどうかについて疑う人は誰もいませんでした。
+ それに、ボランティアの開発者は CollabNet に雇われている開発者達ととても良い関係を築いていて、
+ CollabNet が彼を雇った段階でコミット権限を与えてもほとんどの人は多分反対しなかったでしょう。
+ しかし、CollabNet はそうすることで悪しき前例を作ってしまうことを知っていました。
+ 仮に Mike に CollabNet が独断でコミット権限を与えてしまうと、
+ CollabNet はプロジェクトに一番カネを出しているという理由だけで、
+ プロジェクトが設定したガイドラインを無視する権利があると宣言することになってしまいます。
+ それによる影響はすぐには顕在化しないでしょうが、
+ カネを貰っていない開発者がコミッタを選ぶ権利を奪われたと感じてしまう事態が徐々に出てくるでしょう。
+ CollabNet に雇われていない人がコミット権限を得るには、
+ カネでそれを買わねばならならないのです — つまり、CollabNet はコミット権限を買っているだけなのです。
+</para>
+<!--
<para>So Mike agreed to start out his employment at CollabNet like any
other volunteer developer, without commit access. He sent patches to
the public mailing list, where they could be, and were, reviewed by
@@ -1071,6 +1129,21 @@
of weeks of solid activity by Mike, someone (I can't remember if it
was a CollabNet developer or not) proposed him for commit access, and
he was accepted, as we knew he would be.</para>
+-->
+
+<para>
+ こうした理由から、Mike は 他のボランティアの開発者と同様に、
+ コミット権限がない状態で CollabNet での仕事を始めることに同意しました。
+ 彼は公のメーリングリストに修正プログラムを送り、
+ それはプロジェクトのメンバ全員でレビューできる状態にありましたし、
+ また現にレビューされました。
+ CollabNet は メーリングリスト上で、
+ Mike を雇ったにも関わらず わざと コミット権限を与えていないと宣言したので、
+ 行き違いが起こることはありませんでした。Mike は数週間堅実に働き、
+ 誰かが彼にコミット権限を与えてはどうかと提案し、それは受け入れられました。
+ これは受け入れられるとわかっていたことです。
+ (提案した人が CollabNet が雇った開発者だったかどうか筆者は覚えていません)
+</para>
<!--
@@ -1124,6 +1197,7 @@
Added Mark Murphy, Bill Tutt, C. Michael Pilato.
-->
+<!--
<para>That kind of consistency gets you a credibility that money could
never buy. And credibility is a valuable currency to have in
technical discussions: it's immunization against having one's motives
@@ -1133,7 +1207,22 @@
directions the project takes, presents a wider target than most. By
being scrupulous to observe all project guidelines right from the
start, the funder makes itself the same size as everyone else.</para>
+-->
+
+<para>
+ こうした方針を一貫して守ることで、カネでは買えないことがある、
+ ということを人々は信じるようになります。こういう点で信用されることは、
+ 技術的な議論をしているときでも通用する価値があります。
+ つまり、あとで蒸し返されることを防ぐことにもなるのです。
+ 議論が白熱してくると、人は技術的でない点で議論に勝つ方法を探すようになります。
+ プロジェクトに一番カネを出している人は、プロジェクトに深く関わり、
+ プロジェクトが採る方向性について深い関心があるだけに、
+ ほとんどの人から格好の攻撃の対象とされます。
+ プロジェクトを始めてすぐの段階からガイドラインを実直に守ることで、
+ カネを出す人は自分自身を他と同列に扱っているのです。
+</para>
+<!--
<para>(See also Danese Cooper's blog at
<ulink url="http://blogs.sun.com/roller/page/DaneseCooper/20040916"/>
for a similar story about commit access. Cooper was then Sun
@@ -1141,7 +1230,18 @@
title—and in the blog entry, she describes how the Tomcat
development community got Sun to hold its own developers to the same
commit-access standards as the non-Sun developers.)</para>
+-->
+
+<para>
+ (コミット権限に関する似たような話として、Danese Cooper のブログを見るとよいでしょう。
+ <ulink url="http://blogs.sun.com/roller/page/DaneseCooper/20040916"/>
+ Cooper は そのとき サン・マイクロシステムズ の "オープンソースの部署" にいました —
+ 私はそれが彼女の公の肩書きだと思っていました — このブログエントリでは、
+ Tomcat の開発コミュニティが、どのようにして自分たちと同じコミット権限に関する基準を
+ サン・マイクロシステムズ に守らせたかについて説明しています。)
+</para>
+<!--
<para>The need for the funders to play by the same rules as everyone
else means that the Benevolent Dictatorship governance model (see
<xref linkend="benevolent-dictator"/><phrase output="printed">
@@ -1157,6 +1257,21 @@
governance sitting in your back pocket, ready to be brought out the
moment there are any indications of widespread dissatisfaction in the
community.</para>
+-->
+
+<para>
+ プロジェクトの創始者が、他の人と同じルールを守る必要があることは、
+ 誰かがお金を出す場合に優しい独裁者モデル(<phrase output="printed"><xref
linkend="social-infrastructure"/>
+ の</phrase> <xref linkend="benevolent-dictator"/> を参照してください)
+ がちょっとうまくいきにくいことを意味しています。
+ 優しい独裁者がプロジェクトの創始者である場合は特にそうでしょう。
+ 独裁にはルールがほとんどないので、たとえ実際に守っていたとしても、
+ プロジェクトの創始者がコミュニティのルールを守っていると証明することは困難です。
+ 必ずしも不可能ではありませんが。それには、外部の開発者と同じ視点から物事を見ることができ、
+ 適切に行動できる人で、かつカネを出せる人がプロジェクトリーダーになる必要があります。
+ その場合でも、コミュニティで不満が広がる兆しが明るみに出てしまう場合に備えて、
+ 独裁的ではないやり方で提案をするのはよい考えです。
+</para>
</sect1>
_______________________________________________
Producingoss-translators mailing list
Producingoss-translators@red-bean.com
http://www.red-bean.com/mailman/listinfo/producingoss-translators
