Author: mumumu
Date: Sun Sep 30 10:37:31 2007
New Revision: 1227
Log:
- "Writing It All Down" Complete
- Chapter 4. Complete.
Modified:
trunk/ja/ch04.xml
Modified: trunk/ja/ch04.xml
==============================================================================
--- trunk/ja/ch04.xml (original)
+++ trunk/ja/ch04.xml Sun Sep 30 10:37:31 2007
@@ -1309,12 +1309,13 @@
<para>
ガイドラインに盛りこむ内容を決めるよい方法は、初心者がよく尋ねる質問や、
経験豊富な開発者がよくこぼす不満に関する文書を基にすることです。
- これは必ずしも FAQ を基にすべきというわけではありません—
+ これは必ずしも FAQ を基にすべきというわけではありません —
ガイドラインは、FAQ よりわかりやすい物語風の構造が必要になるでしょうが、
- FAQ と同じく、将来起こりうる問題よりも、
+ FAQ と同様、将来起こりうる問題よりも、
実際に起こった問題に取り組むという現実的な原則に従うべきです。
</para>
+<!--
<para>If the project is a benevolent dictatorship, or has officers
endowed with special powers (president, chair, whatever), then the
document is also a good opportunity to codify succession procedures.
@@ -1328,7 +1329,21 @@
lists <emphasis>before</emphasis> writing about it. People can
sometimes be touchy about hierarchical structures, so the subject
needs to be approached with sensitivity.</para>
+-->
+
+<para>
+ プロジェクトに優しい独裁者や、特別な才能に恵まれた幹部（社長とか議長とか、そういったものです）がいる場合は、
+ 引継ぎの手続きを明文化する良い機会になります。
+ 何らかの理由で優しい独裁者がプロジェクトから突然去る場合は、
+ 特定の人を後継者として単に指名すればいいだけの場合もあります。
+ 一般的には、優しい独裁者がいる場合、彼だけが後継者を指名することができます。
+ 投票で選ばれた幹部がいる場合は、彼らを選ぶのに候補者を選び、
+ 投票する手続きを踏む手続きがはじめに行われたことを文書に記録すべきです。
+ そうした手続きがもともとなかった場合は、文書に手続きを明文化する <emphasis>前に</emphasis>
メーリングリスト上で手続きに関する合意を得るようにします。
+ 階層的な支配構造に神経質な態度をとる人もいるので、こうした話題を扱うときは気を使う必要があります。
+</para>
+<!--
<para>Perhaps the most important thing is to make it clear that the
rules can be reconsidered. If the conventions described in the
document start to hamper the project, remind everyone that it is
@@ -1341,7 +1356,23 @@
that something needs to change. If no one else agrees, then the
person won't get much response, and the rules will stay as they
are.</para>
+-->
+<para>
+ こうしたルールは見直すことができる、というのを明示しておくことが多分一番重要です。
+ たとえ文書に記録された規約がプロジェクトを妨害しはじめたとしても、
+ その文書が開発者グループの意図を強く反映したもので、
+ プロジェクトへの不満や障害の源ではない、ということを周知しておきましょう。
+ 規約が自分の邪魔をするたびに見直しを求める人がいる場合は、
+ その人と議論する必要は必ずしもありません。—
+ 無視しておくことが最良の選択となることもあります。
+ 規約に不満があることで一致している人が他にいるなら、彼らが同調するでしょう。
+ それは何かを見直すべきことをあらわしています。
+ 誰も同調しなければ、見直しを求める人に返答する人はいなくなるでしょう。
+ そして規約は以前の状態のまま残るのです。
+</para>
+
+<!--
<para>Two good examples of project guidelines are the Subversion
<filename>hacking.html</filename> file, at <ulink
url="http://svn.collab.net/repos/svn/trunk/www/hacking.html"/>, and the Apache
@@ -1353,6 +1384,19 @@
procedures more than development conventions. They're still worth
reading, though, because they represent the accumulated experience of
a lot of open source projects.</para>
+-->
+
+<para>
+ プロジェクトの開発者向けガイドラインの良い例がふたつあります。
+ ひとつは <ulink url="http://svn.collab.net/repos/svn/trunk/www/hacking.html"/>
にある、Subversion の <filename>hacking.html</filename> ファイルがあります。
+ もうひとつは、<ulink url="http://www.apache.org/foundation/how-it-works.html"/> と
<ulink url="http://www.apache.org/foundation/voting.html"/> にある、Apache Software
Foundation の統治に関する文書です。
+ Apache Software Foundation は実際はソフトウェアプロジェクトの集合体ですが、
+ 非営利組織として合法的に組織されています。
+ よって彼らの文書には、開発する際の規約よりも、
+ プロジェクトを統治する際の手続きについて多く記述されています。
+ ですが、まだ読む価値は大いにあります。
+ なぜなら、それはたくさんのオープンソースプロジェクトの経験を集積した文書だからです。
+</para>
</sect1>
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
