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

他のチームのプロジェクト/リポジトリに貢献を始める準備はできていますか? マネージメント層へのエスカレーションではなく、コラボレーションでブロッカーを減らすことを楽しみにしていますか? このセクションでは、InnerSourceに貢献する際に覚えておくべき落とし穴に焦点を当て、実践的なアドバイスを提供します。 これにより、あなたとホストチームが可能な限り快適な経験をすることを可能とし、より多くのコントリビューションと素晴らしいコラボレーションをするための基礎を築きます。

この記事は、あなたがおそらく経験する次の3つのステップに分かれています。

もし、あなたの貢献がより大きければ、共通の目標に向かって反復しながら、これらのステップ(の一部)を繰り返し実行する可能性があります。 そうすることで、すべてのことがより自然に感じられるようになる可能性が非常に高くなるでしょうし、おそらく、以前に何か他のことをしていた理由を不思議に思うかもしれません。

取り組む準備をする

リードタイム

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

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

期待のマネージメント

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

信頼関係の構築

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

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

拒否の回避

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

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

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

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

プルリクエストを作成する

コミュニケーションと自分自身の壁を取り除く

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

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

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

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

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

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

コードを作成する

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

プルリクエストを送る

あなたは、すべての重要な作業を完了し、問題と貢献しているプロジェクトのクセをすべて理解した上で、新しい機能を使用するために計画した時間が近くなり、できるだけ早くスムーズにあなたのコントリビューションがマージされるか確認したいと考えています。

Trusted Committer とホストチームに対して、レビューとマージをできるだけ簡単に行えるようにするためにできることは、次のとおりです。 これは実際に、自分のプロジェクトで変更を受け入れるために既に行っていることと非常によく似ているかもしれません。 もしそうであれば、すばらしい!あなたには、自然なものとなるでしょう。

テストと自動化

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

  • コントリビューションするコードのテストを追加して、他のプロジェクトで作業している時や、このプロジェクトへのコントリビューションをやめた可能性がある時にも、後で他の人によるコントリビューションの機能検証がうまくいくようにします。

    • 多くのプロジェクトでは、これらのテストとコード・カバレッジのレベルを使用して、プルリクエストに対する自動チェックが行われます。これらのテストに適用される基準を満たすようにしてください。

  • 多くのプロジェクトでは、ローカルで変更をテストできるように、プロジェクトのビルドと検証を行うスクリプトが用意されています。

    • これらを使用して、プルリクエストをオープンする前に、コントリビューションが正しく機能することを可能な限り確認してください。

    • 修正しやすい欠陥を含むプルリクエストをレビューしなければならないことは、よくTrusted Committerを悩ませます。彼らはコードを修正するのではなく、修正するように要求します。これにより、ラウンドトリップが増え、マージが遅くなる可能性があります。

    • しかし、誰も完璧ではありません。最善を尽くし、準備された検証スクリプトがある場合はそれを使用し、プルリクエストは、あなたのベストショットで提供してください。

    • もしあなたのプルリクエストがテストをブレーキし続けていて、ベストショットをしてもその理由がわからない場合:プルリクエストコメントの中でそれらのテストをハイライトして、あなたが現在理解している問題を説明し、それについて助けを求めてください。

  • 最初のコントリビューションのきっかけとなった自分のプロジェクトを忘れないでください。変更を加えた共有プロジェクトの修正ビルドを作成し、それを使用する自分のプロジェクトで試してみてください。

ドキュメントとレビュー可能性

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

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

  • プルリクエストには、あなたが完了しようとしている問題に関連する変更のみが含まれていることを確認してください。

  • 非常に大規模なコミット、コミットメッセージが不明確なコミット、大量のファイル、一貫性のない変更(例えば、複数のトピックに触れること)は避けるようにしてください。

  • このプルリクエストの変更内容、変更の理由、参照する問題と設計ドキュメント(存在する場合)の明確な説明を提供してください。

  • プルリクエストに一風変わったものや予期しないものが含まれている場合は、それをハイライトして説明してください。これにより、レビュー担当者がレビュー中に直面するかもしれない潜在的なブロックになる質問の理由付けや解決が容易になります。

    • 同じことが、実装やあなたのアプローチに確信が持てないシナリオにも当てはまります。それをハイライトして、洞察を求めてください。

    • 礼儀正しく振る舞い、 Trusted Committers からも礼儀正しさを期待しましょう

  • プルリクエストの範囲が広すぎたり大きすぎたりするとレビューが難しくなるため、受け入れられるまでにかなり時間がかかります。

    • より大きな機能を提供する場合は、その機能を複数のプルリクエストに分割して、順番に送信、レビュー、承認するようにすると助かることがよくあります。あなたが参照している問題と一緒にそれらをバインドすることもできます。

      • 一部のツールにはドラフト/WIPプルリクエスト機能もあり、この機能を使用すると、未完了および未研磨の作業に明示的にマークを付けて、ホストチームの Trusted Committers から早い段階でフィードバックを得ることができます。

      • こうすることで、「早期リリース、頻繁なリリース」という考え方を堅持しながら、完了したらホストチームが喜んでマージできるような道を進むことができます。

      • ホストチームの責任は、完全に洗練されていない仕事を共有して議論することが可能で歓迎されるという雰囲気を作り出すことです。フェイルセーフできなければ、革新もできず、コラボレーションは非常に困難になります。

      • 早期にレビューを依頼することと、レビューに意味のある変更を提供することのバランスを取るようにしてください。

追加記事

これらのリソースの一部は、課金の壁の向こう側に隠されている可能性があります。 あなたの雇い主がアクセスするためのサブスクリプションを持っていることもありますが、そうでなければ、公立大学図書館がゲストにアクセス許可していることもあります。

Contributors