|
|
admin wrote: |
---|
When You Ask Choose your forum carefully Be sensitive in choosing where you ask your question. You are likely to be ignored if you: •post your question to a forum where it's off topic •post a very elementary question to a forum where advanced technical questions are expected, or vice-versa Use meaningful, specific subject headers The subject header is your golden opportunity to attract qualified experts' attention. Don't waste it on babble like 'Please help me' Don't try to impress us with the depth of your anguish; use the space for a super-concise problem description instead. More generally, imagine looking at the index of an archive of questions, with just the subject lines showing. Make your subject line reflect your question well enough that the next guy searching the archive with a question similar to yours will be able to follow the thread to an answer rather than posting the question again. Write in clear, grammatical, correctly-spelled language Expressing your question clearly and well is important. Spend the extra effort to polish your language. It doesn't have to be stiff or formal. But it has to be precise. Don't TYPE IN ALL CAPS; this is read as shouting and considered rude. If you write like a semi-literate boob you will very likely be ignored. So don't use instant-messaging shortcuts. Be precise and informative about your problem •Describe the symptoms of your problem carefully and clearly. •Describe the environment in which it occurs (machine, OS, application, whatever). •Describe the research you did to try and understand the problem before you asked the question. •Describe the diagnostic steps you took to try and pin down the problem yourself before you asked the question. Do the best you can to anticipate the questions a respondent will ask, and answer them in advance in your request for help. Volume is not precision You need to be precise and informative. This end is not served by simply dumping huge volumes of code or data into a help request. If you have a large, complicated test case that is breaking a program, try to trim it and make it as small as possible. This is useful for at least three reasons. One: being seen to invest effort in simplifying the question makes it more likely you'll get an answer, Two: simplifying the question makes it more likely you'll get a useful answer. Three: In the process of refining your bug report, you may develop a fix or workaround yourself. Describe the problem's symptoms, not your guesses It's not useful to tell programmers what you think is causing your problem. So, make sure you're telling them the raw symptoms of what goes wrong, rather than your interpretations and theories. Let them do the interpretation and diagnosis. If you feel it's important to state your guess, clearly label it as such and describe why that answer isn't working for you. Describe the goal, not the step If you are trying to find out how to do something, begin by describing the goal. Only then describe the particular step towards it that you are blocked on. Often, people who need technical help have a high-level goal in mind and get stuck on what they think is one particular path towards the goal. They come for help with the step, but don't realize that the path is wrong. It can take substantial effort to get past this. Be explicit about your question Open-ended questions tend to be perceived as open-ended time sinks. Those people most likely to be able to give you a useful answer are also the busiest people (if only because they take on the most work themselves). People like that are allergic to open-ended time sinks, thus they tend to be allergic to open-ended questions. You are more likely to get a useful response if you are explicit about what you want respondents to do (provide pointers, send code,..). This will focus their effort and implicitly put an upper bound on the time and energy a respondent must allocate to helping you. 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. If you simply want a code review, say as much up front, and be sure to mention what areas you think might particularly need review and why. |
giblit wrote: |
---|
Still missing a question. You are just showing the assignment. What exactly is not working or what would you like help with? |