oss-contributor-onboarding

コントリビューターのオンボーディング

協力したいと考える初めての人が、自分の名前入りのプルリクエストがマージされるまでの道のりを整えます。その道のりでは、プロジェクトはあらゆる段階で人を失います。

• 参加する
• 作業を見つける
• 環境を整える
• 変更する
• 提出する
• レビューを乗り越える
• 再び参加する

人が離れてしまう段階を特定して改善し、まっさらなマシンで一連の手順を実行して、その改善を実証してください。

直感ではなく、公開された分類体系に基づいて診断します。Steinmacher らによる新規参加者の障壁に関する体系的レビュー（Information and Software Technology 59、2015年。特定の1つのプロジェクトを測定したものではなく、20件の一次研究を対象にしたレビュー）では、記録されたあらゆる失敗を次の5つのカテゴリーに分類しています。

• 社会的なやり取り
• 新規参加者の事前知識
• 作業の始め方を見つけること
• ドキュメント
• 技術的な障壁

各所見の背後にあるカテゴリーを明記してください。そうすれば、監査が単なる文言への不満の列挙になるのを防げます。

大きな失敗は2つあり、どちらもプロジェクトの内側からは見えません。

• メンテナーが試していないマシンでセットアップに失敗しても、イシューもメッセージも痕跡も残りません。
• 提出されたプルリクエストに返事がない場合も、同じく何も残りません。

GitHub の Open Source Guides によると、48時間以内にレビューを受けたコントリビューターは、はるかに高い割合で再び参加します（この数値の裏付けとなる公開データセットはなく、実務上のガイダンスです）。また、「たった1回の嫌な体験で、誰かが二度と戻りたくなくなることがあります」。文言を修正する前に、この2つの失敗を優先して改善してください。

初回貢献までの道のりに範囲を絞ってください。隣接する課題は7つの別スキルがそれぞれ担当し、「Reference」セクションに1行ずつ案内があります。ユーザーが抱える本当の問題がそのいずれかであれば、その旨を伝えて、該当するスキルに案内してください。

呼び出し方と出力

典型的な呼び出しと、それぞれで生成すべきものは次のとおりです。

ユーザーの発言	実行する内容	返すもの
「初めてのコントリビューターが諦める理由を監査して」	ステップ1～2を実行してから採点	./references/contributor-path-scorecard.md のセクション5にある監査レポート
「このリポジトリの CONTRIBUTING.md を書いて」	ステップ1～3を実行してから5	ファイルの草案と、記載した各コマンドを実証するクリーン環境での実行ログ
「good first issues が何か月も手つかずのままです」	ステップ1でベースラインを取り、続けてステップ4	書き直したキュー、担当を宣言するルール、期限切れルール
「初めてのプルリクエストが届きましたが、何と返せばよいかわかりません」	ステップ6のみ	テンプレートに基づく返信案と、次回に向けた二重の時間基準
「スターは増えるのにプルリクエストがありません」	ワークフロー全体	まずスコアカード。この表現が示しているのは通常、ファイルの文言ではなく、ステップ3か6です

すべての成果物に証拠を添えてください。

• ファイルパスと行番号
• コマンドの出力
• 日付付きの集計数値

証拠のない推奨事項は単なる意見であり、メンテナーがそれを重く見ないのは当然です。

インタビュー

一度に質問するのは1つにし、可能であれば選択式にしてください。また、リポジトリを読めば自分で答えられる質問は省略してください。質問1～7への回答が作業を開始する条件です。回答を得るまでは、ファイルの下書きを始めないでください。

メモリ：現在のタスクやプロジェクトのコンテキストに関する情報をいくつか保存してください。メモリをファイルに保存する場合は devrel-context.md を使ってください。別のメモリシステムを使っている場合は、そちらを使ってください。タスクごとにセクションを分けてください。完了したタスクは削除してください。タスクには日付を付け、一般的なプロジェクトのコンテキストには日付を付けないでください。インタビューへの回答は、タスクによって異なる場合があります。

1. どのリポジトリですか。また、その中を読み、コマンドを実行できますか？
2. 実際に増やしたいのは何ですか？コードへの貢献、ドキュメントや翻訳の支援、トリアージやサポートの支援、それとも負担を分担できる共同メンテナーですか？
3. ボランティアまたは個人でメンテナンスしているプロジェクトですか。それとも企業の支援を受けている、または財団がホストしているプロジェクトですか？回答によって、対応の対象、法的な条件、約束できる段階が変わります。区分については ./references/contributing-file-outline.md §3 にまとめています。
4. 通常の週に、レビューも含め、コントリビューター対応に現実的に何時間使えますか？調子のよい週ではなく、無理のない週で考えてください。意欲的な目標より、正直な少ない数字のほうが役に立ちます。また、以降のすべての推奨事項の規模は、この上限を基準にします。
5. いつまでに完了させる必要がありますか？リリース、助成金のマイルストーン、イベント、それとも期限なしですか？
6. 貢献を一度だけ募りたいですか。それとも、働きかけをやめたあともコントリビューターが増え続ける仕組みにしたいですか？
7. 対象外にするものは何ですか？どれだけよく書かれていても受け入れない貢献は何ですか？
8. 外部の人が貢献しようとした直近3回で、何が起きましたか？マージされた、停滞した、却下された、連絡が途絶えた、のどれですか？
9. 法的な条件（DCO への署名、CLA）はありますか？コントリビューターはプルリクエストを開く前にそれを知りますか、それとも開いたあとですか？
10. 現在、初めての人が環境をセットアップするのにどのくらいかかりますか？また、クリーンな環境で最後にセットアップを試したのはいつですか？
11. スタックに、データベース、有料 API キー、GPU、プロプライエタリーな SDK など、セットアップを特に難しくするものはありますか？
12. あなた以外にプルリクエストをレビューできる人はいますか？あなたが休暇中、コントリビューターはどうなりますか？

質問7を空欄にした場合は、作業を止める条件ではなく、監査の最初の指摘事項として記録してください。

このスキルのすべての優先順位付けに質問4、5、6を反映し、各回答が何をどう動かしたかを明記してください。

• 期限が近い場合（Q5）は、午後のうちに実施できる修正、対応目標、課題キュー、最初の返信を優先します。再構築が必要な環境層より先に取り組みます。
• 貢献を継続的に増やすことが目的の場合（Q6）は、手順3を優先します。これは、働きかけをやめたあとも効果が続く唯一の作業です。
• 週あたりの対応時間が1日未満の場合（Q4）は、どれだけ魅力的でも、手順7の体系的なプログラムは全面的に除外します。

ステップ 1 - 何も変更する前のベースライン

まず測定し、作業前と作業後の両方が単なる主観にならないようにします。

1. scripts/contributor-path-audit.sh <repo-root> を実行します。このスクリプトは、コミュニティ健全性に関するファイルとその表示優先順位、10 個の貢献トピックのうち現在のファイルで言及されているもの、セットアップの範囲、シークレットを使用しているためフォークからのプルリクエストでは実行できない CI ワークフローの数、Git のコントリビューター履歴（個別の作者数、1 コミットのみの作者の割合、CHAOSS のコントリビューター不在率、年間の新規作者数）を報告します。
2. スクリプトの内容の調査は網羅性の確認ではなく、語彙のチェックとして扱います。キーワードを grep するため、「レビューの期待事項：言及あり」という結果は、単語が一致したことを意味するだけで、そのトピックに対応していることを意味しません。調査結果をメンテナーに伝える前に、ファイルを読んでください。
3. スクリプトでは確認できない情報を、フォージのインターフェースまたは API から収集します。スコアカードのレポート形式に記載されたファネルのベースライン数値に加え、未割り当ての初心者向けイシューの現在の件数と経過期間を確認します。応答時間には 90 日間、コントリビューター数には 4 四半期を使用します。どちらも、このスキル独自のデフォルトであり、公表された標準ではありません。
4. メンテナー以外の人による直近 10 件のプルリクエストを、最も古いコメントから順に読みます。それぞれがどこで停滞したか、メンテナーから最初の返信があった場合はその内容を記録します。
5. 環境に永続メモリがある場合、このプロジェクトについて保存されているスコープの説明、応答目標、対象者の定義を読み込み、改めて導き出さないようにします。

スクリプトが報告するのは事実であり、評価ではありません。1 コミットのみの作者の割合はベースラインとして扱い、欠陥とはみなしません。この経路を改善した後も変化がなければ、その時点で初めて調査結果となります。

./references/contributor-path-scorecard.md を使って現在の経路を採点し、変更を提案する前に結果をメンテナーに示します。診断に納得できないメンテナーは改善策を受け入れません。また、その判断が正しいこともあります。リポジトリからは見えない制約があれば、ゼロ点としたチェックが正当化される場合があります。

ステップ 2 - 自分で経路をたどる

./references/contributor-path-scorecard.md §3 のコールドラン手順に従い、環境の経路とタスクの経路の両方を実行します。また、セットアップを確認だけで動作すると判定してはならないというルールも守ります。

実行中は、摩擦ログを付けます。混乱したすべての場面をタイムスタンプ付きで記録し、各項目に信号機方式の重大度を付けます。各項目について、以下を記録してください。

• 何を予想していたか
• 実際に何が起きたか
• 書かれていないどんな情報を知っている必要があったか

実行中に修正してはいけません。修正すると、問題の大きさが見えなくなります。

ステップ 3 - prose を書く前に環境を整える

壊れたセットアップについてのドキュメントは、ドキュメントがないよりも悪いため、このステップを執筆より先に行います。まず再現性の段階を選び、次にクリーンな状態からの実行で明らかになったギャップを埋めます。

段階は 3 つあります。導入後に必要となるメンテナンスの負担に対して、取り除けるセットアップエラーが多い順です。クリーンな状態からの実行結果を基に選びます。実際に見つかったエラーを取り除ける段階のうち、効率が最も高いものを選び、そこで止めます。

• 効率：bootstrap command > pinned toolchain > container definition
• 価値（取り除けるエラー）：container definition > pinned toolchain > bootstrap command
• 労力：container definition > pinned toolchain > bootstrap command

1. ブートストラップコマンド - 依存関係をインストールし、フィクスチャを準備して、最後にテストスイートを実行する make setup または ./script/bootstrap を用意します。作成とテストに 1、2 時間かかりますが、どこでも動作し、ホストのツールチェーンには依然として依存します。
2. 固定されたツールチェーン - ホストのツールマネージャーが読み取るバージョンファイルと、コミット済みのロックファイルを用意します。ファイル 1 つと、それによって必要になるアップグレードの負担で、「自分のマシンでは動く」問題の報告の大半をなくせます。
3. コンテナ定義 - ローカルエディターとクラウドワークスペースの両方が利用できる開発コンテナ定義を用意します。再現性は最も高い一方、メンテナンスの負担も最も大きくなります。常時のメンテナンスが必要で、メンテナー自身が使わないと最も早く劣化する段階です。

• この順序で後回しになるもの：環境に関するエラーの一群をまるごと取り除ける唯一の段階であるコンテナ定義です。スタックにサービスや扱いづらいツールチェーンが必要な場合は、これを優先してください（インタビュー質問 11）。その場合、より低コストの段階では何も取り除けず、順序を理由に動作しない修正を出荷してはなりません。
• 分かっていることに基づいて順位を付け直してください。CI ですでにコンテナを実行しているチームは、その段階の労力をすでに負担しています。そのプロジェクトに限り、効率の順位で最上位に移動します。

ホスト型ワークスペースのベンダーを採用する前に、コンテナ定義を採用してください。.devcontainer/ 形式はエディター、クラウドワークスペース、セルフホストランナーをまたいで利用できますが、ホスティングの選択肢にはそのような互換性がありません。これらのツールのベンダーが公表する時間短縮の数値は、査読付きの測定に裏付けられていないマーケティング上の数字です。この注意点と、推奨する前に提起すべき 3 つの制約（コンピューティングの費用負担者、ホスティングより先に移植性を確保すること、ドリフト）については、./references/published-findings.md §6 を参照してください。

次に、以下の順番でギャップを埋めます。

• CI で強制されるすべてのゲートを、ドキュメントに記載した 1 つのコマンドでローカル実行できるようにします。失敗したチェックをローカルで再現できないコントリビューターは、定義上、行き詰まります。
• パイプラインを、フォークからのプルリクエストで常に実行される認証情報不要のレーンと、メンテナーが実行する特権レーンに分割します。シークレットが必要なジョブはフォークでは実行できず、安心を必要としている人に対して失敗を示します。承認ゲートによってフォークからの実行が完全に保留される場合は、誰が承認し、どれくらいの速さで承認するのかをファイルに記載します。
• メンテナーがコントリビューターのブランチを編集できるようにし、そのことをファイルに記載します。停滞したプルリクエストをクローズするのではなく、完了できるようにします。
• マージ方式（スカッシュ、リベース、マージコミット）を明記します。これはコントリビューターがコミットをどのように構成するかに影響します。

修正を加えるたびに、クリーンな状態からの実行をやり直します。新たな問題が何も見つからなくなったら、このステップは完了です。

ステップ 4 - 初めての課題キューを用意する

初心者向けラベルは、難易度の評価ではなく、メンタリングを約束するものです。Kubernetes はこれを明確に説明しています。good first issue は、メンバーが追加のサポートを提供すると約束していることを意味し、help wanted は、より広く「パッチを歓迎する」という意味です。GitHub はこのラベルをアルゴリズムによっても表示し、基準を公開していません。そのため、このラベルはプロジェクト外から初めて訪れる人を呼び込みますが、その先に中身のない一行だけの課題があれば、せっかくの関心が悪い第一印象に変わってしまいます。

1. 簡単なバグを自分で修正するのはやめましょう。それぞれが、自分の20分を費やしてしまう採用の機会です。2015年の投稿でfirst-timers-onlyという慣習を生み出した Kent C. Dodds は、その取引についてこう述べています。「自分でやってしまえば、もっと早く終えて先に進めたでしょうか？もちろんです。でも、オープンソースの貢献者として大切なのは、そこではありません」。このスキルの基盤となるのは、彼の次の指摘です。「初めてオープンソースに参加する際の難しさは、機能の実装ではなく、実際にどうやってコードに貢献すればいいのかを把握することです」。
2. 候補となる各課題は、次の7つの要素を盛り込んで書きましょう。確認された動作、期待される動作、対象ファイルとそのテスト、必要なスキルや API、提案するアプローチまたは「設計は未確定です。まず議論してください」という明記、正確な検証コマンド、そして担当メンターです。74人の参加者を対象としたある研究（Steinmacher et al., arXiv:2103.12653）では、新規参加者はアーキテクチャ領域でラベル付けされた課題よりも、_必要な技術領域_でラベル付けされた課題を選ぶことが分かりました。彼らが尋ねるのは「これは自分にもできるか？」であって、「これは簡単か？」ではありません。
3. まだコードベースを見たことのない人が、セットアップも含めておよそ一晩で完了できる規模に、各課題を調整しましょう。これが、このスキルの標準的な規模の目安です。単語を一つ直すだけの課題では何も学べず、その後二度と戻ってこない貢献者を生み出します。
4. コード以外の参加方法として、ドキュメント、テスト、トリアージ、翻訳、サンプルを明示的に用意しましょう。これらは最も広く開かれた入り口であり、コードだけのキューで真っ先に失われるものです。
5. 課題の担当を宣言する方法と、担当したまま更新がない場合に期限切れとするルールを公開し、実際に適用しましょう。キューが埋まっているように見えても、課題がすべて不在の人に担当されたままでは、空のキューよりも悪い状態です。
6. 未担当で有効な課題を、常に少なくとも3件用意しておきましょう。これは独自に定めた最低数です。課題が一件も見つからなかった人は、後で確認しに戻ってきません。

弱い課題文と強い課題文を並べた例については、./references/first-issue-and-review-examples.mdをご覧ください。

ステップ 5 - CONTRIBUTING ファイルを書く

./references/contributing-file-outline.mdに沿って、セクションごとに草案を作成し、次のセクションに進む前に各セクションについてメンテナーの同意を得てください。一度に書き直したファイルは、一度に却下されます。

草案を作成する際は、次の4つのルールを守ってください。

• 現時点で事実であることだけを書いてください。ファイル内のコマンドはすべて、ステップ2または3で実行したものにしてください。
• 質問4への回答から、実際に守れる応答目標を公表してください。明示した7日間の目標を守るほうが、明示した48時間の目標を守れないよりも優れています。
• 法的な確認事項は、読者がコードを書く前に置き、確認の段階には置かないでください。プロジェクトにまだ選択の余地がある場合、サインオフ行（git commit -s）はコントリビューターに何の負担もかけませんが、署名ワークフローはタイプミスの修正まで妨げます。そのためCNCFは、「設定と使用がより簡単」なDCOを使うようプロジェクトに推奨しています。選択そのものはsamber/developer-relations-skills@oss-license-strategyに委ね、ファイル内での配置だけを決めてください。
• そこに目を通すエージェントのことも考えて書いてください。規約は文字どおり、かつ冒頭近くに記し、ラッパーだけで済ませずコマンドを明記し、必須手順はすべてリンク先ではなくファイル内に記載してください。アウトラインの§6では、これら3つのルールの仕様として、GitHub独自のリポジトリへの貢献に関するスキルを参照しています。

ファイルはフォージ上で表示される場所に置き、コピーは必ず1つだけにしてください（アウトライン§1）。隣接するファイルの内容を取り込まず、リンクしてください（§4）。

完成した文章は、お好みのヒューマナイザースキルで整えてください。生成された文章のように読めるコントリビューションガイドは、それが示す歓迎の意を損ない、この読者層にはすぐに見抜かれます。

ステップ 6 - レビューと認知のループを設計する

1. レビューとは別の時間軸で受領を知らせる - 2つの時間軸のルールです。実際のレビューが1週間先でも、当日中に「ありがとうございます。確認しました。木曜日までにレビューします」と伝えれば、関係を保てます。高くつく失敗は返信の遅さではなく、沈黙です。
2. 最初のコメントで対象範囲に回答する。 3回のレビューを経てからプルリクエストの対象範囲外だと判明するのは、双方にとって、このプロセスで最悪の結果です。
3. 決まった順序でレビューする： 対象範囲、正確性とテスト、理由を添えた設計、そしてスタイルの順です。スタイルについては、フォーマッターが修正できなかったものだけを扱います。機械で修正できることを、人間のレビューコメントに含めてはいけません。
4. すべてのコメントに、ブロッキングか任意かのラベルを付ける。 ラベルのないコメントが混在すると、失敗項目の壁のように受け取られます。
5. 断る必要があるときは、速やかに、丁寧に断る。 感謝を伝え、対象範囲のルールを示し、そのルールを公開した場所へのリンクを貼り、代わりの課題を提案して、クローズします。プルリクエストを6か月間放置するより、すぐに断るほうがよいでしょう。
6. マージ時に貢献を明記する： 貢献者を作成者として保持し、リリースノートで名前を挙げ、コミットグラフには残らないコード以外の貢献も記録します。ドキュメント、トリアージ、設計の作業は、そうしないと見えなくなります。
7. 2回目の貢献を、次の課題を名指しして明示的に依頼する。 ここで一度きりの参加者が貢献者になりますが、ほとんどの場合、自動的には起こりません。
8. プルリクエストが停滞したときに双方がどう対応するかを文書化し、ボットにクローズさせるのではなく、自分で仕上げることを申し出る。

人に対する印象ではなく、文書化された対象範囲のルールと固定の順序に沿ってレビューします。これは、レビュー担当者のバイアスを抑えるために利用できる、最も低コストな対策です。Terrell et al.（PeerJ CS 3:e111, 2017）は3,064,667件のプルリクエストを分析し、このプロセスが対象とする母集団そのものである「外部からの」貢献では、性別を特定できたケースにおけるマージ率は女性が58％、男性が61％であり、性別が中立的なプロフィールは最も高いスコアだったと報告しています。性別は推定され、ユーザーのうちリンク可能だったのは35.3％に過ぎないため、傾向は信頼できるものとして扱い、正確な割合は確定的なものと見なさないでください。注意事項については、./references/published-findings.md §5を参照してください。

項目1〜8を、メンテナーが実際に共有する短い手引きにまとめ、対応目標もCONTRIBUTINGファイルに反映して、貢献者とメンテナーが同じ数値を確認できるようにします。状況別の返信テンプレートは./references/first-issue-and-review-examples.mdにあります。

ステップ 7 - ショートカットに飛びつく前に、導入すべきか判断する

実際の問題が上記6つのステップのいずれかにあるのに、メンテナーはメンタリングプログラムやオンボーディングイベント、ボットに頼りがちです。どれも機能している道筋を加速させる正当な手段ですが、壊れた道筋では無駄になります。熱意に任せず、明確に判断してください。

導入を検討するのは、ステップ3〜6が機能している場合に限ります。道筋が壊れていれば、順位にかかわらずすべてゼロ点です。ここでいう労力とは、メンテナーが費やす時間と、告知した後に中止する難しさを指します。価値とは、再び参加するコントリビューターの数です。

• 効率：bot > structured program > onboarding event

• 価値：structured program > bot > onboarding event

• 労力：structured program > onboarding event > bot

• コンプライアンスコスト：structured program > onboarding event > bot

• ボットは機械的な作業を肩代わりできますが、人とのやり取りを代わることはできません。分母だけを見れば効率の筆頭です。導入にかかるのは1時間、その後の負担はほぼゼロで、1つのコミットで元に戻せます。最初の返信、断るときの対応、進捗が止まったときの確認（ステップ6）は人が行い、ボットや承認ゲートによって生じる待ち時間は、記録すべきステップ3の不足として扱ってください。

• 構造化されたプログラム（Google Summer of Code、Outreachy、LFX Mentorship、MLH、Season of Docs）では、奨学金と参加者のコホートを提供します。一方、メンターの時間はあなたが用意します。シーズン全体にわたる継続的な仕事であり、途中でやめれば参加者の夏を台無しにしてしまうため、ここに挙げた中で唯一、途中放棄できないものです。ステップ3〜6が機能してから実施してください。メンタリングが不十分なインターンを受け入れると、インターンがいない場合よりも負担が大きくなります。定着率が上がるとは約束しないでください。最もよく引用される2つの研究は結論が一致しておらず、Mozillaの分析（Labuschagne & Holmes、MSR 2015）では、good-first-bugまたはメンタリング付きのバグから始めたコントリビューターのほうが、長期的なコントリビューターになる可能性が_低い_ことが分かりました。数値と注意事項については、./references/published-findings.md §3-4を参照してください。

• オンボーディングイベントやスプリントは仕組みを教えるのには有効ですが、それだけでは誰も定着しません。準備に数日かかり、さらにフォローアップも必要なのに、3つの中で測定された効果が最も小さいため、効率では最下位です。この分野で最も多くのリソースを投入したワークショップを開催したKubernetesは、「サミット中にセッションを実施しても、すでにプロジェクトに貢献していた人以外で、熱心なコントリビューターになった人はいませんでした」として、これを終了しました。次の課題を明示する、メンターを割り当てる、2回目の貢献を促すといったフォローアップの予算を確保するか、イベントを見送りましょう。

• 品質基準のない報酬は最下位に順位付けするのではなく、削除し、削除したことを明記してください。確認しきれない量の投稿を生むため、わずかなメリットではなくコストです。Hacktoberfestの2020年のスパム急増を受け、参加リポジトリのオプトイン制、猶予期間の延長、Tシャツの完全廃止が行われました。

• この順序で後回しになるもの：構造化されたプログラムです。3つの中で価値が最も高く、プロジェクトを自力では見つけられなかった人を呼び込める唯一の手段です。2人目のレビュアーがいる場合（面接の質問12）、また質問4で確認したメンテナーの時間が、シーズン全体にわたるメンターの週ごとのコミットメントを確保できる場合は、優先度を上げてください。

• コンプライアンスの項目は、それぞれの手段によって生じる義務として読み取ってください。

  • 構造化されたプログラム：第三者の参加契約、メンターのコミットメント、奨学金の管理、シーズン中の行動規範
  • イベント：行動規範と会場
  • ボット：どちらもありません

  削除した報酬には公表済みの賞品ルールが伴います。Hacktoberfestがイベント途中で書き換えざるを得なかったルールです。

• この順序は既定の判断基準であり、絶対的な規則ではありません。プロジェクトやメンテナーによって変わります。分かっている状況に応じて順位を付け直してください。たとえば、雇用主がすでにメンターの時間に予算を割いている、共同メンテナーがコホートの運営経験を持っている、既存のイベントにスプリントを組み込める、といった事情があれば、既定の順位を適用する前に該当項目の順位を上げてください。

ステップ 8 - 再採点し、目標を維持する

スコアカードを再実行し、基準をクリアするまで調整を繰り返します。必須の 4 項目すべてに加え、採点対象の 16 項目中 12 項目を満たす必要があります。この基準はこのスキル独自のベースラインであり、公表された基準ではありません。出典を尋ねるメンテナーに伝える文言は、スコアカードの §4 にあります。

その後も維持してください。経路は時間とともに劣化するためです。新しい依存関係によってブートストラップが壊れたり、初心者向け課題がなくなったり、応答目標が守れなくなったりします。監査スクリプトとコールドランを四半期ごとに 1 回、つまりこのスキル独自の頻度で再実行し、ビルドまたはテストコマンドに変更があった場合も再実行してください。環境が定期実行に対応している場合は、その再確認を定期タスクとして設定します。対応していない場合は、メンテナーに日付入りのカレンダーリマインダーと、再実行するための 1 行のコマンドを残してください。

環境に永続メモリがある場合は、合意済みのスコープ説明、公表されている応答目標、初心者向け課題の定義、日付入りのスコアを保存してください。そうすれば、次回の実行で最初からやり直すのではなく、差分を測定できます。

その後の追跡項目

件数が少ないうちは、これらのシグナルは日付付きの逸話であり、ダッシュボードにはなりません。四半期に 4 件の外部プルリクエストがあっても傾向はつかめません。また、カンファレンスでの講演やトップページでの紹介は、ドキュメントの変更よりも以下の数値すべてに大きな影響を与えます。各変更を公開した日付を記録し、交絡要因を注記してから、差分を読み取ってください。

スコアカードのファネルのベースラインを追跡し、各数値を次のように読み取ります。

• 四半期あたりの新規外部コントリビューター数 - 主要指標であり、最も変動が大きい指標です。
• 90 日以内の 2 回目の貢献率 - この経路全体が改善を目指す定着率です。この期間は、このスキル独自のデフォルト値です。
• 最初の人間による応答までの時間の中央値。ボットを除外し、48 時間を基準に比較します。
• 外部からの最初のプルリクエストのマージ率とマージまでの時間の中央値。メンテナー自身のプルリクエストとは分けて追跡してください。メンテナーのものは常に速く、重要な数値を見えにくくするためです。
• コントリビューター不在要因 - ゆっくり上昇するのが望ましい指標です。これらの中で、プロジェクトの脆弱性が下がったかどうかを測定できる唯一の指標です。
• セットアップのサポート負荷 - 実際には「ビルドできませんでした」という内容の課題やチャットメッセージです。手順を固定すればほぼゼロになり、効果が最も早く目に見える項目です。

よくある失敗パターン

• 古いバグに初心者向けのラベルを付ける。 コードベースを知っている人にとって小さな問題でも、初めての人にとって小さな問題とは限りません。場所、検証コマンド、メンターがそろっていなければ、最初に取り組む課題にはなりません。
• レビューがボトルネックなのに、参加者の募集を最適化する。 担当者のいないレビュー待ちキューにコントリビューターを増やすと、放置されたプルリクエストが増え、双方に不満が生まれます。プロジェクトを広く紹介する前に、ステップ 6 を改善してください。
• 成果の数値を、そのまま当てはまるかのように引用する。 「インターンの 80% が貢献を続ける」という数値は、あるプログラムの修了生アンケートによる自己申告の結果であり、回答率は 37% です。他者の結果を流用するのではなく、プロジェクト独自のファネル、最初の応答までの時間、2 回目の貢献率を測定してください。
• 大規模プロジェクトのプロセスをそのままコピーする。 10 人のプロジェクトが Kubernetes の段階的な参加制度、スポンサー、当番制を導入すると、まだいないコントリビューターのために予算をすべてプロセスに費やすことになります。規模ではなく、形を取り入れてください。

参考資料

• ./references/contributor-path-scorecard.md - 評価基準、初回実行プロトコル、合格基準、レポート形式
• ./references/contributing-file-outline.md - セクションごとの概要、ボランティアと企業の区分、エージェントの読みやすさ、簡潔な骨子
• ./references/first-issue-and-review-examples.md - 内容が不十分な場合と優れた場合の課題本文、最初の返信、レビューコメント、辞退、マージメッセージ、停滞時の確認
• ./references/published-findings.md - 引用されているすべての数値の出典と注意事項、および独自に設定したベースライン
• ./scripts/contributor-path-audit.sh - 評価基準の根拠となる機械的に確認可能な事実
• samber/developer-relations-skills@readme-optimization - リポジトリのランディングページ
• samber/developer-relations-skills@developer-quickstart-guide - ユーザーが製品を初めて使って成功するためのガイド（コントリビューターの道筋ではありません）
• samber/developer-relations-skills@oss-governance - 意思決定権とメンテナーの選定
• samber/developer-relations-skills@developer-community-moderation - 行動規範とその適用
• samber/developer-relations-skills@oss-launch - オーディエンスの獲得
• samber/developer-relations-skills@developer-journey-map - このコントリビューターの道筋がつながる段階