メンテナーになるということは何を意味するのか？
もし多くの人々に使われるオープンソースプロジェクトをメンテナンスしているのであれば、コーディングの時間が減り、イシューへの対応により多くの時間を割いているということに気づいているかもしれません。
プロジェクトの初期段階では、新しいアイデアを実験したり、やりたいと思ったことに基づいて意思決定しているでしょう。プロジェクトの人気が拡大していくことに伴い、ユーザーやコントリビューターと一緒に仕事をする時間がより多くなっていくことでしょう。
プロジェクトを運営するということは、コードを書く以上のことを必要とします。そのようなタスクは予想外のことが多いですが、成長しているプロジェクトにとって重要なことなのです。ここではプロセスのドキュメント化やコミュニティの活用といった、メンテナーとして過ごす日々を楽にする方法をいくつか集めてみました。
プロセスをドキュメント化しよう
ドキュメント化はメンテナーとして出来ることのうち最も重要なことの一つです。
ドキュメント化はメンテナーの考えを明確にするだけではなく、他の人々にとってメンテナーが必要としていることや望んでいることを質問する前に理解する手助けとなります。
ドキュメントを書いておくことで、自分のスコープ外のことが起きたときにノーと言いやすくなります。また、人々が援助や手助けをしやすくなります。誰がドキュメントを読んだり、プロジェクトを使ったりしているかは誰にも分かりません。
たとえ完全な文章ではなく、箇条書きにしておくだけでも何も書かないより良いです。
ドキュメントを最新の状態に保つよう心がけましょう。もし常に最新を保つことが出来ないのであれば、古くなったドキュメントは削除するか、既に古くなっているということを明示することで、コントリビューターに対してそのドキュメントの更新が歓迎されることであることを伝えることが出来ます。
プロジェクトのビジョンを書き留めよう
プロジェクトのゴールを書き留めることから始めましょう。README に追記するか、 VISION という名前の別のファイルを作りましょう。プロジェクトのロードマップなど、他に役立つ成果物があればそれらも公開しましょう。
明確でドキュメント化されたビジョンは、焦点が絞られた状態を保ち、他者からのコントリビュートによる「スコープの肥大化」を避ける助けとなります。
例えば @lord は、プロジェクトのビジョンを持つことでどのリクエストに時間を割くべきか判断しやすくなる、ということに気づきました。新しいメンテナーとして、彼は Slate への最初の機能要望を受け取ったときに、プロジェクトのスコープを固執しなかったことを後悔していました。
期待することを伝えよう
ルールを書き出すというのは神経をすり減らすこともあります。時折、他の人の行動を取り締まったり、楽しみを殺してしまっていると感じるかもしれません。
しかし、適切に明文化され、運用されれば、良いルールはメンテナーの力となります。メンテナーが望まないことに引きずり込まれるような状況を防いでくれるのです。
あなたのプロジェクトを訪れる人の殆どはあなた自身やあなたを取り巻く状況について何も知りません。あなたがこのプロジェクトで金銭を得ていると考えているかもしれません。特に彼らがあなたのプロジェクトを定期的に使い、依存している場合はなおさらです。多分、プロジェクトに多くの時間を費やしていた時もあったが、今は新しい仕事や家族で忙しい、ということもあったりするでしょう。
このようなことは全く問題ありません！他の人々が知ることができるようにすればよいのです。
プロジェクトを運営するのがパートタイムであったり、完全にボランティアで行っている場合、どのくらいの時間を使えるのか正直に打ち明けましょう。プロジェクトに必要であろう時間や、他の人があなたに使ってほしいと望む時間と、あなたが実際に使える時間は異なるからです。
下記に、明記しておく価値のある幾つかのルールをまとめます：
- コントリビュートがどのようにしてレビューされ、受け入れられるか（ テストは必要か？イシューテンプレートを使うべきか？ ）
- 受け入れる予定のコントリビュートの種類（ コードの一部分に関してのみ手助けが必要か？ ）
- リマインドをするのはいつが適切か（ 例えば、「メンテナーが7日以内に返答をします。もしそれを過ぎても返事がない場合は、スレッドで気軽にリマインドして下さい」 ）
- どのくらいの時間をプロジェクトに使えるか（ 例えば、「我々はこのプロジェクトに週5時間しか使いません。」 ）
Jekyll や CocoaPods 、 Homebrew は、メンテナーとコントリビューターのための基本ルールを定めたプロジェクトの良い例です。
コミュニケーションを公開しよう
あなたのやり取りをドキュメント化することも忘れないようにしましょう。可能な限りどこでも、プロジェクトについてのコミュニケーションを公開しましょう。機能要望やサポートリクエストについてプライベートにコンタクトしてくる人がいたら、彼らをメーリングリストやイシュートラッカーのようなパブリックなコミュニケーションチャネルに丁寧に誘導しましょう。
他のメンテナーと会ったり、プライベートに大きな決断をしたりした場合は、これらの会話を公の場にドキュメント化しましょう。たとえ、メモ書きを投稿するだけだとしてもです。
このようにして、コミュニティに参加した人は誰でも何年も所属している人と同程度の情報にアクセスできるようになるでしょう。
ノーと言うやり方を学ぼう
ここまでで様々なものを明文化してきました。あらゆる人があなたのドキュメントを読んでくれるのが理想ですが、現実はドキュメントが存在することを伝える必要があるでしょう。
とはいえ、あらゆるものをドキュメント化する事は、ルールを遵守してもらう必要があるときに属人性を排除するのに役立ちます。
ノーと言うのは楽しいことではありません、しかし 「あなたのコントリビュートはこのプロジェクトの優先事項にはマッチしません。」 という方が 「あなたのコントリビュートが好きではありません。」 というよりも個人的でない印象になります。
メンテナーとして直面する様々な状況でノーを言う場面があります：プロジェクトのスコープに当てはまらない機能要望、議論を脱線させる人、他人のために不要な作業をすることなどです。
会話を友好的に保ちましょう
ノーと言うことを実践する上で最も重要な場所の一つが、イシューやプルリクエスト上です。プロジェクトのメンテナーとして、受け入れたくない提案を受けることは避けられないでしょう。
そのコントリビュートはプロジェクトのスコープを変更してしまうか、ビジョンにマッチしないのかもしれません。アイデアは良くても、実装が良くないのかもしれません。
その理由にかかわらず、あなたのプロジェクトの基準を満たさないコントリビュートをそつなく対処する事は可能です。
もし受け入れたくないコントリビュートを受け取った場合は、あなたの最初の反応はそれを無視するか見なかったことにすることでしょう。そのようなことは他の人の感情を傷つけ、さらにコミュニティの中にいる潜在的なコントリビューターのやる気まで削いでしまいます。
望ましくないコントリビュートをオープンのまま放置しないようにしましょう。放置すると罪悪感を感じたり親切になろうとしてしまいます。時間が経つにつれて、回答されていないイシューやプルリクエストによって、プロジェクトを進めることがストレスを伴い、恐怖を感じるものになってしまいます。
受け入れるつもりのないコントリビュートはすぐに閉じてしまうのが良いです。もし既に膨大なバックログで困っているのであれば、 @steveklabnik のイシューを効率的にトリアージする方法が役に立つでしょう。
また、コントリビュートを無視することはコミュニティに悪い影響を与えます。プロジェクトにコントリビュートすることは威圧感があります。特に初めてのコントリビュートであればなおさらです。たとえ、そのコントリビュートを受け入れないとしても、その人に対して受け入れない旨と感謝の気持ちを伝えましょう。それは大きな賛辞となります！
もし、コントリビュートを受け入れたくないのであれば：
- 彼らのコントリビュートに感謝しましょう
- なぜプロジェクトのスコープにマッチしないか説明しましょう。そして、可能であれば、明確な改善提案をしましょう。親切に、しかし確固たる態度で行いましょう。
- もしあれば、関連するドキュメントにリンクしましょう。もし受け入れたくない内容が繰り返し提案されるようであれば、ドキュメントにその旨を追記して繰り返しの作業をなくしましょう。
- リクエストをクローズしましょう。
1 ~ 2文以上の返答は不要です。例えば、 celery のユーザーが Windows 関連のエラーを報告してきたときに、 @berkerpeksag はこのように返答しました：
ノーと言うのが恐ろしいと感じるのはあなただけではありません。あなたは一人ではないのです。 @jessfraz もこう書いています：
私はこれまで Mesos や Kubernetes 、 Chromium といったオープンソースプロジェクトのメンテナーと話をしてきました。そして、彼ら全員が同意した事は、メンテナーとして最も難しいことの1つは、受け入れたくないパッチに対して「ノー」を言うことだ、という点です。
コントリビュートを受け入れたくないと思うことを罪に感じる必要はありません。オープンソースの第一のルールは、 @shykes によると： 「ノーは一時的だが、イエスは永遠である」 。他の人の熱意に共感するのは良いことですが、コントリビュートを拒否することはその人自身を拒否することとは異なります。
最終的に、コントリビュートがあまり良くないものであれば、それを受け入れる義務はありません。人々がプロジェクトにコントリビュートしてくれたときには親切に、またきちんと返事をするようにしましょう。しかし、本当にプロジェクトのためになると思う変更のみを受け入れましょう。ノーと頻繁に言えば言うほど、それはより簡単になっていきます。約束します。
先回りしよう
まず第一に不要なコントリビュートの量を減らすには、コントリビュートガイドでコントリビュートを提案するプロセスとコントリビュートを受け入れるプロセスを説明しましょう。
もし品質の低いコントリビュートを多く受け取るようであれば、コントリビューターに事前に確認してもらうよう要求しましょう。例えば：
- イシューやプルリクエストのテンプレート/チェックリストを埋めてもらう
- プルリクエストを提出する前にイシューを開いてもらう
もしあなたのルールに従わない人がいたら、即座にイシューを閉じてドキュメントを共有しましょう。
はじめはこのやり方は親切ではないと感じるかもしれませんが、先回りしておくことは両者にとって良いことなのです。コントリビュートする人にとっては、受け入れられる見込みのないプルリクエストに何時間も費やす機会が減ります。そして、あなた自身の作業量もやりくりしやすくなります。
時には、ノーということで、潜在的なコントリビューターが怒ったり決定を批判したりするかもしれません。もしそれらの行動が敵対的であれば、状況を沈静化するために行動を起こすか、建設的に協調できないようであればコミュニティから抜けてもらいましょう。
メンターシップを受け入れよう
プロジェクトの基準に満たないコントリビュートを定期的に提出する人がいるかもしれません。何度も拒絶を経験するのはお互いにとってイライラするものです。
もしその人がプロジェクトに対して情熱があるけれども上達が必要だとわかっている場合は、辛抱強くなりましょう。プロジェクトの期待する水準になぜ満たないのかをそれぞれの状況ごとに明確に説明しましょう。より簡単な、もしくはより明確なタスクを紹介しましょう。例えば、手始めに取り掛かるのにちょうど良いイシューに “good first issue,” ラベルを付けるといったことです。もし時間があるのであれば、初めてのコントリビュートを通じて彼らのメンターとなることも検討しましょう。もしくは、コミュニティの中で喜んでメンターとなってくれそうな人を探しましょう。
コミュニティを活用しよう
あらゆる事を一人で行う必要はありません。あなたのプロジェクトのコミュニティはそのためにあるのですから！たとえ現時点ではまだ活発なコントリビューターコミュニティが無かったとしても、たくさんのユーザーがいるのであれば、その人達に仕事をしてもらいましょう。
作業負荷を共有しよう
もし他の人に支援してもらいたいなら、まずはお願いして回る所からはじめましょう。
新しいコントリビューターが繰り返しコントリビュートを行っていることに気づいたら、より大きい責任を提供することで彼らの仕事を認めましょう。望むならどのようにリーダーの役割を担えるよう成長出来るのかについてもドキュメント化しましょう。
他の人に対してプロジェクトの所有権を共有するよう推奨することはあなたの作業負荷を大いに減らすことに繋がります。 @lmccart が彼女のプロジェクトである p5.js で認識したように。
もし、暫定的であれ恒久的であれ、あなたがプロジェクトから離れる必要があるのであれば、他の誰かに引き継ぎをお願いするのは少しも恥ずかしいことではありません。
もしプロジェクトの方向性に熱意を持っている人がいれば、その人にコミット権限を与えるか、公式にその人にプロジェクトの管理を引き渡しましょう。もしあなたのプロジェクトをフォークしている人がいて、フォーク先が活発にメンテナンスされているのであれば、あなたの元々のプロジェクトとフォーク先をリンクすることを検討しましょう。非常にたくさんの人々があなたのプロジェクトが生き続けて欲しいと望んでくれるのは素晴らしいことです！
@progrium が彼のプロジェクトである Dokku で気づいたこととして、プロジェクトのビジョンをドキュメントに明記しておくことで、たとえ彼がプロジェクトから退いてもプロジェクトのゴールが生き続けたというものがあります：
私は wiki に望むこととその理由を書きました。私にとって驚きだったのは、プロジェクトのメンテナーたちがその方向に向かい始めたことでした！私がやろうとしたことが実際に実現されたかって？常にそうだったわけではありません。しかし、それでも私が描いた理想像にプロジェクトが近づいていったのです。
他の人に彼らが必要な解決策を作ってもらおう
もし潜在的なコントリビューターがあなたのプロジェクトがやるべきことについて異なる意見を持っているのであれば、彼ら自身のフォークを作ることを推奨するのも一つの手です。
プロジェクトをフォークすることは必ずしも悪いことではありません。プロジェクトをコピーしてそれを修正できるということはオープンソースの最も素晴らしい点の1つです。コミュニティメンバーに対して彼ら自身のフォークを作ることを推奨することで、あなたのプロジェクトのビジョンと衝突することなく、メンバーの創造性を発揮するはけ口を作り出すことが出来ます。
同じことが、あなたが構築する余裕の無い解決策を本当に望んでいるユーザーに対しても言えます。 API とカスタマイズのためのフックを提供することで、他の人が彼ら自身のニーズを、ソースコードを直接修正することなく実現する助けとなります。 @orta は CocoaPods 向けのプラグインを他の人に作ってもらうことで、「最も面白いアイデア」が出てきたと言っています：
プロジェクトが大きくなっていくにつれて、メンテナーが新しいコードを追加することに対して保守的になっていくのはほぼ避けようがない。「ノー」ということが上手になっていくだろうが、多くの人は理にかなったニーズを持っています。そこで代わりに、あなたのツールをプラットフォーム化することになるのです。
ロボットを使おう
他の人に手伝ってもらえるタスクがたくさんあるのと同様に、人間がやる必要のないタスクも多数あります。ロボットは友達です。ロボットを使うことでメンテナーとして過ごす日々を楽にしましょう。
コードの品質を向上させるためにテストやチェックを要求しよう
プロジェクトを自動化する最も重要な方法の1つは、テストを追加することです。
テストがあることで、コントリビューターは何一つ壊していない事を自信を持って確認することができます。また、あなたにとっても、コントリビュートをすばやくレビューし取り込みやすくなります。より早く反応すればするほど、コミュニティもより活発になるのです。
全てのコントリビュートに対してテストを自動的に実行するように設定し、またコントリビューターがローカルで簡単にテストを実行できるようにしておきましょう。コントリビュートが提出される前に全てのテストが成功している事を要求しましょう。こうすることで、全てのコントリビュートが提出される前に、最低限の品質基準を設けることができるようになります。 GitHub の Required status checks 機能を使うことで、テストが成功していない変更はマージされないよう保証することができます。
テストを追加したら、 CONTRIBUTING ファイルでテストがどう実行されるかを説明しましょう。
ツールを使って基本的なメンテナンス作業を自動化しよう
人気のあるプロジェクトをメンテナンスすることについての良いニュースとしては、他のメンテナーも似たような問題に直面し、そのための解決策を作っているということです。
メンテナンス作業の一部を自動化するために、非常に幅広いツールがあります。幾つか例を挙げましょう：
- semantic-release はリリースを自動化します
- mention-bot はプルリクエストのレビュアーになってくれる可能性のある人にメンションを送ります
- Danger はコードレビューを自動化します
バグ報告や他のよくあるコントリビュートに対しては、 GitHubに イシューテンプレートとプルリクエストテンプレート という機能があります。これを使うことで、コミュニケーションを簡素化することができます。 @TalAter はイシューやプルリクエストのテンプレートを作成する助けとなるよう、 Choose Your Own Adventure guide を作りました。
メール通知を管理する際、優先順位を設定するためにメールフィルターを使うことができます。
更に発展させたいのであれば、スタイルガイドやリンターを使うことで、プロジェクトへのコントリビュートを標準化し、レビューや取り込みを簡単にできます。
しかし、あなたが設定した標準が複雑すぎると、コントリビュートへの障壁が高くなってしまいます。皆の作業を簡単に行うために十分なルールだけを追加するように気をつけましょう。
どのツールを使うべきかわからないのであれば、他の有名なプロジェクトがどのようにしているかを探してみましょう。特に、同じエコシステムのプロジェクトを見てみましょう。例えば、他の Node モジュールではコントリビュートプロセスをどのようにしているでしょうか？他のプロジェクトと似たようなツールや方法を使うことで、ターゲットとするコントリビューターがコントリビュートプロセスに親しみやすくなります。
活動停止しても良い
オープンソース活動はかつては喜びをもたらしてくれました。しかし今となっては辞めたいと感じていたり、うしろめたい気持ちになっているかもしれません。
おそらく、あなたは困惑しているか、プロジェクトについて考えるのが怖いと感じているかもしれません。その間にも、イシューやプルリクエストは積み上がっていくのです。
オープンソース活動において、燃え尽きてしまうことは特にメンテナーの間で現実に発生し、よく起きることなのです。メンテナーとしてあなた自身が幸福であることは、オープンソースプロジェクトが生き残る上で交渉の余地なく必要なことです。
言うまでもないことですが、休みを取りましょう！バケーションを取るのに、燃え尽きたと感じるまで待つ必要はないのです。 Python のコア開発者である @brettcannon は、14年間に及ぶ OSS ボランティア活動を経て、1ヶ月の休みを取ることを決断しました。
他の仕事と同じように、休みを取ることでリフレッシュし、幸せを感じ、仕事に熱中できるのです。
時には、皆があなたを必要としていると感じられて、オープンソース活動を休むのは難しいと感じることがあるかもしれません。あなたが退くことに対して、罪悪感を感じさせようとする人さえいるかもしれません。
プロジェクトから離れる間にユーザーやコミュニティをサポートしてくれる人を探すために最善を尽くしましょう。もし必要なサポートを見つけられなかったとしても、とにかく休みを取りましょう。不在のときはきちんとその旨を共有しましょう。そうすることで、あなたからの返答がないことで人々を困惑させることもありません。
休みを取ることはバケーションを取ることだけではありません。もし週末であったり、業務時間中にはオープンソース活動をやりたくないのであれば、他の人にその希望を共有しましょう。そうすることで、彼らはあなたを悩ませないようにしてくれるでしょう。
まずはじめに自分を労ろう！
人気のあるプロジェクトをメンテナンスすることは、成長の初期ステージに必要なものとは異なるスキルが必要となります。しかし、それはなおも報われるものです。メンテナーとして、ごくわずかな人しか経験できないレベルのリーダーシップと個人スキルを実践することになります。常に簡単に対処できる訳ではありませんが、明確に線引をし、あなたが心地よく感じることだけを行うようにすることで、幸福でリフレッシュしていて、生産的な状態を維持する助けとなるのです。
