CONTRIBUTING.mdのプルリクエストベストプラクティス

プルリクエストのベストプラクティス

適切に文書化されたPRプロセスは、コントリビューターとメンテナー間のやり取りを減らします。これらのセクションをコントリビューティングガイドに含めてください。

PRサイズ

## プルリクエストガイドライン

PRは集中的かつ小さく保ちます：
- 理想: 変更400行未満
- 許容: 変更800行未満
- 分割が必要: 800行以上

大きなPRはレビューが難しく、バグを導入しやすく、
マージに時間がかかります。

PR説明テンプレート

## 説明
変更の簡潔な説明。

## 変更タイプ
- [ ] バグ修正
- [ ] 新機能
- [ ] 破壊的変更
- [ ] ドキュメント更新

## テスト方法
変更を検証する手順。

## 関連Issue
Closes #123

Issueの連携

GitHubキーワードを使用して関連issueを常にリンク：

• Closes #123 -- マージ時にissueを自動的にクローズ
• Fixes #456 -- Closesと同じ
• Relates to #789 -- クローズせずにリンク

CI要件

レビュー前に通過する必要があるものをリスト：

• リンティング（npm run lint）
• ユニットテスト（npm test）
• ビルド（npm run build）
• 型チェック（npm run typecheck）

マージ戦略

使用するマージ戦略を文書化：

• Squash and merge -- すべてのコミットが1つになる；mainの履歴をクリーンに保つ
• Rebase and merge -- 個々のコミットを保持；クリーンな履歴が必要
• Merge commit -- マージコミットを作成；完全なブランチ履歴を保持

ドラフトPR

早期のドラフトを奨励：

実装を完了する前にアプローチについてフィードバックが欲しい場合は、 早い段階でドラフトPRを開いてください。ドラフトPRは正式にレビューされませんが、 メンテナーがガイダンスを提供する場合があります。