最近怎么都是提问回答的帖子?

03-08-29 robbin
满眼一看,全都是提问请求别人回答的帖子,绝大多数帖子连问题都不描述清楚,甚至是三言两语,或者明显是自己不细心,不花功夫去研究问题的原因,总是指望省心省力的靠别人来解答。感觉很失望,每一个人的时间都是宝贵的,解答问题也一样要花大量的时间,更何况还是无偿自愿的,我感觉这样的行为不是对别人尊重的态度。:(

zmeng
2003-08-29 23:55
robbin,我的问题可是试了一两天后才问你的,确实没辙了的

robbin
2003-08-30 01:01
你觉得我在针对你吗?不要误会了,你的程序我已经调试好了,发给你了。

windman
2003-08-30 09:47
呵呵,不如让banq把那篇《提问的智慧》想办法置顶或者放在论坛显著位置。

wys1978
2003-08-30 10:35
原文在这里

http://www.catb.org/~esr/faqs/smart-questions.html

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"><head><meta description='...and how not to ask stupid ones'><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>How To Ask Questions The Smart Way</title><meta name="generator" content="DocBook XSL Stylesheets V1.58.1" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><h2 class="title"><a id="index"></a>How To Ask Questions The Smart Way</h2></div><div><div class="author"><h3 class="author">Eric Steven Raymond</h3><div class="affiliation"><span class="orgname"><a href="http://www.catb.org/~esr/" target="_top">

Thyrsus Enterprises</a><br /></span><div class="address"><p><br />

    <tt><<a href="mailto:esr@thyrsus.com">esr@thyrsus.com</a>></tt><br />

    </p></div></div></div></div><div><div class="author"><h3 class="author">Rick Moen</h3><div class="affiliation"><div class="address"><p><br />

    <tt><<a href="mailto:rick@linuxmafia.com">rick@linuxmafia.com</a>></tt><br />

    </p></div></div></div></div><div><p class="copyright">Copyright © 2001 Eric S. Raymond</p></div><div><div class="revhistory"><table border="1" width="100%" summary="Revision history"><tr><th align="left" valign="top" colspan="3"><b>Revision History</b></th></tr><tr><td align="left">Revision 2.8</td><td align="left">8 Aug 2003</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

Minor corrections.

</td></tr><tr><td align="left">Revision 2.8</td><td align="left">21 July 2003</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

On the value of not grovelling. Describe the task, not the step.

</td></tr><tr><td align="left">Revision 2.7</td><td align="left">15 July 2003</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

On the value of not grovelling. Describe the task, not the step.

</td></tr><tr><td align="left">Revision 2.6</td><td align="left">29 January 2003</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

Found a way to bash the stylesheets into putting the version

history at the back.

</td></tr><tr><td align="left">Revision 2.5</td><td align="left">21 January 2003</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

New section on not claiming you've found a bug.

</td></tr><tr><td align="left">Revision 2.4</td><td align="left">17 October 2002</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

Good form for problem resolution replies.

</td></tr><tr><td align="left">Revision 2.3</td><td align="left">25 September 2002</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

German translation link added.

</td></tr><tr><td align="left">Revision 2.2</td><td align="left">22 September 2002</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

More on `Thanks in advance'.

</td></tr><tr><td align="left">Revision 2.1</td><td align="left">27 August 2002</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

More on how to choose fora appropriately. Revisions to intro.

</td></tr><tr><td align="left">Revision 2.0</td><td align="left">4 August 2002</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

First XML version. Suggestions from Evelyn Mitchell's

<a href="http://www.tummy.com/Presentations/Questions/" target="_top">

presentation</a>. Also took off from her material to

write "How To Give Good Answers". Added "Make it easy to reply".

</td></tr><tr><td align="left">Revision 1.19</td><td align="left">20 July 2002</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

Added the Bass-O-Matic question example and more

troubleshooting steps.

</td></tr><tr><td align="left">Revision 1.18</td><td align="left">11 July 2002</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

Change the subject on request email.

</td></tr><tr><td align="left">Revision 1.17</td><td align="left">21 April 2002</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

Still more about choosing an appropriate forum.

</td></tr><tr><td align="left">Revision 1.16</td><td align="left">15 March 2002</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

More about choosing an appropriate forum.

</td></tr><tr><td align="left">Revision 1.15</td><td align="left">11 March 2002</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

Don't flag your question "Urgent". Don't line-wrap data.

</td></tr><tr><td align="left">Revision 1.14</td><td align="left">4 February 2002</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

Added links to related resources.

</td></tr><tr><td align="left">Revision 1.13</td><td align="left">1 February 2002</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

Two new translations. Typo fixes.

</td></tr><tr><td align="left">Revision 1.12</td><td align="left">1 January 2002</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

Recommend object-deviation format for bug reports.

How to verify that your mail format is not bogus.

</td></tr><tr><td align="left">Revision 1.11</td><td align="left">17 October 2001</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

More about project mailing lists.

</td></tr><tr><td align="left">Revision 1.10</td><td align="left">5 October 2001</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

Using project mailing lists.

</td></tr><tr><td align="left">Revision 1.9</td><td align="left">2 October 2001</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

MIME attachments are OK. How to turn off HTML. Homework questions.

</td></tr><tr><td align="left">Revision 1.8</td><td align="left">28 September 2001</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

On being specific about your question.

</td></tr><tr><td align="left">Revision 1.7</td><td align="left">21 September 2001</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

A few tips on email etiquette. Noted objections to "Thanks

in advance."

</td></tr><tr><td align="left">Revision 1.6</td><td align="left">14 September 2001</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

More on how to deal with not getting an answer.

</td></tr><tr><td align="left">Revision 1.5</td><td align="left">13 September 2001</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

Added "Volume Is Not Precision" and "Dealing with Rudeness".

</td></tr><tr><td align="left">Revision 1.4</td><td align="left">11 September 2001</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

Minor editorial changes.

</td></tr><tr><td align="left">Revision 1.3</td><td align="left">10 September 2001</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

Added comments on what to do if you don't like the hacker

attitude. Added another archetypal stupid question.

</td></tr><tr><td align="left">Revision 1.2</td><td align="left">9 September 2001</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

Contributions by Richard Gooch.

</td></tr><tr><td align="left">Revision 1.1</td><td align="left">9 September 2001</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

Contributions by William Stearns.

</td></tr><tr><td align="left">Revision 1.0</td><td align="left">6 September 2001</td><td align="left">esr</td></tr><tr><td align="left" colspan="3">

Initial version.

</td></tr></table></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><a href="#translations">Translations</a></dt><dt><a href="#disclaimer">Disclaimer</a></dt><dt><a href="#intro">Introduction</a></dt><dt><a href="#before">Before You Ask</a></dt><dt><a href="#asking">When You Ask</a></dt><dd><dl><dt><a href="#forum">Choose your forum carefully</a></dt><dt><a href="#uselists">Whenever possible, use project mailing lists</a></dt><dt><a href="#bespecific">Use meaningful, specific subject headers</a></dt><dt><a href="#easyreply">Make it easy to reply</a></dt><dt><a href="#writewell">Write in clear, grammatical, correctly-spelled language</a></dt><dt><a href="#formats">Send questions in formats that are easy to understand</a></dt><dt><a href="#beprecise">Be precise and informative about your problem</a></dt><dt><a href="#volume">Volume is not precision</a></dt><dt><a href="#id2790354">Don't claim that you have found a bug</a></dt><dt><a href="#id2790546">Grovelling is not a substitute for doing your homework</a></dt><dt><a href="#symptoms">Describe the problem's symptoms, not your guesses</a></dt><dt><a href="#chronology">Describe your problem's symptoms in chronological order</a></dt><dt><a href="#goal">Describe the goal, not the step</a></dt><dt><a href="#noprivate">Don't ask people to reply by private email</a></dt><dt><a href="#explicit">Be explicit about the question you have</a></dt><dt><a href="#homework">Don't post homework questions</a></dt><dt><a href="#prune">Prune pointless queries</a></dt><dt><a href="#urgent">Don't flag your question as "Urgent", even if it is for you</a></dt><dt><a href="#courtesy">Courtesy never hurts, and sometimes helps</a></dt><dt><a href="#followup">Follow up with a brief note on the solution</a></dt></dl></dd><dt><a href="#answers">How To Interpret Answers</a></dt><dd><dl><dt><a href="#rtfm">RTFM and STFW: How To Tell You've Seriously Screwed Up</a></dt><dt><a href="#lesser">If you don't understand...</a></dt><dt><a href="#keepcool">Dealing with rudeness</a></dt></dl></dd><dt><a href="#not_losing">On Not Reacting Like A Loser</a></dt><dt><a href="#classic">Questions Not To Ask</a></dt><dt><a href="#examples">Good and Bad Questions</a></dt><dt><a href="#id2854531">If You Can't Get An Answer</a></dt><dt><a href="#id2854600">How To Answer Questions in a Helpful Way</a></dt><dt><a href="#id2854696">Related Resources</a></dt><dt><a href="#id2854732">Special note for FAQ list maintainers and webmasters</a></dt><dt><a href="#id2854756">Acknowledgements</a></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><h2 class="title" style="clear: both"><a id="translations"></a>Translations</h2></div></div><p>Translations:

<a href="http://www.usenet.dk/netikette/udvdebatteknik.html" target="_top">Danish</a>

<a href="http://linux.ee/~kala/smart-questions.html" target="_top">Estonian</a>

<a href="http://www.gnurou.org/documents/smart-questions-fr.html" target="_top">French</a>

<a href="http://www.lugbz.org/documents/smart-questions_de.html" target="_top">German</a>

<a href="http://www.penguin.org.il/essays/smart-questions-he.html" target="_top">Hebrew</a>

<a href="http://www.no.info.hu/~kryss/gnu/esr/smart-questions_hu.html" target="_top">Hungarian</a>

<a href="http://rtfm.bsdzine.org/" target="_top">Polish</a>

<a href="http://ln.com.ua/~openxs/articles/smart-questions-ru.html" target="_top">Russian</a>

<a href="http://www.sindominio.net/ayuda/preguntas-inteligentes.html" target="_top">Spanish</a>

.

If you want to copy, mirror, translate, or excerpt this document,

please see my <a href="http://www.catb.org/~esr/copying.html" target="_top">copying policy</a>.</p></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><h2 class="title" style="clear: both"><a id="disclaimer"></a>Disclaimer</h2></div></div><p>Many project websites link to this document in their sections on

how to get help. That's fine, it's the use we intended ― but if

you are a webmaster creating such a link for your project page, please

display prominently near the link notice that <span class="emphasis"><em>we are not a

help desk for your project!</em></span></p><p>We have learned the hard way that without such a notice, we will

repeatedly be pestered by idiots who think that our having published this

document makes it our job to solve all the world's technical

problems.</p><p>If you are reading this document because you need help, and you

walk away with the impression you can get it directly from the

authors, <span class="emphasis"><em>you</em></span> are one of the idiots in question.

Don't ask <span class="emphasis"><em>us</em></span> questions. We'll just ignore you.

We are here to show you how to get help from people who actually know

about the software or hardware you are dealing with, but 99% of the

time that will not be us. Unless you know for

<span class="emphasis"><em>certain</em></span> that one of the authors is an expert on

what you are dealing with, leave us alone and everybody will be

happier.</p></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><h2 class="title" style="clear: both"><a id="intro"></a>Introduction</h2></div></div><p>In the world of <a href="http://www.catb.org/~esr/faqs/hacker-howto.html" target="_top">hackers</a>, the kind of

answers you get to your technical questions depends as much on the way

you ask the questions as on the difficulty of developing the answer.

This guide will teach you how to ask questions in a way that is likely

to get you a satisfactory answer.</p><p>The first thing to understand is that hackers actually like hard

problems and good, thought-provoking questions about them. If we

didn't, we wouldn't be here. If you give us an interesting question

to chew on we'll be grateful to you; good questions are a stimulus and

a gift. Good questions help us develop our understanding, and often

reveal problems we might not have noticed or thought about otherwise.

Among hackers, "Good question!" is a strong and sincere compliment.</p><p>Despite this, hackers have a reputation for meeting simple

questions with what looks like hostility or arrogance. It sometimes

looks like we're reflexively rude to newbies and the ignorant. But

this isn't really true.</p><p>What we are, unapologetically, is hostile to people who seem to be

unwilling to think or to do their own homework before asking

questions. People like that are time sinks ― they take without

giving back, they waste time we could have spent on another question

more interesting and another person more worthy of an answer. We call

people like this "losers" (and for historical reasons we sometimes

spell it "lusers").</p><p>We realize that there are many people who just want to use the

software we write, and have no interest in learning technical

details. For most people, a computer is merely a tool, a means to an

end; they have more important things to do and lives to live. We

acknowledge that, and don't expect everyone to take an interest in the

technical matters that fascinate us. Nevertheless, our style of

answering questions is tuned for people who <span class="emphasis"><em>do</em></span>

take such an interest and are willing to be active participants in

problem-solving. That's not going to change. Nor should it; if it

did, we would become less effective at the things we do best.</p><p>We're (largely) volunteers. We take time out of busy lives to

answer questions, and at times we're overwhelmed with them. So we

filter ruthlessly. In particular, we throw away questions from people

who appear to be losers in order to spend our question-answering time

more efficiently, on winners.</p><p>If you find this attitude obnoxious, condescending, or arrogant,

check your assumptions. We're not asking you to genuflect to us

― in fact, most of us would love nothing more than to deal with

you as an equal and welcome you into our culture, if you put in the

effort required to make that possible. But it's simply not efficient

for us to try to help people who are not willing to help

themselves. It's OK to be ignorant; it's not OK to play stupid.</p><p>So, while it isn't necessary to already be technically competent

to get attention from us, it <span class="emphasis"><em>is</em></span> necessary to

demonstrate the kind of attitude that leads to competence ―

alert, thoughtful, observant, willing to be an active partner in

developing a solution. If you can't live with this sort of

discrimination, we suggest you pay somebody for a commercial support

contract instead of asking hackers to personally donate help to

you.</p><p>If you decide to come to us for help, you don't want to be one

of the losers. You don't want to seem like one, either. The best way

to get a rapid and responsive answer is to ask it like a person with

smarts, confidence, and clues who just happens to need help on one

particular problem.</p><p>(Improvements to this guide are welcome. You can mail

suggestions to <a href="mailto:esr@thyrsus.com" target="_top">esr@thyrsus.com</a>. Note however

that this document is not intended to be a general guide to <a href="http://www.dtcc.edu/cs/rfc1855.html" target="_top">netiquette</a>, and I

will generally reject suggestions that are not specifically related to

eliciting useful answers in a technical forum.)</p></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><h2 class="title" style="clear: both"><a id="before"></a>Before You Ask</h2></div></div><p>Before asking a technical question by email, or in a newsgroup, or on a

website chat board, do the following:</p><div class="procedure"><ol type="1"><li><p>Try to find an answer by searching the Web.</p></li><li><p>Try to find an answer by reading the manual.</p></li><li><p>Try to find an answer by reading a FAQ.</p></li><li><p>Try to find an answer by inspection or experimentation.</p></li><li><p>Try to find an answer by asking a skilled friend.</p></li><li><p>If you are a programmer, try to find an answer by reading

the source code.</p></li></ol></div><p>When you ask your question, display the fact that you have done

these things first; this will help establish that you're not being a

lazy sponge and wasting people's time. Better yet, display what you have

<span class="emphasis"><em>learned</em></span> from doing these things. We like answering

questions for people who have demonstrated that they can learn from

the answers.</p><p>Use tactics like doing a Google search on the text of whatever

error message you get (and search Google groups as well as web pages).

This might well take you straight to fix documentation or a mailing

list thread that will answer your question. Even if it doesn't,

saying "I googled on the following phrase but didn't get anything that

looked useful" is a good thing to be able to put in email or news

posting requesting help.</p><p>Prepare your question. Think it through. Hasty-sounding

questions get hasty answers, or none at all. The more you do to

demonstrate that you have put thought and effort into solving

your problem before asking for help, the more likely you are to

actually get help.</p><p>Beware of asking the wrong question. If you ask one that is

based on faulty assumptions, J. Random Hacker is quite likely to reply

with a uselessly literal answer while thinking "Stupid question...",

and hoping that the experience of getting what you asked for rather

than what you needed will teach you a lesson.</p><p>Never assume you are <span class="emphasis"><em>entitled</em></span> to an answer.

You are not; you aren't, after all, paying for the service. You will

earn an answer, if you earn it, by asking a question that is

substantial, interesting, and thought-provoking ― one that

implicitly contributes to the experience of the community rather than

merely passively demanding knowledge from others.</p><p>On the other hand, making it clear that you are able and willing

to help in the process of developing the solution is a very good

start. "Would someone provide a pointer?", "What is my example

missing?" and "What site should I have checked?" are more likely

to get answered than "Please post the exact procedure I should use."

because you're making it clear that you're truly willing to complete

the process if someone can simply point you in the right

direction.</p></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><h2 class="title" style="clear: both"><a id="asking"></a>When You Ask</h2></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><h3 class="title"><a id="forum"></a>Choose your forum carefully</h3></div></div><p>Be sensitive in choosing where you ask your question. You are

likely to be ignored, or written off as a loser, if you:</p><div class="itemizedlist"><ul type="disc"><li><p>post your question to a forum where it is off topic</p></li><li><p>post a very elementary question to a forum where

advanced technical questions are expected, or vice-versa</p></li><li><p>cross-post to too many different newsgroups</p></li><li><p>post a personal email to somebody who is neither

an acquaintance of yours nor personally responsible for solving your problem</p></li></ul></div><p>Hackers blow off questions that are inappropriately targeted in

order to try to protect their communications channels from being

drowned in irrelevance. You don't want this to happen to you.</p><p>The first step, therefore, is to find the right forum. Again,

Google and other web-searching methods are your friend. Use them to

find the project web page most closely associated with the hardware or

software that is giving you difficulties. Usually it will have links

to a FAQ (Frequently Asked Questions) list, and to project mailing

lists and their archives. These mailing lists are the final places to

go for help, if your own efforts (including

<span class="emphasis"><em>reading</em></span> those FAQs you found) do not find you a

solution.</p><p>But shooting off an email to a person or forum which you are not

familiar with is risky at best. For example, do not assume that the

author of an informative web page wants to be your free consultant.

Do not make optimistic guesses about whether your question will be

welcome -- if you are unsure, send it elsewhere, or refrain from

sending it at all.</p><p>When selecting a newsgroup or mailing list, don't trust the name

by itself too far; look for a FAQ or charter to verify that 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.</p><p>Know what your topic is! One of the classic mistakes is asking

questions about the Unix or Windows programming interface in a forum

devoted to a language or library or tool that is portable across both.

If you don't understand why this is a blunder, you'd be best off not

asking any questions at all until you get it.</p><p>In general, questions to a well-selected public forum are more

likely to get useful answers than equivalent questions to a private

one. There are multiple reasons for this. One is simply the size of

the pool of potential respondents. Another is the size of the

audience; hackers would rather answer questions that educate a lot of

people than questions which only serve a few.</p><p>Understandably, skilled hackers and authors of popular software are

already receiving more than their fair share of mistargeted messages.

By adding to the flood, you could in extreme cases even be the straw

which breaks the camel's back -- quite a few times, contributors to

popular projects have withdrawn their support because the collateral

damage in the form of useless email traffic to their personal accounts

became unbearable.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><h3 class="title"><a id="uselists"></a>Whenever possible, use project mailing lists</h3></div></div><p>When a project has a development mailing list, write to the

mailing list, not to individual developers, even if you believe that

you know who can answer your question best. Check the documentation

of the project and its homepage for the address of a project mailing

list, and use it. There are several good reasons for this

policy:</p><div class="itemizedlist"><ul type="disc"><li><p>Any question that's good enough to be asked of one

developer will also be of value to the whole group. Contrariwise, if

you suspect that your question is too dumb for a mailing list, it's not

an excuse to harass individual developers.</p></li><li><p>Asking questions on the list distributes load between

developers. The individual developer (especially if he's the project

leader) may be too busy to answer your questions.</p></li><li><p>Most mailing lists are archived and the archives are

indexed by search engines. Somebody could find your question and the

answer on the web instead of asking it again in the list.</p></li><li><p>If certain questions are seen to be asked often, the

developers can use that information to improve the documentation or the

software itself to be less confusing. But if those questions are

asked in private, nobody has the complete picture of what questions

are asked most often.</p></li></ul></div><p>If you cannot find a project's mailing list address, but only

see the address of the maintainer of the project, go ahead and write

to the maintainer. But even in that case, don't assume that the

mailing list doesn't exist. State in your e-mail that you tried and

could not find the appropriate mailing list. Also mention that you

don't object to having your message forwarded to other people. (Many

people believe that private e-mail should remain private, even if

there is nothing secret in it. By allowing your message to be

forwarded you give your correspondent a choice about how to handle

your e-mail.)</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><h3 class="title"><a id="bespecific"></a>Use meaningful, specific subject headers</h3></div></div><p>On mailing lists or newsgroups, the subject header is your golden

opportunity to attract qualified experts' attention in around 50

characters or fewer. Don't waste it on babble like "Please help me"

(let alone "PLEASE HELP ME!!!!"; messages with subjects like that get

discarded by reflex). Don't try to impress us with the

depth of your anguish; use the space for a super-concise problem

description instead.</p><p>A good convention for subject headers, used by many tech support

organizations, is "object - deviation". The "object" part specifies

what thing or group of things is having a problem, and the "deviation"

part describes the deviation from expected behavior.</p><div class="variablelist"><dl><dt><span class="term"><span class="strong">Stupid:</span>

</span></dt><dd><p>HELP! Video doesn't work properly on my laptop!</p></dd><dt><span class="term"><span class="strong">Smart:</span></span></dt><dd><p>XFree86 4.1 misshapen mouse cursor, Fooware MV1005 vid. chipset</p></dd><dt><span class="term"><span class="strong">Smarter:</span></span></dt><dd><p> XFree86 4.1 mouse cursor on Fooware MV1005 vid. chipset - is misshapen</p></dd></dl></div><p>The process of writing an "object-deviation" description will

help you organize your thinking about the problem in more detail. What

is affected? Just the mouse cursor or other graphics too? Is this

specific to XFree86? To version 4.1? Is this specific to Fooware

video chipsets? To model MV1005? A hacker who sees the result can

immediately understand what it is that you are having a problem with

<span class="emphasis"><em>and</em></span> the problem you are having, at a

glance.</p><p>If you ask a question in a reply, be sure to change the subject

line to indicate that you are asking a question. A Subject line that

looks like "Re: test" or "Re: new bug" is less likely to attract

useful amounts of attention. Also, pare quotes of previous messages

to the minimum consistent with cluing in new readers.</p><p>Do not simply hit reply to a list message in order to start an

entirely new thread. This will limit your audience. Some mail readers,

like mutt, allow the user to sort by thread and then hide messages in

a thread by folding the thread. Folks who do that will never see your

message.</p><p>Changing the subject is not sufficient. Mutt, and probably other mail

readers, looks at other information in the email's headers to assign

it to a thread, not the subject line. Instead start an entirely new

email.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><h3 class="title"><a id="easyreply"></a>Make it easy to reply</h3></div></div><p>Finishing your query with "Please send your reply to... " makes

it quite unlikely you will get an answer. If you can't be bothered to

take even the few seconds required to set up a correct Reply-To header in

your mail agent, we can't be bothered to take even a few seconds to

think about your problem. If your mail program doesn't permit this,

get a better mail program. If your operating system doesn't support

any mail programs that permit this, get a better operating

system.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><h3 class="title"><a id="writewell"></a>Write in clear, grammatical, correctly-spelled language</h3></div></div><p>We've found by experience that people who are careless and

sloppy writers are usually also careless and sloppy at thinking and

coding (often enough to bet on, anyway). Answering questions for

careless and sloppy thinkers is not rewarding; we'd rather spend our

time elsewhere.</p><p>So expressing your question clearly and well is important. If

you can't be bothered to do that, we can't be bothered to pay

attention. Spend the extra effort to polish your language. It

doesn't have to be stiff or formal ― in fact, hacker culture

values informal, slangy and humorous language used with precision.

But it has to <span class="emphasis"><em>be</em></span> precise; there has to be some

indication that you're thinking and paying attention.</p><p>Spell, punctuate, and capitalize correctly. Don't confuse "its"

with "it's", "loose" with "lose", or "discrete" with "discreet".

Don't TYPE IN ALL CAPS, this is read as shouting and considered

rude. (All-smalls is only slightly less annoying, as it's difficult to

read. Alan Cox can get away with it, but you can't.)</p><p>More generally, if you write like a semi-literate boob you will

very likely be ignored. Writing like a l33t script kiddie hax0r is

the absolute kiss of death and guarantees you will receive nothing but

stony silence (or, at best, a heaping helping of scorn and sarcasm) in

return.</p><p>If you are asking questions in a forum that does not use your

native language, you will get a limited amount of slack for spelling

and grammar errors ― but no extra slack at all for laziness (and

yes, we can usually spot that difference). Also, unless you know what

your respondent's languages are, write in English. Busy hackers tend

to simply flush questions in languages they don't understand, and

English is the working language of the Internet. By writing in

English you minimize your chances that your question will be discarded

unread.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><h3 class="title"><a id="formats"></a>Send questions in formats that are easy to understand</h3></div></div><p>If you make your question artificially hard to read, it is more

likely to be passed over in favor of one that isn't. So:</p><div class="itemizedlist"><ul type="disc"><li><p>Send plain text mail, not HTML. (It's not hard

to <a href="http://expita.com/nomime.html" target="_top">turn

off HTML</a>.)</p></li><li><p>MIME attachments are usually OK, but only if they are

real content (such as an attached source file or patch), and not

merely boilerplate generated by your mail client (such as another copy

of your message).</p></li><li><p> Don't send mail in which entire paragraphs are single

multiply-wrapped lines. (This makes it too difficult to reply to

just part of the message.) Assume that your respondents will be

reading mail on 80-character-wide text displays and set your

line wrap accordingly, to something less than 80.</p></li><li><p> However, do <span class="emphasis"><em>not</em></span> wrap data (such

as log file dumps or session transcripts) at any fixed column width.

Data should be included as-is, so respondents can have confidence

that they are seeing what you saw.</p></li><li><p>Don't send MIME Quoted-Printable encoding to an

English-language forum. This encoding can be necessary when you're

posting in a language ASCII doesn't cover, but a lot of mail agents

don't support it. When they break, all those =20 glyphs scattered

through the text are ugly and distracting. </p></li><li><p> Never, <span class="emphasis"><em>ever</em></span> expect hackers to be

able to read closed proprietary document formats like Microsoft Word.

Most hackers react to these about as well as you would to having a

pile of steaming pig manure dumped on your doorstep.</p></li><li><p>If you're sending mail from a Windows machine, turn

off Microsoft's stupid "Smart Quotes" feature. This is so you'll avoid

sprinkling garbage characters through your mail. </p></li></ul></div><p>If you're using a graphical-user-interface mail client, (such as

Netscape Messenger, MS Outlook, or their ilk) beware that it may

violate these rules when used with its default settings. Most such

clients have a menu-based "View Source" command. Use this on

something in your sent-mail folder to check that you are sending

plain text without unnecessary attached crud.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><h3 class="title"><a id="beprecise"></a>Be precise and informative about your problem</h3></div></div><div class="itemizedlist"><ul type="disc"><li><p>

Describe the symptoms of your problem or bug carefully and clearly.

</p></li><li><p>

Describe the environment in which it occurs (machine, OS, application,

whatever). Provide your vendor's distribution and release level

(e.g.: “Red Hat 8.0”, “Slackware 5.1”, etc.).

</p></li><li><p>

Describe the research you did to try and understand the problem

before you asked the question.

</p></li><li><p>

Describe the diagnostic steps you took to try and pin down the problem

yourself before you asked the question.

</p></li><li><p>

Describe any recent changes in your computer or software configuration

that might be relevant.

</p></li></ul></div><p>Do the best you can to anticipate the questions a hacker will

ask, and to answer them in advance in your request for help.</p><p>Simon Tatham has written an excellent essay entitled <a href="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html" target="_top">How to

Report Bugs Effectively</a>. I strongly recommend that

you read it.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><h3 class="title"><a id="volume"></a>Volume is not precision</h3></div></div><p>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.</p><p>This is useful for at least three reasons. One: being seen to

invest effort in simplifying the question makes it more likely that

you'll get an answer, Two: simplifying the question makes it more

likely you'll get a <span class="emphasis"><em>useful</em></span> answer. Three:

In the process of refining your bug report, you may develop a fix

or workaround yourself.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><h3 class="title"><a id="id2790354"></a>Don't claim that you have found a bug</h3></div></div><p>When you are having problems with a piece of software, don't

claim you have found a bug unless you are very,

<span class="emphasis"><em>very</em></span> sure of your ground. Hint: unless you can

provide a source-code patch that fixes the problem, or a regression

test against a previous version that demonstrates incorrect behavior,

you are probably not sure enough.</p><p>Remember, there are a lot of other users that are not

experiencing your problem. Otherwise you would have learned about it

while reading the documentation and searching the Web (you did do that

before complaining, <a href="#before" title="Before You Ask">didn't you</a>?). This

means that very probably it is you who are doing something wrong, not

the software.</p><p>The people who wrote the software work very hard to make it work

as well as possible. If you claim you have found a bug, you'll be

implying that they did something wrong, and you will almost always

offend them ― even when you are correct. It's especially

undiplomatic to yell “bug” in the Subject line.</p><p>When asking your question, it is best to write as though you

assume <span class="emphasis"><em>you</em></span> are doing something wrong, even if you

are privately pretty sure you have found an actual bug. If there

really is a bug, you will hear about it in the answer. Play it so the

maintainers will want to apologize to you if the bug is real, rather

than so that you will owe them an apology if you have messed up.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><h3 class="title"><a id="id2790546"></a>Grovelling is not a substitute for doing your homework</h3></div></div><p>Some people who get that they shouldn't behave rudely or

arrogantly, demanding an answer, retreat to the opposite extreme of

grovelling. “I know I'm just a pathetic newbie loser,

but...”. This is distracting and unhelpful. It's especially

annoying when it's coupled with vagueness about the actual

problem.</p><p>Don't waste your time, or ours, on crude primate politics.

Instead, present the background facts and your question as clearly as

you can. That is a better way to position yourself than by

grovelling.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><h3 class="title"><a id="symptoms"></a>Describe the problem's symptoms, not your guesses</h3></div></div><p>It's not useful to tell hackers what you think is causing your problem.

(If your diagnostic theories were such hot stuff, would you be consulting

others for help?) 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.</p><div class="variablelist"><dl><dt><span class="term"><span class="strong">Stupid:</span>

</span></dt><dd><p>I'm getting back-to-back SIG11 errors on kernel compiles, and suspect a

hairline crack on one of the motherboard traces. What's the best way to

check for those?</p></dd><dt><span class="term"><span class="strong">Smart:</span>

</span></dt><dd><p>My home-built K6/233 on an FIC-PA2007 motherboard (VIA Apollo VP2

chipset) with 256MB Corsair PC133 SDRAM starts getting frequent SIG11

errors about 20 minutes after power-on during the course of kernel

compiles, but never in the first 20 minutes. Rebooting doesn't restart

the clock, but powering down overnight does. Swapping out all RAM

didn't help. The relevant part of a typical compile session log

follows.</p></dd></dl></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><h3 class="title"><a id="chronology"></a>Describe your problem's symptoms in chronological order</h3></div></div><p>The most useful clues in figuring out something that went wrong often

lie in the events immediately prior. So, your account should describe

precisely what you did, and what the machine did, leading up to the

blowup. In the case of command-line processes, having a session log

(e.g., using the script utility) and quoting the relevant twenty or so

lines is very useful.</p><p>If the program that blew up on you has diagnostic options (such

as -v for verbose), try to think carefully about selecting options

that will add useful debugging information to the transcript.</p><p>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. That way, hackers will know

what to watch for in reading your account.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><h3 class="title"><a id="goal"></a>Describe the goal, not the step</h3></div></div><p>If you are trying to find out how to do something (as opposed to

reporting a bug), begin by describing the goal. Only then describe

the particular step towards it that you are blocked on.</p><p>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 a lot of effort to get past

this.</p><div class="variablelist"><dl><dt><span class="term"><span class="strong">Stupid:</span>

</span></dt><dd><p>How do I get the color-picker on the FooDraw program to take a

hexadecimal RGB value?</p></dd><dt><span class="term"><span class="strong">Smart:</span>

</span></dt><dd><p>I'm trying to replace the color table on an image with values

of my choosing. Right now the only way I can see to do this is by

editing each table slot, but I can't get FooDraw's color picker

to take a hexadecimal RGB value.</p></dd></dl></div><p>The second version if the question is smart. It allows an

answer that suggests a tool better suited to the task.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><h3 class="title"><a id="noprivate"></a>Don't ask people to reply by private email</h3></div></div><p>Hackers believe solving problems should be a public, transparent

process during which a first try at an answer can and should be

corrected if someone more knowledgeable notices that it is incomplete or

incorrect. Also, they get some of their reward for being

respondents from being seen to be competent and knowledgeable by

their peers.</p><p>When you ask for a private reply, you are disrupting both the

process and the reward. Don't do this. It's the

<span class="emphasis"><em>respondent's</em></span> choice whether to reply privately

― and if he does, it's usually because he thinks the question is

too ill-formed or obvious to be interesting to others.</p><p>There is one limited exception to this rule. If you think

the question is such that you are likely to get a lot of answers that

are all pretty similar, then the magic words are "email me and I'll

summarize the answers for the group". It is courteous to try and save

the mailing list or newsgroup a flood of substantially identical

postings ― but you have to keep the promise to summarize.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><h3 class="title"><a id="explicit"></a>Be explicit about the question you have</h3></div></div><p>Open-ended questions tend to be perceived as open-ended time

sinks. The 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.</p><p>You are more likely to get a useful response if you are

explicit about what you want respondents to do (provide pointers,

send code, check your patch, whatever). This will focus their

effort and implicitly put an upper bound on the time and energy

a respondent has to put in to helping you. This is good.</p><p>To understand the world the experts live in, think of expertise

as an abundant resource and time to respond as a scarce one. The less

of a time commitment you implicitly ask for, the more likely you are

to get an answer from someone really good and really busy.</p><p>So it is useful to frame your question to minimize the time

commitme

猜你喜欢
3Go 1 2 3 下一页