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

(Bugs database)
اشکالات اتفاق می افتند و در شروع اشکالات بیشتر هستند. ابزارهایی که برای دنبال کردن اشکالات انتخاب می کنید، باید تا حد امکان کارکردن با آن برای توسعه دهندگان، ساده باشد زیرا در غیر این صورت از آن استفاده نخواهند کرد. تعدادی از توسعه دهندگان ترجیح می دهند که از ابزارهایی برای کنترل اشکالات استفاده کنند که از طریق mail کار می کند، این کار موجب می شود که اشکالات گزارش شده از طریق mail برای آنها ارسال شود و آنها بتوانند از طریق mail آنها را پاسخ دهند. سایر توسعه دهندگان استفاده از پایگاه داده اشکالات مبتنی بر web را ترجیح می دهند. به خاطر اینکه کاربران منابع اصلی گزارش اشکالات هستند، باید گزارش کردن اشکالات برای آنها کار ساده ای باشد. پیدا کردن اشکالات زمان زیادی از کاربران، خواهد گرفت. همچنین آنها را با مشکلاتی روبرو خواهد کرد، حال فرض کنید که گزارش کردن این اشکالات هم کاربران را دچار سختی و زحمت کند، این امر کاربران را از فعال کردن در این زمینه دلسرد خواهد کرد. بنابراین ضروری است که ابزارهای مناسبی برای گزارش آسان اشکالات در اختیار کاربران قرار داده شود. برای پروژه ضروری است که یکی از اعضای پروژه کنترل کند که آیا اشکالی گزارش شده است یا نه و در صورت وجود داشتن گزارش آن را به پایگاه داده اشکالات اضافه کند.
تشویق کاربران برای گزارش اشکالات موجب می شود که شما تعداد زیادی تست کننده داشته باشید که اشکالات پروژه را استخراج می کنند. راه حل مناسب دیگر این است که شما یک توسعه دهنده داشته باشید که مسئول بررسی و خواندن mailing list کاربران باشد و بتواند از مشکلات گزارش شده، گزارشهای مربوط به اشکالات را استخراج کند، همچنین شما می توانید mailing list خاص برای گزارش اشکالات داشته باشید. مسئولین پیمانه ها باید اطمینان داشته باشند که ایده های خوبی که در mailing list بیان می شوند، در پایگاه داده اشکالات ثبت خواهند شد. پیشنهادهای ثبت شده در پایگاه داده اشکالات باید مرتبا برای به روز رسانی لیست دلخواه، مورد استفاده قرار گیرند.
یک نمونه از سیستم دنبال کننده اشکالات که توسط پروژه های متن باز مختلف مورد استفاده قرار گرفته است Bugzilla است. این ابزار به صورت خاص برای پروژه Mozilla ایجاد شد و کد آن به صورت مجانی در دسترس دیگران قرار داده شد. پروژه متن باز NetBeans، در حال حاضر از ISSUEZILLA استفاده می کند که بر مبنای Bugzilla می باشد. Scarab پروژه متن بازی است که به عنوان سیستم کنترل اشکالات نرم افزارهای متن باز، هم اکنون در حال توسعه است.
نگهداری و به روزرسانی پایگاه داده اشکالات، یکی دیگر از کارهای بنیادی است که باید در یک پروژه متن باز انجام شود.
Mailing list یا گروه خبری (Open Mailing Lists or Newsgroup)
اینکه همه بحثهای مربوط به پروژه های متن باز به صورت باز انجام می شود مهم است. کاربران و توسعه دهندگان باید یک Mailing list یا گروه خبری عمومی برای بحثهایشان داشته باشند. بحثها شامل مسائلی مانند خبرها، گزارش اشکالات و خطاها و راه حل آنها، موضوعات مربوط به طراحی و پیشنهادات برای کارهای آینده است. توسعه دهندگان داخلی باید در Mailing listها شرکت کنند و فقط از Mailing listهای داخلی استفاده نکنند. از این به بعد برای راحتی بیان، هر کجا از واژه Mailing list استفاده می شود، منظور گروه خبری میباشد.
اجازه دهید همه بدانند که چه اتفاق هایی می افتد
حیاتی است که اعضای مجمع در جریان بحثهای توسعه دهندگان داخلی باشند زیرا اگر توسعه دهندگان خارجی احساس کنند که توسعه دهندگان داخلی کارهایشان را در یک اجتماع بسته (در جمع خودشان) انجام می دهند و از emailهای اختصاصی خودشان استفاده می کنند احساس می کنند که به عنوان اعضای سطح پایین تر در نظر گرفته شده اند و باعث می شود که تا حد توان با پروژه همکاری نکنند. منظور این نیست که توسعه دهندگان داخلی باید فقط از Mailing list عمومی استفاده کنند، بلکه به این معنی است که در صورتی که جلسه ای برگزار می شود از توسعه دهندگان خارجی هم برای شرکت در جلسه دعوت شود و از نظرات آنها نیز استفاده شود و یا اینکه این امکان وجود داشته باشد که توسعه دهندگان خارجی نقطه نظرات خود را از طریق mail ارسال کرده و نظرات آنها در جلسه مورد بررسی قرار گیرد.
توجه داشته باشید که بیشتر کارهای طراحی از طریق email انجام می شود، مناسب ترین کار این است که آنها را در بایگانی Mailing list نگه داری کنید زیرا بسیاری از بحثهای مربوط به طراحی در مستندات ثبت نمی شوند و این می تواند در شرایطی مشکل ساز باشد. مثلا اگر دیدگاه های پایه در طراحی تغییر کنند و یا اشخاص جدیدی به پروژه اضافه شوند که برای انجام کاری که به عهده دارند نیاز به درک اصول طراحی پروژه داشته باشند، نبود مستندات مربوط به طراحی و بحثهای آن مشکل ساز خواهد بود.
دلیل دیگری که به خاطر آن باید به همه اجازه دهید که در جریان بررسی های پروژه قرار گیرند این است که در شرایطی مجمع تصمیم به تغییر اساسی در کد پروژه می گیرد. بدترین شرایط در صورتی که دیگران از این تصمیم اطلاع نداشته باشند این است که مسئولین پیمانه ها تغییرات زیادی در پیمانه های خود اعمال کنند، بدون اینکه از تغییرات اساسی در کد پروژه اطلاع داشته باشند، در این شرایط وقتی که سایر توسعه دهندگان از تغییرات اطلاع پیدا می کنند به دلیل اینکه اعمال این ت

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