کامیابی کے لیے اپنے پروجیکٹ کو ترتیب دینا
آپ نے اپنا پروجیکٹ شروع کیا ہے، آپ اس بات کو پھیلا رہے ہیں، اور لوگ اسے چیک کر رہے ہیں۔ خوفناک! اب، آپ ان کے ارد گرد رہنا کیسے حاصل کرتے ہیں؟
استقبال کرنے والی کمیونٹی آپ کے پروجیکٹ کے مستقبل اور ساکھ میں سرمایہ کاری ہے۔ اگر آپ کا پروجیکٹ ابھی اپنی پہلی شراکتیں دیکھنا شروع کر رہا ہے، تو ابتدائی شراکت داروں کو ایک مثبت تجربہ دے کر شروع کریں، اور ان کے لیے واپس آتے رہنا آسان بنائیں۔
لوگوں کو خوش آمدید کا احساس دلائیں۔
اپنے پروجیکٹ کی کمیونٹی کے بارے میں سوچنے کا ایک طریقہ وہ ہے جسے @MikeMcQuaid contributor funnel:
جب آپ اپنی کمیونٹی بناتے ہیں تو غور کریں کہ فنل کے اوپری حصے میں کوئی شخص (ایک ممکنہ صارف) نظریاتی طور پر نیچے تک کیسے پہنچ سکتا ہے (ایک فعال مینٹینر)۔ آپ کا مقصد شراکت دار کے تجربے کے ہر مرحلے پر رگڑ کو کم کرنا ہے۔ جب لوگ آسانی سے جیتیں گے، تو وہ مزید کچھ کرنے کی ترغیب محسوس کریں گے۔
اپنی دستاویزات کے ساتھ شروع کریں:
- کسی کے لیے اپنا پروجیکٹ استعمال کرنا آسان بنائیں۔ A friendly READMEاور واضح کوڈ کی مثالیں جو بھی آپ کے پروجیکٹ پر اترتا ہے اسے شروع کرنا آسان بنا دے گا۔ your CONTRIBUTING file کا استعمال کرتے ہوئے اور اپنے مسائل کو اپ ٹو ڈیٹ رکھنے کے لیے **واضح طور پر وضاحت کریں کہ کس طرح تعاون کرنا ہے۔
- پہلے اچھے مسائل: نئے تعاون کنندگان کو شروع کرنے میں مدد کرنے کے لیے، واضح طور پر غور کریں labeling issues that are simple enough for beginners to tackle.۔ اس کے بعد GitHub ان مسائل کو پلیٹ فارم پر مختلف جگہوں پر ظاہر کرے گا، مفید شراکت میں اضافہ کرے گا، اور صارفین کی جانب سے ایسے مسائل سے نمٹنے کے لیے رگڑ کو کم کرے گا جو ان کی سطح کے لیے بہت مشکل ہیں۔
GitHub’s 2017 Open Source Survey نے ظاہر کیا کہ اوپن سورس صارفین کے لیے نامکمل یا مبہم دستاویزات سب سے بڑا مسئلہ ہے۔ اچھی دستاویزات لوگوں کو آپ کے پروجیکٹ کے ساتھ بات چیت کرنے کی دعوت دیتی ہیں۔ آخر کار، کوئی ایک مسئلہ کھولے گا یا درخواست کو کھینچ لے گا۔ ان تعاملات کو موقع کے طور پر استعمال کریں تاکہ انہیں فنل سے نیچے لے جا سکیں۔
- جب کوئی آپ کے پروجیکٹ پر نیا اترتا ہے، تو ان کی دلچسپی کے لیے ان کا شکریہ! کسی کو واپس آنا نہ چاہنے کے لیے صرف ایک منفی تجربہ کی ضرورت ہوتی ہے۔
-
ردعمل بنیں۔ اگر آپ ایک ماہ تک ان کے مسئلے کا جواب نہیں دیتے ہیں، تو امکان ہے کہ وہ آپ کے پروجیکٹ کے بارے میں پہلے ہی بھول چکے ہیں۔
- ان تعاون کی اقسام کے بارے میں کھلے ذہن میں رہیں جو آپ قبول کریں گے۔ بہت سے تعاون کنندگان ایک بگ رپورٹ یا ایک چھوٹی اصلاح کے ساتھ شروع کرتے ہیں۔ کسی پروجیکٹ میں عطیہ دینے کے بہت سے طریقے ہیں۔ لوگوں کو مدد کرنے دیں جس طرح وہ مدد کرنا چاہتے ہیں۔
- اگر کوئی شراکت ہے جس سے آپ متفق نہیں ہیں، ان کے خیال کے لیے ان کا شکریہ اور وضاحت کریں کہ کیوں یہ اس کے دائرہ کار میں فٹ نہیں بیٹھتا پروجیکٹ، اگر آپ کے پاس ہے تو متعلقہ دستاویزات سے لنک کرنا۔
اوپن سورس کے تعاون کرنے والوں کی اکثریت “آرام دہ تعاون کرنے والے” ہیں: وہ لوگ جو کبھی کبھار کسی پروجیکٹ میں حصہ ڈالتے ہیں۔ ایک آرام دہ شراکت دار کے پاس آپ کے پروجیکٹ کے ساتھ تیزی سے کام لینے کا وقت نہیں ہوسکتا ہے، لہذا آپ کا کام ان کے لیے تعاون کرنا آسان بنانا ہے۔
دوسرے تعاون کنندگان کی حوصلہ افزائی کرنا اپنے آپ میں بھی سرمایہ کاری ہے۔ جب آپ اپنے سب سے بڑے مداحوں کو اس کام کے ساتھ چلانے کے لیے بااختیار بناتے ہیں جس کے بارے میں وہ پرجوش ہیں، تو سب کچھ خود کرنے کا دباؤ کم ہوتا ہے۔
ہر چیز کو دستاویز کریں۔
جب آپ کوئی نیا پروجیکٹ شروع کرتے ہیں، تو آپ کے کام کو نجی رکھنا فطری محسوس ہو سکتا ہے۔ لیکن اوپن سورس پروجیکٹ اس وقت پروان چڑھتے ہیں جب آپ اپنے عمل کو عوام میں دستاویز کرتے ہیں۔
جب آپ چیزیں لکھتے ہیں، تو راستے کے ہر قدم پر زیادہ لوگ حصہ لے سکتے ہیں۔ آپ کو کسی ایسی چیز پر مدد مل سکتی ہے جس کے بارے میں آپ کو معلوم بھی نہیں تھا کہ آپ کو ضرورت ہے۔
چیزوں کو لکھنے کا مطلب صرف تکنیکی دستاویزات سے زیادہ ہے۔ جب بھی آپ کچھ لکھنے کی خواہش محسوس کریں یا اپنے پروجیکٹ پر نجی طور پر بات کریں، اپنے آپ سے پوچھیں کہ کیا آپ اسے عوامی بنا سکتے ہیں۔
اپنے پروجیکٹ کے روڈ میپ کے بارے میں شفاف رہیں، آپ کنٹریبیوشن کی اقسام تلاش کر رہے ہیں، شراکتوں کا جائزہ کیسے لیا جاتا ہے، یا آپ نے کچھ فیصلے کیوں کیے ہیں۔
اگر آپ دیکھتے ہیں کہ متعدد صارفین ایک ہی مسئلے سے دوچار ہیں، تو جوابات کو README میں دستاویز کریں۔
میٹنگز کے لیے، متعلقہ شمارے میں اپنے نوٹس یا ٹیک وے شائع کرنے پر غور کریں۔ شفافیت کی اس سطح سے آپ کو جو تاثرات ملیں گے وہ آپ کو حیران کر سکتے ہیں۔
ہر چیز کی دستاویز کرنا آپ کے کام پر بھی لاگو ہوتا ہے۔ اگر آپ اپنے پراجیکٹ کی خاطر خواہ اپ ڈیٹ پر کام کر رہے ہیں، تو اسے پل ریکوئسٹ میں ڈالیں اور اسے کام جاری ہے (WIP) کے طور پر نشان زد کریں۔ اس طرح، دوسرے لوگ جلد ہی اس عمل میں شامل ہونے کا احساس کر سکتے ہیں۔
جوابدہ بنیں۔
جب آپ [اپنے پروجیکٹ کو فروغ دیں گے] چیزیں کیسے کام کرتی ہیں اس کے بارے میں ان کے سوالات ہوسکتے ہیں، یا شروع کرنے میں مدد کی ضرورت ہے۔
جواب دینے کی کوشش کریں جب کوئی مسئلہ فائل کرتا ہے، پل کی درخواست جمع کرتا ہے، یا آپ کے پروجیکٹ کے بارے میں کوئی سوال پوچھتا ہے۔ جب آپ تیزی سے جواب دیں گے، تو لوگ محسوس کریں گے کہ وہ مکالمے کا حصہ ہیں، اور وہ اس میں حصہ لینے کے لیے زیادہ پرجوش ہوں گے۔
یہاں تک کہ اگر آپ فوری طور پر درخواست کا جائزہ نہیں لے سکتے ہیں، تو اسے جلد تسلیم کرنے سے مصروفیت بڑھانے میں مدد ملتی ہے۔ یہاں ہے کہ @tdreyno نے Middleman پر پل کی درخواست کا جواب کیسے دیا:
موزیلا کے ایک مطالعے سے معلوم ہوا ہے کہ تعاون کرنے والے جنہوں نے 4 گھنٹے کے اندر کوڈ کا جائزہ لیا اور ریٹرن کی شرح زیادہ تھی۔ شراکت کو دہرائیں۔
آپ کے پروجیکٹ کے بارے میں بات چیت انٹرنیٹ کے ارد گرد دیگر جگہوں پر بھی ہو سکتی ہے، جیسے Stack Overflow، Twitter، یا Reddit۔ آپ ان میں سے کچھ جگہوں پر اطلاعات ترتیب دے سکتے ہیں تاکہ جب کوئی آپ کے پروجیکٹ کا ذکر کرے تو آپ کو الرٹ کیا جائے۔
اپنی کمیونٹی کو جمع ہونے کی جگہ دیں۔
آپ کی کمیونٹی کو جمع ہونے کی جگہ دینے کی دو وجوہات ہیں۔
پہلی وجہ ان کے لیے ہے۔ لوگوں کو ایک دوسرے کو جاننے میں مدد کریں۔ مشترکہ مفادات کے حامل لوگ لامحالہ اس کے بارے میں بات کرنے کی جگہ چاہیں گے۔ اور جب مواصلت عوامی اور قابل رسائی ہوتی ہے، تو کوئی بھی تیز رفتاری اور حصہ لینے کے لیے ماضی کے آرکائیوز کو پڑھ سکتا ہے۔
دوسری وجہ آپ کے لیے ہے۔ اگر آپ لوگوں کو اپنے پروجیکٹ کے بارے میں بات کرنے کے لیے عوامی جگہ نہیں دیتے ہیں، تو وہ ممکنہ طور پر آپ سے براہ راست رابطہ کریں گے۔ شروع میں، نجی پیغامات کا جواب دینا کافی آسان لگتا ہے “صرف ایک بار”۔ لیکن وقت گزرنے کے ساتھ، خاص طور پر اگر آپ کا پروجیکٹ مقبول ہو جاتا ہے، تو آپ تھکن محسوس کریں گے۔ اپنے پروجیکٹ کے بارے میں لوگوں سے نجی طور پر بات چیت کرنے کے لالچ کا مقابلہ کریں۔ اس کے بجائے، انہیں ایک نامزد عوامی چینل پر بھیجیں۔
عوامی رابطہ اتنا ہی آسان ہو سکتا ہے جتنا کہ آپ کو براہ راست ای میل کرنے یا آپ کے بلاگ پر تبصرہ کرنے کے بجائے لوگوں کو مسئلہ کھولنے کی ہدایت کرنا۔ آپ میلنگ لسٹ بھی ترتیب دے سکتے ہیں، یا ٹویٹر اکاؤنٹ، سلیک، یا IRC چینل بنا سکتے ہیں تاکہ لوگ آپ کے پروجیکٹ کے بارے میں بات کر سکیں۔ یا مندرجہ بالا سب کو آزمائیں!
Kubernetes kops کمیونٹی کے اراکین کی مدد کے لیے ہر دوسرے ہفتے دفتری اوقات کو الگ کرتا ہے:
Kops کے پاس کمیونٹی کو مدد اور رہنمائی پیش کرنے کے لیے ہر دوسرے ہفتے کا وقت بھی ہوتا ہے۔ Kops کے دیکھ بھال کرنے والوں نے خاص طور پر نئے آنے والوں کے ساتھ کام کرنے، PRs کے ساتھ مدد کرنے، اور نئی خصوصیات پر تبادلہ خیال کرنے کے لیے وقت مختص کرنے پر اتفاق کیا ہے۔
عوامی مواصلات میں قابل ذکر استثناء یہ ہیں: 1) سیکورٹی کے مسائل اور 2) حساس ضابطہ اخلاق کی خلاف ورزیاں۔ آپ کے پاس ہمیشہ لوگوں کے لیے نجی طور پر ان مسائل کی اطلاع دینے کا ایک طریقہ ہونا چاہیے۔ اگر آپ اپنا ذاتی ای میل استعمال نہیں کرنا چاہتے ہیں تو ایک مخصوص ای میل ایڈریس ترتیب دیں۔
اپنی برادری کو بڑھانا
کمیونٹیز انتہائی طاقتور ہیں۔ وہ طاقت ایک نعمت یا لعنت ہو سکتی ہے، اس بات پر منحصر ہے کہ آپ اسے کیسے چلاتے ہیں۔ جیسے جیسے آپ کے پروجیکٹ کی کمیونٹی بڑھ رہی ہے، اس کی مدد کرنے کے طریقے ہیں تعمیر کی طاقت بننے میں، تباہی نہیں۔
برے اداکاروں کو برداشت نہ کریں۔
کوئی بھی مشہور پروجیکٹ لامحالہ ان لوگوں کو اپنی طرف متوجہ کرے گا جو آپ کی کمیونٹی کو مدد کرنے کے بجائے نقصان پہنچاتے ہیں۔ وہ غیر ضروری بحثیں شروع کر سکتے ہیں، معمولی خصوصیات پر جھگڑا کر سکتے ہیں، یا دوسروں کو دھونس دے سکتے ہیں۔
اس قسم کے لوگوں کے لیے زیرو ٹالرنس کی پالیسی اپنانے کی پوری کوشش کریں۔ اگر ان پر نشان نہ لگایا گیا تو منفی لوگ آپ کی کمیونٹی کے دوسرے لوگوں کو بے چین کر دیں گے۔ وہ چھوڑ بھی سکتے ہیں۔
آپ کے پروجیکٹ کے معمولی پہلوؤں پر باقاعدہ بحثیں آپ سمیت دوسروں کو اہم کاموں پر توجہ مرکوز کرنے سے ہٹاتی ہیں۔ آپ کے پروجیکٹ پر آنے والے نئے لوگ ان بات چیت کو دیکھ سکتے ہیں اور اس میں حصہ نہیں لینا چاہتے ہیں۔
جب آپ اپنے پروجیکٹ پر منفی رویے کو دیکھتے ہیں، تو اسے عوامی طور پر کال کریں۔ نرم مگر مضبوط لہجے میں وضاحت کریں کہ ان کا رویہ قابل قبول کیوں نہیں ہے۔ اگر مسئلہ برقرار رہتا ہے، تو آپ کو ان سے جانے کے لیے کہو کی ضرورت پڑ سکتی ہے۔ آپ کا ضابطہ اخلاق ان مکالموں کے لیے ایک تعمیری رہنما ہو سکتا ہے۔
تعاون کنندگان سے ملیں جہاں وہ ہیں۔
اچھی دستاویزات صرف اس وقت زیادہ اہم ہو جاتی ہیں جب آپ کی کمیونٹی بڑھتی ہے۔ آرام دہ اور پرسکون تعاون کرنے والے، جو آپ کے پروجیکٹ سے بصورت دیگر واقف نہیں ہوں گے، اپنی دستاویزات کو پڑھیں تاکہ ان کی ضرورت کا سیاق و سباق تیزی سے حاصل کیا جا سکے۔
اپنی CONTRIBUTING فائل میں، نئے تعاون کنندگان کو واضح طور پر بتائیں کہ کیسے شروع کیا جائے۔ آپ اس مقصد کے لیے ایک سرشار سیکشن بھی بنانا چاہیں گے۔ Django، مثال کے طور پر، نئے تعاون کنندگان کو خوش آمدید کہنے کے لیے ایک خاص لینڈنگ صفحہ ہے۔
!
آپ کے شمارے کی قطار میں، لیبل کیڑے جو مختلف قسم کے تعاون کنندگان کے لیے موزوں ہیں: مثال کے طور پر، “first timers only”، “پہلے اچھا مسئلہ”، یا “دستاویزات”۔ یہ لیبلز کسی نئے کے لیے آپ کے پروجیکٹ کو جلدی سے اسکین کرنا آسان بناتے ہیں شروع کرنے کے.
آخر میں، لوگوں کو راستے کے ہر قدم پر خوش آئند محسوس کرنے کے لیے اپنی دستاویزات کا استعمال کریں۔
آپ اپنے پروجیکٹ پر اترنے والے زیادہ تر لوگوں کے ساتھ کبھی بات چیت نہیں کریں گے۔ ہو سکتا ہے کہ آپ کو کوئی ایسا تعاون نہیں ملا ہو کیونکہ کسی نے خوف محسوس کیا تھا یا وہ نہیں جانتا تھا کہ کہاں سے شروع کرنا ہے۔ یہاں تک کہ کچھ مہربان الفاظ بھی کسی کو مایوسی میں آپ کے پروجیکٹ کو چھوڑنے سے روک سکتے ہیں۔
مثال کے طور پر، یہاں یہ ہے کہ Rubinius کیسے شروع کرتا ہے اس کا تعاون کرنے والا رہنما:
ہم یہ کہہ کر شروعات کرنا چاہتے ہیں کہ Rubinius استعمال کرنے کے لیے آپ کا شکریہ۔ یہ پروجیکٹ محبت کی محنت ہے، اور ہم ان تمام صارفین کی تعریف کرتے ہیں جو کیڑے پکڑتے ہیں، کارکردگی میں بہتری لاتے ہیں، اور دستاویزات میں مدد کرتے ہیں۔ ہر تعاون معنی خیز ہے، لہذا شرکت کرنے کے لیے آپ کا شکریہ۔ یہ کہا جا رہا ہے، یہاں کچھ رہنما خطوط ہیں جن پر ہم آپ سے عمل کرنے کو کہتے ہیں تاکہ ہم آپ کے مسئلے کو کامیابی سے حل کر سکیں۔
اپنے پروجیکٹ کی ملکیت کا اشتراک کریں۔
جب لوگ ملکیت کا احساس محسوس کرتے ہیں تو پروجیکٹس میں حصہ ڈالنے کے لیے پرجوش ہوتے ہیں۔ اس کا مطلب یہ نہیں ہے کہ آپ کو اپنے پروجیکٹ کے وژن کو تبدیل کرنے یا وہ تعاون قبول کرنے کی ضرورت ہے جو آپ نہیں چاہتے ہیں۔ لیکن جتنا زیادہ آپ دوسروں کو کریڈٹ دیں گے، وہ اتنا ہی زیادہ رہیں گے۔
دیکھیں کہ کیا آپ اپنی کمیونٹی کے ساتھ زیادہ سے زیادہ ملکیت کا اشتراک کرنے کے طریقے تلاش کر سکتے ہیں۔ یہاں کچھ خیالات ہیں:
- آسان (غیر اہم) کیڑوں کو ٹھیک کرنے کے خلاف مزاحمت کریں۔ اس کے بجائے، انہیں نئے شراکت داروں کو بھرتی کرنے کے مواقع کے طور پر استعمال کریں، یا کسی ایسے شخص کی رہنمائی کریں جو تعاون کرنا چاہے۔ شروع میں یہ غیر فطری معلوم ہو سکتا ہے، لیکن آپ کی سرمایہ کاری وقت کے ساتھ ساتھ ادا ہو جائے گی۔ مثال کے طور پر، @michaeljoseph نے ایک تعاون کنندہ کو Cookiecutter کے مسئلے کو خود حل کرنے کے بجائے اس پر پل کی درخواست جمع کرانے کو کہا۔
- اپنے پروجیکٹ میں CONTRIBUTORS یا AUTHORS فائل شروع کریں جس میں ہر اس شخص کی فہرست ہو جس نے آپ کے پروجیکٹ میں تعاون کیا ہے، جیسے Sinatra کرتا ہے۔
*اگر آپ کے پاس ایک بڑی کمیونٹی ہے، تو ایک نیوز لیٹر بھیجیں یا بلاگ پوسٹ لکھیں تعاون کرنے والوں کا شکریہ ادا کریں۔ Rust’s This Week in Rust اور Hoodie’s Shoutouts دو اچھے ہیں مثالیں
- ہر تعاون کرنے والے کو کمٹڈ رسائی دیں۔ @felixge نے پایا کہ اس سے لوگ اپنے پیچ پالش کرنے کے لیے زیادہ پرجوش ہیں، اور اسے ایسے پروجیکٹس کے لیے نئے مینٹینرز بھی مل گئے جن پر اس نے کچھ عرصے سے کام نہیں کیا تھا۔
*اگر آپ کا پروجیکٹ GitHub پر ہے، تو اپنے پروجیکٹ کو اپنے ذاتی اکاؤنٹ سے ایک تنظیم میں منتقل کریں اور شامل کریں۔ کم از کم ایک بیک اپ ایڈمن۔ تنظیمیں بیرونی ساتھیوں کے ساتھ منصوبوں پر کام کرنا آسان بناتی ہیں۔
حقیقت یہ ہے کہ زیادہ تر پروجیکٹس میں صرف ایک یا دو مینٹینرز ہوتے ہیں جو زیادہ تر کام کرتے ہیں۔ آپ کا پروجیکٹ جتنا بڑا ہوگا، اور آپ کی کمیونٹی جتنی بڑی ہوگی، مدد تلاش کرنا اتنا ہی آسان ہوگا۔
اگرچہ آپ کو کال کا جواب دینے کے لیے ہمیشہ کوئی شخص نہیں مل سکتا ہے، لیکن وہاں سگنل لگانے سے اس بات کے امکانات بڑھ جاتے ہیں کہ دوسرے لوگ اندر آ جائیں گے۔ اور جتنی جلدی آپ شروع کریں گے، اتنی جلدی لوگ مدد کر سکتے ہیں۔
تنازعات کو حل کرنا
آپ کے پروجیکٹ کے ابتدائی مراحل میں، بڑے فیصلے کرنا آسان ہے۔ جب آپ کچھ کرنا چاہتے ہیں، آپ صرف کرتے ہیں.
جیسے جیسے آپ کا پروجیکٹ زیادہ مقبول ہوتا جائے گا، زیادہ لوگ آپ کے فیصلوں میں دلچسپی لیں گے۔ یہاں تک کہ اگر آپ کے پاس تعاون کرنے والوں کی ایک بڑی کمیونٹی نہیں ہے، اگر آپ کے پروجیکٹ میں بہت سارے صارفین ہیں، تو آپ کو ایسے لوگ ملیں گے جو فیصلوں پر وزن رکھتے ہیں یا اپنے مسائل اٹھاتے ہیں۔
زیادہ تر حصے کے لیے، اگر آپ نے ایک دوستانہ، عزت دار کمیونٹی کو فروغ دیا ہے اور اپنے عمل کو کھلے عام دستاویز کیا ہے، تو آپ کی کمیونٹی کو حل تلاش کرنے کے قابل ہونا چاہیے۔ لیکن بعض اوقات آپ کسی ایسے مسئلے کا شکار ہو جاتے ہیں جس کو حل کرنا تھوڑا مشکل ہوتا ہے۔
احسان کے لئے بار مقرر کریں۔
جب آپ کی کمیونٹی کسی مشکل مسئلے سے دوچار ہوتی ہے تو غصہ بڑھ سکتا ہے۔ لوگ ناراض یا مایوس ہو سکتے ہیں اور اسے ایک دوسرے پر یا آپ پر نکال سکتے ہیں۔
دیکھ بھال کرنے والے کے طور پر آپ کا کام ان حالات کو بڑھنے سے روکنا ہے۔ یہاں تک کہ اگر آپ اس موضوع پر ایک مضبوط رائے رکھتے ہیں تو، لڑائی میں کودنے اور اپنے خیالات کو آگے بڑھانے کے بجائے ایک ناظم یا سہولت کار کا عہدہ لینے کی کوشش کریں۔ اگر کوئی بدتمیزی کر رہا ہے یا گفتگو پر اجارہ داری کر رہا ہے، تو فوری طور پر عمل کریں تاکہ بات چیت کو سول اور نتیجہ خیز بنایا جا سکے۔
دوسرے لوگ رہنمائی کے لیے آپ کی طرف دیکھ رہے ہیں۔ ایک اچھی مثال قائم کریں۔ آپ اب بھی مایوسی، ناخوشی یا تشویش کا اظہار کر سکتے ہیں، لیکن سکون سے کریں۔
اپنا ٹھنڈا رکھنا آسان نہیں ہے، لیکن قیادت کا مظاہرہ کرنا آپ کی کمیونٹی کی صحت کو بہتر بناتا ہے۔ انٹرنیٹ آپ کا شکریہ۔
اپنے README کو آئین کی طرح سمجھیں۔
آپ کا README [ہدایات کے صرف ایک سیٹ سے زیادہ] (../starting-a-project/#writing-a-readme) ہے۔ یہ آپ کے اہداف، پروڈکٹ ویژن، اور روڈ میپ کے بارے میں بات کرنے کی جگہ بھی ہے۔ اگر لوگ کسی خاص خصوصیت کی خوبی پر بحث کرنے پر ضرورت سے زیادہ توجہ مرکوز کرتے ہیں، تو یہ آپ کے README کو دوبارہ دیکھنے اور آپ کے پروجیکٹ کے اعلی وژن کے بارے میں بات کرنے میں مدد کر سکتا ہے۔ اپنے README پر توجہ مرکوز کرنا بھی گفتگو کو غیر ذاتی بنا دیتا ہے، تاکہ آپ تعمیری گفتگو کر سکیں۔
منزل پر نہیں، سفر پر توجہ دیں۔
کچھ منصوبے بڑے فیصلے کرنے کے لیے ووٹنگ کے عمل کا استعمال کرتے ہیں۔ پہلی نظر میں سمجھدار ہونے کے باوجود، ووٹنگ ایک دوسرے کے خدشات کو سننے اور ان کو دور کرنے کے بجائے “جواب” حاصل کرنے پر زور دیتی ہے۔
ووٹنگ سیاسی بن سکتی ہے، جہاں کمیونٹی کے اراکین ایک دوسرے کے حق میں یا کسی خاص طریقے سے ووٹ ڈالنے کے لیے دباؤ محسوس کرتے ہیں۔ ہر کوئی ووٹ نہیں دیتا، چاہے وہ خاموش اکثریت آپ کی کمیونٹی میں، یا موجودہ صارفین جو نہیں جانتے تھے کہ ووٹ ہو رہا ہے۔
بعض اوقات، ووٹنگ ایک ضروری ٹائی بریکر ہوتا ہے۔ تاہم، جتنا آپ کر سکتے ہیں، اتفاق رائے کی بجائے “اتفاق کی تلاش” پر زور دیں۔
اتفاق رائے کے حصول کے عمل کے تحت، کمیونٹی کے اراکین اس وقت تک اہم خدشات پر تبادلہ خیال کرتے ہیں جب تک کہ وہ محسوس نہ کریں کہ انہیں مناسب طور پر سنا گیا ہے۔ جب صرف معمولی خدشات باقی رہ جاتے ہیں تو کمیونٹی آگے بڑھ جاتی ہے۔ “اتفاق رائے کی تلاش” اس بات کو تسلیم کرتی ہے کہ ایک کمیونٹی کامل جواب تک پہنچنے کے قابل نہیں ہوسکتی ہے۔ اس کے بجائے، یہ سننے اور بحث کو ترجیح دیتا ہے۔
یہاں تک کہ اگر آپ واقعی اتفاق رائے کے حصول کے عمل کو نہیں اپناتے ہیں، بطور پروجیکٹ مینٹینر، یہ ضروری ہے کہ لوگ جانیں کہ آپ سن رہے ہیں۔ دوسرے لوگوں کو سننے کا احساس دلانا، اور ان کے خدشات کو حل کرنے کا عہد کرنا، حساس حالات کو پھیلانے کے لیے ایک طویل سفر طے کرتا ہے۔ پھر، اعمال کے ساتھ اپنے الفاظ پر عمل کریں۔
کسی قرارداد کی خاطر کسی فیصلے میں جلدی نہ کریں۔ اس بات کو یقینی بنائیں کہ ہر کوئی سنتا محسوس کرے اور کسی قرارداد کی طرف بڑھنے سے پہلے تمام معلومات کو عام کر دیا گیا ہو۔
گفتگو کو عمل پر مرکوز رکھیں
بات چیت اہم ہے، لیکن نتیجہ خیز اور غیر نتیجہ خیز گفتگو میں فرق ہے۔
بحث کی حوصلہ افزائی کریں جب تک کہ یہ فعال طور پر حل کی طرف بڑھ رہی ہے۔ اگر یہ واضح ہے کہ بات چیت ختم ہو رہی ہے یا موضوع سے ہٹ رہی ہے، جابس ذاتی ہو رہے ہیں، یا لوگ معمولی تفصیلات کے بارے میں جھگڑ رہے ہیں، تو اسے بند کرنے کا وقت آ گیا ہے۔
ان بات چیت کو جاری رکھنے کی اجازت دینا نہ صرف ہاتھ میں موجود مسئلے کے لیے برا ہے، بلکہ آپ کی کمیونٹی کی صحت کے لیے بھی برا ہے۔ یہ پیغام بھیجتا ہے کہ اس قسم کی گفتگو کی اجازت ہے یا اس کی حوصلہ افزائی بھی کی جاتی ہے، اور یہ لوگوں کو مستقبل کے مسائل کو اٹھانے یا حل کرنے سے حوصلہ شکنی کر سکتی ہے۔
آپ کے یا دوسروں کے ذریعہ بنائے گئے ہر نکتے کے ساتھ، اپنے آپ سے پوچھیں، “یہ ہمیں کسی حل کے قریب کیسے لاتا ہے؟”
اگر بات چیت کھلنا شروع ہو رہی ہے، تو گروپ سے پوچھیں، “ہمیں آگے کون سا قدم اٹھانا چاہیے؟” بات چیت پر دوبارہ توجہ مرکوز کرنے کے لیے۔
اگر کوئی بات چیت واضح طور پر کہیں نہیں جا رہی ہے، کوئی واضح کارروائی نہیں کی جا رہی ہے، یا مناسب کارروائی پہلے ہی کی جا چکی ہے، تو اس مسئلے کو بند کریں اور وضاحت کریں کہ آپ نے اسے کیوں بند کیا۔
اپنی لڑائیوں کو سمجھداری سے چنیں۔
سیاق و سباق اہم ہے۔ غور کریں کہ بحث میں کون شامل ہے اور وہ کس طرح باقی کمیونٹی کی نمائندگی کرتے ہیں۔
کیا کمیونٹی میں ہر کوئی اس مسئلے سے پریشان ہے، یا اس سے بھی منسلک ہے؟ یا اکیلا پریشانی پیدا کرنے والا ہے؟ اپنی خاموش کمیونٹی کے اراکین پر غور کرنا نہ بھولیں، نہ صرف فعال آوازوں پر۔
اگر مسئلہ آپ کی کمیونٹی کی وسیع تر ضروریات کی نمائندگی نہیں کرتا ہے، تو آپ کو صرف چند لوگوں کے خدشات کو تسلیم کرنے کی ضرورت ہوگی۔ اگر یہ ایک واضح حل کے بغیر ایک بار بار چلنے والا مسئلہ ہے، تو اس موضوع پر پچھلے مباحثوں کی طرف اشارہ کریں اور تھریڈ کو بند کریں۔
کمیونٹی ٹائی بریکر کی شناخت کریں۔
اچھے رویے اور واضح مواصلت کے ساتھ، زیادہ تر مشکل حالات قابلِ حل ہوتے ہیں۔ تاہم، نتیجہ خیز گفتگو میں بھی، آگے بڑھنے کے طریقہ پر رائے میں فرق ہوسکتا ہے۔ ان صورتوں میں، کسی فرد یا لوگوں کے گروپ کی نشاندہی کریں جو ٹائی بریکر کے طور پر کام کر سکتے ہیں۔
ٹائی بریکر پروجیکٹ کا بنیادی مینٹینر ہو سکتا ہے، یا یہ لوگوں کا ایک چھوٹا گروپ ہو سکتا ہے جو ووٹنگ کی بنیاد پر فیصلہ کرتے ہیں۔ مثالی طور پر، آپ نے گورننس فائل میں ٹائی بریکر اور اس سے وابستہ عمل کی نشاندہی کی ہے اس سے پہلے کہ آپ کو اسے استعمال کرنا پڑے۔
آپ کا ٹائی بریکر آخری حربہ ہونا چاہیے۔ تفرقہ انگیز مسائل آپ کی کمیونٹی کے لیے بڑھنے اور سیکھنے کا ایک موقع ہیں۔ ان مواقع کو گلے لگائیں اور جہاں بھی ممکن ہو کسی قرارداد کی طرف جانے کے لیے ایک باہمی عمل کا استعمال کریں۔
کمیونٹی اوپن سورس کا ❤️ ہے۔
صحت مند، ترقی پزیر کمیونٹیز ہر ہفتے اوپن سورس میں ڈالے جانے والے ہزاروں گھنٹوں کو ایندھن فراہم کرتی ہیں۔ بہت سے شراکت دار دوسرے لوگوں کو اوپن سورس پر کام کرنے - یا کام نہ کرنے کی وجہ بتاتے ہیں۔ اس طاقت کو تعمیری طور پر استعمال کرنے کا طریقہ سیکھ کر، آپ کسی ایسے شخص کی مدد کریں گے جس کو اوپن سورس کا ناقابل فراموش تجربہ حاصل ہو۔
