رفتن به مطلب
مرجع رسمی سی‌پلاس‌پلاس ایران

جستجو در تالارهای گفتگو

در حال نمایش نتایج برای برچسب های 'قوانین'.



تنظیمات بیشتر جستجو

  • جستجو بر اساس برچسب

    برچسب ها را با , از یکدیگر جدا نمایید.
  • جستجو بر اساس نویسنده

نوع محتوا


آی‌او‌استریم

چیزی برای نمایش وجود ندارد

چیزی برای نمایش وجود ندارد

تالارهای گفتگو

  • انجمن‌های آی او استریم
    • اخبار و اعلامیه‌های سایت
    • اسناد و قوانین مرجع
    • جلسات و دوره‌همی‌های آنلاین
    • پادکست‌های آموزشی
    • معرفی محصولات نوشته شده‌ بومی
    • مرکز نظرسنجی
    • مقالات و اسناد مشاوره‌ای
    • مرکز چالش برانگیز برنامه‌نویسان
    • رمز‌های موفقیت
    • ابزار‌ها و نرم‌افزارهای کاربردی برنامه‌نویسان حرفه‌ای
  • برنامه نویسی در C و ‏++C
    • سوالات عامیانه در رابطه با ++C مدرن
    • کتابخانه‌های استاندارد STL
    • کتابخانه بوست (Boost)
    • کتابخانه کیوت (Qt)
    • کتابخانه‌‌ی SDL
    • کتابخانه‌های گرافیکی Vulkan, OpenGL, Metal, Direct3D
    • کتابخانه‌‌ی OpenCV
    • کتابخانه‌‌ی Cuda
    • کتابخانه‌‌ی OpenMP
    • کتابخانه‌‌ی OpenCL
    • کتابخانه‌های دیگر
    • کامپایلر‌ها
    • کتابخانهٔ SFML
    • ابزار‌ها
  • استارتاپی و کسب‌و‌کار
    • استارتاپ‌ها
    • سرمایه گذاری
    • شتاب دهنده‌ها
    • پارک‌های علم و فناوری و مراکز رشد
    • مصاحبه با استارت‌آپ‌ها
    • قوانین حقوقی
    • داستان‌های موفقیت
    • کارآفرینان و متخصصین
    • مشاوره اجرای کسب‌وکار
    • اخبار حوزه‌ی استارتا‌پی
    • آگهی‌های استخدامی
  • ابزار‌های ساخت و ساز
    • ابزار CMake
    • ابزار QMake
    • ابزار Qbs
    • ابزار Make و Autotools
  • طراحی و توسعه وب
  • طراحی و توسعه وب اپلیکیشن‌ها
    • طراحی و توسعه در Angular
    • طراحی و توسعه در React.JS
    • طراحی و توسعه در Vue.JS
  • طراحی و توسعه موبایل و اِمبِد‌ها و تلوزیون‌ها
    • برنامه نویسی تحت محصولات اپل
    • برنامه نویسی تحت محصولات گوگل
    • طراحی و توسعه تحت محصولات دیگر
  • برنامه‌نویسی سطح پایین و سیستم عامل‌ها
    • سیستم عامل‌های آزاد
    • سیستم عامل‌های تجاری
    • مباحث آموزشی مرتبط با سیستم‌عامل
  • شبکه و اینترنت
    • مباحث و منابع آموزشي
    • سوالات و مشکلات
  • بانک‌های اطلاعاتی
  • برنامه نویسی تحت محصولات اپل
  • برنامه نویسی تحت محصولات مایکروسافت
  • طراحی و توسعه تجربه کاربری (UX) و رابط کاربری (UI)
  • سوالات و مباحث عامیانه
  • سطل آشغال

Product Groups

  • کتاب‌ها و مقالات آموزشی

دسته ها

  • علمی
  • استارتاپی
  • برنامه‌نویسی
    • زبان‌های برنامه نویسی
    • معماری‌ها
  • کامپایلر و مفسر
  • محیط‌های توسعه
  • طراحی و توسعه‌ی وب
  • مجوز‌های نرم‌افزاری
  • فناوری‌ها
    • پردازش تصویر
    • اینترنت اشیاء
    • پردازش ابری (Cloud Computing)
    • چند سکویی (Cross-Platform)
    • بیگ دیتا (Big Data)
    • هوش مصنوعی (AI)
    • سخت افزار
    • نرم‌افزار و اپلیکیشن
    • اینترنت و شبکه
    • رمزنگاری
    • امبد‌ها (Embedded)
  • طراحی
    • تجربه کاربری
    • رابط کاربری

دسته ها

  • عمومی
  • گرافیکی
  • شبکه و ارتباطات

دسته ها

  • کامپایلر‌ها
  • محیط‌های توسعه
  • کتابخانه‌ها
  • ماژول‌ها و پلاگین‌ها
  • محصولات بومی
  • کتاب‌ها و مقالات
  • زبان‌ها و ابزار‌ها
  • طراحی و گرافیک

جستجو در ...

نمایش نتایجی که شامل ...


تاریخ ایجاد

  • شروع

    پایان


آخرین بروزرسانی

  • شروع

    پایان


فیلتر بر اساس تعداد ...

تاریخ عضویت

  • شروع

    پایان


گروه


درباره من


شماره تلفن همراه


شناسه گیت‌هاب


شناسه لینکدین


شناسه پیام رسان


شهر


آدرس پستی

7 نتیجه پیدا شد

  1. قانون حمایت از حقوق پدیدآورندگان نرم‌افزارهای رایانه‌ای قانون دیگر قانون حمایت از حقوق پدیدآورندگان نرم‌افزارهای رایانه‌ای مصوب ۱۳۷۹ است. همان‌طور که از نام این قانون مشخص است، در این قانون حقوق مادی و معنوی پدیدآورندگان نرم‌افزارهای رایانه‌ای شرح داده می‌شود. مطابق ماده‌ی ۱ این قانون، «حق نشر، عرضه، اجرا و حق بهره‌برداری مادی و معنوی از نرم‌افزارهای رایانه‌ای متعلق به پدیدآورنده‌ی آن است. نحوه‌ی تدوین و ارائه‌ی داده‌ها در محیط قابل پردازش رایانه‌ای نیز مشمول احکام نرم‌افزار خواهد بود.» مطابق مطابق ماده‌ی ۳ این قانون، نام، عنوان و نشان ویژه‌ای که معرف نرم‌افزار است از حمایت این قانون برخوردار است و هیچ‌کس نمی‌تواند آنها را برای نرم‌افزار دیگری از همان نوع یا مانند آن به نحوی که القای شبهه نماید، استفاده کند. در ماده‌ی ۱۳ قانون به‌طور کلی ضمانت اجرای نقض حقوق مورد حمایت این قانون، علاوه بر جبران خسارت متضرر، حبس از نود و یک روز تا شش ماه و جزای نقدی از ده میلیون تا پنجاه میلیون ریال بیان شده است. همچنین مطابق ماده‌ی ۱۵ این قانون، جرایم مربوط به نقض حقوق مورد حمایت این قانون، از جرایم قابل گذشت است. ‌ماده ۱ - حق نشر، عرضه، اجرا و حق بهره برداری مادی و معنوی نرم افزار رایانه‌ای متعلق به پدید آورنده آن است. نحوه تدوین و ارائه داده‌ها در‌محیط قابل پردازشرایانه‌ای نیز مشمول احکام نرم‌افزار خواهد بود. مدت حقوق مادی سی (۳۰) سال از تاریخ پدید آوردن نرم‌افزار و مدت حقوق‌معنوی نامحدود است. ماده ۲ - در صورت وجود شرایط مقرر در قانون ثبت علایم و اختراعات، نرم‌افزار به عنوان اختراع شناخته می‌شود، آئین‌نامه مربوط به این ماده به‌تصویب هیأت وزیرا نخواهد رسید. ‌ماده ۳ - نام، عنوان و نشانه ویژه‌ای که معرف نرم افزار است از حمایت این قانونبرخوردار است و هیچ کس نمی‌تواند آنها را برای نرم افزار دیگری‌ از همان نوع یامانند آن به ترتیبی که القای شبهه کند بکار برد در غیر این صورت به مجازات مقرر در ماده (۱۳) این قانون محکوم خواهد شد. ‌ماده ۴ - حقوق ناشی از آن بخش از نرم‌افزاری که به واسطه نرم‌افزارهای دیگر پدیدمی‌آید متعلق به دارنده حقوق نرم‌افزارهای واسط نیست.‌ ماده ۵ - پدید آوردن نرم‌افزارهای مکمل و سازگار با دیگر نرم‌افزارها با رعایتحقوق مادی نرم‌افزارهای اولیه مجاز است.‌ ماده ۶ - پدید آوردن نرم‌افزارها ممکن است ناشی از استخدام و یا قرارداد باشد دراین صورت: ‌الف - باید نام پدید آورنده توسط متقاضی ثبت به مراجع یاد شده در این قانون بهمنظور صدور گواهی ثبت، اعلام شود. ب - اگر هدف از استخدام یا انعقاد قرارداد، پدید آوردن نرم‌افزار مورد نظر بوده ویا پدید آوردن آن جزء موضوع قرارداد باشد، حقوق مادی مربوط‌و حق تغییر و توسعه نرم‌افزار متعلق به استخدام کننده یا کارفرما است، مگر اینکه در قرارداد به صورتدیگری پیش بینی شده باشد. ‌ماده ۷ - تهیه نسخه‌های پشتیبان و همچنین تکثیر نرم‌افزاری که به طریق مجاز برایاستفاده شخصی تهیه شده است چنانچه به طور همزمان مورد‌استفاده قرار نگیرد، بلامانعاست.‌ ماده ۸ - ثبت نرم‌افزارهای موضوع مواد (۱) و (۲) این قانون پس از صدور تأییدیه فنی توسط شورای عالی انفورماتیک حسب مورد توسط وزارت‌فرهنگ و ارشاد اسلامی و یامرجع ثبت شرکتها انجام می‌پذیرد.‌ ماده ۹ - دعوای نقض حقوق مورد حمایت این قانون ، در صورتی در مراجع قضایی مسموعاست که پیش از اقامه دعوی ، تأییدیه فنی یاد شده در‌ماده (۸) این قانون صادر شده باشد. در مورد حق اختراع ، علاوه بر تأییدیه مزبور ، تقاضای ثبت نیز باید به مرجعذی ربط تسلیم شده باشد.‌ ماده ۱۰ - برای صدور تأییدیه فنی موضوع ماده (۸) در مورد نرم افزارهایی که پدیدآورنده آن مدعی اختراع بودن آن است، کمیته‌ای به نام "‌کمیته‌حق اختراع" زیر نظرشورای عالی انفورماتیک تشکیل می‌شود. اعضای این کمیته مرکب از سه کارشناس ارشدنرم‌افزار به عنوان نمایندگان شورای عالی‌انفورماتیک، نماینده سازمان ثبت اسناد واملاک کشور و یک کارشناس حقوقی به انتخاب شورای عالی انفورماتیک خواهد بود.‌ ماده ۱۱ - شورا مکلف است از صدور تأییدیه فنی برای نرم‌افزارهایی که به تشخیصوزارت فرهنگ و ارشاد اسلامی خلاف اخلاق اسلامی و‌عفت عمومی و سلامت شخصیت کودکان ونوجوانان باشند خودداری کند. وزارت فرهنگ و ارشاد اسلامی باید ظرف دو هفته راجع به استعلام کتبی‌شورای عالی انفورماتیک اعلام نظر کند.‌ ماده ۱۲ - به منظور حمایت عملی از حقوق یاد شده در این قانون‌، نظم بخشی وساماندهی فعالیت‌های تجاری رایانه‌ای مجاز، نظام صنفی رایانه‌ای‌توسط اعضای صنف یادشده تحت نظارت شورا به وجود خواهد آمد. مجازات‌های مربوط به تخلفات صنفی مربوط،برابر مجازات‌های جرایم یاد شده در‌ لایحه قانونی امور صنفی - مصوب 1359.4.13 واصلاحیه‌های آن - خواهد بود.‌ ماده ۱۳ - هرکس حقوق مورد حمایت این قانون را نقض نماید علاوه بر جبران خسارت بهحبس از نود و یک روز تا شش ماه و جزای نقدی از ده‌ میلیون (۱۰،۰۰۰،۰۰۰) تا پنجاه میلیون (۵۰،۰۰۰،۰۰۰) ریال محکوم می‌گردد.‌ تبصره - خسارات شاکی خصوصی از اموال شخص مرتکب جرم جبران می‌شود.‌ ماده ۱۴ - شاکی خصوصی می‌تواند تقاضا کند مفاد حکم دادگاه در یکی از روزنامه‌ها با انتخاب و هزینه او آگهی شود.‌ ماده ۱۵ - رسیدگی جرم مذکور در ماده (۱۳) با شکایت شاکی خصوصی آغاز و باگذشت او موقوف می‌شود.‌ ماده ۱۶ - حقوق مذکور در ماده (۱) در صورتی مورد حمایت این قانون خواهد بود که موضوع برای نخستین بار در ایران تولید و توزیع شده باشد.‌ ماده ۱۷ - آیین‌نامه اجرایی این قانون شامل مواردی از قبیل چگونگی صدور گواهی ثبت و تأییدیه فنی و هزینه‌های مربوط همچنین نحوه تشکیل‌ نظام صنفی رایانه‌ای، به پیشنهاد سازمان مدیریت و برنامه‌ریزی کشور و با هماهنگی وزارتخانه‌های فرهنگ وارشاد اسلامی و دادگستری به تصویب‌ هیأت وزیران خواهد رسید.‌قانون فوق مشتمل بر هفده ماده و یک تبصره در جلسه علنی روز یکشنبه مورخ چهارم دی‌ماه یک هزار و سیصد و هفتاد و نه مجلس شورای اسلامی‌تصویب و در تاریخ ۱۳۷۹/۱۰/۱۰ به تأیید شورای نگهبان رسیده است. تاریخ تصویب : ۱۳۷۹/۱۰/۰۴ مرجع تصویب : مصوبات مجلس شورا ماده ۱۷ بند ۲ منابع و اسناد رسمی مرکز پژوهش‌های مجلس شورای اسلامی ویکی‌پدیا
  2. کامبیز اسدزاده

    مبنای امتیازات مرجع

    مقدمه نقد و بررسی‌ و ارسال نظرات کارشناسی سایت مرجع‌آی‌او استریم با هدف شناساندن هرچه بیشتر و بهتر زبان‌ها و فناوری‌های برنامه‌نویسی به مخاطب و همچنین کمک به تصمیم‌گیری در رابطه با نحوه‌‌ی تجزیه و تحلیل برنامه نویسی و کسب تجربه می‌باشد که در کنار آن علاوه بر آن، هدفِ این مرجع شناساندن متخصصین به جامعه و به کار گیری تجربیات صحیح و مطلوب به جامعه‌ی استارتاپی کشور است. توضیحات کلی در نقد و بررسی‌هایِ آی او استریم، پیش از خواندن متن سوالات و پاسخ‌ها می‌توانید به طور کاملا خلاصه با نکات مثبت و منفی موضوعات مطرح شده و همچنین نظر کلی اساتید و مراجع را در مورد آن‌ها بررسی کنید. لازم بذکر است دلیل امتیاز دهی تنها نباید مبنا بر اساس حل مشکل باشد! بنابراین امتیاز‌ها باید در زمانی ارسال شوند که از صحت پاسخ و همچنین نتیجه‌ی درست و مستند شده‌ی آن اطمینان شود. نحوه‌ی کار با سیستم امتیاز‌دهی تصویر زیر مربوط به ابزار امتیاز‌دهی است، در صورتی که پاسخ داده شده به سوال شما بر اساس مستندات، منطق و علوم مربوطه صحت داشته و دیگر اساتید آن را تایید می‌کنند می‌توانید در این صورت از ابزار مربوطه برای اعلام نظر خود استفاده کنید. در صورتی که بر اساس مستندات از قبل ثابت شده نظر بر پاسخ منفی باشد از دکمه‌ی فلِش به پایین استفاده کنید. در صورتی که پاسخ مثبت و علمی باشد از دکمه‌ی فلش رو به بالا برای امتیاز مثبت به پاسخ استفاده کنید. بدون هیچ امتیازی دارای امتیاز منفی دارای امتیاز مثبت مطالبی که دارای بیش از ۵ امتیاز می‌باشد به صورت برجسته نمایان خواهد شد. امتیاز به موضوعات، عناوین و فایل‌ها بخش امتیاز به فایل‌ها، تاپیک‌ها و موضوعات بر اساس سیستم امتیاز دهی ستاره‌ای مشخص می‌شود. این امتیاز موجب می‌گردد تا فایل یا موضوع مربوطه بر اساس درجاتی که کسب کرده است بین موضوعات مختلف در سطحی که نیاز است نمایان شوند. بدون امتیاز به موضوع دارای امتیاز به موضوع اعتبار‌ها امتیاز کل کاربر همراه با مرحله‌ای که در آن قرار دارد، نمایش می‌یابد. میانگین اعتبار از کمترین امتیاز ممکن (۲۰-) آغاز شده و به بهترین امتیاز ممکن (۲۰+) ختم می‌شود که توسط واکنش کاربران نسبت به هر یک از فعالیت‌های شما بر روی مرجع خواهد بود. برای مثال در صورتی که شما هرگونه به‌روز رسانی بر روی پست‌های خود، وضعیت خود و دیگر فعالیت‌های خود بر روی مرجع دارید، کاربران دیگر می‌توانند آن را بر اساس برداشت و حِسی که نسبت به آن عمل دارند، یکی از پنج حالت را اعمال کنند که شامل می‌باشد. واکنش به شکلک ناراحت (خنثی) هیچ امتیازی اعمال نمی‌کند. واکنش به شکلک خندان (۱+) یک امتیاز به موضوع یا مطلب شما اعمال می‌کند. واکنش به شکلک سردرگم (خنثی) هیچ امتیازی اعمال نمی‌کند. واکنش به جام (۱+) یک امتیاز اعمال می‌کند. واکنش به ستاره‌ی دنباله‌دار (۱+) یک امتیاز مثبت اعمال می‌کند. واکنش به شکلک قلب (پسندیدن ۱+) یک امتیاز مثبت را اعمال می‌کند. واکنش به قلب شکسته (۱-) یک امتیاز منفی اعمال می‌کند و آن را از امتیاز کل شما کم می‌کند. محیط رقابتی شما می‌توانید به لیستی از بهترین پرچم‌داران، بهترین کاربران و سوابق آن‌ها در مرجع دسترسی داشته باشید و برای بهتر شدن و نشان داده شدن در این لیست با یک دیگر رقابت کنید. همچنین شما می‌توانید اقدام به دنبال کردن یکدیگر و مشاهده‌ی مطالب به صورت برجسته بر اساس طرفداران خود را در اختیار داشته باشید.
  3. کامبیز اسدزاده

    قوانین مرتبط با بخش ویژه‌ی درخواست پروژه

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

    شرایط کسب مجوز فعالیتی و ارتقا حساب‌کاربری

    شرایط کسب مجوز فعالیتی و ارتقا حساب‌کاربری نسخه‌ی ۱.۰.۰ همانطور که می‌دانید مرجع آی او استریم در ابتدا ثبت‌نام دارای گروه‌های کاربری مشخصی می‌باشد که ثبت‌نام کننده خود انتخاب می‌کند که عضو کدام گروه باشد. اما بعضی از گروه‌های کاربری موجود که در لیست زمان ثبت‌نامی موجود نیستند شامل مدیران سایت، میانجی‌گر‌ها و فول‌اِستَک‌ها هستند که دارای مجوز‌های بیشتری نسبت به دیگر گروه‌های کاربری می‌باشند که توسط اساتید تایید می‌شوند. بنابراین برای کسب مجوز این نوع گروه‌های کاربری نیاز بر این است ابتدا اسناد قوانین و قالب اصول نگارشی در مرجع آی او استریم، سند نحوه‌ی پرسش و پاسخ هوشمندانه و حریم خصوصی را مطالعه و بپذیرید. ما بر این باوریم که باهم به صورت کار تیمی می‌توانیم مرجعی پُر بار و مفید برای جامعه‌ی برنامه‌نویسی کشورمان فراهم کنیم?. گروه‌های کاربری در مرجع آی او استریم به صورت زیر می‌باشند: بنیان‌گذاران مدیران کل سایت میانجی‌گر‌ها اساتید توسعه‌دهنده بَک‌اِند توسعه‌دهنده فرانت‌اِند توسعه‌دهنده فول‌اِستک طراحان مترجمین منتور‌ها و مشاورین کاربران عادی کاربران رسمی برخی از مجوز‌های ویژه این گروه‌ها در مدیریت کاربری، مطالب و گروه‌ها گروه‌های کاربری عادی، توسعه‌دهنده بَک‌اِند و فرانت اِند، طراحان، مترجمین توانایی دسترسی به سایت توانایی تغییر نام کاربری بعد از پذیرفته شدن حداقل ۱۰ مطلب، نظرسنجی و دیدگاه‌ها نمایش در لیست آخرین کاربران و اطلاعات آنلاین توانایی ارسال تصویر کاور توانایی استفاده از انیمیشن‌های متحرک بر روی آواتار اجازه‌ی نمایش کاربران و مطالب مرتبط به آن در نتایج جستجو توانایی نمایش تاریخچه‌ی نام نمایشی توانایی دسترسی به سایت در هنگام آفلاین بودن توانایی ایجاد نظرسنجی توانایی رای دادن در نظر‌سنجی‌ها توانایی بستن نظر‌سنجی خود توانایی استفاده از برچسب‌ها توانایی استفاده از پیشوند‌ها گفتگو‌های مجاز برای ارسال در هر هفته (25 عدد) گفتگوهای مجاز برای آغاز در هر دقیقه (۱) حداکثر دریافت کننده در هر گفتگو (10) امکان استفاده از امضاء توانایی بارگذاری فایل نمایش پاسخ‌های برجسته (نمایش پاسخ‌های این گروه در ویژگی و رنگ خاص) توانایی ارسال امتیاز به مطالب توانایی تغییر امتیاز به مطالب توانایی ویرایش مطالب خود در ماژول‌های زیر گفتگو‌های خصوصی به‌روز‌رسانی وضعیت مطالب وبلاگ‌ها موضوعات انجمن‌ها تصاویر آلبوم‌ها رویداد‌ها مقالات صفحه‌هات استاتیک فایل‌ها (مرکز دانلود) محدودیت ویرایش زمانی مطالب (120 دقیقه بعد از ارسال) توانایی ویرایش مطالب به صورت مخفی (به طور عادی اگر مطلبی ویرایش گردد در زیر آن عبارت ویرایش شده قرار می گیرد. اگر فعال شود، کاربران این گروه قادر خواهند بود این پیام را مخفی نمایند. مدیران تالاری که دسترسی مربوطه را دارند همیشه قادر به مشاهده این پیام هستند.) توانایی مخفی سازی مطالب خود توانایی حذف مطالب خود توانایی قفل یا باز کردن مطالب خود محدودیت ارسال مطلب، دیدگاه و نظرسنجی ۱۰ عدد در روز توانایی گزارش مطالب امکان بازنشر در شبکه‌های اجتماعی نیاز مطالب ارسالی به تایید توسط مدیران توانایی بارگذاری فایل در پیام‌های خصوصی و چت توانایی نشان دادن افراد واکنش نشان داده شده امکان ایجاد بلاگ امکان ارسال نظر در پست‌های بلاگ توانایی ایجاد گالری توانایی ایجاد آلبوم توانایی ارسال ویدیو امکان ایجاد پُست به عنوان اسناد معتبر (ویژه، مهم) مدیریت تاپیک‌ها برای عمل‌های ایجاد، حذف، قفل کردن، باز کردن، ویرایش و انتقال مدیریت کاربران (اخطار، رسیدگی به شکایت و بررسی صف‌های پذیرش) ایجاد مقاله در بخش مقالات و یا وبلاگ تخصصی به صورت (مشارکت گروهی) توانایی مشاهده‌ی دریافت کنندگان فایل توانایی مشاهده‌ی پذیرنده‌های فایل توانایی مدیریت نسخه‌ها توانایی فروش و کسب پورسانت از فایل‌ها در بخش مرکز دانلود و فروشگاه توانایی ارسال چند فایل به صورت همزمان گروه‌های کاربری رسمی توانایی دسترسی به سایت توانایی تغییر نام کاربری بعد از پذیرفته شدن حداقل ۱۰ مطلب، نظرسنجی و دیدگاه‌ها نمایش در لیست آخرین کاربران و اطلاعات آنلاین توانایی ارسال تصویر کاور توانایی استفاده از انیمیشن‌های متحرک بر روی آواتار اجازه‌ی نمایش کاربران و مطالب مرتبط به آن در نتایج جستجو توانایی نمایش تاریخچه‌ی نام نمایشی توانایی دسترسی به سایت در هنگام آفلاین بودن توانایی ایجاد نظرسنجی توانایی رای دادن در نظر‌سنجی‌ها توانایی بستن نظر‌سنجی خود توانایی استفاده از برچسب‌ها توانایی استفاده از پیشوند‌ها گفتگو‌های مجاز برای ارسال در هر هفته (25 عدد) گفتگوهای مجاز برای آغاز در هر دقیقه (۱) حداکثر دریافت کننده در هر گفتگو (10) امکان استفاده از امضاء توانایی بارگذاری فایل نمایش پاسخ‌های برجسته (نمایش پاسخ‌های این گروه در ویژگی و رنگ خاص) توانایی ارسال امتیاز به مطالب توانایی تغییر امتیاز به مطالب توانایی ویرایش مطالب خود در ماژول‌های زیر گفتگو‌های خصوصی به‌روز‌رسانی وضعیت مطالب وبلاگ‌ها موضوعات انجمن‌ها تصاویر آلبوم‌ها رویداد‌ها مقالات صفحه‌هات استاتیک فایل‌ها (مرکز دانلود) محدودیت ویرایش زمانی مطالب (120 دقیقه بعد از ارسال) توانایی ویرایش مطالب به صورت مخفی (به طور عادی اگر مطلبی ویرایش گردد در زیر آن عبارت ویرایش شده قرار می گیرد. اگر فعال شود، کاربران این گروه قادر خواهند بود این پیام را مخفی نمایند. مدیران تالاری که دسترسی مربوطه را دارند همیشه قادر به مشاهده این پیام هستند.) توانایی مخفی سازی مطالب خود توانایی حذف مطالب خود توانایی قفل یا باز کردن مطالب خود محدودیت ارسال مطلب، دیدگاه و نظرسنجی ۱۰ عدد در روز توانایی گزارش مطالب امکان بازنشر در شبکه‌های اجتماعی نیاز مطالب ارسالی به تایید توسط مدیران توانایی بارگذاری فایل در پیام‌های خصوصی و چت توانایی نشان دادن افراد واکنش نشان داده شده امکان ایجاد بلاگ امکان ارسال نظر در پست‌های بلاگ توانایی ایجاد گالری توانایی ایجاد آلبوم توانایی ارسال ویدیو امکان ایجاد پُست به عنوان اسناد معتبر (ویژه، مهم) مدیریت تاپیک‌ها برای عمل‌های ایجاد، حذف، قفل کردن، باز کردن، ویرایش و انتقال مدیریت کاربران (اخطار، رسیدگی به شکایت و بررسی صف‌های پذیرش) ایجاد مقاله در بخش مقالات و یا وبلاگ تخصصی به صورت (مشارکت گروهی) توانایی مشاهده‌ی دریافت کنندگان فایل توانایی مشاهده‌ی پذیرنده‌های فایل توانایی مدیریت نسخه‌ها توانایی فروش و کسب پورسانت از فایل‌ها در بخش مرکز دانلود و فروشگاه توانایی ارسال چند فایل به صورت همزمان گروه‌های کاربری فول‌اِستک، اساتید، منتور و مشاورین توانایی دسترسی به سایت توانایی تغییر نام کاربری بدون محدودیت نمایش در لیست آخرین کاربران و اطلاعات آنلاین توانایی ارسال تصویر کاور توانایی استفاده از انیمیشن‌های متحرک بر روی آواتار اجازه‌ی نمایش کاربران و مطالب مرتبط به آن در نتایج جستجو توانایی نمایش تاریخچه‌ی نام نمایشی توانایی دسترسی به سایت در هنگام آفلاین بودن توانایی ایجاد نظرسنجی توانایی رای دادن در نظر‌سنجی‌ها توانایی بستن نظر‌سنجی خود توانایی استفاده از برچسب‌ها توانایی استفاده از پیشوند‌ها گفتگو‌های مجاز برای ارسال در هر هفته (100 عدد) گفتگوهای مجاز برای آغاز در هر دقیقه (10) حداکثر دریافت کننده در هر گفتگو (30) امکان استفاده از امضاء توانایی بارگذاری فایل نمایش پاسخ‌های برجسته (نمایش پاسخ‌های این گروه در ویژگی و رنگ خاص) توانایی ارسال امتیاز به مطالب توانایی تغییر امتیاز به مطالب توانایی ویرایش مطالب خود در ماژول‌های زیر گفتگو‌های خصوصی به‌روز‌رسانی وضعیت مطالب وبلاگ‌ها موضوعات انجمن‌ها تصاویر آلبوم‌ها رویداد‌ها مقالات صفحه‌هات استاتیک فایل‌ها (مرکز دانلود) محدودیت ویرایش زمانی مطالب (120 دقیقه بعد از ارسال) توانایی ویرایش مطالب به صورت مخفی (به طور عادی اگر مطلبی ویرایش گردد در زیر آن عبارت ویرایش شده قرار می گیرد. اگر فعال شود، کاربران این گروه قادر خواهند بود این پیام را مخفی نمایند. مدیران تالاری که دسترسی مربوطه را دارند همیشه قادر به مشاهده این پیام هستند.) توانایی مخفی سازی مطالب خود توانایی حذف مطالب خود توانایی قفل یا باز کردن مطالب خود محدودیت ارسال مطلب، دیدگاه و نظرسنجی 30 عدد در روز توانایی گزارش مطالب امکان بازنشر در شبکه‌های اجتماعی نیاز مطالب ارسالی به تایید توسط مدیران توانایی بارگذاری فایل در پیام‌های خصوصی و چت توانایی نشان دادن افراد واکنش نشان داده شده امکان ایجاد بلاگ امکان ارسال نظر در پست‌های بلاگ توانایی ایجاد گالری توانایی ایجاد آلبوم توانایی ارسال ویدیو امکان ایجاد پُست به عنوان اسناد معتبر (ویژه، مهم) مدیریت تاپیک‌ها برای عمل‌های ایجاد، حذف، قفل کردن، باز کردن، ویرایش و انتقال مدیریت کاربران (اخطار، رسیدگی به شکایت و بررسی صف‌های پذیرش) ایجاد مقاله در بخش مقالات و یا وبلاگ تخصصی به صورت (مشارکت گروهی) توانایی مشاهده‌ی دریافت کنندگان فایل توانایی مشاهده‌ی پذیرنده‌های فایل توانایی مدیریت نسخه‌ها توانایی فروش و کسب پورسانت از فایل‌ها در بخش مرکز دانلود و فروشگاه توانایی ارسال چند فایل به صورت همزمان گروه‌های کاربری میانجی‌گر‌ها توانایی دسترسی به سایت توانایی تغییر نام کاربری بدون محدودیت نمایش در لیست آخرین کاربران و اطلاعات آنلاین توانایی ارسال تصویر کاور توانایی استفاده از انیمیشن‌های متحرک بر روی آواتار اجازه‌ی نمایش کاربران و مطالب مرتبط به آن در نتایج جستجو توانایی نمایش تاریخچه‌ی نام نمایشی توانایی دسترسی به سایت در هنگام آفلاین بودن توانایی ایجاد نظرسنجی توانایی رای دادن در نظر‌سنجی‌ها توانایی بستن نظر‌سنجی خود توانایی استفاده از برچسب‌ها توانایی استفاده از پیشوند‌ها گفتگو‌های مجاز برای ارسال در هر هفته (100 عدد) گفتگوهای مجاز برای آغاز در هر دقیقه (10) حداکثر دریافت کننده در هر گفتگو (30) امکان استفاده از امضاء توانایی بارگذاری فایل نمایش پاسخ‌های برجسته (نمایش پاسخ‌های این گروه در ویژگی و رنگ خاص) توانایی ارسال امتیاز به مطالب توانایی تغییر امتیاز به مطالب توانایی ویرایش مطالب خود در ماژول‌های زیر گفتگو‌های خصوصی به‌روز‌رسانی وضعیت مطالب وبلاگ‌ها موضوعات انجمن‌ها تصاویر آلبوم‌ها رویداد‌ها مقالات صفحه‌هات استاتیک فایل‌ها (مرکز دانلود) محدودیت ویرایش زمانی مطالب (بدون محدودیت زمانی) توانایی ویرایش مطالب به صورت مخفی (به طور عادی اگر مطلبی ویرایش گردد در زیر آن عبارت ویرایش شده قرار می گیرد. اگر فعال شود، کاربران این گروه قادر خواهند بود این پیام را مخفی نمایند. مدیران تالاری که دسترسی مربوطه را دارند همیشه قادر به مشاهده این پیام هستند.) توانایی مخفی سازی مطالب خود توانایی حذف مطالب خود توانایی قفل یا باز کردن مطالب خود محدودیت ارسال مطلب، دیدگاه و نظرسنجی 30 عدد در روز توانایی گزارش مطالب امکان بازنشر در شبکه‌های اجتماعی نیاز مطالب ارسالی به تایید توسط مدیران را ندارد توانایی بارگذاری فایل در پیام‌های خصوصی و چت توانایی نشان دادن افراد واکنش نشان داده شده امکان ایجاد بلاگ امکان ارسال نظر در پست‌های بلاگ توانایی ایجاد گالری توانایی ایجاد آلبوم توانایی ارسال ویدیو امکان ایجاد پُست به عنوان اسناد معتبر (ویژه، مهم) مدیریت تاپیک‌ها برای عمل‌های ایجاد، حذف، قفل کردن، باز کردن، ویرایش و انتقال مدیریت کاربران (اخطار، رسیدگی به شکایت و بررسی صف‌های پذیرش) ایجاد مقاله در بخش مقالات و یا وبلاگ تخصصی به صورت (مشارکت گروهی) توانایی مشاهده‌ی دریافت کنندگان فایل توانایی مشاهده‌ی پذیرنده‌های فایل توانایی مدیریت نسخه‌ها توانایی فروش و کسب پورسانت از فایل‌ها در بخش مرکز دانلود و فروشگاه توانایی ارسال چند فایل به صورت همزمان گروه‌های کاربری، مدیران کل سایت توانایی دسترسی به سایت توانایی تغییر نام کاربری بدون محدودیت نمایش در لیست آخرین کاربران و اطلاعات آنلاین توانایی ارسال تصویر کاور توانایی استفاده از انیمیشن‌های متحرک بر روی آواتار اجازه‌ی نمایش کاربران و مطالب مرتبط به آن در نتایج جستجو توانایی نمایش تاریخچه‌ی نام نمایشی توانایی دسترسی به سایت در هنگام آفلاین بودن توانایی ایجاد نظرسنجی توانایی رای دادن در نظر‌سنجی‌ها توانایی بستن نظر‌سنجی خود توانایی استفاده از برچسب‌ها توانایی استفاده از پیشوند‌ها گفتگو‌های مجاز برای ارسال در هر هفته (نامحدود) گفتگوهای مجاز برای آغاز در هر دقیقه (نامحدود) حداکثر دریافت کننده در هر گفتگو (نامحدود) امکان استفاده از امضاء توانایی بارگذاری فایل نمایش پاسخ‌های برجسته (نمایش پاسخ‌های این گروه در ویژگی و رنگ خاص) توانایی ارسال امتیاز به مطالب توانایی تغییر امتیاز به مطالب توانایی ویرایش مطالب خود در ماژول‌های زیر گفتگو‌های خصوصی به‌روز‌رسانی وضعیت مطالب وبلاگ‌ها موضوعات انجمن‌ها تصاویر آلبوم‌ها رویداد‌ها مقالات صفحه‌هات استاتیک فایل‌ها (مرکز دانلود) محدودیت ویرایش زمانی مطالب (بدون محدودیت زمانی) توانایی ویرایش مطالب به صورت مخفی (به طور عادی اگر مطلبی ویرایش گردد در زیر آن عبارت ویرایش شده قرار می گیرد. اگر فعال شود، کاربران این گروه قادر خواهند بود این پیام را مخفی نمایند. مدیران تالاری که دسترسی مربوطه را دارند همیشه قادر به مشاهده این پیام هستند.) توانایی مخفی سازی مطالب خود توانایی حذف مطالب خود توانایی قفل یا باز کردن مطالب خود محدودیت ارسال مطلب، دیدگاه و نظرسنجی (نامحدود) عدد در روز توانایی گزارش مطالب امکان بازنشر در شبکه‌های اجتماعی نیاز مطالب ارسالی به تایید توسط مدیران را ندارد توانایی بارگذاری فایل در پیام‌های خصوصی و چت توانایی نشان دادن افراد واکنش نشان داده شده امکان ایجاد بلاگ امکان ارسال نظر در پست‌های بلاگ توانایی ایجاد گالری توانایی ایجاد آلبوم توانایی ارسال ویدیو امکان ایجاد پُست به عنوان اسناد معتبر (ویژه، مهم) مدیریت تاپیک‌ها برای عمل‌های ایجاد، حذف، قفل کردن، باز کردن، ویرایش و انتقال مدیریت کاربران (اخطار، رسیدگی به شکایت و بررسی صف‌های پذیرش) ایجاد مقاله در بخش مقالات و یا وبلاگ تخصصی به صورت (مشارکت گروهی) توانایی مشاهده‌ی دریافت کنندگان فایل توانایی مشاهده‌ی پذیرنده‌های فایل توانایی مدیریت نسخه‌ها توانایی فروش و کسب پورسانت از فایل‌ها در بخش مرکز دانلود و فروشگاه توانایی ارسال چند فایل به صورت همزمان گروه‌های کاربری بنیان‌گذاران، مدیران کل سایت اعضای این گروه مجوز خاص مدیریتی جهت اعمال دسترسی‌ها، مدیریت گروه‌های کاربری و رسیدگی به نگه‌داری و پشتیبانی سیستم نرم‌افزاری را در اختیار دارند.
  5. کامبیز اسدزاده

    سند نحوهٔ پرسش و پاسخ هوشمندانه

    مقدمه در دنیای برنامه‌نویسی، نوع جوابی که برای سوالات فنی خود می‌گیرید، هر چقدر که به سختی جواب دادن سوال بستگی دارد، همانقدر هم به روش پرسیدن شما بستگی دارد. با مطالعهٔ این راهنما قادر خواهید بود طوری سوال کنید که به احتمال بیشتری جواب رضایت بخشی دریافت کنید. هدف ما از این سند در مرجع برنامه نویسی ایران، این است که فرهنگ مکاتبه و رسیدگی به مشکلات همدیگر را در زمینه‌های مرتبط افزایش و بهینه سازی کنیم. بنابراین، امروزه که برنامه‌نویسی بیش از پیش گسترده شده، می‌توانید از وجود افراد با‌تجربه استفاده کنید و جواب‌های خوبی دریافت کنید. با این حال حتی اگر افراد با‌تجربه هم برای پرسیدن سوال روش‌های توصیه شده در این راهنما را به کار گیرند جواب‌های مفید‌تری دریافت می‌کنند. اولین چیزی که باید درک کنیم این است که افراد با‌تجربه سوال های سخت و طولانی را دوست دارند که به خوبی ذهن را درگیر می‌کند. اگر به ما یک سوال جالب توجه بدهید که به آن فکر کنیم از شما سپاس‌گزار خواهیم شد. سوالات خوب محرک ذهن بوده و یک هدیه هستند. سوالات خوب به ما کمک می‌کنند تا فهم خود را توسعه دهیم و عموماً باعث آشکار شدن مشکلاتی میشود که ممکن است ما ندانیم یا به آنها توجهی نکرده باشیم. در میان افراد با‌تجربه یک سوال خوب یک چالش مهیج است. با این وجود بسیاری از تازه‌کار ها گمان میکنند که افراد با‌تجربه در مقابل سوالات ساده با دشمنی و تکبر برخورد می‌کنند و به نظر می‌رسد که واکنش گستاخانه‌ای با افراد تازه‌کار و ناآگاه دارند. اما به هیچ وجه این‌طور نیست! چیزی که بدون شرمندگی باید بگوییم، خصومت با افرادی است که ظاهراً تمایلی به تفکر در موضوع ندارند و جواب دادن به سوالشان را به نوعی وظیفهٔ افراد با تجربه می‌دانند. از دید افراد با‌تجربه چنین افرادی باعث هدر رفتن وقت می‌شوند پس وقت خود را صَرف جواب دادن به سوالات بهتر میکنند. همچین افراد با‌تجربه بسیار داوطلب هستند و در زمان‌هایی که مشغول نباشند به پاسخ دادن به سوالات می‌پردازند. در آن مواقع غرق سوالات هستند. پس بدون ترس سوالات را فیلتر می‌کنند و ترجیح می‌دهند که به سوالاتِ بهتر جواب دهند. نوع رفتار شما شایستگی شما را برای دریافت جواب نشان می‌دهد. افراد شایسته زیرک، اندیشمند، هشیار و علاقمند به شرکت فعالانه در توسعهٔ یک راه‌حل هستند. بهترین راه برای گرفتن یک جواب سریع و خوب اینست که آن را مانند یک شخص زرنگ و مطمئن بپرسید، شخصی که واقعاً نیاز به کمک در یک مشکل خاص دارد. قبل از این که سوال کنید قبل از پرسیدن یک سوال فنی از طریق ایمیل، شبکه اجتماعی یا انجمن یک وبسایت، این کار‌ها را انجام دهید: سعی کنید جواب خود را با جستجو در ویکی‌پدیا و یا در قسمت‌های ویکی سایت مربوطه پیدا کنید. سعی کنید جواب خود را با جستجو در آرشیو انجمنی که می‌خواهید بفرسیتد، پیدا کنید. سعی کنید جواب خود را با جستجو در وب پیدا کنید. سعی کنید جواب خود را با خواندن manual (راهنما) پیدا کنید. سعی کنید جواب خود را با خواندن FAQ (سوالات متداول) پیدا کنید. سعی کنید جواب خود را از طریق بازبینی یا آزمایش پیدا کنید. سعی کنید جواب خود را با پرسیدن از یک دوست باتجربه پیدا کنید. اگر یک برنامه‌نویس هستید، سعی کنید جواب خود را با خواندن کدمنبع پیدا کنید. از فنونی استفاده کنید. برای مثال متن پیغام ارور را در گوگل جستجو کنید. حتی اگر به نتیجه ای نرسید، گفتن اینکه «من عبارت زیر را گوگل کردم، اما چیز امیدوار کننده‌ای پیدا نکردم» چیز خوبی برای یک گروه پستی یا خبری است، حداقل به این دلیل که مشخص می‌شود جستجو کمکی نمی‌کند. وقت بگذارید. انتظار نداشته باشد که بتوانید مشکل پیچیدهٔ خود را با چند ثانیه گوگل کردن حل کنید. FAQ ها را بخوانید و بفهمید، آرام و باتمرکز بنشنید و کمی در مورد مشکل خود فکر و گمانه‌زنی کنید. به یکباره تمام سوالات خود را ارسال نکنید فقط به خاطر اینکه اولین جستجوی شما به هیچ جوابی نرسید (یا به جواب‌های زیادی رسید). سوال خود را آماده کنید. به آن فکر کنید. سوالات شتاب‌زده به جواب‌های شتاب‌زده منجر خواهد شد، یا اصلاً به هیچ جوابی نمی‌رسد. هر چه بیشتر این را نشان دهید که برای حل مسئلهٔ خود قبل از درخواست کمک، فکر و تلاش کرده‌اید، همانقدر احتمال بیشتری خواهد رفت که واقعاً به شما کمک کنند. از پرسیدن سوال اشتباه، اجتناب کنید. اگر سوالی بپرسید که بر اساس فرض‌های ناقص و اشتباه است، یک فرد با تجربه ممکن است با این تصور که «یک سوال احمقانه است...» بخواهد به شما یک جواب لفظی و بی‌فایده بدهد، و به امید اینکه شما درس بگیرید از تجربهٔ گرفتن آنچه پرسیدید، نه آنچه مورد نیاز شما بود. ما وقتی می‌توانید به جواب برسید که یک سوال قابل توجه و برانگیزندهٔ ذهن بپرسید، سوالی که بطور ضمنی باعث کمک به تجربهٔ جامعه می‌شود، نه آنکه فقط بصورت انفعالی خواستار دانش از دیگران باشید. از طرف دیگر، روشن ساختن اینکه شما توانایی و تمایل کمک در پروسهٔ حل مسئله را دارید، شروع بسیار خوبی است. «آیا کسی می‌خواهد منبعی معرفی کند؟»، «مثال من چه چیز کم دارد؟»، و «چه وبسایتی را بهتر است بررسی کنم» به احتمال بیشتری جواب خواهند گرفت نسبت به این سوال که «لطفاً روش دقیق کاری که باید انجام دهم را بنویسید.». چون [در حالت اول] شما این را روشن می‌سازید که واقعاً راغب به تکمیل پروسه [ی حل مشکل] هستید اگر شخصی فقط مسیر صحیح را به شما نشان دهد. وقتی سوأل می‌کنید: انجمن خود را به دقت انتخاب کنید به این حساس باشید که کجا سوال خود را مطرح می‌کنید. شما احتمالاً نادیده گرفته خواهید شد اگر: سوال شما دارای عنوان مناسب نباشد. یک سوال بسیار ابتدایی را در انجمنی پست کنید که انتظار سوالات فنی پیشرفته را دارند. یا بالعکس. یک سوال مشترک را در چند گروه خبری پست کنید. در گروهی باشید که عنوان و موضوع آن مشخص است، اما با این حال بگویید کسی چیزی بلد هست یا خیر! یک ایمیل شخصی به کسی بفرستید که نه سابقه آشنایی با شما دارد، و نه شخصاً مسئول حل مشکل شماست. افراد با تجربه سوالاتی که بیجا در مکان خاصی پست شود را پاک می‌کنند تا کانالهای ارتباطی‌شان را از غرق شدن در بی‌ربطی حفظ کند. شما نمی‌خواهید این اتفاق برایتان بیفتد؛ بنابراین اولین قدم این است که انجمن درست را انتخاب کنید. باز هم، گوگل و سایر روشهای جستجوی وب، دوست شما هستند. از آنها استفاده کنید. رها کردن یک ایمیل به سوی شخص یا انجمنی که با آن آشنا نیستید، در بهترین حالت یک ریسک است. در مورد اینکه آیا سوال شما مورد استقبال واقع می‌شود یا نه، حدس‌های خوشبینانه نزنید. اگر مطمئن نیستید آن را جای دیگری بفرستید یا اینکه از فرستادن آن خودداری کنید. به یکباره سوال خود را به همهٔ کانال های کمک‌رسانی ارسال نکنید، این کار مانند فریاد زدن است و افراد را عصبانی می‌کند. به آرامی از میان آنها گام بردارید. عموماً سوالاتی که در یک انجمن عمومی و درست (بجا) پرسیده شوند، احتمال اینکه جواب مفید بگیرند بیشتر است تا آنهایی که در جای خصوصی پرسیده می‌شوند. چندین دلیل برای این وجود دارد. یک دلیل ساده، مقدار منابع پاسخگو است. یکی دیگر تعداد بازدیدکنندگان است؛ افراد با‌تجربه ترجیح می‌دهند به سوالاتی جواب دهند که افراد بیشتری را آموزش دهد، تا سوالاتی که فقط به درد افراد کمی بخورد. به وضوح، برنامه‌نویسان چیره‌دست و سازندگان نرم‌افزارهای محبوب، همواره بسیار بیشتر از توان پاسخ‌گویی‌شان، پیغام‌های انبوه و بی‌هدف دریافت می‌کنند. شما با اضافه شدن به این سیل، یکی از آن موارد بسیار زیاد هستید. از عناوین پرمعنا و دارای موضوع مشخص، استفاده کنید در لیست‌های پستی، گروه‌های خبری یا انجمن‌های وب، عنوانِ موضوع، فرصت طلایی شماست تا با حدود ۵۰ کاراکتر یا کمتر، توجه متخصصانِ قابل را جلب کنید. با عناوینی مثل «لطفاً به من کمک کنید»، آن را هدر ندهید (پیغام‌هایی با این‌گونه عناوین به راحتی دور انداخته می‌شوند). سعی نکنید با عمق اضطراب خود، افراد با تجربه را تحت تأثیر قرار دهید؛ در عوض، از آن فضا برای یک توصیف بسیار مختصر از مشکل خود استفاده کنید. نامطلوب: کمک! کتابخانه X روی لپ‌تاپ من درست کار نمی‌کند! هوشمندانه: با استفاده از امکانY از کتاب‌خانه X برنامه من کار نمی‌کند! هوشمندانه تر: با استفاده از امکان Y در کتاب‌خانه X نسخه 5.8 برنامه من کرش (Crash) می‌کند. تصور کنید که به یک لیست از سوالات یک آرشیو نگاه می‌کنید، که فقط خطوط عنوان‌ها نمایش داده می‌شوند. عنوان پست خود را طوری انتخاب کنید که بخوبی سوال شما را منعکس کنید، تا شخص بعدی که آرشیو را جستجو می‌کند، بتواند دنبال آن ریسمان (thread) را بگیرد و به یک جواب برسد، بجای اینکه دوباره آن سوال را پست کند. رسیدن یک سوال در یک پاسخ، به خودی خود مورد شک است، چون آن فقط توسط افرادی دیده خواهد شد که این ریسمان را دنبال می‌کنند. پس یک ریسمان (تاپیک) جدید را آغاز کنید، مگر اینکه مطمئنید می‌خواهید فقط از افرادی بپرسید که در حال حاضر در این ریسمان فعال هستند. پاسخ دادن را آسان کنید پایان دادن سوال با این عبارت که «لطفاً پاسخ خو را به ... بفرستید»، جواب گرفتن شما را کاملاً بعید می‌سازد. بصورت واضح، از لحاظ دستوری صحیح، و با املای صحیح بنویسید مهم است که سوال خود را واضح و خوب بیان کنید. قبل از ارسال سوال خود یکبار متن سوالتان را بررسی و سعی خود را بکنید تا زبان (بیان) خود را بهبود دهید (صیقل دهید). لازم نیست که رسمی و سنگین باشد. در واقع افراد با تجربه به آن طرز بیانی بها میدهند که غیر رسمی، عامیانه، شوخ‌طبعانه و همراه با دقت و ظرافت باشد. اما باید دقیق باشد؛ باید نشانه‌هایی از اینکه که شما اندیشه و توجه می‌کنید را داشته باشد. این نکته بسیار مهم است که به زبان رسمی آن کانال ارتباطی سوال خود را ارسال کنید. برای مثال اگر در انجمنی که زبان رسمی آن فارسی است سوال خود را به زبان انگلیسی (یا فینگلیش) بنویسید سوال شما معمولا یا پاک خواهد شد و یا نادیده گرفته می‌شود. اگر دارید سوال خود را در انجمنی می‌پرسید که از زبان بومی شما استفاده نمی‌کند، شما یک میزان محدودی از خطاهای املایی و دستوری خواهید داشت، اما از روی تنبلی دچار خطاهای بیش از حد نشوید (بله، افراد معمولاً می‌توانند آن تفاوت را تشخیص دهند). همینطور اگر نمی‌دانید که شخص پاسخگو چه زبانی دارد، به انگلیسی بنویسید. افراد با‌تجربه مشغول، سوالات با زبانی که نمی‌فهمند را نادیده می‌گیرند، و انگلیسی زبان کاری اینترنت است. با نوشتن به زبان انگلیسی، این احتمال را که سوالتان بدون خوانده شدن پاک شود، به حداقل می‌رسانید. سوال خود را در قالب‌های استاندارد و در دسترس مطرح کنید نامه خود را به صورت پاراگراف‌هایی که از خطوط به هم پیچیده شده تشکیل شده‌اند، نفرستید. این کار، پاسخ گویی به قسمت‌های مختلف نوشته شما را دشوار می‌کند. هرگز تصور نکنید که مخاطبین شما قادر به خواند فایل‌های اختصاصی مانند Microsoft word یا Excel هستند. افراد مختلف از سیستم عامل‌های مختلف و برنامه‌های متفاوتی برای ویرایش متن استفاده می‌کنند پس بهترین گزینه این است که فایل خود را به صورت متنی ارسال کنید. در صفحات گفتگو، از اشکال خندان (Smile) و امکانات HTML استفاده نکنید. یکی دو تا از این اشکال ایرادی ندارد. اما در صورت استفاده بیش از حد. بهای سوال شما را کاهش می‌دهد و احتمال نادیده گرفته شدن سوال شما افزایش پیدا می‌کند. اگر شما از یک پردازش‌گر ایمیل با صورت گرافیکی کاربری مانند MS، Outlook، Netscape، Messenger و یا از این‌گونه‌ها استفاده می‌کنید، آگاه باشید که در صورتی که از تنظیمات پیش‌فرض آن استفاده می‌کنید، ممکن است این قوانین نقض شوند. بیشتر این پردازشگرها دارای یک دستور در فهرست خود به نام view source هستند از این گزینه در پوشه نامه‌های فرستاده خود استفاده کنید و فرستادن نوشته ساده (plain tent) بدون ضمایم غیر ضروری را بررسی کنید. درباره مشکل خود دقیق و آگاه باشید نشانه‌های مشکل ایجاد شده یا bug ها را به دقت و روشنی شرح دهید. محیطی که در آن این مشکل ایجاد می‌شود را شرح دهید. (سیستم عامل، کاربرد و ...) شرکت فروشنده و مدل آنرا هم معرفی کنید مثلاً (Fedora Coret یا Slackware 91 و ...). مطالعاتی که بر روی این مشکل انجام داده‌اید را شرح دهید. مراحل تشخیص مشکل و رفع آنرا که انجام داده‌اید، قبل از طرح سوال، شرح دهید. هرگونه تغییر در سخت‌افزار یا نرم‌افزار که اخیراً انجام شده است را شرح دهید. تلاش کنید تا به سوالاتی که پیش‌بینی می‌کنید از شما پرسیده شوند، پیش‌تر پاسخ دهید. حجم مطالب دلیلی بر دقیق بودن آن نیست باید دقیق و آموزنده بنویسید. این هدف با نوشتن حجم زیادی از داده‌ها و کدها در نامه تقاضای کمک محقق نمی‌شود. اگر یک مشکل بزرگ و پیچیده دارید، سعی کنید تا آنرا تا حد ممکن خلاصه و مرتب ارائه کنید. این امر حداقل سه فایده دارد. اول اینکه معلوم شود که شما برای خلاصه کردن سؤال خود تلاش کرده‌اید یا تمایل بیشتری برای پاسخ به شما وجود خواهد داشت. دوم اینکه با خلاصه‌سازی پاسخ مفیدتری هم خواهید گرفت؛ و سوم اینکه در حین خلاصه کردن و پیرایش گزارش خود ممکن است بتوانید مشکل را حل کنید یا راه حل کوتاه‌تری برای آن پیدا کنید. بدون اطمینان ادعای یافتن یک bug را نکنید! هنگامی که با یک نرم‌افزار به مشکل برخوردید، بدون اطمینان کامل ادعای یافتن یک bug جدید را مطرح نکنید. راهنمایی: تا هنگامی که با یک ضمیمه به کد منبع نتوانید مشکل را برطرف کنید یا با آزمایش رگرسیون با ورژن قبلی که نشان دهنده یک رفتار نادرست باشد، شما نباید مطمئن شوید. این امر در مورد وب سایت‌ها و مدارک هم صدق می‌کند سندی را به عنوان bug یافتید، باید متنی را جایگزین آن کنید یادآوری می‌شود که کاربران بسیاری هستند که مشکل شما را تجربه نکرده‌اند. همچنین شما با خواندن مطالب و وب سایت‌های مرتبط، در مورد آن نرم‌افزار آموزش دیده‌اید در غیر این صورت شما کاری را اشتباه انجام می‌دهید و نه نرم‌افزار. افرادی که یک نرم‌افزار را تهیه می‌کنند، تلاش می‌کنند تا آن نرم‌افزار حداکثر کارایی مطلوب را داشته باشد. اگر شما ادعا کنید که یک bug در آن یافته‌اید، در واقع کامل بودن کار آنها را زیر سؤال برده‌اید و این باعث رنجاندن آنهان می‌شود، حتی اگر حق با شما باشد. به خصوص ذکر کلمه bug در عنوان نامه، کار سیاست مدارانه‌ای نیست. وقتی که سوال خود را مطرح می‌کنید، بهتر است فرض کنید که شما کار اشتباهی را انجام می‌دهید، حتی اگر مطمئن باشید که یک bug واقعی را یافته‌اید. اگر واقعاً این طور باشد، در مورد آن در پاسخ‌ها خواهید شنید. با این کار نگهدارنده‌های نرم‌افزار از شما عذرخواهی خواهند کرد، همچنین اگر شما اشتباه کرده باشید، باید از آنها عذرخواهی کنید. به جای حدس‌های خود نشانه‌های مشکل را شرح دهید نوشتن در مورد اینکه خودتان علت مشکل پیش آمده را چه می‌دانید، مفید نیست (اگر فرضیات شما به‌کلی اشتباه باشد آیا با دیگران مشورت می‌کنید؟). لذا سعی کنید که به دوست‌داران کامپیوتر از علائم و نشانه‌های اولیه مشکل موجود بگویید و نه از فرضیات و تئوری‌های خود. بگذارید آنها خود تفسیر کنند و مشکل را تشخیص دهند اگر احساس می‌کنید که ذکر کردن حدس خودتان می‌تواند مهم باشد، آنرا روشن و تحت عنوان حدس خودتان بیان کنید و همچنین ذکر کنیدن که چرا این پاسخ نمی‌تواند جوابگوی مسئله باشد. هدف را مشخص کنید، نه مرحله اگر به دنبال این هستید که بدانید چطور باید کاری را انجام دهید (مثل گزارش کردن یک اشکال یا bug )، با شرح دادن هدف خود شروع کنید. بعد از آن فقط برخی از مراحل خاص که برای رسیدن به آن طی کردید و موفق نشدید را شرح دهید. اغلب، افرادی که به کمک تکنیکی نیاز دارند، هدف بلند مرتبه‌ای را در ذهن می‌پرورانند و در راهی که فکر می‌کنند تنها راه رسیدن به هدف است گمراه می‌شوند. آنها برای کمک گرفتن مرحله به مرحله می‌آیند اما نمی‌دانند که مسیر اشتباه است تلاش قابل توجهی برای گذر از این مرحله مورد نیاز است. سوال نامطلوب: چگونه می‌توان در برنامه FooDraw مقادیر RGB رنگ را بر مبنای شانزده‌تایی انتخاب کرد؟ سوال هوشمندانه: من تلاش می‌کنم که جدول رنگ‌ها را روی یک تصویر با مقادیر انتخابی خودم قرار دهم. در حال حاضر تنها راهی که به نظرم می‌رسد اینست که هر ردیف از جدول را اصلاح کنم اما نمی‌توانم در برنامه FooDraw رنگ‌ها را بر مبنای مقادیر RGB شانزده‌تایی انتخاب کنم. سوال دوم هوشمندانه بود. جواب این سوال ابزار بهتری برای آن کار را پیشنهاد می‌دهد. سوال را صریح مطرح کنید برای سوال‌هایی که انتهای مشخصی ندارد، بازه زمانی محدودی برای پاسخگویی به آنها در نظر گرفته نمی‌شود. کسانی که می‌خواهند پاسخ‌های مفیدی به شما بدهند، مشغول‌ترین افراد هستند. (چون در اغلب کارها به تنهایی کار می‌کنند). این گونه افراد نسبت به سوال‌هایی با بازه زمانی نامحدود حساسیت دارند و تمایل چندانی به پاسخ‌گویی به آنها ندارند. شما هنگامی که یک پاسخ مفید دریافت می‌کنید که از پاسخگویی خود در مورد چیزی که می‌خواهید به‌طور صریح پرسیده باشید (از اشاره‌گر استفاده کند، که بفرستید، پیوست را بررسی کنید یا هر چیز دیگر). این کار تلاش پاسخگو را بر روی هدف شما متمرکز می‌کند و به طور ضمنی حدی از نظر زمانی برای پاسخگویی و صرف انرژی برای کمک به شما ایجاد می‌کند. این کار خوبی است. برای درک دنیایی که متخصصین در آن زندگی می‌کنند، به مهارت به عنوان یک منبع و زمان فراوان برای پاسخگویی به یک مورد کمیاب فکر کنید. هر چه زمان کمتری را برای پاسخگویی به سوال خود به طور ضمنی در نظر بگیرید، احتمال اینکه جواب واقعاً مناسب از جانب یک فرد خبره و پرمشغله دریافت کنید، بیشتر می‌شود بنابراین بهتر است که برای سوال خود قالبی در نظر بگیرید که زمان مورد نیاز به پاسخگویی به آن را از جانب یک فرد خبره به حداقل برساند. اما این کار اغلب مشابه ساده‌سازی یک سوال نیست. به عنوان مثال، ممکن است برای شرح مناسبی از X یک راهنمایی بکنید؟ معمولاً سوال هوشمندانه‌تری است نسبت به اینکه ممکن است لطفاً X را توضیح دهید! اگر شما یک کد نادرست دارید، بهتر است در مورد اینکه چه اشکالی دارد بپرسید تا اینکه درخواست کنید کسی آنرا اصلاح کند. سوالهای بی‌معنی را حذف کنید از به پایان رساندن درخواست سوال خود با جملات بی‌مفهومی مانند کسی می‌تواند به من کمک کند؟ یا آیا جوابی وجود دارد؟ پرهیز کنید. اولاً، اگر شرح خود را تا نیمه نوشته بودید، این گونه سوال‌ها زائد هستند. دوماً، به دلیل زائد بودن آنها کاربران آنها را آزاردهنده تلقی می‌کنند و احتمال دارد که جواب‌هایی بی عیب و نقص ولی بی اعتنا مانند بله، به شما می‌توان کمک کرد. یا خیر، هیچ کمکی نمی‌توان کرد به شما بدهند. به طور کلی، از سوالهای آری یا خیر باید اجتناب شود مگر اینکه تنها جواب بله یا خیر برای شما کافی باشد. سوال خود را با کلمه «فوری» نشانه‌دار نکنید، حتی اگر برای شما اینگونه باشد: این مشکل شماست، نه دیگران. اظهار ضرورت کردن نتیجه معکوس می‌دهد. بیشتر کاربران به راحتی اینگونه سوال‌ها را که با خودخواهی و گستاخی درخواست توجه فوری و ویژه می‌کنند را حذف می‌کنند. تنها یک شبه استثناء وجود دارد. اگر شما در یک محل با مرتبه بالا و با یک نرم‌افزار کار می‌کنید و از نظر زمانی تحت فشار هستید، گفتن مودبانه محدودیت زمانی خود می‌تواند مؤثر باشد تا دیگران را به پاسخ دادن به شما ترغیب کند. البته این کار ریسک بالایی دارد، چون معیار جالب بودن مسائل از نظر کاربران دیگر با شما متفاوت است. به عنوان مثال فرستادن نامه از یک ایستگاه فضایی بین‌المللی قانع کننده است اما از جانب یک انسان با احساس خوب و مهربان یا یک سیاستمدار خیر. در واقع، نوشتن کلمه «فوری» باعث می‌شود که از سوال شما اجتناب و دوری شود حتی اگر از نظر آنها مهم باشد. اگر فکر می‌کنید که این امری مبهم است، دوباره این مطالب را بخوانید تا کاملاً آنرا درک کنید، قبل از آنکه نوشته‌ای را به جایی بفرستید. ادب و احترام را رعایت کنید مؤدب باشید. از جملاتی مانند «لطفاً» و «با تشکر از توجه شما» یا «ممنون از ملاحظه شما» استفاده کنید. به طور واضح بیان کنید که شما اینکه دیگران وقت خود را برای کمک به شما رایگان صرف می‌کنند، تحسین کنید. صادق بودن، به اندازه واضح، دقیق، با دستور زبان صحیح و مشروح بودن و پرهیز از قالب‌های مالکانه، مهم نیست و حتی جایگزین آنها هم نمی‌تواند باشد. کاربران بطور کلی علاقه دارند که گزارش‌های دقیق تکنیکی از bug ها و ایرادها را هر چند بی ادبانه دریافت کنند تا نوشته‌های مؤدب ولی ابهام‌آمیز. (اگر این امر برای شما مبهم است، به یاد داشته باشید که سوال‌ها را با چیزی که توسط آن می‌توان یاد گرفت ارزش‌گذاری می‌کنند). به هر حال اگر مشکلات تکنیکی خود را ردیف کنید، مؤدب بودن شانس شما را برای دریافت پاسخ مفید افزایش می‌دهد. باید ذکر شود که تنها مخالفتی که از سوی کاربران قدیمی نسبت به این نوشته دریافت کرده‌ایم، در رابطه با توصیه‌های قبلی ما برای تشکر پیشاپیش است. برخی از کاربران احساس می‌کنند که این دلالتی به منظوری دارد و نه تشکر. توصیه ما اینست که هم پیشاپیش تشکر کنید و هم بعد از پاسخ‌گویی و یا ادب و احترام را به روشهای دیگری بیان کنید قبلاً با جملاتی مثل: «با تشکر از توجه شما» یا «ممنون از ملاحظه شما». روش حل را با یادداشت مختصری پاسخ دهید بعد از اینکه مسئله حل شد، یادداشتی به همه کسانی که به شما کمک کرده‌اند بفرستید، آنها را از نحوهٔ حل مطلع کنید؛ و باز هم از یاری آنها تشکر کنید. پاسخ شما نباید طولانی و شامل جملاتی ساده مثل: «ایراد از کابل شبکه بود، با تشکر از همه» باشد. حتی اگر پاسخ ندهید، بهتر از این جملات است. پاسخ کوتاه و خلاصه‌ای شیرین بهتر است از یک مقاله طولانی مگر اینکه عمق تکنیکی مسئله زیاد باشد. ذکر کنید که چه عملی مشکل را حل کرد اما لزومی ندارد که تمام مراحل حل مشکل را گزارش کنید. برای برخی از مسائل مناسب است که خلاصه‌ای از مراحل رفع مشکل را گزارش کنید. وضعیت نهایی مسئله خود را شرح دهید. توضیح دهید که چه روشی شما را به حل رساند و بعد از آن به داده‌هایی که جواب نمی‌رسد اشاره کنید. روشهای اشتباه را باید بعد از جواب صحیح و دیگر مطالب خلاصه بیاورید تا اینکه خلاصه شما تبدیل به یک داستان کارآگاهی نشود. از افرادی که به شما کمک کردند نام ببرید، با این کار با آنها دوست هم می‌شوید. در نهایت، این گونه خلاصه نویسی به تمام کسانی که کمک کرده‌اند، احساس رضایت‌مندی و نزدیکی به مسئله می‌دهد و این کم ارزش نیست. اگر شما یک تکنسین یا فرد باتجربه نیستید، مطمئن باشید که این احساس برای راهنماها و متخصصینی که از آنها کمک گرفته‌اید، بسیار مهم است. اگر نفهمیدید... اگر جواب را نفهمیدید، فوراً تقاضای روشن کردن پاسخ نکنید. از همان اندازه‎هایی که برای پاسخ اولیه خودتان (دستورالعمل‎ها ( FAQS)، وب و دوستان ماهر) برای فهمیدن جواب استفاده کنید. سپس اگر باز هم نیاز به شفاف سازی نشان دهید که چه چیزی یادگرفته‎اید. برای مثال تصور کنید که من به شما می‎گویم: "به‎نظر می‎رسد که شما Zentry گرفته شده‎ای دارید، باید آنرا تمیز کنید." در این صورت یک جواب نامناسب این خواهد بود: « Zentry چیست؟» و یک جواب خوب این خواهد بود "بسیار خوب، من صفحه اصلی را خواندم و به Zentry ها تحت عنوان سوئیچ‎های –Z و –P اشاره شده است اما هیچ یک از تمیز کردن Zentry چیزی نگفته‎اند. آیا اینها درست است یا من نکته‎ای را متوجه نشده‎ام؟" اخلاق حرفه ای داشته باشید با توجه به راه‎های مفصلی که در این‎جا گفته شد یا راه‎های مشابه بعید است که در راه‌های ارتباطی با افراد باتجربه اشتباه کنید. به‎طور دقیقی با جملات متفاوت به شما گفتیم که چگونه می‎توان اشتباه کرد. اگر چنین اتفاقی افتاد بدترین کار اینست که از این تجربه خود ناله کنید، ادعا کنید که شفاهاً مورد توهین قرار گرفته‎اید، تقاضای عذرخواهی کنید، نقستان را حبس کنید، به شکایت کردن تهدید کنید، از افراد شکایت کنید و غیره. در عوض پیش بروید. این امری طبیعی است. درواقع مناسب و سالم است. گاهی اوقات افراد بدون هیچ دلیل روشنی شخصاً شما را مورد حمله قرار می‎دهند حتی اگر شما اشتباهی نکرده باشید (یا فقط در ذهن آنها دچار اشتباه شده‎اید) در این موارد، شکایت کردن روشی واقعاً اشتباه است. این افرادِ متجاوز، نادان هم هستند که بدون هیچ دلیلی، خود را با تجربه می‎دانند یا با آزمایش‎های روان‎شناسی می‎خواهند بدانند که اشتباه کرده‎اید یا خیر. خوانندگان دیگر هم آنها را نادیده می‎گیرند و یا با روش خودشان با آنها برخورد می‎کنند رفتار این‎گونه افراد خود آنها را دچار مشکل می‎کند که به شما ربطی ندارد. اجازه ندهید که داخل این‎گونه بحث‎ها به دام بیفتید. بعد از اینکه بررسی کردید که آیا آنها واقعاً توهین هستند و نه اشاره‎ای به اشتباه شما و نه اشاره‎ای به اشتباه شما و نه اشاره‎ای زیرکانه به جواب واقعی سوال شما اغلب توهین‎ها نادیده گرفته می‎شوند. به اطلاعات موجود در فایل های ارسالی و ضمیمه توجه کنید در بسیاری از مواقع ممکن است سوال شما همراه با فایل (یا فایل های) ضمیمه‌ای باشد که مشکل را دقیق‌تر به پاسخ دهند‌گان شرح میدهد. حتما قبل از ارسال فایل ضمیمه به موارد زیر توجه کنید: فایل ارسالی حاوی اطلاعات شخصی افراد نباشد. این موارد حریم شخصی افراد را نقض میکند و ممنوع می‌باشد. در صورتی که سوال شما مربوط به نحوهٔ نمایش آن اطلاعات است میتوانید با ابزار ویرایش تصویر یا فایل، اطلاعات شخصی را حذف کنید. توصیه می‌شود که در زمان جستجوی محتوا از طریق موتور‌های جستجو‌گر مانند گوگل، به توصیه‌های رسمی در نحوهٔ جستجوی پیش‌رفته توجه کنید.
  6. کامبیز اسدزاده

    قوانین نگارشی جهت نشر محتوا

    قوانین و قالب اصول نگارشی در مرجع آی او استریم نسخهٔ 1.3.0 با توجه به اهداف مرجع، ارائه اسناد و محتوای معتبر رعایت اصول صحیح نگارشی در ترجمه، بازنشر و دیگر شرایط تولید محتوا نیاز است. بنابر‌این برای یادگیری شیوه نگارش و نحوهٔ صحیح نوشتن شما می‌توانید شیوهٔ صحیح نوشتن و استفاده از علائم نگارشی را بیاموزید. متن زیر بر همین اساس آماده شده است و به مرور زمان تکمیل خواهد شد. توجه داشته باشید که شرایط زیر در سراسر سیستم نرم‌افزاری که شامل ماژول‌های مختلفی چون (خبر، وبلاگ، پادکست، مستندات و ...) می‌شود. و عدم رعایت آن موجب عدم تایید و حتی لغو مقاله شما خواهد گردید. قبل از هر چیز به نمونه مثال زیر توجه کنید: عنوان آزمایشی متن (انتخاب سر نویس ۳) این متن آزمایشی است جهت نمایش یک پاراگراف از اندازه، چیدمان و دیگر موارد نگارشی که بدون اعمال هیچ گونه اندازه و سر نویسی نوشته شده است. برای اینکه پاراگراف‌های زیب و یک‌دست در سرتاسر وب سایت داشته باشیم لازم است این قانون را رعایت نماییم. با توجه به اهداف مرجع ممکن است در آموزش‌های شما در میان متن فارسی از متن انگلیسی یا کد‌های برنامه نویسی استفاده کنید که برای مثال : کتابخانه STL یک کتابخانهٔ استاندارد کتابخانه‌ای با نام iostream وجود دارد که با تکه کد #include <iostream> وارد می‌شود. برای حل این مشکل آن تگ < > کد را بر روی نوشته خود اعمال کنید#include <iostream>نتیجه به صورت یک تکه کد درون خطی نمایش داده می‌شود. در برخی موارد کاراکتر‌های خاص مانند C++ لازم است به صورت صحیح نوشته شود، معمولاً برای این کار آن را به صورت برعکس می‌نویسد اما این کار پیشنهاد نمی‌شود چرا که در بحث سئو تاثیر منفی خواهد گذاشت. ما برای حل این مشکل یک افزونه با عنوان L در نظر گرفته ایم که می‌توانید کاراکتر‌های خود را انتخاب کنید و آن را بر روی آن اعمال نمایید. مثال : زبان برنامه‌نویسی C++ بدون اعمال تگ L مثال : زبان برنامه‌نویسی C++ تگ L اعمال شده است بنابراین نکاتی که همه ما به آن در تولید محتوا توجه می‌کنیم به صورت زیر هستند: قبل از شروع نگارش فارسی به «راست چین بودن» محیط ویرایشگر توجه می‌کنیم. برای نگارش صحیح فارسی از صفحه کلید استاندارد فارسی در ویندوز و گنو/لینوکس و مک استفاده می‌کنیم. این صفحه کلید به صورت پیش‌فرض در سیستم عامل گنو/لینوکس و مک نصب است. همینطور در نسخه‌های جدید ویندوز(از ۸ و به بعد) قابل فعال‌سازی در این سیستم عامل نیز است. در جملات از «می‌باشد» و «نمی‌باشد» استفاده نمی‌کنیم. معادل این کلمات به ترتیب «است» و «نیست» است. معادل واژه‌ها بسیار مهم هستند، برای مثال کیبورد معادلش در فارسی صفحه‌کلید است و بهتر است از معادل فارسی استاندارد استفاده شود. در نگارش صحیح فارسی هیچ‌گاه پیشوندها و پسوندها به صورت چسبیده نوشته نمی‌شوند. مثلاً: نمیشوند، میروم، جنگلها، پرندهگان، طراحیها، آنها و… همگی غلط هستند. برای نوشتن پیشوندها و پسوندها به صورت جداگانه، چنانچه حروف دو بخش به صورت پیش‌فرض احتمال چسبیدن به هم را داشته باشند برای جداسازی آن‌ها از نیم فاصله استفاده می‌کنیم. مثلاً: نمی‌شود، می‌شود، توسعه‌دهنده، برنامه‌نویس، کسب‌و‌کار‌، می‌رسم، نمی‌خورم، گله‌ها، سبزه‌زار‌ها، طراحی‌ها، آن‌ها و… همگی درست هستند. برای درج نیم فاصله در صفحه کلید استاندارد فارسی از Shift + Space که تقریبا در تمامی سیستم‌عامل‌ها همین ترکیب را دارد استفاده می‌کنیم. در هنگام استفاده از کاراکترها (نظیر . ! ؟ ، … : ؛) باید به این نکته توجه کرد که آن‌ها بدون هیچ فاصله‌ای به کلمه قبل از خود می‌چسبند. همینطور پس از آن‌ها همیشه یک فاصله وجود دارد. چنانچه در متن از کلمات و یا عباراتی به زبانی دیگر استفاده شده بود حتماً در نخستین جایی که از آن کلمات و یا عبارات استفاده می‌کنیم باید معادل آن به زبان اصلی در درون پرانتز و بلافاصله پس از استفاده درج شود. مثلاً جملات زیر را در نظر بگیرید: پردازنده و رم (RAM) رایانه حتماً باید با هم سازگاری داشته باشند. زبان برنامه‌نویسی سی‌پلاس‌پلاس (++C) و فناوری کیوت کوئیک (Qt Quick). جی. کی. رولینگ (J. K. Rowling) خالق مجموعه داستان‌های هری پاتر (Harry Potter) در مصاحبه اخیر خود با بی بی سی (BBC) از قصد خود در خصوص نوشتن سری جدیدی از داستان‌ها خبر داد. نوروزبل (نؤرۊزبل) عید باستانی مردم خطه کاسپین است. به هیچ عنوان هیچ یک از اصطلاحات علمی را به فارسی نباید ترجمه و باز نشر کنیم، برای مثال : فناوری کیوت کوئیک (فناوری کیوت سریع) این غلط است. چنانچه در متن از کلمات و یا عبارتی به زبان فارسی استفاده شود که معادل غیر فارسی آن مفهوم را به شکل بهتری برساند، معادل غیر فارسی در هنگام نخستین استفاده در درون پرانتز نوشته می‌شود. مثلاً جملات زیر را در نظر بگیرید: راهنمای فایل (File Directory) یکی از روش‌های رایج دسترسی به فایل‌ها در سیستم عامل‌ها است. طراحی رابط کاربری (UI) و تجربه کاربری (UX) دو مقوله جدا از هم هستند. چنانچه در متن از عبارات مخفف (فارسی و یا غیر فارسی) استفاده کرده باشیم در نخستین استفاده حتماً باید عبارت کامل در درون پرانتز درج شود. مثلاً جملات زیر را در نظر بگیرید: جهت استفاده از کتابخانه‌هایی چون Qt باید (سطوح مقدماتی و متوسط زبان برنامه‌نویسی ++C) را به خوبی پشت گذاشته باشید. جَک JAC (Jangal Accounts)) سیستم یکپارچه‌ای برای مدیریت حساب‌های کاربری در سرویس‌های گوناگون است که توسط شرکت جنگل ساخته شده و مورد استفاده قرار می‌گیرد. هرگاه در متن نیاز به درج توضیحات تکمیلی باشد از پرانتز استفاده می‌کنیم. مثلا: دات‌ویوز (شرکت دات‌ویوز (Dotwaves) با (مسئولیت محدود)) بزرگترین تولید کننده نرم‌افزار در شمال غرب کشور است. متن باید دارای افعالی یکپارچه باشد. این بدان معناست که فعل‌های خبری متن همگی باید دارای یک نقش باشند. مثلاً اگر در حال نوشتن متن دستور پخت یک غذا باشیم، عبارت زیر غلط خواهد بود: برای طراحی یک نرم‌افزار تحت کیوت ابتدا باید محیط توسعه را نصب و راه اندازی کرد. سپس تحت زبان برنامه‌نویسی ++C و فناوری Qt Quick آن را طراحی و توسعه می‌دهیم. متن باید دارای لحنی یکپارچه باشد. مثلاً اگر در قسمتی از متن از زبان محاوره استفاده کردیم در جای دیگر نباشد از زبان کتابی صحبت کنیم. مثلاً ۲ جمله اول هر دو درست هستند ولی جمله سوم غلط است. قراره من در این آموزش برای شما بگم که چطور در رابطه با برنامه‌نویسی سطح پایین دانشتان را ارتقا دهید! (غلط) قراره من در این آموزش برای شما بگم که چطور در رابطه با برنامه‌نویسی سطح پایین دانشتون رو ارتقا بدین (صحیح) قرار است من در این آموزش برای شما نحوه ارتقا دانشتان در برنامه‌نویسی سطح پایین را توضیح دهم. (صحیح) در متن هرجا که لازم باشد به مهم بودن بخشی خاص اشاره شود آن را بلد (Bold) می‌کنیم. مثال: آوردن ماشین حساب در امتحان ریاضی مهندسی ممنوع نیست. در پاراگراف‌های موجود در متن باید سعی شود که تا جایی که امکان دارد در جملات پشت سر هم از کلمات یکسان استفاده نشود. مثلاً متن زیر به خاطر تکرار کلمات یکسان (در این مثال جاوا اسکریپت و است) متن زیبایی نیست: جاوا اسکریپن یک زبان پر طرفدار است. جاوا اسکریپت پر کاربرد ترین زبان در لایه رابط کاربری است. جاوا اسکریپت ملقب به نام «JS» است. چنانچه در متن بخواهیم یکپارچگی عبارتی را نشان دهیم آن را درون «» قرار می‌دهیم. این کار برای سهولت خواندن متن انجام می‌شود. چنانچه در متن بخواهیم که جمله‌ای را نقل قول کنیم آن را در درون «» قرار می‌دهیم. اگر متن نقل قول شده بیشتر از یک جمله بود به غیر از استفاده از علامت فوق از فونتی کوچکتر و یا اتالیک (Italic) استفاده می‌شود. البته برای راحتی کار و یکسان بودن بهتر است بر روی دکمه قالب روی ویرایستار کلیک کرده و از بخش بلوک‌ (بلوک نقل قول) را انتخاب کنید. در محیط وب اگر در متن از کلمات و یا عباراتی استفاده شود که توضیحاتی مفصل از آن در جایی دیگر موجود باشد، آن کلمات و یا عبارات را به همان جایی که توضیحات مفصل آن وجود دارد پیوند (Link) می‌کنیم. در هنگام لینک کردن عبارات در وب چنانچه لینک مورد نظر خارج از آدرسی خارج از سایت خودمان باشد حتماً باید لینک در تبی (Tab) جداگانه باز شود. در هنگام لینک کردن عبارات حتماً برای آن عنوانی (Title) در نظر می‌گیریم. این عنوان زمانی که ماوس بر روی لینک قرار بگیرد نمایش داده می‌شود. این عنوان باید متنی باشد که توضیحات بیشتر را در مورد لینک بدهد. مثلاً اگر کلمه رشت را به صفحه ویکی‌پدیا فارسی رشت لینک کرده‌ایم یکی از عنوان‌های مناسب می‌تواند «در مورد رشت در ویکی‌پدیا فارسی بیشتر بخوانید.» باشد. چنانچه در محیط وب متنی را از جایی نقل و قول (و یا کپی) کردیم حتماً باید در صفحه خودمان به آن مطلب لینک بدهیم. این لینک می‌تواند درون متنی باشد و یا اینکه در انتهای متن‌مان به عنوان منبع ذکر شود. در وب چنانچه مایل به استفاده از تصاویر در متن‌مان بودیم حتماً مسأله اندازه (حجم)‌آن را در نظر می‌گیریم. معمولاً از تصاویر با حجم پایین در درون متن استفاده می‌شود و اگر لازم بود که خواننده به تصویر با اندازه اصلی دسترسی داشته باشد معمولاً این تصویر به تصویر کم حجم موجود در متن لینک می‌شود. در نوشتن مطالب از فونت‌های عجیب و غیر استاندارد و یا اندازه‌های بسیار بزرگ/کوچک استفاده نمی‌کنیم. هر چند فونت‌های استاندارد بر روی ویرایستار تعبیه شده است اما همینطور حتی‌الامکان رنگ‌ها و فونت و اندازه‌های پیش‌فرض را تغییر نمی‌دهیم. (مگر اینکه واقعاً در مواردی خاص نیاز به این کار باشد.) کاراکترهای اعداد در زبان‌ فارسی با زبان‌هایی نظیر انگلیسی و عربی کاملاً متفاوت است. در نگارش فارسی فقط و فقط از کاراکترهای فارسی اعداد استفاده می‌کنیم. این کاراکترها ۱۲۳۴۵۶۷۸۹۰ هستند. تنها زمانی مجاز به استفاده از کاراکترهای اعداد انگلیسی و عربی هستیم که در حال ذکر معادل‌های غیر فارسی باشیم. مثلا: فایل ام پی تری (MP3) یکی از فرمت‌های رایج موسیقی است. ام فور (M4) یکی از اسلحه‌های رایج بازی کانتر است. در لیست‌ها اعداد شماره‌گذاری را به صورت دستی وارد نمی‌کنیم! برای این کار از ابزار تعبیه شده در محیط نگارش استفاده می‌کنیم. (همینطور در لیست‌های غیر مرتب نیز کاراکترهای شروع کننده پاراگراف را دستی وارد نمی‌کنیم.) در نگارش جدید فارسی از ی مالکیت استفاده نمی‌شود. مثلاً عبارات زیر همگی غلط هستند: خانهٔ ما علاقهٔ مفرط پذیرندهٔ جدید برخی از کاراکترها نظیر ی و ک در فارسی متفاوت با عربی است. در نگارش فارسی دقت می‌کنیم که از کاراکترهای عربی استفاده نکنیم. برای خوانایی متن و بالا بردن درک مطلب از پاراگراف‌ استفاده می‌کنیم. هر پاراگراف متشکل از یک یا چند جمله است که نزدیکی محتوایی دارند. پس از اتمام پاراگراف فارغ از اینکه جمله نهایی در کجا به پایان رسیده است به خط بعدی می‌رویم. پس از انتشار مطلب در محیط وب چنانچه پس از گذشت مدتی طولانی قسمتی از متن با حقایق روز متفاوت بود بر روی آن خط می‌کشیم. همچنین اگر لازم بود بخشی را به عنوان اصلاحیه اضافه می‌کنیم. متن زیر را در نظر بگیرید: سیستم عامل مَک او اِس ایکس (Mac OS X) در حال حاضر جدیدترین سیستم عامل ساخته شده توسط شرکت اپل (Apple) است. یکی از ویژگی‌های جدید افزوده شده به این سیستم عامل ظاهر بسیار زیبای آن است. حال این متن را پس از گذشت چند سال به شکل زیر تغییر می‌دهیم: سیستم عامل مَک او اِس ایکس (Mac OS X) در حال حاضر جدیدترین سیستم عامل ساخته شده توسط شرکت اپل (Apple) است. (در حال حاضرسیستم عامل مَک او اِس سییرا (macOS Sierra) جدیدترین سیستم عامل اپل است.) یکی از ویژگی‌های جدید افزوده شده به این سیستم عامل ظاهر بسیار زیبای آن است. اگر در متن در حال توضیح موضوع خاصی هستیم بهتر است که در جاهایی از معادل‌های مترادف آن موضوع استفاده کنیم. مثلاً اگر در حال معرفی یک نرم‌افزار هستیم می‌توانیم برای اشاره به آن از کلماتی نظیر نرم افزار، برنامه، اپ و اپلیکیشن استفاده کنیم. به طور کلی در متن از کلمات و عباراتی که از زبان دیگری آمده‌اند استفاده نمی‌کنیم ولی این مسأله نباید باعث کاهش خوانایی و مفهوم متن شود. ساده نویسی یکی از اصول اصلی نگارش است. اینکه از چه مجموعه از کلمات و عباراتی در متن‌مان استفاده کنیم بستگی به سطح خوانندگان‌مان دارد. مثلاً اگر در حال نوشتن یک متن برای برنامه نویسان هستیم به راحتی می‌توانیم از کلماتی نظیر UX و UI و.. استفاده کنیم ولی استفاده از این کلمات در یک متن عمومی توصیه نمی‌شود و در صورت استفاده حتماً باید معانی آن‌ها به صورت کامل در درون پرانتز و یا پاورقی درج شود. روش ارسال کد‌ در قالب مناسب برای درک بهتر مطلب توسط ابزار <> در صورتی که مقاله، سند یا مطلب خاصی را منتشر می‌کنید که دارای تکه کدی است آن را در داخل تگ کد قرار می‌دهیم که نمونه مثال‌های آن به صورت زیر نمایان خواهند شد: نمونه مثال خروجی کد C //A Hello World! program in C. #include <stdio.h> int main() { // printf() displays the string inside quotation printf("Hello, World!"); return 0; } نمونه مثال خروجی کد ++C // A Hello World! program in C++. #include <iostream> using namespace std; int main() { cout << "Hello, World!"; return 0; } نمونه مثال خروجی کد در Java //A Hello World! program in Java. public class HelloWorld { public static void main( String[] args ) { System.out.println( "Hello World!" ); System.exit( 0 ); //success } } نمونه مثال خروجی کد در JavaScript // A Hello World! program in JavaScript. const btn = document.getElementById('button'); btn.addEventListener('click', function() { alert('Hello World!'); نمونه مثال خروجی کد در QML // A Hello World! program in QML. import QtQuick 2.0 Rectangle { id: page width: 320; height: 480 color: "lightgray" Text { id: helloText text: "Hello world!" y: 30 anchors.horizontalCenter: page.horizontalCenter font.pointSize: 24; font.bold: true } } نمونه مثال خروجی کد در PHP // A Hello World! program in PHP. $text = "Hello, World!"; $x = 5; $y = 4; echo "<h2>" . $text . "h2><br>"; echo $x + $y; نمونه مثال خروجی کد در Node.JS // A Hello World! program in Node.JS const express = require('express') const app = express() app.get('/', (req, res) => res.send('Hello World!')) app.listen(3000, () => console.log('Example app listening on port 3000!')) نمونه مثال خروجی کد در CSS p { text-align: center; color: red; } نمونه مثال خروجی کد در #C // A Hello World! program in C#. using System; namespace HelloWorld { class Hello { static void Main() { Console.WriteLine("Hello World!"); // Keep the console window open in debug mode. Console.WriteLine("Press any key to exit."); Console.ReadKey(); } } } نمونه مثال خروجی کد در Ruby #!/usr/bin/ruby print "Hello, World!\n" نمونه مثال خروجی کد در Python # This program prints Hello, world in Python! print('Hello, world!') و اما یک نکته‌‌ی اساسی در نشر محتوا این است که برای مخفی نگه داشتن بخشی از پاسخ‌ها که نیاز نیست برای همه قابل نمایش باشد از گزینه اسپویلر یا همان مخفی کردن با علامت چشم بر روی ادیتور استفاده می‌کنیم تا محتوا به صورت همین نمونه نمایان شود.
  7. کامبیز اسدزاده

    مقدمه در دنیای برنامه‌نویسی، نوع جوابی که برای سوالات فنی خود می‌گیرید، هر چقدر که به سختی جواب دادن سوال بستگی دارد، همانقدر هم به روش پرسیدن شما بستگی دارد. با مطالعه‌ی این راهنما قادر خواهید بود طوری سوال کنید که به احتمال بیشتری جواب رضایت بخشی دریافت کنید. هدف ما از این سند در مرجع برنامه نویسی ایران، این است که فرهنگ مکاتبه و رسیدگی به مشکلات همدیگر را در زمینه‌های مرتبط افزایش و بهینه سازی کنیم. بنابراین، امروزه که برنامه‌نویسی بیش از پیش گسترده شده، می‌توانید از وجود افراد با‌تجربه استفاده کنید و جواب‌های خوبی دریافت کنید. با این حال حتی اگر افراد با‌تجربه هم برای پرسیدن سوال روش‌های توصیه شده در این راهنما را به کار گیرند جواب‌های مفید‌تری دریافت می‌کنند. اولین چیزی که باید درک کنیم این است که افراد با‌تجربه سوال های سخت و طولانی را دوست دارند که به خوبی ذهن را درگیر می‌کند. اگر به ما یک سوال جالب توجه بدهید که به آن فکر کنیم از شما سپاس‌گزار خواهیم شد. سوالات خوب محرک ذهن بوده و یک هدیه هستند. سوالات خوب به ما کمک میکنند تا فهم خود را توسعه دهیم و عموماً باعث آشکار شدن مشکلاتی میشود که ممکن است ما ندانیم یا به آنها توجهی نکرده باشیم. در میان افراد با‌تجربه یک سوال خوب یک چالش مهیج است. با این وجود بسیاری از تازه‌کار ها گمان میکنند که افراد با‌تجربه در مقابل سوالات ساده با دشمنی و تکبر برخورد می‌کنند و به نظر می‌رسد که واکنش گستاخانه‌ای با افراد تازه‌کار و ناآگاه دارند. اما به هیچ وجه این‌طور نیست! چیزی که بدون شرمندگی باید بگوییم، خصومت با افرادی است که ظاهراً تمایلی به تفکر در موضوع ندارند و جواب دادن به سوالشان را به نوعی وظیفه‌ی افراد با تجربه می‌دانند. از دید افراد با‌تجربه چنین افرادی باعث هدر رفتن وقت می‌شوند پس وقت خود را صَرف جواب دادن به سوالات بهتر میکنند. همچین افراد با‌تجربه بسیار داوطلب هستند و در زمان‌هایی که مشغول نباشند به پاسخ دادن به سوالات می‌پردازند. در آن مواقع غرق سوالات هستند. پس بدون ترس سوالات را فیلتر می‌کنند و ترجیح می‌دهند که به سوالاتِ بهتر جواب دهند. نوع رفتار شما شایستگی شما را برای دریافت جواب نشان می‌دهد. افراد شایسته زیرک، اندیشمند، هشیار و علاقمند به شرکت فعالانه در توسعهٔ یک راه‌حل هستند. بهترین راه برای گرفتن یک جواب سریع و خوب اینست که آن را مانند یک شخص زرنگ و مطمئن بپرسید، شخصی که واقعاً نیاز به کمک در یک مشکل خاص دارد. قبل از این که سوال کنید قبل از پرسیدن یک سوال فنی از طریق ایمیل، شبکه اجتماعی یا انجمن یک وبسایت، این کار‌ها را انجام دهید: سعی کنید جواب خود را با جستجو در ویکی‌پدیا و یا در قسمت‌های ویکی سایت مربوطه پیدا کنید. سعی کنید جواب خود را با جستجو در آرشیو انجمنی که می‌خواهید بفرسیتد، پیدا کنید. سعی کنید جواب خود را با جستجو در وب پیدا کنید. سعی کنید جواب خود را با خواندن manual (راهنما) پیدا کنید. سعی کنید جواب خود را با خواندن FAQ (سوالات متداول) پیدا کنید. سعی کنید جواب خود را از طریق بازبینی یا آزمایش پیدا کنید. سعی کنید جواب خود را با پرسیدن از یک دوست باتجربه پیدا کنید. اگر یک برنامه‌نویس هستید، سعی کنید جواب خود را با خواندن کدمنبع پیدا کنید. از فنونی استفاده کنید. برای مثال متن پیغام ارور را در گوگل جستجو کنید. حتی اگر به نتیجه ای نرسید، گفتن اینکه «من عبارت زیر را گوگل کردم، اما چیز امیدوار کننده‌ای پیدا نکردم» چیز خوبی برای یک گروه پستی یا خبری است، حداقل به این دلیل که مشخص می‌شود جستجو کمکی نمی‌کند. وقت بگذارید. انتظار نداشته باشد که بتوانید مشکل پیچیدهٔ خود را با چند ثانیه گوگل کردن حل کنید. FAQ ها را بخوانید و بفهمید، آرام و باتمرکز بنشنید و کمی در مورد مشکل خود فکر و گمانه‌زنی کنید. به یکباره تمام سوالات خود را ارسال نکنید فقط به خاطر اینکه اولین جستجوی شما به هیچ جوابی نرسید (یا به جواب‌های زیادی رسید). سوال خود را آماده کنید. به آن فکر کنید. سوالات شتاب‌زده به جواب‌های شتاب‌زده منجر خواهد شد، یا اصلاً به هیچ جوابی نمی‌رسد. هر چه بیشتر این را نشان دهید که برای حل مسئلهٔ خود قبل از درخواست کمک، فکر و تلاش کرده‌اید، همانقدر احتمال بیشتری خواهد رفت که واقعاً به شما کمک کنند. از پرسیدن سوال اشتباه، اجتناب کنید. اگر سوالی بپرسید که بر اساس فرض‌های ناقص و اشتباه است، یک فرد با تجربه ممکن است با این تصور که «یک سوال احمقانه است...» بخواهد به شما یک جواب لفظی و بی‌فایده بدهد، و به امید اینکه شما درس بگیرید از تجربهٔ گرفتن آنچه پرسیدید، نه آنچه مورد نیاز شما بود. ما وقتی می‌توانید به جواب برسید که یک سوال قابل توجه و برانگیزندهٔ ذهن بپرسید، سوالی که بطور ضمنی باعث کمک به تجربهٔ جامعه می‌شود، نه آنکه فقط بصورت انفعالی خواستار دانش از دیگران باشید. از طرف دیگر، روشن ساختن اینکه شما توانایی و تمایل کمک در پروسهٔ حل مسئله را دارید، شروع بسیار خوبی است. «آیا کسی می‌خواهد منبعی معرفی کند؟»، «مثال من چه چیز کم دارد؟»، و «چه وبسایتی را بهتر است بررسی کنم» به احتمال بیشتری جواب خواهند گرفت نسبت به این سوال که «لطفاً روش دقیق کاری که باید انجام دهم را بنویسید.». چون [در حالت اول] شما این را روشن می‌سازید که واقعاً راغب به تکمیل پروسه [ی حل مشکل] هستید اگر شخصی فقط مسیر صحیح را به شما نشان دهد. وقتی سوال می‌کنید: انجمن خود را به دقت انتخاب کنید به این حساس باشید که کجا سوال خود را مطرح می‌کنید. شما احتمالاً نادیده گرفته خواهید شد اگر: سوال شما دارای عنوان مناسب نباشد. یک سوال بسیار ابتدایی را در انجمنی پست کنید که انتظار سوالات فنی پیشرفته را دارند. یا بالعکس. یک سوال مشترک را در چند گروه خبری پست کنید. یک ایمیل شخصی به کسی بفرستید که نه سابقه آشنایی با شما دارد، و نه شخصاً مسئول حل مشکل شماست. افراد با تجربه سوالاتی که بیجا در مکان خاصی پست شود را پاک می‌کنند تا کانالهای ارتباطی‌شان را از غرق شدن در بی‌ربطی حفظ کند. شما نمی‌خواهید این اتفاق برایتان بیفتد؛ بنابراین اولین قدم این است که انجمن درست را انتخاب کنید. باز هم، گوگل و سایر روشهای جستجوی وب، دوست شما هستند. از آنها استفاده کنید. رها کردن یک ایمیل به سوی شخص یا انجمنی که با آن آشنا نیستید، در بهترین حالت یک ریسک است. در مورد اینکه آیا سوال شما مورد استقبال واقع می‌شود یا نه، حدس‌های خوشبینانه نزنید. اگر مطمئن نیستید آن را جای دیگری بفرستید یا اینکه از فرستادن آن خودداری کنید. به یکباره سوال خود را به همه‌ی کانال های کمک‌رسانی ارسال نکنید، این کار مانند فریاد زدن است و افراد را عصبانی می‌کند. به آرامی از میان آنها گام بردارید. عموماً سوالاتی که در یک انجمن عمومی و درست (بجا) پرسیده شوند، احتمال اینکه جواب مفید بگیرند بیشتر است تا آنهایی که در جای خصوصی پرسیده می‌شوند. چندین دلیل برای این وجود دارد. یک دلیل ساده، مقدار منابع پاسخگو است. یکی دیگر تعداد بازدیدکنندگان است؛ افراد با‌تجربه ترجیح می‌دهند به سوالاتی جواب دهند که افراد بیشتری را آموزش دهد، تا سوالاتی که فقط به درد افراد کمی بخورد. به وضوح، برنامه‌نویسان چیره‌دست و سازندگان نرم‌افزارهای محبوب، همواره بسیار بیشتر از توان پاسخ‌گویی‌شان، پیغام‌های انبوه و بی‌هدف دریافت می‌کنند. شما با اضافه شدن به این سیل، یکی از آن موارد بسیار زیاد هستید. از عناوین پرمعنا و دارای موضوع مشخص، استفاده کنید در لیست‌های پستی، گروه‌های خبری یا انجمن‌های وب، عنوانِ موضوع، فرصت طلایی شماست تا با حدود ۵۰ کاراکتر یا کمتر، توجه متخصصانِ قابل را جلب کنید. با عناوینی مثل «لطفاً به من کمک کنید»، آن را هدر ندهید (پیغام‌هایی با این‌گونه عناوین به راحتی دور انداخته می‌شوند). سعی نکنید با عمق اضطراب خود، افراد با تجربه را تحت تأثیر قرار دهید؛ در عوض، از آن فضا برای یک توصیف بسیار مختصر از مشکل خود استفاده کنید. نامطلوب: کمک! کتابخانه X روی لپ‌تاپ من درست کار نمی‌کند! هوشمندانه: با استفاده از امکانY از کتاب‌خانه X برنامه من کار نمی‌کند! هوشمندانه تر: با استفاده از امکان Y در کتاب‌خانه X نسخه 5.8 برنامه من کرش (Crash) می‌کند. تصور کنید که به یک لیست از سوالات یک آرشیو نگاه می‌کنید، که فقط خطوط عنوان‌ها نمایش داده می‌شوند. عنوان پست خود را طوری انتخاب کنید که بخوبی سوال شما را منعکس کنید، تا شخص بعدی که آرشیو را جستجو می‌کند، بتواند دنبال آن ریسمان (thread) را بگیرد و به یک جواب برسد، بجای اینکه دوباره آن سوال را پست کند. رسیدن یک سوال در یک پاسخ، به خودی خود مورد شک است، چون آن فقط توسط افرادی دیده خواهد شد که این ریسمان را دنبال می‌کنند. پس یک ریسمان (تاپیک) جدید را آغاز کنید، مگر اینکه مطمئنید می‌خواهید فقط از افرادی بپرسید که در حال حاضر در این ریسمان فعال هستند. پاسخ دادن را آسان کنید پایان دادن سوال با این عبارت که «لطفاً پاسخ خو را به ... بفرستید»، جواب گرفتن شما را کاملاً بعید می‌سازد. بصورت واضح، از لحاظ دستوری صحیح، و با املای صحیح بنویسید مهم است که سوال خود را واضح و خوب بیان کنید. قبل از ارسال سوال خود یکبار متن سوالتان را بررسی و سعی خود را بکنید تا زبان (بیان) خود را بهبود دهید (صیقل دهید). لازم نیست که رسمی و سنگین باشد. در واقع افراد با تجربه به آن طرز بیانی بها میدهند که غیر رسمی، عامیانه، شوخ‌طبعانه و همراه با دقت و ظرافت باشد. اما باید دقیق باشد؛ باید نشانه‌هایی از اینکه که شما اندیشه و توجه می‌کنید را داشته باشد. این نکته بسیار مهم است که به زبان رسمی آن کانال ارتباطی سوال خود را ارسال کنید. برای مثال اگر در انجمنی که زبان رسمی آن فارسی است سوال خود را به زبان انگلیسی (یا فینگلیش) بنویسید سوال شما معمولا یا پاک خواهد شد و یا نادیده گرفته می‌شود. اگر دارید سوال خود را در انجمنی می‌پرسید که از زبان بومی شما استفاده نمی‌کند، شما یک میزان محدودی از خطاهای املایی و دستوری خواهید داشت، اما از روی تنبلی دچار خطاهای بیش از حد نشوید (بله، افراد معمولاً می‌توانند آن تفاوت را تشخیص دهند). همینطور اگر نمی‌دانید که شخص پاسخگو چه زبانی دارد، به انگلیسی بنویسید. افراد با‌تجربه مشغول، سوالات با زبانی که نمی‌فهمند را نادیده می‌گیرند، و انگلیسی زبان کاری اینترنت است. با نوشتن به زبان انگلیسی، این احتمال را که سوالتان بدون خوانده شدن پاک شود، به حداقل می‌رسانید. سوال خود را در قالب‌های استاندارد و در دسترس مطرح کنید نامه خود را به صورت پاراگراف‌هایی که از خطوط به هم پیچیده شده تشکیل شده‌اند، نفرستید. این کار، پاسخ گویی به قسمت‌های مختلف نوشته شما را دشوار می‌کند. هرگز تصور نکنید که مخاطبین شما قادر به خواند فایل‌های اختصاصی مانند Microsoft word یا Excel هستند. افراد مختلف از سیستم عامل‌های مختلف و برنامه‌های متفاوتی برای ویرایش متن استفاده می‌کنند پس بهترین گزینه این است که فایل خود را به صورت متنی ارسال کنید. در صفحات گفتگو، از اشکال خندان (Smile) و امکانات HTML استفاده نکنید. یکی دو تا از این اشکال ایرادی ندارد. اما در صورت استفاده بیش از حد. بهای سوال شما را کاهش می‌دهد و احتمال نادیده گرفته شدن سوال شما افزایش پیدا می‌کند. اگر شما از یک پردازش‌گر ایمیل با صورت گرافیکی کاربری مانند MS، Outlook، Netscape، Messenger و یا از این‌گونه‌ها استفاده می‌کنید، آگاه باشید که در صورتی که از تنظیمات پیش‌فرض آن استفاده می‌کنید، ممکن است این قوانین نقض شوند. بیشتر این پردازشگرها دارای یک دستور در فهرست خود به نام view source هستند از این گزینه در پوشه نامه‌های فرستاده خود استفاده کنید و فرستادن نوشته ساده (plain tent) بدون ضمایم غیر ضروری را بررسی کنید. درباره مشکل خود دقیق و آگاه باشید نشانه‌های مشکل ایجاد شده یا bug ها را به دقت و روشنی شرح دهید. محیطی که در آن این مشکل ایجاد می‌شود را شرح دهید. (سیستم عامل، کاربرد و ...) شرکت فروشنده و مدل آنرا هم معرفی کنید مثلاً (Fedora Coret یا Slackware 91 و ...). مطالعاتی که بر روی این مشکل انجام داده‌اید را شرح دهید. مراحل تشخیص مشکل و رفع آنرا که انجام داده‌اید، قبل از طرح سوال، شرح دهید. هرگونه تغییر در سخت‌افزار یا نرم‌افزار که اخیراً انجام شده است را شرح دهید. تلاش کنید تا به سوالاتی که پیش‌بینی می‌کنید از شما پرسیده شوند، پیش‌تر پاسخ دهید. حجم مطالب دلیلی بر دقیق بودن آن نیست باید دقیق و آموزنده بنویسید. این هدف با نوشتن حجم زیادی از داده‌ها و کدها در نامه تقاضای کمک محقق نمی‌شود. اگر یک مشکل بزرگ و پیچیده دارید، سعی کنید تا آنرا تا حد ممکن خلاصه و مرتب ارائه کنید. این امر حداقل سه فایده دارد. اول اینکه معلوم شود که شما برای خلاصه کردن سؤال خود تلاش کرده‌اید یا تمایل بیشتری برای پاسخ به شما وجود خواهد داشت. دوم اینکه با خلاصه‌سازی پاسخ مفیدتری هم خواهید گرفت؛ و سوم اینکه در حین خلاصه کردن و پیرایش گزارش خود ممکن است بتوانید مشکل را حل کنید یا راه حل کوتاه‌تری برای آن پیدا کنید. بدون اطمینان ادعای یافتن یک bug را نکنید! هنگامی که با یک نرم‌افزار به مشکل برخوردید، بدون اطمینان کامل ادعای یافتن یک bug جدید را مطرح نکنید. راهنمایی: تا هنگامی که با یک ضمیمه به کد منبع نتوانید مشکل را برطرف کنید یا با آزمایش رگرسیون با ورژن قبلی که نشان دهنده یک رفتار نادرست باشد، شما نباید مطمئن شوید. این امر در مورد وب سایت‌ها و مدارک هم صدق می‌کند سندی را به عنوان bug یافتید، باید متنی را جایگزین آن کنید یادآوری می‌شود که کاربران بسیاری هستند که مشکل شما را تجربه نکرده‌اند. همچنین شما با خواندن مطالب و وب سایت‌های مرتبط، در مورد آن نرم‌افزار آموزش دیده‌اید در غیر این صورت شما کاری را اشتباه انجام می‌دهید و نه نرم‌افزار. افرادی که یک نرم‌افزار را تهیه می‌کنند، تلاش می‌کنند تا آن نرم‌افزار حداکثر کارایی مطلوب را داشته باشد. اگر شما ادعا کنید که یک bug در آن یافته‌اید، در واقع کامل بودن کار آنها را زیر سؤال برده‌اید و این باعث رنجاندن آنهان می‌شود، حتی اگر حق با شما باشد. به خصوص ذکر کلمه bug در عنوان نامه، کار سیاست مدارانه‌ای نیست. وقتی که سوال خود را مطرح می‌کنید، بهتر است فرض کنید که شما کار اشتباهی را انجام می‌دهید، حتی اگر مطمئن باشید که یک bug واقعی را یافته‌اید. اگر واقعاً این طور باشد، در مورد آن در پاسخ‌ها خواهید شنید. با این کار نگهدارنده‌های نرم‌افزار از شما عذرخواهی خواهند کرد، همچنین اگر شما اشتباه کرده باشید، باید از آنها عذرخواهی کنید. به جای حدس‌های خود نشانه‌های مشکل را شرح دهید نوشتن در مورد اینکه خودتان علت مشکل پیش آمده را چه می‌دانید، مفید نیست (اگر فرضیات شما به‌کلی اشتباه باشد آیا با دیگران مشورت می‌کنید؟). لذا سعی کنید که به دوست‌داران کامپیوتر از علائم و نشانه‌های اولیه مشکل موجود بگویید و نه از فرضیات و تئوری‌های خود. بگذارید آنها خود تفسیر کنند و مشکل را تشخیص دهند اگر احساس می‌کنید که ذکر کردن حدس خودتان می‌تواند مهم باشد، آنرا روشن و تحت عنوان حدس خودتان بیان کنید و همچنین ذکر کنیدن که چرا این پاسخ نمی‌تواند جوابگوی مسئله باشد. هدف را مشخص کنید، نه مرحله اگر به دنبال این هستید که بدانید چطور باید کاری را انجام دهید (مثل گزارش کردن یک اشکال یا bug )، با شرح دادن هدف خود شروع کنید. بعد از آن فقط برخی از مراحل خاص که برای رسیدن به آن طی کردید و موفق نشدید را شرح دهید. اغلب، افرادی که به کمک تکنیکی نیاز دارند، هدف بلند مرتبه‌ای را در ذهن می‌پرورانند و در راهی که فکر می‌کنند تنها راه رسیدن به هدف است گمراه می‌شوند. آنها برای کمک گرفتن مرحله به مرحله می‌آیند اما نمی‌دانند که مسیر اشتباه است تلاش قابل توجهی برای گذر از این مرحله مورد نیاز است. سوال نامطلوب: چگونه می‌توان در برنامه FooDraw مقادیر RGB رنگ را بر مبنای شانزده‌تایی انتخاب کرد؟ سوال هوشمندانه: من تلاش می‌کنم که جدول رنگ‌ها را روی یک تصویر با مقادیر انتخابی خودم قرار دهم. در حال حاضر تنها راهی که به نظرم می‌رسد اینست که هر ردیف از جدول را اصلاح کنم اما نمی‌توانم در برنامه FooDraw رنگ‌ها را بر مبنای مقادیر RGB شانزده‌تایی انتخاب کنم. سوال دوم هوشمندانه بود. جواب این سوال ابزار بهتری برای آن کار را پیشنهاد می‌دهد. سوال را صریح مطرح کنید برای سوال‌هایی که انتهای مشخصی ندارد، بازه زمانی محدودی برای پاسخگویی به آنها در نظر گرفته نمی‌شود. کسانی که می‌خواهند پاسخ‌های مفیدی به شما بدهند، مشغول‌ترین افراد هستند. (چون در اغلب کارها به تنهایی کار می‌کنند). این گونه افراد نسبت به سوال‌هایی با بازه زمانی نامحدود حساسیت دارند و تمایل چندانی به پاسخ‌گویی به آنها ندارند. شما هنگامی که یک پاسخ مفید دریافت می‌کنید که از پاسخگویی خود در مورد چیزی که می‌خواهید به‌طور صریح پرسیده باشید (از اشاره‌گر استفاده کند، که بفرستید، پیوست را بررسی کنید یا هر چیز دیگر). این کار تلاش پاسخگو را بر روی هدف شما متمرکز می‌کند و به طور ضمنی حدی از نظر زمانی برای پاسخگویی و صرف انرژی برای کمک به شما ایجاد می‌کند. این کار خوبی است. برای درک دنیایی که متخصصین در آن زندگی می‌کنند، به مهارت به عنوان یک منبع و زمان فراوان برای پاسخگویی به یک مورد کمیاب فکر کنید. هر چه زمان کمتری را برای پاسخگویی به سوال خود به طور ضمنی در نظر بگیرید، احتمال اینکه جواب واقعاً مناسب از جانب یک فرد خبره و پرمشغله دریافت کنید، بیشتر می‌شود بنابراین بهتر است که برای سوال خود قالبی در نظر بگیرید که زمان مورد نیاز به پاسخگویی به آن را از جانب یک فرد خبره به حداقل برساند. اما این کار اغلب مشابه ساده‌سازی یک سوال نیست. به عنوان مثال، ممکن است برای شرح مناسبی از X یک راهنمایی بکنید؟ معمولاً سوال هوشمندانه‌تری است نسبت به اینکه ممکن است لطفاً X را توضیح دهید! اگر شما یک کد نادرست دارید، بهتر است در مورد اینکه چه اشکالی دارد بپرسید تا اینکه درخواست کنید کسی آنرا اصلاح کند. سوالهای بی‌معنی را حذف کنید از به پایان رساندن درخواست سوال خود با جملات بی‌مفهومی مانند کسی می‌تواند به من کمک کند؟ یا آیا جوابی وجود دارد؟ پرهیز کنید. اولاً، اگر شرح خود را تا نیمه نوشته بودید، این گونه سوال‌ها زائد هستند. دوماً، به دلیل زائد بودن آنها کاربران آنها را آزاردهنده تلقی می‌کنند و احتمال دارد که جواب‌هایی بی عیب و نقص ولی بی اعتنا مانند بله، به شما می‌توان کمک کرد. یا خیر، هیچ کمکی نمی‌توان کرد به شما بدهند. به طور کلی، از سوالهای آری یا خیر باید اجتناب شود مگر اینکه تنها جواب بله یا خیر برای شما کافی باشد. سوال خود را با کلمه «فوری» نشانه‌دار نکنید، حتی اگر برای شما اینگونه باشد: این مشکل شماست، نه دیگران. اظهار ضرورت کردن نتیجه معکوس می‌دهد. بیشتر کاربران به راحتی اینگونه سوال‌ها را که با خودخواهی و گستاخی درخواست توجه فوری و ویژه می‌کنند را حذف می‌کنند. تنها یک شبه استثناء وجود دارد. اگر شما در یک محل با مرتبه بالا و با یک نرم‌افزار کار می‌کنید و از نظر زمانی تحت فشار هستید، گفتن مودبانه محدودیت زمانی خود می‌تواند مؤثر باشد تا دیگران را به پاسخ دادن به شما ترغیب کند. البته این کار ریسک بالایی دارد، چون معیار جالب بودن مسائل از نظر کاربران دیگر با شما متفاوت است. به عنوان مثال فرستادن نامه از یک ایستگاه فضایی بین‌المللی قانع کننده است اما از جانب یک انسان با احساس خوب و مهربان یا یک سیاستمدار خیر. در واقع، نوشتن کلمه «فوری» باعث می‌شود که از سوال شما اجتناب و دوری شود حتی اگر از نظر آنها مهم باشد. اگر فکر می‌کنید که این امری مبهم است، دوباره این مطالب را بخوانید تا کاملاً آنرا درک کنید، قبل از آنکه نوشته‌ای را به جایی بفرستید. ادب و احترام را رعایت کنید مؤدب باشید. از جملاتی مانند «لطفاً» و «با تشکر از توجه شما» یا «ممنون از ملاحظه شما» استفاده کنید. به طور واضح بیان کنید که شما اینکه دیگران وقت خود را برای کمک به شما رایگان صرف می‌کنند، تحسین کنید. صادق بودن، به اندازه واضح، دقیق، با دستور زبان صحیح و مشروح بودن و پرهیز از قالب‌های مالکانه، مهم نیست و حتی جایگزین آنها هم نمی‌تواند باشد. کاربران بطور کلی علاقه دارند که گزارش‌های دقیق تکنیکی از bug ها و ایرادها را هر چند بی ادبانه دریافت کنند تا نوشته‌های مؤدب ولی ابهام‌آمیز. (اگر این امر برای شما مبهم است، به یاد داشته باشید که سوال‌ها را با چیزی که توسط آن می‌توان یاد گرفت ارزش‌گذاری می‌کنند). به هر حال اگر مشکلات تکنیکی خود را ردیف کنید، مؤدب بودن شانس شما را برای دریافت پاسخ مفید افزایش می‌دهد. باید ذکر شود که تنها مخالفتی که از سوی کاربران قدیمی نسبت به این نوشته دریافت کرده‌ایم، در رابطه با توصیه‌های قبلی ما برای تشکر پیشاپیش است. برخی از کاربران احساس می‌کنند که این دلالتی به منظوری دارد و نه تشکر. توصیه ما اینست که هم پیشاپیش تشکر کنید و هم بعد از پاسخ‌گویی و یا ادب و احترام را به روشهای دیگری بیان کنید قبلاً با جملاتی مثل: «با تشکر از توجه شما» یا «ممنون از ملاحظه شما». روش حل را با یادداشت مختصری پاسخ دهید بعد از اینکه مسئله حل شد، یادداشتی به همه کسانی که به شما کمک کرده‌اند بفرستید، آنها را از نحوه‌ی حل مطلع کنید؛ و باز هم از یاری آنها تشکر کنید. پاسخ شما نباید طولانی و شامل جملاتی ساده مثل: «ایراد از کابل شبکه بود، با تشکر از همه» باشد. حتی اگر پاسخ ندهید، بهتر از این جملات است. پاسخ کوتاه و خلاصه‌ای شیرین بهتر است از یک مقاله طولانی مگر اینکه عمق تکنیکی مسئله زیاد باشد. ذکر کنید که چه عملی مشکل را حل کرد اما لزومی ندارد که تمام مراحل حل مشکل را گزارش کنید. برای برخی از مسائل مناسب است که خلاصه‌ای از مراحل رفع مشکل را گزارش کنید. وضعیت نهایی مسئله خود را شرح دهید. توضیح دهید که چه روشی شما را به حل رساند و بعد از آن به داده‌هایی که جواب نمی‌رسد اشاره کنید. روشهای اشتباه را باید بعد از جواب صحیح و دیگر مطالب خلاصه بیاورید تا اینکه خلاصه شما تبدیل به یک داستان کارآگاهی نشود. از افرادی که به شما کمک کردند نام ببرید، با این کار با آنها دوست هم می‌شوید. در نهایت، این گونه خلاصه نویسی به تمام کسانی که کمک کرده‌اند، احساس رضایت‌مندی و نزدیکی به مسئله می‌دهد و این کم ارزش نیست. اگر شما یک تکنسین یا فرد باتجربه نیستید، مطمئن باشید که این احساس برای راهنماها و متخصصینی که از آنها کمک گرفته‌اید، بسیار مهم است. اگر نفهمیدید... اگر جواب را نفهمیدید، فوراً تقاضای روشن کردن پاسخ نکنید. از همان اندازه‎هایی که برای پاسخ اولیه خودتان (دستورالعمل‎ها ( FAQS)، وب و دوستان ماهر) برای فهمیدن جواب استفاده کنید. سپس اگر باز هم نیاز به شفاف سازی نشان دهید که چه چیزی یادگرفته‎اید. برای مثال تصور کنید که من به شما می‎گویم: "به‎نظر می‎رسد که شما Zentry گرفته شده‎ای دارید، باید آنرا تمیز کنید." در این صورت یک جواب نامناسب این خواهد بود: « Zentry چیست؟» و یک جواب خوب این خواهد بود "بسیار خوب، من صفحه اصلی را خواندم و به Zentry ها تحت عنوان سوئیچ‎های –Z و –P اشاره شده است اما هیچ یک از تمیز کردن Zentry چیزی نگفته‎اند. آیا اینها درست است یا من نکته‎ای را متوجه نشده‎ام؟" اخلاق حرفه ای داشته باشید با توجه به راه‎های مفصلی که در این‎جا گفته شد یا راه‎های مشابه بعید است که در راه‌های ارتباطی با افراد باتجربه اشتباه کنید. به‎طور دقیقی با جملات متفاوت به شما گفتیم که چگونه می‎توان اشتباه کرد. اگر چنین اتفاقی افتاد بدترین کار اینست که از این تجربه خود ناله کنید، ادعا کنید که شفاهاً مورد توهین قرار گرفته‎اید، تقاضای عذرخواهی کنید، نقستان را حبس کنید، به شکایت کردن تهدید کنید، از افراد شکایت کنید و غیره. در عوض پیش بروید. این امری طبیعی است. درواقع مناسب و سالم است. گاهی اوقات افراد بدون هیچ دلیل روشنی شخصاً شما را مورد حمله قرار می‎دهند حتی اگر شما اشتباهی نکرده باشید (یا فقط در ذهن آنها دچار اشتباه شده‎اید) در این موارد، شکایت کردن روشی واقعاً اشتباه است. این افرادِ متجاوز، نادان هم هستند که بدون هیچ دلیلی، خود را با تجربه می‎دانند یا با آزمایش‎های روان‎شناسی می‎خواهند بدانند که اشتباه کرده‎اید یا خیر. خوانندگان دیگر هم آنها را نادیده می‎گیرند و یا با روش خودشان با آنها برخورد می‎کنند رفتار این‎گونه افراد خود آنها را دچار مشکل می‎کند که به شما ربطی ندارد. اجازه ندهید که داخل این‎گونه بحث‎ها به دام بیفتید. بعد از اینکه بررسی کردید که آیا آنها واقعاً توهین هستند و نه اشاره‎ای به اشتباه شما و نه اشاره‎ای به اشتباه شما و نه اشاره‎ای زیرکانه به جواب واقعی سوال شما اغلب توهین‎ها نادیده گرفته می‎شوند. به اطلاعات موجود در فایل های ارسالی و ضمیمه توجه کنید در بسیاری از مواقع ممکن است سوال شما همراه با فایل (یا فایل های) ضمیمه‌ای باشد که مشکل را دقیق‌تر به پاسخ دهند‌گان شرح میدهد. حتما قبل از ارسال فایل ضمیمه به موارد زیر توجه کنید: فایل ارسالی حاوی اطلاعات شخصی افراد نباشد. این موارد حریم شخصی افراد را نقض میکند و ممنوع میباشد. در صورتی که سوال شما مربوط به نحوه‌ی نمایش آن اطلاعات است میتوانید با ابزار ویرایش تصویر یا فایل، اطلاعات شخصی را حذف کنید.
×
×
  • جدید...