اوپن سورس میں کیوں تعاون کریں؟

اوپن سورس میں تعاون کرنا سیکھنے، سکھانے اور تجربہ بنانے کا ایک فائدہ مند طریقہ ہو سکتا ہے جس کا آپ تصور کر سکتے ہیں۔

لوگ اوپن سورس میں کیوں حصہ ڈالتے ہیں؟ بہت سی وجوہات!

سافٹ ویئر کو بہتر بنائیں جس پر آپ انحصار کرتے ہیں۔

بہت سارے اوپن سورس تعاون کنندگان سافٹ ویئر کے استعمال کنندہ بن کر شروع کرتے ہیں جس میں وہ تعاون کرتے ہیں۔ جب آپ کو اوپن سورس سافٹ ویئر میں کوئی بگ ملتا ہے جسے آپ استعمال کرتے ہیں، تو آپ ماخذ کو دیکھنا چاہیں گے کہ آیا آپ اسے خود ہی پیچ کر سکتے ہیں۔ اگر ایسا ہے تو، اس بات کو یقینی بنانے کا بہترین طریقہ ہے کہ آپ کے دوست (اور خود جب آپ اگلی ریلیز پر اپ ڈیٹ کریں گے) اس سے فائدہ اٹھا سکیں گے۔

موجودہ مہارتوں کو بہتر بنائیں

چاہے یہ کوڈنگ ہو، یوزر انٹرفیس ڈیزائن، گرافک ڈیزائن، تحریر، یا تنظیم، اگر آپ مشق کی تلاش میں ہیں، تو آپ کے لیے اوپن سورس پروجیکٹ پر ایک کام ہے۔

ایسے لوگوں سے ملیں جو اسی طرح کی چیزوں میں دلچسپی رکھتے ہیں۔

پرجوش، خوش آئند کمیونٹیز کے ساتھ اوپن سورس پروجیکٹس لوگوں کو سالوں تک واپس آتے رہتے ہیں۔ بہت سے لوگ اوپن سورس میں اپنی شرکت کے ذریعے زندگی بھر کی دوستی قائم کرتے ہیں، چاہے وہ کانفرنسوں میں ایک دوسرے کے ساتھ چل رہے ہوں یا رات گئے آن لائن چیٹس کے بارے میں۔

سرپرست تلاش کریں اور دوسروں کو سکھائیں۔

مشترکہ پروجیکٹ پر دوسروں کے ساتھ کام کرنے کا مطلب ہے کہ آپ کو یہ بتانا پڑے گا کہ آپ کام کیسے کرتے ہیں، اور ساتھ ہی دوسرے لوگوں سے بھی مدد طلب کریں۔ سیکھنے اور سکھانے کے عمل اس میں شامل ہر فرد کے لیے ایک تکمیلی سرگرمی ہو سکتے ہیں۔

عوامی نمونے بنائیں جو آپ کو شہرت (اور کیریئر) بڑھانے میں مدد کرتے ہیں۔

تعریف کے مطابق، آپ کا تمام اوپن سورس کام عوامی ہے، جس کا مطلب ہے کہ آپ کو مفت مثالیں ملتی ہیں کہ آپ کیا کر سکتے ہیں اس کے مظاہرے کے طور پر کہیں بھی لے جائیں۔

لوگوں کے ہنر سیکھیں۔

اوپن سورس قیادت اور انتظامی مہارتوں کی مشق کرنے کے مواقع فراہم کرتا ہے، جیسے تنازعات کو حل کرنا، لوگوں کی ٹیموں کو منظم کرنا، اور کام کو ترجیح دینا۔

تبدیلیاں کرنے کے قابل ہونا بااختیار بناتا ہے، یہاں تک کہ چھوٹی بھی

اوپن سورس میں شرکت سے لطف اندوز ہونے کے لیے آپ کو تاحیات شراکت دار بننے کی ضرورت نہیں ہے۔ کیا آپ نے کبھی کسی ویب سائٹ پر ٹائپنگ کی غلطی دیکھی ہے، اور خواہش کی ہے کہ کوئی اسے ٹھیک کردے؟ اوپن سورس پروجیکٹ پر، آپ ایسا ہی کر سکتے ہیں۔ اوپن سورس لوگوں کو ان کی زندگیوں پر ایجنسی محسوس کرنے میں مدد کرتا ہے اور وہ دنیا کا تجربہ کیسے کرتے ہیں، اور یہ بذات خود اطمینان بخش ہے۔

حصہ ڈالنے کا کیا مطلب ہے۔

اگر آپ ایک نئے اوپن سورس تعاون کنندہ ہیں، تو یہ عمل خوفناک ہو سکتا ہے۔ آپ کو صحیح پروجیکٹ کیسے ملتا ہے؟ اگر آپ کوڈ کرنا نہیں جانتے تو کیا ہوگا؟ اگر کچھ غلط ہو جائے تو کیا ہوگا؟

پریشانی کی بات نہیں! اوپن سورس پروجیکٹ میں شامل ہونے کے ہر طرح کے طریقے ہیں، اور چند تجاویز آپ کو اپنے تجربے سے زیادہ سے زیادہ فائدہ اٹھانے میں مدد کریں گی۔

آپ کو کوڈ میں تعاون کرنے کی ضرورت نہیں ہے۔

اوپن سورس میں تعاون کرنے کے بارے میں ایک عام غلط فہمی یہ ہے کہ آپ کو کوڈ میں تعاون کرنے کی ضرورت ہے۔ درحقیقت، یہ اکثر کسی پروجیکٹ کے دوسرے حصے ہوتے ہیں جو سب سے زیادہ نظرانداز یا نظر انداز کیے جاتے ہیں۔ آپ اس قسم کے تعاون کے ساتھ حصہ لینے کی پیشکش کر کے اس پروجیکٹ پر ایک بڑا احسان کریں گے!

یہاں تک کہ اگر آپ کوڈ لکھنا پسند کرتے ہیں تو، دوسرے قسم کے تعاون کسی پروجیکٹ میں شامل ہونے اور کمیونٹی کے دیگر اراکین سے ملنے کا بہترین طریقہ ہیں۔ ان تعلقات کو استوار کرنے سے آپ کو پروجیکٹ کے دوسرے حصوں پر کام کرنے کے مواقع ملیں گے۔

کیا آپ ایونٹس کی منصوبہ بندی کرنا پسند کرتے ہیں؟

  • پروجیکٹ کے بارے میں ورکشاپس یا میٹنگز کا اہتمام کریں، جیسے @fzamperin نے NodeSchool کے لیے کیا
  • پروجیکٹ کی کانفرنس کا اہتمام کریں (اگر ان کے پاس ہے)
  • کمیونٹی کے اراکین کو صحیح کانفرنسیں تلاش کرنے اور بولنے کے لیے تجاویز جمع کرانے میں مدد کریں۔

کیا آپ ڈیزائن کرنا پسند کرتے ہیں؟

  • پراجیکٹ کے استعمال کو بہتر بنانے کے لیے ترتیب کو دوبارہ ترتیب دیں۔
  • پروجیکٹ کی نیویگیشن یا مینوز کو دوبارہ ترتیب دینے اور بہتر کرنے کے لیے صارف کی تحقیق کریں، جیسے ڈروپل تجویز کرتا ہے
  • پراجیکٹ کو مستقل بصری ڈیزائن بنانے میں مدد کرنے کے لیے ایک اسٹائل گائیڈ جمع کریں۔
  • ٹی شرٹس یا نئے لوگو کے لیے آرٹ بنائیں، جیسے hapi.js کے تعاون کرنے والوں نے کیا

کیا آپ لکھنا پسند کرتے ہیں؟

کیا آپ کو منظم کرنا پسند ہے؟

  • ڈپلیکیٹ ایشوز سے لنک کریں، اور چیزوں کو منظم رکھنے کے لیے نئے ایشو لیبل تجویز کریں۔
  • کھلے مسائل کو دیکھیں اور پرانے کو بند کرنے کا مشورہ دیں، جیسے @nzakas نے ESLint کے لیے کیا
  • بحث کو آگے بڑھانے کے لیے حال ہی میں کھولے گئے مسائل پر واضح سوالات پوچھیں۔

کیا آپ کوڈ کرنا پسند کرتے ہیں؟

  • نمٹنے کے لیے ایک کھلا مسئلہ تلاش کریں، جیسے @dianjin نے لیفلیٹ کے لیے کیا
  • پوچھیں کہ کیا آپ ایک نیا فیچر لکھنے میں مدد کر سکتے ہیں۔
  • خودکار پروجیکٹ سیٹ اپ
  • ٹولنگ اور ٹیسٹنگ کو بہتر بنائیں

کیا آپ لوگوں کی مدد کرنا پسند کرتے ہیں؟

  • پراجیکٹ کے بارے میں سوالات کے جواب دیں جیسے کہ اسٹیک اوور فلو ([اس پوسٹگریس مثال کی طرح)(https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying) -to-ge)) یا Reddit
  • کھلے مسائل پر لوگوں کے سوالات کے جوابات دیں۔
  • ڈسکشن بورڈز یا بات چیت کے چینلز کو معتدل کرنے میں مدد کریں۔

کیا آپ دوسروں کو کوڈ میں مدد کرنا پسند کرتے ہیں؟

  • دوسرے لوگوں کی گذارشات پر کوڈ کا جائزہ لیں۔
  • پراجیکٹ کو کس طرح استعمال کیا جا سکتا ہے اس کے لیے سبق لکھیں۔
  • کسی اور تعاون کنندہ کو سرپرست کی پیشکش، جیسے @ereichert نے @bronzdoc on Rust کے لیے کیا

آپ کو صرف سافٹ ویئر پروجیکٹس پر کام کرنے کی ضرورت نہیں ہے!

اگرچہ “اوپن سورس” سے اکثر سافٹ ویئر مراد ہوتا ہے، آپ کسی بھی چیز پر تعاون کر سکتے ہیں۔ ایسی کتابیں، ترکیبیں، فہرستیں اور کلاسیں ہیں جو اوپن سورس پروجیکٹس کے طور پر تیار ہوتی ہیں۔

مثال کے طور پر:

یہاں تک کہ اگر آپ سافٹ ویئر ڈویلپر ہیں، دستاویزی پروجیکٹ پر کام کرنے سے آپ کو اوپن سورس میں شروع کرنے میں مدد مل سکتی ہے۔ ایسے پروجیکٹس پر کام کرنا اکثر کم خوفزدہ ہوتا ہے جن میں کوڈ شامل نہیں ہوتا ہے، اور تعاون کا عمل آپ کا اعتماد اور تجربہ بڑھاتا ہے۔

اپنے آپ کو ایک نئے پروجیکٹ کی طرف راغب کرنا

ٹائپنگ فکس کے علاوہ کسی بھی چیز کے لیے، اوپن سورس میں تعاون کرنا پارٹی میں اجنبیوں کے گروپ کے ساتھ چلنے کے مترادف ہے۔ اگر آپ لاماس کے بارے میں بات کرنا شروع کرتے ہیں، جب وہ گولڈ فش کے بارے میں گہری بحث میں تھے، تو وہ شاید آپ کو قدرے عجیب نظر سے دیکھیں گے۔

اپنی تجاویز کے ساتھ آنکھیں بند کر کے کودنے سے پہلے، کمرے کو پڑھنے کا طریقہ سیکھ کر شروع کریں۔ ایسا کرنے سے اس بات کے امکانات بڑھ جاتے ہیں کہ آپ کے خیالات کو دیکھا اور سنا جائے گا۔

ایک اوپن سورس پروجیکٹ کی اناٹومی۔

ہر اوپن سورس کمیونٹی مختلف ہے۔

ایک اوپن سورس پروجیکٹ پر سال گزارنے کا مطلب ہے کہ آپ نے ایک اوپن سورس پروجیکٹ کو جان لیا ہے۔ ایک مختلف پروجیکٹ پر جائیں، اور آپ کو الفاظ، اصول، اور مواصلات کے انداز بالکل مختلف معلوم ہو سکتے ہیں۔

اس نے کہا، بہت سے اوپن سورس پروجیکٹ اسی طرح کے تنظیمی ڈھانچے کی پیروی کرتے ہیں۔ کمیونٹی کے مختلف کرداروں اور مجموعی عمل کو سمجھنے سے آپ کو کسی بھی نئے پروجیکٹ کی طرف تیزی سے توجہ حاصل کرنے میں مدد ملے گی۔

ایک عام اوپن سورس پروجیکٹ میں درج ذیل قسم کے لوگ ہوتے ہیں:

  • مصنف: وہ شخص یا تنظیم جس نے پروجیکٹ بنایا
  • مالک: وہ شخص جس کی تنظیم یا ذخیرہ پر انتظامی ملکیت ہے (ہمیشہ اصل مصنف کی طرح نہیں ہوتا)
  • ** دیکھ بھال کرنے والے:** تعاون کرنے والے جو وژن کو آگے بڑھانے اور پروجیکٹ کے تنظیمی پہلوؤں کو منظم کرنے کے ذمہ دار ہیں (وہ پروجیکٹ کے مصنف یا مالک بھی ہوسکتے ہیں۔) * شراکت دار: ہر وہ شخص جس نے پروجیکٹ میں کچھ حصہ دیا ہے۔
  • کمیونٹی ممبرز: وہ لوگ جو پروجیکٹ استعمال کرتے ہیں۔ وہ بات چیت میں سرگرم ہو سکتے ہیں یا پروجیکٹ کی سمت پر اپنی رائے کا اظہار کر سکتے ہیں۔

بڑے پروجیکٹس میں ذیلی کمیٹیاں یا ورکنگ گروپس بھی ہوسکتے ہیں جن کی توجہ مختلف کاموں پر مرکوز ہوتی ہے، جیسے ٹولنگ، ٹرائیج، کمیونٹی اعتدال اور ایونٹ آرگنائزنگ۔ اس معلومات کو تلاش کرنے کے لیے کسی پروجیکٹ کی ویب سائٹ پر “ٹیم” کے صفحے، یا گورننس دستاویزات کے ذخیرے میں دیکھیں۔

ایک پروجیکٹ کے پاس دستاویزات بھی ہیں۔ یہ فائلیں عام طور پر ذخیرے کے اوپری درجے میں درج ہوتی ہیں۔

  • لائسنس: تعریف کے مطابق، ہر اوپن سورس پروجیکٹ کے پاس اوپن سورس لائسنس ہونا ضروری ہے۔ اگر پروجیکٹ کے پاس لائسنس نہیں ہے تو یہ اوپن سورس نہیں ہے۔
  • README: README ایک ہدایت نامہ ہے جو کمیونٹی کے نئے اراکین کو پروجیکٹ میں خوش آمدید کہتا ہے۔ یہ بتاتا ہے کہ پروجیکٹ کیوں مفید ہے اور کیسے شروع کیا جائے۔
  • کنٹریبیوٹنگ: جہاں READMEs لوگوں کو پروجیکٹ کو استعمال کرنے میں مدد کرتے ہیں، وہیں تعاون کرنے والے دستاویزات لوگوں کو پروجیکٹ میں contributing کرنے میں مدد کرتے ہیں۔ یہ بتاتا ہے کہ کن قسم کے تعاون کی ضرورت ہے اور یہ عمل کیسے کام کرتا ہے۔ اگرچہ ہر پروجیکٹ میں CONTRIBUTING فائل نہیں ہوتی ہے، لیکن اس کی موجودگی اس بات کا اشارہ دیتی ہے کہ یہ تعاون کرنے کے لیے ایک خوش آئند پروجیکٹ ہے۔ ایک مؤثر تعاون کرنے والی گائیڈ کی ایک اچھی مثال Codecademy’s Docs repository سے ہوگی۔
  • CODE_OF_CONDUCT: ضابطہ اخلاق شرکا سے وابستہ رویے کے لیے بنیادی اصول طے کرتا ہے اور ایک دوستانہ، خوش آئند ماحول کو آسان بنانے میں مدد کرتا ہے۔ اگرچہ ہر پروجیکٹ میں CODE_OF_CONDUCT فائل نہیں ہوتی ہے، لیکن اس کی موجودگی اس بات کا اشارہ دیتی ہے کہ یہ تعاون کرنے کے لیے ایک خوش آئند پروجیکٹ ہے۔
  • دیگر دستاویزات: اضافی دستاویزات ہو سکتی ہیں، جیسے سبق، واک تھرو، یا گورننس پالیسیاں، خاص طور پر بڑے پروجیکٹس جیسے Astro Docs۔

آخر میں، اوپن سورس پروجیکٹس بحث کو منظم کرنے کے لیے درج ذیل ٹولز کا استعمال کرتے ہیں۔ آرکائیوز کو پڑھنے سے آپ کو ایک اچھی تصویر ملے گی کہ کمیونٹی کس طرح سوچتی ہے اور کام کرتی ہے۔

* ایشو ٹریکر: جہاں لوگ پروجیکٹ سے متعلق مسائل پر بات کرتے ہیں۔

  • درخواستیں کھینچیں: جہاں لوگ ان تبدیلیوں پر تبادلہ خیال کرتے ہیں اور ان کا جائزہ لیتے ہیں جو جاری ہیں کہ آیا یہ شراکت کنندہ کے کوڈ، گرامر کا استعمال، تصاویر کا استعمال، وغیرہ کو بہتر بنانا ہے۔ کچھ پروجیکٹس، جیسے MDN Web Docs، اپنے کوڈ کے جائزوں کو خودکار اور تیز کرنے کے لیے مخصوص GitHub ایکشن فلو استعمال کریں۔
  • ڈسکشن فورمز یا میلنگ لسٹ: کچھ پروجیکٹس ان چینلز کو گفت و شنید کے موضوعات کے لیے استعمال کر سکتے ہیں (مثال کے طور پر، “میں کیسے…“ یا “آپ کا کیا خیال ہے…“ بگ کی بجائے رپورٹس یا فیچر کی درخواستیں)۔ دوسرے تمام بات چیت کے لیے ایشو ٹریکر استعمال کرتے ہیں۔ اس کی ایک اچھی مثال CHAOSS’ ہفتہ وار نیوز لیٹر ہوگی۔
  • مطابقت پذیر چیٹ چینل: کچھ پروجیکٹس آرام دہ گفتگو، تعاون، اور فوری تبادلے کے لیے چیٹ چینلز (جیسے Slack یا IRC) استعمال کرتے ہیں۔ اس کی ایک اچھی مثال EddieHub’s Discord community ہوگی۔

شراکت کے لیے ایک پروجیکٹ تلاش کرنا

اب جب کہ آپ یہ جان چکے ہیں کہ اوپن سورس پروجیکٹس کس طرح کام کرتے ہیں، اب وقت آگیا ہے کہ اس میں تعاون کرنے کے لیے کوئی پروجیکٹ تلاش کیا جائے!

اگر آپ نے پہلے کبھی اوپن سورس میں تعاون نہیں کیا ہے، تو امریکی صدر جان ایف کینیڈی سے کچھ مشورہ لیں، جنہوں نے ایک بار کہا تھا:، “یہ مت پوچھو کہ آپ کا ملک آپ کے لیے کیا کر سکتا ہے - پوچھیں کہ آپ اپنے ملک کے لیے کیا کر سکتے ہیں۔”

اوپن سورس میں تعاون ہر سطح پر، تمام پروجیکٹس میں ہوتا ہے۔ آپ کو یہ سوچنے کی ضرورت نہیں ہے کہ آپ کا پہلا حصہ بالکل کیا ہوگا، یا یہ کیسا نظر آئے گا۔

اس کے بجائے، ان منصوبوں کے بارے میں سوچ کر شروع کریں جو آپ پہلے سے استعمال کرتے ہیں، یا استعمال کرنا چاہتے ہیں۔ جن منصوبوں میں آپ فعال طور پر تعاون کریں گے وہ وہی ہیں جن پر آپ خود کو واپس آتے ہوئے پائیں گے۔

ان منصوبوں کے اندر، جب بھی آپ اپنے آپ کو یہ سوچتے ہیں کہ کچھ بہتر یا مختلف ہو سکتا ہے، اپنی جبلت پر عمل کریں۔

اوپن سورس کوئی خصوصی کلب نہیں ہے۔ یہ آپ جیسے لوگوں نے بنایا ہے۔ “اوپن سورس” دنیا کے مسائل کو حل کرنے کے قابل سمجھنے کے لیے صرف ایک فینسی اصطلاح ہے۔

آپ README کو اسکین کر سکتے ہیں اور ایک ٹوٹا ہوا لنک یا ٹائپو تلاش کر سکتے ہیں۔ یا آپ ایک نئے صارف ہیں اور آپ نے دیکھا کہ کچھ ٹوٹا ہوا ہے، یا کوئی مسئلہ جو آپ کے خیال میں واقعی دستاویزات میں ہونا چاہیے۔ اسے نظر انداز کرنے اور آگے بڑھنے، یا کسی اور سے اسے ٹھیک کرنے کے لیے کہنے کے بجائے، دیکھیں کہ کیا آپ اندر جا کر مدد کر سکتے ہیں۔ اوپن سورس کا یہی مطلب ہے!

Igor Steinmacher اور کمپیوٹر سائنس کے دیگر محققین کی طرف سے کی گئی ایک تحقیق کے مطابق، اوپن سورس کے لیے 28% غیر معمولی تعاون دستاویزات ہیں، جیسے جیسا کہ ٹائپنگ ٹھیک کرنا، دوبارہ فارمیٹ کرنا، یا ترجمہ لکھنا۔

اگر آپ موجودہ مسائل کی تلاش کر رہے ہیں جس کو آپ ٹھیک کر سکتے ہیں، تو ہر اوپن سورس پروجیکٹ میں ایک /contribute صفحہ ہوتا ہے جو ابتدائی دوستانہ مسائل کو نمایاں کرتا ہے جس سے آپ شروعات کر سکتے ہیں۔ GitHub پر مخزن کے مرکزی صفحہ پر جائیں، اور URL کے آخر میں /contribute شامل کریں (مثال کے طور پر https://github.com/facebook/react/contribute)۔

آپ نئے پروجیکٹس کو دریافت کرنے اور ان میں تعاون کرنے میں مدد کے لیے درج ذیل وسائل میں سے ایک بھی استعمال کر سکتے ہیں:

آپ کے تعاون سے پہلے ایک چیک لسٹ

جب آپ کو کوئی ایسا پروجیکٹ مل جاتا ہے جس میں آپ تعاون کرنا چاہتے ہیں، تو اس بات کو یقینی بنانے کے لیے فوری اسکین کریں کہ پروجیکٹ شراکت قبول کرنے کے لیے موزوں ہے۔ ورنہ آپ کی محنت کا جواب کبھی نہیں مل سکتا۔

یہ جانچنے کے لیے ایک آسان چیک لسٹ ہے کہ آیا کوئی پروجیکٹ نئے تعاون کنندگان کے لیے اچھا ہے۔

اوپن سورس کی تعریف پر پورا اترتا ہے

پروجیکٹ فعال طور پر شراکتیں قبول کرتا ہے

مرکزی برانچ پر کمٹ کی سرگرمی کو دیکھیں۔ GitHub پر، آپ یہ معلومات ذخیرہ کے ہوم پیج کے بصیرت والے ٹیب میں دیکھ سکتے ہیں، جیسے Virtual-Coffee

اگلا، پروجیکٹ کے مسائل کو دیکھیں۔

Now do the same for the project’s pull requests.

منصوبہ خوش آئند ہے

ایک ایسا پروجیکٹ جو دوستانہ اور خوش آئند سگنل ہے کہ وہ نئے شراکت داروں کے لیے قبول کریں گے۔

شراکت جمع کرنے کا طریقہ

آپ کو اپنی پسند کا پروجیکٹ مل گیا ہے، اور آپ اپنا حصہ ڈالنے کے لیے تیار ہیں۔ آخرکار! اپنا تعاون صحیح طریقے سے حاصل کرنے کا طریقہ یہاں ہے۔

مؤثر طریقے سے بات چیت کرنا

چاہے آپ ایک وقتی تعاون کرنے والے ہوں یا کسی کمیونٹی میں شامل ہونے کی کوشش کر رہے ہوں، دوسروں کے ساتھ کام کرنا ان سب سے اہم مہارتوں میں سے ایک ہے جسے آپ اوپن سورس میں تیار کریں گے۔

اس سے پہلے کہ آپ کوئی مسئلہ کھولیں یا درخواست کریں، یا چیٹ میں کوئی سوال پوچھیں، ان نکات کو ذہن میں رکھیں تاکہ آپ کے خیالات کو مؤثر طریقے سے سامنے آنے میں مدد ملے۔

سیاق و سباق دیں۔ دوسروں کو تیزی سے تیز رفتار بنانے میں مدد کریں۔ اگر آپ کو کوئی غلطی ہو رہی ہے تو وضاحت کریں کہ آپ کیا کرنے کی کوشش کر رہے ہیں اور اسے دوبارہ کیسے بنایا جائے۔ اگر آپ کوئی نیا آئیڈیا تجویز کر رہے ہیں تو وضاحت کریں کہ آپ کو کیوں لگتا ہے کہ یہ پروجیکٹ کے لیے مفید ہوگا (صرف آپ کے لیے نہیں!)

😇 “X نہیں ہوتا جب میں Y کرتا ہوں”

😢 “X ٹوٹ گیا ہے! براہ کرم اسے ٹھیک کریں۔”

اپنا ہوم ورک پہلے سے کر لیں۔ چیزوں کو نہ جاننا ٹھیک ہے، لیکن دکھائیں کہ آپ نے کوشش کی۔ مدد طلب کرنے سے پہلے، کسی پروجیکٹ کی README، دستاویزات، مسائل (کھلی یا بند)، میلنگ لسٹ، اور جواب کے لیے انٹرنیٹ پر تلاش کرنا یقینی بنائیں۔ لوگ اس کی تعریف کریں گے جب آپ یہ ظاہر کریں گے کہ آپ سیکھنے کی کوشش کر رہے ہیں۔

😇 “مجھے یقین نہیں ہے کہ X کو کیسے نافذ کیا جائے۔ میں نے مدد کے دستاویزات کو چیک کیا اور مجھے کوئی تذکرہ نہیں ملا۔”

😢 “میں ایکس کیسے کروں؟”

درخواستوں کو مختصر اور براہ راست رکھیں۔ بالکل ای میل بھیجنے کی طرح، ہر تعاون، چاہے کتنا ہی آسان یا مددگار ہو، کسی اور کے جائزے کی ضرورت ہوتی ہے۔ بہت سے منصوبوں میں مدد کے لیے دستیاب لوگوں سے زیادہ آنے والی درخواستیں ہوتی ہیں۔ مختصر ہونا۔ آپ اس موقع کو بڑھا دیں گے کہ کوئی آپ کی مدد کر سکے گا۔

😇 “میں ایک API ٹیوٹوریل لکھنا چاہوں گا۔”

😢 “میں دوسرے دن ہائی وے پر گاڑی چلا رہا تھا اور گیس کے لیے رک گیا، اور تب مجھے یہ حیرت انگیز خیال آیا کہ ہمیں کچھ کرنا چاہیے، لیکن اس سے پہلے کہ میں اس کی وضاحت کروں، میں آپ کو دکھاتا ہوں…“

تمام مواصلات کو عوامی رکھیں۔ اگرچہ یہ پرکشش ہے، لیکن نجی طور پر دیکھ بھال کرنے والوں تک نہ پہنچیں جب تک کہ آپ کو حساس معلومات (جیسے سیکیورٹی کا مسئلہ یا اخلاق کی سنگین خلاف ورزی) کا اشتراک کرنے کی ضرورت نہ ہو۔ جب آپ گفتگو کو عام رکھتے ہیں تو زیادہ لوگ آپ کے تبادلے سے سیکھ سکتے ہیں اور فائدہ اٹھا سکتے ہیں۔ بات چیت، اپنے آپ میں، شراکت ہو سکتی ہے۔

😇 (ایک تبصرہ کے طور پر) “@-maintainer ہیلو! ہمیں اس PR پر کیسے آگے بڑھنا چاہئے؟”

😢

سوال پوچھنا ٹھیک ہے (لیکن صبر کریں!)۔ ہر کوئی کسی وقت اس پروجیکٹ میں نیا تھا، اور یہاں تک کہ تجربہ کار شراکت داروں کو بھی کسی نئے پروجیکٹ کو دیکھتے وقت تیز رفتاری سے کام لینا پڑتا ہے۔ اسی علامت کے مطابق، یہاں تک کہ طویل عرصے سے دیکھ بھال کرنے والے بھی ہمیشہ منصوبے کے ہر حصے سے واقف نہیں ہوتے ہیں۔ انہیں وہی صبر دکھائیں جو آپ چاہتے ہیں کہ وہ آپ کو دکھائے۔

😇 “اس غلطی کو دیکھنے کا شکریہ۔ میں نے آپ کی تجاویز پر عمل کیا۔ آؤٹ پٹ یہ ہے۔”

😢 “آپ میرا مسئلہ حل کیوں نہیں کر سکتے؟ کیا یہ آپ کا پروجیکٹ نہیں ہے؟”

کمیونٹی کے فیصلوں کا احترام کریں۔ آپ کے خیالات کمیونٹی کی ترجیحات یا وژن سے مختلف ہو سکتے ہیں۔ وہ رائے پیش کر سکتے ہیں یا آپ کے خیال پر عمل نہ کرنے کا فیصلہ کر سکتے ہیں۔ جب کہ آپ کو بحث کرنی چاہیے اور سمجھوتے کی تلاش کرنی چاہیے، مینٹینرز کو آپ کے فیصلے کے ساتھ آپ کی مرضی سے زیادہ دیر تک رہنا ہوگا۔ اگر آپ ان کی سمت سے متفق نہیں ہیں، تو آپ ہمیشہ اپنے کانٹے پر کام کر سکتے ہیں یا اپنا پروجیکٹ شروع کر سکتے ہیں۔

😇 “میں مایوس ہوں کہ آپ میرے استعمال کے معاملے کی حمایت نہیں کر سکتے، لیکن جیسا کہ آپ نے وضاحت کی ہے کہ یہ صرف صارفین کے ایک معمولی حصے کو متاثر کرتا ہے، میں سمجھتا ہوں کیوں۔ سننے کا شکریہ۔”

😢 “آپ میرے استعمال کے معاملے کی حمایت کیوں نہیں کریں گے؟ یہ ناقابل قبول ہے!”

سب سے بڑھ کر، اسے بہترین رکھیں۔ اوپن سورس پوری دنیا کے ساتھیوں پر مشتمل ہے۔ سیاق و سباق زبانوں، ثقافتوں، جغرافیوں اور ٹائم زونز میں گم ہو جاتا ہے۔ اس کے علاوہ، تحریری موڈ کو ٹون یا موڈ بتانا مشکل بنا دیتا ہے۔ ان گفتگو میں نیک نیتی کا خیال رکھیں۔ شائستگی سے کسی آئیڈیا کو پیچھے دھکیلنا، مزید سیاق و سباق طلب کرنا، یا اپنی پوزیشن کو مزید واضح کرنا ٹھیک ہے۔ بس انٹرنیٹ کو اس سے بہتر جگہ چھوڑنے کی کوشش کریں جب آپ نے اسے پایا۔

سیاق و سباق جمع کرنا

کچھ بھی کرنے سے پہلے، اس بات کو یقینی بنانے کے لیے فوری جانچ پڑتال کریں کہ آپ کے خیال پر کہیں اور بات نہیں کی گئی ہے۔ پروجیکٹ کے README، مسائل (کھلے اور بند)، میلنگ لسٹ، اور اسٹیک اوور فلو کو سکیم کریں۔ آپ کو ہر چیز میں گھنٹوں گزارنے کی ضرورت نہیں ہے، لیکن چند کلیدی اصطلاحات کی فوری تلاش ایک طویل سفر طے کرتی ہے۔

اگر آپ کو اپنا آئیڈیا کہیں اور نہیں ملتا ہے، تو آپ آگے بڑھنے کے لیے تیار ہیں۔ اگر پروجیکٹ GitHub پر ہے، تو آپ ممکنہ طور پر درج ذیل کام کرکے بات چیت کریں گے:

  • مسئلہ اٹھانا: یہ بات چیت یا بحث شروع کرنے کی طرح ہیں۔
  • پل کی درخواستیں حل پر کام شروع کرنے کے لیے ہیں۔
  • مواصلاتی چینلز: اگر پروجیکٹ کے پاس ایک نامزد ڈسکارڈ، آئی آر سی، یا سلیک چینل ہے، تو بات چیت شروع کرنے یا اپنے تعاون کے بارے میں وضاحت طلب کرنے پر غور کریں۔

اس سے پہلے کہ آپ کوئی ایشو کھولیں یا درخواست کریں، پروجیکٹ کے تعاون کرنے والے دستاویزات (عام طور پر ایک فائل جسے CONTRIBUTING کہا جاتا ہے، یا README میں) چیک کریں، یہ دیکھنے کے لیے کہ آیا آپ کو کوئی خاص چیز شامل کرنے کی ضرورت ہے۔ مثال کے طور پر، وہ پوچھ سکتے ہیں کہ آپ کسی ٹیمپلیٹ کی پیروی کریں، یا آپ سے ٹیسٹ استعمال کرنے کا مطالبہ کریں۔

اگر آپ کوئی خاطر خواہ حصہ ڈالنا چاہتے ہیں تو اس پر کام کرنے سے پہلے پوچھنے کے لیے کوئی مسئلہ کھولیں۔ اس منصوبے کو تھوڑی دیر کے لیے دیکھنا مفید ہے۔(on GitHub, you can click “Watch” تمام بات چیت کے بارے میں مطلع کرنے کے لیے) اور ایسے کام کرنے سے پہلے جو شاید قبول نہ کیے جائیں، کمیونٹی کے اراکین کو جانیں۔

ایک مسئلہ کھولنا

آپ کو عام طور پر درج ذیل حالات میں ایک مسئلہ کھولنا چاہئے:

  • ایک غلطی کی اطلاع دیں جسے آپ خود حل نہیں کرسکتے ہیں۔
  • ایک اعلیٰ سطحی موضوع یا خیال پر بحث کریں (مثال کے طور پر کمیونٹی، وژن یا پالیسیاں)
  • ایک نئی خصوصیت یا دیگر پروجیکٹ آئیڈیا تجویز کریں۔

مسائل پر بات چیت کے لیے تجاویز:

* اگر آپ کو کوئی کھلا مسئلہ نظر آتا ہے جس سے آپ نمٹنا چاہتے ہیں، تو اس مسئلے پر تبصرہ کریں تاکہ لوگوں کو معلوم ہو سکے کہ آپ اس پر ہیں۔ اس طرح، لوگوں کے آپ کے کام کی نقل تیار کرنے کا امکان کم ہوتا ہے۔ **اگر کوئی مسئلہ کچھ دیر پہلے کھولا گیا تھا، ممکن ہے کہ اسے کہیں اور حل کیا جا رہا ہو، یا پہلے ہی حل ہو چکا ہو، اس لیے کام شروع کرنے سے پہلے تصدیق کے لیے تبصرہ کریں۔ اگر آپ نے کوئی مسئلہ کھولا، لیکن بعد میں خود ہی اس کا جواب معلوم کر لیا، لوگوں کو بتانے کے لیے اس مسئلے پر تبصرہ کریں، پھر مسئلہ کو بند کریں۔ یہاں تک کہ اس نتیجہ کی دستاویز کرنا بھی اس منصوبے میں ایک شراکت ہے۔

پل کی درخواست کھولنا

آپ کو عام طور پر درج ذیل حالات میں پل کی درخواست کھولنی چاہیے:

  • چھوٹی اصلاحات جمع کروائیں جیسے کہ ٹائپنگ کی غلطی، ٹوٹا ہوا لنک یا کوئی واضح غلطی۔
  • اس شراکت پر کام شروع کریں جو پہلے ہی طلب کیا گیا تھا، یا جس پر آپ پہلے ہی کسی مسئلے میں بات کر چکے ہیں۔

پل کی درخواست کو ختم شدہ کام کی نمائندگی کرنے کی ضرورت نہیں ہے۔ پل کی درخواست کو جلد کھولنا عام طور پر بہتر ہوتا ہے، تاکہ دوسرے آپ کی پیشرفت کو دیکھ سکیں یا اپنی رائے دے سکیں۔ اسے صرف ایک “ڈرافٹ” کے طور پر کھولیں یا مضمون کی لائن میں “WIP” (کام جاری ہے) کے بطور نشان زد کریں یا اگر فراہم کیا گیا ہو تو “نوٹز ٹو ریویورز” سیکشنز (یا آپ صرف اپنا بنا سکتے ہیں۔ اس طرح: **## جائزہ لینے والے کے لیے نوٹس**)۔ آپ بعد میں ہمیشہ مزید کمٹ شامل کر سکتے ہیں۔

اگر پروجیکٹ GitHub پر ہے تو، یہاں پل کی درخواست جمع کرنے کا طریقہ ہے:

  • Fork the repository اور اسے مقامی طور پر کلون کریں۔ اپنے مقامی کو ریموٹ کے طور پر شامل کرکے اصل “اپ اسٹریم” ریپوزٹری سے جوڑیں۔ “اپ اسٹریم” سے اکثر تبدیلیاں کریں تاکہ آپ اپ ٹو ڈیٹ رہیں تاکہ جب آپ اپنی پل کی درخواست جمع کرائیں تو انضمام کے تنازعات کا امکان کم ہوگا۔ (مزید تفصیلی ہدایات دیکھیںhere.)
  • Create a branch آپ کی ترامیم کے لیے۔
  • کسی بھی متعلقہ مسائل کا حوالہ دیں یا اپنے PR میں معاون دستاویزات (مثال کے طور پر، “کلوز #37۔”) *** اگر آپ کی تبدیلیوں میں HTML/CSS میں فرق شامل ہے تو اس سے پہلے اور بعد کے اسکرین شاٹس شامل کریں۔ تصاویر کو اپنی پل کی درخواست کے باڈی میں گھسیٹیں اور چھوڑیں۔
  • اپنی تبدیلیوں کی جانچ کریں! اپنی تبدیلیاں کسی بھی موجودہ ٹیسٹ کے خلاف چلائیں اگر وہ موجود ہیں اور ضرورت پڑنے پر نئی بنائیں۔ یہ یقینی بنانا ضروری ہے کہ آپ کی تبدیلیاں موجودہ پروجیکٹ کو نہ توڑیں۔ پروجیکٹ کے انداز میں اپنا حصہ ڈالیں اپنی بہترین صلاحیتوں سے۔ اس کا مطلب ہو سکتا ہے کہ انڈینٹ، نیم کالون یا تبصرے آپ کے اپنے ذخیرے میں استعمال کرنے سے مختلف ہوں، لیکن دیکھ بھال کرنے والے کے لیے ضم کرنا، دوسروں کو مستقبل میں سمجھنا اور برقرار رکھنا آسان بناتا ہے۔

اگر یہ آپ کی پہلی پل ریکوئسٹ ہے تو، Make a Pull Request کو دیکھیں، جسے @kentcdodds نے واک تھرو ویڈیو ٹیوٹوریل کے طور پر بنایا ہے۔ آپ @Roshanjossey کی تخلیق کردہ First Contributions ریپوزٹری میں پل کی درخواست کرنے کی مشق بھی کر سکتے ہیں۔

آپ اپنا تعاون جمع کروانے کے بعد کیا ہوتا ہے۔

اس سے پہلے کہ ہم جشن منانا شروع کریں، درج ذیل میں سے ایک آپ کے تعاون جمع کرانے کے بعد ہو گا:

😭 آپ کو کوئی جواب نہیں ملتا

امید ہے کہ آپ نے شراکت کرنے سے پہلے سرگرمی کے آثار کے لیے پروجیکٹ کو چیک کیا ہے۔ ایک فعال پروجیکٹ پر بھی، تاہم، یہ ممکن ہے کہ آپ کے تعاون کو جواب نہ ملے۔

اگر آپ کو ایک ہفتے سے زیادہ وقت میں کوئی جواب نہیں ملا ہے تو، اسی تھریڈ میں شائستگی سے جواب دینا، کسی سے جائزہ لینے کے لیے کہنا مناسب ہے۔ اگر آپ اپنے تعاون کا جائزہ لینے کے لیے صحیح شخص کا نام جانتے ہیں، تو آپ اس تھریڈ میں ان کا @-ذکر کر سکتے ہیں۔

اس شخص سے نجی طور پر رابطہ نہ کریں؛ یاد رکھیں کہ اوپن سورس پروجیکٹس کے لیے عوامی رابطہ بہت ضروری ہے۔

اگر آپ شائستہ یاد دہانی دیتے ہیں اور پھر بھی جواب نہیں ملتا ہے، تو یہ ممکن ہے کہ کوئی بھی جواب نہ دے۔ یہ ایک اچھا احساس نہیں ہے، لیکن اس سے آپ کی حوصلہ شکنی نہ ہونے دیں! 😄 آپ کو جواب نہ ملنے کی بہت سی ممکنہ وجوہات ہیں، بشمول ذاتی حالات جو آپ کے قابو سے باہر ہو سکتے ہیں۔ کوئی دوسرا پروجیکٹ یا تعاون کرنے کا طریقہ تلاش کرنے کی کوشش کریں۔ اگر کچھ بھی ہے تو، یہ ایک اچھی وجہ ہے کہ کمیونٹی کے دیگر اراکین کے مشغول اور جوابدہ ہونے سے پہلے اپنا حصہ ڈالنے میں زیادہ وقت نہ لگائیں۔

🚧 کوئی آپ کے تعاون میں تبدیلی کی درخواست کرتا ہے۔

یہ عام بات ہے کہ آپ سے اپنے تعاون میں تبدیلیاں کرنے کے لیے کہا جائے گا، چاہے وہ آپ کے خیال کے دائرہ کار پر رائے ہو، یا آپ کے کوڈ میں تبدیلیاں ہوں۔

جب کوئی تبدیلی کی درخواست کرتا ہے، تو جوابدہ بنیں۔ انہوں نے آپ کے تعاون کا جائزہ لینے کے لیے وقت نکالا ہے۔ PR کھولنا اور دور چلنا بری شکل ہے۔ اگر آپ تبدیلیاں کرنا نہیں جانتے ہیں تو مسئلہ کی تحقیق کریں، پھر اگر آپ کو ضرورت ہو تو مدد طلب کریں۔ اس کی ایک اچھی مثال یہ ہوگی وہ تاثرات جو ایک اور تعاون کنندہ نے @a-m-lamb کو Codecademy’s Docs میں اپنی پل کی درخواست پر دیا ہے۔

اگر مہینوں سے بات چیت جاری رہنے جیسی وجوہات کی بنا پر آپ کے پاس اس مسئلے پر مزید کام کرنے کا وقت نہیں ہے، اور آپ کے حالات بدل گئے ہیں یا آپ کوئی حل تلاش کرنے سے قاصر ہیں، تو دیکھ بھال کرنے والے کو بتائیں تاکہ وہ کسی اور کے لیے مسئلہ کھولیں، جیسے @RitaDee نے OpenSauced’s app repository میں کسی مسئلے کے لیے کیا۔

👎 آپ کا تعاون قبول نہیں کیا جائے گا۔

آپ کا تعاون آخر میں قبول کیا جا سکتا ہے یا نہیں۔ امید ہے کہ آپ نے پہلے ہی اس میں زیادہ کام نہیں کیا ہوگا۔ اگر آپ کو یقین نہیں ہے کہ اسے کیوں قبول نہیں کیا گیا، تو دیکھ بھال کرنے والے سے رائے اور وضاحت طلب کرنا بالکل مناسب ہے۔ تاہم، بالآخر، آپ کو اس بات کا احترام کرنے کی ضرورت ہوگی کہ یہ ان کا فیصلہ ہے۔ جھگڑا نہ کریں اور دشمنی نہ کریں۔ اگر آپ متفق نہیں ہیں تو آپ کا ہمیشہ خیرمقدم ہے اور اپنے ورژن پر کام کریں!

🎉 آپ کا تعاون قبول ہو جاتا ہے۔

ہورے! آپ نے کامیابی کے ساتھ اوپن سورس کا تعاون کیا ہے!

تم نے یہ کیا! 🎉

چاہے آپ نے اپنا پہلا اوپن سورس تعاون کیا ہو، یا آپ تعاون کرنے کے نئے طریقے تلاش کر رہے ہوں، ہمیں امید ہے کہ آپ کارروائی کرنے کے لیے متاثر ہوں گے۔ یہاں تک کہ اگر آپ کا تعاون قبول نہیں کیا گیا تھا، تب بھی جب کوئی مینٹینر آپ کی مدد کرنے کی کوشش کرتا ہے تو شکریہ کہنا نہ بھولیں۔ اوپن سورس آپ جیسے لوگوں نے بنایا ہے: ایک مسئلہ، پل کی درخواست، تبصرہ، یا ایک وقت میں ہائی فائیو۔