トライアージとは、ユーザーから報告されたチケットを処理する作業です。一般的なタスクには、バグの検証、チケットの分類、バグを再現するのに十分な情報を確保し、修正を試みたいすべての人が再現できるようにすることが含まれます。
ユーザーがBundlerプロジェクトの問題を報告する方法を案内するissueテンプレートを作成しました。トラブルシューティングガイドも用意してあり、よくある問題の診断に役立ちます。
すべてのチケットがBundlerのコードのバグであるとは限りませんが、開いているチケットは通常、そのユーザーを支援するために改善できる点があることを意味します。場合によっては、追加のドキュメントを作成したり、エラーメッセージをより明確にしたりすることが必要になります。
チケットを確認する際には、次の主な質問を検討してください。
チケットのトライアージ戦略：* ユーザーに`bundle env`の出力をすべて出力するように必ず依頼してください。ユーザーがissueに`bundle env`の出力をすべて投稿し忘れる場合があります。* ユーザーの`bundle env`の出力を確認した後、現在の環境でユーザーの問題を再現してみてください。各リリースで変更されるのはコードベースの一部のみであるため、あなたのBundlerバージョンにも同じバグがある可能性が高いです。* 現在の環境でユーザーの問題を再現できない場合は、ユーザーの環境設定を徐々に取り入れてみてください。つまり、ここからユーザーの環境と一致させる作業を始めます。たとえば、ユーザーのバージョンのRuby、RubyGems、RVMなどを段階的に切り替えてみてください。* ユーザーは最新のBundlerバージョンを実行していますか？そうでない場合は、`gem install bundler`を実行して更新するよう依頼してください。最新のBundlerバージョンで既に問題が解決されている可能性があります。
問題が依然としてユーザー情報の提供を必要とする場合は、「ユーザーからのフィードバックが必要です」というラベルを適用します。これにより、将来、古い問題を特定するのに役立ちます。
問題を再現できない場合、バグは既に修正されている可能性が高いです（万歳！）。その場合は、行ったことと結果をチケットに投稿するのが良いでしょう。
問題を再現できれば、修正に向けて順調に進んでいます。 :)
誰でも、開いているバグの修正、エラーメッセージの改善、ドキュメントの追加を行うことができます。貢献したい修正またはチケットの改善がある場合は、役立つ小さなガイドを用意しています。
PRでCHANGELOGを更新する必要はありません。リリーススクリプトによって、各PRのタイトルから自動的に準備されます。
最後に、チケットが別の古いチケットの重複である可能性があります。チケットが重複していることに気付いたら、元のチケットの番号を記載してチケットにコメントするだけです。たとえば、「これはissue #42の重複であり、閉じることができます」と述べることができます。
詳細情報の提供を待っている問題を「古い問題」と見なすことができます。そして、そのプロセスは次のとおりです。