I wrote this guide at $job-1 (where it seems to be still in circulation) and thought maybe it could be a useful thing to share further.
We love a good ticket. It makes the job easier, it gets done faster, and it keeps everyone a bit happier. Here’s a quick guide to what makes good tickets.
Describe the problem - not the solution
Whilst ideas about what might be wrong can be helpful, the absolute best thing you can do is describe the problem in its entirety
A descriptive ticket title
so that we can find your ticket at a glance
Relevant information and examples
If something is broken, then please outline how we can test it out for ourselves. How does it normally work? What happens now? When did it break?
If you need something changing, what is currently configured, and what would you prefer?
If you need something new, is it like anything that currently exists?
What’s the timescale?
Any indication of due dates, or potential blockers are useful
Set the ticket priority as appropriate
If it’s urgent, it’s usually best to log a ticket and then come over in person
What’s the value?
If something is broken or not working correctly, what is the impact to the business?
If the ticket is for some new infrastructure, what project is it supporting?
Can you justify your request? How does it fit into the organisational priorities?
This information helps us do the most important tickets first.
Other helpful things to include:
Error messages
Screenshots
Example URLs
What not to include:
A direct set of commands to run without a full explanation of the problem.
You don’t need to say thank you! At least not on the ticket, as this re-opens closed tickets. You’re welcome to come and say thank you in person (or buy us a beer at the pub).