Contributor Guide

最初の pull request を出荷する方法

初心者向け Issue を見つけてから、メンテナーがレビューできる pull request をマージしてもらうまでの最短で信頼できる道筋です。

Start here

出発点を選ぶ

これらのカードを静的なセレクターとして使ってください。今の状態に近いものを選び、下の同じフェーズを進みます。

完全な初心者

ツール、用語、ドキュメントだけの変更から始めます。安全な 1 ループを終えることが目標です。

初めての PR

小さく最近の Issue を選び、diff を絞ります。コーディング前に範囲を確認しましょう。

再挑戦する貢献者

このプレイブックをチェックリストとして使い、再現とテストに一番力を使いましょう。

Phase 0

基本ツールを入れる

リポジトリを clone し、ブランチを作り、プロジェクトのチェックを実行し、作業を push できるだけのローカルツールがあれば十分です。

git

Git は作業を記録し、メンテナーが何が変わったかを正確にレビューできるようにします。

git --version

gh

GitHub CLI は fork、clone、認証、pull request 作成をターミナルから進める助けになります。

gh auth login
gh repo fork OWNER/REPO --clone --remote

editor

リポジトリ全体を検索でき、フォーマッターを実行し、変更ファイルを明確に見せるエディタを使います。

code .

Phase 1

適切な Issue を選ぶ

良い first issue は小さいだけではありません。新しく、理解でき、プロジェクトを保守している人がレビューできる必要があります。

良いシグナル

  • Issue が最近のもの、またはメンテナーの返信がある。
  • リポジトリのセットアップ手順がまだ動く。
  • 期待される変更が 1 つの小さな pull request に収まる。
  • テストまたは手動検証手順が説明されている。

注意シグナル

  • すでに複数人が同じ Issue に取り組んでいる。
  • Issue が曖昧、古い、または設計議論で止まっている。
  • 変更がセキュリティ、課金、データベース移行、リリース自動化に触れる。
  • プロジェクトに最近のメンテナー活動がない。

判断ツリー

  1. 依頼内容を一文で説明できますか？
  2. 問題をローカルで再現または検証できますか？
  3. 変更を小さく独立したままにできますか？
  4. 3 つすべてが yes なら、Issue を担当してよいか尋ねましょう。

Phase 2

6 ステップのプレイブック

ループは退屈で予測可能に保ちます。小さな pull request はレビュー、修正、マージがしやすいです。

1

担当を申し出る

対象 Issue を明確にし、範囲がまだ妥当か尋ねる短いコメントを残します。

2

ルールを読む

コードを変える前に CONTRIBUTING、README、開いている PR、テストコマンド、コードスタイルを読みます。

3

Fork + branch

自分のコピーを作り、main ではなくタスク名に沿ったブランチで作業します。

4

セットアップ + 再現

依存関係を入れ、問題を再現し、どのコマンドや画面で確認したかを記録します。

5

小さな diff を出す

必要最小限だけ変更します。ついでのリファクタ、依存更新、無関係な整形は避けます。

6

PR を開く

何を変え、どうテストし、どんな制限があるかを説明します。レビュアーの最初の確認を楽にします。

gh repo fork OWNER/REPO --clone --remote
cd REPO
git checkout -b docs/fix-install-note
pnpm install
pnpm test
git status
gh pr create --fill

Templates

コピーして使えるテンプレート

文面は状況に合わせ、具体的にし、完了できる以上の約束は避けます。

担当希望コメント

こんにちは。この issue に取り組みたいです。

変更範囲は次に絞る予定です:
- ...

始める前に、この方針で問題ないでしょうか？

PR 説明

## 変更内容
- ...

## テスト方法
- ...

## メモ
- このリポジトリへの初めての貢献なので、フィードバックを歓迎します。

Pause points

さらに時間を使う前の注意点

レビューできない pull request を無理に作るより、早めに止まる方がよいです。

  • 文書化された手順に従ってもプロジェクトをローカルで動かせない。
  • 修正にメンテナーの入力なしでプロダクト挙動を推測する必要がある。
  • Issue が大きな機能、再設計、移行、アーキテクチャ判断を求めている。
  • メンテナーが初回貢献者にその領域を触らないでほしいと述べている。

Reference

用語集

Fork
リポジトリのあなた用コピー。pull request を開く前に自分のブランチをここへ push します。
Branch
移動可能な作業線です。変更をレビューしやすく保つため、Issue ごとに 1 ブランチを使います。
Pull request
あなたのブランチをプロジェクトリポジトリへレビュー、マージしてもらうための依頼です。
Diff
無関係な掃除を含まず、Issue を解決する最小限の意味ある変更集合です。
CONTRIBUTING
セットアップ、スタイル、テスト、pull request の期待をまとめたプロジェクト固有のチェックリストです。

FAQ

初めての PR でよくある質問

メンテナーから 1 週間返信がない場合は？

現在の状況と直接的な質問を短く投稿します。それでも返信がない場合は、無期限に待たず別の Issue を選びましょう。

セットアップに失敗したら？

試したこと、正確なエラー、OS とツールのバージョンを含め、次のデバッグ手順を質問しましょう。

最初の PR はドキュメントだけでもよいですか？

リポジトリがドキュメント変更を歓迎しているなら可能です。明確なドキュメント、例、誤字、壊れたリンクの修正は正当な貢献です。

After first merge

1 回の貢献を繰り返せる習慣にする

レビューしてくれた人に感謝し、うまく動いたコマンドを記録し、プロジェクトの慣習を保存して、前回より少しだけ難しい次の Issue を探しましょう。