バグトラッカー (Trac)
Topics
Trac は、WordPress のバグトラッカーおよびプロジェクト管理ツールとして機能するオープンソースプロジェクトです。Trac を使用することで、開発者はソースコードの履歴を閲覧するだけでなく、バグレポートや機能開発を管理できます。
チケットは、バグレポートと機能開発の両方に使用され、WordPress.org のアカウントを持っている人なら誰でも作成できます。
チケットのプロパティ
チケットには、チケットのステータスのスナップショットを提供する多くのプロパティが割り当てられています。
タイトルと説明: 明確なタイトルと説明を提供します。タイトルについては、一般的に、解決策ではなく問題を記述することが最善です。解決策ではなく問題に集中することは、一般的に良いことです。説明には、一般的に、再現手順や期待される結果 (バグの場合)、適切な根拠 (機能強化の場合) を含めるとよいでしょう。
Type: チケットは、defect (bug)、enhancement、feature request、task (blessed) の4つのタイプのいずれかに分類されます。
- Defect (bug): バグとは、エラーや予期せぬ結果のことです。パフォーマンスの改善やコードの最適化は、不具合ではなく、機能強化とみなされます。機能フリーズ後は、バグのみを処理し、リグレッション (前バージョンからの望ましくない変更) を最優先とします。
- Enhancements: フックの追加や既存機能の改善など、WordPress の簡単な改善です。
- Feature requests: これらは新機能の提案です。機能の提案は通常、アイデアフォーラムやメーリングリストで、またプラグインとして、またはメジャーリリースごとに開催されるスコープミーティングなどを通じてコアチームの注意を喚起することから始める必要があります。この種の一方的なチケットは、通常は推奨されません。
- Tasks (blessed): 次のメジャーリリースのための機能開発は、コアチームによって承認された主要機能または重要な機能強化であるタスクチケットを中心に行われます。それ以外のチケットは、この指定を受けるべきではありません。
Milestone: マイルストーンは、そのチケットが解決されると予想される WordPress のリリースで、たとえば3.7などです。デフォルトでは、スコープクリープを防止するために、すべてのチケットは作成時に Awaiting Review マイルストーンに割り当てられます。マイルストーンを変更できるのは、コミッターまたは信頼できるコア貢献者 のみです。
Keywords: マイルストーンに続いて、キーワードフィールドは最も重要なフィールドです。これらは WordPress の投稿タグのようなものではなく、私たちの開発ワークフローにおけるチケットの現在の状態を説明するキーワードの定義リストです。私たちはこれらのキーワードを使用して、重要なレポートを作成します。たとえば、needs-design-feedback とタグ付けされたチケットは、デザインチームが大きく依存しているレポートに取り込まれます。キーワードの完全なリストは Trac ワークフローキーワードを参照してください。
Component: コンポーネントは、チケットが影響する WordPress の範囲です。たとえば UI チームは、Graphic Design、UI、Accessibility のカテゴリーでチケットに取り組むことがよくあります。General や Administration などの一般的なコンポーネントよりも、特定のコンポーネント (該当する場合) を選択するようにしてください。コンポーネントは、チケットをテーマ別に論理的なグループ化を行うためにレポートで使用されます。
インポーターなどのコアプラグインのチケットは Plugins または Import コンポーネントで管理され、現在および以前のデフォルトのテーマは Bundled Theme コンポーネントで管理されます。
WordPress.org サイトの問題は、以前は WordPress core と同じ Trac で管理されていました。2013年6月現在、WordPress.org サイトに関連するバグレポートは meta.trac.wordpress.org が正式な場所となりました。あなたの問題をそこで報告するべきかどうかを判断するには、フルコンポーネントリストを参照してください。
Resolution: コードベースへの1回以上のコミットにより、チケットは fixed としてクローズされることがあります。しかし、すべてのチケットがコミットに至るわけではなく、他の理由でクローズされる場合もあります。
- duplicate: このチケットは既存のチケットと重複しており、貢献者はこのチケットを閉じることで参照されることになります。
- invalid: このチケットは、バグやサポートリクエストではありません。
- worksforme: チケットで報告されたバグが再現されません。既存のプラグインやフック、機能によってチケットの意味がなくなり、チケットはそのまま閉じられることがあります。
- wontfix: このチケットは取り組まれません。時には、バグが許容できるエッジケースであると見なされ、それ以上対処されないこともあります。これは、拡張や機能の要求がコアに含まれることを拒否されたときに使われることがあります。
- maybelater: wontfix と同様に、maybelater は、おそらく完全には拒否されていないものの、現在活発ではないチケットに使用されます。
- reported-upstream: このチケットは外部のライブラリやコンポーネントに関するもので、上流のリポジトリ (例: Gutenberg) で報告されており、そこで対処されます。
これらの5つの分類は重なる部分もありますが、チケットの分類に正解はありません。
Severity and Priority: Severity は報告者の目から見たチケットの重要度です。Priority はプロジェクト全体から見たチケットの優先度です。一般的に、重要度はバグがどの程度悪いかを判断するためのものであり、優先度は他のバグとの関係です。優先度を変更できるのはコミッターと信頼されたコア貢献者だけです。
Version: 使用している WordPress のバージョン。理想的には、影響を受けているまたは適用可能な最も古いバージョンであることです。チケットやバグ、リグレッションなどの経過を追跡するために利用するため、一度設定したらそれ以降のバージョンに更新してはいけません。
役割
Trac のチケットでは3つの役割が存在します。
Reporter: チケットをオープンした人。
Owner: このフィールドは、たとえあなたがパッチを提出していたとしても、通常は空白のままです。Owner フィールドは、コミッターと信頼されたコア貢献者によって、チケットの受け入れと割り当てのために使用されます。コミッターはこのフィールドを利用して、チケットに取り組むことを申し出たり、チケットの調査やコミット、その他のフォローをしたり、バグや機能強化をコアに取り込むことを暫定的に受け入れたりします。また機能開発の段階では、開発者が自発的に担当した分野のタスクや関連するバグレポートを受け入れることもあります。信頼できる貢献者は、誰がそのレビューに責任を持つべきかという自身の知識にもとづいて、他の人にチケットを割り当てるかもしれません。
CC: あなたのメールアドレスが Trac preferences で設定されていると、あなたが作成したチケットやあなたがコメントしたチケットの更新情報をメールで受け取ることができます。このフィールドは一般的に、あなたがチケットに自分自身を追加し、更新を受け取ることを希望していることを視覚的に確認するためのものです。時々、コミッターから要求された場合など、他の人を CC フィールドに追加することが意味を持つことがあります。ほとんどのコミッターとコア開発者は、すべてのチケットとコメントを読んでいることに注意してください。
トリアージと移動
新しいチケットは、自動的に Awaiting Review マイルストーンに割り当てられます。最初のレビューでは、クローズすることが推奨されたり、報告者やコア開発者からのフィードバックが必要だったりします。ここでよく使われるキーワードは 2nd-opinion、close、reporter-feedback、dev-feedback です。
また、コミッターや信頼できるコア貢献者によってマイルストーンに移動されることもあります。
- The next point release milestone (たとえば、現在のリリースが3.6.1の場合、3.6.2) は、重大なバグとリグレッションのためのものです。ポイントリリースは、セキュリティ修正、重大なバグ、旧バージョンの WordPress からのリグレッションのみを対象としています。これらのリリースでは、通常のバグ修正や機能強化は行いません。
- The next major release milestone (たとえば、現在のリリースが3.6.1の場合、3.7) は、リリース予定のタスクや機能、それらの機能に影響を与えるバグ、現在のアルファ版やベータ版の最新リリースに含まれるリグレッションが対象です。既存のバグが含まれることもありますが、そのバグが重大で優先すべきものでない限り、解決策が見つかるまで考慮されないことが一般的です。コミッターの判断で機能強化を含めることもできますが、アルファ版の開発中 (ベータ版のリリース前) に限ります。大規模な機能強化は通常スコープ外であるため、次のメジャーリリースでは検討されません。
- The Future Release milestone は、他のチケットのために予約されています。潜在的に良い機能強化と判断されたり、バグと確認されたりしていますが、WordPress の次のリリースに予定されているわけではありません。
フィードバックする
チケットをレビューする際の主な目標は以下の通りです。報告者と建設的な対話をし、チケットを何らかの形で解決に導くことです。解決されることはうれしいですが、すぐに解決する必要はなく、ゆっくり着実に進めていくことが大切です。初めての方は、チケットにどのようにアプローチし、対処するか、いくつかのヒントをご覧ください。
チケットに対してフィードバックする場合:
- 本人に対して、報告のお礼を言う。これらのチケットの中には、かなり古いものもあります。そのような場合は、「nacin さん、報告ありがとうございます。返信をしなくてすいません。」と言うだけで十分です。
- 報告者の初めてのチケットであった場合、コメント欄の上に表示されます。すばらしいですね。🙂
- サポート依頼であれば、WordPress.org のサポートフォーラムを紹介し、チケットを「無効」として閉じることができます。
- もし、バグレポートが機能強化のように見えるであれば、チケットを機能強化に変更します。機能強化はトリアージがやや難しいので (フィードバックがより主観的であるため)、バグから始めるほうがはるかに簡単です。
- 他のチケットと重複していないか、一度検索してみてください。
- もし、このチケットにもっとふさわしいコンポーネントがあれば、遠慮なく移動してください。
バグレポートの場合:
- trunk で再現できるかどうか、最新の安定版リリースを試してみてください。バグレポートの中にはそもそも無効なものもあるかもしれませんし、すでに修正されているものもあるかもしれません。
- 再現するために、問題を詳しく説明したり、再現するための明確な手順を書くことができる場合は、ぜひそうしてください。
- 再現できない場合は、報告者に詳細を尋ね、reporter-feedback キーワードを追加してください。もしそのチケットがクローズされるべきだと思ったら、close キーワードでマークしてください (チケットのクローズを急ぐ必要はありません)。
- 再現性のあるバグにはパッチ (場合によってはユニットテストも) が必要です !
パッチの場合:
- テストしてみてください – それは問題を解決しますか ? どのようにそれをテストしましたか ? 何か副作用はありましたか ?
- パッチがきれいに適用されない場合 (試したときに失敗するような場合) は、needs-refresh キーワードを追加してください。
- もしあなたが開発者なら、ざっとコードレビューすることを検討してください。それが WordPress コーディング規約に沿っているかどうか確認してください。
- has-patch というワークフローキーワードがない場合は、追加してください。また、レビューの結果パッチが十分でないと判断した場合は、代わりに needs-patch と設定できます。
- もしパッチが WordPress の内部構造に関わっているなら、おそらくユニットテストが必要でしょう。
- パッチがコア開発者がによってレビューされ、WordPress に含めることを検討する準備ができたと感じたら、コメントでそう言ってください。ベータ1までは、現在のマイルストーンに対してパッチを申請できます。ベータ1以降は、Future Release と early タグを付けてください。
一度コツをつかめば、より簡単なチケットのトリアージには数分しかかからないかもしれません。20～30分はかかることもあるでしょうし、テストすることがたくさんあったり、フィードバックがたくさんある場合は、もっとかかるでしょう。
もし、あなたが気に入ったチケットを見つけ、そのチケットのパッチを書きたいと思ったら、それはすばらしいことです。そのチケットにフィードバックを残し、パッチの作成に取りかかることができます。
トリアージは、あなたが興味を持つチケットを見つけるためのすばらしい方法です。最初は戸惑うかもしれませんが、もしそうであるなら、#core で仲間を見つけ、慣れるまで共同作業をしてみてください。
チケットの移動
チケットは、マイナーまたはメジャーリリースのマイルストーンから将来のマイルストーンに変更されたときに、「移動」されます。これは一般に、優先度の低いチケットに対してサイクルの異なる間隔で起こります。いくつかのチケットは、個別に複雑すぎる、または範囲外であると判断され、移動されます。
最終更新日: