プロジェクトの規約や合意の数が多くなり過ぎるために、 ある時点でどこかに記録しておく必要が生じます。 記録を正統なものにするためには、 メーリングリストでの議論や既に有効になっている合意をベースにしていることを明示するようにしましょう。 実際に記録するときは、 メーリングリストのアーカイブにある関連したスレッドを参照するようにし、 不明な点があるときにはもう一度尋ねるようにしましょう。 記録した文書には人々を驚かせるようなことを書くべきではありません。 なぜなら、その文書は合意の根拠ではなく、合意の中身を説明したものに過ぎないからです。 もちろん、成功すればそれを権威あるものとして人々が引用しはじめるかもしれませんが、 それはその文書がプロジェクトの総意を正確に反映しているだけに過ぎません。

これが 2章さあ始めましょう の 「開発者向けのガイドライン」 で述べた文書になります。 当然、プロジェクトが若いうちは、 長く続いているプロジェクトの歴史のような、 ためになる話抜きでガイドラインを書かねばならないでしょう。 しかしプロジェクトが成長するにつれ、 明らかになってきた事柄を反映させた形で、文書を改訂することができます。

文書を包括的なものにするのはやめましょう。 どんな文書でも、プロジェクトに参加するのに必要なことを全て網羅することはできません。 プロジェクトで生まれる多くの規約は、ずっと暗黙のもので、 決して明示的に言及されることがないにもかかわらず、 メンバー全員がかたくなに守っているものなのです。 単に当り前過ぎるので言及されないものもありますし、 重要だけど曖昧なのでただ避けているだけのものもあります。 たとえば、"メーリングリストでは礼儀正しくし、他人を尊重しましょう。 また、フレームウォーを始めてはいけません。" とか、 "綺麗で、読みやすくバグのないコードを書きましょう。" といったことをガイドラインに書いても意味がありません。 もちろん、これらは望ましいことではありますが、 これらが望ましくないと思われる世界は存在しないので、言及する価値がないのです。 メーリングリスト上で失礼な発言をしたり、バグだらけのコードを書いている人がいたとして、 彼らはプロジェクトのガイドラインにやめろと書いてあるからといってやめはしないでしょう。 こういう状況は包括的なガイドラインであらかじめ対処するものではなく、 問題が起きたときに対処すべきものなのです。 一方で、あるフォーマットですべてのAPIを文書化するルールのような よいコードの書き方に関するガイドラインがプロジェクトにある場合は、 できる限り完全なものを書いておくべきです。

ガイドラインに盛りこむ内容を決めるよい方法は、初心者がよく尋ねる質問や、 経験豊富な開発者がよくこぼす不満に関する文書を基にすることです。 これは必ずしも FAQ を基にすべきというわけではありません — ガイドラインは、FAQ よりわかりやすい物語風の構造が必要になるでしょうが、 FAQ と同様、将来起こりうる問題よりも、 実際に起こった問題に取り組むという現実的な原則に従うべきです。

プロジェクトに優しい独裁者や、特別な才能に恵まれた幹部（社長とか議長とか、そういったものです）がいる場合は、 引継ぎの手続きを明文化する良い機会になります。 何らかの理由で優しい独裁者がプロジェクトから突然去る場合は、 特定の人を後継者として単に指名すればいいだけの場合もあります。 一般的には、優しい独裁者がいる場合、彼だけが後継者を指名することができます。 投票で選ばれた幹部がいる場合は、彼らを選ぶのに候補者を選び、 投票する手続きを踏む手続きがはじめに行われたことを文書に記録すべきです。 そうした手続きがもともとなかった場合は、文書に手続きを明文化する 前に メーリングリスト上で手続きに関する合意を得るようにします。 階層的な支配構造に神経質な態度をとる人もいるので、こうした話題を扱うときは気を使う必要があります。

こうしたルールは見直すことができる、というのを明示しておくことが多分一番重要です。 たとえ文書に記録された規約がプロジェクトを妨害しはじめたとしても、 その文書が開発者グループの意図を強く反映したもので、 プロジェクトへの不満や障害の源ではない、ということを周知しておきましょう。 規約が自分の邪魔をするたびに見直しを求める人がいる場合は、 その人と議論する必要は必ずしもありません。— 無視しておくことが最良の選択となることもあります。 規約に不満があることで一致している人が他にいるなら、彼らが同調するでしょう。 それは何かを見直すべきことをあらわしています。 誰も同調しなければ、見直しを求める人に返答する人はいなくなるでしょう。 そして規約は以前の状態のまま残るのです。

開発者向けガイドラインの良い例がふたつあります。 ひとつは http://subversion.apache.org/docs/community-guide/ にある、Subversion Cummunity Guide です。 もうひとつは、http://www.apache.org/foundation/how-it-works.html と http://www.apache.org/foundation/voting.html にある、Apache Software Foundation の統治に関する文書です。 Apache Software Foundation は実際はソフトウェアプロジェクトの集合体ですが、 非営利組織として合法的に組織されています。 よって彼らの文書には、開発する際の規約よりも、 プロジェクトを統治する際の手続きについて多く記述されています。 ですが、まだ読む価値は大いにあります。 なぜなら、それはたくさんのオープンソースプロジェクトの経験を集積した文書だからです。