RubyリポジトリにおけるSorbet/RBS/Steepなどの型チェック導入が、GitHub上のPRログで観測できるbugfix PR率、bugfix種類、開発プロセス指標、PR内typecheck failure/reworkにどう現れるかを調査した観察研究リポジトリです。
結論は慎重です。Rubyの型関連シグナル導入について、GitHub PRログ上で一般bugfix PR率が頑健に下がる証拠は得られていません。CIで型チェックを強制しているrepoではbugfix低下方向のposteriorはありますが、サンプルが小さく、matching/support制約に敏感です。一方で、commit-level check履歴を見ると、PR途中でtypecheck failureが発生し、final headではsuccessになっているケースが観測されます。つまり、型チェックの効果があるとしても、公開bugfix PRの減少より、merge前の検出・修正・型運用コストとして現れている可能性が高い、というのが現時点での読みです。
- 論文ドラフト: paper/paper.md
- 論文HTML: paper/paper.html
- 結論スライド: slides/conclusion.marp.md
- 結論スライドPDF: slides/conclusion.pdf
- 再現手順: docs/REPRODUCIBILITY.md
- データmanifest: docs/DATA_MANIFEST.md
- 最終分析サマリー: reports/review_response_final_summary.md
- typecheck failure顕在化監査: reports/typecheck_manifestation_evidence.md
- Broadな型関連シグナル導入では、一般bugfix PR率の低下は確認できない。
processed_100x_balancedのBayesian event-study extensionでは、全体bugfix RRは1.133 [0.977, 1.321]、P(RR<1)=0.05。 - CI-enforced type checkingではbugfix低下方向のposteriorがあるが不確実。RRは
0.814 [0.488, 1.324]、P(RR<1)=0.80。 - explicit type/runtime bugfixは減っていない。型導入後に型関連作業や型関連PRが顕在化している可能性がある。
- DORA/Four Keys風のGitHub proxyでは、delivery performance改善は頑健には見えない。
- commit-level check履歴では、final headだけを見るとpre-merge typecheck failureを大きく取り逃がす。
- 83件のtypecheck-failure PRを監査すると、潜在的runtime/API契約バグ候補、RBS/RBI/signatureなどの型成果物修正、CI/tooling setup修正が混在していた。
既存研究には、言語特徴と欠陥率の大規模比較、JavaScript/TypeScriptやFlowによる公開バグ検出可能性、静的型がAPI理解・保守作業に与えるcontrolled experiment、bug mining/SZZ、DORA/Four Keysがあります。一方で、RubyのSorbet/RBS/Steep導入がOSSのbugfix PR、DORA風proxy、commit-level CI履歴にどう現れるかを直接見る研究は少ないです。このrepoの論文ドラフトでは、その差分をRelated Workとして整理しています。
SPEC.md 初期研究計画と設計メモ
paper/ 論文ドラフト
docs/ 再現手順、データmanifest、公開チェックリスト
scripts/ 収集、分類、推定、監査スクリプト
data/ processed datasetsとmanifest
reports/ スクリプトで生成したMarkdownレポートと図表
依存関係は uv で固定しています。
uv syncデータmanifestと最新のtypecheck manifestation監査を再生成します。
uv run python scripts/build_reproducibility_manifest.py
uv run python scripts/analyze_typecheck_manifestation_evidence.py --no-fetch-logs
uv run python scripts/make_paper_figures.py
uv run python scripts/export_pdfs.py論文用の主要再現コマンドをdry-runで確認します。
uv run python scripts/reproduce_paper_outputs.py --dry-run --stage paper詳細は docs/REPRODUCIBILITY.md を参照してください。
processed CSVは公開GitHub/GitLab metadata、PR本文、label、file list、check-run/status metadata、release/tag metadataなどから作成しています。一部CSVは大きいため、GitHub repository本体にはスクリプト・レポート・manifest・軽量集計を置き、フルprocessed dataはGitHub Release、Zenodo、OSF、またはGit LFSで配布する構成を推奨します。
API tokenやprivate credentialは保存していません。再収集スクリプトは必要に応じて gh auth token や環境変数を使います。
この研究は観察研究です。型チェック導入の因果効果を確定するものではありません。分類はheuristicであり、GitHub PRログにはreview前・CI内・local開発中に防がれた問題や、本番incidentは十分に現れません。そのため、結論は「PRログ上で何が観測できるか」に限定して解釈してください。