چگونه هوشمندانه سوال بپرسیم

رفع ادعا

بسیاری از وب سایت ها این مطلب را در بخش «چگونه کمک بگیریم» قرار می دهند. این کار ایرادی ندارد، چون ما هم همین قصد را داشتیم - اما اگر شما یک وب مستر هستید و این لینک را برای صفحه ی پروژه ی خود ایجاد می کنید

لطفا به صورت برجسته در کنار لینک ذکر کنید که: ما به عنوان یک help desk برای پروژه ی شما نیستیم!

ما از طریقی سخت [تجربه های قبلی] فهمیدیم که بدون چنین توجهاتی، ما با هجوم حجم قابل توجهی از احمق هایی مواجه می شویم که فکر می کنند منتشر کردن این مطلب حل کردن تمام مشکلات تکنیکی دنیا را وظیفه ی ما میکند!

اگر این مطلب را می خوانید چونکه به کمک نیاز دارید و احساسی را به طور مستقیم از نویسندگان این مطلب گرفته اید [ناراحتید از اینکه چرا نمیایم مشکلاتتون رو حل کنیم]، شما یکی از همان احمق ها هستید! از ما هیچ سوالی نپرسید چون ما فقط شما را نادیده خواهیم گرفت. ما صرفا در این مطلب سعی کردیم تا به شما نشان دهیم که چطور باید از افراد مطلع در زمینه ی سخت افزار و نرم افزار کمک گرفت.

اما در ۹۹.۹٪ مواقع، آن افراد ما نیستیم! مگر اینکه مطمئن باشید که یکی از نویسندگان این مطلب در حوزه ی کاری شما متخصص است. ما را رها کنید تا همگی شاد و خوشحال باشیم!

معرفی

در جهان هکر ها، چیزی که در جواب سوال تکنیکی خود می گیرید به نحوه ی سوال پرسیدن شما بستگی دارد و روی میزان سختی جواب دادن به سوال شما تاثیر می گذارد. این راهنما به شما آموزش می دهد که چگونه سوال بپرسید تا دریافت یک پاسخ رضایت بخش محتمل تر باشد.

امروزه که استفاده از open source همه گیر شده، معمولا جواب های خوبی برای سوالاتمان از دیگران و همینطور از کاربران مجرب تر مثل هکر ها پیدا می کنیم و این خوب است. کاربران سعی می کنند تا در برابر مشکلاتی که نوب ها [تازه وارد ها] با آن ها درگیرند کمی صبور تر باشند. اما همچنان رفتار کردن با کاربران با تجربه مثل هکر ها به شیوه ای که ما در اینجا به آن اشاره می کنیم به طور کلی موثر ترین راه برای گرفتن جواب های بدرد بخور از آنهاست.

اولین چیزی که باید بدانید این است که هکر ها در واقع مسئله های خوب و سخت، و سوالاتی که ذهن را تحریک می کند دوست دارند. اگر اینطور نبود، ما اینجا نبودیم! اگر شما به ما یک سوال بدهید تا روی آن کار کنیم، ما قدردان شما خواهیم بود. سوالات خوب محرک و هدیه هستند و به ما در اعتلای فهم کمک می کنند. همینطور گاهی مشکلاتی که ممکن است به آن فکر نکرده باشیم را به ما نشان می دهد. بین هکر ها جمله ی «سوال خوبی بود!» یک تمجید قوی و خالص به حساب می آید.

برخلاف این، هکر ها شهرتی در پاسخ دادن به سوالات ساده با جواب های به ظاهر غیر محترمانه یا متکبرانه دارند. گاهی این طور به نظر می رسد که نسبت به نوب ها و نادان ها با بی ادبی برخورد می کنیم. اما این واقعا حقیقت ندارد.

ما متخاصم نسبت به کسانی هستیم که تمایلی به فکر کردن ندارند و مشق های خودشان را قبل از سوال پرسیدن حل نکردند و به خاطرش از کسی عذرخواهی نمی کنیم. چنین کسانی مثل یک سینک ظرف شویی برای زمان هستند. اون ها استفاده می کنند بدون اینکه بازدهی ای داشته باشند و زمان را تلف می کنند. زمانی که می توانستیم صرف سوالی جالب تر و یا انسانی شایسته تر برای پاسخ کنیم. ما به چنین کسانی «بازنده» می گوییم.

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

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

اگر شما این طرز فکر را منزجر کننده، مشفقانه و یا متکبرانه می دانید، فرضیات خود را چک کنید. ما قصد نداریم که شما را به زانو در آوریم. در حقیقت بیشتر ما چیزی بیشتر از برخورد با مساوات با همه ی شما را دوست نداریم (مشروط به اینکه تلاش لازم را برای تحقیق آن داشته باشید). ولی کمک کردن به کسانی که خودشان حاضر به کمک کردن به خودشان نیستند برای ما میسر نیست. نامطلع بودن ایرادی ندارد، ولی احمق بازی درآوردن خیلی ایراد دارد!

پس با وجود اینکه لزومی ندارد تا شما از لحاظ تکنیکی شایسته باشید تا توجه ما را بدست بیاورید، نشان دادن نشانه های دیدگاهی که منجر به شایستگی می شود مثل هوشیار بودن، متفکر بودن، مشاهده گر بودن و تمایل داشتن به مشارکت فعال در حل مسئله ضروری است. اگر با چنین تبعیضی نمی توانید کنار بیایید به شما پیشنهاد می دهیم برای عقد قرارداد حمایت تبلیغاتی کسی را اجیر کنید به جای اینکه از هکر ها بخواهید به شما کمک اهدا کنند!

اگر تصمیم شما به کمک خواستن از ماست، نباید یکی از آن بازنده ها باشید. بهترین راه برای سریع جواب گرفتن، با فراست و با اطمینان پرسیدن است و نشان دادن این مطلب که شما به کمک ما در مشکلی بخصوص احتیاج دارید.

(مقدم کسانی که خواهان بهبود این راهنما هستند را خوشامد می گوییم! می توانید پیشنهادات خود را به ‏[email protected] یا [email protected] ارسال کنید. در نظر داشته باشید که این مطلب به هدف راهنمایی در مورد netiquette نیست و ما عموما پیشنهاداتی که خصوصا به تحصیل پاسخی کاربردی در یک فرم تکنیکی ارتباطی ندارند را رد می کنیم.)

قبل از اینکه بپرسید

قبل از پرسیدن یک سوال فنی با ایمیل یا در یک گروه خبری یا در یک وب سایت کار های زیر را انجام دهید.

سعی کنید جوابی پیدا کنید با استفاده از:

۱. جستجوی آرشیو های forum یا mailing list که قصد پست گذاشتن در آن را دارید

۲. جستجوی وب

۳. مطالعه ی manual

۴. مطالعه ی FAQ

۵. بررسی و آزمودن

۶. پرسیدن از دوستانی که در این زمینه مهارت دارند

۷. مطالعه ی source code (اگر یک برنامه نویس هستید)

وقتی که شما سوالی می پرسید، این حقیقت را نشان می دهید که این کار ها را در ابتدا انجام داده اید و این نکته را می رساند که شما یک اسفنج تنبل نبوده اید و وقت مردم را تلف نکرده اید و بهتر از آن، نشان می دهید که شما به واسطه ی انجام دادن این کار ها آموخته اید. ما متمایل هستیم به سوالات کسانی جواب دهیم که نشان داده اند می توانند از جواب ها بیاموزند.

از تاکتیک هایی مثل جستجو کردن متن ارور سیستم (error message) در گوگل (و همینطور Google groups) استفاده کنید. این کار می تواند شما را مستقیما به مطلب راهنمای مورد نظرتان برساند. حتی اگر به نتیجه ای هم نرسیدید، ذکر این مطلب که شما این کار را انجام داده اید در ایمیل یا وب سایتی که برای پرسش خود به آن رجوع کرده اید مفید واقع خواهد شد. چون این کار به ثبت این موضوع که در جستجو ها به راه حل مشکل شما اشاره ای نشده کمک می کند و همچنین افرادی که به مشکلی مشابه مشکل شما برخورد کرده اند را به رشته ی شما هدایت میکند.

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

سوال خود را آماده کنید. به خوبی به آن فکر کنید. سوالات سهل انگارانه و بی دقت پاسخ های چرت و پرت می گیرند یا اصلا پاسخی نمی گیرند. به هر اندازه نشان دهید که به سوال خود به خوبی فکر کرده و روی آن کار کرده اید احتمال رسیدن به پاسخ برای شما بیشتر خواهد بود.

از پرسیدن سوال اشتباه بر حذر باشید. اگر سوالی مبتنی بر فرض های مشکل دار بپرسید، هکر تصادفی شما در حالی که زیر لب می گوید «چه سوال احمقانه ای!..» به شما یک جواب بدرد نخور خواهد داد و تجربه کردن چیزی که به اشتباه درخواست کرده بودید به جای چیزی که به آن احتیاج داشتید به شما درس خوبی خواهد داد.

هرگز فکر نکنید که شما برای دریافت پاسخ «محق» هستید. شما نیستید. به هیچ وجه. شما به جواب می رسید تنها در صورتی که آن را «بدست» بیاورید. آن هم با پرسیدن یک سوال ظریف، جالب و ذهن تحریک کن! سوالی که در لفافه به تجربه ی جامعه ی نرم افزاری کمک میکند. نه سوالی که صرفا محتوی نیازی گذرا از دانش دیگران است.

از سوی دیگر، شفاف سازی این مطلب که شما قادر و خواهان کمک به پروسه ی ایجاد و توسعه ی یک راه حل هستید نقطه ی خوبی برای شروع است. سوالاتی نظیر: «میشه یه نفر یه نکته برای راهنمایی بگه؟»، «توی مثال من چه مشکلی هستش؟ چی کمه؟»، «چه سایت هایی رو باید چک میکردم؟» احتمال بیشتری برای دریافت پاسخ دارند تا سوالاتی مثل: «لطفا مسیر دقیقی رو که باید طی کنم برام بنویسین» چون با پرسش های بالا شما نشان می دهید که حقیقتا به دنبال کامل کردن پروسه هستید و فقط به یک راهنمایی ساده برای پیدا کردن مسیر درست نیاز دارید.

وقتی که می پرسید
‏forum خود را به دقت انتخاب کنید

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

• سوال خود را در forum ی که ربطی به موضوع سوال شما ندارد پست کنید

• یک سوال بچگانه را به forum ی که در آن سوالات فنی می شود یا vice-versa بفرستید

• به newsgroups های مختلف سوالات یکسان خود را بفرستید

• یک ایمیل شخصی را به کسی که نه آشنای شماست نه شخصا مسئول حل مشکل شماست بفرستید

هکر ها سوال های نامربوط را به قصد حفاظت از یکپارچگی مطالب موجود در اجتماعات و کانال های خودشان از بین می برند. باور کنید اصلا دلتان نمی خواهد چنین چیزی برایتان اتفاق بیفتد.

بنابراین اولین قدم پیدا کردن forum مناسب است. گوگل و مابقی موتور های جستجو به شما کمک میکنند تا مرتبط ترین صفحات وب به مشکل نرم/سخت افزاری تان را پیدا کنید و معمولا به لیست FAQ و به پروژه ها و آرشیو های mailing lists لینک می شوند. این mailing lists ها آخرین مکان هایی هستند که برای کمک گرفتن باید به سراغشان رفت. صفحات پروژه هم ممکن است به یک روند bug-reporting اشاره کنند. اگر اینطور بود، آن را دنبال کنید.

ایمیل فرستادن برای کسی یا جایی که با آن آشنایی ندارید هم ریسک بالایی دارد. برای مثال فکر نکنید که نویسنده ی یک صفحه ی اطلاع رسان تمایل دارد مشاوره ی رایگان به شما دهد. درباره ی پیامد های ارسال پرسش خود خوشبین نباشید. اگر اطمینان ندارید به جای/کس دیگری بفرستید یا اصلا از فرستادن آن امتناع کنید.

وقتی که یک forum، newsgroup، mailing list را انتخاب می کنید، صرفا به عنوان آن اعتماد نکنید. به دنبال یک FAQ یا چارتر (charter) برای تا مطمئن شوید که سوال شما به موضوع مورد بحث آنها ارتباط دارد. قبل از پست گذاشتن، تعدادی از مباحثی که پیشتر آنجا مطرح شده است را مطالعه کنید تا بفهمید اوضاع از چه قرار است. در واقع این ایده ی خوبیست که قبل از پست کردن مسئله ی خود کلید واژه های مربوط به آن را در صفحات مد نظر جستجو کنید. با انجام این کار یا به پاسخی خواهید رسید و یا سوال بهتری به ذهنتان خطور خواهد کرد.

تمام کانال های راهنما را به یک باره با آتش سوالات خود نسوزانید! این کار مثل فریاد کشیدن است و باعث رنجش دیگران می شود. به آرامی و گام به گام پیش روید.

شما طبیعتا می دانید که موضوع سوال تان چیست! یکی از اشتباهات متداول این است که سوالی درباره ی Unix یا برنامه نویسی محیط ویندوز (Windows programming interface) در یک forum که متعلق به یک زبان برنامه نویسی یا library یا ابزاری که از هر دو سمت portable است، بپرسید. اگر نمی فهمید که چرا این کار یک اشتباه احمقانه محسوب می شود بهتر است تا زمانی که این را بفهمید کلا هیچ سوالی نپرسید!

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

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

اورفلو شدن استک

(Stack Overflow)

عبارت فوق و سپس عبارت تبادل استک (Stack Exchange) را جستجو کنید.

در سالهای اخیر، سایت های مختص به اجتماعات Stack Exchange به عنوان یک منبع عمده برای پاسخگویی به سوالات فنی و دیگر سوالات پدیدار شده اند و حتی به عنوان یک forum برای پروژه های open-source متعددی ترجیح داده شده اند.

با یک جستجوی گوگل قبل از نگاه کردن به Stack Exchange شروع کنید. گوگل آن را در آن واحد فهرست می کند. احتمال دارد که تا الان کسی سوال مشابهی را پرسیده باشد و سایت های Stack Exchange معمولا جزو اولین نتایج نمایش داده شده هستند. اگر از طریق گوگل چیزی پیدا نکردید، در سایتی دیگر که بیشترین ارتباط را با سوال مد نظر شما دارد جستجو کنید. جستجو با استفاده از تگ (tags) می تواند به محدود کردن نتایج جستجو کمک کند.

اگر همچنان چیزی پیدا نکردید، سوال خود را در وب سایتی مطرح کنید که موضوع محور ترین است. از formatting tools به خصوص برای کد استفاده کنید. تگ هایی که به اجزاء سوال شما مرتبط است را اضافه کنید (علی الخصوص نام زبان برنامه نویسی، سیستم عامل و یا library که با آن به مشکل برخورد کرده اید). اگر کسی در بخش نظرات از شما برای اطلاعات بیشتر پرسید، پست اصلی خود را ویرایش کنید تا شامل آن نیز بشود. اگر جوابی بدرد بخور بود، فلش رو به بالا را کلیک کنید (click the up arrow) تا به مفید بودن آن رای دهید (upvote). اگر یکی از پاسخ ها به شما راه حلی برای مشکل داد، گزینه ی چک که زیر فلش های رای قرار دارند را کلیک کنید تا به درست بودن جواب مطرح شده رای دهید.

تعداد سایت های Stack Exchange به بیش از ۱۰۰ رسیده است، ولی این ها محتمل ترین کاندیدا ها هستند:

• Super User درباره ی سوالات مربوط به حوزه ی general-purpose computing است. اگر سوال شما مربوط به کد یا برنامه هایی با محوریت اتصال شبکه است (programs that you talk to only over a network connection)، پس احتمالا سوال شما مربوط به اینجاست.

‏+ Stack Overflow برای سوالاتی با محوریت برنامه نویسی است.

‏+ Server Fault درباره ی سوالات مربوط به سرور و مدیریت شبکه است (server and network administration).

تعدادی از پروژه ها سایت های بخصوص خود را دارند، من جمله اندروید، اوبونتو، TeX/LaTeX و SharePoint. برای یک لیست به روز رسانی شده به سایت Stack Exchange سر بزنید.

فروم های وب و آی آر سی

(Web and IRC forums)

گروه کاربری محلی (local user group) یا توزیع لینوکس شما (Linux distribution)، ممکن است یک Web forum یا IRC channel را تبلیغ کنند. جایی که نوب ها (آماتور ها) بتوانند کمک بگیرند (در کشور های غیر انگلیسی زبان، فروم های مختص به نوب ها (newbie forums) هنوز احتمال دارد که به صورت mailing lists باشند). این ها مکان های مناسبی برای مراجعه ی اول جهت پرسیدن سوال هستند، مخصوصا اگر فکر می کنید که به یک سوال نسبتا ساده یا مشکلی متداول برخورد کرده اید. یک IRC channel تبلیغ شده، در حکم یک دعوت عمومی برای پرسش و پاسخ است و معمولا پاسخگویی آنی ارائه می شود.

در واقع اگر شما برنامه ای دارید که مشکلاتی از یک توزیع لینوکس برای شما ایجاد می کند (که امروزه متداول است)، شاید بهتر باشد قبل از امتحان کردن برنامه ی project forum/list در distro’s forum/list آن را مطرح کنید. هکر های پروژه ممکن است فقط بگویند: از ساز و کار ما استفاده کنید (use our build).

قبل از پست گذاشتن در هر Web forum، بررسی کنید تا قابلیت جستجو داشته باشد. اگر اینطور بود، برای چیزی مشابه مشکل خودتان چند کلید واژه را جستجو کنید. شاید کمکی کرد. اگر از قبل یک جستجوی وب عمومی انجام داده باشید (که باید هم انجام داده باشید!)، در forum به هر حال جستجو کنید. موتور جستجوی شما ممکن است تمام این forum را اخیرا فهرست نکرده باشد.

یک تمایل افزاینده در Web forum یا IRC channel ها برای پروژه هایی با رزرو ایمیل جهت توسعه ی ترافیک وجود دارد تا حمایت از کاربر را انجام دهند. پس وقتی که نیاز به کمک در پروژه ی خاصی دارید، ابتدا به دنبال چنین کانال هایی باشید.

در IRC، بهتر است که در اولین قدم، یک توضیح بلند بالا و طولانی از مشکل مان را نگذاریم. بعضی از افراد این را تحت عنوان سیلاب کانال (channel-flooding) تفسیر می کنند. بهترین کار این است که یک توضیح یک خطی از مشکل را به شیوه ای که یک مکالمه را در کانال راه بیندازد، بیان کنیم.

به عنوان قدم دوم، از mailing list پروژه ها استفاده کنید

وقتی که یک پروژه، یک mailing list برای توسعه دارد، به mailing list مطالب خود را بنویسید و نه به شخص یا اشخاص توسعه دهنده (دولوپر ها). حتی اگر مطمئن هستید که می دانید کدام شخص یا اشخاص سوال شما را پاسخ می دهند این کار را نکنید. اسناد پروژه و homepage آن را را برای آدرس project mailing list بررسی و استفاده کنید. برای این سیاست دلایل خوبی وجود دارد:

• هر سوالی که آنقدر خوب باشد تا از یکی از توسعه دهنده ها پرسیده شود برای تمام گروه ارزش خواهد داشت. برعکس، اگر مشکوک شوید که سوال شما احمقانه تر از آن است که به mailing list ارسال شود، این بهانه ای برای این نیست که با ارسال آن به افراد توسعه دهنده آنها را آزار دهیم!

• ارائه ی سوال به mailing list باعث پخش شدن بار سوالات میان توسعه دهندگان می شود. هر کدام از توسعه دهندگان به تنهایی (مخصوصا اگر مدیر پروژه باشند) ممکن است درگیر تر از آن باشند که به سوال شما پاسخ دهند.

• بیشتر mailing list ها آرشیو شده اند و آرشیو ها توسط موتور های جستجو فهرست شده اند. اگر سوال خود را در mailing list بگذارید و در آنجا پاسخ داده شود، جوینده ی بعدی می تواند سوال شما را به همراه پاسخ آن با یک جستجوی ساده پیدا کند جای آنکه دوباره آن را بپرسد.

• اگر سوالات مشخصی متداولا پرسیده شوند، توسعه دهندگان می توانند از آن اطلاعات جهت ارتقای اسناد یا خود نرم افزار استفاده کنند تا کمتر گیج کننده به نظر برسند. اما اگر همان سوالات به صورت خصوصی پرسیده شوند هیچکس نخواهد دانست که کدام سوالات، سوالات متداول تری هستند.

اگر یک پروژه در mailing list یا Web forum هم بخش کاربران داشته باشد هم بخش توسعه دهندگان (و هکر ها) و شما در حال هک کردن کد نباشید، پرسش خود را در بخش کاربران (user list/forum) بپرسید. فکر نکنید که در بخش توسعه دهندگان کسی برایتان تره ای خرد خواهد کرد!

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

اگر نمی توانید آدرس mailing list یک پروژه را پیدا کنید و فقط آدرس maintainer پروژه ذکر شده، می توانید به او مراجعه کنید. اما حتی در آن حالت هم فکر نکنید که mailing list وجود ندارد. در ایمیل اشاره کنید که سعی کردید mailing list را پیدا کنید ولی نتوانستید. همچنین اشاره کنید که قصد ندارید که پیام شما برای بقیه فرستاده شود.

از header های با معنی و مشخص استفاده کنید

در mailing list ها، newsgroup ها و Web forum ها، موضوع هدر فرصت طلایی شما برای جذب کارشناسان واجد شرایط با استفاده از حدود ۵۰ کاراکتر یا کمتر است. با چرت و پرت هایی مثل «لطفا کمکم کنید!» این فرصت را از به باد ندهید (پیام هایی مثل این به طور غیر ارادی در ذهن خواننده اصلا حتی دیده نمی شوند). سعی نکنید با عمق غم و اضطراب خود ما را تحت تاثیر قرار دهید. به جای آن، یک شرح مسئله ی فوق کوتاه بنویسید.

یک راه خوب برای نوشتن موضوع هدر که توسط پشتیبان های فنی استفاده می شود، روش “object - deviation” است [یعنی موضوع هدر خود را به این صورت بنویسید که اول هدف (object) و سپس انحراف از آن را (deviation) بنویسید]. بخش object مشخص میکند که چه چیز یا چیزهایی مشکل ساز شده اند و بخش deviation انحراف نتیجه ی کار را از چیزی که انتظار می رفته نشان می دهد.

روش احمقانه:

کمکم کنید! ویدیو توی لپ تاپ من درست کار نمی کنه!

روش هوشمندانه:

‏X.org 6.8.1 نشانگر ماوس تحت Fooware MV1005 vid. chipset به درستی عمل نمی کند.

پروسه ی نوشتن یک توضیح بر اساس روش “object-deviation” باعث نظم دادن به ذهنیت شما و دیدن جزئیات مشکل تان می شود. چه چیزی خراب شده است؟ فقط نشانگر ماوس شما یا بقیه ی اجزای گرافیکی؟ آیا مختص ورژن X.org از نرم افزار X است؟ ورژن 6.8.1؟ مختص Fooware video chipsets؟ مدل MV1005؟ هکری که نتیجه را می بیند به سرعت متوجه می شود که شما با چه چیزی دچار مشکل شده اید و مشکل شما چیست.

به صورت کلی تر، فکر کنید که دارید به فهرست آرشیوی از سوالات نگاه می کنید که تنها موضوع سوالات را نشان شما می دهد. کاری کنید تا موضوع سوال شما به خوبی دربردارنده ی مفهوم سوال شما باشد تا نفر بعدی ای که آرشیو را به دنبال سوالی مشابه سوال شما جستجو می کند قادر باشد تا رشته ی سوالات را تا رسیدن به پاسخ آن پیدا کند، به جای آنکه مجبور شود همان سوال را دوباره پست کند.

اگر سوالی را در قسمت پاسخ و به عنوان یک reply ثبت می کنید، مطمئن شوید که خط موضوع (subject line) را عوض می کنید تا نشان دهید که سوال می پرسید. خط موضوعی که به صورت “Re: test” یا “Re: new bug” باشد شانس کمتری برای جذب توجهات مفید دارد. همچنین، نقل قول هایی که از پیام های گذشته به جا مانده است را حذف کنید تا رشته ی شما کمتر متناقض به نظر برسد و خوانندگان به اشتباه نروند.

برای شروع یک رشته ی جدید [از پرسش و پاسخ] صرفا دکمه ی reply ی لیستی از پیام ها را نزنید. این کار مخاطبان شما را کاهش می دهد. برخی از mail reader ها مثل mutt، به کاربر اجازه میدهند که مطالب خود را با توجه به رشته ها دسته بندی کنند و با به اصطلاح تا کردن آن رشته (folding the thread) پیام های آن را پنهان می کنند. کسانی که این کار را می کنند هرگز پیام های شما را نخواهند دید.

عوض کردن موضوع مفید است ولی کافی نیست. Mutt و احتمالا بقیه ی mail reader ها برای انتساب ایمیل شما به یک رشته به اطلاعات دیگری هم در header ایمیل ها نگاه می کنند و فقط به خط موضوع آن توجه خود را معطوف نمی کنند.

در Web forum ها، قواعد تمرین خوب (good practice) کمی متفاوت است، زیرا پیام ها معمولا خیلی تنگاتنگ با رشته مباحث پیوند دارند و عموما خارج از آن رشته ها اصلا دیده نمی شوند. تعویض موضوع هنگام پرسیدن سوال در بخش پاسخ ها (reply)، ضروری نیست و همه ی forum ها هم اجازه ی جداسازی خط موضوع سوالات را در بخش پاسخ ها نمی دهد. کسی هم آنها را نمی خواند. اگرچه پرسیدن سوال در بخش پاسخ، به خودی خود کاری شک برانگیز است، زیرا چون در این صورت سوال شما فقط توسط کسانی که آن رشته را دنبال می کنند خوانده می شود. پس اگر مطمئن نیستید که می خواهید سوالتان را فقط برای دنبال کنندگان آن رشته مطرح کنید، به سراغ رشته ی جدیدی بروید.

پاسخ دادن را آسان کنید

به انتها رساند یک شبهه (query) با جمله ی «لطفا پاسخ های خود را به این آدرس…» باعث می شود تا احتمال دریافت پاسخ کاهش پیدا کند. اگر حاضر نیستید حتی چند ثانیه برای نوشتن یک Reply-To header درست و حسابی در mail agent خود زمان بگذارید، از ما هم توقع نداشته باشید که چند ثانیه برای پاسخ دادن به شما زمان بگذاریم. اگر برنامه ی ایمیل شما چنین دسترسی ای نمی دهد، یک ایمیل بهتر بگیرید. اگر سیستم عامل شما هیچ ایمیلی را پشتیبانی نمی کند، یک سیستم عامل بهتر بگیرید.

در Web forum ها، درخواست یک پاسخ از طریق ایمیل اصلا کار جالبی نیست، مگر آنکه شما باور داشته باشید که پاسخ محتوی اطلاعات مهم و حساسی باشد. وقتی جوابی در یک رشته دریافت می کنید اگر به یک کپی ایمیل شده از آن احتیاج دارید، از Web forum بخواهید که آن را ارسال کند. این ویژگی تقریبا در هر وب سایتی، زیر گزینه هایی مثل “watch this thread”، “send email on answers” و… وجود دارد.

واضح و بدون غلط املایی/گرامری بنویسید

به تجربه فهمیده ایم کسانی که به دقت و شلخته می نویسند معمولا در کد زدن هم بی دقت و شلخته اند و پاسخ دهی به سوالات کسانی که بی دقت و شلخته اند سودی ندارد. ما ترجیح میدهیم وقت خود را جای دیگری صرف کنیم.

پس واضح بیان کردن سوال اهمیت دارد. اشتباه نکنید. منظورمان رسمی و اتو کشیده حرف زدن نبود. در واقع در فرهنگ هکر ها، صحبت کردن به صورت غیر رسمی، آمیخته با شوخی و صریح است. صریح و دقیق بودن اهمیت دارد. باید نشانه ای از تفکر و توجه در حرف های شما باشد.

املا، نشانه گذاری و حروف بزرگ و کوچک انگلیسی را رعایت کنید.

اگر از یک forum با زبانی غیر از زبانی مادری خود استفاده می کنید، کمی به شما درباره ی شیوه ی نوشتار آسان گرفته خواهد شد ولی نه تا آن حد که هیچ تلاشی برای درست نوشتن نکنید (ما تفاوت این دو را تشخیص می دهیم). همیشه به انگلیسی بنویسید مگر این که از قبل زبان کسانی که قرار است به شما پاسخ بدهند را بدانید. هکر هایی که سرشان شلوغ است سوالات غیر انگلیسی را دور می ریزند.

اگر به انگلیسی تعامل می کنید ولی انگلیسی زبان دوم شماست، بهتر است مخاطب خود را از این مسئله آگاه کنید:

• انگلیسی زبان مادری من نیست. اشتباهات متنی را عفو کنید.

• اگر شما می توانید به زبان من صحبت کنید، لطفا در یک ایمیل یا پیام خصوصی مرا در ترجمه ی سوال کمک کنید.

• من با اصطلاحات تخصصی آشنا هستم ولی در بکار بستن عبارات عامیانه مشکل دارم.

• من سوال خود را به دو زبان فارسی و انگلیسی پست کرده ام. خوشحال میشوم اگر به یکی از این دو زبان پاسخ دهید.

سوالات خود را با فرم استاندارد بنویسید

اگر سوال خود را تصنعی و ناخوانا بنویسید، احتمال آن میرود که به آن توجهی نشود تا به سوالی بهتر پاسخ داده شود. پس:

• یک ایمیل به فرمت متن ساده (plain text) بنویسید، نه به فرمت HTML (خاموش کردن HTML سخت نیست).

• فایل های ملتصق شده به صورت MIME attachments به طور معمول مشکلی ندارند. اما اگر مشتمل بر مطالب مفید و واقعی باشند: مثل فایل های سورس یا پچ (source file or patch).

• ایمیل خود را بدون جمله بندی های کوتاه و پاراگراف بندی صحیح ارسال نکنید (جملات طولانی و متن های بلند و بدون پاراگراف بندی کار جواب دادن به سوال شما را سخت می کند). در نظر بگیرید که کسی که جواب سوال شما را می دهد با یک ایمیل ۸۰ کاراکتری مواجه می شود. چینش و تعداد خطوط جملات را طبق آن تنظیم کنید و سعی کنید از ۸۰ کمتر شود.

• تغییری در دیتا ها و فایل ها ایجاد نکنید. آنها باید دقیقا همانطور که هستند ارائه شوند.

• به forum های انگلیسی، MIME Quoted-Printable encoding را نفرستید. این encoding می تواند ضروری باشد وقتی که پست خود را به زبانی که ASCII پشتیبانی نمیکند ثبت می کنید. اما بسیاری از ایجنت های ایمیل آن را پشتیبانی نمی کنند. وقتی که متن توسط آن ها خوانده می شوند، تمام ۲۰ گلیچ موجود در آن زشت و ناخوانا می شوند. یا حتی امکان دارد منطق نوشتار شما را از بین ببرند.

• هرگز از هکر ها توقع نداشته باشید تا فایل هایی با فرمت closed proprietary مثل Microsoft Word یا Excel را بخوانند. بیشتر هکر ها نسبت به این فایل ها همان رفتاری را دارند که شما با تپه ای از مدفوع خوک که جلوی در خانه ی شما ریخته شده است دارید.

• اگر کاربر Windows هستید، ویژگی Smart Quotes را غیر فعال کنید (به Tools بروید > AutoCorrect Options > چک باکسی که زیر AutoFormat قرار دارد را خالی کنید). این کار برای از بین بردن کاراکتر های آشغال در ایمیل شماست.

• در Web forums، از ایموجی به صورت افراطی استفاده نکنید. یک یا دو ایموجی مسئله ای ندارد ولی این ایموجی ها و رنگ آمیزی کردن متن باعث می شود آدم مزخرفی به نظر برسید.

اگر از یک رابط کاربری گرافیکی ایمیل مثل Netscape Messenger، Outlook و… استفاده می کنید، آگاه باشید که ممکن است این رابط ها ممکن است با توجه تنظیمات پیش فرض خود این قواعد را زیر پا بگذارند. چنین کلاینت هایی اکثرا در منوی خود گزینه ی “View Source” دارند. با استفاده از تنظیمات آن، ارسال متون را به حالت plain text تغییر دهید.

مشکل خود را دقیق و با اطلاعات کافی بنویسید

• علائم و نشانه های مشکل یا bug خود را واضح و با دقت توصیف کنید.

• محیطی که این مشکل در آن اتفاق افتاده است (دستگاه، سیستم عامل،…).

• بررسی های خود برای درک کردن چگونگی و چرایی وقوع مشکل را بنویسید.

• توضیح دهید که قبل از پرسیدن سوال چه قدم هایی در راستای تشخیص مشکل برداشته اید.

• هر تغییر مرتبطی را که اخیرا در configuration کامپیوتر یا نرم افزار خود ایجاد کرده اید بنویسید.

• اگر امکان دارد، راهی برای وقوع دوباره ی این مشکل در یک محیط کنترل شده ایجاد کنید.

تمام تلاش خود را برای پیشبینی سوالاتی که هکر ممکن است بپرسد انجام دهید و آن سوالات را زود تر و در همین پست یا ایمیلی که میزنید، پاسخ دهید.

دادن این قابلیت به هکر ها که بتوانند مشکل را در یک محیط کنترل شده مشاهده کنند به طور خاص اهمیت خواهد داشت، اگر مشکلی که گزارش داده اید یک باگ در کد های شما باشد. وقتی که این کار را انجام دهید، احتمال اینکه پاسخی بدرد بخور و در کمترین زمان بگیرید به شدت افزایش خواهد یافت.

آقای Simon Tatham مقاله ی بسیار ارزشمندی تحت عنوان «چگونه باگ ها را به بهترین شکل گزارش کنیم» نوشته اند. به شدت به شما توصیه می کنیم آن را بخوانید.

حجم، نشانه ی دقت نیست

پیش تر گفتیم که باید دقیق و با اطلاعات کافی مشکل خود را گزارش کنید.

این به معنای ریختن حجم زیادی از کد ها و دیتا ها در گزارش شما نیست. اگر یک test case بزرگ و پیچیده دارید، سعی کنید که آن را تا حد امکان تکه تکه و کوچک کنید.

این کار حداقل به سه دلیل مفید است.

یک: سعی شما در ساده سازی سوال باعث افزایش احتمال دریافت پاسخ خواهد شد.

دو: سوال ساده سازی شده شانس بیشتری برای دریافت یک پاسخ واقعا بدرد بخور دارد.

سه: در طی این فرایند، ممکن است خود شما به جواب برسید.

برای این که ادعا کنید یک باگ پیدا کرده اید، عجله نکنید

وقتی که با یک نرم افزار به مشکل برخورده اید، ادعا نکنید که باگی پیدا کرده اید. مگر اینکه خیلی خیلی مطمئن باشید. اگر نمی توانید یک source-code patch که مشکل را حل میکند یا یک تست بازگشتی روی یک ورژن قدیمی که خرابی آن را نشان می دهد ارائه کنید، این یعنی شما به اندازه ی کافی روی این موضوع مطمئن نیستید.

به یاد داشته باشید، کاربران بسیاری با مشکلی که شما دارید مواجه نشده اند وگرنه وقتی که مشغول بررسی اسناد و جستجو در اینترنت بودید با آن مواجه می شدید. و این یعنی که به احتمال خیلی زیاد، این شما هستید که یک جای کار را اشتباه رفته اید، نه نرم افزار.

کسانی که نرم افزار را نوشته اند سخت تلاش می کنند که نرم افزار به خوبی کار کند. اگر ادعا دارید که یک باگ پیدا کرده اید، این یعنی شما تمام تلاش هایشان را زیر سوال می برید که برای بعضی از آنها ممکن است توهین تلقی شود. فریاد کردن کلمه ی باگ در خط موضوع گزارش هم یک حرکت غیر دیپلماتیک تلقی میشود.

کوچک کردن خودتان جایگزینی برای انجام دادن تکالیفتان نیست

بعضی افراد که متوجه شده اند نباید بی ادب یا مغرور باشند و خواستار یک جواب هستند، عقب نشینی کرده و به تفریط روی می آورند. یعنی خودشان را حقیر می کنند: «میدونم که من فقط یه آماتور نفرت انگیز بازنده هستم. اما…» این کار هیچ کمکی به آنها نمی کند و مخصوصا وقتی با واضح نبودن مشکل مطرح شده آمیخته شود آزار دهنده خواهد بود.

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

علائم و نشانه های مشکل خود را توضیح دهید، نه حدس هایتان

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

احمقانه:

من پشت سرهم ارور های SIG11 روی کامپایل هسته ی لینوکس (kernel) دریافت می کنم و

و به یک hairline crack روی motherboard مظنونم. بهترین راه برای چک کردن آنها چیست؟

هوشمندانه:

نسخه ی home-built K6/233 من روی یک FIC-PA2007 motherboard با چیپ ست Apollo VP2 و 256MB Corsair PC133 SDRAM، به صورت متوالی ارور های SIG11 حدود ۲۰ دقیقه بعد از روشن کردن دستگاه رخ میدهد، اما هرگز در ۲۰ دقیقه ی ابتدایی شاهد آن نیستیم. ریبوت کردن باعث ری استارت شدن ساعت نمی شود. اما خاموش کردن دستگاه در شب کارساز است. تعویض تمام ظرفیت RAM کمکی نکرد.

علائم مشکل خود را به ترتیب وقوع آن توضیح دهید

سرنخ های بدرد بخور برای فهمیدن اینکه کجای کار اشتباه است معمولا در وقایعی که در همان ابتدای کار رخ داده اند، قرار دارند. پس گزارش شما باید دقیقا کار هایی که شما کرده اید و دستگاه و نرم افزار شما انجام داده اند را تا لحظه ی بوجود آمدن مشکل توصیف کند. در مواردی که مشکل ما در پروسه های دستور-خط (command-line) بوجود آمده است، داشتن یک session log (با استفاده از ابزار script) و ذکر کردن حدود ۲۰ خط از آن در گزارش مان خیلی مفید است.

اگر برنامه ای که به مشکل خورده است آپشن هایی برای تشخیص مشکل داشته باشد (مثل -v برای verbose)، سعی کنید آپشن هایی که اطلاعات بدرد بخوری را جهت رفع باگ به transcript اضافه می کند انتخاب کنید. به یاد داشته باشید که قرار دادن اطلاعات بیشتر لزوما بهتر نیست. سعی کنید که خواننده را در جریان اصل مطلب قرار دهید، جای آنکه او را در دریایی از چرندیات بدرد نخور غرق کنید.

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

هدف را توضیح دهید، نه مراحل را

اگر سعی می کنید بفهمید که چطور کاری را انجام دهید (کاری مخالف گزارش کردن باگ)، با توضیح دادن هدف خود شروع کنید. آنگاه تنها گام هایی را که در برداشتن آنها در راستای هدف مشکل دارید توصیف کنید.

اغلب، کسانی که نیاز به کمک فنی دارند یک هدف بسیار متعالی را در ذهن دارند و در جایی به بن بست می خورند که فکر می کنند یک راه خاص برای رسیدن به هدف شان است. آنها برای پیمودن راه مسیر خود کمک می خواهند در حالی که نمی دانند اصلا مسیر اشتباه است. عبور از این مشکل تلاشی قابل توجه را می طلبد.

احمقانه:

چگونه گزینشگر رنگ را در برنامه ی FooDraw وادار به گرفتن مقادیر hexadecimal RGB کنم؟

هوشمندانه:

من سعی در جایگزینی جدول رنگ در یک تصویر با مقادیر منتخب خودم دارم. تنها راهی که برای این

کار به ذهنم میرسد، ویرایش کردن هر سطر جدول است. اما نمی توانم گزینشگر رنگ در FooDraw

را وادار به گرفتن مقادیر hexadecimal RGB کنم.

سوال دوم هوشمندانه است. زیرا به پاسخ دهنده ی آن اجازه ی معرفی ابزاری بهتر برای این کار را می دهد.

از ما نخواهید که با یک ایمیل خصوصی به شما پاسخ دهیم

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

وقتی که درخواست یک جواب خصوصی می کنید، هم جلوی انجام پروسه و هم دریافت مزد را گرفته اید. انتخاب این که هکر به شما عمومی جواب دهد یا خصوصی به عهده ی خودش است.

فقط یک استثنا برای این حالت وجود دارد. اگر فکر می کنید که سوال شما به نحویست که جواب های بسیار مشابه و متعددی را دریافت خواهد کرد، این عبارات کلیدی را ذکر کنید: «به من ایمیل بزنید تا من پاسخ را برای گروه خلاصه کنم» این یک روش مودبانه است برای خلاص کردن mailing list یا newsgroup از سیل پست هایی که اساسا یکسان هستند. اما شما باید به وعده ی خود برای خلاصه کردن وفادار باشید.

سوال خود را با صراحت بپرسید

سوال هایی که پایان باز دارند همان سوالات وقت تلف کن هستند. افرادی که قادرند به شما پاسخ دهند، معمولا بسیار سرشان شلوغ است. این دسته از افراد نسبت به سوالاتی با پایان باز حساس هستند.

اگر درباره ی کاری که می خواهید فرد پاسخگو برای شما انجام دهد صریح باشید (اشاره گر بگذارید، کد بفرستید، پچ خود را بررسی کنید، …) با احتمال بیشتری یک پاسخ بدرد بخور خواهید گرفت. این کار باعث متمرکز شدن تلاش آنها در پاسخگویی می شود و صراحت شما در پاسخگویی باعث افزایش مقدار انرژی و زمانی که فرد پاسخگو برای پاسخ دادن به شما می گذارد می شود.

برای فهم دنیایی که هکر ها در آن هستند، تخصص را به عنوان یک منبع وافر و زمان را به عنوان چیزی نادر در نظر بگیرید. هر مقدار سوال شما به تعهد زمانی کمتری برای پاسخگویی نیاز داشته باشد، احتمال دریافت پاسخ بدرد بخور از شخصی متخصص که زمان کمی در اختیار دارد بیشتر می شود.

پس کاهش زمان مورد نیاز برای پاسخگویی به سوال شما مفید است. اما این مسئله با ساده سازی سوال یکی نیست. برای مثال «میشه اشاره ای به یک توضیح خوب برای مسئله ی X داشته باشید؟» سوال هوشمندانه تری نسبت به سوال «میشه X رو توضیح بدید؟» هستش. اگر شما یک کد خراب داشته باشید، بهتر است بپرسید که مشکل آن چیست، نه اینکه لطفا آن را درست کنید.

وقتی درباره ی کد می پرسید

از دیگران نخواهید که کد معیوب شما را بدون داشتن ایده ای درباره ی مشکلی که با آن سروکار دارید رفع عیب کنند. اگر صرفا صد ها خط کد را روی هم تلنبار کنید و در آخر زیر آن بنویسید «کار نمی کند»، هیچ کس به شما جواب نخواهد داد. پست کردن یک دوجین خط کد و گفتن این که «بعد از خط هفت توقع داشتم که را ببینم ولی ظاهر شد.» احتمال بیشتری برای دریافت جواب دارد.

موثر ترین راه برای دقیق توضیح دادن یک مشکل در کد، تهیه ی یک test case که باگ را به صورت حداقلی (مینیمال) به ما نشان می دهد است.

یک test case مینیمال چیست؟ نمایشی از مشکل است و به اندازه ای کد دارد که رفتار نامطلوب آن را مشاهده کنیم، نه بیشتر.

چگونه یک test case مینیمال درست کنیم؟ اگر می دانید کدام خط یا بخش از کد رفتاری نامطلوب دارد، همان قسمت را کپی کنید و به مقدار کافی کد های لازم به آن اضافه کنید تا یک مثال کامل (منبعی کامل برای پردازش کامپایلر) از آن را بدست بیاورید. اگر نمی توانید مشکل را به یک قسمت خاص معطوف و محدود کنید، یک کپی از منبع ایجاد کرده و شروع به حذف بخش هایی که باعث ایجاد رفتار نامطلوب و مشکل ساز نمی شوند کنید. هر چه تست مینیمال شما کوچک تر باشد بهتر است (بخش «حجم نشانه ی دقت نیست» را ببینید).

ایجاد یک test case خیلی کوچک و مینیمال همیشه ممکن نخواهد بود، اما سعی کردن برای ایجاد آن مفید است. ممکن است به شما در حل مشکلتان آن هم بدون کمک کسی و فقط با اتکا به خودتان کمک کند و حتی اگر این اتفاق نیفتد هکر ها دوست دارند ببینند که شما در جهت رفع مشکل خود تلاش کرده اید و باعث می شود تا آنها بیشتر همکاری کنند.

سوالاتی که مشق و تکلیف شما هستند را پست نکنید

هکر ها میتوانند سوالاتی که پاسخ دادن به آنها تکلیف خودتان است را تشخیص دهند. پیدا کردن پاسخ آن سوال ها بر عهده ی شماست تا شما بر حسب تجربه آنها را بیاموزید.

اگر شما متوجه شده اید سوالی از این دست وجود دارد که تحت هیچ شرایطی نمی توانید حل کنید، آن را در گروه کاربران یک forum مطرح کنید. علاوه بر اینکه هکر ها آن را می بینند، ممکن است برخی از کاربران رده بالا هم یک راهنمایی مختصر به شما بدهند.

پرس و جو های بی هدف را دور بریزید

هرگز سوالاتی مثل «میشه یه نفر بهم کمک کنه؟» را نپرسید. اول از همه اینکه اگر سوالی این چنین ناقص را بپرسید، چنین سوالاتی در بهترین حالت زائد هستند. و دوم اینکه چون زائد هستند، هکر ها این دست سوالات را اذیت کننده می دانند و احتمال دارد با جواب هایی تحقیر آمیز مثل «بله میشه» یا «نه نمیشه» پاسخ شما را خواهند داد.

به صورت کلی باید از پرسیدن سوالات بله/خیر اجتناب کرد مگر اینکه یک جواب بله/خیر بخواهید.

سوال خود را با تگ #فوری نشانه گذاری نکنید، حتی اگر واقعا باشد

این مشکل شماست، نه ما. ادعای ضروری یا فوری بودن در چنین مواردی بسیار غیر سودمند است. بیشتر هکر ها به سادگی چنین پیام هایی را پاک میکنند چون به نظر آنها چنین ادعایی به جهت جلب توجه، خودخواهانه و بی ادبانه است. به علاوه، کلمه ی فوری مورد هدف فیلتر های اسپم می باشد. بنابراین ممکن است مخاطب خاص شما هرگز پیامتان را نبیند.

یک استثنا وجود دارد. اگر برنامه ای خاص و مهم را استفاده میکنید که برای هکر ها جذاب باشد، اشاره کردن آن خالی از لطف نخواهد بود. در چنین مواردی اگر تحت فشار زمان باشید و مشکل خود را مودبانه مطرح کنید ممکن است توجه افراد را به اندازه ای جلب کنید که سریع تر پاسخ دهند.

این کار ریسک بالایی دارد زیرا چیزی که هکر ها را به وجد می آورد ممکن است با چیز هایی که شما را به وجد می آورد متفاوت باشد. برای مثال پست کردن «فوری: کمکم کنید تا شیر های دریایی پشمالو را نجات بدم!» قطعا توسط هکر هایی که فکر میکنند شیر های دریایی پشمالو مهم هستند مورد عنایت قرار خواهد گرفت.

تواضع ایرادی ندارد و گاهی کمک می کند

متواضع باشید. از «لطفا» و «از توجهتون ممنونم» استفاده کنید. توجه خود را به وقتی که بدون چشم داشت برای شما صرف شده نشان دهید. در حقیقت، تواضع به اندازه ی رعایت دستور زبان، وضوح نوشتار و هدف آن مهم نیست. هکر ها به صورت کلی فنی، دقیق و سرد و بی ادبانه حرف زدن را به پست های مودبانه، مبهم و غیر فنی ترجیح میدهند (یادتان باشد معیار اصلی برای ارزشمند بودن یک سوال، چیزهاییست که آن سوال به ما می آموزد).

اگرچه، در صورتی که مبانی فنی را رعایت کرده اید، مودب بودن شانس شما را برای دریافت یک پاسخ بدرد بخور بیشتر می کند.

بعد از دریافت پاسخ یک یادداشت مختصر بفرستید

یادداشتی برای تشکر از شخصی/اشخاصی که به شما کمک کرد/کردند بفرستید. نتیجه ی کار را به آنها اطلاع دهید و مجددا بابت کمکی که دریافت کردید تشکر کنید.

در یک حالت ایده آل، یادداشت باید به رشته ای که سوال اصلی در آن پرسیده شده فرستاده شود و با تگ هایی مثل «حل شد»، «برطرف شد» و… همراه باشد. وقتی یک نفر در انتهای رشته این تگ ها را می بیند، دیگر وقت خود را روی آن سوال تلف نمیکند.

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

برای مسائل عمیق و پیچیده، پست کردن خلاصه ای از راه حل مناسب است. وضعیت نهایی مشکل را در آخر بیان کنید. بخش هایی از راه حل که مناسب و بخش هایی که بن بست بودند را بنویسید. بن بست ها را بعد از ذکر کردن راه حل صحیح بنویسید. یادتان باشد که قرار نیست یک داستان کاراگاهی بنویسید [یعنی اول راه درست را مثل آدم بنویسید و بعد بگویید کجا ها به بن بست خوردید]. اسم کسانی که به شما کمک کردند را هم بنویسید. با این کار دوستان جدیدی پیدا می کنید.

و در آخر، اینگونه یادداشت ها به هکر ها این حس را می دهد که کار خود را خوب انجام داده اند و مسئله حل شده است. اگر خودتان یک هکر یا تکنسین نباشید این را نمی فهمید ولی بدانید که این احساس برای ما بسیار با ارزش است. القای این احساس میان هکر ها به شما در حل سوالات بعدی توسط آنها بسیار کمک می کند.

در نظر بگیرید که چگونه می توانید از بوجود آمدن مشکل مشابهی مانند مشکل خودتان جلوگیری کنید. از خودتان بپرسید که آیا یک مطلب مستند یا FAQ patch کمکی میکند. اگر پاسخ بله بود، patch را برای مدیر (maintainer) بفرستید.

چگونه پاسخ ها را تفسیر کنید

چگونه اذعان کنید که گند زده اید

یک سنت باستانی و مقدس وجود دارد: اگر کسی به در پاسخ به شما نوشت «ر.ل.ر.ب»، این یعنی برو و «راهنمای لعنتی رو بخون» (“RTFM” = Read The Fucking Manual).

این نشان می دهد که شما ساده ترین و ابتدایی ترین چیزی که باید خوانده باشید را نخوانده اید و آن Manual است.

«ر.ل.ر.ب» یک فامیل دیگر هم در اقوام خود دارد. اگر کسی در پاسخ به شما گفت «ا.ل.ر.ب»، این یعنی «اینترنت لعنتی رو بگرد» (“STFW” = Search The Fucking Web).

در Web forums ها، ممکن است به شما گفته شود که آرشیو های forum را بخوانید. در واقع بعضی ها ممکن است آنقدر مهربان باشند که شما را به مباحث گذشته ی forum ارجاع دهند. ولی با این وجود، حتما آرشیو های forum را قبل از پرسیدن جستجو کنید.

معمولا کسی که به شما می گوید «ا.ل.ر.ب» یا «ر.ل.ر.ب»، خودش آن راهنما یا صفحه ای که در آن اطلاعات مرتبط به سوال شما وجود دارد را در اختیار دارد و در حین تایپ کردن جواب دارد به آنها نگاه میکند! آن شخص در آن لحظه به دو چیز فکر میکند:

۱- حماقت شما: اطلاعاتی که به آن نیاز دارید به راحتی پیدا می شوند.

۲- گشادی شما: اگر به دنبال این اطلاعات بگردید برایتان بسیار سودمند تر و آموزنده تر است تا اینکه من با قاشق آن را در حلق تان فرو کنم.

نباید به شما بربخورد (ناراحت شوید). با توجه به استاندارد هکر ها، کسی که به شما اینگونه جواب میدهد در واقع با نادیده نگرفتن و پاسخ دادن به شما نوعی از احترام خشونت آمیز را در حقتان به جا آورده است. باید قدردان این محبت مادربزرگ گونه باشید.

اگر نمی فهمید…

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

برای مثال فرض کنید که به شما گفته می شود: «به نظر میرسه که یه zentry داری که stuck شده (باید clear بشه)». سوال بدی که می توانید بپرسید: «zentry چیه؟». و اما سوال خوب: «اوکی. من صفحه ی manual رو خوندم و به zentry ها فقط زیر -z اشاره شده. هیچ کدوم توضیحی درباره ی clear کردن zentry نمیدن. جای درستی رو دنبالش گشتم یا اینکه چیزی رو جا انداختم؟».

مواجهه با بی ادبی

چیزی که در زمره ی هکر ها بی ادبی به نظر می آید عموما با چنین منظوری نوشته یا گفته نشده است.

این اتفاق محصول مکالمه ی مستقیم، بدون طفره رفتن، بدون ادا در آوردن و صریح و واضح صحبت کردن آن افرادی است که بیشتر متمرکز روی حل مشکل هستند تا ایجاد احساس امنیت عاطفی در شما.

وقتی پاسخی بی ادبانه دریافت می کنید، سعی کنید آرام باشید. اگر کسی واقعا در حال بی ادبی یا فحاشی باشد، به احتمال زیاد یکی از اعضای بلند پایه ی گروه (senior) به این مسئله رسیدگی خواهد کرد. اما اگر آن فرد مطابق قواعد معاشرت هکر ها با شما صحبت کرده باشد ولی شما کنترل خود را از دست بدهید، باید منتظر عواقب آن که شامل نادیده گرفته شدن شما و سوالاتتان توسط تمام اعضای گروه است، باشید.

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

مشاهدات Jeff Bigler درباره ی فیلتر های خردمندی در این باره ارزش مطالعه را دارند.

چند خط درباره ی «مثل یک بازنده واکنش نشان ندادن»

احتمال دارد که به دفعات در یک اجتماع forum هکر ها گند بالا بیاورید (به شیوه هایی که در این مقاله گفته شد) و به شما گفته خواهد شد که گند زدید، آن هم در جمع. وقتی این اتفاق رخ میدهد، بدترین کار ممکن آه و ناله کردن است. به جای این کار، با آن کنار بیایید. این یک اتفاق طبیعی و حتی مفید و مناسب است.

استاندارد های جامعه خودشان از خودشان مراقبت نمی کنند. این حراست توسط افرادی که فعالانه و جلوی چشم همه در عموم آنها را اعمال میکنند صورت می گیرد. توقع نداشته باشید که انتقادات و حرف های تند فقط از طریق ایمیل های خصوصی فرستاده شوند.

تعدادی forum هکری وجود دارد که در آنها بخاطر سیاست های اشتباه و شدید برای رعایت ادب، اعضای forum حق تصحیح کردن نظرات و پست های یکدیگر را ندارند. این گونه سیاست ها باعث شده تا این forum ها از لحاظ کیفی تبدیل به اجتماعاتی که از لحاظ فنی بدرد نخور و بی معنی هستند، بشوند.

به طرزی اغراق آمیز «دوستانه» یا به طرزی رضایت بخش «بدرد بخور»؟ انتخاب با شماست…

سخن مترجم:

در پایان مقاله تعدادی پرسش و پاسخ نوشته شده که برای سوال پرسیدن در forum های انگلیسی اهمیت دارند ولی برای آشنایی شما با قالب های گرامری در گفتار و نوشتار انگلیسی ترجمه نشده اند زیرا ترجمه ی آنها ارزشی ندارد. شما باید با نحوه ی تعامل به زبان انگلیسی در forum های انگلیسی زبان آشنا شوید و ترجمه ی این مقاله صرفا به هدف ارتقای فهم شما از چگونگی پرسش ها و مفاهیم مورد نیاز برای این کار است.

۴ بخش پایانی متن را (Questions Not To Ask، Good and Bad Questions، If You Can’t Get An Answer، How To Answer Questions in a Helpful Way) حتما مطالعه فرمایید:

How To Ask Questions The Smart Way

از توجهتون ممنونم!

امیرحسین پیمانفرد

ارتباط با من