レッスン15 — OSS 貢献ワークフロー（Reth / Revm / Alloy）

問い

crypto 界の大半のエンジニアはコンパイルする Rust を書ける。最初のレビューで Reth / Revm / Alloy に merge される Rust を書けるエンジニアは少ない。Paradigm は upstream PR queue で見覚えのある人を採用する。そのギャップはどう埋めるか？

原理（最小モデル）

PR を無視させる 6 原因. 不明瞭なタイトル / 「なぜ」抜け description / 非 atomic commit / スタイル不一致 / テスト規約違反 / defensive 応答。
ルーキング期間 2 週. CONTRIBUTING.md / 直近 20 merged PR / 直近 10 close（無し merge）PR / メンテナの最近の PR / good first issue / TODO コメント。
エスカレーション梯子 5 段. Docs/README typo → テストケース追加 → 小バグ修正 → 小機能 → アーキ変更。#5 から始めると無視される。
Paradigm 品質 PR の解剖. Title（命令形、狭スコープ）+ Description 3 セクション（What / Why / How to verify）+ Atomic commits + コード（cargo fmt + clippy + 既存パターン合致）+ テスト（規約合致 + 意味あるエラー）+ 性能主張にはベンチ数字。
非自明変更は RFC. Motivation / Design / Alternatives / Drawbacks / Prior art。作業の多くは Alternatives と Drawbacks。
「チームが書いたものと思うか？」テスト. 既存 trait-first パターン / 不要新抽象なし / 隣接命名合致 / unsafe 避ける / プロジェクトエラー型一致 / なぜをコメント。
応答パターン. 速 + 同意 → merge / 遅 + defensive → close。「これを OK にするには何が必要？」が再議論より良い。
Reputation 弧 5 段. 1 merged（存在）→ 5（認識）→ 10（領域信頼）→ 20（非公式 expert）→ 50+（実質チーム、Paradigm 採用検討）。月でなく年単位。

具体例

エスカレーション梯子:

Docs / README typo — ほぼ確実 merge。注意深く読む人と印象
テストケース追加 — edge case カバー。正しさを考える人
小バグ修正 — good first issue ラベル。navigate できる人
小機能追加 — 有用だが load-bearing でない。判断力ある人
アーキ変更 — 上 4 つの後でなければ無理

PR description 3 セクション:

1. What changed (1段落、diffが何をするか)
2. Why (1段落、動機; 該当 issue 番号引用)
3. How to verify (レビュアー向け明示指示: テスト + 手動チェック)

RFC 構造（非自明変更）:

Motivation — どんな問題 + なぜ今
Design — 何を提案 + API スケッチ
Alternatives — 他に何を考え + なぜ却下
Drawbacks — 提案の悪い点正直リスト
Prior art — 他プロジェクトの扱い

応答パターン比較:

良い（速 + 同意）:

Reviewer: 「ケース X は？」
You: 「指摘ありがとう、テスト追加 + 修正入れる」（数時間以内）
You: [push]（1-2 日以内）
Reviewer: ✓ merge

悪い（遅 + defensive）:

Reviewer: 「ケース X は？」
You: [元設計が X を正しく扱う 200 単語 defense]
Reviewer: [engage せず easier PR に移る]
3 週後: PR が inactivity で close

Reputation 弧:

Merged 数	状態
最初の PR（小修正）	社会的グラフに存在
5 件	メンテナがハンドル認識、PR を見やすくなる
10 件	ある領域で信頼できる contributor
20 件	非公式 expert、新 contributor の例に指される
50+ 件	実質チームの一部、設計判断で相談される、Paradigm 採用検討

監視 4 情報源:

Issue tracker（good first issue + help wanted フィルタ）
PR queue（active review コメントは無料の教育）
Discord / Telegram（#contributing、低リスクの「これは正しい approach か」質問）
コードベース TODO / FIXME（待っている would-be PR）

週 ~30 分。情報は複利。

失敗例（誤解）

「最初の PR で大きな技術貢献を見せる」— 間違い。最初は 社会的グラフに存在を確立 が仕事。小さい修正で reliability を示す → 5-10 merge で初めて大きな PR の聞いてもらえる地位。

「Refactor PR が技術的に正しいなら受け入れられる」— 間違い。履歴のない人の refactor は批判として読まれる。「あなたのコードがパターン X を使っているのに気づいた、Y で書き直した」は最悪パターン。

「PR が止まったら ping し続ける」— 間違い。14 日 + 28 日に 1 度ずつ ping、それ以降は沈黙が答え。Social capital を nagging で焼かない。

「PR を Twitter で marketing」— 間違い。merge 前の自己宣伝は協力前の self-promotion として読まれ、メンテナはそれを見る。

🛑 予測。 Reviewer が「ケース X は？」と聞く。応答パターン 2 つあるが、どちらが merge させる？（答え: 速 + 同意 + 修正 push（数時間以内応答、1-2 日以内 commit、修正 + テスト追加）。遅 + defensive（元設計の 200 単語 defense）はレビュアーが engage せず easier PR に移る → 3 週後 inactivity close。デフォルトでレビュアーが正しいと仮定。同意しないなら「これを OK にするには何が必要か？」を聞くのが再議論より良い — レビュアーは多数の PR を扱い、長い議論を相手にする余裕がない。）

ステップで組み立てる

Step 1: 2 週のルーキング期間

CONTRIBUTING.md + 直近 20 merged + 直近 10 close + メンテナ最近 PR + good first issue + TODO。

Step 2: エスカレーション梯子で最初の PR を選ぶ

Typo か edge case テスト追加。「履歴を作る」が仕事。

Step 3: Paradigm 品質 PR の 5 要素を毎回チェック

Title + Description 3 セクション + Atomic commits + コード（fmt + clippy + パターン）+ テスト（規約合致）。

Step 4: 非自明変更は RFC

5 セクション（Motivation / Design / Alternatives / Drawbacks / Prior art）。Alternatives と Drawbacks に時間を。

Step 5: 「チームが書いたものと思うか」テスト

既存パターン合致 / 不要新抽象なし / 命名合致 / unsafe 避ける / エラー型一致 / なぜをコメント。

Step 6: 応答規律

速 + 同意 + 修正 push、deadlock では「これを OK にする方法は？」、止まったら 14 日 + 28 日に ping、以降沈黙が答え。

Step 7: 4 情報源を週 ~30 分

Issue tracker + PR queue + Discord + TODO コメント。複利で効く。

答え合わせ

最初の PR が「大きな技術貢献ではない」理由: メンテナはまだあなたを知らない、レビューに時間投資する正当化がない。小さい修正（typo、edge case テスト）で 存在 + reliability を確立 → 後の大きい PR が聞かれる地位を作る。技術スキルではなく social capital の構築。
2 応答パターンが merge を決める理由: レビュアー視点で「engage コスト」が違う。速 + 同意 = 「3 日で merge」、遅 + defensive = 「3 週間議論」。レビュアーは多数 PR を扱う + 長議論の余裕なし → easier PR に移る → 結局 close。「あなたが正しい場合でも、再議論より これを OK にする方法は？ が速い」。
Reputation 弧が年単位な理由: メンテナの認識は merge ごとに少しずつ更新 → 「ハンドルを記憶 + 過去 PR を例に出せる」までに 10-20 PR + 各 PR が atomic + clean + テスト付き → 1 PR/月でも 1-2 年。Paradigm 採用は「実質チームの一部」の認識（50+ merge）で起きる → 通常 2-3 年。速い道は存在しない。

合格基準

ルーキング期間の 6 情報源を即答できる。
エスカレーション梯子 5 段を順に言える。
Paradigm 品質 PR の 5 要素を毎回チェックできる。
RFC 構造 5 セクションを暗唱できる。
Reputation 弧 5 段と Paradigm 採用検討段階を即答できる。

まとめ（3行）

Paradigm 採用は upstream PR queue で見覚えのある人から → 「コンパイルする Rust」と「merge される Rust」のギャップは独立スキル。
2 週ルーキング + エスカレーション梯子 + Paradigm 品質 PR 5 要素 + 応答規律（速 + 同意）+ 4 情報源 ~30 分/週。
Reputation 弧 5 段は年単位、近道なし。50+ merge で実質チームの一部 → 採用検討段階。