ベータテストポイントリリースや最先端の WordPress ナイトリービルドだけでなく、報告されたバグのテストや確認、WordPress に組み込まれる可能性のあるパッチをナイトリービルドに組み込まれる前にテストすることも重要です。この仕事は、バグを修正する人として働く (あなたのような) ボランティアによって主に処理されます。
バグトラッカーには、報告者、修正する人、開発者、コミッターによって処理される、報告されたあらゆる種類のバグ、機能強化、新機能、およびさまざまなタスクなどの多種多様なワークフローが含まれています。全体像を一度に把握しようとすると非常に混乱するかもしれませんが、その必要はありません。
バグトラッカーを初めて使用する場合、手伝いたい場合は、ここで最初の簡単なワークフローを始めることができます。一度このワークフローに時間を費やせば、トラッカーの他の部分がよりよく理解できるようになり、同様にサポートが必要な Trac の他の領域でも自信を持って探索できます。
バグスクラブに参加するには、今後の WordPress ミーティングに注目してください。
バグ修正レビューのワークフロー
このワークフローでは、bugs/defects に分類されるチケットと、それらのバグを修正すると思われるパッチが添付されたチケットのみを扱います。さらに、このワークフローは Awaiting Review または Future Release マイルストーンにあるチケットのみを対象としています。つまり、これらのチケットはほとんどが、まだレビューや徹底的なテストが行われていない、報告されたバグやパッチです。Trac の Patches to Defects That Need Review レポートはこれらのフィルターをすでに処理しているため、今すぐ開いてください。
このレポートには、(この記事の執筆時点で) 600を超える固有のチケットがあるため、最初のステップは、そのうちの1つを選択して開始することです。もしあなたがバグ修正を始めたばかりなら、12ヵ月以上前のチケットは避けることをおすすめします。古いチケットは通常、議論を呼ぶような変更を含んでいたり、複雑な解決策を伴う複雑な問題が含まれており、より厳しいレビュープロセスを必要とします。そのため、通常レビュープロセスが1年以上滞っています。
自分がよく知っている WordPress の部分に関連するチケットに取り組むようにしてください。レポートはコンポーネントごとにグループ化されているので、最初に作業するチケットを見つけることがとても簡単になります。
最後に、reporter-feedback または dev-feedback というキーワードのチケットはスキップしてください。報告者またはコア開発者からの詳しい情報がなければ、これらのチケットに対して何も行うことはできません。
取り組みたいチケットを見つけたら、選んだチケットにどのように対処すべきか、ここでの残りの手順を読み進めてください。
1. チケットがバグであることを確認する
このレポートのチケットに必要な最初のステップは、そのチケットが機能リクエストや機能強化ではなく、実際にバグであることを確認することです。
新しいチケットはデフォルトで Awaiting Review マイルストーンに割り当てられるため、報告者がパッチを添付し、has-patch キーワードを適切に追加して提出したと仮定すると、このレポートには完全に新しい問題が含まれます。これらのチケットの中には、適切な issue タイプ、コンポーネント、キーワードで提出されたことを確認するための初期レビューが行われていないものがあります。チケットプロパティのドキュメントは、チケットの種類とコンポーネントがどのような値に設定されるべきか、そしてチケットがどのようなキーワードを持つべきかを明確にするために役立つはずです。
新しいチケットがこのレポートに含まれるために必要なことを考慮すると、通常、ここにリストされたチケットを提出している報告者は、チケットのプロパティとその設定方法について十分に理解しています。ただし、これはルールの例外の1つであり、他のワークフローではこの点にもっと注意を払う必要があります。
このワークフローで注意しなければならない最も一般的な問題は、不具合として提出されたチケットですが、実際にはその問題 (およびパッチ) は機能強化または機能リクエストであるものです。チケットに新しい機能、あるいは完全に問題なく動作している (ただし、おそらく最も理想的な方法ではない) 既存の機能への変更が記述されている場合、チケットの種類は機能強化 (既存のコンポーネントの変更/追加の場合)、または機能リクエスト (まったく新しい機能の場合) として設定する必要があります。この場合、チケットの種類を修正し、次のチケットに進んでください。
チケットが実際にバグである場合、報告されたバグが実際に再現可能なものであることを確認する必要があります。
2. バグを確認する
常に、WordPress の SVN trunk チェックアウトを使用してバグをテストする必要があります。まれに重大なバグやリグレッションが発生する場合は、WordPress の最新の安定版リリースでもバグをテストしてください。
バグが特定のバージョンの PHP、MySQL、ブラウザ、特定の WordPress 設定 (マルチサイト、ユーザーの種類と権限、異なるプラグイン/テーマなど) でのみ発生する可能性があることも覚えておいてください。
- 報告者の説明が明確でなく、再現できない場合は、報告者に説明を求め、チケットに reporter-feedback キーワードを追加してください。
- もし報告者の説明が非常に明確で、あなたが彼らの説明する条件下でまだバグを再現できない場合、テストしてバグを再現できなかったというメモを残してください。
- もしあなたがバグを再現できない (報告者を除く) 二人目のテスターである場合は、報告者のインストール/設定に何か他の問題がある可能性があります。この場合、チケットに dev-feedback キーワードを追加し、次のチケットに進んでください。
3. パッチを確認する
バグを再現できた場合は、パッチを確認します。あなたが経験豊富な開発者で、パッチの書き方に問題があることをすぐに見つけられるのでない限り、パッチがどのように書かれたかについてはあまり気にしないでください。
あなたがバグを確認できた同じインストール環境に、提案されたパッチをダウンロードして適用します。チケットに複数のパッチが添付されていることがありますが、その場合、通常は最新の提案されたパッチだけをテストする必要があります。ただし、他のパッチがテストされていない場合は、それらもテストする必要がある場合があります。
次の条件のいずれかに当てはまる場合、has-patch キーワードを削除し、needs-patch キーワードを追加してください:
- パッチが適切に適用されないか、コーディング規約に従っていない。この場合、needs-refresh キーワードを追加してください。
- パッチがバグを修正しない。これは当然のことのように思えますが、WordPress の開発バージョン用に書かれたものではないパッチでも、変更された箇所にはきちんと適用されることがあります。パッチは特定のバージョンの PHP と MySQL でのみバグを修正するかもしれませんし、マルチサイトではバグを修正しないかもしれません。
- パッチによって新しいエラーや警告メッセージが発生する。デバッグを有効にしてテストすることを忘れないでください。
- パッチが適用されると、新しいユニットテストが失敗する。
- パッチが適切なデータ検証と出力のサニタイズを使っていないか、ユーザーの種類と権限をチェックすべきときにチェックをしていない。
- パッチが、ここで説明されていないその他の理由により適切ではない。私たちは、WordPress において読みやすく、効率的で安全なコードを目指しています。そのため、たとえ実際にバグが修正されていたとしても、パッチの改善すべき点を指摘することを恐れないでください。
また、has-patch キーワードを削除し、needs-patch を追加するだけでなく、パッチが受け入れられない理由をチケットのノートで必ず説明してください。ただし、パッチがすべての面で良いものである場合は、パッチのどのような点をテストしたかをチケットのメモで説明し、次にそのチケットをトリアージしてください。
4. チケットのトリアージ
バグとパッチの両方が確認された場合でも、多くの場合、このワークフローではチケットの優先度を調整する必要があります。また、そのパッチを次のポイントリリース (x.x.x) で適用するのか、次のメジャーリリース (x.x) で適用するのか、それともさらに将来に延期するのかを決定する必要があります。
注意: 新しい Trac ユーザーには、デフォルトではチケットの優先度を調整したり、チケットを別のマイルストーンに移動したりする機能がありません。そのため、このワークフローと Trac 全体に慣れるまでは、このステップでは優先度やマイルストーンを調整する必要があることを説明するメモをチケットに追加するだけです。バグを修正する他の人が更新を確認し、それが正しいと思われる場合は、それに応じてチケットを調整します。これらの調整を自分で行うことに慣れたら、Make WordPress Core ブログでアクセスをリクエストできます。
リグレッションや重大なバグに関連するチケットは、すぐに最優先事項に設定し、次のポイントリリースのマイルストーンに割り当ててください。リグレッションとは、最新リリースやその前の WordPress リリースではまったく問題なく動作していた機能が壊れていることであり、私たちはこれらを真剣に受け止めています。リグレッションとまではいかなくても、多数のユーザーにとっての主要な機能が壊れているような重大なバグも同様です。これは主に、WordPress の公開側を壊してしまったり、管理パネルが大きく壊れてしまったりするような、露出度の高いバグを指します。これは非常にまれであり、慎重に扱われるべきです。
単純なタイプミスの修正、インラインドキュメントの追加、小さなスタイル/外観の問題の修正などのパッチを含むチケットは、優先順位を低く設定してください。
このワークフローの残りのチケットはすべて、次のメジャーリリースのマイルストーンにトリアージされるべきです。これは通常、すべてのチケットに適用されるわけではなく、ワークフローでは品質パッチを伴う確認済みの不具合のみに適用されます。WordPress の開発サイクルが次のメジャーリリースのリリース候補の途中である場合、重要なバグ修正は引き続き Next Release マイルストーンに割り当てる必要があります。ただし、それ以外のものはすべて Future Release マイルストーンに移し、x.x-early というキーワードもつける必要があります (x.x は、リリース候補が出ているリリースの次のメジャーリリースです)。たとえば、3.6のリリース候補のフェーズでは、重大ではないバグに対する確認済みの修正には、3.7-early というキーワードをつける必要があります。