トリアージ（Triage）

トリアージチームに参加する

トリアージチームは、Gutenbergリポジトリ全体でトリアージが一貫して行われることを確保する特定の役割を持つ人々のオープングループです。さまざまな種類のトリアージが行われます：

• メンバーが自分の時間で行う定期的な自己トリアージセッション。
• 定められた時間にグループとして行う組織的なトリアージセッション。これらのトリアージセッションや適切なSlackチャンネルを見つけるには、ミーティングページを確認してください。
• 特定のボード、ラベル、または機能に焦点を当てたトリアージセッション。

トリアージチームのメンバーとしての期待は次のとおりです：

• 自己トリアージであっても、週に少なくとも一度はトリアージを行うことが期待されています。
• 可能であれば、組織的なトリアージセッションに参加してください。
• 特定のラベルやボードに焦点を当てるためにトリアージチームに参加する場合、その焦点がそこにあることを期待されています。このことを他のトリアージチームのメンバーに知らせてください。

このチームに参加したい場合は、いつでも#core-editor Slackで尋ねてください。

最初の問題をトリアージする

まず、以下のフィルタリングされたリストのいずれかを選択してください。注意：これらのフィルターのほとんどは、全体の問題ページから「ソート」オプションを選択することで見つけることができます。

• ラベルが割り当てられていないすべてのGutenbergの問題。ラベルを追加することでトリアージを行うと、Gutenbergの特定の側面に焦点を当てた人々が関連する問題を見つけやすくなり、それに取り組み始めることができます。
• ラベルが割り当てられていないすべてのGutenbergのプルリクエスト。これはコードに対する一定の快適さを必要とします。どのラベルを使用するのが最適かについての詳細なガイダンスについては、プルリクエストのラベリングに関するこのセクションを確認してください貢献者向け。プルリクエストを作成した人に確認して、ラベルが彼らの意図に合っているかどうかを確認することもできます。
• 最も最近更新されていないGutenbergの問題。古くなり、もしかしたら時代遅れになっている問題をトリアージすることで、重要な作業が見落とされるのを防ぎます。
• コメントがないすべてのGutenbergの問題。このリストをトリアージすることで、すべての問題が認識されていることを確認し、アクションを起こす前に、より多くの情報や議論が必要な問題を特定するのに役立ちます。
• 最もコメントが少ないGutenbergの問題。このリストをトリアージすることで、コミュニティが特定の提案に対してまだ traction が必要なものを把握するのに役立ちます。
• 最もコメントが多いGutenbergの問題。会話が停滞していると感じた場合、これらの問題をトリアージする最良の方法は、これまでの議論を要約し、アクションアイテム、ブロッカーなどを特定することです。このリストをトリアージすることで、重要で複雑な問題の解決策を見つけて前進することができます。
• GitHubで独自のカスタムフィルターセットを作成することもできます。コミュニティに役立つと思われるフィルターがある場合は、自由にPRを提出してこのリストに追加してください。
  

一般的なトリアージプロセス

トリアージを行う際は、上記のリストのいずれかまたは一般的な問題を一つずつ処理します。各問題に対して実行できるいくつかのステップは次のとおりです：

• 1. 最初に重複を検索します。問題が重複している場合は、「Duplicate of #」とコメントして閉じ、関連する新しい詳細を既存の問題に追加します。（閉じた問題の中でも重複を検索することを忘れないでください！）。
• 2. 問題にラベルが欠けている場合は、いくつか追加して、より良く分類します（トリアージチームに参加した後に与えられる適切な権限が必要です）。ラベルを追加する際の良い出発点は、[Type]（例：[Type] Enhancementまたは[Type] Bug）で始まるラベルのいずれかを適用して、どのような問題であるかを示すことです。その後、より説明的なラベルを追加することを検討してください。問題が特定のコアブロックに関するものであれば、[Block]で始まるラベルのいずれかを追加します。また、特定の機能に影響を与える問題には[Feature]ラベルがあります。最後に、アクセシビリティや国際化など、特定の関心分野に影響を与えるラベルもあります。すべての可能なラベルはこちらで確認できます。
• 3. タイトルが問題を十分に明確に伝えていない場合は、明確さのために編集します（適切な権限が必要です）。具体的には、問題に関連する主要な機能をタイトルの最初に持ってくることをお勧めします（例）し、タイトルはできるだけ簡潔でありながら説明的であるべきです（例）。
• 4. バグレポートの場合は、レポートを確認するためにテストを行うか、Needs Testingラベルを追加します。レポートを確認するための情報が不十分な場合は、[Status] Needs More Infoラベルを追加し、必要な詳細を求めます。バグレポートに再現手順が含まれていると特に有益ですので、報告者にそれを追加するように依頼してください。
• 5. もはや必要ない場合は[Status] Needs More Infoを削除します。たとえば、問題の著者が十分な詳細で応答した場合です。
• 6. 2週間以上応答がない場合は、非アクティブな[Status] Needs More Info問題をメモを添えて閉じます。
• 7. 問題に関して会話があったがアクション可能なステップが特定されていない場合は、参加者にフォローアップして何がアクション可能かを確認します。コメントで応答する際は、各参加者に@を付けてください。
• 8. 問題をさらにトリアージすることに自信がある場合は、次のこともできます：
  • バグレポートが有効であることを確認するためにデバッグして、技術的な詳細を追跡できるか確認します。
  • 問題に詳細が欠けているか確認し、それを補うことができるか確認します。たとえば、バグレポートに視覚的な詳細が欠けている場合は、ローカルで問題を再現し、スクリーンショットやGIFをアップロードすることが役立ちます。
  • 初めての貢献者が解決を試みるのに比較的簡単な問題であると考える場合は、Good First Issueラベルを追加することを検討してください。

一般的に使用されるラベル

一般的に言えば、以下のラベルは問題のトリアージに非常に役立ち、最も一貫して使用される可能性があります。すべての可能なラベルはこちらで確認できます。

優先ラベルの決定

報告内容について十分な知識があり、自信がある場合は、優先度を追加することを検討できます。優先ラベルが通常のレベルを示唆しないようにするために、意図的にそうしています。


| ラベル | 理由 |
| —- | —- |
| Priority: High | 現在の焦点の1つに合致し、主要な壊れた体験を引き起こしている（フロー、視覚的なバグやブロックを含む）。 |
| Priority: Low | 焦点に含まれない改善、ニッチなバグ、古いブラウザの問題。 |

問題を閉じる

問題は以下の理由で閉じられます：

• PRおよび/または最新のリリースが報告された問題を解決しました。
• 現在の報告の重複。
• WordPress.orgフォーラムで最も適切に処理されるヘルプリクエスト。
• 再現できない問題。
• 2週間以上応答がない問題で、より多くの情報が必要です。
• 修正できないと判断された項目、または意図した通りに動作している項目。
  

特定のトリアージ

リリース特定のトリアージ

リリースの時期に特にトリアージを行う際に従うべきガイドラインがあります。これは、一般的なトリアージと区別するために重要であり、問題のあるリリースブロッキングバグが適切に特定され、解決策が見つかるようにします。

• リリース候補（RC）でバグが導入され、多くのワークフローを壊す場合、それをバージョンマイルストーンに追加し、WordPress.orgのSlackの#core-editorチャンネルでフラグを立てます。
• 最新のバージョンでバグが導入され、次のRCがまだ行われていない場合、理想的には開発者がRCの前に修正をプッシュできるべきです！修正のためのプッシュの量は、壊れる可能性に比例してスケールするべきです。この場合、RCマイルストーンに追加し、緊急と見なされる場合は、WordPress.orgのSlackの#core-editorチャンネルでピンを立てます。
• 最新のバージョンで導入されていないバグの場合、マイルストーンを追加しないでください。代わりに、[Priority] Highのようなラベルを使用し、必要に応じて週次コアミーティングで注目を集めることができます。
  

デザイン特定のトリアージ

以前にリストされた一般的なトリアージフローに加えて、トリアージに参加するデザイン志向の人々のためのデザイン中心のトリアージのためのフローにいくつかの特定の追加があります。

• PRのテストとレビュー：これは、日々の自己トリアージの最初のステップであるべきです。
• ラベルNeeds Design Feedback：問題がデザインフィードバックを必要とするかどうかを確認し、可能であればそれを提供します。優先度、プロジェクトボード、または最もコメントが少ないものによって整理できます。十分な意見が集まったら、このラベルを削除し、次のステップ（つまり、Needs Designラベルを追加する）を決定してください。
• ラベルNeeds Design：本当にデザインが必要ですか？これは焦点に合っていますか？デザインがある場合は、Needs Design Feedbackとしてマークして問題をより良く分類します。

リマインダー：

• 必要に応じてスクリーンショットを求めてください。
• マージする前に反復を求め、変更を記録してください。
• 問題がボードにない場合は、特定の焦点に合わないか確認してください。
• 問題/プルがまだ優先されていない場合は、問題を前進させるために優先ラベルを追加することを検討してください。

週次デザイントリアージに関する詳細情報や参加方法については、このガイドを確認してください。