Picking a ticket #

Top ↑

Requirements for patches #

  • Inline documentation
  • Automated testing (spin-off)
  • Feature requests
  • WP_DEBUG, SCRIPT_DEBUG
  • 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 #

  • 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 #

Top ↑

Helpful tools/tips/code snippets/design patterns #

  • parse_args

Top ↑

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