Now that most of the hoopla over the new Forums replacement has died down, it seemed like a good idea to blog about what I've found has been necessary to get a useful response to a question. In my experience, and this has been confirmed with members of the MVP crowd, some folks like to answer "interesting questions" for the sheer joy of solving problems. Difficult questions don't phase us, but incomplete ones do.
Therefore, a well-written question SHOULD include:
- The software packages you're using
This includes the exact operating system(s) in use on the various components of the implementation (if it's complex, then a diagram would not be inappropriate), and the exact release, service pack and any patches which have been applied to Esri software (e.g., "Desktop 10.1 SP1 with Quality Improvement Patch"), and a complete description of any supporting software such as Oracle, SQL-Server, PostreSQL, DB2,... (a complete description would be what the software provides in its "About" page or connection banner -- "Oracle 11g" is not enough, instead specify "Oracle 11.2.0.3.0 (64-bit)").
- A general description of your computing environment, data, and goal
This should include a distinction between desktop and server operation, the language(s), extensions and tools available to solve the problem, the format(s) of the available dataset(s) (e.g., "shapefiles and file geodatabase" or "Oracle enterprise geodatabase using SDE.ST_GEOMETRY storage"), and a description of what you're trying to accomplish (in a "big picture" context -- the what, not the how).
- Exactly what you were doing when you encountered the problem
If an ArcPy processing job was running, copy the exact command and all its output. Programming questions should always include a representative code block of the commands necessary to produce the behavior (but don't just paste in your code in the hope that someone will debug it for you).
While screenshots can help explain what was going on, please be sure to include the full error message text in the question as text. This allows the search engine to index the terms and allow others to find your question (and answer). If no explicit error is present, then recent contents of relevant log files would be appropriate.
- Some indication that you've tried to solve the issue on your own
Searching the web on the error message text is often the first step to solving a problem. If you don't do this "due diligence" minimum for yourself, then you might find that others are unwilling to do more for you.
- A judicious complement of keyword tags
Tags are not exactly new, since the vBulletin-based Forums permitted them, but now that they're used extensively by the Jive-based GeoNet, it is good to browse the existing tag lists to find some keys that apply to your situation. Software products, languages, tool names, and development frameworks are all ways that domain experts can filter out your question from the volume of daily postings. If you have to create a new tag, it's unlikely that anyone is already looking for it.
Obviously, not all questions will require all these properties, but most will, so if you use this checklist, you'll be well on your way to an answer.
While I'm on the topic, I should also mention that a well-crafted question should NOT include:
- Any assertion of importance or urgency
If it wasn't important, its unlikely you would have posted it, and "urgent" is often translated to "uninterested in working with others," reducing the attractiveness of a question -- You can't force folks to answer your question outside their available timeline, but you can convince them to not bother at all.
- Gratuitous use of UPPERCASE and bold text
Rants, while they may have some cathartic value, are often counterproductive in a problem-solving context. I know I'm unlikely to assist someone in the middle of a full-on hissy fit -- I've already gotten scratched trying to break up a cat fight, and I'm not likely to do so again.
- Anything you wouldn't want posted on your office door (or slipped into your supervisor's inbox)
Please remember that GeoNet, like all social media, is public information, so IP addresses, usernames, passwords, licensing documents, complaints about people and processes, etc should not be posted with any expectation of privacy.
It would also be useful to remember that not all of the people reading your question are being paid to do so. Even if they were, it would still be useful to be courteous (though not overly effusive) and to maintain a professional demeanor. Those with the power to moderate GeoNet content are not eager to do so, but will do so when necessary.
Speaking on behalf of those who look for questions to answer, I say: Please help us to help you by framing answer-ready questions with complete problem statements. The extra time it takes to provide necessary information when first posting the question will be paid back in faster, less speculative answers.
- V
