Creating an appropriate ticket
If you have a support contract with Code Enigma, you can ask our multi-disciplinary team any question about our services through our secure ticketing system, Redmine.
You can also access Redmine through the client dashboard.
The subject
The purpose of the subject is to tell us what the problem is. If, for example, you have a module that awards users points based on their activity on the site, which returns incorrect results or a fatal error, a good ticket subject would be: Custom user points module returns a fatal error.
This is descriptive enough for support to grasp a basic understanding of the issue. Reporting the issue with the subject "Bug" or "Fatal Error!" are poor subjects as they are not descriptive.
The description
Please include all the detail you can about the issue. Screenshots of errors and error log entries help the support team to understand what to look out for when attempting to replicate the issue.
Include any URLs where the errors are occurring, or explain in as much detail as possible what you were doing at the time of receiving the errors. Providing the date and time when an error occurred can also help the support team to locate information relating to the error in the server logs.
It would also be useful to include information on which environment the issue occurs in (if you have a dev/stage/prod type setup).
Detail the steps you’ve taken to try and solve the issue, as this will prevent the support team from repeating the same steps and getting the same results. You should include the steps to reproduce the issue, as this will help the support team when it comes to debugging.
Choosing the correct tracker
There are two trackers available, Task (Systems) and Task (Dev Support). If your ticket is related to the application itself, eg Drupal, WordPress, then select Task (Dev Support), otherwise, select Task (Systems).
If you're not sure which tracker to choose, leave it set to the default, and the support team will change it, if necessary.
Assigning the ticket
Upon creating the ticket, a notification will be sent to the support team, alerting them that a new ticket has been created. We recommend, in most cases, tickets are left unassigned so they can be allocated to the next available team member. If you want to add an assignee to the ticket, please DO NOT assign it directly to an individual. In these cases, you can use the ‘ce’ groups (ceSysadmins, ceSupport).
You may add Watchers to a ticket by checking the relevant boxes. Each watcher you select will receive an email notification that they have been added as a watcher to a ticket. It's not advised to select everyone, as there will be some members of staff who do not know about your project.
If you consider the issue to be urgent, it is advised to add several watchers, so they are informed of the creation of the ticket. However, an issue you may consider urgent may not fall under our ‘Urgent’ category. All Drupal-related tickets will be responded to within 24 hours. If you do not have an SLA-backed server package, the priority parameters will have been pre-arranged with you along with their respective response times (more on that in the next section). Tickets that fall under this SLA are server-based issues.
Status
When a task is created, it follows the following workflow:
- New - An issue created but yet not actioned
- In progress -Work has started
- Blocked - Progress blocked for a given reason
- Approved, waiting to go live - The solution has passed UAT and is now pending release
- Resolved - On live, pending ticket being closed (usually by client)
- Closed - The issue is closed
- Closed (due to inactivity) - After 7 days has passed on a ticket in resolved state, the ticket will close automatically
Iceboxes
Worth noting here that every client has an Icebox and it's really important to use it. We want to get through as many of tickets as possible, but each takes time. If a ticket isn't in the Icebox, we'll work on the premise that you want us to spend time working on it. If this was to use up your remaining time from your Monthly support contract or introduce PAYG charges, you would see that from your overview (under 'Hours remaining'). So if you'd rather prioritise something else, or save that time for an emergency, you need to move the request into your Icebox. You can do this by updating the issue, changing the project from Support to Icebox
Priority
Redmine provides four priorities to choose from: Low, Normal, High and Urgent. The priority of the ticket is generally used to judge only the order in which the tickets should be looked at. For example, if you have three normal priority tickets, two high priority tickets and one low priority ticket, the two high priority tickets will be looked at first, then, providing there is remaining support time, the normal priority tickets will be looked at. If there is support time remaining after all other tickets have been looked at, low priority tickets will be looked at and dealt with.
Urgent – A critical failure, resulting in an outage of client-facing services.
Full information regarding response times can be found in our SLA
High – A serious issue, resulting in users being inconvenienced, for example:
- Solr Search server stops operating
- Some image styles are not generating
- External services (e.g. an SFTP drop or an API) cannot function properly due to a server fault
- An editor can not create content and has a critical deadline
Normal – A minor issue, for example:
- A problem with a service that does not affect the client experience
- A cron task needs creating
- Assistance is required managing a server component
- An editor can not create content
Low – A maintenance task or planned work, for example:
- A new site launch
- A new service launch/feature
- A new user account needs creating for a server/application
- A package upgrade
- A new continuous integration job
The first response will be made within the pre-arranged times, depending on the priority.
Bad examples
We've received tickets with the subject of "Bug", "Urgent ticket" or "Help!".
Descriptions that do not contain enough information, such as not providing URLs where errors were found or not providing the steps necessary to reproduce the error(s) are just two bad examples of a ticket description.
Such tickets take extra time to process as we have to ask the customer for more information before we can begin to investigate the issue.
Text formatting
You can format the text in the description field. You can make text bold, underlined, italicised, create ordered and unordered lists, headings and tables, amongst many other things. You can use this guide to help you with text formatting in Redmine.
A deeper look into Redmine
Now you know the basics, you should check out our blog post on Redmine for current support clients, where you can learn about how to best manage your projects with us.