コントリビューターの心構え

隣人を訪ねるとき、たとえドアが開いていても、ノックしたりドアベルを鳴らしたりせずに彼らの家に入ることはないでしょう。 同様に、InnerSourceにおいても、訪問者としてどのコードリポジトリに対しても直接コミットすることはできません（または招待されません）。

代わりに、コードベースに変更を加えた後、それらをプルリクエストとして送信します。 大規模な変更を行うことや、隣人の家の改善を考えたりしないのと同様に、InnerSourceではプロジェクトのコラボレーション・ガイドラインを予測し、それに従うことになります。 今度は、ホストがあなたに方法を示します - InnerSourceでは、既存のTrusted Committer達がゲストを指導するために時間を費やしていることと解釈します。

あなたが行った素敵な夏のパーティーはいかがでしたか？ 通常は、日時を決めたり、十分な食料を用意したり、それらをゲストから提供してもらうために、事前に計画を立てておく必要があります。 同じことがInnerSourceのプロジェクトで大きな変更をする際に起こります：プロジェクトでは、大きな変更を行う前に必要性や提案する解決法を問題提起する形で説明することが求められる可能性があります。 いきなり実装する代わりに初期設計に時間を割くことで、コントリビューターは多くの作業をやり直す必要がなくなります。 早くから進捗を共有することは、たとえそれが完了していないとしても、ホストチームがコントリビューターを良い解決策に導くための助けとなります。 Yonikの 未完了パッチの法則 ではこう説明しています。「Jiraにある中途半端なパッチは、ドキュメントもテストも後方互換性もないが、パッチが全くないよりは良いです」。

それは、InnerSourceのプロジェクトが対面でのコミュニケーションに価値を置いていないことを意味するのでしょうか？ 必ずしもそうではありません:参加者と直接会うことにはには価値があります。 すべてのテキストによるコミュニケーションには、対面する場合に比べて多くの情報が不足することを覚えておいてください：そこには、理解を助けるためのジェスチャーも、ものまねも、声色もありません。 対面でのミーティングは、対人的な問題や対立、誤解の解決に特に効果があります。 しかし、プロジェクトの意思決定に関するコミュニケーションは、たとえそれが、数年後であっても、なぜプロジェクトでその意思決定が行われたかを、他の人が理解して影響をあたえられるように、文書化しておくべきです。

私の一般的な経験則はこうです：気軽にコーヒーでもしながら会いましょう。 多くの場合、特にチームが複数の物理的な場所に離れている時、より強いチームを構築するために役立ちます。 全ての意思決定が、透明かつ非同期的な方法で行われていることを確認してください - そうすることで、会話の 裏側にいる人 も含めて、全員が参加してアクティブなコントリビューターになることができます。 オープンな意思決定がどこまでできるかの一例が、 Open Organization Workbook の中のいくつかの演習で解説されています。

では、あなたはどのようにして、InnerSourceのプロジェクトの将来の方向性や変化を議論する場所を把握するのでしょうか？ 多くのInnerSourceのプロジェクトでは、README.mdで、潜在的なコントリビューターからどのようにアプローチされたいかを概説しています。 もし、そのドキュメントが大きくなりすぎる場合、コントリビューションガイドラインはCONTRIBUTING.mdという名前のファイルに分割される傾向があります。 これらの推奨事項に従うことは、コントリビューターが自分の提案を売込むのに役立ちます。

すべてのやり取りにおいて、あなたのコントリビューションをホストチームへ「売込む」準備をしてください。 コントリビューションがホストチームのエコシステムにもたらす価値を明確にしてください。

ホストチームが、あなたの変更に対するメンテナンスを引継ぐことになります。 あなたの投稿に対して、 「30日間保証」 を付けることは理にかなっています。 こうすることで、コントリビューションから時間が経過した後に、バグ修正のサポートをコントリビューターから受けられなくなるというホストチームの不安を軽減することができます。

あなたが近所の人を訪問するとき、彼らはアパートの中であなたを助けてくれるでしょう。彼らは居間への行き方やトイレの場所を教えてくれます。 もし、あなたがより長く滞在するなら、彼らはおそらくもっと詳細を教えてくれるでしょう：例えば私の場合、ヒューズを切らないように食洗機と電気ケトルのスイッチを同時に入れないようにする、ということがありました。

同様に、すべてのソフトウェア・システムには、独自の癖と複雑さがあります。 多くの場合、最も明白なものは十分に文書化されています。 小規模なプロジェクトでは、このドキュメントは README.md にあります。大規模なプロジェクトでは、多くの場合、コントリビューションに特化したドキュメントである CONTRIBUTING.md にあります。

これらのファイルには、プロジェクトをチェックアウトしてビルドする方法、テストスイートの実行方法、プロジェクトに変更を提案する方法に関する情報が含まれています。 標準的なツールから大きく逸脱している場合や、変更を行う際に注意すべき点がある場合には、さらにドキュメントを参照するかもしれません。

このドキュメントに目を通すことで、間違った道を進むのを防ぎ、行き詰まりを警告するため、通常は大きな時間の節約になります。 もしあなたの経験に基づいて、何かが欠けていることに気付いたなら、そのドキュメントに対するパッチは一般的に非常に歓迎されます：プロジェクトを初めて見た新しいコントリビューターほど改善に適した人はいません。

あなたが考えている変更が全体的に意味のあるものかを、プロジェクトが好むコミュニケーションチャネルで一緒に考えてみてください。 最初は、アーカイブされ検索可能な企業の公開メディアでこうした会話を行うことは怖いことです。 ここでのメリットは、あなたの後に似たような提案をする他の人たちにあります：まったく同じ道を再び歩く代わりに、彼らはすでに議論されたことを学び、そこから始めることができます。

コントリビューターになるということは、本質的には、機能を要求するだけの人よりホストチームに近いことを意味します。 ただし、コントリビューターは貢献するソフトウェア・プロジェクトに対しての責任を負いません。

結果として、貢献がどのようなものでなければならないかについての最終判断はホストチームが行うことになります。 すべて人が共有組織の目的に向かって協力しているという前提の下で、謙虚な考え方でホストチームにアプローチすることは役に立ちます。 何がどのように実装されたかだけでなく,なぜその変更が必要であったかについても、オープンで透明性があることは役に立ちます。

フィードバックは贈り物として扱いましょう。他の人たちはあなたのソリューションを改善しようとしており、今後のトラブルからあなたを救います。

ホストチームが、あなたの貢献を全く受け入れない可能性があります。 その場合、チームと協力して、彼らのプロジェクトで解決できるニーズのサブアスペクトがあるかどうかを判断することが役に立ちます。 そのサブアスペクトで協力してから、あなた側の残りの問題を解決する別の方法を見つけてください。