Writing Patches

Picking a ticket Picking a ticket

  • Pick a bug to work on
  • Work on the most important bugs first
  • Make sure documentation gets updated
  • Take extra time to do it right the first time
  • Test your code
  • Regressions are bad
  • Smaller patches get reviewed faster
  • Work on multiple bugs in parallel
  • Get advice before, not after
  • More detail for these guidelines here: Mozilla Development Strategies
  • Review disagreements best handled quickly in Slack with summary on Trac

Top ↑

Requirements for patches Requirements for patches

  • Inline documentation
  • Automated testing (spin-off)
  • Feature requests
  • Patch development scripts, and don’t minimize
  • Images (attach originals)
  • Patches should be made against the latest code in the SVN repository
  • Patches should be made against the root WordPress directory (not against a subdirectory)
  • … however, if your patch includes tests, both the code changes and tests can be included in the same patch.
  • Patches should adhere to the coding standards

Top ↑

Expectations for patches Expectations for patches

  • Expect rounds of feedback
  • Expect potential for rejection (wontfix, invalid, plugin, etc.)
  • Understand it may not be a priority
  • Bugs: Expect steps to reproduce
  • Enhancements: Expect request for justification
  • UI/UX: There is a separate process

Top ↑

Seeking feedback Seeking feedback

  • Slack, bump, find committer, etc.
  • Knowing where to ask for help: https://make.wordpress.org/chat/

Top ↑

Helpful tools/tips/code snippets/design patterns Helpful tools/tips/code snippets/design patterns

  • parse_args

Top ↑

Pro tips Pro tips

  • Good attributes of a core contributor
    • Brevity (Patches, Comments, Personal Agendas)
    • Thick Skin
    • Don’t assume everyone is stupid
    • Do your homework (study code and history)
    • Constraints of pragmatism and back compat
    • Constructive criticism
    • Humility