چگونه هوشمندانه سوال کنیم

به نقل از : http://wiki.ubuntu.ir/SmartQuestions
نویسنده : اریک ردموند
ترجمه : سعید رسولی و شایان سیف
ویرایش : امیر مهری

چگونه هوشمندانه سوال کنیم

رفع ادعا
وب سایت تعدادی از پروژه‌ها در قسمت مربوط به چگونگی کمک گرفتن، به این سند لینک داده‌اند. این خوب است، این استفاده‌ای است که ما قصد داشته‌ایم — اما اگر شما مدیر سایتی هستید که در صفحهٔ پروژهٔ خود چنین لینکی را قرار داده‌اید، لطفاً نزدیک آن لینک این اعلان را بصورت برجسته نمایش دهید که ما یک میز کمک برای پروژهٔ شما نیستیم! ما به طریق سختی یاد گرفته‌ایم که بدون چنین اعلانی، ما را افراد ساده و ابلهی مکررأ مورد آزار قرار می‌دهند، افرادی که فکر می‌کنند انتشار این سند، کار ما را تبدیل به این کرده که تمام مشکلات فنی جهان را حل کنیم.
اگر شما این سند را می‌خوانید چون نیاز به کمک دارید، و اگر خیال می‌کنید که می‌توانید مستقیماً از نویسندگان این سند کمک بگیرید، شما یکی از همان افراد ابله در سوال کردن هستید. سوالات خود را از ما نپرسید. [وگرنه] ما فقط شما را نادیده خواهیم گرفت. ما اینجا می‌خواهیم به شما نشان دهیم که چگونه کمک بگیرید از افرادی که واقعاً دانشی در مورد نرم‌افزار یا سخت‌افزار مورد نظر شما دارند، اما در 99.9 درصد مواقع، آن افراد ما نیستیم. بدون اطمینان به اینکه یکی از نویسندگان این سند در مورد مشکل شما تخصص دارد، ما را تنها بگذارید.

مقدمه
در دنیای هکرها، نوع جوابی که برای سوالات فنی خود می‌گیرید، هر چقدر که به سختی جواب دادنش بستگی دارد، همانقدر هم به روش پرسیدن شما بستگی دارد. این راهنما به شما یاد می‌دهد که چگونه طوری سوال کنید که به احتمال بیشتری بتوانید به جواب رضایت‌بخشی برسید.
حالا که استفاده از اوپن‌سورس رایج و گسترده شده است، شما معمولاً می‌توانید کاربران باتجربه‌تر و هکرها جواب‌های خوبی دریافت کنید. این چیز خوبی است؛ کاربرانی که تمایل دارند که فقط کمی بیشتر در مورد مشکلات رایج تازه‌کارها بردباری کنند.با این حال اگر کاربران باتجربه مثل هکرها هم طبق روشهایی که ما اینجا توصیه می‌کنیم رفتار کنند، عموماً موثرترین راه برای گرفتن جواب‌های مفید خواهد بود. اولین چیزی که باید درک کنیم اینست که هکرها حقیقتاً مسائل سخت و سوالاتی را دوست دارند که به‌خوبی ذهن را درگیر می‌کند. اگر ما انجام ندادیم چون نمی‌خواستیم. اگر شما به ما یک سوال جالب توجه بدهید که به آن فکر کنیم، از شما سپاسگذار خواهیم شد؛ سوالات خوب محرک ذهن بوده و یک هدیه هستند. سوالات خوب به ما کمک می‌کنند که فهم خود را توسعه دهیم، و معمولاً باعث آشکار شدن مشکلاتی می‌شود که ممکن است ما ندانیم یا به آنها توجه نکرده باشیم. در میان هکرها، «سوال خوب!» یک درود بزرگ و مخلصانه است.
با این وجود، هکرها شهرت دارند که در مقابل سوالات ساده به‌نظر با دشمنی و تکبر برخورد می‌کنند. این گاهی به نظر می‌رسد که ما واکنش گستاخانه‌ای با تازه‌کارها و افراد ناآگاه داریم. اما واقعاً اینطور نیست. چیزی که ما بدون شرمندگی باید بگوییم، خصومت با افرادی است که ظاهراً تمایلی به فکر کردن ندارند یا نمی‌خواهند تکلیف خود را قبل از سوال کردن انجام دهند. این افراد کُشندهٔ وقت هستند — می‌گیرند و پس نمی‌دهند، و آنها وقت ما را هدر می‌دهند، وقتی که می‌توانیم صَرف جواب دادن به سوالات بهتر کنیم، صَرف جواب دادن به افرادی کنیم که بیشتر شایستهٔ جواب دادن هستند. ما چنین افرادی[که وقت را هدر می‌دهند] را «loser ها» می‌خوانیم (و به دلایل تاریخی، گاهی آن را «luser ها» تلفظ می‌کنیم).
ما درک می‌کنیم که افرادی هستند که می‌خواهند از نرم‌افزارهایی که ما نوشته‌ایم فقط استفاده کنند، و علاقه‌ای به یاد گرفتن جرئیات فنی ندارند. برای اکثر مردم کامپیوتر فقط یک ابزار است، واسطه‌ای برای رسیدن به یک هدف است؛ آنها کارهای مهمتری برای انجام دادن دارند، کارهایی که زندگی به آنها وابسته است. ما این را تصدیق می‌کنیم، و انتظار نداریم که همه به مسائل فنی مورد علاقهٔ ما علاقه داشته باشند. با این حال، سبک جواب دادن ما به سوالات، تنظیم شده است برای مردمی که چنین علاقعه‌ای را دارند، و تمایل دارند که در حل مشکل، سهم فعالی داشته باشند. این سبک تغییر نخواهد کرد. کسی از ما قصد تغییر دادنش را ندارد؛ اگر این سبک را تغییر دهیم، در چیزهایی که بهتر از همه می‌توانیم انجام دهیم، کمتر موثر خواهیم بود.
ما به شدت داوطلب هستیم. ما در زمانهایی که سرمان شلوغ نیست، روی جواب دادن به سوالات وقت می‌گذاریم، و در آن مواقع ما غرق در این سوالات هستیم. پس ما بدون ترس، سوالات را فیلتر می‌کنیم. به ویژه، ما سوالاتی که از افراد بازنده(loser) است را به دور می‌اندازیم تا زمان خود برای جواب دادن به سوالات را بهتر صرف کنیم، برای جواب دادن به افراد برنده(winner).
اگر شما این رفتار ما را گزنده، فروتنی یا خودبینی می‌یابید، پنداشت‌های خود را بررسی کنید. ما از شما نمی‌خواهیم که در مقابل ما زانو بزنید — در واقع اکثرِ ما هیچ چیز را بیشتر از این دوست ندارند که با شما بصورت برابر معالمه کنند، و ورود شما به جامعهٔ خود را خوشآمد بگویند، اگر شما تلاش کافی برای میسر شدن آن را داشته باشید. اما برای ما به سادگی کارآمد نیست که سعی کنیم به افرادی کمک کنیم که نمی‌خواهند به خودشان کمک کنند. انسان ممکن جاهل باشد؛ اما نباید احمقانه رفتار کند.
پس، درحالیکه لازم است که شایستگی فنی برای توجه از سوی ما را داشته باشید، این هم لازم است که نوع رفتار شما این شایستگی را نشان دهد — زیرک، اندیشمند، هشیار و علاقمند به شرکت فعالانه در توسعهٔ یک راه‌حل. اگر شما نمی‌توانید با این شرایط سر کنید، ما پیشنهاد می‌کنیم که به شخصی برای قرارداد پشتیبانی تجاری پول پرداخت کنید، بجای اینکه از هکرها بخواهید که شخصاً کمک خود را به شما اهدا کنند.
اگر شما تصمیم گرفتید که از ما کمک بگیرید، پس نمی‌خواهید که یکی از آن بازنده‌ها(loser ها) باشید. همینطور شما نمی‌خواهید که شبیه یکی از آنها به نظر برسید. بهترین راه برای گرفتن یک جواب سریع و خوب اینست که آن را مانند یک شخص زرنگ و مطمئن بپرسید، شخصی که واقعاً نیاز به کمک در یک مشکل خاص دارد.

(از اصلاح و بهبود این راهمنا استقبال می‌کنیم. می‌توانید پیشنهادات خود را به آدرس esr@thyrsus.com یا respond-auto@linuxmafia.com ایمیل کنید. توجه کنید اگرچه قصد نداریم این سند یک راهنمای جامع برای فرهنگ استفاده از اینترنت (netiquette) باشد، و ما عموماً پیشنهاداتی را که بطور خاص مربوط به استخراج جوابهای مفید در یک انجمن(forum) فنی نیستند، رد می‌کنیم.)

قبل از اینکه سوال کنید

قبل از پرسیدن یک سوال فنی از طریق ایمیل، یا در یک گروه خبری، یا در میز چت یک وب‌سایت، این کارها را انجام دهید:
سعی کنید جواب خود را با جستجو در ویکی پدیا و یا در مداخل ویکی سایت مربوطه پیدا کنید.
سعی کنید جواب خود را با جستجو در آرشیو انجمنی که می‌خواهید بفرسیتد، پیدا کنید.
سعی کنید جواب خود را با جستجو در وب پیدا کنید.
سعی کنید جواب خود را با خواندن manual (راهنما) پیدا کنید.
سعی کنید جواب خود را با خواندن FAQ (سوالات متداول) پیدا کنید.
سعی کنید جواب خود را از طریق بازبینی یا آزمایش پیدا کنید.
سعی کنید جواب خود را با پرسیدن از یک دوست باتجربه پیدا کنید.
اگر یک برنامه‌نویس هستید، سعی کنید جواب خود را با خواندن کدمنبع پیدا کنید.

وقتی شما سوال خود را می‌پرسید، این حقیقت را نشان دهید که اول ین کارها را انجام داده‌اید؛ این به تصدیق این امر کمک می‌کند که شما یک فرد تنبل و کشندهٔ وقت مردم نیستید. حتی بهتر، نشان دهید که شما این چیزها رایاد گرفته‌اید. ما دوست داریم به افرادی جواب دهیم که می‌توانند از جوابها یاد بگیرند.
از فنونی استفاده کنید مثل اینکه متن پیغام ارور را در گوگل جستجو کنید(جستجو در گروه‌های گوگل علاوه بر صفحات وب). این ممکن باعث شود که بتوانید مستندات یا آن گروه خبری را اصلاح کنید. حتی اگر این اتفاق هم نیفتد، گفتن اینکه «من عبارت زیر را گوگل کردم، اما چیز امیدوارکننده‌ای پیدا نکردم» چیز خوبی برای یک گروه پستی یا خبری است، حداقل به این دلیل که ثبت می‌شود که جستجو کمکی نمی‌کند. همینطور این کار به افراد دیگری با مشکلات مشابه کمک می‌کند که به آن ریسمان هدایت شوند، از طریق پیوند عبارتهای جستجو به چیزی که ممکن است شامل مشکل شما و ریسمان مربوط به راه‌حل آن باشد.
وقت بگذارید. انتظار نداشته باشد که بتوانید مشکل پیچیدهٔ خود را با چند ثانیه گوگل کردن حل کنید. FAQ ها را بخوانید و بفهمید، آرام و باتمرکز بنشنید و کمی در مورد مشکل خود فکر و گمانه‌زنی کنید، قبل از اینکه به سمت متخصصان بروید. به ما اعتماد کنید، آنها می‌توانند از سوالات شما تشخیص دهند که چقدر مطالعه و فکر کرده‌اید، و اگر شما خود را آماده کرده باشید آنها تمایل بیشتری به کمک خواهد داشت. به یکباره انبار سوالات خود را شلیک نکنید فقط به خاطر اینکه اولین جستجوی شما به هیچ جوابی نرسید(یا به جوابهای زیادی رسید).
سوال خود را آماده کنید. به آن فکر کنید. سوالات شتابزده به جوابهای شتابزده منجر خواهد شد، یا اصلاً به هیچ جوابی نمی‌رسد. هر چه بیشتر این را نشان دهید که برای حل مسئلهٔ خود قبل از درخواست کمک، فکر و تلاش کرده‌اید، همانقدر احتمال بیشتری خواهد رفت که واقعاً به شما کمک کنند.
. از پرسیدن سوال اشتباه، اجتناب کنید. اگر سوالی بپرسید که بر اساس فرض‌های ناقص و اشتباه است، یک هکر ممکن است با این تصور که «یک سوال احمقانه است...» بخواهد به شما یک جواب لفظی و بی‌فایده بدهد، و به امید اینکه شما درس بگیرید از تجربهٔ گرفتن آنچه پرسیدید، نه آنچه مورد نیاز شما بود. هرگز فرض نکنید که شما مستحق یک جواب هستید. اینطور نیست؛ به هر حال شما بهایی بابت خدمات پرداخت نکرده‌اید. شما وقتی می‌توانید به جواب برسید که یک سوال قابل توجه و برانگیزندهٔ ذهن بپرسید، سوالی که بطور ضمنی باعث کمک به تجربهٔ جامعه می‌شود، نه آنکه فقط بصورت انفعالی خواستار دانش از دیگران باشید.

از طرف دیگر، روشن ساختن اینکه شما توانایی و تمایل کمک در پروسهٔ حل مسئله را دارید، شروع بسیار خوبی است. «آیا کسی می‌خواهد منبعی معرفی کند؟»، «مثال من چه چیز کم دارد؟»، و «چه وبسایتی را بهتر است بررسی کنم» به احتمال بیشتری جواب خواهند گرفت نسبت به این سوال که «لطفاً روش دقیق کاری که باید انجام دهم را بنویسید.». چون[در حالت اول] شما این را روشن می‌سازید که واقعاً راغب به تکمیل پروسه [ی حل مشکل] هستید اگر شخصی فقط مسیر صحیص را به شما نشان دهد.

وقتی سوال می‌کنید
انجمن خود را به دقت انتخاب کنید به این حساس باشید که کجا سوال خود را مطرح می‌کنید. شما نادیده گرفته خواهید شد، یا بعنوان یک بازنده(loser) محسوب خواهید شد اگر:
سوال خود را در یک عنوان از دور خارج شده(off topic) پست کنید
یک سوال بسیار ابتدایی را در انجمنی پست کنید که انتظار سوالات فنی پیشرفته را دارند. یا بالعکس.
یک سوال مشترک را در چند گروه خبری پست کنید
یک ایمیل شخصی به کسی بفرستید که نه سابقه آشنایی با شما دارد، و نه شخصاً مسئول حل مشکل شماست.

هکرها پاک می‌کنند سوالاتی را که بیجا در مکان خاصی پست شود تا کانالهای ارتباطی‌شان را از غرق شدن در بی‌ربطی حفظ کند. شما نمی‌خواهید این اتفاق برایتان بیفتد. بنابراین اولین قدم این است که انجمن درست را انتخاب کنید. باز هم، گوگل و سایر روشهای جستجوی وب، دوست شما هستند. از آنها استفاده کنید و صفحهٔ وب پروژه‌ای که بیشتر با سخت‌افزار و نرم‌افزار مورد اشکال شما ارتباط دارند. معمولاً آن به شما لینکهایی به یک لیست از FAQ (سوالات مکرراً پرسیده‌شده) می‌دهند، و همینطور لینکهایی به لیست پستی پروژه و آرشیو آنها. این لیست‌های پستی آخرین مکانهایی هستند که باید از آنها کمک بگیرید، در صورتیکه تلاش کرده باشید(از جمله خواندن آن FAQ ها) و جواب خود را نیافته باشید. همینطور صفحهٔ پروژه ممکن است روش گزارش اشکال(bug report) را شرح داده باشد، یا یک لینک به یکی از آنها داشته باشد؛ در اینصورت، به دنبال آن بروید.
رها کردن یک ایمیل به سوی شخص یا انجمنی که با آن آشنا نیستید، در بهترین حالت یک ریسک است. مثلاً فرض نکنید صاحب یک صفحهٔ‌وب حاوی اطلاعات، می‌خواهد مشاور رایگان شما باشد. در مورد اینکه آیا سوال شما مورد استقبال واقع می‌شود یا نه، حدس‌های خوشبینانه نزنید — اگر مطمئن نیستید آن را جای دیگری بفرستید یا اینکه از فرستادن آن خودداری کنید.
وقتی یک انجمن وب، گروه خبری یا لیست پستی را انتخاب کردید، به اسم بتنهایی زیاد اعتماد نکنید؛ به یک FAQ یا امتیاز نگاه کنید تا بررسی کنید که سوال شما on-topic است. قبل از پست کردن، کمی از ترافیک گذشته بخوانید تا در نتیجه به یک احساس(تصور) برسید از اینکه چه جور چیزهایی آنجا انجام می‌شود. در واقع این ایدهٔ بسیار خوبی است که قبل از پست کردن، در آرشیو آن گروه‌خبری یا لیست پستی یک جستجو بر کلمات کلیدی مربوط به مشکل خود انجام دهید. این کار ممکن است برای شما جوابی را پیدا کند، و اگر هم اینطور نشود، حداقل باعث می‌شود که بتوانید یک سوال بهتر را تنظیم کنید.
همهٔ کانالهای کمک‌رسانی را به یکباره تیرباران نکنید، این کار مانند فریاد زدن است و مردم را عصبانی می‌کند. به آرامی از میان آنها گام بردارید.
بدانید که موضوع مورد بحث شما چیست! یکی از اشتباهات کلاسیک اینست که سوالاتی دربارهٔ رابط برنامه‌نویسی یونیکس یا ویندوز را در انجمنی بپرسید که علاقمند به یک زبان یا کتابخانه یا ابزار قابل‌انتقال بین هردو(یونیکس و ویندوز) است. اگر متوجه نمی‌شوید که چرا این کار اشتباه است، بهتر است که اصلاً هیچ سوالی نپرسید، تا وقتی که قضیه را درک کنید.
عموماً سوالاتی که در یک انجمن عمومی و درست(بجا) پرسیده شوند، احتمال اینکه جواب مفید بگیرند بیشتر است تا آنهایی که در جای خصوصی پرسیده می‌شوند. چندین دلیل برای این وجود دارد. یک دلیل ساده، مقدار منابع پاسخگو است. یکی دیگر تعداد بازدیدکنندگان است؛ هکرها ترجیح می‌دهند به سوالاتی جواب دهند که افراد بیشتری را آموزش دهد، تا سوالاتی که فقط به درد افراد کمی بخورد.
به وضوح، هکرهای چیره‌دست و سازندگان نرم‌افزارهای محبوب، همواره بسیار بیشتر از توان پاسخ‌گویی‌شان، پیغام‌های انبوه و بی‌هدف دریافت می‌کنند. شما با اضافه شدن به این سیل، یکی از آن موارد بسیار زیاد هستید، حتی مثل یک کاه از انبوهی که پشت شتر را می‌شکند. — حتی در موارد کمی، توسعه‌دهندگان پروژه‌های محبوب، پشتیبانی خود را قطع کردند چون خسارت ناشی از ترافیک شدید و بی‌جهت ایمیل شخصی‌شان تحمل‌ناپذیر شده بود.

انجمن‌های وب و IRC که برای تازه‌کارها تهیه شده‌اند، معمولاً سریع‌تر جواب می‌دهند
گروه کاربران محلی شما، یا توزیع لینوکس شما، ممکن است یک انجمن وب یا کانال IRC را معرفی کند که تازه‌کارها می‌توانند از طریق آن کمک بگیرند. (در شهرهای غیر انگلیسی ‌زبان، انجمن‌های تازه‌واردان احتمالاً هنوز لیست پستی هستند) اینها مکان‌های اولیهٔ خوبی برای پرسیدن هستند، بخصوص اگر فکر می‌کنید که ممکن است گرفتار یک مشکل نسبتاً ساده یا رایج باشید. یک کانال IRC اعلام شده، یک دعوتِ باز برای پرسیدن سوالات است و معمولاً در همان زمان جواب می‌گیرند.
در واقع، آن برنامه‌ای که برای شما مشکل بوجود آورده، اگر آن برنامه را از یک توزیع رایج لینوکس گرفته‌اید، بهتر است سوال خود را در انجمن/لیست مربوط به آن توزیع بپرسید، قبل از اینکه در انجمن/لیست مربوط به پروژهٔ آن برنامه بپرسید. هکرهای آن پروژه ممکن است فقط بگویند که «از نسخهٔ ساخته‌شدهٔ ما استفاده کنید».
قبل از پست کردن در هر انجمن وب، بررسی کنید که آیا یک قابلیت جستجو در آن انجمن هست یا نه. اگر هست، دوبار کلمات کلیدی را برای چیزی شبیه مشکل خود جستجو کنید؛ این کار فقط ممکن است کمک کند. حتی اگر یک جستجوی کلی در وب هم انجام دادا باشید(که بهتر است انجام داده باشید)، باز هم انجمن را جستجو کنید؛ موتور جستجوگر وب شما ممکنه است اخیراً تمام این انجمن را فهرست‌نویسی(index) نکرده باشد.
پروژه‌ها یک تمایل فزاینده‌ای دارند برای اینکه پشتیبانی کاربران را از طریق یک انجمن وب یا کانال IRC انجام دهند، و ایمیلی که بیشتر برای ترافیک توسعه رزرو شده است(نه پشتیبانی کاربر). پس برای کمک‌گرفتن‌های مربوط به پروژه، به دنبال آن کانال‌ها باشید.

بعنوان گام دوم، از لیست پستی پروژه استفاده کنید
وقتی پروژه‌ای یک لیست پستی توسعه دارد، سوال خود را در لیست پستی بنویسید نه به شخص توسعه‌دهدگان، حتی اگر گمان می‌کنید که می‌دانید چه کسی بهتر از همه می‌تواند به سوال شما جواب دهد. مستندات پروژه و صفحهٔ خانگی آن(در وب) را بررسی کنید تا آدرس لیست پستی پروژه را پیدا کنید، و از آن استفاده کنید. چندین دلیل خوب برای این خط‌مشی وجود دارد:
اگر یک سوال برای پرسیدن از یک توسعه‌دهنده، بقدر کافی خوب باشد، ارزش پرسیدن در کل گروه را هم دارد. برعکس، اگر گمان می‌کنید که سوال شما برای یک لیست پستی بسیار تکراری است، پس عذری هم برای آزار دادن توسعه‌دهندگان منفرد وجود ندارد.
پرسیدن سوالات در لیست‌های پستی، بارِ جواب دادن را بین توسعه‌دهندگان تقسیم می‌کند. یک توسعه‌دهندهٔ منفرد(بخصوص اگر راهبر پروژه باشد) ممکن است آنقدر سرش شلوغ باشد که نتواند به سوال شما جواب دهد.
بیشتر لیست‌های پستی، آرشیو می‌شوند، و آرشیوها را موتورهای جستجو فهرست‌نویسی(index) می‌کنند. اگر شما سوال خود را در لیست پستی بپرسید و جواب بگیرید، افراد دیگری که در آینده همان سوال را دارند می‌توانند سوال شما و جوابش را در وب پیدا کنند، بجای اینکه دوباره آن را بپرسند.
اگر سوالات خاصی به نظر می‌رسند که دارند بارها پرسیده می‌شوند، توسعه‌دهندگان می‌توانند از آن اطلاعات استفاده کنند برای بهبود مستندات یا خود نرم‌افزار تا واضح‌تر باشد. اما اگر آن سوالات بصورت شخصی پرسیده شوند، هیچ کس تصویر کاملی ندارد از اینکه چه سوالاتی بیشتر از بقیه پرسیده می‌شوند. اگر یک پروژه هم برای «کاربر» و هم برای «توسعه‌دهنده» (یا «هکر»)، لیست پستی یا انجمن وب دارد، و شما با کد برنامه کاری ندارید(و با کد آن درگیر نمی‌شوید)، سوال خود را در لیست/انجمن مربوط به کاربر بپرسید. تصور نکنید که در لیست پستی توسعه‌دهنده مورد استقبال واقع خواهید شد، در حالیکه احتمالاً آنها سوال شما را بعنوان یک پارزیت حساب می‌کنند که در جریان مباحثهٔ توسعه‌دهندگان گسستگی ایجاد می‌کند.
با این حال، اگر مطمئنید که سوال شما جزئی(و کم‌مایه) نیست، و طی چند روز جوابی در لیست/انجمن «کاربر» نگرفتید، از لیست پستی «توسعه‌دهنده» استفاده کنید. می‌توانید بخوبی مصلحت‌اندیش باشید و قبل از پست کردن، یکی دو روز آنجا(لیست پستی «توسعه‌دهنده») را زیر نظر بگیرید تا با جَو و عرف محلی آنجا آشنا شوید(در واقع این مصلحت خوبی برای هر لیست خصوصی یا نیمه‌خصوصی است).
اگر نمی‌توانید آدرس لیست پستی پروژه را پیدا کنید، و فقط آدرس نگهدارنده(maintainer) پروژه را می‌بینید، پیش بروید و سوال خود را برای گهدارنده(maintainer) پروژه بنویسید. اما حتی در این حالت هم فرض نکنید که لیست پستی وجود ندارد. در ایمیل خود اشاره کنید که شما سعی کردید ولی نتوانستید لیست پستی مناسب را پیدا کنید. همینطور اشاره کنید که مخالفتی ندارید اگر پیغام شما به افراد دیگری منعکس شود(forward شود). (بعضی افراد معتقدند که ایمیل خصوصی باید خصوصی بماند، حتی اگر هیچ چیز محرمانه در آن نباشد. اگر اجازه بدهید که پیغام شما forward شود، به طرف مقابل این انتخاب را می‌دهید که چطور با ایمیل شما رفتار کند[خودش جواب دهد یا به شخص دیگری بسپارد، یا مثلاً در یک لیست پستی یا انجمن قرار دهد])

از عناوین پرمعنا و دارای موضوع مشخص، استفاده کنید
در لیست‌های پستی، گروه‌های خبری یا انجمن‌های وب، عنوانِ موضوع، فرصت طلایی شماست تا با حدود ۵۰ کاراکتر یا کمتر، توجه متخصصانِ قابل را جلب کنید. با یاوه‌هایی مثل «لطفاً به من کمک کنید»، آن را هدر ندهید(پیعام‌هایی با چنین این‌گونه عناوین، از طریق واکنش دور انداخته می‌شوند). سعی نکنید با عمق اضطراب خود، ما را تحت تاثیر قرار دهید؛ در عوض، از آن فضا برای یک توصیف بسیار مختصر از مشکل خود استفاده کنید.
یک قرارداد خوب برای عنوان موضوع‌ها، که تعدادی از سازمان‌های پشتیبانیِ فنی استفاده کرده‌اند، اینست که به شکل «شیء - اِشکال» باشد. قسمت «شیء» مشخص می‌کند که کدام چیز یا کدام مجموعه از چیزها با مشکل مواجه است، و قسمت «اِشکال» انحراف رفتار آن شیء از آنچه انتظار می‌رود را شرح می‌دهد.

. احمقانه:
کمک! ویدئو روی لپ‌تاپ من درست کار نمی‌کند!

. هوشمندانه:
مکان‌نمای خراب موس X.org 6.8.1، چیپست ویدئوFooware MV1005 vid. chipset
Fooware MV1005 X.org 6.8.1 misshapen mouse cursor,

. هوشمندانه‌تر:
مکان‌نمای موس 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 ؟ یک هکر که نتیجه را می‌بیند، فوراً می‌تواند بفهمد که شما با چه چیزی مشکل دارید، و در یک نگاه مشکل شما را بفهمد.
کلی‌تر، تصور کنید که به یک لیست از سوالات یک آرشیو نگاه می‌کنید، که فقط خطوط عنوان‌ها نمایش داده می‌شوند. عنوان پست خود را طوری انتخاب کنید که بخوبی سوال شما را منعکس کنید، تا شخص بعدی که آرشیو را جستجو می‌کند، بتواند دنبال آن ریسمان(thread) را بگیرد و به یک جواب برسد، بجای اینکه دوباره آن سوال را پست کند.
اگر شما یک سوال را در پاسخ می‌فرستید، مطمئن شوید که خط عنوان را تغییر دهید تا نشان دهد که در حال پرسیدن یک سوال هستید. یک خط عنوان مانند «پاسخ: تست» یا «پاسخ: باگ جدید» کمتر احتمال می‌رود که به قدر مفیدی توجه را جلب کند. همینطور در نقل قول پیام‌های قبلی، با حذف قسمتهای اضافه، آن را به حداقل برسانید تا با mail reader های جدید سازگار باشد .
برای شروع یک ریسمان کاملاً جدید، به سادگی دکمهٔ پاسخ را فشار ندهید. با این کار، بازدیدکنندگان را محدود خواهید کرد. بعضی mail reader ها مثل mutt به کاربر اجازه می‌دهند که بر اساس ریسمان مرتب کنند و سپس پیام‌های داخل یک ریسمان را با تا کردن آن پنهان کنند. افرادی که این کار را انجا دهند هرگز پیام شما را نخواهند دید.
تغییر دادن عنوان، کافی نیست. Mutt و شاید دیگر mail reader ها، برای تعیین یک ریسمان، به اطلاعات دیگری در سرآیند ایمیل‌ها نگاه می‌کنند، نه به خط عنوان. بجای این کار یک ایمیل کاملاً جدید را شروع کنید.
در انجمن‌های وب، قواعد رفتار خوب، کمی متفاوت است، چون پیام‌ها معمولاً خیلی بیشتر به یک بحث خاص محدود هستند، و معمولاً خارج از آن ریسمان‌ها(تاپیک‌ها) قابل مشاهده نیستند. هنگام پرسیدن یک سوال در پاسخ به ریسمان، تغییر دادنِ عنوان لازم نیست. حتی همهٔ انجمن‌ها اجازه نمی‌دهند که پاسخ‌ها بتوانند عنوان جداگانه‌ای داشته باشند، و اگر هم چنین کاری انجا دهند تقریباً آنها را نمی‌خواند. به‌هرحال، پرسیدن یک سوال در یک پاسخ، به خودی خود مورد شک است، چون آن فقط توسط افرادی دیده خواهد شد که این ریسمان را دنبال می‌کنند. پس یک ریسمان(تاپیک) جدید را آغاز کنید، مگر اینکه مطمئنید می‌خواهید فقط از افرادی بپرسید که در حال حاظر در این ریسمان فعال هستند.

پاسخ دادن را آسان کنید
پایان دادن سوال با این عبارت که «لطفاً پاسخ خو را به ... بفرستید»، جواب گرفتن شما را کاملاً بعید می‌سازد. اگر شما حتی نمی‌توانید چند ثانیه به خودتان زحمت دهید که یک عنوان پاسخ-به در mail reader خود تنظیم کنید، ما هم نمی‌توانیم چند ثانیه به خودمان زحمت دهیم که دربارهٔ مشکل شما فکر کنیم. اگر نرم‌افزار ایمیل شما این امکان را نمی‌دهد، از یک mail reader بهتر استفاده کنید.
اگر سیستم‌عامل شما از هیچ mail reader ی که این امکان را بدهد، پشتیبانی نمی‌کند، از یک سیستم‌عامل بهتر استفاده کنید. در انجمن‌های وب، درخواست پاسخ از طریق ایمیل، کاملاً گستاخانه است، مگر اینکه معتقد باشید آن اطلاعات حساس هستند(و شخصی به هر دلیلی می‌خواهد آن را فقط به شما اطلاع دهد و نه به دیگران). اگر می‌خواهید هنگام پاسخ هر فرد، یک ایمیل کپی از آن به شما ارسال شود، از آن انجمن وب درخواست کنید که آن را برای شما ارسال کند؛ این امکان تقریباً همه جا تحت عناوینی مثل «این ریسمان را دنبال کن»، «هنگام پاسخ، ایمیل بفرست» و غیره، مورد پشتیبانی است.

بصورت واضح، از لحاظ دستوری صحیح، و با املای صحیح بنویسید
ما به تجربه دریافتیم افرادی که نویسندگان بی‌دقت و نامرتبی هستند، در فکر کردن و کدنویسی هم بی‌دقت و نامرتب هستند. جواب دادن به افرادی که فکر نامرتب و شلخته‌ای دارند، چندان مفید نیست؛ ما ترجیح می‌دهیم وقت خود را جای دیگری صرف کنیم.
پس مهم است که سوال خود را واضح و خوب بیان کنید. اگر نمی‌توانید زحمت آن را بکشید، ما هم نمی‌توانیم به آن توجه کنیم. تمام سعی خود را بکنید تا زبان(بیان) خود را بهبود دهید(صیقل دهید). لازم نیست که رسمی و سنگین باشد — در واقع فرهنگ هکرها به آن طرز بیانی بها می‌دهد که غیررسمی، عامیانه و شوخ‌طبعانه و همراه با دقت و ظرافت باشد. اما آن باید دقیق باشد؛ باید نشانه‌هایی باشد که شما اندیشه و توجه می‌کنید.
املا، نشانه‌گذاری و بزرگ کردن حروف اول را درست انجام دهید. its را با it's و loose را با lose و discrete را با discreet اشتباه نگیرید.تمام حروف را بزرگ ننویسید؛ این مانند فریاد زدن تعبیر می‌شود و خشن تصور می‌شود. (اگر تمام حروف هم کوچک باشد، فقط کمی رنجش‌آور بوده و خواندن آن را سخت می‌کند.)
کلی‌تر، اگر مانند یک انسان ساده و کم‌سواد بنویسید، بسیار احتمال می‌رود که نادیده گرفته شوید. پس از میانبرهایی که کوتاه‌کنندهٔ متن استفاده نکنید. نوشتن you بصورت u شما را شبیه یک انسان ساده و کم‌سواد می‌کند که می‌خواهد دو کلید کمتر فشار دهد.
اگر دارید سوال خود را در انجمنی می‌پرسید که از زبان بومی شما استفاده نمی‌کند، شما یک میزان محدودی از خطاهای املایی و دستوری خواهید داشت، اما از روی تنبلی دچار خطاهای بیش از حد نشوید(بله، ما معمولاً می‌توانیم آن تفاوت را تشخیص دهیم). همینطور اگر نمی‌دانید که شخص پاسخگو چه زبانی دارد، به انگلیسی بنویسید. هکرهای مشغول، سوالات با زبانی که نمی‌فهمند را نادیده می‌گیرند، و انگلیسی زبان کاری اینترنت است. با نوشتن به زبان انگلیسی، این احتمال را که سوالتان بدون خوانده شدن پاک شود، به حداقل می‌رسانید.

سوال خود را در قالب های استاندارد و در دسترش مطرح کنید:
اگر سوال خود را به طور مصنوعی سخت کنید، احتمال نادیده گرفتن آن بیشتر می شود لذا:

نامه را با فرمت"plaintext"و نه "HTML" بفرستید. (غیر فعال کردن HTML کار سختی نیست) ضمیمه های MIMEمعمولاً مناسب هستند اگر شامل مطالب واقعاً ضروری باشند.
نامه خود را به صورت پاراگراف هایی که از خطوط به هم پیچیده شده.

تشکیل شده اند، نفرستید. این کار، پاسخ گویی به قسمتهای مختلف نوشته شما را دشوار می کند، فرض کنید که پاسخگویی شما، نامه شما را در صفحاتی با خطوط شامل 80 کاراکتر می بیند، لذا خطوط خود را در 80 کاراکتر یا کمتر تهیه کنید.
- داده های خود را مانند آدرس فایل ها به چند خط تبدیل نکنید تا در عرض یک ستون قرار گیرد. داده ها باید به همان صورتی که هستند
در نامه قرار بگیرند تا خواننده مطمئن شود که چیزی را می‌بیند که شما قبلاً دیده‌اید.
- هرگز تصور نکنید که مخاطبین شما قادر به خواند فایلهای اختصاصی مانند Microsoft word یا Excel هستند. بسیاری از هکرها به این کار همانند وقتی که یک توده‌ای از کود که بوی خوک می دهد و در جلوی در باشد، به آن واکنش نشان می‌دهند و اگر هم بتوانند به آن غلبه کنند، این کار نمی‌کنند.
- اگر شما از سیستم عامل window نامه می‌فرستید، امکان "smart Quotes" را غیر فعال کنید. این کار از فرستاده شدن کاراکترهای بی‌مصرف جلوگیری می‌کند.
- در صفحات گفتگو، از اشکال خندان (Smilg) و امکانات HTML استفاده نکنید. یکی دو تا از این اشکال ایرادی ندارد اما اگر صورت نوشته شما با این گونه اشکال پر شده باشد، دیگران فکر می‌کنند که شما عاجز از نوشتن هستید. بطور جدی استفاده بیش از حد از این اشکال و رنگی کردن نوشته‌ها شما را شبیه دختر نوجوانی که در حال خندیدن است می‌کند که این کار عموماً برای شما جوابی به همراه ندارد.
اگر شما از یک پردازش‌گر ایمیل با صورت گرافیکی کاربری مانند MS Out look Netscape Messenger و یا از این‌گونه‌ها استفاده می‌کنید، آگاه باشید که در صورتی که از تنظیمات پیش‌فرض آن استفاده می‌کنید، ممکن است این قوانین نقض شوند.
بیشتر این پردازشگرها دارای یک دستور در فهرست خود به نام view source هستند از این گزینه در پوشه نامه‌های فرستاده خود استفاده کنید و فرستادن نوشته ساده (pain tent) بدون ضمایم غیر ضروری را بررسی کنید.

درباره مشکل خود دقیق و آگاه باشید:
- نشانه‌های مشکل ایجاد شده یا bugها را به دقت و روشنی شرح دهید.
- محیطی که در آن این مشکل ایجاد می‌شود را شرح دهید. (سیستم عامل، کاربرد و ...) شرکت فروشنده و مدل آنرا هم معرفی کنید مثلا (Fedora Coret یا Slackware 91 و ...)
- مطالعاتی که بر روی این مشکل انجام داده‌اید را شرح دهید.
- مراحل تشخیص مشکل و رفع آنرا که انجام داده‌اید، قبل از طرح سوال، شرح دهید
- هرگونه تغییر در سخت‌افزار یا نرم‌افزار که اخیراً انجام شده است را شرح دهید.
تلاش کنید تا به سوالاتی که پیش‌بینی می‌کنید از شما پرسیده شوند،‌ پیش‌تر پاسخ دهید.
Simon Tatham مقاله جالبی به نام «چگونه Bug ها را به طور موثر گزارش کنیم». نوشته است که قویاً توصیه می‌شود آنرا بخوانید.

حجم مطالب دلیلی بر دقیق بودن آن نیست:
باید دقیق و آموزنده بنویسید. این هدف با نوشتن حجم زیادی از داده‌ها و کدها در نامه تقاضای کمک محقق نمی‌شود. اگر یک مشکل بزرگ و پیچیده دارید، سعی کنید تا آنرا تا حد ممکن خلاصه و مرتب ارائه کنید.
این امر حداقل سه فایده دارد. اول اینکه معلوم شود که شما برای خلاصه کردن سؤال خود تلاش کرده‌اید یا تمایل بیشتری برای پاسخ به شما وجود خواهد داشت. دوم اینکه با خلاصه‌سازی پاسخ مفیدتری هم خواهید گرفت. و سوم اینکه در حین خلاصه کردن و پیرایش گزارش خود ممکن است بتوانید مشکل حل کنید یا راه حل کوتاهتری برای آن پیدا کنید.

ادعای یافتن یک bug را نکنید!:
هنگامی که با یک نرم‌افزار به مشکل برخوردید، بدون اطمینان کامل ادعای یافتن یک bug جدید را مطرح نکنید. راهنمایی: تا هنگامی که با یک ضمیمه به کد منبع نتوانید مشکل را برطرف کنید یا با آزمایش رگرسیون با ورژن قبلی که نشان دهنده یک رفتار نادرست باشد، شما نباید مطمئن شوید. این امر در مورد وب سایت‌ها و مدارک هم صدق می‌کند سندی را به عنوان bug یافتید، باید متنی را جایگزین آن کنید یادآوری می‌شود که کاربران بسیاری هستند که مشکل شما را تجربه نکرده‌اند. همچنین شما با خواندن مطالب و وب سایت‌های مرتبط، در مورد آن نرم‌افزار آموزش دیده‌اید در غیر این صورت شما کاری را اشتباه انجام می‌دهید و نه نرم‌افزار.
افرادی که یک نرم‌افزار را تهیه می‌کنند، تلاش می‌کنند تا آن نرم‌افزار حداکثر کارایی مطلوب را داشته باشد. اگر شما ادعا کنید که یک bug در آن یافته‌اید، در واقع کامل بودن کار آنها را زیر سؤال برده‌اید و این باعث رنجاندن آنهان می‌شود، حتی اگر حق با شما باشد. به خصوص ذکر کلمه bug در عنوان نامه، کار سیاست مدارانه‌ای نیست.
وقتی که سوال خود را مطرح می‌کنید، بهتر است فرض کنید که شما کار اشتباهی را انجام می‌دهید، حتی اگر مطمئن باشید که یک bug واقعی را یافته‌اید. اگر واقعاً این طور باشد، در مورد آن در پاسخ‌ها خواهید شنید. با این کار نگهدارنده‌های نرم‌افزار از شما عذرخواهی خواهند کرد، همچنین اگر شما اشتباه کرده باشید، باید از آنها عذرخواهی کنید.

منبع: www.barnamenevis.org