What makes a good WordPress bug report. From 2013 WordCamp Orlando contributor sessions with Andrew Nacin and Mark Jaquith.

good-bug-report.txt

What makes a good bug report:


   * Steps to reproduce, with earliest step Shouldn’t need to know code
   * Description of the bug. What you saw vs what you expected.
   * Error messages or error codes.
   * 
      * PHP errors-
      * 
         * What warning on page
         * What went in log
      * Errors could be in javascript/apache/nginx
   * Browser- try it in incognito
   * Environment
   * PHP version, MySQL Apache or nginx version- Norcross system profiler plugin
   * Does it happen with no plugins and default theme
   * Screenshots for UI issues, before and after for UI patches.
   * Possibly screencast
   * Clearly and concise. Get to point first, then details.
   * Related ticket number
   * One bug per ticket
   * Permalinks
   * Multisite or not?
   * WP_DEBUG or equivalent enabled?
   * User role logged in as when the issue happened. Or changed roles in database.

Not all of these needed, depends on the situation.