《提问の智慧》中文版

質問の知恵#

エリック・スティーブン・レイモンド（Eric Steven Raymond）#

Thyrsus Enterprises

リック・モーエン（Rick Moen）#

改訂履歴#

改訂版 3.9    2013年4月23日    esr
リンク修正
改訂版 3.8    2012年6月19日    esr
リンク修正
改訂版 3.7    2010年12月6日    esr
英語を第二言語とする人への有益なアドバイス
改訂版 3.7    2010年11月2日    esr
いくつかの翻訳が消えた
改訂版 3.6    2008年3月19日    esr
小さな更新と新しいリンク
改訂版 3.5    2008年1月2日    esr
誤記といくつかの翻訳リンク
改訂版 3.4    2007年3月24日    esr
新章：「コードに関する問題」
改訂版 3.3    2006年9月29日    esr
カイ・ニゲマン（Kai Niggemann）の良い提案を追加
改訂版 3.2    2006年1月10日    esr
リック・モーエン（Rick Moen）が執筆した内容を追加
改訂版 3.1    2004年10月28日    esr
文書「Googleはあなたの友達！」
改訂版 3.0    2004年2月2日    esr
ウェブフォーラムにおける礼儀の主要な追加

原文：How To Ask Questions The Smart Way #

翻訳：王刚
時間：2013 年 10 月 26 日
内容

目次#

免責事項
序文
質問の前に
質問の際に
回答の解釈方法
失敗者のように反応しない
質問の禁忌
良い質問と悪い質問
回答が得られない場合
より良い回答をする方法
関連リソース
謝辞

翻訳：インドネシア語ベラルーシ語ブラジルポルトガル語簡体字中国語オランダ語フランス語ジョージア語ドイツ語ギリシャ語ヘブライ語日本語ポーランド語ポルトガル語ルーマニア語ロシア語スペイン語タイ語もしこの文書をコピー、ミラーリング、翻訳、または引用したい場合は、私のコピーライセンスを参照してください。

免責事項#

多くのプロジェクトのウェブサイトが、どのように助けを得るかのセクションでこの記事にリンクしていますが、それは問題ありませんし、まさに私たちが望んでいることです。しかし、もしあなたがそのプロジェクトのリンクを生成したウェブマスターであれば、リンクの近くに目立つ位置で次のことを明記してください：私たちはそのプロジェクトのサービスサポートを提供していません！

私たちはこの説明がないことによる苦痛を経験しており、私たちがこの記事を公開したからには、世界中のすべての技術的問題を解決する責任があると考えている愚か者たちに、絶えず悩まされることになります。

もしあなたが助けを必要としてこの記事を読んでいるのなら、そして著者から直接助けを得られる印象を持って去るなら、あなたは不幸にも私たちが言うところの愚か者の一人になってしまいます。私たちに質問しないでください、私たちは無視します。私たちは、あなたのソフトウェアやハードウェアの問題を本当に理解している人々から助けを得る方法を教えているだけで、99.9％の確率で私たちはその人々ではありません。もしあなたがこの記事の著者があなたの問題に関して専門家であると非常に確信しているのでなければ、邪魔しないでください、そうすればみんながもっと幸せになります。

序文#

ハッカーの世界では、あなたが提起する技術的な質問の答えは、あなたの質問の仕方とその問題を解決する難しさに大きく依存します。この記事では、満足のいく回答を得る可能性が高くなるように質問する方法を教えます。

オープンソースソフトウェアの利用は非常に広がっており、通常はハッカーではなく、他の経験豊富なユーザーから回答を得ることができます。これは良いことです。彼らは一般的に初心者のよくある過ちに対してより寛容です。しかし、私たちが推奨する方法を使用して、ハッカーのようにこれらの経験豊富なユーザーに接することが、通常は最も効果的に問題の解決を得ることができます。

最初に理解すべきことは、ハッカーは難問や思考を刺激する良い質問を好むということです。そうでなければ、私たちもこの記事を書くことはなかったでしょう。もしあなたが私たちが考えさせられるような興味深い質問を提起できれば、私たちは感謝します。良い質問は刺激と贈り物であり、私たちの認識を発展させ、注意を払っていなかったり考えもしなかった問題を明らかにします。ハッカーの間では、「良い質問！」は非常に熱烈で真摯な賛辞です。

さらに、ハッカーは単純な問題に対して敵意や傲慢さを示すことがあるという評判もあります。時には、私たちは初心者や愚かな人々に対して条件反射的に無礼に見えることもありますが、実際にはそうではありません。

私たちは、考えずに質問をする人々や自分の宿題をしない人々に対して無遠慮に敵意を持っています。こうした人々は時間の無駄遣いをするだけで、他のより面白い問題やより価値のある人々に使えるはずの時間を浪費します。私たちはこうした人々を「失敗者（loser）」と呼んでいます（歴史的な理由から、時には「loser」を「lusers」と綴ることもあります）。

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

私たち（大多数）はボランティアであり、自分の忙しい生活から時間を割いて質問に答えていますが、時には力不足を感じることもあります。そのため、特に失敗者のように見える質問をフィルタリングし、より効果的に質問に答える時間を勝利者に留めるために、無情に質問を排除します。

もしあなたがこの態度を不快に思ったり、施しをする者のように見える、または傲慢だと感じるなら、あなたの仮定を再評価してください。私たちはあなたに屈服することを求めているわけではありません──実際、あなたがやるべき努力をした場合、私たちの大多数は平等にあなたと交流し、私たちの文化を受け入れることを歓迎します。自分を助けようとしない人々を助けようとする試みは、私たちにとって非常に非効率的です。理解できないのは構いませんが、愚かに行動するのは許されません。

したがって、あなたは技術的に非常に熟練している必要はありませんが、あなたが得意なことを導く姿勢を示さなければなりません──敏感で、考えを持ち、観察力があり、問題解決に積極的に参加することを楽しむ姿勢です。もしあなたがこれらのことを実行できないのであれば、私たちはあなたにお金を払って他の人と商業サービス契約を結ぶことをお勧めします。ハッカーに無償で助けを求めるのではなく。

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

（この記事に対する指摘は歓迎します。提案は esr@thyrsus.com または respond-auto@linuxmafia.com に送信できます。この記事は一般的なネットマナーガイドになりたいわけではなく、技術フォーラムで有用な回答を引き出すことに特に関連しない提案は一般的に拒否します。）

質問の前に#

メール、ニュースグループ、またはフォーラムを通じて技術的な質問をする前に、次のことを行ってください：

質問を準備しているフォーラムの歴史文書を検索して答えを探す
インターネットで答えを探す
マニュアルを読んで答えを探す
「よくある質問」（FAQ）を読んで答えを探す
自分で確認または実験して答えを探す
知識のある友人に尋ねて答えを探す
あなたがプログラマーであれば、ソースコードを読んで答えを探す

質問する際には、上記のことを行ったことを最初に示してください。これにより、あなたが寄生虫であり、他人の時間を浪費している印象を与えるのに役立ちます。さらに、あなたがそこから学んだことを述べると良いでしょう。私たちは、答えから学ぶことができることを示す人々の質問に答えるのが好きです。

いくつかの戦略を使用して、Google で遭遇したさまざまなエラーメッセージを検索することができます（Google フォーラムとウェブの両方を検索すること）。これにより、問題を解決するための文書やメールリストの手がかりを直接見つける可能性が高くなります。たとえ結果が得られなくても、メールリストやニュースグループで助けを求める際に「私は Google で次の文を検索しましたが、有用なものは見つかりませんでした」と言うのも良いことです。少なくとも、検索エンジンがどのような助けを提供できなかったかを示しています。検索キーワードをあなたの質問や可能な解決策と関連付けることは、同様の問題を抱えている他の人々を導くのにも役立ちます。

急がないでください。複雑な問題を数秒の Google 検索で解決できるとは期待しないでください。FAQ を読んでみてください。専門家に質問する前に、少し後ろに下がってリラックスし、問題について考えてみてください。私たちを信じてください。彼らはあなたの質問からあなたがどれだけの読書と考えをしたかを見抜くことができます。もしあなたが準備ができているなら、答えを得る可能性が高くなります。すべての質問を一度に投げつけないでください。最初の検索で結果が得られなかったからといって（または結果が多すぎるからといって）。

真剣に考え、質問の準備をしてください。軽率な質問は軽率な回答しか得られないか、まったく得られないことになります。質問する際に、あなたが以前に考え、問題を解決しようと努力したことを示せば示すほど、真の助けを得る可能性が高くなります。

間違った質問をしないでください。もし質問が誤った仮定に基づいている場合、あるハッカーは「愚かな質問……」と思いながら、間違った答えを返すことが多く、その結果、あなたが本当に必要な答えを得ることができず、教訓を得ることになります。

決して自分が答えを得る資格があると仮定しないでください。あなたにはその資格はありません。結局、あなたはそのサービスに対してお金を払っていないのです。もしあなたが内容があり、興味深く、思考を刺激する質問を提起できるのであれば──それは間違いなくコミュニティに経験を提供し、他の人から知識を受け取るだけではない質問であれば、あなたは「答えを得る」ことができます。

一方で、問題の解決に参加する能力があることを示すのは良いスタートです。「誰か方向を指示してくれませんか？」「私は何を調べるべきですか？」「どのウェブサイトをチェックすべきですか？」という質問は、「私が使える完全な手順を教えてください」と言うよりも、通常は返信を得やすいです。なぜなら、あなたは誰かが方向を指示してくれれば、残りのプロセスを喜んで完了することを示しているからです。

質問の際に#

フォーラムを慎重に選ぶ#

質問する場所に注意を払い、以下のことを行った場合、ほとんどの場合、無視されるか「失敗者」と見なされるでしょう：

フォーラムのテーマに関係のない質問を投稿する
高度な技術的問題に向けたフォーラムに浅薄な質問を投稿する、またはその逆
同時に多くの異なるニュースグループに投稿する
知人でもなく、あなたの問題を解決する義務のない人にプライベートなメールを送る

通信のチャネルが無関係なもので溢れないようにするために、ハッカーは適切な場所を見つけられなかった質問を排除します。あなたはそのようなことが自分に降りかかることを望まないでしょう。

したがって、最初のステップは適切なフォーラムを見つけることです。Google や他の検索エンジンはあなたの友人です。遭遇したソフトウェアやハードウェアの問題に最も関連するプロジェクトのウェブサイトを検索するために使用できます。そこには通常、プロジェクトの FAQ、メールリスト、文書へのリンクがあります。あなたの努力（FAQ を読むことを含む）が結果を出さなかった場合、これらのメールリストが最後の助けを得る場所です。プロジェクトのウェブサイトにはバグを報告するプロセスやリンクがあるかもしれません。そうであれば、確認してください。

見知らぬ人やフォーラムにメールを送ることは非常にリスキーです。たとえば、内容が豊富なウェブページの著者があなたの無料の顧問になりたいと思っているとは仮定しないでください。あなたの質問が歓迎されるかどうかを楽観視しないでください──もしあなたが確信が持てない場合は、他の場所に送信するか、まったく送信しないでください。

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

すべての支援チャネルを一度に「銃撃」するようにしないでください。これは大声で叫ぶようなもので、気分を害します。優しく一つずつ行ってください。

テーマを理解してください！最も典型的な間違いの一つは、クロスプラットフォームで移植可能な言語、ライブラリ、またはツールに関するフォーラムで Unix または Windows のプログラムインターフェースに関する質問をすることです。なぜこれが大きな間違いであるか理解できない場合は、概念を理解するまで何も質問しない方が良いです。

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

理解できるように、熟練したハッカーや人気のあるソフトウェアの著者は、過剰な不適切なメッセージに苦しんでいます。最後の一押しがキャメルの背中を折るわけではありませんが、あなたの参加が状況を極端にする可能性があります──何度も、人気のあるソフトウェアの著者が自分のソフトウェアのサポートを辞めたのは、伴ってくるプライベートメールボックスへのスパムが耐え難くなったからです。

初心者向けのフォーラムとインターネット中継チャット（IRC）は通常最も迅速に応答する#

地域のユーザー組織や使用している Linux ディストリビューションは、新しいユーザーが助けを得るためのフォーラムや IRC チャネルを宣伝しているかもしれません（いくつかの非英語圏では、初心者フォーラムはメールリストである可能性が高いです）。これらの場所は、特に相対的に簡単または一般的な問題に直面していると感じるときに質問を始めるのに良い場所です。宣伝された IRC チャネルは、質問をすることを公然と招待する場所であり、通常はリアルタイムでの応答を得ることができます。

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

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

フォーラムや IRC チャネルを通じてプロジェクトのユーザーサポートを提供する傾向が高まっており、電子メールのやり取りはプロジェクトの開発者により多く留保されています。したがって、まずフォーラムや IRC でそのプロジェクトに関連する助けを求めてください。

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

プロジェクトに開発者メールリストがある場合は、リストに質問をし、個々のメンバーに質問しないでください。たとえあなたが彼があなたの質問に最もよく答えられると確信していても。プロジェクトの文書やホームページを確認し、プロジェクトのメールリストを見つけて使用してください。この方法にはいくつかの良い理由があります：

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

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

しかし、もしあなたが自分の質問が一般的ではなく、「ユーザー」リストやフォーラムで数日間返信がない場合は、「開発者」リストやフォーラムを試してみることができます。投稿する前に、少なくとも数日間観察して、最近の投稿を見て、その場の行動様式を理解することが良いアイデアです（実際、これは私的または半私的リストに参加する際の良いアイデアです）。

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

意味のある明確な件名を使用する#

メールリスト、ニュースグループ、またはフォーラムでは、件名は 50 語以下で資格のある専門家の注意を引く黄金の機会です。「助けてください」などのフレーズ（特に大文字の「助けてください！！！！」など）は、条件反射的に削除されるので、無駄にしないでください。あなたの苦痛の深さで私たちを感動させようとしないでください。むしろ、このスペースで超簡潔な問題の説明を使用してください。

件名の良い慣習は「オブジェクト──偏差」（形式の説明）です。多くの技術サポート組織がこのようにしています。「オブジェクト」部分では、どのアイテムまたはグループに問題があるかを示し、「偏差」部分では期待される動作と一致しない部分を説明します。

愚か：

助けて！私のノートパソコンのビデオが正常に動作しません！

賢明：

X.org 6.8.1 での MV1005 モデルの特定のグラフィックチップセットでのマウスカーソルの歪み

さらに賢明：

X.org 6.8.1 の MV1005 モデルの特定のグラフィックチップセットでのマウスカーソルの歪み

「オブジェクト──偏差」形式の説明を書くプロセスは、問題に対する詳細な考察を整理するのに役立ちます。何が影響を受けましたか？マウスカーソルだけですか、それとも他のグラフィックもですか？X.org の中だけですか？それともその 6.8.1 版だけですか？特定のグラフィックチップセットに関連していますか？それとも MV1005 モデルだけですか？ハッカーは一目であなたが直面している問題が何であるか、あなた自身の問題が何であるかを理解できます。

より一般的に、件名が問題をよりよく反映することを想像してください。次に同様の問題を検索している人が、文書内で直接答えの手がかりを見つけることができるようになります。

返信の中で質問をする場合は、件名を変更して質問をしていることを示してください。「Re: テスト」や「Re: 新しいバグ」のような件名のメッセージは、十分な注意を引くことはありません。同時に、返信の中で新しいテーマにあまり関連しない引用内容はできるだけ削除してください。

リストメッセージに対して、直接返信ボタンをクリックして新しいスレッドを開始しないでください。これにより、あなたの視聴者が制限されます。一部のメールリーダー（たとえば mutt）は、ユーザーがスレッドで並べ替え、スレッドを折りたたむことを許可します。これを行う人々は、あなたが送信したメッセージを決して見ることはありません。

単に件名を変更するだけでは不十分です。mutt や他のいくつかのメールリーダーは、メールヘッダーの件名以外の情報も確認してスレッドを指定するため、全く新しいメールを送信する方が良いです。

フォーラムでは、メッセージが特定のスレッドに密接に結びついており、通常はスレッドの外では見えないため、良い質問の仕方はわずかに異なります。返信で質問することは問題ありません。すべてのフォーラムが返信に異なるテーマを許可しているわけではなく、そうすることで基本的に誰も見ないことになります。しかし、返信で質問すること自体が疑わしい行為であるため、スレッドを見ている人々だけが読むことになります。したがって、もしあなたがそのスレッドの現在の活発な人々の中でのみ質問したいのでなければ、別のスレッドを開始する方が良いです。

質問を答えやすくする#

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

フォーラムでは、電子メールでの返信を要求することは完全に無礼です。返信の情報が敏感であると確信している場合を除いて（そして誰かが何らかの未知の理由であなたにだけ答えを知らせることを望んでいる場合）、そうすることは無礼です。もしあなたが単に誰かがスレッドに返信したときに電子メールの通知を受け取りたいだけであれば、フォーラムに通知を送信するように要求できます。ほとんどのフォーラムは「このスレッドに注意する」「返信があったらメールを送る」などの機能をサポートしています。

明確で文法的、スペルが正しい文で書く#

経験から言うと、粗雑で不注意な著者は通常、粗雑で不注意に考え、プログラミングを行います（私は賭けます）。これらの粗雑で不注意な思考者に質問に答えることには何の利益もありません。私たちは他の場所に時間を費やす方が良いです。

あなたの質問を明確かつ適切に表現することは非常に重要です。もしあなたがそうするのが面倒だと感じるなら、私たちもあなたの質問に注意を払うのが面倒だと感じます。少し余分なエネルギーを使って言葉を選んでください。あまり堅苦しくなく、正式である必要はありません──実際、ハッカー文化は非公式、スラング、ユーモアを正確に使用することを重視しています。しかし、それは非常に正確でなければならず、あなたが問題について考え、注意を払っていることを示す必要があります。

正しくスペルをつけ、句読点と大文字を使用し、itsをit'sと混同しないでください、looseをloseにしたり、「discrete」を「discreet」にしたりしないでください。すべて大文字を使用しないでください。これは無礼な大声で叫ぶと見なされます（すべて小文字も良くありません。なぜなら、読みづらいからです。アラン・コックス（Alan Cox）[著名なハッカーで、Linux カーネルの重要な参加者] はこれを行うかもしれませんが、あなたはそうではありません）。

一般的に、あなたが半文盲のように書いている場合、ほとんど無視されるでしょう。また、即時メッセージングでの略語を使用しないでください。たとえば、youをuに短縮することは、あなたを二度のキー入力を節約するための半文盲のように見せることになります。さらに悪いのは、子供のように落書きすることは絶対に自殺行為であり、誰もあなたを気にかけないことが確実です（または、せいぜいあなたに多くの非難と嘲笑を与えることになります）。

もしあなたが母国語でないフォーラムで質問する場合、あなたのスペルや文法の間違いには限られた寛容さがあるかもしれませんが、怠惰は完全に許されません（はい、私たちは通常その違いを見抜きます）。また、返信者が使用する言語を知らない限り、英語で書いてください。忙しいハッカーは、彼らが理解できない言語で書かれたメッセージを直接削除することが一般的です。インターネットでは英語が作業言語であり、英語で書くことであなたの質問が読まれずに直接削除される可能性を最小限に抑えることができます。

もしあなたが英語で書いているが、それが第二言語である場合、潜在的な返信者に言語上の困難を知らせてこの問題を回避することをお勧めします。たとえば：

英語は私の母国語ではありません。スペルミスをお許しください。
あなたが特定の言語を使用する場合、私にメール / プライベートメッセージを送ってください。おそらく、私の質問を翻訳するためにあなたの助けが必要です。
この技術用語自体には非常に精通していますが、それに関するいくつかのスラングや慣用表現にはあまり理解がありません。
私は特定の言語と英語の両方で質問しています。もしあなたがどちらか一方で返信してくれれば、私は喜んで翻訳します。

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

もしあなたが意図的に問題を読みづらくしているなら、それはほとんど無視されることになります。人々は理解しやすい質問を読むことを好むので：

HTML（ハイパーテキストマークアップ言語）ではなくプレーンテキストを使用してください（HTML をオフにするのは難しくありません）
MIME（マルチパーパスインターネットメール拡張）添付ファイルは、実際に内容がある場合（たとえば、添付されたソースファイルやパッチ）には問題ありませんが、メールクライアントが生成したテンプレート（たとえば、メッセージ内容のコピー）ではありません。
単なる 1 行の文で構成される段落を送信しないでください（これにより、返信の一部が非常に困難になります）。あなたの読者が 80 文字幅のテキスト端末でメールを読んでいることを想定し、行の折り返しポイントを 80 列未満に設定してください。
ただし、固定列でデータを折り返さないでください（たとえば、ログファイルのコピーやセッション記録）。データはそのまま保持し、返信者があなたが見ているものと同じものを見ていることを確信させる必要があります。
英語のフォーラムでは、'Quoted-Printable' MIME エンコーディングを使用してメッセージを送信しないでください。このエンコーディングは非 ASCII 言語を投稿するために必要かもしれませんが、多くのメールプログラムはサポートしていません。それらが断片化されると、テキスト中に散らばる「=20」記号は見栄えが悪く、注意を散漫にし、内容の意味を破壊する可能性すらあります。
ハッカーが閉じられた専用フォーマットで書かれた文書を読むことを期待しないでください。たとえば、マイクロソフトの Word や Excel ファイルなど。ほとんどのハッカーは、誰かがまだ熱い豚の糞をあなたのドアの前に倒したときのあなたの反応のように反応します。たとえ彼らがそれを処理できたとしても、そうすることは非常に嫌がられます。
もしあなたがウィンドウズのコンピュータから電子メールを送信している場合、問題の多いマイクロソフトの「スマート引用」機能をオフにしてください（「ツール」->「自動修正オプション」の「入力時に自動フォーマット」でスマート引用のチェックボックスを外してください）。これにより、あなたのメール中にゴミ文字が散らばるのを防ぎます。
フォーラムでは、「絵文字」や「HTML」機能を乱用しないでください（提供されている場合）。一つか二つの絵文字は通常問題ありませんが、派手なカラーテキストはあなたが無能であると見なされる傾向があります。絵文字、色、フォントを過剰に使用すると、あなたは愚かな笑顔の少女のように見えることになります。これは通常良いアイデアではありません。もしあなたが有用な返信よりも性に興味があるのであれば。
もしあなたがグラフィカルユーザーインターフェースのメールクライアント（たとえば、Netscape の Messenger、Microsoft の Outlook など）を使用している場合、これらのデフォルト設定がこれらの要件を満たさないことがあることに注意してください。ほとんどのこの種のプログラムには、メニューに基づく「ソースを表示」コマンドがあり、送信フォルダ内のメッセージを確認して、余分な不純物のないプレーンテキストファイルが送信されていることを確認できます。

問題を正確かつ内容のある形で説明する#

問題の症状を注意深く、明確に説明する
問題が発生した環境（ホスト、オペレーティングシステム、アプリケーション、関連するもの）を説明し、販売者のディストリビューションとバージョン番号を提供する（例：「Fedora Core 7」、「Slackware 9.1」など）
質問する前に行った研究とその理解を説明する
質問する前に問題を特定するために取った診断ステップを説明する
コンピュータやソフトウェアの設定に対する最近の関連する変更を説明する
可能であれば、制御された環境で問題を再現する方法を提供する
ハッカーが言及する可能性のある質問を予測し、事前に答えを用意する

もしあなたがコードに問題があると思うなら、ハッカーに制御された環境で問題を再現する方法を提供することが特に重要です。これを行うと、有用でタイムリーな返信を得る可能性が大幅に増加します。

サイモン・タサム（Simon Tatham）は「バグを効果的に報告する方法」という記事を書いており、私は皆さんに読むことを強くお勧めします。

量よりも精緻さが重要#

あなたは（書くのが）精緻で内容があるべきです。単に大量のコードやデータをヘルプメッセージに羅列するだけでは目的を達成できません。もしあなたが大きくて複雑なテストサンプルを持っていてプログラムがクラッシュする場合は、それをできるだけ小さく切り詰めるようにしてください。

これには少なくとも 3 つの理由があります。第一に、他の人に問題を簡素化しようとする努力を見せることで、返信を得る可能性が高くなります。第二に、問題を簡素化することで、有用な返信を得る可能性が高くなります。第三に、バグレポートを精製するプロセスで、あなた自身が解決策や回避策を見つけるかもしれません。

バグを見つけたと急いで主張しない#

ソフトウェアで問題が発生した場合、非常に確信がない限り、すぐにバグを見つけたと主張しないでください。ヒント：問題を解決するためのソースコードのパッチを提供できない限り、または以前のバージョンの回帰テストが不正確な動作を示さない限り、あなたはほとんど確信が持てないでしょう。ウェブページや文書についても同様です。もしあなたが（文書の）「バグ」を発見したと主張するのであれば、相応の位置の代替テキストを提供できるべきです。

覚えておいてください、他の多くのユーザーはあなたが遭遇した問題を経験していません。さもなければ、あなたは文書を読んだりウェブページを検索したりしているときにそれを発見しているはずです（あなたは文句を言う前にこれを行ったのですよね？）。これは、あなたが間違っている可能性が高いことを意味します。

ソフトウェアを作成する人々は、できるだけ完璧にするために非常に苦労しています。もしあなたがバグを見つけたと主張するなら、彼らの能力を疑うことになります。たとえあなたが正しいとしても、一部の人々を不快にさせる可能性があります。（さらに）「バグ」と叫ぶことは特に未熟です。

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

低姿勢は自分の宿題をすることに代わるものではない#

ある人々は、無礼または傲慢に行動してはいけないことを理解していますが、彼らは反対の低姿勢の極端に退いてしまいます。「私はただの可哀想な新参者で、失敗者だと知っていますが……」。これは人を困惑させるだけでなく、無駄です。実際の問題のあいまいな説明を伴うと、特に不快です。

低級な霊長類の方法であなたの時間を無駄にしないでください。代わりに、できるだけ明確に背景とあなたの問題を説明してください。これは低姿勢よりも良い位置を示します。

時には、フォーラムには初心者向けの質問専用のセクションがある場合があります。もしあなたが本当に浅薄な問題に直面していると思うなら、そこに行くのが良いでしょうが、同様に低姿勢であってはいけません。

問題の症状を説明し、推測しない#

ハッカーに問題の原因を伝えることは無駄です（もしあなたの診断理論が素晴らしいものであれば、他の人に助けを求めることはないでしょう）。したがって、問題の原始的な症状を伝え、あなたの説明や理論を述べないようにしてください。彼らに説明と診断をさせてください。もし自分の推測を述べることが重要だと思うなら、それが単なる推測であり、なぜそれが機能しないのかを説明してください。

愚か：

カーネルをコンパイルしているときに SIG11 エラーが続出し、マザーボードの回路が切れているのではないかと疑っています。見つける最良の方法は何ですか？

賢明：

私が組み立てたコンピュータ（K6/233 CPU、FIC-PA2007 マザーボード [VIA Apollo VP2 チップセット]、Corsair PC133 SDRAM 256Mb メモリ）は、最近電源を入れて 20 分ほど経過し、カーネルをコンパイルしているときに頻繁に SIG11 エラーを報告しますが、最初の 20 分間は問題が発生しません。再起動しても時計はリセットされず、一晩オフにしておくと問題が解決します。すべてのメモリを交換しても問題は解決しませんでした。関連する典型的なコンパイルセッションのログを添付します。

上記の点を多くの人が理解するのが難しいようですので、あなたに思い出させるための言葉があります。「すべての診断の専門家はミズーリ州出身です」。アメリカ国務省の公式モットーは「見せてください」（これは国会議員ウィラード・D・バンディファー（Willard D. Vandiver）が 1899 年に行った演説から来ています。「私はトウモロコシ、綿花、牛蒡、そして民主党員を生産する国から来ました。流暢な弁論は私を説得することも満足させることもありません。私はミズーリ州出身です。あなたは私に見せなければなりません。」）診断者にとって、これは疑いではなく、あなたが見ている原始的な証拠とできるだけ一致するものを見せるための真実かつ有用な要求です。したがって、見せてください。

時間順に問題の症状を列挙する#

問題が発生する直前に何が起こったかは、問題を解決するための最も効果的な手がかりを含んでいることがよくあります。したがって、記録には、あなた、コンピュータ、ソフトウェアがクラッシュする前に何をしていたかを正確に説明する必要があります。コマンドライン処理の場合、セッションログ（たとえば、スクリプトツールによって生成されたもの）を引用し、関連する数行（たとえば 20 行）を引用することが非常に役立ちます。

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

もしあなたの記録が長い（たとえば 4 段以上）場合、最初に問題を簡潔に説明し、その後に時間順に詳細なプロセスを列挙する方が有用かもしれません。これにより、ハッカーはあなたの記録を読む際に注意すべき内容を知ることができます。

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

もしあなたが何かをする方法を理解したいのであれば（バグを報告するのではなく）、最初にあなたの目標を説明し、その後に問題に直面した特定のステップを述べてください。

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

愚か：

どうすれば特定のグラフィックプログラムのカラーピッカーで 16 進数の RGB 値を取得できますか？

賢明：

私は自分で選んだ値の色で画像のカラーパレットを置き換えようとしています。今私が知っている唯一の方法は、各パレットスロットを編集することですが、特定のグラフィックプログラムのカラーピッカーで 16 進数の RGB 値を取得することができません。

後者の表現は賢明であり、より適切なツールを使用してタスクを完了するための提案を受ける可能性を開きます。

プライベートな返信を要求しない#

ハッカーは問題解決のプロセスが公開され、透明であるべきだと考えています。このプロセスの中で、より才能のある人々が不完全または不適切な点に気づくことができ、最初の返信ができるようになります。同時に、返信者も他の同僚にその能力と知識を見てもらうことで、何らかの報酬を得ることができます。

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

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

質問は明確であるべき#

漠然とした質問は、通常、明確な制限のない時間の無底洞と見なされます。最も有用な回答を提供する可能性が高い人々は、通常最も忙しい人々です（彼らが多くの仕事を抱えているからです）。これらの人々は、終わりのない時間の無底洞に非常に敏感であり、したがって漠然とした質問を嫌う傾向があります。

あなたが返信者に何をしてほしいのか（方向を指示する、コードを送る、パッチをチェックするなど）を明確にすれば、より有用な返信を得る可能性が高くなります。（なぜなら）これにより、彼らは集中し、あなたを助けるために必要な時間と労力の上限を間接的に設定することができます。これは良いことです。

専門家の生活の世界を理解するために、豊富な専門知識があるが、応答時間が不足していると想像してください。彼らに奉仕するために求める時間が少ないほど、あなたは本当に知識が豊富で忙しい専門家から答えを得る可能性が高くなります。

したがって、専門家が回答するために必要な時間を最小限に抑えるように質問を制限してください──これは通常、問題を簡素化することとはまだ異なります。たとえば、「良い X の説明がある場所を指摘してもらえますか？」は、「X を説明してください」と言うよりも賢明です。あなたのコードが動作しない場合、通常は他の人にどこが問題か見てもらう方が、彼らに修正を手伝ってもらうよりも賢明です。

コードに関する問題#

他の人に問題のコードをデバッグしてもらうように求める場合、どこから始めるべきかを示さないでください。数百行のコードを投稿し、「それは動作しません」と言うと、あなたは無視されることになります。数十行のコードを投稿し、「7 行目以降は表示されるはずですが、実際には」と言うと、非常に返信を得る可能性が高くなります。

コードの問題を最も正確に説明する方法は、問題を示す最小のテストサンプルを提供することです。最小のテストサンプルとは、問題を再現するのに必要な最小限のコードです。最小のテストサンプルを生成するには、問題を引き起こす行またはセクションを知っている場合、それをコピーし、完全なサンプルを構成するために必要な周辺コードを提供します（必要なものは、ソースコードがコンパイラ、インタープリタ、またはそれを処理するプログラムによって受け入れられることです）。問題を特定のセクションに絞り込むことができない場合は、ソースコードをコピーし、問題に関係のないコードセクションを削除します。あなたが提供できる最小のテストサンプルは小さければ小さいほど良いです（「量よりも精緻さが重要」を参照）。

非常に小さな最小のテストサンプルを生成することは常に可能ではありませんが、できるだけ努力することは良い練習であり、あなたが自分で解決すべき問題を見つけるのに役立つかもしれません。たとえ見つからなくても、ハッカーはあなたが努力したことを好みます。これにより、彼らはより協力的になります。

もしあなたが他の人にコードを見てもらいたいだけであれば、最初にそれを言い、特にどの部分に注意を払ってほしいか、なぜそれが重要かを必ず言及してください。

宿題のような質問を投稿しない#

ハッカーは「宿題」スタイルの質問を見抜くのが得意です。私たちの大多数は自分の宿題を終えています。それはあなたが行うべきことです。ヒントを尋ねることは問題ありませんが、完全な解決策を要求することではありません。

もしあなたが自分が宿題のような問題に直面しているのではないかと疑っているが、それでも解決できない場合は、ユーザーグループ、フォーラム、または（最後の手段として）プロジェクトの「ユーザー」メールリストやフォーラムで質問してみてください。ハッカーはそれを見抜くでしょうが、一部の古参ユーザーはあなたにヒントを与えるかもしれません。

無意味な要求を削除する#

「誰か助けてくれませんか？」や「答えはありますか？」など、意味のないものを助けを求めるメッセージの末尾に追加する誘惑に抵抗してください。第一に、問題の説明が不完全であれば、これらの追加はほとんど余分なものに過ぎません。第二に、これらは余分なものであるため、ハッカーはこれらを煩わしいと見なすことが多く、論理的に正しいが無視される返信を受ける可能性が高くなります。「はい、あなたは助けを得ることができます」と「いいえ、あなたに助けを与えない」と。

一般的に、「はいまたはいいえ」タイプの質問を避けてください。あなたが「はいまたはいいえ」タイプの回答を得たいのでない限り。

質問を「緊急」とマークしない、たとえあなたにとってそうであっても#

これはあなたの問題であり、私たちの問題ではありません。「緊急」と宣言することは、逆効果になる可能性が高いです。ほとんどのハッカーはこのようなメッセージを直接削除します。彼らは、無礼で自己中心的に即時かつ特別な配慮を得ようとする試みだと見なします。また、「緊急」やそれに類似した意味のある件名は、スパムフィルタリングルールを引き起こす可能性があり、潜在的な返信者はあなたの問題を永遠に見ることができないかもしれません！

一部の局所的な例外があります。もしあなたが非常に有名な場所でプログラムを使用しており、ハッカーたちが興奮する可能性がある場合、そうする価値があるかもしれません。この場合、もしあなたに締切のプレッシャーがあるなら、それを礼儀正しく言及することが重要です。人々はおそらく、より早く回答することに興味を持つでしょう。

もちろん、これは非常にリスキーです。なぜなら、ハッカーたちが何が興奮を引き起こすかの基準は、あなたの基準とは異なることが多いからです。たとえば、国際宇宙ステーションからこのように投稿することには問題はありませんが、気分が良い慈善や政治的理由を代表してこのようにすることはほぼ確実に問題になります。実際、「緊急：この毛むくじゃらの小さなアザラシを助けて！」と投稿することは、ハッカーたちが避けたり怒ったりすることになるでしょう。たとえ彼らがその毛むくじゃらの小さなアザラシが重要だと考えていても。

もしあなたがこれを信じられないのであれば、残りの内容をもう一度読み返し、理解するまで投稿しない方が良いです。

礼儀は常に有益である#

礼儀正しく、お願いしますやご関心をお寄せいただきありがとうございます、またはご配慮ありがとうございますを使用して、他の人々が無償であなたを助けるために時間を費やしていることに感謝していることを示してください。

率直に言って、この点は文法が正しいこと、文章が明確であること、正確であること、内容があること、そして専用フォーマットを避けることほど重要ではありません（同時に、これらを代替することもできません）。ハッカーたちは、少し唐突でも技術的に明確なバグレポートを読むことを好みますが、礼儀正しいがあいまいなレポートは好みません。（この点が理解できない場合、私たちは問題が私たちに何を教えてくれるかによって評価していることを思い出してください）

しかし、もしあなたが技術的な問題を明確に説明した場合、少し礼儀正しくすることで、有用な返信を得る可能性が高くなります。

（私たちは指摘しなければなりませんが、この記事で唯一、いくつかの古いハッカーから真剣に反対された点は、以前に推奨されていた「前もって感謝します」という表現です。一部のハッカーは、これが事後に誰にも感謝しなくてもよいという暗示を含んでいると考えています。私たちの提案は、前もって感謝しますと言って、事後に返信者に感謝の意を示すか、ご関心をお寄せいただきありがとうございますやご配慮ありがとうございますのように別の方法で表現することです。）

問題解決後に簡潔な説明を追加する#

問題が解決した後、助けてくれたすべての人にメッセージを追加し、問題がどのように解決されたかを知らせ、再度感謝の意を示してください。問題がメールリストやニュースグループで広く注目された場合、そこでこのメッセージを追加するのが適切です。

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

追加のメッセージは長くても複雑である必要はありません。「こんにちは──ネットワークケーブルが壊れていました！皆さん、ありがとう──ビル」といった簡単な一文が何もないよりも良いです。実際、問題を解決する技術が本当に高度でない限り、短く親しみやすい要約が長々とした説明よりも良いです。何が問題を解決したのかを説明し、全体のトラブルシューティングのストーリーを再演する必要はありません。

深い問題に関しては、トラブルシューティングの履歴を投稿することが適切です。問題の最終状態を説明し、何が問題を解決したのかを示し、その後に回避できた道を指摘します。回避すべき道の部分は、正しい解決策や他の要約資料の後に置くべきであり、このメッセージを探偵小説のようにしてはいけません。あなたを助けてくれた人々の名前を挙げることで、友達を作ることができます。

礼儀正しさと内容のあるこの種の追記は、他の人々がメールリスト、ニュースグループ、またはフォーラムの文書であなたの問題を解決した本当の解決策を検索するのを助け、彼らにも利益をもたらします。

最後に、このような追記は、問題の解決によって協力したすべての人に満足感を与えます。もしあなた自身が技術的な専門家やハッカーでない場合、私たちを信じてください。この感覚は、あなたが助けを求めているベテランや専門家にとって非常に重要です。問題の説明が最後まで不明瞭であることは常に失望を引き起こします。ハッカーたちはそれらが解決されることを切望しています。かゆみを掻くことで得られる信用は、次回再度質問を投稿する際に非常に役立ちます。

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

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

动物园没有海洋馆