パッチを書く

チケットを選ぶ

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

Top ↑

パッチの要件

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

Top ↑

パッチに期待されること

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

Top ↑

フィードバックを求める

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

Top ↑

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

  • parse_args

Top ↑

プロのヒント

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

原文 / 日本語訳

最終更新日: