This article will teach you how to ask a good support question. After all, if you want good support (and of course you do) then you really need to start with a good question. Good questions lead to good answers. Good questions help us help you.
Let’s be frank about this. Asking a good support question is actually a difficult thing for some people to do. The folks who really need support are often the least-knowledgeable, which already places them at a pretty solid disadvantage.
Really, it’s hard to ask good questions. In fact, the possible scope of things that would need to be covered in an article of this nature is so large that I’m really only going to be able to give you some general guidelines. I’ll do what I can to help, and remember that various sites may have different conventions, so you’ll have to take from this what you can.
This article is pretty long because it is not easy to ask a good support question. It’s okay, to be new at it. It’s okay to not know everything. But, if you want support, you’ll have to learn how to ask for it. Also, if you’ve been directed to this page, it just means that you could can use some pointers to help us help you.
With all that said and done… Let’s learn how to ask a good support question!
It should be noted that this article is written in a fairly generic manner. After all, I want to make sure it’s useful to as many people as possible. Because of this, I add: When in doubt, follow the local conventions. The support site you’re using may have their own definitions of normal and good. So, as they say, “When in Rome, do as the Romans did.”
Your headline should actually be a short description. Generic headlines don’t help and won’t attract people to your question. A good headline will inform and be accurate. A good headline will make people want to open the thread and read your question. A bad headline lessens interest and interaction.
Bad: “My computer doesn’t work.”
Good: “After my last update, my computer stops booting after the GRUB screen with a blinking cursor and a black screen.”
Put some effort into crafting your headline. Don’t make it click-bait; make it an accurate summary of the problem. Make it a simple, well-thought-out description of your problem and brief enough to fit as a headline.
But, before you even begin asking questions…
Before you post your question, search! Search, search, search! It’s your computer and your problem, you should be the one doing the most research. On top of that, many questions already have an answer. Every support site out there has a search function. Use it!
Don’t just use the forum’s search – use your favorite search engine. Don’t just do a quick search, keep searching. Make it past the first five or ten search results, and don’t expect your answer to be on the first link you clicked. You might have to do multiple searches, digging deeper into the problem. Not all problems are easily resolved.
Searching can be hard – especially if you don’t know the jargon or lack the information to know the correct keywords. So, find as much information as you can about your problem and use any error logs you can find. Even if your searching doesn’t give you the answer – it might give you enough information to help us help you.
Hint: If you start an application from the terminal, you might learn something from the text it outputs to the terminal.
Hint: If you want a nice GUI way to read your logs, I highly recommend using ksystemlog. It pulls in just a few dependencies and is a very handy tool to have in your toolbox.
Again, search and then search some more. If nothing else, you’ll have more information, which you can help us to help you. You’ll also learn things along the way. What’s not to love?
While you’re searching, make sure you also search the support site to make sure you put your question in the right sub-forum. The “General” category is not a catch-all, it’s where you put your question when there’s no better category. If your question is about the terminal, put it in the command line sub-forum. If your question is specific to Ubuntu, make sure you put it in the “Debian and derivatives” section, or the “Ubuntu” section if they have it. Use commonsense and put your question in the most appropriate section.
If you want help, once again, you have to help us help you. This article is written for more than one site in mind, so I need to be generic. The support forum you choose to use has formatting features – use them! Make use of the formatting to better explain your problem and to better identify the information you’re sharing.
Unless otherwise specified, the language is English. It’s not that we’re trying to be jerks, it’s that we don’t speak your language. Use the DeepL translator (or Google Translate if needed) and post your question in English (when you’re on English-speaking sites). More generic, use the language the forum uses. The translation onus is on you, and not on them.
Use code tags. Every single Linux support forum that I know of has the ability to wrap things in code tags. It will look a little like this:
[code]sudo apt update && sudo apt upgrade -y[/code]
Using the code tags where appropriate will properly format the code and make it legible to those who wish to help you. It makes it easier for us to actually see what’s going on. It gives clear line breaks, makes the text distinct, and helps us spot problems.
Use paragraphs. Giant walls of text aren’t easy to read, nor are they fun to decipher. This is especially true when they’re interspersed with multiple problems and poorly formatted code snippets. Without paragraphs, you might as well be writing gibberish.
For the love of all that’s holy, stop taking screenshots of text! It’s text. Post it as text! When you post your output as text, we can highlight the important bits and search for them. We can edit it and send it back to you. We may know what bit of that text is important and not having to type it out based on a picture is much more efficient.
So, if it is at all possible, do not post text as images. It’s a pain in the butt to get the text during a boot error, so there are obvious exceptions when it’s approached by a reasonable person. But, seriously, try to avoid it. Some of us completely ignore questions that are hard to read or questions that use graphics when text is more appropriate.
There’s almost no such thing as too much information. I mean, sure, you could possibly give us more information than we need, but that’s infinitely better than not enough information.
We not only need to know what distro you’re using, we also need to know what version you’re using. Then, we may also need to know what desktop environment you’re using. We need to know what major changes you’ve made to your system. In some cases, where appropriate, we will also need to know what software version it is you’re talking about. For all but the most basic of questions, we may need to know quite a bit of information.
Believe it or not, we don’t actually know every piece of software that has been written over the years. When necessary, you should provide a link to the software’s home page – so that we can learn about it and help you with it. We’ll maybe even need to know how you installed it, as there are often multiple routes to installation.
If it’s a hardware connection, telling us the model number of your computer isn’t actually enough information. Different models have entirely different configurations while keeping the same model number. We’ll need to know things like what CPU you have, what your GPU model number is, what you have for a sound card, what type of connection to the internet you have, how much RAM you have, and possibly more. A great tool for gathering that information is inxi. We use that tool often on my favorite support site, Linux.org.
Sometimes, it’s the expected behavior. Yes, your computer will slow down when you have a bunch of browser tabs open and leave them open for days. Yes, your computer will still boot slowly if it’s old and you’re using an OS with a heavy desktop environment while you have everything opening at boot. No, it’s not supposed to show asterisks (some distros do) when you type your password into the terminal.
Unless you’re paying for support, we’re all volunteers. We owe you nothing. Don’t treat us like paid support and don’t expect us to do the work for you. You’re expected to participate in us helping you. When we ask for follow-up information, provide it in a timely manner. Don’t ask for help unless you have time to follow-up and respond to requests for additional information. Civility and gratitude go a long ways.
TIP: Limit your questions to one at a time, unless you’re absolutely certain that they’re related. We volunteers tend to specialize in a few areas, so mixing a bunch of questions into one post is just confusing and may lead to your problems remaining unresolved.
Pick a forum, one support site, and ask your question there. Chances are good that we’re members of the other forums, so you’re going to get a lot of the same people helping you. Don’t ask the same question at multiple sites, ask at one site – which also makes it easier for the person who’s searching for the same question in the future. Asking at multiple sites is asking folks to duplicate work. It’s just lazy, uninspired, and rude to do so.
This is just a general guide. As I told you at the start, asking a good support question isn’t easy. On top of it all, different forums will have different conventions. So, you should probably lurk at a forum before just jumping in. It’s probably a good idea to pick a forum at the same time you pick a distro. That way, they know who you are when you’re asking for their help and you’re already a member of the community before you’re asking for help.
Remember, if your post was resolved, mention it and thank the person that helped you solve it. If you resolve the post on your own, add a comment to let folks know you found the solution – and what the solution was. On the sites that allow it, be sure to edit your title to let folks know the problem has been solved. For example, you can add [Solved] to your original headline and let forum helpers (and people looking for solutions) know that the thread contains a solution.
And there it is… I have updated and moved the article that’s meant to help people ask a good support question. Quite a lot of the article has changed, including formatting. In the next day or two, the old link will have a 301 redirect to this link. So, if you’re linking to the older version of this article, it will automatically shunt people over here to view this article about how to ask a good support question.
I’d like to think that this is a ‘living document’. As such, it will change in time. If you can think of worthy additions, please leave a comment below. If this has helped you, please feel free to let us know (in a comment) which section of the article was most helpful to you. Most importantly, I want it to serve as a link folks can use when they want to help folks ask a good support question. The older version of this article was quite beneficial in that way. I hope this one follows suit.
Thanks for reading! If you want to help, or if the site has helped you, you can donate, register to help, write an article, or buy inexpensive hosting to start your own site. If you scroll down, you can sign up for the newsletter, vote for the article, and comment.
Updated:
02/12/2022 (added the [Solved] and Google translate.)
07/07/2022 (fixed a spelling error that has been there the whole time.)
Today we'll cover one way to enable or disable your network interface in the Linux…
Today's exercise is a nice and simple exercise where we check your NIC speed in…
Have you ever wanted to easily monitor your wireless connection? Well, now you can learn…
I think I've covered this before with the ls command but this time we'll count…
Today we'll be learning about a basic Linux command that's known as 'uname' and it…
If you've used hardinfo in the past, it may interest you to know that hardinfo…
View Comments
EXCELLENT I hope it gets regular readers [it will make our lives a bit simpler
i agree! If you pressed the right buttons, you'll be subscribed to *all* the comments (on this particular article).
Good information! I'll try to use this for my own questions.
This is the best version of this answer that I have ever read.