linux-l: Umgangsformen/Fragen von Newbies usw.

[Guido Seifert]

Hi, und zuallererst eine Entschuldigung fuer diesen sehr langen Anhang.
Den Texte habe ich erst von ein paar Tagen irgendwo gefunden und runtergeladen.
Leider weiss ich nicht mehr von wo, sonst haette ich einfach nur einen 
Link geschickt. Da er aber auf einige Threads der letzten Tage gut passt,
moechte ich ihn trotzdem hierher weiterreichen. Insbesondere die, die es mit
dem Englischen nicht so gut haben, moegen mir verzeihen. Vielleicht findet
sich ja jemand, der das uebersetzt.

Gruesse
Guido




Introduction

In the world of hackers, 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.

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.

Despite this, hackers have a reputation for meeting simple questions with 
what looks like hostility or arrogance. It sometimes looks like we're hostile 
to newbies and the ignorant. But this isn't really true.

What we are, unapologetically, is hostile to people who seem to be unwilling 
to to think or 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").

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.

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 
winner - to ask it like a person with smarts, confidence,
and clues who just happens to need help on one particular problem.

(Improvements to this guide are welcome. You can mail suggestions to 
esr at thyrsus.com.)



Before You Ask

Before asking a technical question by email, or in a newsgroup, or on a 
website chat board, do the following:

  1.Try to find an answer by reading the manual.

  2.Try to find an answer by reading a FAQ.

  3.Try to find an answer by searching the Web.

  4.Try to find an answer by asking a skilled friend.

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 peoples' time. Better yet, display what you
have learned from doing these things. We like answering questions for people 
who have demonstrated that they can learn from the answers.

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.

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.

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. "Can someone 
provide a pointer?", "What is my example missing?" and "Is there a site I 
should have checked?" are more likely to get answered than "Please post the
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.

Never assume you are entitled to an answer. You are not. 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.



When You Ask

Choose your forum carefully

Be sensitive in choosing where you ask your question. You are likely to be 
ignored, or written off as a loser, if you:

    post your question to a forum where it is off topic

    post a very elementary question to a forum where advanced technical 
    questions are expected, or vice-versa

    cross-post to too many different newsgroups

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.



Write in clear, grammatical, correctly-spelled language

We've found by experience that people who are careless and sloppy writers are 
usually also careless and sloppy thinkers (often enough to bet on, anyway). 
Answering questions for careless and sloppy thinkers is not rewarding; we'd 
rather spend our time elsewhere.

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 be precise; there has to be some 
indication that you're thinking and paying attention.

Spell correctly. Don't confuse "its" with "it's" or "loose" with "lose". 
Don't TYPE IN ALL CAPS, this is read as shouting and considered rude. If you 
write like a semi-literate boob, you will probably 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.

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 sloppy thinking. 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 net. By writing in English you minimize your chances 
that your question will be discarded unread.


Send questions in formats that are easy to understand

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:

    Send plain text mail, not HTML.

    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.) 

    Never, ever 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.

    If you're sending mail from a Windows machine, turn off Microsoft's 
    stupid "Smart Quotes" feature. This is so you avoid sprinkling garbage 
    characters through your mail. 



Use meaningful, specific subject headers

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!!!!"). Don't try to impress us with the depth of your anguish; use the space
for a super-concise problem description instead.

Stupid:

    HELP! Video doesn't work properly on my laptop!

Smart:

    XFree86 4.1 misshapen mouse cursor, Fooware MV1005 vid. chipset



Be precise and informative about your problem

    Describe the symptoms of your problem or bug 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.

    Describe any recent changes in your computer or software configuration 
    that might be relevant.

Do the best you can to anticipate the questions a hacker will ask, and to 
answer them in advance in your request for help.

Simon Tatham has written an excellent essay entitled How to Report Bugs 
Effectively. I strongly recommend that you read it.



Describe the problem's symptoms, not your guesses

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 them 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.

Stupid:

    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?

Smart:

    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.



Describe your problem's symptoms in chronological order

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.

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.

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.



Don't ask people to reply by private email

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.

When you ask for a private reply, you are disrupting both the process and the 
reward. Don't do this. It's the respondent's choice whether to reply privately
- and if he does, it's usually because he thinks the question is too obvious 
or ill-formed to be interesting to others.

There is one limited exception to 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.



Prune pointless queries

Resist the temptation to close your request for help with semantically-null 
questions like "Can anyone help me?" or "Is there an answer?" First, if you've
written your problem description halfway competently, such tacked-on questions
are at best superfluous. Second, given the foregoing, the question verges on 
being actively annoying, inviting dismissive albeit logically impeccable 
answers like "Yes" and "No"



Courtesy never hurts, and sometimes helps

Be courteous. Use "Please" and "Thanks in advance". Make it clear that you 
appreciate the time people spend helping you for free.

To be honest, this isn't as important as (and cannot substitute for) being 
grammatical, clear, precise and descriptive, avoiding proprietary formats 
etc.; hackers in general would rather get somewhat brusque but technically 
sharp bug reports than polite vagueness. (If this puzzles you, remember that
we value a question by what it teaches us.)

However, if you've got your technical ducks in a row, politeness does 
increase you chances of getting a useful answer.



Follow up with a brief note on the solution

Send a note after the problem has been solved to all who helped you; let them 
know how it came out and thank them again for their help. If the problem 
attracted general interest in a mailing list or newsgroup, it's appropriate 
to post the followup there.

Your followup doesn't have to be long and involved; a simple "Howdy - it was a
failed network cable! Thanks, everyone. - Bill" would be better than nothing. 
In fact, a short and sweet summary is better than a long dissertation unless 
the solution has real technical depth.

Besides being courteous and informative, this sort of followup helps everybody
who assisted feel a satisfying sense of closure about the problem. If you are 
not a techie or hacker yourself, trust us that this feeling is very important 
to the gurus and experts you tapped for help. Problem narratives that
trail off into unresolved nothingness are frustrating things; hackers itch to 
see them resolved. The good karma that scratching that itch earns you will be 
very, very helpful to you next time you need to pose a question. 



How To Interpret Answers

RTFM and STFW: How To Tell You've Seriously Screwed Up

There is an ancient and hallowed tradition: if you get a reply that reads 
"RTFM", the person who sent it thinks you should have Read The Fucking Manual.
He is almost certainly right. Go read it.

RTFM has a younger relative. If you get a reply that reads "STFW", the person 
who sent it thinks you should have Searched The Fucking Web. He is almost 
certainly right. Go search it.

Often, the person sending either of these replies has the manual or the web 
page with the information you need open, and is looking at it as he types. 
These replies mean that he thinks (a) the information you read is easy to 
find, and (b) you will learn more if you seek out the information than if you 
have it spoon-fed to you.

You shouldn't be offended by this; by hacker standards, he is showing you a 
rough kind of respect simply by not ignoring you. You should instead thank 
him for his grandmotherly kindness.



If you don't understand...

If you don't understand the answer, do not immediately bounce back a demand 
for clarification. Use the same tools that you used to try and answer your 
original question (manuals, FAQs, the Web, skilled friends) to understand the 
answer. If you need to ask for clarification, exhibit what you have learned.

For example, suppose I tell you: "It sounds like you've got a stuck zentry; 
you'll need to clear it." Then:

Here's a bad followup question: "What's a zentry?"

Here's a good followup question: "OK, I read the man page and zentries are 
only mentioned under the -z and -p switches. Neither of them says anything 
about clearing zentries. Is it one of these or am I missing something here?"



On Not Reacting Like A Loser

Odds are, you'll screw up a few times, on hacker community forums -- in ways 
detailed in this article, or similar. And you'll be told exactly how you 
screwed up, possibly with colourful asides. In public.

When this happens, the worst thing you can do is whine about the experience, 
claim to have been verbally assaulted, demand apologies, scream, hold your 
breath, threaten lawsuits, complain to people's employers, leave the toilet 
seat up, etc. Instead, here's what you do:

Get over it. It's normal. In fact, it's healthy and appropriate.

Community standards do not maintain themselves: They're maintained by people 
actively applying them, visibly, in public. Don't whine that all criticism 
should have been conveyed via private mail: That's not how it works. Nor is 
it useful to insist you've been personally insulted when someone comments that
one of your claims was wrong, or that his views differ. Those are loser 
attitudes.

There have been hacker forums where, out of some misguided sense of 
hyper-courtesy, participants are banned from posting any fault-finding with 
another's posts, and told "Don't say anything if you're unwilling to help the 
user." The resulting departure of clueful participants to elsewhere causes 
them to descend into meaningless babble and become useless as technical forums.

Exaggeratedly "friendly" (in that fashion) or useful: Pick one.

Remember: When that hacker tells you that you've screwed up, and (no matter 
how gruffly) tells you not to do it again, he's acting out of concern for (1) 
you and (2) his community. It would be much easier for him to ignore you and 
filter you out of his life. If you can't manage to be grateful, at least
have a little dignity, don't whine, and don't expect to be treated like a 
fragile doll just because you're a newcomer with a theatrically 
hypersensitive soul and delusions of entitlement.



Questions Not To Ask

Here are some classic stupid questions, and what hackers are thinking when 
they don't answer them.

Q: Where can I find program X?
Q: I'm having problems with my Windows machine. Can you help?
Q: I'm having problems installing Linux or X. Can you help?
Q: How can I crack root/steal channel-ops privileges/read someone's email?

Q: Where can I find program X?

A: The same place I'd find it, fool -- at the other end of a web search. Ghod,
   doesn't everybody know how to use Google yet?

Q: I'm having problems with my Windows machine. Can you help?

A: Yes. Throw out that Microsoft trash and install Linux.

Q: I'm having problems installing Linux or X. Can you help?

A: No. I'd need hands-on access to your machine to troubleshoot this. Go ask 
   your local Linux user group for hands-on help.

Q: How can I crack root/steal channel-ops privileges/read someone's email?

A: You're a lowlife for wanting to do such things and a moron for asking a 
   hacker to help you.



Good and Bad Questions

Finally, I'm going to illustrate how to ask questions in a smart way by 
example; pairs of questions about the same problem, one asked in a stupid way 
and one in a smart way.

Stupid: Where can I find out stuff about the Foonly Flurbamatic?

    This question just begs for "STFW" as a reply.

Smart: I used Google to try to find "Foonly Flurbamatic 2600" on the Web, but 
       I got no useful hits. Does anyone know where I can find programming 
       information on this device?

    This one has already SFTWed, and sounds like he might have a real problem.

Stupid: I can't get the code from project foo to compile. Why is it broken?

    He assumes that somebody else screwed up. Arrogant of him.

Smart: The code from project foo doesn't compile under Nulix version 6.2. 
       I've read the FAQ, but it doesn't have anything in it about 
       Nulix-related problems. Here's a transcript of my compilation attempt; 
       is it something I did?

    He's specified the environment, he's read the FAQ, he's showing the error,
    and and he's not assuming his problems are someone else's fault. This guy 
    might be worth some attention.

Stupid: I'm having problems with my motherboard. Can anybody help?

    J. Random Hacker's response to this is likely to be "Right. Do you need 
    burping and diapering, too?" followed by a punch of the delete key.

Smart: I tried X, Y, and Z on the S2464 motherboard. When that didn't work, 
       I tried A, B, and C. Note the curious symptom when I tried C. Obviously
       the florbish is grommicking, but the results aren't what one might 
       expect. What are the usual causes of grommicking on MP motherboards?
       Anybody got ideas for more tests I can run to pin down the problem?

    This person, on the other hand, seems worthy of an answer. He has 
    exhibited problem-solving intelligence rather than waiting for an answer 
    to drop from on high.

In the last question, notice the subtle but important difference between 
demanding "Give me an answer" and "Please help me figure out what additional 
diagnostics I can run to achieve enlightenment."

In fact, the form of that last question is closely based on a real incident 
that happened in August 2001 on the linux-kernel mailing list. I was the one 
asking the question that time. I was seeing mysterious lockups on a Tyan S2464
motherboard. The listmembers supplied the critical information I needed to
solve them.

By asking the question in the way I did, I gave people something to chew on; I
made it easy and attractive for them to get involved. I demonstrated respect 
for my peers' ability and invited them to consult with me as a peer. I 
demonstrated respect for their time by telling them the blind alleys I had
already run down.

Afterwards, when I thanked everyone and remarked how well the process had 
worked, an lkml member observed that he thought it had worked not because I'm 
a "name" on that list, but because I asked the question in the proper form.

We hackers are in some ways a very ruthless meritocracy; I'm certain he was 
right, and that if I had behaved like a sponge I would have been flamed or 
ignored no matter who I was. His suggestion that I write up the whole incident
as an instruction to others led directly to the composition of this guide.