InnerSourceコミュニティでコントリビューションを求めることは、いくつかの理由からオープンソースコミュニティよりも困難です。
-
InnerSourceコミュニティでは、潜在的な コントリビューター の数が少ない。
-
コントリビューターは、勤務時間内にコントリビューションしたいと考えるため、時間の制約が大きくなる。
-
InnerSourceでの作業は、コントリビューターの正式な目標管理の一部に必ずなるとは限らないため、InnerSourceの作業に費やす時間が目標達成を損なうように見える場合がある。
そのため、Trusted Committerにとって、 コントリビューター のオンボーディングやコントリビューション作成のプロセスを、できるだけスムーズにすることが重要となります。 役立つことがいくつかあります。
-
各コードリポジトリに、適切な README.md を用意する。 適切な README.md には、リポジトリの内容と、その使用目的が説明されています。 さらに、ライセンスに関する情報も含め、リポジトリ内のソフトウェアの取得、構築、テスト、および使用方法について詳細な手順を提供する必要があります。
-
コントリビューター に期待される事をまとめた CONTRIBTING.md を作成する。 それは、次のような一般的な質問に回答する必要があります。
-
バグレポートや機能リクエストを送付するには、どのようにすれば良いか。
-
質問がある時に、誰にどのようにコンタクトすれば良いか。
-
コーディングスタイル、ブランチ作成、コミットメッセージに関する決まりはどのようなものか。
-
コントリビューションに対する「完了」の定義は何か。
-
コントリビューションに適用されるプロセスの段階には何があるか。
-
コントリビューションが受け入れられた後に、コントリビューションしたコードに対するサポートとして、何を期待しているか。
-
行動規範やコミュニティ運営に関するガイドラインはどのようなものか。
-
ソフトウェアに内部ライセンスが添付されている場合には（企業によっては法的エンティティ間でソフトウェアを共有する前提条件）、そのライセンスのコピーと、権利および義務について分かりやすい説明を含めてください。
これら文書化の作業に加えて、オープンソースソフトウェアの開発と同様に、潜在的な コントリビューター によってローカルに開発されるソフトウェアの実行とテストが簡単かつ直ぐに行えるようにすべきです。 それにより可能な限り少ない労力でコントリビューションの実装と検証を開始することができます。
コントリビューションの作成には、 共有リポジトリ と フォークアンドジョイン の2つの共通モデルがあります。 どちらにも利点があり、Trusted Committerとしては、潜在的および現在の コントリビューター のさまざまなニーズに応えるために両方のモデルをサポートする必要があります。 コントリビューターは、コントリビューションプロセスやコミュニティ自体について質問することが多く、これらの質問に回答できる担当者が必要となります。 したがって、どのようなInnerSourceコミュニティでも、このような質問に回答する担当者が1人以上いることが重要となります。 通常はTrusted Committerのグループの誰かが担当者になりますが、そうでなければ「オンコール」のコミュニティメンバーがいることを確認する必要があります。
また、潜在的な コントリビューター が、どのようなコントリビューションが必要とされているか判断することを支援することも重要です。 これには、コードのコントリビューションだけでなく、ドキュメントの作成、アートワークの作成、イベントの催しなど、コード以外のコントリビューションも含まれます。 そのための一般的な方法の一つは、コミュニティが使用するイシュートラッカーで「新人向けタスク」というタグ付けを行うか、コントリビューターが利用できるオープンタスクのマーケットプレイスを実装することです。
まとめると、企業という環境にあるInnerSourceコミュニティでは、できるだけ多くの人々がコントリビューションできるように、コントリビューションに対する障壁をできるだけ低く保つことがとても重要です。 これは、有益なドキュメントへのアクセスと、質問に答えたり、コラボレーションを促進したりするコミュニティの人々の両方を提供するということを意味します。 要約すると、Trusted Committerは、オンボーディングやコントリビューションがポジティブな経験となることを確認する必要があります。
