FSWP Core Contributor は何をしますか？
基本原則（常に適用）: fswp-developer/references/lean-coding.md（少なく書いて、まず再利用）、fswp-developer/references/coding-standards.md（コーディング規約、ドキュメント、i18n、アクセシビリティ）、および fswp-security-engineer（入力、出力、認可）。
ここに記載されたワークフローの事実は、2026-09-28 時点で Core Contributor Handbook と照合済みです。Core のプロセスは変更される可能性があります。助言を行う前に、fswp-developer/references/official-docs.md で時間に敏感な情報を確認してください。ここで何かを送信することはありません。ユーザー自身がチケットを提出し、プルリクエストを開きます（GitHub の自動化は予約されています。fswp-developer/references/github-foundation.md を参照）。
まず変更をルーティングする
| 変更箇所 | 送り先 |
|---|---|
| 脆弱性 | Core ハンドブックにリンクされた非公開セキュリティプロセス。公開チケットや PR には決して送りません。その旨を伝えて停止します。 |
| PHP、管理画面、API、テスト、ほとんどの Core コード | Trac チケットと、WordPress/wordpress-develop に対するパッチまたはプルリクエスト（このスキル） |
| ブロックエディター（Gutenberg パッケージ、エディターUI、サイトエディター） | WordPress/gutenberg の Issue とプルリクエスト。Core はそこからアップデートを受け取ります。そのリポジトリのコントリビューティングガイドを読んでください。 |
| プラグインやテーマのバグ | Core ではありません。fswp-maintainer を使用して、そのプロジェクトに報告してください。 |
| ドキュメント | 該当するハンドブックの Docs チームのプロセス |
まずチケットを作成する
- Trac（https://core.trac.wordpress.org/）で症状を検索します。チケットの履歴とパッチを読んでください。
- チケットが存在しない場合、下書きを作成します。正確なタイトル、WordPress/PHP バージョン、再現手順、期待される動作と実際の動作、そしてそれがバグ（欠陥）であるか機能拡張であるかの理由を記載します。ユーザーが適切なコンポーネントに提出します。
- チケット上のワークフローキーワード（例：単体テストの要求）に注意して従ってください。
環境
通常のサイトではなく、開発用チェックアウトを使用します。
WordPress/wordpress-developをクローンします（正規リポジトリの Git ミラー。正規リポジトリは Subversion で管理されています）。- 標準ワークフローには Docker と Node が必要です。チェックアウトルートから:
npm install、npm run build:dev、npm run env:start、npm run env:installを実行します。 - PHP テストは
npm run test:phpで実行します。PHPUnit の引数はダブルダッシュの後に渡します。例:-- --group formatting。@ticketタグが付いたテストはチケット番号でグループとして実行されます。マルチサイトは独自の設定ファイルがあります（-c tests/phpunit/multisite.xml）。AJAX テストは--group ajaxで実行します。 - Docker 以外のワークフロー（Composer、PHPUnit PHAR）も存在します。ハンドブックの PHPUnit ページを参照してください。
変更を作成する
- trunk からブランチを作成し、ブランチ名はチケット番号にします（例:
12345-short-description）。変更は 1 つのチケットに集中させてください。 - コーディング規約: WordPress PHP、JS、CSS、HTML の規約（Yoda 条件、タブ、スペース、エスケープ/サニタイズルールを含む）。変更したファイルで PHPCS を実行します。
- インラインドキュメント: Core スタイルに従った、新規または変更された関数、フック、クラスに対する PHPDoc。
@sinceはチケットのマイルストーンが示すバージョンに設定します。 - 後方互換性: Core はパブリックな動作をほとんど壊しません。削除する代わりに非推奨にします（
_deprecated_function()など）。フィルターとアクションは安定したままにし、関数シグネチャを維持します。 - テスト:
@ticketタグを付けて、変更前は失敗し変更後は合格する PHPUnit テストを追加または更新します。バグパッチにテストがない場合、通常は追加を求められます。 - セキュリティとパフォーマンス: 他の WordPress コードと同じルール（
fswp-security-engineer、fswp-performance-engineer）が適用され、より高い基準が求められます。 - 無関係なフォーマット変更やリファクタリングをバンドルしないでください。
提出（ユーザーが行う）
- Trac チケットに
.diffファイルを添付します。ファイル名はチケット番号にします。または、WordPress/wordpress-developに対するプルリクエストを開き、チケットを参照させます。プルリクエストはレビュー用に使用され、GitHub 上ではマージされません。コミッターは正規リポジトリを通じてコミットするためです。 - チケットにコメントを投稿します。パッチの内容、テスト方法、テスターが従う手順、および未解決の質問事項を記載します。
references/ticket-comment-template.mdを使用してユーザー向けにドラフトを作成します。 - レビュー、変更要求、遅いサイクルを想定してください。チケット上で返信し、パッチを更新し、trunk にリベースし続けてください。
引き渡す前に確認する
Core チェックリストを使用して fswp-qa-engineer を実行します。再現手順が変更前は失敗し変更後は合格すること、関連するテストグループが合格すること、変更行でコーディング規約がクリーンであること、ドキュメントが存在すること、後方互換性が維持されていることを確認します。