パッチがたくさん送られてくるフリーソフトウェアプロジェクトでは、 「どんなパッチが投稿されたのか」「そのパッチをどう処理することにしたのか」 といった情報を追いかけるのは大変です。 中央管理体制でない場合などは特にそうでしょう。 大半のパッチはそのプロジェクトの開発者向けメーリングリストに投稿されます (中にはバグ追跡システムに投稿したり 外部のウェブサイトで公開したりといったものもあります)。 そしてそのパッチをどのように処理するかについては何通りものパターンがあります。

時には、パッチをレビューした結果何か問題が見つかり、 元の投稿者に差し戻しとなることもあります。 このようなやり取りは、通常は何度か (メーリングリスト上で) 繰り返されることになります。元の投稿者がパッチを何度か書き直し、 レビューする側が何も文句のつけようがなくなるまでこれが続きます。 この繰り返しがいつ完了するのかがはっきりわかるとは限りません。 もしレビューした人がパッチをコミットすれば 「これで完了」とはっきりわかるのですが、そうでない場合はいろいろな理由が考えられます。 「コミットする時間がないだけ」「そもそもその人にコミット権がなく、 他の開発者にコミットを依頼できていない」などの理由があるでしょう。

パッチに対する反応としてよくあるもうひとつのパターンは、 そのパッチをネタにして議論が紛糾することです。 議論の内容はパッチそのものである必要はなく、 そのパッチの背景にある考え方のよしあしについてが話題になることもあります。 たとえば、ある特定のバグを修正するパッチが投稿されたとしましょう。 しかし、開発者側ではもっと別の修正方法のほうがよいと考えている (問題をより一般化して、もっと広い範囲を修正することを考えているなど) ということがあります。開発者側の考える修正方法は、 何も以前から頭にあったものであるとは限りません。 投稿されたパッチを見ることで、別の修正方法をひらめくということもあります。

たまに、投稿したパッチが完全にスルーされてしまうことがあります。 これは、たまたま そのときにパッチをレビューする暇のある開発者がいなかっただけ (みんな、誰か他の人がみてくれるだろうと思っていただけ) ということが多いようです。「誰かが相手をするのを待つ」 のに時間の制限はありませんし、それ以外にも重要な作業はいくらでもあります。 かくしてそのパッチは誰の目にとまることもなくやみに葬り去られていきます。 せっかくの有用なパッチがこんなことで見過ごされてしまう可能性があるわけです。 それだけでなく、さらに悪い副作用もあります。せっかく時間を割いてくれた パッチ作者のやる気をそいでしまうということです。 さらに「パッチのひとつでも書いてやろうか」 と考えているその他の人たちにとっても、 そのプロジェクトが魅力あるものには見えなくなるでしょう。

パッチマネージャーの役割は、この手の「闇に葬り去られてしまう」 パッチをなくすことです。そのために、 次のような手順ですべてのパッチを安定した状態にします。 パッチマネージャーはすべてのメーリングリストのスレッドを監視し、 パッチを含む投稿を拾い出します。 最終的にそのパッチがコミットされているのなら特に何もすることはありません。 レビューと修正を繰り返した結果、最終版のパッチがまだコミットされていないという場合は、 最終版のパッチ (とメーリングリストでの議論) を問題追跡システムに投稿します。 そうすれば、開発者が後でその記録を追うのが容易になります。 もしそのパッチが特定の問題を修正するためのものなら、 問題追跡システム上に登録されているその問題のコメントとしてパッチの情報を加えます。 この場合は、新たな問題として投稿することはありません。

パッチに対する反応が何もないまま数日が経過した場合は、 パッチマネージャーが「誰かレビューする人はいませんか?」とフォローします。 そうすれば、普通は何らかの反応があります。 「そのパッチは適用する価値があるとは思えない。なぜなら……」 とか「じゃあ私がレビューしましょうか?」などです。 反応があった場合は、先ほど説明したような手順で処理していきます。 それでも誰も反応しなかった場合は、 そのパッチを問題追跡システムに登録するかどうかは パッチマネージャーの判断で決めます。しかし、 少なくともパッチの投稿者に対しては 何らかの 反応を返すようにしましょう。

パッチマネージャーを任命したおかげで、 Subversion の開発チームは時間と気力を大幅に節約することができました。 専任の担当者がいなければ、開発者みんなが 「今すぐには返事できそうにないけれど、誰か他の人が反応してくれるのかなあ? それとも私が後で対応したほうがいいのかな? でも、もし誰か他の人も同じように考えているのなら時間の無駄だなあ」 と常に心配するはめになっていたでしょう。 パッチマネージャーのおかげで、このような裏読みをすることはなくなりました。 各開発者は、パッチを見たときの状況に応じてどう処理するかを決めることができます。 もしそれをレビューしたいのならそうします。 マッチマネージャーが適切にフォローしてくれるでしょう。 もしそのパッチを完全に無視したいのならそれも結構。 あなたが見なかったとしても、 パッチマネージャーがそのパッチをきちんと扱ってくれます。

この仕組みがうまく動作するのは、 パッチマネージャーがきちんと処理してくれるとみんなが信頼できるときだけです。 つまり、この役割の担当者はノリで決めるのではなく正式な手続きを踏んで決める必要があります。 Subversion プロジェクトの場合は、まず開発者向けメーリングリストと ユーザー向けメーリングリストで告知を行いました。 何人かが立候補してくれましたが、最初に返事をくれた人を担当者として任命しました。 後にその人が担当を降りたとき (本章の後半の 「引き継ぎ」 をご覧ください) にも、同じ手順を繰り返しました。 同時に複数名を任命することは決してしませんでした。 なぜなら、そうすると担当者間のコミュニケーションの手間がかかるからです。 しかし、パッチの量があまりにも多い場合には 複数担当者制を敷くのもよいでしょう。

ソフトウェアプロジェクトにおける "翻訳" には、ふたつの異なる意味合いがあります。 ソフトウェアのドキュメントを翻訳することと、ソフトウェアそのものを翻訳する (エラー表示やヘルプメッセージをユーザーの好きな言語で表示できるようにする) ことです。どちらも複雑な作業ですが、いったん仕組みを確立してしまえば これは他の開発とは分けて行うことができます。 どちらの翻訳もやることはほぼ同じなので、(プロジェクトによっては) 両方の作業を一人の翻訳マネージャーが管理してもいいでしょう。 あるいはそれぞれ別の人に管理させてもいいでしょう。

Subversion プロジェクトでは、一人の翻訳マネージャーに両方を管理させています。 もちろん彼が実際に自分で翻訳を行うわけではありません。 ひとつやふたつの言語については作業できるかもしれませんが、 もしすべての翻訳を自分でしようとすると、現時点で彼は 10か国語 (方言も考慮すると12か国語) を操れなければなりません! それは無理なので、彼はボランティアの翻訳者のチームを管理しています。 彼の仕事は翻訳者たちがお互いに協力し合えるように支援することであり、 翻訳チームがプロジェクトの他のメンバーとうまくやっていけるようにすることです。

翻訳マネージャーが必要となる理由のひとつに、 翻訳者たちは一般的な開発者とは少し異なるという点があります。 彼らの中にはバージョン管理システムの使用経験が浅い人もいるでしょうし、 ボランティアのチームの一員として働いたことのない人がいる可能性もあります。 しかし、それを別にすれば、彼らはボランティアとして最高の人たちであるともいえます。 特定の分野に関する知識を持っており、 それを生かしてプロジェクトに協力してくれているわけです。 彼らは、作業をするためならよろこんで勉強してくれるでしょう。 彼らに必要なのは、どうすればいいのかを教えてあげる人です。 翻訳マネージャーは、翻訳作業が通常の開発を不要に妨げないように注意します。 また、翻訳者全体の代表として働くこともあります。 翻訳作業に影響を与えるような変更を開発者が行った場合に、 それを翻訳者たちに伝えるのがその役目です。

したがって、翻訳マネージャーにとって一番大切なのは 技術的な能力ではなく外交力になります。 たとえば Subversion プロジェクトの場合、 各国語の翻訳は少なくとも 2 人以上で行うことという決まりを設けました。 そうしないと、翻訳をレビューすることができないからです。 たとえば、Subversion をマラガシ語に翻訳したいという人があらわれたとしましょう。 翻訳マネージャーは、6 か月前に同じことを申し出てきた別の人とペアを組ませて翻訳を任せるか、 あるいは「だれかもうひとりマラガシ語のわかる人を連れてきて、 ふたりで作業をしてほしい」とお願いしなければなりません。 人が集まったら、マネージャーは彼らに適切なコミット権を与え、 プロジェクト内の決まり事 (コミットメッセージの書き方など) を説明したうえで彼らの作業を見守ります。

翻訳マネージャーと開発者とのやりとり、 あるいは翻訳マネージャーと各翻訳チームとのやりとりは、 通常はそのプロジェクトが元々使用している言語で行います。 つまり、翻訳の元となる言語ということです。 ほとんどのフリーソフトウェアプロジェクトでは、これは英語となるでしょう。 しかし、プロジェクトの事情によってそれ以外の言語となることがあってもかまいません (とはいえ、そのプロジェクトを世界に広めたいのなら、 英語を使うのが一番よいでしょう)。

しかし、個々の翻訳チーム内でのやりとりは 彼らの言語で行うことになるでしょう。 翻訳マネージャーの仕事のひとつは、 個々の翻訳チーム用に専用のメーリングリストを用意することです。 そうすれば、翻訳に関する議論を プロジェクト本体のメーリングリストのじゃまをせずに行うことができます。 本体のメーリングリストで翻訳の議論をしても、 ほとんどの人はその言語を理解できないでしょうから。

ソフトウェアのドキュメントを最新の状態に保つというのは、果てしなく続く作業です。 コードに新機能や拡張機能が追加されたら、 ドキュメントにもそれを反映させなければなりません。 また、そのプロジェクトのドキュメントがある一定のレベルに達したら、 コード自体へのパッチだけでなくドキュメントへのパッチも送られてくるようになるでしょう。 「コードのバグを修正することはできないけれど、 ドキュメントの間違いなら直せる」という人はたくさんいます。 ドキュメントはすべてのユーザーが読めますが、 実際にプログラムが書けるユーザーはその一部だけだからです。

ドキュメントへのパッチは、コードへのパッチに比べて レビューして適用するのが容易です。 テストの必要はほとんどありませんし、 変更内容もざっと見ればわかります。 パッチの数は多いけれどそのレビューの手間は少ないということもあり、 管理作業と実際の生産的な作業の割合は コードのパッチよりドキュメントのパッチのほうが高くなるでしょう。 さらに、もとの作者の書き方との一貫性を保つためには ほとんどのパッチに対して多少の調整が必要となることでしょう。 多くの場合、ひとつのパッチが他のパッチに影響を及ぼしたり 他のパッチと内容が重複していたりします。 お互いのパッチの内容を尊重してそれらを調整してからコミットしなければなりません。

ドキュメントのパッチは緊急に処理しなければならないこと、 そしてドキュメントを最新に保つには ソースコードの変更内容を逐次監視する必要があることなどを考えると、 ドキュメント専任の担当者を何名かおいたほうがいいでしょう。 彼らの作業は、ソフトウェアのどこがどう変わったのかを正確にドキュメントに反映させること。 そして彼らに必要なのは、大量のパッチを効率よくさばく能力です。

もちろん、そうしたからといってプロジェクトの他のメンバーが ドキュメントのパッチを適用できなくなるというわけではありません。 ちょっとしたパッチなら、他のメンバーがその場でコミットしてしまってもかまわないでしょう。 パッチマネージャー (さきほどの 「パッチマネージャー」 を参照ください) はコードとドキュメントのパッチを把握しているので、 開発チームとドキュメントチームの両方に対して適切な情報を提供してくれます (とはいえ、もしパッチの量が多くなりすぎて 1 人では管理しきれなくなっと場合などは、 まずはコードのパッチの担当者とドキュメントのパッチの担当者を分けることになるでしょう)。 ドキュメントチームのポイントは、各メンバーが 「ドキュメントをきちんとまとめて最新の状態に保ち、一貫性のあるものにする」 という役割を自覚することです。実際の作業としては、 ドキュメントの構成を熟知したうえでソースコードの変更点を追跡し、 また 別の人 によるドキュメントへのコミットや ドキュメントに対するパッチをチェックして、しかるべき対応をすることなどがあります。

プロジェクトのバグ追跡システムに投稿される問題の数は、 そのソフトウェアを使う人の数に比例して増えていきます。 したがって、いくらバグを修正して安全なプログラムを公開するようにしても、 未対応の問題の数は際限なく増えていくことを覚悟しなければなりません。 同じ問題が何度も投稿されることも多くなるでしょうし、 何が言いたいのかさっぱりわからないバグ報告も増えてくるでしょう。

バグマネージャーの役割は、これらの問題を軽減するために バグデータベースを常に監視し、定期的に整理整頓することです。 主な作業は、バグ報告の内容を補足することです。 バグ報告の中には、いくつかの項目が正しく埋められていないものもあれば 既存のバグと同じ内容を報告しているようなものもあるからです。 担当者がバグデータベースの内容に精通していればいるほど、 既存のバグと重複しているバグ報告を見つけやすくなります。 これが、バグ報告の対応に専任の担当者を割り当てる利点のひとつとなります。 全員が臨機応変に対応するより、そのほうが効率的だからです。 バグ対応を一元管理せずに分散管理しようとすると、 結局誰一人としてバグデータベースの内容に精通した人がいなくなってしまいます。

バグマネージャーは、個々のバグ報告に対して 個別の開発者を割り当てる作業も手伝います。 大量のバグ報告が飛び交うようになると、 中にはバグ報告の通知用メーリングリストをチェックするのが おっくうになる開発者も出てくるでしょう。 開発チームの誰かがすべての報告にきちんと目を通しておくことにすれば、 そんな場合でも適切な担当者にきちんとバグ対応をお願いすることができるでしょう。 もちろん、この作業は開発の妨げにならないよう注意して行う必要があります。 対応をお願いする相手の状況を考慮することも大切です。 これらのことを考えると、 バグマネージャーは開発者チームの中から任命するとよいでしょう。

そのプロジェクトでバグ追跡システムをどのように利用するのかにもよりますが、 プロジェクト内の優先順位に応じて バグデータベースを調整する役割もバグマネージャーにはあります。 たとえば Subversion プロジェクトでは、 各バグ報告に対して「将来のどのリリースで対応するか」を設定します。 そうすれば、誰かに「あのバグはいつ修正されるの？」と聞かれたときに 正確な日付がわからなくても「次の次のリリースで対応します」と答えることができます。 この「リリース」は、バグ追跡システム上では「ターゲットマイルストーン」 という項目で管理します。IssueZilla ^[33] にはこの項目が存在します。Subversion プロジェクトのルールとして、 各リリースにはひとつの大きな新機能追加といくつかのバグ修正を含めることにしています。 将来のリリースに向けた各バグ報告 (新機能も含みます。 新機能も同じデータベースで管理しています) に対して適切な ターゲットマイルストーンを設定しておくことで、 それを見れば今後のリリースの予定がわかるようにしています。 しかし、一度設定したターゲットマイルストーンがずっとそのままでいることは めったにありません。新しいバグが飛び込んでくると、 作業の優先順位が変わることもあるでしょう。 そんな場合は既存のバグのマイルストーンを移動させないと リリース計画を管理できなくなります。 こういった作業をおこなうには、やはり特定の担当者を割り当てて バグデータベース全体の状況と各報告の内容を把握させておくことが大切です。

バグマネージャーのもうひとつの役割は、 バグ報告の内容が現状に即していないものになった場合の対応です。 全然関係ない別の変更の結果、偶然にバグがなおってしまうこともあります。 あるいは、最初はバグとして対処しようとしていたけれど 結局それは仕様ということにしてしまうという場合もあります。 現状に即していないバグ報告を見つけるのは大変な手間のかかる作業です。 機械的にやるとするなら、データベース内のすべてのバグをチェックしなければなりません。 しかし、時を経て報告の量が増えてくればくるほど、 総チェックいうのは現実的ではなくなります。 ある程度の段階になると、データベースをまともな状態に保つ唯一の方法は 「分割して統治」ということになるでしょう。 バグ報告をカテゴリ分けし、それぞれを適切な開発者 (あるいはチーム) に振り分けるのです。その後の対応はすべて振り分けられた側が責任を持つことにします。 これほどデータベースが巨大化すると、バグマネージャーは どちらかというと全体の調整役として働くことが多くなります。 自分自身で個々のバグを処理するのではなく、 適切な人にそれを振り分ける役になるということです。

FAQ の保守という作業は、思いのほか難しいものです。 大半のドキュメントは、作者が事前に練り込んだ内容を記述するものです。 それとは異なり、FAQ は基本的に受け身のドキュメントとなります (FAQ の管理 を参照ください)。 どれだけたくさんの量を書いたとしても、 次にどんな内容が追加されることになるかは決してわかりません。 そして、常に細切れの内容が追加され続けるので ドキュメント全体としての一貫性やまとまりは簡単に崩れてしまいます。 ひどい場合は同じ内容が重複してしまったりすることもあるでしょう。 そんな問題がないように見えるものでも、 目立たないところで関連項目間の相互依存の問題が発生していることはよくあります。 たとえば本来はリンクするべきところができていないなどです。 お互いの項目が時期をずらして追加された場合などにこれが起こりえます。

FAQ マネージャーの役割は、ふたつあります。 まずは FAQ 全体の品質を保持すること。 そのためには、FAQ の中でどんな項目が取り上げられているのか 少なくとも質問だけでも把握しておく必要があります。 そうすれば、既存の項目に関連する内容や重複する内容が新たに追加されたときに 適切な処理をすることができます。 もうひとつは、プロジェクトのメーリングリストや掲示板をチェックして、 どんな問題が発生しているのかやどんな質問が行われているのかを確認することです。 それをもとにして、新しい FAQ を書き進めていきます。 後者の作業は非常に複雑なものになるかもしれません。 各スレッドを追いかけ、そこで行われている質問の内容を把握して 新たな FAQ エントリの追加を提案します。 そして他のメンバーのコメントなども考慮して (FAQ マネージャーがすべての内容のエキスパートであるとは限りません) エントリの内容をふくらませ、ある程度まとまった段階でそれを実際に追加することになります。

FAQ マネージャーは、FAQ 自体の書式についても責任を持ちます。 FAQ の体裁に関する注意点はさまざまなものがあります (6章コミュニケーション の 「全リソースをアーカイブと同様に扱う」 を参照ください)。 不特定多数が FAQ を編集するようになると、 これらの注意事項がおろそかになってしまうことがあります。 そんな場合でも FAQ マネージャーがきちんと注意してそれを修正していけば大丈夫です。

FAQ の管理を支援するためのフリーソフトウェアも数多く存在します。 FAQ の品質を低下させない範囲でそれらのソフトウェアを使うのはかまいませんが、 過度に自動化してしまわないように注意しましょう。 プロジェクトによっては、FAQ の保守を完全に自動化しようとしているところもあります。 wiki (3章技術的な問題 の 「Wiki」 を参照ください) などを使用して、 誰でも自由に FAQ の項目を追加/編集できるようにするなどしています。 これは Faq-O-Matic (http://faqomatic.sourceforge.net/) を使っているプロジェクトでよく見かけますが、 私の見る限りでは Faq-O-Matic がもともと想定している範囲を超えた使い方だと感じます。 FAQ の管理を分散化することでたとえ全体の作業量を軽減できたとしても、 その結果できあがる FAQ はどうしても品質が劣ったものになってしまいます。 そこには FAQ 全体を把握している人もいなければ 更新を要する項目や時代遅れになってしまった項目を見つける人もいません。 さらに各項目間のつながりを管理できる人もいないでしょう。 そんな状態でできあがった FAQ は、 探したい情報が見つからないどころか 間違った情報を与えてしまうものになってしまう可能性があります。 プロジェクトの FAQ を管理するのにどんなツールを使うのも自由ですが、 ツールの便利さに惑わされて FAQ 自体の品質に妥協してしまわないようにしましょう。

Sean Michael Kerner が書いた The FAQs on FAQs という記事が http://osdir.com/Article1722.phtml で読めます。この記事では、オープンソースの FAQ 管理ツールについての説明とその評価を行っています。