技術的な問題
フリーソフトウェアプロジェクトを運営していくには、
さまざまな情報を取捨選択する技術が必要です。
これらの技術を使いこなせばこなすほど、また周りの人に使わせれば使わせるほど、
プロジェクトがうまくいく可能性が高くなります。
プロジェクトの規模が大きくなればなるほど、この傾向は強まります。
うまく情報を管理しないと、オープンソースプロジェクトは
ブルックスの法則
1975 年に出版された彼の著書 The Mythical Man Month
(邦題:「人月の神話」) に登場した法則。
および
(
日本語) を参照してください。
(プロジェクトの終盤になってから人を増やしたところで、
かえってプロジェクトの完成が遅れてしまう) の罠に陥ってしまいます。
Fred Brooks は、プロジェクトの複雑度はそれにかかわる関係者の数の
２乗に比例するとしています。
メンバーの数がほんの数人の時は、簡単にお互いの意思疎通ができます。
しかしメンバーが数百人規模に膨れ上がると、
もはや他のメンバーが何をしているのかをすべて把握することは不可能です。
フリーソフトウェアプロジェクトを管理する秘訣は、
お互いがまるでひとつの部屋に集まってともに働いているかのように感じさせることだといいます。
では、もし混雑した部屋に詰め込まれたメンバーがみんないっせいに話し始めたら、
どんなことになるでしょう?
これは、特に目新しい問題ではありません。
たとえ話ではない実際の混雑した部屋では、このような場合の解決法は
議会制、つまり大人数の集団で議論を行う際の手順を決めることです。
重要な異議が「異議なし!」の大合唱にかき消されてしまわないようにしたり、
いくつかの小委員会を構成したり、議決方法を定義したりといったことです。
この制度で重要なのは、その集団が情報管理システムをどのように利用するかというところです。
"正式に記録される" 情報もあれば、そうでないものもあります。
記録自体は方向性を決めるためのものです。
「何が起こったのか」を単に書き記したものではなく、
その集団で何を 合意 しようとしているのかを表すものと考えます。
記録は、目的によってさまざまな形式で行います。
個別の打ち合わせの議事録、すべての打ち合わせの議事録をまとめたもの、
その概要、議題、コメント、委員会の報告書、
その場にいない通信員からの報告、宿題の一覧などが記録に含まれます。
インターネットは実際の部屋とは異なるので、
「誰かが発言しているときは他のメンバーは静かにそれを聴く」
というようなしきたりにこだわる必要はありません。情報管理技術を駆使すると、
オープンソースプロジェクトにおける議論の手順はより効率的になります。
オープンソースプロジェクトでは、ほぼすべてのやりとりは文字によって行われます。
そこで、情報を振り分けたり適切なラベル付けをしたりするためのシステムが発達してきました。
繰り返しを最小限に抑えて間違った方向に進みにくいようにしたり、
データを保存して検索しやすくしたり、
間違った情報や古びた情報を訂正したり、
あちこちに散らばった情報をまとめてそれらのつながりを見出したりといった作業のためのシステムです。
オープンソースプロジェクトに積極的にかかわっている人たちは、
これらのテクニックを自然に身に着けており、
情報が正しくいきわたるように複雑な手作業を行っていることもあります。
しかし、プロジェクト全体で考えると、これらの作業にはソフトウェアのサポートが必要です。
可能な限り、通信に使用するメディア自身が
振り分けやラベル付け、内容の保存といった作業を行うべきです。
そして、その情報は、人間が見やすい形式で利用可能にしておかなければなりません。
もちろん、現実的にはまだそこまで全自動化されているわけではなく、
途中で何らかの人手が必要となるでしょう。
しかし一般論として、人間側で振り分けやラベル付けのための情報を一度提供したら、
あとはソフトウェア側でそのめたデータを最大限に活用できるようにすべきです。
本章でのアドバイスは、実用的なものばかりです。
どれも特定のソフトウェアやその使用例にもとづいたものです。
とはいえ、単に特定のテクニックを教えるだけというつもりはありません。
ちょっとした例をたくさんご覧いただくことで、
あなたのプロジェクトにおける情報管理をよりよくするための
一般的な方法を身につけていただくつもりです。
これには、技術的なスキルだけでなく社会的なスキルも含まれます。
技術的なスキルは必要不可欠です。というのも、
情報管理用のソフトウェアは常に何らかの設定が必要となるからです。
また、運用中にもある程度の保守作業が必要です
(たとえば、大きく成長したプロジェクトをどのように扱うかについて、
本章の後半 の
で取り上げています)。
また、社会的なスキルも必須です。なぜなら、
人間の集まりについても維持する必要があるからです。
さまざまなツールを使用して利益を受ける方法は、
すぐに明らかになるとは限りません。場合によってはその使用法をめぐって争いが起こるかもしれません
(例として、メーリングリストから配送されるメールの
Reply-to ヘッダの設定についての議論を
で取り上げています)。
プロジェクトに参加している人たちはみな、
そのプロジェクトの情報をうまく管理するための方法を必要としています。
プロジェクトに深くかかわればかかわるほど、
学ばねばならないテクニックは複雑で専門的なものになります。
情報管理には、月並みな解決策はありません。
考慮すべき点があまりにも多すぎるのです。
最終的に望みどおりの手段が見つかるかもしれません。
コミュニティーの参加者のほとんどもその方法を利用してくれるかもしれません。
しかし、プロジェクトがさらに成長したときに、
その方法がそのまま使えるとは限りません。
あるいは、プロジェクトの成長が安定し、
開発者とユーザーの両方が現在の情報管理技術に慣れてきたときに、
だれかがまったく新しい情報管理サービスを発明するかもしれません。
新しくプロジェクトに参加したメンバーはきっとこう言うでしょう。
「何であの便利なツールを使わないの?」
Wiki ( を参照してください)
が登場しだした頃に、当時のプロジェクトの多くでまさにこれと同じことが起こりました。
どのような手段を使用するかを決めるには、さまざまな判断材料があります。
たとえば、情報を提供する側と情報を利用する側のどちらの利便性を優先させるかも
判断材料のひとつとなるでしょう。あるいは、
情報管理ソフトウェアの設定の難易度と、
それがプロジェクトにもたらす利益とのトレードオフについても考える必要があります。
あまりになんでもかんでも自動化しすぎないようにしましょう。
実際、人手がかかわるべきところまで自動化してしまってはいけません。
技術的な仕組みは重要ではありますが、
フリーソフトウェアプロジェクトをうまく運営するために重要なのは、
結局のところ人への気配り—決しておしつけがましくない気配りなのです。
技術的な仕組みというのは、この気配りをうまく行うための手段に過ぎません。
プロジェクトに必要なもの
ほとんどのオープンソースプロジェクトは、
情報管理用のツールとして少なくとも以下のようなものを用意しています。
ウェブサイト
プロジェクトについての情報を、
管理者側から一般に向けて公開する場所です。
また、プロジェクトで使用するその他のツールについての
管理用インターフェイスもここで提供します。
メーリングリスト
通常は、そのプロジェクトにおける最も活発な議論の場となります。
また、議論の「記録媒体」としての意味合いもあります。
バージョン管理システム
開発者が、コードの変更点を追いかけやすくするものです。
変更内容を元に戻したり、他に移植したりすることもできます。
これを見ると、コードに何が起こっているのかを誰もが知ることができます。
バグ追跡システム
開発者が自分の作業内容を確認したり、
他の開発者と作業を調整したり、リリース時期の予定をたてたりするために用います。
特定のバグの状況や関連情報 (再現手順など)
について、誰もが調べられるようになります。
バグだけに限らず、やるべき作業やリリース時期、
新機能の追加などについてもここで扱うことがあります。
リアルタイムチャット
ちょっとした議論や質問のやり取りのための場です。
議論の内容がアーカイブされないこともあります。
ここであげたツールはどれも異なるニーズを満たすものではありますが、
その機能には相関性があります。また、
各種ツール群は協調して動作させなければなりません。これ以降では、
その方法について考えます。また、より重要なこととして、
メンバーにそれを使ってもらうためにはどうすればいいのかも説明します。
ウェブサイトについての議論は後回しにします。というのもウェブサイトは、
独立したツールというよりは
他のツールを組み合わせるための接着剤のようなものだからです。
どんなツールを選択しようかといった問題に悩まされたくないという場合は、
出来合いの ホスティング サイトを使用するといいでしょう。
たいていはパッケージ化されたウェブサイトのテンプレートが用意されており、
フリーソフトウェアプロジェクトの運営に必要なツールもひととおりそろっているはずです。
本章の後半の
で、
ホスティングサイトの利点と欠点を取り上げます。
メーリングリスト
メーリングリストは、プロジェクト内でのコミュニケーションに必要不可欠なものです。
ウェブページ以外にユーザーに見せるものがあるとすれば、
まず最初はそのプロジェクトのメーリングリストとなるでしょう。
しかし、メーリングリストに参加する前に、
ユーザーはまずそのメーリングリストのインターフェイス
(たとえば "メーリングリストに参加する" など)
に出会うことになります。
ここから、次の「メーリングリスト第一法則」が得られます。
メーリングリストの管理は、手作業で行うのではなく、
専用のソフトウェアを使用すること。
いきなりそんなことを言われても驚きますよね。
メーリングリストの管理用にわざわざソフトウェアをセットアップするなんて、
ちょっとやりすぎのように感じられるかもしれません。
小規模で流量の少ないメーリングリストは手動で管理するほうが楽に見えます。
参加申し込み用のアドレスをひとつ作成してそれをあなた宛てに転送されるようにしておき、
届いたメールの内容を見て、アドレス一覧 (おそらく単なるテキストファイル)
に追加したり削除したりするだけです。
これ以上にシンプルなやりかたなんてないでしょう?
みんなが満足するレベルでメーリングリストの管理を行うということは、
思っているほど簡単なことではありません。
メーリングリストの管理というのは、
単にユーザーを登録したり削除したりするだけの話ではありません。
スパムよけのために投稿内容をモデレートするようにしたり、
複数の投稿をひとまとめにした形式でメールを配信するようにしたり、
メーリングリストやプロジェクトに関する情報を自動返信するようにしたり
といったさまざまな内容があります。
参加用のアドレスを人手でチェックするというだけでは、
最小限の機能しか提供することができません。
そしてその最小限の機能でさえ、ソフトウェアに任せるのに比べると
信頼性や即時性に欠けるものとなるでしょう。
いまどきのメーリングリスト管理用ソフトウェアなら、
少なくとも次のような機能が搭載されているはずです。
メールおよびウェブの両方からの参加受付
ユーザーがメーリングリストへの参加を申し込むと、
すぐに自動返信のメッセージを受け取ります。
そこには、参加しようとしているメーリングリストの情報や
メーリングリストソフトウェアへの指示の出し方、そして
(最も重要な項目として) リストからの退会のしかたなどが書かれています。
この自動返信の内容はカスタマイズすることが可能です。
ここにはプロジェクトのウェブサイトや
FAQ の場所といった情報を含めることができます。
一通ごとの配信かまとめての配信かの選択
ダイジェストモード (「まとめて配信」モード)
にすると、参加者が受け取るメールは１日に１通となります。
その日に投稿されたすべてのメールの内容が１通にまとめて送信されるわけです。
積極的に参加するわけではないが、
大まかな話の流れは追いかけておきたいといった人たちには
ダイジェストモードがお勧めです。
これを使用すると、頻繁にやってくるメールに気を散らされることなく
その日のメールの内容をゆっくり見渡せるからです。
モデレート機能
「モデレート」とは、
投稿の内容をいったんチェックし、
a) スパムでないこと、そして
b) メーリングリストで扱うのにふさわしい内容であること
を確認してから一般向けに配信する作業のことです。
モデレート処理は、必ずしも人間が行わなければならないというものではありません。
ソフトウェアに任せることで、より簡単に行えるようになります。
モデレートについては、後でもういちど取り上げます。
管理者用インターフェイス
これは特に、使われなくなったアドレスを簡単に削除するために有用です。
メーリングリストの参加者のアドレスから
「このアドレスはもう存在しません」といった自動返信メッセージが毎回届くようになったら、
即刻対応しなければなりません
(メーリングリストソフトウェアによっては、
これを自動検出して該当者を自動的にメンバーから外すようにできるものもあります)。
ヘッダの操作
多くの人は、メールソフトの仕分け機能などを活用していることでしょう。
メーリングリストソフトウェアを使用すると、
特定のヘッダをメールに付加することで
これらの機能を使いやすいようにします
(詳細は後で説明します)。
アーカイブ処理
メーリングリストへのすべての投稿は、
保存されたうえでウェブから閲覧可能になります。
あるいは、メーリングリストソフトウェアによっては
MHonArc ()
のような外部のアーカイブツールへのプラグインインターフェイスを持っているものもあります。
の で説明するように、
アーカイブは重要な作業です。
このようにひとつひとつ挙げてみると、
メーリングリストの管理というものが思いのほか複雑な作業であることがお分かりでしょう。
そして、それらの作業の多くがソフトウェアで自動化できることもわかります。
決してこれらのソフトウェアのエキスパートになる必要はありません。
しかし、まだまだ常に学ぶ余地があるということ、
そしてフリーソフトウェアプロジェクトを運営するにあたって
メーリングリストの管理作業は避けて通れないものであることは心においておきましょう。
これ以降では、メーリングリストの設定に関するよくある問題についてみていきます。
スパム対策
今、この文章を書いている時点と実際に本書が出版された時点を比べても、
スパムに関する問題の深刻度は倍増していることでしょう。
少なくとも、そう感じるくらいのレベルにはなっているはずです。
つい最近までは、スパム対策をまったく行わなくても
メーリングリストを普通に運営できていました。
ごくまれに変な投稿が行われることもありましたが、気になるほどのものではなかったのです。
しかし、そんな時代はとっくに終わってしまいました。
現在では、スパム対策をまったくしていないメーリングリストは
あっという間にゴミメールの山となってしまいます。
そんなメーリングリストは使い物にならないでしょう。
スパムは決して野放しにしてはいけません。
本書では、スパム対策を２種類に分けて考えます。
ひとつはメーリングリストにスパムが配信されないようにすること。
もうひとつは、メーリングリストの参加者のメールアドレスを
スパム業者に収集されないようにすることです。
前者の方がより大事なので、まずはそちらから考えていきましょう。
投稿のフィルタリング
スパム投稿を防ぐ基本的な方法は、次の３つです。
ほとんどのメーリングリストソフトウェアは、これらの機能をすべて提供しています。
また、これらの方法は、どれかひとつだけを使うのではなく
組み合わせて使うと有効です。
メーリングリストのメンバーからの投稿のみを自動配信する
これはある程度は有効で、管理者にはほとんど負担がかかりません。というのも、
これを行うには単にメーリングリストソフトウェアの設定を変更するだけだからです。
しかし、自動承認されなかった投稿を単に捨ててしまってはいけません。
そうではなく、自動承認されなかった投稿は管理者がいったんチェックするようにしましょう。
そうする理由は次の２つです。まず第一に、
メーリングリストのメンバー以外からの投稿も受け付けたいからです。
ちょっとした質問や提案がある人が、
いちいちメーリングリストに参加しなければメールを投稿できないというのは不便です。
もうひとつ、メーリングリストのメンバーであっても、
登録しているアドレス以外のメールアドレスから投稿することがあるかもしれません。
メールアドレスは、人を識別する手段としてはあまり信頼できるものではありません。
メールアドレスにあまり頼りすぎないようにしましょう。
投稿を、いったんスパムフィルタリングソフトウェアにかける
メーリングリストソフトウェアが対応していれば (ほとんどは対応しています)、
投稿内容をスパムフィルタリングソフトウェアに渡すことができます。
自動スパムフィルタリングは完璧なものではありません。
また、今後も決して完璧なものにはならないでしょう。
スパムの送信者とフィルタの作者との戦いは永遠に続くのです。
しかし、フィルタリングソフトを使用することで、
管理者が手作業で処理すべきスパムを激減させることができます。
人手で処理すべき内容が多くなればなるほど、
自動フィルタリングは有用です。
ここでは、スパムフィルタの設定方法については説明しません。
ご利用のメーリングリストソフトウェアのドキュメントを参照してください
(本章の後半の
で詳しく説明します)。
メーリングリストソフトウェアにはたいてい、
自前のスパム対策機能が組み込まれています。
しかし、サードパーティのフィルタを使いたいこともあるでしょう。
私がよく利用しているのは、SpamAssassin
()
と SpamProbe
()
です。もちろんこれら以外にも
オープンソースのスパムフィルタはたくさんありますし、
その中にはすばらしいものもあるでしょう。
私はたまたまこの２つで満足しているので、
他のものをあまり調べていないというだけのことです。
モデレートする
登録されているメールアドレスからの投稿ではないので
自動配信はされませんでした。
また、スパムフィルタを通した結果、スパムではないと判断されました。
そのような投稿に対する最後の手段は
モデレート です。
メールの内容が特別なアドレスに送られ、
人間がその内容をチェックしたうえで承認するか却下するかを決めるのです。
投稿を承認する場合は、「その投稿だけを承認する」
あるいは「その投稿を承認し、
今後同じアドレスからの投稿があった場合は自動的に配信する」
のいずれかの方式となります。
ほとんどの場合は後者の方式をとることになるでしょう。
そうすれば、将来のモデレートの負荷を下げることができます。
投稿の承認方法は、システムによってことなります。
よくある方式は、特別なアドレスに対してコマンドを返信することです。
たとえば "accept" (この投稿だけを承認する)
あるいは "allow" (この投稿および今後のすべての投稿を承認する)
などのようになります。
却下する場合は、通常は単に何もせずにモデレートメールを無視します。
メーリングリストソフトウェアは、
その投稿を承認するという確認を受け取らない限り
投稿を配信することはありません。
つまり、単にモデレートメールを無視しておけば
それで用が満たされるのです。
あるいは、"reject" や "deny"
といったコマンドを明示的に返信することもあります。
そうすると、同じアドレスから今後投稿があった場合に
モデレート処理の前に自動的に却下してくれるようになります。
しかし、そんなことをしてもあまり意味はないでしょう。
モデレートの主要な目的はスパムの防止であり、
スパマーが同じアドレスからメールを何度も送るなんてありえないでしょうから。
モデレートを乱用しすぎないようにしましょう。
スパムを防ぐことと、まったく的外れな投稿
(投稿するメーリングリストを間違えたなど)
を防ぐことだけに限るべきです。
モデレートシステムを使用すると、
投稿者にだけ直接返信を返すことができますが、
それを使ってメーリングリストに関する質問に答えてはいけません。
たとえ即答できるようなものであったとしてもです。
そんなことをすると、どんな質問があったのかがコミュニティーに伝わりません。
また、その質問に対してより適切に答えられる人がコミュニティーにいたとしても、
答えるチャンスがなくなってしまいます。他の人が答えた内容も見ることができません。
メーリングリストのモデレートは、
ゴミメールや場違いなメールばかりにすることを防ぐためのものでしかありません。
それ以上の何者でもありません。
アーカイブでのメールアドレスの処理
メーリングリスト参加者のアドレスをスパマーに抜き取られないようにするには、
アーカイブする際にメールアドレスをぼかすのが一般的です。
たとえば、
jrandom@somedomain.com
のようなアドレスを
jrandom_AT_somedomain.com
あるいは
jrandomNOSPAM@somedomain.com
あるいはそれと同様な (人間には理解できるような) 形式に変換します。
ありがちなメールアドレス収集ソフトは、
メーリングリストのアーカイブのウェブページを読み込んで
"@" を含む文字列を探します。したがって、
アドレスをこのように変換しておけば収集ソフト用の対策になります。
これは、メーリングリストに直接送られてくるようなスパムには無意味です。
そうではなく、リストの参加者のアドレスに直接スパムが送られるのを防ぐための仕組みです。
このようにアドレスを隠すことには賛否両論があります。
この機能を気に入っている人は、アーカイブではそうするのが当然だと思っており、
もしそうなっていなければ非常に驚きます。
しかし、中にはちょっとそれはやりすぎだと考える人もいます。
いくら人間にとっては理解できる形式であるとはいえ、
いったん頭の中で変換しないと正しいアドレスがわからないからです。
また、まったく無意味だという人もいます。
いくらしっかりした符号化を行ったとしても、
アドレス収集ソフトはそれを理論上は理解できるはずだからです。
しかし、アドレスの変換が有用であるということは実証されています。
を参照してください。
理想を言えば、このような処理は
個々の好みで切り替えられるようにしておくべきでしょう。
つまり、メーリングリストの参加者の個人設定ページで
「自分のメールアドレスを符号化する/しない」
を切り替えられるようにしておけばいいのです。
しかし、そのように投稿者ごとや投稿ごとに設定を切り替えられる
ソフトウェアを見たことはありません。現状では、
メーリングリストの管理者が全員の設定を一括で決めなければならないのです
(アーカイブツールがメールアドレスの変換処理に対応していることを
前提としていますが、中にはその機能がないものもあります)。
私は、個人的にはどちらかというと変換処理を行うほうが好きです。
自分のメールアドレスをウェブページなどに表記する際に、
アドレス収集用ソフト対策に非常に気を使っている人たちもいます。
そのような人たちの努力が
メーリングリストのアーカイブによって台無しになってしまうと、
きっと非常に悲しむことでしょう。
一方、アドレスが変換されていることによって
アーカイブの利用者に多少不便を感じさせたとしても、
そんなにたいしたものではないでしょう。
しょせん、必要なたった一人のアドレスを正しい形式に戻すだけのことなのですから。
ところで、メールアドレスの変換作業もまた、
終わりのない戦いであることを覚えておきましょう。
あなたがこれを読んでいる今まさにこの間にも、
アドレス収集ソフトウェアは進化し続けています。
ありがちなアドレス変換方法はすでに破られており、
私たちはまた別の方法を考えなければならないのです。
Reply-to はどうすべきか
先ほど で、
議論は公開の場で行うということの重要性を強調しました。
できるだけそのように心がけておかないと、
議論はどんどん個人的なメールのやりとりに収束してしまいます。
また、本章で扱っている内容は、
ソフトウェアを用いていかにプロジェクト内のコミュニケーションを
円滑にするかということです。
もし議論をメーリングリスト上で続けされるような機能が
メーリングリスト管理ソフトウェアに搭載されているのなら、
それを使用しない手はありません。
……とは一概に言い切れないのです。
実際そのような機能はあるのですが、
無視できない問題点もいくつかあります。
この機能を有効にするかどうかについては、
メーリングリスト管理に関する議論の中でも最も白熱するものです。
７時のニュースで取り上げられるような内容ではありませんが、
フリーソフトウェアプロジェクトにおいては何度となく議論されてきました。
ここでは、まずその機能について説明し、
双方の立場の主張を並べたうえで、
個人的にお勧めの方式を示します。
機能そのものは非常にシンプルです。
メーリングリストへのすべての投稿に対して自動で Reply-to
ヘッダを設定し、返信先をメーリングリストのアドレスにするというものです。
もとの送信者がどんな Reply-to ヘッダをつけていたとしても
(あるいはつけていなかったとしても)、
メーリングリストの参加者に配信されるときには
Reply-to がメーリングリストのアドレスに変わっています。
Reply-to: discuss@lists.example.org
一見これはよさげな機能に見えるかもしれません。
たいていのメールソフトは Reply-to ヘッダの内容を考慮するので、
投稿に対して返信しようとすると、
自動的にメーリングリスト宛てに送信するようになります。
もちろん返信する人の意思で宛先を変更することはできますが、
デフォルトで
メーリングリスト宛てになるということが大事なのです。
テクノロジーの力で協調作業をやりやすくする。
まさに完璧な例じゃないですか。
ところが残念なことに、この方法にはいくつか欠点があるのです。
欠点としてまず最初にあげられるのが、いわゆる
Can't Find My Way Back Home (おうちに帰れない)
問題です。何らかの理由で普段とは異なるアドレスからメールを送信する際など、
「本当の」アドレスを Reply-to フィールドに指定しておくこともあります。
常に同じ場所でメールの読み書きを行うのなら、この問題は起こりません。
もしかしたら、そんな問題があることにすら気づいていないかもしれません。
しかし、普段とは異なる設定でメールを送信する人や
メールの From アドレスを変更できない状況
(職場から送信しており、IT 部門に対する権限がない状況)
の人にとっては、返信を自分で受け取るための唯一の手段が Reply-to となるわけです。
そのような人たちにとって、メーリングリストに参加しているのとは別のアドレスで投稿する際には
Reply-to 設定は必要不可欠な情報となります。
メーリングリストソフトウェアがそれを上書きしてしまうと、
その人は自分の投稿に対する返信を見ることができなくなってしまいます。
もうひとつの問題は、期待に反する動作をしてしまうということです。
個人的には、Reply-to の変更に反対する人が最も強く主張しているのがこの問題だと思います。
メールの処理に慣れている人は、reply-to-all (全員に返信)
と reply-to-author (送信者に対して返信)
の２通りの返信方法を使い分けています。
最近のメールソフトは、これらの操作に対して
それぞれ別のショートカットキーを割り当てています。
全員 (メーリングリストも含む) に返信したい場合は
「全員に返信」を、そして送信者に対して個人的に返信したい場合は
単なる「返信」を使えばいいということを知っているのです。
あなたとしては返信は可能な限りメーリングリストに送信してほしいでしょうが、
返信するほうには個人的に返信する権利があります。たとえば、
元のメッセージに対して何か機密情報を含む内容を返信したい場合などは、
それが公開のメーリングリストに流れてしまってはまずいでしょう。
さて、メーリングリスト側で送信者の Reply-to
設定を書き換えてしまったらどうなるのかを考えてみましょう。
そのメールに対して「送信者に返信」のキーを押したとしたら、
当然その人はそのメールが送信者に対してのみ届くものと期待することでしょう。
ごく当たり前のことなので、いちいちあて先を確認することもないかもしれません。
返信メールの中で個人的な内緒のメッセージ
(もしかしたら他のメンバーの悪口かも……)
を書き、送信ボタンを押します。
予想に反して、数分後には彼の書いた返信が
メーリングリストに流れることになるでしょう!
ええ、もちろん送信前にあて先をしっかり確認しなかった彼が悪いのです……
理屈上は。でも、普通は Reply-to は送信者のアドレスに設定されているもの
(メールソフトがそう設定しているはず) なので、
長年メールを使っている人ほどそう信じ込んでしまう傾向があります。
実際、もし意図的に他のアドレス (たとえばメーリングリストなど)
を Reply-to に設定した場合は、通常はそれをメッセージの中で明記するものです。
この予期せぬ振る舞いの影響は無視できないため、
個人的にはソフトウェア側での Reply-to ヘッダの変更は行わないことをお勧めします。
確かにこの機能は共同作業の際には便利でしょうが、
私にとってはその副作用の影響のほうが重大に感じます。
しかし、もう一方の立場の人たちにもそれなりの言い分があります。
どちらを選択したとしても、「どうして○○にしなかったの?」
という質問がたびたびメーリングリストに投稿されることになるでしょう。
これはきっと、そのメーリングリストで本来扱いたいと思っているテーマとは異なるはずです。
そんな場合用に、この問題に関する議論をうまくしずめるような
お決まりの返答を用意しておくといいでしょう。ここで大切なのは、
あなたがどちらの設定を選んだとしても、決して
それが唯一の正解なんだと主張しないようにすることです
(たとえ内心ではそう思っていたとしても)。
そうではなく、次のように説明するようにしましょう。
「この問題については昔から議論が繰り返されています。
どちらの立場の主張にもそれなりの言い分があり、
みんなが納得するようにすることは困難です。
だから、私は自分がよりよいと思う設定にしたのです。」
そして、(まったくの新入りさんが質問してくる場合は別として)
もうこの話題はメーリングリスト上で話すのはやめるよう丁寧にお願いし、
あとはそのスレッドを放置しておきます。
そうすれば、そのスレッドの議論は自然に収まるでしょう。
もしかしたら、誰かが「どっちがいいか投票で決めよう」なんて言い出すかもしれません。
あなたさえかまわなければそれでもいいのですが、
個人的には、この問題は多数決で決めるような類のものではないと思います。
予期せぬ挙動のせいで受ける被害 (個人的なメールを
間違ってメーリングリストに送ってしまう) は甚大ですが、
Reply-to を書き換えないことで参加者が受ける不利益はたかが知れています
(たまに間違って個人宛に返信してしまった人に対して、
メーリングリストに返信するよう伝えるくらいです)。
個人的なメールをメーリングリストに送ってしまうような人は
ほんの一握りかもしれません。でも、たとえそうであっても
彼らにそのようなリスクを負わせることが許されるでしょうか?
この問題に関するすべての議論を取り上げることはしません。
ここでは、最も重要だと思われるものだけを示しておきます。
詳細な議論の内容は、以下の文書でご確認ください。
どちらも、この問題が持ち上がるたびに多くの人が引用するものです。
Reply-to はそのままにしておくべきだという主張,
by Chip Rosenthal
(日本語)
Reply-to をメーリングリスト宛に変更すべきだという主張,
by Simon Hill
(日本語)
先ほど私の個人的な好みを軽く述べましたが、決してそれが "正解"
だと確信しているわけではありません。実際、私は Reply-to を
書き換えている メーリングリストにも多数参加しています。
大事なことは、どちらにするのかを早めに決めておくこと。
そして、後々この件についての議論に巻き込まれないようにすることです。
私のふたつの夢
いつの日か、どこかの誰かが reply-to-list
機能をメールソフトに組み込んでくれるかもしれません。これを使用すると、
先ほど説明したメーリングリスト独特のヘッダの内容をうまく読み取り、
メーリングリスト宛てに適切に返信してくれるのです。
それ以外の相手にはメールは送られません。
だってその人たちほほとんどはメーリングリストにも加入しているんですから。
結局のところ、メールソフト側でこのような機能を実装してしまえば、
こんな議論をせずにすむようになるわけです
(実際、Mutt
というメールソフトはこの機能を持っています
本書の出版直後に Michael
Bernstein が教えてくれました。"Mutt 以外にも、
reply-to-list 機能を実装しているメールソフトがあります。
たとえば Evolution では、キーボードショートカット
(Ctrl+L) でこの機能を使用できます。でもボタンはありません。"
)。
よりよい対応法は、Reply-to を変更するかしないかを
各メンバーが個別に設定できるようにすることでしょう。
メーリングリスト宛ての投稿は (自分の投稿も他人の投稿も含めて)
Reply-to をメーリングリストのアドレスにしてほしいという人はそのオプションを指定し、
Reply-to をそのままにしておいてほしい人はそのように指定します。
残念ながら現時点では、
これを各参加者ごとに設定できるメーリングリスト管理ソフトは存在しないようです。
現状は、全員共通の設定で我慢するしかありません。
その後、この機能をサポートするメーリングリスト管理ソフトがあることを知りました。
Siesta
というものです。
の記事も参考になるでしょう。
アーカイブ
メーリングリストのアーカイブを設定する技術的な方法は、
使用するメーリングリスト管理ソフトによって異なるので、
本書では詳しくは取り上げません。
アーカイブツールを選択したり設定したりする際には、
以下のような点に注意しましょう。
迅速な更新
少なくとも、実際に投稿があってから１時間後くらいには
その投稿がアーカイブされていてほしいものです。
可能なら、実際に投稿があった瞬間にアーカイブ処理も同時に行なうべきです。
そうすれば、その投稿がメンバーに配信されたときには既に
アーカイブにも同じ内容が存在するということになります。
それが無理だとしても、少なくとも１時間おきくらいの頻度でアーカイブの更新を行ないましょう
(アーカイブソフトによっては、デフォルトでは
１日に１回しかアーカイブを行なわないものもあります。
しかし、メーリングリストのアーカイブ処理としては、
事実上これでは使い物にならないでしょう)。
参照の永続性
メッセージがいったんある URL にアーカイブされたら、
その後ずっと同じ URL でそのアーカイブにアクセスできるようにすべきです。
アーカイブを再構築したりバックアップから復旧したり、
あるいはその他何らかの修正を加えたときにも、
いったん公開した URL はそのまま変わらないことが望ましいでしょう。
同じ URL を保つようにしておけば、サーチエンジンに捕捉されやすくなります。
これは、利用者にとって大きな利点となるでしょう。
URL を保ち続けるよう心がけるもうひとつの理由としては、
メーリングリストの投稿やスレッドがバグ追跡システム
(本章の後半の
を参照してください)
や他のプロジェクトのドキュメントからリンクされることが多いということもあります。
理想を言えば、メールをメンバーに配信する際に、
そのメッセージがアーカイブされている URL
をヘッダに含められるようになっていればなおよいでしょう。
そうすれば、そのメールを受け取った人は
わざわざアーカイブサイトを訪れなくても
そのメッセージがアーカイブされている場所を知ることができます。
ブラウザを開いて何らかの操作をするというのは時間のかかる作業なので、
それが省けるだけでも非常に便利です。
このような機能を持つメーリングリスト管理ソフトウェアがあるかどうかは、
私は知りません。残念ながら、
私が今使っているソフトウェアにはそのような機能はないようです。
しかし、どこかにそんなソフトウェアがあるのではと期待しています
(もしあなたが新たにメーリングリスト管理ソフトウェアを開発するのなら、
ぜひこの機能を実装してください。お願いします)。
バックアップ
当然、アーカイブのバックアップとバックアップからの復旧の方法は
簡単なほうがよいでしょう。いいかえれば、
アーカイブソフトがブラックボックス化してしまってはいけないということです。
あなた (もしくはプロジェクト内の誰か)
はメッセージが実際にどのように保存されているかを知っている必要があり、また、
必要になったときにはそこからアーカイブを復元できるようにしておかなければなりません。
プロジェクトにとって、アーカイブの内容は宝物です。
万一アーカイブを失ってしまうことがあれば、
貴重な記録を失ってしまうことになります。
スレッドのサポート
個々のメッセージから、そのメッセージが属する
スレッド (関連するメッセージのまとまり)
へ移動できるようにしておく必要があります。
また、各メッセージ個別の URL とは別に、
スレッドを表す URL もあるとよいでしょう。
検索機能
メッセージの本文や送信者、件名などによる検索機能を
サポートしていないアーカイブソフトなんて、使い物にならないといっていいでしょう。
アーカイブソフトの中には、単に
Google
などの外部のサーチエンジンに処理をまかせているだけのものもあります。
機能がないよりはましですが、検索機能を自前で実装しているほうが
よりきめ細やかな処理ができます。
たとえば、タイトルだけを対象に検索したり、
本文も含めて検索したりといったこともできるでしょう。
上にあげたのは、アーカイブソフトを選択する際に注意する点として
技術的な面にしぼった一覧です。
実際にみんなにアーカイブソフトを利用
してもらうことにどのような利点があるのかについては、
でとりあげます。
ソフトウェア
メーリングリストの管理やアーカイブの作成用に、
さまざまなツールがオープンソースで公開されています。
あなたのプロジェクトを公開しているサイトで何かのツールが用意されているのなら、
それを使えばいいでしょう。しかし、もし自分で新たにインストールする必要があるのなら、
いくつかの選択肢があります。私が実際に使用したことがあるのは
Mailman、Ezmlm、MHonArc、そして Hypermail です。
しかし、それ以外のソフトウェアが劣っているというわけではありません
(また、当然のことですが、私が知っているソフトウェアだけがすべてではありません。
それ以外にもさまざまなものがあるはずなので、
これを完全なリストとはとらえないでください)。
メーリングリスト管理ソフトウェア
Mailman —
(Pipermail というアーカイバが組み込まれていますが、
プラグイン形式で外部のアーカイバを使用することもできます。
Mailman は標準の座を長年維持しています。
その管理インターフェイス、特にスパムのモデレーションや
購読のモデレーションに関してはさすがに時代を感じさせ、
よりモダンなインターフェイスに慣れた人にとっては
もどかしさを感じることがあるかもしれません)
GroupServer —
(アーカイバが組み込まれており、ウェブベースのインターフェイスも統合されています。
GroupServer は Mailman に比べて少し導入が難しく、
2012 年はじめの時点では前提条件もかなり厳しいものです。
しかし、ひとたび動き出せば、より使いやすさを実感できるでしょう)
Sympa —
(開発と保守はフランスの大学のコンソーシアムが担当しており、
700000 人を超える大規模なメーリングリストを扱えるように設計されています。
また、メーリングリストの数が多くなっても対応できます。
依存するツールはさまざまなものが選べ、
たとえば sendmail や postfix、qmail、そして exim
などをメッセージ配送エージェントとして利用できます。
ウェブベースのアーカイブ機能が組み込まれています)
SmartList —
(メール処理システム Procmail と組み合わせて使用するためのものです)
Ecartis —
ListProc —
Ezmlm —
(メール配送システム Qmail
と組み合わせて使用するように設計されています)
Dada —
(なぜかサイト上では隠そうとしているようですが、
これはフリーソフトウェアで、GNU General Public License
のもとで公開されています。また、アーカイバも組み込まれています)
メーリングリストのアーカイブ用ソフトウェア
MHonArc —
Hypermail —
Lurker —
Procmail —
(SmartList に同梱されているソフトウェアです。
通常のメール処理システムなのですが、
アーカイバとしても使えるようです)
バージョン管理
バージョン管理システム（あるいは
リビジョン管理システム）は、
プロジェクト内のさまざまなファイルの変更履歴を管理するための
テクノロジーや習慣を組み合わせたものです。
たとえば、ソースコードやドキュメント、
ウェブページなどがバージョン管理の対象となります。
もしこれまでにバージョン管理システムを使ったことがないのなら、
まずはバージョン管理システムを使ったことのある人を探して
プロジェクトに引きずり込みましょう。いまどきのプロジェクトなら、
少なくともソースコードくらいはバージョン管理されていて当然です。
また、たかがバージョン管理程度のことすらできていないプロジェクトなど、
誰もまともに取り合ってくれないかもしれません。
バージョン管理がこれほどまで一般的になった理由は、
プロジェクトを運営していく上でいろいろな場面で役立つということです。
開発者どうしのコミュニケーション、リリース管理、バグ管理、
コードの安定性の確保、安心して新機能を実験できる環境、
各開発者の権限の管理など、
あらゆる場面でバージョン管理が利用できます。
バージョン管理システムは、これらの内容を一まとめにして管理します。
その中心となる機能が、変更管理です。
これは、プロジェクト内のファイルが変更されるたびに
その変更についてのメタデータ（更新日や更新者など）
を収集する仕組みです。
そして、あとからその変更の内容を再現できるようにするのです。
つまり、変更が発生した単位で情報を管理する仕組みといえます。
このセクションでは、バージョン管理システムのあらゆる機能を説明するわけにはいきません。
あまりにもさまざまな機能があるので、本書ではすべてを紹介することができないのです。
ここでは、使用するバージョン管理システムを選択して
実際に稼動させるところまでに絞って説明していきます。
バージョン管理に関する用語集
本書では、まだバージョン管理システムを使ったことがない人に対して
その基本的な使い方を解説することはできません。
しかし、いくつかのキーワードを知っていなければ、
これ以降の議論についていけなくなるでしょう。
ここで説明するキーワードは、どのバージョン管理システムでも共通に使われるものです。
これらの言葉については、これ以降でもとくに説明せずに使用していきます。
たとえこの世にバージョン管理システムがなかったとしても、
変更の管理をどうするかという問題が消えてなくなることはありません。
この問題について語る際には、ここで取り上げたキーワードを知っていると便利です。
コミット
プロジェクトに変更を加えること。もう少しかしこまって言うと、
変更した内容をバージョン管理データベースに格納し、
そのプロジェクトが次に公開するリリースに反映されるようにすること。
"コミット" は、動詞としても名詞としても用いられます。
名詞として使った場合の意味は、"変更" とほぼ同じです。
たとえば次のように使用します。"Mac OS X
上でサーバがクラッシュするバグを修正してコミットした。
ジェイ、悪いけどこのコミットの内容をチェックしてくれないかな？
もしかしたらメモリを確保する方法を間違っているかもしれないし"
ログメッセージ
各コミットに添付されたコメントで、
そのコミットの内容や目的を説明するもの。
ログメッセージは、そのプロジェクトのドキュメントの中で
最も重要なものです。これは、実際に変更したコードの内容を
人間が読んでわかりやすい言葉 ("機能追加"、"バグ対応"、
あるいはプロジェクトの進捗状況など)
に変換する意味合いがあります。
このセクションの後半では、
ログメッセージを適切なメンバーに配信する方法を説明します。また、
の では
各メンバーにいかにして有用なログメッセージを書いてもらうかを説明します。
アップデート
他のメンバーの変更 (コミット) をローカル環境に取り込むこと。
つまり、ローカル環境を "最新版" にすること。
これは非常に頻繁に行われる操作です。
ほとんどの開発者は、自分のコードを一日に何度もアップデートします。
それにより、自分の開発環境を他のメンバーとほぼ同じ状態に保つようにするのです。
また、もし何かバグを見つけたときに、
おそらくまだそれは修正されていないものであろうことを予想できるようにします。
たとえば次のように使用します。"ねぇ、このコードって、
いちばん最後のバイトを読んでいないように見えるんだけど……。
バグじゃない？"
"うん。でもそれは先週修正したよ。
最新版にアップデートしたらバグはなくなるはずだ。"
リポジトリ
変更内容を格納するデータベース。
たとえば中央管理方式のバージョン管理システムでは、
マスタリポジトリがひとつだけ存在します。
すべての変更内容がここに格納されることになります。
分散管理方式の場合は、各開発者が個別にリポジトリを所有します。
他のリポジトリとの間のデータ交換が、任意のタイミングで発生します。
バージョン管理システムは、各変更の内容を記録しています。
リリース時期には、特定の時点の内容をリリース用として指定します。
中央管理方式と分散管理方式のどちらがよいかについて語りだすと、
終わりのない宗教戦争に巻き込まれてしまいます。
プロジェクトのメーリングリストでは、
できるだけこの問題には触れないようにしましょう。
チェックアウト
リポジトリからプロジェクトの内容を取得する処理。
チェックアウトを行うと、いわゆる「作業コピー」
（次の項を参照ください）と呼ばれるディレクトリツリーが作成されます。
このツリーに変更を加えた結果をコミットし、元のリポジトリに反映させます。
分散型のバージョン管理システムの中には、
作業コピーそのものがリポジトリでもあるというものもあります。
その変更内容を、他のリポジトリとの間でやりとりしたりする構造になっています。
作業コピー
開発者がローカル環境に保持するディレクトリツリーで、
この中にはプロジェクトのソースコードやウェブページ、
その他のドキュメントが格納されることになります。
作業コピーには、バージョン管理システムが使用するメタデータも含まれています。
このメタデータの中には、取得元のリポジトリの場所や現在の
"リビジョン"（次の項を参照ください）などについての情報が格納されています。
一般に、個々の開発者は自分の作業コピーを取得してそこで開発を行います。
そして、変更した内容のテストを済ませたうえで
それをコミットします。
リビジョン、
チェンジ、
チェンジセット
"リビジョン" とは、指定したファイルやディレクトリの
特定の時点の状態のことです。
たとえば、あるプロジェクトのファイル F のリビジョンが 6
であった場合に、誰かがファイル F を変更してコミットすると、
F のリビジョンは 7 となります。
システムによっては、一度に行われたある特定の変更群を称して
"リビジョン"、"チェンジ" あるいは "チェンジセット"
とするものもあります。
バージョン管理システムによっては、
これらの用語を明確に定義しているものもあります。
しかし、一般的な考え方はどれも同じです。
一連の流れの中の特定の時点
(バグ修正が行われた箇所など)
を指定する方法を用意しているわけです。
たとえば、次のように使用します。
"ああ、それなら彼女がリビジョン 10 で修正したよ。"
あるいは
"彼女は foo.c のリビジョン10でそれを修正したよ。"
特定のリビジョンを指定せずに話を進めている場合は、
一般に最新のリビジョンについて語っているものと考えていいでしょう。
"バージョン"？それとも"リビジョン"？
"リビジョン" と同じような意味で バージョン
という言葉を使う人もいますが、本書の中ではこの使い方はしません。
"バージョン" といってしまうと、ソフトウェアのリリース時の版番号
(たとえば "バージョン 1.0 をリリースしました" などと使用)
と混同されてしまうからです。
しかし、"バージョン管理" という言葉は既に市民権を得てしまっているので、
この言葉は使うようにします (本来なら "リビジョン管理"
や "変更管理" と言いたいところです)。
差分
変更内容を表すテキスト。
変更があった箇所とその前後数行について、
変更前と変更後の状態を表示します。
元のコードになじみがある人なら、
差分を見ればどこをどう変更したのかがわかります。
時にはバグを見つけたりすることもできるでしょう。
タグ
指定したリビジョンを構成するファイルにつけるラベル。タグは、
プロジェクトの特筆すべき時点の状態を保護するために使用することが多くなります。
特筆すべき点とは、たとえば一般向けのリリースなどがあげられます。
リリースごとにタグをつけておけば、
そのリリースとまったく同じ内容のファイル群を
バージョン管理システムから簡単に取得できるようになります。
タグの名前としてよく用いられるのは、
Release_1_0 や
Delivery_00456 といったものです。
ブランチ
プロジェクトの一部でありバージョン管理下に存在するが、
他とは隔離されている部分。ブランチに対して適用した変更は
その他の部分に対しては影響をおよぼしません。また逆も同様です。
ただし、明示的に "マージ" した場合は別です (以下を参照ください)。
ブランチは、"開発ライン" と呼ばれることもあります。
明示的にブランチを作成していない場合でも、
"メインブランチ" で開発を進めているものと考えます。このブランチのことは
"メインライン" あるいは "トランク (trunk)"
と呼ばれることもあります
ブランチを使用すると、複数の開発ラインを別々に管理できるようになります。
たとえば、本流の開発ラインとは別に実験的な開発用のブランチを作成し、
本流を不安定にさせる可能性があるような開発はそちらで行うということができます。
あるいは逆に、新しいリリース用の安定版ブランチを作成するといった使用法もあります。
この方式の場合、リリースが間近に迫っても、
通常の開発は本流ブランチ上で途切れなく続けられます。
一方、リリース用ブランチではリリース作業に入った段階でコミットを停止し、
リリース管理者が許可しない限りはコミットをしないようにします。
この方式を採用すると、リリース前にいったん開発を中断する必要がなくなります。
ブランチについての詳細は、本章の後半
にある をご覧ください。
マージ (あるいはポート)
変更内容を、あるブランチから別のブランチに移動すること。
本流の変更内容を他のブランチに適用したり、その逆を行ったりすることも含みます。
実際のところ、ほとんどのマージ作業はこのパターンです。
本流以外の２つのブランチ間でのマージはほとんどありません。
この手のマージについては
をご覧ください。
"マージ" にはもうひとつの意味もあります。
ひとつのファイルに対して複数人が別々の箇所を変更したときに、
バージョン管理システムが行う処理のことです。
お互いの変更が相手の変更を邪魔することはないので、
手元で修正済みのファイルをアップデートすると、
相手の変更内容が自動的にマージされ（取り込まれ）ます。
これは、複数の人が同じファイルをハックしている場合によくあることです。
万一お互いが変更した箇所が重なっていた場合は、次に説明する
"コンフリクト" 状態になります。
コンフリクト
ひとつのコードの同じ箇所を異なる人が変更しようとした際に起こる現象。
バージョン管理システムは、コンフリクトの発生を自動的に検出します。
そして、変更しようとしたユーザーに対してそれを通知します。
発生したコンフリクトを 解決
するのは、変更しようとした人たち自身の責任です。
解決したあとで、それをバージョン管理システムに通知します。
ロック
特定のファイルやディレクトリを、他人に変更されないように宣言する方法。
たとえば "ウェブページの変更内容をコミットしようとしたけどできない。
たぶん、Alfred が背景画像を修正する間、すべてのファイルをロックしているんだろう"
というように使います。
中にはロック機能を持っていないバージョン管理システムもあります。
また、その機能を持っていたとしても、実際にそれが必要となることはあまりないでしょう。
いろんな人が同時に平行して開発を進めるというのが普通の状況なのであり、
ロックして他人を締め出すというのはこの理想に相反するものです。
コミットするにはロックが必要となるバージョン管理システムのことを、
「ロック - 修正 - ロック解除 (lock-modify-unlock) モデル」
といいます。一方、ロックが必要でない方式のことは
「コピー - 修正 - マージ (copy-modify-merge) モデル」
といいます。２つの方式について深く掘り下げて比較したすばらしい文書が
（日本語訳）
にあります。一般に、オープンソース開発においては
コピー - 修正 - マージ モデルの方が適しています。
本書で扱うバージョン管理システムは、すべてこの方式を採用しています。
バージョン管理システムの選択
本書の執筆時点では、
フリーソフトウェアの世界で最もよく使われているバージョン管理システムは
Concurrent Versions System
(CVS, )
と Subversion (SVN,
) の２つです。
CVS には長い歴史があります。
ベテランの開発者はすでに CVS についてはよくご存知でしょう。
これまでにも CVS がいろいろな場面で役に立ってきたはずです。
CVS の時代があまりにも長く続いてきたので、
本当にそれが最適な選択肢だったのかどうかなんて聞くだけ野暮というものでしょう。
しかし、CVS には欠点もあります。
まず、複数のファイルを一括して変更したときに、それを追いかける簡単な手段がありません。
また、バージョン管理下にあるファイルの名前を変えたりコピーしたりすることができません
（プロジェクトをいったん開始した後でコードツリーの構成を変更したい場合は、
泣きながら大変な作業をこなすことになるでしょう)。
そして、マージ機能はかなりお粗末なものです。
巨大なファイルやバイナリファイルの扱いも不得意です。
そして、大量のファイルを一括して操作しようとすると非常に時間がかかることがあります。
CVS のこれらの欠点は決して致命的なものではありませんが、
無視できるものでもありません。
ここ数年、新たに立ち上げられたプロジェクトでは
Subversion を採用することが多くなってきました
その証拠としては
や
があります。
。
これから新たにプロジェクトを立ち上げるのなら、Subversion をお勧めします。
一方、私が Subversion プロジェクトにかかわっていることもあり、
私の意見の客観性に疑問を持たれる方もいるかもしれません。
ここ数年、新たなオープンソースのバージョン管理システムがいくつか登場しています。
に、
私が知っているものを挙げておきます。
このリストを見てもわかるように、バージョン管理システムにどれを採用するかを決めるには、
下手したら一生かかってしまうかも知れません。
もしかしたら、あなたには選択の余地がないかも知れません。
というのは、ホスティングサイトを使用する場合は
ホスティングサイト側でバージョン管理システムが設定されているかもしれないからです。
もしあなたが自分で選択しなければならない立場になったのなら、
まず周りの意見をよく聞いてからどれかひとつを選択し、
そして動かしてみましょう。
最近のバージョン管理システムは、どれもそれなりに機能します。
どれを選んだとしても、致命的な被害を受けることはないでしょう。
もしまだ迷っているのなら、Subversion を使ってみましょう。
これは簡単に習得でき、少なくとも今後数年は標準的に使われることでしょう。
バージョン管理システムの使用法
この章で説明する内容は、特定のバージョン管理システムに固有のものではありません。
どのシステムを選択した場合にも適用できるはずです。
詳細は、各システムのドキュメントを調べるようにしましょう。
すべてをバージョン管理する
ソースコードだけでなく、ウェブページやドキュメント、FAQ、設計メモなどなど、
編集する可能性のあるものはすべてバージョン管理下におくようにしましょう。
これらは、同一リポジトリツリー内でソースコードの隣に置いておきます。
書き残した情報は、すべてバージョン管理する価値があります。
つまり、あらゆる情報は変化する可能性があるということです。
今後変わりようのない内容については、
バージョン管理ではなくアーカイブしなければなりません。
たとえば、メーリングリストに投稿されたメールの内容は、変わることがありません。
このようなものをバージョン管理しても無意味です
(もちろん、それが巨大な文書の一部となる場合などは別ですが)。
すべてを同じ場所でバージョン管理する理由は、
そうしておけば作業に参加する人がひとつのことを覚えるだけですむようになるからです。
たとえば、最初はウェブページやドキュメントの修正から参加しはじめたメンバーが、
後にコードそのものの修正にも参加するようになるといったことがあります。
すべてを同じ仕組みでバージョン管理しておけば、
このような場合に新たにその使用法を学ぶ必要がなくなるのです。
また、新機能を追加すると同時にドキュメントも更新したり、
コードのブランチを作成すると同時にドキュメントのブランチも作成したり
といった際にも便利です。
自動生成されるファイル はバージョン管理する必要がありません。
これらのファイルは純粋に編集可能なデータではなく、
別のファイルの内容をもとにして自動生成されるものだからです。
たとえば、ビルドシステムでよく用いられるファイル configure
は、テンプレート configure.in
の内容をもとにして自動生成されるものです。もし configure
を変更したいのなら、configure.in
を編集してから再生成するということになります。つまり、この場合で言う
「真に編集可能なファイル」は、テンプレートである configure.in
だけということになります。バージョン管理するのはテンプレートだけにします。
生成した結果までバージョン管理してしまうと、
テンプレートを修正した際にファイルを再生成することを忘れてしまうかも知れません。
そうすると、ファイルの整合性が取れなくなってしまって混乱の元となります。
configure ファイルをバージョン管理するか否かについては、
別の見方もあります。Alexey Makhotkin の記事 "configure.in and version
control" が、次の URL で見られます。
「編集可能なデータはすべてバージョン管理下におかなければならない」
という規則には、残念ながらひとつだけ例外があります。
それが バグ追跡システム です。
バグデータベースは編集可能なデータを大量に保持していますが、
技術的な理由により、このデータをバージョン管理することはできません
(バグ追跡システムの中には、ちょっとしたバージョン管理機能を独自に実装しているものもあります。
しかし、これはプロジェクトのメインリポジトリとは独立したものとなります)。
ウェブで閲覧できるようにする
プロジェクトのリポジトリは、ウェブ上からも閲覧できるようにしなければなりません。
これは、ただ単に最新のリビジョンが見られればいいというレベルのものではありません。
前のリビジョンにさかのぼったりリビジョン間の差分を見たり、
変更時のログメッセージを見たりといった機能も含みます。
これは、そのプロジェクトのデータに関する便利な入り口となるので、
ブラウザビリティ（閲覧のしやすさ）が重要となります。
もしウェブブラウザ経由での閲覧ができなければ、
そのプロジェクトの特定のファイルを調べたい人
（あのバグ修正はどんな風に行われたのかな？など）はまず
バージョン管理システムのクライアントソフトウェアを
インストールするところから始めなければならなくなってしまいます。
ウェブで見られれば２分ですむことなのに、
それがないために30分がかりの作業になってしまうということになります。
ブラウザビリティの中には、特定のファイルの特定のリビジョンが特定の
URL で見られること、そして特定のファイルの（その時点での）
最新リビジョンも特定の URL で見られることといった内容も含まれます。
こうしておくと、技術的な議論の際にその場所を示しやすくなるので便利です。
たとえば「バグ管理についてのガイドラインは、作業コピーにある
www/hacking.html をご覧ください」という代わりに
「バグ管理についてのガイドラインは
http://subversion.apache.org/docs/community-guide/
をご覧ください」と言えるのです。
これは、常に community-guides/index.html
の最新リビジョンを指す URL です。URL を指定するほうが、
あいまい性を排除するという点でよいでしょう。
バージョン管理システムの中には、
リポジトリをウェブで閲覧するための仕組みが組み込まれているものもあります。
また、サードパーティのツールを使ってこの機能を実現しているものもあります。
サードパーティのツールとして有名なのは
ViewVC ()、
CVSWeb ()、
そして
WebSVN ()
です。ViewVC は CVS と Subversion の両方に対応しています。
一方、CVSWeb は CVS 専用、WebSVN は Subversion 専用です。
コミットメール
コミットが行われるたびに、その内容をメールで送信するようにします。
メールには「だれが」「いつ」「どのファイルやディレクトリを」「どのように」
変更したのかを記述します。
このメールの送信先は独立したメーリングリストとし、
人間が投稿する普通のメーリングリストとは独立させましょう。
コミットメールを受け取りたいひとだけがそのメーリングリストに参加することになります。
開発者やプロジェクトに興味があるその他の人たちには、
このメーリングリストへの加入を勧めましょう。
今そのプロジェクトに何が起こっているのかをコードレベルで知るために、
このメーリングリストは最適な手段となります。
ピアレビューの技術的な有用性については改めて語るまでもありません
( をご覧ください)
が、コミットメールもコミュニティーにおいては有用なものとなります。
すべてのイベント（コミット）の内容が共有されることで、
他のメンバーがそれに反応したりといったことがしやすくなるのです。
コミットメールの設定方法は、使用するバージョン管理システムによって異なります。
しかし、通常はそれ用のスクリプトやパッケージが用意されているはずです。
もし見つからなければ、使用しているシステムのドキュメントで
フック（hooks）、あるいは
コミット後フック（post-commit hook）
といったキーワードで探してみましょう。ちなみに CVS では
loginfo フック（loginfo hook）
と言うようです。
コミットがあるたびに自動で特定の作業をさせる際に使用するのが
コミット後フックです。これは各コミットの直後に呼び出され、
そのコミットに関する情報を受け取って任意の作業を行うことができます。
そう。たとえばメールを送信したりなど。
用意されているメール送信の仕組みを使用していると、
そのデフォルトの動作をちょっと変更したくなってくるかもしれません。
コミットメールシステムの中には、実際の差分そのものは本文に含めず、
それをウェブで見るための URL だけを記載するというものがあります。
もちろん URL は大事です。後から変更内容を確認するのにも便利ですしね。
でも、差分の内容そのものをメールの本文に含めておくことも
非常に 重要です。多くの人にとって、
メールを読むという作業は日常のルーチンワークとして組み込まれているでしょう。
変更の内容が直接メールに書かれていれば、
一連の流れの中で自然にコミットをレビューすることができます。
いちいちメールソフトを終了してブラウザに切り替える必要がなくなるのです。
変更を確認するには URL をクリックする必要があるとなれば、
ほとんどの人はクリックなどしてくれないでしょう。
だって、これまでずっとメールを読んでいたのに、
いきなり別の操作が必要となるのですから。
さらに、変更点をレビューした人がその内容について質問をしたいときに、
そのメールに「返信」すれば自動的に変更内容が得られるので便利です。
さもないと、ウェブページを開いて変更点を
カット＆ペーストするという大変な手間がかかってしまいます。
(もちろん、新たにリポジトリにコードを追加したなどで変更点が大量にある場合は、
差分を省略して URL だけにするというのもわかります。
コミットメールのシステムの多くは、
何らかの制限値を設定してこの処理を自動化してくれるようになっています。
もしそんな機能がついていなかったとしましょう。そんな場合でも、
差分をまったく記載しないよりは常に差分を含めるようにするほうがずっとマシです。
たまに巨大なメールが送信されることになりますが、許容範囲です。
共同開発においては、みんなが他人の変更をレビューしたりコメントしたりすることが重要です。
そのための努力は、いくらしてもしすぎることはありません)
コミットメールの Reply-to ヘッダは、コミットメール用のメーリングリストではなく
開発者向けのメーリングリストにしておきましょう。
そうすると、コミットメールの内容をレビューして何らかのコメントをしたくなった人が
「返信」すると、それが自動的に開発者向けメーリングリストに流れることになります。
こうしておくべき理由はいくつかあります。
まず、技術的な議論はひとつの場所に集約するということ。
技術的な議論を行う場として最適なのは、開発者向けメーリングリストです。
次に、コミットメール用のメーリングリストに参加していないメンバーにも
議論の内容を伝えるということ。
３つ目に、コミットメール用のメーリングリストはあくまでも
コミットの内容をチェックするだけのものであり、
決して「コミットの内容のチェックがメインだけど、
たまに技術的な議論もある」というものであってはいけないからです。
コミットメール用のメーリングリストに登録する人たちは、
コミット内容のメールだけが送られてくることを期待しています。
それ以外の内容が送られると、暗黙の了解を裏切ってしまうことになります。
最後に、コミットメールの内容を処理して（ウェブページなどに）
結果を出力するプログラムを作成するような人のことを考えるということ。
この種のプログラムは、
コミットメールのようなお決まりのパターンのメールに関してはうまく動作します。
しかし、人間が書いたメールを処理させると変な結果になってしまうでしょう。
ここでお勧めした Reply-to の設定は、決して
本章の前半で述べた
の内容と矛盾するものではないことに注意しましょう。
先ほども、メッセージの 送信者 自身が
Reply-to を設定するぶんには特に問題はないとしています。今回の場合、
メッセージの送信者はバージョン管理システムです。
バージョン管理システム自身で Reply-to
を指定して開発者向けメーリングリスト向けに返信させようとしているのですから、
さきほどの説明とは矛盾しません。
CIA: 変更点を公開するための標準化された方法
変更点を公開する方法はコミットメールだけではなく、
CIA () をインストールすることもできます。
これは、コミットの状況をリアルタイムで収集し、配信するものです。
CIA の最も一般的な使用法は、コミットの通知を
IRC チャンネルに送信するというものです。
そのチャンネルに参加していれば、
コミットがあるたびに即時にそれを知ることができます。
メールに比べたら、技術的に劣っているかもしれません。
だって、IRC にコミット通知を送ったとしても
それを見ている人がいるかどうかがわからないわけですから。
それでも、この仕組みは 社会的な面で
面白いものです。参加している人たちは
そこで何かが起こっていることが感じられ、
開発の進行状況をまさに目の前で見られるというわけです。
また、共有空間に通知されるので、
チャットルームにいる人たちがリアルタイムで反応し、
即座にコミットをレビューしてコメントをしてくれることが多くなります。
CIA を使用するには、コミット後のフックで通知用プログラムを実行します。
このプログラムは、コミットに関する情報を XML
形式に変換して中央サーバ (通常は cia.vi)
に送ります。するとサーバがその情報を別のフォーラムに配信するのです。
CIA を設定することで、
RSS
フィードを送信させることもできます。詳細は
のドキュメントをご確認ください。
CIA が実際に動作している例を見るには、IRC クライアントで
irc.freenode.net のチャンネル #commits
に行ってみましょう。ここでは、
CIA が監視している全プロジェクトの活動状況を見ることができます。
ブランチの活用
バージョン管理システムにあまり慣れていないユーザーは、
ブランチの作成やマージ作業を怖がる傾向があるようです。
おそらく、これは CVS の悪評の副作用でしょう。
CVS のブランチ作成処理やマージ処理は直感的とは言えず、
多くの人がそれを避けるようにしています。
もしあなたもその中のひとりだというのなら、
怖がる気持ちを乗り越えてブランチ作成やマージについて勉強してみましょう。
いったん作業に慣れてしまえば、そんなに難しいものではありません。
また、プロジェクトに参加するメンバーが増えれば増えるほどこの作業の重要性も増します。
ブランチを使用すると、限られた資源（プロジェクトのソースコード中の作業場所）
を有効活用できるので便利です。
通常は、すべての開発者がひとつの砂場の上で作業をします。
みんなでひとつのお城を作っていこうとしているわけです。
あるとき、ひとりのメンバーが「ここに跳ね橋をつけましょうよ」と言い出しました。
でも、他のメンバーは、それがそのお城にとって本当に有用なのかどうかがわかりません。
そのメンバー用に砂場の一角を隔離し、彼女にはそこで作業をしてもらう。
ブランチを作成するとは、そういうことになります。
もしうまい具合に跳ね橋が出来上がったら、
彼女は他のメンバーを呼び寄せてそれを見てもらいます。
みんなが納得するようなできばえであることがわかれば、
バージョン管理システムを使ってその跳ね橋をみんなのお城に移植
（"マージ"）するのです。
共同作業を進めるうえでこの機能がいかに有用かは、
言うまでもないことでしょう。この機能を使えば、
「他の人に迷惑がかからないかな？」
なんて気にせずに思う存分新しいことを試せるのです。
同じくらい重要なこととして、
バグ修正や安定版リリースのためのブランチを本流から隔離する
( の
と
を参照ください) ということがあります。
そうすれば、それぞれの流れを追いやすくなります。
偏見を捨て、ブランチを積極的に使うようにしましょう。
そして、他のメンバーにもブランチの使用を推奨しましょう。
しかし、不要になったブランチはいつまでも残しておかないようにしましょう。
ブランチが増えれば増えるほど、コミュニティー内での注目が散らばってしまいます。
そのブランチとは直接関係のない開発者であっても、
周りで起こっていることを気にせずにはいられないでしょう。
無理もありません。もちろん、
ブランチに対するコミットであってもコミットメールは同じように送ります。
しかし、ブランチは開発者のコミュニティーを分断する仕組みとなるべきではありません。
わずかな例外を除いては、
初期の目的を達成して本流にマージした時点でブランチを削除するようにしましょう。
情報の一元管理
ブランチが重要だということは、当然マージ処理も重要になってくるということです。
同じコミットを２回繰り返すなんていうことがないようにしましょう。
つまり、ある変更がバージョン管理システムに投入されるのは１回だけにしておくということです。
そうしておくことで、ある変更に対応するリビジョン（あるいはリビジョン群）
が一意に決まるようになります。その変更と同じ内容を別のブランチにも適用したい場合は、
そのブランチ上でもまったく同じように手を加えてそれをコミットするというのではなく、
最初の変更をマージするようにしましょう。
手作業で同じように修正したものをコミットしても結果は同じですが、
そうすると正確なリリース管理ができなくなります。
この件に関する実際のアドバイスは、
使用するバージョン管理システムによって異なります。
あるシステムでは、「マージ」は特別な処理として扱われ、
通常のコミットとは別のものとなります。
そして独自のメタデータを保持します。
また、システムによっては、
マージした結果を通常のコミットと同様に適用するものもあります。
このようなシステムでは、「マージした結果のコミット」と
「新しい変更のコミット」の区別はログメッセージで行います。
マージした際のログメッセージには、
元の変更の際のログをそのまま繰り返してはいけません。
そうではなく、「この変更はマージである」ことと、
どのリビジョンをマージしたのかを簡単に記述するようにします。
実際の変更内容を知りたければ、
マージ元のログメッセージを見るようにするわけです。
ログメッセージの重複を避けるのがなぜそんなに大事なのかというと、
ログメッセージは後から修正される可能性があるからです。
同じ内容のログを繰り返し記述していると、
だれかが元のログメッセージを修正したときに
コピー先のメッセージがそのままになってしまう可能性があります。
後から見たら、これは非常にややこしい状況になります。
同じ原則は、変更を取り消す (revert) 際にもあてはまります。
ある修正が廃案になったときのログメッセージは、
単にそれが revert されたということだけを記述します。
実際に何をどのように戻したのかまでを書いては
いけません。だってそれは、
もともとその変更を行った際のログを見ればわかることなんですから。
もちろん「なぜ」取り消したのかという理由の説明は必要でしょう。
しかし、元の変更の際のログメッセージを一言一句書き写す必要はありません。
できれば、元の変更の際のログメッセージも修正し、
それが結局取り消されたことを記述しておくとよいでしょう。
これまで説明してきたことからも何となくお分かりでしょうが、
特定のリビジョンを参照する際の表記方法は統一しておいたほうがいいでしょう。
これは、ログメッセージだけでなくメールやバグ追跡システムなどでも同じです。
CVS を使っているのなら、
"path/to/file/in/project/tree:REV"
という形式をお勧めします。ここで、REV は CVS のリビジョン番号
(たとえば "1.76" など) を指します。
Subversion を使っているのなら、(たとえばリビジョン 1729 の場合の)
標準の表記法は "r1729" となります (ファイルのパスは不要です。
Subversion はリポジトリ全体でリビジョン番号を管理するからです)。
それ以外のシステムでもきっと、
チェンジセットを表すための標準形式があることでしょう。
ともかく、メンバーには標準の形式を使ってもらうようにしましょう。
この表記法を統一しておくと、後からプロジェクトの流れを追うのが簡単になり
( や
で説明します) ます。
これらの管理を行うのはたいていはボランティアなので、
できるだけ簡単に進められるようにしておくことが重要です。
の
もご覧ください。
承認
たいていのバージョン管理システムには、
特定のユーザーに対してリポジトリ内の特定の場所だけのコミットを許可したり
逆に拒否したりといったことをする機能があります。
「ハンマーを与えられたら、人はみんな周囲の釘を探すようになる」
という原則どおり、多くのプロジェクトでこの機能が使われてきました。
アクセス権を注意深く管理し、特定の場所にだけコミット権を与えて
他の場所は触らせないようにするといった具合です
(
の で、
コミット権の管理方法について説明しています)。
このように厳格に管理してしまえば、悪影響が出る可能性を減らせることでしょう。
しかし、もうすこし緩やかな方針でもかまいません。
プロジェクトによっては、緩やかな方針を採用しているものもあります。
たとえリポジトリの一部分のみへのコミット権を与えられたユーザーであっても、
設定上はリポジトリ全体を変更できる権限を与えるというものです。
ただ「コミットするのはこの範囲だけにしておいてね」とお願いするだけです。
こうしたところで、実害はないことを覚えておきましょう。
ふつうのプロジェクトなら、すべてのコミットは何らかの形でレビューされます。
誰かが予期せぬコミットをしたら、
それを見つけた人が何かコメントすることでしょう。
その変更を取り消すべきだと判断したのなら、やることは簡単です。
すべてバージョン管理されているのだから、
単にその変更を取り消せばいいだけのことです。
緩やかな方針にしておく利点はいくつかあります。
まず、ある開発者の権限を拡張する
（プロジェクトに長年かかわっていると、よくあることです）
場合に一切手間がかからないということです。
単に「今日からは、ここもコミットしていいよ」というだけで、
後はすぐにコミットできるようになります。
次に、より緻密な方法で権限の拡張ができるようになります。
一般に、エリア X のコミッターがエリア Y にもコミットしたいと考えた場合は、
まず Y に対するパッチを投稿してレビューしてもらうことになります。
すでに Y へのコミット権を持つメンバーがそのパッチをレビューして承認したら、
パッチを投稿した人に対して「直接コミットしてもいいよ」と伝えます
(もちろん、誰がレビューして承認したのかという情報は
ログメッセージに残しておきます)。
この方法だと、実際にパッチを書いた人がコミットをすることになります。
これは、情報管理の面でも功績をたたえる意味でも重要です。
最後に、最も重要なのが、この緩やかな方式を採用すると
お互いに信頼し、尊重しあう空気が生まれるということです。
この方式の場合、「君はこの部分にコミットする能力があることがわかった。
ぜひコミットしてくれ」というようにとられます。
厳格に管理してしまうと「君のできることには制限があるんだ」
ということを強調するだけでなく
「間違って変なことをしてしまわないかどうかが心配なんだ」
と疑っているように感じられてしまいます。
できればこのようなことは避けたいでしょう。
だれかを新たにコミッターとして迎え入れるということは、
みんなの信頼の輪の中に新しいメンバーを加えるということです。
その際には、本来必要なもの以上の力を与え、
「それをどう使うかはあなたしだい。でもこれ以上のことはしないでね」
としたほうがいいでしょう。
Subversion プロジェクトでは、かれこれ 4 年以上この「緩やかな管理」
方式を採用しています。本書の執筆時点で、フルコミッターは 33 人、
一部にだけコミット権限のあるメンバーが 43 人います。
この管理方式では、システムが管理するのは「コミッターかそうでないか」
だけです。その詳細 (どの部分にコミット権があるかなど) は人間が管理します。
今のところ、コミット権のない部分について故意にコミットするなどといった
問題は発生していません。コミット権に関する誤解が生じたことも何度かありましたが、
いつも速やかに円満解決していました。
このような自己管理方式が明らかに現実的でない場面もあるでしょう。
当然、そんな場合は厳格な管理が必要となります。
とはいえ、そんな状況はまれです。
たとえ何千人の開発者が何百万行のコードを扱っていたとしても、
そのコードに対するすべてのコミットはだれか他の人によるレビューを受けます。
おかしなコミットがあればすぐに指摘されるでしょう。
もしコミットをレビューしあう習慣ができていないのなら、
それは認証システムがどうのこうのいう以前の問題です。
まとめると、よっぽどの理由がない限りは
バージョン管理システム上のアクセス権限にあまり気を使う必要はないということです。
厳密に管理したところで得られる具体的なメリットはあまりありません。
それより人間による管理に頼ったほうが得られるものは多いでしょう。
もちろん、制限をすること自体が無意味だといっているわけではありません。
権限のないところへコミットさせるようなことは、あまりしたくないでしょう。
さらに、多くのプロジェクトでは「フルコミッター (制限のないコミッター)」
には何らかの特権 (たとえばプロジェクトの運営に関する投票に参加できるなど)
が与えられています。コミット権の扱いに関する政治的な意味合いについては
の で詳しく説明します。
バグ追跡システム
バグ追跡 が扱う範囲は多岐にわたります。
この本ではバグ追跡についての様々な側面を議論しています。
ここでは バグ追跡システムをセットアップすることと、
その作業に関する技術的な考察に集中しようと思います。
その話題に入る前に、バグ追跡の方針に関する質問から始めましょう。
具体的にどの情報をバグ追跡システムに保存すべきなのでしょうか?
バグ追跡システム は、誤解を招きやすい用語です。
バグ追跡システムは、新しい機能要望や、一度限りのタスク、
送られてきたパッチ — はじまりと終わりの状態があるすべてのもの、
存在している間に情報が発生するすべてのものを追跡するためによく使われます。
このため、バグ追跡システムは、
問題追跡システム、
不具合追跡システム、
影響追跡システム、
要望追跡システム、
チケットシステム などとも呼ばれています。
バグ追跡システムのソフトウェアの一覧は、 を参照してください。
この本では "バグ追跡システム" という用語を、
バグを追跡するソフトウェアを指すものとします。
なぜなら、殆どの人がバグ追跡システムと呼んでいるからです。
しかし、バグ追跡システムのデータベースに登録される個々のアイテムを指すものとして、
問題 という用語を使います。
これによってユーザーが遭遇するソフトウェアの変な振る舞い（つまり、バグです）と、
バグの発見、診断、解決の 記録 を区別できるからです。
殆どの問題は実際に起こったバグに関するものですが、
他のタスクに関することでも問題という用語が使えるということを覚えておいてください。
問題の典型的なライフサイクルは次のようなものです。
誰かが問題をバグデータベースに記録します。
この記録には、問題の要点、問題の説明(もしあれば、
問題を再現させるための手順も。
ユーザーに優れたバグ報告をさせる方法については、
の を参照してください)
、バグ追跡システムが求めているその他の情報が全て含まれています。
問題を報告した人は、プロジェクトについて全く知らないかもしれません。—
ユーザーのコミュニティーと開発者達から、同じくらいの割合でバグ報告や機能要望があがってきます。
いったん問題が報告されると、その問題は 保留中 の状態にあるといいます。
なぜなら、それに対して何らアクションがとられていないからです。
システムによっては、
未確認 とか 未着手 といったラベルを付与するものもあります。
まだ誰もこの問題を担当していません。システムによっては、
担当が決まっていないことを表すためにダミーの担当者を割り当てるものもあります。
この時点では、問題は一時的な領域に置かれています。つまり、
システムに記録されてはいるが、プロジェクトがまだ関心を持っていないということです。
誰か他の人が問題を読み、コメントを付けます。
おそらく問題を報告した人に、不明な点について説明を求めるでしょう。
問題はやがて 再現済み という状態になります。
これは問題のライフサイクルの中で最も重要かもしれません。これは、
まだ解決されたわけではないが、
報告した人以外の誰かが問題を再現でき、
この問題が本物だと証明したことをいいます。
そして同じくらい重要なことですが、
報告した人が本物のバグを報告することで、
プロジェクトに貢献したと確認することでもあります。
そして 診断済み という状態になります。
問題の原因が特定され、可能なら解決に必要な労力が見積もられます。
これらのことは必ず追跡システムに記録するようにしましょう。
原因を調べた人が突然しばらくプロジェクトを離れなければならない（これはボランティアの開発者にはよくあることです）場合に、
誰かが穴を埋められるようにしておくべきだからです。
この段階か、もうひとつ前の段階で、
開発者が問題を "自分が解決することにして"、 自分自身を 担当者にする するかもしれません。
(担当者を決める手続きをさらに詳細に調べるには
の 、
を参照してください)
この段階で、問題に優先度 も割り当てられるかもしれません。
たとえば、問題がとても深刻なので解決は次のリリースにまわすべき場合、
その事実は早い段階で確認する必要があります。
よって、追跡システムはそれを記録する何らかの方法を備えるべきということになります。
問題をいつ解決するかという予定が立てられます。
予定を決めるということは、
いつまでに直すという日程を決めることとは限りません。
将来のどのリリース（次のバージョンとは限りません）で直すかを決めるだけのこともありますし、
特定のリリースで直すと決めない場合もあります。
バグが素早く直せる場合には、予定を立てないこともあります。
問題が解決されます。（タスクが終了したり、
パッチが適用されたりとか、そういったものです）
行った変更は、問題の 処理が済んだ り、
解決済み とマークされたあとに、
コメントとして記録するようにしましょう。
問題のライフサイクルには共通のバリエーションがいくつかあります。
問題によっては、バグではなくユーザー側が誤解していたという理由ですぐに処理済みとされることがあります。
プロジェクトが多くのユーザーを獲得するにつれ、
バグではない問題が報告される回数も増えていき、
開発者は次第にぶっきらぼうな返事をして問題を処理済みとするようになります。
こういう風潮にならないよう努力しましょう。
ぶっきらぼうに問題を処理済みにしてもいいことは何もありません。
バグではない問題を報告したユーザ－は、以前報告された問題には何の責任もないのですから。
それに報告される問題が統計的にどういった傾向にあるかは、
開発者のみわかることで、ユーザーにはわからないことです。
(この章の後半の で、
バグではない問題の数を減らすテクニックについて見ていきます)
また、異なったユーザーが繰り返し同じような誤解をする場合は、
誤解を生む部分を再設計する必要があるということかもしれません。
この手のパターンはバグデータベースを監視する問題管理システムがあれば簡単に見つかります。
の、
を参照してください。
別のバリエーションとして、
1. のすぐ後で問題が 重複している として処理済みにされる場合があります。
重複した問題は、プロジェクトが既に認識している問題を誰かがまた報告すると発生します。
重複した状態は 保留中 の問題で発生するとは限りません。
解決したあとで再び報告される(この状態を リグレッション（回帰） と呼びます)こともあります。
こういう場合は、重複の元となった問題を 再度保留中の状態にして、
重複した問題は処理済みにしてしまうのが普通は望ましいでしょう。
バグ追跡システムは、
問題を再現する情報ははじめに報告された問題で見られるように（逆も同様）、
問題同士の関連を追跡しているはずです。
開発者が問題を処理済みにする3つ目のバリエーションは、
問題を解決したと思い込んで処理済みにするパターンです。
これは結局、問題を報告した人がそれを拒んで再度保留中にする結果になります。
これは開発者が単にバグを再現するのに必要な環境にアクセスできないか、
問題を再現する手順に正確に従ってテストをしなかったために発生します。
これらのバリエーションのほかにも、
バグ追跡システムによって細かい部分が変わる場合はありますが、
基本的なパターンは同じです。
問題のライフサイクルそのものもオープンソースソフトウェアに特有のものではありませんが、
オープンソースプロジェクトのバグ追跡システムの使い方に影響を与えています。
1. が暗に示すとおり、
バグ追跡システムはメーリングリストやウェブページと同様プロジェクトの顔です。
誰でも問題を報告し、調べることができますし、現在保留中とされている問題の一覧を見ることができます。
よって、報告されている問題の進捗を何人の人が知りたがっているのかが、
開発者にはわからないということになります。
問題が解決される割合は開発者コミュニティーの規模やスキルに左右されますが、
プロジェクトは少なくとも問題が報告されたらすぐにそれを認識しようとすべきです。
たとえ問題が解決されずにしばらく残り続けても、
開発者が返答すると、問題を報告した人は引き続き参加したいと考えます。
なぜなら、自分がやったことが認められたと感じるからです。(問題を報告することは、
たとえば電子メールを送ること以上に労力がいることを思い出してください)
それ以上に、問題をいったん開発者が見れば、
報告された問題の他の事例に注意を払ったり、他の開発者と話し合える、などの意味で、
プロジェクトが問題を認識したことになります。
適切なタイミングで問題に応答するには、次の二つが必要です。
バグ追跡システムをメーリングリストと接続しなければいけません。
これは、問題を報告することを含めた、問題の状態を変更するあらゆる行動が、
メールで投稿されるようにするためです。
このメーリングリストは通常使う開発用のものとは違うのが普通です。
なぜなら、開発者全員が自動送信されるバグ報告メールを受け取りたいとは限らないからです。
しかし、(コミットメールと同様に) Reply-to ヘッダは開発用のメーリングリストのアドレスに設定しておきましょう。
問題を報告するときの記入フォームは、
報告する人の電子メールアドレスの欄にフォーカスを当てておくべきです。
(しかし、匿名で報告したいと思う人もいるので、
電子メールアドレスを 必須 にすべきではありません。
匿名の重要性については、
この章の後半にある を参照してください。
議論の場としてメーリングリストを使う
バグ追跡システムがディスカッションフォーラムにならないようにしましょう。
バグ追跡システムに人間が顔を出し続けることは大事ですが、
それがリアルタイムに議論するのに適しているわけではありません。
バグ追跡システムは、起こった事実や他の議論に対する参照、
メーリングリストで起きた議論をまとめるアーカイバと考えるようにしましょう。
こうした区別をするのはふたつの理由があります。
ひとつめは、バグ追跡システムがメーリングリストに比べて（ついでにいうと、リアルタイムに会話ができるチャットシステムと比べても）使いにくいからです。
これはバグ追跡システムのインターフェイス設計が悪いからではなく、
単にメーリングリストやチャットシステムが、連続していない状態、つまり自由に流れていく議論を取り込めるように設計されているからです。
ふたつめは、ある議論に参加している人が、
バグ追跡システムを見ているとは限らないからです。
よい問題管理のやり方( の、 を参照してください)は、
開発者全員に起こっている問題全部を追いかけさせるのではなく、
適切な人の注意をひくようにすることです。
の では、
適切なフォーラム以外に偶然議論が波及しないようにする方法や、
バグ追跡システムに議論を持ち込まないようにする方法を見ていきます。
バグ追跡システムによっては、メーリングリストをモニタし、
既知の問題に関する電子メールを全て自動的に記録するものがあります。
通常、こうしたシステムはメールの件名の行にある問題の番号を、
特別な文字列として認識することでこれを行います。
開発者達は、バグ追跡システムの注意を引くために、
電子メールにこうした文字列を含めることができるようになります。
バグ追跡システムに電子メール全体を記録させてもいいですし、
(よりよいのは)通常のメーリングリストのアーカイブにあるメールへのリンクを記録させてもよいでしょう。
どちらの方法でも、これはとても役に立つ機能です。
あなたが使っているバグ追跡システムにこの機能があるなら、
それを有効にして人々が利用するように知らせておきましょう。
バグ追跡システムをあらかじめフィルタする
ほとんどのバグ追跡システムは結局同じ課題に悩まされます。
バグを報告した経験が少なかったり、
肝心な部分を知らない善意のユーザーが、
既に報告されている問題やバグではない問題を大量に報告してくるのです。
この傾向に対処するはじめのステップとして、
バグ追跡システムのトップページに目立つように注意書きを置いておく方法があります。
そこで本当にバグかどうかを区別する方法や、
既に報告されている問題かどうかを検索する方法、
そして最後に、本当に新規のバグであった場合に効果的に報告する方法を説明しておくのです。
こうすることでしばらくは報告されてくる問題のノイズは下げられますが、
ユーザーが増えてくるにつれてこの課題は結局再燃します。
このことでユーザーを責めることはできません。
ひとりひとりのユーザーはただプロジェクトをよくするために貢献しようとしているだけですし、
たとえ彼らのバグ報告がはじめは役に立たなかったとしても、
あなたは彼らにひき続きプロジェクトに参加してもらって、
将来はよりよいバグ報告をして欲しいと思うでしょう。
しばらくの間は、バグ追跡システムに自由にバグを報告させ続ける必要があります。
この課題を避けるために何より実行すべきことがふたつあります。
バグではない問題や、
重複したバグ報告を報告されたらすぐに 処理済みとマークできる十分な知識がある人にバグ報告システムを見張ってもらうこと。
そしてバグ報告システムにバグを報告する前に、
他の人とバグかどうかを確認するようユーザーに求める（または強く勧める）ことです。
はじめのテクニックはあらゆるところで使われているようです。
巨大なバグデータベースを持つ（たとえば にある Debian のバグ追跡システムは、執筆時点で 315,929個 のバグ情報があります）プロジェクトでも、バグが報告されるたびに 誰かが 見張るようにシステムを改造しています。
問題のカテゴリによって見張る人は違うかもしれません。
たとえばDebianプロジェクトはソフトウェアパッケージの集合体なので、
自動的にそれぞれの問題を適切なパッケージメンテナーに転送しています。
もちろん、ユーザーがときどき問題のカテゴリを誤解することもありえます。
そういう場合は、そのバグははじめは間違った人に転送されるので、
転送された人が再度転送し直さなければなりません。
しかし重要なのは、その負担が共有されているということです
— ユーザーがバグを報告するときに正しいか間違っているかを推測しようがすまいが、
報告されたバグを見張る役目は多かれ少なかれ開発者に分散されています。
よって問題が報告されるたびに、適切なタイミングで応答できるのです。
ふたつめのテクニックは広く使われているわけではありませんが、
これはおそらく自動化が難しいからでしょう。
アイディアの要点は、新しく報告されてくる問題をデータベースに登録する前に、
"仲間を" 巻き込むことです。
ユーザーが問題を見つけたと思ったときは、
メーリングリストかIRCで説明するように求めます。
そうすることで、誰かが本当にバグかどうかを確認するのです。
別の人の目に早めに晒すことで、たくさんの間違った報告を避けることができます。
別の人がその振る舞いはバグではないとわかったり、
最近のリリースで解決済みだとわかる場合があります。
または、別の人が以前報告された問題から報告されるバグの兆候に精通しているので、
古い問題であるとユーザーに指摘することで重複した報告を防ぐことができる場合もあります。
"既に報告された問題かどうかをバグ追跡システムで検索したかい?"
とユーザーに聞くだけで十分なこともあります。
多くの人はそんなことを考えてもいませんが、
誰かがそうすることを 期待している とわかれば、
喜んで検索するものです。
仲間を巻き込む仕組みはバグデータベースをきれいにしてくれますが、
欠点もいくつかあります。
多くの人が、新しくバグを報告するときに仲間を見つけなさいという指示を見ないか、
軽視するかして、結局ひとりでバグ報告をしてしまうことです。
よって、ボランティアにはやはりバグデータベースを見張ってもらう必要があります。
さらに、ほとんどの新しい報告者はバグデータベースを維持するのがどれだけ難しいかを知らないので、
ガイドラインを無視しているからといって厳しく注意するのはフェアではありません。
よってボランティアは、
誰にも見てもらっていないバグ報告を報告者にどう差し戻すのかについては、
用心深く、なおかつ慎重でなければなりません。
これは、問題をフィルタする仕組みを理解する人々を増やせるように、
ゆくゆくは仲間を巻き込んでバグ報告をしてもらうことが目的です。
誰にも見てもらっていないバグ報告を見つけたら、
とるべき理想的な対処のステップは次のようなものです。
すぐにバグ報告に応答し、
ユーザーがバグ報告をしてくれたことに丁寧にお礼を言います。
しかし、バグかどうかを誰かに見てもらうガイドラインがあることを指摘します。（これはもちろん、ウェブサイトに目立つように投稿すべきです）
報告された問題が明らかに正しいもので重複していない場合は、
とりあえずそれを受け入れて通常のライフサイクルを開始します。
結局、報告した人はバグかどうかを誰かに見てもらうべきだと言われているので、
正しいバグ報告を処理済みにするまで労力を無駄にする点はありません。
そうでない場合、つまり報告された明らかに正しくない場合は処理済みとマークしましょう。
しかし、報告した人には誰かにバグであるかを確認した上で報告したのなら、再度保留中にして欲しいと伝えます。
この場合、報告した人は確認をとったスレッドへの参照（e.g. メーリングリストアーカイブへのURLなど）を掲載するはずです。
この方法はいずれバグ追跡システムの S/N比を改善してくれるでしょう。
しかし、間違ったバグ報告は決してなくならないことを覚えておいてください。
間違ったバグ報告を根絶する唯一の方法は、
開発者以外の人にはバグ追跡システムを使わせないことです —
しかし、この方法でよい結果が出ることはほとんどありません。
間違ったバグ報告を取り除くことがプロジェクトのルーチンワークであることを受け入れ、
できるだけ多くの人達の助けを得ようとした方がよいでしょう。
の も参照してください。
IRC / リアルタイムに行なわれるチャットシステム
多くのプロジェクトでは、Internet Relay Chat (IRC) を使ったリアルタイムのチャットルームを提供しています。
そこではユーザーと開発者が質問を出し合い、すぐに返事を貰うことができます。
自前のIRCサーバを動かすことも 可能です が、
普通はそこまで頑張る必要はありません。むしろみんながやっていることを真似てみましょう。
つまり、Freenode () で自分のIRCチャンネルを開設するのです。
Freenodeは、IRCサーバを自分で管理する苦労からあなたを解放すると同時に、
Freenode への寄付を要求されたり、
期待されたりすることはありませんが、
あなた個人やプロジェクトに余裕があるなら寄付することを考えてみてください。
アメリカ国内からだと税金が控除される寄付金として扱われますし、
寄付されたお金を使って価値のあるサービスが提供されるのです。
プロジェクトのIRCチャンネルを管理するために必要な規制を行っています。
まずやるべきことはチャンネルの名前を決めることです。
もっともわかりやすいのはプロジェクトの名前です。
— Freenode で使える名前なら使ってください。
もし使えないのなら、
プロジェクトの名前に近い名前で、
できるだけ覚えやすい名前を選ぶようにしてみてください。
質問に素早く答えて欲しいユーザーがすぐにわかるように、
プロジェクトのウェブサイトでIRCチャンネルが利用できることを知らせましょう。
たとえばSubversion のホームページでは、
ページ上部の目立つボックス部分に次のような情報を表示しています。
Subversionをお使いなら、メーリングリスト
users@subversion.tigris.org
を購読し、
Subversionによるバージョン管理 と
FAQ
を読むことを勧めます。
IRCの
irc.freenode.net
上のチャンネル
#svn
でも質問することができます。
プロジェクトによっては複数のチャンネルを持つものもあり、
ひとつひとつが副次的なトピックを扱っています。
たとえばあるチャンネルはインストール時の問題を扱い、
別のチャンネルでは使い方の問題、開発に関するチャット、等です。
( の では、チャンネルを複数に分割する方法について議論しています。)
プロジェクトが始まって間もないなら、皆が一緒にお喋りできるようにチャンネルの数はひとつにすべきでしょう。
後に開発者ひとりに対するユーザーの数が増えるのに応じて、
チャンネルの分割が必要になるかもしれません。
どのチャンネルで喋ればよいかは言うまでもなく、
利用できる全てのチャンネルを知らせるにはどうしたらよいでしょうか?
そしてチャットをするとき、
プロジェクトに特有の決まりごとを知らせるにはどうすればよいでしょうか?
答えは チャンネルトピック
チャンネルトピックを設定するには /topic コマンドを使います。
IRCコマンドは全て "/" で始まります。
IRCの使い方やチャンネルの管理に慣れていないのであれば、
を参照してください。:
特に は優れたチュートリアルです。
を設定して知らせることです。
チャンネルトピックは、初めてチャンネルに入ったときにユーザーが見るメッセージです。
これは新顔のユーザーに簡単な案内をすると同時に、
さらに詳しい情報へのポインタを提供します。
たとえば以下のようなものです。:
あなたは #svn で喋っています。
#svn のトピックは以下の通りです。Subversionユーザーの質問を受け付ける
フォーラムです。http://subversion.tigris.org も参照してください。 ||
開発に関する議論は、#svn-dev で行われています。 || 長い Subversion の
トランザクションを貼り付けないでください。http://pastebin.ca/ のような
貼り付け用のサイトを使ってください。 || ニュース: Subversion 1.1.0 が
リリースされました。詳しくは http://svn110.notlong.com/ を参照してくだ
さい。
これは簡単ですが、新顔のユーザーが知る必要がある情報を伝えています。
チャンネルの目的を正確に伝え、
プロジェクトのホームページを示し(ユーザーによっては、
プロジェクトのウェブサイトを訪れたことがないとチャンネル内で迷子になってしまいます。)
関連するチャンネルに言及し、貼り付けに関する案内もあります。
貼り付け用のサイト
IRCチャンネルは共有スペースです。誰でも他人の発言を見ることができます。
これは貢献したいと思うときに会話に割って入れますし、
他のメンバーはやりとりを見て学ぶことができるので普段はよい状態です。
しかしデバッグセッションのコピーのように、
大量の情報を一度に流さなければならない場合は問題になります。
なぜなら、チャンネルにあまりに多くの行を貼り付けると他の会話をぶち壊してしまうからです。
こうした問題の解決策は、
ペーストビン または ペーストボット サイトを使うことです。
大量のデータを他人から見てほしいと頼まれる時は、
チャンネルに貼り付けないで、
(たとえば) に行き、
フォームにデータを入力して生成されたURLをチャンネルに伝えるように頼みましょう。
そうすれば、そのURLを誰でも訪れてデータを見ることができます。
今ではたくさんの貼り付けサイトが無料で利用できますし、
まとめて示すには数が多すぎますが、
私が使われているのを見たことがあるサイトをいくつか以下に示します:
,
,
,
,
,
,
ボット
多くの技術指向なIRCチャンネルには、
いわゆる ボット と呼ばれる人間でないメンバーがいます。
これは特定のコマンドに反応して情報を保存したり、
表示したりできます。
通常は、ボットはチャンネルにいる他のメンバーと同じように扱います。
つまり、コマンドはボットに "話しかける" ことで伝えます。
たとえば次のようなものです :
<kfogel> ayita: learn diff-cmd = http://subversion.tigris.org/faq.html#diff-cmd
<ayita> Thanks!
これはボット(ayita としてチャンネルにログインしています)に "diff-cmd" という問い合わせの答えとしてあるURLを覚えておくように伝えています。
では、ayita に話しかけて、他のユーザーに diff-cmd に関する情報を伝えるように頼んでみましょう :
<kfogel> ayita: tell jrandom about diff-cmd
<ayita> jrandom: http://subversion.tigris.org/faq.html#diff-cmd
便利な短縮コマンドを使っても同じことが実現できます。
<kfogel> !a jrandom diff-cmd
<ayita> jrandom: http://subversion.tigris.org/faq.html#diff-cmd
正確なコマンドとそれに対する振舞いはボットによって異なります。
上の例は Freenode の #svn で通常動いている ayita() のものです。
他にも Dancer() や Supybot() といったボットがいます。
ボットを動かすのに特別なIRCサーバ上の権限は必要ないということを覚えておいてください。
ボットはクライアントプログラムなので、誰でもセットアップして特定の IRCサーバ/チャンネル 上で待機させることができます。
あなたのチャンネルで同じ質問が繰り返される傾向があるなら、
ボットをセットアップすることを強くお勧めします。
ボットの操作方法を身に付けるのはほんの一握りのメンバーですが、
ボットが効率的に反応してくれるので、
少ない人数で繰り返される質問に答えられるのです。
IRCの会話を保存する
IRCチャンネルで起こったことは全て保存できますが、
必ずしもそれが期待されているわけではありません。
IRCでの会話は建前上は公なものかもしれませんが、
非公式なもの、もしくは半ばプライベートな会話だと考える人も多くいます。
IRC上ではユーザーは文法に無頓着ですし、
オンライン上で絶対に保存されたくない意見(たとえば、
他のソフトウェアやプログラマーに関するもの)を言ったりするかもしれません。
もちろん、会話のまとめ を保存すべき時もあるでしょう。
その場合はよいのです。
ほとんどのIRCクライアントはユーザーの要求に応じて会話を保存することが出来ますし、
それができなくても会話をフォーラム(ほとんどの場合はバグ追跡システム)に貼り付けるだけならいつでもできます。
しかし、節操なく会話を保存すると不安になるユーザーもいるかもしれません。
全ての会話を保存するのなら、必ずその旨をチャンネルトピックで明示的に宣言し、保存先のURLを示すようにしましょう。
Wiki
wiki とは、
訪れた人が誰でもコンテンツを編集し、
拡張できるウェブサイトのことです。
"wiki" (ハワイ語で "素早い" とか "超高速の"という意味です）という用語は、
ウェブサイトの編集ができるソフトウェアを指すものとしても使われています。
wiki は1995年に発明されましたが、
2000年か2001年に人気が出て、
wiki ベースな無料の百科事典である Wikipedia() の成功がそれを後押ししました。
wiki は、IRCとウェブサイトの中間的なものと考えればよいでしょう。
wiki は即時性がないので、
自分が更新する内容について推敲することができます。
それでいて更新も非常に簡単なので、通常のウェブサイトを編集するのに比べて、
HTMLに悩む負担が小さくなっています。
wiki はまだオープンソースプロジェクトで標準的なツールになっているわけではありませんが、
多分すぐにそうなるでしょう。
wikiは比較的新しい技術ですし、
人々は wiki をいろいろなやり方でまだ試しているところです。
よって—今の段階では、
2,3警告をするだけにしておいて、
wiki の成功を分析するよりは、
wiki の間違った使い方を分析する方がわかりやすいでしょう。
wiki を使おうと決めたら、
見通しの良いサイト構成にすることと、
魅力的な見た目になるように特に力を注ぎましょう。
これは訪問者（i.e. 編集する可能性がある人でもあります）が無意識にどのように編集したらよいかがわかるようにするためです。
同じく重要なのは、
人々を誘導できるように、
こうした見た目やサイト構成に関する基準を wiki に投稿しておくことです。
よくあるのは、
wiki の管理者が、
「多くの訪問者が高い品質のコンテンツを個別に追加してくれているんだから、
こうした更新が集まったウェブサイト全体も高い品質であるに違いない」という幻想に堕ちてしまうことです。
多く更新されているからといって、
ウェブサイトがうまく機能するわけではありません。
個々のページや段落は、
それ自体素晴らしいものかもしれませんが、
全体が混乱したり、
まとまっていないウェブサイトに紛れ込んでしまうと、そうではなくなるでしょう。
wiki を使うと、
次のような事態によく悩まされます。
読者を誘導するルールが欠けている
うまく構成されたウェブサイトは、
訪問者がいつでもサイト内のどこにいるかをわかるようにしています。
例えば、ページがうまく設計されていると、
訪問者は"目次"の部分と、"内容"の部分を直感的に区別できます。
wikiのページを更新する人も、
はじめからそういった区別がされていれば、それを尊重することでしょう。
情報が重複している
wikiでは、更新を行なう個々の人達が、
情報が重複しているかを気にしないので、
似たようなことを述べている異なったページが複数存在することがよくあります。
これは、上で述べた読者を誘導するルールが欠けていることとも重なる部分がありますが、
情報が重複していると、
訪問者は自分が期待するコンテンツのありかを見つけられないかもしれません。
対象読者が決まっていない
これは、更新を行なう人が多くいる場合にはある程度避けられない問題です。
しかし、コンテンツを追加する方法の指針があれば、
この問題で苦しむ可能性は少なくなるかもしれません。
また、更新に関する指針が根付くように、
はじめから例としてコンテンツをたくさん追加しておくのもよいでしょう。
こうした問題に対する共通の解は同じです。: 編集に関する指針を作り、
その指針を wiki に投稿するだけではなく、
それに従ってページを編集することです。
一般に wiki は、更新する人が自分が見るページのあらゆる傾向を真似てしまうため、
もともと存在するページのあらゆる不備が全体に伝染してしまいがちです。
wiki をただセットアップするだけで、全てうまくいくと期待しないでください。
まずは、人々を誘導するテンプレートとなるように、
よく練られたコンテンツを置いておかなければならないのです。
うまくいっている wiki の良い例は Wikipedia ですが、これは、
（百科事典の項目という）内容が本来 wiki のフォーマットとよく合っているからというのが理由のひとつです。
しかし、Wikipedia をよく調べてみると、
管理者達が お互いが協力するためにとても周到に準備をしていることがわかるでしょう。
新しい項目を追加する方法、適切な観点で編集する方法、どのような編集を行なうべきか、避けるべきか、
編集合戦にまつわる論争を解決するプロセス（ある段階では、最終的な調停も含みます）、
などにまつわる外部文書が存在します。
管理者達は、繰り返し不適切に編集されたページがあった場合に、
問題が解決されるまでそれをロックできるようアクセス制御も行なっています。
言い換えれば、彼らはウェブサイトにページの雛形を書き込むだけで、
うまくいくと思っていたわけではないということです。
Wikipedia は、創始者達が、どうしたら何千ものどこの馬の骨ともわからない人たちに、
中立的な観点で記事を書かせることができるかを注意深く考えたからこそうまくいっているのです。
フリーソフトウェアのプロジェクトで wiki を使うのに、これと同じくらい周到になる必要はないかもしれませんが、
その精神は真似る価値があります。
wikiに関するさらに詳しい情報は、 を参照してください。
また、世界で最初のwikiはまだ健在で、wikiの運用に関する多くの議論が含まれています。
: 様々な観点から、,
, そして
を参照してみてください。
ウェブサイト
技術的な観点からプロジェクトのウェブサイトを立ち上げることについては、
それほど語ることはありません。ウェブサーバを起動し、
ウェブページを書くことはかなり単純な仕事ですし、
ページの配置や設計に関して重要なことはほとんど以前の章で述べました。
ウェブサイトの主な機能は、明快にプロジェクトの概要を提供し、
(バージョン管理システム, バグ追跡システムなどの)他のツールをウェブサイトと結びつけることです。
たとえあなたにウェブサーバを設定して起動する技量がなくても、
その作業を喜んでやってくれる人を探すことは普通難しくありません。
とはいえ、時間と労力を節約するために、
プロジェクトを運営するためのツールが一通り揃っているホスティングサイトがよく好んで使われます。
ツールが一通り揃ったホスティングサイト
一通りのものが揃ったホスティングサイトには、主に二つの利点があります。
ひとつめは、サーバのディスク容量とネットワーク帯域の太さです。つまり、
超高速なネットワーク上に、複数のサーバマシンが巨大なラックに収納されているのです。
プロジェクトがどれだけ成功しても、ディスク容量を使い切ったり、
ネットワーク接続が使い物にならなくなることはないでしょう。
ふたつめは、サイトの維持が簡単なことです。
ホスティングサイトは、バグ追跡システム、バージョン管理システム、
メーリングリスト管理システム、アーカイバや、
プロジェクトのウェブサイトを運営するのに必要ものを全て選んでくれています。
また、それらは既に設定済みであり、蓄積される全てのデータのバックアップにも注意を払ってくれます。
多くの決断をする必要はありません。フォームに入力し、ボタンを押しさえすればよいのです。
そうすれば巨大なプロジェクト用ウェブサイトが突然手に入ることでしょう。
これらはとても重要な利点です。勿論、他のツールでよいものがあったとしても、
ホスティングサイトが 選択したツールや設定を受け入れなければならないという欠点があります。
ホスティングサイトは、設定できるパラメータの範囲を普通狭くしているので柔軟性がありません。
自前でウェブサイトを立ち上げてサーバへの完全な管理権限を持っていた場合にできる、
きめの細かい制御は決してできないでしょう。
このことのよい例が、自動生成されるファイルの扱いです。
あるプロジェクトのウェブページは、自動生成されたファイルかもしれません —
たとえば、FAQのデータを編集しやすいマスターフォーマットに保存し、それからHTMLやPDF、
その他表示用のフォーマットを生成するシステムがあるとします。
この章の で説明したとおり、
あなたは自動生成されたフォーマットではなく、
マスターファイルだけをバージョン管理したいと考えるでしょう。
しかしウェブサイトが他人のサーバに置いてある場合は、
マスターファイルが変更された場合にFAQのHTML版を再生成するカスタムフックを設定できないかもしれません。
唯一の回避策は、ウェブサイトで表示できるように自動生成されたフォーマットもバージョン管理することです。
もっと大きな影響があるかもしれません。
あなたが望むほどウェブサイトの見た目を変える権限がないかもしれません。
ホスティングサイトの中には、ウェブページをカスタマイズすることを許可してはいますが、
結局はデフォルトの配置がうんざりするようなやり方で表示されてしまうものもあります。
たとえば、SourceForge がホスティングしているプロジェクトの中には、
完全にカスタマイズしたホームページがあるけれども、
詳しい情報を参照させるために "Sourceforge上のページ" に開発者を誘導しているものがあります。
SourceForge のページは、プロジェクトのホームページになるはずのものでしたが、
ユーザーに自前のホームページを使わせないようにしています。
SourceForge のページには、バグ追跡システムやCVSリポジトリ、ダウンロードサイトへのリンクなどがあります。
不幸なことに、SourceForge のページにはたくさんのプロジェクトとは無関係なリンクも含まれているのです。
ページの一番上部にはバナー広告がありますが、アニメーション画像であることもよくあります。
左側にはプロジェクトに興味がある人には殆ど関係がないリンクが垂直に配置されています。
右側には別の広告がよく配置されています。
ページの中央部分だけが本当にプロジェクトに特有の事項に専用の場所になっていますが、
これらもわかりにくい方法で配置されているので、
訪問者が次にどこをクリックしたらいいのかわからなくなってしまうことがよくあります。
SourceForge のページ設計の裏には、きっと — 広告のように、
SourceForge の立場からすれば尤もな理由があるのでしょう。しかし、
プロジェクトの立場から見れば、その結果が理想のウェブページとはかけ離れたものになるかもしれません。
私は SourceForge を非難するつもりで言っているのではありません。
似たような懸念は多くのホスティングサイトにも当てはまります。
重要なのは、トレードオフが存在するということです。
プロジェクトのウェブサイトを維持するための技術的な重荷から解放されますが、
他人のやり方を受け入れることとひきかえにはじめて恩恵を受けられるのです。
ホスティングサイトがプロジェクトに最適かどうかを決められるのはあなただけです。
仮にホスティングサイトを選んだ場合、プロジェクトの"ホームとなるURL"に自前のドメインを使うことで、
自前のサーバに移行する余地を残しておくようにしましょう。
自前のURLをホスティングサイトに転送することもできますし、
公開されているURLに完全に手を加えたホームページを置くことで、
ユーザーを洗練された機能を持ったホスティングサイトに誘導することもできます。
ウェブサイトのホスティングについて後に別の解を選んだとしても、
プロジェクトのURLは変えないように確実に準備をしておくようにしましょう。
ホスティングサイトを選ぶ
2011年が始まった現時点で、自由につかえるホスティングサイトとして定評のあるのは次の三つです。
これらはすべて、オープンソースライセンスで公開するプロジェクト用に無料で使うことができます。
また、バージョン管理システムやバグ追跡システム、そして Wiki も用意されています
(バイナリのダウンロード機能など、その他の機能を用意しているところもあります)。
GitHub
対応しているバージョン管理システムは Git だけですが、もし自分のプロジェクトで
Git を使っているのならここを選ぶのが適切でしょう。GitHub
は Git を使ったプロジェクトの世界の中心となっており、
各種サービスも Git と統合されています。
また GitHub には、プログラムからそのサービスを利用するための
API も完備されています。
メーリングリストはありませんが、メーリングリストのサービスは他にもいろいろあるので
たいした問題にはならないでしょう。
Google Code Hosting
対応しているバージョン管理システムは Subversion と Mercurial (少なくとも現時点では Git は未対応) で、
Wiki やダウンロードエリア、そしてよくできたバグ追跡システムも用意されています。
また、API もあります。バージョン管理システムには当然ながらそれ自身の API があり、問題追跡システムにも
専用の API があります。Wiki のコンテンツは バージョン管理システムと連動 しているので、スクリプトから編集することができます。
また、ダウンロードエリアにも スクリプトによるアップロード という名の API が用意されています。
また、メーリングリストとして Google Groups が使えます。
SourceForge
これは最も古くからあるホスティングサイトで、古くからあるだけあって今でも規模が最大です。
他の二つのサイトが用意する機能をすべて備えており、インターフェイスも非常に使いやすいものです。
しかし、プロジェクトのページに表示される広告ブロックが気になるという人もいます。
現時点では、ホスティングサイトの三巨頭の中で唯一、主要なバージョン管理システム
(Git、Subversion、Mercurial そして CVS) のすべてに対応しています。
SourceForge にはメーリングリストサービスも用意されていますが、
もちろん他のメーリングリストサービスを使うこともできます。
Apache Software Foundation
のように、自分達の任務と既にあるプロジェクトのコミュニティーにうまく合っているオープンソースプロジェクトを無料でホスティングしている組織もあります。
どれにすればいいかわからない場合は、これら三巨頭のいずれかを選ぶことを強くおすすめします。
もう少し詳しく言うと、もしバージョン管理システムに Git を使っているのなら GitHub を、
それ以外を使っているのなら Google Code Hosting を使うといいでしょう。
SourceForge も悪くありませんが、現時点で敢えて SourceForge を選ぶ特筆すべき理由はありません。
また広告も気になります。
お気づきの人も多いでしょうが、フリーなホスティングサイトの多くは、
そのサイト自身を構成するソフトウェアをフリーソフトウェアのライセンスで公開していません
(公開しているサイトとしては Launchpad
や Gitorious そして
GNU Savannah があります)。
個人的には、サイト自身を構成するソフトウェアのすべてのコードにもアクセスできるのが理想だと考えます。
自分のデータをエクスポートしたり、自分のデータの操作を自動化させたりできるということが重要だからです。
そのようなサイトであれば決してそこにロックインされることがなくなり、
さらにプログラムを通じて拡張可能になります。
ホスティングサイトを動かすためのすべてのコードをオープンソースで入手することにはそれなりの価値があります。
とはいえ、実際にそのコードを運用するということはほとんどのユーザーにとって無理な話です。
これらのサイトには何台ものサーバーやカスタマイズしたネットワーク、
そして専任スタッフが必要になります。いずれにせよ、単にコードを持っているだけでは、
サービスを複製したり「フォーク」したりするのは無理なのです。
大事なのは、自分のデータがしばられてしまわないのを確実にするということです。
Wikipedia に ホスティングサービスの比較
(日本語)
の記事があります。オープンソースプロジェクトのホスティング環境の最新情報については、まずここを見るとよいでしょう。
また、Haggen So は、博士論文
Construction of an Evaluation Model for Free/Open Source Project Hosting (FOSPHost) sites
の研究の一環としてさまざまなホスティングサイトを評価しました。
発表されたのは 2005 年ですが、2007 年に更新されています。
この評価基準は今後も長く使えるでしょう。彼の調査結果は
にあり、
比較結果の表は です。
possv2 24 March 2013: If you're reading this note, then
you've encountered this chapter while it's undergoing substantial
revision; see producingoss.com/v2.html for details.
poss2 todo: Note the possibility of mixing services from
different canned hosting sites. Also, talk about the importance of
APIs for an exit export. Mention the Google Groups conundrum. Maybe
replace some of the above commentary with a reference to .
匿名性とプロジェクト参加
厳密にはホスティングサイトに限った問題ではないのですが、
ホスティングサイトで最もよく見られるのが、ユーザーログインの機能に関する苦情です。
ログイン機能自体は十分単純です。
ウェブサイトでは、訪問者が自分のユーザー名とパスワードを登録することができるのです。
登録するとユーザーのプロフィールが保存され、
プロジェクトの管理者は、ユーザーにリポジトリへのコミット権限のような特定の権限を与えることができます。
この機能は非常に有用で、ホスティングサイトの主な利点のひとつです。
問題は、未登録のユーザーにも許可されるべきタスク、
特にバグ追跡システム内のファイルアップロードや、既存の問題にコメントをつけるときに、
往々にしてログインが必要になってしまっている点にあります。
こうしたタスクにログインを必要としてしまうと、
本来迅速で便利であるべきタスクに参加する敷居が高くなってしまいます。
勿論、バグ追跡システムにデータを登録した人に連絡を取りたい人もいますが、
その場合は(本人が望んだ場合に)電子メールアドレスを入力できるフィールドを設けておけば十分です。
新しいユーザーがバグを発見して報告したいと思ったとして、
バグ追跡システムに入力する前にアカウント作成フォームを入力しないといけないとわかればうんざりするでしょう。
そのユーザーは結局バグを登録しないかもしれません。
ユーザーを管理する利点は、通常は欠点に勝るものです。
しかしユーザーを匿名で行動させる選択肢があるなら、
全ての 読み取り専用のアクションだけでなく、
特にバグ追跡システムや、持っているならwikiページのデータ入力についても、
ログインしていないユーザーに許可するようにしましょう。
Social Networking Services
24 March 2013: If you're reading this note, then
you've encountered this section while it's undergoing substantial
revision; see producingoss.com/v2.html for details.
poss2 tbd: subsections for Twitter, Facebook, any others.
Twitter is useful; Facebook appears not to be so relevant to open
source projects but check this with people who use it more. Identi.ca
(if will persist). Others? Eventbrite (mention from
"meeting-in-person" section), what else? Acknowledge that many of
these services are not open source; times have changed, the train has
left the barn or the horse has left the station or whatever.