انجمنهای فارسی اوبونتو
تازه کار => فلسفهٔ اوبونتو، گنو/لینوکس و نرمافزارهای آزاد و متنباز => نویسنده: Plugin در 03 بهمن 1391، 09:45 قظ
-
نرمافزارهای منبع باز شیوه برنامهنویسی دنیا را تغییر داده است و بسیاری از کاربران تمایل دارند به بهترشدن آن کمک کنند. متاسفانه این تصور ایجاد شده است که برای کمک به دنیای منبع باز باید از دانش پیچیده برنامهنویسی برخوردار باشیم و معمولا جملههایی مانند:
- من برنامهنویس خوبی نیستم.
- نمیدانم روی چه پروژهای کار کنم.
را در ذهن خود مطرح میکنیم؛ اما باید به نکات زیر توجه کرد:
- پروژهها به همه افراد با هر سطح توانایی و مهارت نیاز دارد.
- کمک هر اندازه هم که اندک باشد، باز هم سودمند است.
- بهترین پروژه برای کمک، پروژهای است که از آن استفاده میکنیم.
بزرگترین دغدغه تازه واردان در کمک به دنیای برنامهنویسی این است که میاندیشند باید برنامهنویس خبرهای باشند. این مساله صحیح نیست. هر چند بزرگان این جامعه برای خود شهرتی دست و پا کردهاند، اما بخش عمدهای از این جامعه اینگونه نیستند. برخی اوقات کمک به یک پروژه در حوزه برنامهنویسی است و برخی اوقات هیچ ارتباطی با برنامهنویسی ندارد.
بخش عمدهای از دلیل موفقیت پروژههای منبع باز، کاری است که در آنها انجام میشود؛ کارهایی که نیاز به مغز متفکر ندارد. طراحی یک زبان برنامهنویسی یا بستر توسعه وب شاید نیاز به الهامات درونی داشته باشد، اما موفقیت پروژههایی چون Perl و Rails در استمرار فعالیت آنهاست؛ کارهایی که شاید خیلی شهرتی به ارمغان نیاورد، اما لازم است و بعد از مدتی، میزان کمکهای هر فرد بالاخره مورد توجه قرار میگیرد.
شنیدن
در منبع باز، همه چیز به دیگران مربوط است. باید به یک تیم بپیوندید و برای این کار باید درکی از جامعه و شیوه کارکرد آن پروژه داشته باشید. ورود به پروژه و اعلام این جمله: «سلام، به نظر من این پروژه باید چنین کاری را بکند.» معمولا گزینه خوبی نیست. برخی پروژهها این روش را میپسندند اما اگر پروژهای برای مدتی در حال کار باشد، چنین رفتاری معمولا با استقبال مواجه نمیشود. ارتباط با دیگر اعضا و شنیدن نیازهای پروژه میتواند نقطه شروع خوبی برای ورود به پروژه باشد.
پیوستن به فهرستهای ایمیل
بیشتر پروژهها فهرست ایمیلی دارند که ارتباطات اصلی توسعه پروژه در آن محل انجام میشود. در پروژههای بزرگ فهرستهای ایمیل زیرشاخه وجود دارد. مثلا در پروژه PostgreSQL دوازده فهرست با محوریت کاربری و شش فهرست با محوریت توسعه کد وجود دارد که میتوان به آنها ملحق شد.
خواندن بلاگ
بلاگهای این پروژهها که معمولا توسط توسعهدهندگان مرکزی بهروز میشود، اطلاعاتی از جمله قابلیتهایی را که در نسخههای بعدی نرمافزار پیاده میشود شامل میشود. سایتهای قمری(سیاره ای) معمولا این کار را انجام میدهند و اخبار و حواشی توسعه پروژه را تحت پوشش خبری قرار میدهد. وب سایتهایی چون planet.gnome.org و planet.mysql.com از این نمونههاست. برای شروع میتوانید در گوگل عبارت planet و سپس نام پروژه را جستجو کنید.
پیوستن به IRC
بسیاری از پروژههای منبع باز، کانال چت IRC مخصوص به خود را دارد که توسعهدهندگان و کاربران در آنجا مشکلات و مسائل توسعه را با یکدیگر در میان میگذارند. معمولا توضیحات اتصال به شبکه IRC در وب سایت این پروژهها وجود دارد.
کار با تیکتها
کدنویسی قلب هر پروژه منبع باز در نظر گرفته میشود اما نوشتن کد تنها روش کمک به پروژه نیست. نگهداری از کد و سیستمی که کنار آن فعالیت میکند از بخشهای مهم دیگر این پروژه به شمار میرود. این نواحی برای ورود تازهکاران بسیار مفید خواهد بود. البته برای کنترل تیکتها به دسترسی نیاز دارید، اما مدیران اغلب پروژهها به دنبال فردی میگردند که بخش درخواستها و باگها را مرتب و کنترل کند.
تشخیص باگ
معمولا باگها بخوبی گزارش نمیشوند. گزارش یک باگ و پیگیری آن میتواند در وقت توسعهدهندگان صرفهجویی کند. اگر اتفاقی برای نرمافزارتان افتاد و توانستید با انجام اعمالی آن را دوباره تکرار کنید، این شرایط هرقدر هم که خاص باشد، میتواند به رفع آن باگ و در نتیجه به کل پروژه کمک کند.
حتی اگر دلیل رویداد باگ را هم نمیدانید، تلاشی که برای کم کردن حالتهای اتفاق انجام میدهید، به تعمیر سریعتر آن کمک میکند. بهتر است نتایج خود را در قالب تیکت به وب سایت پروژه ارسال کنید.
معمولا در پروژهها باگهایی وجود دارد که قبلا رفع شده ولی تیکت آن به روز نشده است. با یافتن و بستن این تیکتها (که کار دشوار و زمان بری است) میتوان به پروژهای تمیزتر و هدفمندتر کمک کرد.
برای شروع کافی است تیکتهایی را که بیش از یک سال است در سیستم باز ماندهاند، جستجو کنید و بعد با مراجعه به release log پروژه، به دنبال آن باگ بگردید. اگر این مشکل رفع شده بود، شماره نسخه رفع ایراد را در انتهای تیکت نوشته و آن را ببندید.
امتحان کنید آیا باگ در آخرین نسخه تیکت نیز وجود دارد یا خیر. اگر باگی وجود نداشت، این موضوع را در تیکت قید کرده و آن را ببندید. اگر باگ هنوز وجود داشت، در انتهای تیکت این موضوع را یادداشت کنید و تیکت را باز بگذارید.
کار با کد
همه برنامهنویسها، در هر سطحی که باشند، میتوانند به کدنویسی پروژه کمک کنند. هر پروژه یک جریان کاری دارد و بهتر است قبل از دستبردن و ارسال کد، متوجه آن جریان کاری شویم.
مثلا در پروژه PostgreSQL، اصلاح کدها به شکل Patch به فهرست ایمیل ارسال میشود و بعد توسعهدهندگان از هر نظر کد جدید را بررسی میکنند، اما مثلا در پروژهای دیگر مثل Parrot، کافی است دسترسی تغییر مستقیم کد را داشته باشید.
اگر پروژه مورد نظر از GitHub استفاده میکند، میتوان از قابلیت pull آن استفاده کرد و به طور مستقل به تولید پچ پرداخت.
ضمیمه کلیک، یکشنبه ۰۱ بهمن ۱۳۹۱، شماره خبر: ۱۰۰۷۷۰۲۴۳۴۵۱ (http://jamejamonline.ir/papertext.aspx?newsnum=100770243451)، محمدرضا قربانی
-
خیلی توضیحات خوبی بود ولی چندتا نکته رو بگم:
۱. در مورد «تشخیص باگ» و «کار با تیکتها» وبگاه launchpad.net عالی هست. اگه خواستید پروژهای رو شروع کنید حتما یه نگاهی به لانچپد بندازید. چون خیلی کارها رو راحت میکنه. مثلا وقتی که یه باگ رو تصحیح کِردید میتونید با دستور زیر اعلام کنید که مثلا باگ شماره ۱۲۳۴ روی لانچپد درست شده:
bzr commit -m "un bug ro dorostesh kerdam" --fixes lp:1234
۲. طبق چیزی که از بعضی از فعالان پروژهی گنوم خوندم «اولین قدم پیوستن به کانال IRC» هست و گفتن اینکه «من فلان قابلیتها رو دارم، الآن چه کمکی از دست من برمیياد؟» و افراد شما رو راهنمایی میکنن که نیاز پروژه در حال حاضر چیه و با توجه به قابلیتهای شما، چه کمکی میتونید بکنید.
۳. در مورد ارسال کد هم معمولا دسترسی به مخازن برنامهها رو اینجوری تعریف میکنن:
تمام دنیا : read-only access «فقط قابلیت خواندن و fork کردن اون مخزن»
افراد اون پروژه: read-write access «هم فابلیت خوندن و هم قابلیت ویرایش اون مخزن»
خب افراد کل دنیا که دسترسی ندارن، باید اول پروژه رو fork کنن و بعد کدهای تغییر یافته رو به اونها ارسال کنن و بگن که لطفا کدهای ما رو با کدهای اصلی قاطی (merge) کنین. به این میگن pull request یا merge request.
-
:)
به Plugin : مطالب خیلی جامع و مفیدی بود.تشکر از شما
-
:)
به Plugin : مطالب خیلی جامع و مفیدی بود.تشکر از شما
+۱