コントリビューションの仕組み

一つの重要な違いは、ターンアラウンドタイムです。 初めてコントリビューションする時はいつも、あなたは新しい（ホスト）チームに参加する事になります。 その結果、あなたは彼らのコードベース、使用している技術、そして彼らの好む開発環境（テストフレームワークやビルドシステムを想像してください）について知る必要があります。 この種のツールが標準化されている場合でも、各チームはいくらかの個性があります。 技術的な側面に加えて、コミュニケーション方法の違いに直面することもあるかもしれません（コードレビューを想像してください）。 しばらくして戻ってきたときには、チームのやり方やメンバーが変わっているかも知れません。 しばらく会っていなかった友人を訪ねてキャッチアップする時と同じように時間をかけてください。

十分なリードタイムを確保してください。 必要なときに作業を活用できるように、十分に早くから始めてください。 最初により多くのスラックタイム（余裕時間）を加えると良いでしょう。ホストチームと一緒に仕事をするとターンアラウンドタイムの感覚がわかります。 多くの場合、ホストチームへのコントリビューションが幾つか成功すると、ホストチームあたりのターンアラウンドタイム短縮を実感することができるでしょう。 この効果は、オープンソースでも見られます。詳細は、 こちら を参照してください。

従来のチームでは、誰もが予想されるリードタイムを知っていました。 InnerSouceのコンテキストでは、タイムゾーンの大きな違い（例えば、米国・シアトルのPDT（太平洋標準夏時間）とドイツ・ベルリンのCEST（中央ヨーロッパ夏時間））や、物理的に同じ場所にいたとしても所属元チームのようにフルタイムで対応できないなどの理由で。これが当てはまらないケースがあります。 したがって、双方のフラストレーションや焦り、その他の信頼構築以外への影響を防ぐために、予想される反応時間に関しての期待管理を明示的に行う必要があります。 1つのアプローチは、もしあなたが数日後にしか彼らに反応できないことが分かっている場合に、 Trusted Committer のフィードバックに対して、「調査しますが、数日では終わりそうにないです」とすばやく反応することです。 理想的には、彼らのインプットを見る時間があると思われるときに、大まかな見積もりを提示することができます。 そうすることで、非物理的な接触、長距離、または非同期メディアを介しても信頼性による信頼が構築されます。 信頼関係の構築は、あなたの前にある共同道路での不確実性の壁を克服を可能にします。

InnerSourceでは、特にプロジェクトの決定に関して、文書によるコミュニケーションを非常に重視しています。 それは、対面のコミュニケーションが禁止されているという事でしょうか？

あきらかに違います：アーカイブや検索性に関しては文書によるコミュニケーションが優れていますが、通信帯域幅に関しては対面コミュニケーションが優れています。 名前の後ろにいる人と会う時間を作るようにしましょう。できれば、お気に入りの飲み物や食べ物を持って会うようにしましょう。 人の話を聞くことができ、その人達の個性を知ることができれば、リモートコラボレーションがより容易になります。

コントリビューションしたい大きな機能はありますか？ 素晴らしい！ もしあなたの仕事がすべて無駄になってしまったら大変ではありませんか？ ホストチームがすでに似たようなものを作っていたり、ソフトウェアを非推奨にしようと計画していたり、あなたが提案していることが彼らのプロジェクトに適しているとは思っていない場合に、このようなことが起こる可能性があります。 この課題は頻繁に発生するものであり、多くのチーム関係では、コントリビューションが適切であることに事前に合意していないことが問題となっていました。

変更に取り組む前にコントリビューションのユーザー/技術面の設計についてホストチームから同意を得てから、プルリクエストを提出することで、自分自身とホストチームを幸せに(そしておそらくいくらか作業を節約)します。 あなたは、ホストチームがどのように手を差し伸べてほしいのかを理解する必要があります。 あなたの提案をどのように議論するのが良いか、 Trusted Committer に尋ねてみるのがベストです。

オープンソースの領域では何度も証明されているように、もしあなたの提案を議論する方法を選択できるとしたら、文書による方法を選択してみるべきです。 理想的には、あなたや他の誰かが後でこの機能のコントリビューションや他のコントリビューションに関してディスカッションする際に、あなたの提案を参照できるように、成果物が公開され、検索可能で、永続的にリンク可能である方法を選択することです。

このタイプのハイレベルで早期の合意は、将来のプルリクエストやり直しや拒否にかかる時間を節約することになるでしょう。

すばらしい、あなたはホストチームのやり方に慣れてきて、彼らはあなたのプルリクエストを受け取ることを楽しみにしています。 今あなたを待ってる落とし穴はどれでしょうか？

第一に、あなたは彼らとあまり直接コンタクトすることが少なくなるでしょう。第二に、あなたはあなたのチームのフルタイムのプロジェクトに参加している時ほどの豊富な知識や熟練を期待されていないでしょう。 これにどう対処するのが一番良いでしょうか?

彼らの文書、会話アーカイブ、ホスト・チームからのコード成果物をよく調べて、あなた自身のブロックを解除してください。 これは、人気のあるOSSプロジェクトの1つを使用しているときに、ほとんどの人が直面する状況と似ています。

オープンソースプロジェクトの場合と同様に、自分のブロックを解除しようとしてもうまく行かないということを、ホストチームに質問してみます。 あなたの質問と受け取る回答は、後で他の人があなたと同じ問題を解決する時の役に立ちます。 あなたの会話が、プロジェクトに密接にリンクされた検索可能なアーカイブになっていることを確認してください。 もし、未達成の目標があり、あなたがその目標を達成するための簡単な改善の機会があるようなら、ホストチームに改善を(とても丁寧に)提案することができます。 時には、現状は純粋な偶然から生じ、誰も違うアイデアを持っていなかったり、十分な配慮をしていなかったりしたために、そのような状態になってしまうことがあります。 そのような場合には、改善の提案は歓迎されるかもしれません。 プロジェクトに詳しい人と数分の会話で解決できる問題について、いつまでも空回りしつづけることは、どちらの役にも立ちません。 助けを求めても構いません。

しかし、重要な違いが1つあり、それは、あなたと他の人々に将来のメリットをもたらすことです。 ほとんどの場合は、プロジェクトの公式なコミュニケーション・チャネルを優先するべきです。これには、メーリング・リスト、チャット・ルーム、問題追跡ツールなどがあり、コミュニケーションの構造に対するさまざまなニーズに応じて同期的または非同期的な対話方法を目的に応じて使用します。 これらすべてに共通しているのは、テキストベースで、アーカイブされ、検索可能で、安定したリンクが付いていることです。つまり、質問と回答が記録され、それらの回答にリンクした参照情報にもアクセス可能な状態が保たれます。 このようにして、受動的に文書化された知識を検索で活用できるようになる利点に加えて、将来のコントリビューターが同じ利点を得られるように支援することができます。 このような受動的なドキュメンテーションは、特に価値のある宝石（アドホックに作成された重要な定義など）が含まれている場合に、「公式」ドキュメントを充実させるのに役立つ可能性があります。

作業中に、不足している(または古い)ドキュメントが見つかった場合は、次のコントリビューターにお願いするとともに、発見したものを更新してください。 プロジェクト・チームは、既存のドキュメントへの追加、更新、修正を喜んで受け取ることがよくあります。あなたは、新たな貢献の機会を見つけたのです！ (あるいは、あなたの経験や何があなたの役に立ったかという事に関するフィードバックを丁寧に提供してください。）

私たちは皆、コーディングスタイルやインデントなどについて好みや意見を持っています。 ホストチームのプロジェクトにも、それがあります。 プロジェクトの `CONTRIBTING.md` で指定されておらず、あなたの通常の設定とは異なる場合でも、これらの設定を適合して一致するようにしてください。 もしわからなければ、いつでも丁寧に質問することができます。 しかし、機能やバグ修正に対するゲストの貢献は、プロジェクト・コードを構造化したりフォーマットしたりする新しい方法を導入するタイミングではありません。

ここでの基本的なポイントは、 Trusted Committer が、あなたなしでコントリビューションを検証し、保守性を確保しやすくすることです。 あなたが解決できないようなクセのある機能や処理、あるいは重要なパフォーマンス調整を作成したのに、コードは完全には明らかでない(あるいは、一見したところハッキーで間違っているようにも見える)ことを想像してみてください。 もしあなたがこれをテストでこれをカバーしていて、理想的にはその背後にある理論的根拠についていくつかのコメントを残していたなら、将来の編集者はコードの目的を思い出すだろうし、テストはあなたのコードが実現する値が新しい実装でも維持されることを保証できるでしょう。 これを実現するには、次のことを行います。

あなたは、プルリクエストに変更に関連するドキュメントの更新が含まれていることを確認する必要があります。 ドキュメントが別の場所にある場合は、その場所にドキュメントを追加したことを確認し、プルリクエストでそれらにリンクしてください。

実際のコードレビューをTrusted Committerや他の人ができるだけ簡単にできるようにするには、次のヒントに従ってください。