パッチを書く
チケットを選ぶ
- 取り組むべきバグを選ぶ
- 最初に最も重要なバグに取り組む
- ドキュメントが更新されていることを確認する
- 最初から正しく行うために、時間をかける
- コードをテストする
- リグレッションは良くない
- 小さなパッチほどはやくレビューされる
- 複数のバグに並行して取り組む
- 後ではなく事前にアドバイスを得る
- これらのガイドラインの詳細については、こちらをご覧ください: Mozilla 開発戦略
- レビューの相違は Slack ですばやく処理し、Trac にまとめることがベストです
パッチの要件
- インラインドキュメント
- 自動テスト (スピンオフ)
- 機能リクエスト
- WP_DEBUG と SCRIPT_DEBUG
- 開発スクリプトにパッチを適用し、最小化しない
- 画像 (オリジナルを添付すること)
- パッチは SVN リポジトリの最新のコードに対して作成されるべきです
- パッチは WordPress のルートディレクトリに対して作成されるべきです (サブディレクトリに対してではありません)
- ただし、パッチにテストが含まれている場合は、コードの変更とテストの両方を同じパッチに含めることができます。
- パッチがコーディング規約に従っていること
パッチに期待されること
- 一連のフィードバック
- 却下される可能性もあります (wontfix、無効、プラグインなど)
- 優先順位が低いかもしれないこと
- バグの場合、再現するためのステップ
- 機能強化の場合、正当性があること
- UI/UX の場合は、別のプロセスがあります
フィードバックを求める
- Slack、bump、コミッターを探す、など。
- どこに助けを求めればいいかを知る: https://make.wordpress.org/chat/
役立つツール・ヒント・コードやスニペット・デザインパターン
- parse_args
プロのヒント
- コア貢献者の良い特徴
- 簡潔さ (パッチ、コメント、個人的な要約)
- 打たれ強いこと
- みんなが愚かであると思わないこと
- 下調べをする (コードと歴史を勉強する)
- 実用性と後方互換の制約
- 建設的な批判
- 謙虚さ
最終更新日: