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
- 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).