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