Skip to content

Translation of Sadra's article about becoming an open source contributor !

License

Notifications You must be signed in to change notification settings

SepehrRasouli/BecomeAnOpenSourceContributorTranslation

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

7 Commits
 
 
 
 
 
 

Repository files navigation

| Note : این ترجمه ی مقاله ای هست که صدرا نوشته

ما از ابزار ها و نرم افزار های متن باز(Open-Source) بسیار زیادی در زندگی و مسیر فنیمون استفاده کردیم، اما اینها چطوری توسعه پیدا میکنن ؟ چطور مردم وقت میزارن که برنامه ی متن باز بنویسن و ازشون استفاده کنن ؟ ما چطور میتونیم جزئی از جامعه ی متن باز باشیم ؟

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

1. چطوری سفر رو شروع کنیم

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

1.1 متواضع و اجتماعی باشید !

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

1.2 مشارکت خود را با پروژه های کوچک تر آغاز کنید!

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

1.3 سعی کنید بر روی پروژه های فعال مشارکت داشته باشید!

به‌عنوان مشارکت‌کننده، از مشارکت روی پروژه ای بیشتر احساس رضایت خواهید کرد که مدیران و انجمن‌های فعالی داشته باشد، بنابراین درخواست های شما به سرعت بررسی می‌شود و سؤالات شما سریع‌تر پاسخ داده می‌شوند. شما می توانید هر پروژه ای را که به نظرتان جالب است برای مشارکت انتخاب کنید. اطمینان حاصل کنید که آنها منسوخ نشده اند و مشارکت پذیر باشند. فایل README و/یا CONTRIBUTING را در مخزن بررسی و مطالعه کنید. ممکن است به دنبال پروژه هایی باشید که محصول شما به آنها متکی است یا حتی ممکن است در پروژه های محبوب تر مشارکت کنید تا رزومه کاری و تجربه کاری بهتری برای خود ایجاد کنید.

1.4 مشارکت تنها به معنی توسعه سورس کد واقعی نیست!

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

1.5 استفاده از یک ابزار متن باز ممکن است شما را به یک مشارکت کننده تبدیل کند !

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

1.6 از Issue ها شروع کنید!

شما به سادگی می توانید مشکلاتی که چندی پیش دیگر کاربران با آن مواجه شده اند را برطرف کنید. نیازی نیست حتما خودتان آن ها را تجربه کرده باشید. اکثر مخازن از تب مسائل (issue) GitHub استفاده می کنند. در بخش ایشو، مطمئن شوید که مکالمات خود را عمومی نگه دارید. تصمیمات و گفتگو های شما در Forum های بخش Issue ممکن است روزی به دیگر توسعه دهندگان/کاربران کمک کند.

1.7 از طریق دنیای متن باز، ارتباطات خود را گسترش دهید!

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

1.8 ناراحت و ناامید نشوید!

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

2. مشارکت در پروژه های عظیم

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

فایل های مرتبط با گیت

  • .git فولدری که خود گیت استفاده شده در پروژه داخلش هست.
  • ‍‍‍‍.gitignore فایل ها و الگوهایی که گیت بهشون اهمیت نمیده.
  • برای دادن صفت(Attribute) به فایل ها. .gitattributes

فایل های مرتبط با گیتهاب

  • دایرکتوری که گیت داخلش به دنبال روند های عملیاتی(Action Workflows)، قالب ها(Templates) و... میگرده : .github
  • ممکنه یه فایل md یا rst یا txt باشه که توضیحاتی درمورد مخزن(Repository) یا یه اپلیکیشن میده : README
  • یک داکیومنت که پروژه تحت اون مجوز[License] هست : LICENSE
  • مراحل مشارکت کردن که باید درمورد پروژه بدونید : CONTRIBUTING

اولین قدم همیشه باید خوندن فایل README باشه. مطمئن بشید که مخزن(Repository) فعاله، و بعد به سراغ فایل CONTRIBUTING برید. یه فایل CONTRIBUTING برای مثال: Picture1 برای مشارکت کردن به پروژه های بزرگتر، باید اول پروژه رو کامل بشناسید. داکیومنتش و داک استرینگ هاش رو بخونید تا متوجه ی هر بخش بشید. داخل فایل ها و دایرکتوری ها بچرخید. ساختار و معماری کد رو، یکپارچه(Monolithic) یا مایکروسرویس(Microservice)، رو درک کنید. اینکه رویه ای(Procedural) هستن یا شیء گرا. پروژه های بزرگتر به برنامه ها و ماژول های مختلف تقسیم شدن تا روند توسعه برای مشارکت کننده ها آسون تر بشه. اگر میخواید که یه تابع(Function) رو بهتر کنید، ماژول ها و تست هاش رو راحت تر پیدا میکنید. یه کار خوب اینه که تست های پروژه رو بخونید تا نقش هر بخش پروژه رو بفهمین. در پروژه های بسیار عظیم تر، مثل زبان های برنامه نویسی، یک راهنمای توسعه دهنده(Developer Guideline) وجود داره برای کسایی که میخوان در پروژه مشارکت داشته باشن. برای مثال، پایتون راهنمای توسعه دهنده خودش رو داره و همه چیز اونجا توضیح داده شده. نکاتی که بالاتر بررسی کردیم بهتون کمک میکنن مشارکت کننده متن باز(Open-Source) بهتری باشید. اما در بیشتر اوقات، شاید شما نگه دارنده(Maintainer) یک پروژه باشید. از لحاظ نگه داری یه پروژه، این مسیر شاید کمی سخت و چالش برانگیز باشه، اما در مباحث بعدی، نکاتی درمورد نگه داری پروژه ها بهتون میگیم که مدیر متن باز(Open-Source) بهتری باشین.

3. آچار فرانسه، اما متخصص تو یه چیز

به عنوان نگه دارنده(Maintainer) یه پروژه ی متن باز(Open-Source)، بعضی وقت ها در شرایطی گیر میکنید که باید همه چیز رو خودتون شروع کنید. لوگو، بنر، داکیومنت بی نقص و یه مخزن(Repository) به خوبی ساختار یافته و شما هم تنها کسی هستین که ازش مراقبت میکنین. تجربه داشتن در مهارت های متفرقه شاید بهتون توی این شرایط کمک کنه. من به شخصه فکر میکنم که یه نگه دارنده ی(Maintainer) متن باز(Open Source) باید با تمامی زمینه های فنی آشنایی داشته باشه. اما، نگه دارنده(Maintainer) باید در یک زمینه ی به خصوص متخصص باشه. این طریقه ای هست که میشه یه ایده رو متولد و آماده برای پرواز کرد. یک مقدار مهارت بازاریابی همیشه خوبه. نه تنها نیازه که در زمینه ی فنیتون بسیار ماهر باشید، بلکه بهتره مهارت های متفرقه هم به خوبی بدونید. حداقل بتونید نیازمندی های پروژتون رو برآورده کنید. | رهبری پروژه ی متن باز به مهارت های بسیار زیادی در متن باز و جسارت کافی برای استفاده ازش نیاز داره - اما فقط بعد از اینکه قلق کار دستتون اومده باشه، رفتار و کردار بقیه رو به درستی فهمیده باشین و دستاتونو با چندتا پروژه کثیف کرده باشین. (The Linux Foundation)

4. چرا متن بازش کنیم

ما در دنیایی پر از مشکل و سختی زندگی میکنیم. به عنوان توسعه دهنده ی نرم افزار، شما قراره مشکلات رو با توانایی هاتون حل کنید. مهم نیست که متن بازه(Open-Source) یا متن بسته(Closed-Source). هر پروژه ای که دارین روش کار میکنین چیزی نیست جز یه ایده. بزارید با یه مثال توضیح بدم. تصور کنید که یه سیستم عامل روی کامپیوترتون نصب کردید. یه برنامه دارین که میخواین حین بوت شدن کامپیوتر، اجرا بشه. یه اسکریپت پایتون مینویسید و الان مشکل حل شده. میتونید اسکریپت رو نگه دارید و هرجا که میخواید دوباره ازش استفاده کنید. دیگه نیاز نیست دوباره این مشکل رو حل کنید چون الان راه حل خوبی براش دارید. اون اسکریپت چیزی جز یه متن ساده نیست. ایده ی پشتش مهم ترین بخشه. وقتی که اسکریپتتون رو متن باز میکنید، دارید این ایده رو برای همه در دسترس میزارید. هزاران فایده در توسعه دادن پروژه های متن باز هست. شاید مهم ترینش این باشه بفهمید آیا ایده یا راه حلتون پتانسیل بهتر شدن رو داره یا نه. بسیاری از مخازن(Repositories) مشهور، روزی که منتشر شدن فقط یه ایده بودن و الان کلی مشارکت کننده(Contributor) داره. شرکت هایی که از اون پروژه های متن باز(Open-Source) استفاده میکنن بهترین حامی هاشونن.

5. لایسنس ها

یه محصول متن باز(Open-Source) تحت یک مجوز یا پروانه(License) هست. وقتی پروژتون هیچ پروانه ای(License) نداشته باشه به این معنی نیست که پروژتون متن بازه. از اونجایی که انتخاب پروانه(License) خیلی قدم مهمی هست، بهتون پیشنهاد میکنم با دقت انتخابش کنید. اگر با پروانه های(License) متن باز فعلی فعلی راحت نیستید، میتونید خودتون یک پروانه(License) بنویسید که پیشنهاد نمیکنم.

6. هیچکس به پروژه های من اهمیت نمیده

خیلی از توسعه دهنده ها(Developers) براشون سخته که پروژه هاشون رو روی پلتفورم های مثل Github بزارن و به توسعش بپردازن. و نه از نظر فنی. شاید این سوالات رو پرسیده باشید، من هم جواب های خودمو براتون دارم.

6.1 کد من اونقدر تمیز نیست که بزارمش روی گیتهاب !

نیاز نیست که کدتون ** بی نقص** باشه تا بتونه روی گیتهاب بره. شما ایده رو پوش(Push) میکنید تا پیاده سازیش بی نقص بشه. ایده ای که الان دارید روش کار میکنید ممکنه راه حلی برای یک مخزن(Repository) معروف دیگه بشه.

6.2 هیچکس دنبال پروژه ی من نیست و فقط چندتا ستاره داره !

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

نتیجه گیری

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

About

Translation of Sadra's article about becoming an open source contributor !

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published