|This page is heavily inspired by https://hpc-uit.readthedocs.io/en/latest/help/writing-support-requests.html.|
If you need assistance, please email email@example.com. This will generate a new ticket and one of the members of our team will assist you as soon as possible.
In order for us to help us with your request as effectively as possible, please refer to the instructions below.
Writing good support requests is not only good for the support team, it is also better for you. Due to us having lots of help requests, the time to understand each problem is at a premium. The easier it is to understand yours, the faster we will get to it. Below is a list of good practices.
Always send requests to firstname.lastname@example.org and team members will respond there. Creating tickets via email@example.com means they will be tracked and have more visibility. Sending the request to firstname.lastname@example.org makes sure that somebody will see your request even if one of our team members is out of the office.
Before submitting your ticket, consider doing a simple internet search for your exact error message. Other scientists may have encountered similar issues and have a solution.
The subject line of your email should be descriptive. A subject line of Problem on Ganymede is too vague to be useful. This makes it difficult for us to locate your issue when trying to address it in our ticketing system.
Please remember that our entire team sees all incoming requests so it’ll help you to get your request answered quickly if it is not too generic.
When submitting help requests, please include the commands you run as well as any error messages you receive. Please copy and paste these into the email/ticket. If you fail to do so, we will likely be annoyed and request this information.
Please refrain from submitting screenshots or pictures (JPEG, PNG, etc) of what you see on your screen. Not everyone views emails using a graphical email client and doing this slows us down while trying to research your issue. We don’t care what your ticket "looks" like. We just need the relevant text copy/pasted into the email/ticket so we can quickly and easily research your problem.
Do not respond to unrelated tickets for new issues. Every issue should receive a unique number and will contain the number in the subject line. Replying to old tickets for new issues means your email will get filed under the wrong thread and will possibly be overlooked.
Please try and avoid the XY problem. If you are having issues with Y but are actually trying to do X, please let us know about X. Try and tell us exactly what you are trying to do. Oftentimes solving Y can take a long time while solving X is much simpler.
If you are submitting a request because your issue only manifests in certain situations, let us know. It’s helpful for us to know if your problem exists all the time or if it’s only present under specific conditions. Providing us with more information will make it easier to isolate the issue and avoid long email threads where we have to ask many questions. Let us know what steps you’ve taken to try and isolate the issue so that we can quickly provide assistance.
Are you running custom-compiled code? Which modules are loaded? Are you running your code in a custom Conda environment? If you use a non-default environment and fail to include that information, we will waste time debugging in a different environment.
Simply saying "X didn’t work" will not result in us solving your issue. Please provide the exact commands run, the environment, the output and error messages. Providing us with the actual error messages is extremely useful. It allows us to easily copy and paste it while researching your issue.
The better you describe the problem the less we have to guess and ask.
Oftentimes seeing the error message is enough to provide a useful answer. In almost every case, you will need to make sure the problem is reproducible and provide us with a way to reproduce.
For complex issues, please create an example that we can copy, paste and run which demonstrates the problem. It’s too time-consuming for our team to try and debug your issue based on incomplete information. Please also see below.
If you are running a calculation which crashes after a week, you will need to reduce the example running time. Your goal should be to get the example as small as possible while still demonstrating the issue.
It will be easier for us to debug an issue that crashes within a few seconds than one which has a log time measured in minutes or hours. Yes, this requires some effort on your part but it will pay off with a support request that we can answer quickly and effectively.