Norwegian
version of this page
Contact TSD
How to write good support requests
Writing descriptive and specific support requests helps the support team understand your request quicker. Below is a list of good practices.
Create a ticket
Send an email to tsd-drift@usit.uio.no to create a support ticket. Tickets are tracked and have higher visibility. Everyone in the support team can see the tickets and respond appropriately.
Create a ticket for each issue
Creating a ticket for separate issues ensures that each issue is given the appropriate priority and can be tracked easily. Adding a new issue to a resolved or unrelated issue diminishes its visibility.
Give descriptive and specific subject line
The subject line should be descriptive and specific to the issue. “Problem in TSD” is not descriptive enough and does not differentiate itself from other issues.
Specify the environment and intent
Describe the system environment. A suggested template to start out with:
Project number: (eg: pXXX)
Username: (eg: pXXX-<username>)
Operating system of the virtual TSD-machine: (eg: Windows or Linux)
Login protocol: (eg: VMware web-client, or Vmware Horizon client)
First time login? (yes/no)
Description of issue:
Telephone number:
Any extra information like describing software involved, specifying filenames and paths, attaching screenshots will mostly be very helpful to the support personnel working on your ticket.
Tell us what actually worked so far and what was attempted to solve the issue. Often we get requests of the type “I cannot get X to work”. The request does not mention whether it has ever worked or if this was the first attempt.
Be descriptive and give us enough information to understand what you are trying to achieve.
Describe the original problem and intent (The XY problem)
Often we know the solution but we don’t know the problem. Please read http://xyproblem.info which happens when a user’s original issue is masked by a different problem.
In short (quoting from http://xyproblem.info):
-
User wants to do X.
-
User doesn’t know how to do X, but thinks they can fumble their way to a solution if they can just manage to do Y.
-
User doesn’t know how to do Y either.
-
User asks for help with Y.
-
Others try to help user with Y, but are confused because Y seems like a strange problem to want to solve.
-
After much interaction and wasted time, it finally becomes clear that the user really wants help with X, and that Y wasn’t even a suitable solution for X.
To avoid the XY problem, if you struggle with Y but really what you are after is X, please also tell us about X. Tell us what you really want to achieve. Solving Y can take a long time. We have had cases where after enormous effort on Y we realized that the user wanted X and that Y was not the best way to achieve X.