Asking good questions for GIS Stack Exchange

Question

I often see vaguely framed questions posted, and I would like to help their askers, but I cannot, because their questions are missing key information.

Instead of having a long discussion in the comments, I would like to point them to some resource or checklist, which will help them form a good question.

Given that our Help Center uses this Q&A as the canonical question for this topic, What concise advice would you give on how to ask a good question?

Do keep in mind that this advice should be specific to GIS SE i.e. we do not want to simply link to the multipage How To Ask Questions The Smart Way by Eric Raymond, or 'What have you tried?'

Answer 1

A Question is composed of three distinct parts:

• body
• title
• tags

Body

By far the most important is the body of your question because this is where you pose the all important single question that you would like answered. It is the quality of your question body that engages or loses the attention of potential answerers.

You are provided with plenty of space and formatting tools here to assist you to present any technical background that potential answerers may need to understand your question. Questions and their titles must be written in English.

Start by mentioning the single GIS software (and version) that you are using and wish to ask about, or explain that you are asking about a GIS principle or algorithm instead. This saves potential answerers having to try and guess, or to ask, all of which may slow down or prevent an answer to your question.

The question body may well be the only part that potential answerers read and re-read after glancing at the title, so be sure to read and re-read it yourself, and to make ongoing edits to improve it as clarifications are sought by others via comments. You cannot assume that a potential answerer has read any of your previous questions, answers or comments so be sure to include all relevant details in the body so that it can standalone.

Once written, a good cross-check on your question's body is whether it contains a single question mark ("?"). If that is the case, then what you are asking is clearly indicated. If you find yourself wanting to place more than one question mark in the body, then questions other than the most important one to you can always be researched/asked separately.

A question that ends with "Any ideas?" or one that asks for examples to be provided (i.e. to make a list) suggests that what you are asking may lack focus. One that asks for step-by-step instructions lacks focus because we do not offer a tutorial writing service. Try always to ask a specific question.

If you are asking a coding question I strongly recommend reviewing How to create a Minimal, Reproducible Example so that what you include is just a code snippet that works up until where you are stuck. GIS Stack Exchange does not offer a code debugging/writing/reviewing service but we are generally happy to try to help you debug your code snippets.

If you have not already taken this site's 2-minute Tour then be aware that it says:

This site is all about getting answers. It's not a discussion forum. There's no chit-chat.

By "no chit-chat" we mean that words and phrases that are superfluous to the actual question being asked (or answers to it) like "Hi", "Greetings all", "Thanks", "Please", "Much appreciated", "Tearing my hair out", "Hope that helps", "Cheers", etc should not be included to try and connect socially with, or convey a sense of urgency to, potential answerers.

The quality of your question should be all that is needed to entice one of our many volunteers to answer it, and chit-chat (no matter how polite) will usually be removed. If you find yourself writing something that you might see in a personal communication but would not expect to see on a Wikipedia page, then you may be starting to bloat our focused Q&A with chit-chat.

Title

The title is best written after the body of the question because it is there to summarise what is in the body. As a result it should not introduce any new terms or information not covered in the body. By making this as succinct and accurately descriptive of the body as possible you are likely to attract more potential answers than if you hastily pen something like "Help! GIS not working!!???".

Tags

These help the people who are willing to try and help you quickly find the subset of questions in which they have skills instead of having to open many in which they do not.

I prefer that there is always at least one tag used for the main GIS product that you are using. This still gives you scope to apply 4 more tags that reflect the significant keywords that are likely to help group your question with others that are somewhat similar.

Do not worry if you get tags "wrong" - they are always quick and easy to fix as incoming questions are triaged as long as the information is in your question body.

What about Comments?

Comments are attached to, but do not form part of, your Question.

Their main purpose is to help you edit to improve your Question by requesting clarifications wherever potential answerers are unsure of what you are doing, using or asking.

Imagine the pleasure of a potential answerer reading just your Question body and thinking immediately "I know the answer to that", and answering it, versus reading a trail of back and forth comments between asker and commenters and thinking "does it mean this" or "does it mean that", and eventually "now I understand" or maybe not, or not bothering to read the comments and just moving on to the next Question.

What about Answers?

Answers should never be written in questions. We have a separate area for answers, and self-answering in that area is encouraged.

Answer 2

Before anything else, the number one priority of your question should be that it is understandable to the reader. It should convey all the required information to the reader. Don't just leave vague information, and don't assume that the reader will know about your situation and problem. The Way I think about it, is that if someone comes across the question in the wild, it should contain all the information and context to understand what you are asking. As Jon Skeet wrote:

The Golden Rule: Imagine You're Trying To Answer The Question

Once you've finished writing your question, read it through. Imagine you were coming to it fresh, with no context other than what's on the screen. Does it make sense? Is it clear what's being asked? Is it easy to read and understand? Are there any obvious areas you'd need to ask about before providing an answer? You can usually do this pretty well however stuck you are on the actual question. Just apply common sense. If there's anything wrong with the question when you're reading it, obviously that will be a problem for whoever's actually trying to answer it. So fix the problems. Improve the question until you can read it and think, "If I only knew the answer to the question, it would be a pleasure to provide that answer." At that point, post and wait for the answers to come rolling in.

Make sure that you left nothing to chance. Don't say it does not work. Tell us what went wrong. Tell us the error message if any.

Then tell us what you have tried. There is a greater chance of your question being answered if you show that you have done some research. The results of your trials will help us in narrowing down the problem.

Answer 3

The way I like to think of it is to just put yourself in the shoes of someone trying to answer your question. What information would someone need to even begin to have a chance of answering your question? That is what is so often missing.

For example, we often get questions about some kind of data manipulation. We need to know about the data. What is it, where did it come from, what is its purpose, and how was it designed? And then there is the obvious but so often overlooked, what software (including version numbers) are you using or able to use to accomplish this task?

Heck, even try answering your own question yourself. I would say more than half the time when I start writing a question here, the process of formulating the question leads itself to the answer on its own.

Answer 4

An item of highly recommended viewing that may help to answer this Question is a one hour Google+ Hangout video for Agile India entitled Good Stack Overflow Citizen by Jeff Atwood where he talks mostly about what makes a great Question.

A quick list by Agile India of Jeff's points, which go beyond just what makes a great Question, and apply to Stack Exchange sites other than just Stack Overflow, is:

• Rubber Ducking
• Noble Effort (do your own research)
• Describe a tweet size goal (why are you doing this?)
• Minimum Reproducible Code
• Don't write the title until you finish asking the question
• Review your question
  • Write like you talk (talk it out loud in your mind)
  • Ask questions as if you were asking yourself
  • Don't assume the context (links, documentation, research)
  • Provide sample data
• Participate in the research to find the answer
• Gardening your question
• Revise the question to clarify
• Most important feature is Edit button
• Join the community
• Voting and Accepting Answers is important

Answer 5

Jon Skeet has posted an excellent checklist on the main meta site, which is worth reading. Let me quote the relevant points from the checklist here:

• Have you done some research before asking the question?
• Have you explained what you've already tried to solve your problem?
• Have you specified which language and platform you're using, including version number where relevant?
• If your question includes code, have you written it as a short but complete program?
• If your question includes code, have you checked that it's correctly formatted?
• If your code doesn't compile, have you included the exact compiler error?
• If your question doesn't include code, are you sure it shouldn't?
• If your program throws an exception, have you included the exception, with both the message and the stack trace?
• If your program produces different results to what you expected, have you stated what you expected, why you expected it, and the actual results?
• Have you checked that your question looks reasonable in terms of formatting?
• Have you checked the spelling and grammar to the best of your ability?
• Have you read the whole question to yourself carefully, to make sure it makes sense and contains enough information for someone coming to it without any of the context that you already know?

If you use this checklist while forming your question, it will definitely get a good response.