I was asked by the organizers of WordCamp Vancouver to give a lighting talk on how to submit a proper Trac Ticket for WordPress. Here is the transcript of the talk. Hopefully the video will make it’s way up to WordPress.tv.
After using WordPress for years my First Trac Ticket I submitted was actually only last December and interesting enough it’s still open as of August 2013.
But first… a word from Nacin…
security [at] wordpress [dot] org
What is Trac?
Trac is open source software that WordPress uses. It is the place where all of those design / functionality decisions are made. It is part project management, part bug tracking software, part repository (via SVN). It is all of those things at exactly the same time. The only thing it doesn’t do is provide support… but don’t worry that’s what the forums are for…
Check list before submitting a ticket.
a. What version of WordPress are you running?
– If your running alpha or beta make sure you grab the latest build before submitting.
b. Has it been submitted previously?
– Do a query on trac before submitting a new one.
c. Check in various browsers. Is it consistently replicated? Which browser does what?
– Record in the description what you find…
d. If you turn off all of your plugins does still happen?
e. If it’s something visual take screenshots. Annotate if possible.
– You can upload screenshots directly to trac or use something like cloud app.
f. A link to the page or site with the issue.
g. Make sure the code is actually core and no your own.
– eg. If you child themes has code in the function file that overwrites the parent theme then it is your code and not core.
You now have all the details required to complete a useful trac ticket.
Go to https://core.trac.wordpress.org login using your same WordPress.org login details.
Properties:
1. Summary: Title of the Trac Ticket.
2. Description: Explain the issue explain as much as you can. You can also upload screenshots directly to trac. A lot of people use screenshot programs like cloud app. Any service will work as long as it is reliable.
3. Type: Bug, Enhancement or Feature Request
4. Version of WordPress:
– Which version of WordPress are you using to product the bug?
(eg. Trunk is currently in 3.7 and once that is release Trunk will be into 3.8)
5. Workflow Keywords: (couple common ones)
• Reporter Feedback (needs more detail from the actual reporter of the ticket)
• Needs Patch (needs a patch ???)
• Has patch (either you or someone has submitted a patch to this)
A full list of keyword descriptions can be found here.
If you don’t know what the keywords means then don’t apply it. Core committer like Sergey Biryukov who truly have amazing attention to detail in Trac will apply keyword if needed. (If you put enough detail in the description they will be able to figure it out)
6. Priority: Reporters without commit status can’t set this… But they range from:
• Trivial
• Major
• Normal
• Highest OMG BBQ.
“Which means it is as Important as BBQ… Sadly you don’t get BBQ if you close this ticket.” ~ Samuel Wood ( Otto42 ) WordCamp Seattle 2013
7. Component:
• Default Themes are called: Bundled Themes as they are bundled with core.
• Post Format are about Post Format’s
• Widgets are about Widgets
• etc…
If you don’t know where it fits just choose general and those above you on the “Trac food chain” like Sergey will find the proper home…
If you want to find out more about the WordPress Trac and how to submit tickets visit the WordPress Core Contributors handbook.
Ha ha, saw this post and it reminded me of a previous in house job that I had that used Trac tickets, super useful, but the thing that made me laugh is that I remmeber ‘non techs’ always filling them out incorrectly or without any detail, grrrrr…..