چگونه هوشمندانه پرسش کنیم؟

دسته‌بندی: ترجمه‌ی مقالات
بدون دیدگاه

فهرست مطالب

سخنی با خوانندگان

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

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

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

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

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

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

اریک اس. ریموند (به انگلیسی: Eric S. Raymond) برنامه‌نویس، محقق و تاریخ‌نگار فرهنگ هکرهای رایانه‌ای و نویسنده‌ی مقاله کلیسای جامع و بازار می‌باشد. بعد از سال ۱۹۹۷(میلادی) به نوعی به یک پیش‌تاز در دنیای نرم‌افزار متن‌باز تبدیل‌شد و رهبری و هدایت این جامعه را به عهده‌گرفت. امروزه به عنوان یک شخصیت بحث‌برانگیز و ستیزگر شناخته‌می‌شود. تلاش‌های او آنچنان که اندکی از آنها در این نوشته آورده‌شده‌است، آقای ریموند را به جامعه‌ی متن‌باز و نرم‌افزار متن‌باز شناسانده‌است. جامعه‌ای که سهم زیادی در تشکیل آن داشته‌است. او را به عنوان پدر جامعه بازمتن می‌شناسند.[۱]

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

مقدمه

در دنیای هکرها[۲]، نوع پاسخ‌هایی که از پرسش‌های فنی خود می‌گیرید، همان اندازه که به پیچیدگی پاسخ بستگی دارد به نحوه‌ی مطرح کردنِ پرسش شما هم بستگی دارد. این راهنما به شما می‌آموزد که چگونه پرسش خود را مطرح کنید تا احتمالِ بیشتری برای دریافتِ پاسخی درخور داشته باشد.

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

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

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

بدون رودربایستی، رفتار خصمانه‌ی ما با کسانی است که به نظر می‌رسد تمایلی به تفکر یا انجام وظایف خود قبل از مطرح کردن پرسش ندارند. آدم‌های این‌چنینی وقت‌گیر و خورنده هستند، آنها می‌گیرند بدون اینکه چیزی پس بدهند و وقتی را که می‌توان صرف پرسش‌های جذاب‌تر و آدم‌های باارزش‌تر کرد تلف می‌کنند. ما چنین آدم‌هایی را بازنده”loser” یا به شکل از قدیم جاافتاده‌ی آن “luser” می‌نامیم.

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

عموما همه‌ی ما داوطلبانه کار می‌کنیم. زمانی از زندگیِ پرمشغله را برای پاسخ‌گویی در نظر می‌گیریم. بنابراین بی‌رحمانه فیلتر می‌کنیم. در عمل پرسش‌هایی که از سوی بازنده‌ها مطرح می‌شوند را کنار می‌گذاریم تا زمان برای رسیدگی به افراد برنده “winner” باشد.

اگر شما این نگرش را نفرت‌انگیز می‎دانید، رک و رو راست پیش‌فرض‌های‌تان را بازبینی کنید. ما از شما نمی‎خواهیم تا به نظر ما کرنش کنید. در حقیقت اگر شما به اندازه‌ی کافی انرژی بگذارید، اکثر ما دوست داریم تا با همه‌ی شما به مساوات برخورد کنیم و برای ورود شما به دنیای خودمان خوش‌آمد بگوییم. اما کمک‌کردن به کسانی که حاضر به کمک به خود نیستند، برای ما بهینه و خوش‌آیند نیست. مشکلی در نداستن(نادانی) نیست، اما احمقانه نباید عمل کرد.

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

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


[۱] برگرفته از صفحه‌ی ویکی‌پدیا

[۲]  در این متن، هکر”Hacker” معادل فرد با تجربه و متخصص در یک حوزه‌ی تکنولوژی است

قبل از پرسش

قبل از مطرح کردن پرسشِ فنی از طریق ایمیل، گروه‌های مجازی، انجمن‌ و یا وب‌سایت‌ها موارد زیر را انجام دهید:

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

  • تلاش کنید پاسخ را با جستجو در اینترنت پیدا کنید.

  • تلاش کنید پاسخ را با خواندن دیتاشیت یا دستورالعمل‌ها پیدا کنید.

  • تلاش کنید پاسخ را با خواندن بخش پرسش‌های متداول”FAQ” پیدا کنید.

  • تلاش کنید پاسخ را با آزمایش یا بازبینی پیدا کنید.

  • تلاش کنید پاسخ را با پرسش از یک دوست متخصص پیدا کنید.

  • اگر شما یک برنامه‌نویس هستید، تلاش کنید پاسخ را با خواندن کدها “source code”پیدا کنید.

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

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

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

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

در مورد مطرح کردن پرسش اشتباه هوشیار باشید. اگر شما پرسشی با مفروضات اشتباه مطرح کنید، [J. Random Hacker[1 با امید به آن‌که تجربه‌ی دریافت پاسخ چیزی که پرسیده‌اید به جای چیزی که نیاز داشته‌اید درسی به شما بدهد، پاسخی با ادبیات بدردنخور در حالی‌که تصور می‌کند با یک پرسش احمقانه برخوردکرده‌است می‌دهد.

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

از طرف دیگر، روشن‌کردن این‌که شما توان و رغبت مشارکت در پیش‌برد راه‌حل را دارید، نقطه شروع بسیار مناسبی است. نمونه پرسش‌هایی چون “کسی میتونه اشاره‌ای بکنه؟” یا “نمونه کدِ من چه چیزی کم دارد؟” یا “چه وب‌سایتی را من باید بررسی کنم؟” احتمالا با پاسخ همراه خواهدبود اما نمونه‌هایی چون ” لطفا روند دقیق کاری که من باید انجام دهم را ارسال کنید” پاسخی به دنبال ندارند. چراکه در نمونه‌های اول شما صادقانه اذعان می‌کنید که با راهنمایی به مسیر درست توسط شخص دیگر، تمایل به تکمیل روند حل مساله دارید.

زمانی‌که پرسش می‌کنید

انجمن(forum) مورد نظر را با دقت انتخاب کنید.

به جایی‌ که پرسش‌تان را مطرح می‌کنید حساس باشید. در یکی از حالت‌های زیر شما نادیده گرفته‌می‌شوید یا به عنوان بازنده “luser” شناخته‌می‌شوید اگر:

  • در انجمن یا گروه بی‌ربط پرسش‌تان را مطرح کنید.

  • پرسش‌های ابتدایی در انجمنی ارسال کنید که مطالب فنی سطح بالا مطرح می‌شود و یا برعکس.

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

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

هکرها(افراد متخصص) پرسش‌های بی‌ربط را حذف می‌کنند تا از کانال‌های ارتباطی‌شان در مقابل اشباع شدن با هرزنوشته‌ها محافظت کنند. شما حتما نمی‌خواهید این اتفاق برایتان بیافتد.

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

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

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

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

بدانید که موضوع بحث شما چیست! یک ایراد مرسوم این است که مثلا سوالی را در مورد واسط برنامه‌نویسی windows یا unix در گروهی که برای زبان، کتابخانه یا ابزاری که قابل انتقال بین هر دو پلتفورم است مطرح کنید. تا زمانی‌که درک نکردید که این چه اشتباه بزرگی است، بهتر است پرسش‌تان را کلا مطرح نکنید.

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

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

اقبال بیشتری برای داشتن پاسخ کارآمد

STACK OVERFLOW

جستجو کنید، سپس در Stack Exchange پرسش را مطرح کنید.

در سال‌های اخیر، انجمن‌های STACK EXCHANGE به عنوان اصلی‌ترین مرجع پاسخ‌گویی به پرسش‌های فنی و غیره حتی در بسیاری از پروژهای متن‌باز ظهورکرده‌است.

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

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

Stack Exchange بیش از صد وب‌سایت دارد، اما در این‌جا بهترین موارد آن معرفی می‌شوند:

  • Super user برای پرسش‌های عمومی است. اگر پرسش شما در مورد برنامه یا کد خاصی نیست، احتمالا به این قسمت مربوط می‌شود.

  • Stack Overflow برای پرسش در مورد برنامه‌نویسی است.

  • server fault برای پرسش در مورد سرور و مدیریت شبکه است.

بسیاری پروژه ها مثل android، ubuntu، tex/latex وب‌سایت‌های ویژه‌ی خود را دارند. صفحه‌ی stack exchange site را برای مشاهده‌ی لیست بروز مشاهده کنید.

انجمن‌های تحت وب و [IRC[2

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

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

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

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

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

قدم دوم، استفاده از لیست ایمیل تیم پروژه

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

  • یک پرسش به‌جا به همان اندازه که برای یکی از برنامه‌نویسان پروژه می‌توانند مهم باشد، برای دیگر برنامه‌نویسان پروژه هم می‌تواند باشد. در ضمن اگر شک دارید که پرسش‌تان برای ارسال به لیست ایمیل مناسب نیست، هیچ عذری پذیرفته نیست که وقت یک برنامه‌نویس از پروژه را با آن بگیرید و باعث اذیت شوید.

  • ارسال پرسش به لیست ایمیل زحمت اعضای یک پروژه را زیاد می‌کند. یک برنامه‌نویس مشخص از آن تیم(علی الخصوص اگر مدیر تیم باشد) مشغله‌ی زیادی دارد که ممکن است فرصت برای پاسخ به شما نداشته‌باشد.

  • بیشتر لیست ایمیل‌ها آرشیو می‌شوند و این آرشیوها توسط موتورهای جستجو index می‌شوند، لذا در آینده فرد دیگری می‌تواند به جای پرسش دوباره‌ی آن با جستجو به “پرسش و پاسخ” دسترسی پیداکند.

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

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

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

فرصت طلایی برای جلب توجه افراد متخصص استفاده از عنوان مناسب در ۵۰ کاراکتر یا کمتر است. با حرف‌های بیهوده مثل “لطفا کمک کنید” این فرصت را ازدست‌‌ندهید(پیام‌هایی با عنوانی که فقط شامل “لطفا کمک کنید” باشند، طردمی‌شوند). برای متاثرکردن ما با عمق اضطراب‌تان تلاش نکنید و به جای آن از عنوان مناسب برای توضیح بسیار مختصر از مشکل استفاده‌کنید.

یک مدل قراردادیِ مناسب که توسط بسیاری از تشکل‌های پشتیبانی فنی استفاده‌می‌شود، ترکیب “موضوع-مشکل” برای ترکیب‌بندی عنوان است. تکه‌ی “موضوع” شامل چیزهایی است که خطا در آن‌ها رخ‌داده‌است و تکه‌ی “مشکل” توضیح مختصری از رفتار غیرعادی آن بخش‌ها است.

احمق:

کمک! ویدیو در لپ‌تاپ من درست اجرانمی‌شود!

باهوش:

برنامه X ورژن Y مکان‌نمای موس را بهم‌می‌ریزد، firmware چیپ‌ست گرافیگی Z است.

باهوش‌تر:

برنامه X ورژن Y و firmware گرافیکی Z – مکان‌نمای موس بهم‌می‌ریزد

روند نوشتن توضیحات به شکل “موضوع-مشکل” به شما کمک‌می‌کند تا فکرکردن در مورد مشکل را با جزییات بیشتری نظم‌دهید. روی چه چیزی تاثیرمی‌گذارد؟ فقط روی مکان‌نمای موس یا روی چیپ‌ست گرافیک هم تاثیرمی‌گذارد؟ آیا این مورد فقط به این ورژن از برنامه مربوط می‌شود؟ آیا این مورد فقط به این ورژن از فرم‌ور چیپ‌ست مربوط‌می‌شود؟ فرد متخصصی که این نتایج را می‌بیند، در یگ نگاه متوجه مشکلی که با آن مواجه هستید می‌شود.

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

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

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

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

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

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

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

بدون غلط املایی و گرامری و همچنین شفاف بنویسید

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

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

دیکته، نقطه‌گذاری و نکات گرامری رعایت شود. در غیر اینصورت بی‌ادبانه تلقی‌می‌شود.

به‌طورکلی اگر شبیه آدم کم‌سواد بنویسید، احتمالا در نظر گرفته‌نمی‌شوید. از فرم شکسته کلمات مثل “سلم” به جای “سلام” فقط برای مقداری کمتر فشردن دکمه‎های صفحه کلید، استفاده نکنید. در غیر این‌صورت احتمالا با سکوت سنگین کاربران یا تمسخر آن‌ها روبرو می‌شوید.

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

اگر به زبان انگلیسی پرسش را مطرح‌می‌کنید و انگلیسی زبان دوم شماست، بهتر آن است که پاسخ‌دهندگان را از مشکلات احتمالی در نگارش‌تان آگاه‌کنید. گزینه‌هایی برای این مورد:

  • انگلیسی زبان اصلی من نیست. بابت اشتباهات نگراشی عذرمی‎‌خواهم.

  • اگر زبان x را می‌دانید، لطفا پیام دهید. برای ترجمه پرسشم نیاز به کمک دارم.

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

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

پرسش‌ را در قالب استاندارد و مشخص ارسال‌کنید

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

  • پرسش را در قالب فایل متنی ساده ارسال کنید.

  • اضافه کردن فایل‌های پیوست به شرطی که محتوای واقعی داشته‌باشند و تکرار واضحات نباشند، مشکلی ندارد.

  • ایمیل را در قالب متن یک‌پارچه‌ی wrapped شده ارسال نکنید. این مساله ارسال پاسخ برای یک تکه از متن را دشوارمی‌کند. نوشته را در قالب یک متن با طول ۸۰ کاراکتر در هر خط یا کمتر ارسال کنید.

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

  • [به متن اصلی مراجعه شود]

  • هرگز، هرگز انتظار نداشته‌باشید که هکرها بتوانند قالب‌های بسته‌ی اختصاصی اسناد مانند Microsoft Word یا Excel را بخوانند. اکثر هکرها نسبت به این موارد واکنش نشان می‌دهند. مثل این است که شما انبوهی از فضولات بخارداده‌شده‌ی خوکی را در متن خود بپاشید. حتی وقتی امکان باز کردن این فایل‌ها را داشته‌باشند، از انجام این کار منزجر و ناراحت می‌شوند.

  • [به متن اصلی مراجعه شود]

  • در انجمن‌ها، از ابزارهای “شکلک‌گذاری” و “HTML” بیش از حد استفاده نکنید(اگر وجود دارند). یک یا دو شکلک معمولاً خوب است، اما متن فانتزی رنگی باعث می‌شود دیگران فکر کنند شما کودن یا خیره‌سر هستید. استفاده بیش از حد از شکلک‌ها و رنگ و فونت باعث می‌شود شما مثل یک دختر نوجوان مسخره به نظر بیایید، که به طور کلی ایده‌ی خوبی نیست مگر اینکه بیشتر از پاسخ به دنبال سکس و لاس‌زدن باشید.

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

در مورد مشکل‌تان دقیق و مطلع باشید

  • علایم و نشانه‌های مشکل‌تان و نیز باگ‌ها را با دقت و شفاف توضیح‌دهید.

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

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

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

  • تغییرات احتمالیِ مرتبطی را تشریح‌کنید که در سخت‌افزار و نرم‌افزار اعمال‌کرده‌اید.

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

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

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

آقای simon tatham مقاله‌ای با عنوان “چگونه به شکل موثر یک باگ را گزارش‌دهیم” نوشته‌است که قویا خواندن آن را توصیه‌می‌کنم.

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

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

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

عجله برای اعلام ادعای یافتن یک باگ نکنید

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

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

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

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

تنبلی جایگزین خوبی برای انجام وظایف نیست

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

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

بعضی انجمن‌ها بخش جداگانه‌ای برای پرسش تازه‌کاران دارند. اگر احساس می‌کنید پرسش مبتدی دارید، به این بخش مراجعه کنید. اما حتی در آن‌جا هم تنبلی‌نکنید.

به جای حدسیات خود، علایم و نشانه‌های مشکل را تشریح‌کنید

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

احمق:

من خطاهای پی‌درپی موقع کامپایل SIG11 دریافت‌می‌کنم و حدس‌می‌زنم که تَرکی به اندازه‌ی موی سر روی مسیرهای مادربورد وجود دارد. بهترین راه برای بررسی آن چیست؟

باهوش:

کامپیوتر k6/233 دست‌ساز من با مادربورد fic-pa2007 (با چیپ‌ست apollo vp2) و با حافظه‌ی sdram مدل corsair pc133 بعد از سپری‌شدن حدود ۲۰ دقیقه از روشن‌شدن در طول کامپایل هسته، خطاهای مکرر sig11 می‌دهد. در‌حالی‌که در ۲۰ دقیقه اول خطایی رخ‌نمی‌دهد. ریست‌کردن ساعت را ریست‌نمی‌کند اما خاموش‌کردن در طول شب ساعت را هم ریست‌می‌کند. تعویض کل حافظه‌ی ram تغییری ایجادنکرد. فایل log بخش مربوط به کامپایل در ادامه می‌آید.

ازآنجاکه به نظر می‌رسد نکته قبلی برای بسیاری از افراد درک دشواری دارد، در این‌جا عبارتی آورده شده‌است که به شما یادآوری می‌کند: “همه‌ی متخصصان از میسوری آمریکا هستند”. شعار رسمی این ایالت “به من نشان بده” است.( این شعار از آن‌جا آمده‌است که نماینده‌ی کنگره، ویلارد دی وندیور در سال ۱۸۹۹ گفت:” من از منطقه‌ای می‌آیم که ذرت، پنبه، کاسنی و دموکرات‌ها را پرورش‌می‌دهد، سخنوریِ بی‌سروته نه مرا متقاعد و نه راضی می‌کند. من از میسوری هستم. شما باید به من نشان‌دهید.”. در مورد متخصصان و تشخیص‌دهندگان مشکل، این مساله‌ی شک و تردید نیست، بلکه یک نیاز اساسی و کاربردی است تا به جای حدس و جمع‌بندی‌های شما آنچه را که واقعا وجود دارد و به همان وضوحی که شما بر اساس شواهد خام مشاهده می‌کنید، ببینند. پس به ما نشان‌دهید.

علایم و نشانه‌های مشکل را به ترتیب وقوع تشریح‌کنید

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

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

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

هدف را توصیف‌کنید نه مراحل

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

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

احمق:

چگونه باید از color-picker در برنامه‌ی x-draw استفاده کنم تا مقدار کد rgb را داشته باشم؟

باهوش:

من می‌خواهم مقادیر جدول رنگ یک عکس را با مقادیر دلخواه جایگزین کنم. در حال حاضر تنها راهی که برای آن می‌شناسم از طریق ویرایش جدول رنگ یک تکه از عکس است، اما نمی‌توانم با ابزار color picker مقدار کد rgb را داشته‌باشم.

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

از دیگران نخواهید تا با ایمیل شخصی یا از طریق کانال‌های خصوصی پاسخ‌دهند

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

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

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

پرسش را صریح و شفاف بیان‌کنید

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

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

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

بنابراین شکل‌دهی مناسب به پرسش برای کمترکردن زمان مورد نیاز برای پاسخ‌دادن از سوی فرد متخصص مثمرثمر خواهدبود. اما غالبا این مساله با ساده‌سازی پرسش یکی نیست. بنابراین به عنوان مثال “امکان‌دارد لینکی برای یک توضیح مناسب درباره‌ی x بدهید؟” هوشمندانه‌تر از “امکان‌دارد x را توضیح‌دهید؟” است. اگر شما کدی دارید که به درستی کارنمی‌کند، معمولا هوشمندانه‌تر آن است که به جای درخواست اصلاح کُد، توضیحی درباره‌ی ایراد احتمالی در کُد بخواهید.

زمانی‌که در مورد یک دسته “کد” پرسش‌می‌کنید

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

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

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

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

 

تکالیف‌ و پرسش‌های درسی را مطرح‌نکنید

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

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

درخواست‌های بی‌معنی را حذف‌کنید

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

پرسش‌ را با عناوینی چون “فوری” برچسب‌نرنید، حتی اگر برای خود شما این‌گونه باشد

این مشکل شما است نه ما. بیان‌کردن قید فوری احتمالا نتیجه‌ی معکوس می‌دهد: اکثر هکرها از این‌گونه پیام‌ها به عنوان تلاش‌های گستاخانه و خودخواهانه که قصد جلب توجه ویژه و فوری دارند چشم‌پوشی‌می‌کنند. علاوه بر آن، واژه‌ی “فوری”(و شکل‌های شبیه آن در عنوان درخواست برای جلب توجه) غالبا توسط ابزارهای استفاده‌شده در گروه‌ها فیلتر می‌شوند و مخاطبان مورد نظر شما اصلا پیام شما را نخواهنددید.

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

استفاده از این مورد بسیار پرمخاطره است، چراکه معیار جذابیت نسبت به یک موضوع بین شما و هکرها احتمالا متفاوت است. به عنوان مثال برای ایجاد انگیزه، ارسال یک مطلب از “ایستگاه بین‌المللی فضایی” کافی است، اما به قصد یک انگیزه‌ی سیاسی یا خیرخواهانه قطع به یقین کافی نیست. در واقع ارسال پستی با عنوان “فوری: برای نجات بچه فُک‌های چنگی کمک کنید!” احتمال قریب به یقین از همه طرف حتی از سوی هکرهایی که فکرمی‌کنند بچه فُک‌های چنگی مهم هستند هم، طردخواهدشد.

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

ادب هیچ‌گاه ضرر ندارد، گاها تاثیر مثبت هم دارد

مودب باشید. از جملاتی چون “لطفا”، “از توجه شما سپاس‌گزارم”، “از ملاحظه‌ی شما سپاس‌گزارم” استفاده کنید. این مطلب را به وضوح بیان‌کنید که شما قدردان زمانی که دیگران بدون چشم‌داشت برای کمک به شما می‌گذارند، هستید.

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

به‌هرحال، اگر همه ملاحظات فنی را در درخواست‌تان لحاظ کرده‌باشید، آن‌گاه به کاربستن ادب و احترام شانس شما را برای دریافت پاسخ مناسب بیشتر می‌کند.

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

بعد از رسیدن به راه‎حل، مطلب کوتاهی در مورد آن ارسال‌کنید

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

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

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

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

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

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

تصورکنید که چگونه می‌توانید از اشتباه دیگران در مساله‌ای مشابه جلوگیری‌کنید. از خودتان سوال‌کنید که آیا یک پیوست برای مستندات یا بخش faq کمک خواهدکرد؟ اگر جواب مثبت بود، آن پیوست را آماده‌کنید و برای تیم پشتیبانی محصول ارسال‌کنید.

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

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

[RTFM[3 و [STFW[4 : چگونه به شما بگوییم که پیچانده‌اید؟ (تنبلی‌کرده‌اید)

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

RTFM یک فامیل جوان‌تر هم دارد. : اگر پاسخی دریافت‌کردید که STFW خوانده‌می‌شد، کسی که این پاسخ را ارسال‌کرده‌است تصور می‌کند که شما باید در آن اینترنت لعنتی جستجوکنید. قریب به یقین او درست می‌گوید. بروید و جستجوکنید.(یک ورژن خفیف‌تر آن این است که به شما بگویند “گوگل دوست شما است!”)

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

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

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

اگر شما پاسخ را نفهمیدید…

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

به عنوان مثال فرض‌کنید من به شما می‌گویم: “به نظر می‌رسد شما یک stuck zenty دارید، باید آن را پاک کنید.”. این یک نمونه پستی است که می‌تواند در ادامه بیاید: “zentry چیست؟” و این‌جا یک نمونه مناسب برای پستی است که می‌تواند در ادامه بیاید: “باشه، من در وب‌سایت شخصی خواندم که zentryها فقط در زیر سوییچ‌های z و s اشاره‌شده‌اند. هیچ‌کدام از آن‌ها چیزی درباره‌ی پاک‌کردن zentry ها نگفته‌اند. آیا یکی از این موارد است یا من در این‌جا چیزی را از قلم انداخته‌ام؟”

نوع برخورد با خشونت و سفتی(یا بی‌ادبی) در کلام هکرها

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

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

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

(برخی از افراد ادعامی‌کنند که بسیاری از هکرها نوع خفیفِ اوتیسم یا سندرم آسپرگر دارند و در واقع بعضی از مدارهای مغزی را که تعاملات اجتماعی “طبیعی” انسان را تنظیم می‌کند، ندارند. این مطلب ممکن‌است درست یا غلط باشد. اگر شما خودتان هکر نیستید و فکرمی‌کنید که مغز ما معیوب است، توجه به این مطلب به شما کمک‌می‌کند تا با رفتارهای غیرعادی ما برخورد مناسب داشته‌باشید. برای ما فرقی نمی‌کند. ما دوست داریم چیزی باشیم که هستیم و به طورکلی در مورد برچسب‌ها و اسم‌گذاری‌های بالینی تردید داریم.)

مشاهدات آقای جف بیگلر درباره‌ی tact filter مربوط به این موضوع است که ارزش مطالعه دارد.

در بخش بعدی، ما در مورد یک موضوع متفاوت صحبت‌خواهیم‌کرد. نوعی از “بی‌ادبی”، که هنگام رفتار نادرست خواهیددید.


[۱] J. Random Hacker در ادبیات برنامه‌نویسی یک نام مستعار است.

[۲]  گپ رله‌ی اینترنتی

[۳] Read The Fucking Manual  : دستورالعمل لعنتی را بخوان

[۴]  Search The Fucking Web : در اینترنت لعنتی جستجوکن

[۵]  تبادل طولانی پیام‌های توهین‌آمیز بین کاربران یک انجمن آنلاین یا سایر حوزه‌های گفتگو.

درباره‌ی واکنش نشان ندادن شبیه یک بازنده”luser”

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

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

بی‌خیال این موضوع شوید. کاملا طبیعی است. در حقیقت هیچ مشکلی نیست.

قواعد و قوانین یک انجمن به خودی خود حفظ‌نمی‌شوند. آن‌ها با مورد استفاده‌ قرارگرفتن توسط افراد، واضحا به شکل عمومی، حفظ و مراعات می‌شوند. ناله و شکایت نکنید که همه‌ی انتقادها باید از طریق کانال‌ و ایمیل‌های خصوصی منتقل‌شوند. این راه مثمرِثمر نخواهندبود. همچنین اصرارکردن به اینکه شما با ابراز مخالفت کسی با نظر و ادعایتان مورد توهین واقع‌شده‌اید مفید نخواهدبود. این‌ها ویژگی افراد بازنده “loser” است.

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

“انجمن دوستانه و دورهمی” یا “انجمن کاربردی”، یکی را انتخاب‌کنید.

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

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

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

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

پرسش‎های که پاسخ داده‎نمی‌شوند

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

پ: کجا می‌توانم فلان برنامه یا سورس کد را پیداکنم؟

پ: چگونه می‌توانم از x برای انجام y استفاده‌کنم؟

پ: چگونه می‌توانم خط فرمان را پیکربندی‌کنم؟

پ: آیا می‌توان فرمت x را به y با استفاده از z تبدیل‌کنم؟

پ: فلان برنامه‌ی من کارنمی‌کند.

پ: با ویندوزم مشکل دارم. کسی می‌تواند کمک‌کند؟

پ: برنامه‌ام کارنمی‌کند. فکرمی‌کنم مشکل از بخش x است.

پ: با نصب برنامه‌ی x مشکل دارم. کسی می‌تواند کمک‌کند؟

پ: چگونه می‌توانم فلان کانال ارتباطی فردی را هک‌کنم تا به ایمیل‌هایش دسترسی داشته‌باشم؟

پ: کجا می‌توانم فلان برنامه یا سورس کد را پیداکنم؟

ج: از همان جایی که من پیداکردم، احمق. در انتهای دیگرِ جستجو در اینترنت. یا خدا! آیا هنوز همه نمی‌دانند چگونه از گوگل استفاده‌کنند؟

پ: چگونه می‌توانم از x برای انجام y استفاده‌کنم؟

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

پ: چگونه می‌توانم خط فرمان را پیکربندی‌کنم؟

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

پ: آیا می‌توان فرمت x را به y با استفاده از z تبدیل‌کنم؟

ج: امتحان‌کنید و نتیجه را ببینید. اگر انجام‌دادید، شما الف) پاسخ را یافته‌بودید، ب) وقت من را تلف‌نمی‌کردید.

پ: فلان برنامه‌ی من کارنمی‌کند.

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

  • آیا شما اطلاعات بیشتری می‌توانید اضافه‌کنید؟

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

  • این دقیقا چه ارتباطی به من دارد؟

پ: با ویندوزم مشکل دارم. کسی می‌تواند کمک‌کند؟

ج: بله، مایکروسافت را به سطل آشغال بیانداز و یک سیستم‌عامل متن‌باز مثل لینوکس یا bsd نصب‌کن.

پ: برنامه‌ام کار نمی‌کند. فکرمی‌کنم مشکل از بخش x است.

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

پ: با نصب برنامه‌ی x مشکل دارم. کسی می‌تواند کمک‌کند؟

ج: برای اشکال‌یابی نیاز به دسترسی عملی به دستگاه شما دارم. از گروه محلی خودتان کمک حضوری درخواست‌کنید.

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

پ: چگونه می‌توانم فلان کانال ارتباطی فردی را هک‌کنم تا به ایمیل‌هایش دسترسی داشته‌باشم؟

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

پرسش‌های خوب و بد

سرانجام من با مثال می‌خوام نشان بدهم که چگونه هوشمندانه پرسش‌کنیم. دو نمونه در مورد یک مشکل، یکی احمقانه و دیگری هوشمندانه.

احمقانه: از کجا می‌توانم اطلاعاتی درباره Foonly Flurbamatic پیداکنم؟

           این پرسش فقط “STFW” را به عنوان پاسخ می‌طلبد.

هوشمندانه: من از گوگل برای بدست‌آوردن اطلاعات درباره‌ی ” Foonly Flurbamatic 2600″ استفاده‌کردم اما چیزی نیافتم. آیا می‌توانم لینکی در مورد برنامه‌نویسی روی این دستگاه داشته‌باشم؟

           این فرد قبلا “STFW” کرده‌است، و به نظر مشکلی جدی و واقعی وجود دارد.

احمقانه: من نمی‌توانم کد پروژه foo را کامپایل کنم. چرا خراب است؟

           پرسش‌کننده تصورمی‌کند شخص دیگری خراب‌کاری کرده‌است. متکبر مغرور…

هوشمندانه: کدی که از پروژه foo دریافت‌کرده‌ام تحت Nulix نسخه ۶.۲ کامپایل‌نمی‌شود. من بخش سوالات متداول را خوانده‌ام ، اما در مورد مشکلات مربوط به Nulix چیزی در آن وجود ندارد. در این‌جا متن گزارش کامپایل را آورده‌ام. آیا این کاری است که من باید انجام‌می‌دادم؟

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

احمقانه: مادربورد من مشکل دارد، کسی می‌تواند کمک‌کند؟

پاسخ J. Random Hacker احتمالا این باشد: “خوب، به پوشک و آروغ زدن هم نیاز دارید؟” و در ادامه چندین بار زدن دکمه‌ی delete…

هوشمندانه: منX ، Y و Z را روی مادربرد S2464 امتحان‌کردم. وقتی این کار جواب نداد، منA ، B و C را امتحان‌کردم. به شواهد جالب وقتی که من C را امتحان‌کردم توجه‌کنید. بدیهی است که florbish به شکل grommicking است، اما نتایج آن چیزی نیست که انتظارمی‌رود. دلایل معمول grommicking در مادربردهای Athlon MP چیست؟ کسی ایده‌ای برای آزمایش‌های بیشتر دارد که بتوانم برای مشخص‌کردن مشکل انجام‌دهم؟

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

در آخرین پرسش به تفاوت نامحسوس اما مهم بین درخواست “به من یک پاسخ بدهید” و “لطفا به من کمک کنید تا بدانم که چه روش‌های تشخیصی دیگری را می‌توانم برای روشن‌شدن مساله به‌کار ببندم” توجه‌کنید.

در واقع شکل آخرین پرسش بسیار شبیه مورد واقعی بود که در آگوست ۲۰۰۱ در لیست ایمیل‌های کرنل لینوکس اتفاق‌افتاد. من(اریک) کسی بودم که در آن موقع پرسش را مطرح‌کردم. یک مورد عجیب هنگ‌کردن در مادربورد tyan s2462 مشاهده‌می‌کردم. اعضای لیست ایمیل اطلاعات مهمی را که من برای حل مشکل نیازداشتم، فراهم‌کردند.

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

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

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

اگر نتوانستید پاسخی بگیرید…

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

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

منابع دیگری برای کمک به شما وجود دارد که می‌توانید به آنها مراجعه‌کنید، غالباً منابعی که با نیازهای تازه‌کارها سازگارتر هستند.

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

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

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

چگونگی پاسخ دادنِ مفید به پرسش‌ها

ملایم و آرام باشید. استرس مربوط به مشکل حتی باعث‌می‌شود افراد بی‌ادب یا احمق به نظربرسند.

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

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

اگر نمی‌توانید کمک کنید، مانع‌نشوید. در مورد رویه‌هایی که می‌تواند تنظیمات کاربر را حذف‌کند شوخی نکنید – افراد ساده‌انگار ممکن است این موارد را به عنوان دستورالعمل تفسیر کنند.

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

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

اگر می‌خواهید به پرسشی پاسخ دهید، چیز با ارزشی ارائه دهید. وقتی کسی از ابزار یا روش غلطی استفاده‎می‌کند راه‌حل‌های موقتی و غیراصولی(kludgy) پیشنهادنکنید. ابزارهای خوب را پیشنهاددهید. پرسش را دوباره بهتر تنظیم‌کنید.

پرسش واقعی را پاسخ‌دهید! اگر پرسش‌کننده آن‌قدر دقیق بود که تحقیقات خود را انجام‌داده و در درخواست خود این مورد را گنجانده که موارد x,y,z,a,b و c را بدون نتیجه‌ی مطلوب آزمایش‌کرده‌است، فوق‌العاده بی‌فایده است که با گفتن “مورد a یا b را آزمایش‌کن” یا ارسال لینکی که در آن گفته‌شده مورد x,y,z,a,b یا c را آزمایش کنید پاسخ داده‌شود.

به انجمن کمک‌کنید تا از این پرسش‌ها بیاموزد. وقتی کسی پرسش خوبی را مطرح‌کرد، از خود بپرسید “چگونه مستندات یا بخش سوالات متداول مربوطه باید تغییرکند تا کسی مجبور نباشد دوباره به این پرسش پاسخ‌دهد؟” سپس یک پیوست یا متمم آماده و برای تیم پشتیبانی ارسال‌کنید.

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

منابع مرتبط

اگر شما به راهنمایی درباره‌ی اصول کار کامپیوترهای شخصی، یونیکس و اینترنت نیاز دارید، به The Unix and Internet Fundamentals HOWTO مراجعه‌کنید.

هنگام انتشار نرم‌افزار یا نوشتن مکمل نرم‌افزار(patch)، سعی‌کنید از دستورالعمل‌های Software Release Practice HOWTO پیروی‌کنید.

تقدیر و تشکر

Evelyn Mitchell چند نمونه از پرسش‌های احمقانه را ارائه‌داد و نوشتن بخش “چگونگی پاسخ‌دادن مفید به پرسش” را الهام بخشید. Mikhail Ramendik پیشنهادهای ارزشمندی برای بهبود متن ارائه‌داد.

  • نویسنده
    صابر یوسفی
  • تعداد بازدید
    53 بازدید
۰دیدگاه فرستاده شده است.
شما هم دیدگاه خود را بنویسید