Ask Question in A SMART Way

Detailed suggestions can be found here

1. Before You Ask

Do your homework before you ask questions, and display you have done these things when you ask:

Try to find an answer by searching web, reading the manual, reading a FAQ, asking a skilled friend or even by reading the source code if you are a programmer.

Take your time. It probably won't be solved in a few seconds.

Prepare your question and be aware of asking the wrong question.

2. When You Ask

• Choose your forum carefully

Domestic (China) Segmentfault,

International Stack Overflow, for questions about programming,

Several projects have their own specific sites, including Android, Ubuntu, TeX/LaTeX, and SharePoint.

You can find more in StackExchange.

When selecting a Web forum, newsgroup or mailing list, don't trust the name by itself too far; look for a FAQ or charter to verify your question is on-topic. Read some of the back traffic before posting so you'll get a feel for how things are done there. In fact, it's a very good idea to do a keyword search for words relating to your problem on the newsgroup or mailing list archives before you post. It may find you an answer, and if not it will help you formulate a better question.

Still, search before posting questions. If can't find anything, post your question on the on-topic site.

• Use web or IRC forums first, then use project mailing lists

When a project has a development mailing list, write to the mailing list, not to individual developers.

• Specific subject headers

'object-deviation' for mailing list questions: The “object” part specifies what thing or group of things is having a problem, and the “deviation” part describes the deviation from expected behavior.

• Make it easy to reply

• Correctly spelled

if you are writing in English but it is a second language for you, it is good form to alert potential respondents to potential language difficulties and options for getting around them. Examples: English is not my native language; please excuse typing errors.

• Send plain text question, not in other formats

But Data should be included as-is, so respondents can have confidence that they are seeing what you saw.

• Be precise and informative about your problem

Describe the symptoms of your bug, the enviroment in which it occurs, your research and understanding, diagnostic steps you tried, possible relavant changes in your computer.

If at all possible, provide a way to reproduce the problem in a controlled environment.

Try to trim the question and make it as small as possible, volume is not precision.

• Describe your problem's symptoms in chronological order

If your account ends up being long (more than about four paragraphs), it might be useful to succinctly state the problem up top, then follow with the chronological tale.

• When asking about code

Don't ask others to debug your broken code without giving a hint what sort of problem they should be searching for. Posting a few hundred lines of code, saying "it doesn't work", will get you ignored. Posting a dozen lines of code, saying "after line 7 I was expecting to see <x>, but <y> occurred instead" is much more likely to get you a response.

• Follow up with a brief note on the solution

3. How To Interpret Answers

RTFM: Read the F**king Manual; STFW: Search the F**king Web

Exhibit what you have learned when asking for more clarifications.

4. If You Can't Get An Answer

Have patience.

Pay for support.