Copyright © 2001,2006,2014 Eric S. Raymond, Rick Moen
このドキュメントはEric Steven Raymond氏によるHow To Ask Questions The Smart Wayの日本語訳です。
翻訳： アラビア語 インドネシア語 ベラルーシ語 ブラジルポルトガル語 中国語 チェコ語 オランダ語 フランス語 グルジア語 ドイツ語 ギリシャ語 ヘブライ語 ポーランド語 ポルトガル語 ルーマニア語 ロシア語 セルビア語 スペイン語 スウェーデン語 タイ語 If you want to copy, mirror, translate, or excerpt this document, please see my copying policy.
多くのプロジェクトのウェブサイトがヘルプの項目からこのドキュメントにリンクを張っている。それは私達の意図した使い方なので構わない ―― しかしあなたがそのようなリンクをプロジェクトのページに追加しようとしているウェブ管理者ならば、リンクの傍らに目立つように、私達があなたのプロジェクトのサポート窓口ではないことを明示してほしい。
その注意書き無くしては、このドキュメントを公開したことで全世界の技術的問題を解決するのが私達の役目となると思い込む困った人達によって私達が再三苦しめられることになると、経験をもって学んだ。
もしあなたが助けを必要としてこのドキュメントを読んでいるならば、そしてドキュメントの作者達から直接助けを得られると感じるならば、あなたは私達の言うところの困った人達の一人である。私達に質問しないように。質問されても私達は無視するだけだ。このドキュメントはあなたの使用しているソフトウェアかハードウェアについて実際に知っている人から助けを得る方法について説明しているが、その人とは九分九厘私達ではない。著者の一人があなたの使っているものの専門家であると確かに知っているのではない限り、私達を放っておいてほしい。そうすれば誰もが幸せになれる。
ハッカーの世界で技術的な質問に返ってくる答えの質は、回答の難しさだけではなく聞き方次第でもある。この手引きはあなたがより満足する回答を得られるような質問のしかたについて述べている。
今日オープンソースは広く使われている。あなたが良い回答を、他のあなたより経験のあるユーザーから得ることも、ハッカーからと同じくらい多くあるだろう。それは「いいこと」だ。ユーザーは概して初心者が陥りやすい間違いについて多少寛容だろう。しかし経験を積んだユーザーにもハッカーに対するようにここで勧める作法で対応することは、一般に有用な答えを得るための最も効果的な方法である。
最初に理解することは、ハッカーは本来難しい問題やそれについて考えさせる良い質問が好きだということだ。そうでなければ私達はここにいないだろう。私達はあなたが考えさせる興味深い質問をしてくれるならば、本当にありがたいと思う。良い質問は刺激であり贈り物なのだ。良い質問は私達の理解を深め、しばしばそのままでは私達が気づかなかったり考えもしなかった問題を明らかにしてくれる。ハッカーの間で「良い質問です」とは力のこもった心からの褒め言葉なのだ。
それにもかかわらず、ハッカー達は単純な質問に対し敵意や尊大さで応じているという評判がある。初心者や知識の無い人には反射的に無礼な態度を取っているように時には見えるかもしれない。しかし実際はそうではない。
悪びれずに言うならば、私達は質問をする前に、自分で考えたり下調べしたがらない人達に敵意を持っているのだ。そういう人達は時間を無駄にする ―― 彼らは一方的に質問を行い、そして他のより興味深い質問や答えるに足る人に対して費やせた時間を無駄にする。このような人を私達は「敗者（losers, ルーザー / タコ）」と呼ぶ（そして歴史的な経緯でたまに「lusers」と綴る）。
単に私達の書いたソフトウェアを使いたいだけの人や、技術的な詳細について知ることに興味が無い人が多いことは知っている。大部分の人にとってコンピュータは単に道具、つまり目的を達成する手段であり、他により重要な事や生活があるのだ。私達はそれを知っており、私達を魅了する技術的な事柄に誰もが興味を持つとは期待していない。それにもかかわらず、私達の答え方はそのようなことに興味を持ち、かつ問題解決に積極的な参加者に向いている。それは変わらないだろうし変わるべきでもない。さもなければ私達は最善を尽くせなくなってしまう。
私達は（大部分が）ボランティアだ。忙しい時間の中から質問に答え、時にはそれに掛かり切りになる。そのため冷酷に質問を選別する。特に敗者でありそうな人の質問は、より効率良く「勝者」の質問に答えるために打ち捨てる。
もしこの態度を不快で恩着せがましい、もしくは傲慢であると思ったならば、その推測を検証してみてほしい。私達はあなたにひざまずけとは言っていない。それどころか私達の大部分は、あなた方が必要な努力を行うならば、あなた方を公平に扱い、私達の文化へ迎え入れることを何よりも好む。しかし自助努力を行いたがらない人を助けようとするのは私達にとって全く非効率的だ。無知であることは構わないが、馬鹿のふりをするのは良くないのだ。
だから私達の注意を引くために予め技術的な能力を持っている必要はない。能力に通じる類いの考え ―― 注意深さ、思慮、観察力、解決策を見つけるための意欲的な協力者であろうとする姿勢 ―― を見せる必要があるのだ。もしこのような待遇を受け入れられないならば、ハッカー達に個人的に手助けしてもらう代わりに誰かにお金を払い商業的なサポート契約を結ぶことをお勧めする。
私達に手助けを求めるならば、敗者の一人にならない方がいいし、そう見えないほうがいいだろう。迅速な答えを得る一番の方法は、知性と確信と見当を持った人が、ある特定の問題についてたまたま助けが必要になったかのように尋ねることだ。
（原文の著者達のメールアドレス）まで送ってほしい。ただしこの文書は一般的なネチケットの手引きにするつもりはないので、技術的なフォーラムにおいて有益な回答を引きだすことに特に関係しない意見については基本的に却下する。）
技術的な質問をメール・ニュースグループ・チャットでする前に、次のことを行ってほしい：
投稿先のフォーラムのアーカイブを検索して答えを探してみる。
ウェブを検索して答えを探してみる。
マニュアルを読んで答えを探してみる。
FAQ（よくある質問）を読んで答えを探してみる。
追跡や実験を行って答えを見つけてみる。
詳しい友人に聞いてみる。
もしプログラマなら、ソースコードを読んで答えを探してみる。
質問をするときは、まずこれらを行ったという事実を提示する。それはあなたが人の時間を浪費する、怠け者のたかりではないということの証明になる。その結果学んだことを書くとより良いだろう。私達は回答から学べるということを実証した人に回答することが好きなのだ。
表示されたエラーメッセージは何でもGoogle検索を行うような戦略を取ろう（そしてウェブ検索だけでなくGoogleグループの検索も）。そうすれば質問に答えてくれるドキュメントやメーリングリストのスレッドに辿り着くかもしれない。もしそうならなくても、助けを求めるメールやニュースへの投稿をするときに「この語句を検索してみましたが期待できそうなページは見つかりませんでした」と書き添えるのは（どの語句の検索では役に立たないということが分かるだけでも）良いことだ。うまくいけば、検索語句を問題と解決法となるかもしれないあなたのスレッドに関連づけることもでき、後々似た問題を抱える他の人達を誘導するのにも役立つだろう。
時間をかけよう。数秒間Google検索するだけで複雑な問題を解決できるなどと思ってはいけない。専門家に持ちかける前にFAQを読み理解し、椅子にもたれリラックスして問題のことをしばらく考える。彼らは質問から、あなたがどれだけ読み、考えたかを量ることができるはずだし、心がけが見えればより助けたくなるはずだ。最初の検索で全く答えが見つからなかった（もしくは多すぎた）からといって、いきなり矢継ぎ早に質問を浴びせてはいけない。
質問の準備をしよう。問題についてよく考えてほしい。せっかちに見える質問にはそのような答えが、もしくは全く答えが返ってこない。助けを求める前に問題を解決しようと考察と努力を重ねたことを証明すればするほど、実際に助けが得られやすくなる。
間違った質問に気をつけよう。誤った仮定を元に質問をすると、必ずどこかのハッカーが「馬鹿な質問だな…」と考えながら無用なまでに字面通りに解釈した答えを返してくるだろう。あなたが、必要な答えではなく質問の答えを得ることで学習することを望んでいるからだ。
あなたが回答を得る資格があるとは絶対に思わないこと。そもそもサービスに対する対価を支払っていないのだから。回答を得るために、価値があり興味深く、示唆に富んだ質問をすることで、単に他人の知識を受け身で要求するのではなく、暗黙的にコミュニティーに貢献できるのだ。
一方、あなたが問題の解決法を探る過程を助けることができ、またそれを望んでいることを明確にするのはとても良いスタートだ。「どなたか助言はありますか？」、「私の例に足りないものはありますか？」、「どこか見ておくべきサイトはありますか？」と言うことは「私のするべき正確な手順を教えて下さい」と書くよりも答えを得やすいだろう。なぜなら誰かがただ正しい道筋を示してくれれば後は自力で解決するつもりであると明らかにしているのだから。
どこで質問するか注意深く選ぼう。次のようでは無視されるか敗者と見なされるだろう。
話題違いなフォーラムに投稿した。
初歩的な質問を高度に技術的な質問を想定したフォーラムに投稿した。もしくはその逆。
多くの異なるニュースグループにクロスポストした。（ニュースグループにおいては、複数回同じ内容を投稿するマルチポストに比べてクロスポストによって新着扱いになるメッセージは1件のため問題となりにくいですが、投稿先を吟味しないと問題とされます。）
知人でも、また個人的に問題解決の責任があるわけでもない人に私的にメールを送った。
ハッカーはコミュニケーションの場が無関係な投稿で埋もれないように不適当な質問は無視する。あなたはそうされないようにすべきだ。
そのため第一歩は正しいフォーラムを見つけることになる。再び、Google等のウェブ検索が助けになる。困難の元になっているハードウェアかソフトウェアに最もよく関連しているプロジェクトのウェブページを見つけよう。通常そのページにはFAQリストのページやプロジェクトのメーリングリスト、アーカイブへのリンクがある。メーリングリストはあなた自身の努力（見つけたFAQを読むことを含む）によって解決できなかった時に最後に助けを求める場所だ。プロジェクトページにはバグレポートの手順が述べられていたり、それに関するリンクがあるかもしれない。その時はそれに従おう。
どんなときでもあまり知らない人やフォーラムにメールを出すのは危険である。例えば、有益なウェブページを作っている人が無料の相談相手になりたがっていると思わないこと。あなたの質問が歓迎されるかどうか楽観的観測を行わないように。自信がないならば、どこか他の場所に送るか、いっそ送ることを止めよう。
ウェブフォーラムやニュースグループ、メーリングリストを選ぶときは、そのタイトルだけを信用しすぎることなく、FAQや注意書き（charter, 憲章）を探してあなたの質問が正しい話題か確認すること。投稿前に最近のログを読んでその場の雰囲気を掴もう。実際、投稿前にそのニュースグループやメーリングリストのアーカイブ内を検索するのはとても良い考えだ。答えが見つかるかもしれないし、見つからなくてもより良い質問をする手助けになるだろう。
可能な場全てを一度に頼ってはいけない。喚き散らしているようなもので、怒りを買うことになる。一つ一つ穏やかに。
あなたの話題が何かを把握すること。典型的な間違いはUnixやWindowsのプログラミングインターフェースについての質問を、両方の環境で利用できるプログラミング言語やライブラリ、ツールに関するフォーラムで尋ねてしまうことだ。何故これが間違いなのか分からないうちは何も質問しないほうが良いだろう。
一般に、十分に厳選した有名なフォーラムの方が私的なフォーラムよりも有益な回答が得られる傾向がある。理由はいくつかあるが、一つは単に潜在的な回答者の数、そしてもう一つは読者の数だ。ハッカーは数人よりも多くの人に教えられる質問に答えたがる。
当然だが、技術のあるハッカーや有名なソフトウェアの作者は既に相当量の見当外れのメッセージを受け取っている。その殺到に加わることで、極端な場合あなたは彼らに決定打をあたえてしまうかもしれない。しばしば、有名なプロジェクトに寄与してきた人達が個人的なメールアカウントに届く無用なメールという二次的な被害に耐えられなくなりサポートを取りやめている。
検索し、それからStack Exchangeで質問する。
近年、Stack Exchangeコミュニティが技術的な質問やその他の質問に答える主要なリソースとなってきており、また多くのオープンソースプロジェクトにとってはまず調べるべきフォーラムとなっている。
Stack Exchangeを見る前に、まずGoogle検索を行う。Googleはリアルタイムでインデックス化を行っているからだ。誰かが既に似た質問を行っている可能性が十分にあるし、Stack Exchangeの各サイトは検索結果の上位に出ることが良くある。もしGoogleで何も見つからなかったら、質問のカテゴリにあったサイト内で検索を行う(下記一覧参照)。タグを組み合わせて検索すると結果の絞り込みに役に立つだろう。
もしそれでも見つからなかった場合は、質問をもっとも適したサイトひとつに投稿する。コードは特にツールを使って整形し、質問の本質に合ったタグを追加する(特にプログラミング言語、OS、問題のライブラリの名前の)。もし詳細な情報を求めるコメントが付いたら、質問を編集してそれを追記する。もし助けになった回答があったら上矢印をクリックして投票する。もし回答が解決策をくれたならば、矢印の下にあるチェックマークを押して解答とする。
Stack Exchangeは100を超えるサイトがあるが、次のものが大抵の候補だろう:
コンピュータに関する質問はSuper User。もしあなたの質問がコードやプログラムについてではなく、単にネットワーク接続越しに操作しているだけならば、おそらくこのサイトだろう。
プログラミングに関する質問はStack Overflow。（日本語版:スタック・オーバーフロー）
サーバやネットワーク管理についての質問はServer Fault。
いくつかのプロジェクトは専用のサイトを持っている。たとえばAndroid, Ubuntu, TeX/LaTeX, SharePointなど。Stack Exchangeのサイトで最新の一覧を確認しよう。
あなたの地元のユーザーグループやLinuxディストリビューションは、初心者が質問するためのウェブフォーラムやIRCチャンネルを宣伝しているかもしれない（非英語圏ではまだ初心者向けの場はメーリングリストが多いかもしれない）。これらは最初に質問する場所として、とりわけ単純そうだったり一般的そうな問題につまずいた時には適しているだろう。自ら宣伝しているIRCチャンネルは質問が来るのを待っており、しばしば即座に回答が得られる。
実際（近ごろは一般的になった）Linuxディストリビューションに含まれているプログラムで問題を抱えているならば、そのプログラムのプロジェクトのフォーラムやリストよりも前にそのディストロのフォーラムやリストで質問したほうが良いだろう。プロジェクトのハッカーは単に「私達のビルドを使って下さい」と言うかもしれないからだ。
ウェブフォーラムに投稿する前には、検索機能がついているか確認しよう。もしあるならば、二三のキーワードであなたの問題に似た事例を検索してみることはきっと役立つはずだ。もし普通のウェブ検索をした上だとしても（そうでなくてはならないが）、とにかくフォーラム内を検索してほしい。ウェブの検索エンジンはフォーラム全体のインデックス化を最近していなかったかもしれないからだ。
メールのやりとりが開発者寄りになるにつれ、プロジェクトのサポートはウェブフォーラムやIRCチャンネルで行われる傾向がある。プロジェクト固有の助けが必要な時は、まずそちらを探そう。
プロジェクトに開発者によるメーリングリストがあるときは、たとえ開発者個人が一番よく答えることができると思ってもそのメーリングリストに投稿しよう。プロジェクトのドキュメントやホームページでメーリングリストのアドレスを確認してそこへ宛てる。この手段を取るのにはいくつかの道理にかなった理由がある。
一人の開発者に尋ねるに足るほど良い質問ならばグループ全体にとっても価値があるはずだ。逆に質問がメーリングリストに投稿するには馬鹿げているのではないかと思える場合でも、それが開発者個人を悩ませる口実にはならない。
リストで質問することで負担を開発者達の間で分散できる。開発者個人は（特にプロジェクトリーダーの場合）忙しくて質問に答えられないかもしれない。
多くのメーリングリストはアーカイブされ、検索エンジンによってインデックス化される。あなたがリストで質問をして回答されると、将来の質問者が再びその質問をする代わりに、あなたの質問とその回答をウェブで見つけることができる。
もし特定の質問が頻繁にされるようならば、開発者はその情報を元にドキュメントやソフトウェア自体を分かりやすく改善することができる。しかしもしこれらの質問が個人的に行われたならば、だれも最も頻繁にある質問の全体像を把握することができない。
もしプロジェクトのメーリングリストやウェブフォーラムに「ユーザー向け」と「開発者向け」（または「ハッカー向け」）の両方があり、あなたがコードをハックしているのでなければ、「ユーザー向け」のリスト／フォーラムに質問しよう。開発者のリストで歓迎されると思ってはいけない。彼らは開発者間のやりとりを混乱させるノイズだと感じるだろう。
ただしもし質問が確かに些細なことではなく、「ユーザー」のリスト／フォーラムで数日待っても回答が得られないならば、「開発者」側に出してみよう。投稿の前に二三日潜む（いわゆるROM）か最低限でもここ数日のアーカイブを調べて、そこの習慣を掴んでおくのが懸命だろう（実際これはどんな私的・半私的なリストにも当てはまる良いアドバイスである）。
もしプロジェクトのメーリングリストのアドレスを発見できず、管理者のメールアドレスしか見当たらなかった場合はその人にメールしてみよう。しかしその場合でもメーリングリストが無いと思い込んではいけない。メールにはメーリングリストを探したけれども適切なものが見つからなかったことに言及する。また、あなたのメッセージを他の人に転送しても構わないと書いておこう。（多くの人はたとえ何も秘密が書かれていなくてもメールは公開するべきではないと思っている。転送の許可をすることで送信者にあなたのメールをどのように扱うか選択の余地を与えることができるのだ。）
メーリングリストやニュースグループ、ウェブフォーラムにおいて、件名はたかだか50文字で適任の専門家の注意を引ける絶好の機会だ。「助けて下さい」等の無駄口で浪費しないように。（もちろん「助けて下さい！！！」は言うまでもない。そのような件名のメッセージは反射的に放置される。）件名で自分の苦悩を印象づけようとせず、代わりに簡潔な問題の説明に利用しよう。
多くのテクニカルサポートで使われる良い件名の形式は「対象 - 逸脱」である。「対象」の部分はどの事柄や分野の問題かを明記し、「逸脱」の部分は期待した振るまいからの逸脱を明記する。
助けて！ノートで画面が正しく表示されない！
X.org 6.8.1のマウスカーソルが変な形, Fooware MV1005ビデオチップセット
(X.org 6.8.1 misshapen mouse cursor, Fooware MV1005 vid. chipset)
X.org 6.8.1のマウスカーソル, Fooware MV1005ビデオチップセット - が変な形
(X.org 6.8.1 mouse cursor on Fooware MV1005 vid. chipset - is misshapen)
「対象 - 逸脱」形式で書くことは問題についてより詳細に考えを整理する助けになる。何が影響を受けているのか？ マウスカーソルだけなのか、他の画像もなのか？ これはX.orgのX固有の問題なのか？ それもバージョン6.8.1に？ Foowareのビデオカード固有なのか？ それもMV1005に？ 結果を見たハッカーは一瞥しただけで即座に何に問題があるかとあなたが抱えている問題とを理解することができる。
もっと一般的に言うと、質問の件名が並ぶアーカイブの目次を見ることを想像してほしい。後であなたと似た質問を持った人が再び投稿しないでもアーカイブを探せば答えを見つけられるように内容を件名に十分反映させる。
もし返信で質問を行うときは、件名であなたが質問をしていることを示そう。「Re: テスト」や「Re: 新しいバグ」のような件名は有効な注意を得にくいものだ。また、前のメッセージの引用は新しい読者に配慮しつつ最小限に削るようにしよう。
完全に新しいスレッドを開始する際に絶対に返信を押さないように。メッセージの読み手を減らすことになる。Muttなどいくつかのメーラはメッセージをスレッド別に畳んで並べることができる。そうしている人にはあなたのメッセージが見えないことになってしまう。
件名を変えるだけでは十分ではない。Muttやおそらくは他のメーラは件名ではなくメールヘッダの他の情報を元にスレッドに並べるからだ。代わりに完全に新しいメールを作成しよう。
一方ウェブフォーラムでは良しとされる習慣が少し異なる。なぜなら通常メッセージはより強く議論のスレッドに結びついており、しばしばスレッドの外からは見えないからだ。返信で質問をするときに件名を変えることはさほど重要ではない。返信に違う件名が付けられるとは限らない上、付けてもほとんど誰も読まない。しかし返信で質問をすること自体が、スレッドを読んでいる人にしかわからないために疑問のある習慣なのだ。そのためそのスレッドを現在読んでいる人達だけに聞きたいのでないかぎり、新しいスレッドを作ろう。
「返信は××まで送って下さい」で締めた質問はかなり回答を得にくくなる。もしあなたが正しいReply-Toヘッダを付ける数秒の手間もかけられないならば、私達があなたの問題について何秒も考えられるわけがないのだ。もしメーラがそのヘッダを追加できないならば、別のメーラを使おう。あなたのOSで動作するメーラにそのようなものがないならば、別のOSを使おう。
ウェブフォーラムでは、メールで返事を求めることは完璧に不作法である ―― あなたがその情報がデリケートなものであると（そして誰かが何らかの不明な理由によりその情報をフォーラムのあなた以外の人達に知らせたくないと）確信しているのでない限りは。もし誰かがスレッドに返信した時にメールでその内容を通知して欲しいのならば、ウェブフォーラムの機能を使おう。そのような機能は大抵のフォーラムで、「スレッドを購読」や「スレッドに投稿されたらメールで通知」のようなオプションとして用意されている。
私達は経験的に、不注意でだらしのない人は大抵考えることやコーディングもだらしがないと知っている（賭けてもいいくらい、とにかくよくある）。そのような人の質問には答える甲斐がないので、他のことに時間を使うだろう。
そのためあなたの質問を明確に充分説明することは大切だ。そのような手間が掛けられないならば、私達も注意を払わない。言葉を洗練させるためにさらに時間をかけるように。堅苦しく、形式張る必要はない ―― 実際ハッカーの文化は正確に使われた くだけてスラング混じりのユーモラスな言葉を重んじる。しかし正確である必要がある。あなたに頭を使っていて注意を払っているという証がなくてはならない。
正しく綴り、句読点を正しく付け、大文字小文字を正しく書こう。「its」と「it's」、「loose」と「lose」、「discrete」と「discreet」を混同しないように。全てを大文字で書かないこと。怒鳴っているように読め、失礼と判断される。（全てを小文字で書くのは読みにくいので、大文字より若干煩わしくないだけである。Alan Cox氏ならば許されるが、あなたでは無理だ。）
より一般的には、読み書きのできない間抜けのように書いてしまうと無視される。よってメッセンジャーで使うような省略をしてはいけない。youをほんの2文字省いてuと書くだけであなたはそのような間抜けのように見られる。より悪い：ｽｰﾊﾟｰﾊｶｰを気取って厨臭さの漂う書き方をすれば命取りであり、返ってくるのは冷たい沈黙（もしくは、良くて山ほどの軽蔑と皮肉）だろう。
自分の母国語ではないフォーラムで質問をするのならば、ある程度の綴りや文法間違いはあるだろう ―― しかしだからといって普段より不精にはならない（普通その違いは見抜くことができる）。また回答者の使う言語が分からないならば英語で書こう。忙しいハッカーは読めない言葉で書かれた質問を単に流しがちだし、英語はインターネットで実際に使われている言語なのだ。英語で書くことで質問が読まれずに捨てられる可能性を最小限にすることができる。
もしあなたが英語で書いていて、しかし英語が第二言語であるときは、回答してくれるかもしれない人のために、言葉に関わる問題や、それを回避する手立てについて知らせておくとよい。例えば
English is not my native language; please excuse typing errors.
（英語がネイティブではありません。タイプミスがありましたらご容赦ください。）
If you speak $LANGUAGE, please email/PM me; I may need assistance translating my question.
（${LANGUAGE}がわかる方はどうぞメール/PMをお願いします。質問を翻訳する手助けをいただきたいです。）
I am familiar with the technical terms, but some slang expressions and idioms are difficult for me.
（技術用語は見慣れているのですが、スラングやイディオムなどはそれと判りにくいです。）
I've posted my question in $LANGUAGE and English. I'll be glad to translate responses, if you only use one or the other.
（質問は${LANGUAGE}と英語で書きました。返信していただける方がもしどちらかの言葉しか使わないようでしたら翻訳したいです。）
もしあなたがわざと質問を読みにくくするならば、そうしないものに比べて無視されやすい。だから
HTML形式ではなくテキスト形式で送ろう。（HTML形式で送らないようにするのは難しくない）
MIMEエンコードの添付ファイルは普通は構わない。ただし、単にメールクライアントによって自動的に作られたもの（同じメッセージのコピー等）ではなく実際の内容（ソースファイルやパッチ）がある場合だけである。
段落中が無改行のメールを送ってはいけない（メッセージの一部に対して返信するのがとても難しくなる）。回答者が横幅80文字の画面で読んでいると考え、80文字未満で適宜改行するように。
しかし、絶対にデータ（ログファイルのダンプやセッションの記録等）は固定幅で折り返さないように。回答者があなたと同じデータを見ていると確信できるように、ありのままで含めなければならない。
英語のフォーラムにMIME Quoted-Printable形式で送らないように。ASCIIでは表現できない言語ではこのエンコーディングは必要なこともあるが、多くのメーラはそれをサポートしておらず、文章全体に=20という記号がまき散らされて見苦しく混乱させることに ―― もしくは文章の意味合いを変えてしまうことになる。
Microsoft WordやExcel等の閉鎖的で独占的な文書形式をハッカーが読めるとは絶対に思わないこと。大部分のハッカーはこれらの形式に対して、玄関の段に捨てられた湯気を立てている豚の厩肥の山と同じような反応をする。対処できるときでも、そうさせられたことに憤るのだ。
Windowsからメールを送るならば、Microsoftのおせっかいな「引用符の変換」機能を切ろう。そうすればメールにゴミ文字をまき散らさずにすむ。
ウェブフォーラムでは、「顔文字」や「HTML」機能を（もし用意されているなら）多用しないこと。1つか2つの顔文字は普通大丈夫だが、色つきの装飾的な文字はあなたが間抜けだと思われがちになる。顔文字や色や書体の乱用はあなたが喧しい十代の少女であるかのように見せる。一般的にあなたが回答よりも性的なことの方に興味があるのでない限り、良い手ではない。
もしあなたがNetscape MessangerやMS OutlookのようなGUIのメールクライアントを使っているならば、標準設定のまま使うことでこれらのルールを破ることになるかもしれないので気をつけてほしい。そのようなクライアントには大抵、メニューに「ソースを表示」コマンドがある。送信済みメールフォルダのメールをこれでチェックしてあなたが不要なごみを添付せずにテキスト形式でメールを送っているか確認するように。
問題やバグの症状について注意深く明確に書こう。
発生する環境（マシン、OS、アプリケーション等何でも）について書こう。ベンダーのディストリビューションとリリースレベル（「Fedora Core 7」や「Slackware 9.1」等）の情報も。
質問の前に問題を理解するために行った調査について書こう。
質問の前に問題を突き止めるために行った診断手順について書こう。
最近行ったコンピュータやソフトウェアの設定変更で関係のありそうなものを書こう。
可能な限り、決まった環境でその問題を再現する方法を提示しよう。
あなたの求めに対しハッカーが聞いてきそうな質問を予想し、それに前もって答えるために最善を尽くそう。
バグだと思う挙動を報告するときは特に重要なのが、ハッカーが問題を決まった環境で再現可能にすることだ。有用な回答を得る可能性や、その回答を得るまでの時間が、ものすごく向上する。
Simon Tatham氏が効果的にバグを報告するにはという優れたエッセイを書いている。一読を強く勧める。
正確かつ有益である必要があるが、単に大量のコードやデータを質問に突っ込むことではこの結果は得られない。もしプログラムを動かなくする巨大で複雑なテストケースがあるならば、可能な限りその量を小さく削減しようとしてほしい。
これには少なくとも三つの役立つ理由がある。一つ目は質問を単純にする努力を見せることで答えが得られやすくなるから。二つ目は質問を単純にすることで有益な答えが得られやすくなるから。三つ目はバグレポートを洗練させる過程で解決策や回避策を自分自身で発見できるかもしれないからだ。
使っているソフトウェアの一部に問題が出たとき、本当に確かな根拠がない限りはバグを見つけたと報告するべきではない。ヒント：問題を解決できるソースコードのパッチをあなたが提供できるか、前のバージョンに対してリグレッションテストを行って不適当な振る舞いを証明できるのでない限りは、おそらく十分ではないだろう。ウェブページやドキュメントにも当てはまる。ドキュメントの「バグ」を見つけたら、代わりの文章を用意し、それがどこの文なのか示すべきだ。
他の多くのユーザーはその問題を体験していないことも忘れてはいけない。さもなければあなたはドキュメントを読むか、ウェブを検索した時にそれについて知っているはずだ（その問題を訴える前にそうしたでしょう？）。つまり何か間違ったことをしているのはソフトウェアではなく、きっとあなたなのだ。
ソフトウェアを書いている人達はそれを可能な限り正しく動作させるために非常に苦労している。もしあなたがバグを見つけたと主張したら、彼らの力量に疑問を示すことになり、たとえあなたが正しいとしても一部の人達の気を損ねるかもしれない。特に「バグ」と件名に書き立てることは得策とは言えない。
質問するときは、たとえ実際にバグを発見してしまったと確信していてもあなたが何か間違ったことをしてしまったと仮定するのが最良だ。もし本当にバグがあったのならば、そのような回答があるだろう。そのように振る舞うことで、あなたの勘違いで謝罪することになる代わりに、バグが実際にあった場合に責任者が謝るかもしれない。
一部の回答が欲しい人達は、失礼に、もしくは傲慢に振る舞うべきではないと理解すると、今度は逆に極端に卑下しだす。「哀れな敗者の初心者ですが…」これは気を散らすものであり役に立たない。特に実際の問題が漠然としていると鬱陶しいものだ。
あなたや私達の時間を露骨な霊長類の駆け引きで無駄にしないように。代わりに背景的な事実やあなたの疑問を可能な限り明確に示してほしい。それが卑下するよりもよい立ち回り方なのだ。
ウェブフォーラムには初心者の質問用の場が設けられている場合がある。もし初心者の質問だと思うならば、そちらへ行くように。ただしそこでも媚びてはいけない。
問題についてあなたの考えた原因をハッカーに教えることは役立たない。（あなたの診断の理論が並外れたものならば他の人の相談にのっているはずでしょう？）だからあなたの解釈と理論ではなく、必ずうまく行かない症状をそのまま伝えるようにする。解釈と診断は彼らに任せよう。もし推測を述べるのが重要だと思ったら、推測であるとはっきりと言い、何故その考えが上手くいっていないのか書こう。
カーネルをコンパイルしようとするとSIG11が必ず出ます。マザーボード上の信号線の一つの細いキズが原因ではないかと思うのですが、確認するにはどうしたらいいでしょうか？
自作機（K6/233+FIC-PA2007(VIA Apollo VP2 chipset)+256MB Corsair PC133 SDRAM）が電源を入れて約20分経つと、カーネルのコンパイル中によくSIG11エラーを起こすようになりました。最初の20分には起こりません。再起動させても駄目ですが、一晩電源を切ると元に戻ります。RAMを交換しても解決できませんでした。関係する部分の主なコンパイルセッションログは次の通りです。
前述の例は多くの人に把握しにくいようなので、これを知っておいて欲しい：「診断する人は皆ミズーリ州から来ている」 アメリカのこの州の公式な標語は「見せてくれ」だ。（1899年に議員のWillard D. Vandiverが「私はトウモロコシと綿花とオナモミと民主主義を育てている州から来た。口先だけでは納得も満足もしない。私はミズーリから来た。証拠を見せてくれ。」と発言したことによる。）診断する人の場合は、懐疑ではなくむしろ文字通り診断のために、推測や要約ではなくあなたが見た形跡にできるだけ近いものを見る必要があるということだ。私達に見せてほしい。
うまく行かない原因を探るために最も役立つ手がかりは、多くの場合その直前の出来事にある。そのためあなたは正確に、駄目になるまでにあなたとあなたのマシンやソフトウェアがした事を説明しなくてはならない。コマンドラインの手順ならばセッションログを（例えばスクリプトユーティリティを使って）残し、20行程度の関係する部分を引用するととても役立つ。
もしそのプログラムに診断するためのオプション（verboseモードの-v等）がいくつかあるなら、有用なデバッグ情報を記録に付け加えるオプションを選んでみてほしい。ただしそれが多いほうが良いとは限らない。読者をゴミ漬けにせずに情報を伝えられるデバッグレベルを選び出そう。
もしあなたの説明が長く（大体4段落以上に）なってしまったならば、最初に問題を簡潔に示し、そして時間に沿った話を続けるのが有効かもしれない。そうすればハッカーはあなたの説明を読む上で何に気をつけるべきか判るだろう。
もし（バグレポートとは反対に）何かをするための方法を見つけようとしているならば、まず目的を説明しよう。そしてその後にそのために行き詰まっている特定の過程を説明する。
多くの場合、技術的な手助けが必要な人は高度な目的を持ち、そのために特有と思っている進路でつまずく。その手順について助けを求めるが、進路が間違っていることには気づかない。その方法では次の手順に進むのに相当な努力を必要とするかもしれないのだ。
FooDrawのカラーピッカーで16進数のRGB値を指定するにはどうしたらいいでしょうか？
画像のカラーテーブルを好きな値に置き換えようとしています。今のところそのためにはテーブルの各値を編集する事しか思いつかないのですが、FooDrawのカラーピッカーで16進数のRGB値を指定することができません。
後者の良い質問は、その作業により適しているツールを提案する回答を見込んでいる。
ハッカーは問題の解決は公にされるべきと思っている。最初に回答してみてからの過程を透明にすることで、より知識のある人がそれが不完全であったり間違っていることに気づいて正すことができるように、また正されるべきであると考えているのだ。そして回答者になることで、彼らは仲間から有能で知識があると見られるという対価をいくらか得ることになる。
私的な返事を求めることは過程と対価の両方を崩壊させてしまう。個人的に返信するか決めるのは回答者の権限である ―― また回答者が仮にそうしたとしても、通常それは質問があまりに不適格か明らかなため他の人が感心を持たないと思ったからなのだ。
この規則には限定的に例外がある。もしあなたがその質問に対して良く似た回答が大量に返ってきそうだと思うならば、「私にメールを送って下さい。後で回答のサマリーを投稿します。」という魔法の言葉が使える。メーリングリストやニュースグループを概ね似たような投稿の殺到で埋めないようにすることは思いやりのあることだ ―― しかし要約を投稿するという約束は守らなくてはいけない。
決まった回答の無い質問は時間を限りなく無駄にすると考えられがちだ。最も役立つ回答をくれそうな人は（彼ら自身が多くの仕事を引き受けているというだけでも）最も忙しい人でもあるのだ。そのような人達は時間の果てしない浪費が嫌いなので、決まった回答の無い質問が嫌いな傾向がある。
あなたが回答者に何をしてほしいか明確にすると（ポインタを示す、コードを送る、方針を確認してもらう等）、回答がより得られやすくなる。これは彼らの労力を一点に集中させ、回答者があなたを助けるために割かなければならない時間とエネルギーの限度を暗に設定するので良いことなのだ。
専門家の世界を理解するには専門的知識を豊富な資源と考え、回答の時間を不足した資源と考える。あなたが暗につぎ込むことを要求している時間が少なければ少ないほど、非常に優秀で忙しい人から答えが得られやすくなる。
そのためあなたの質問を専門家がさばくのに要求される時間が少なくなるように質問を組み立てるのは有効だ ―― しかしこれは大抵質問を単純にすることと同義ではない。そのため、例えば「Xについての適当な解説のあるポインタを示していただけますか？」というのは通常「Xについて説明していただけますか？」よりもよい質問である。もし動かないコードがあるならば、普通はどこが悪いのか説明してもらうほうが直してもらうよりは良いだろう。
どのような問題を知りたいのか手掛かりを示さずに、あなたの滅茶苦茶なソースコードをデバッグさせようとしてはいけない。何百行かのコードを書いて「動きません」と言っても無視されるだろう。10行程度のコードと「7行目の後で『X』になるはずなのに『Y』になってしまいます」の方が返事を得やすい。
正確に言うと、コードに関するもっとも効果的な方法とはバグを再現する最小限のテストケースを提供することだ。では最小限のテストケースとは何か？ それはバグの実例、つまり問題の動作をさせるのにちょうど十分なコードで、それを超えるものではない。ではどのようにして最小限のテストケースを作るのか？ もし問題の動作を起こすのがどの行または部分なのか分かっているなら、それをコピーして補助的なコードを必要最低限付け加えることで実例が完成する。（補助的なコードとはつまり、コンパイラやインタープリタなどのアプリケーションが処理するのに必要最低限のソースだ。）もし、特に細かい部分に限定できない場合は、そのソースのコピーを作ってから問題に関係しない部分を削っていこう。最小限のテストケースは小さければ小さいほど良い（「分量が正確さではない」節を参照）。
本当に小さな最小限のテストケースを作ることは必ずしも可能とは限らない。しかしそうなるよう努力することはよい訓練になる。自力で問題を解決するのに何が必要なのか学ぶ手助けになる ―― それに、そうでない場合でも、ハッカーはあなたがそうやってみたという姿勢を見たがっている。彼らはより協力的になるだろう。
単にコードを検証してもらいたいなら予めそう言っておき、特に調べて欲しい個所とその理由を必ず述べること。
ハッカーは宿題の問題であることを見抜くのが得意だ。私達のほとんどはそれを自分でやってきたのだから。それらの問題はあなたが解いて、その経験から学ぶためのものである。ヒントを求めるのは構わないが、完全な解答を求めてはいけない。
もし宿題の問題を投稿してしまったのではないかと思い、しかしいずれにせよ解決できないならば、ユーザーグループのフォーラムか（最後の手段として）「ユーザー向け」リスト／フォーラムに投稿してみよう。ハッカーはそれを見抜くが、技術のあるユーザーは少なくともヒントをくれるかもしれない。
あなたのお願いを「誰か助けてくださいますか？」や「何か答えがありますか？」のような意味のない問い掛けで終える誘惑は我慢しよう。第一に、もしあなたが問題の説明を多少なりとも有能に書き終えたなら、そのような付け加えはせいぜい余計なだけだ。第二に、余計なものなのでハッカーはうるさく感じる ―― そして論理的に申し分の無い、しかし軽蔑的な答え「はい、助けてもらえるでしょう。」や「いいえ、誰も助けてくれませんよ。」を返すかもしれない。
一般的にはい・いいえの質問ははい・いいえの回答が欲しくないかぎり避けたほうがいいだろう。
それはあなたの問題であり、私達の問題ではない。急ぐことを主張するのは逆効果になるだろう。大部分のハッカーはそのようなメッセージを失礼な、即座に特別な注意引くための自分勝手な策として単に削除する。さらに、「至急」という単語（そして注意を引くために件名で行うその他の似たような試み）は迷惑メールフィルタに引っかかりやすい ―― あなたが読んでほしかった人達はメールに気づきさえしないかもしれない。
いくらか例外はある。もしあなたがそのプログラムをどこか注目を浴びる場所で使っていて、あなたがハッカーを興奮させる人物ならば、そのことに触れる価値はあるかもしれない。そんなとき、もし期限が迫っていてそのことを礼儀正しく持ち出すなら、興味をもってもらい素早く答えてくれるかもしれない。
しかしこれを実行するのは危険である。なぜならハッカーが何に興奮するかという基準はおそらくあなたのものとは異なるからだ。例えば国際宇宙ステーションから投稿するのならばその資格があるが、良い気分にさせる慈善運動や政治運動のためというのは間違いなく駄目だ。実際「【緊急】もふもふの赤ちゃんアザラシを救って！」という投稿をすることはもふもふの赤ちゃんアザラシの保護が大事だと考えているハッカーからさえも、必ず避けられるか非難されるだろう。
もしこれが不思議に思えるならば、何かを投稿する前にこのHow Toを理解するまで繰り返し読むように。
礼儀正しく。「Please（お願いします）」や「Thanks for your attention（ご覧いただきありがとうございました）」、「Thanks for your consideration（よろしくお願いします）」と書こう。あなたを助けようと無償で時間を掛けてくれる人に感謝していることをはっきりとさせる。
正直なところ、これは正しい文法で明確・正確かつ記述的にする程は重要でない（そしてそれに代えることはできない）。ハッカーは洗練された曖昧な文より、いくぶんぞんざいでも技術的にはっきりしたバグレポートを喜ぶ。（もしこれに戸惑うのならば、私達は質問をそれが何を教えてくれるかで評価することを思い出してほしい。）
しかし技術的な準備ができたならば、礼儀正しくすることで有用な答えが返ってくる可能性を高くできる。
（このHow Toに対してベテランハッカー達から唯一受けた重大な反論として、前出の勧めに対する敬意と共に「Thanks in advance」は使うべきではないと指摘されたことに言及するべきだろう。これはそれ以降お礼を言わないということを述べていると感じる人もハッカーの中にはいる。私達は「Thanks in advance」と最初に書いた上で回答者には後でお礼を言うか、別の方法、例えば「Thanks for your attention」や「Thanks for your consideration」と書くことで礼儀を尽くすことを勧める。）
問題が解決したらあなたを助けてくれた人全員に一筆書いて、それがどうなったかを知らせもう一度お礼を言おう。もしその問題がメーリングリストやニュースグループで一般的な関心を引いたら、そこに返信するのが適当である。
返信は元の質問のスレッドに対して、「解決」等の明確な印を付けるのが好ましい。流れの速いメーリングリストにおいて回答者になりそうな人が「問題X」のスレッドが「問題X - 解決しました」で終わっているのを見ればスレッドを読む時間さえも（問題Xに興味を持たない場合は）無駄にせずにすみ、そのため他の問題を解決するためにその時間を使うことができる。
あなたの返信は長く複雑である必要はない。簡単な「どうも ―― ネットワークケーブルが切れていました！ 皆さんありがとうございました。 - Bill」でもなにもないよりもマシだ。それどころか、解決策に実際の技術的な深みがない限りは、長い学術論文よりも簡潔なサマリーのほうが良いだろう。何をしたら問題が解決したかを書くように。しかし一連のトラブルシューティング全体を再現する必要はない。
いくらか高度な問題には、トラブルシューティングの履歴を投稿することが適切である。問題の最終的な症状を説明し、なにが解決策になったか、そしてその後に回避可能な袋小路を示す。袋小路は正しい解決策や他のサマリー要素の後に続けるべきであり、返信を推理小説に仕立てるべきではない。あなたを助けてくれた人達の名前を挙げれば彼らと親しくなるだろう。
この種の返信は礼儀正しく有益である上、メーリングリスト・ニュースグループ・フォーラムのアーカイブを検索している人があなたがどういう方法で解決したかを知らせるのに役立ち、従って彼らの助けになるかもしれない。
最後に、この種の返信は少なからず手伝ってくれた人達全員に問題が終わったことの満足感を与えることができる。あなた自身が技術者やハッカーではなかったら、この感覚があなたが助けを求めた達人や専門家達にとって大変に重要だということを信用してほしい。問題という物語が未解決の無へと帰していくのは苛立たしいことで、ハッカーはそれらが解決するのを見たくてうずうずしている。その衝動を解決してあげることは、次に質問をするときに大変役に立つだろう。
将来他の人があなたと同じ問題を持たないようにするにはどうすれば良いか考えよう。ドキュメントやFAQが助けになるか自問してみて、なりそうならばそのパッチを管理者に送る。
ハッカーの間では、この種の良い返信の作法は型にはまった礼儀よりも実は大事なことなのだ。それによってあなたが他の人達とうまくやっているという評判を得ることができる。それは実に貴重な財産になりうるだろう。
古くからの神聖な流儀がひとつある。もし「マニュアル嫁(RTFM)」と書いてある返信を受け取ったら、送信者はあなたがマニュアルを読んでおくべきだと思っている。それは大抵間違いなく正しいのでマニュアルを読もう。
マニュアル嫁には弟がいる。もし「ググれ(STFW)」と書いてある返信を受け取ったら、送信者はあなたがウェブを検索しておくべきだと思っている。それは大抵間違いなく正しいのでウェブを検索しよう。（より穏やかな返信では「Googleで見つかります」となる。）
ウェブフォーラムではフォーラムのアーカイブを検索するように言われるかもしれない。それどころか、誰かが以前その問題を解決した時のスレッドのポインタを示してくれるかもしれない。しかしこの予想を当てにしてはいけない。聞く前にまず自分でアーカイブを検索しよう。
検索しろと言う人は多くの場合、あなたの必要としている情報が載ったマニュアルやウェブページを開いている。そしてそれを見ながらタイプしているのだ。これらの返信は(a)その情報は見つけるのが簡単であることと、(b)自分で探せば単にそれを教えてもらうよりもより多くの情報を学べると送信者が考えていることを意味する。
腹を立てるべきではない。ハッカーの基準では、回答者はあなたを無視しないことである種のおおざっぱな敬意を表しているのだ。あなたは代わりにその祖母のような優しさをありがたく思うべきなのだ。
もし回答がわからないときも、すぐに説明を求める返信をしてはいけない。回答を理解するために前と同じツールを使い、元の質問（マニュアル、FAQ、ウェブ、詳しい友人）に答えようとしてみよう。もしそれでも説明が必要ならば、あなたの学んだことを提示しよう。
例えば、私があなたに「zentryが詰まっているようです。クリアすればいいでしょう。」と教えたとする。その場合、悪い返信の質問は：「zentryって何でしょうか？」であり、良い返信の質問は：「man pageを読みましたがzentryは-zと-pオプションでしか説明されていませんでした。どちらもzentryのクリアについては書かれていません。このどちらかでしょうか、それとも私が何か見逃しているのでしょうか？」となる。
ハッカーの世界で乱暴な表現に見えるものは大概、怒らせるためのものではない。問題の解決により感心のある人達にとって、むしろそれは他人の心を暖かく曖昧にさせるよりも自然な直接的コミュニケーション法なのだ。
無礼という気がしても冷静に対処しようとすること。もし誰かが本当にそう振る舞っているならば、リストやニュースグループ、フォーラムの古参の参加者がその人を注意するだろう。もしそうならずにあなたが腹を立てると、その人物の行為はハッカーコミュニティの規範の範囲内であり、あなたに責任があると考えられてしまうだろう。それにより必要な情報や手助けを得られる可能性が減ってしまうのだ。
その一方で、いわれの無い失礼な目にあうことも時にはあるかもしれない。前出の逆として、真の無礼者を酷評し、鋭い言葉のナイフで徹底的に抉る態度も容認できる。しかしそうする前に基づく根拠を確固たるものにしよう。失礼な言葉を正す事は無益な罵り合いを始めてしまう事と紙一重で、ハッカー自身うっかりそうしてしまうこともしばしばあるのだ。初心者や門外漢だと、それを避けられる可能性は低くなる。娯楽よりも情報を求めるならば、この賭けをせずにキーボードから手を放していたほうが懸命である。
（一部の人は多くのハッカーが軽度の自閉症やアスペルガー症候群であり、実際に「正常な」人間社会の交流を行うための脳回路が欠落していると主張している。これは真実かもしれないし、そうでないかもしれない。もしあなた自身がハッカーではないならば、私達の脳に障害があると考えることでその奇行とうまく付きあう助けになるかもしれない。それは結構。私達はそれが何であれ現状が好きなので気にしないし、臨床的分類には概して健全な懐疑論を持っている。）
次の節では異なる問題、あなたが失礼をしでかしたときに見られる種類の「不作法」について論じる。
たぶんあなたはハッカーコミュニティで数回 ―― この記事が述べているかそれに似た様な ―― 間違った事をするだろう。そしておそらくあなたは様々な脱線と共にどのような行動をしたかを正確に語られるのだ。人前で。
そうなったときにとる最も悪い行動は、その体験について愚痴を言うことだ。言葉の暴力を受けたと主張したり、謝罪を要求したり、絶叫する、息を殺す、訴訟を起こすと脅す、相手の勤務先に文句を言う、便座を上げたままにする等々。その代わりにあなたがするべきこととは：
乗り越えよう。それは正常なこと、それどころか、健全で適切なことなのだ。
社会の規範はそれ自体ではなくそれを積極的に適用する目に見える普通の人達が維持する。批判は全て個人的なメールで伝えるべきだと愚痴を言わないでほしい。そういうものではない。また誰かがあなたの主張の一つが間違っていると意見したときに個人的に侮辱されたと、もしくは彼とは意見が違うと言い張ることが有効でもない。それは敗者の態度である。
以前、少々見当違いの礼儀を徹底し、参加者が他の投稿に対してあら探しをすることを禁止し、「ユーザーを助けたくないならば何も投稿しないで下さい」と指示しているハッカーのフォーラムがいくつかあった。しかし精通した参加者が他へ移ってしまった結果、意味のない雑談ばかりになり、技術的フォーラムとして用をなさないものに成り下がってしまった。
（前出のような）不自然な「友好」か有用。どちらかがいいか。
ハッカーが、あなたがの行動が間違っており二度とそうしないように言ったときは（それがどんなに荒々しくても）、彼は(1)あなたと(2)彼のコミュニティを心配して行動していることを心に留めておいてほしい。あなたを無視して生活から締め出す方が余程簡単なのだ。どうしても感謝できないならば、少なくとも品位を持って、愚痴らず、そしてあなたが演劇並に敏感な心と、権利があるという妄想を持つ新参者だからというだけで、脆い人形のように扱われることを期待しないようにしよう。
時には誰かが、あなたが何も失敗していない（あるいは唯一その人の頭の中以外では）にも関わらずあなたを個人的に攻撃したり、明確な理由なく非難したりするだろう。その時に不平を言うことは完全に間違いである。
このような罵倒をするフレーマー達は根拠無く自分を専門家だと思い込んでいるアホウか、あなたがヘマをするか試している自称心理学者なのだ。他の読者は彼らを無視するか、自分で対処する方法を見つける。フレーマーの行いのツケは彼ら自身にまわる。それをあなたが心配する必要はない。
またフレーム合戦に身を投じようとしないこと。ほとんどのフレームは無視するのが一番だ ―― 本当にフレームなのか、あなたの失敗に対する示唆でも、あなたの質問に対する巧妙に暗号化された答え（これもあり得る）でもないと確認した後で。
愚かな質問、ハッカーが答えない質問を挙げる。
A:私だったらとっくに見つけてるよ馬鹿。ウェブの検索結果から。全く、まだGoogleの使い方を知らない奴がいるのか。
A:もしあなたがYをしたいのならば、適切でないかもしれない方法Xを前提とするべきではない。この形の質問は大抵、Xについて無知であるだけではなく解決すべきYという問題についてもはっきりしておらず、固有な状況の細部に固執していることを示している。一般にこのような人達は彼らが問題をよりうまく定義するまで無視するのが得策である。
A:この質問ができるならばマニュアルを読んで（RTFM）自分で解決できる。
A:やってみてほしい。そうすれば(a)答えが判るし(b)私の時間を無駄にしない。
A:これは質問ではない。私には「あなたの本当の質問を探るための20の質問」にも興味はない ―― もっとマシなやることがある。このような質問を見た時、私の反応は通常以下のどれかである。
他に何か付け加えることはありますか？
ああ、それはお気の毒です。直せるといいですね。
で、それが私に一体何の関係があると？
A:ええ。Microsoftは投げ捨ててLinuxやBSDのようなオープンソースのOSをインストールするように。
注：もしプログラムが公式にWindows版を用意しているか、Windowsマシンと共に動作する（つまりSamba）ならば、Windowsマシンに関する質問をすることができる。もっとも問題がプログラムではなくWindowsにあるという返事に驚かないように。Windowsはとても不安定なのでそういう事がよくあるのだ。
A:あなたが数百数千の人々に使われているシステムコールやライブラリの明らかな欠陥を見つけた最初の人物である可能性もあるが、それよりもあなたの完全な見当違いである可能性が高いだろう。並外れた主張には並外れた証拠が必要になる。こういった主張をするときは、明確かつ徹底的な欠陥の証拠資料で裏付けなくてはならない。
A:いいえ。解決するにはあなたのマシンを直接操作できる必要があるだろう。地元のLinuxユーザーグループに助けを求めるように。
注：Linuxのインストールに関する質問は、個別のディストリビューションのフォーラムやメーリングリストに対するもので、問題がそのディストリビューションに関係しているならば適当だろう。地元のLinuxユーザーグループでも同じである。その場合、必ず不具合の正確な詳細を述べる。もっとも最初に「linux」と全ての疑わしいハードウェアをキーワードに入念に検索してほしい。
A:あなたはそういうことをしたがる犯罪者であり、ハッカーに助けを求める低能だ。
最後に賢い質問のしかたを例を挙げて説明する。同じ問題に対する一対の質問で、一つは悪く一つは良いものである。
この質問は単に「ウェブを検索しなさい（ググれ）」という答えを請うものだ。
こちらは既にググって、また質問者が実際の問題を把握しているように読める。
質問者は誰か他の人がしくじったと決めてかかっている。傲慢なろくでなしだ。
質問者は環境を明記し、FAQを読み、エラー内容を示し、問題が誰か他の人のせいとは決めつけていない。この質問者はいくらか注意を引いてもらうに値する。
どこかのハッカーが「ああ、げっぷをさせたりおむつの交換も必要かい？」と打った後でデリートキーを叩くことだろう。
一方こちらは回答に値するように見える。答えが天から降ってくるのを待つ代わりに問題解決の思考力を示したのだ。
最後の質問の「答えを教えて下さい」と「問題を把握するために更にどのようなことを調べるべきか助言を下さい」との明確な違いに注意してほしい。
実のところ、最後の質問の形式は2001年8月にlinux-kernelメーリングリスト（lkml）へ投稿された質問を元にしている。私（Eric）がその時の質問者だった。Tyan S2462マザーボードに不可解なロックアップが起こったが、リストの参加者が問題の解決に重要な情報を提供してくれた。
私の場合のように質問することは人々に考えさせる題材を与える。彼らが関わることを容易に、そして魅力的にしたのだ。私は仲間の技量に対する尊敬を表し、仲間として助言を求めた。また、私が既に陥った袋小路を伝えることで彼らの時間の価値を慮っていることも示した。
その後皆に感謝し、解決までの過程がいかにスムーズに進んだか述べると、あるlkmlのメンバーは、うまく行ったのは私がリストで有名だからではなく適切な形で質問をしたからだろうと言った。
ハッカーはいくつかの面でとても冷酷な実力主義だ。彼の言ったことが正しいこと、またたかりのように振る舞っていたならば私が誰であろうと非難されるか無視されていた事は確かである。他の人のため、事の顛末を手引きとしてまとめてはどうかという彼の提案がこのガイドを書くことに繋がった。
もし回答が得られなくても、私達が助けになれないと思ったからだと考えないように。時には質問したグループのメンバーが実際に答えを知らないかもしれない。確かに返答がないことと無視されることの違いを外側から見分けるのは難しいが、それらは同じではない。
一般に、質問を再投稿するのは悪い考えだ。無駄に邪魔なものと見なされてしまうだろう。辛抱強く。質問に答えられる人は違う時間帯に居て、寝ているのかもしれない。あるいはそもそも質問の形式が不適切だったからかもしれない。
他にもあなたの頼ることのできる、そして大抵はより初心者の要求に適った情報源がある。
そのソフトウェアが大好きなオンラインの、または地元のユーザグループが（例え彼らがソフトウェアを書いたことがないかもしれないとしても）たくさんある。これらのグループは多くの場合お互いや新しいユーザーを助けられるように設けられている。
また助けてくれる商業的な会社が大小数多くある。少しの助けのためにお金を支払うという考えに狼狽しないでほしい。もし車のエンジンのヘッドガスケットが吹き抜けたら、おそらく修理工場に持っていき直してもらうために対価を支払うのだから。たとえソフトウェアが無料でも、サポートまで常に無料であることは期待できない。
Linuxのような人気のあるソフトウェアは開発者1人に対し最低10,000人のユーザーがいる。ひとりの人間が10,000人のサポート依頼を処理するのは全く不可能だ。サポートにお金を払うことになっても、ソフトウェアまで購入しなくてはならなかった場合よりも相当小額であること（そしてクローズドソースのソフトウェアのサポートは通常、オープンソースのソフトウェアよりもより高額で役立ちにくいこと）を思い出してほしい。
寛大に。質問者は問題に関係したストレスによって実際にそうではない時でさえも、不作法な馬鹿に思えることがある。
初犯者には直接返信すること。純粋に間違えた人に公で恥をかかせる必要はない。本当の初心者はアーカイブの検索方法や、FAQがどこにあるか、どこに投稿するものかを知らなかったりする。
確かではないならそう言うように。間違っているのに信頼できそうに聞こえる回答は最悪なものだ。ただ専門家のように見られるのが楽しいからと間違った道を示さないように。謙虚かつ正直に、質問者とあなたの仲間双方に良い手本を示してほしい。
助けられないのなら邪魔をしないこと。ユーザーの環境を駄目にするような手順を冗談で書かないこと ―― 正しい手順だと勘違いしてしまう人がいるかもしれない。
より詳しい情報を引きだすために完璧な質問をしよう。これを上手に行えば質問者は何かを学ぶ ―― もしかしたらあなたも。悪い質問を良いものにしようとすること。私達は皆最初は初心者だったことを忘れないでほしい。
誰かに回答するときにマニュアル嫁と呟くだけでは怠け者と見なされることもあるが、ドキュメントへのポインタは（それがGoogle検索するキーワードの提案だとしても）それよりよいものである。
もし質問に少しでも答えるならば、価値のあるものにしよう。誰かが間違ったツールや方法を取っているときに下手な回避方法を提案してはいけない。質問を再構成して良いツールを提案しよう。
実際の質問に答えよう。もし質問者が調査を徹底していて、質問に「X、Y、Z、A、BとCも試したけれども駄目でした」と書いているならば、「AかBを試して」と答えたり、「X、Y、Z、A、BかCを試す」と書いてあるURLを示すのはまるきり役に立たない。
あなたのコミュニティがその質問から学ぶ手助けをしよう。良い質問に答えるときは「関連するドキュメントやFAQをどう変更したらだれもこの質問に答える必要がなくなるか」と自問してみる。そしてドキュメントのパッチを管理者に送ろう。
質問に答えるために調査を行ったら、その事を元から知っていたように書くのではなくあなたの技術を説明してほしい。ある良い質問に答えることはお腹を空かせた人に一食与えるようなものだが、調査技術を例をもって教えることは生涯にわたり食物を育てるよう教育するようなものなのだ。
パソコン・Unix・インターネットの仕組みの基礎が知りたい場合はThe Unix and Internet Fundamentals HOWTOを参照のこと。
ソフトウェアを公開したりパッチを書く時はSoftware Release Practice HOWTOのガイドラインに従うようにしてほしい。
Evelyn Mitchell氏にはいくつか愚かな質問の例を送っていただき、また「良い回答のしかた」の節の着想を頂いた。Mikhail Ramendik氏からは改善にとりわけ貴重な助言を頂いた。