I’m new to the UNIX & Linux site and I would like to ask a question. There is some guidance in the Help Center, but what are other actions I can take to make my question well-received and improve my chances of getting answers?
Welcome to our site! Interesting questions and answers about UNIX & Linux are what this site is all about.
Let’s get some basics out of the way; skip ahead if you’ve already covered these.
- Register an account - New users sometimes skip past the sign-up page and post as a guest. If you register your account, you’ll have an easier time editing your own post with updates and clarifications, commenting on your question, and commenting on Answers to your question.
- Take our tour - Take a minute and read through our tour page. It’s a quick introduction to the site (and to Stack Exchange) and it earns you a badge! If you’ve been to other Stack Exchange sites already, it will look familiar. Pay particular attention to the section that’s unique to UNIX & Linux, the "Ask about…" and "Don’t ask about" section.
Browse the help pages - Right at the end of the tour, there’s a link to our Help Center; there’s a lot to read there, so poke around the links that you find interesting. Since you’re interested in asking a good question, pay particular attention to these:
Next, see if your question already has an answer. You might have searched this site directly or via a search engine, so skip ahead if you feel confident that you have a unique problem. There are over 100,000 questions on the site, though, so it doesn’t hurt to double-check!
Write down the main verbs and nouns from your problem in the Ask a Question title box. You have no intention of submitting this as your question, yet. As you start typing, a list of Questions that may already have your answer will appear directly below the title field. Let the search engine automatically show you questions that it thinks are similar. Open any of them separately to see if they pertain to your situation. Take note of any questions that look as if they would solve your problem, but do not, for one reason or another; you might refer back to them in your question and explain why they do not solve your problem. This will prevent well-meaning reviewers from finding them and proposing your question as a duplicate of those.
If very few search results came back, look back at the on-topic page to confirm that your problem fits the on-topic list. If your question is not on-topic for the site, it may be closed for being “off-topic”. On the other hand, you may have a unique situation or combination of technology that hasn’t been asked about yet.
Before we continue, let’s avoid three very common pitfalls that result in questions being closed:
- opinion-based, or
- too broad, or
Are you asking for people’s experiences with a certain piece of hardware or software? Are you wondering if something will work? Are you looking for guidance, or for opinions on how to proceed? If so, stop and re-think your approach. Questions should have concrete answers; instead of the “best” way to do something, are you actually concerned about limiting memory use, or network traffic? Do you need something that’s cross-platform?
Are you asking for an architectural-level solution? Something a consultant might be paid to spend several weeks on? You should have made some attempt at solving your problem; share those commands and any specific error messages or confusion before asking a question; otherwise, your question risks being closed as “too broad”.
Lastly, take a step back from your problem and ask yourself: “What would an answer look like?” Your question should give enough guidance about what’s specifically needed and what’s specifically excluded so that you don’t have to constantly guide answerers towards the solution that you actually need. Think of your question as if you had to explain it to an intelligent friend; even if they didn’t know what “grep” was, could they understand what you were trying to accomplish? If potential answerers (or reviewers) can’t figure out what you mean, and you don’t step in to clarify, your question risks being closed as “unclear what you’re asking”. If you have textual input, don’t provide it in a graphic! That’s a pitfall that’s become common enough to warrant its own PSA.
Yet another way trap to avoid is to ask what’s known as an “XY problem”. Keep your eyes on the goal; mention the things you tried and the errors you received, but be flexible if your approach isn’t the one that others take.
If you’re not sure what an objective, specific, and clear question might look like, you could do worse than to browse the top-voted questions or top-viewed questions. Many of those “top” questions rose there because of their canonical nature, and so generated many views and votes; they may very well be broader in scope than your question. To get a more targeted list of questions, head over to the tags page and enter some key words from your question, one at a time. When you find a matching tag, click on it to get a list of questions with that tag, then sort the questions by “Frequent” or by “Votes” to see what well-received questions in that tag look like.
Now let’s begin formulating your question. Go to (or stay at) the tags page and take the major nouns from your question and find at least one, but no more than five, tags that relate to your question. Tags are one of the two elements of your question that active users of the site will see first when looking for questions that they want to answer, so choose the ones that appear most pertinent to your question.
Now write a first draft of your question, either directly in the Ask a Question form or in your favorite editor. Set up each of three sections:
The title: create a sentence from your nouns & verbs that indicate the pertinent software, operating environment, goal, and any errors. You have a limit of 150 characters; this translates to approximately 20-25 average English words.
The body: start with an outline of: a re-worded summary of your goal and operating environment; representative (sample) input and output; any commands that you tried in pursuit of your goal and their output/results.
The tags: from the previous step
Now take another look at the body, particularly at the first 200 characters. This can be a third preview of your question beyond the title and tags, depending on the particular “view” a person takes while browsing the site. Rewrite the introduction to put as much of a “hook” as you can into the first 200 characters. This should describe the problem and the surprising result you got instead of the expected result. Think of a person who’s knowledgeable in this area; how would get them engaged with your problem in one or two sentences?
Be thorough and pertinent in the body of your question; explain what you think you know, up to the edge of where you were surprised or stumped. Be as clear as you can in describing any translation between input and output. If possible, demonstrate how people can set up similar environments for them to test their potential solutions. Show the research that you’ve already done. As you already saw in How do I ask a good question?, tell us what you’ve already found and why it didn’t meet your needs. Another method that was experimented with on Stack Overflow is a question template, so if the following questions help you to frame yours, use them!
- What are you trying to accomplish?
- What is some sample input, if applicable.
- What would be the desired output, based on that input?
- What happened instead? Include any errors, verbatim.
Take one more look at your question’s title and body. Have you presented the question as well as you can? Before posting the Question, particularly if English is not your strong suit, run a spell checker on the title and body. Many browsers will underline words that they think are misspelled. Capitalize proper nouns such as “I” and “Linux”. Feel free to ask for help in the Unix & Linux chat room or even with a post on English Language Learners. Make sure you have an actual question in your Question! It would end with a question mark and should act as the entry point for any answers.
Now – finally – post your question!
But you’re not done! Stay tuned to the site after posting for as long as you can, in case there are immediate requests for clarification. The active users of the site may read your question and enter comments requesting clarification. If they do ask for clarification, respond by editing your question using the “edit” link towards the bottom of your question – assuming you registered your account – DO NOT clarify your question in the comments! Comments do not support all the formatting options, may be deleted or collapsed together, all of which make it harder than it needs to be to piece together the correct question.
Finally, while you’re waiting, it’d be a good time to read What should I do when someone answers my question?. The main point is to up-vote (if you’ve earned that privilege, at 15 reputation points) and/or accept Answers that solve your problem. Do not feel any pressure to accept an answer immediately; it’s fine to do so, but it’s also OK to leave a question out there for a couple days to see if anyone else has other ideas or approaches to your problem.
how can I improve my questions to get more answers
use interrogatories ( interrogation techniques ), who, when, where, why and what have you tried
Views are due to the subject, but the body is what causes down votes usually because it doesn't contain enough information, vague questions are not well understood.
one dumb user less experienced user to another:
- Make your question novel:
- most of the people on this site are wizards and they get bored by questions they've seen 10s or 100s or 1000s of times before.
- Make your question hard:
- Ensure that you've googled and binged and tried and failed and only then ask a question and tell everyone what you've tried already (keep all the links to the other questions here on the site you've tried in a list and post them together with your question)
- make the question generic and specific:
man commandbefore you ask.
- If you can read source code and it's FLOSS: read the source code first
- And for crying out loud: Don't ask Windows questions here!
To write a good, welcomed question, I would advise:
- keeping it on-topic to the main subject of our stack/group;
- not addressing several subjects at once, in a single question;
- researching the facts behorehand;
- making an honest effort to understand and solve the question at hand, before asking it;
- being brief but comprehensive;
- keeping on topic to the question at hand:
Avoid digressing into loosely related background/questions/context.
- bringing it in a professional tone as best as you can achieve;
- not talking about things in vague terms:
Add palpable facts and debbuging data to your questions.
- making an effort to write it in good quality English;
- employing in generous quantities much needed paragraphs;
- using an automated spelling checker.
The main problems in not so well received questions, is mainly a lack of investiment in time above anything else. Beware though, that a good answer normally takes much more time to write than a question.
It also does not hurt to lurk for a bit while in our main site, to understand how regulars address questions and answers.
Consider creating a permanent user id to:
- gain reputation;
- comment freely on questions/answers;
- be part of the regular users of this community.