質問の知恵 - Len

本指南英文版版权为 Eric S. Raymond, Rick Moen 所有。

原文网址：[http://www.catb.org/~esr/faqs/smart-questions.html][1]

本文另有 [繁體中文版][2]。

はじめに#

[ハッカー][40] の世界では、技術的な問題を投げかけたときに、有用な回答を得られるかどうかは、あなたの質問の仕方や追求の仕方に大きく依存します。本ガイドでは、正しい質問を通じて満足のいく回答を得る方法を教えます。

ハッカーだけでなく、オープンソース（Open Source）ソフトウェアは非常に普及しており、他の経験豊富なユーザーから回答を得ることができることは良いことです。ユーザーはハッカーよりも、新人がよく直面する問題に対して寛容であることが多いです。しかし、経験豊富なユーザーをハッカーと見なし、本ガイドの方法で彼らとコミュニケーションを取ることは、彼らから満足のいく回答を得るための最も効果的な方法でもあります。

まず理解しておくべきは、ハッカーは挑戦的な問題や、彼らの思考を刺激する良い質問を好むということです。もし私たちがそうでなければ、あなたが尋ねたい相手にはならないでしょう。私たちに繰り返し考えさせるような良い質問をしてくれれば、私たちはあなたに感謝します。良い質問は刺激であり、贈り物です。良い質問は私たちの理解力を高め、通常は私たちが以前に気づかなかったり考えなかった問題を明らかにします。ハッカーにとって、「良い質問」は心からの称賛です。

とはいえ、ハッカーは単純な問題に対して軽蔑や傲慢な態度を持つ悪名があるため、時には新米や無知な人に対して敵対的に見えることがありますが、実際はそうではありません。

私たちは、考えようとせず、質問する前にやるべきことをしない人々に対して軽蔑を隠しません。そうした人々は時間の浪費者であり、彼らはただ受け取ることを望み、決して与えることはなく、私たちの時間をより興味深い問題やより価値のある人々に使うことができる時間を消耗します。私たちはこうした人々を失敗者（lusers）と呼びます。

私たちは、多くの人々が私たちが書いたソフトウェアを使いたいだけであり、技術的な詳細を学ぶことに興味がないことを理解しています。ほとんどの人にとって、コンピュータは単なる道具であり、目的を達成する手段に過ぎません。彼らには自分の生活があり、より重要なことをする必要があります。私たちはこの点を理解しており、すべての人が私たちを魅了する技術的な問題に興味を持つことを期待していません。それでも、私たちの質問への回答のスタイルは、実際にそのことに興味を持ち、問題解決に積極的に参加しようとする人々に向けられています。この点は変わらず、変わるべきではありません。これが変わると、私たちは自分たちが最も得意とすることの効率を下げることになります。

私たちは（大部分は）自発的に、忙しい生活の中から時間を割いて疑問に答え、しばしば質問に圧倒されています。したがって、私たちは無情にいくつかのトピックをフィルタリングし、特に失敗者のように見える人々を排除し、より効率的に勝者（winner）の質問に答えるための時間を利用します。

もし私たちの態度が嫌いで、傲慢すぎると感じるなら、少し考えてみてください。私たちはあなたに屈服することを求めているわけではありません -- 実際、私たちのほとんどは、あなたが基本的な要件を満たすために少し努力をすれば、平等に交流することを非常に喜んでいます。しかし、自分自身を助けようとしない人々を助けることは非効率的です。無知は問題ありませんが、愚かであることは許されません。

したがって、技術的に非常に熟練している必要はありませんが、あなたが熟練するための特性 -- 機敏さ、考え、観察力、問題解決に積極的に参加する意欲を示す必要があります。これらのことを実行できない場合は、商業会社にお金を払って技術サポートサービス契約を結ぶことをお勧めします。ハッカー個人に無償で助けを求めるのではなく。

私たちに助けを求めることを決定した場合、もちろんあなたは失敗者として見られたくないし、失敗者の一員になりたくないでしょう。迅速かつ効果的な回答を得る最良の方法は、勝者のように質問することです -- 賢く、自信を持ち、問題解決の考えを持ち、特定の問題に関して少し助けを得る必要があるだけです。

質問する前に#

電子メール、コミュニティ、またはソーシャルメディアで技術的な質問をする準備をする前に、以下のことを行ってください：

質問を準備しているフォーラムの過去の投稿を検索して、答えを探してみてください。
インターネットで検索して、答えを見つけてみてください。
マニュアルを読んで、答えを見つけてみてください。
よくある質問（FAQ）を読んで、答えを見つけてみてください。
自分で確認または実験して、答えを見つけてみてください。
身近な強者の友人に尋ねて、答えを見つけてみてください。
プログラマーであれば、ソースコードを読んで、答えを見つけてみてください。

質問をする際には、まず上記の努力をしたことを示してください。これは、あなたが不労所得を得ようとしているわけではなく、他人の時間を無駄にしているわけではないという印象を与えるのに役立ちます。もしあなたが上記の努力の過程で学んだことを伝えることができれば、さらに良いです。なぜなら、私たちは答えから学ぼうとする人々の質問に答えることをより喜んでいるからです。

特定の戦略を使用して、遭遇したさまざまなエラーメッセージを最初に Google で検索してみてください（[Google フォーラム][41] やウェブページも検索してください）。これにより、問題を解決するためのドキュメントやメールリストの手がかりを直接見つけることができる可能性が高くなります。結果が得られなかった場合でも、メールリストやニュースグループで助けを求める際に「私は Google で以下の文を検索しましたが、役に立つものは見つかりませんでした」と付け加えるのも良いことです。これは、検索エンジンがどのように役立たなかったかを示すだけでなく、同様の問題に直面している他の人々が検索エンジンによってあなたの質問に導かれるのを助けます。

焦らず、複雑な問題を数秒の Google 検索で解決できるとは期待しないでください。専門家に助けを求める前に、もう一度 FAQ を読み、リラックスして快適に座り、この問題について考える時間を取ってください。私たちを信じてください。彼らはあなたの質問から、あなたがどれだけの読書と考えをしたかを見抜くことができます。準備が整っていれば、回答を得る可能性が高くなります。最初の検索で答えが見つからなかったからといって、すべての質問を一度に投げかけないでください（または、あまりにも多くの答えを見つけたからといって）。

質問を準備し、質問を慎重に考えてください。なぜなら、軽率な質問は軽率な回答しか得られないか、まったく回答が得られないからです。あなたが助けを求める前に問題を解決するためにどれだけ努力したかを示すことができればできるほど、実質的な助けを得る可能性が高くなります。

間違った質問をしないように注意してください。あなたの質問が誤った仮定に基づいている場合、一般的なハッカー（J. Random Hacker）は心の中で「愚かな質問…」と思いながら、無意味な文字通りの説明であなたに答えるでしょう。あなたが質問の回答（あなたが得たい答えではなく）から学ぶことを期待していることを願っています。

自分が資格があると思わないでください。あなたはそうではありません。あなたはそうではありません。結局、あなたはこのサービスに対して何も支払っていないのです。あなたは、意味のある、興味深い、思考を刺激する質問をすることで、答えを得る必要があります -- コミュニティの経験に貢献できる可能性のある質問であり、他の人から知識を受動的に求めるだけではありません。

一方で、答えを見つける過程で何かをする意欲を示すことは非常に良いスタートです。「誰かヒントをくれませんか？」、「私のこの例には何が欠けていますか？」や「私はどこをチェックすべきですか？」は、「必要な正確なプロセスを貼り付けてください」と言うよりも、より容易に回答を得ることができます。なぜなら、あなたが誰かに正しい方向を指し示してもらえれば、あなたにはそれを完了する能力と決意があることを示しているからです。

質問するとき#

質問するフォーラムを慎重に選ぶ#

質問する場を慎重に選んでください。以下のことを行った場合、あなたは無視されるか、失敗者と見なされる可能性が高くなります：

* テーマに合わないフォーラムに質問を投稿する。
* 高度な技術的問題を議論するフォーラムに非常に初歩的な質問を投稿する；その逆も同様。
* 多くの異なるニュースグループに同じ質問を繰り返し投稿する（cross-post）。
* 知人でもない人にプライベートメールを送信して、あなたの問題を解決する義務がない人に送信する。

ハッカーは、場を間違えた質問を排除して、彼らのコミュニケーションチャネルが無関係なもので溢れないようにします。あなたはこのようなことが自分に起こることを望まないでしょう。

したがって、第一歩は正しいフォーラムを見つけることです。再度言いますが、Google や他の検索エンジンはあなたの友人です。これらを使用して、あなたが直面しているソフトウェアやハードウェアの問題に最も関連するウェブサイトを見つけてください。通常、そこには FAQ、メールリスト、関連するドキュメントへのリンクがあります。あなたの努力（FAQ を読むことを含む）が結果を出さなかった場合、ウェブサイトにはバグを報告するプロセスやリンクがあるかもしれません。そうであれば、リンクをたどってみてください。

見知らぬ人やフォーラムにメールを送ることは、最もリスクの高い行動の一つです。たとえば、豊富なコンテンツを提供するウェブページの作者があなたの無料の顧問になりたいと思うとは限りません。あなたの質問が歓迎されるかどうかを過度に楽観視しないでください -- 確信が持てない場合は、他の場所に送信するか、そもそも送信しないでください。

フォーラム、ニュースグループ、またはメールリストを選択する際には、名前を過信せず、まず FAQ やライセンスを確認して、あなたの質問が適切かどうかを確認してください。投稿する前に、既存のトピックを確認することで、その場の文化を感じることができます。実際、ニュースグループやメールリストの履歴の中で、あなたの質問に関連するキーワードを検索することは非常に良いアイデアであり、これにより答えが見つかるかもしれません。たとえ見つからなくても、より良い質問をまとめるのに役立ちます。

すべての支援チャネルに一度に「掃射」するようなことは避けてください。これは大声で叫ぶようなものであり、他の人を不快にさせます。一つずつ来てください。

あなたのテーマを明確にしてください！最も典型的な間違いの一つは、特定のクロスプラットフォームの移植性のある言語、スイート、またはツールのフォーラムで Unix または Windows オペレーティングシステムのプログラムインターフェースに関する質問をすることです。なぜこれが大きな間違いなのか理解できない場合は、まずその違いを理解するまで何も質問しない方が良いでしょう。

一般的に、慎重に選ばれた公共フォーラムで質問する方が、プライベートフォーラムで同じ質問をするよりも有用な回答を得る可能性が高いです。これを支持する理由はいくつかあります。潜在的な回答者の数、観客の数を考慮することです。ハッカーは、多くの人々に役立つ質問に回答することを好みます。

理解できることですが、熟練したハッカーや人気のあるソフトウェアの作者は、過剰な誤送信を受けています。最後の一押しがキャメルの背中を折る稲わらのように、あなたの参加が状況を極端にする可能性があります -- 何度も、人気のあるソフトウェアの作者は、自分のソフトウェアのサポートから手を引くことになりました。なぜなら、彼らのプライベートメールボックスに押し寄せる無駄なメールが耐えられなくなったからです。

Stack Overflow#

検索して、その後 Stack Exchange で質問してください。

近年、Stack Exchange コミュニティは、特にオープンソースプロジェクトに関する技術的およびその他の質問に回答する主要なチャネルとなっています。

Google のインデックスは即時であるため、Stack Exchange を見る前に Google で検索してください。誰かが似たような質問をすでにしている可能性が高く、Stack Exchange のウェブサイトは検索結果の最初の数件に表示されることがよくあります。Google で答えが見つからなかった場合は、特定の関連テーマのウェブサイトに行って探してください。タグ（Tag）検索を使用すると、検索結果をさらに絞り込むことができます。

Stack Exchange は [100 を超えるウェブサイト][42] に成長しており、以下は最も一般的に使用されるいくつかのサイトです：

Super User は一般的なコンピュータの質問をする場所で、あなたの質問がコードやプログラミングに関係ない場合、ここに行ってください。
Stack Overflow はプログラミングに関する質問をする場所です。
Server Fault はサーバーやネットワーク管理に関する質問をする場所です。

ウェブサイトと IRC フォーラム#

ローカルのユーザーグループ（user group）や使用している Linux ディストリビューションは、初心者支援を提供するウェブフォーラムや IRC チャンネルを宣伝しているかもしれません（いくつかの非英語圏では、初心者フォーラムはメールリストである可能性が高いです）。これらの場所は、特にあなたが直面している問題が比較的簡単または一般的なものであると思われる場合、質問を始めるのに良い選択肢です。広告スポンサー付きの IRC チャンネルは、質問を歓迎する公開の場所であり、通常は即座に応答を得ることができます。

実際、プログラムの問題が特定の Linux ディストリビューションが提供するバージョンでのみ発生する場合（これは非常に一般的です）、最初にそのディストリビューションのフォーラムやメールリストで質問し、その後プログラム自体のフォーラムやメールリストで質問するのが最善です。（そうでなければ）そのプロジェクトのハッカーは「私たちのバージョンを使用してください」とだけ返答するかもしれません。

フォーラムに投稿する前に、検索機能があるかどうかを確認してください。もしあれば、問題のいくつかのキーワードを検索してみてください。これが役立つかもしれません。もしその前に一般的なウェブ検索を行っていた場合（あなたはそうすべきです）、フォーラムを再度検索してみてください。検索エンジンがこのフォーラムのすべてのコンテンツをインデックスする時間がなかったかもしれません。

フォーラムや IRC チャンネルを通じてユーザーサポートを提供する傾向が高まっており、電子メールは主にプロジェクト開発者間のコミュニケーションに留まっています。したがって、最初にフォーラムや IRC でそのプロジェクトに関連する支援を求めるのが最善です。

IRC を使用する際には、最初に長い問題の説明を投稿しない方が良いです。これを「チャンネル洪水」と呼ぶ人もいます。最初は一文の問題の説明から始めるのが最善です。

次のステップ、プロジェクトのメールリストを使用する#

プロジェクトが開発者のメールリストを提供している場合は、リストに質問をするのが良いです。個々のメンバーに質問するのではなく、リストに質問してください。たとえあなたがその人が最も良い回答を提供できると確信していても。プロジェクトのドキュメントやホームページを確認して、プロジェクトのメールリストを見つけて使用してください。このアプローチを支持する良い理由がいくつかあります：

個別の開発者に尋ねる必要があるほど良い質問は、プロジェクト全体のグループにも役立ちます。逆に、あなたの質問がプロジェクト全体にとって愚かすぎると思うなら、個別の開発者を悩ませる理由にはなりません。
リストに質問することで、開発者の負担を軽減できます。個別の開発者（特にプロジェクトリーダー）は、あなたの質問に答える余裕がないほど忙しいかもしれません。
ほとんどのメールリストはアーカイブされており、アーカイブされた内容は検索エンジンによってインデックスされます。もしリストに質問して回答を得られれば、将来他の人がウェブ検索を通じてあなたの質問と回答を見つけることができ、再度質問する必要がなくなります。
もし特定の質問が頻繁に尋ねられる場合、開発者はこの情報を利用してドキュメントやソフトウェア自体を改善し、より明確にすることができます。個別に質問するだけでは、最も一般的な質問の全体像を見ることはできません。

もしプロジェクトに「ユーザー」と「開発者」（または「ハッカー」）のメールリストやフォーラムがあり、あなたがそのソースコードに触れないのであれば、「ユーザー」リストやフォーラムに質問してください。あなたが開発者リストで歓迎されると思わないでください。彼らはあなたの質問を彼らの開発を妨げる雑音と見なすことが多いです。

しかし、もしあなたが特別な質問をしていると確信していて、「ユーザー」リストやフォーラムで数日間返信がない場合は、「開発者」リストやフォーラムに質問してみてください。投稿する前に、そこでの行動様式を理解するために数日間観察することをお勧めします（実際、これは任意のプライベートまたは半プライベートリストに参加する際の良いアイデアです）。

もしプロジェクトのメールリストが見つからず、プロジェクトのメンテナの電子メールアドレスしか見つからない場合でも、彼にメールを送ってください。この場合でも、（プロジェクトの）メールリストが存在しないと仮定しないでください。あなたの電子メールには、あなたが試したが適切なメールリストが見つからなかったことを述べ、他の人にあなたのメールを転送することに反対しないことを明記してください（多くの人は、秘密がない場合でも、プライベートな電子メールは公開されるべきではないと考えています。あなたの電子メールを他の人に転送することを許可することで、相応の人々にあなたのメールを処理する選択肢を与えています）。

意味のある、明確なタイトルを使用する#

メールリスト、ニュースグループ、またはフォーラムでは、約 50 文字以内のタイトルが熟練した専門家の注意を引く良い機会です。「助けてください」、「お願い」、「急いで」（ましてや「助けて！！！！」のような不快な言葉を使ってこの機会を無駄にしないでください）を使ってこの機会を浪費しないでください。あなたの苦痛の程度で私たちを感動させようとするのではなく、このスペースを使って非常にシンプルで簡潔な説明で質問を提示してください。

良いタイトルの例は「目標 -- 差異」形式の説明です。目標部分では、どのアイテムまたはグループに問題があるかを示し、差異部分では期待される動作と一致しない場所を説明します。

愚かな質問：助けて！私のノートパソコンが正常に表示されません！

賢い質問：X.org 6.8.1 のマウスカーソルが変形します。特定のブランドのグラフィックカード MV1005 チップセットを使用しています。

さらに賢い質問：X.org 6.8.1 のマウスカーソルが、特定のブランドのグラフィックカード MV1005 チップセット環境で変形します。

目標 -- 差異形式の説明を作成するプロセスは、問題についての詳細な考察を整理するのに役立ちます。何が影響を受けましたか？マウスカーソルだけですか、それとも他のグラフィックもですか？X.org の X バージョンでのみ発生しますか？それとも 6.8.1 バージョンでのみ発生しますか？特定のブランドのグラフィックカードチップセットに関連していますか？それとも MV1005 モデルだけですか？ハッカーは一目であなたの環境とあなたが直面している問題を理解できます。

要するに、あなたがタイトルだけを表示するアーカイブされたディスカッションスレッドのインデックスを検索していると想像してください。あなたのタイトルが問題をよりよく反映することで、次に同様の問題を検索している人がこのディスカッションスレッドに注目できるようになります。

もし返信で質問を提起したい場合は、内容のタイトルを変更して、あなたが質問をしていることを示してください。「Re: テスト」や「Re: 新しいバグ」のようなタイトルは、十分な注意を引くことが難しいです。また、連続性に影響を与えない範囲で、前の内容を適切に引用し、削除することで、新しい読者に手がかりを残すことができます。

ディスカッションスレッドに対して、直接返信をクリックして新しいディスカッションスレッドを開始しないでください。これにより、あなたの観客が制限されます。なぜなら、いくつかのメールリーディングプログラム（例えば mutt）は、ユーザーがディスカッションスレッドでソートし、スレッドを折りたたんでメッセージを隠すことを許可するため、これを行う人はあなたが送信したメッセージを永遠に見ることができません。

タイトルを変更するだけでは不十分です。mutt や他のいくつかのメールリーディングプログラムは、メールのタイトル以外の情報もチェックして、ディスカッションスレッドを指定します。したがって、全く新しいメールを送信する方が良いです。

ウェブフォーラムでは、良い質問の方法は少し異なります。なぜなら、ディスカッションスレッドは特定の情報に密接に結びついており、通常はディスカッションスレッドの外ではその内容を見ることができないため、タイトルを変更するのではなく、返信で質問することが許容されます。すべてのフォーラムが返信に分離されたタイトルを許可しているわけではなく、そうした場合、基本的に誰も見ないでしょう。しかし、返信で質問すること自体が曖昧な行為であり、タイトルを見ている人だけがそれを読むことになります。したがって、あなたがそのディスカッションスレッドの現在のアクティブな人々の中でのみ質問したいのでなければ、別のスレッドを開始する方が良いです。

質問を容易にする#

「あなたの返信を... に送ってください」と質問を終えることは、ほとんどの場合、回答を得られないことになります。もしあなたがメールクライアントで返信アドレスを設定するのに数秒かかるのが面倒だと感じるなら、私たちもあなたの質問を考えるのに数秒かかるのが面倒です。もしあなたのメールプログラムがこれをサポートしていない場合は、[良いものに変えてください][43]。もしオペレーティングシステムがそのようなメールプログラムをサポートしていない場合も、良いものに変えてください。

フォーラムでは、電子メールでの返信を要求することは非常に失礼です。あなたが信じるに足る理由がない限り（そして誰かが未知の理由であなたにだけ答えを知らせることを望んでいる場合）、それを行うべきではありません。もしあなたが単に誰かがディスカッションスレッドに返信したときに電子メールの通知を受け取りたいだけなら、ウェブフォーラムにそれを送信するように要求できます。ほとんどのフォーラムは「このディスカッションスレッドを追跡する」、「返信時にメール通知を送信する」などの機能をサポートしています。

明確で正確、正確な文法の文を使用する#

私たちは経験から、粗雑な質問者は通常、粗雑にプログラムを書いたり考えたりすることが多いことを知っています（私は保証します）。粗雑な人の質問に答えることは価値がなく、私たちは他の場所で時間を費やす方が良いです。

正しいスペル、句読点、大文字小文字は非常に重要です。一般的に、あなたがそれを行うのが面倒だと感じるなら、私たちも面倒だと感じ、あなたの質問を気にしません。少し余分なエネルギーを使って言葉を考え、あまり堅苦しくなく正式である必要はありません -- 実際、ハッカー文化は非公式、スラング、ユーモアを正確に使用することを重視しています。しかし、それは非常に正確でなければならず、あなたが問題について考え、注意を払っていることを示す兆候が必要です。

正しくスペルをつけ、句読点と大文字小文字を使用し、「its」と「it's」を混同せず、「loose」を「lose」にしたり、「discrete」を「discreet」にしないでください。すべて大文字で書かないでください。これは無礼な大声での叫びと見なされます（すべて小文字も読みづらいため、あまり良くありません。[Alan Cox][44] はこれを行うかもしれませんが、あなたはそうではありません）。

より口語的に言えば、あなたが半文盲のように書くと、ほとんどの人は無視するでしょう [訳注：[小白][45]]。また、即時通信の略語や [火星文][46] を使用しないでください。「の」を「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.

もしあなたが特定の言語を話すなら、私にメール / プライベートメッセージを送ってください。私の質問を翻訳するのを手伝ってほしいです。

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.

私は特定の言語と英語で質問を投稿しました。もしあなたが一つの言語だけで答えた場合、私は喜んでそれを翻訳します。

読みやすく、標準的なファイル形式で質問を送信する#

もしあなたが問題を読みづらくするように意図的に作成した場合、それは無視される可能性が高いです。人々は理解しやすい質問を読むことを好むので：

HTML ではなくプレーンテキストを使用してください（[HTML を無効にする][47] のは難しくありません）。
MIME 添付ファイルを使用することは通常許可されていますが、実際に内容がある場合（たとえば、添付されたソースコードやパッチ）であり、単にメールプログラムが生成したテンプレート（たとえば、手紙の内容のコピー）ではないことが前提です。
一行の文が自動的に折り返されて複数行になるようなテキストを送信しないでください（これは返信の一部を非常に困難にします）。あなたの読者が 80 文字幅の端末でメールを読んでいると想像し、折り返しの分割点を 80 文字未満に設定してください。
ただし、特定のファイルに対して固定幅を設定しないでください（たとえば、ログファイルのコピーやセッション記録）。データはそのまま保持し、返信者が彼らが見ているものがあなたが見ているものと同じであることに自信を持てるようにしてください。
英語のフォーラムでは、Quoted-Printable MIME エンコーディングを使用してメッセージを送信しないでください。このエンコーディングは非 ASCII 言語を投稿するために必要な場合がありますが、多くのメールプログラムはこのエンコーディングをサポートしていません。これらのプログラムが改行を処理するとき、テキスト中に散在する=20記号は見栄えが悪く、注意を散漫にし、内容の意味を破壊する可能性があります。
絶対に、決してハッカーが閉じた形式で作成された文書を読むことを期待しないでください。たとえば、Microsoft の Word や Excel ファイルなどです。ほとんどのハッカーは、誰かがまだ熱い豚の糞をあなたの家の前に捨てるときのあなたの反応のように反応します。たとえ彼らがそれを処理できたとしても、彼らはそれを非常に嫌います。
Windows コンピュータから電子メールを送信する場合、Microsoft の愚かなスマートクォート機能を無効にしてください（[オプション] > [校正] > [自動修正オプション] から、スマートクォートのチェックボックスを外してください）。これにより、あなたのメールの中にゴミ文字が散らばるのを防ぎます。
フォーラムでは、絵文字やHTML機能を乱用しないでください（それらが提供されている場合）。一、二個の絵文字は通常問題ありませんが、派手なカラーテキストは、あなたが無能な人間であると見なされる傾向があります。絵文字、色、フォントを過剰に使用すると、あなたは愚かな笑顔の女の子のように見えます。これは通常良いアイデアではありません。なぜなら、あなたが答えではなく性に興味がある場合を除いて。

もしグラフィカルユーザーインターフェースのメールプログラム（Microsoft の Outlook やその他の類似のものなど）を使用している場合、それらのデフォルト設定がこれらの要件を満たさないことがあることに注意してください。このようなプログラムのほとんどには、メニューに基づくソースコードを表示コマンドがあり、これを使用して送信フォルダ内のメールを確認し、プレーンテキストファイルが送信され、奇妙な文字が含まれていないことを確認できます。

問題を正確に説明し、具体的に述べる#

あなたの問題やバグの症状を注意深く、明確に説明してください。
問題が発生した環境（マシンの構成、オペレーティングシステム、アプリケーション、および関連情報）を説明し、ベンダーのリリースとバージョン番号を提供してください（例：Fedora Core 4、Slackware 9.1など）。
質問する前に、あなたがこの問題をどのように研究し、理解したかを説明してください。
質問する前に、問題を特定するために取った診断手順を説明してください。
最近行った可能性のある関連するハードウェアまたはソフトウェアの変更を説明してください。
可能な限り、この問題を再現するための制御された環境を提供してください。

ハッカーがどのように反問するかを推測し、あなたが質問する前にハッカーが直面する可能性のある問題に事前に回答してください。

上記のポイントの中で、あなたがコードの中に問題があると思う場合、ハッカーにあなたの問題を再現できる環境を提供することが特に重要です。これを行うことで、あなたが有効な回答を得る機会と速度が大幅に向上します。

[Simon Tatham][48] は「[バグを効果的に報告する方法][49]」という素晴らしい記事を書いています。ぜひ読んでみてください。

言葉は多くなく、精度が重要#

あなたは正確で内容のある情報を提供する必要があります。これは、あなたが大量のエラーメッセージやデータを質問に完全に転記することを要求するものではありません。もしあなたがプログラムがクラッシュする状況を再現するための大規模で複雑なテストケースを持っている場合、それをできるだけ小さく切り詰めるようにしてください。

これを行うことには少なくとも 3 つの利点があります。
第一に、問題を簡素化するために努力したことを示すことで、回答を得る機会が増えます；
第二に、問題を簡素化することで、有用な回答を得る可能性が高くなります；
第三に、バグレポートを精練する過程で、あなた自身が解決策や回避策を見つけることができる可能性が高くなります。

バグを見つけたと軽々しく主張しない#

ソフトウェアを使用しているときに問題が発生した場合、あなたが非常に、非常に根拠がある場合を除いて、軽々しくバグを見つけたと主張しないでください。ヒント：問題を解決するためのソースコードのパッチを提供するか、前のバージョンでの動作が不正確であることを示す回帰テストを提供できない限り、あなたはほとんど完全に確信が持てないでしょう。このことはウェブページやファイルにも当てはまります。もしあなたが（バグを）発見したと主張するのであれば、相応の位置の修正や代替ファイルを提供できるべきです。

他の多くのユーザーがあなたが発見した問題に直面していないことを忘れないでください。さもなければ、あなたはドキュメントを読んだりウェブページを検索したりしているときにそれを発見しているはずです（あなたは不満を言う前に [これらを行ったのでしょう][50]？）。これは、あなたが間違っている可能性が高いことを意味します。

ソフトウェアを作成する人々は、できるだけ完璧にするために非常に苦労しています。もしあなたがバグを見つけたと主張するなら、それは彼らの能力を疑うことになります。たとえあなたが正しいとしても、彼らの一部の人々を冒犯する可能性があります。特に、あなたがタイトルで「バグがある」と叫ぶとき、これは特に深刻です。

質問するとき、たとえあなたが私的に本当にバグを見つけたと確信していても、あなたが何かを間違えたと書くのが最善です。もし本当にバグがある場合、あなたは返信の中でそれを見つけることができるでしょう。こうすることで、もし本当にバグがあれば、メンテナはあなたに謝罪するでしょう。これは、他の人を怒らせて謝罪を求めるよりも良い結果です。

低姿勢はあなたの宿題を代わりにすることはできない#

ある人々は、粗野または傲慢に質問して回答を求めるべきではないことを理解していますが、彼らは別の極端を選択します -- 低姿勢になることです。「私はただの悲しい初心者で、失敗者ですが...」。これは困惑させるだけでなく、特に実際の問題の曖昧な説明を伴う場合はさらに不快です。

原始的な猿のトリックを使って、あなたの時間と私の時間を無駄にしないでください。代わりに、背景条件とあなたの問題の状況をできるだけ明確に説明してください。これは低姿勢よりもあなたの立場をより良く特定します。

時には、ウェブフォーラムには初心者の質問専用のセクションがある場合があります。もしあなたが本当に初心者の問題に直面していると思うなら、そこに行くのが良いですが、同じように低姿勢にならないでください。

問題の症状を説明し、あなたの推測を述べない#

ハッカーに問題がどのように発生したと思うかを伝えることは役に立ちません。（もしあなたの推測がそれほど効果的であれば、他の人に助けを求める必要はありません）。したがって、彼らに問題の症状を原則として伝え、あなたの説明や理論ではなく、彼らに推測や診断をさせてください。もし自分の推測を述べることが重要だと思うなら、それは単なる推測であり、なぜそれが機能しないのかを説明してください。

愚かな質問

カーネルをコンパイルしているときに SIG11 エラーが続出します。
どこかの飛び線がマザーボードのラインに接触していると思います。これをどうやって確認すればいいですか？

賢い質問

私の組み立てたコンピュータは FIC-PA2007 マザーボードに AMD K6/233 CPU（VIA Apollo VP2 チップセット）を搭載しており、
256MB の Corsair PC133 SDRAM メモリを使用しています。カーネルをコンパイルすると、起動から 20 分後に頻繁に SIG11 エラーが発生しますが、
最初の 20 分間は同じ問題が発生したことはありません。再起動しても効果がなく、夜間にシャットダウンすると再び 20 分間動作します。
すべてのメモリを交換しましたが、効果はありませんでした。関連部分の標準的なコンパイルログは以下の通りです…。

上記の点は、多くの人々が協力するのが難しいと感じるようですが、ここでの言葉を思い出してください：すべての診断専門家はミズーリ州出身です。 アメリカ国務省の公式モットーは見せてくださいです（これは国会議員 Willard D. Vandiver が 1899 年に発言した言葉で、私はトウモロコシ、綿花、牛蒡、民主党員を生産する国から来ました。雄弁は私を説得することも、私を満足させることもありません。私はミズーリ州から来ました。あなたは私に見せなければなりません。）。診断者にとって、これは疑念ではなく、彼らが見たいのはあなたが見ている原始的な証拠にできるだけ一致するものであるという現実的かつ有用な要求です。したがって、私たちに見せてください！

問題の症状を発生した順に列挙する#

問題が発生する前の一連の操作は、問題を特定するための最も有用な手がかりとなることがよくあります。したがって、あなたの説明には操作手順とマシンやソフトウェアの反応を含め、問題が発生するまでの過程を説明する必要があります。コマンドライン処理の場合、操作の記録（たとえば、スクリプトツールが生成したもの）を提供し、関連する数行（たとえば 20 行）を引用することが非常に役立ちます。

もしクラッシュしたプログラムに診断オプション（たとえば - v の詳細スイッチ）がある場合、これらのオプションを選択して、記録にデバッグ情報を追加するようにしてください。覚えておいてください、多いは良いではありません。読者をゴミの中で溺れさせるのではなく、有用な情報を提供するために適切なデバッグレベルを選択してください。

もしあなたの説明が長い（たとえば 4 段落を超える）場合、最初に問題を簡潔に説明し、その後に時間の経過に従って詳細を説明することが役立ちます。これにより、ハッカーはあなたの記録を読む際に注意すべき内容を理解できます。

目標を説明し、プロセスを説明しない#

何かを行う方法を理解したい場合（バグを報告するのではなく）、最初に目標を説明し、その後にあなたが詰まっている特定のステップを述べてください。

技術的な助けを求める人々は、心の中により高いレベルの目標を持っており、彼らは自分がその目標に到達できると思っている特定の道で詰まってしまい、どう進むべきかを尋ねに来ますが、その道自体に問題があることに気づいていません。結果として、非常に多くの努力が必要になります。

愚かな質問

どうやって特定の描画プログラムのカラーピッカーから 16 進数の RGB 値を取得できますか？

賢い質問

私は画像の色コードを自分が選んだ色コードに置き換えようとしています。今のところ、唯一の方法は各色コードブロック（table slot）を編集することだと知っていますが、
特定の描画プログラムのカラーピッカーから 16 進数の RGB 値を取得することができません。

後者の質問の方が賢明であり、「別のより適切なツールを提案する」といった返信を得る可能性があります。

プライベートメールでの返信を要求しない#

ハッカーは、問題の解決プロセスは公開され、透明であるべきだと考えています。このプロセスの中で、より経験豊富な人々が不完全または不適切な点に気づいた場合、最初の返信は修正されるべきです。同時に、助けを提供する者は、彼の能力と知識が他の同業者に見られるという報酬を得ることができます。

プライベートな返信を要求すると、このプロセスと報酬は中断されます。そうしないでください。返信者にプライベートに回答するかどうかを決定させてください -- もし彼が本当にそうした場合、通常は彼が問題の書き方があまりにも悪いか、他の人に興味がないと考えたからです。

このルールには限られた例外があります。もしあなたが質問が大量の同様の返信を引き起こす可能性があると確信している場合、この魔法の質問文は「私にメールを送ってください。私はフォーラムのためにこれらの返信を要約します」となります。メールリストやニュースグループを同じような返信の洪水から救おうとすることは非常に礼儀正しい行為ですが、あなたは約束を守らなければなりません。

あなたの質問とニーズを明確に表現する#

漫然とした質問は、ほぼ無限の時間のブラックホールです。最も有用な回答を提供する可能性が高い人々は、通常最も忙しい人々です（彼らが忙しいのは、ほとんどの作業を自分で完了する必要があるからです）。このような人々は、無制限の時間のブラックホールに対して非常に嫌悪感を抱くため、漫然とした質問を嫌う傾向があります。

あなたが回答者に何をしてほしいのか（指導を提供する、コードの一部を送信する、あなたのパッチをチェックする、またはその他のことなど）を明確に述べることで、有用な回答を得る可能性が最も高くなります。なぜなら、これにより、回答者があなたを助けるために集中できる時間と労力の上限が設定されるからです。これは素晴らしいことです。

専門家が置かれている世界を理解するために、専門的なスキルを豊富な資源と考え、返信にかかる時間を希少な資源と考えてください。彼らに奉仕する時間を少なく要求すればするほど、真に専門的で非常に忙しい専門家から回答を得る可能性が高くなります。

したがって、あなたの問題を定義し、専門家があなたの問題を特定し、回答するために必要な時間を最小限に抑えることができれば、これは有用な回答を得るのに非常に役立ちます -- しかし、このテクニックは通常、問題を簡素化することとは異なります。したがって、「私は X をよりよく理解したいのですが、どこに良い説明がありますか？」と尋ねることは、「X を説明してもらえますか？」と尋ねるよりも通常は良いです。あなたのコードが機能しない場合、他の人にどこに問題があるかを見てもらうように頼むことは、他の人に修正を求めるよりも賢明です。

コードに関する質問をする際#

他の人に問題のあるコードをデバッグするのを手伝ってもらうことを求めないでください。どこから始めるべきかを示さずに、数百行のコードを投稿して「動かない」と言うことは、完全に無視されることになります。数行のコードを投稿し、「7 行目以降でが表示されることを期待していますが、実際にはが表示されます」と言う方が、応答を得る可能性が高くなります。

プログラムの問題を最も効果的に説明する方法は、最も簡潔なバグデモテストケース（bug-demonstrating test case）を提供することです。最も簡潔なテストケースとは、問題の縮図です；プログラムの異常な動作をちょうど示す小さなプログラムの断片であり、他の気を散らす内容を含まないものです。最も簡潔なテストケースを作成するには、異常な動作を引き起こす行またはセクションを知っている場合、それをコピーし、その状況を再現するのに十分なコードを追加します（たとえば、そのコードがコンパイル / 解釈 / アプリケーションで処理されるのに十分です）。問題を特定のセクションに縮小できない場合は、コードをコピーして、問題の動作を引き起こさない部分を削除します。要するに、テストケースは小さければ小さいほど良いです（[精度が重要][51] のセクションを参照）。

一般的に、かなり簡潔なテストケースを得ることは簡単ではありませんが、常に最初にこれを試みることは良い習慣です。この方法は、あなたが問題を自分で解決する方法を理解するのに役立ちます -- そして、たとえあなたの試みが成功しなくても、ハッカーはあなたが答えを得るために努力していることを見て、より協力的になるでしょう。

もしあなたが他の人にコードをレビューしてもらいたいだけなら、メールの冒頭でそれを言い、特にどの部分に注目してほしいか、なぜそれが重要なのかを必ず言及してください。

宿題の問題を投稿しない#

ハッカーは、どの問題が宿題のような問題であるかを見分けるのが得意です。なぜなら、私たちのほとんどはこのような問題を自分で解決した経験があるからです。同様に、これらの問題はあなたが解決する必要があります。あなたはそこから学ぶことができます。ヒントを求めることはできますが、完全な解決策を求めないでください。

もしあなたが宿題のような問題に直面しているのではないかと疑っているが、それでも解決できない場合は、ユーザーグループ、フォーラム、または（最後の手段として）プロジェクトのユーザーメールリストやフォーラムで質問してみてください。ハッカーは気づくでしょうが、経験豊富なユーザーがいくつかのヒントを提供してくれるかもしれません。

無意味な質問文を排除する#

無意味な言葉で質問を終えることを避けてください。たとえば、「誰か助けてくれますか？」や「これに答えはありますか？」などです。

まず第一に：もしあなたの問題の説明があまり良くない場合、そう尋ねることはさらに蛇足です。

第二に：このように尋ねることは蛇足であるため、ハッカーはあなたに非常に嫌悪感を抱きます -- そして通常は論理的に正しいが無意味な回答で彼らの軽蔑を示します。たとえば、「はい、誰かがあなたを助けることができます」や「いいえ、答えはありません」といった具合です。

一般的に、はいまたはいいえ、正しいまたは間違っている、あるまたはないのような質問を避けてください。あなたが [はいまたはいいえの回答][52] を得たい場合を除いて。

たとえ急いでいても、タイトルに「緊急」と書かない#

これはあなたの問題であり、私たちの問題ではありません。「緊急」と宣言することは、ほとんどの場合、逆効果です。ほとんどのハッカーは、無礼で自己中心的に即座に注意を引こうとする問題を直接削除します。さらに深刻なのは、「緊急」という言葉（または他の注意を引こうとするタイトル）は、スパムフィルターによってフィルタリングされることがよくあります -- あなたの問題を見たい人は、永遠にそれを見ることができないかもしれません。

半分の例外があります。もしあなたが非常に目立つ場所にいて、ハッカーを興奮させるような場合、そうする価値があるかもしれません。この場合、時間的なプレッシャーがある場合は、それを礼儀正しく言及することができ、他の人々は迅速に回答することに興味を持つかもしれません。

もちろん、これは非常にリスクが高いです。なぜなら、ハッカーが興奮するポイントは、あなたのものとは異なることが多いからです。たとえば、NASA の国際宇宙ステーション（International Space Station）からこのようなタイトルを発信することには問題ありませんが、自分の気分が良い慈善行為や政治的理由で発信することは間違いなく問題です。実際、「緊急：この毛むくじゃらのアザラシを救ってください！」のような投稿は、ハッカーに無視されるか、彼らを怒らせることになります。たとえ彼らが毛むくじゃらのアザラシが重要だと考えていても。

もしあなたがこれが信じられないのであれば、このガイドの残りの内容をもう一度読み返し、理解するまで待ってから投稿してください。

礼儀正しさは重要であり、時には役立つ#

礼儀正しく、「お願いします」や「ご関心をお持ちいただきありがとうございます」や「ご配慮ありがとうございます」といった言葉を多く使ってください。誰もがあなたが彼らの時間を無償で提供してくれることに感謝していることを知っていると良いでしょう。

率直に言って、この点は明確で正確、正確な文法を使用し、特定の形式を避けることよりも重要ではありません（また、これに取って代わることもできません）。ハッカーは、少し唐突でも技術的に明確なバグレポートを読むことを好む傾向がありますが、礼儀正しいが曖昧なレポートは好まれません。（この点が理解できない場合は、私たちが問題が私たちに何を教えてくれるかによって問題の価値を評価することを思い出してください）

しかし、もしあなたが解決すべき問題のリストを持っている場合、少し礼儀正しくすることで、有用な応答を得る可能性が高くなります。

（私たちは、このガイドが公開されて以来、経験豊富なハッカーから得られた唯一の重大なフィードバックは、事前に感謝の意を表することに関するものであることに気づきました。一部のハッカーは「先に感謝する」ということが、事後に感謝しないことを暗示していると感じています。私たちの提案は、最初に「先に感謝します」と言い、その後返信者に感謝の意を表すか、感謝を表現する別の方法を使用することです。たとえば、「ご関心をお持ちいただきありがとうございます」や「ご配慮ありがとうございます」といった表現です。）

問題が解決した後、簡単なフォローアップを追加する#

問題が解決した後、あなたを助けてくれたすべての人に説明を送信し、問題がどのように解決されたかを知らせ、再度感謝の意を表してください。問題がニュースグループやメールリストで広く関心を引いた場合、そこで説明を投稿するのが適切です。

最も理想的な方法は、最初の質問のトピックにこのメッセージを返信し、タイトルに「修正済み」、「解決済み」またはその他の同等の意味の明確なマークを含めることです。人が行き交うメールリストでは、潜在的な返信者は「問題 X」と「問題 X - 修正済み」を見れば、再度時間を浪費する必要がないことを理解します（彼が個人的に「問題 X」に興味を持っている場合を除いて）。

フォローアップは長くても深くなくても構いません。単に「こんにちは、実はネットワークケーブルに問題がありました！皆さん、ありがとうございます – Bill」といった一言が、何も言わないよりも良いです。実際、結論が本当に技術的でない限り、短くて魅力的な要約の方が長文よりも良いです。問題がどのように解決されたかを説明し、解決策のプロセスを繰り返す必要はありません。

深い問題に対しては、デバッグ記録の要約を投稿することが役立ちます。問題の最終状態を説明し、何が問題を解決したのかを示し、その後に回避すべき盲点を指摘します。盲点を避ける部分は、正しい解決策や他の要約資料の後に配置し、この情報を探偵小説のようにする必要はありません。あなたを助けてくれた人々の名前を挙げることで、より多くの友人を得ることができます。

礼儀正しさと内容のあることに加えて、この種のフォローアップは、メールリスト / ニュースグループ / フォーラムで他の人々があなたの問題を解決するための実際の解決策を検索するのに役立ち、彼らもそれから利益を得ることができます。

少なくとも、このフォローアップは、問題の解決によってすべての協力者が満足感を得るのに役立ちます。もしあなたが技術的な専門家やハッカーでないなら、私たちを信じてください。この感覚は、あなたが助けを求めたマスターや専門家にとって非常に重要です。問題が未解決のままであることは人々を落胆させます。ハッカーは問題が解決されるのを見たいと切望しています。良い人には良い報いがあり、彼らの渇望を満たすことで、次回の質問時に甘い思いをすることができます。

他の人が将来同様の問題に直面するのを避ける方法を考え、ドキュメントを書くことや FAQ を追加することが役立つかどうか自問してください。もしそうであれば、それをメンテナに送信してください。

ハッカーの間では、この良いフォローアップは実際には伝統的な礼儀よりも重要であり、他人を大切にすることで評判を得る方法であり、これは非常に価値のある資産です。

答えを解釈する方法#

RTFM と STFW：あなたが完全にやらかしたかどうかを知る方法#

古くて神聖な伝統があります：もしあなたがRTFM（Read The Fucking Manual）という返答を受け取った場合、回答者はあなたが彼のマニュアルを読むべきだと考えています。もちろん、基本的に彼は正しいです。あなたは読んでみるべきです。

RTFM には若い親戚がいます。もしあなたがSTFW（Search The Fucking Web）という返答を受け取った場合、回答者はあなたが彼のマニュアルをオンラインで検索すべきだと考えています。その人もおそらく正しいです。検索してみてください。（より穏やかな言い方は **[Google はあなたの友人です][53]**！）

フォーラムでは、古い文書を検索するように求められることもあります。実際、誰かが以前にこの問題を解決したディスカッションスレッドを親切に提供してくれるかもしれません。しかし、このような配慮に依存しないでください。質問する前に古い文書を検索するべきです。

通常、これらのいずれかであなたに返答する人は、あなたが必要な内容を含むマニュアルやウェブサイトを提供してくれるでしょう。そして、彼らがこれらの単語を打っているとき、彼らもそれを読んでいます。これらの回答は、回答者が

あなたが必要な情報を非常に簡単に入手できると考えている；
あなた自身で情報を検索する方が、与えられるよりも多くのことを学ぶことができると考えている。

あなたはこれに不満を抱くべきではありません；ハッカーの基準に従って、彼はあなたに対して一定の関心を示し、あなたの要求を無視していないのです。彼の祖母のような優しさに感謝すべきです。

もしまだ理解できない場合#

もしあなたが返答を理解できない場合、すぐに相手に説明を求めないでください。以前に自分で問題を解決しようとしたときと同じように（マニュアル、FAQ、ウェブ、身近な専門家を利用して）、まず彼の返答を理解しようとしてください。もし本当に相手に説明を求める必要がある場合は、あなたが何かを学んだことを示してください。

たとえば、もし私があなたに「zentry が詰まっているようです。まずそれをクリアしてください」と答えた場合、これは非常に悪いフォローアップの質問です。「zentry とは何ですか？」という質問は良い質問ではありません。良い質問はこうです：「ああ～～～説明書を見ましたが、-z と - p の 2 つのパラメータしか zentry に言及されておらず、どちらもそれをクリアする方法を明確に説明していません。あなたはこの 2 つのうちのどちらを指しているのですか？それとも私が見逃した何かがありますか？」

無礼な返答に対処する#

多くのハッカーのコミュニティでは、無礼に見える行動は必ずしも意図的な侮辱ではありません。むしろ、それは直接的で、率直なコミュニケーションスタイルであり、問題を解決することに重点を置いています。人々の気持ちを快適にすることや曖昧さを避けることよりも、問題を解決することが優先されます。

もしあなたが侮辱されたと感じた場合、冷静に反応してみてください。もし誰かが本当に行き過ぎたことをした場合、メールリスト、ニュースグループ、またはフォーラムの先輩が彼を注意することが多いです