راهنمای تعامل و پرسش‌وپاسخ در کامیونیتی‌های فنی
نسخه ۱.۰ — راهنمای عملی برای گروه‌ها، انجمن‌ها و فضاهای گفتگو در حوزه فناوری اطلاعات
مقدمه
کامیونیتی‌های فنی بر پایهٔ اشتراک دانش و وقتِ داوطلبانهٔ اعضا شکل می‌گیرند. در یک گروه برنامه‌نویسی، لینوکسی یا مهندسی، زمان و تمرکز افراد ارزشمندترین دارایی جمع است. رعایت چند اصل ساده در نحوهٔ مطرح کردن سؤالات، اشتراک‌گذاری کدها و برخورد با یکدیگر، نه‌تنها شانس دریافت پاسخ دقیق و سریع را چند برابر می‌کند، بلکه محیطی سالم، حرفه‌ای و عاری از هیاهو برای همه می‌سازد.
این سند، چکیدهٔ مهم‌ترین استانداردهای جهانی در فرهنگ کامیونیتی‌های نرم‌افزاری است که به ترتیبِ مراحل تعامل (از لحظهٔ برخورد با مشکل تا زمان حل شدن آن و مشارکت در بحث‌ها) تنظیم شده است.
۱. پیش از پرسیدن سؤال
۱-۱. جستجو و تلاش اولیه
پیش از مطرح کردن هر سؤال، مطمئن شوید که متن خطا را در موتورهای جستجو و تاریخچهٔ همان گروه جستجو کرده‌اید و مستندات رسمی ابزار مربوطه را خوانده‌اید. جامعهٔ فنی به کسانی که نشان می‌دهند پیش از پرسش، خودشان برای یافتن پاسخ تلاش کرده‌اند، با اشتیاق بیشتری کمک می‌کند. در این باره، مطالعهٔ مقالهٔ کلاسیک چگونه هوشمندانه سؤال بپرسیم و راهنمای پرسش در Stack Overflow دید بسیار خوبی به شما می‌دهد.
۱-۲. دیباگ اردک پلاستیکی (Rubber Duck Debugging)
قبل از ارسال پیام در گروه، یک بار مشکل و کد خود را خط‌به‌خط و با صدای بلند برای یک شیء بی‌جان روی میزتان (مثل یک اردک پلاستیکی) یا در یک فایل متنی پیش‌نویس توضیح دهید. در بسیاری از مواقع، همین تلاش برای صورت‌بندی منطقی مسئله و توضیح دادن آن از صفر، باعث می‌شود خودتان متوجه نقطهٔ خطا شوید. (بیشتر بخوانید)
۲. آداب ارسال پیام و آغاز گفتگو
۲-۱. «سلام»ِ خالی نفرستید (No Hello)
در ارتباطات متنی، فرستادن یک «سلام» یا «سلام، وقت بخیر» و منتظر ماندن تا طرف مقابل جواب دهد و بعد سؤال خود را بپرسید، باعث وقفه و اتلاف وقت هر دو طرف می‌شود. سلام و احوال‌پرسی را در همان پیام اول و در کنارِ اصلِ مطلب بنویسید. (بیشتر بخوانید)
۲-۲. برای پرسیدن سؤال اجازه نگیرید (Don't Ask to Ask)
پرسیدن جملاتی مانند «کسی اینجا با داکر کار کرده؟» یا «یه سؤال لینوکسی داشتم، کسی هست کمک کنه؟» هیچ اطلاعاتی دربارهٔ مشکل شما نمی‌دهد. افراد باتجربه معمولاً از پاسخ دادن به چنین سؤال‌های مبهمی خودداری می‌کنند، چون نمی‌دانند قرار است با چه سطحی از مسئله روبه‌رو شوند. مستقیماً خودِ سؤال را مطرح کنید. (بیشتر بخوانید)
۲-۳. کل مطلب را در یک پیام واحد بنویسید
فرستادنِ یک موضوع در قالب پنج یا شش پیام کوتاه و پشت‌سرهم، باعث ارسال اعلان‌های (Notification) پیاپی برای اعضای گروه، قطع شدن رشتهٔ افکار دیگران و شلوغی کاذب صفحهٔ گفتگو می‌شود. پیش از فشردن دکمهٔ ارسال، تمام توضیحات خود را در یک پیام کامل، منسجم و پاراگراف‌بندی‌شده بنویسید.
❌ نادرست: - سلام دوستان - کسی اینجا با Nginx کار کرده؟ - من یه مشکلی توی کانفیگ دارم - وقتی ریلود می‌کنم خطا میده ✅ درست: سلام وقت بخیر. من در تنظیمات Nginx روی اوبونتو ۲۴.۰۴ قصد دارم ترافیک پورت ۸۰ را به پورت ۳۰۰۰ هدایت کنم، اما هنگام اجرای دستور nginx -t با خطای زیر روبه‌رو می‌شوم: [متن خطا و بخش مربوط به کانفیگ] تا الان این موارد را هم بررسی کرده‌ام... ممنون می‌شوم راهنمایی کنید.
۲-۴. از ارسال پیام صوتی (Voice) برای مسائل فنی خودداری کنید
توضیح دادن معماری سیستم، لاگ سرور یا روند یک باگ در قالب پیام صوتی، کار را برای کسانی که می‌خواهند به شما کمک کنند دشوار می‌سازد. بسیاری از افراد در محیط کار امکان گوش دادن به فایل صوتی را ندارند؛ ضمن اینکه محتوای صوتی با نگاه سریع قابل مرور نیست و در جستجوهای بعدی گروه نیز پیدا نمی‌شود.
۲-۵. پرهیز از پیام خصوصی (DM/PV) و ارسال هم‌زمان در چند گروه (Cross-Posting)
- پیام خصوصی نفرستید: بردن سؤالات فنی به پیام خصوصی افراد، هم وقت آن‌ها را به شکل انحصاری می‌گیرد و هم بقیهٔ اعضای گروه را از خواندن راه‌حل محروم می‌کند. سؤالات فنی باید در فضای عمومی پرسیده شوند.
- کراس‌پست نکنید: کپی کردن هم‌زمان یک سؤال در چند گروه مختلف باعث می‌شود چندین نفر به طور موازی و بی‌خبر از یکدیگر، برای مشکلی که شاید در گروه دیگری حل شده باشد وقت بگذارند. سؤال را در مرتبط‌ترین گروه بپرسید و صبور باشید.
۳. کالبدشکافی یک سؤال فنی استاندارد
۳-۱. هدف اصلی را بگویید، نه فقط راه‌حل حدسی خودتان را (XY Problem)
مسئلهٔ XY زمانی رخ می‌دهد که شما می‌خواهید کار X را انجام دهید، و فکر می‌کنید راه‌حل آن استفاده
از
روش Y است؛ اما چون در پیاده‌سازی Y به مشکل خورده‌اید، بدون اشاره به هدف اصلی، فقط
دربارهٔ Y سؤال می‌پرسید. در بسیاری از مواقع، مسیر Y از پایه برای رسیدن به هدف شما
اشتباه است. همیشه در کنار سؤالتان، هدف نهایی (تصویر بزرگ‌تر) را هم توضیح دهید. (بیشتر بخوانید)
۳-۲. محیط اجرا، زمینه و تلاش‌های خود را مشخص کنید
جملاتی مثل «این کد کار نمی‌کند» یا «برنامه کرش می‌کند» بدون جزئیات، غیرقابل‌پاسخ هستند. همیشه موارد زیر را به روشن‌ترین شکل ذکر کنید (بیشتر بخوانید):
- سیستم‌عامل، نسخهٔ زبان برنامه‌نویسی، فریم‌ورک یا کتابخانه‌های مرتبط؛
- رفتاری که انتظار داشتید رخ دهد در برابر رفتاری که در عمل رخ داده است؛
- متن کامل و دقیق خطا (Stack Trace / Log)؛
- راه‌حل‌هایی که تا این لحظه امتحان کرده‌اید و نتیجهٔ آن‌ها.
۳-۳. ارائهٔ مثال حداقلی، کامل و قابل بازتولید (MRE / SSCCE)
برای دریافت کمک در مورد یک باگ، نه کل پروژهٔ هزارخطی خود را بفرستید و نه کد را به کلی حذف کنید. کد را به کوچک‌ترین قطعهٔ مستقلی تقلیل دهید که هر کس با کپی و اجرای آن، دقیقاً همان خطای شما را ببیند. برای آشنایی با نحوهٔ ساخت چنین مثالی به SSCCE و راهنمای MRE در Stack Overflow مراجعه کنید.
۳-۴. از کد و ترمینال عکس نگیرید!
فرستادن عکس با دوربین موبایل از صفحهٔ مانیتور یا ارسال اسکرین‌شات از محیط کدنویسی و ترمینال، یکی از بزرگ‌ترین موانع کمک‌رسانی است. هیچ‌کس نمی‌تواند کدِ داخلِ عکس را کپی، اجرا و دیباگ کند؛ ضمن اینکه خواندن عکس در موبایل سخت است و متن آن در جستجوها ایندکس نمی‌شود. (بیشتر بخوانید)
- کدهای کوتاه (چندخطی) را مستقیماً در پیام و درون بلاک کد (
```) قرار دهید. - کدها و لاگ‌های طولانی را در سرویس‌های اشتراک متن مانند GitHub Gist یا Pastebin قرار داده و لینک آن را ارسال کنید.
۴. پس از دریافت پاسخ و حل مشکل
۴-۱. سؤال را پاک نکنید و راه‌حل نهایی را بنویسید
پاک کردن پیامِ سؤال پس از رسیدن به جواب، یا بستن بحث با جملهٔ «ممنون، خودم حلش کردم!» بدون توضیحِ چگونگی آن، تضییع وقت کامیونیتی است. ماه‌ها یا سال‌ها بعد، فرد دیگری دقیقاً با همین مشکل در گروه جستجو خواهد کرد؛ دیدن سؤالی بدون جواب (پدیده‌ای که در فرهنگ وب با کمیک معروف Wisdom of the Ancients شناخته می‌شود) بسیار ناامیدکننده است. همیشه در پایان، راه‌حل نهایی را در چند خط زیر سؤال خود ثبت کنید تا به دانش جمعی اضافه شود.
۵. فرهنگ تعامل، پاسخ‌گویی و اخلاق حرفه‌ای
۵-۱. نقد کد، نه نقد شخص (Egoless Programming)
هنگام بررسی کد یا معماری سیستم دیگران، نقد خود را معطوف به «منطق فنی و پیاده‌سازی» کنید، نه هوش، تجربه یا شخصیت نویسنده. به جای جملاتی مانند «چقدر این کد رو بد نوشتی»، بگویید «این کوئری در ترافیک بالا باعث مشکل N+1 می‌شود و بهتر است به این شکل بازنویسی شود». به همین ترتیب، اگر کد شما نقد شد، آن را حملهٔ شخصی تلقی نکنید.
۵-۲. چهار قاعدهٔ طلایی تعامل
برای حفظ فضای امن، محترمانه و یادگیرنده در گروه، رعایت چهار قانون اجتماعیِ تعریف‌شده در Recurse Center ضروری است:
- الف) ابراز تعجب نکردن از ندانستن دیگران (No Feigning Surprise): هرگز در برابر سؤال دیگران نگویید «واقعاً نمی‌دونی Git چطور کار می‌کنه؟!» یا «مگه میشه فلان مفهوم رو بلد نباشی؟». این واکنش هیچ ارزش فنی ندارد و تنها باعث می‌شود افراد از پرسیدن و یادگیری بترسند.
- ب) پرهیز از اصلاح‌های وسواسی و بی‌ربط (No Well-Actually's): وقتی فردی در حال توضیح یک مفهوم کلی است، وسط پریدن برای اصلاح یک جزئیات بسیار ریز که هیچ تأثیری در اصلِ بحث و مشکلِ مطرح‌شده ندارد، فقط باعث انحراف گفتگو و فرسایش جمع می‌شود.
- ج) پرهیز از راهنمایی از صندلی عقب (No Backseat Driving): اگر دو نفر در حال بررسی و دیباگ گام‌به‌گام یک مشکل هستند، بدون خواندن کامل پیام‌های قبلی، ناگهان وسط بحث نپرید و دستورات پراکنده صادر نکنید؛ مگر اینکه واقعاً به کل روند گفتگو مسلط باشید.
- د) پرهیز از تعصبات ابزاری و شوخی‌های تحقیرآمیز (No Subtle -isms): ابزارها، زبان‌های برنامه‌نویسی و سیستم‌عامل‌ها وسیلهٔ کارند، نه قبیلهٔ تعصب. از تحقیر کاربران یک زبان یا ابزار خاص، و همچنین از هرگونه شوخی یا کنایهٔ جنسیتی، قومیتی و نژادی خودداری کنید.
۵-۳. پایبندی به منشور اخلاقی (Code of Conduct)
سلامت بلندمدت هر کامیونیتی در گرو احترام متقابل، رواداری و پذیرش افراد با سطوح دانش متفاوت است. آشنایی با چارچوب‌های شناخته‌شدهٔ بین‌المللی مانند پیمان مشارکت‌کنندگان (Contributor Covenant) و منشور اخلاقی برلین به درک بهتر مرزهای رفتار حرفه‌ای در فضاهای متن‌باز و فناوری کمک می‌کند.
درباره این راهنما
این سند با هدف ارتقای کیفیت گفتگوها، صرفه‌جویی در وقت متخصصان و تسهیل یادگیری در کامیونیتی‌های فارسی‌زبان حوزه فناوری اطلاعات تدوین شده است. بازنشر، کپی‌برداری و استفاده از این صفحه به عنوان قوانین پایه در گروه‌ها، انجمن‌ها و کانال‌های فنی کاملاً آزاد است.
نگارش و تنظیم: پینک اورکا