転載声明
以下の内容はすべてAsunaによりHow-To-Ask-Questions-The-Smart-Wayから転載したものです。
中国大陸内でのアクセスを高速化することのみを目的としており、権利侵害があればご連絡いただければ削除します！
質問の作法
How To Ask Questions The Smart Way
Copyright © 2001,2006,2014 Eric S. Raymond, Rick Moen
本ガイドの英語版の著作権は Eric S. Raymond, Rick Moen に帰属します。
原文 URL：http://www.catb.org/~esr/faqs/smart-questions.html
Copyleft 2001 by D.H.Grand(nOBODY/Ginux), 2010 by Gasolin, 2015 by Ryan Wu
本中国語ガイドは、原文 3.10 版および 2010 年にGasolinが翻訳した版を基にした最新の翻訳です。
翻訳上の問題をご指摘いただける方は、发 issueしていただくか、あるいは直接发 pull request までご連絡ください。
本文には別途繁體中文版もあります。
原文版本历史
声明
多くのプロジェクトが、自らのウェブサイトのヘルプドキュメントから本ガイドにリンクを張っています。これは素晴らしいことであり、まさに私たちが意図している用途です。しかし、もしあなたがそのプロジェクトの管理者で、本ガイドへのハイパーリンクを作成しようとしているなら、リンクの近くの目立つ場所に次のように明記してください：
本ガイドは、このプロジェクトに対する実際のサポートを提供するものではありません！
私たちは、上記の声明を欠いたことによる苦痛を身をもって味わってきました。すなわち、このガイドを公開している以上、世界中のあらゆる技術的な問題を解決する責任があると勘違いした愚か者たちに、絶え間なく付きまとわれるのです。
もしあなたが何らかの助けを求めて本ガイドを読み、それでもなお本ガイドの著者から直接助けを得られると思いながら去っていくのなら、あなたは先に述べた愚か者の一人です。私たちに質問しないでください。無視するだけです。本ガイドで私たちが教えたいのは、あなたが遭遇しているソフトウェアやハードウェアの問題を本当に理解している人たちから支援を得る方法であり、その 99% は私たちではありません。本ガイドの著者の一人が、あなたが直面している問題の分野の専門家であると確信できない限り、私たちを煩わせないでください。そうすれば、みんな少しは幸せになれるのです。
はじめに
黑客の世界では、技術的な質問を投げかけたとき、最終的に有用な回答を得られるかどうかは、しばしばあなたの質問の仕方と、その後の問い詰め方にかかっています。本ガイドは、あなたが満足のいく答えを得るために、正しく質問する方法を教えます。
現在、オープンソース（Open Source）ソフトウェアはかなり普及しており、あなたはたいてい、他のより経験豊富なユーザーからハッカーと同等に優れた答えを得ることができます。これは良いことです。ハッカーに比べ、ユーザーたちは初心者がよくぶつかる問題に対してより寛容な傾向があります。それでも、私たちがここで推奨するやり方でこうした経験豊富なユーザーに接することは、たいてい彼らから有用な答えを引き出すための最も効果的な方法です。
まず理解すべきは、ハッカーたちは挑戦的な問題、あるいは自分たちの思考を刺激する良い問題を好むということです。もしそうでなければ、私たちはあなたが質問すべき相手にはならないでしょう。もしあなたが、何度も噛みしめて味わう価値のある良い問題を私たちに与えてくれたなら、私たちは自然とあなたに感謝するでしょう。良い問題は励みであり、贈り物です。良い問題は私たちの理解力を高め、そしてたいてい、私たちがこれまで気づかなかった、あるいは考えたこともなかった問題を明らかにしてくれます。ハッカーにとって、「良い問題だ！」は心からの大いなる賛辞なのです。
それでも、ハッカーたちは単純な問題に対して軽蔑的あるいは傲慢に接するという悪評があり、それが時として私たちが初心者や無知な人々に対して敵意を持っているように見せるのですが、実際はそうではありません。
私たちは、考えようとしない人、あるいは質問する前にやるべきことをやらない人たちを軽蔑していることを隠しません。そういう人たちは時間の浪費者です —— 彼らはただ奪うことだけを望み、決して与えず、私たちがより面白い問題や、より答える価値のある人に使えるはずの時間を消耗させます。私たちはそういう人たちを 失败者（撸瑟） と呼んでいます（歴史的な理由から、時に lusers と綴ることもあります）。
私たちは、多くの人が単に私たちの書いたソフトウェアを使いたいだけで、技術的な詳細を学ぶことには興味がないのだと理解しています。大多数の人にとって、コンピュータはただの道具であり、目的を達成するための手段にすぎません。彼らには自分たちの生活があり、もっと大切な用事があるのです。私たちはそれを理解しており、誰もが私たちを夢中にさせるこうした技術的な問題に興味を持つことを期待したことはありません。それでも、私たちの回答のスタイルは、本当にこれに興味を持ち、進んで問題解決に参加しようとする人たちに向けたものであり、この点は変わりませんし、変わるべきでもありません。もしこれすら変わってしまったら、私たちは自分たちが最も得意とすることを行う効率を下げていることになるのです。
私たちは（大いに）自発的に、忙しい生活の中から時間を割いて疑問に答えており、しばしば質問に埋もれてしまいます。だからこそ私たちは、いくつかの話題を容赦なく濾過し、特に失敗者のように見える連中を切り捨てて、赢家（winner）な問題に答えるために時間をより効率的に使おうとするのです。
もしあなたが私たちの態度を嫌悪し、高慢だ、傲慢すぎると思うなら、どうか立場を置き換えて考えてみてください。私たちはあなたに私たちへ屈服することを求めているのではありません —— 実際、私たちの大多数はあなたと対等に交流することを非常に喜んでおり、あなたが基本的な要件を満たすために少しばかりの努力を払ってくれさえすれば、私たちはあなたを私たちの文化へ喜んで迎え入れます。しかし、自分自身を助けようとしない人を助けるのは非効率なのです。無知であることは構いませんが、愚か者のふりをするのは許されません。
ですから、私たちの注意を引くために技術的に熟練している必要はありませんが、あなたを熟練へと導く資質 —— 機敏さ、考えを持つこと、観察眼、進んで問題解決に参加しようとする姿勢 —— を示す必要があります。もしあなたがこれらの、あなたを他の人と区別するようなことができないのなら、私たちは、ハッカー個人に無償で助けを求めるのではなく、少しお金を払って商業会社と技術サポート契約を結ぶことを勧めます。
（これは同じ記事の全 12 部のうちの第 1 部です。）
もし私たちに助けを求めることにしたなら、もちろん自分が失敗者と見なされたいとは思わないだろうし、まして失敗者の仲間入りなどしたくはないはずだ。すぐに素早く有効な答えを得る最良の方法は、勝ち組のように質問することだ——賢く、自信があり、問題解決の筋道を持ち、ただ時折、特定の問題について少しだけ助けが必要なだけ、という姿勢で。
（本ガイドへの改善意見を歓迎します。提案は [email protected] または [email protected] までお送りください。ただし、本文は 网络礼节 の汎用ガイドではないことにご注意を。また、技術フォーラムで有用な答えを得る助けにならない提案は、たいていお断りしています）。
質問する前に
メール、ニュースグループ、あるいはチャットルームで技術的な質問をしようと準備する前に、まず次のことを済ませておいてほしい：
- 質問しようとしているフォーラムの過去記事で答えを検索してみる。
- ネットで検索して答えを探してみる。
- マニュアルを読んで答えを探してみる。
- よくある質問ファイル（FAQ）を読んで答えを探してみる。
- 自分で調べたり試したりして答えを探してみる。
- 身近な頼れる友人に聞いて答えを探してみる。
- あなたがプログラマなら、ソースコードを読んで答えを探してみる。
質問をするときは、まず上記の努力をすでに行ったことを示してほしい。そうすれば、あなたが労せずして他人の時間を浪費する質問者ではないと分かってもらいやすくなる。もし、それらの努力の過程で学んだことまで一緒に示せれば、なお良い。私たちは、答えから学び取れる素振りを見せる人の質問にこそ、進んで答えたくなるからだ。
何らかの工夫を凝らすのもよい。たとえば、遭遇した各種のエラーメッセージをまず Google で検索してみる（Google 论坛 とウェブページを検索する）。こうすれば、問題を解決できるファイルやメーリングリストの手がかりに、そのまま行き当たることも少なくない。たとえ結果が出なくても、メーリングリストやニュースグループで助けを求める際に 我在 Google 中搜过下列句子但没有找到什么有用的东西 の一言を添えておくのは良いことだ。検索エンジンがどんな助けを提供できないかが分かるだけでも意味がある。そうすること（検索した文字列を添えること）で、同じ問題に遭遇した他の人も検索エンジンを通じてあなたの質問にたどり着けるようになる。
焦らないこと。数秒の Google 検索で複雑な問題が片付くなどと期待してはいけない。専門家に助けを求める前に、もう一度 FAQ を読み、気を楽にして楽な姿勢で座り、少し時間をかけてその問題を考えてみよう。信じてほしい、彼らはあなたの質問から、あなたがどれだけ読み、どれだけ考えたかを見抜ける。準備を整えて臨めば、答えを得られる可能性はより高くなる。最初の検索で答えが見つからなかった（あるいは多すぎた）というだけで、すべての問いを一度に投げつけてはいけない。
質問を準備し、その問題をよくよく考え抜いてからにしよう。いい加減な質問は、いい加減な答えしか返ってこないか、あるいは何の答えも得られないからだ。問題を解決するために助けを求める前にどれだけ努力したかを示せれば示すほど、実質的な助けを得られる可能性は高まる。
間違った質問をしないよう気をつけよう。もしあなたの質問が誤った前提に基づいていると、通りすがりのハッカー（J. Random Hacker）は、心の中で 蠢问题… と思いながら、無意味な字義どおりの説明で返してくるだろう。あなたが質問への回答（君が得たかった答えではなく）から教訓を汲み取ることを期待しながら。
答えを得る資格があるなどと決して思わないこと。ないのだ。あなたにはない。なにしろ、あなたはこのサービスに対していかなる対価も払っていないのだから。あなたは自分で答えを勝ち取ることになる——中身のある、面白い、思考を刺激する問いによって。コミュニティの経験に寄与しうる可能性のある問いによって。ただ受動的に他人から知識を搾り取るのではない。
一方で、答えを探す過程で何かをしようとする意思を示すことは、非常に良い出発点だ。谁能给点提示？、我的这个例子里缺了什么？、そして 我应该检查什么地方 は、请把我需要的确切的过程贴出来 よりも答えを得やすい。正しい方向を誰かが示してくれさえすれば、それを成し遂げる能力と決意があることを示せているからだ。
質問するとき
質問するフォーラムを慎重に選ぶ
質問する場を慎重に選ぼう。もし次のようなことをすれば、あなたは無視されるか、失敗者と見なされる可能性が高い：
- 話題に合わないフォーラムに自分の質問を投稿する。
- 高度な技術的議論を扱うフォーラムに、ごく初歩的な質問を投稿する。あるいはその逆。
- あまりに多くの異なるニュースグループに同じ質問を繰り返し転載する（クロスポスト）。
- 知人でもなく、あなたの問題を解決する義務もない相手に個人的なメールを送る。
ハッカーたちは、場違いな質問をふるい落とすことで、自分たちのコミュニケーションの場が無関係なもので埋め尽くされないよう守っている。あなたも、そんなことが自分に降りかかってほしくはないだろう。
だから、第一歩は正しいフォーラムを見つけることだ。繰り返すが、Google やその他の検索エンジンはあなたの味方であり、遭遇したソフトウェアやハードウェアの問題に最も関係の深いサイトを見つけるのに使うべきだ。たいていそこには FAQ、メーリングリスト、関連する説明文書へのリンクがある。もしあなたの努力（FAQ の読解を含む）が実らなかったとしても、サイトにはバグ報告（Bug-reporting）の手順やリンクが用意されているかもしれない。そうなら、そこへたどってみよう。
見知らぬ相手やフォーラムにメールを送るのは、最もリスクの高い行為かもしれない。たとえば、豊富な内容のウェブページの作者が自分の無料の顧問役を買って出てくれるなどと想定してはいけない。自分の質問が喜んで受け入れられるかどうかを楽観的に見積もりすぎないこと——確信が持てないなら、別の場所に送るか、いっそ送らないことだ。
フォーラム、ニュースグループ、メーリングリストを選ぶときは、その名前をあまり信じないこと。まず FAQ や利用規約に目を通し、あなたの質問が的外れでないかを確かめよう。投稿前に既存の話題をざっと眺めれば、そこでの文化がつかめる。実のところ、事前にニュースグループやメーリングリストの履歴で自分の問題に関連するキーワードを検索するのは、極めて良い考えだ。もしかすると、それだけで答えが見つかるかもしれない。たとえ見つからなくても、より良い質問をまとめる助けになる。
（これは同じ記事の全12回中の第2回です。）
助けを求める渠道を機関銃のように一斉「掃射」するのはやめましょう。それは大声で叫ぶのと同じで、相手を不快にさせます。一つずつ順番に当たりましょう。
自分の話題をはっきりさせましょう！ 最も典型的な間違いの一つは、クロスプラットフォームの移植性を目指すある言語やスイート、ツールのフォーラムで、Unix や Windows の OS 上のプログラムのインターフェースについて質問してしまうことです。なぜこれが大間違いなのか分からないなら、その違いをはっきりさせるまでは何も聞かないほうがよいでしょう。
一般に、慎重に選んだ公開フォーラムで質問するほうが、非公開のフォーラムで同じ質問をするよりも役に立つ回答を得やすいものです。これにはいくつかの理由があります。一つは潜在的な回答者の数、もう一つは観客の数です。ハッカーは、多くの人の助けになる質問に答えることを好みます。
理解できることですが、熟練したハッカーや人気ソフトウェアの作者たちは、あまりにも多くの宛先違いのメッセージを受け取っています。ラクダの背を折る最後の一本の藁のように、あなたの参加が事態を極端な方向へ押しやる可能性もあります——すでに何度か、人気ソフトウェアの作者たちが、自分の私用メールボックスに押し寄せる耐え難いほどの無用なメールのせいでサポートをやめてしまっています。
Stack Overflow
検索し、それから Stack Exchange で質問しましょう。
ここ数年で、Stack Exchange コミュニティは技術やその他の質問に答える主要な渠道となりました。とりわけオープンソースのプロジェクトに関するものがそうです。
Google のインデックスは即時なので、Stack Exchange を見る前にまず Google で検索しましょう。誰かがすでに似た質問をしている可能性は高く、Stack Exchange の各サイトが検索結果の上位に現れることもよくあります。Google で何の答えも見つからなければ、特定の関連テーマのサイトを探しましょう。タグで検索すれば、検索結果をさらに絞り込めます。
それでも自分の問題に役立つ内容がまったく見つからない場合は、最も関連するサイトに質問を投稿してください。質問するときは書式設定ツールを上手に使い、とりわけコードに書式を付けること、そして関連するタグ（特にプログラミング言語、OS、ライブラリ／パッケージの名前）を付けることに注意しましょう。誰かがさらに詳しい情報を求めてきたら、返信や回答を投稿するのではなく、自分の投稿を編集して補足してください［訳注：返信や回答を投稿するのではなく！］。ある回答が役に立ったと思ったら、上向きの矢印をクリックして投票しましょう。ある回答が問題の正しい解決策を示しているなら、投票ボタンの下にあるチェックマークをクリックして正解としてマークしましょう。
Stack Exchange は超过一百个网站まで成長しており、以下は最もよく使われるいくつかのサイトです：
- Super User は一般的なコンピュータの問題を尋ねる場所です。あなたの問題がコードやプログラミングとは無関係で、ネットワーク接続のようなものなら、ここへどうぞ。
- Stack Overflow はプログラミングに関する質問をする場所です。
- Server Fault はサーバーやネットワーク管理に関する質問をする場所です。
ウェブサイトと IRC フォーラム
地元のユーザーグループや、あなたが使っている Linux ディストリビューションが、ウェブフォーラムや IRC チャンネルを宣伝し、初心者向けの助けを提供しているかもしれません（英語圏以外の国では、初心者向けフォーラムがメーリングリストであることもよくあります）。こうした場所は質問を始めるのに良いところです。特に、自分が遭遇しているのが比較的単純あるいはありふれた問題かもしれないと感じるときにはなおさらです。広告でスポンサードされた IRC チャンネルは質問を公開で歓迎しており、たいていは即座に応答が得られます。
実際、プログラムの問題が特定の Linux ディストリビューションが提供するバージョンでのみ発生する場合（これはよくあります）、まずそのディストリビューションのフォーラムやメーリングリストで質問し、それからプログラム自体のフォーラムやメーリングリストで質問するのが最善です。（そうしないと）そのプロジェクトのハッカーは「私たちのバージョンを使ってください」とだけ返してくるかもしれません。
どのフォーラムに投稿する前でも、まず検索機能があるか確認しましょう。あれば、問題のいくつかのキーワードで検索してみてください。それで助かるかもしれません。もしこれ以前に一般的なウェブ検索をしていたとしても（そうするべきですが）、フォーラムでもう一度検索してみましょう。検索エンジンがこのフォーラムの全内容をまだインデックスし終えていない可能性があります。
フォーラムや IRC チャンネルを通じてユーザーサポートを提供する傾向は増しており、電子メールは主にプロジェクト開発者間のやり取りのために残されています。ですから、そのプロジェクトに関する助けはまずフォーラムや IRC で求めるのがよいでしょう。
IRC を使うときは、まず長々とした問題の説明を投稿しないことです。これをチャンネルフラッドと呼ぶ人もいます。一文程度の問題説明で会話を始めるのがよいでしょう。
第二段階、プロジェクトのメーリングリストを使う
あるプロジェクトが開発者向けメーリングリストを提供している場合、個々のメンバーではなくリストに質問しましょう。たとえその人があなたの質問に最もよく答えられると確信していてもです。プロジェクトの文書やホームページを調べて、プロジェクトのメーリングリストを見つけ、それを使いましょう。この方法を取るのには、いくつかの良い理由があります：
- 個々の開発者に尋ねる価値があるほど良い質問は、プロジェクトのグループ全体にとっても有益です。逆に、自分の質問がプロジェクトのグループ全体にとってあまりに愚かだと思うなら、それは個々の開発者を煩わせる理由にはなりません。
- リストに質問すれば開発者の負担を分散できます。個々の開発者（特にプロジェクトのリーダー）は忙しすぎてあなたの質問に答えられないかもしれません。
- ほとんどのメーリングリストはアーカイブされ、アーカイブされた内容は検索エンジンにインデックスされます。あなたがリストに質問して解答を得れば、将来ほかの人がウェブ検索であなたの質問と答えを見つけられるので、同じことを再び尋ねずに済みます。
- ある問題がよく尋ねられるものであれば、開発者はその情報を利用して説明文書やソフトウェア自体を改善し、より分かりやすくできます。非公開で質問するだけでは、最もよくある問題の完全な状況を誰も見ることができません。
あるプロジェクトに「ユーザー」向けと「開発者」（または「ハッカー」）向けの両方のメーリングリストやフォーラムがある場合、あなたがソースコードに一切触れないのであれば、「ユーザー」向けのリストやフォーラムで質問してください。開発者リストで歓迎されるなどと勝手に思い込まないこと。彼らの大半は、あなたの質問を開発を妨げるノイズと見なします。
しかし、自分の問題が確かに特別であり、「ユーザー」向けのリストやフォーラムで数日間まったく返信がない場合は、「開発者」向けのリストやフォーラムで尋ねてみてもよいでしょう。投稿する前に、まず数日間こっそり観察して、そこでのやり方を把握しておくことをおすすめします（実際、これはあらゆるプライベートまたはセミプライベートなリストに参加する際に良い心がけです）。
プロジェクトのメーリングリストが見つからず、メンテナーのメールアドレスしか分からない場合は、遠慮なくメールを送ってください。そのような場合でも、（プロジェクトの）メーリングリストが存在しないと決めつけてはいけません。メールの中では、適切なメーリングリストを探したが見つからなかったことを伝え、自分のメールを他人に転送されても構わない旨も述べてください（多くの人は、秘密がなくても、私的なメールは公開されるべきではないと考えています。メールの転送を許可することで、その関係者にあなたのメールを扱う選択肢を与えることになるのです）。
意味があり、明確で説明的なタイトルを使う
メーリングリスト、ニュースグループ、フォーラムでは、およそ 50 文字以内のタイトルが、経験豊富な専門家の注意を引く絶好の機会となります。帮帮忙、跪求、急 などとぐちぐちと書き連ねて（ましてや救命啊！！！！のような反感を買う言葉はなおさらで、そんなタイトルは反射的に無視されます）この機会を無駄にしないでください。自分の苦しさの度合いで我々を動かそうなどと妄想せず、このわずかな空間でごく簡潔な説明の仕方で問題を提示してください。
良いタイトルの例は目标 —— 差异形式の説明で、多くの技術サポート組織がそうしています。目标の部分でどの物、あるいはどのグループに問題があるのかを示し、差异の部分では期待される動作と食い違う点を説明します。
愚かな質問：助けて！私のノートPCの画面が正常に表示されません！
賢い質問：X.org 6.8.1 でマウスポインタが変形する、某社製グラフィックカードの MV1005 チップセット。
さらに賢い質問：X.org 6.8.1 のマウスポインタが、某社製グラフィックカードの MV1005 チップセット環境で - 変形する。
目标 —— 差异形式の説明を書く過程は、問題についての細やかな思考を整理する助けになります。何が影響を受けているのか？ マウスポインタだけなのか、それとも他のグラフィック要素もなのか？ X.org の X 版でのみ発生するのか？ それとも 6.8.1 版だけなのか？ 某社製グラフィックカードのチップセットが原因なのか？ それともその中の MV1005 モデルだけなのか？ ハッカーは一目見ただけで、あなたの環境とあなたが遭遇している問題をたちどころに理解できるのです。
要するに、自分がタイトルだけを表示するアーカイブ済みスレッドの索引で検索しているところを想像してみてください。タイトルが問題をよりよく反映していれば、次に類似の問題を検索する人がこのスレッドに注目でき、同じ質問を再びする必要がなくなります。
返信の中で質問をしたい場合は、内容の見出しを変更して、自分が質問をしていることを示すのを忘れないようにしてください。Re: 测试やRe: 新 bugのように見えるタイトルでは、十分な注目を集めるのは難しいものです。また、一貫性を損なわない範囲で、前文を適切に引用して削っておくと、新たに来た読者に手がかりを残せます。
スレッドについては、返信を直接クリックしてまったく新しいスレッドを始めないでください。それはあなたの読者を制限してしまいます。mutt など一部のメール閲覧ソフトは、ユーザーがスレッドで並べ替えたり、スレッドを折りたたんでメッセージを隠したりできるため、そうしている人はあなたのメッセージを永遠に見ることができません。
タイトルを変えるだけでは不十分です。mutt やその他のメール閲覧ソフトは、スレッドを指定するためにメールのタイトル以外の情報もチェックします。ですから、まったく新しいメールを送るほうがよいのです。
ウェブフォーラムでは、良い質問の仕方が少し異なります。スレッドと特定の情報が緊密に結びついており、通常はスレッドの外から中の内容が見えないため、返信で質問するのは、タイトルを変えるのではなくても許容されます。すべてのフォーラムが返信内での分離したタイトルを許可しているわけではなく、そうしたところで誰も見ないのがほとんどです。とはいえ、返信で質問すること自体が曖昧なやり方です。なぜなら、それはそのタイトルを現在見ている人にしか読まれないからです。ですから、そのスレッドで現在活発に活動している人たちだけに質問したいのでなければ、新しく立てたほうがよいでしょう。
回答しやすいように問題を提示する
请将你的回复发送到……で質問を締めくくると、たいてい回答は得られません。メールクライアントで返信先アドレスを数秒設定するのが面倒だと思うなら、こちらもあなたの問題を考えるのに数秒費やすのが面倒だと思います。あなたのメーラープログラムがそうした設定に対応していないなら、换个好点的。もし OS がそうしたメーラーに対応していないなら、それもまともなものに替えてください。
フォーラムでは、メールでの返信を求めるのは非常に失礼です。ただし、返信内容が比較的センシティブかもしれないと思う場合は別です（何らかの未知の理由で、フォーラム全体ではなくあなただけに答えを知らせたい人がいるかもしれません）。単に誰かがスレッドに返信したときにメールで通知を受け取りたいだけなら、ウェブフォーラムから送信するよう要求すればよいのです。ほとんどすべてのフォーラムが追踪此讨论串、有回复时发送邮件提醒などの機能に対応しています。
明確で正確、的確で文法にかなった言葉遣いをする
経験から分かったことですが、不注意な質問者はたいてい、不注意にプログラムを書き、不注意に考えるものです（間違いありません）。不注意な人の質問に答えるのは割に合いません。我々はむしろ時間を他のことに費やしたいのです。
（これは同じ記事の全 12 回中の第 4 回です。）
正しい綴り、句読点、大文字・小文字の使い分けはとても重要です。一般的に、もしあなたがそれを面倒だと感じ、気にしたくないと思うなら、私たちも面倒だと感じ、あなたの質問を気にしたくはありません。少しだけ余分な労力を割いて言葉を選んでください。堅苦しく正式である必要はありません——実際、ハッカー文化は非公式な表現やスラング、ユーモアを正確に使いこなすことを重視しています。しかし、それはとても正確でなければならず、かつあなたが問題を考え、注意を払っているという兆候がなければなりません。
正しく綴り、句読点と大文字・小文字を使い分けてください。its を it's と混同したり、loose を lose にしたり、discrete を discreet にしたりしないでください。すべて大文字で書かないでください。それは無礼な大声の叫びと見なされます（すべて小文字もましではありません。読みにくいからです。Alan Cox ならそうしてもいいかもしれませんが、あなたは駄目です）。
もっと平たく言えば、もしあなたが半文盲の[译注：小白]のように書くなら、おそらく相手にされません。インスタントメッセージの略語や火星文 も使わないでください。例えば 的 を d と略すと、数文字打つのを惜しむ初心者のように見えます。さらに悪いことに、子供のように落書きするのは間違いなく自滅行為であり、誰も相手にしないことは確実です（せいぜい、あなたに大量の非難と皮肉を浴びせるくらいでしょう）。
母語でない言語のフォーラムで質問する場合、綴りや文法の小さな間違いは許されますが、思考において手を抜いてはいけません（ええ、私たちはたいていその二つを区別できます）。また、返信者の使う言語を知らない限り、英語で書いてください。多忙なハッカーは、自分が読めない言語で書かれたメッセージをそのまま削除してしまうのが普通です。ネット上では英語が共通語であり、英語で書けば、あなたの質問が読まれる前にそのまま削除される可能性を最小限に抑えられます。
英語があなたにとって外国語（セカンドランゲージ）であるなら、潜在的な返信者に言語上の困難があることを伝えるのは良いことです：
[訳注：以下に原文をそのまま添えます]
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.
- もし某言語を話すなら、私にメール／DMを送ってください；
- 私の質問の翻訳を手伝ってくれる人が必要です。
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.
- 私は自分の質問を某言語と英語の両方で書きました。
- もしあなたがどちらか一方の言語だけで答えてくれるなら、その返信をあなたの使う言語に翻訳するのを喜んでお引き受けします。
読みやすく標準的なファイル形式で質問を送る
もしあなたが故意に質問を読みにくくするなら、それはたいてい無視されます。人々はわかりやすい質問を好んで読むので、次のようにしてください：
(This is part 5 of 12 of the same post.)
- HTML ではなくプレーンテキストを使う（关闭 HTML は難しくない）。
- MIME 添付を使うのは通常問題ない。ただし本当に中身がある場合（添付されたソースコードや patch など）に限られ、メールソフトが生成したテンプレート（単なる本文のコピーなど）ではいけない。
- 一行の文が自動折り返しで複数行になるようなメールを送らないこと（部分的な返信が非常に難しくなる）。読者は幅 80 文字の端末でメールを読んでいると想定し、折り返し位置は 80 文字未満に設定するのがよい。
- ただし、特殊なファイル（ログのコピーやセッション記録など）には固定幅を設定しないこと。データはそのまま含めるべきで、返信者が自分と同じものを見ていると確信できるようにする。
- 英語のフォーラムでは、
Quoted-PrintableMIME エンコードでメッセージを送らないこと。このエンコードは非 ASCII 言語を投稿する際に必要な場合があるが、多くのメールソフトは対応していない。改行を処理するとき、テキスト中に散らばる=20記号は見苦しく気が散るうえ、内容の意味を壊すことさえある。 - 絶対に、決して、クローズドな形式で書かれた文書（Microsoft の Word や Excel ファイルなど）をハッカーが読んでくれることを期待してはいけない。ほとんどのハッカーの反応は、玄関先にまだ湯気の立つ豚の糞をぶちまけられたときのあなたの反応と同じだ。たとえ扱えたとしても、そうすることを嫌悪する。
- Windows の PC からメールを送るなら、Microsoft の愚かな
智能引号機能をオフにすること（[オプション] > [校正] > [オートコレクト オプション] で智能引号のチェックを外す）。メール中にゴミ文字がばらまかれるのを防ぐためだ。 - フォーラムでは、
表情符号やHTMLの機能を（提供されている場合）乱用しないこと。絵文字が 1 つ 2 つなら通常問題ないが、派手な色付きテキストはあなたを無能に見せがちだ。絵文字・色・フォントの過剰な使用は、へらへら笑う小娘のように見える。これはたいてい良い考えではない。ただし、あなたが答えではなくセックスに興味がある場合を除く。
GUI のメールソフト（Microsoft の Outlook やそれに類するもの）を使うなら、デフォルト設定がこれらの要件を満たすとは限らないことに注意してほしい。ほとんどの場合、メニューから 查看源代码 コマンドを使い、送信フォルダ内のメールを確認して、プレーンテキストで送信され奇妙な文字が含まれていないことを確かめられる。
問題を正確に記述し、中身を持たせる
- 自分の問題やバグの症状を注意深く、はっきりと記述する。
- 問題が発生する環境（マシン構成、オペレーティングシステム、アプリケーション、および関連情報）を記述し、ディストリビュータのディストリビューション名とバージョン番号（例：
Fedora Core 4、Slackware 9.1など）を提供する。 - 質問する前に、この問題についてどのように調べ、理解したかを記述する。
- 質問する前に、問題を特定するために行った診断手順を記述する。
- 最近行った、関連する可能性のあるハードウェアやソフトウェアの変更を記述する。
- できるだけ、
重现这个问题的可控环境できる方法を提供する。
ハッカーがどう聞き返してくるかをできるだけ推測し、質問する前にハッカーが尋ねそうなことにあらかじめ答えておく。
以上の点のうち、コードの中の問題だと思うものを報告する場合、ハッカーがあなたの問題を再現できる環境を提供することがとりわけ重要だ。そうすれば、有効な回答を得られる可能性とスピードが大幅に上がる。
Simon Tatham は《如何有效的报告 Bug》という優れた記事を書いている。ぜひ読むことを強く勧める。
言葉は多さより精にある
正確で中身のある情報を提供する必要がある。これは、エラーメッセージの山や資料をそのまま質問に丸写ししろという意味ではない。プログラムが落ちる状況を再現できる巨大で複雑なテストケースがあるなら、できるだけ小さく切り詰めたほうがよい。
これには少なくとも 3 つの利点がある。
第一に、問題を単純化するための努力を示すことになり、回答を得られる可能性が高まる。
第二に、問題を単純化することで有用な答えを得られる可能性が高まる。
第三に、バグレポートを磨き上げる過程で、自分で解決策や回避策を見つけられることがよくある。
すぐにバグを見つけたと主張しない
ソフトウェアを使っていて問題に遭遇したとき、非常に、非常に確かな根拠がない限り、すぐにバグを見つけたと主張してはいけない。ヒント：問題を解決するソースコードパッチを提供できるか、以前のバージョンで動作が正しくなかったことを示す回帰テストを提供できるのでなければ、たいてい十分な確信は持てていない。これはウェブページやファイルにも当てはまり、ファイルの Bug を（主張として）見つけたなら、該当箇所の修正や代替ファイルを提供できるべきだ。
忘れないでほしい。あなたが見つけた問題に出会っていないユーザーが他にも大勢いるということだ。そうでなければ、ファイルを読んだりウェブを検索したりするときに見つけているはずだ（不平を言う前に 已经做了这些，是吧 したか？）。これはつまり、ソフトウェア自体に問題があるのではなく、あなたが間違っている可能性が高いということでもある。
ソフトウェアを書く人はいつも、できるだけ完璧にしようと苦心している。バグを見つけたと主張することは、彼らの能力を疑うことであり、たとえあなたが正しくても、一部の人を不快にさせるかもしれない。タイトルで Bug があると叫ぶときは、とりわけ深刻だ。
質問するときは、たとえ内心で本物のバグを見つけたと確信していても、あなたが何か間違ったことをしたかのように書いたほうがよい。本当にバグがあれば、返信でそれがわかる。そうすれば、本当にバグがあった場合、メンテナはあなたに謝罪してくれる。相手を怒らせてから謝罪を借りるよりはましだ。
卑屈さはあなたの宿題の代わりにならない
（これは同じ記事の全 12 部のうち 6 部目です。）
ある人たちは、失礼や傲慢な態度で質問して回答を要求するのはよくないと理解していながら、もう一方の極端——卑屈になること——を選んでしまう：我知道我只是个可悲的新手，一个撸瑟，但...。これは相手を困惑させるだけで役に立たず、とりわけ問題そのものの説明が曖昧なまま伴っていると、なおさら不快にさせる。
原始的な霊長類の小細工でお互いの時間を無駄にするのはやめよう。代わりに、背景となる条件と自分の問題の状況をできるだけ明確に説明してほしい。これは卑屈になるよりずっと上手く、あなたの置かれた立場を位置づけてくれる。
ウェブフォーラムの中には、初心者向けの質問専用のコーナーを設けているところもある。もし本当に初心者らしい問題に遭遇したと思うなら、そこへ行けばいい。ただし、そこでも同じように卑屈になる必要はない。
推測ではなく症状を説明する
ハッカーたちに、あなたが問題の原因をこうだと考えていると伝えても、あまり役には立たない。（もしあなたの推測がそれほど当たっているなら、そもそも他人に助けを求める必要があるだろうか？）だから、あなたの解釈や理論ではなく、問題の症状をありのまま伝えることを確実にしてほしい。推測と診断はハッカーたちに任せよう。もし自分の推測を述べることが重要だと思うなら、それが単なる推測にすぎないことをはっきり示し、なぜそれがうまくいかないのかを説明してほしい。
愚かな質問
カーネルをコンパイルしているときに、立て続けに SIG11 エラーが発生します。
どこかのジャンパ線がマザーボードの配線に触れているのではないかと疑っていますが、この状況はどうやって調べるのが一番よいでしょうか？
賢い質問
私の自作機は FIC-PA2007 マザーボードに AMD K6/233 CPU（VIA Apollo VP2 チップセット）を搭載し、
256MB Corsair PC133 SDRAM メモリを積んでいます。カーネルをコンパイルすると、起動から 20 分を過ぎたあたりから
頻繁に SIG11 エラーが発生しますが、最初の 20 分以内には一度も同じ問題は起きていません。
再起動しても効果はなく、一晩電源を切っておくと、また 20 分だけ動作します。
メモリはすべて交換しましたが、効果はありませんでした。関連部分の標準的なコンパイル記録は以下のとおりです…
この点は多くの人にとって守るのが難しいように思われるので、こんな言葉を思い出してほしい：所有的诊断专家都来自密苏里州。。アメリカ国務省の公式モットーは、让我看看 である（1899 年、国会議員 Willard D. Vandiver の演説より：我来自一个出产玉米，棉花，牛蒡和民主党人的国家，滔滔雄辩既不能说服我，也不会让我满意。我来自密苏里州，你必须让我看看。）。診断する側にとって、これは疑いの表明ではなく、単なる現実的で役に立つ要求にすぎない。すなわち、目にするものをあなたが見た生の証拠にできる限り一致させ、あなたの推測や帰納した結論を見せられるのではなく、という意味だ。だから、遠慮なく見せてほしい！
問題の症状を発生順に並べる
問題が起こる前の一連の操作は、たいてい問題を突き止めるうえで最も役立つ手がかりになる。だから、説明には、問題が発生するまでのあなたの操作手順と、それに対するマシンやソフトウェアの反応を含めるべきだ。コマンドラインでの作業なら、操作記録（たとえばスクリプトツールが生成したもの）を提供し、その中から関連する数行（たとえば 20 行）を引用すると非常に役に立つ。
クラッシュしたプログラムに診断オプション（たとえば詳細表示スイッチの -v）があるなら、記録にデバッグ情報を増やせるオプションを試してみてほしい。忘れないでほしいのは、多は好ではないということだ。読者をゴミの山に埋もれさせず、役に立つ情報を提供できるよう、適切なデバッグレベルを選ぼう。
もしあなたの説明が長い（たとえば 4 段落を超える）なら、冒頭で問題を簡潔に述べ、そのあとに時系列で詳述すると役に立つ。そうすれば、ハッカーたちはあなたの記録を読むときに、どこに注意すべきかがわかる。
過程ではなく目標を説明する
もし何かのやり方を知りたい（バグを報告するのではなく）なら、冒頭で目標を述べ、そのあとで自分が行き詰まった特定の手順を再現して見せよう。
技術的な助けを求める人はしばしば、心の中にさらに高い次元の目標がありながら、目標に到達できると思い込んだ特定の道筋で行き詰まり、どう進めばいいのかと訊いてくる。そして、その道筋そのものに問題があることに気づいていない。その結果、解決に多大な労力を要することになる。
愚かな質問
あるお絵かきソフトのカラーピッカーから、16 進数の RGB 値を取得するにはどうすればいいですか？
賢い質問
画像のカラーテーブルを、自分で選んだ色コードに置き換えようとしています。今わかっている唯一の方法は、
各カラーテーブルスロットを個別に編集することですが、
あるお絵かきソフトのカラーピッカーから 16 進数の RGB 値を取得する方法がわかりません。
2 番目の質問の仕方のほうが賢く、建议采用另一个更合适的工具のような返信が得られるかもしれない。
個人的なメールでの返信を求めない
ハッカーたちは、問題の解決過程は公開され、透明であるべきだと考えている。その過程で、より経験のある人が不完全な点や不適切な点に気づけば、最初の返信は訂正されるべきだし、訂正されうる。同時に、助ける側にも報酬がある。その報酬とは、自分の能力と知識が他の同業者に見られることだ。
返信を非公開で求めると、この過程も報酬も途絶えてしまう。そうしてはいけない。非公開で答えるかどうかは返信者に決めさせよう——もし本当にそうしたなら、たいていは、その質問がおそらく他の人の興味を引くことはないほど、拙劣か浅薄だと彼が判断したからだ。
このルールには限定的な例外がある。もし自分の質問が大量の似たような返信を呼び寄せるかもしれないと確信しているなら、その魔法の質問文は向我发电邮，我将为论坛归纳这些回复となるだろう。メーリングリストやニュースグループを似たような返信の洪水から救おうと試みるのは非常に礼儀正しいことだ——ただし、その約束は必ず守らなければならない。
自分の問題と要求を明確に表現する
とりとめのない質問は、ほぼ際限のない時間のブラックホールだ。あなたに役立つ答えをくれる可能性が最も高い人は、たいてい最も忙しい人でもある（彼らが忙しいのは、仕事の大部分を自分でこなしているからだ）。そういう人は無制限の時間のブラックホールをかなり嫌うので、とりとめのない質問も嫌う傾向がある。
回答者に何をしてほしいのか（助言がほしい、コードの一部を送ってほしい、パッチをチェックしてほしい、など）を明確に書けば、役に立つ答えを得られる可能性が最も高い。なぜなら、それによって求められる時間と労力の上限が定まり、回答者は集中してあなたを助けられるからだ。これは素晴らしいことだ。
専門家たちの世界を理解するには、専門技能を潤沢な資源、返信に割く時間を希少な資源と想像するとよい。相手に求める時間が少なければ少ないほど、本当に専門的で忙しい専門家から答えを得られる可能性は高くなる。
だから、自分の問題をきちんと定義し、専門家があなたの問題を識別して回答するために費やす時間を最小限に抑えよう。このスキルは役に立つ答えを得るのに大いに役立つ —— ただし、このスキルは通常、問題を単純化することとは別物だ。したがって、我想更好地理解 X，可否指点一下哪有好一点说明？と尋ねるほうが你能解释一下 X 吗？と尋ねるよりたいてい良い。コードが動かないなら、自分で直してもらうよう頼むよりも、どこがおかしいか見てもらうほうが賢明だ。
コードについて質問するとき
どこから手を付ければよいかの手がかりも示さずに、問題のあるコードのデバッグを頼んではいけない。数百行のコードを貼り付けて它不能工作と言うだけでは、完全に無視される。数十行だけ貼って在第七行以后，我期待它显示 <x>，但实际出现的是 <y>と添えれば、返事をもらえる可能性が高い。
プログラムの問題を説明する最も効果的な方法は、最小限のバグ再現テストケース（bug-demonstrating test case）を提供することだ。最小限のテストケースとは何か。それは問題の縮図だ。小さなプログラム断片が、まさにプログラムの異常な挙動を示し、他の気を散らす内容を含んでいないものだ。どうやって作るのか。異常な挙動を引き起こす行やブロックが分かっているなら、それをコピーし、その状況を再現するのに十分なコード（例えば、そのコードがコンパイル／インタプリタ実行／アプリケーションで処理されるのに足るコード）を加える。問題を特定のブロックに絞り込めないなら、コードをコピーして、問題の挙動を生むのに影響しない部分を取り除く。とにかく、テストケースは小さいほどよい（话不在多而在精の節を参照）。
一般に、かなり簡潔なテストケースを得るのはそれほど容易ではないが、まずはそうしてみるのは常に良い習慣だ。この方法は、自分で問題を解決する方法を理解する助けになる —— そして、たとえその試みが成功しなくても、ハッカーたちはあなたが答えを得ようと努力しているのを見て、より協力的になってくれる。
単にコードをレビューしてほしいだけなら、メールの冒頭でそれを述べ、どの部分に特に注目してほしいか、そしてその理由を必ず書くこと。
自分の宿題の問題を投稿しない
ハッカーたちは宿題式の問題を見分けるのが得意だ。私たちの大半がそうした問題を自分で解いてきたからだ。同様に、そうした問題はあなたが片付けるべきもので、そこから学べるものがある。ヒントを求めるのはよいが、完全な解答を求めてはいけない。
宿題式の問題に当たったと疑っているが、それでも解決できないなら、ユーザーグループやフォーラム、あるいは（最後の手段として）プロジェクトのユーザーメーリングリストやフォーラムで質問してみよう。ハッカーたちには見抜かれても、経験豊富なユーザーならヒントをくれるかもしれない。
無意味な質問文を省く
有人能帮我吗？や这有答案吗？のような無意味な言葉で質問を締めくくるのは避けよう。
第一に、問題の説明がうまくできていないなら、そう尋ねるのは余計な付け足しにすぎない。
第二に、余計な付け足しなので、ハッカーたちはうんざりする —— そして大抵、論理的には正しいが無意味な回答で軽蔑を示してくる。例えば没错，有人能帮你や不，没答案のように。
一般に、是或否、对或错、有或没有といった類の問いは、是或否类型的回答を得たいのでなければ避けること。
急いでいてもタイトルに紧急と書かない
それはあなたの問題であって、私たちの問題ではない。紧急と宣言すると裏目に出る可能性が非常に高い。ほとんどのハッカーは、無礼で自己中心的に即時の注目を求めようとする質問をそのまま削除する。さらに悪いことに、紧急という語（あるいは注目を引こうとする他のタイトル）はスパムフィルタで除去されることが多い —— あなたの質問を見てほしい人たちは永遠にそれを見られないかもしれない。
半分だけ例外なのは、ハッカーたちが興奮するような非常に注目度の高い場所にいる場合で、そうする価値があるかもしれない。その場合、時間的な制約があるなら、丁寧にその旨を添えれば、人々はもっと早く答えてくれるかもしれない。
もちろん、リスクは大きい。ハッカーたちが興奮するポイントはたいていあなたとは違うからだ。例えば NASA の国際宇宙ステーション（International Space Station）からならこのようなタイトルでも問題ないが、自己満足的な慈善行為や政治的理由では絶対にうまくいかない。実際、紧急：帮我救救这个毛茸茸的小海豹！のようなものを投稿すれば、たとえ毛むくじゃらのアザラシの赤ちゃんを重要だと思っていても、ハッカーたちに無視されるか怒らせることは確実だ。
この点が信じられないなら、このガイドの残りを何度も読み返し、理解してから投稿するのがよい。
礼儀は決して損にならないし、時に役にも立つ
礼儀正しく、请や谢谢您的关注、あるいは谢谢你的关照を多用しよう。相手が無料で時間を割いて助けてくれていることに感謝していることを、みんなに示そう。
正直に言えば、この点は明確で正確、簡潔で文法的に正しく、特殊な書式を避けた表現を使うことほど重要ではない（その代わりにもならない）。ハッカーたちは一般に、少しぶっきらぼうでも技術的に明快なバグ報告のほうを、礼儀正しいが曖昧な報告より好む。（これが腑に落ちないなら、私たちは問題が私たちに何を教えてくれるかでその価値を評価していることを思い出してほしい）
しかし、解決すべき問題が山積みになっているなら、丁寧に振る舞うことで有用な返答を得られる可能性は確実に高まります。
（本ガイドの公開後、経験豊富なハッカーたちから寄せられた唯一の深刻な欠点の指摘は、事前に感謝を示すことに関するものでした。一部のハッカーは、先谢了 が事後に誰にも感謝する必要はないという暗示だと受け取ったのです。私たちの提案は、まず 先谢了 と言い、その後で返答者に改めて感謝するか、あるいは 谢谢你的关注 や 谢谢你的关照 など別の形で感謝を表すことです。）
問題が解決したら、短い補足説明を添える
問題が解決したら、助けてくれたすべての人に説明を送り、問題がどのように解決したかを知らせ、もう一度感謝を伝えましょう。もし問題がニュースグループやメーリングリストで広く注目を集めたなら、そこに説明を投稿するのが適切です。
最も理想的なのは、最初に質問したスレッドに返信し、タイトルに 已修正、已解决、あるいはそれと同等の意味を持つ明らかな印を含めることです。人の出入りの多いメーリングリストでは、问题 X と 问题 X - 已解决 を見た潜在的な返答者は、もう時間を無駄にする必要はないと理解します（本人が 问题 X を面白いと感じる場合を除いて）。そのため、その時間を他の問題の解決に充てることができます。
補足説明は長くなくても、深くなくてもかまいません。你好，原来是网线出了问题！谢谢大家 – Bill という簡単な一言でも、何も言わないよりはずっと良いのです。実際、結論が本当に技術的に高度なものでない限り、短くて愛らしいまとめのほうが長々とした講釈より優れています。問題がどう解決したかを説明しましょう。ただし、解決までの過程をそのまま繰り返す必要はまったくありません。
深みのある問題であれば、デバッグ記録の要約を投稿することは役に立ちます。問題の最終的な状態を描写し、何が問題を解決したかを説明し、その後に回避できた落とし穴を指摘します。落とし穴を避ける部分は、正しい解決策やその他の総括的な内容の後に置くべきであり、この情報を推理小説のように仕立ててはいけません。助けてくれた人たちの名前を挙げれば、あなたはより多くの友人を得られるでしょう。
礼儀正しく、内容があるというだけでなく、この種の補足は、他の人がメーリングリスト／ニュースグループ／フォーラムの中で、あなたの問題を本当に解決した方法を検索して見つけ、彼らもそこから恩恵を受けられるようにする助けにもなります。
少なくとも、この補足は、協力に関わったすべての人が問題の解決によって満足感を得る助けになります。もしあなた自身が技術の専門家でもハッカーでもないなら、私たちを信じてください。この感覚は、あなたが助けを求めた達人や専門家にとって、非常に重要なものです。問題が未解決のまま宙に浮いていると、人はがっかりします。ハッカーたちは問題が解決されるのを見ることを切望しています。善行には善報が返ってきます。彼らの切望を満たしておけば、次に質問するときに良い思いをすることでしょう。
どうすれば他の人が将来同じような問題に遭遇するのを避けられるか考えてみましょう。文書を書いたり、よくある質問（FAQ）を追加したりすることが役立つかどうか、自問してみてください。もしそうなら、それをメンテナに送りましょう。
ハッカーの間では、このような良い後続の行動は実のところ伝統的な礼儀よりも重要であり、あなたが他者を大切にすることで評判を勝ち取る方法でもあります。これは非常に価値のある資産なのです。
答えをどう読み解くか
RTFM と STFW：自分が完全にしくじったとどう知るか
古く神聖な伝統があります。もし RTFM（Read The Fucking Manual） という返答を受け取ったら、返答者はあなたがマニュアルを読むべきだと考えています。もちろん、基本的には彼が正しく、あなたは読むべきなのです。
RTFM には若い親戚がいます。もし STFW（Search The Fucking Web） という返答を受け取ったら、返答者はあなたがネットで検索すべきだと考えています。その人もおそらく正しいので、検索してみましょう。（もっと穏やかな言い方なら Google 是你的朋友 です！）
フォーラムでは、過去の投稿を漁るように求められることもあるかもしれません。実際、親切にも以前この問題を解決したスレッドを提供してくれる人さえいるでしょう。しかし、そうした気遣いに頼るべきではなく、質問する前にまず過去の投稿を検索しておくべきです。
たいていの場合、この二つのフレーズのどちらかで返答してくる人は、あなたが必要とする内容を含むマニュアルや URL を渡してくれますし、それらの文字を打っているとき、彼ら自身もそれを読んでいます。これらの返答は、返答者が次のように考えていることを意味します：
- あなたが必要とする情報は非常に手に入りやすい；
- 自分でその情報を検索するほうが、教えてもらうよりも、あなたは多くを学べる。
だからといって不機嫌になるべきではありません。ハッカーの基準からすれば、彼はあなたに対して一定の関心を示しており、あなたの要求を無視したわけではないのです。彼の祖母のような慈しみに感謝すべきです。
それでもわからない場合
返答が理解できないからといって、すぐに相手に説明を求めてはいけません。以前に自分で問題を解決しようとしたときのように（マニュアル、FAQ、ネット、身近な達人を利用して）、まず彼の返答を理解しようと努めましょう。どうしても相手の説明が必要なら、自分がそこから何かを学んだことを示すのを忘れないでください。
たとえば、私があなたに 看来似乎是 zentry 卡住了；你应该先清除它。 と答えたとします。そして、これはとてもひどいフォローアップの返答です：zentry 是什么？。良い聞き方はこうでしょう：哦~~~我看过说明了但是只有 -z 和 -p 两个参数中提到了 zentries，而且还都没有清楚的解释如何清除它。你是指这两个中的哪一个吗？还是我看漏了什么？
無礼な返答への対処
ハッカーの圈子で無礼に見える行為の多くは、故意の侮辱ではありません。むしろ、それは率直で核心を突くコミュニケーションのスタイルであり、相手を気持ちよくさせたまま曖昧にするよりも、問題の解決を重んじるスタイルなのです。
もし侮辱されたと感じたら、冷静に反応するようにしましょう。もし誰かが本当に度を越したことをしたなら、メーリングリスト、ニュースグループ、あるいはフォーラムの古参がたいてい彼に注意します。もしそれが起きず、あなたが怒りを露わにしたなら、あなたが怒りの対象にした相手の言葉はハッカーコミュニティでは普通に見えるかもしれません。そしてあなたが間違っている側と見なされ、それが情報や助けを得る機会を損なうことになるのです。
（これは同じ記事の全12回中の第9回です。）
一方で、失礼でくだらない言動に時折本当に遭遇することもある。前述とは逆に、真の侮辱者に対して容赦なく反撃し、鋭い言葉で徹底的に論破することは許容される。しかし、行動を起こす前に、非常に非常に確かな根拠を持つ必要がある。無礼な発言を正すことと、無意味な口喧嘩を始めることは紙一重であり、ハッカー自身が無謀に一線を越えてしまうことも珍しくない。あなたが初心者や部外者であれば、こうした無謀の機会を避けられる可能性は高くない。もし求めているのが暇つぶしではなく情報なら、このときはキーボードに手を置かず、危険を冒さないほうがよい。
（多くのハッカーには軽度の自閉症やアスペルガー症候群があり、人間社会の正常な交流を潤滑にするのに必要な神経を欠いている、と断言する人もいる。これは真実かもしれないし、嘘かもしれない。もしあなた自身がハッカーでないなら、おそらく私たちの頭がおかしいと考えることが、私たちの奇妙な行動に対処する助けになるだろう。そう考えていればよい。私たちは気にしない。私たちは今の自分たちが好きであり、そして通常、患者のレッテルには筋の通った疑念を抱いている。）
Jeff Bigler の観察のまとめもこれと関連しており、一読の価値がある（tact filters）。
次の節では、別の問題、つまりあなたが不適切な行動をしたときに受ける冒犯について述べる。
敗者を演じるのを避ける方法
ハッカーコミュニティのフォーラムでは、このガイドに書かれた、あるいはそれに似た形で、何度か失敗してしまうことがあるだろう。そしてあなたは、公の場でどのように失敗したのかを告げられ、その攻撃的な言葉には多少の辛辣な色彩が混じっているかもしれない。
こうしたことが起きた後、あなたができる最悪のことは、自分の不遇を嘆き、言葉の攻撃を受けたと主張し、謝罪を要求し、大声で叫び、ふくれっ面をし、法的手段に訴えると脅し、相手の雇用主に文句を言い、トイレの便座の蓋を閉めない、などなどだ。そうではなく、こうすべきである：
耐え抜け、これは普通のことだ。実際、それは健康に良く、理にかなっている。
コミュニティの基準はひとりでに維持されるものではなく、参加者が積極的かつ公然と執行することによって維持される。あらゆる批判は非公開のメールで送られるべきだと泣き叫ぶのはやめよう。そういうふうには機能しない。誰かがあなたの主張の誤りを指摘したり、異なる見解を示したときに、個人的な攻撃を受けたと主張し続けても何の益もない。これらはすべて敗者の態度である。
他のハッカーコミュニティのフォーラムもあり、高い礼節の要求に誤って導かれ、参加者が他人の投稿の欠点を指摘するいかなるメッセージを投稿することも禁止し、如果你不想帮助用户就闭嘴。と主張した結果、考えを持つ参加者が次々と去っていき、そうすることで彼らは無意味な井戸端会議と役に立たない技術フォーラムへと成り下がってしまった。
誇張して言えば、あなたが求めるのは「友善」（上述のやり方での）なのか、それとも有用性なのか。二つのうち一つを選べ。
覚えておけ：ハッカーがあなたは失敗したと言い、そして（どれほど耳に痛くとも）もうそうするなと告げるとき、彼はあなたと彼のコミュニティを気にかけて行動しているのだ。彼にとっては、あなたを無視して自分の生活から濾し取ってしまうほうがもっと簡単だ。感謝できないにしても、せめて多少の品位を示し、大声で嘆きわめかず、自分はドラマチックで超敏感な魂であり自惚れた新参者であるからといって、他人が壊れやすい人形のように自分に接してくれることを期待してはならない。
時には、あなたが失敗していなくても（あるいは彼の想像の中でだけあなたが失敗したとしても）、理由もなくあなた個人を攻撃してくる人もいる。そうした場合、不満を述べることは本当に問題を台無しにしてしまう。
こうした難癖をつけてくる者は、どうしようもないのに専門家気取りの役立たずか、あなたが本当に失敗するかどうかを試す心理の専門家のどちらかだ。他の読者は無視するか、自分なりのやり方で対処する。こうした難癖をつける者は自分自身に厄介を招いているのであって、その点をあなたが心配する必要はない。
自分を口喧嘩に巻き込ませてもいけない。大多数の口喧嘩は無視するのが一番だ——もちろん、それが単なる口喧嘩にすぎず、あなたが失敗した点を指摘しておらず、同時に問題の本当の答えを巧妙にその後ろに隠してもいない（これもあり得る）ことを確認したうえでの話だが。
尋ねるべきでない質問
以下は定番の愚かな質問と、ハッカーが答えなかったときに心の中で思っていることである：
質問：我怎样用 X 做 Y？
質問：我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 文件转换为 TeX 格式吗？
質問：我在安装 Linux（或者 X ）时有问题，你能帮我吗？
質問：我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢？
質問：X プログラムや X リソースはどこで見つけられますか？
回答：私が見つけたまさにその場所さ、愚か者め——検索エンジンの向こう側だ。おやまあ！まさか Google の使い方すら知らない人がいるとは？
質問：X を使って Y をするにはどうすればいいですか？
回答：もしあなたが解決したいのが Y なら、質問するときに不適切かもしれない方法を持ち出さないことだ。この種の質問は、質問者が X についてまったく無知であるだけでなく、Y で解決すべき問題についてもぼんやりしており、さらに特定の状況に思考を縛られていることを示している。こういう人は無視して、問題をはっきりさせてから話すほうがよい。
質問：シェルのプロンプトはどう設定すればいいですか？？
回答：この質問をするだけの知恵があるなら、RTFM して自分で見つけ出すだけの知恵もあるはずだ。
質問：Bass-o-matic ファイル変換ツールを使って AcmeCorp ファイルを TeX 形式に変換できますか？
回答：試してみればすぐにわかる。試したなら答えはわかるはずで、私の時間を無駄にする必要はない。
質問：私の{プログラム/設定/SQL 文}が動きません
回答：それは質問とは言えないでしょう。あなたの本当の問題を見つけるために20も質問をしなければならないような質問には興味がありません —— 私にはもっと面白いことがあるんです。こういう質問を見たときの私の反応は、たいてい次の3つのどれかです。
- 何か補足することはありますか？
- それは大変ですね、うまく解決できるといいのですが。
- それが私に何の関係があるんでしょうか？
質問：私の Windows マシンに問題があるのですが、助けてもらえますか？
回答：ええ、喜んで。マイクロソフトのクソを捨てて、Linux や BSD のようなオープンソースの OS に乗り換えましょう。
注意：そのプログラムに公式の Windows 版がある場合、あるいは Windows と連携する場合（Samba など）は、Windows 関連の質問をしてかまいません。ただし、問題がプログラム自体ではなく Windows OS に起因するという返答に驚かないでください。Windows は概して本当にひどいので、たいていその通りなのです。
質問：私のプログラムが動かなくなりました。システムツール X に問題があると思います。
回答：何千ものユーザーに繰り返し使われているシステムコールやライブラリファイルに明らかな欠陥があることに、あなたが最初に気づいた人物である可能性は十分にあります。しかし、もっと可能性が高いのは、あなたに何の根拠もないということです。並外れた主張には並外れた証拠が必要です。そう主張するなら、明確で詳細な不具合の説明資料を後ろ盾にしなければなりません。
質問：Linux（あるいは X）のインストールで問題が起きているのですが、助けてもらえますか？
回答：できません。実際にあなたのマシンの上で私自身が手を動かさないと、どこが悪いのか見つけられないからです。地元の Linux ユーザーグループの人に実際的な指導を求めてください（ユーザーグループの一覧は这儿にあります）。
注意：インストールの問題が特定の Linux ディストリビューションに関係するなら、そのメーリングリストやフォーラム、地元のユーザーグループで尋ねるのが適切かもしれません。その際は、問題の正確な詳細を描写してください。その前に、まず Linux と、疑わしいすべてのハードウェアをキーワードにしてよく検索しておきましょう。
質問：root アカウントをクラックする／OP 権限を奪う／他人のメールを読むにはどうすればいいですか？
回答：そんなことをしたいと思う時点で、あなたは卑劣な人間です。ハッカーに手伝ってもらおうと思うなら、あなたは白痴です！
良い質問と愚かな質問
最後に、いくつか例を挙げて、どうすれば賢く質問できるのかを説明します。同じ質問の2通りの聞き方を並べます。一方は愚かで、もう一方が賢明です。
愚かな質問：
Foonly Flurbamatic についての資料はどこで見つけられますか？
この聞き方は、STFW のような答えを引き出したいだけにすぎません。
賢い質問：
Google で “Foonly Flurbamatic 2600” を検索しましたが、役に立つ結果は見つかりませんでした。このデバイスのプログラミングに関する資料はどこを探せばいいか、ご存じの方はいませんか？
この質問はすでに STFW 済みで、本当に困っているように見えます。
愚かな質問：
foo プロジェクトから取ってきたソースがコンパイルできません。どうしてこんなにクソなんですか？
彼は何でも他人のせいだと思っています。この傲慢で思い上がった質問者。
賢い質問：
foo プロジェクトのコードが Nulix 6.2 版でコンパイルを通りません。FAQ には目を通しましたが、Nulix に関する問題には触れられていません。これが私のコンパイル過程の記録です。何か私のやり方が間違っているのでしょうか？
質問者は環境を明示し、FAQ も読み、エラーも列挙しています。しかも問題の責任を他人に押し付けていません。彼の質問は注目に値します。
愚かな質問：
マザーボードがおかしくなりました。誰か助けてくれませんか？
あるハッカーがこういう質問に対して返すのは、たいてい 好的，还要帮你拍拍背和换尿布吗？ で、それから Delete キーを押すだけです。
賢い質問：
S2464 マザーボードで X、Y、Z を試しましたが効果がなく、さらに A、B、C も試しました。C を試したときの奇妙な現象に注目してください。明らかに florbish が grommicking しているのですが、結果は予想外です。通常、Athlon MP マザーボードで grommicking が起きる原因は何でしょうか？ 問題を特定するために次にどんなテストをすべきか、ご存じの方はいませんか？
この男は、別の角度から見れば、答える価値があります。彼は天から答えが降ってくるのを待つのではなく、問題を解決する能力を示しています。
最後の質問では、告诉我答案 と 给我启示，指出我还应该做什么诊断工作 の間の微妙かつ重要な違いに注目してください。
実は、後者の質問は 2001 年 8 月の Linux カーネルメーリングリスト（lkml）での実際の投稿に由来します。私（Eric）がその質問者でした。私は Tyan S2464 マザーボード上でこの不可解なハング現象を観察し、リストのメンバーたちが問題解決につながる重要な情報を提供してくれました。
私の質問の仕方によって、私は他人に噛みしめて味わえる材料を与えました。私は人々が気軽に参加し、引き込まれるように工夫したのです。私は自分が彼らと対等な能力を持つことを示し、彼らをともに議論するよう招きました。私が通ってきた回り道を伝えることで彼らの時間を無駄にしないようにし、私は彼らの貴重な時間に対する敬意も示しました。
後日、私が皆に感謝し、この良好な議論の経験を称賛したとき、Linux カーネルメーリングリストのあるメンバーは、私の問題が解決したのは私がこのリストの名物だからではなく、私が正しい方法で質問したからだ、と語りました。
（これは同じ記事の全12回中11回目です。）
ハッカーはある意味で、豊富な知識を持つが人間味に欠ける連中だ。彼は正しいと私は思う。もし私が物乞いのように質問すれば、私が誰であろうと必ず誰かを不快にさせるか、無視されるだろう。彼はこのことを書き留めておくよう提案し、それが直接このガイドの誕生につながった。
回答が得られない場合
それでも回答が得られない場合、私たちがあなたを助けられないと思っているわけではない。時には、あなたの質問を見た人が答えを知らないだけということもある。反応がないからといって無視されたわけではない。とはいえ、その違いを見分けるのが難しいのは確かだ。
一般的に言って、単に質問を繰り返し投稿するのは非常に悪い考えだ。それは無意味な騒ぎと見なされる。少し忍耐を持とう。あなたの質問の答えを知っている人は別のタイムゾーンに住んでいて、眠っているかもしれないし、そもそもあなたの質問が最初から整理されていなかった可能性もある。
他のチャネルから助けを得ることもできる。そうしたチャネルは通常、初心者のニーズにより適している。
オンラインやローカルには、熱心なソフトウェア愛好家（彼ら自身が一度もソフトウェアを書いたことがないとしても）によって構成されるユーザーグループが数多くある。通常、人々は互いに助け合い、初心者を助けるためにこうした団体を組織する。
また、大小を問わず多くの商業企業に助けを求めることもできる。助けを得るためにお金を払うことを悲しむ必要はない！ 結局のところ、もしあなたの車のエンジンのシリンダーシールが破裂したら――十分にあり得ることだが――修理工場に持って行き、修理代を払わなければならない。ソフトウェアが一銭もかからなかったとしても、技術サポートが常に無料だとは強要できない。
Linux のような大衆的なソフトウェアでは、開発者一人に対して少なくとも数万人のユーザーがいる。一人で数万人のユーザーからの問い合わせ電話を処理することは到底不可能だ。たとえこうした支援に対して料金を払うとしても、購入した同種のソフトウェアと比べれば、支払う額は取るに足らないものだと知っておいてほしい（通常、クローズドソースソフトウェアの技術サポート費用はオープンソースソフトウェアよりもはるかに高く、内容もそれほど豊富ではない）。
よりよく質問に答える方法
もう少し穏やかな態度で。 問題がもたらすプレッシャーは、しばしば人を無礼や愚かに見せてしまうが、実際はそうではない。
初めての失敗者には個別に返信する。 率直に間違いを犯した人を公衆の面前で辱める必要はない。本当の初心者は、検索の仕方やよくある質問がどこにあるかすら知らないかもしれない。
確信が持てないなら、必ずそれを伝えよう！ 権威あるように聞こえる間違った返信は、返信しないよりも悪い。専門家のように聞こえるのが面白いからといって、他人に間違った道を教えてはいけない。謙虚で誠実であろう。質問者にも同僚にも良い模範を示そう。
助けられないなら、彼の邪魔をしないこと。 実際の手順を冗談にしてはいけない。それは質問者の設定を台無しにするかもしれない――哀れな間抜けがそれを本当の指示と受け取るかもしれないのだ。
より多くの詳細を引き出すために、試しに逆質問してみる。 うまくやれば、質問者は何かを学べる――あなたも学べる。愚かな質問を良い質問に変えてみよう。私たちは皆かつて初心者だったことを忘れないでほしい。
怠け者に対して RTFM と愚痴るのは正当だが、ドキュメントへのリンクを示すほうがよい（たとえ Google 検索のキーワードを提案するだけでも）。
答えると決めたなら、良い答えを出そう。 他人が間違ったツールや方法を使っているときは、不格好なその場しのぎの策（workaround）を提案するのではなく、より良いツールを勧め、問題を再定義しよう。
前向きに答えよう！ 質問者がすでに深く研究し、X、Y、Z、A、B、C を試しても結果が得られなかったと明示している場合、试试看 A 或是 B や 试试 X 、 Y 、 Z 、 A 、 B 、 C と答え、リンクを添えるのは何の役にも立たない。
あなたのコミュニティが質問から学べるようにしよう。 良い質問に返信するときは、自分自身に問いかけてみよう如何修改相关文件或常见问题文件以免再次解答同样的问题？。そしてファイルのメンテナにパッチを送ろう。
もし調査した末に回答を出したのなら、結果をそのまま差し出すのではなく、あなたのスキルを示そう。結局のところ授人以鱼不如授人以渔。
関連リソース
パソコン、Unix システム、ネットワークがどのように動作するかについての基礎知識が必要なら、Unix 系统和网络基本原理 を参照してほしい。
ソフトウェアやパッチをリリースするときは、软件发布实践 に従ってみてほしい。
謝辞
Evelyn Mitchel はいくつかの愚かな質問の例を提供し、如何更好地回答问题 の節の執筆を促してくれた。Mikhail Ramendik は特に価値のある提案と改善を寄せてくれた。
（これは同じ投稿の全 12 回中 12 回目である。）
微信- 支付宝
