定義された意味を持ついくつかのキーワードがあります。これらは一般的に、特定のチケットやリリースのワークフローを管理したり、レポートを生成するために使用されます。
ステータスにもとづいたキーワード
changes-requested
フィードバックがあったため、添付されたパッチを更新する必要があります。
close
このチケットは、修正以外の処理によってクローズされる候補です (例: wontfix、worksforme、invalid、または duplicate)。しばしば reporter-feedback や 2nd-opinion と一緒に付与される事があります。そうでなければ、チケットは close キーワードを追加する代わりにクローズされているはずです。
early
このキーワードはコミッターのみが付与できます。このキーワードは、そのチケットが優先され、次のリリースサイクルの早いフェーズで取り組むべきものであることを示します。
good-first-bug
このキーワードは、新しい貢献者がより複雑なチケットに取り組む前に、プロセスに慣れるための良い出発点であることを示します。
has-patch
チケットに解決案が添付され、レビューの準備ができています。
has-screenshots
needs-screenshots と一緒に機能します。チケットに少なくとも1枚のスクリーンショットがあれば、has-screenshots とタグ付けします。さらにスクリーンショットが必要な場合は、すべてのスクリーンショットが提供されるまで、チケットに needs-screenshots を残してください。#has-screenshots は視覚的な変更履歴と Today in the Nightly の投稿を作成するために使用されます。クローズされたチケットからこのタグを消さないでください。has-screenshot と needs-screenshots はコミット後のライフサイクルの一部であり、クローズドチケットに存在することが期待されます。need-screenshots はすべてのスクリーンショットが提供されるまで一時的に存在し、has-screenshots は永続的に存在します。
has-unit-tests
チケットはレビューされ、解決することが望ましいと判断され、最新のパッチはユニットテストを含んでいます。このキーワードは needs-unit-tests と同様に、提案された変更が他の問題を引き起こす危険性が高いことを示します。
needs-codex
Codex のドキュメントを更新または追加する必要があります。Codex が更新されたら、チケットからキーワードを削除してください。
needs-docs
コードのためのインラインドキュメントが必要です。これらは、個々のファイルに対するプレースホルダーチケットか、コミットする前にドキュメント化が必要な新機能のパッチを持つチケットのどちらかです。
needs-patch
このチケットはレビューされ、解決することが望ましいと判断され、特にパッチが必要であるとマークされています。または、提出されたパッチが動作せず、やり直しが必要な場合です。
needs-refresh
パッチが提出された後、近くのコードが変更されたため、提出されたパッチが WordPress のコアファイルにきれいに適用されなくなった場合です。パッチをマージして再提出する必要があります。
needs-screenshots
UI を変更するパッチやコミットにはスクリーンショットが必要です。視覚的なイテレーションをドキュメント化します。スクリーンショットをチケットに直接アップロードするか、音声や映像記録のようなより複雑なドキュメントの場合は make/flow に投稿してください。make/flow の投稿は、すべてチケットと相互にリンクしてください。少なくともデスクトップとモバイルの両方のスクリーンショットが提供されたら、チケットから needs-screenshots キーワードを削除してください。物理的なデバイスで撮影されたフルコンテキストを持つスクリーンショットが望ましいです。新しいパッチでは、新しいスクリーンショットが必要です。チケットに必要なスクリーンショットが少なくとも1枚あれば、has-screenshots というタグを付けてください。#needs-screenshots
needs-unit-tests
このチケットはレビューされ、解決することが望ましいと判断されました。そして、他の問題を引き起こすリスクが高いため、機能および存在する可能性のあるパッチをテストするために、変更をコミットする前にいくつかのユニットテストを書くことが推奨されています。
phpNN
このキーワードは php-compatibility フォーカスと組み合わせると、互換性の問題やタスクを最初に導入した PHP のバージョン (つまり NN) を特定します。たとえば、php80 キーワードは PHP 8.0が最初に非互換性を導入したバージョンであることを示します。
アクションにもとづいたキーワード
2nd-opinion
問題や解決策について別の意見が必要です。
commit
このパッチは、開発コミュニティの信頼できるメンバーによってレビューおよびテストされています。したがって、このパッチはコミット候補とみなされ、WordPress のコアファイルに追加する準備ができています。
dev-feedback
コア開発者または開発コミュニティの信頼できるメンバーからの回答が求められています。
dev-reviewed
リリースのためにブランチが作成された後、各変更は (ビルドとテストスイートの変更を除いて) 2人のレギュラーコミッターによってレビューされる必要があります。最初のレビュアーは「commit dev-feedback」というキーワードを設定し、2番目のレビュアーは「commit dev-reviewed」というキーワードを設定しなければなりません。レギュラーコミッターがパッチを作成した場合、追加で必要なレビューは1回だけです。
fixed-major
開発サイクルの後半 (リリース用のブランチが作成された後) で、次の「メジャー」バージョン (trunk) で問題が「修正」され、レギュラーコミッターによって次のリリース用のブランチにマージされる必要があることを示します (マイナーリリースブランチから trunk にマージする必要があることを示す「fixed-minor」というキーワードもあります。これらのキーワードの詳細については、こちらの記事をご覧ください。「fixed-major」と「fixed-minor」キーワード)。
has-copy-review
コピーライターが文言の変更案を検討し、意見を述べました。
has-dev-note
この変更の概要を説明する dev note が make core ブログに掲載されました。この変更は、重要な新機能を提供したり、大規模なリファクタリングを行ったり、破壊的な変更を含んでいます。
has-privacy-review
提案された変更に対して、プライバシーへの影響を検討するコアプライバシーチームから意見が出されました。
i18n-change
開発サイクルの後半 (翻訳文字列のフリーズ後) にのみ使用し、翻訳者に通知するために、翻訳文字列の変更の可能性を追跡します。
needs-copy-review
コピーライターの意見が必要となる文言の変更案です。
needs-design
デザイナーはコードを書く前に、提案された変更がどのように見えるかまたは動作するかを確認するためのプロトタイプを作成する必要があります。
needs-design-feedback
デザイナーは、変更案を確認し、フィードバックする必要があります。
needs-dev-note
この変更は、make core ブログに dev note を掲載する価値のあるものです。もしその変更が重要な新機能や大規模なリファクタリング、あるいは破壊的な変更を含んでいるならば、常に dev note を必要とします。
needs-privacy-review
提案された変更のプライバシーへの影響に関して、コアプライバシーチームからの意見が必要です。
needs-testing
解決策をテストするために、一人または複数の人が必要です。パッチをテストするときには、テストしたパッチのファイル名、パッチのテスト方法、使用した WordPress のバージョン (正式リリース版でない場合は SVN リビジョン番号も含む) をコメントで知らせてください。
reporter-feedback
報告者からの回答が必要です。問題を調査している人からの質問への回答がなければ、さらなる調査は望めません。