パッチを書く

チケットを選ぶ

• 取り組むべきバグを選ぶ
• 最初に最も重要なバグに取り組む
• ドキュメントが更新されていることを確認する
• 最初から正しく行うために、時間をかける
• コードをテストする
• リグレッションは良くない
• 小さなパッチほどはやくレビューされる
• 複数のバグに並行して取り組む
• 後ではなく事前にアドバイスを得る
• これらのガイドラインの詳細については、こちらをご覧ください: Mozilla 開発戦略
• レビューの相違は Slack ですばやく処理し、Trac にまとめることがベストです

パッチの要件

• インラインドキュメント
• 自動テスト (スピンオフ)
• 機能リクエスト
• WP_DEBUG と SCRIPT_DEBUG
• 開発スクリプトにパッチを適用し、最小化しない
• 画像 (オリジナルを添付すること)
• パッチは SVN リポジトリの最新のコードに対して作成されるべきです
• パッチは WordPress のルートディレクトリに対して作成されるべきです (サブディレクトリに対してではありません)
• ただし、パッチにテストが含まれている場合は、コードの変更とテストの両方を同じパッチに含めることができます。
• パッチがコーディング規約に従っていること

パッチに期待されること

• 一連のフィードバック
• 却下される可能性もあります (wontfix、無効、プラグインなど)
• 優先順位が低いかもしれないこと
• バグの場合、再現するためのステップ
• 機能強化の場合、正当性があること
• UI/UX の場合は、別のプロセスがあります

フィードバックを求める

• Slack、bump、コミッターを探す、など。
• どこに助けを求めればいいかを知る: https://make.wordpress.org/chat/

役立つツール・ヒント・コードやスニペット・デザインパターン

• parse_args

プロのヒント

• コア貢献者の良い特徴
  • 簡潔さ (パッチ、コメント、個人的な要約)
  • 打たれ強いこと
  • みんなが愚かであると思わないこと
  • 下調べをする (コードと歴史を勉強する)
  • 実用性と後方互換の制約
  • 建設的な批判
  • 謙虚さ

原文 / 日本語訳