はじめに
ハッカーの世界では、技術的な質問を投げかけたとき、有用な回答が得られるかどうかは、質問とその後の問い合わせの方法にかかっています。このガイドでは、満足のいく回答を得るために正しく質問する方法を教えます。
ハッカーだけでなく、現在オープンソースソフトウェアはかなり普及しており、経験豊富なユーザーから良い回答を得ることができます。これは良いことです。ユーザーはハッカーよりも、初心者が直面する問題に対してより寛容な傾向があります。しかし、経験豊富なユーザーをハッカーと見なし、このガイドで提案されている方法で彼らとコミュニケーションをとることは、満足のいく回答を得るための最も効果的な方法です。
まず、ハッカーは挑戦的な問題や、彼らの思考を刺激する良い質問を好むことを理解すべきです。もし私たちがそうでなければ、私たちはあなたが尋ねたい相手にはならなかったでしょう。もし私たちに咀嚼し味わう価値のある良い質問をすれば、私たちは感謝するでしょう。良い質問は励みであり、贈り物です。良い質問は私たちの理解力を高め、通常、私たちが以前認識していなかったり考えたりしなかった問題を明らかにします。ハッカーにとって、「良い質問！」は心からの大きな称賛です。
それでも、ハッカーは単純な問題を軽蔑したり傲慢に扱うという悪い評判を持っています。これは時々、私たちが初心者や無知な人々に対して敵対的に見えることを意味しますが、実際はそうではありません。
私たちは、考えようとしない人々や、質問する前にすべきことをしない人々に対する軽蔑を隠しません。そのような人々は時間の浪費者です。彼らはただ求めるだけで、決して与えず、より興味深い問題や回答に値する人々に使える時間を消費します。私たちはそのような人々を敗者（ルーザー）と呼びます（歴史的な理由から、時々lusersと綴ります）。
私たちは、多くの人が単に私たちが書いたソフトウェアを使用したいだけで、技術的な詳細を学ぶことに興味がないことを理解しています。大多数の人にとって、コンピュータは単なるツールであり、目的を達成するための手段です。彼らには自分の生活があり、より重要なことがあります。私たちはこれを理解しており、私たちを魅了する技術的な問題に全員が興味を持つことを期待していません。それでも、私たちの質問への回答スタイルは、本当に興味を持ち、問題解決に積極的に参加しようとする人々に向けられています。これは変わらず、変わるべきでもありません。これが変われば、私たちは最も得意なことでの効率を下げることになります。
私たちは（大部分において）ボランティアであり、忙しい生活から時間を割いて疑問に答え、しばしば質問に圧倒されます。だからこそ、私たちはいくつかのトピックを容赦なくフィルタリングし、特に敗者のように見える人々を排除して、勝者（winner）の質問に答えるために時間をより効率的に使います。
もし私たちの態度が嫌なら、高慢であったり、傲慢すぎたりするなら、私たちの立場に立って考えてみてください。私たちはあなたが私たちに屈服することを要求していません。実際、私たちのほとんどは、基本的な要件を満たすために少し努力すれば、あなたと対等に交流することを喜んでいます。しかし、自分自身を助けようとしない人々を助けることは効率的ではありません。無知は問題ありませんが、愚か者を装うことは許されません。
だから、私たちの注意を引くために技術的に熟練している必要はありませんが、熟練するように導く資質を示す必要があります。機敏さ、アイデア、観察力、問題解決に積極的に参加する意欲です。もしこれらの違いを生むことができないなら、ハッカー個人に無償で助けを求めるのではなく、お金を払って商業会社と技術サポート契約を結ぶことをお勧めします。
私たちに助けを求めることを決めたなら、もちろん敗者として見られたくないし、敗者の一員になりたくないでしょう。迅速で効果的な回答をすぐに得るための最良の方法は、勝者のように質問することです。賢く、自信を持ち、問題解決のアプローチを持ち、特定の問題で時々少しの助けが必要なだけです。
（このガイドへの改善提案を歓迎します。提案をesr@thyrsus.comまたはrespond-auto@linuxmafia.comにメールしてください。ただし、この記事はネットエチケットの一般的なガイドではなく、技術フォーラムで有用な回答を得るのに役立たない提案は通常拒否されます。）
質問する前に
電子メール、ニュースグループ、またはチャットルームで技術的な質問をする準備をする前に、以下のことを行ってください：
- 質問しようとしているフォーラムの過去の記事で回答を検索してみてください。
- インターネットで検索して回答を見つけてみてください。
- マニュアルを読んで回答を見つけてみてください。
- よくある質問ファイル（FAQ）を読んで回答を見つけてみてください。
- 自分でチェックまたは実験して回答を見つけてみてください。
- 近くの熟練した友人に聞いて回答を見つけてみてください。
- プログラム開発者であれば、ソースコードを読んで回答を見つけてみてください。
質問するときは、上記の努力をしたことを示してください。これは、あなたがただ利益を得ようとするだけで他人の時間を無駄にする質問者ではないことを確立するのに役立ちます。上記の努力の過程で学んだことを一緒に表現できれば、さらに良いです。私たちは回答から学ぶ能力を示す人々の質問に喜んで答えるからです。
いくつかの戦略を使用してください。たとえば、Googleで遭遇した様々なエラーメッセージを検索する（Googleグループとウェブページの両方を検索）。これにより、問題を解決できるドキュメントやメーリングリストの手がかりが直接見つかる可能性があります。結果がなくても、メーリングリストやニュースグループで助けを求める際に「Googleで次の文を検索しましたが、有用なものは見つかりませんでした」と付け加えることは良いことです。これは検索エンジンがどのような助けを提供できないかを示すだけかもしれません。これを行う（検索した文字列を追加する）ことで、同様の問題に遭遇した他の人々があなたの質問に検索エンジンから導かれるようになります。
急がないでください。数秒のGoogle検索で複雑な問題が解決できるとは期待しないでください。専門家に助けを求める前に、よくある質問ファイル（FAQ）をもう一度読み、リラックスして、快適に座り、この問題についてもう少し時間をかけて考えてください。信じてください、彼らはあなたの質問からあなたがどれだけ読み、考えたかを見ることができます。準備をしてくれば、回答を得る可能性が高くなります。最初の検索で回答が見つからなかった（または回答が多すぎた）からといって、すべての質問を一度に投げ出さないでください。
質問を準備し、注意深く考え直してください。性急な質問は性急な回答しか得られないか、まったく回答が得られないからです。助けを求める前に問題解決のために払った努力を示せば示すほど、実質的な助けを得る可能性が高くなります。
間違った質問をしないように注意してください。もし質問が間違った仮定に基づいているなら、ある普通のハッカー（J. Random Hacker）は心の中で愚かな質問...と思いながら、無意味な文字通りの解釈で答えるでしょう。あなたが質問の回答（得たい回答ではなく）から教訓を得ることを期待して。
答えを得る資格があると決して思い込まないでください。あなたにはありません。結局のところ、このサービスに対して報酬を支払っていません。あなたは答えを稼ぐことになります。内実のある、興味深い、思考を刺激する質問をすることによって。コミュニティの経験に貢献する可能性のある質問であり、他人から知識を受動的に求めるだけではありません。
一方、答えを見つける過程で何かをしようとする意欲を示すことは非常に良いスタートです。「誰かヒントをいただけますか？」「この例で何が欠けていますか？」「どこをチェックすべきですか？」は「必要な正確なプロセスを投稿してください」よりも回答を得やすいです。誰かが正しい方向を指し示してくれれば、それを完了する能力と決意があることを示しているからです。
質問するとき
質問するフォーラムを慎重に選ぶ
質問する場を慎重に選んでください。以下のことをすると、無視されたり敗者と見なされたりする可能性があります：
- トピックに合わないフォーラムに質問を投稿する。
- 高度な技術的問題を議論するフォーラムに非常に初歩的な質問を投稿する。逆も同様。
- 多くの異なるニュースグループに同じ質問を繰り返しクロスポストする。
- 知人でもなく、問題を解決する義務もない人に個人的なメールを送る。
ハッカーは、コミュニケーションのチャネルを無関係なもので溢れさせないように保護するために、場違いな質問を排除します。あなたは自分にこのようなことが起きてほしくないでしょう。
したがって、最初のステップは適切なフォーラムを見つけることです。もう一度言いますが、Googleや他の検索エンジンはあなたの友達です。それらを使って、直面しているハードウェアやソフトウェアの問題に最も関連するウェブサイトを見つけてください。通常、そこにはよくある質問（FAQ）、メーリングリスト、関連ドキュメントへのリンクがあります。もし努力（FAQを読むことを含む）が結果をもたらさない場合、ウェブサイトにはバグ報告（Bug-reporting）のプロセスやリンクがあるかもしれません。その場合、そこに行ってみてください。
見知らぬ人やフォーラムにメールを送ることは最もリスクの高いことかもしれません。たとえば、豊富なコンテンツを提供するウェブページの著者が無料のコンサルタントになりたいとは思わないでください。質問が歓迎されるかどうかを楽観的に推測しないでください。確信がない場合は、別の場所に送るか、まったく送らないでください。
フォーラム、ニュースグループ、またはメーリングリストを選ぶ際、名前をあまり信じないでください。まずFAQや許可書を見て、質問がトピックに関連しているかどうかを確認してください。投稿する前に既存のトピックをざっと見て、そこでの文化を感じ取ってください。実際、事前にニュースグループやメーリングリストの履歴で質問に関連するキーワードを検索するのは非常に良いアイデアです。これで回答が見つかるかもしれません。見つからなくても、より良い質問をまとめるのに役立ちます。
機関銃のように一度にすべてのヘルプチャネルを「スキャン」しないでください。これは叫ぶように不快です。一つずつ進めてください。
トピックを明確にしてください！最も典型的な間違いの一つは、クロスプラットフォームの移植性に専念している言語、パッケージ、またはツールのフォーラムで、UnixやWindowsオペレーティングシステムのプログラムインターフェースに関する質問をすることです。なぜこれが大きな間違いなのかわからない場合は、その違いを理解するまで何も聞かない方が良いでしょう。
一般的に、慎重に選ばれた公開フォーラムで質問する方が、プライベートフォーラムで同じ質問をするよりも有用な回答を得やすいです。これを支持するいくつかの理由があります。潜在的な回答者の数、視聴者の数です。ハッカーは多くの人々を助けることができる質問に答える意欲が高いです。
理解できることですが、熟練したハッカーや人気のあるソフトウェアの著者は、過剰な誤送信を受け取っています。ラクダの背中を折る最後の藁のように、あなたの参加も状況を極端に進める可能性があります。すでに何度も、人気のあるソフトウェアの著者が自分のソフトウェアのサポートから身を引いています。伴って流入する無駄なメールが耐え難くなったからです。
Stack Overflow
検索し、それからStack Exchangeで質問する。
近年、Stack Exchangeコミュニティは技術やその他の質問に回答する主要なチャネルとなり、特にオープンソースプロジェクトにとって重要です。
Googleのインデックスは即時なので、Stack Exchangeを見る前にGoogleで検索してください。誰かが同様の質問をしている可能性が高く、Stack Exchangeサイトは検索結果の最上位に表示されることが多いです。Googleで回答が見つからない場合は、特定の関連トピックのサイトに行ってください。タグ（Tag）検索を使うと、検索結果をさらに絞り込むことができます。
Stack Exchangeは100以上のサイトに成長しました。以下は最もよく使われるサイトです：
- 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モデルだけですか？ハッカーは一目見るだけで、あなたの環境と遭遇した問題を即座に理解できます。
要するに、タイトルのみを表示するアーカイブされたスレッド（Thread）インデックスで検索していると想像してください。タイトルをより良く問題を反映させることで、次に同様の問題を検索する人がこのスレッドに注目でき、同じ質問を再びする必要がなくなります。
返信で質問したい場合、コンテンツのタイトルを変更して、質問をしていることを示すことを忘れないでください。「Re: テスト」や「Re: 新しいバグ」のようなタイトルは十分な注意を引くのが難しいです。また、一貫性を損なわない範囲で、前文の内容を適切に引用し、削減することで、新しく来た読者に手がかりを残すことができます。
スレッドについては、返信をクリックして全く新しいスレッドを開始しないでください。これは視聴者を制限します。一部のメールリーダープログラム（muttなど）は、ユーザーがスレッドで並べ替え、スレッドを折りたたんでメッセージを非表示にすることができるからです。これを行う人はあなたのメッセージを決して見ません。
タイトルを変更するだけでは不十分です。muttや他のメールリーダープログラムは、スレッドを指定するためにタイトル以外の情報もチェックします。したがって、全く新しいメールを送る方が良いです。
ウェブフォーラムでは、良い質問方法は少し異なります。スレッドは特定の情報と密接に結びついており、通常スレッド外ではその中のコンテンツが見えないため、タイトルを変更せずに返信で質問することは許容されます。すべてのフォーラムが返信で分離されたタイトルを許可するわけではなく、これを行っても基本的に誰も見ません。ただし、返信で質問すること自体が曖昧な做法です。なぜなら、それらはそのタイトルを見ている人だけに読まれるからです。したがって、そのスレッドで現在アクティブな人々にだけ質問したい場合を除き、別のスレッドを始める方が良いです。
質問に返信しやすくする
「あなたの返信を…に送ってください」で質問を終えると、回答が得られない可能性が高いです。メールクライアントで返信アドレスを設定するのに数秒かけるのが面倒なら、私たちもあなたの質問を考えるのに数秒かけるのはもっと面倒です。メールプログラムがこれをサポートしていない場合は、より良いものに変えてください。オペレーティングシステムがこのようなメールプログラムをサポートしていない場合も、より良いものに変えてください。
フォーラムでは、電子メールでの返信を要求することは非常に失礼です。返信情報が敏感である可能性があると考える場合を除きます（何らかの未知の理由で、フォーラム全体ではなく、あなただけに答えを知らせたい人もいます）。誰かがスレッドに返信したときに電子メール通知を受け取りたいだけなら、ウェブフォーラムに送信を要求できます。ほぼすべてのフォーラムが「このスレッドを追跡」、「返信があるときにメール通知を送信」などの機能をサポートしています。
明確で、正確で、正確な文法を使用する
経験から、不注意な質問者は通常、不注意にプログラムを書き、考えることがわかっています（保証します）。不注意な人々の質問に答える価値はなく、時間を別の場所で過ごす方が良いです。
正しいスペル、句読点、大文字と小文字は重要です。一般的に、これが面倒で気にしたくないなら、私たちもあなたの質問を気にするのは面倒です。言葉を少し余分に考慮してください。硬すぎたり正式すぎたりする必要はありません。実際、ハッカー文化は非公式、スラング、ユーモラスな表現を正確に使用することを高く評価しています。しかし、それは非常に正確でなければならず、あなたが考え、問題に注目している兆候が必要です。
スペル、句読点、大文字と小文字を正しく使用してください。「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.
- もしあなたがある言語を話すなら、メール/プライベートメッセージを送ってください。質問を翻訳するのに支援が必要です。
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を無効にするのは難しくありません）。
- MIME添付ファイルは通常許容されますが、実際にコンテンツがある場合（添付のソースコードやパッチなど）、メールプログラムが生成したテンプレート（単に手紙の内容のコピーなど）ではない場合に限ります。
- 一行の文が自動的に折り返されて複数行になるメールを送らないでください（これにより、コンテンツの一部に返信するのが非常に困難になります）。読者が80文字幅の端末でメールを読んでいると想定し、折り返し点を80文字未満に設定するのが最善です。
- ただし、特別なファイル（ログファイルのコピーやセッション記録など）については固定幅を設定しないでください。データはそのまま含め、回答者があなたと同じものを見ているという確信を持てるようにしてください。
- 英語フォーラムでは、
Quoted-PrintableMIMEエンコーディングでメッセージを送らないでください。このエンコーディングは非ASCII言語の投稿に必要かもしれませんが、多くのメールプログラムはこのエンコーディングをサポートしていません。改行を処理するとき、テキスト中に散らばる=20記号は見苦しく、気を散らし、コンテンツの意味を損なう可能性さえあります。 - 絶対に、永遠に、ハッカーが閉じた形式で書かれたドキュメント（マイクロソフトのWordやExcelファイルなど）を読むことを期待しないでください。ほとんどのハッカーの反応は、誰かがまだ熱を帯びた豚の糞をあなたの玄関に投げたときのあなたの反応と同じです。たとえ処理できても、彼らはこれを行うことを嫌います。
- Windowsを使用するコンピュータからメールを送信する場合、マイクロソフトの愚かな「スマートクォート」機能を無効にしてください（[オプション] > [校正] > [オートコレクトオプション]から、「スマートクォート」チェックボックスをオフにします）。メール中にゴミ文字が散らばるのを防ぐためです。
- フォーラムでは、「絵文字」や「HTML」機能を濫用しないでください（提供されている場合）。1つか2つの絵文字は通常問題ありませんが、派手な色付きテキストはあなたを無能な人だと見なす傾向があります。絵文字、色、フォントを過剰に使用すると、あなたはニヤニヤ笑う少女のように見えます。これは通常良いアイデアではありません。答えではなくセックスに興味がある場合を除きます。
グラフィカルユーザーインターフェースのメールプログラム（マイクロソフトのOutlookやその他の類似のもの）を使用する場合、それらのデフォルト設定がこれらの要件を満たしていない可能性があることに注意してください。ほとんどのこのようなプログラムには、メニューベースの「ソースコードを表示」コマンドがあります。これを使って送信フォルダのメールをチェックし、プレーンテキストファイルが送信され、奇妙な文字がないことを確認してください。
問題を正確に説明し、内容があるようにする
- 問題やバグの症状を注意深く、明確に説明してください。
- 問題が発生した環境（マシン構成、オペレーティングシステム、アプリケーション、関連情報）を説明し、ディストリビューターのディストリビューションとバージョン番号（例：「Fedora Core 4」、「Slackware 9.1」など）を提供してください。
- 質問する前に、どのようにこの問題を研究し、理解したかを説明してください。
- 質問する前に問題を特定するために取った診断ステップを説明してください。
- 最近行った可能性のあるハードウェアまたはソフトウェアの変更を説明してください。
- 可能な限り、「この問題を再現できる制御された環境」を提供する方法を提供してください。
ハッカーがあなたにどのように反問するかを推測し、質問する前にハッカーが遭遇する可能性のある質問に事前に答えてください。
以上の点の中で、コードにあると思われる問題を報告する場合、ハッカーに問題を再現できる環境を提供することは特に重要です。これを行うと、有効な回答を得る機会と速度が大幅に向上します。
Simon Tathamは「効果的にバグを報告する方法」という優れた記事を書きました。強くお勧めします。
多くではなく正確に
正確で内容のある情報を提供する必要があります。これは、大量のエラーコードや資料を完全に質問に転記することを要求するものではありません。プログラムがクラッシュする状況を再現できる膨大で複雑なテストケースがある場合、できるだけ小さく剪定してください。
これには少なくとも3つの利点があります。 第一、問題を簡素化する努力をしたことを示し、回答を得る機会が増えます。 第二、問題を簡素化することで、有用な回答を得る可能性が高くなります。 第三、バグレポートを精練する過程で、自分で解決策や回避策を見つける可能性があります。
バグを見つけたと主張しない
ソフトウェアを使用中に問題に遭遇した場合、非常に、非常に確信がない限り、バグを見つけたと主張しないでください。ヒント：問題を解決するソースコードのパッチを提供できるか、前のバージョンで動作が正しくなかったことを示す回帰テストを提供できない限り、完全に確信しているとは言えません。これはウェブページやドキュメントにも適用されます。ドキュメントの「バグ」を（主張して）見つけた場合、対応する場所の修正または代替ドキュメントを提供できるはずです。
他の多くのユーザーがあなたが見つけた問題に遭遇していないことを覚えておいてください。そうでなければ、ドキュメントを読んだりウェブページを検索したりしたときに見つかっていたはずです（不満を言う前にこれらを行いましたよね？）。これは、ソフトウェア自体に問題があるのではなく、あなたが間違っている可能性が高いことを意味します。
ソフトウェアを書く人々は、それを可能な限り完璧にするために非常に努力しています。バグを見つけたと主張すると、彼らの能力を疑うことになり、たとえあなたが正しくても、一部の人々を怒らせる可能性があります。タイトルで「バグ」があると叫ぶとき、これは特に深刻です。
質問するとき、たとえ個人的に本当のバグを見つけたと確信していても、あなたが何か間違ったことをしたかのように書くのが最善です。本当にバグがあれば、回答でそれがわかります。これを行うと、本当にバグがあれば、メンテナーはあなたに謝罪します。これは、他人を怒らせてから謝罪を負うよりも少し良いです。
卑屈さは宿題の代わりにはならない
一部の人々は、無礼に質問したり傲慢に回答を要求したりすべきではないと理解していますが、別の極端を選びます。卑屈になることです：「私はただの惨めな初心者、敗者ですが…」。これは人を悩ませ、役に立たず、特に実際の問題の曖昧な説明を伴うと、さらに不快です。
原始的な霊長類のトリックであなたと私の時間を無駄にしないでください。代わりに、背景条件と問題の状況をできるだけ明確に説明してください。これは卑屈になるよりも、あなたの位置をより良く特定します。
時には、ウェブフォーラムには初心者のための質問セクションがあります。本当に初心者の問題に遭遇したと思うなら、そこに行けばいいですが、同じように卑屈にならないでください。
問題の症状を説明し、推測を述べない
ハッカーに問題の原因が何だと思うかを伝えることはあまり役に立ちません。（あなたの推論がそれほど有効なら、他人に助けを求める必要がありますか？）したがって、問題の症状をそのまま伝え、あなたの解釈や理論ではなく、ハッカーに推測と診断をさせてください。自分の推測を述べることが重要だと思う場合、それが単なる推測であることを明確にし、なぜそれらが機能しないのかを説明してください。
愚かな質問
カーネルをコンパイル中に連続して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を説明していただけますか？」と尋ねるよりも良いです。コードが動作しない場合、通常、他人にどこに問題があるかを見てもらうことは、他人に修正してもらうことを要求するよりも賢明です。
コードに関する質問をするとき
問題のあるコードのデバッグを手伝ってくれるように他人に要求しないでください。どこから始めるべきかのヒントなしに。数百行のコードを投稿し、「動作しません」と言うと、完全に無視されます。数十行のコードを投稿し、「7行目以降、
プログラムの問題を説明する最も効果的な方法は、最も簡潔なバグデモンストレーションテストケース（bug-demonstrating test case）を提供することです。最も簡潔なテストケースとは何ですか？それは問題の縮図です。プログラムの異常な動作をちょうど示す小さなプログラムフラグメントであり、他の気を散らすコンテンツを含みません。最も簡潔なテストケースを作成するには？どの行またはコードのセグメントが異常な動作を引き起こすかを知っている場合、それをコピーし、この状況を再現するのに十分なコード（このコードをコンパイル/解釈/アプリケーションで処理できるなど）を追加します。問題を特定のブロックに縮小できない場合、コードのコピーを作成し、問題の動作を生成しない部分を削除します。とにかく、テストケースは小さいほど良いです（多くではなく正確にのセクションを参照）。
一般的に、かなり簡潔なテストケースを得るのはそれほど簡単ではありませんが、常に最初にこれを試みるのは良い習慣です。この方法は、自分でこの問題を解決する方法を理解するのに役立ちます。また、試みが成功しなくても、ハッカーはあなたが回答を得るために努力していることを見て、より協力的になるでしょう。
単にコードをレビューしてもらいたい場合、手紙の冒頭でそれを言い、特にどの部分に注目すべきか、そしてなぜかを必ず言及してください。
宿題の質問を投稿しない
ハッカーは、どの質問が宿題の質問であるかを区別するのが得意です。私たちのほとんどは、このような問題を自分で解決したことがあるからです。同様に、これらの問題はあなたが解決すべきであり、そこから学ぶことができます。ヒントを求めることはできますが、完全な解決策を求めないでください。
宿題の質問に遭遇したと疑っているが、まだ解決できない場合、ユーザーグループ、フォーラム、または（最後の手段として）プロジェクトのユーザーメーリングリストまたはフォーラムで質問してみてください。ハッカーは気づきますが、一部の経験豊富なユーザーはまだヒントを与えるかもしれません。
無意味な質問文を削除する
「誰か助けてくれませんか？」や「これに答えはありますか？」などの無意味な言葉で質問を終えることを避けてください。
第一に、問題の説明があまり良くない場合、このような質問はさらに蛇足です。
第二に、このような質問は蛇足であるため、ハッカーはあなたを嫌い、通常、論理的には正しいが無意味な回答で軽蔑を示します。例えば：「はい、誰かがあなたを助けることができます」または「いいえ、答えはありません」。
一般的に、「はいまたはいいえ」、「正しいまたは間違い」、「あるまたはない」タイプの質問を避けてください。はいまたはいいえタイプの回答が欲しい場合を除きます。
たとえ急いでいてもタイトルに「緊急」と書かない
これはあなたの問題であり、私たちの問題ではありません。「緊急」と主張することは、逆効果になる可能性が非常に高いです。ほとんどのハッカーは、無礼で利己的に即座に注目を引こうとする質問を直接削除します。さらに深刻なことに、「緊急」という言葉（または他の注目を引こうとするタイトル）は通常、スパムフィルターによってフィルタリングされます。あなたの質問を見たい人が永遠に見られない可能性があります。
半分の例外は、あなたが非常に高調で、ハッカーを興奮させる場所にいる場合、これを行う価値があるかもしれません。このような場合、時間のプレッシャーがあり、礼儀正しくこれに言及すれば、人々はより早く回答することに興味を持つかもしれません。
もちろん、これはリスクが高いです。ハッカーが興奮する点は、あなたとは異なる可能性が高いからです。例えば、NASA国際宇宙ステーションからこのようなタイトルを送るのは問題ありませんが、自己満足の慈善行為や政治的理由で送るのは確実にいけません。実際、「緊急：この毛むくじゃらのアザラシを助けて！」のような投稿は、ハッカーに無視されるか、彼らを怒らせます。たとえ彼らが毛むくじゃらのアザラシが重要だと考えても。
この点が信じられないと思うなら、このガイドの残りの内容を理解するまで何度も読み直すのが最善です。
礼儀正しさは人を嫌がらせないし、時には非常に役立つ
礼儀正しく、「ください」と「ご関心ありがとうございます」、または「ご配慮ありがとうございます」を多用してください。彼らが無料で時間を割いて助けを提供してくれたことに感謝していることを皆に知らせてください。
率直に言って、この点は、明確で、正確で、正確な文法を使用し、専用形式を避けることよりも重要ではありません（また、それに取って代わるものでもありません）。ハッカーは通常、少し唐突だが技術的に鮮明なバグレポートを読むことを好みます。礼儀正しいが曖昧なレポートよりも。（この点が理解できない場合、私たちは質問が私たちに何を教えてくれるかで質問の価値を評価することを覚えておいてください。）
しかし、一連の問題を解決する必要がある場合、礼儀正しくすることは有用な回答を得る機会を確実に増やします。
（このガイドが公開されて以来、熟練したハッカーから得た唯一の重大な欠陥フィードバックは、事前の感謝についてであることに注意してください。一部のハッカーは「事前にありがとう」という言葉が、事後に誰にも感謝しなくていいという暗示を意味すると感じています。私たちの提案は、「事前にありがとう」と言い、それから事後に回答者に感謝するか、または別の方法で感謝を表現することです。例えば、「ご関心ありがとうございます」や「ご配慮ありがとうございます」など。）
問題が解決した後、短い補足説明を追加する
問題が解決した後、助けてくれたすべての人に説明を送り、問題がどのように解決されたかを知らせ、再び感謝の意を表してください。問題がニュースグループやメーリングリストで広く注目を集めた場合、そこに説明を投稿するのが適切です。
最も理想的な方法は、最初の質問トピックにこのメッセージを返信し、タイトルに「修正済み」、「解決済み」、またはその他の同等の意味を持つ明確なマークを含めることです。往来の激しいメーリングリストでは、「問題X」と「問題X - 解決済み」のスレッドを見る潜在的な回答者は、もう時間を無駄にする必要がないことを理解します（個人的に「問題X」が面白いと思う場合を除き）、したがって、この時間を他の問題を解決するために使うことができます。
補足説明は長くまたは深くある必要はありません。簡単な一言「こんにちは、ネットケーブルの問題でした！みなさんありがとう - Bill」は、何も言わないより良いです。実際、結論が本当に技術的な内容でない限り、短くてかわいい要約は長々とした説明よりも良いです。問題がどのように解決されたかを説明しますが、問題解決のプロセスを繰り返す必要はありません。
深い問題の場合、デバッグログの要約を投稿するのは役立ちます。問題の最終状態を説明し、何が問題を解決したかを説明し、その後に回避できる盲点を指摘します。回避できる盲点の部分は、正しい解決策と他の要約資料の後に置くべきであり、この情報を探偵小説にしないでください。助けてくれた人々の名前をリストすると、より多くの友達を作ることができます。
礼儀正しさと内容があることに加えて、このタイプの補足は、他の人がメーリングリスト/ニュースグループ/フォーラムであなたの問題を本当に解決した解決策を見つけるのに役立ち、彼らもそこから利益を得ることができます。
少なくとも、この補足は、協力に参加した各人が問題の解決から満足感を得るのに役立ちます。自分が技術専門家やハッカーでないなら、私たちを信じてください。この感覚は、あなたが助けを求めた専門家や専門家にとって非常に重要です。問題が未解決のままであることは人を落胆させます。ハッカーは問題が解決されるのを見たいと切望しています。善人は善い報いを受け、彼らの切望を満たせば、次回質問するときに甘い結果を得ることができます。
他の人が将来同様の問題に遭遇しないようにする方法を考え、ドキュメントやよくある質問（FAQ）を書くことが役立つかどうか自問してください。そうであれば、それらをメンテナーに送ってください。
ハッカーの間では、このような良いフォローアップは実際には伝統的な礼儀よりも重要であり、他者を善待することで評判を得る方法であり、これは非常に価値のある資産です。
回答を解釈する方法
RTFMとSTFW：完全に台無しにしたことを知る方法
古くて神聖な伝統があります。「RTFM（Read The Fucking Manual）」の返信を受け取った場合、回答者はあなたがマニュアルを読むべきだと考えています。もちろん、基本的には彼は正しく、あなたは読むべきです。
RTFMには若い親戚がいます。「STFW（Search The Fucking Web）」の返信を受け取った場合、回答者はあなたがウェブを検索すべきだと考えています。その人もたぶん正しいので、検索してください。（より穏やかな言い方はGoogleはあなたの友達です！）
フォーラムでは、フォーラムの過去の記事をクロールするように求められることもあります。実際、誰かがこの問題を解決した過去のスレッドを親切に提供してくれるかもしれません。しかし、このような配慮に依存しないでください。質問する前に過去の記事を検索すべきです。
通常、これらの2つのフレーズのいずれかで回答する人は、必要なコンテンツを含むマニュアルまたはウェブサイトのURLを提供し、それらを入力している間も読んでいます。これらの回答は、回答者が次のように考えていることを意味します：
- 必要な情報は非常に簡単に入手できる。
- 自分でこれらの情報を検索する方が、あなたに教えるよりも、より多くを学べる。
これで不快になるべきではありません。ハッカーの基準に従えば、彼はあなたにある程度の関心を示し、あなたの要求を無視していません。彼の祖母のような優しさに感謝すべきです。
それでも理解できない場合
回答が理解できない場合、すぐに説明を求めないでください。以前自分で問題を解決しようとしたときと同じように（マニュアル、FAQ、ネットワーク、近くの専門家を使用して）、まず彼の回答を理解しようとしてください。本当に説明が必要な場合、そこから何かを学んだことを示すことを忘れないでください。
例えば、私があなたにこう答えた場合：「zentryがスタックしているようです。まずそれをクリアすべきです。」その後、これは非常に悪いフォローアップの質問です：「zentryとは何ですか？」良い質問方法は次のようになります：「ああ、説明を見ましたが、-zと-pの2つのパラメータだけがzentriesに言及しており、それもそれをクリアする方法を明確に説明していません。これら2つのうちのどちらを指していますか？それとも何か見落としましたか？」
無礼な返信に対処する
多くのハッカーコミュニティで無礼に見える行動は、必ずしも意図的に攻撃しているわけではありません。逆に、それは直接的で、核心を突くコミュニケーションスタイルであり、このスタイルは人を快適に感じさせることよりも、問題を解決することに重点を置いています。
攻撃されたと感じた場合、穏やかに反応してみてください。誰かが本当に不適切なことをした場合、メーリングリスト、ニュースグループ、またはフォーラムの先輩が彼に声をかけるでしょう。これが起こらず、あなたが怒った場合、あなたが怒った相手の言葉はハッカーコミュニティでは正常に見えるかもしれません。そしてあなたが間違っている側と見なされ、これは情報や助けを得る機会を損なう可能性があります。
一方、時々本当に無礼で退屈な言葉や行動に遭遇します。上記とは逆に、本当に攻撃的な人に対して強く打撃を与え、鋭い言葉で完全に論破することは許容されます。しかし、行動する前に、非常に確信を持つ必要があります。無礼な発言を修正することと、無意味な口論を始めることの間には、わずかな境界線しかありません。ハッカー自身が無礼にその線を越えることは珍しくありません。初心者や部外者の場合、このような無礼を避ける機会は高くありません。情報を得たいのであって、時間を潰したいのでない場合、この時はキーボードに手を置かないのが最善です。
（一部の人々は、多くのハッカーが軽度の自閉症やアスペルガー症候群を持っており、人間社会の正常な交流に必要な神経が欠けていると主張しています。これは真実かもしれませんし、そうでないかもしれません。自分がハッカーでない場合、私たちに問題があると考えることが、私たちの奇妙な行動に対処するのに役立つかもしれません。そうしてください。私たちは気にしません。私たちは今の状態が好きであり、通常、患者ラベルには説得力のある疑念を持っています。）
Jeff Biglerの観察の要約はこれに関連しており、読む価値があります（tact filters）。
次のセクションでは、別の問題について話します。あなたが不適切に行動したときに受ける「攻撃」についてです。
敗者になることを避ける方法
ハッカーコミュニティのフォーラムでは、何度か失敗する可能性があります。このガイドで説明されている方法や類似の方法で。そして、公開の場でどのように失敗したかを告げられ、攻撃的な言葉には少しの色が混じるかもしれません。
このようなことが起きた後、できる最悪のことは、自分の遭遇を嘆き、口頭攻撃されたと宣言し、謝罪を要求し、大声で叫び、不機嫌になり、法的措置を脅し、雇用主に不満を言い、トイレの蓋を閉め忘れることなどです。逆に、あなたはこうすべきです：
耐えてください。これは正常です。実際、それは健康的で合理的です。
コミュニティの基準は自然に維持されず、参加者が積極的に公開で実行することによって維持されます。すべての批判は個人的なメールで送られるべきだと泣き言を言わないでください。それはそのように機能しません。誰かがあなたの発言が間違っているとコメントしたり、異なる見解を提示したりしたとき、個人的な攻撃を受けたと主張し続けることも役に立ちません。これらは敗者の態度です。
他のハッカーフォーラムもあり、高い礼儀要件に誤導され、参加者が他人の投稿に欠点を見つけるメッセージを投稿することを禁止し、「ユーザーを助けたくないなら黙ってください」と主張しています。結果として、アイデアを持つ参加者が次々と去り、これは彼らを無意味なお喋りと無用な技術フォーラムに変えてしまいます。
誇張して言えば、「親切」（上記の方法で）か有用か？2つのうちから1つを選んでください。
覚えておいてください：ハッカーがあなたが失敗したと言い、（どんなに厳しくても）二度とそうしないようにと伝えるとき、彼はあなたと彼のコミュニティを気にかけて行動しています。彼にとって、あなたを無視し、彼の生活からフィルタリングする方が簡単です。感謝できないなら、少なくとも少しの尊厳を示し、大声で嘆かず、自分がドラマチックで超敏感な魂であり、資格があると信じる新参者だからといって、他人が壊れやすい人形のようにあなたを扱うことを期待しないでください。
時には、失敗していない（または彼の想像の中で失敗した）場合でも、一部の人々は理由もなくあなたを攻撃します。このような場合、不満を言うことは本当に問題を台無しにします。
これらのトラブルを探しに来る人々は、方法がないが専門家だと信じている役立たずか、あなたが本当に失敗するかどうかをテストしている心理学者です。他の読者は無視するか、自分の方法で彼らに対処します。これらのトラブルを探しに来る人々は自分自身にトラブルを見つけており、あなたは心配する必要はありません。
自分自身を口論に巻き込まないでください。ほとんどの口論を無視するのが最善です。もちろん、これはあなたがそれらが単なる口論であることを検証し、あなたが失敗した点を指摘しておらず、同時に問題の本当の答えがその背後に巧みに隠されていないことを確認した上でです（これも可能です）。
聞くべきではない質問
以下はいくつかの古典的な愚かな質問と、ハッカーが回答しなかったときに心の中で考えていることです：
質問：XプログラムやXリソースはどこで見つけられますか？
回答：私がそれを見つけた場所ですよ、愚か者。検索エンジンの向こう側に。なんてことだ！Googleを使えない人がまだいるんですか？
質問：Xを使ってYをするにはどうすればいいですか？
回答：Yを解決したいなら、質問するときに不適切かもしれない方法を提示しないでください。このような質問は、質問者がXについて完全に無知であるだけでなく、Yが解決しようとしている問題についても混乱しており、特定の状況に思考が囚われていることを示しています。このような人は無視するのが最善です。彼らが問題を明確にするのを待ちましょう。
質問：シェルプロンプトを設定するにはどうすればいいですか？？
回答：この質問をする十分な知恵があれば、RTFMする十分な知恵もあり、自分で見つけられるはずです。
質問：Bass-o-maticファイル変換ツールを使ってAcmeCorpファイルをTeX形式に変換できますか？
回答：試してみればわかります。試したことがあれば、答えを知っているので、私の時間を無駄にする必要はありません。
質問：私の{プログラム/設定/SQL文}が動作しません
回答：これは質問ではないでしょう。20の質問をして本当の問題を見つける必要がある質問には興味がありません。もっと面白いことがあります。このような質問を見たとき、私の反応は通常次の3つのいずれかです：
- 他に何か追加はありますか？
- 残念ですね。解決できるといいですね。
- 私に何の関係がありますか？
質問：私のWindowsコンピュータに問題があります。助けてくれませんか？
回答：はい、マイクロソフトのゴミを捨てて、LinuxやBSDのようなオープンソースオペレーティングシステムに変えてください。
注意：プログラムに公式のWindows版がある場合、またはWindowsと対話する場合（Sambaなど）、Windows関連の質問をできます。ただし、問題がプログラム自体ではなくWindowsオペレーティングシステムによって引き起こされたという回答に驚かないでください。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も読み、エラーもリストし、問題の責任を他人に押し付けていません。彼の質問は注目に値します。
愚かな質問：
マザーボードに問題があります。誰か助けてくれませんか？
あるハッカーのこのような質問に対する回答は通常：「はい、背中を叩いておむつを替えてあげましょうか？」と言って、削除キーを押します。
賢い質問：
S2464マザーボードでX、Y、Zを試しましたが、効果がありませんでした。A、B、Cも試しました。Cを試したときの奇妙な現象に注意してください。明らかにflorbishがgrommickingしていますが、結果は予想外です。通常、Athlon MPマザーボードでgrommickingを引き起こす原因は何ですか？問題を見つけるために次にどのようなテストをすべきか知っている人はいますか？
この男は、別の角度から見ると、答える価値があります。彼は問題を解決する能力を示しており、天から答えが降ってくるのを待っているわけではありません。
最後の質問では、「答えを教えて」と「私がまだすべき診断作業を指摘して、啓発を与えて」の間の微妙で重要な違いに注意してください。
実際、後者の質問は、2001年8月にLinuxカーネルメーリングリスト（lkml）で行われた実際の質問に由来しています。私（Eric）がその質問をした人です。Tyan S2464マザーボードで、この説明できないロック現象を観察し、リストのメンバーがこの問題を解決するための重要な情報を提供しました。
私の質問方法を通じて、私は他の人々が咀嚼し味わうことができるものを与えました。人々が簡単に参加し、引き込まれるようにしました。私は彼らと同等の能力を持っていることを示し、彼らと共に探求するよう招待しました。私が通った回り道を彼らに伝えることで、彼らが時間を無駄にするのを避け、彼らの貴重な時間への敬意も示しました。
事後、私が各人に感謝し、この良い議論経験を称賛したとき、あるLinuxカーネルメーリングリストのメンバーは、私の質問が解決されたのは、私がこのリストの有名人だからではなく、正しい方法で質問したからだと述べました。
ハッカーはある意味で、豊富な知識を持っているが人間味に欠ける人々です。彼が正しいと信じています。もし私が乞食のように質問していたら、私が誰であろうと、一部の人々を怒らせるか、無視されたでしょう。彼は私にこのことを書き留めるよう勧め、これが直接このガイドの作成につながりました。
回答が得られない場合
まだ回答が得られない場合、私たちがあなたを助けることができないと考えていると思わないでください。時には、あなたの質問を見た人が答えを知らないだけです。返信がないことは、あなたが無視されていることを意味しません。この違いを区別するのが難しいことは否定できませんが。
一般的に、質問を単純に繰り返し投稿するのは非常に悪いアイデアです。これは無意味な騒音と見なされます。少し忍耐強くしてください。あなたの質問の答えを知っている人は、異なるタイムゾーンに住んでいるかもしれず、寝ているかもしれません。あるいは、あなたの質問が最初からうまく組織されていないかもしれません。
他のチャネルを通じて助けを得ることができます。これらのチャネルは通常、初心者のニーズにより適しています。
オンラインおよびローカルのユーザーグループがたくさんあり、情熱的なソフトウェア愛好家（彼らが自分でソフトウェアを書いたことがないとしても）で構成されています。通常、人々はこのようなグループを形成して、互いに助け合い、初心者を助けます。
また、多くの商業会社に助けを求めることができます。会社が大きくても小さくても。助けを得るために支払わなければならないことに落胆しないでください！結局のところ、あなたの車のエンジンのシリンダーシールが破裂した場合（完全に可能です）、修理工場に持ち込み、修理のために支払わなければなりません。ソフトウェアが1銭もかからなかったとしても、技術サポートが常に無料であることを要求することはできません。
Linuxのような大衆的なソフトウェアの場合、各開発者は少なくとも数万人のユーザーに対応します。数万人のユーザーからの助けを求める電話を一人で処理することは不可能です。これらの支援のために支払うとしても、購入する同様のソフトウェアと比較して、あなたが支払うのは取るに足らないことを知ってください（通常、クローズドソースソフトウェアの技術サポート費用はオープンソースソフトウェアよりもはるかに高く、内容もそれほど豊富ではありません）。
より良く質問に答える方法
態度を少し良くしてください。問題がもたらすプレッシャーは、人々を無礼または愚かに見せることがありますが、実際はそうではありません。
初犯者には個人的に返信してください。正直に間違いを犯した人々を公衆の面前で恥じ入らせる必要はありません。本当の初心者は、検索方法やよくある質問の場所さえ知らないかもしれません。
不確かな場合は、必ず言ってください！権威的に聞こえる間違った返信は、ないよりも悪いです。専門家のように聞こえるのが面白いからといって、他人に間違った道を指示しないでください。謙虚で誠実であり、質問者と同業者の両方に良い例を示してください。
助けられない場合、邪魔しないでください。実際のステップで冗談を言わないでください。それはユーザーの設定を破壊するかもしれません。一部の哀れな間抜けはそれを本当の指示として受け取るかもしれません。
探りを入れる反問をして、より多くの詳細を引き出してください。うまくやれば、質問者は何かを学べます。あなたもです。愚かな質問を良い質問に変えてみてください。私たち全員がかつて初心者だったことを忘れないでください。
怠け者にRTFMと文句を言うのは正当ですが、ドキュメントの場所を指摘する（単にGoogle検索キーワードを提案するだけでも）方が良いです。
回答することを決めたら、良い回答を与えてください。他人が間違ったツールや方法を使用しているとき、不器用な回避策（workaround）を提案せず、より良いツールを推奨し、問題を再定義してください。
質問に正面から答えてください！質問者がすでに深く研究し、X、Y、Z、A、B、Cを試したが結果が得られなかったことを示している場合、「AまたはBを試してみてください」または「X、Y、Z、A、B、Cを試してみてください」とリンクを添えて回答するのは役に立ちません。
あなたのコミュニティが問題から学ぶのを助けてください。良い質問に返信するとき、「関連ドキュメントやよくある質問ファイルをどのように修正すれば、同じ質問に再び答える必要がなくなるか？」と自問し、それからドキュメントメンテナーにパッチを送ってください。
研究してから回答した場合、結果を直接出すのではなく、あなたのスキルを示してください。結局のところ、「魚を与えるのではなく、魚の釣り方を教える」です。
関連リソース
パーソナルコンピュータ、Unixシステム、ネットワークがどのように機能するかについての基礎知識が必要な場合、Unixシステムとネットワーク基本原理を参照してください。
ソフトウェアやパッチをリリースするとき、ソフトウェアリリース実践に従って操作してみてください。
謝辞
Evelyn Mitchelはいくつかの愚かな質問の例を提供し、「より良く質問に答える方法」セクションの作成を啓発しました。Mikhail Ramendikは特に価値のある提案と改善を提供しました。
このガイドの英語版の著作権はEric S. Raymond、Rick Moenに帰属します。
原文URL：http://www.catb.org/~esr/faqs/smart-questions.html
転載请注明：デベロッパーリレーションズ »
