re0-merge

貢献の価値を公平に届けましょう。クレジットを保ち、メンテナーによる変更を分かりやすくし、承認の記録を残します。

目標

貢献は、永続的な維持コストを伴う贈り物です。レビューはその両方に応えるか、どちらかを損ないます。re0-merge は、作者だけでなく、コラボレーターやメンテナーなど、誰がレビューする場合でも、このスイートの流儀に沿ってプルリクエストを受け入れられるよう導きます。論旨に照らして評価し、作者の著作者性を保ったまま取り込み、メンテナー自身の編集は別コミットとして残し、黙って拒否するのではなく、承認とクレジットを添えて完了します。

ワークフロー

1. 取り込む前に門番を務めます。 追加的な貢献は、デフォルトでは見送ります。スイートに追加がなければ悪くなることを示す責任は、その追加を提案する側にあります。「いいえ」とする理由をあなたが説明する必要はありません。各 PR を単独で判断し、まとめて評価してはいけません。バグ修正は欠陥を取り除くため、受け入れやすい貢献です。新しいツールは、手作業で既に適用しているルールを自動化する場合にのみ、導入する価値があります。新しいスキルは、既存のスキルでは対応できない実際の不足を埋める場合にのみ取り込みます。十分な理由に基づく見送りも、成果としてリリースされるものであり、失敗ではありません。
2. まず先入観なく読みます。 決定を下す前に、新鮮な目で貢献全体を最初から最後まで読みます（インストールされていれば shower で確認します）。作者には問題なく見える名前や主張でも、初見の人にはそうとは限りません。
3. 修正し直すのではなく、検証します。 作者が既に修正をプッシュしている場合は、書き直すのではなく、使い捨ての回帰テストケースで修正を証明します。修正のクレジットは作者のものです。
4. 受け入れを決めたら承認し、その後 land/pr-<n> ブランチに取り込みます（複数 PR をまとめて扱う必要が本当にある場合に限り、範囲を指定します）。受け入れを決めたら、取り込む前にすぐ承認レビューを送信します。これは貢献者のコードに対する判定であり、リリースの受領確認ではありません。後のクローズとまとめず、今送ることで、マージせずにクローズされた PR も承認済みと読み取れる状態を保てます。続いて、各貢献者のコミットを著作者性を保って受け入れます（コミッターはあなたになります。コミットメッセージは re0-git で整えます）。メンテナーによる変更はすべて個別のコミットにし、クレジットの分担を分かりやすくします。その後、main にファストフォワードで統合します。
5. 新しいスキルは未加工のままマージせず、仕上げます。 名前（実在する一般的な単語、または簡潔な略称とし、意味不明な造語は避けます）、呼び出し方（モデルによる呼び出しか、ユーザーによる呼び出しか）、配置場所を適切に整えます。その後、各一覧に登録します（plugin.json、ルートとすべてのローカライズ版にある README の Index、re0-upgrade の Current catalog、scripts/catalog.cjs）。これにより、ドリフトガードに引っかからないようにします。
6. 貢献が含まれたリリース後に、その PR をコメント付きでクローズします。 クレジットと説明を添えたコメントと同時にクローズします。黙ってクローズしてはいけません。また、リリースされる前にクローズしてはいけません。手順 4 の承認で受け入れの記録は既に残っているため、この手順ではクローズと説明のみを行います。
7. コメントでは、温かみをもってクレジットを示し、説明します。 リリースノートで PR 番号と作者のハンドル名を挙げて貢献を称えます。名前を変更したり、位置付けを変えたりした場合は、クローズ時のコメントで作者に感謝し、何をなぜ変更したかを説明し、貢献が含まれたリリースを示し、核となるアイデアのクレジットを作者に戻します。

ルール

• 対象範囲への追加はデフォルトで拒否しますが、見送りは丁寧に行います。論旨に結び付いた理由を示し、ブランチは保持し、黙ってクローズしないでください（否定的な結果もコーパスに残します）。
• 著作者性を保ちます。貢献者が自身のコミットを作成し、メンテナーによる編集はすべて、メンテナー名義の別コミットにします。
• 受け入れを決めたら、取り込む前に承認します。リリース後のクローズとまとめてはいけません。承認は貢献者のコードに対する判定であり、失敗する可能性のあるリリースの受領確認ではありません。特定のレビュー担当者に限らず、レビュー権限を持つコラボレーターやメンテナーが行います。
• 変更点はすべて、作者にとって有益な形で説明します。作者が求めていない名前の変更や位置付けの変更には、その理由を添えます。
• レビュー担当者に依存せず、ツールがなくても手順を実行できるようにします。インストール済みのパイプラインスキル（shower、re0-git、re0-release）を使い、利用できない場合は各手順を手作業で行います。

検証

完了前に、次の点を確認します。

1. 取り込まれたすべての貢献について、作者の著作者性が保たれ、メンテナーによる編集は別々のコミットになっている。
2. PR はクローズ前に承認され、クレジットを記載したコメントとともにクローズされている。
3. 新しいスキルがすべての名簿に登録され、チェックがすべて成功している。
4. 見送る場合は、すべて論旨に結び付いた理由を明記し、ブランチを維持している。
5. 名前の変更や再構成を行った場合は、作者に説明している。