自動化とトリアージプロセス

本ドキュメントでは、Issue と Pull Request の管理・トリアージに使用する自動化プロセスの詳細を説明します。目標は迅速なフィードバックを提供し、コントリビューションが効率的にレビューおよびマージされるようにすることです。この自動化を理解することで、コントリビューターは何を期待すべきか、リポジトリボットとどのようにやり取りすればよいかを把握できます。

基本原則：Issue と Pull Request

まず第一に、ほとんどの Pull Request（PR）は、対応する Issue にリンクされている必要があります。Issue は「何を」「なぜ」（バグや機能）を説明し、PR は「どのように」（実装）を説明します。この分割により、作業の追跡、機能の優先順位付け、明確な履歴コンテキストの維持が容易になります。私たちの自動化はこの原則に基づいて構築されています。

詳細な自動化ワークフロー

以下は、リポジトリで実行される具体的な自動化ワークフローの内訳です。

1. Issue を作成した場合：自動 Issue トリアージ

これは、Issue を作成したときに最初にやり取りするボットです。その役割は、初期分析を実行し、正しいラベルを適用することです。

• ワークフローファイル: .github/workflows/qwen-automated-issue-triage.yml
• 実行タイミング: Issue が作成または再オープンされた直後。
• 実行内容:
  • Qwen モデルを使用して、Issue のタイトルと本文を詳細なガイドラインセットと照らし合わせて分析します。
  • 1つの area/* ラベルを適用: Issue をプロジェクトの機能領域（例：area/ux、area/models、area/platform）に分類します。
  • 1つの kind/* ラベルを適用: Issue の種類（例：kind/bug、kind/enhancement、kind/question）を識別します。
  • 1つの priority/* ラベルを適用: 説明された影響に基づいて、P0（重大）から P3（低）までの優先度を割り当てます。
  • status/need-information を適用する場合あり: Issue にログや再現手順などの重要な詳細が欠けている場合、追加情報を求めるためにフラグが立てられます。
  • status/need-retesting を適用する場合あり: Issue で参照されている CLI バージョンが 6 つ以上古い場合、現在のバージョンでの再テストを促すためにフラグが立てられます。
• あなたがすべきこと:
  • Issue テンプレートをできる限り完全に記入してください。詳細が多いほど、トリアージの正確性が向上します。
  • status/need-information ラベルが付与された場合は、コメントで要求された詳細情報を提供してください。

2. Pull Request をオープンした場合：継続的インテグレーション (CI)

このワークフローは、すべての変更がマージ可能になる前に品質基準を満たしていることを保証します。

• ワークフローファイル: .github/workflows/ci.yml
• 実行タイミング: Pull Request へのすべてのプッシュ時。
• 実行内容:
  • Lint: コードがプロジェクトのフォーマットとスタイルルールに準拠しているかをチェックします。
  • テスト: macOS、Windows、Linux 上で、複数の Node.js バージョンに対して、自動テストの全スイートを実行します。これが CI プロセスの中で最も時間のかかる部分です。
  • カバレッジコメントの投稿: すべてのテストが正常にパスした後、ボットが PR にコメントを投稿します。このコメントは、変更がテストによってどの程度カバーされているかのサマリーを提供します。
• あなたがすべきこと:
  • すべての CI チェックがパスすることを確認してください。すべて成功すると、コミットの横に緑色のチェックマーク ✅ が表示されます。
  • チェックが失敗した場合（赤い “X” ❌）、失敗したチェックの横にある「Details」リンクをクリックしてログを表示し、問題を特定して修正をプッシュしてください。

3. Pull Request の継続的なトリアージ：PR 監査とラベル同期

このワークフローは定期的に実行され、すべてのオープン PR が正しく Issue にリンクされ、一貫したラベルが付与されていることを確認します。

• ワークフローファイル: .github/workflows/qwen-scheduled-pr-triage.yml
• 実行タイミング: すべてのオープン Pull Request に対して 15 分ごと。
• 実行内容:
  • リンクされた Issue の確認: ボットが PR の説明文をスキャンし、Issue にリンクするキーワード（例：Fixes #123、Closes #456）を探します。
  • status/need-issue を追加: リンクされた Issue が見つからない場合、ボットは PR に status/need-issue ラベルを追加します。これは、Issue を作成してリンクする必要があることを明確に示すシグナルです。
  • ラベルの同期: Issue がリンクされている場合、ボットは PR のラベルが Issue のラベルと完全に一致するようにします。不足しているラベルを追加し、属さないラベルを削除し、status/need-issue ラベルが存在する場合はそれを削除します。
• あなたがすべきこと:
  • 常に PR を Issue にリンクしてください。 これが最も重要なステップです。Resolves #<issue-number> のような行を PR の説明文に追加してください。
  • これにより、PR が正しく分類され、レビュープロセスがスムーズに進みます。

4. Issue の継続的なトリアージ：定期 Issue トリアージ

これは、トリアージプロセスでどの Issue も見逃されないようにするためのフォールバックワークフローです。

• ワークフローファイル: .github/workflows/qwen-scheduled-issue-triage.yml
• 実行タイミング: すべてのオープン Issue に対して 1 時間ごと。
• 実行内容:
  • ラベルがまったくない Issue、またはまだ status/need-triage ラベルが付いている Issue を積極的に探します。
  • その後、初期トリアージボットと同じ強力な QwenCode ベースの分析をトリガーし、正しいラベルを適用します。
• あなたがすべきこと:
  • 通常、何もする必要はありません。このワークフローは、初期トリアージが失敗した場合でも、すべての Issue が最終的に分類されることを保証するセーフティネットです。

5. リリース自動化

このワークフローは、Qwen Code の新しいバージョンをパッケージ化して公開するプロセスを処理します。

• ワークフローファイル: .github/workflows/release.yml
• 実行タイミング: ナイトリリースの場合は毎日スケジュール、公式のパッチ/マイナーリリースの場合は手動。
• 実行内容:
  • プロジェクトを自動的にビルドし、バージョン番号を更新し、パッケージを npm に公開します。
  • 生成されたリリースノートとともに、GitHub 上に対応するリリースを作成します。
• あなたがすべきこと:
  • コントリビューターとして、このプロセスに対して何もする必要はありません。PR が main ブランチにマージされると、その変更が次のナイトリリースに含まれることを確信できます。

この詳細な概要がお役に立てば幸いです。自動化やプロセスについてご質問があれば、遠慮なくお問い合わせください！