دیکھ بھال کرنے والا ہونے کا کیا مطلب ہے؟

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

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

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

اپنے عمل کو دستاویزی بنانا

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

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

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

یہاں تک کہ اگر آپ مکمل پیراگراف استعمال نہیں کرتے ہیں تو، بلٹ پوائنٹس کو لکھنا بالکل نہ لکھنے سے بہتر ہے۔

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

اپنے پروجیکٹ کا وژن لکھیں۔

اپنے پروجیکٹ کے اہداف لکھ کر شروع کریں۔ انہیں اپنے README میں شامل کریں، یا VISION نامی ایک الگ فائل بنائیں۔ اگر کوئی اور نمونے ہیں جو مدد کر سکتے ہیں، جیسے کہ پروجیکٹ روڈ میپ، ان کو بھی عوامی بنائیں۔

واضح، دستاویزی وژن کا ہونا آپ کو مرکوز رکھتا ہے اور دوسروں کے تعاون سے “اسکوپ کریپ” سے بچنے میں آپ کی مدد کرتا ہے۔

مثال کے طور پر، @lord نے دریافت کیا کہ پراجیکٹ وژن رکھنے سے اسے یہ جاننے میں مدد ملی کہ کن درخواستوں پر وقت گزارنا ہے۔ ایک نئے دیکھ بھال کرنے والے کے طور پر، جب اسے پہلی خصوصیت کی درخواست موصول ہوئی تو اسے اپنے پروجیکٹ کے دائرہ کار پر قائم نہ رہنے پر افسوس ہوا۔ Slate.

اپنی توقعات سے آگاہ کریں۔

قواعد لکھنے کے لیے اعصاب شکن ہو سکتے ہیں۔ کبھی کبھی آپ کو ایسا محسوس ہو سکتا ہے کہ آپ دوسرے لوگوں کے رویے پر پولیسنگ کر رہے ہیں یا سارا مزہ ختم کر رہے ہیں۔

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

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

یہ سب بالکل ٹھیک ہے! بس اس بات کو یقینی بنائیں کہ دوسرے لوگ اس کے بارے میں جانتے ہیں۔

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

یہاں کچھ اصول ہیں جو لکھنے کے قابل ہیں:

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

Jekyll, CocoaPods, and Homebrew دیکھ بھال کرنے والوں اور تعاون کرنے والوں کے لیے زمینی اصولوں کے ساتھ منصوبوں کی کئی مثالیں ہیں۔

مواصلات کو عام رکھیں

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

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

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

نہیں کہنا سیکھنا

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

تاہم، جب آپ کو اپنے قوانین کو نافذ کرنے کی ضرورت ہوتی ہے تو ہر چیز کو تحریر کرنے سے حالات کو ذاتی نوعیت کا بنانے میں مدد ملتی ہے۔

نہیں کہنا مزہ نہیں ہے، لیکن “آپ کا تعاون اس پروجیکٹ کے معیار سے میل نہیں کھاتا” اس سے کم ذاتی محسوس ہوتا ہے “مجھے آپ کا تعاون پسند نہیں”۔

نہ کہنے کا اطلاق بہت سے ایسے حالات پر ہوتا ہے جن کا آپ ایک مینٹینر کے طور پر سامنا کریں گے: خصوصیت کی درخواستیں جو دائرہ کار کے مطابق نہیں ہیں، کوئی بحث کو پٹڑی سے اتار رہا ہے، دوسروں کے لیے غیر ضروری کام کر رہا ہے۔

گفتگو کو دوستانہ رکھیں

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

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

وجہ سے قطع نظر، آپ کے پروجیکٹ کے معیارات پر پورا نہ اترنے والے تعاون کو تدبر سے سنبھالنا ممکن ہے۔

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

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

یہ بہتر ہے کہ وہ تعاون فوری طور پر بند کر دیں جنہیں آپ جانتے ہیں کہ آپ قبول نہیں کرنا چاہتے۔ اگر آپ کا پروجیکٹ پہلے سے ہی ایک بڑے بیک لاگ کا شکار ہے تو، @steveklabnik کے لیے تجاویز ہیں۔ how to triage issues efficiently.

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

اگر آپ شراکت قبول نہیں کرنا چاہتے ہیں:

ان کے تعاون کے لیے ان کا شکریہ *** وضاحت کریں کہ یہ پروجیکٹ کے دائرہ کار میں کیوں فٹ نہیں ہے، اور اگر آپ قابل ہو تو بہتری کے لیے واضح تجاویز پیش کریں۔ مہربان رہو، لیکن مضبوط.

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

جواب دینے کے لیے آپ کو 1-2 سے زیادہ جملوں کی ضرورت نہیں ہونی چاہیے۔ مثال کے طور پر، جب کوئی صارف celery ونڈوز سے متعلق غلطی کی اطلاع دی، @berkerpeksag responded with:

اگر نہ کہنے کا خیال آپ کو خوفزدہ کرتا ہے تو آپ اکیلے نہیں ہیں۔ As @jessfraz put it:

میں نے کئی مختلف اوپن سورس پروجیکٹس، Mesos، Kubernetes، Chromium کے مینٹینرز سے بات کی ہے، اور وہ سب اس بات سے متفق ہیں کہ مینٹینر ہونے کے سب سے مشکل حصوں میں سے ایک یہ ہے کہ آپ جو پیچ نہیں چاہتے ہیں انہیں “نہیں” کہنا ہے۔

کسی کے تعاون کو قبول نہ کرنے کے بارے میں مجرم محسوس نہ کریں۔ اوپن سورس کا پہلا اصول، according to @shykes: “نہیں عارضی ہے، ہاں ہمیشہ کے لیے ہے۔” جب کہ کسی دوسرے شخص کے جوش و جذبے کے ساتھ ہمدردی کرنا ایک اچھی چیز ہے، لیکن کسی شراکت کو مسترد کرنا اس کے پیچھے موجود شخص کو مسترد کرنے کے مترادف نہیں ہے۔

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

متحرک رہیں

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

اگر آپ کو بہت زیادہ کم معیار کی شراکتیں موصول ہو رہی ہیں، تو ضرورت ہے کہ تعاون کرنے والے پہلے سے تھوڑا سا کام کریں، مثال کے طور پر:

• ایک شمارہ یا PR ٹیمپلیٹ/چیک لسٹ پُر کریں۔
• PR جمع کرانے سے پہلے ایک مسئلہ کھولیں۔

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

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

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

رہنمائی کو گلے لگائیں۔

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

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

اپنی کمیونٹی سے فائدہ اٹھائیں۔

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

Share the workload

اگر آپ دوسروں کو تلاش کر رہے ہیں، تو ارد گرد پوچھ کر شروع کریں۔

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

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

دوسروں کی حوصلہ افزائی کرنا منصوبے کی ملکیت کا اشتراک کریں آپ کے اپنے کام کا بوجھ بہت کم کر سکتا ہے، جیسا کہ @lmccart نے اپنے پروجیکٹ پر دریافت کیا، p5.js.

اگر آپ کو اپنے پروجیکٹ سے الگ ہونے کی ضرورت ہے، یا تو وقفے وقفے پر یا مستقل طور پر، کسی اور سے آپ کے لیے کام لینے کے لیے کہنے میں کوئی شرم کی بات نہیں ہے۔

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

@progrium found that اپنے منصوبے کے وژن کی دستاویز کرنا، Dokku, اس منصوبے سے دور ہونے کے بعد بھی ان مقاصد کو زندہ رہنے میں مدد ملی:

میں نے ایک ویکی صفحہ لکھا جس میں بتایا گیا کہ میں کیا چاہتا ہوں اور کیوں چاہتا ہوں۔ کسی وجہ سے یہ میرے لیے حیران کن تھا کہ دیکھ بھال کرنے والوں نے اس منصوبے کو اس سمت میں لے جانا شروع کر دیا! کیا یہ بالکل وہی ہوا جس طرح میں یہ کروں گا؟ ہمیشہ نہیں. لیکن اس نے پھر بھی پروجیکٹ کو اس کے قریب لایا جو میں نے لکھا تھا۔

دوسروں کو وہ حل تیار کرنے دیں جن کی انہیں ضرورت ہے۔

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

کسی پروجیکٹ کو فورک کرنا کوئی بری چیز نہیں ہے۔ پروجیکٹس کو کاپی اور ان میں ترمیم کرنے کے قابل ہونا اوپن سورس کے بارے میں بہترین چیزوں میں سے ایک ہے۔ آپ کی کمیونٹی کے اراکین کو ان کے اپنے کانٹے پر کام کرنے کی ترغیب دینا آپ کے پروجیکٹ کے وژن سے متصادم ہوئے بغیر تخلیقی آؤٹ لیٹ فراہم کر سکتا ہے جس کی انہیں ضرورت ہے۔

یہی بات اس صارف پر بھی لاگو ہوتی ہے جو واقعتاً ایسا حل چاہتا ہے جسے بنانے کے لیے آپ کے پاس بینڈوڈتھ نہیں ہے۔ APIs اور حسب ضرورت ہکس کی پیشکش دوسروں کو ان کی اپنی ضروریات کو پورا کرنے میں مدد کر سکتی ہے، بغیر براہ راست ذریعہ میں ترمیم کیے. @orta found that CocoaPods کے لیے حوصلہ افزا پلگ ان “کچھ انتہائی دلچسپ خیالات” کا باعث بنے:

یہ تقریباً ناگزیر ہے کہ ایک بار جب کوئی پروجیکٹ بڑا ہو جائے تو دیکھ بھال کرنے والوں کو اس بارے میں بہت زیادہ قدامت پسند بننا پڑتا ہے کہ وہ نیا کوڈ کیسے متعارف کراتے ہیں۔ آپ “نہیں” کہنے میں اچھے بن جاتے ہیں، لیکن بہت سے لوگوں کی جائز ضروریات ہوتی ہیں۔ لہذا، اس کے بجائے آپ اپنے آلے کو پلیٹ فارم میں تبدیل کرتے ہیں۔

روبوٹ لے آئیں

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

اپنے کوڈ کے معیار کو بہتر بنانے کے لیے ٹیسٹ اور دیگر چیکس کی ضرورت ہے۔

اپنے پروجیکٹ کو خودکار بنانے کے سب سے اہم طریقوں میں سے ایک ٹیسٹ شامل کرنا ہے۔

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

خودکار ٹیسٹ ترتیب دیں جو آنے والی تمام شراکتوں پر چلیں گے، اور اس بات کو یقینی بنائیں کہ آپ کے ٹیسٹ آسانی سے شراکت داروں کے ذریعے مقامی طور پر چلائے جا سکتے ہیں۔ تمام کوڈ شراکتیں آپ کے ٹیسٹوں کو جمع کروانے سے پہلے پاس کر لیں۔ آپ تمام گذارشات کے لیے معیار کا کم از کم معیار مقرر کرنے میں مدد کریں گے۔ Required status checks GitHub پر اس بات کو یقینی بنانے میں مدد کر سکتا ہے کہ آپ کے ٹیسٹ پاس کیے بغیر کوئی تبدیلی ضم نہ ہو۔

اگر آپ ٹیسٹ شامل کرتے ہیں تو یقینی بنائیں کہ وہ آپ کی CONTRIBUTING فائل میں کیسے کام کرتے ہیں۔

دیکھ بھال کے بنیادی کاموں کو خودکار کرنے کے لیے ٹولز کا استعمال کریں۔

ایک مشہور پروجیکٹ کو برقرار رکھنے کے بارے میں اچھی خبر یہ ہے کہ دوسرے دیکھ بھال کرنے والوں نے شاید اسی طرح کے مسائل کا سامنا کیا ہے اور ان کے لئے ایک حل تیار کیا ہے۔

دیکھ بھال کے کام کے کچھ پہلوؤں کو خودکار بنانے میں مدد کے لیے variety of tools available۔ چند مثالیں:

• semantic-release آپ کی ریلیز کو خودکار کرتا ہے
• mention-bot پل کی درخواستوں کے لیے ممکنہ جائزہ لینے والوں کا تذکرہ کرتا ہے۔
• Danger خودکار کوڈ کے جائزے میں مدد کرتا ہے۔
• no-response ان مسائل کو بند کرتا ہے جہاں مصنف نے مزید معلومات کی درخواست کا جواب نہیں دیا ہے
• dependabot پرانے تقاضوں کے لیے ہر روز آپ کی انحصاری فائلوں کی جانچ پڑتال کرتا ہے اور جو بھی اسے ملتا ہے اس کے لیے انفرادی پل کی درخواستیں کھولتا ہے۔

بگ رپورٹس اور دیگر عام شراکتوں کے لیے، GitHub کے پاس ایشو ٹیمپلیٹس اور پل ریکوسٹ ٹیمپلیٹس ہیں، جنہیں آپ مواصلات کو ہموار کرنے کے لیے بنا سکتے ہیں۔ آپ وصول کرتے ہیں. @TalAter نے اپنا مسئلہ اور PR ٹیمپلیٹس لکھنے میں آپ کی مدد کرنے کے لیے ایک اپنی اپنی مہم جوئی کا رہنما منتخب کریں بنایا ہے۔

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

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

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

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

توقف کو مارنا ٹھیک ہے۔

اوپن سورس کا کام ایک بار آپ کو خوشی دیتا ہے۔ شاید اب یہ آپ کو پرہیز یا مجرم محسوس کرنے لگا ہے۔

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

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

اگرچہ یہ کہے بغیر جانا چاہئے، ایک وقفہ لے لو! آپ کو اس وقت تک انتظار نہیں کرنا چاہئے جب تک کہ آپ چھٹی لینے کے لیے جلنے کا احساس نہ کریں۔ @brettcannon، ایک ازگر کور ڈویلپر نے لینے کا فیصلہ کیا۔ a month-long vacation 14 سال کے رضاکارانہ OSS کام کے بعد۔

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

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

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

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

پہلے اپنا خیال رکھیں!

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