ادامه مقاله :
تحقیر کردن جایگزینی برای انجام تکلیف نیست:
بعضی از افراد که می‌دانند نباید گستاخانه یا مغرورانه رفتار کنند، در نقطه مقابل تحقیر کردن، تقاضای جواب می‌کنند. جملاتی مثل «می‌دانم که یک کاربر جدید بازنده هستم ولی...» از این قبیل‌اند. این کار منحرف کننده است و کمکی هم نمی‌کند به خصوص این کار وقتی توام با ابهام در مورد مشکل واقعی باشد، آزار دهنده است.
وقت خود و ما را با سیاست‌های خام و پیش پا افتاده هدر ندهید. در عوض، زمینه‌های واقعی مشکل خود را به وضوح شرح دهید. این کار بهتری نسبت به تحقیر کردن است.
برخی از Forum ها محل جداگانه‌ای برای سوالهای کاربران جدید دارند. اگر فکر می‌کنید که سوال پیش پا افتاده‌ای دارید، به آنجا بروید. اما در آنجا نیز نباید تحقیر کرد.
به جای حدس‌های خود نشانه‌های مشکل را شرح دهید:
نوشتن در مورد اینکه خودتان علت مشکل پیش آمده را چه می‌دانید، مفید نیست (اگر فرضیات شما بکلی اشتباه باشد آیا با دیگران مشورت می‌کنید؟)
لذا سعی کنید که به دوستداران کامپیوتر از علائم و نشانه‌های اولیه مشکل موجود بگویید و نه از فرضیات و تئوری‌های خود. بگذارید
آنها خود تفسیر کنند و مشکل را تشخیص دهند اگر احساس می‌کنید که ذکر کردن حدس خودتان می‌تواند مهم باشد، آنرا روشن و تحت عنوان حدس خودتان بیان کنید و همچنین ذکر کنیدن که چرا این پاسخ نمی‌تواند جوابگوی مسئله باشد.
سوال احمقانه:
من دائماً پیغام خطای SIG11 را در هسته کمپایل دریافت می‌کنم و به یک شکاف بسیار نازک در بورد اصلی (Mothor Boord) مشکوک هستم. بهترین راه برای اطمینان از این وضعیت چیست؟
سؤال هوشمندانه:
کامپیوتر خانگی من که K 6233 بر روی بورد اصلی FIC-PA 2007 (VIA Apollo VP2 Chipcedt) با 256 مگابایت رم از نوع Car Sair PC133 SDRAM می‌باشد، 20 دقیقه بعد از روشن شدن دائماً پیغام خطای SIG11 را نشان می‌دهد. اما قبل از 20 دقیقه هرگز این اتفاق نمی‌افتد. با Restart کردن سیستم، ساعت Restart نمی‌شود ولی با خاموش کردن در شب Restart می‌شود. با خارج کردن رم‌ها هم این مشکل حل نمی‌شود. قسمت مربوطه از فهرست کامپایل به شرح ذیل است.
چون رسیدن به این نقطه برای بسیاری از افراغد مشکل به نظر می‌رسد، یک جمله را به شما یادآوری می‌کنیم: «همه تشخیص دهندگان از ایالت میسوری هستند!» که شعار اداری این ایالت «به من نشان بده» است. (در سال 1899 یکی از افراد کنگره آمریکا گفت من از کشوری می‌آید که در آنجا ذرت و کتان و دموکرات و فصاحت بیان بی‌معنی کشت می‌کنند که نه مرا متقاعد می‌کند و نه راضی. من از ایالت میسوری هستم. شما باید به من نشان بدهید) در مورد تشخیص دادن، شک کردن مهم نیست اما نیاز واقعی و کاربردی به دانستن این است که چه چیزی به نشانه‌هایی که شما دیده‌اید نزدیک‌تر است و نه فرضیات و حدس‌های شما. به ما نشان بدهید!
نشانه‌های مشکل خود را به ترتیب زمان وقوع شرح دهید:
نشانه‌های مفید برای تشخیص اینکه چه مشکلی پیش آمده است، اغلب در اتفاقاتی که قبلاً افتاده‌اند وجود دارند. لذا نامه شما باید به دقت شرح دهید که شما چه کاری انجام داده‌اید و سیستم و کامپیوتر شما چه عکس‌العملی داشتند تا اینکه سیستم blow up کرده است.
در مورد فرآیندهای Command-Line ، داشتن یک Session log و نقل قول مربوط در حدود بیست خط می‌تواند خیلی مفید باشد.
اگر برنامه شما که blow up کرده است، دارای گزینه تشخیص عیب باشد ( مانند حالت verbose ) سعی کنید از آن برای گرفتن اطلاعات بیشتر برای اشکال‌زدایی (debug) برنامه استفاده کنید.
به یاد داشته باشید که لزوماً هر چه بیشتر، بهتر نخواهد بود. سعی کنید سطحی از اشکال‌زدایی را انتخاب کنید که خواننده را مطلع نماید و نه اینکه آنرا در انبوهی از داده‌های بی‌ارزش گمراه کند.
اگر نوشته شما طولانی شد (بیش از 4 پاراگراف)، بهتر است به طور مختصر مشکل را در ابتدا مطرح کنید و سپس به شرح وقایع به ترتیب زمانی بپردازید. به این ترتیب خوانندگان خواهند دانست که در نوشته شما به دنبال چه چیزی باید بگردند.
هدف را مشخص کنید، نه مرحله:
اگر به دنبال این هستید که بدانید چطور باید کاری را انجام داد (مثل گزارش کردن یک اشکال یا bug )،با شرح دادن هدف خود شروع کنید. بعد از آن فقط برخی از مراحل خاص که برای رسیدن به آن طی کردید و موفق نشدید را شرح دهید.
اغلب، افرادی که به کمک تکتیکی نیاز دارند، هدف بلند مرتبه‌ای را در ذهن می‌پرورانند و در راهی که فکر می‌کنند تنها راه رسیدن به هدف است گمراه می‌شوند. آنها برای کمک گرفتن مرحله به مرحله می‌آیند اما نمی‌دانند که مسیر اشتباه است تلاش قابل توجهی برای گذر از این مرحله مورد نیاز است.
سوال احمقانه :
چگونه می‌توان در برنامه FooDraw مقادیر RGB رنگ را بر مبنای شانزده‌تایی انتخاب کرد؟
سوال هوشمندانه :
من تلاش می‌کنم که جدول رنگ‌ها را روی یک تصویر با مقادیر انتخابی خودم قرار دهم. در حال حاضر تنها راهی که به نظرم می‌رسد اینست که هر ردیف از جدول را اصلاح کنم اما نمی‌توانم در برنامه FooDraw رنگ‌ها را بر مبنای مقادیر RGB شانزده‌تایی انتخاب کنم.
سوال دوم هوشمندانه بود. جواب این سوال ابزار بهتری برای آن کار را پیشنهاد می‌دهد.
از دیگران نخواهید که جواب سوال را به صورت خصوصی ایمیل کنند:
کاربران اینترنت عقیده دارند که حل مشکلات باید یک فرآیند عمومی و روشن باشد که در طی آن اولین جواب به یک پاسخ می‌تواند و باید توسط دیگر کاربران که با اطلاعات بیشتری به آن توجه می‌کنند مورد تصحیح و تکمیل قرار بگیرد. همچنین، کسانی که کمک می‌کنند تا دیگران به جواب سوال خود برسند، بخشی از پاداش خود را به این صورت می‌گیرند که به عنوان یک فرد مسئول و جوابگو و صلاحیت‌دار و مطلع توسط دیگر کاربران دیده می‌شوند.
وقتی که شما درخواست جواب خصوصی می‌کنید، هم فرآیند پاسخگویی و هم این پاداش را دچار مشکل می‌کنید. این کار را نکنید. این انتخاب فرد پاسخگو است که به شما بطور خصوصی پاسخ دهد یا خیر و اگر او این کار را انجام دهد معمولاً به این دلیل است که فکر می‌کند سوال از لحاظ جذابیت برای دیگران و همچنین اطلاعات، برای دیگران بسیار ضعیف است.
تنها یک استثناء برای این قاعده وجود دارد. اگر فکر می‌کنید که سوال شما بگونه‌ای است که ممکن است جواب‌های بسیار زیاد و مشابه به یکدیگر دریافت کنید، از کلمات جادویی مانند «به من ایمیل بزنید و من خلاصه‌ای از پاسخ‌ها را به Group خواهم فرستاد» استفاده کنید. ممانعت از ورود تعداد بسیار زیاد نامه‌های مشابه یکدیگر به Group ' ها و یا Mailing hist ها کار مودبانه‌ای است اما باید به قول خود مبنی بر خلاصه کردن جواب‌ها عمل کنید.
سوال را صریح مطرح کنید:
برای سوالهایی که انتهای مشخصی ندارد، بازه زمانی محدودی برای پاسخگویی به آنها در نظر گرفته نمی‌شود. کسانی که می‌خواهند پاسخ‌های مفیدی به شما بدهند، مشغول‌ترین افراد هستند. (چون در اغلب کارها به تنهایی کار می‌کننند). این گونه افراد نسبت به سوالهایی با بازه زمانی نامحدود حساسیت دارند و تمایل چندانی به پاسخگویی به آنها ندارند.
شما هنگامی که یک پاسخ مفید دریافت می‌کنید که از پاسخگویی خود در مورد چیزی که می‌خواهید بطور صریح پرسیده باشید (از اشاره‌گر استفاده کند، که بفرستید، پیوست را بررسی کنید یا هر چیز دیگر). این کار تلاش پاسخگو را بر روی هدف شما متمرکز می‌کند و به طور ضمنی حدی از نظر زمانی برای پاسخگویی و صرف انرژی برای کمک به شما ایجاد می‌کند. این کار خوبی است.
برای درک دنیایی که متخصصین در آن زندگی می‌کنند، به مهارت به عنوان یک منبع و زمان فراوان برای پاسخگویی به یک مورد کمیاب فکر کنید. هر چه زمان کمتری را برای پاسخگویی به سوال خود به طور ضمنی در نظر بگیرید، احتمال اینکه جواب واقعاً مناسب از جانب یک فرد خبره و پرمشغله دریافت کنید، بیشتر می‌شود بنابراین بهتر است که برای سوال خود قالبی در نظر بگیرید که زمان مورد نیاز به پاسخگویی به آن را از جانب یک فرد خبره به حداقل برساند. اما این کار اغلب مشابه ساده‌سازی یک سوال نیست. به عنوان مثال، ممکن است برای شرح مناسبی از X یک راهنمایی بکنید؟ معمولا سوال هوشمندانه‌تری است نسبت به اینکه ممکن است لطفاً X را توضیح دهید!
اگر شما یک کد نادرست دارید، بهتر است در مورد اینکه چه اشکالی دارد بپرسید تا اینکه درخواست کنید کسی آنرا اصلاح کند.
==وقتی که در مورد کد می‌پرسید:==
بدون اینکه مشخص کنید که باید به دنبال چه نوع مشکل باید بود، از دیگران نخواهید تا کد برنامه‌ی شما را اشکال‌زدایی یا به اصلاح debug کنند. فرستادن چند صد خط برنامه و گفتن اینکه «این برنامه کار نمی‌کند!» باعث می‌شود که هیچ پاسخی دریافت نکنید با فرستادن ده دوازده خط از برنامه و گفتن اینکه بعد از خط هفتم انتظار داشتم یا اتفاق بیفتد ولی رخ داد! بیشتر احتمال دارد تا به پاسخ خود برسید.
تکالیف منزل را سوال نکنید:
کاربران کامپیوتر دریافتن سوالهای تکالیف منزل تبحر دارند. اغلب ما این کار را کرده‌ایم. این سوالها برای این است که شما روی آنها کار کنید تا تجربه کسب کنید. پرسیدن راهنمایی ایرادی ندارد اما نه کل روش حل.
اگر دیدید که روی یک سوال کار کرده‌اید اما نتوانستید آنرا حل کنید، از یک فروم یا گروپ بپرسید یا در نهایت به عنوان یک «کاربر» از لیست فروم یا پروژه کمک بگیرید با وجود اینکه کاربران دیگر متوجه آن می‌شوند، اما برخی از دیگر کاربران حرفه‌ای ممکن است حداقل یک راهنمایی به شما بکنند.
سوالهای بی معنی را حذف کنید:
از به پایان رساندن درخواست سوال خود با جملات بی‌مفهومی مانند کسی می‌تواند به من کمک کند؟ یا آیا جوابی وجود دارد؟ پرهیز کنید. اولاً، اگر شرح خود را تا نیمه نوشته بودید، این گونه سوالها زائد هستند. دوماً، به دلیل زائد بودن آنها کاربران آنها را آزاردهنده تلقی می‌کنند و احتمال دارد که جواب‌هایی بی عیب و نقص ولی بی اعتنا مانند بله، به شما می‌توان کمک کرد. یا خیر، هیچ کمکی نمی‌توان کرد به شما بدهند.
به طور کلی، از سوالهای آری یا خیر باید اجتناب شود مگر اینکه تنها جواب بله یا خیر برای شما کافی باشد.
سوال خود را با کلمه «فوری» نشانه‌دار نکنید، حتی اگر برای شما اینگونه باشد: این مشکل شماست، نه دیگران. اظهار ضرورت کردن نتیجه معکوس می‌دهد. بیشتر کاربران به راحتی اینگونه سوالها را که با خودخواهی و گستاخی درخواست توجه فوری و ویژه می‌کنند را حذف می‌کنند.
تنها یک شبه استثناء وجود دارد. اگر شما در یک محل با مرتبه بالا و با یک نرم‌افزار کار می‌کنید و از نظر زمانی تحت فشار هستید، گفتن مودبانه محدودیت زمانی خود می‌تواند موثر باشد تا دیگران را به پاسخ دادن به شما ترغیب کند.
البته این کار ریسک بالایی دارد، چون معیار جالب بودن مسائل از نظر کاربران دیگر با شما متفاوت است. به عنوان مثال فرستادن نامه از یک ایستگاه فضایی بین‌المللی قانع کننده است اما از جانب یک انسان با احساس خوب و مهربان یا یک سیاستمدار خیر. در واقع، نوشتن کلمة «فوری» باعث می‌شود که از سوال شما اجتناب و دوری شود حتی اگر از نظر آنها مهم باشد.
اگر فکر می‌کنید که این امری مبهم است،دوباره این مطالب را بخوانید تا کاملاً آنرا درک کنید، قبل از آنکه نوشته‌ای را به جایی بفرستید.
ادب ضرری ندارد، گاهی کمک هم می‌کند:
مؤدب باشید. از جملاتی مانند «لطفاً» و «با تشکر از توجه شما» یا «ممنون از ملاحظه شما» استفاده کنید. به طور واضح بیان کنید که شما اینکه دیگران وقت خود را برای کمک به شما رایگان صرف می‌کنند، تحسین کنید.
صادق بودن، به اندازه واضح، دقیق، با دستور زبان صحیح و مشروح بودن و پرهیز از قالب‌های مالکانه، مهم نیست و حتی جایگزین آنها هم نمی‌تواند باشد. کاربران بطور کلی علاقه دارند که گزارش‌های دقیق تکنیکی از bug ها و ایرادها را هر چند بی ادبانه دریافت کنند تا نوشته‌های مودب ولی ابهام‌آمیز. (اگر این امر برای شما مبهم است، به یاد داشته باشید که سوالها را با چیزی که توسط آن می‌توان یاد گرفت ارزش‌گذاری می‌کنند)
به هر حال اگر مشکلات تکنیکی خود را ردیف کنید، مؤدب بودن شانس شما را برای دریافت پاسخ مفید افزایش می‌دهد.
(باید ذکر شود که تنها مخالفتی که از سوی کاربران قدیمی نسبت به این نوشته دریافت کرده‌ایم، در رابطه با توصیه‌های قبلی ما برای تشکر پیشاپیش است. برخی از کاربران احساس می‌کنند که این دلالتی به منظوری دارد و نه تشکر. توصیه ما اینست که هم پیشاپیش تشکر کنید و هم بعد از پاسخگویی و یا ادب و احترام را به روشهای دیگری بیان کنید قبلا با جملاتی مثل: «با تشکر از توجه شما» یا «ممنون از ملاحظه شما».
روش حل را با یادداشت مختصری پاسخ دهید:
بعد از اینکه مسئله حل شد، یادداشتی به همه کسانی که به شما کمک کرده‌اند بفرستید، آنها را از نحوه‌ی حل مطلع کنید. و باز هم از یاری آنها تشکر کنید. اگر مسئله شما در یک ایمیل لیست را گروه خبری مورد توجه قرار گرفته بود بهتر است این یادداشت را به آنجا بفرستید.
در بهترین حالت، جواب شما باید شامل سوال اولیه و به همراه کلمه حل شده یا Fixed یا Resolved یا هر کلمه‌ای با معنی مشابه در عنوان نامه باشد. در ایمیل لیست‌هایی که سرعت برگشت یا جواب دادن نامه‌ها زیاد است، یک کاربرد مستعد که می‌بینید یک نامه با عنوان مشکل X مطرح شده و سپس نامه مشکل X حل شده وجود دارد، وقت خود را (اگر علاقه‌مند به آن موضوع خاص نباشد) روی آن صرف نمی‌کند و به حل مشکلات دیگر می‌پردازد.
پاسخ شما نباید طولانی و شامل جملاتی ساده مثل: «ایراد از کابل شبکه بود، با تشکر از همه» باشد. حتی اگر پاسخ ندهید، بهتر از این جملات است. پاسخ کوتاه و خلاصه‌ای شیرین بهتر است از یک مقاله طولانی مگر اینکه عمق تکنیکی مسئله زیاد باشد. ذکر کنید که چه عملی مشکل را حل کرد اما لزومی ندارد که تمام مراحل حل مشکل را گزارش کنید.
برای برخی از مسائل مناسب است که خلاصه‌ای از مراحل رفع مشکل را گزارش کنید. وضعیت نهایی مسئله خود را شرح دهید. توضیح دهید که چه روشی شما را به حل رساند و بعد از آن به داده‌هایی که جواب نمی‌رسد اشاره کنید. روشهای اشتباه را باید بعد از جواب صحیح و دیگر مطالب خلاطه بیاورید تا اینکه خلاصه شما تبدیل به یک داستان کارگاهی نشود. از افرادی که به شما کمک کردند نام ببرید، با این کار با آنها دوست هم می‌شوید.
در کنار مودب و آموزنده بودن، این روش خلاصه نویسی به دیگرانی که در آرشیو ایمیل لیست‌ها، گروههای خبری و یا فروم‌ها به دنبال مطلبی هستند، کمک می‌کنید تا بدانند دقیقاً چه روشی به شما کمک کرده است.
در نهایت،این گونه خلاصه نویسی به تمام کسانی که کمک کرده‌اند، احساس رضایت‌مندی و نزدیکی به مسئله می‌دهد و این کم ارزش نیست. اگر شما یک تکنسین یا هکر نیستید، مطمئن باشید که این احساس برای راهنماها و متخصصینی که از آنها کمک گرفته‌اید، بسیار مهم است. شرح مسئله‌ای که به حل نشدن و پوچی ختم شود، مایوس کننده است و کاربران از حل آنها خودداری می‌کنند. احساس دوری از این حالت کمک بسیار بسیار بزرگی به شما برای مرتبه بعدی که می‌خواهید سوال بپرسید می‌کند.
در نظر داشته باشید که چقدر قادرید دیگران را از داشتن مشکل مشابه پیشگیری کنید از خود بپرسید که آیا یک سند نوشته یا FAQ (سوالات پرسیده شده متداول) می‌تواند کمک کند؟ و اگر جواب بله بود، آنرا نوشته و بفرستید.
در میان کاربران حرفه‌ای، این گونه رفتار خلاصه نویسی مهمتر از ادب معمول است. این روشی است که می‌توانید توسط آن شهرتی بین دیگران برای تعامل با آنها کسب کنید که دارایی با ارزشی است.
چگونه پاسخ‌ها را تفسیر کنیم:
RTFM و STFW: چگونه بیان کنیم که دچار مشکل جدی شده‌ایم:
یک رسم سنتی و مقدس وجود دارد: اگر پاسخی دریافت کردید که در آن نوشته شده بود RTFM یعنی با Manaal (کتاب راهنما) را بخوانید. در این مواقع نظر فرد پاسخ دهنده معمولاً صحیح است. بروید دستورالعمل‌ها را بخوانید.
RTFM خویشاوندن جوانتری هم دارد. اگر پاسخ دریافتی شامل STFW بود یعنی آن فرد معتقد است که باید وب را جستجو کنید. مطمئناً حق با اوست. بروید و جستجو کنید.
مدل مودبانه‌تر این بیان اینست که بگویند Google is your Friend یعنی گوگل دوست شماست و این یعنی در گوگل جستجو کنید.
در فروم‌ها، ممکن است توصیه کنند که آرشیو فروم را بگردید. در واقع، ممکن است فرد مهربانی، اشاره‌ای به مشکلات قبلی که این مسئله در آنجا حل شده است، کرده باشد. اما به این ملاحظات اعتماد نکنید، قبل از پرسش، آرشیو را جستجو کنید.
اغلب، هنگامی که افرادی به شما توصیه می‌کنند وب را جستجو کنید، در حین نوشتن از جملات، صفحه‌ای از دستورالعمل یا اطلاعاتی شما به آن نیاز دارید را در مانیتور خود باز کرده‌اند و می‌بینند. این توصیه آنها به این معناست که (1) اطلاعات مورد نیاز شما را به راحتی پیدا می‌شود (2) اگر خودتان جستجو کنید بیشتر یاد می‌گیرید تا اینکه آن اطلاعات را به شما بدهند.
شما با این کار نباید رنجیده شوید. در استاندارد کاربران حرفه‌ای (هکرها)، پاسخ دهنده به سوال شما بدین طریق نوعی از احترام خشن را نشان می‌دهد، به جای اینکه شما را نادیده بگیرد. در عوض شما باید به خاطر این مهربانی مادربزرگانه از او تشکر کنید.
اگر نفهمیدند...:
اگر جواب را نفهمیدید، فورا تقاضای روشن کردن پاسخ نکنید. از همان اندازههایی که برای پاسخ اولیه خودتان(دستورالعمل‌ها FAQS، وب و دوستان ماهر) برای فهمیدن جواب استفاده کنید. سپس اگر باز هم نیاز به شفاف سازی نشان دهید که چه چیزی یادگرفتهاید.
برای مثال تصور کنید که من به شما میگویم: "بهنظر می‌رسد که شما Zentry گرفته شدهای دارید، باید آنرا تمیز کنید." در این صورت یک جوابیه نامناسب این خواهد بود:" Zentryچیست؟" و یک جواب خوب این خواهد بود" بسیار خوب، من صفحه اصلی را خواندم و به Zentry ها تحت عنوان سوئیچهای –Z و –P اشاره شده است اما هیچ یک از تمیز کردن Zentry چیزی نگفتهاند. آیا اینها درست است یا من نکتهای را متوجه نشدهام؟"
برخورد با گستاخی:
آنچه که در محیط هکرها گستاخی مینمایند به معنای توهین آمیزی نیست بلکه حاصل بیان مستقیم و بدور از مطالب اضافه است که برای افرادی که بیشتر به حل مسائل میاندیشیدند تا ایجاد احساس خوبی در دیگران، طبیعیتر است. وقتی با گستاخی مواجه شدید، سعی کنید آرام برخورد کنید. اگر کسی واقعا از حد خود خارج شودبسیار متحمل است که یکی از افراد قدیمی آن لیست یا گروه جدی یا فروم او را متوجه کند. اگر این کار صورت نگیرد و شما خلق و خوی را از دست دهید ممکن است فردی را که طبق هنجارهای یک محیط کاربری افتاده کرده است از دست بدهید و شما مقصر خواهید بود. این امر شانس شما را در دریافت کمک برای آنچه که خواستهاید کاهش خواهد داد.
از طرف دیگر، معمولا شما با گستاخی مواجه می‌شوید و برخورد با آن بیجا خواهد بود. حالت عکس فوق اینست که با متخلفین واقعی را بهشدت برخورد کنید و رفتار غیر معقول آنها را با چاقوی کلام قطع کنید. البته قبل از کار از موقعیت خود بسیار بسیار مطمئن باشید مرز بین تصحیح دیگران و غیر فعال بودن و شروع یک جدال بیهدف به اندازهای باریک است که خود هکرها هم گاهی اوقات آنرا اشتباه می‌گیرند. اگر شما یک تازه وارد هستید، شانس شما کمتر خواهد بود. اگر بدنبال اطلاعات هستید ونه سرگرمی، بهتر است انگشتانتان را از روی کیبورد بردارید و ریسک نکنید.
(برخی افراد معتقدند که هکرها حالت خفیفی از خود ماندگی یا سندرم اسپرگر دارند و واقعا فاقد برخی از مداربندیهای مغزی آنها که برهم کنشهای اجتماعی انسان را روان می‌کند، هستند. این ممکن است درست باشد یا نباشد اگر خودتان یک هکر نیستید، ممکن است از عهده بیقاعدگی و عجیب و غریب بودن این مسئله برآیید، اگر فکر می‌کنید که مغزما دچار ضایعه شده است. شروع کنید ما اهمیتی نمیدهیم! ترجیح میدهیم همان چیزی باشیم که هستیم و عموما تردیدی نسبت به عناوین پزشکی داریم.)
در قسمت بعد، در مورد مطلب متفاوتی بحث می‌کنیم با نوع گستاخی که در اثر رفتار اشتباه با آن برخورد می‌کنید.
شبیه یک بازنده رفتار نکردن:
با توجه به راههای مفصلی که در اینجا گفته شد یا راههای مشابه بعید از که در فرمهای ارتباطی هکرها اشتباه کنید. بهطور دقیقی با جملات متفاوت به شما گفتیم که چگونه می‌توان اشتباه کرد.
اگر چنین اتفاقی افتاد بدترین کار اینست که از این تجربه خود ناله کنید، ادعا کنید که شفاها مورد توهین قرار گرفته‌اید، تقاضای عذرخواهی کنید، جیغ بکشید، نقستان را حبس کنید، به شکایت کردن تهدید کنید، از افراد شکایت کنید و غیره. در عوض کاری که شما می‌کنید، اینست که:
پیش بروید. این امری طبیعی است. درواقع مناسب و سالم است.
استانداردهای جوامع از خودشان حمایت نمیکنند. توسط افراد فعالی که از آنها استفاده می‌کند و بهوضوح در عموم حمایت می‌شوند. ناله نکنید که همه انتقادها باید در ایمیلهای خصوصی عنوان شوند. اینگونه نیست. همچنین نباید اصرار کنید که توسط فردی که یکی از ادعاهای شما را اشتباه خوانده است یا نظر متفاوت است، مورد هجوم واقع شدهاید. این اخلاق بازندههاست.
فرومهایی هستند که در آنها بهدلیل راهنمایی اشتباه و از روی ادب زیاد، شرکتکنندگان توسط دیگران کاربران از فرستادن نامه‌های گمراه کننده منع شدهاند و به آنها گفته شده"اگر نمیخواهید به کسی کمک کنید، لطفا حرف نزنید!"
رفتن کاربران راهنما به جاهای دیگر، منتج به این می‌شود که فروم به صحبتهای بلیمعنی نزول کنند و تبدیل به یک ؟ تکنیکی بیاستفاده گردد.
بهطور اغراقآمیزی "دوستانه" (در این حالت) یا مفید: یکی را انتخاب کنید.
به یاد داشته باشید: وقتی که هکری به شما میگوید که اشتباه کرده‌اید،(صرف نظر از اینکه چقدر درشتگویی کرده باشد)، به شما میگوید که دوباره آن کار را تکرار نکنید، او ملاحظه 1- شما 2- اجتماع را می‌کند. بسیار راحتتر است برای او که شما را ندیده بگیرد و شما را از زندگی خودش فیلتر کند. اگر نمیتوانند سپاسگزار باشید، حداقل کمی بزرگی داشته باشید و ناله و شکایت نکنید و انتظار نداشته باشید که مثل یک عروسک شکننده با شما رفتار بشود زیرا شما یک تازه وارد با روحیه حساس و ادعاهای مبهم هستید.
گاهی اوقات افراد بدون هیچ دلیل روشنی شخصا شما را مورد حمله قرار میدهند حتی اگر شما اشتباهی نکرده باشید(یا فقط در ذهن آنها دچار اشتباه شدهاید.) در این موارد، شکایت کردن روشی واقعا اشتباه است.
این افراد متجاوز، نادان هم هستند که بدون هیچ دلیلی، خود را با تجربه می‌دانند یا با آزمایشهای روانشناسی می‌خواهند بدانند که اشتباه کرده‌اید یا خیر. خوانندگان دیگر هم آنها را نادیده می‌گیرند و یا با روش خودشان با آنها برخورد می‌کنند رفتار اینگونه افراد خود آنها را دچار مشکل می‌کند که به شما ربطی ندارد.
اجازه ندهید که داخل اینگونه بحثها به دام بیفتید. بعد از اینکه بررسی کردید که آیا آنها واقعا توهین هستند و نه اشاره‌ای به اشتباه شما و نه اشاره‌ای به اشتباه شما و نه اشاره‌ای زیرکانه به جواب واقعی سوال شما اغلب توهینها نادیده گرفته می‌شوند.
سوالهایی که نباید پرسید:
در اینجا برخی از سوالهای معمول احمقانه و سوالهایی که هکرها به آنها پاسخی نمیدهند، آورده شده است:
سوال: کجا میتوانم برنامه یا منبع x را پیدا کنم؟
سوال: چگونه میتوانم از X برای انجام استفاده کنم؟
سوال: چگونه میتوانم پوسته Prompt خود را تنظیم کنم؟
سوال: میتوانم یک فایل Acme Corp را به Tex توسط تبدیل کننده Bass- O- Matic تبدیل کنم؟
سوال:مسیر SQL statement و Configuration و Program من کار نمی‌کند!
سوال: با Window خود مشکل دارم. می‌توانید کمکم کنید؟
سوال: برنامه من کار نمی‌کند. فکر می‌کنم وسیله X سیستم من خراب است!
سوال: برای نصب Linux یا X مشکل دارم. می‌توانید کمکم کنید؟
سوال: چگونه میتوانم Crack کنم؟ حق امتیاز یک کانال را بدزدم؟ ایمیل کسی را بخوانم؟
سوال: کجا میتوانم برنامه یا منبع X را پیدا کنم؟
جواب: از همانهایی که من پیدا کردم در پایان یک جستجوی اینترنتی. یعنی هنوز همه نمی‌دانند چگونه از google استفاده کنند؟
سوال: چگونه میتوانم از X برای انجام Y استفاده کنم؟
جواب: اگر هدف شما انجام Y است نباید روشی را که ممکن است برای آن مناسب نباشد ذکر کنید. سوالهایی از این قبیل اغلب نشانگر این هستند که فرد فقط در مورد X بیاطلاع نیست بلکه در مورد شکل 2 که درحال حل آنست و در جزئیات موقعیت خاصی هم سردرگم شده است. بهتر است اینگونه افراد را نادیده بگیریم تا وقتیکه مشکل خود را بهتر مطرح کنند.
سوال: چگونه میتوانم پوسته Prompt خود را تنظیم کنم؟
جواب: اگر به همان اندازه که برای پرسیدن این سوال باهوش باشید می‌توانید RTFM کنید و جواب خود را بیابید.
سوال: میتوانم یک فایل Acme Corp را به فایل Tex با تبدیل کننده Boss- O- matic تبدیل کنم؟
جواب: امتحان کن و ببین اگر این کار را میکردی 1- جواب را مییافتی 2- وقت من را هم نمیگرفتی.
سوال: مسیر SQL statement و Program/ Configuration من کار نمی‌کند.
جواب: این سوال نیست و من علاقه‌مند نیستم که با بیست سوالی سوال واقعی را شما کاوش کنم.
کارهای . بهتری برای انجام دارم. وقتی چیزی شبیه این میبینم، عکسالعمل من طبیعتا یکی از موارد زیر خواهد بود: چیز دیگری هم داری که به آن اضافه کنی؟
آه، چقدر بد! امیدوارم درستش کنی.
دقیقا این چه ربطی به من دارد؟
سوال: با Windows خود شکل دارم می‌توانید کمک کنید؟
جواب: بله آن تفاله مایکرو سافت را بیرون بریز و یک سیستم عامل با منبع باز مثل Linux یا BSD نصب کن.
یادداشت: در مورد Windows و در مورد برنامهای که ساخت رسمی ویندوز نیست یا با آن تداخل دارد(مثل Somba) سوال نپرس. از این جواب متعجب نباش چراکه مشکل از ویندوز است و نه برنامه زیرا ویندوز بهطور کلی بسیار آسیبپذیر است و این مورد معمولی است.
سوال: برنامه من کار نمی‌کند. فکر می‌کنم وسیله X سیستم من خراب است.
جواب: درحالیکه ممکن است شما اولین مغزی باشید که به یک عیب واضح
در سیستم توجه کرده باشید به کتابخانههایی که توسط صدها یا هزاران نفر استفاده شدهاند رجوع کنید؛ بهتر از اینست ک بطور کلی بیدلیل بنویسید ادعاهای غیر معمول، شواهد غیر معمول هم لازم دارد وقتی ادعایی شبیه این می‌کنید، باید با مستندات واضح و جامع در مورد ایراد پشتیبانی کنید.
سوال : برای نصب Linux یا X یا مشکل دارم می‌توانید کمک کنید؟
جواب: خیر. باید دستم به سیستم شما برسد تا بتوانم مشکل را حل کنم. از گروه محلی کاربران Linux خود برای کمک بپرسید.(می‌توانید لیستی از گروههای کاربران را اینجا پیدا کنید.)
یادداشت: سوال در مورد نصب Linux هنگامیکه در ایمیل لیست یا فرومی در مورد یک توزیع خاص باشید مناسب است، یا در فرمهای محلی کاربران. در این موارد، جزئیات مشکل را شرح دهید. اما قبل از آن جستجوی دقیقی با "Linux" و همه قطعات سختافزاری مشکوک انجام دهید.
سوال: چگونه میتوانم Crack حق امتیاز یک کانال را بدزدم؟ ایمیل کسی را بخوانم؟
جواب: شما زندگی سطح پایینی دارید که می‌خواهید این کارها را انجام دهید و یک انسان سبک مغز هستید که از یک هکر چنین چیزی می‌پرسید.
سوالهای خوب و بد:
در آخر، قصد دارم که توسط مثالهایی روش سوالهای هوشمندانه را شرح دهم جفتی از سوالها درباره یک مشکل یکسان، یکی از راه احمقانه و دیگر هوشمندانه.
احمقانه: کجا میتوانم چیزی درباره Foonly Flarbamatic پیدا کنم؟
این سوال فقط تقاضای یک "STFW" در جواب دارد.
هوشمندانه: از گوگل برای یافتن "Foonly Flurbumatic 2600" استفاده کردم، اما راهنمایی مقیدی نیافتم. میتوانم راهنمایی در مورد اطلاعات برنامهنویسی روی این وسیله بگیرم؟
این مورد اکنون STFW را انجام داده است و به نظر می‌رسد که مشکل واقعی دارد.
احمقانه: نمی‌توانم کد را از فلان پروژه برای کمپایل بگیرم. چرا خراب است؟
این پرسشگر فرض می‌کند که کس دیگری اشتباه کرده است خودبین...
هوشمندانه: کدهای فلان پروژه تحت Nulix ورژن 6.2 کمپایل نمی‌شود. من FAQ را خواندهام اما چیزی درمورد مسائل مربوط به Nulix نداشت. در اینجا نسخهای از تلاش کمپایل کردن را آوردهام آیا کاری انجام دادهام؟
پرسشگر این سوال محیط را مشخص کرده است FAQ را خوانده است خطا را نشان داده است. و فرض نمی‌کند که شکل او اشتباه دیگری باشد. این مورد ارزش توجه را دارد.
احمقانه: با مادربورد خود مشکل دارم کسی می‌تواند کمک کند؟
پاسخ هکر J. Randem به این سوال اینست:"درست است. آیا احتیاج دارد آروغ بزنید و پوشکتان عوض شود؟" که با زدن کلید Delete پایان مییابد.
هوشمندانه: روی مادربورد t,y,x,s2464 را امتحان کردم. وقتی کمکی نکرد C,B,A را امتحان کردم. هنگام امتحان C نشانه‌های غیر معمول را یادداشت کردم بهطور مشخص اشکال از برنامهنویسی است اما نتایج طبق انتظار نیست. دلایل معمول ایرادهای مادربوردهای athlon MP کدامند؟ کسی ایدهای برای امتحان بیشتر مادربورد برای حل مشکل موجود دارد؟
از طرف دیگر این فرد ارزش پاسخ را دارد. او هوش حل مسئله خود را نشان داد. نه اینکه منفعلانه منتظر جوابی از بالا باشد.
در سوال آخر دقت کنید به تفاوت زیرکانه ولی مهم بین درخواست کردن"جوابی به من بدهید" و "لطفا به من کمک کنید تا بدانم چه تشخیصهای دیگری میتوانم بدهم تا به آگاهی برسم" در واقع حالت سوال آخر بسیار نزدیک به یک رویداد واقعی که در آگوبیت 2001 در ایمیل لیست (lkml) Linux- kemel اتفاق افتاد بنا شده است. من (اریک) در آن زمان یک سوال پرسیدم. من قفل شدنهای عجیبی در مادربورد S2462 Tyon میدیدم. اعضای لیست اطلاعات ضروری که برای حل به آنها نیاز داشتم که تامین کردند.
به روشی که من سوال را پرسیدم به مردم چیزی را برای چاوش کردن دارم؛ من راه را برای وارد شدن آنها آسان و جذاب کردم. من برای توانایی همسالان خودم احترام قائل شدم و آنها را برای مشورت با من بهعنوان یک دوست دعوت کردم. همچنین برای زمانی که آنها برای نشان دادن روشهای اشتباه به من صرف کردند احترام قائل شدم.
بعد از آن، وقتیکه از همه تشکر کردم و یادآوری کردم که چه خوب فرآیند حل شد، یکی از اعضای lkml مشاهده کرد که این مسئله نه به این خاطر که من یک "اسمی" در لیست داشتم حل شده است، بلکه به اینخاطر که من سول را به روش مناسبی پرسیدم.
هکرها از برخی جهات خیلی ظالماند. من مطمئن هستم که اگر مانند یک انگل رفتار میکردم، به من توهین میشد یا اینکه مرا نادیده میگرفتید بدون توجه به اینکه من چهکسی هستم. پیشنهاد او برای نوشتن کل ماجرا بهعنوان یک دستورالعمل به دیگران مستقیما موجب شد تا این راهنما را بنویسیم.
اگر نتوانستید جوابی بدست آورید:
اگر نتوانستید جوابی بیابید لطفا ناراحت نشوید که ما احساس نمیکنیم که میتوانیم به شما کمک کنیم.گاهی اوقات اعضای گروهی که شما از آنها سوالی پرسیدهاید ممکن است جواب را ندانند ندادن جواب به معنای نادیده گرفتن نیست، اگرچه مسلما تشخیص بین این دو سخت است.
بطور کلی، دوباره فرستادن سوال ایدهی بدی است. این کار آزاردهنده و غیر مودبانه بهنظر می‌رسد. صبر داشته باشید: کسی که جواب شما را میداند ممکن است در منطقه ساعتی جهانی دیگری و در حالت خواب باشد. یا شاید سوال شما به حدکافی خوب شکل نگرفته باشد تا بتوان با آن شروع کرد.
مراجع دیگری برای کمک به شما هستند که اغلب به نیاز تازه واردها بهتر جواب میدهند. گروههای کاربری محلی و آن لاین بسیاری هست که مشتاق نرم‌افزار هستند حتی اگر هیچگاه خودشان نرمافزاری ننوشته باشند. این گروهها معمولا به این دلیل شکل می‌گیرند که بتوانن به یکدیگر و تازه وارد کمک کنند.
همچنین شرکتهای تجاری بسیاری هستند که می‌توانید برای کمک گرفتن با آنها تماس بگیرید، چه بزرگ و چه کوچک(SpikeSource , RedHat دو تا از بهترین آنها هستند، موارد بسیارری دیگری نیز هست). از اینکه باید برای کمک گرفتن، پولی بپردازید مضطرب نشوید! اگر موتور ماشین شما واشر بالایی را بسوزاند، باید بروید به یک تعمیرگاه و برای تعمیر آن پول بپردازید.
حتی اگر نرم‌افزار برای شما هزینهای در بر نداشته باشد، نباید انتظار داشته باشید که پشتیبانی هم همیشه مجانی باشد.
برای نرمافزارهای معروف مانند Linux ، حداقل 10000 کاربر برای هر نمایندگی وجود دارد. برای یک نفر ممکن نیست که تماس 10000 نفر را پشتیبانی کند. یادآوری می‌کنیم که حتی اگر مجبور شوید برای کمک پول بپردازید، هنوز دارید پول کمتری نسبت به آنچه که باید برای خرید نرمافزاری میپرداختید، میپردازید (پشتیبانی برای نرم افزار با منبع بسته معمولا گرانتر و با صلاحیت کمتری نسبت به یک نرم‌افزار با منبع باز است.)
چگونه به سوالات بهطور مفید پاسخ بدهیم:
آرام باشید. سوالهایی که با تنش همراه باشد، باعث می‌شوند افراد احمق و یا گستاخ جلوه کننده حتی اکر اینطور نباشد.
به اولین متخلف بهصورت Off- Line پاسخ دهید. هیچ نیازی به تحقیر کسی که اشتباه صادقانهای را مرتکب شده است،در جمع عمومی نیست یک تازه وارد واقعی شاید نداند که چگونه آرشیو را جستجو کند یا کجا FAQ ذخیره می‌شوند. اگر واقعا نمیدانید، بگویید! یک جواب اشتباه ولی ظاهرا موثق بدتر از اینست که چیزی گفته نشود به کسی به گونهای اشاره نکنید که او تحقیر شود چون فقط می‌خواهید مانند یک فرد ماهر بهنظر بیایید متواضع و صادق باشید، مثال خوبی برای سوال کننده و همتایان خود بزنید.
اگر نمیتوانید کمک کنید، مانع از کمک هم نشوید. روشها را به شوخی نگیرید که ممکن است ساختار کاربر را به شوخی نگیرید که ممکن است ساختاری کاربر را از بین ببرد، یک کاربر ضعیف ممکن است اینها بهعنوان دستورالعمل تلقی کند.
سوالهای کاوش گراند. بپرسید تا جزئیات بیشتری را استخراج کند. اگر در این کار ماهر هستید، سوال کننده چیزی یاد خواهد گرفت و همچنین شما سعی کنید سوال بد را به خوب تبدیل کنید. یادمان باشد که همه ما زمانی تازه وارد بودیم.
در هنگام خواندن RTFM گاهی اوقات خوب است به کسی که تنبل و نامرتب است یک راهنمایی به مستندات بکنیم(حتی اگر یک پیشنهاد برای عبارت کلیدی جستجو در گوگل باشد.)
اگر به دنبال پاسخ دادن به سوال هستید ارزش خوبی به آن بدهید. به کسی که روش یا ابزار اشتباهی را بکار گرفته، برای دور زدن مسئله ندهید. ابزار مناسب را پیشنهاد کنید. سوال را دوباره قالببندی کنید.
به جامعه خود برای یادگرفتن از سوال کمک کنید. وقتی که سوال خوبی دارید، از خودتان بپرسید، "چگونه می‌توان اسناد و FAQ های مرتبط را بهگونهای تغییر داد که دیگر کسی این سوال را دوباره نپرسد؟" سپس یک ضمیمه برای اسناد(به نگهدارنده سایت بفرستید).
اگر برای پاسخ پژوهشی انجام داده‌اید، مهارتهای خود را نشان دهید بهجای اینکه وانمود کنید جواب را از جیب خود درآوردهاید. جواب دادن به یک سوال خوب، مانند غذا دادن به یک فرد گرسنه است اما آموختن روشها و مهارتهای تحقیق توسط مثال به آنها مانند نشان دادن راهی برای کاشتن غذا برای یک عمر است.
تحقیر کردن جایگزینی برای انجام تکلیف نیست:
بعضی از افراد که می‌دانند نباید گستاخانه یا مغرورانه رفتار کنند، در نقطه مقابل تحقیر کردن، تقاضای جواب می‌کنند. جملاتی مثل «می‌دانم که یک کاربر جدید بازنده هستم ولی...» از این قبیل‌اند. این کار منحرف کننده است و کمکی هم نمی‌کند به خصوص این کار وقتی توام با ابهام در مورد مشکل واقعی باشد، آزار دهنده است.
وقت خود و ما را با سیاست‌های خام و پیش پا افتاده هدر ندهید. در عوض، زمینه‌های واقعی مشکل خود را به وضوح شرح دهید. این کار بهتری نسبت به تحقیر کردن است.
برخی از Forum ها محل جداگانه‌ای برای سوالهای کاربران جدید دارند. اگر فکر می‌کنید که سوال پیش پا افتاده‌ای دارید، به آنجا بروید. اما در آنجا نیز نباید تحقیر کرد.
به جای حدس‌های خود نشانه‌های مشکل را شرح دهید:
نوشتن در مورد اینکه خودتان علت مشکل پیش آمده را چه می‌دانید، مفید نیست (اگر فرضیات شما بکلی اشتباه باشد آیا با دیگران مشورت می‌کنید؟)
لذا سعی کنید که به دوستداران کامپیوتر از علائم و نشانه‌های اولیه مشکل موجود بگویید و نه از فرضیات و تئوری‌های خود. بگذارید
آنها خود تفسیر کنند و مشکل را تشخیص دهند اگر احساس می‌کنید که ذکر کردن حدس خودتان می‌تواند مهم باشد، آنرا روشن و تحت عنوان حدس خودتان بیان کنید و همچنین ذکر کنیدن که چرا این پاسخ نمی‌تواند جوابگوی مسئله باشد.
سوال احمقانه:
من دائماً پیغام خطای SIG11 را در هسته کمپایل دریافت می‌کنم و به یک شکاف بسیار نازک در بورد اصلی (Mothor Boord) مشکوک هستم. بهترین راه برای اطمینان از این وضعیت چیست؟
سؤال هوشمندانه:
کامپیوتر خانگی من که K 6233 بر روی بورد اصلی FIC-PA 2007 (VIA Apollo VP2 Chipcedt) با 256 مگابایت رم از نوع Car Sair PC133 SDRAM می‌باشد، 20 دقیقه بعد از روشن شدن دائماً پیغام خطای SIG11 را نشان می‌دهد. اما قبل از 20 دقیقه هرگز این اتفاق نمی‌افتد. با Restart کردن سیستم، ساعت Restart نمی‌شود ولی با خاموش کردن در شب Restart می‌شود. با خارج کردن رم‌ها هم این مشکل حل نمی‌شود. قسمت مربوطه از فهرست کامپایل به شرح ذیل است.
چون رسیدن به این نقطه برای بسیاری از افراغد مشکل به نظر می‌رسد، یک جمله را به شما یادآوری می‌کنیم: «همه تشخیص دهندگان از ایالت میسوری هستند!» که شعار اداری این ایالت «به من نشان بده» است. (در سال 1899 یکی از افراد کنگره آمریکا گفت من از کشوری می‌آید که در آنجا ذرت و کتان و دموکرات و فصاحت بیان بی‌معنی کشت می‌کنند که نه مرا متقاعد می‌کند و نه راضی. من از ایالت میسوری هستم. شما باید به من نشان بدهید) در مورد تشخیص دادن، شک کردن مهم نیست اما نیاز واقعی و کاربردی به دانستن این است که چه چیزی به نشانه‌هایی که شما دیده‌اید نزدیک‌تر است و نه فرضیات و حدس‌های شما. به ما نشان بدهید!
نشانه‌های مشکل خود را به ترتیب زمان وقوع شرح دهید:
نشانه‌های مفید برای تشخیص اینکه چه مشکلی پیش آمده است، اغلب در اتفاقاتی که قبلاً افتاده‌اند وجود دارند. لذا نامه شما باید به دقت شرح دهید که شما چه کاری انجام داده‌اید و سیستم و کامپیوتر شما چه عکس‌العملی داشتند تا اینکه سیستم blow up کرده است.
در مورد فرآیندهای Command-Line ، داشتن یک Session log و نقل قول مربوط در حدود بیست خط می‌تواند خیلی مفید باشد.
اگر برنامه شما که blow up کرده است، دارای گزینه تشخیص عیب باشد ( مانند حالت verbose ) سعی کنید از آن برای گرفتن اطلاعات بیشتر برای اشکال‌زدایی (debug) برنامه استفاده کنید.
به یاد داشته باشید که لزوماً هر چه بیشتر، بهتر نخواهد بود. سعی کنید سطحی از اشکال‌زدایی را انتخاب کنید که خواننده را مطلع نماید و نه اینکه آنرا در انبوهی از داده‌های بی‌ارزش گمراه کند.
اگر نوشته شما طولانی شد (بیش از 4 پاراگراف)، بهتر است به طور مختصر مشکل را در ابتدا مطرح کنید و سپس به شرح وقایع به ترتیب زمانی بپردازید. به این ترتیب خوانندگان خواهند دانست که در نوشته شما به دنبال چه چیزی باید بگردند.
هدف را مشخص کنید، نه مرحله:
اگر به دنبال این هستید که بدانید چطور باید کاری را انجام داد (مثل گزارش کردن یک اشکال یا bug )،با شرح دادن هدف خود شروع کنید. بعد از آن فقط برخی از مراحل خاص که برای رسیدن به آن طی کردید و موفق نشدید را شرح دهید.
اغلب، افرادی که به کمک تکتیکی نیاز دارند، هدف بلند مرتبه‌ای را در ذهن می‌پرورانند و در راهی که فکر می‌کنند تنها راه رسیدن به هدف است گمراه می‌شوند. آنها برای کمک گرفتن مرحله به مرحله می‌آیند اما نمی‌دانند که مسیر اشتباه است تلاش قابل توجهی برای گذر از این مرحله مورد نیاز است.
سوال احمقانه :
چگونه می‌توان در برنامه FooDraw مقادیر RGB رنگ را بر مبنای شانزده‌تایی انتخاب کرد؟
سوال هوشمندانه :
من تلاش می‌کنم که جدول رنگ‌ها را روی یک تصویر با مقادیر انتخابی خودم قرار دهم. در حال حاضر تنها راهی که به نظرم می‌رسد اینست که هر ردیف از جدول را اصلاح کنم اما نمی‌توانم در برنامه FooDraw رنگ‌ها را بر مبنای مقادیر RGB شانزده‌تایی انتخاب کنم.
سوال دوم هوشمندانه بود. جواب این سوال ابزار بهتری برای آن کار را پیشنهاد می‌دهد.
از دیگران نخواهید که جواب سوال را به صورت خصوصی ایمیل کنند:
کاربران اینترنت عقیده دارند که حل مشکلات باید یک فرآیند عمومی و روشن باشد که در طی آن اولین جواب به یک پاسخ می‌تواند و باید توسط دیگر کاربران که با اطلاعات بیشتری به آن توجه می‌کنند مورد تصحیح و تکمیل قرار بگیرد. همچنین، کسانی که کمک می‌کنند تا دیگران به جواب سوال خود برسند، بخشی از پاداش خود را به این صورت می‌گیرند که به عنوان یک فرد مسئول و جوابگو و صلاحیت‌دار و مطلع توسط دیگر کاربران دیده می‌شوند.
وقتی که شما درخواست جواب خصوصی می‌کنید، هم فرآیند پاسخگویی و هم این پاداش را دچار مشکل می‌کنید. این کار را نکنید. این انتخاب فرد پاسخگو است که به شما بطور خصوصی پاسخ دهد یا خیر و اگر او این کار را انجام دهد معمولاً به این دلیل است که فکر می‌کند سوال از لحاظ جذابیت برای دیگران و همچنین اطلاعات، برای دیگران بسیار ضعیف است.
تنها یک استثناء برای این قاعده وجود دارد. اگر فکر می‌کنید که سوال شما بگونه‌ای است که ممکن است جواب‌های بسیار زیاد و مشابه به یکدیگر دریافت کنید، از کلمات جادویی مانند «به من ایمیل بزنید و من خلاصه‌ای از پاسخ‌ها را به Group خواهم فرستاد» استفاده کنید. ممانعت از ورود تعداد بسیار زیاد نامه‌های مشابه یکدیگر به Group ' ها و یا Mailing hist ها کار مودبانه‌ای است اما باید به قول خود مبنی بر خلاصه کردن جواب‌ها عمل کنید.
سوال را صریح مطرح کنید:
برای سوالهایی که انتهای مشخصی ندارد، بازه زمانی محدودی برای پاسخگویی به آنها در نظر گرفته نمی‌شود. کسانی که می‌خواهند پاسخ‌های مفیدی به شما بدهند، مشغول‌ترین افراد هستند. (چون در اغلب کارها به تنهایی کار می‌کننند). این گونه افراد نسبت به سوالهایی با بازه زمانی نامحدود حساسیت دارند و تمایل چندانی به پاسخگویی به آنها ندارند.
شما هنگامی که یک پاسخ مفید دریافت می‌کنید که از پاسخگویی خود در مورد چیزی که می‌خواهید بطور صریح پرسیده باشید (از اشاره‌گر استفاده کند، که بفرستید، پیوست را بررسی کنید یا هر چیز دیگر). این کار تلاش پاسخگو را بر روی هدف شما متمرکز می‌کند و به طور ضمنی حدی از نظر زمانی برای پاسخگویی و صرف انرژی برای کمک به شما ایجاد می‌کند. این کار خوبی است.
برای درک دنیایی که متخصصین در آن زندگی می‌کنند، به مهارت به عنوان یک منبع و زمان فراوان برای پاسخگویی به یک مورد کمیاب فکر کنید. هر چه زمان کمتری را برای پاسخگویی به سوال خود به طور ضمنی در نظر بگیرید، احتمال اینکه جواب واقعاً مناسب از جانب یک فرد خبره و پرمشغله دریافت کنید، بیشتر می‌شود بنابراین بهتر است که برای سوال خود قالبی در نظر بگیرید که زمان مورد نیاز به پاسخگویی به آن را از جانب یک فرد خبره به حداقل برساند. اما این کار اغلب مشابه ساده‌سازی یک سوال نیست. به عنوان مثال، ممکن است برای شرح مناسبی از X یک راهنمایی بکنید؟ معمولا سوال هوشمندانه‌تری است نسبت به اینکه ممکن است لطفاً X را توضیح دهید!
اگر شما یک کد نادرست دارید، بهتر است در مورد اینکه چه اشکالی دارد بپرسید تا اینکه درخواست کنید کسی آنرا اصلاح کند.
==وقتی که در مورد کد می‌پرسید:==
بدون اینکه مشخص کنید که باید به دنبال چه نوع مشکل باید بود، از دیگران نخواهید تا کد برنامه‌ی شما را اشکال‌زدایی یا به اصلاح debug کنند. فرستادن چند صد خط برنامه و گفتن اینکه «این برنامه کار نمی‌کند!» باعث می‌شود که هیچ پاسخی دریافت نکنید با فرستادن ده دوازده خط از برنامه و گفتن اینکه بعد از خط هفتم انتظار داشتم یا اتفاق
تکالیف منزل را سوال نکنید:
کاربران کامپیوتر دریافتن سوالهای تکالیف منزل تبحر دارند. اغلب ما این کار را کرده‌ایم. این سوالها برای این است که شما روی آنها کار کنید تا تجربه کسب کنید. پرسیدن راهنمایی ایرادی ندارد اما نه کل روش حل.
اگر دیدید که روی یک سوال کار کرده‌اید اما نتوانستید آنرا حل کنید، از یک فروم یا گروپ بپرسید یا در نهایت به عنوان یک «کاربر» از لیست فروم یا پروژه کمک بگیرید با وجود اینکه کاربران دیگر متوجه آن می‌شوند، اما برخی از دیگر کاربران حرفه‌ای ممکن است حداقل یک راهنمایی به شما بکنند.
سوالهای بی معنی را حذف کنید:
از به پایان رساندن درخواست سوال خود با جملات بی‌مفهومی مانند کسی می‌تواند به من کمک کند؟ یا آیا جوابی وجود دارد؟ پرهیز کنید. اولاً، اگر شرح خود را تا نیمه نوشته بودید، این گونه سوالها زائد هستند. دوماً، به دلیل زائد بودن آنها کاربران آنها را آزاردهنده تلقی می‌کنند و احتمال دارد که جواب‌هایی بی عیب و نقص ولی بی اعتنا مانند بله، به شما می‌توان کمک کرد. یا خیر، هیچ کمکی نمی‌توان کرد به شما بدهند.
به طور کلی، از سوالهای آری یا خیر باید اجتناب شود مگر اینکه تنها جواب بله یا خیر برای شما کافی باشد.
سوال خود را با کلمه «فوری» نشانه‌دار نکنید، حتی اگر برای شما اینگونه باشد: این مشکل شماست، نه دیگران. اظهار ضرورت کردن نتیجه معکوس می‌دهد. بیشتر کاربران به راحتی اینگونه سوالها را که با خودخواهی و گستاخی درخواست توجه فوری و ویژه می‌کنند را حذف می‌کنند.
تنها یک شبه استثناء وجود دارد. اگر شما در یک محل با مرتبه بالا و با یک نرم‌افزار کار می‌کنید و از نظر زمانی تحت فشار هستید، گفتن مودبانه محدودیت زمانی خود می‌تواند موثر باشد تا دیگران را به پاسخ دادن به شما ترغیب کند.
البته این کار ریسک بالایی دارد، چون معیار جالب بودن مسائل از نظر کاربران دیگر با شما متفاوت است. به عنوان مثال فرستادن نامه از یک ایستگاه فضایی بین‌المللی قانع کننده است اما از جانب یک انسان با احساس خوب و مهربان یا یک سیاستمدار خیر. در واقع، نوشتن کلمة «فوری» باعث می‌شود که از سوال شما اجتناب و دوری شود حتی اگر از نظر آنها مهم باشد.
اگر فکر می‌کنید که این امری مبهم است،دوباره این مطالب را بخوانید تا کاملاً آنرا درک کنید، قبل از آنکه نوشته‌ای را به جایی بفرستید.
ادب ضرری ندارد، گاهی کمک هم می‌کند:
مؤدب باشید. از جملاتی مانند «لطفاً» و «با تشکر از توجه شما» یا «ممنون از ملاحظه شما» استفاده کنید. به طور واضح بیان کنید که شما اینکه دیگران وقت خود را برای کمک به شما رایگان صرف می‌کنند، تحسین کنید.
صادق بودن، به اندازه واضح، دقیق، با دستور زبان صحیح و مشروح بودن و پرهیز از قالب‌های مالکانه، مهم نیست و حتی جایگزین آنها هم نمی‌تواند باشد. کاربران بطور کلی علاقه دارند که گزارش‌های دقیق تکنیکی از bug ها و ایرادها را هر چند بی ادبانه دریافت کنند تا نوشته‌های مودب ولی ابهام‌آمیز. (اگر این امر برای شما مبهم است، به یاد داشته باشید که سوالها را با چیزی که توسط آن می‌توان یاد گرفت ارزش‌گذاری می‌کنند)
به هر حال اگر مشکلات تکنیکی خود را ردیف کنید، مؤدب بودن شانس شما را برای دریافت پاسخ مفید افزایش می‌دهد.
(باید ذکر شود که تنها مخالفتی که از سوی کاربران قدیمی نسبت به این نوشته دریافت کرده‌ایم، در رابطه با توصیه‌های قبلی ما برای تشکر پیشاپیش است. برخی از کاربران احساس می‌کنند که این دلالتی به منظوری دارد و نه تشکر. توصیه ما اینست که هم پیشاپیش تشکر کنید و هم بعد از پاسخگویی و یا ادب و احترام را به روشهای دیگری بیان کنید قبلا با جملاتی مثل: «با تشکر از توجه شما» یا «ممنون از ملاحظه شما».
روش حل را با یادداشت مختصری پاسخ دهید:
بعد از اینکه مسئله حل شد، یادداشتی به همه کسانی که به شما کمک کرده‌اند بفرستید، آنها را از نحوه‌ی حل مطلع کنید. و باز هم از یاری آنها تشکر کنید. اگر مسئله شما در یک ایمیل لیست را گروه خبری مورد توجه قرار گرفته بود بهتر است این یادداشت را به آنجا بفرستید.
در بهترین حالت، جواب شما باید شامل سوال اولیه و به همراه کلمه حل شده یا Fixed یا Resolved یا هر کلمه‌ای با معنی مشابه در عنوان نامه باشد. در ایمیل لیست‌هایی که سرعت برگشت یا جواب دادن نامه‌ها زیاد است، یک کاربرد مستعد که می‌بینید یک نامه با عنوان مشکل X مطرح شده و سپس نامه مشکل X حل شده وجود دارد، وقت خود را (اگر علاقه‌مند به آن موضوع خاص نباشد) روی آن صرف نمی‌کند و به حل مشکلات دیگر می‌پردازد.
پاسخ شما نباید طولانی و شامل جملاتی ساده مثل: «ایراد از کابل شبکه بود، با تشکر از همه» باشد. حتی اگر پاسخ ندهید، بهتر از این جملات است. پاسخ کوتاه و خلاصه‌ای شیرین بهتر است از یک مقاله طولانی مگر اینکه عمق تکنیکی مسئله زیاد باشد. ذکر کنید که چه عملی مشکل را حل کرد اما لزومی ندارد که تمام مراحل حل مشکل را گزارش کنید.
برای برخی از مسائل مناسب است که خلاصه‌ای از مراحل رفع مشکل را گزارش کنید. وضعیت نهایی مسئله خود را شرح دهید. توضیح دهید که چه روشی شما را به حل رساند و بعد از آن به داده‌هایی که جواب نمی‌رسد اشاره کنید. روشهای اشتباه را باید بعد از جواب صحیح و دیگر مطالب خلاطه بیاورید تا اینکه خلاصه شما تبدیل به یک داستان کارگاهی نشود. از افرادی که به شما کمک کردند نام ببرید، با این کار با آنها دوست هم می‌شوید.
در کنار مودب و آموزنده بودن، این روش خلاصه نویسی به دیگرانی که در آرشیو ایمیل لیست‌ها، گروههای خبری و یا فروم‌ها به دنبال مطلبی هستند، کمک می‌کنید تا بدانند دقیقاً چه روشی به شما کمک کرده است.
در نهایت،این گونه خلاصه نویسی به تمام کسانی که کمک کرده‌اند، احساس رضایت‌مندی و نزدیکی به مسئله می‌دهد و این کم ارزش نیست. اگر شما یک تکنسین یا هکر نیستید، مطمئن باشید که این احساس برای راهنماها و متخصصینی که از آنها کمک گرفته‌اید، بسیار مهم است. شرح مسئله‌ای که به حل نشدن و پوچی ختم شود، مایوس کننده است و کاربران از حل آنها خودداری می‌کنند. احساس دوری از این حالت کمک بسیار بسیار بزرگی به شما برای مرتبه بعدی که می‌خواهید سوال بپرسید می‌کند.
در نظر داشته باشید که چقدر قادرید دیگران را از داشتن مشکل مشابه پیشگیری کنید از خود بپرسید که آیا یک سند نوشته یا FAQ (سوالات پرسیده شده متداول) می‌تواند کمک کند؟ و اگر جواب بله بود، آنرا نوشته و بفرستید.
در میان کاربران حرفه‌ای، این گونه رفتار خلاصه نویسی مهمتر از ادب معمول است. این روشی است که می‌توانید توسط آن شهرتی بین دیگران برای تعامل با آنها کسب کنید که دارایی با ارزشی است.
چگونه پاسخ‌ها را تفسیر کنیم:
RTFM و STFW: چگونه بیان کنیم که دچار مشکل جدی شده‌ایم:
یک رسم سنتی و مقدس وجود دارد: اگر پاسخی دریافت کردید که در آن نوشته شده بود RTFM یعنی با Manaal (کتاب راهنما) را بخوانید. در این مواقع نظر فرد پاسخ دهنده معمولاً صحیح است. بروید دستورالعمل‌ها را بخوانید.
RTFM خویشاوندن جوانتری هم دارد. اگر پاسخ دریافتی شامل STFW بود یعنی آن فرد معتقد است که باید وب را جستجو کنید. مطمئناً حق با اوست. بروید و جستجو کنید.
مدل مودبانه‌تر این بیان اینست که بگویند Google is your Friend یعنی گوگل دوست شماست و این یعنی در گوگل جستجو کنید.
در فروم‌ها، ممکن است توصیه کنند که آرشیو فروم را بگردید. در واقع، ممکن است فرد مهربانی، اشاره‌ای به مشکلات قبلی که این مسئله در آنجا حل شده است، کرده باشد. اما به این ملاحظات اعتماد نکنید، قبل از پرسش، آرشیو را جستجو کنید.
اغلب، هنگامی که افرادی به شما توصیه می‌کنند وب را جستجو کنید، در حین نوشتن از جملات، صفحه‌ای از دستورالعمل یا اطلاعاتی شما به آن نیاز دارید را در مانیتور خود باز کرده‌اند و می‌بینند. این توصیه آنها به این معناست که (1) اطلاعات مورد نیاز شما را به راحتی پیدا می‌شود (2) اگر خودتان جستجو کنید بیشتر یاد می‌گیرید تا اینکه آن اطلاعات را به شما بدهند.
شما با این کار نباید رنجیده شوید. در استاندارد کاربران حرفه‌ای (هکرها)، پاسخ دهنده به سوال شما بدین طریق نوعی از احترام خشن را نشان می‌دهد، به جای اینکه شما را نادیده بگیرد. در عوض شما باید به خاطر این مهربانی مادربزرگانه از او تشکر کنید.
اگر نفهمیدند...:
اگر جواب را نفهمیدید، فورا تقاضای روشن کردن پاسخ نکنید. از همان اندازههایی که برای پاسخ اولیه خودتان(دستورالعمل‌ها FAQS، وب و دوستان ماهر) برای فهمیدن جواب استفاده کنید. سپس اگر باز هم نیاز به شفاف سازی نشان دهید که چه چیزی یادگرفتهاید.
برای مثال تصور کنید که من به شما میگویم: "بهنظر می‌رسد که شما Zentry گرفته شدهای دارید، باید آنرا تمیز کنید." در این صورت یک جوابیه نامناسب این خواهد بود:" Zentryچیست؟" و یک جواب خوب این خواهد بود" بسیار خوب، من صفحه اصلی را خواندم و به Zentry ها تحت عنوان سوئیچهای –Z و –P اشاره شده است اما هیچ یک از تمیز کردن Zentry چیزی نگفتهاند. آیا اینها درست است یا من نکتهای را متوجه نشدهام؟"
برخورد با گستاخی:
آنچه که در محیط هکرها گستاخی مینمایند به معنای توهین آمیزی نیست بلکه حاصل بیان مستقیم و بدور از مطالب اضافه است که برای افرادی که بیشتر به حل مسائل میاندیشیدند تا ایجاد احساس خوبی در دیگران، طبیعیتر است. وقتی با گستاخی مواجه شدید، سعی کنید آرام برخورد کنید. اگر کسی واقعا از حد خود خارج شودبسیار متحمل است که یکی از افراد قدیمی آن لیست یا گروه جدی یا فروم او را متوجه کند. اگر این کار صورت نگیرد و شما خلق و خوی را از دست دهید ممکن است فردی را که طبق هنجارهای یک محیط کاربری افتاده کرده است از دست بدهید و شما مقصر خواهید بود. این امر شانس شما را در دریافت کمک برای آنچه که خواستهاید کاهش خواهد داد.
از طرف دیگر، معمولا شما با گستاخی مواجه می‌شوید و برخورد با آن بیجا خواهد بود. حالت عکس فوق اینست که با متخلفین واقعی را بهشدت برخورد کنید و رفتار غیر معقول آنها را با چاقوی کلام قطع کنید. البته قبل از کار از موقعیت خود بسیار بسیار مطمئن باشید مرز بین تصحیح دیگران و غیر فعال بودن و شروع یک جدال بیهدف به اندازهای باریک است که خود هکرها هم گاهی اوقات آنرا اشتباه می‌گیرند. اگر شما یک تازه وارد هستید، شانس شما کمتر خواهد بود. اگر بدنبال اطلاعات هستید ونه سرگرمی، بهتر است انگشتانتان را از روی کیبورد بردارید و ریسک نکنید.
(برخی افراد معتقدند که هکرها حالت خفیفی از خود ماندگی یا سندرم اسپرگر دارند و واقعا فاقد برخی از مداربندیهای مغزی آنها که برهم کنشهای اجتماعی انسان را روان می‌کند، هستند. این ممکن است درست باشد یا نباشد اگر خودتان یک هکر نیستید، ممکن است از عهده بیقاعدگی و عجیب و غریب بودن این مسئله برآیید، اگر فکر می‌کنید که مغزما دچار ضایعه شده است. شروع کنید ما اهمیتی نمیدهیم! ترجیح میدهیم همان چیزی باشیم که هستیم و عموما تردیدی نسبت به عناوین پزشکی داریم.)
در قسمت بعد، در مورد مطلب متفاوتی بحث می‌کنیم با نوع گستاخی که در اثر رفتار اشتباه با آن برخورد می‌کنید.
شبیه یک بازنده رفتار نکردن:
با توجه به راههای مفصلی که در اینجا گفته شد یا راههای مشابه بعید از که در فرمهای ارتباطی هکرها اشتباه کنید. بهطور دقیقی با جملات متفاوت به شما گفتیم که چگونه می‌توان اشتباه کرد.
اگر چنین اتفاقی افتاد بدترین کار اینست که از این تجربه خود ناله کنید، ادعا کنید که شفاها مورد توهین قرار گرفته‌اید، تقاضای عذرخواهی کنید، جیغ بکشید، نقستان را حبس کنید، به شکایت کردن تهدید کنید، از افراد شکایت کنید و غیره. در عوض کاری که شما می‌کنید، اینست که:
پیش بروید. این امری طبیعی است. درواقع مناسب و سالم است.
استانداردهای جوامع از خودشان حمایت نمیکنند. توسط افراد فعالی که از آنها استفاده می‌کند و بهوضوح در عموم حمایت می‌شوند. ناله نکنید که همه انتقادها باید در ایمیلهای خصوصی عنوان شوند. اینگونه نیست. همچنین نباید اصرار کنید که توسط فردی که یکی از ادعاهای شما را اشتباه خوانده است یا نظر متفاوت است، مورد هجوم واقع شدهاید. این اخلاق بازندههاست.
فرومهایی هستند که در آنها بهدلیل راهنمایی اشتباه و از روی ادب زیاد، شرکتکنندگان توسط دیگران کاربران از فرستادن نامه‌های گمراه کننده منع شدهاند و به آنها گفته شده"اگر نمیخواهید به کسی کمک کنید، لطفا حرف نزنید!"
رفتن کاربران راهنما به جاهای دیگر، منتج به این می‌شود که فروم به صحبتهای بلیمعنی نزول کنند و تبدیل به یک ؟ تکنیکی بیاستفاده گردد.
بهطور اغراقآمیزی "دوستانه" (در این حالت) یا مفید: یکی را انتخاب کنید.
به یاد داشته باشید: وقتی که هکری به شما میگوید که اشتباه کرده‌اید،(صرف نظر از اینکه چقدر درشتگویی کرده باشد)، به شما میگوید که دوباره آن کار را تکرار نکنید، او ملاحظه 1- شما 2- اجتماع را می‌کند. بسیار راحتتر است برای او که شما را ندیده بگیرد و شما را از زندگی خودش فیلتر کند. اگر نمیتوانند سپاسگزار باشید، حداقل کمی بزرگی داشته باشید و ناله و شکایت نکنید و انتظار نداشته باشید که مثل یک عروسک شکننده با شما رفتار بشود زیرا شما یک تازه وارد با روحیه حساس و ادعاهای مبهم هستید.
گاهی اوقات افراد بدون هیچ دلیل روشنی شخصا شما را مورد حمله قرار میدهند حتی اگر شما اشتباهی نکرده باشید(یا فقط در ذهن آنها دچار اشتباه شدهاید.) در این موارد، شکایت کردن روشی واقعا اشتباه است.
این افراد متجاوز، نادان هم هستند که بدون هیچ دلیلی، خود را با تجربه می‌دانند یا با آزمایشهای روانشناسی می‌خواهند بدانند که اشتباه کرده‌اید یا خیر. خوانندگان دیگر هم آنها را نادیده می‌گیرند و یا با روش خودشان با آنها برخورد می‌کنند رفتار اینگونه افراد خود آنها را دچار مشکل می‌کند که به شما ربطی ندارد.
اجازه ندهید که داخل اینگونه بحثها به دام بیفتید. بعد از اینکه بررسی کردید که آیا آنها واقعا توهین هستند و نه اشاره‌ای به اشتباه شما و نه اشاره‌ای به اشتباه شما و نه اشاره‌ای زیرکانه به جواب واقعی سوال شما اغلب توهینها نادیده گرفته می‌شوند.
سوالهایی که نباید پرسید:
در اینجا برخی از سوالهای معمول احمقانه و سوالهایی که هکرها به آنها پاسخی نمیدهند، آورده شده است:
سوال: کجا میتوانم برنامه یا منبع x را پیدا کنم؟
سوال: چگونه میتوانم از X برای انجام استفاده کنم؟
سوال: چگونه میتوانم پوسته Prompt خود را تنظیم کنم؟
سوال: میتوانم یک فایل Acme Corp را به Tex توسط تبدیل کننده Bass- O- Matic تبدیل کنم؟
سوال:مسیر SQL statement و Configuration و Program من کار نمی‌کند!
سوال: با Window خود مشکل دارم. می‌توانید کمکم کنید؟
سوال: برنامه من کار نمی‌کند. فکر می‌کنم وسیله X سیستم من خراب است!
سوال: برای نصب Linux یا X مشکل دارم. می‌توانید کمکم کنید؟
سوال: چگونه میتوانم Crack کنم؟ حق امتیاز یک کانال را بدزدم؟ ایمیل کسی را بخوانم؟
سوال: کجا میتوانم برنامه یا منبع X را پیدا کنم؟
جواب: از همانهایی که من پیدا کردم در پایان یک جستجوی اینترنتی. یعنی هنوز همه نمی‌دانند چگونه از google استفاده کنند؟
سوال: چگونه میتوانم از X برای انجام Y استفاده کنم؟
جواب: اگر هدف شما انجام Y است نباید روشی را که ممکن است برای آن مناسب نباشد ذکر کنید. سوالهایی از این قبیل اغلب نشانگر این هستند که فرد فقط در مورد X بیاطلاع نیست بلکه در مورد شکل 2 که درحال حل آنست و در جزئیات موقعیت خاصی هم سردرگم شده است. بهتر است اینگونه افراد را نادیده بگیریم تا وقتیکه مشکل خود را بهتر مطرح کنند.
سوال: چگونه میتوانم پوسته Prompt خود را تنظیم کنم؟
جواب: اگر به همان اندازه که برای پرسیدن این سوال باهوش باشید می‌توانید RTFM کنید و جواب خود را بیابید.
سوال: میتوانم یک فایل Acme Corp را به فایل Tex با تبدیل کننده Boss- O- matic تبدیل کنم؟
جواب: امتحان کن و ببین اگر این کار را میکردی 1- جواب را مییافتی 2- وقت من را هم نمیگرفتی.
سوال: مسیر SQL statement و Program/ Configuration من کار نمی‌کند.
جواب: این سوال نیست و من علاقه‌مند نیستم که با بیست سوالی سوال واقعی را شما کاوش کنم.
کارهای . بهتری برای انجام دارم. وقتی چیزی شبیه این میبینم، عکسالعمل من طبیعتا یکی از موارد زیر خواهد بود: چیز دیگری هم داری که به آن اضافه کنی؟
آه، چقدر بد! امیدوارم درستش کنی.
دقیقا این چه ربطی به من دارد؟
سوال: با Windows خود شکل دارم می‌توانید کمک کنید؟
جواب: بله آن تفاله مایکرو سافت را بیرون بریز و یک سیستم عامل با منبع باز مثل Linux یا BSD نصب کن.
یادداشت: در مورد Windows و در مورد برنامهای که ساخت رسمی ویندوز نیست یا با آن تداخل دارد(مثل Somba) سوال نپرس. از این جواب متعجب نباش چراکه مشکل از ویندوز است و نه برنامه زیرا ویندوز بهطور کلی بسیار آسیبپذیر است و این مورد معمولی است.
سوال: برنامه من کار نمی‌کند. فکر می‌کنم وسیله X سیستم من خراب است.
جواب: درحالیکه ممکن است شما اولین مغزی باشید که به یک عیب واضح
در سیستم توجه کرده باشید به کتابخانههایی که توسط صدها یا هزاران نفر استفاده شدهاند رجوع کنید؛ بهتر از اینست ک بطور کلی بیدلیل بنویسید ادعاهای غیر معمول، شواهد غیر معمول هم لازم دارد وقتی ادعایی شبیه این می‌کنید، باید با مستندات واضح و جامع در مورد ایراد پشتیبانی کنید.
سوال : برای نصب Linux یا X یا مشکل دارم می‌توانید کمک کنید؟
جواب: خیر. باید دستم به سیستم شما برسد تا بتوانم مشکل را حل کنم. از گروه محلی کاربران Linux خود برای کمک بپرسید.(می‌توانید لیستی از گروههای کاربران را اینجا پیدا کنید.)
یادداشت: سوال در مورد نصب Linux هنگامیکه در ایمیل لیست یا فرومی در مورد یک توزیع خاص باشید مناسب است، یا در فرمهای محلی کاربران. در این موارد، جزئیات مشکل را شرح دهید. اما قبل از آن جستجوی دقیقی با "Linux" و همه قطعات سختافزاری مشکوک انجام دهید.
سوال: چگونه میتوانم Crack حق امتیاز یک کانال را بدزدم؟ ایمیل کسی را بخوانم؟
جواب: شما زندگی سطح پایینی دارید که می‌خواهید این کارها را انجام دهید و یک انسان سبک مغز هستید که از یک هکر چنین چیزی می‌پرسید.
سوالهای خوب و بد:
در آخر، قصد دارم که توسط مثالهایی روش سوالهای هوشمندانه را شرح دهم جفتی از سوالها درباره یک مشکل یکسان، یکی از راه احمقانه و دیگر هوشمندانه.
احمقانه: کجا میتوانم چیزی درباره Foonly Flarbamatic پیدا کنم؟
این سوال فقط تقاضای یک "STFW" در جواب دارد.
هوشمندانه: از گوگل برای یافتن "Foonly Flurbumatic 2600" استفاده کردم، اما راهنمایی مقیدی نیافتم. میتوانم راهنمایی در مورد اطلاعات برنامهنویسی روی این وسیله بگیرم؟
این مورد اکنون STFW را انجام داده است و به نظر می‌رسد که مشکل واقعی دارد.
احمقانه: نمی‌توانم کد را از فلان پروژه برای کمپایل بگیرم. چرا خراب است؟
این پرسشگر فرض می‌کند که کس دیگری اشتباه کرده است خودبین...
هوشمندانه: کدهای فلان پروژه تحت Nulix ورژن 6.2 کمپایل نمی‌شود. من FAQ را خواندهام اما چیزی درمورد مسائل مربوط به Nulix نداشت. در اینجا نسخهای از تلاش کمپایل کردن را آوردهام آیا کاری انجام دادهام؟
پرسشگر این سوال محیط را مشخص کرده است FAQ را خوانده است خطا را نشان داده است. و فرض نمی‌کند که شکل او اشتباه دیگری باشد. این مورد ارزش توجه را دارد.
احمقانه: با مادربورد خود مشکل دارم کسی می‌تواند کمک کند؟
پاسخ هکر J. Randem به این سوال اینست:"درست است. آیا احتیاج دارد آروغ بزنید و پوشکتان عوض شود؟" که با زدن کلید Delete پایان مییابد.
هوشمندانه: روی مادربورد t,y,x,s2464 را امتحان کردم. وقتی کمکی نکرد C,B,A را امتحان کردم. هنگام امتحان C نشانه‌های غیر معمول را یادداشت کردم بهطور مشخص اشکال از برنامهنویسی است اما نتایج طبق انتظار نیست. دلایل معمول ایرادهای مادربوردهای athlon MP کدامند؟ کسی ایدهای برای امتحان بیشتر مادربورد برای حل مشکل موجود دارد؟
از طرف دیگر این فرد ارزش پاسخ را دارد. او هوش حل مسئله خود را نشان داد. نه اینکه منفعلانه منتظر جوابی از بالا باشد.
در سوال آخر دقت کنید به تفاوت زیرکانه ولی مهم بین درخواست کردن"جوابی به من بدهید" و "لطفا به من کمک کنید تا بدانم چه تشخیصهای دیگری میتوانم بدهم تا به آگاهی برسم" در واقع حالت سوال آخر بسیار نزدیک به یک رویداد واقعی که در آگوبیت 2001 در ایمیل لیست (lkml) Linux- kemel اتفاق افتاد بنا شده است. من (اریک) در آن زمان یک سوال پرسیدم. من قفل شدنهای عجیبی در مادربورد S2462 Tyon میدیدم. اعضای لیست اطلاعات ضروری که برای حل به آنها نیاز داشتم که تامین کردند.
به روشی که من سوال را پرسیدم به مردم چیزی را برای چاوش کردن دارم؛ من راه را برای وارد شدن آنها آسان و جذاب کردم. من برای توانایی همسالان خودم احترام قائل شدم و آنها را برای مشورت با من بهعنوان یک دوست دعوت کردم. همچنین برای زمانی که آنها برای نشان دادن روشهای اشتباه به من صرف کردند احترام قائل شدم.
بعد از آن، وقتیکه از همه تشکر کردم و یادآوری کردم که چه خوب فرآیند حل شد، یکی از اعضای lkml مشاهده کرد که این مسئله نه به این خاطر که من یک "اسمی" در لیست داشتم حل شده است، بلکه به اینخاطر که من سول را به روش مناسبی پرسیدم.
هکرها از برخی جهات خیلی ظالماند. من مطمئن هستم که اگر مانند یک انگل رفتار میکردم، به من توهین میشد یا اینکه مرا نادیده میگرفتید بدون توجه به اینکه من چهکسی هستم. پیشنهاد او برای نوشتن کل ماجرا بهعنوان یک دستورالعمل به دیگران مستقیما موجب شد تا این راهنما را بنویسیم.
اگر نتوانستید جوابی بدست آورید:
اگر نتوانستید جوابی بیابید لطفا ناراحت نشوید که ما احساس نمیکنیم که میتوانیم به شما کمک کنیم.گاهی اوقات اعضای گروهی که شما از آنها سوالی پرسیدهاید ممکن است جواب را ندانند ندادن جواب به معنای نادیده گرفتن نیست، اگرچه مسلما تشخیص بین این دو سخت است.
بطور کلی، دوباره فرستادن سوال ایدهی بدی است. این کار آزاردهنده و غیر مودبانه بهنظر می‌رسد. صبر داشته باشید: کسی که جواب شما را میداند ممکن است در منطقه ساعتی جهانی دیگری و در حالت خواب باشد. یا شاید سوال شما به حدکافی خوب شکل نگرفته باشد تا بتوان با آن شروع کرد.
مراجع دیگری برای کمک به شما هستند که اغلب به نیاز تازه واردها بهتر جواب میدهند. گروههای کاربری محلی و آن لاین بسیاری هست که مشتاق نرم‌افزار هستند حتی اگر هیچگاه خودشان نرمافزاری ننوشته باشند. این گروهها معمولا به این دلیل شکل می‌گیرند که بتوانن به یکدیگر و تازه وارد کمک کنند.
همچنین شرکتهای تجاری بسیاری هستند که می‌توانید برای کمک گرفتن با آنها تماس بگیرید، چه بزرگ و چه کوچک(SpikeSource , RedHat دو تا از بهترین آنها هستند، موارد بسیارری دیگری نیز هست). از اینکه باید برای کمک گرفتن، پولی بپردازید مضطرب نشوید! اگر موتور ماشین شما واشر بالایی را بسوزاند، باید بروید به یک تعمیرگاه و برای تعمیر آن پول بپردازید.
حتی اگر نرم‌افزار برای شما هزینهای در بر نداشته باشد، نباید انتظار داشته باشید که پشتیبانی هم همیشه مجانی باشد.
برای نرمافزارهای معروف مانند Linux ، حداقل 10000 کاربر برای هر نمایندگی وجود دارد. برای یک نفر ممکن نیست که تماس 10000 نفر را پشتیبانی کند. یادآوری می‌کنیم که حتی اگر مجبور شوید برای کمک پول بپردازید، هنوز دارید پول کمتری نسبت به آنچه که باید برای خرید نرمافزاری میپرداختید، میپردازید (پشتیبانی برای نرم افزار با منبع بسته معمولا گرانتر و با صلاحیت کمتری نسبت به یک نرم‌افزار با منبع باز است.)
چگونه به سوالات بهطور مفید پاسخ بدهیم:
آرام باشید. سوالهایی که با تنش همراه باشد، باعث می‌شوند افراد احمق و یا گستاخ جلوه کننده حتی اکر اینطور نباشد.
به اولین متخلف بهصورت Off- Line پاسخ دهید. هیچ نیازی به تحقیر کسی که اشتباه صادقانهای را مرتکب شده است،در جمع عمومی نیست یک تازه وارد واقعی شاید نداند که چگونه آرشیو را جستجو کند یا کجا FAQ ذخیره می‌شوند. اگر واقعا نمیدانید، بگویید! یک جواب اشتباه ولی ظاهرا موثق بدتر از اینست که چیزی گفته نشود به کسی به گونهای اشاره نکنید که او تحقیر شود چون فقط می‌خواهید مانند یک فرد ماهر بهنظر بیایید متواضع و صادق باشید، مثال خوبی برای سوال کننده و همتایان خود بزنید.
اگر نمیتوانید کمک کنید، مانع از کمک هم نشوید. روشها را به شوخی نگیرید که ممکن است ساختار کاربر را به شوخی نگیرید که ممکن است ساختاری کاربر را از بین ببرد، یک کاربر ضعیف ممکن است اینها بهعنوان دستورالعمل تلقی کند.
سوالهای کاوش گراند. بپرسید تا جزئیات بیشتری را استخراج کند. اگر در این کار ماهر هستید، سوال کننده چیزی یاد خواهد گرفت و همچنین شما سعی کنید سوال بد را به خوب تبدیل کنید. یادمان باشد که همه ما زمانی تازه وارد بودیم.
در هنگام خواندن RTFM گاهی اوقات خوب است به کسی که تنبل و نامرتب است یک راهنمایی به مستندات بکنیم(حتی اگر یک پیشنهاد برای عبارت کلیدی جستجو در گوگل باشد.)
اگر به دنبال پاسخ دادن به سوال هستید ارزش خوبی به آن بدهید. به کسی که روش یا ابزار اشتباهی را بکار گرفته، برای دور زدن مسئله ندهید. ابزار مناسب را پیشنهاد کنید. سوال را دوباره قالببندی کنید.
به جامعه خود برای یادگرفتن از سوال کمک کنید. وقتی که سوال خوبی دارید، از خودتان بپرسید، "چگونه می‌توان اسناد و FAQ های مرتبط را بهگونهای تغییر داد که دیگر کسی این سوال را دوباره نپرسد؟" سپس یک ضمیمه برای اسناد(به نگهدارنده سایت بفرستید).
اگر برای پاسخ پژوهشی انجام داده‌اید، مهارتهای خود را نشان دهید بهجای اینکه وانمود کنید جواب را از جیب خود درآوردهاید. جواب دادن به یک سوال خوب، مانند غذا دادن به یک فرد گرسنه است اما آموختن روشها و مهارتهای تحقیق توسط مثال به آنها مانند نشان دادن راهی برای کاشتن غذا برای یک عمر است.
1 نظر:
سلام
ممنونم ازت خيلي جالب و كاربردي بود.
دوستان پيشنهاد مي كنم همتون دو قسمت مقاله رو بخونيد...
ارسال یک نظر