From 9c427c687a002d4f4094b768ffed7cd2e30b6617 Mon Sep 17 00:00:00 2001 From: Areebey Date: Sun, 15 Oct 2023 03:40:56 +0500 Subject: [PATCH 01/10] Convert into Urdu lang --- _articles/ur/best-practices.md | 284 +++++++++++++++++++++++++++++++++ 1 file changed, 284 insertions(+) create mode 100644 _articles/ur/best-practices.md diff --git a/_articles/ur/best-practices.md b/_articles/ur/best-practices.md new file mode 100644 index 00000000000..9113d16e115 --- /dev/null +++ b/_articles/ur/best-practices.md @@ -0,0 +1,284 @@ +--- +lang: ur +title: دیکھ بھال کرنے والوں کے لیے بہترین طرز عمل +description: ایک اوپن سورس مینٹینر کے طور پر اپنی زندگی کو آسان بنانا، دستاویزی عمل سے لے کر اپنی کمیونٹی کا فائدہ اٹھانا۔ +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +## دیکھ بھال کرنے والا ہونے کا کیا مطلب ہے؟ + +اگر آپ اوپن سورس پروجیکٹ کو برقرار رکھتے ہیں جسے بہت سارے لوگ استعمال کرتے ہیں، تو آپ نے محسوس کیا ہوگا کہ آپ کم کوڈنگ کر رہے ہیں اور مسائل کا زیادہ جواب دے رہے ہیں۔ + +کسی پروجیکٹ کے ابتدائی مراحل میں، آپ نئے آئیڈیاز کے ساتھ تجربہ کر رہے ہیں اور اپنی مرضی کی بنیاد پر فیصلے کر رہے ہیں۔ جیسے جیسے آپ کے پروجیکٹ کی مقبولیت میں اضافہ ہوتا جائے گا، آپ خود کو اپنے صارفین اور معاونین کے ساتھ مزید کام کرتے ہوئے پائیں گے۔ + +کسی پروجیکٹ کو برقرار رکھنے کے لیے کوڈ سے زیادہ کی ضرورت ہوتی ہے۔ یہ کام اکثر غیر متوقع ہوتے ہیں، لیکن یہ بڑھتے ہوئے پروجیکٹ کے لیے اتنے ہی اہم ہوتے ہیں۔ ہم نے آپ کی زندگی کو آسان بنانے کے چند طریقے اکٹھے کیے ہیں، دستاویزی عمل سے لے کر آپ کی کمیونٹی کو فائدہ پہنچانے تک۔ + +## اپنے عمل کو دستاویزی بنانا + +چیزوں کو لکھنا سب سے اہم چیزوں میں سے ایک ہے جو آپ دیکھ بھال کرنے والے کے طور پر کر سکتے ہیں۔ + +دستاویز نہ صرف آپ کی اپنی سوچ کو واضح کرتی ہے، بلکہ اس سے دوسرے لوگوں کو یہ سمجھنے میں مدد ملتی ہے کہ آپ کو کیا ضرورت ہے یا توقع ہے، اس سے پہلے کہ وہ پوچھیں۔ + +چیزوں کو لکھنے سے جب کوئی چیز آپ کے دائرہ کار میں فٹ نہ ہو تو نہ کہنا آسان ہو جاتا ہے۔ یہ لوگوں کے لیے اندر آنے اور مدد کرنا بھی آسان بناتا ہے۔ آپ کبھی نہیں جانتے کہ کون آپ کے پروجیکٹ کو پڑھ رہا ہے یا استعمال کر رہا ہے۔ + +یہاں تک کہ اگر آپ مکمل پیراگراف استعمال نہیں کرتے ہیں تو، بلٹ پوائنٹس کو لکھنا بالکل نہ لکھنے سے بہتر ہے۔ + +اپنے دستاویزات کو اپ ٹو ڈیٹ رکھنا یاد رکھیں۔ اگر آپ ہمیشہ ایسا کرنے کے قابل نہیں ہیں، تو اپنی پرانی دستاویزات کو حذف کریں یا اس کے پرانے ہونے کی نشاندہی کریں تاکہ تعاون کنندگان کو معلوم ہو کہ اپ ڈیٹس خوش آئند ہیں۔ + +### اپنے پروجیکٹ کا وژن لکھیں۔ + +اپنے پروجیکٹ کے اہداف لکھ کر شروع کریں۔ انہیں اپنے README میں شامل کریں، یا VISION نامی ایک الگ فائل بنائیں۔ اگر کوئی اور نمونے ہیں جو مدد کر سکتے ہیں، جیسے کہ پروجیکٹ روڈ میپ، ان کو بھی عوامی بنائیں۔ + +واضح، دستاویزی وژن کا ہونا آپ کو مرکوز رکھتا ہے اور دوسروں کے تعاون سے "اسکوپ کریپ" سے بچنے میں آپ کی مدد کرتا ہے۔ + +مثال کے طور پر، @lord نے دریافت کیا کہ پراجیکٹ وژن رکھنے سے اسے یہ جاننے میں مدد ملی کہ کن درخواستوں پر وقت گزارنا ہے۔ ایک نئے دیکھ بھال کرنے والے کے طور پر، جب اسے پہلی خصوصیت کی درخواست موصول ہوئی تو اسے اپنے پروجیکٹ کے دائرہ کار پر قائم نہ رہنے پر افسوس ہوا۔ [Slate](https://github.com/lord/slate). + + + +### اپنی توقعات سے آگاہ کریں۔ + +قواعد لکھنے کے لیے اعصاب شکن ہو سکتے ہیں۔ کبھی کبھی آپ کو ایسا محسوس ہو سکتا ہے کہ آپ دوسرے لوگوں کے رویے پر پولیسنگ کر رہے ہیں یا سارا مزہ ختم کر رہے ہیں۔ + +تحریری اور منصفانہ طور پر نافذ کیا جاتا ہے، تاہم، اچھے اصول دیکھ بھال کرنے والوں کو بااختیار بناتے ہیں۔ وہ آپ کو ان کاموں میں گھسیٹنے سے روکتے ہیں جو آپ نہیں کرنا چاہتے۔ + +زیادہ تر لوگ جو آپ کے پروجیکٹ میں آتے ہیں وہ آپ یا آپ کے حالات کے بارے میں کچھ نہیں جانتے ہیں۔ وہ فرض کر سکتے ہیں کہ آپ کو اس پر کام کرنے کے لیے معاوضہ ملتا ہے، خاص طور پر اگر یہ وہ چیز ہے جسے وہ باقاعدگی سے استعمال کرتے ہیں اور اس پر انحصار کرتے ہیں۔ ہوسکتا ہے کہ ایک موقع پر آپ نے اپنے پروجیکٹ میں بہت زیادہ وقت لگایا، لیکن اب آپ کسی نئی ملازمت یا خاندان کے رکن کے ساتھ مصروف ہیں۔ + +یہ سب بالکل ٹھیک ہے! بس اس بات کو یقینی بنائیں کہ دوسرے لوگ اس کے بارے میں جانتے ہیں۔ + +اگر آپ کے پروجیکٹ کو برقرار رکھنا جز وقتی ہے یا مکمل طور پر رضاکارانہ ہے، تو ایماندار ہو کہ آپ کے پاس کتنا وقت ہے۔ یہ وہی نہیں ہے جتنا آپ کے خیال میں پروجیکٹ کے لیے کتنا وقت درکار ہے، یا دوسرے لوگ آپ سے کتنا وقت گزارنا چاہتے ہیں۔ + + +یہاں کچھ اصول ہیں جو لکھنے کے قابل ہیں: + +* شراکت کا جائزہ اور قبول کیسے کیا جاتا ہے (_کیا انہیں ٹیسٹ کی ضرورت ہے؟ ایک ایشو ٹیمپلیٹ؟_) +* شراکت کی وہ قسمیں جنہیں آپ قبول کریں گے (_کیا آپ اپنے کوڈ کے صرف ایک مخصوص حصے میں مدد چاہتے ہیں؟_) +* جب فالو اپ کرنا مناسب ہو (مثال کے طور پر، "آپ 7 دنوں کے اندر مینٹینر سے جواب کی توقع کر سکتے ہیں۔ اگر آپ نے اس وقت تک کچھ نہیں سنا، تو بلا جھجھک تھریڈ کو پنگ کریں۔"_) +* آپ پروجیکٹ پر کتنا وقت صرف کرتے ہیں (_مثال کے طور پر، "ہم اس پروجیکٹ پر صرف 5 گھنٹے فی ہفتہ صرف کرتے ہیں"_) + + +[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) دیکھ بھال کرنے والوں اور تعاون کرنے والوں کے لیے زمینی اصولوں کے ساتھ منصوبوں کی کئی مثالیں ہیں۔ + +### مواصلات کو عام رکھیں + +اپنے تعاملات کو بھی دستاویز کرنا نہ بھولیں۔ جہاں کہیں بھی ہو سکے، اپنے پراجیکٹ کے بارے میں عوامی رابطہ رکھیں۔ اگر کوئی خصوصیت کی درخواست یا مدد کی ضرورت پر بات کرنے کے لیے آپ سے نجی طور پر رابطہ کرنے کی کوشش کرتا ہے، تو اسے شائستگی کے ساتھ عوامی مواصلاتی چینل، جیسے میلنگ لسٹ یا ایشو ٹریکر پر بھیجیں۔ + +اگر آپ دوسرے دیکھ بھال کرنے والوں سے ملتے ہیں، یا نجی طور پر کوئی بڑا فیصلہ کرتے ہیں، تو ان بات چیت کو عوامی طور پر دستاویز کریں، چاہے یہ صرف آپ کے نوٹس پوسٹ کر رہا ہو۔ + +اس طرح، آپ کی کمیونٹی میں شامل ہونے والے کسی بھی شخص کو وہی معلومات تک رسائی حاصل ہوگی جو وہاں برسوں سے موجود ہے۔ + +## نہیں کہنا سیکھنا + +آپ نے چیزیں لکھ دی ہیں۔ مثالی طور پر، ہر کوئی آپ کی دستاویزات کو پڑھے گا، لیکن حقیقت میں، آپ کو دوسروں کو یاد دلانا پڑے گا کہ یہ علم موجود ہے۔ + +تاہم، جب آپ کو اپنے قوانین کو نافذ کرنے کی ضرورت ہوتی ہے تو ہر چیز کو تحریر کرنے سے حالات کو ذاتی نوعیت کا بنانے میں مدد ملتی ہے۔ + +نہیں کہنا مزہ نہیں ہے، لیکن _"آپ کا تعاون اس پروجیکٹ کے معیار سے میل نہیں کھاتا"_ اس سے کم ذاتی محسوس ہوتا ہے _"مجھے آپ کا تعاون پسند نہیں"_۔ + +نہ کہنے کا اطلاق بہت سے ایسے حالات پر ہوتا ہے جن کا آپ ایک مینٹینر کے طور پر سامنا کریں گے: خصوصیت کی درخواستیں جو دائرہ کار کے مطابق نہیں ہیں، کوئی بحث کو پٹڑی سے اتار رہا ہے، دوسروں کے لیے غیر ضروری کام کر رہا ہے۔ + +### گفتگو کو دوستانہ رکھیں + +سب سے اہم جگہوں میں سے ایک جہاں آپ اپنے مسئلے پر نہیں کہنے کی مشق کریں گے اور درخواست کی قطار کو کھینچیں گے۔ پروجیکٹ مینٹینر کے طور پر، آپ کو لامحالہ ایسی تجاویز موصول ہوں گی جنہیں آپ قبول نہیں کرنا چاہتے۔ + +ہوسکتا ہے کہ شراکت آپ کے پروجیکٹ کے دائرہ کار کو تبدیل کردے یا آپ کے وژن سے میل نہ کھائے۔ ہوسکتا ہے کہ خیال اچھا ہو، لیکن عمل درآمد ناقص ہے۔ + +وجہ سے قطع نظر، آپ کے پروجیکٹ کے معیارات پر پورا نہ اترنے والے تعاون کو تدبر سے سنبھالنا ممکن ہے۔ + +اگر آپ کو کوئی ایسا تعاون ملتا ہے جسے آپ قبول نہیں کرنا چاہتے، تو آپ کا پہلا ردعمل اسے نظر انداز کرنا یا یہ دکھاوا کرنا ہو سکتا ہے کہ آپ نے اسے نہیں دیکھا۔ ایسا کرنے سے دوسرے شخص کے جذبات کو ٹھیس پہنچ سکتی ہے اور یہاں تک کہ آپ کی کمیونٹی میں دیگر ممکنہ شراکت داروں کی حوصلہ شکنی بھی ہو سکتی ہے۔ + + + +غیر مطلوبہ شراکت کو کھلا نہ چھوڑیں کیونکہ آپ خود کو مجرم محسوس کرتے ہیں یا اچھا بننا چاہتے ہیں۔ وقت گزرنے کے ساتھ، آپ کے جواب نہ ملنے والے مسائل اور PR آپ کے پروجیکٹ پر کام کرنے کو زیادہ دباؤ اور خوفزدہ کرنے کا احساس دلائیں گے۔ + +یہ بہتر ہے کہ وہ تعاون فوری طور پر بند کر دیں جنہیں آپ جانتے ہیں کہ آپ قبول نہیں کرنا چاہتے۔ اگر آپ کا پروجیکٹ پہلے سے ہی ایک بڑے بیک لاگ کا شکار ہے تو، @steveklabnik کے لیے تجاویز ہیں۔ [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). + +دوم، شراکت کو نظر انداز کرنا آپ کی کمیونٹی کو منفی سگنل بھیجتا ہے۔ کسی پروجیکٹ میں تعاون کرنا خوفناک ہوسکتا ہے، خاص طور پر اگر یہ کسی کے لیے پہلی بار ہو۔ یہاں تک کہ اگر آپ ان کے تعاون کو قبول نہیں کرتے ہیں، تو اس کے پیچھے موجود شخص کو تسلیم کریں اور ان کی دلچسپی کے لیے ان کا شکریہ ادا کریں۔ یہ ایک بڑی تعریف ہے! + +اگر آپ شراکت قبول نہیں کرنا چاہتے ہیں: + +**ان کے تعاون کے لیے ان کا شکریہ** +*** وضاحت کریں کہ یہ پروجیکٹ کے دائرہ کار میں کیوں فٹ نہیں ہے، اور اگر آپ قابل ہو تو بہتری کے لیے واضح تجاویز پیش کریں۔ مہربان رہو، لیکن مضبوط. +* **متعلقہ دستاویزات کا لنک**، اگر آپ کے پاس ہے۔ اگر آپ کو ان چیزوں کے لیے بار بار درخواستیں نظر آتی ہیں جنہیں آپ قبول نہیں کرنا چاہتے ہیں، تو اپنے آپ کو دہرانے سے بچنے کے لیے انہیں اپنی دستاویزات میں شامل کریں۔ +***درخواست بند کریں** + +جواب دینے کے لیے آپ کو 1-2 سے زیادہ جملوں کی ضرورت نہیں ہونی چاہیے۔ مثال کے طور پر، جب کوئی صارف [celery](https://github.com/celery/celery/) ونڈوز سے متعلق غلطی کی اطلاع دی، @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383): + +![Celery screenshot](/assets/images/best-practices/celery.png) + +اگر نہ کہنے کا خیال آپ کو خوفزدہ کرتا ہے تو آپ اکیلے نہیں ہیں۔ As @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/): + +> میں نے کئی مختلف اوپن سورس پروجیکٹس، Mesos، Kubernetes، Chromium کے مینٹینرز سے بات کی ہے، اور وہ سب اس بات سے متفق ہیں کہ مینٹینر ہونے کے سب سے مشکل حصوں میں سے ایک یہ ہے کہ آپ جو پیچ نہیں چاہتے ہیں انہیں "نہیں" کہنا ہے۔ + +کسی کے تعاون کو قبول نہ کرنے کے بارے میں مجرم محسوس نہ کریں۔ اوپن سورس کا پہلا اصول، [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"نہیں عارضی ہے، ہاں ہمیشہ کے لیے ہے۔"_ جب کہ کسی دوسرے شخص کے جوش و جذبے کے ساتھ ہمدردی کرنا ایک اچھی چیز ہے، لیکن کسی شراکت کو مسترد کرنا اس کے پیچھے موجود شخص کو مسترد کرنے کے مترادف نہیں ہے۔ + +بالآخر، اگر کوئی شراکت کافی اچھی نہیں ہے، تو آپ اسے قبول کرنے کے پابند نہیں ہیں۔ جب لوگ آپ کے پروجیکٹ میں تعاون کرتے ہیں تو مہربان اور ذمہ دار بنیں، لیکن صرف ان تبدیلیوں کو قبول کریں جن پر آپ کو یقین ہے کہ آپ کے پروجیکٹ کو بہتر بنایا جائے گا۔ جتنی بار آپ نہ کہنے کی مشق کریں گے، اتنا ہی آسان ہوتا جائے گا۔ وعدہ۔ + +### متحرک رہیں + +سب سے پہلے ناپسندیدہ تعاون کے حجم کو کم کرنے کے لیے، اپنے تعاون کرنے والی گائیڈ میں شراکت جمع کرانے اور قبول کرنے کے لیے اپنے پروجیکٹ کے عمل کی وضاحت کریں۔ + +اگر آپ کو بہت زیادہ کم معیار کی شراکتیں موصول ہو رہی ہیں، تو ضرورت ہے کہ تعاون کرنے والے پہلے سے تھوڑا سا کام کریں، مثال کے طور پر: + +* ایک شمارہ یا PR ٹیمپلیٹ/چیک لسٹ پُر کریں۔ +* PR جمع کرانے سے پہلے ایک مسئلہ کھولیں۔ + +اگر وہ آپ کے اصولوں پر عمل نہیں کرتے ہیں، تو مسئلہ کو فوری طور پر بند کریں اور اپنی دستاویزات کی طرف اشارہ کریں۔ + +اگرچہ یہ نقطہ نظر شروع میں غیر مہذب محسوس کر سکتا ہے، فعال ہونا اصل میں دونوں فریقوں کے لیے اچھا ہے۔ یہ اس موقع کو کم کر دیتا ہے کہ کوئی شخص کام کے بہت سے ضائع ہونے والے گھنٹوں کو پل کی درخواست میں ڈالے گا جسے آپ قبول نہیں کرنے جا رہے ہیں۔ اور یہ آپ کے کام کے بوجھ کو منظم کرنا آسان بناتا ہے۔ + + + +بعض اوقات، جب آپ نہیں کہتے ہیں، تو آپ کا ممکنہ تعاون کنندہ پریشان ہو سکتا ہے یا آپ کے فیصلے پر تنقید کر سکتا ہے۔ اگر ان کا رویہ معاندانہ ہو جائے، [صورتحال کو ختم کرنے کے لیے اقدامات کریں۔](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) یا یہاں تک کہ انہیں اپنی کمیونٹی سے ہٹا دیں، اگر وہ تعمیری طور پر تعاون کرنے کو تیار نہیں ہیں۔ + +### رہنمائی کو گلے لگائیں۔ + +ہو سکتا ہے کہ آپ کی کمیونٹی میں کوئی شخص باقاعدگی سے ایسے تعاون جمع کرائے جو آپ کے پروجیکٹ کے معیار پر پورا نہیں اترتے۔ دونوں فریقوں کے لیے بار بار مسترد کیے جانا مایوس کن ہو سکتا ہے۔ + +اگر آپ دیکھتے ہیں کہ کوئی آپ کے پروجیکٹ کے بارے میں پرجوش ہے، لیکن اسے تھوڑا سا پالش کی ضرورت ہے، تو صبر کریں۔ ہر صورت حال میں واضح طور پر وضاحت کریں کہ کیوں ان کے تعاون پروجیکٹ کی توقعات پر پورا نہیں اترتے۔ انہیں کسی آسان یا کم مبہم کام کی طرف اشارہ کرنے کی کوشش کریں، جیسے کہ ان کے پاؤں گیلے ہونے کے لیے _"پہلا اچھا مسئلہ"_ کا نشان لگا ہوا مسئلہ۔ اگر آپ کے پاس وقت ہے تو، ان کی پہلی شراکت کے ذریعے ان کی رہنمائی کرنے پر غور کریں، یا اپنی کمیونٹی میں کسی اور کو تلاش کریں جو ان کی رہنمائی کے لیے تیار ہو۔ + +## اپنی کمیونٹی سے فائدہ اٹھائیں۔ + +آپ کو سب کچھ خود کرنے کی ضرورت نہیں ہے۔ آپ کے پروجیکٹ کی کمیونٹی ایک وجہ سے موجود ہے! یہاں تک کہ اگر آپ کے پاس ابھی تک ایک فعال شراکت دار کمیونٹی نہیں ہے، اگر آپ کے بہت سارے صارفین ہیں، تو انہیں کام پر لگائیں۔ + +### Share the workload + +اگر آپ دوسروں کو تلاش کر رہے ہیں، تو ارد گرد پوچھ کر شروع کریں۔ + +نئے شراکت داروں کو حاصل کرنے کا ایک طریقہ یہ ہے کہ واضح طور پر [مسائل کو لیبل کریں جو ابتدائی افراد سے نمٹنے کے لیے کافی آسان ہیں](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). پھر GitHub ان مسائل کو پلیٹ فارم پر مختلف جگہوں پر ظاہر کرے گا، ان کی مرئیت میں اضافہ کرے گا۔ + +جب آپ نئے شراکت داروں کو بار بار تعاون کرتے ہوئے دیکھتے ہیں، تو مزید ذمہ داری پیش کرتے ہوئے ان کے کام کو پہچانیں۔ دستاویز کریں کہ اگر دوسرے چاہیں تو قائدانہ کردار میں کیسے بڑھ سکتے ہیں۔ + +دوسروں کی حوصلہ افزائی کرنا [منصوبے کی ملکیت کا اشتراک کریں](../building-community/#share-ownership-of-your-project) آپ کے اپنے کام کا بوجھ بہت کم کر سکتا ہے، جیسا کہ @lmccart نے اپنے پروجیکٹ پر دریافت کیا، [p5.js](https://github.com/processing/p5.js). + + + +اگر آپ کو اپنے پروجیکٹ سے الگ ہونے کی ضرورت ہے، یا تو وقفے وقفے پر یا مستقل طور پر، کسی اور سے آپ کے لیے کام لینے کے لیے کہنے میں کوئی شرم کی بات نہیں ہے۔ + +اگر دوسرے لوگ اس کی سمت کے بارے میں پرجوش ہیں، تو انہیں رسائی دیں یا باضابطہ طور پر کنٹرول کسی اور کے حوالے کریں۔ اگر کسی نے آپ کے پروجیکٹ کو فورک کیا ہے اور اسے کسی اور جگہ فعال طور پر برقرار رکھے ہوئے ہے، تو اپنے اصل پروجیکٹ سے فورک کو لنک کرنے پر غور کریں۔ یہ بہت اچھا ہے کہ بہت سارے لوگ چاہتے ہیں کہ آپ کا پروجیکٹ چلتا رہے! + +@progrium [found that](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) اپنے منصوبے کے وژن کی دستاویز کرنا، [Dokku](https://github.com/dokku/dokku), اس منصوبے سے دور ہونے کے بعد بھی ان مقاصد کو زندہ رہنے میں مدد ملی: + +> میں نے ایک ویکی صفحہ لکھا جس میں بتایا گیا کہ میں کیا چاہتا ہوں اور کیوں چاہتا ہوں۔ کسی وجہ سے یہ میرے لیے حیران کن تھا کہ دیکھ بھال کرنے والوں نے اس منصوبے کو اس سمت میں لے جانا شروع کر دیا! کیا یہ بالکل وہی ہوا جس طرح میں یہ کروں گا؟ ہمیشہ نہیں. لیکن اس نے پھر بھی پروجیکٹ کو اس کے قریب لایا جو میں نے لکھا تھا۔ + +### دوسروں کو وہ حل تیار کرنے دیں جن کی انہیں ضرورت ہے۔ + +اگر کسی ممکنہ تعاون کنندہ کی اس بارے میں مختلف رائے ہے کہ آپ کے پروجیکٹ کو کیا کرنا چاہیے، تو ہو سکتا ہے کہ آپ نرمی سے انہیں اپنے کانٹے پر کام کرنے کی ترغیب دیں۔ + +کسی پروجیکٹ کو فورک کرنا کوئی بری چیز نہیں ہے۔ پروجیکٹس کو کاپی اور ان میں ترمیم کرنے کے قابل ہونا اوپن سورس کے بارے میں بہترین چیزوں میں سے ایک ہے۔ آپ کی کمیونٹی کے اراکین کو ان کے اپنے کانٹے پر کام کرنے کی ترغیب دینا آپ کے پروجیکٹ کے وژن سے متصادم ہوئے بغیر تخلیقی آؤٹ لیٹ فراہم کر سکتا ہے جس کی انہیں ضرورت ہے۔ + + + +یہی بات اس صارف پر بھی لاگو ہوتی ہے جو واقعتاً ایسا حل چاہتا ہے جسے بنانے کے لیے آپ کے پاس بینڈوڈتھ نہیں ہے۔ APIs اور حسب ضرورت ہکس کی پیشکش دوسروں کو ان کی اپنی ضروریات کو پورا کرنے میں مدد کر سکتی ہے، بغیر براہ راست ذریعہ میں ترمیم کیے. @orta [found that](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) CocoaPods کے لیے حوصلہ افزا پلگ ان "کچھ انتہائی دلچسپ خیالات" کا باعث بنے: + +> یہ تقریباً ناگزیر ہے کہ ایک بار جب کوئی پروجیکٹ بڑا ہو جائے تو دیکھ بھال کرنے والوں کو اس بارے میں بہت زیادہ قدامت پسند بننا پڑتا ہے کہ وہ نیا کوڈ کیسے متعارف کراتے ہیں۔ آپ "نہیں" کہنے میں اچھے بن جاتے ہیں، لیکن بہت سے لوگوں کی جائز ضروریات ہوتی ہیں۔ لہذا، اس کے بجائے آپ اپنے آلے کو پلیٹ فارم میں تبدیل کرتے ہیں۔ + +## روبوٹ لے آئیں + +جس طرح ایسے کام ہیں جن میں دوسرے لوگ آپ کی مدد کر سکتے ہیں، اسی طرح ایسے کام بھی ہیں جو کسی انسان کو کرنے کی ضرورت نہیں ہے۔ روبوٹ آپ کے دوست ہیں۔ ایک مینٹینر کے طور پر اپنی زندگی کو آسان بنانے کے لیے ان کا استعمال کریں۔ + +### اپنے کوڈ کے معیار کو بہتر بنانے کے لیے ٹیسٹ اور دیگر چیکس کی ضرورت ہے۔ + +اپنے پروجیکٹ کو خودکار بنانے کے سب سے اہم طریقوں میں سے ایک ٹیسٹ شامل کرنا ہے۔ + +ٹیسٹ تعاون کنندگان کو اعتماد محسوس کرنے میں مدد کرتے ہیں کہ وہ کچھ نہیں توڑیں گے۔ وہ آپ کے لیے تعاون کا جائزہ لینا اور قبول کرنا بھی آسان بناتے ہیں۔ آپ جتنے زیادہ ذمہ دار ہوں گے، آپ کی کمیونٹی اتنی ہی زیادہ مصروف ہوسکتی ہے۔ + +خودکار ٹیسٹ ترتیب دیں جو آنے والی تمام شراکتوں پر چلیں گے، اور اس بات کو یقینی بنائیں کہ آپ کے ٹیسٹ آسانی سے شراکت داروں کے ذریعے مقامی طور پر چلائے جا سکتے ہیں۔ تمام کوڈ شراکتیں آپ کے ٹیسٹوں کو جمع کروانے سے پہلے پاس کر لیں۔ آپ تمام گذارشات کے لیے معیار کا کم از کم معیار مقرر کرنے میں مدد کریں گے۔ [Required status checks](https://help.github.com/articles/about-required-status-checks/) GitHub پر اس بات کو یقینی بنانے میں مدد کر سکتا ہے کہ آپ کے ٹیسٹ پاس کیے بغیر کوئی تبدیلی ضم نہ ہو۔ + +اگر آپ ٹیسٹ شامل کرتے ہیں تو یقینی بنائیں کہ وہ آپ کی CONTRIBUTING فائل میں کیسے کام کرتے ہیں۔ + + + +### دیکھ بھال کے بنیادی کاموں کو خودکار کرنے کے لیے ٹولز کا استعمال کریں۔ + +ایک مشہور پروجیکٹ کو برقرار رکھنے کے بارے میں اچھی خبر یہ ہے کہ دوسرے دیکھ بھال کرنے والوں نے شاید اسی طرح کے مسائل کا سامنا کیا ہے اور ان کے لئے ایک حل تیار کیا ہے۔ + +دیکھ بھال کے کام کے کچھ پہلوؤں کو خودکار بنانے میں مدد کے لیے [variety of tools available](https://github.com/showcases/tools-for-open-source)۔ چند مثالیں: + +* [semantic-release](https://github.com/semantic-release/semantic-release) آپ کی ریلیز کو خودکار کرتا ہے +* [mention-bot](https://github.com/facebook/mention-bot) پل کی درخواستوں کے لیے ممکنہ جائزہ لینے والوں کا تذکرہ کرتا ہے۔ +* [Danger](https://github.com/danger/danger) خودکار کوڈ کے جائزے میں مدد کرتا ہے۔ +* [no-response](https://github.com/probot/no-response) ان مسائل کو بند کرتا ہے جہاں مصنف نے مزید معلومات کی درخواست کا جواب نہیں دیا ہے +* [dependabot](https://github.com/dependabot) پرانے تقاضوں کے لیے ہر روز آپ کی انحصاری فائلوں کی جانچ پڑتال کرتا ہے اور جو بھی اسے ملتا ہے اس کے لیے انفرادی پل کی درخواستیں کھولتا ہے۔ + +بگ رپورٹس اور دیگر عام شراکتوں کے لیے، GitHub کے پاس [ایشو ٹیمپلیٹس اور پل ریکوسٹ ٹیمپلیٹس](https://github.com/blog/2111-issue-and-pull-request-templates) ہیں، جنہیں آپ مواصلات کو ہموار کرنے کے لیے بنا سکتے ہیں۔ آپ وصول کرتے ہیں. @TalAter نے اپنا مسئلہ اور PR ٹیمپلیٹس لکھنے میں آپ کی مدد کرنے کے لیے ایک [اپنی اپنی مہم جوئی کا رہنما منتخب کریں](https://www.talater.com/open-source-templates/#/) بنایا ہے۔ + +اپنی ای میل اطلاعات کا نظم کرنے کے لیے، آپ ترجیحی طور پر ترتیب دینے کے لیے [ای میل فلٹرز](https://github.com/blog/2203-email-updates-about-your-own-activity) ترتیب دے سکتے ہیں۔ + +اگر آپ کچھ زیادہ ایڈوانس حاصل کرنا چاہتے ہیں تو اسٹائل گائیڈز اور لِنٹرز پروجیکٹ کی شراکت کو معیاری بنا سکتے ہیں اور ان کا جائزہ لینے اور قبول کرنے میں آسانی پیدا کر سکتے ہیں۔ + +تاہم، اگر آپ کے معیارات بہت پیچیدہ ہیں، تو وہ شراکت میں رکاوٹوں کو بڑھا سکتے ہیں۔ یقینی بنائیں کہ آپ ہر ایک کی زندگیوں کو آسان بنانے کے لیے صرف کافی اصول شامل کر رہے ہیں۔ + +اگر آپ کو یقین نہیں ہے کہ کون سے ٹولز استعمال کرنے ہیں، تو دیکھیں کہ دوسرے مشہور پروجیکٹ کیا کرتے ہیں، خاص طور پر وہ جو آپ کے ماحولیاتی نظام میں ہیں۔ مثال کے طور پر، شراکت کا عمل دوسرے نوڈ ماڈیولز کے لیے کیسا لگتا ہے؟ اسی طرح کے ٹولز اور اپروچز کا استعمال آپ کے عمل کو آپ کے ٹارگٹ کنٹریبیوٹرز کے لیے مزید مانوس بنا دے گا۔ + +## توقف کو مارنا ٹھیک ہے۔ + +اوپن سورس کا کام ایک بار آپ کو خوشی دیتا ہے۔ شاید اب یہ آپ کو پرہیز یا مجرم محسوس کرنے لگا ہے۔ + +جب آپ اپنے پروجیکٹس کے بارے میں سوچتے ہیں تو شاید آپ مغلوب ہو رہے ہوں یا خوف کا بڑھتا ہوا احساس محسوس کر رہے ہوں۔ اور اس دوران، مسائل اور پل کی درخواستوں کا انبار لگ جاتا ہے۔ + +برن آؤٹ اوپن سورس کے کام میں خاص طور پر دیکھ بھال کرنے والوں میں ایک حقیقی اور وسیع مسئلہ ہے۔ ایک دیکھ بھال کرنے والے کے طور پر، آپ کی خوشی کسی بھی اوپن سورس پروجیکٹ کی بقا کے لیے ایک غیر گفت و شنید کی ضرورت ہے۔ + +اگرچہ یہ کہے بغیر جانا چاہئے، ایک وقفہ لے لو! آپ کو اس وقت تک انتظار نہیں کرنا چاہئے جب تک کہ آپ چھٹی لینے کے لیے جلنے کا احساس نہ کریں۔ @brettcannon، ایک ازگر کور ڈویلپر نے لینے کا فیصلہ کیا۔ [a month-long vacation](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) 14 سال کے رضاکارانہ OSS کام کے بعد۔ + +کسی بھی دوسری قسم کے کام کی طرح، باقاعدگی سے وقفے لینے سے آپ اپنے کام کے بارے میں تازہ دم، خوش اور پرجوش رہیں گے۔ + + + +کبھی کبھی، جب یہ محسوس ہوتا ہے کہ ہر کسی کو آپ کی ضرورت ہے تو اوپن سورس کے کام سے وقفہ لینا مشکل ہو سکتا ہے۔ یہاں تک کہ لوگ آپ کو دور جانے پر مجرم محسوس کرنے کی کوشش کر سکتے ہیں۔ + +جب آپ کسی پروجیکٹ سے دور ہوں تو اپنے صارفین اور کمیونٹی کے لیے تعاون تلاش کرنے کی پوری کوشش کریں۔ اگر آپ کو وہ مدد نہیں مل رہی جس کی آپ کو ضرورت ہے، تو بہرحال ایک وقفہ لیں۔ جب آپ دستیاب نہ ہوں تو بات چیت کرنا یقینی بنائیں، تاکہ لوگ آپ کی ردعمل کی کمی کی وجہ سے الجھن کا شکار نہ ہوں۔ + +وقفے لینے کا اطلاق صرف چھٹیوں سے زیادہ پر بھی ہوتا ہے۔ اگر آپ ہفتے کے آخر میں، یا کام کے اوقات کے دوران اوپن سورس کا کام نہیں کرنا چاہتے ہیں، تو ان توقعات کو دوسروں تک پہنچائیں، تاکہ وہ آپ کو پریشان نہ کریں۔ + +## پہلے اپنا خیال رکھیں! + +ایک مقبول پروجیکٹ کو برقرار رکھنے کے لیے ترقی کے ابتدائی مراحل سے مختلف مہارتوں کی ضرورت ہوتی ہے، لیکن یہ کم فائدہ مند نہیں ہے۔ ایک دیکھ بھال کرنے والے کے طور پر، آپ قیادت اور ذاتی مہارتوں کی اس سطح پر مشق کریں گے جس کا تجربہ بہت کم لوگوں کو ہوتا ہے۔ اگرچہ اس کا انتظام کرنا ہمیشہ آسان نہیں ہوتا ہے، لیکن واضح حدیں طے کرنا اور صرف وہی اختیار کرنا جس میں آپ آرام دہ ہوں آپ کو خوش، تروتازہ اور نتیجہ خیز رہنے میں مدد ملے گی۔ \ No newline at end of file From c301ea676e04c58a3445b4e78cc88de3c22953e6 Mon Sep 17 00:00:00 2001 From: Areebey Date: Mon, 23 Oct 2023 05:08:52 +0500 Subject: [PATCH 02/10] completly convert in urdu building-community file --- _articles/ur/building-community.md | 279 +++++++++++++++++++++++++++++ 1 file changed, 279 insertions(+) create mode 100644 _articles/ur/building-community.md diff --git a/_articles/ur/building-community.md b/_articles/ur/building-community.md new file mode 100644 index 00000000000..0307a9cb5d6 --- /dev/null +++ b/_articles/ur/building-community.md @@ -0,0 +1,279 @@ +--- +lang: en +title: استقبال کرنے والی کمیونٹیز کی تعمیر +description: ایک ایسی کمیونٹی کی تعمیر جو لوگوں کو آپ کے پروجیکٹ کو استعمال کرنے، اس میں تعاون کرنے اور انجیلی بشارت دینے کی ترغیب دیتی ہے۔ +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## کامیابی کے لیے اپنے پروجیکٹ کو ترتیب دینا + +آپ نے اپنا پروجیکٹ شروع کیا ہے، آپ اس بات کو پھیلا رہے ہیں، اور لوگ اسے چیک کر رہے ہیں۔ خوفناک! اب، آپ ان کے ارد گرد رہنا کیسے حاصل کرتے ہیں؟ + +استقبال کرنے والی کمیونٹی آپ کے پروجیکٹ کے مستقبل اور ساکھ میں سرمایہ کاری ہے۔ اگر آپ کا پروجیکٹ ابھی اپنی پہلی شراکتیں دیکھنا شروع کر رہا ہے، تو ابتدائی شراکت داروں کو ایک مثبت تجربہ دے کر شروع کریں، اور ان کے لیے واپس آتے رہنا آسان بنائیں۔ + +### لوگوں کو خوش آمدید کا احساس دلائیں۔ + +اپنے پروجیکٹ کی کمیونٹی کے بارے میں سوچنے کا ایک طریقہ وہ ہے جسے @MikeMcQuaid [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/): + +![Contributor فنل](/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +جب آپ اپنی کمیونٹی بناتے ہیں تو غور کریں کہ فنل کے اوپری حصے میں کوئی شخص (ایک ممکنہ صارف) نظریاتی طور پر نیچے تک کیسے پہنچ سکتا ہے (ایک فعال مینٹینر)۔ آپ کا مقصد شراکت دار کے تجربے کے ہر مرحلے پر رگڑ کو کم کرنا ہے۔ جب لوگ آسانی سے جیتیں گے، تو وہ مزید کچھ کرنے کی ترغیب محسوس کریں گے۔ + +اپنی دستاویزات کے ساتھ شروع کریں: + +* **کسی کے لیے اپنا پروجیکٹ استعمال کرنا آسان بنائیں۔** [A friendly README](../starting-a-project/#writing-a-readme)اور واضح کوڈ کی مثالیں جو بھی آپ کے پروجیکٹ پر اترتا ہے اسے شروع کرنا آسان بنا دے گا۔ +[your CONTRIBUTING file](../starting-a-project/#writing-your-contributing-guidelines) کا استعمال کرتے ہوئے اور اپنے مسائل کو اپ ٹو ڈیٹ رکھنے کے لیے **واضح طور پر وضاحت کریں کہ کس طرح تعاون کرنا ہے۔ +* **پہلے اچھے مسائل**: نئے تعاون کنندگان کو شروع کرنے میں مدد کرنے کے لیے، واضح طور پر غور کریں [labeling issues that are simple enough for beginners to tackle](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels).۔ اس کے بعد GitHub ان مسائل کو پلیٹ فارم پر مختلف جگہوں پر ظاہر کرے گا، مفید شراکت میں اضافہ کرے گا، اور صارفین کی جانب سے ایسے مسائل سے نمٹنے کے لیے رگڑ کو کم کرے گا جو ان کی سطح کے لیے بہت مشکل ہیں۔ + +[GitHub's 2017 Open Source Survey](http://opensourcesurvey.org/2017/) نے ظاہر کیا کہ اوپن سورس صارفین کے لیے نامکمل یا مبہم دستاویزات سب سے بڑا مسئلہ ہے۔ اچھی دستاویزات لوگوں کو آپ کے پروجیکٹ کے ساتھ بات چیت کرنے کی دعوت دیتی ہیں۔ آخر کار، کوئی ایک مسئلہ کھولے گا یا درخواست کو کھینچ لے گا۔ ان تعاملات کو موقع کے طور پر استعمال کریں تاکہ انہیں فنل سے نیچے لے جا سکیں۔ + +* **جب کوئی آپ کے پروجیکٹ پر نیا اترتا ہے، تو ان کی دلچسپی کے لیے ان کا شکریہ!** کسی کو واپس آنا نہ چاہنے کے لیے صرف ایک منفی تجربہ کی ضرورت ہوتی ہے۔ +* **ردعمل بنیں۔** اگر آپ ایک ماہ تک ان کے مسئلے کا جواب نہیں دیتے ہیں، تو امکان ہے کہ وہ آپ کے پروجیکٹ کے بارے میں پہلے ہی بھول چکے ہیں۔ + +* **ان تعاون کی اقسام کے بارے میں کھلے ذہن میں رہیں جو آپ قبول کریں گے۔** بہت سے تعاون کنندگان ایک بگ رپورٹ یا ایک چھوٹی اصلاح کے ساتھ شروع کرتے ہیں۔ کسی پروجیکٹ میں [عطیہ دینے کے بہت سے طریقے](../how-to-contribute/#what-it-means-to-contribute) ہیں۔ لوگوں کو مدد کرنے دیں جس طرح وہ مدد کرنا چاہتے ہیں۔ +* **اگر کوئی شراکت ہے جس سے آپ متفق نہیں ہیں،** ان کے خیال کے لیے ان کا شکریہ اور [وضاحت کریں کہ کیوں](../best-practices/#learning-to-say-no) یہ اس کے دائرہ کار میں فٹ نہیں بیٹھتا پروجیکٹ، اگر آپ کے پاس ہے تو متعلقہ دستاویزات سے لنک کرنا۔ + + + +اوپن سورس کے تعاون کرنے والوں کی اکثریت "آرام دہ تعاون کرنے والے" ہیں: وہ لوگ جو کبھی کبھار کسی پروجیکٹ میں حصہ ڈالتے ہیں۔ ایک آرام دہ شراکت دار کے پاس آپ کے پروجیکٹ کے ساتھ تیزی سے کام لینے کا وقت نہیں ہوسکتا ہے، لہذا آپ کا کام ان کے لیے تعاون کرنا آسان بنانا ہے۔ + +دوسرے تعاون کنندگان کی حوصلہ افزائی کرنا اپنے آپ میں بھی سرمایہ کاری ہے۔ جب آپ اپنے سب سے بڑے مداحوں کو اس کام کے ساتھ چلانے کے لیے بااختیار بناتے ہیں جس کے بارے میں وہ پرجوش ہیں، تو سب کچھ خود کرنے کا دباؤ کم ہوتا ہے۔ + +### ہر چیز کو دستاویز کریں۔ + + + +جب آپ کوئی نیا پروجیکٹ شروع کرتے ہیں، تو آپ کے کام کو نجی رکھنا فطری محسوس ہو سکتا ہے۔ لیکن اوپن سورس پروجیکٹ اس وقت پروان چڑھتے ہیں جب آپ اپنے عمل کو عوام میں دستاویز کرتے ہیں۔ + +جب آپ چیزیں لکھتے ہیں، تو راستے کے ہر قدم پر زیادہ لوگ حصہ لے سکتے ہیں۔ آپ کو کسی ایسی چیز پر مدد مل سکتی ہے جس کے بارے میں آپ کو معلوم بھی نہیں تھا کہ آپ کو ضرورت ہے۔ + +چیزوں کو لکھنے کا مطلب صرف تکنیکی دستاویزات سے زیادہ ہے۔ جب بھی آپ کچھ لکھنے کی خواہش محسوس کریں یا اپنے پروجیکٹ پر نجی طور پر بات کریں، اپنے آپ سے پوچھیں کہ کیا آپ اسے عوامی بنا سکتے ہیں۔ + +اپنے پروجیکٹ کے روڈ میپ کے بارے میں شفاف رہیں، آپ کنٹریبیوشن کی اقسام تلاش کر رہے ہیں، شراکتوں کا جائزہ کیسے لیا جاتا ہے، یا آپ نے کچھ فیصلے کیوں کیے ہیں۔ + +اگر آپ دیکھتے ہیں کہ متعدد صارفین ایک ہی مسئلے سے دوچار ہیں، تو جوابات کو README میں دستاویز کریں۔ + +میٹنگز کے لیے، متعلقہ شمارے میں اپنے نوٹس یا ٹیک وے شائع کرنے پر غور کریں۔ شفافیت کی اس سطح سے آپ کو جو تاثرات ملیں گے وہ آپ کو حیران کر سکتے ہیں۔ + +ہر چیز کی دستاویز کرنا آپ کے کام پر بھی لاگو ہوتا ہے۔ اگر آپ اپنے پراجیکٹ کی خاطر خواہ اپ ڈیٹ پر کام کر رہے ہیں، تو اسے پل ریکوئسٹ میں ڈالیں اور اسے کام جاری ہے (WIP) کے طور پر نشان زد کریں۔ اس طرح، دوسرے لوگ جلد ہی اس عمل میں شامل ہونے کا احساس کر سکتے ہیں۔ + +### جوابدہ بنیں۔ + +جب آپ [اپنے پروجیکٹ کو فروغ دیں گے] چیزیں کیسے کام کرتی ہیں اس کے بارے میں ان کے سوالات ہوسکتے ہیں، یا شروع کرنے میں مدد کی ضرورت ہے۔ + +جواب دینے کی کوشش کریں جب کوئی مسئلہ فائل کرتا ہے، پل کی درخواست جمع کرتا ہے، یا آپ کے پروجیکٹ کے بارے میں کوئی سوال پوچھتا ہے۔ جب آپ تیزی سے جواب دیں گے، تو لوگ محسوس کریں گے کہ وہ مکالمے کا حصہ ہیں، اور وہ اس میں حصہ لینے کے لیے زیادہ پرجوش ہوں گے۔ + +یہاں تک کہ اگر آپ فوری طور پر درخواست کا جائزہ نہیں لے سکتے ہیں، تو اسے جلد تسلیم کرنے سے مصروفیت بڑھانے میں مدد ملتی ہے۔ یہاں ہے کہ @tdreyno نے [Middleman](https://github.com/middleman/middleman/pull/1466) پر پل کی درخواست کا جواب کیسے دیا: + +![مڈل مین پل کی درخواست](/assets/images/building-community/middleman_pr.png) + +[موزیلا کے ایک مطالعے سے معلوم ہوا ہے کہ](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) تعاون کرنے والے جنہوں نے 4 گھنٹے کے اندر کوڈ کا جائزہ لیا اور ریٹرن کی شرح زیادہ تھی۔ شراکت کو دہرائیں۔ + +آپ کے پروجیکٹ کے بارے میں بات چیت انٹرنیٹ کے ارد گرد دیگر جگہوں پر بھی ہو سکتی ہے، جیسے Stack Overflow، Twitter، یا Reddit۔ آپ ان میں سے کچھ جگہوں پر اطلاعات ترتیب دے سکتے ہیں تاکہ جب کوئی آپ کے پروجیکٹ کا ذکر کرے تو آپ کو الرٹ کیا جائے۔ + +### اپنی کمیونٹی کو جمع ہونے کی جگہ دیں۔ + +آپ کی کمیونٹی کو جمع ہونے کی جگہ دینے کی دو وجوہات ہیں۔ + +پہلی وجہ ان کے لیے ہے۔ لوگوں کو ایک دوسرے کو جاننے میں مدد کریں۔ مشترکہ مفادات کے حامل لوگ لامحالہ اس کے بارے میں بات کرنے کی جگہ چاہیں گے۔ اور جب مواصلت عوامی اور قابل رسائی ہوتی ہے، تو کوئی بھی تیز رفتاری اور حصہ لینے کے لیے ماضی کے آرکائیوز کو پڑھ سکتا ہے۔ + +دوسری وجہ آپ کے لیے ہے۔ اگر آپ لوگوں کو اپنے پروجیکٹ کے بارے میں بات کرنے کے لیے عوامی جگہ نہیں دیتے ہیں، تو وہ ممکنہ طور پر آپ سے براہ راست رابطہ کریں گے۔ شروع میں، نجی پیغامات کا جواب دینا کافی آسان لگتا ہے "صرف ایک بار"۔ لیکن وقت گزرنے کے ساتھ، خاص طور پر اگر آپ کا پروجیکٹ مقبول ہو جاتا ہے، تو آپ تھکن محسوس کریں گے۔ اپنے پروجیکٹ کے بارے میں لوگوں سے نجی طور پر بات چیت کرنے کے لالچ کا مقابلہ کریں۔ اس کے بجائے، انہیں ایک نامزد عوامی چینل پر بھیجیں۔ + +عوامی رابطہ اتنا ہی آسان ہو سکتا ہے جتنا کہ آپ کو براہ راست ای میل کرنے یا آپ کے بلاگ پر تبصرہ کرنے کے بجائے لوگوں کو مسئلہ کھولنے کی ہدایت کرنا۔ آپ میلنگ لسٹ بھی ترتیب دے سکتے ہیں، یا ٹویٹر اکاؤنٹ، سلیک، یا IRC چینل بنا سکتے ہیں تاکہ لوگ آپ کے پروجیکٹ کے بارے میں بات کر سکیں۔ یا مندرجہ بالا سب کو آزمائیں! + +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) کمیونٹی کے اراکین کی مدد کے لیے ہر دوسرے ہفتے دفتری اوقات کو الگ کرتا ہے: + +> Kops کے پاس کمیونٹی کو مدد اور رہنمائی پیش کرنے کے لیے ہر دوسرے ہفتے کا وقت بھی ہوتا ہے۔ Kops کے دیکھ بھال کرنے والوں نے خاص طور پر نئے آنے والوں کے ساتھ کام کرنے، PRs کے ساتھ مدد کرنے، اور نئی خصوصیات پر تبادلہ خیال کرنے کے لیے وقت مختص کرنے پر اتفاق کیا ہے۔ + +عوامی مواصلات میں قابل ذکر استثناء یہ ہیں: 1) سیکورٹی کے مسائل اور 2) حساس ضابطہ اخلاق کی خلاف ورزیاں۔ آپ کے پاس ہمیشہ لوگوں کے لیے نجی طور پر ان مسائل کی اطلاع دینے کا ایک طریقہ ہونا چاہیے۔ اگر آپ اپنا ذاتی ای میل استعمال نہیں کرنا چاہتے ہیں تو ایک مخصوص ای میل ایڈریس ترتیب دیں۔ + +## اپنی برادری کو بڑھانا + +کمیونٹیز انتہائی طاقتور ہیں۔ وہ طاقت ایک نعمت یا لعنت ہو سکتی ہے، اس بات پر منحصر ہے کہ آپ اسے کیسے چلاتے ہیں۔ جیسے جیسے آپ کے پروجیکٹ کی کمیونٹی بڑھ رہی ہے، اس کی مدد کرنے کے طریقے ہیں تعمیر کی طاقت بننے میں، تباہی نہیں۔ + +### برے اداکاروں کو برداشت نہ کریں۔ + +کوئی بھی مشہور پروجیکٹ لامحالہ ان لوگوں کو اپنی طرف متوجہ کرے گا جو آپ کی کمیونٹی کو مدد کرنے کے بجائے نقصان پہنچاتے ہیں۔ وہ غیر ضروری بحثیں شروع کر سکتے ہیں، معمولی خصوصیات پر جھگڑا کر سکتے ہیں، یا دوسروں کو دھونس دے سکتے ہیں۔ + +اس قسم کے لوگوں کے لیے زیرو ٹالرنس کی پالیسی اپنانے کی پوری کوشش کریں۔ اگر ان پر نشان نہ لگایا گیا تو منفی لوگ آپ کی کمیونٹی کے دوسرے لوگوں کو بے چین کر دیں گے۔ وہ چھوڑ بھی سکتے ہیں۔ + + + +آپ کے پروجیکٹ کے معمولی پہلوؤں پر باقاعدہ بحثیں آپ سمیت دوسروں کو اہم کاموں پر توجہ مرکوز کرنے سے ہٹاتی ہیں۔ آپ کے پروجیکٹ پر آنے والے نئے لوگ ان بات چیت کو دیکھ سکتے ہیں اور اس میں حصہ نہیں لینا چاہتے ہیں۔ + +جب آپ اپنے پروجیکٹ پر منفی رویے کو دیکھتے ہیں، تو اسے عوامی طور پر کال کریں۔ نرم مگر مضبوط لہجے میں وضاحت کریں کہ ان کا رویہ قابل قبول کیوں نہیں ہے۔ اگر مسئلہ برقرار رہتا ہے، تو آپ کو [ان سے جانے کے لیے کہو](../code-of-conduct/#enforcing-your-code-of-conduct) کی ضرورت پڑ سکتی ہے۔ آپ کا [ضابطہ اخلاق](../code-of-conduct/) ان مکالموں کے لیے ایک تعمیری رہنما ہو سکتا ہے۔ + +### تعاون کنندگان سے ملیں جہاں وہ ہیں۔ + +اچھی دستاویزات صرف اس وقت زیادہ اہم ہو جاتی ہیں جب آپ کی کمیونٹی بڑھتی ہے۔ آرام دہ اور پرسکون تعاون کرنے والے، جو آپ کے پروجیکٹ سے بصورت دیگر واقف نہیں ہوں گے، اپنی دستاویزات کو پڑھیں تاکہ ان کی ضرورت کا سیاق و سباق تیزی سے حاصل کیا جا سکے۔ + +اپنی CONTRIBUTING فائل میں، نئے تعاون کنندگان کو واضح طور پر بتائیں کہ کیسے شروع کیا جائے۔ آپ اس مقصد کے لیے ایک سرشار سیکشن بھی بنانا چاہیں گے۔ [Django](https://github.com/django/django)، مثال کے طور پر، نئے تعاون کنندگان کو خوش آمدید کہنے کے لیے ایک خاص لینڈنگ صفحہ ہے۔ + +! + +آپ کے شمارے کی قطار میں، لیبل کیڑے جو مختلف قسم کے تعاون کنندگان کے لیے موزوں ہیں: مثال کے طور پر، [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only)، _"پہلے اچھا مسئلہ"_، یا _"دستاویزات"_۔ [یہ لیبلز](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) کسی نئے کے لیے آپ کے پروجیکٹ کو جلدی سے اسکین کرنا آسان بناتے ہیں شروع کرنے کے. + +آخر میں، لوگوں کو راستے کے ہر قدم پر خوش آئند محسوس کرنے کے لیے اپنی دستاویزات کا استعمال کریں۔ + +آپ اپنے پروجیکٹ پر اترنے والے زیادہ تر لوگوں کے ساتھ کبھی بات چیت نہیں کریں گے۔ ہو سکتا ہے کہ آپ کو کوئی ایسا تعاون نہیں ملا ہو کیونکہ کسی نے خوف محسوس کیا تھا یا وہ نہیں جانتا تھا کہ کہاں سے شروع کرنا ہے۔ یہاں تک کہ کچھ مہربان الفاظ بھی کسی کو مایوسی میں آپ کے پروجیکٹ کو چھوڑنے سے روک سکتے ہیں۔ + +مثال کے طور پر، یہاں یہ ہے کہ [Rubinius](https://github.com/rubinius/rubinius/) کیسے شروع کرتا ہے [اس کا تعاون کرنے والا رہنما](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing۔ md): + +ہم یہ کہہ کر شروعات کرنا چاہتے ہیں کہ Rubinius استعمال کرنے کے لیے آپ کا شکریہ۔ یہ پروجیکٹ محبت کی محنت ہے، اور ہم ان تمام صارفین کی تعریف کرتے ہیں جو کیڑے پکڑتے ہیں، کارکردگی میں بہتری لاتے ہیں، اور دستاویزات میں مدد کرتے ہیں۔ ہر تعاون معنی خیز ہے، لہذا شرکت کرنے کے لیے آپ کا شکریہ۔ یہ کہا جا رہا ہے، یہاں کچھ رہنما خطوط ہیں جن پر ہم آپ سے عمل کرنے کو کہتے ہیں تاکہ ہم آپ کے مسئلے کو کامیابی سے حل کر سکیں۔ + +### اپنے پروجیکٹ کی ملکیت کا اشتراک کریں۔ + + + +جب لوگ ملکیت کا احساس محسوس کرتے ہیں تو پروجیکٹس میں حصہ ڈالنے کے لیے پرجوش ہوتے ہیں۔ اس کا مطلب یہ نہیں ہے کہ آپ کو اپنے پروجیکٹ کے وژن کو تبدیل کرنے یا وہ تعاون قبول کرنے کی ضرورت ہے جو آپ نہیں چاہتے ہیں۔ لیکن جتنا زیادہ آپ دوسروں کو کریڈٹ دیں گے، وہ اتنا ہی زیادہ رہیں گے۔ + +دیکھیں کہ کیا آپ اپنی کمیونٹی کے ساتھ زیادہ سے زیادہ ملکیت کا اشتراک کرنے کے طریقے تلاش کر سکتے ہیں۔ یہاں کچھ خیالات ہیں: + +* **آسان (غیر اہم) کیڑوں کو ٹھیک کرنے کے خلاف مزاحمت کریں۔** اس کے بجائے، انہیں نئے شراکت داروں کو بھرتی کرنے کے مواقع کے طور پر استعمال کریں، یا کسی ایسے شخص کی رہنمائی کریں جو تعاون کرنا چاہے۔ شروع میں یہ غیر فطری معلوم ہو سکتا ہے، لیکن آپ کی سرمایہ کاری وقت کے ساتھ ساتھ ادا ہو جائے گی۔ مثال کے طور پر، @michaeljoseph نے ایک تعاون کنندہ کو [Cookiecutter](https://github.com/audreyr/cookiecutter) کے مسئلے کو خود حل کرنے کے بجائے اس پر پل کی درخواست جمع کرانے کو کہا۔ + +![کوکی کٹر کا مسئلہ](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **اپنے پروجیکٹ میں CONTRIBUTORS یا AUTHORS فائل شروع کریں** +جس میں ہر اس شخص کی فہرست ہو جس نے آپ کے پروجیکٹ میں تعاون کیا ہے، جیسے [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) کرتا ہے۔ + +*اگر آپ کے پاس ایک بڑی کمیونٹی ہے، تو **ایک نیوز لیٹر بھیجیں یا بلاگ پوسٹ لکھیں** تعاون کرنے والوں کا شکریہ ادا کریں۔ Rust's [This Week in Rust](https://this-week-in-rust.org/) اور Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) دو اچھے ہیں مثالیں + +* **ہر تعاون کرنے والے کو کمٹڈ رسائی دیں۔** @felixge نے پایا کہ اس سے لوگ [اپنے پیچ پالش کرنے کے لیے زیادہ پرجوش ہیں](https://felixge.de/2013/03/11/the-pull-request-hack.html )، اور اسے ایسے پروجیکٹس کے لیے نئے مینٹینرز بھی مل گئے جن پر اس نے کچھ عرصے سے کام نہیں کیا تھا۔ + +*اگر آپ کا پروجیکٹ GitHub پر ہے، تو **اپنے پروجیکٹ کو اپنے ذاتی اکاؤنٹ سے ایک [تنظیم](https://help.github.com/articles/creating-a-new-organization-account/)** میں منتقل کریں اور شامل کریں۔ کم از کم ایک بیک اپ ایڈمن۔ تنظیمیں بیرونی ساتھیوں کے ساتھ منصوبوں پر کام کرنا آسان بناتی ہیں۔ + +حقیقت یہ ہے کہ [زیادہ تر پروجیکٹس میں صرف](https://peerj.com/preprints/1233/) ایک یا دو مینٹینرز ہوتے ہیں جو زیادہ تر کام کرتے ہیں۔ آپ کا پروجیکٹ جتنا بڑا ہوگا، اور آپ کی کمیونٹی جتنی بڑی ہوگی، مدد تلاش کرنا اتنا ہی آسان ہوگا۔ + +اگرچہ آپ کو کال کا جواب دینے کے لیے ہمیشہ کوئی شخص نہیں مل سکتا ہے، لیکن وہاں سگنل لگانے سے اس بات کے امکانات بڑھ جاتے ہیں کہ دوسرے لوگ اندر آ جائیں گے۔ اور جتنی جلدی آپ شروع کریں گے، اتنی جلدی لوگ مدد کر سکتے ہیں۔ + + + +## تنازعات کو حل کرنا + +آپ کے پروجیکٹ کے ابتدائی مراحل میں، بڑے فیصلے کرنا آسان ہے۔ جب آپ کچھ کرنا چاہتے ہیں، آپ صرف کرتے ہیں. + +جیسے جیسے آپ کا پروجیکٹ زیادہ مقبول ہوتا جائے گا، زیادہ لوگ آپ کے فیصلوں میں دلچسپی لیں گے۔ یہاں تک کہ اگر آپ کے پاس تعاون کرنے والوں کی ایک بڑی کمیونٹی نہیں ہے، اگر آپ کے پروجیکٹ میں بہت سارے صارفین ہیں، تو آپ کو ایسے لوگ ملیں گے جو فیصلوں پر وزن رکھتے ہیں یا اپنے مسائل اٹھاتے ہیں۔ + +زیادہ تر حصے کے لیے، اگر آپ نے ایک دوستانہ، عزت دار کمیونٹی کو فروغ دیا ہے اور اپنے عمل کو کھلے عام دستاویز کیا ہے، تو آپ کی کمیونٹی کو حل تلاش کرنے کے قابل ہونا چاہیے۔ لیکن بعض اوقات آپ کسی ایسے مسئلے کا شکار ہو جاتے ہیں جس کو حل کرنا تھوڑا مشکل ہوتا ہے۔ + +### احسان کے لئے بار مقرر کریں۔ + +جب آپ کی کمیونٹی کسی مشکل مسئلے سے دوچار ہوتی ہے تو غصہ بڑھ سکتا ہے۔ لوگ ناراض یا مایوس ہو سکتے ہیں اور اسے ایک دوسرے پر یا آپ پر نکال سکتے ہیں۔ + +دیکھ بھال کرنے والے کے طور پر آپ کا کام ان حالات کو بڑھنے سے روکنا ہے۔ یہاں تک کہ اگر آپ اس موضوع پر ایک مضبوط رائے رکھتے ہیں تو، لڑائی میں کودنے اور اپنے خیالات کو آگے بڑھانے کے بجائے ایک ناظم یا سہولت کار کا عہدہ لینے کی کوشش کریں۔ اگر کوئی بدتمیزی کر رہا ہے یا گفتگو پر اجارہ داری کر رہا ہے، تو [فوری طور پر عمل کریں](../building-community/#dont-tolerate-bad-actors) تاکہ بات چیت کو سول اور نتیجہ خیز بنایا جا سکے۔ + + + +دوسرے لوگ رہنمائی کے لیے آپ کی طرف دیکھ رہے ہیں۔ ایک اچھی مثال قائم کریں۔ آپ اب بھی مایوسی، ناخوشی یا تشویش کا اظہار کر سکتے ہیں، لیکن سکون سے کریں۔ + +اپنا ٹھنڈا رکھنا آسان نہیں ہے، لیکن قیادت کا مظاہرہ کرنا آپ کی کمیونٹی کی صحت کو بہتر بناتا ہے۔ انٹرنیٹ آپ کا شکریہ۔ + +### اپنے README کو آئین کی طرح سمجھیں۔ + +آپ کا README [ہدایات کے صرف ایک سیٹ سے زیادہ] (../starting-a-project/#writing-a-readme) ہے۔ یہ آپ کے اہداف، پروڈکٹ ویژن، اور روڈ میپ کے بارے میں بات کرنے کی جگہ بھی ہے۔ اگر لوگ کسی خاص خصوصیت کی خوبی پر بحث کرنے پر ضرورت سے زیادہ توجہ مرکوز کرتے ہیں، تو یہ آپ کے README کو دوبارہ دیکھنے اور آپ کے پروجیکٹ کے اعلی وژن کے بارے میں بات کرنے میں مدد کر سکتا ہے۔ اپنے README پر توجہ مرکوز کرنا بھی گفتگو کو غیر ذاتی بنا دیتا ہے، تاکہ آپ تعمیری گفتگو کر سکیں۔ + +### منزل پر نہیں، سفر پر توجہ دیں۔ + +کچھ منصوبے بڑے فیصلے کرنے کے لیے ووٹنگ کے عمل کا استعمال کرتے ہیں۔ پہلی نظر میں سمجھدار ہونے کے باوجود، ووٹنگ ایک دوسرے کے خدشات کو سننے اور ان کو دور کرنے کے بجائے "جواب" حاصل کرنے پر زور دیتی ہے۔ + +ووٹنگ سیاسی بن سکتی ہے، جہاں کمیونٹی کے اراکین ایک دوسرے کے حق میں یا کسی خاص طریقے سے ووٹ ڈالنے کے لیے دباؤ محسوس کرتے ہیں۔ ہر کوئی ووٹ نہیں دیتا، چاہے وہ [خاموش اکثریت](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority) آپ کی کمیونٹی میں، یا موجودہ صارفین جو نہیں جانتے تھے کہ ووٹ ہو رہا ہے۔ + +بعض اوقات، ووٹنگ ایک ضروری ٹائی بریکر ہوتا ہے۔ تاہم، جتنا آپ کر سکتے ہیں، اتفاق رائے کی بجائے ["اتفاق کی تلاش"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) پر زور دیں۔ + +اتفاق رائے کے حصول کے عمل کے تحت، کمیونٹی کے اراکین اس وقت تک اہم خدشات پر تبادلہ خیال کرتے ہیں جب تک کہ وہ محسوس نہ کریں کہ انہیں مناسب طور پر سنا گیا ہے۔ جب صرف معمولی خدشات باقی رہ جاتے ہیں تو کمیونٹی آگے بڑھ جاتی ہے۔ "اتفاق رائے کی تلاش" اس بات کو تسلیم کرتی ہے کہ ایک کمیونٹی کامل جواب تک پہنچنے کے قابل نہیں ہوسکتی ہے۔ اس کے بجائے، یہ سننے اور بحث کو ترجیح دیتا ہے۔ + + + + +یہاں تک کہ اگر آپ واقعی اتفاق رائے کے حصول کے عمل کو نہیں اپناتے ہیں، بطور پروجیکٹ مینٹینر، یہ ضروری ہے کہ لوگ جانیں کہ آپ سن رہے ہیں۔ دوسرے لوگوں کو سننے کا احساس دلانا، اور ان کے خدشات کو حل کرنے کا عہد کرنا، حساس حالات کو پھیلانے کے لیے ایک طویل سفر طے کرتا ہے۔ پھر، اعمال کے ساتھ اپنے الفاظ پر عمل کریں۔ + +کسی قرارداد کی خاطر کسی فیصلے میں جلدی نہ کریں۔ اس بات کو یقینی بنائیں کہ ہر کوئی سنتا محسوس کرے اور کسی قرارداد کی طرف بڑھنے سے پہلے تمام معلومات کو عام کر دیا گیا ہو۔ + +### گفتگو کو عمل پر مرکوز رکھیں + +بات چیت اہم ہے، لیکن نتیجہ خیز اور غیر نتیجہ خیز گفتگو میں فرق ہے۔ + +بحث کی حوصلہ افزائی کریں جب تک کہ یہ فعال طور پر حل کی طرف بڑھ رہی ہے۔ اگر یہ واضح ہے کہ بات چیت ختم ہو رہی ہے یا موضوع سے ہٹ رہی ہے، جابس ذاتی ہو رہے ہیں، یا لوگ معمولی تفصیلات کے بارے میں جھگڑ رہے ہیں، تو اسے بند کرنے کا وقت آ گیا ہے۔ + +ان بات چیت کو جاری رکھنے کی اجازت دینا نہ صرف ہاتھ میں موجود مسئلے کے لیے برا ہے، بلکہ آپ کی کمیونٹی کی صحت کے لیے بھی برا ہے۔ یہ پیغام بھیجتا ہے کہ اس قسم کی گفتگو کی اجازت ہے یا اس کی حوصلہ افزائی بھی کی جاتی ہے، اور یہ لوگوں کو مستقبل کے مسائل کو اٹھانے یا حل کرنے سے حوصلہ شکنی کر سکتی ہے۔ + +آپ کے یا دوسروں کے ذریعہ بنائے گئے ہر نکتے کے ساتھ، اپنے آپ سے پوچھیں، _"یہ ہمیں کسی حل کے قریب کیسے لاتا ہے؟"_ + +اگر بات چیت کھلنا شروع ہو رہی ہے، تو گروپ سے پوچھیں، _"ہمیں آگے کون سا قدم اٹھانا چاہیے؟"_ بات چیت پر دوبارہ توجہ مرکوز کرنے کے لیے۔ + +اگر کوئی بات چیت واضح طور پر کہیں نہیں جا رہی ہے، کوئی واضح کارروائی نہیں کی جا رہی ہے، یا مناسب کارروائی پہلے ہی کی جا چکی ہے، تو اس مسئلے کو بند کریں اور وضاحت کریں کہ آپ نے اسے کیوں بند کیا۔ + + + +### اپنی لڑائیوں کو سمجھداری سے چنیں۔ + +سیاق و سباق اہم ہے۔ غور کریں کہ بحث میں کون شامل ہے اور وہ کس طرح باقی کمیونٹی کی نمائندگی کرتے ہیں۔ + +کیا کمیونٹی میں ہر کوئی اس مسئلے سے پریشان ہے، یا اس سے بھی منسلک ہے؟ یا اکیلا پریشانی پیدا کرنے والا ہے؟ اپنی خاموش کمیونٹی کے اراکین پر غور کرنا نہ بھولیں، نہ صرف فعال آوازوں پر۔ + +اگر مسئلہ آپ کی کمیونٹی کی وسیع تر ضروریات کی نمائندگی نہیں کرتا ہے، تو آپ کو صرف چند لوگوں کے خدشات کو تسلیم کرنے کی ضرورت ہوگی۔ اگر یہ ایک واضح حل کے بغیر ایک بار بار چلنے والا مسئلہ ہے، تو اس موضوع پر پچھلے مباحثوں کی طرف اشارہ کریں اور تھریڈ کو بند کریں۔ + +### کمیونٹی ٹائی بریکر کی شناخت کریں۔ + +اچھے رویے اور واضح مواصلت کے ساتھ، زیادہ تر مشکل حالات قابلِ حل ہوتے ہیں۔ تاہم، نتیجہ خیز گفتگو میں بھی، آگے بڑھنے کے طریقہ پر رائے میں فرق ہوسکتا ہے۔ ان صورتوں میں، کسی فرد یا لوگوں کے گروپ کی نشاندہی کریں جو ٹائی بریکر کے طور پر کام کر سکتے ہیں۔ + +ٹائی بریکر پروجیکٹ کا بنیادی مینٹینر ہو سکتا ہے، یا یہ لوگوں کا ایک چھوٹا گروپ ہو سکتا ہے جو ووٹنگ کی بنیاد پر فیصلہ کرتے ہیں۔ مثالی طور پر، آپ نے گورننس فائل میں ٹائی بریکر اور اس سے وابستہ عمل کی نشاندہی کی ہے اس سے پہلے کہ آپ کو اسے استعمال کرنا پڑے۔ + +آپ کا ٹائی بریکر آخری حربہ ہونا چاہیے۔ تفرقہ انگیز مسائل آپ کی کمیونٹی کے لیے بڑھنے اور سیکھنے کا ایک موقع ہیں۔ ان مواقع کو گلے لگائیں اور جہاں بھی ممکن ہو کسی قرارداد کی طرف جانے کے لیے ایک باہمی عمل کا استعمال کریں۔ + +## کمیونٹی اوپن سورس کا ❤️ ہے۔ + +صحت مند، ترقی پزیر کمیونٹیز ہر ہفتے اوپن سورس میں ڈالے جانے والے ہزاروں گھنٹوں کو ایندھن فراہم کرتی ہیں۔ بہت سے شراکت دار دوسرے لوگوں کو اوپن سورس پر کام کرنے - یا کام نہ کرنے کی وجہ بتاتے ہیں۔ اس طاقت کو تعمیری طور پر استعمال کرنے کا طریقہ سیکھ کر، آپ کسی ایسے شخص کی مدد کریں گے جس کو اوپن سورس کا ناقابل فراموش تجربہ حاصل ہو۔ \ No newline at end of file From 7a9b63d23727bc4e49054c72222cad389e70539a Mon Sep 17 00:00:00 2001 From: Areebey Date: Mon, 23 Oct 2023 05:17:52 +0500 Subject: [PATCH 03/10] convert code-of-conduct file in urdu as well --- _articles/ur/code-of-conduct.md | 114 ++++++++++++++++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 _articles/ur/code-of-conduct.md diff --git a/_articles/ur/code-of-conduct.md b/_articles/ur/code-of-conduct.md new file mode 100644 index 00000000000..a13da452c72 --- /dev/null +++ b/_articles/ur/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: en +title: آپ کا ضابطہ اخلاق +description: ضابطہ اخلاق کو اپنانے اور نافذ کر کے صحت مند اور تعمیری کمیونٹی کے رویے کی سہولت فراہم کریں۔ +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## مجھے ضابطہ اخلاق کی ضرورت کیوں ہے؟ + +ضابطہ اخلاق ایک دستاویز ہے جو آپ کے پروجیکٹ کے شرکاء کے رویے کی توقعات قائم کرتی ہے۔ ضابطہ اخلاق کو اپنانا، اور نافذ کرنا آپ کی کمیونٹی کے لیے ایک مثبت سماجی ماحول بنانے میں مدد کر سکتا ہے۔ + +ضابطہ اخلاق نہ صرف آپ کے شرکاء کی بلکہ آپ کی حفاظت میں مدد کرتے ہیں۔ اگر آپ کسی پروجیکٹ کو برقرار رکھتے ہیں، تو آپ کو معلوم ہو سکتا ہے کہ دوسرے شرکاء کے غیر پیداواری رویے آپ کو وقت گزرنے کے ساتھ ساتھ اپنے کام سے مایوس یا ناخوش محسوس کر سکتے ہیں۔ + +ضابطہ اخلاق آپ کو صحت مند، تعمیری کمیونٹی کے رویے میں سہولت فراہم کرنے کا اختیار دیتا ہے۔ فعال ہونا اس امکان کو کم کرتا ہے کہ آپ، یا دوسرے، آپ کے پروجیکٹ سے تھکاوٹ کا شکار ہو جائیں گے، اور آپ کو کارروائی کرنے میں مدد ملتی ہے جب کوئی ایسا کام کرتا ہے جس سے آپ متفق نہیں ہوتے ہیں۔ + +## ضابطہ اخلاق کا قیام + +جتنی جلدی ممکن ہو ایک ضابطہ اخلاق قائم کرنے کی کوشش کریں: مثالی طور پر، جب آپ پہلی بار اپنا پروجیکٹ بناتے ہیں۔ + +آپ کی توقعات سے آگاہ کرنے کے علاوہ، ضابطہ اخلاق درج ذیل کو بیان کرتا ہے: + +* جہاں ضابطہ اخلاق نافذ ہوتا ہے _(صرف مسائل اور درخواستوں پر، یا اجتماعی سرگرمیوں جیسے واقعات پر؟)_ +* جن پر ضابطہ اخلاق لاگو ہوتا ہے _(کمیونٹی ممبران اور مینٹینرز، لیکن اسپانسرز کا کیا ہوگا؟)_ +* اگر کوئی ضابطہ اخلاق کی خلاف ورزی کرتا ہے تو کیا ہوتا ہے۔ +* کوئی کیسے خلاف ورزی کی اطلاع دے سکتا ہے۔ + +جہاں بھی آپ کر سکتے ہو، پیشگی آرٹ استعمال کریں۔ [Contributor Covenant](https://contributor-covenant.org/) ایک ڈراپ ان ضابطہ اخلاق ہے جسے 40,000 سے زیادہ اوپن سورس پروجیکٹس بشمول Kubernetes، Rails اور Swift استعمال کرتے ہیں۔ + +[Django کوڈ آف کنڈکٹ](https://www.djangoproject.com/conduct/) اور [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct)۔ org/) دو اچھے ضابطہ اخلاق کی مثالیں بھی ہیں۔ + +ایک CODE_OF_CONDUCT فائل کو اپنے پروجیکٹ کی روٹ ڈائرکٹری میں رکھیں، اور اسے اپنی CONTRIBUTING یا README فائل سے لنک کرکے اپنی کمیونٹی کے لیے مرئی بنائیں۔ + +## یہ فیصلہ کرنا کہ آپ اپنے ضابطہ اخلاق کو کیسے نافذ کریں گے۔ + + + +آپ کو بتانا چاہیے کہ آپ کا ضابطہ اخلاق کیسے نافذ کیا جائے گا **_اس سے پہلے کہ کوئی خلاف ورزی ہو۔ ایسا کرنے کی کئی وجوہات ہیں: + +* یہ ظاہر کرتا ہے کہ ضرورت پڑنے پر آپ کارروائی کرنے میں سنجیدہ ہیں۔ + +* آپ کی کمیونٹی زیادہ اطمینان محسوس کرے گی کہ شکایات کا حقیقت میں جائزہ لیا جاتا ہے۔ + +* آپ اپنی کمیونٹی کو یقین دلائیں گے کہ نظرثانی کا عمل منصفانہ اور شفاف ہے، کیا وہ کبھی خلاف ورزی کے لیے خود کو چھان بین کریں۔ + +آپ کو لوگوں کو ضابطہ اخلاق کی خلاف ورزی کی اطلاع دینے کے لیے ایک نجی طریقہ (جیسے ای میل ایڈریس) دینا چاہیے اور یہ بتانا چاہیے کہ وہ رپورٹ کس کو موصول ہوتی ہے۔ یہ دیکھ بھال کرنے والا، دیکھ بھال کرنے والوں کا ایک گروپ، یا ضابطہ اخلاق کا ورکنگ گروپ ہو سکتا ہے۔ + +یہ نہ بھولیں کہ کوئی شخص کسی ایسے شخص کے بارے میں خلاف ورزی کی اطلاع دینا چاہتا ہے جسے وہ رپورٹیں موصول ہوتی ہیں۔ اس صورت میں، انہیں کسی اور کو خلاف ورزیوں کی اطلاع دینے کا اختیار دیں۔ مثال کے طور پر، @ctb اور @mr-c [اپنے پروجیکٹ کی وضاحت کریں](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst)، [khmer](https://github. com/dib-lab/khmer): + +> بدسلوکی، ہراساں کرنے، یا دوسری صورت میں ناقابل قبول رویے کے واقعات کی اطلاع **khmer-project@idyll.org** پر ای میل کرکے دی جا سکتی ہے جو صرف C. Titus Brown اور Michael R. Crusoe کو جاتی ہے۔ ان میں سے کسی ایک مسئلے کی اطلاع دینے کے لیے براہ کرم **Judi Brown Clarke, Ph.D.** کو ای میل کریں۔ + +حوصلہ افزائی کے لیے، Django کا [انفورسمنٹ مینوئل](https://www.djangoproject.com/conduct/enforcement-manual/) دیکھیں (اگرچہ آپ کو اپنے پروجیکٹ کے سائز کے لحاظ سے اس جامع چیز کی ضرورت نہیں ہو سکتی ہے)۔ + +## اپنے ضابطہ اخلاق کو نافذ کرنا + +کبھی کبھی، آپ کی بہترین کوششوں کے باوجود، کوئی ایسا کام کرے گا جس سے اس ضابطے کی خلاف ورزی ہوتی ہے۔ منفی یا نقصان دہ رویے کے سامنے آنے پر اس سے نمٹنے کے کئی طریقے ہیں۔ + +### صورتحال کے بارے میں معلومات اکٹھی کریں۔ + +کمیونٹی کے ہر رکن کی آواز کو اپنی آواز کی طرح اہم سمجھیں۔ اگر آپ کو یہ اطلاع ملتی ہے کہ کسی نے ضابطہ اخلاق کی خلاف ورزی کی ہے، تو اسے سنجیدگی سے لیں اور معاملے کی چھان بین کریں، چاہے وہ اس شخص کے ساتھ آپ کے اپنے تجربے سے میل نہیں کھاتا۔ ایسا کرنا آپ کی کمیونٹی کو اشارہ دیتا ہے کہ آپ ان کے نقطہ نظر کی قدر کرتے ہیں اور ان کے فیصلے پر بھروسہ کرتے ہیں۔ + +زیر بحث کمیونٹی کا رکن ایک بار بار مجرم ہو سکتا ہے جو مسلسل دوسروں کو بے چینی محسوس کرتا ہے، یا اس نے صرف ایک بار کچھ کہا یا کیا ہو گا۔ دونوں سیاق و سباق کے لحاظ سے کارروائی کرنے کی بنیادیں ہو سکتی ہیں۔ + +جواب دینے سے پہلے، اپنے آپ کو یہ سمجھنے کے لیے وقت دیں کہ کیا ہوا ہے۔ اس شخص کے ماضی کے تبصروں اور گفتگو کو پڑھیں تاکہ یہ بہتر طور پر سمجھ سکیں کہ وہ کون ہیں اور انہوں نے ایسا کیوں کیا ہو گا۔ اس شخص اور اس کے طرز عمل کے بارے میں اپنے نقطہ نظر کے علاوہ دوسرے نقطہ نظر کو جمع کرنے کی کوشش کریں۔ + + + +### مناسب کارروائی کریں۔ + +کافی معلومات جمع کرنے اور اس پر کارروائی کرنے کے بعد، آپ کو فیصلہ کرنا ہوگا کہ کیا کرنا ہے۔ جب آپ اپنے اگلے مراحل پر غور کرتے ہیں، یاد رکھیں کہ بطور ناظم آپ کا مقصد ایک محفوظ، باعزت، اور باہمی تعاون پر مبنی ماحول کو فروغ دینا ہے۔ نہ صرف اس بات پر غور کریں کہ زیربحث صورتحال سے کیسے نمٹا جائے، بلکہ آپ کا ردعمل آپ کی باقی کمیونٹی کے رویے اور آگے بڑھنے کی توقعات کو کیسے متاثر کرے گا۔ + +جب کوئی ضابطہ اخلاق کی خلاف ورزی کی اطلاع دیتا ہے، تو اسے سنبھالنا آپ کا نہیں، ان کا کام ہے۔ بعض اوقات، رپورٹر اپنے کیریئر، ساکھ، یا جسمانی تحفظ کے لیے بہت زیادہ خطرے میں معلومات کا انکشاف کر رہا ہوتا ہے۔ انہیں اپنے ہراساں کرنے والے کا سامنا کرنے پر مجبور کرنا رپورٹر کو سمجھوتہ کرنے والی پوزیشن میں ڈال سکتا ہے۔ آپ کو زیربحث شخص کے ساتھ براہ راست بات چیت کو سنبھالنا چاہئے، جب تک کہ رپورٹر واضح طور پر دوسری درخواست نہ کرے۔ + +ضابطہ اخلاق کی خلاف ورزی کا جواب دینے کے چند طریقے ہیں: + +** زیر بحث شخص کو عوامی انتباہ دیں** اور وضاحت کریں کہ اس کے رویے نے دوسروں پر کس طرح منفی اثر ڈالا، ترجیحا اس چینل میں جہاں یہ واقع ہوا ہے۔ جہاں ممکن ہو، عوامی رابطہ باقی کمیونٹی کو بتاتا ہے کہ آپ ضابطہ اخلاق کو سنجیدگی سے لیتے ہیں۔ مہربان بنیں، لیکن اپنی بات چیت میں مضبوط رہیں۔ + +**اس شخص سے نجی طور پر رابطہ کریں** اس کی وضاحت کرنے کے لیے کہ ان کے رویے نے دوسروں پر کس طرح منفی اثر ڈالا۔ اگر صورت حال میں حساس ذاتی معلومات شامل ہو تو آپ نجی مواصلاتی چینل استعمال کرنا چاہیں گے۔ اگر آپ کسی کے ساتھ پرائیویٹ طور پر بات چیت کرتے ہیں، تو ان لوگوں کو CC کرنا اچھا خیال ہے جنہوں نے سب سے پہلے صورت حال کی اطلاع دی، تاکہ انہیں معلوم ہو کہ آپ نے کارروائی کی ہے۔ رپورٹ کرنے والے شخص کو سی سی کرنے سے پہلے رضامندی کے لیے پوچھیں۔ + +کبھی کبھی، ایک قرارداد تک نہیں پہنچ سکتا. زیربحث شخص اس وقت جارحانہ یا دشمن بن سکتا ہے جب اس کا سامنا ہوتا ہے یا وہ اپنے رویے کو تبدیل نہیں کرتا ہے۔ اس صورت حال میں، آپ مضبوط کارروائی کرنے پر غور کر سکتے ہیں۔ مثال کے طور پر: + +پروجیکٹ کے کسی بھی پہلو میں حصہ لینے پر عارضی پابندی کے ذریعے لاگو کیے جانے والے شخص کو ** پروجیکٹ سے معطل کر دیں + +**مستقل طور پر اس شخص پر پروجیکٹ سے پابندی لگا دیں۔ + +اراکین پر پابندی لگانے کو ہلکے سے نہیں لیا جانا چاہیے اور یہ نقطہ نظر کے ایک مستقل اور ناقابل مصالحت فرق کی نمائندگی کرتا ہے۔ آپ کو یہ اقدامات صرف اس وقت کرنے چاہئیں جب یہ واضح ہو کہ کسی قرارداد تک نہیں پہنچا جا سکتا۔ + +## ایک دیکھ بھال کرنے والے کے طور پر آپ کی ذمہ داریاں + +ضابطہ اخلاق کوئی ایسا قانون نہیں ہے جو من مانی سے نافذ ہو۔ آپ ضابطہ اخلاق کے نافذ کرنے والے ہیں اور یہ آپ کی ذمہ داری ہے کہ ضابطہ اخلاق کے قائم کردہ قواعد پر عمل کریں۔ + +ایک دیکھ بھال کرنے والے کے طور پر آپ اپنی کمیونٹی کے لیے رہنما خطوط قائم کرتے ہیں اور اپنے ضابطہ اخلاق میں بیان کردہ اصولوں کے مطابق ان ہدایات کو نافذ کرتے ہیں۔ اس کا مطلب ہے ضابطہ اخلاق کی خلاف ورزی کی کسی بھی رپورٹ کو سنجیدگی سے لینا۔ رپورٹر کو ان کی شکایت کا مکمل اور منصفانہ جائزہ لینا چاہیے۔ اگر آپ اس بات کا تعین کرتے ہیں کہ انہوں نے جس رویے کی اطلاع دی ہے وہ خلاف ورزی نہیں ہے، تو انہیں واضح طور پر بتائیں اور بتائیں کہ آپ اس پر کارروائی کیوں نہیں کر رہے ہیں۔ اس کے ساتھ وہ کیا کرتے ہیں ان پر منحصر ہے: اس رویے کو برداشت کریں جس سے انہیں کوئی مسئلہ تھا، یا کمیونٹی میں حصہ لینا چھوڑ دیں۔ + +طرز عمل کی ایک رپورٹ جو _تکنیکی طور پر_ ضابطہ اخلاق کی خلاف ورزی نہیں کرتی ہے وہ اب بھی اس بات کی نشاندہی کر سکتی ہے کہ آپ کی کمیونٹی میں کوئی مسئلہ ہے، اور آپ کو اس ممکنہ مسئلے کی تحقیقات کرنی چاہیے اور اس کے مطابق عمل کرنا چاہیے۔ اس میں قابل قبول رویے کو واضح کرنے کے لیے آپ کے ضابطہ اخلاق پر نظرثانی کرنا اور/یا اس شخص سے بات کرنا شامل ہو سکتا ہے جس کے رویے کی اطلاع دی گئی تھی اور اسے یہ بتانا کہ اس نے ضابطہ اخلاق کی خلاف ورزی نہیں کی ہے، لیکن وہ توقع کے عین مطابق ہیں اور یقینی بنا رہے ہیں۔ شرکاء غیر آرام دہ محسوس کرتے ہیں. + +آخر میں، ایک دیکھ بھال کرنے والے کے طور پر، آپ قابل قبول رویے کے لیے معیارات مرتب اور نافذ کرتے ہیں۔ آپ کے پاس پروجیکٹ کی کمیونٹی اقدار کو تشکیل دینے کی صلاحیت ہے، اور شرکاء آپ سے ان اقدار کو منصفانہ اور یکساں طریقے سے نافذ کرنے کی توقع رکھتے ہیں۔ + +## اس طرز عمل کی حوصلہ افزائی کریں جو آپ دنیا میں دیکھنا چاہتے ہیں 🌎 + +جب کوئی پروجیکٹ مخالفانہ یا ناپسندیدہ لگتا ہے، یہاں تک کہ اگر یہ صرف ایک شخص ہے جس کے رویے کو دوسرے برداشت کرتے ہیں، تو آپ کو بہت سے شراکت داروں کو کھونے کا خطرہ ہوتا ہے، جن میں سے کچھ آپ کبھی بھی نہیں مل سکتے ہیں۔ ضابطہ اخلاق کو اپنانا یا نافذ کرنا ہمیشہ آسان نہیں ہوتا، لیکن خوش آئند ماحول کو فروغ دینے سے آپ کی کمیونٹی کی ترقی میں مدد ملے گی۔ \ No newline at end of file From 6dfe9d5fc68cdc89cccc1f00be8494ad94c9168f Mon Sep 17 00:00:00 2001 From: Areebey Date: Tue, 24 Oct 2023 04:50:56 +0500 Subject: [PATCH 04/10] finding-users file completed to convert. --- _articles/ur/finding-users.md | 151 ++++++++++++++++++++++++++++++++++ 1 file changed, 151 insertions(+) create mode 100644 _articles/ur/finding-users.md diff --git a/_articles/ur/finding-users.md b/_articles/ur/finding-users.md new file mode 100644 index 00000000000..2cc92fe8e2b --- /dev/null +++ b/_articles/ur/finding-users.md @@ -0,0 +1,151 @@ +--- +lang: en +title: اپنے پروجیکٹ کے لیے صارفین کی تلاش +description: اپنے اوپن سورس پروجیکٹ کو خوش صارفین کے ہاتھ میں لے کر اسے بڑھنے میں مدد کریں۔ +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## بات پھیلانا + +ایسا کوئی اصول نہیں ہے جو یہ کہے کہ آپ کو اوپن سورس پروجیکٹ کو لانچ کرنے پر فروغ دینا ہوگا۔ اوپن سورس میں کام کرنے کی بہت ساری وجوہات ہیں جن کا مقبولیت سے کوئی تعلق نہیں ہے۔ اس امید کے بجائے کہ دوسرے آپ کے اوپن سورس پروجیکٹ کو تلاش کریں گے اور استعمال کریں گے، آپ کو اپنی محنت کے بارے میں بات پھیلانی ہوگی! + +## اپنے پیغام کو سمجھیں۔ + +اپنے پروجیکٹ کو فروغ دینے کا اصل کام شروع کرنے سے پہلے، آپ کو یہ بتانے کے قابل ہونا چاہیے کہ یہ کیا کرتا ہے، اور یہ کیوں اہمیت رکھتا ہے۔ + +آپ کے پروجیکٹ کو کیا مختلف یا دلچسپ بناتا ہے؟ آپ نے اسے کیوں بنایا؟ اپنے لیے ان سوالات کا جواب دینے سے آپ کو اپنے پروجیکٹ کی اہمیت بتانے میں مدد ملے گی۔ + +یاد رکھیں کہ لوگ بطور صارف شامل ہوتے ہیں، اور آخر کار شراکت دار بن جاتے ہیں، کیونکہ آپ کا پروجیکٹ ان کے لیے ایک مسئلہ حل کرتا ہے۔ جیسا کہ آپ اپنے پروجیکٹ کے پیغام اور قدر کے بارے میں سوچتے ہیں، انہیں اس عینک سے دیکھنے کی کوشش کریں کہ _صارف اور تعاون کنندگان_ کیا چاہتے ہیں۔ + +مثال کے طور پر، @robb واضح طور پر یہ بتانے کے لیے کوڈ کی مثالیں استعمال کرتا ہے کہ اس کا پروجیکٹ، [کارٹوگرافی](https://github.com/robb/Cartography) مفید کیوں ہے: + +![کارٹوگرافی README](/assets/images/finding-users/cartography.jpg) + +پیغام رسانی میں مزید گہرا غوطہ لگانے کے لیے، Mozilla کی ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) صارف کی شخصیت کو تیار کرنے کی مشق دیکھیں۔ + +## لوگوں کو اپنے پروجیکٹ کو تلاش کرنے اور اس کی پیروی کرنے میں مدد کریں۔ + + + +لوگوں کو ایک نام کی جگہ کی طرف اشارہ کرکے اپنے پروجیکٹ کو تلاش کرنے اور یاد رکھنے میں مدد کریں۔ + +**اپنے کام کو فروغ دینے کے لیے واضح ہینڈل رکھیں۔** ٹویٹر ہینڈل، GitHub URL، یا IRC چینل لوگوں کو آپ کے پروجیکٹ کی طرف اشارہ کرنے کا ایک آسان طریقہ ہے۔ یہ آؤٹ لیٹس آپ کے پراجیکٹ کی بڑھتی ہوئی کمیونٹی کو جمع ہونے کی جگہ بھی دیتے ہیں۔ + +اگر آپ ابھی تک اپنے پروجیکٹ کے لیے آؤٹ لیٹس قائم نہیں کرنا چاہتے ہیں، تو آپ جو کچھ بھی کرتے ہیں اس میں اپنے ٹوئٹر یا GitHub ہینڈل کو فروغ دیں۔ آپ کے ٹویٹر یا گٹ ہب ہینڈل کو فروغ دینے سے لوگوں کو آپ سے رابطہ کرنے یا آپ کے کام کی پیروی کرنے کا طریقہ معلوم ہوگا۔ اگر آپ کسی میٹ اپ یا تقریب میں بات کرتے ہیں، تو یقینی بنائیں کہ آپ کی رابطہ کی معلومات آپ کے بائیو یا سلائیڈز میں شامل ہے۔ + + + +**اپنے پروجیکٹ کے لیے ایک ویب سائٹ بنانے پر غور کریں۔** ویب سائٹ آپ کے پروجیکٹ کو زیادہ دوستانہ اور نیویگیٹ کرنے میں آسان بناتی ہے، خاص طور پر جب یہ واضح دستاویزات اور سبق کے ساتھ جوڑا ہو۔ ویب سائٹ رکھنے سے یہ بھی پتہ چلتا ہے کہ آپ کا پروجیکٹ فعال ہے جو آپ کے سامعین کو اس کے استعمال میں زیادہ آرام دہ محسوس کرے گا۔ لوگوں کو اپنے پروجیکٹ کو استعمال کرنے کے بارے میں خیالات دینے کے لیے مثالیں فراہم کریں۔ + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689)، جینگو کے شریک تخلیق کار، نے کہا کہ ایک ویب سائٹ _"ابتدائی دنوں میں جینگو کے ساتھ اب تک کی سب سے بہترین چیز تھی"_ . + +اگر آپ کا پروجیکٹ GitHub پر ہوسٹ کیا گیا ہے، تو آپ آسانی سے ویب سائٹ بنانے کے لیے [GitHub Pages](https://pages.github.com/) استعمال کر سکتے ہیں۔ [Yeoman](http://yeoman.io/)، [Vagrant](https://www.vagrantup.com/)، اور [Middleman](https://middlemanapp.com/) ہیں [چند مثالیں] (https://github.com/showcases/github-pages-examples) بہترین، جامع ویب سائٹس۔ + +![واگرنٹ ہوم پیج](/assets/images/finding-users/vagrant_homepage.png) + +اب جب کہ آپ کے پاس اپنے پروجیکٹ کے لیے ایک پیغام ہے، اور لوگوں کے لیے آپ کے پروجیکٹ کو تلاش کرنے کا ایک آسان طریقہ ہے، آئیے وہاں سے نکلیں اور اپنے سامعین سے بات کریں! + +## جائیں جہاں آپ کے پروجیکٹ کے سامعین ہیں (آن لائن) + +آن لائن آؤٹ ریچ بات کو تیزی سے شیئر کرنے اور پھیلانے کا ایک بہترین طریقہ ہے۔ آن لائن چینلز کا استعمال کرتے ہوئے، آپ کے پاس بہت وسیع سامعین تک پہنچنے کی صلاحیت ہے۔ + +اپنے سامعین تک پہنچنے کے لیے موجودہ آن لائن کمیونٹیز اور پلیٹ فارمز سے فائدہ اٹھائیں۔ اگر آپ کا اوپن سورس پروجیکٹ ایک سافٹ ویئر پروجیکٹ ہے، تو آپ شاید اپنے سامعین کو [Stack Overflow](https://stackoverflow.com/)، [Reddit](https://www.reddit.com)، [Hacker News پر تلاش کر سکتے ہیں۔ ](https://news.ycombinator.com/)، یا [Quora](https://www.quora.com/)۔ وہ چینل تلاش کریں جہاں آپ کے خیال میں لوگ آپ کے کام سے سب سے زیادہ فائدہ اٹھائیں گے یا آپ کے کام سے پرجوش ہوں گے۔ + + + + +دیکھیں کہ کیا آپ اپنے پروجیکٹ کو متعلقہ طریقوں سے شیئر کرنے کے طریقے تلاش کر سکتے ہیں: + +* **متعلقہ اوپن سورس پروجیکٹس اور کمیونٹیز کے بارے میں جانیں۔** بعض اوقات، آپ کو اپنے پروجیکٹ کو براہ راست فروغ دینے کی ضرورت نہیں ہوتی ہے۔ اگر آپ کا پروجیکٹ ڈیٹا سائنسدانوں کے لیے موزوں ہے جو Python استعمال کرتے ہیں، تو Python ڈیٹا سائنس کمیونٹی کو جانیں۔ جیسے جیسے لوگ آپ کو جانیں گے، آپ کے کام کے بارے میں بات کرنے اور شیئر کرنے کے قدرتی مواقع پیدا ہوں گے۔ +* **لوگوں کو تلاش کریں جو اس مسئلے کا سامنا کررہے ہیں جو آپ کا پروجیکٹ حل کرتا ہے۔** متعلقہ فورمز کے ذریعے ان لوگوں کے لیے تلاش کریں جو آپ کے پروجیکٹ کے ہدف والے سامعین میں آتے ہیں۔ ان کے سوال کا جواب دیں اور جب مناسب ہو تو اپنے پراجیکٹ کو حل کے طور پر تجویز کرنے کے لیے تدبر کا طریقہ تلاش کریں۔ +* **رائے کے لیے پوچھیں۔** اپنا اور اپنے کام کا تعارف ایسے سامعین سے کروائیں جو اسے متعلقہ اور دلچسپ لگے۔ اس بارے میں مخصوص رہیں کہ آپ کے خیال میں آپ کے پروجیکٹ سے کون فائدہ اٹھائے گا۔ جملہ ختم کرنے کی کوشش کریں: _"مجھے لگتا ہے کہ میرا پروجیکٹ واقعی X کی مدد کرے گا، جو Y_ کرنے کی کوشش کر رہے ہیں۔" صرف اپنے کام کو فروغ دینے کے بجائے دوسروں کے تاثرات سنیں اور ان کا جواب دیں۔ + +عام طور پر، بدلے میں چیزیں مانگنے سے پہلے دوسروں کی مدد کرنے پر توجہ دیں۔ کیونکہ کوئی بھی آسانی سے کسی پروجیکٹ کو آن لائن پروموٹ کر سکتا ہے، اس لیے بہت شور مچے گا۔ ہجوم سے الگ ہونے کے لیے، لوگوں کو سیاق و سباق دیں کہ آپ کون ہیں نہ کہ صرف آپ جو چاہتے ہیں۔ + +اگر کوئی آپ کی ابتدائی رسائی پر توجہ نہیں دیتا یا اس کا جواب نہیں دیتا، تو حوصلہ نہ ہاریں! زیادہ تر پراجیکٹ کا آغاز ایک تکراری عمل ہے جس میں مہینوں یا سال لگ سکتے ہیں۔ اگر آپ کو پہلی بار جواب نہیں ملتا ہے تو، کوئی دوسرا حربہ آزمائیں، یا پہلے دوسروں کے کام کی قدر بڑھانے کے طریقے تلاش کریں۔ اپنے پروجیکٹ کو فروغ دینے اور شروع کرنے میں وقت اور لگن درکار ہوتی ہے۔ + +## وہاں جائیں جہاں آپ کے پروجیکٹ کے ناظرین ہیں (آف لائن) + +![عوامی بات](/assets/images/finding-users/public_speaking.jpg) + +آف لائن ایونٹس سامعین تک نئے پروجیکٹس کو فروغ دینے کا ایک مقبول طریقہ ہیں۔ یہ مشغول سامعین تک پہنچنے اور گہرے انسانی روابط استوار کرنے کا بہترین طریقہ ہیں، خاص طور پر اگر آپ ڈویلپرز تک پہنچنے میں دلچسپی رکھتے ہیں۔ + +اگر آپ [عوامی بولنے میں نئے ہیں](https://speaking.io/)، تو ایک مقامی ملاقات تلاش کرکے شروع کریں جو آپ کے پروجیکٹ کی زبان یا ماحولیاتی نظام سے متعلق ہو۔ + + + + +اگر آپ نے پہلے کبھی کسی تقریب میں بات نہیں کی ہے، تو گھبراہٹ محسوس کرنا بالکل معمول کی بات ہے! یاد رکھیں کہ آپ کے سامعین وہاں موجود ہیں کیونکہ وہ حقیقی طور پر آپ کے کام کے بارے میں سننا چاہتے ہیں۔ + +جب آپ اپنی تقریر لکھتے ہیں، تو اس بات پر توجہ مرکوز کریں کہ آپ کے سامعین کو کیا دلچسپ لگے گا اور اس کی قدر کریں۔ اپنی زبان کو دوستانہ اور قابل رسائی رکھیں۔ مسکرائیں، سانس لیں، اور مزے کریں۔ + + + + +جب آپ تیار محسوس کریں تو اپنے پروجیکٹ کو فروغ دینے کے لیے کانفرنس میں بولنے پر غور کریں۔ کانفرنسیں آپ کو زیادہ سے زیادہ لوگوں تک پہنچنے میں مدد کر سکتی ہیں، بعض اوقات پوری دنیا سے۔ + +ایسی کانفرنسیں تلاش کریں جو آپ کی زبان یا ماحولیاتی نظام کے لیے مخصوص ہوں۔ اپنی تقریر پیش کرنے سے پہلے، شرکاء کے لیے اپنی گفتگو کو تیار کرنے کے لیے کانفرنس کی تحقیق کریں اور کانفرنس میں تقریر کرنے کے لیے قبول کیے جانے کے اپنے امکانات کو بڑھا دیں۔ آپ اکثر کانفرنس کے مقررین کو دیکھ کر اپنے سامعین کا احساس حاصل کر سکتے ہیں۔ + + + +## ساکھ بنائیں + +اوپر بیان کردہ حکمت عملیوں کے علاوہ، لوگوں کو اپنے پروجیکٹ میں اشتراک اور تعاون کرنے کے لیے مدعو کرنے کا بہترین طریقہ ان کے پروجیکٹس کا اشتراک اور تعاون ہے۔ + +نئے آنے والوں کی مدد کرنا، وسائل کا اشتراک کرنا، اور دوسروں کے منصوبوں میں سوچ سمجھ کر تعاون کرنا آپ کو ایک مثبت ساکھ بنانے میں مدد دے گا۔ اوپن سورس کمیونٹی میں ایک فعال رکن ہونے سے لوگوں کو آپ کے کام کے حوالے سے سیاق و سباق جاننے میں مدد ملے گی اور آپ کے پروجیکٹ پر توجہ دینے اور اس کا اشتراک کرنے کا زیادہ امکان ہوگا۔ دوسرے اوپن سورس پروجیکٹس کے ساتھ تعلقات استوار کرنا سرکاری شراکت داری کا باعث بھی بن سکتا ہے۔ + + + +اپنی ساکھ بنانا شروع کرنے میں کبھی جلدی، یا بہت دیر نہیں ہوتی۔ یہاں تک کہ اگر آپ نے اپنا پروجیکٹ پہلے ہی شروع کر دیا ہے، تو دوسروں کی مدد کرنے کے طریقے تلاش کرنا جاری رکھیں۔ + +سامعین بنانے کا کوئی راتوں رات حل نہیں ہے۔ دوسروں کا بھروسہ اور احترام حاصل کرنے میں وقت لگتا ہے، اور اپنی ساکھ بنانے میں کبھی ختم نہیں ہوتا۔ + +## اس پر قائم رہو! + +لوگوں کو آپ کے اوپن سورس پروجیکٹ کو دیکھنے میں کافی وقت لگ سکتا ہے۔ یہ ٹھیک ہے! آج کے کچھ سب سے مشہور پروجیکٹس کو سرگرمی کی اعلی سطح تک پہنچنے میں برسوں لگے۔ اس امید کے بجائے کہ آپ کا پروجیکٹ بے ساختہ مقبولیت حاصل کرے گا تعلقات استوار کرنے پر توجہ دیں۔ صبر کریں، اور اپنے کام کو ان لوگوں کے ساتھ بانٹتے رہیں جو اس کی تعریف کرتے ہیں۔ \ No newline at end of file From 71a7a0e09867d0dc3e9516c8a6dffe0ede701209 Mon Sep 17 00:00:00 2001 From: Areebey Date: Tue, 24 Oct 2023 05:02:12 +0500 Subject: [PATCH 05/10] getting-paid file also completeed to convert. --- _articles/ur/getting-paid.md | 177 +++++++++++++++++++++++++++++++++++ 1 file changed, 177 insertions(+) create mode 100644 _articles/ur/getting-paid.md diff --git a/_articles/ur/getting-paid.md b/_articles/ur/getting-paid.md new file mode 100644 index 00000000000..67581a6a75b --- /dev/null +++ b/_articles/ur/getting-paid.md @@ -0,0 +1,177 @@ +--- +lang: en +title: اوپن سورس کام کے لیے ادائیگی کرنا +description: اپنے وقت یا اپنے پروجیکٹ کے لیے مالی مدد حاصل کرکے اوپن سورس میں اپنے کام کو برقرار رکھیں۔ +class: getting-paid +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## کیوں کچھ لوگ مالی مدد چاہتے ہیں۔ + +اوپن سورس کا زیادہ تر کام رضاکارانہ ہے۔ مثال کے طور پر، کسی کو اپنے استعمال کردہ پروجیکٹ میں کوئی خرابی آ سکتی ہے اور اسے فوری طور پر ٹھیک کرنا ہو سکتا ہے، یا وہ اپنے فارغ وقت میں اوپن سورس پروجیکٹ کے ساتھ ٹنکرنگ سے لطف اندوز ہو سکتا ہے۔ + + + +ایسی بہت سی وجوہات ہیں جن کی وجہ سے کوئی شخص اپنے اوپن سورس کام کی ادائیگی نہیں کرنا چاہے گا۔ + +* **ان کے پاس پہلے سے ہی ایک کل وقتی ملازمت ہے جو انہیں پسند ہے،** جو انہیں فارغ وقت میں اوپن سورس میں حصہ ڈالنے کے قابل بناتی ہے۔ +* **وہ اوپن سورس کو مشغلہ** یا تخلیقی فرار کے طور پر سوچنے سے لطف اندوز ہوتے ہیں اور اپنے پروجیکٹس پر کام کرنے کے لیے مالی طور پر ذمہ دار محسوس نہیں کرنا چاہتے۔ +* **انہیں اوپن سورس میں تعاون کرنے سے دیگر فوائد حاصل ہوتے ہیں،** جیسے کہ اپنی ساکھ یا پورٹ فولیو بنانا، کوئی نیا ہنر سیکھنا، یا کسی کمیونٹی کے قریب محسوس کرنا۔ + + + +دوسروں کے لیے، خاص طور پر جب شراکتیں جاری ہوں یا اہم وقت درکار ہو، اوپن سورس میں حصہ ڈالنے کے لیے ادائیگی کرنا ہی واحد طریقہ ہے جس میں وہ حصہ لے سکتے ہیں، یا تو اس لیے کہ پروجیکٹ کو اس کی ضرورت ہے، یا ذاتی وجوہات کی بنا پر۔ + +مقبول منصوبوں کو برقرار رکھنا ایک اہم ذمہ داری ہو سکتی ہے، جس میں ہر مہینے چند گھنٹے کی بجائے 10 یا 20 گھنٹے فی ہفتہ لگ سکتے ہیں۔ + + + + +بامعاوضہ کام زندگی کے مختلف شعبوں سے تعلق رکھنے والے لوگوں کو بامعنی شراکت کرنے کے قابل بھی بناتا ہے۔ کچھ لوگ اپنی موجودہ مالی پوزیشن، قرض، یا خاندان یا دیگر نگہداشت کی ذمہ داریوں کی بنیاد پر اوپن سورس پروجیکٹس پر بلا معاوضہ وقت گزارنے کے متحمل نہیں ہو سکتے۔ اس کا مطلب ہے کہ دنیا کبھی بھی ایسے باصلاحیت لوگوں کے تعاون کو نہیں دیکھتی جو اپنا وقت رضاکارانہ طور پر خرچ کرنے کے متحمل نہیں ہوسکتے ہیں۔ اس کے اخلاقی مضمرات ہیں، جیسا کہ @ashedryden نے [بیان کیا ہے](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community)، چونکہ کام کیا جاتا ہے ان لوگوں کے حق میں متعصب جن کے پاس پہلے سے ہی زندگی میں فوائد ہیں، جو پھر اپنی رضاکارانہ شراکت کی بنیاد پر اضافی فوائد حاصل کرتے ہیں، جبکہ دوسرے جو رضاکارانہ طور پر کام کرنے کے قابل نہیں ہیں انہیں بعد میں مواقع نہیں ملتے، جو اوپن سورس میں تنوع کی موجودہ کمی کو تقویت دیتا ہے۔ برادری. + + + +اگر آپ مالی مدد کی تلاش میں ہیں، تو غور کرنے کے لیے دو راستے ہیں۔ آپ بطور شراکت دار اپنا وقت نکال سکتے ہیں، یا آپ اس منصوبے کے لیے تنظیمی فنڈنگ ​​حاصل کر سکتے ہیں۔ + +## اپنے وقت کی مالی اعانت + +آج، بہت سے لوگوں کو اوپن سورس پر جزوی یا کل وقتی کام کرنے کے لیے معاوضہ ملتا ہے۔ اپنے وقت کے لیے ادائیگی حاصل کرنے کا سب سے عام طریقہ اپنے آجر سے بات کرنا ہے۔ + +اگر آپ کا آجر واقعی اس پروجیکٹ کو استعمال کرتا ہے تو اوپن سورس کام کے لیے کیس بنانا آسان ہے، لیکن اپنی پچ کے ساتھ تخلیقی بنیں۔ ہوسکتا ہے کہ آپ کا آجر اس پروجیکٹ کو استعمال نہ کرے، لیکن وہ Python کا استعمال کرتے ہیں، اور Python کے ایک مشہور پروجیکٹ کو برقرار رکھنے سے نئے Python ڈویلپرز کو راغب کرنے میں مدد ملتی ہے۔ ہوسکتا ہے کہ یہ آپ کے آجر کو عام طور پر زیادہ ڈویلپر کے موافق نظر آئے۔ + +اگر آپ کے پاس کوئی موجودہ اوپن سورس پروجیکٹ نہیں ہے جس پر آپ کام کرنا چاہتے ہیں، لیکن اس کے بجائے یہ کہ آپ کا موجودہ ورک آؤٹ پٹ اوپن سورس ہے، تو اپنے آجر کے لیے اپنے اندرونی سافٹ ویئر میں سے کچھ کو اوپن سورس کرنے کے لیے کیس بنائیں۔ + +بہت سی کمپنیاں اپنا برانڈ بنانے اور معیاری ہنر کو بھرتی کرنے کے لیے اوپن سورس پروگرام تیار کر رہی ہیں۔ + +@hueniverse، مثال کے طور پر، پتہ چلا کہ [اوپن سورس میں والمارٹ کی سرمایہ کاری](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-) کو جواز فراہم کرنے کی مالی وجوہات تھیں۔ اوپن سورس-isn-t-cheap.html)۔ اور @jamesgpearce نے پایا کہ فیس بک کے اوپن سورس پروگرام نے بھرتی میں [ایک فرق کیا](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon): + +> یہ ہمارے ہیکر کلچر کے ساتھ قریب سے منسلک ہے، اور ہماری تنظیم کو کس طرح سمجھا جاتا ہے۔ ہم نے اپنے ملازمین سے پوچھا، "کیا آپ فیس بک پر اوپن سورس سافٹ ویئر پروگرام سے واقف تھے؟"۔ دو تہائی نے کہا "ہاں"۔ ایک نصف نے کہا کہ پروگرام نے ہمارے لیے کام کرنے کے ان کے فیصلے میں مثبت کردار ادا کیا۔ یہ معمولی تعداد نہیں ہیں، اور مجھے امید ہے کہ ایک رجحان جاری رہے گا۔ + +اگر آپ کی کمپنی اس راستے سے نیچے جاتی ہے، تو کمیونٹی اور کارپوریٹ سرگرمیوں کے درمیان حدود کو واضح رکھنا ضروری ہے۔ بالآخر، اوپن سورس پوری دنیا کے لوگوں کے تعاون کے ذریعے خود کو برقرار رکھتا ہے، اور یہ کسی ایک کمپنی یا مقام سے بڑا ہے۔ + + + +اگر آپ اپنے موجودہ آجر کو اوپن سورس کے کام کو ترجیح دینے کے لیے قائل نہیں کر سکتے ہیں، تو ایک نیا آجر تلاش کرنے پر غور کریں جو اوپن سورس میں ملازمین کی شراکت کی حوصلہ افزائی کرے۔ ایسی کمپنیوں کو تلاش کریں جو اوپن سورس کے کام کو واضح کرتی ہیں۔ مثال کے طور پر: + +* کچھ کمپنیاں، جیسے [Netflix](https://netflix.github.io/) یا [PayPal](https://paypal.github.io/)، ایسی ویب سائٹیں ہیں جو اوپن سورس میں ان کی شمولیت کو نمایاں کرتی ہیں +* [Zalando](https://opensource.zalando.com) نے ملازمین کے لیے اپنی [اوپن سورس شراکت کی پالیسی](https://opensource.zalando.com/docs/using/contributing/) شائع کی + +ایک بڑی کمپنی سے شروع ہونے والے پروجیکٹس، جیسے کہ [Go](https://github.com/golang) یا [React](https://github.com/facebook/react)، بھی ممکنہ طور پر لوگوں کو کام کرنے کے لیے ملازمت دیں گے۔ آزاد مصدر. + +آپ کے ذاتی حالات پر منحصر ہے، آپ اپنے اوپن سورس کام کو فنڈ دینے کے لیے آزادانہ طور پر رقم جمع کرنے کی کوشش کر سکتے ہیں۔ مثال کے طور پر: + +* @Homebrew (اور [کئی دیگر دیکھ بھال کرنے والے اور تنظیمیں](https://github.com/sponsors/community)) اپنے کام کو [GitHub Sponsors](https://github.com/sponsors) کے ذریعے فنڈ دیتے ہیں۔ +* @gaearon نے [Patreon crowdfunding مہم] (https://redux.js.org/) کے ذریعے [Redux](https://github.com/reactjs/redux) پر اپنے کام کی مالی اعانت فراہم کی۔ +* @andrewgodwin نے Django اسکیما مائیگریشن پر مالی اعانت فراہم کی [ایک کِک اسٹارٹر مہم کے ذریعے](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) + +آخر میں، بعض اوقات اوپن سورس پروجیکٹس ان مسائل پر انعامات ڈالتے ہیں جن میں آپ مدد کرنے پر غور کر سکتے ہیں۔ + +* @ConnorChristie [مدد کرنے] (https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F) کے لیے ادائیگی کرنے کے قابل تھا۔ %2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol اپنی JavaScript لائبریری پر کام کرتا ہے [gitcoin پر ایک فضل کے ذریعے](https://gitcoin.co/)۔ +* @mamiM نے @MetaMask کے لیے جاپانی ترجمے کیے جب [مسئلے کو باؤنٹیز نیٹ ورک پر فنڈ فراہم کیا گیا تھا](https://explorer.bounties.network/bounty/134)۔ + +## اپنے پروجیکٹ کے لیے فنڈنگ ​​تلاش کرنا + +انفرادی شراکت داروں کے لیے انتظامات سے ہٹ کر، بعض اوقات پروجیکٹ جاری کام کو فنڈ دینے کے لیے کمپنیوں، افراد یا دوسروں سے رقم اکٹھا کرتے ہیں۔ + +تنظیمی فنڈنگ ​​موجودہ شراکت داروں کی ادائیگی، پروجیکٹ کو چلانے کے اخراجات (جیسے ہوسٹنگ فیس)، یا نئی خصوصیات یا آئیڈیاز میں سرمایہ کاری کی طرف جا سکتی ہے۔ + +جیسے جیسے اوپن سورس کی مقبولیت بڑھ رہی ہے، پروجیکٹس کے لیے فنڈز تلاش کرنا اب بھی تجرباتی ہے، لیکن چند عام اختیارات دستیاب ہیں۔ +### Raise money for your work through crowdfunding campaigns or sponsorships + +Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular. +A few examples of sponsored projects include: + +* **[webpack](https://github.com/webpack)** کمپنیوں اور افراد سے پیسہ اکٹھا کرتا ہے۔ [through OpenCollective](https://opencollective.com/webpack) +* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects + +### آمدنی کا سلسلہ بنائیں + +آپ کے پروجیکٹ پر منحصر ہے، آپ تجارتی تعاون، میزبانی کے اختیارات، یا اضافی خصوصیات کے لیے چارج کر سکتے ہیں۔ چند مثالوں میں شامل ہیں: + +* **[Sidekiq](https://github.com/mperham/sidekiq)** اضافی سپورٹ کے لیے بامعاوضہ ورژن پیش کرتا ہے +* **[Travis CI](https://github.com/travis-ci)** اپنی مصنوعات کے ادا شدہ ورژن پیش کرتا ہے +* **[گھوسٹ](https://github.com/TryGhost/Ghost)** ایک غیر منفعتی تنظیم ہے جس میں ادا کردہ نظم کردہ سروس ہے + +کچھ مشہور پروجیکٹس، جیسے [npm](https://github.com/npm/cli) اور [Docker](https://github.com/docker/docker)، یہاں تک کہ اپنے کاروبار کی ترقی میں مدد کے لیے وینچر کیپیٹل بھی بڑھاتے ہیں۔ + +### گرانٹ فنڈنگ ​​کے لیے درخواست دیں۔ + +کچھ سافٹ ویئر فاؤنڈیشنز اور کمپنیاں اوپن سورس کام کے لیے گرانٹ پیش کرتی ہیں۔ بعض اوقات، اس منصوبے کے لیے قانونی ادارہ قائم کیے بغیر افراد کو گرانٹس کی ادائیگی کی جا سکتی ہے۔ + +* **[دستاویزات کو پڑھیں](https://github.com/rtfd/readthedocs.org)** کو [موزیلا اوپن سورس سپورٹ] (https://www.mozilla.org/en-US/) سے گرانٹ موصول ہوا گرانٹس/) +* **[OpenMRS](https://github.com/openmrs)** کام کی مالی اعانت [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) سے کی گئی تھی۔ ) +* **[Libraries.io](https://github.com/librariesio)** کو [Sloan Foundation] (https://sloan.org/programs/digital-technology) سے گرانٹ موصول ہوا +* **[Python Software Foundation](https://www.python.org/psf/grants/)** ازگر سے متعلقہ کام کے لیے گرانٹس پیش کرتا ہے + +مزید تفصیلی اختیارات اور کیس اسٹڈیز کے لیے، @nayafia نے اوپن سورس کے کام کی ادائیگی کے لیے [ایک گائیڈ لکھا](https://github.com/nayafia/lemonade-stand)۔ مختلف قسم کی فنڈنگ ​​کے لیے مختلف مہارتوں کی ضرورت ہوتی ہے، اس لیے یہ جاننے کے لیے اپنی طاقتوں پر غور کریں کہ کون سا آپشن آپ کے لیے بہترین کام کرتا ہے۔ +## مالی مدد کے لیے کیس بنانا + +چاہے آپ کا پروجیکٹ ایک نیا آئیڈیا ہو، یا برسوں سے چل رہا ہو، آپ کو اپنے ہدف کے فنڈر کی شناخت کرنے اور ایک زبردست کیس بنانے میں اہم سوچ رکھنے کی توقع کرنی چاہیے۔ + +چاہے آپ اپنے وقت کے لیے ادائیگی کرنا چاہتے ہیں، یا کسی پروجیکٹ کے لیے فنڈ اکٹھا کرنا چاہتے ہیں، آپ کو درج ذیل سوالات کا جواب دینے کے قابل ہونا چاہیے۔ + +### کے اثرات + +یہ منصوبہ کیوں مفید ہے؟ آپ کے صارفین، یا ممکنہ صارفین، اسے اتنا کیوں پسند کرتے ہیں؟ پانچ سالوں میں کہاں ہو گا؟ + +### کرشن + +ثبوت جمع کرنے کی کوشش کریں کہ آپ کا پروجیکٹ اہمیت رکھتا ہے، چاہے وہ میٹرکس، کہانیاں، یا تعریفیں ہوں۔ کیا اس وقت کوئی کمپنیاں یا قابل ذکر لوگ آپ کے پروجیکٹ کو استعمال کر رہے ہیں؟ اگر نہیں تو کیا کسی ممتاز شخص نے اس کی تائید کی ہے؟ + +### فنڈ دینے والے کی قدر + +فنڈرز، چاہے آپ کا آجر ہو یا گرانٹ بنانے والی فاؤنڈیشن، اکثر مواقع کے ساتھ رابطہ کیا جاتا ہے۔ وہ کسی دوسرے موقع پر آپ کے پروجیکٹ کی حمایت کیوں کریں؟ وہ ذاتی طور پر کیسے فائدہ اٹھاتے ہیں؟ + +### فنڈز کا استعمال + +کیا، بالکل، آپ مجوزہ فنڈنگ ​​سے پورا کریں گے؟ تنخواہ ادا کرنے کے بجائے پروجیکٹ کے سنگ میل یا نتائج پر توجہ دیں۔ + +### آپ کو فنڈز کیسے ملیں گے۔ + +کیا فنڈ دینے والے کے پاس تقسیم کے بارے میں کوئی تقاضے ہیں؟ مثال کے طور پر، آپ کو ایک غیر منفعتی یا غیر منفعتی مالی کفیل ہونے کی ضرورت ہو سکتی ہے۔ یا شاید فنڈز کسی تنظیم کے بجائے انفرادی ٹھیکیدار کو دیئے جائیں۔ یہ تقاضے فنڈ دینے والوں کے درمیان مختلف ہوتے ہیں، اس لیے پہلے سے اپنی تحقیق کرنا یقینی بنائیں۔ + + + +## تجربہ کریں اور ہمت نہ ہاریں۔ + +پیسہ اکٹھا کرنا آسان نہیں ہے، چاہے آپ اوپن سورس پروجیکٹ ہوں، غیر منافع بخش ہوں، یا سافٹ ویئر اسٹارٹ اپ ہوں، اور زیادہ تر معاملات میں آپ کو تخلیقی بننے کی ضرورت ہوتی ہے۔ اس بات کی نشاندہی کرنا کہ آپ کس طرح ادائیگی حاصل کرنا چاہتے ہیں، اپنی تحقیق کرنا، اور اپنے آپ کو اپنے فنڈر کے جوتے میں ڈالنا آپ کو فنڈنگ ​​کے لیے ایک قائل کیس بنانے میں مدد کرے گا۔ \ No newline at end of file From 1b0b95cb216df82314eb449f4415dfbf13d67cdc Mon Sep 17 00:00:00 2001 From: Areebey Date: Wed, 25 Oct 2023 05:16:24 +0500 Subject: [PATCH 06/10] make and initialize how-to-contribute file --- _articles/ur/how-to-contribute.md | 526 ++++++++++++++++++++++++++++++ 1 file changed, 526 insertions(+) create mode 100644 _articles/ur/how-to-contribute.md diff --git a/_articles/ur/how-to-contribute.md b/_articles/ur/how-to-contribute.md new file mode 100644 index 00000000000..1a952f1c86e --- /dev/null +++ b/_articles/ur/how-to-contribute.md @@ -0,0 +1,526 @@ +--- +lang: en +title: How to Contribute to Open Source +description: Want to contribute to open source? A guide to making open source contributions, for first-timers and for veterans. +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +## Why contribute to open source? + + + +Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine. + +Why do people contribute to open source? Plenty of reasons! + +### Improve software you rely on + +Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it. + +### Improve existing skills + +Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project. + +### Meet people who are interested in similar things + +Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos. + +### Find mentors and teach others + +Working with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved. + +### Build public artifacts that help you grow a reputation (and a career) + +By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do. + +### Learn people skills + +Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work. + +### It's empowering to be able to make changes, even small ones + +You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying. + +## What it means to contribute + +If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong? + +Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience. + +### You don't have to contribute code + +A common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions! + + + +Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project. + +### Do you like planning events? + +* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406) +* Organize the project's conference (if they have one) +* Help community members find the right conferences and submit proposals for speaking + +### Do you like to design? + +* Restructure layouts to improve the project's usability +* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability) +* Put together a style guide to help the project have a consistent visual design +* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68) + +### Do you like to write? + +* Write and improve the project's documentation, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151) +* Curate a folder of examples showing how the project is used +* Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://news.opensauced.pizza/about/) +* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194) +* Write a translation for the project's documentation, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077) + + + +### Do you like organizing? + +* Link to duplicate issues, and suggest new issue labels, to keep things organized +* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765) +* Ask clarifying questions on recently opened issues to move the discussion forward + +### Do you like to code? + +* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* Ask if you can help write a new feature +* Automate project setup +* Improve tooling and testing + +### Do you like helping people? + +* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit +* Answer questions for people on open issues +* Help moderate the discussion boards or conversation channels + +### Do you like helping others code? + +* Review code on other people's submissions +* Write tutorials for how a project can be used +* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### You don't just have to work on software projects! + +While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects. + +For example: + +* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome) +* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates +* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts) + +Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience. + +## Orienting yourself to a new project + + + +For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely. + +Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard. + +### Anatomy of an open source project + +Every open source community is different. + +Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different. + +That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project. + +A typical open source project has the following types of people: + +* **Author:** The person/s or organization that created the project +* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author) +* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.) +* **Contributors:** Everyone who has contributed something back to the project +* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction + +Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information. + +A project also has documentation. These files are usually listed in the top level of a repository. + +* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source. +* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started. +* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to. A good example of an effective Contributing Guide would be the one from [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide). +* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to. +* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects like [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs). + +Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works. + +* **Issue tracker:** Where people discuss issues related to the project. +* **Pull requests:** Where people discuss and review changes that are in progress whether its to improve a contributor's line of code, grammar usage, use of images, etc. Some projects, such as [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint-fix.yml), use certain GitHub Action flows to automate and quicken their code reviews. +* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations. A good example of this would be [CHAOSS' weekly Newsletter](https://chaoss.community/news/) +* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. A good example of this would be [EddieHub's Discord community](http://discord.eddiehub.org/). + +## Finding a project to contribute to + +Now that you've figured out how open source projects work, it's time to find a project to contribute to! + +If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said:, _"Ask not what your country can do for you - ask what you can do for your country."_ + + + +Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look. + +Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to. + +Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct. + +Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable. + +You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about! + +> According to a study conducted by Igor Steinmacher and other Computer Science researchers, [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as typo fixes, reformatting, or writing a translation. + +If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). + +You can also use one of the following resources to help you discover and contribute to new projects: + +* [GitHub Explore](https://github.com/explore/) +* [Open Source Friday](https://opensourcefriday.com) +* [First Timers Only](https://www.firsttimersonly.com/) +* [CodeTriage](https://www.codetriage.com/) +* [24 Pull Requests](https://24pullrequests.com/) +* [Up For Grabs](https://up-for-grabs.net/) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) +* [OpenSauced](https://opensauced.pizza/) + +### A checklist before you contribute + +When you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response. + +Here's a handy checklist to evaluate whether a project is good for new contributors. + +**Meets the definition of open source** + +
+ + +
+ +**Project actively accepts contributions** + +Look at the commit activity on the main branch. On GitHub, you can see this information in the Insights tab of a repository's homepage, such as[Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse) + +
+ + +
+ +
+ + +
+ +
+ + +
+ +Next, look at the project's issues. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +Now do the same for the project's pull requests. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Project is welcoming** + +A project that is friendly and welcoming signals that they will be receptive to new contributors. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## How to submit a contribution + +You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way. + +### Communicating effectively + +Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source. + + + +Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively. + +**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!). + +> 😇 _"X doesn't happen when I do Y"_ +> +> 😢 _"X is broken! Please fix it."_ + +**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate it when you demonstrate that you're trying to learn. + +> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_ +> +> 😢 _"How do I X?"_ + +**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you. + +> 😇 _"I'd like to write an API tutorial."_ +> +> 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_ + +**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions. + +> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_ +> +> 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_ + +**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you. + +> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_ +> +> 😢 _"Why can't you fix my problem? Isn't this your project?"_ + +**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project. + +> 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_ +> +> 😢 _"Why won't you support my use case? This is unacceptable!"_ + +**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it. + +### Gathering context + +Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way. + +If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by doing the following: + +* **Raising an Issue:** These are like starting a conversation or discussion +* **Pull requests** are for starting work on a solution. +* **Communication Channels:** If the project has a designated Discord, IRC, or Slack channel, consider starting a conversation or asking for clarification about your contribution. + +Before you open an issue or pull request, check the project's contributing docs (usually a file called CONTRIBUTING, or in the README), to see whether you need to include anything specific. For example, they may ask that you follow a template, or require that you use tests. + +If you want to make a substantial contribution, open an issue to ask before working on it. It's helpful to watch the project for a while (on GitHub, [you can click "Watch"](https://help.github.com/articles/watching-repositories/) to be notified of all conversations), and get to know community members, before doing work that might not get accepted. + + + +### Opening an issue + +You should usually open an issue in the following situations: + +* Report an error you can't solve yourself +* Discuss a high-level topic or idea (for example, community, vision or policies) +* Propose a new feature or other project idea + +Tips for communicating on issues: + +* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work. +* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work. +* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project. + +### Opening a pull request + +You should usually open a pull request in the following situations: + +* Submit small fixes such as a typo, a broken link or an obvious error. +* Start work on a contribution that was already asked for, or that you've already discussed, in an issue. + +A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line or "Notes to Reviewers" sections if provided (or you can just create your own. Like this: `**## Notes to Reviewer**`). You can always add more commits later. + +If the project is on GitHub, here's how to submit a pull request: + +* **[Fork the repository](https://guides.github.com/activities/forking/)** and clone it locally. Connect your local to the original "upstream" repository by adding it as a remote. Pull in changes from "upstream" often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. (See more detailed instructions [here](https://help.github.com/articles/syncing-a-fork/).) +* **[Create a branch](https://guides.github.com/introduction/flow/)** for your edits. +* **Reference any relevant issues** or supporting documentation in your PR (for example, "Closes #37.") +* **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request. +* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. It's important to make sure your changes don't break the existing project. +* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future. + +If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey. + +## What happens after you submit your contribution + +Before we start celebrating, one of the following will happen after you submit your contribution: + +### 😭 You don't get a response + +Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response. + +If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread. + +**Don't reach out to that person privately**; remember that public communication is vital to open source projects. + +If you give a polite reminder and still do not receive a response, it's possible that nobody will ever respond. It's not a great feeling, but don't let that discourage you! 😄 There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive. + +### 🚧 Someone requests changes to your contribution + +It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code. + +When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it. A good example of this would be [the feedback that another contributor has given to @a-m-lamb on their pull request to Codecademy's Docs](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286). + +If you don't have time to work on the issue anymore due to reasons such as the conversation has been going on for months, and your circumstances have changed or you're unable to find a solution, let the maintainer know so that they can open the issue for someone else, like [@RitaDee did for an issue at OpenSauced's app repository](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346). + +### 👎 Your contribution doesn't get accepted + +Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree! + +### 🎉 Your contribution gets accepted + +Hooray! You've successfully made an open source contribution! + +## You did it! 🎉 + +Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time. From 9e2d593dd91c30e1cd02a5a3b88051f8e890b4de Mon Sep 17 00:00:00 2001 From: Areebey Date: Thu, 26 Oct 2023 05:41:48 +0500 Subject: [PATCH 07/10] still working on contributing.md file --- _articles/ur/how-to-contribute.md | 269 +++++++++++++++--------------- 1 file changed, 134 insertions(+), 135 deletions(-) diff --git a/_articles/ur/how-to-contribute.md b/_articles/ur/how-to-contribute.md index 1a952f1c86e..cc115e26629 100644 --- a/_articles/ur/how-to-contribute.md +++ b/_articles/ur/how-to-contribute.md @@ -10,295 +10,294 @@ related: - building --- -## Why contribute to open source? +## اوپن سورس میں کیوں تعاون کریں؟ -Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine. +اوپن سورس میں تعاون کرنا سیکھنے، سکھانے اور تجربہ بنانے کا ایک فائدہ مند طریقہ ہو سکتا ہے جس کا آپ تصور کر سکتے ہیں۔ -Why do people contribute to open source? Plenty of reasons! +لوگ اوپن سورس میں کیوں حصہ ڈالتے ہیں؟ بہت سی وجوہات! -### Improve software you rely on +### سافٹ ویئر کو بہتر بنائیں جس پر آپ انحصار کرتے ہیں۔ -Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it. +بہت سارے اوپن سورس تعاون کنندگان سافٹ ویئر کے استعمال کنندہ بن کر شروع کرتے ہیں جس میں وہ تعاون کرتے ہیں۔ جب آپ کو اوپن سورس سافٹ ویئر میں کوئی بگ ملتا ہے جسے آپ استعمال کرتے ہیں، تو آپ ماخذ کو دیکھنا چاہیں گے کہ آیا آپ اسے خود ہی پیچ کر سکتے ہیں۔ اگر ایسا ہے تو، اس بات کو یقینی بنانے کا بہترین طریقہ ہے کہ آپ کے دوست (اور خود جب آپ اگلی ریلیز پر اپ ڈیٹ کریں گے) اس سے فائدہ اٹھا سکیں گے۔ -### Improve existing skills +### موجودہ مہارتوں کو بہتر بنائیں -Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project. +چاہے یہ کوڈنگ ہو، یوزر انٹرفیس ڈیزائن، گرافک ڈیزائن، تحریر، یا تنظیم، اگر آپ مشق کی تلاش میں ہیں، تو آپ کے لیے اوپن سورس پروجیکٹ پر ایک کام ہے۔ -### Meet people who are interested in similar things +### ایسے لوگوں سے ملیں جو اسی طرح کی چیزوں میں دلچسپی رکھتے ہیں۔ -Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos. +پرجوش، خوش آئند کمیونٹیز کے ساتھ اوپن سورس پروجیکٹس لوگوں کو سالوں تک واپس آتے رہتے ہیں۔ بہت سے لوگ اوپن سورس میں اپنی شرکت کے ذریعے زندگی بھر کی دوستی قائم کرتے ہیں، چاہے وہ کانفرنسوں میں ایک دوسرے کے ساتھ چل رہے ہوں یا رات گئے آن لائن چیٹس کے بارے میں۔ -### Find mentors and teach others +### سرپرست تلاش کریں اور دوسروں کو سکھائیں۔ -Working with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved. +مشترکہ پروجیکٹ پر دوسروں کے ساتھ کام کرنے کا مطلب ہے کہ آپ کو یہ بتانا پڑے گا کہ آپ کام کیسے کرتے ہیں، اور ساتھ ہی دوسرے لوگوں سے بھی مدد طلب کریں۔ سیکھنے اور سکھانے کے عمل اس میں شامل ہر فرد کے لیے ایک تکمیلی سرگرمی ہو سکتے ہیں۔ -### Build public artifacts that help you grow a reputation (and a career) +### عوامی نمونے بنائیں جو آپ کو شہرت (اور کیریئر) بڑھانے میں مدد کرتے ہیں۔ -By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do. +تعریف کے مطابق، آپ کا تمام اوپن سورس کام عوامی ہے، جس کا مطلب ہے کہ آپ کو مفت مثالیں ملتی ہیں کہ آپ کیا کر سکتے ہیں اس کے مظاہرے کے طور پر کہیں بھی لے جائیں۔ -### Learn people skills +### لوگوں کے ہنر سیکھیں۔ -Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work. +اوپن سورس قیادت اور انتظامی مہارتوں کی مشق کرنے کے مواقع فراہم کرتا ہے، جیسے تنازعات کو حل کرنا، لوگوں کی ٹیموں کو منظم کرنا، اور کام کو ترجیح دینا۔ -### It's empowering to be able to make changes, even small ones +### تبدیلیاں کرنے کے قابل ہونا بااختیار بناتا ہے، یہاں تک کہ چھوٹی بھی -You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying. +اوپن سورس میں شرکت سے لطف اندوز ہونے کے لیے آپ کو تاحیات شراکت دار بننے کی ضرورت نہیں ہے۔ کیا آپ نے کبھی کسی ویب سائٹ پر ٹائپنگ کی غلطی دیکھی ہے، اور خواہش کی ہے کہ کوئی اسے ٹھیک کردے؟ اوپن سورس پروجیکٹ پر، آپ ایسا ہی کر سکتے ہیں۔ اوپن سورس لوگوں کو ان کی زندگیوں پر ایجنسی محسوس کرنے میں مدد کرتا ہے اور وہ دنیا کا تجربہ کیسے کرتے ہیں، اور یہ بذات خود اطمینان بخش ہے۔ -## What it means to contribute +## حصہ ڈالنے کا کیا مطلب ہے۔ -If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong? +اگر آپ ایک نئے اوپن سورس تعاون کنندہ ہیں، تو یہ عمل خوفناک ہو سکتا ہے۔ آپ کو صحیح پروجیکٹ کیسے ملتا ہے؟ اگر آپ کوڈ کرنا نہیں جانتے تو کیا ہوگا؟ اگر کچھ غلط ہو جائے تو کیا ہوگا؟ -Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience. +پریشانی کی بات نہیں! اوپن سورس پروجیکٹ میں شامل ہونے کے ہر طرح کے طریقے ہیں، اور چند تجاویز آپ کو اپنے تجربے سے زیادہ سے زیادہ فائدہ اٹھانے میں مدد کریں گی۔ -### You don't have to contribute code +### آپ کو کوڈ میں تعاون کرنے کی ضرورت نہیں ہے۔ -A common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions! +اوپن سورس میں تعاون کرنے کے بارے میں ایک عام غلط فہمی یہ ہے کہ آپ کو کوڈ میں تعاون کرنے کی ضرورت ہے۔ درحقیقت، یہ اکثر کسی پروجیکٹ کے دوسرے حصے ہوتے ہیں جو [سب سے زیادہ نظرانداز یا نظر انداز کیے جاتے ہیں](https://github.com/blog/2195-the-shape-of-open-source)۔ آپ اس قسم کے تعاون کے ساتھ حصہ لینے کی پیشکش کر کے اس پروجیکٹ پر ایک _بڑا_ احسان کریں گے! -Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project. +یہاں تک کہ اگر آپ کوڈ لکھنا پسند کرتے ہیں تو، دوسرے قسم کے تعاون کسی پروجیکٹ میں شامل ہونے اور کمیونٹی کے دیگر اراکین سے ملنے کا بہترین طریقہ ہیں۔ ان تعلقات کو استوار کرنے سے آپ کو پروجیکٹ کے دوسرے حصوں پر کام کرنے کے مواقع ملیں گے۔ -### Do you like planning events? +### کیا آپ ایونٹس کی منصوبہ بندی کرنا پسند کرتے ہیں؟ -* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406) -* Organize the project's conference (if they have one) -* Help community members find the right conferences and submit proposals for speaking +* پروجیکٹ کے بارے میں ورکشاپس یا میٹنگز کا اہتمام کریں، [جیسے @fzamperin نے NodeSchool کے لیے کیا](https://github.com/nodeschool/organizers/issues/406) +* پروجیکٹ کی کانفرنس کا اہتمام کریں (اگر ان کے پاس ہے) +* کمیونٹی کے اراکین کو صحیح کانفرنسیں تلاش کرنے اور بولنے کے لیے تجاویز جمع کرانے میں مدد کریں۔ -### Do you like to design? +### کیا آپ ڈیزائن کرنا پسند کرتے ہیں؟ -* Restructure layouts to improve the project's usability -* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability) -* Put together a style guide to help the project have a consistent visual design -* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68) +* پراجیکٹ کے استعمال کو بہتر بنانے کے لیے ترتیب کو دوبارہ ترتیب دیں۔ +* پروجیکٹ کی نیویگیشن یا مینوز کو دوبارہ ترتیب دینے اور بہتر کرنے کے لیے صارف کی تحقیق کریں، [جیسے ڈروپل تجویز کرتا ہے](https://www.drupal.org/community-initiatives/drupal-core/usability) +* پراجیکٹ کو مستقل بصری ڈیزائن بنانے میں مدد کرنے کے لیے ایک اسٹائل گائیڈ جمع کریں۔ +* ٹی شرٹس یا نئے لوگو کے لیے آرٹ بنائیں، [جیسے hapi.js کے تعاون کرنے والوں نے کیا](https://github.com/hapijs/contrib/issues/68) -### Do you like to write? +### کیا آپ لکھنا پسند کرتے ہیں؟ -* Write and improve the project's documentation, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151) -* Curate a folder of examples showing how the project is used -* Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://news.opensauced.pizza/about/) -* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194) -* Write a translation for the project's documentation, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077) +* پروجیکٹ کی دستاویزات لکھیں اور بہتر بنائیں، [جیسے @CBID2 نے OpenSauced کی دستاویزات کے لیے کیا](https://github.com/open-sauced/docs/pull/151) +* مثالوں کا ایک فولڈر بنائیں جس میں دکھایا گیا ہے کہ پروجیکٹ کیسے استعمال ہوتا ہے۔ +* پروجیکٹ کے لیے ایک نیوز لیٹر شروع کریں، یا میلنگ لسٹ سے ہائی لائٹس کیوریٹ کریں، [جیسے @opensauced نے اپنے پروڈکٹ کے لیے کیا](https://news.opensauced.pizza/about/) +* پروجیکٹ کے لیے سبق لکھیں، [جیسا کہ PyPA کے معاونین نے کیا](https://github.com/pypa/python-packaging-user-guide/issues/194) +* پروجیکٹ کی دستاویزات کے لیے ترجمہ لکھیں، [جیسے @frontendwizard نے فری کوڈ کیمپ کے سی ایس ایس فلیکس باکس چیلنج کی ہدایات کے لیے کیا](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077) -### Do you like organizing? +### کیا آپ کو منظم کرنا پسند ہے؟ -* Link to duplicate issues, and suggest new issue labels, to keep things organized -* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765) -* Ask clarifying questions on recently opened issues to move the discussion forward +* ڈپلیکیٹ ایشوز سے لنک کریں، اور چیزوں کو منظم رکھنے کے لیے نئے ایشو لیبل تجویز کریں۔ +* کھلے مسائل کو دیکھیں اور پرانے کو بند کرنے کا مشورہ دیں، [جیسے @nzakas نے ESLint کے لیے کیا](https://github.com/eslint/eslint/issues/6765) +* بحث کو آگے بڑھانے کے لیے حال ہی میں کھولے گئے مسائل پر واضح سوالات پوچھیں۔ -### Do you like to code? +### کیا آپ کوڈ کرنا پسند کرتے ہیں؟ -* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) -* Ask if you can help write a new feature -* Automate project setup -* Improve tooling and testing +* نمٹنے کے لیے ایک کھلا مسئلہ تلاش کریں، [جیسے @dianjin نے لیفلیٹ کے لیے کیا](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* پوچھیں کہ کیا آپ ایک نیا فیچر لکھنے میں مدد کر سکتے ہیں۔ +* خودکار پروجیکٹ سیٹ اپ +* ٹولنگ اور ٹیسٹنگ کو بہتر بنائیں -### Do you like helping people? +### کیا آپ لوگوں کی مدد کرنا پسند کرتے ہیں؟ -* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit -* Answer questions for people on open issues -* Help moderate the discussion boards or conversation channels +* پراجیکٹ کے بارے میں سوالات کے جواب دیں جیسے کہ اسٹیک اوور فلو ([اس پوسٹگریس مثال کی طرح)(https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying) -to-ge)) یا Reddit +* کھلے مسائل پر لوگوں کے سوالات کے جوابات دیں۔ +* ڈسکشن بورڈز یا بات چیت کے چینلز کو معتدل کرنے میں مدد کریں۔ -### Do you like helping others code? +### کیا آپ دوسروں کو کوڈ میں مدد کرنا پسند کرتے ہیں؟ -* Review code on other people's submissions -* Write tutorials for how a project can be used -* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) +* دوسرے لوگوں کی گذارشات پر کوڈ کا جائزہ لیں۔ +* پراجیکٹ کو کس طرح استعمال کیا جا سکتا ہے اس کے لیے سبق لکھیں۔ +* کسی اور تعاون کنندہ کو سرپرست کی پیشکش، [جیسے @ereichert نے @bronzdoc on Rust کے لیے کیا](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) -### You don't just have to work on software projects! +### آپ کو صرف سافٹ ویئر پروجیکٹس پر کام کرنے کی ضرورت نہیں ہے! -While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects. +اگرچہ "اوپن سورس" سے اکثر سافٹ ویئر مراد ہوتا ہے، آپ کسی بھی چیز پر تعاون کر سکتے ہیں۔ ایسی کتابیں، ترکیبیں، فہرستیں اور کلاسیں ہیں جو اوپن سورس پروجیکٹس کے طور پر تیار ہوتی ہیں۔ -For example: +مثال کے طور پر: -* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome) -* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates -* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts) +* @sindresorhus ["خوبصورت" فہرستوں کی فہرست تیار کرتا ہے](https://github.com/sindresorhus/awesome) +* @h5bp فرنٹ اینڈ ڈویلپر امیدواروں کے لیے [ممکنہ انٹرویو کے سوالات کی فہرست](https://github.com/h5bp/Front-end-Developer-Interview-Questions) برقرار رکھتا ہے۔ +* @stuartlynn اور @nicole-a-tesla نے ایک [پفنز کے بارے میں تفریحی حقائق کا مجموعہ] بنایا (https://github.com/stuartlynn/puffin_facts) -Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience. +یہاں تک کہ اگر آپ سافٹ ویئر ڈویلپر ہیں، دستاویزی پروجیکٹ پر کام کرنے سے آپ کو اوپن سورس میں شروع کرنے میں مدد مل سکتی ہے۔ ایسے پروجیکٹس پر کام کرنا اکثر کم خوفزدہ ہوتا ہے جن میں کوڈ شامل نہیں ہوتا ہے، اور تعاون کا عمل آپ کا اعتماد اور تجربہ بڑھاتا ہے۔ -## Orienting yourself to a new project +## اپنے آپ کو ایک نئے پروجیکٹ کی طرف راغب کرنا -For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely. +ٹائپنگ فکس کے علاوہ کسی بھی چیز کے لیے، اوپن سورس میں تعاون کرنا پارٹی میں اجنبیوں کے گروپ کے ساتھ چلنے کے مترادف ہے۔ اگر آپ لاماس کے بارے میں بات کرنا شروع کرتے ہیں، جب وہ گولڈ فش کے بارے میں گہری بحث میں تھے، تو وہ شاید آپ کو قدرے عجیب نظر سے دیکھیں گے۔ -Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard. +اپنی تجاویز کے ساتھ آنکھیں بند کر کے کودنے سے پہلے، کمرے کو پڑھنے کا طریقہ سیکھ کر شروع کریں۔ ایسا کرنے سے اس بات کے امکانات بڑھ جاتے ہیں کہ آپ کے خیالات کو دیکھا اور سنا جائے گا۔ -### Anatomy of an open source project +### ایک اوپن سورس پروجیکٹ کی اناٹومی۔ -Every open source community is different. +ہر اوپن سورس کمیونٹی مختلف ہے۔ -Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different. +ایک اوپن سورس پروجیکٹ پر سال گزارنے کا مطلب ہے کہ آپ نے ایک اوپن سورس پروجیکٹ کو جان لیا ہے۔ ایک مختلف پروجیکٹ پر جائیں، اور آپ کو الفاظ، اصول، اور مواصلات کے انداز بالکل مختلف معلوم ہو سکتے ہیں۔ -That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project. +اس نے کہا، بہت سے اوپن سورس پروجیکٹ اسی طرح کے تنظیمی ڈھانچے کی پیروی کرتے ہیں۔ کمیونٹی کے مختلف کرداروں اور مجموعی عمل کو سمجھنے سے آپ کو کسی بھی نئے پروجیکٹ کی طرف تیزی سے توجہ حاصل کرنے میں مدد ملے گی۔ -A typical open source project has the following types of people: +ایک عام اوپن سورس پروجیکٹ میں درج ذیل قسم کے لوگ ہوتے ہیں: -* **Author:** The person/s or organization that created the project -* **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author) -* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.) -* **Contributors:** Everyone who has contributed something back to the project -* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction +* **مصنف:** وہ شخص یا تنظیم جس نے پروجیکٹ بنایا +* **مالک:** وہ شخص جس کی تنظیم یا ذخیرہ پر انتظامی ملکیت ہے (ہمیشہ اصل مصنف کی طرح نہیں ہوتا) +* ** دیکھ بھال کرنے والے:** تعاون کرنے والے جو وژن کو آگے بڑھانے اور پروجیکٹ کے تنظیمی پہلوؤں کو منظم کرنے کے ذمہ دار ہیں (وہ پروجیکٹ کے مصنف یا مالک بھی ہوسکتے ہیں۔) +*** شراکت دار:** ہر وہ شخص جس نے پروجیکٹ میں کچھ حصہ دیا ہے۔ +* **کمیونٹی ممبرز:** وہ لوگ جو پروجیکٹ استعمال کرتے ہیں۔ وہ بات چیت میں سرگرم ہو سکتے ہیں یا پروجیکٹ کی سمت پر اپنی رائے کا اظہار کر سکتے ہیں۔ -Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information. +بڑے پروجیکٹس میں ذیلی کمیٹیاں یا ورکنگ گروپس بھی ہوسکتے ہیں جن کی توجہ مختلف کاموں پر مرکوز ہوتی ہے، جیسے ٹولنگ، ٹرائیج، کمیونٹی اعتدال اور ایونٹ آرگنائزنگ۔ اس معلومات کو تلاش کرنے کے لیے کسی پروجیکٹ کی ویب سائٹ پر "ٹیم" کے صفحے، یا گورننس دستاویزات کے ذخیرے میں دیکھیں۔ -A project also has documentation. These files are usually listed in the top level of a repository. +ایک پروجیکٹ کے پاس دستاویزات بھی ہیں۔ یہ فائلیں عام طور پر ذخیرے کے اوپری درجے میں درج ہوتی ہیں۔ -* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source. -* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started. -* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to. A good example of an effective Contributing Guide would be the one from [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide). -* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to. -* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects like [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs). +* **لائسنس:** تعریف کے مطابق، ہر اوپن سورس پروجیکٹ کے پاس [اوپن سورس لائسنس](https://choosealicense.com) ہونا ضروری ہے۔ اگر پروجیکٹ کے پاس لائسنس نہیں ہے تو یہ اوپن سورس نہیں ہے۔ +* **README:** README ایک ہدایت نامہ ہے جو کمیونٹی کے نئے اراکین کو پروجیکٹ میں خوش آمدید کہتا ہے۔ یہ بتاتا ہے کہ پروجیکٹ کیوں مفید ہے اور کیسے شروع کیا جائے۔ +* **کنٹریبیوٹنگ:** جہاں READMEs لوگوں کو پروجیکٹ کو _استعمال_ کرنے میں مدد کرتے ہیں، وہیں تعاون کرنے والے دستاویزات لوگوں کو پروجیکٹ میں _contributing_ کرنے میں مدد کرتے ہیں۔ یہ بتاتا ہے کہ کن قسم کے تعاون کی ضرورت ہے اور یہ عمل کیسے کام کرتا ہے۔ اگرچہ ہر پروجیکٹ میں CONTRIBUTING فائل نہیں ہوتی ہے، لیکن اس کی موجودگی اس بات کا اشارہ دیتی ہے کہ یہ تعاون کرنے کے لیے ایک خوش آئند پروجیکٹ ہے۔ ایک مؤثر تعاون کرنے والی گائیڈ کی ایک اچھی مثال [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide) سے ہوگی۔ +* **CODE_OF_CONDUCT:** ضابطہ اخلاق شرکا سے وابستہ رویے کے لیے بنیادی اصول طے کرتا ہے اور ایک دوستانہ، خوش آئند ماحول کو آسان بنانے میں مدد کرتا ہے۔ اگرچہ ہر پروجیکٹ میں CODE_OF_CONDUCT فائل نہیں ہوتی ہے، لیکن اس کی موجودگی اس بات کا اشارہ دیتی ہے کہ یہ تعاون کرنے کے لیے ایک خوش آئند پروجیکٹ ہے۔ +* **دیگر دستاویزات:** اضافی دستاویزات ہو سکتی ہیں، جیسے سبق، واک تھرو، یا گورننس پالیسیاں، خاص طور پر بڑے پروجیکٹس جیسے [Astro Docs](https://docs.astro.build/en/contribute/#contributing دستاویزات سے)۔ -Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works. +آخر میں، اوپن سورس پروجیکٹس بحث کو منظم کرنے کے لیے درج ذیل ٹولز کا استعمال کرتے ہیں۔ آرکائیوز کو پڑھنے سے آپ کو ایک اچھی تصویر ملے گی کہ کمیونٹی کس طرح سوچتی ہے اور کام کرتی ہے۔ -* **Issue tracker:** Where people discuss issues related to the project. -* **Pull requests:** Where people discuss and review changes that are in progress whether its to improve a contributor's line of code, grammar usage, use of images, etc. Some projects, such as [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint-fix.yml), use certain GitHub Action flows to automate and quicken their code reviews. -* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (for example, _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations. A good example of this would be [CHAOSS' weekly Newsletter](https://chaoss.community/news/) -* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. A good example of this would be [EddieHub's Discord community](http://discord.eddiehub.org/). +*** ایشو ٹریکر:** جہاں لوگ پروجیکٹ سے متعلق مسائل پر بات کرتے ہیں۔ +* **درخواستیں کھینچیں:** جہاں لوگ ان تبدیلیوں پر تبادلہ خیال کرتے ہیں اور ان کا جائزہ لیتے ہیں جو جاری ہیں کہ آیا یہ شراکت کنندہ کے کوڈ، گرامر کا استعمال، تصاویر کا استعمال، وغیرہ کو بہتر بنانا ہے۔ کچھ پروجیکٹس، جیسے [MDN Web Docs](https: //github.com/mdn/content/blob/main/.github/workflows/markdown-lint-fix.yml)، اپنے کوڈ کے جائزوں کو خودکار اور تیز کرنے کے لیے مخصوص GitHub ایکشن فلو استعمال کریں۔ +* **ڈسکشن فورمز یا میلنگ لسٹ:** کچھ پروجیکٹس ان چینلز کو گفت و شنید کے موضوعات کے لیے استعمال کر سکتے ہیں (مثال کے طور پر، _"میں کیسے..."_ یا _"آپ کا کیا خیال ہے..."_ بگ کی بجائے رپورٹس یا فیچر کی درخواستیں)۔ دوسرے تمام بات چیت کے لیے ایشو ٹریکر استعمال کرتے ہیں۔ اس کی ایک اچھی مثال [CHAOSS' ہفتہ وار نیوز لیٹر](https://chaoss.community/news/) ہوگی۔ +* **مطابقت پذیر چیٹ چینل:** کچھ پروجیکٹس آرام دہ گفتگو، تعاون، اور فوری تبادلے کے لیے چیٹ چینلز (جیسے Slack یا IRC) استعمال کرتے ہیں۔ اس کی ایک اچھی مثال [EddieHub's Discord community](http://discord.eddiehub.org/) ہوگی۔ -## Finding a project to contribute to +## شراکت کے لیے ایک پروجیکٹ تلاش کرنا -Now that you've figured out how open source projects work, it's time to find a project to contribute to! +اب جب کہ آپ یہ جان چکے ہیں کہ اوپن سورس پروجیکٹس کس طرح کام کرتے ہیں، اب وقت آگیا ہے کہ اس میں تعاون کرنے کے لیے کوئی پروجیکٹ تلاش کیا جائے! -If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said:, _"Ask not what your country can do for you - ask what you can do for your country."_ +اگر آپ نے پہلے کبھی اوپن سورس میں تعاون نہیں کیا ہے، تو امریکی صدر جان ایف کینیڈی سے کچھ مشورہ لیں، جنہوں نے ایک بار کہا تھا:، _"یہ مت پوچھو کہ آپ کا ملک آپ کے لیے کیا کر سکتا ہے - پوچھیں کہ آپ اپنے ملک کے لیے کیا کر سکتے ہیں۔"_ -Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look. +اوپن سورس میں تعاون ہر سطح پر، تمام پروجیکٹس میں ہوتا ہے۔ آپ کو یہ سوچنے کی ضرورت نہیں ہے کہ آپ کا پہلا حصہ بالکل کیا ہوگا، یا یہ کیسا نظر آئے گا۔ -Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to. +اس کے بجائے، ان منصوبوں کے بارے میں سوچ کر شروع کریں جو آپ پہلے سے استعمال کرتے ہیں، یا استعمال کرنا چاہتے ہیں۔ جن منصوبوں میں آپ فعال طور پر تعاون کریں گے وہ وہی ہیں جن پر آپ خود کو واپس آتے ہوئے پائیں گے۔ -Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct. +ان منصوبوں کے اندر، جب بھی آپ اپنے آپ کو یہ سوچتے ہیں کہ کچھ بہتر یا مختلف ہو سکتا ہے، اپنی جبلت پر عمل کریں۔ -Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable. +اوپن سورس کوئی خصوصی کلب نہیں ہے۔ یہ آپ جیسے لوگوں نے بنایا ہے۔ "اوپن سورس" دنیا کے مسائل کو حل کرنے کے قابل سمجھنے کے لیے صرف ایک فینسی اصطلاح ہے۔ -You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about! +آپ README کو اسکین کر سکتے ہیں اور ایک ٹوٹا ہوا لنک یا ٹائپو تلاش کر سکتے ہیں۔ یا آپ ایک نئے صارف ہیں اور آپ نے دیکھا کہ کچھ ٹوٹا ہوا ہے، یا کوئی مسئلہ جو آپ کے خیال میں واقعی دستاویزات میں ہونا چاہیے۔ اسے نظر انداز کرنے اور آگے بڑھنے، یا کسی اور سے اسے ٹھیک کرنے کے لیے کہنے کے بجائے، دیکھیں کہ کیا آپ اندر جا کر مدد کر سکتے ہیں۔ اوپن سورس کا یہی مطلب ہے! -> According to a study conducted by Igor Steinmacher and other Computer Science researchers, [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as typo fixes, reformatting, or writing a translation. +> Igor Steinmacher اور کمپیوٹر سائنس کے دیگر محققین کی طرف سے کی گئی ایک تحقیق کے مطابق، اوپن سورس کے لیے [28% غیر معمولی تعاون](https://www.igor.pro.br/publica/papers/saner2016.pdf) دستاویزات ہیں، جیسے جیسا کہ ٹائپنگ ٹھیک کرنا، دوبارہ فارمیٹ کرنا، یا ترجمہ لکھنا۔ -If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). +اگر آپ موجودہ مسائل کی تلاش کر رہے ہیں جس کو آپ ٹھیک کر سکتے ہیں، تو ہر اوپن سورس پروجیکٹ میں ایک `/contribute` صفحہ ہوتا ہے جو ابتدائی دوستانہ مسائل کو نمایاں کرتا ہے جس سے آپ شروعات کر سکتے ہیں۔ GitHub پر مخزن کے مرکزی صفحہ پر جائیں، اور URL کے آخر میں `/contribute` شامل کریں (مثال کے طور پر [`https://github.com/facebook/react/contribute`](https://github. com/facebook/react/contribute))۔ -You can also use one of the following resources to help you discover and contribute to new projects: +آپ نئے پروجیکٹس کو دریافت کرنے اور ان میں تعاون کرنے میں مدد کے لیے درج ذیل وسائل میں سے ایک بھی استعمال کر سکتے ہیں: -* [GitHub Explore](https://github.com/explore/) -* [Open Source Friday](https://opensourcefriday.com) -* [First Timers Only](https://www.firsttimersonly.com/) +* [گٹ ہب ایکسپلور](https://github.com/explore/) +* [اوپن سورس فرائیڈے](https://opensourcefriday.com) +* [صرف فرسٹ ٹائمرز](https://www.firsttimersonly.com/) * [CodeTriage](https://www.codetriage.com/) -* [24 Pull Requests](https://24pullrequests.com/) -* [Up For Grabs](https://up-for-grabs.net/) -* [First Contributions](https://firstcontributions.github.io) +* [24 پل کی درخواستیں](https://24pullrequests.com/) +* [اپ فار گرابس](https://up-for-grabs.net/) +* [پہلی شراکتیں](https://firstcontributions.github.io) * [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) * [OpenSauced](https://opensauced.pizza/) -### A checklist before you contribute +### آپ کے تعاون سے پہلے ایک چیک لسٹ -When you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response. +جب آپ کو کوئی ایسا پروجیکٹ مل جاتا ہے جس میں آپ تعاون کرنا چاہتے ہیں، تو اس بات کو یقینی بنانے کے لیے فوری اسکین کریں کہ پروجیکٹ شراکت قبول کرنے کے لیے موزوں ہے۔ ورنہ آپ کی محنت کا جواب کبھی نہیں مل سکتا۔ -Here's a handy checklist to evaluate whether a project is good for new contributors. +یہ جانچنے کے لیے ایک آسان چیک لسٹ ہے کہ آیا کوئی پروجیکٹ نئے تعاون کنندگان کے لیے اچھا ہے۔ -**Meets the definition of open source** +**اوپن سورس کی تعریف پر پورا اترتا ہے**
-**Project actively accepts contributions** +**پروجیکٹ فعال طور پر شراکتیں قبول کرتا ہے** -Look at the commit activity on the main branch. On GitHub, you can see this information in the Insights tab of a repository's homepage, such as[Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse) +مرکزی برانچ پر کمٹ کی سرگرمی کو دیکھیں۔ GitHub پر، آپ یہ معلومات ذخیرہ کے ہوم پیج کے بصیرت والے ٹیب میں دیکھ سکتے ہیں، جیسے [Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse)
+تازہ ترین عہد کب تھا؟
+اس منصوبے کے کتنے شراکت دار ہیں؟
-Next, look at the project's issues. +اگلا، پروجیکٹ کے مسائل کو دیکھیں۔
+کیا دیکھ بھال کرنے والے مسائل کا فوری جواب دیتے ہیں جب وہ کھولے جاتے ہیں؟
@@ -307,41 +306,41 @@ Now do the same for the project's pull requests.
-**Project is welcoming** +**منصوبہ خوش آئند ہے** -A project that is friendly and welcoming signals that they will be receptive to new contributors. +ایک ایسا پروجیکٹ جو دوستانہ اور خوش آئند سگنل ہے کہ وہ نئے شراکت داروں کے لیے قبول کریں گے۔
From 35dd134766f82991b032024a3fc1596bd03f8257 Mon Sep 17 00:00:00 2001 From: Areebey Date: Sat, 28 Oct 2023 05:31:42 +0500 Subject: [PATCH 08/10] convert how-to-contribute file in urdu. --- _articles/ur/how-to-contribute.md | 159 +++++++++++++++--------------- 1 file changed, 78 insertions(+), 81 deletions(-) diff --git a/_articles/ur/how-to-contribute.md b/_articles/ur/how-to-contribute.md index cc115e26629..b8a73c15c3a 100644 --- a/_articles/ur/how-to-contribute.md +++ b/_articles/ur/how-to-contribute.md @@ -345,181 +345,178 @@ Now do the same for the project's pull requests.
+کیا دیکھ بھال کرنے والے مسائل میں سوالات کا مددگار جواب دیتے ہیں؟
+کیا پل کی درخواستوں کا جائزہ لیا جاتا ہے؟
+کیا دیکھ بھال کرنے والے لوگوں کے تعاون کے لیے ان کا شکریہ ادا کرتے ہیں؟
-## How to submit a contribution +## شراکت جمع کرنے کا طریقہ -You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way. +آپ کو اپنی پسند کا پروجیکٹ مل گیا ہے، اور آپ اپنا حصہ ڈالنے کے لیے تیار ہیں۔ آخرکار! اپنا تعاون صحیح طریقے سے حاصل کرنے کا طریقہ یہاں ہے۔ -### Communicating effectively +### مؤثر طریقے سے بات چیت کرنا -Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source. +چاہے آپ ایک وقتی تعاون کرنے والے ہوں یا کسی کمیونٹی میں شامل ہونے کی کوشش کر رہے ہوں، دوسروں کے ساتھ کام کرنا ان سب سے اہم مہارتوں میں سے ایک ہے جسے آپ اوپن سورس میں تیار کریں گے۔ -Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively. +اس سے پہلے کہ آپ کوئی مسئلہ کھولیں یا درخواست کریں، یا چیٹ میں کوئی سوال پوچھیں، ان نکات کو ذہن میں رکھیں تاکہ آپ کے خیالات کو مؤثر طریقے سے سامنے آنے میں مدد ملے۔ -**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!). +**سیاق و سباق دیں۔** دوسروں کو تیزی سے تیز رفتار بنانے میں مدد کریں۔ اگر آپ کو کوئی غلطی ہو رہی ہے تو وضاحت کریں کہ آپ کیا کرنے کی کوشش کر رہے ہیں اور اسے دوبارہ کیسے بنایا جائے۔ اگر آپ کوئی نیا آئیڈیا تجویز کر رہے ہیں تو وضاحت کریں کہ آپ کو کیوں لگتا ہے کہ یہ پروجیکٹ کے لیے مفید ہوگا (صرف آپ کے لیے نہیں!) -> 😇 _"X doesn't happen when I do Y"_ +> 😇 _"X نہیں ہوتا جب میں Y کرتا ہوں"_ > -> 😢 _"X is broken! Please fix it."_ +> 😢 _"X ٹوٹ گیا ہے! براہ کرم اسے ٹھیک کریں۔"_ -**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate it when you demonstrate that you're trying to learn. +**اپنا ہوم ورک پہلے سے کر لیں۔** چیزوں کو نہ جاننا ٹھیک ہے، لیکن دکھائیں کہ آپ نے کوشش کی۔ مدد طلب کرنے سے پہلے، کسی پروجیکٹ کی README، دستاویزات، مسائل (کھلی یا بند)، میلنگ لسٹ، اور جواب کے لیے انٹرنیٹ پر تلاش کرنا یقینی بنائیں۔ لوگ اس کی تعریف کریں گے جب آپ یہ ظاہر کریں گے کہ آپ سیکھنے کی کوشش کر رہے ہیں۔ -> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_ +> 😇 _"مجھے یقین نہیں ہے کہ X کو کیسے نافذ کیا جائے۔ میں نے مدد کے دستاویزات کو چیک کیا اور مجھے کوئی تذکرہ نہیں ملا۔"_ > -> 😢 _"How do I X?"_ +>😢 _"میں ایکس کیسے کروں؟"_ -**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you. +**درخواستوں کو مختصر اور براہ راست رکھیں۔** بالکل ای میل بھیجنے کی طرح، ہر تعاون، چاہے کتنا ہی آسان یا مددگار ہو، کسی اور کے جائزے کی ضرورت ہوتی ہے۔ بہت سے منصوبوں میں مدد کے لیے دستیاب لوگوں سے زیادہ آنے والی درخواستیں ہوتی ہیں۔ مختصر ہونا۔ آپ اس موقع کو بڑھا دیں گے کہ کوئی آپ کی مدد کر سکے گا۔ -> 😇 _"I'd like to write an API tutorial."_ +> 😇 _"میں ایک API ٹیوٹوریل لکھنا چاہوں گا۔"_ > -> 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_ +>😢 _"میں دوسرے دن ہائی وے پر گاڑی چلا رہا تھا اور گیس کے لیے رک گیا، اور تب مجھے یہ حیرت انگیز خیال آیا کہ ہمیں کچھ کرنا چاہیے، لیکن اس سے پہلے کہ میں اس کی وضاحت کروں، میں آپ کو دکھاتا ہوں..."_ -**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions. +**تمام مواصلات کو عوامی رکھیں۔** اگرچہ یہ پرکشش ہے، لیکن نجی طور پر دیکھ بھال کرنے والوں تک نہ پہنچیں جب تک کہ آپ کو حساس معلومات (جیسے سیکیورٹی کا مسئلہ یا اخلاق کی سنگین خلاف ورزی) کا اشتراک کرنے کی ضرورت نہ ہو۔ جب آپ گفتگو کو عام رکھتے ہیں تو زیادہ لوگ آپ کے تبادلے سے سیکھ سکتے ہیں اور فائدہ اٹھا سکتے ہیں۔ بات چیت، اپنے آپ میں، شراکت ہو سکتی ہے۔ -> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_ +> 😇 _(ایک تبصرہ کے طور پر) "@-maintainer ہیلو! ہمیں اس PR پر کیسے آگے بڑھنا چاہئے؟"_ > -> 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_ +😢 -**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you. +**سوال پوچھنا ٹھیک ہے (لیکن صبر کریں!)۔** ہر کوئی کسی وقت اس پروجیکٹ میں نیا تھا، اور یہاں تک کہ تجربہ کار شراکت داروں کو بھی کسی نئے پروجیکٹ کو دیکھتے وقت تیز رفتاری سے کام لینا پڑتا ہے۔ اسی علامت کے مطابق، یہاں تک کہ طویل عرصے سے دیکھ بھال کرنے والے بھی ہمیشہ منصوبے کے ہر حصے سے واقف نہیں ہوتے ہیں۔ انہیں وہی صبر دکھائیں جو آپ چاہتے ہیں کہ وہ آپ کو دکھائے۔ -> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_ +> 😇 _"اس غلطی کو دیکھنے کا شکریہ۔ میں نے آپ کی تجاویز پر عمل کیا۔ آؤٹ پٹ یہ ہے۔"_ > -> 😢 _"Why can't you fix my problem? Isn't this your project?"_ +>😢 _"آپ میرا مسئلہ حل کیوں نہیں کر سکتے؟ کیا یہ آپ کا پروجیکٹ نہیں ہے؟"_ -**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project. +**کمیونٹی کے فیصلوں کا احترام کریں۔** آپ کے خیالات کمیونٹی کی ترجیحات یا وژن سے مختلف ہو سکتے ہیں۔ وہ رائے پیش کر سکتے ہیں یا آپ کے خیال پر عمل نہ کرنے کا فیصلہ کر سکتے ہیں۔ جب کہ آپ کو بحث کرنی چاہیے اور سمجھوتے کی تلاش کرنی چاہیے، مینٹینرز کو آپ کے فیصلے کے ساتھ آپ کی مرضی سے زیادہ دیر تک رہنا ہوگا۔ اگر آپ ان کی سمت سے متفق نہیں ہیں، تو آپ ہمیشہ اپنے کانٹے پر کام کر سکتے ہیں یا اپنا پروجیکٹ شروع کر سکتے ہیں۔ -> 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_ +> 😇 _"میں مایوس ہوں کہ آپ میرے استعمال کے معاملے کی حمایت نہیں کر سکتے، لیکن جیسا کہ آپ نے وضاحت کی ہے کہ یہ صرف صارفین کے ایک معمولی حصے کو متاثر کرتا ہے، میں سمجھتا ہوں کیوں۔ سننے کا شکریہ۔"_ > -> 😢 _"Why won't you support my use case? This is unacceptable!"_ +>😢 _"آپ میرے استعمال کے معاملے کی حمایت کیوں نہیں کریں گے؟ یہ ناقابل قبول ہے!"_ -**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it. +**سب سے بڑھ کر، اسے بہترین رکھیں۔** اوپن سورس پوری دنیا کے ساتھیوں پر مشتمل ہے۔ سیاق و سباق زبانوں، ثقافتوں، جغرافیوں اور ٹائم زونز میں گم ہو جاتا ہے۔ اس کے علاوہ، تحریری موڈ کو ٹون یا موڈ بتانا مشکل بنا دیتا ہے۔ ان گفتگو میں نیک نیتی کا خیال رکھیں۔ شائستگی سے کسی آئیڈیا کو پیچھے دھکیلنا، مزید سیاق و سباق طلب کرنا، یا اپنی پوزیشن کو مزید واضح کرنا ٹھیک ہے۔ بس انٹرنیٹ کو اس سے بہتر جگہ چھوڑنے کی کوشش کریں جب آپ نے اسے پایا۔ -### Gathering context +### سیاق و سباق جمع کرنا -Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way. +کچھ بھی کرنے سے پہلے، اس بات کو یقینی بنانے کے لیے فوری جانچ پڑتال کریں کہ آپ کے خیال پر کہیں اور بات نہیں کی گئی ہے۔ پروجیکٹ کے README، مسائل (کھلے اور بند)، میلنگ لسٹ، اور اسٹیک اوور فلو کو سکیم کریں۔ آپ کو ہر چیز میں گھنٹوں گزارنے کی ضرورت نہیں ہے، لیکن چند کلیدی اصطلاحات کی فوری تلاش ایک طویل سفر طے کرتی ہے۔ -If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by doing the following: +اگر آپ کو اپنا آئیڈیا کہیں اور نہیں ملتا ہے، تو آپ آگے بڑھنے کے لیے تیار ہیں۔ اگر پروجیکٹ GitHub پر ہے، تو آپ ممکنہ طور پر درج ذیل کام کرکے بات چیت کریں گے: -* **Raising an Issue:** These are like starting a conversation or discussion -* **Pull requests** are for starting work on a solution. -* **Communication Channels:** If the project has a designated Discord, IRC, or Slack channel, consider starting a conversation or asking for clarification about your contribution. +* **مسئلہ اٹھانا:** یہ بات چیت یا بحث شروع کرنے کی طرح ہیں۔ +* **پل کی درخواستیں** حل پر کام شروع کرنے کے لیے ہیں۔ +* **مواصلاتی چینلز:** اگر پروجیکٹ کے پاس ایک نامزد ڈسکارڈ، آئی آر سی، یا سلیک چینل ہے، تو بات چیت شروع کرنے یا اپنے تعاون کے بارے میں وضاحت طلب کرنے پر غور کریں۔ -Before you open an issue or pull request, check the project's contributing docs (usually a file called CONTRIBUTING, or in the README), to see whether you need to include anything specific. For example, they may ask that you follow a template, or require that you use tests. +اس سے پہلے کہ آپ کوئی ایشو کھولیں یا درخواست کریں، پروجیکٹ کے تعاون کرنے والے دستاویزات (عام طور پر ایک فائل جسے CONTRIBUTING کہا جاتا ہے، یا README میں) چیک کریں، یہ دیکھنے کے لیے کہ آیا آپ کو کوئی خاص چیز شامل کرنے کی ضرورت ہے۔ مثال کے طور پر، وہ پوچھ سکتے ہیں کہ آپ کسی ٹیمپلیٹ کی پیروی کریں، یا آپ سے ٹیسٹ استعمال کرنے کا مطالبہ کریں۔ -If you want to make a substantial contribution, open an issue to ask before working on it. It's helpful to watch the project for a while (on GitHub, [you can click "Watch"](https://help.github.com/articles/watching-repositories/) to be notified of all conversations), and get to know community members, before doing work that might not get accepted. +اگر آپ کوئی خاطر خواہ حصہ ڈالنا چاہتے ہیں تو اس پر کام کرنے سے پہلے پوچھنے کے لیے کوئی مسئلہ کھولیں۔ اس منصوبے کو تھوڑی دیر کے لیے دیکھنا مفید ہے۔(on GitHub, [you can click "Watch"](https://help.github.com/articles/watching-repositories/) تمام بات چیت کے بارے میں مطلع کرنے کے لیے) اور ایسے کام کرنے سے پہلے جو شاید قبول نہ کیے جائیں، کمیونٹی کے اراکین کو جانیں۔ -### Opening an issue +### ایک مسئلہ کھولنا -You should usually open an issue in the following situations: +آپ کو عام طور پر درج ذیل حالات میں ایک مسئلہ کھولنا چاہئے: -* Report an error you can't solve yourself -* Discuss a high-level topic or idea (for example, community, vision or policies) -* Propose a new feature or other project idea +* ایک غلطی کی اطلاع دیں جسے آپ خود حل نہیں کرسکتے ہیں۔ +* ایک اعلیٰ سطحی موضوع یا خیال پر بحث کریں (مثال کے طور پر کمیونٹی، وژن یا پالیسیاں) +* ایک نئی خصوصیت یا دیگر پروجیکٹ آئیڈیا تجویز کریں۔ -Tips for communicating on issues: +مسائل پر بات چیت کے لیے تجاویز: -* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work. -* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work. -* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project. +*** اگر آپ کو کوئی کھلا مسئلہ نظر آتا ہے جس سے آپ نمٹنا چاہتے ہیں، تو اس مسئلے پر تبصرہ کریں تاکہ لوگوں کو معلوم ہو سکے کہ آپ اس پر ہیں۔ اس طرح، لوگوں کے آپ کے کام کی نقل تیار کرنے کا امکان کم ہوتا ہے۔ +**اگر کوئی مسئلہ کچھ دیر پہلے کھولا گیا تھا،** ممکن ہے کہ اسے کہیں اور حل کیا جا رہا ہو، یا پہلے ہی حل ہو چکا ہو، اس لیے کام شروع کرنے سے پہلے تصدیق کے لیے تبصرہ کریں۔ +**اگر آپ نے کوئی مسئلہ کھولا، لیکن بعد میں خود ہی اس کا جواب معلوم کر لیا،** لوگوں کو بتانے کے لیے اس مسئلے پر تبصرہ کریں، پھر مسئلہ کو بند کریں۔ یہاں تک کہ اس نتیجہ کی دستاویز کرنا بھی اس منصوبے میں ایک شراکت ہے۔ -### Opening a pull request +### پل کی درخواست کھولنا -You should usually open a pull request in the following situations: +آپ کو عام طور پر درج ذیل حالات میں پل کی درخواست کھولنی چاہیے: -* Submit small fixes such as a typo, a broken link or an obvious error. -* Start work on a contribution that was already asked for, or that you've already discussed, in an issue. +* چھوٹی اصلاحات جمع کروائیں جیسے کہ ٹائپنگ کی غلطی، ٹوٹا ہوا لنک یا کوئی واضح غلطی۔ +* اس شراکت پر کام شروع کریں جو پہلے ہی طلب کیا گیا تھا، یا جس پر آپ پہلے ہی کسی مسئلے میں بات کر چکے ہیں۔ -A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line or "Notes to Reviewers" sections if provided (or you can just create your own. Like this: `**## Notes to Reviewer**`). You can always add more commits later. +پل کی درخواست کو ختم شدہ کام کی نمائندگی کرنے کی ضرورت نہیں ہے۔ پل کی درخواست کو جلد کھولنا عام طور پر بہتر ہوتا ہے، تاکہ دوسرے آپ کی پیشرفت کو دیکھ سکیں یا اپنی رائے دے سکیں۔ اسے صرف ایک "ڈرافٹ" کے طور پر کھولیں یا مضمون کی لائن میں "WIP" (کام جاری ہے) کے بطور نشان زد کریں یا اگر فراہم کیا گیا ہو تو "نوٹز ٹو ریویورز" سیکشنز (یا آپ صرف اپنا بنا سکتے ہیں۔ اس طرح: `**## جائزہ لینے والے کے لیے نوٹس**`)۔ آپ بعد میں ہمیشہ مزید کمٹ شامل کر سکتے ہیں۔ -If the project is on GitHub, here's how to submit a pull request: +اگر پروجیکٹ GitHub پر ہے تو، یہاں پل کی درخواست جمع کرنے کا طریقہ ہے: -* **[Fork the repository](https://guides.github.com/activities/forking/)** and clone it locally. Connect your local to the original "upstream" repository by adding it as a remote. Pull in changes from "upstream" often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. (See more detailed instructions [here](https://help.github.com/articles/syncing-a-fork/).) -* **[Create a branch](https://guides.github.com/introduction/flow/)** for your edits. -* **Reference any relevant issues** or supporting documentation in your PR (for example, "Closes #37.") -* **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request. -* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. It's important to make sure your changes don't break the existing project. -* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future. +* **[Fork the repository](https://guides.github.com/activities/forking/)** اور اسے مقامی طور پر کلون کریں۔ اپنے مقامی کو ریموٹ کے طور پر شامل کرکے اصل "اپ اسٹریم" ریپوزٹری سے جوڑیں۔ "اپ اسٹریم" سے اکثر تبدیلیاں کریں تاکہ آپ اپ ٹو ڈیٹ رہیں تاکہ جب آپ اپنی پل کی درخواست جمع کرائیں تو انضمام کے تنازعات کا امکان کم ہوگا۔ (مزید تفصیلی ہدایات دیکھیں[here](https://help.github.com/articles/syncing-a-fork/).) +* **[Create a branch](https://guides.github.com/introduction/flow/)** آپ کی ترامیم کے لیے۔ +* **کسی بھی متعلقہ مسائل کا حوالہ دیں** یا اپنے PR میں معاون دستاویزات (مثال کے طور پر، "کلوز #37۔") +*** اگر آپ کی تبدیلیوں میں HTML/CSS میں فرق شامل ہے تو اس سے پہلے اور بعد کے اسکرین شاٹس شامل کریں۔ تصاویر کو اپنی پل کی درخواست کے باڈی میں گھسیٹیں اور چھوڑیں۔ +* **اپنی تبدیلیوں کی جانچ کریں!** اپنی تبدیلیاں کسی بھی موجودہ ٹیسٹ کے خلاف چلائیں اگر وہ موجود ہیں اور ضرورت پڑنے پر نئی بنائیں۔ یہ یقینی بنانا ضروری ہے کہ آپ کی تبدیلیاں موجودہ پروجیکٹ کو نہ توڑیں۔ +**پروجیکٹ کے انداز میں اپنا حصہ ڈالیں** اپنی بہترین صلاحیتوں سے۔ اس کا مطلب ہو سکتا ہے کہ انڈینٹ، نیم کالون یا تبصرے آپ کے اپنے ذخیرے میں استعمال کرنے سے مختلف ہوں، لیکن دیکھ بھال کرنے والے کے لیے ضم کرنا، دوسروں کو مستقبل میں سمجھنا اور برقرار رکھنا آسان بناتا ہے۔ -If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey. +اگر یہ آپ کی پہلی پل ریکوئسٹ ہے تو، [Make a Pull Request](http://makeapullrequest.com/) کو دیکھیں، جسے @kentcdodds نے واک تھرو ویڈیو ٹیوٹوریل کے طور پر بنایا ہے۔ آپ @Roshanjossey کی تخلیق کردہ [First Contributions](https://github.com/Roshanjossey/first-contributions) ریپوزٹری میں پل کی درخواست کرنے کی مشق بھی کر سکتے ہیں۔ -## What happens after you submit your contribution +## آپ اپنا تعاون جمع کروانے کے بعد کیا ہوتا ہے۔ -Before we start celebrating, one of the following will happen after you submit your contribution: +اس سے پہلے کہ ہم جشن منانا شروع کریں، درج ذیل میں سے ایک آپ کے تعاون جمع کرانے کے بعد ہو گا: -### 😭 You don't get a response +### 😭 آپ کو کوئی جواب نہیں ملتا -Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response. +امید ہے کہ آپ نے شراکت کرنے سے پہلے [سرگرمی کے آثار کے لیے پروجیکٹ کو چیک کیا ہے](#a-checklist-before-you-contribute)۔ ایک فعال پروجیکٹ پر بھی، تاہم، یہ ممکن ہے کہ آپ کے تعاون کو جواب نہ ملے۔ -If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread. +اگر آپ کو ایک ہفتے سے زیادہ وقت میں کوئی جواب نہیں ملا ہے تو، اسی تھریڈ میں شائستگی سے جواب دینا، کسی سے جائزہ لینے کے لیے کہنا مناسب ہے۔ اگر آپ اپنے تعاون کا جائزہ لینے کے لیے صحیح شخص کا نام جانتے ہیں، تو آپ اس تھریڈ میں ان کا @-ذکر کر سکتے ہیں۔ -**Don't reach out to that person privately**; remember that public communication is vital to open source projects. +**اس شخص سے نجی طور پر رابطہ نہ کریں**؛ یاد رکھیں کہ اوپن سورس پروجیکٹس کے لیے عوامی رابطہ بہت ضروری ہے۔ -If you give a polite reminder and still do not receive a response, it's possible that nobody will ever respond. It's not a great feeling, but don't let that discourage you! 😄 There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive. +اگر آپ شائستہ یاد دہانی دیتے ہیں اور پھر بھی جواب نہیں ملتا ہے، تو یہ ممکن ہے کہ کوئی بھی جواب نہ دے۔ یہ ایک اچھا احساس نہیں ہے، لیکن اس سے آپ کی حوصلہ شکنی نہ ہونے دیں! 😄 آپ کو جواب نہ ملنے کی بہت سی ممکنہ وجوہات ہیں، بشمول ذاتی حالات جو آپ کے قابو سے باہر ہو سکتے ہیں۔ کوئی دوسرا پروجیکٹ یا تعاون کرنے کا طریقہ تلاش کرنے کی کوشش کریں۔ اگر کچھ بھی ہے تو، یہ ایک اچھی وجہ ہے کہ کمیونٹی کے دیگر اراکین کے مشغول اور جوابدہ ہونے سے پہلے اپنا حصہ ڈالنے میں زیادہ وقت نہ لگائیں۔ -### 🚧 Someone requests changes to your contribution +### 🚧 کوئی آپ کے تعاون میں تبدیلی کی درخواست کرتا ہے۔ -It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code. +یہ عام بات ہے کہ آپ سے اپنے تعاون میں تبدیلیاں کرنے کے لیے کہا جائے گا، چاہے وہ آپ کے خیال کے دائرہ کار پر رائے ہو، یا آپ کے کوڈ میں تبدیلیاں ہوں۔ -When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it. A good example of this would be [the feedback that another contributor has given to @a-m-lamb on their pull request to Codecademy's Docs](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286). +جب کوئی تبدیلی کی درخواست کرتا ہے، تو جوابدہ بنیں۔ انہوں نے آپ کے تعاون کا جائزہ لینے کے لیے وقت نکالا ہے۔ PR کھولنا اور دور چلنا بری شکل ہے۔ اگر آپ تبدیلیاں کرنا نہیں جانتے ہیں تو مسئلہ کی تحقیق کریں، پھر اگر آپ کو ضرورت ہو تو مدد طلب کریں۔ اس کی ایک اچھی مثال یہ ہوگی [وہ تاثرات جو ایک اور تعاون کنندہ نے @a-m-lamb کو Codecademy's Docs میں اپنی پل کی درخواست پر دیا ہے](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286)۔ -If you don't have time to work on the issue anymore due to reasons such as the conversation has been going on for months, and your circumstances have changed or you're unable to find a solution, let the maintainer know so that they can open the issue for someone else, like [@RitaDee did for an issue at OpenSauced's app repository](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346). +اگر مہینوں سے بات چیت جاری رہنے جیسی وجوہات کی بنا پر آپ کے پاس اس مسئلے پر مزید کام کرنے کا وقت نہیں ہے، اور آپ کے حالات بدل گئے ہیں یا آپ کوئی حل تلاش کرنے سے قاصر ہیں، تو دیکھ بھال کرنے والے کو بتائیں تاکہ وہ کسی اور کے لیے مسئلہ کھولیں، جیسے [@RitaDee نے OpenSauced's app repository میں کسی مسئلے کے لیے کیا](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346)۔ -### 👎 Your contribution doesn't get accepted +### 👎 آپ کا تعاون قبول نہیں کیا جائے گا۔ -Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree! +آپ کا تعاون آخر میں قبول کیا جا سکتا ہے یا نہیں۔ امید ہے کہ آپ نے پہلے ہی اس میں زیادہ کام نہیں کیا ہوگا۔ اگر آپ کو یقین نہیں ہے کہ اسے کیوں قبول نہیں کیا گیا، تو دیکھ بھال کرنے والے سے رائے اور وضاحت طلب کرنا بالکل مناسب ہے۔ تاہم، بالآخر، آپ کو اس بات کا احترام کرنے کی ضرورت ہوگی کہ یہ ان کا فیصلہ ہے۔ جھگڑا نہ کریں اور دشمنی نہ کریں۔ اگر آپ متفق نہیں ہیں تو آپ کا ہمیشہ خیرمقدم ہے اور اپنے ورژن پر کام کریں! -### 🎉 Your contribution gets accepted +### 🎉 آپ کا تعاون قبول ہو جاتا ہے۔ -Hooray! You've successfully made an open source contribution! +ہورے! آپ نے کامیابی کے ساتھ اوپن سورس کا تعاون کیا ہے! -## You did it! 🎉 +## تم نے یہ کیا! 🎉 -Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time. +چاہے آپ نے اپنا پہلا اوپن سورس تعاون کیا ہو، یا آپ تعاون کرنے کے نئے طریقے تلاش کر رہے ہوں، ہمیں امید ہے کہ آپ کارروائی کرنے کے لیے متاثر ہوں گے۔ یہاں تک کہ اگر آپ کا تعاون قبول نہیں کیا گیا تھا، تب بھی جب کوئی مینٹینر آپ کی مدد کرنے کی کوشش کرتا ہے تو شکریہ کہنا نہ بھولیں۔ اوپن سورس آپ جیسے لوگوں نے بنایا ہے: ایک مسئلہ، پل کی درخواست، تبصرہ، یا ایک وقت میں ہائی فائیو۔ From 9c07173a19f11274f7114fa44a6155218dbd2396 Mon Sep 17 00:00:00 2001 From: Areebey Date: Sat, 28 Oct 2023 05:36:15 +0500 Subject: [PATCH 09/10] added hyper text file as well. --- _articles/ur/index.html | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 _articles/ur/index.html diff --git a/_articles/ur/index.html b/_articles/ur/index.html new file mode 100644 index 00000000000..a129cd9965f --- /dev/null +++ b/_articles/ur/index.html @@ -0,0 +1,6 @@ +--- +layout: index +title: اوپن سورس گائیڈز +lang: ur +permalink: /ur/ +--- From 9c266e821cda3b3a1f47c0c5783ff6a2adb74a10 Mon Sep 17 00:00:00 2001 From: Areebey Date: Mon, 30 Oct 2023 02:52:26 +0500 Subject: [PATCH 10/10] completed, all files convert into urdu sucessfully --- _articles/ur/leadership-and-governance.md | 156 ++++++++ _articles/ur/legal.md | 158 ++++++++ ...ing-balance-for-open-source-maintainers.md | 226 +++++++++++ _articles/ur/metrics.md | 131 +++++++ _articles/ur/starting-a-project.md | 357 ++++++++++++++++++ 5 files changed, 1028 insertions(+) create mode 100644 _articles/ur/leadership-and-governance.md create mode 100644 _articles/ur/legal.md create mode 100644 _articles/ur/maintaining-balance-for-open-source-maintainers.md create mode 100644 _articles/ur/metrics.md create mode 100644 _articles/ur/starting-a-project.md diff --git a/_articles/ur/leadership-and-governance.md b/_articles/ur/leadership-and-governance.md new file mode 100644 index 00000000000..0a466c377a7 --- /dev/null +++ b/_articles/ur/leadership-and-governance.md @@ -0,0 +1,156 @@ +--- +lang: en +title: قیادت اور گورننس +description: بڑھتے ہوئے اوپن سورس پروجیکٹس فیصلے کرنے کے رسمی اصولوں سے فائدہ اٹھا سکتے ہیں۔ +class: leadership +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +--- + +## اپنے بڑھتے ہوئے پروجیکٹ کے لیے گورننس کو سمجھنا + +آپ کا پروجیکٹ بڑھ رہا ہے، لوگ مصروف ہیں، اور آپ اس چیز کو جاری رکھنے کے لیے پرعزم ہیں۔ اس مرحلے پر، آپ سوچ رہے ہوں گے کہ اپنے ورک فلو میں باقاعدہ پروجیکٹ کے شراکت داروں کو کیسے شامل کیا جائے، چاہے یہ کسی کو کمٹٹ رسائی دے رہا ہو یا کمیونٹی کے مباحثوں کو حل کر رہا ہو۔ اگر آپ کے سوالات ہیں، تو ہمارے پاس جوابات ہیں۔ + +## اوپن سورس پروجیکٹس میں استعمال ہونے والے رسمی کرداروں کی کیا مثالیں ہیں؟ + +بہت سے منصوبے شراکت داروں کے کردار اور شناخت کے لیے ایک جیسے ڈھانچے کی پیروی کرتے ہیں۔ + +ان کرداروں کا اصل میں کیا مطلب ہے، اگرچہ، مکمل طور پر آپ پر منحصر ہے۔ یہاں چند قسم کے کردار ہیں جنہیں آپ پہچان سکتے ہیں: + +*** دیکھ بھال کرنے والا** +**مضمون کنندہ** +**کمیٹر** + +**کچھ پروجیکٹس کے لیے، "مینٹینرز"** پروجیکٹ میں واحد لوگ ہوتے ہیں جن کے پاس کمٹٹ رسائی ہوتی ہے۔ دوسرے پروجیکٹس میں، وہ صرف وہ لوگ ہیں جو README میں دیکھ بھال کرنے والے کے طور پر درج ہیں۔ + +ضروری نہیں کہ مینٹینر کوئی ایسا شخص ہو جو آپ کے پروجیکٹ کے لیے کوڈ لکھتا ہو۔ یہ کوئی ایسا شخص ہو سکتا ہے جس نے آپ کے پروجیکٹ کی بشارت کے لیے بہت زیادہ کام کیا ہو، یا تحریری دستاویزات جس نے پروجیکٹ کو دوسروں کے لیے زیادہ قابل رسائی بنایا ہو۔ اس سے قطع نظر کہ وہ روزانہ کیا کرتے ہیں، ایک مینٹینر شاید وہ ہوتا ہے جو پروجیکٹ کی سمت پر ذمہ داری محسوس کرتا ہے اور اسے بہتر بنانے کے لیے پرعزم ہے۔ + +**ایک "مطالعہ کرنے والا" کوئی بھی ہو سکتا ہے** جو کسی مسئلے پر تبصرہ کرتا ہے یا پل کی درخواست کرتا ہے، وہ لوگ جو پروجیکٹ میں اہمیت کا اضافہ کرتے ہیں (چاہے یہ ٹریجنگ ایشوز ہوں، کوڈ لکھیں، یا ایونٹس کا اہتمام کریں) یا ضم شدہ پل کی درخواست والا کوئی بھی ہو (شاید شراکت دار کی سب سے تنگ تعریف)۔ + + + +** اصطلاح "کامیٹر"** کا استعمال کمٹ رسائی کو الگ کرنے کے لیے کیا جا سکتا ہے، جو کہ ایک مخصوص قسم کی ذمہ داری ہے، شراکت کی دیگر اقسام سے۔ + +جب کہ آپ اپنے پروجیکٹ کے کردار کو اپنی مرضی کے مطابق بیان کر سکتے ہیں، شراکت کی مزید اقسام کی حوصلہ افزائی کے لیے [وسیع تر تعریفیں استعمال کرنے پر غور کریں](../how-to-contribute/#what-it-means-to-contribute)۔ آپ قائدانہ کرداروں کا استعمال ان لوگوں کو باضابطہ طور پر پہچاننے کے لیے کر سکتے ہیں جنہوں نے آپ کے پراجیکٹ میں نمایاں شراکت کی ہے، چاہے ان کی تکنیکی مہارت کچھ بھی ہو۔ + + + +## میں ان قائدانہ کرداروں کو کیسے باضابطہ بناؤں؟ + +آپ کے قائدانہ کرداروں کو باضابطہ بنانے سے لوگوں کو ملکیت کا احساس کرنے میں مدد ملتی ہے اور وہ کمیونٹی کے دیگر ممبران کو بتاتے ہیں کہ کس کی مدد کرنا ہے۔ + +ایک چھوٹے پروجیکٹ کے لیے، لیڈروں کو نامزد کرنا اتنا ہی آسان ہو سکتا ہے جتنا کہ آپ کے README یا CONTRIBUTORS ٹیکسٹ فائل میں ان کے نام شامل کرنا۔ + +کسی بڑے پروجیکٹ کے لیے، اگر آپ کے پاس ویب سائٹ ہے، تو ایک ٹیم کا صفحہ بنائیں یا وہاں اپنے پروجیکٹ لیڈرز کی فہرست بنائیں۔ مثال کے طور پر، [Postgres](https://github.com/postgres/postgres/) کا ایک [جامع ٹیم صفحہ](https://www.postgresql.org/community/contributors/) ہے جس میں ہر تعاون کنندہ کے مختصر پروفائلز ہیں۔ + +اگر آپ کے پروجیکٹ میں بہت فعال شراکت دار کمیونٹی ہے، تو آپ دیکھ بھال کرنے والوں کی ایک "بنیادی ٹیم" تشکیل دے سکتے ہیں، یا یہاں تک کہ ایسے لوگوں کی ذیلی کمیٹیاں بھی تشکیل دے سکتے ہیں جو مختلف ایشو ایریاز (مثال کے طور پر، سیکیورٹی، ایشو ٹرائجنگ، یا کمیونٹی کنڈکٹ) کی ملکیت حاصل کرتے ہیں۔ لوگوں کو انہیں تفویض کرنے کے بجائے خود کو منظم کرنے اور ان کرداروں کے لیے رضاکارانہ طور پر کام کرنے دیں۔ + + + +لیڈرشپ ٹیمیں ایک نامزد چینل (جیسے IRC پر) بنانا چاہتی ہیں یا پروجیکٹ پر بات کرنے کے لیے باقاعدگی سے مل سکتی ہیں (جیسے Gitter یا Google Hangout پر)۔ آپ ان ملاقاتوں کو عوامی بھی بنا سکتے ہیں تاکہ دوسرے لوگ سن سکیں۔ [ککڑی-روبی](https://github.com/cucumber/cucumber-ruby)، مثال کے طور پر، [ہر ہفتے دفتری اوقات کی میزبانی کرتا ہے](https://github.com/cucumber/cucumber-ruby/blob/HEAD/ CONTRIBUTING.md#talking-with-other-devs)۔ + +ایک بار جب آپ قائدانہ کردار قائم کر لیں، تو یہ دستاویز کرنا نہ بھولیں کہ لوگ انہیں کیسے حاصل کر سکتے ہیں! ایک واضح عمل قائم کریں کہ کس طرح کوئی آپ کے پروجیکٹ میں مینٹینر بن سکتا ہے یا ذیلی کمیٹی میں شامل ہو سکتا ہے، اور اسے اپنی GOVERNANCE.md میں لکھیں۔ + +ٹولز جیسے [Vossibility](https://github.com/icecrime/vossibility-stack) آپ کو عوامی طور پر ٹریک کرنے میں مدد کر سکتے ہیں کہ پروجیکٹ میں کون تعاون کر رہا ہے (یا نہیں کر رہا)۔ اس معلومات کو دستاویزی بنانا کمیونٹی کے اس تاثر سے بچتا ہے کہ دیکھ بھال کرنے والے ایک گروہ ہیں جو اپنے فیصلے نجی طور پر کرتے ہیں۔ + +آخر میں، اگر آپ کا پروجیکٹ GitHub پر ہے، تو اپنے پروجیکٹ کو اپنے ذاتی اکاؤنٹ سے کسی تنظیم میں منتقل کرنے اور کم از کم ایک بیک اپ ایڈمن کو شامل کرنے پر غور کریں۔ [گٹ ہب آرگنائزیشنز](https://help.github.com/articles/creating-a-new-organization-account/) اجازتوں اور متعدد ذخیروں کا نظم کرنا اور [مشترکہ ملکیت] کے ذریعے اپنے پروجیکٹ کی میراث کی حفاظت کرنا آسان بناتی ہیں۔ /building-community/#share-ownership-of-your-project)۔ + +## میں کب کسی کو کمٹ کی رسائی دوں؟ + +کچھ لوگوں کا خیال ہے کہ آپ کو ہر اس شخص تک رسائی دینا چاہئے جو تعاون کرتا ہے۔ ایسا کرنے سے زیادہ لوگوں کو آپ کے پروجیکٹ کی ملکیت محسوس کرنے کی ترغیب مل سکتی ہے۔ + +دوسری طرف، خاص طور پر بڑے، زیادہ پیچیدہ منصوبوں کے لیے، آپ صرف ان لوگوں تک رسائی دینا چاہیں گے جنہوں نے اپنی وابستگی کا مظاہرہ کیا ہے۔ ایسا کرنے کا کوئی صحیح طریقہ نہیں ہے - وہ کریں جو آپ کو سب سے زیادہ آرام دہ بناتا ہے! + +اگر آپ کا پروجیکٹ GitHub پر ہے، تو آپ [protected branches](https://help.github.com/articles/about-protected-branches/) کا استعمال کر سکتے ہیں تاکہ یہ انتظام کیا جا سکے کہ کون کسی خاص برانچ کو دھکیل سکتا ہے، اور کن حالات میں۔ + + + +## اوپن سورس پروجیکٹس کے لیے کچھ عام گورننس ڈھانچے کیا ہیں؟ + +اوپن سورس پروجیکٹس کے ساتھ تین مشترکہ گورننس ڈھانچے وابستہ ہیں۔ + +* **BDFL:** BDFL کا مطلب ہے "زندگی کے لیے فلاحی آمر"۔ اس ڈھانچے کے تحت، ایک شخص (عام طور پر پروجیکٹ کا ابتدائی مصنف) تمام بڑے پروجیکٹ فیصلوں پر حتمی رائے رکھتا ہے۔ [Python](https://github.com/python) ایک بہترین مثال ہے۔ چھوٹے منصوبے شاید ڈیفالٹ کے طور پر BDFL ہوتے ہیں، کیونکہ صرف ایک یا دو مینٹینرز ہوتے ہیں۔ ایک پروجیکٹ جس کی ابتدا کسی کمپنی سے ہوئی ہو وہ بھی BDFL کے زمرے میں آ سکتی ہے۔ + +* **Meritocracy:** ** (نوٹ: اصطلاح "میریٹوکریسی" کچھ کمیونٹیز کے لیے منفی معنی رکھتی ہے اور اس کی ایک [پیچیدہ سماجی اور سیاسی تاریخ] ہے (http://geekfeminism.wikia.com/wiki/Meritocracy)) ** میرٹ کریسی کے تحت، پراجیکٹ کے فعال شراکت داروں (جو "میرٹ" کا مظاہرہ کرتے ہیں) کو فیصلہ سازی کا باقاعدہ کردار دیا جاتا ہے۔ فیصلے عام طور پر خالص ووٹنگ اتفاق رائے کی بنیاد پر کیے جاتے ہیں۔ میرٹوکیسی کے تصور کا آغاز [Apache Foundation](https://www.apache.org/) نے کیا تھا۔ [تمام اپاچی پروجیکٹس](https://www.apache.org/index.html#projects-list) قابلیت ہیں۔ شراکتیں صرف اپنی نمائندگی کرنے والے افراد کی طرف سے کی جا سکتی ہیں، کمپنی کی طرف سے نہیں۔ + +* **لبرل شراکت:** ایک لبرل کنٹریبیوشن ماڈل کے تحت، سب سے زیادہ کام کرنے والے لوگوں کو سب سے زیادہ بااثر تسلیم کیا جاتا ہے، لیکن یہ موجودہ کام پر مبنی ہے نہ کہ تاریخی شراکتوں پر۔ منصوبے کے بڑے فیصلے خالص ووٹ کی بجائے اتفاق رائے کے حصول کے عمل (بڑی شکایات پر بات چیت) کی بنیاد پر کیے جاتے ہیں، اور زیادہ سے زیادہ کمیونٹی کے نقطہ نظر کو شامل کرنے کی کوشش کرتے ہیں۔ لبرل کنٹری بیوشن ماڈل استعمال کرنے والے پروجیکٹس کی مشہور مثالوں میں [Node.js](https://foundation.nodejs.org/) اور [Rust](https://www.rust-lang.org/) شامل ہیں۔ + +آپ کو کون سا استعمال کرنا چاہئے؟ یہ آپ پر منحصر ہے! ہر ماڈل کے فوائد اور تجارتی تعلقات ہیں۔ اور اگرچہ وہ پہلے تو بالکل مختلف لگ سکتے ہیں، تینوں ماڈلز میں ان سے کہیں زیادہ مشترک ہے۔ اگر آپ ان میں سے کسی ایک ماڈل کو اپنانے میں دلچسپی رکھتے ہیں، تو یہ ٹیمپلیٹس دیکھیں: + +* [BDFL ماڈل ٹیمپلیٹ](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) +* [میریٹوکریسی ماڈل ٹیمپلیٹ](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) +* [Node.js کی لبرل شراکت کی پالیسی](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) + +## جب میں اپنا پروجیکٹ شروع کرتا ہوں تو کیا مجھے گورننس کے دستاویزات کی ضرورت ہے؟ + +اپنے پروجیکٹ کی گورننس کو لکھنے کا کوئی صحیح وقت نہیں ہے، لیکن جب آپ نے اپنی کمیونٹی کی حرکیات کو ختم ہوتے دیکھا ہے تو اس کی وضاحت کرنا بہت آسان ہے۔ اوپن سورس گورننس کے بارے میں سب سے بہترین (اور سب سے مشکل) حصہ یہ ہے کہ اس کی تشکیل کمیونٹی نے کی ہے! + +کچھ ابتدائی دستاویزات لازمی طور پر آپ کے پروجیکٹ کی گورننس میں حصہ ڈالیں گی، تاہم، اس لیے لکھنا شروع کریں جو آپ کر سکتے ہیں۔ مثال کے طور پر، آپ رویے کے لیے واضح توقعات کی وضاحت کر سکتے ہیں، یا آپ کے تعاون کنندہ کا عمل کیسے کام کرتا ہے، یہاں تک کہ آپ کے پروجیکٹ کے آغاز پر بھی۔ + +اگر آپ اوپن سورس پروجیکٹ شروع کرنے والی کمپنی کا حصہ ہیں، تو لانچ کرنے سے پہلے اس بارے میں ایک اندرونی بات چیت کرنے کے قابل ہے کہ آپ کی کمپنی اس پروجیکٹ کو آگے بڑھنے کے بارے میں کیسے برقرار رکھنے اور فیصلے کرنے کی توقع رکھتی ہے۔ آپ عوامی طور پر کسی خاص بات کی وضاحت بھی کرنا چاہیں گے کہ آپ کی کمپنی اس منصوبے کے ساتھ کس طرح شامل ہوگی (یا نہیں کرے گی!)۔ + + + +## اگر کارپوریٹ ملازمین چندہ جمع کرنا شروع کردیں تو کیا ہوگا؟ + +کامیاب اوپن سورس پروجیکٹس کو بہت سے لوگوں اور کمپنیوں کے ذریعہ استعمال کیا جاتا ہے، اور کچھ کمپنیاں آخر کار آمدنی کے سلسلے کو پروجیکٹ سے منسلک کرسکتی ہیں۔ مثال کے طور پر، ایک کمپنی تجارتی سروس کی پیشکش میں پروجیکٹ کے کوڈ کو ایک جزو کے طور پر استعمال کر سکتی ہے۔ + +جیسے جیسے اس پروجیکٹ کا وسیع پیمانے پر استعمال ہوتا جاتا ہے، اس میں مہارت رکھنے والے افراد کی مانگ میں اضافہ ہوتا جاتا ہے - ہو سکتا ہے آپ ان میں سے ایک ہو! - اور کبھی کبھی اس منصوبے میں کام کرنے کے لیے ادائیگی کی جائے گی۔ + +تجارتی سرگرمیوں کو معمول کے مطابق اور ترقی کی توانائی کا ایک اور ذریعہ سمجھنا ضروری ہے۔ بامعاوضہ ڈویلپرز کو بلا معاوضہ ڈیولپرز کے ساتھ خاص سلوک نہیں کرنا چاہیے، یقیناً۔ ہر شراکت کو اس کی تکنیکی خوبیوں پر جانچنا چاہیے۔ تاہم، لوگوں کو تجارتی سرگرمی میں مشغول ہونے میں آرام محسوس کرنا چاہیے، اور کسی خاص اضافہ یا خصوصیت کے حق میں بحث کرتے وقت اپنے استعمال کے معاملات بتاتے ہوئے آرام محسوس کرنا چاہیے۔ + +"کمرشل" مکمل طور پر "اوپن سورس" کے ساتھ مطابقت رکھتا ہے۔ "تجارتی" کا مطلب صرف یہ ہے کہ کہیں پیسہ شامل ہے - یہ کہ سافٹ ویئر کامرس میں استعمال ہوتا ہے، جس کا امکان بڑھتا جا رہا ہے جیسے جیسے کسی پروجیکٹ کو اپنایا جاتا ہے۔ (جب اوپن سورس سافٹ ویئر کو کسی غیر اوپن سورس پروڈکٹ کے حصے کے طور پر استعمال کیا جاتا ہے، تو مجموعی پروڈکٹ اب بھی "مالیداری" سافٹ ویئر ہے، حالانکہ اوپن سورس کی طرح، یہ تجارتی یا غیر تجارتی مقاصد کے لیے استعمال کیا جا سکتا ہے۔) + +کسی اور کی طرح، تجارتی طور پر حوصلہ افزائی کرنے والے ڈویلپرز اپنے تعاون کے معیار اور مقدار کے ذریعے پروجیکٹ میں اثر و رسوخ حاصل کرتے ہیں۔ ظاہر ہے، ایک ڈویلپر جسے اس کے وقت کے لیے ادائیگی کی جاتی ہے وہ کسی ایسے شخص سے زیادہ کام کرنے کے قابل ہو سکتا ہے جسے ادا نہیں کیا جاتا، لیکن یہ ٹھیک ہے: ادائیگی بہت سے ممکنہ عوامل میں سے صرف ایک ہے جو متاثر کر سکتی ہے کہ کوئی شخص کتنا کرتا ہے۔ اپنے پراجیکٹ کے مباحثوں کو شراکت پر مرکوز رکھیں، نہ کہ ان بیرونی عوامل پر جو لوگوں کو یہ تعاون کرنے کے قابل بناتے ہیں۔ + +## کیا مجھے اپنے پروجیکٹ کی حمایت کے لیے کسی قانونی ادارے کی ضرورت ہے؟ + +آپ کو اپنے اوپن سورس پروجیکٹ کو سپورٹ کرنے کے لیے کسی قانونی ادارے کی ضرورت نہیں ہے جب تک کہ آپ رقم ہینڈل نہ کر رہے ہوں۔ + +مثال کے طور پر، اگر آپ تجارتی کاروبار بنانا چاہتے ہیں، تو آپ C Corp یا LLC (اگر آپ امریکہ میں مقیم ہیں) قائم کرنا چاہیں گے۔ اگر آپ صرف اپنے اوپن سورس پروجیکٹ سے متعلق کنٹریکٹ کا کام کر رہے ہیں، تو آپ ایک واحد مالک کے طور پر رقم قبول کر سکتے ہیں، یا ایک LLC قائم کر سکتے ہیں (اگر آپ امریکہ میں مقیم ہیں)۔ + +اگر آپ اپنے اوپن سورس پروجیکٹ کے لیے عطیات قبول کرنا چاہتے ہیں، تو آپ عطیہ کا بٹن ترتیب دے سکتے ہیں (مثال کے طور پر پے پال یا اسٹرائپ کا استعمال کرتے ہوئے)، لیکن اس رقم پر ٹیکس کی کٹوتی نہیں ہوگی جب تک کہ آپ اہل غیر منفعتی (501c3، اگر آپ امریکہ میں ہیں)۔ + +بہت سے پروجیکٹس غیر منفعتی تنظیم قائم کرنے کی پریشانی سے گزرنا نہیں چاہتے ہیں، اس لیے وہ اس کے بجائے ایک غیر منفعتی مالی کفیل تلاش کرتے ہیں۔ ایک مالی کفیل آپ کی طرف سے عطیات قبول کرتا ہے، عام طور پر عطیہ کے فیصد کے بدلے میں۔ [سافٹ ویئر فریڈم کنزروینسی](https://sfconservancy.org/)، [Apache Foundation](https://www.apache.org/)، [Eclipse Foundation](https://eclipse.org/org/foundation/ )، [Linux Foundation](https://www.linuxfoundation.org/projects) اور [Open Collective](https://opencollective.com/opensource) ان تنظیموں کی مثالیں ہیں جو اوپن سورس پروجیکٹس کے لیے مالی کفیل کے طور پر کام کرتی ہیں۔ + + + +اگر آپ کا پروجیکٹ کسی مخصوص زبان یا ماحولیاتی نظام کے ساتھ قریب سے وابستہ ہے، تو وہاں ایک متعلقہ سافٹ ویئر فاؤنڈیشن بھی ہو سکتی ہے جس کے ساتھ آپ کام کر سکتے ہیں۔ مثال کے طور پر، [Python Software Foundation](https://www.python.org/psf/) [PyPI](https://pypi.org/)، Python پیکیج مینیجر، اور [Node.js فاؤنڈیشن](https://foundation.nodejs.org/) ایک نوڈ پر مبنی فریم ورک [Express.js](https://expressjs.com/) کو سپورٹ کرنے میں مدد کرتا ہے۔ diff --git a/_articles/ur/legal.md b/_articles/ur/legal.md new file mode 100644 index 00000000000..be95b2eea9a --- /dev/null +++ b/_articles/ur/legal.md @@ -0,0 +1,158 @@ +--- +lang: en +title: اوپن سورس کا قانونی پہلو +description: ہر وہ چیز جو آپ نے کبھی اوپن سورس کے قانونی پہلو کے بارے میں سوچا ہو، اور کچھ چیزیں جو آپ نے نہیں سوچیں۔ +class: legal +order: 10 +image: /assets/images/cards/legal.png +related: + - contribute + - leadership +--- + +## اوپن سورس کے قانونی مضمرات کو سمجھنا + +اپنے تخلیقی کام کو دنیا کے ساتھ بانٹنا ایک دلچسپ اور فائدہ مند تجربہ ہو سکتا ہے۔ اس کا مطلب قانونی چیزوں کا ایک گروپ بھی ہو سکتا ہے جن کے بارے میں آپ کو معلوم نہیں تھا کہ آپ کو فکر کرنے کی ضرورت ہے۔ شکر ہے، آپ کو شروع سے شروع کرنے کی ضرورت نہیں ہے۔ ہم نے آپ کی قانونی ضروریات کو پورا کر لیا ہے۔ (اس سے پہلے کہ آپ کھودیں، ہمارا [ڈس کلیمر](/notices/) کو ضرور پڑھیں۔) + +## لوگ اوپن سورس کے قانونی پہلو کی اتنی پرواہ کیوں کرتے ہیں؟ + +خوشی ہوئی کہ آپ نے پوچھا! جب آپ کوئی تخلیقی کام کرتے ہیں (جیسے تحریر، گرافکس، یا کوڈ)، تو وہ کام بطور ڈیفالٹ خصوصی کاپی رائٹ کے تحت ہوتا ہے۔ یعنی، قانون یہ فرض کرتا ہے کہ آپ کے کام کے مصنف کے طور پر، آپ کو اس بارے میں کچھ کہنا ہے کہ دوسرے اس کے ساتھ کیا کر سکتے ہیں۔ + +عام طور پر، اس کا مطلب ہے کہ کوئی اور آپ کے کام کو ٹیک ڈاؤن، شیک ڈاؤن، یا قانونی چارہ جوئی کے خطرے کے بغیر استعمال، کاپی، تقسیم یا ترمیم نہیں کر سکتا۔ + +اوپن سورس ایک غیر معمولی صورت حال ہے، تاہم، مصنف کو توقع ہے کہ دوسرے اس کام کو استعمال کریں گے، اس میں ترمیم کریں گے اور اس کا اشتراک کریں گے۔ لیکن چونکہ قانونی ڈیفالٹ اب بھی خصوصی کاپی رائٹ ہے، آپ کو ایک لائسنس کی ضرورت ہے جو ان اجازتوں کو واضح طور پر بیان کرے۔ + +اگر آپ اوپن سورس لائسنس کا اطلاق نہیں کرتے ہیں، تو ہر وہ شخص جو آپ کے پروجیکٹ میں تعاون کرتا ہے اپنے کام کا خصوصی کاپی رائٹ ہولڈر بن جاتا ہے۔ اس کا مطلب ہے کہ کوئی بھی اپنے تعاون کو استعمال، کاپی، تقسیم یا ترمیم نہیں کر سکتا -- اور یہ کہ "کوئی بھی" آپ کو شامل نہیں کرتا ہے۔ + +آخر میں، آپ کے پروجیکٹ میں لائسنس کی ضروریات کے ساتھ انحصار ہوسکتا ہے جس سے آپ واقف نہیں تھے۔ آپ کے پروجیکٹ کی کمیونٹی، یا آپ کے آجر کی پالیسیاں، آپ کے پروجیکٹ کو مخصوص اوپن سورس لائسنس استعمال کرنے کی بھی ضرورت پڑ سکتی ہے۔ ہم ذیل میں ان حالات کا احاطہ کریں گے۔ + +## کیا عوامی GitHub پروجیکٹ اوپن سورس ہیں؟ + +جب آپ GitHub پر [ایک نیا پروجیکٹ بناتے ہیں](https://help.github.com/articles/creating-a-new-repository/) تو آپ کے پاس ریپوزٹری کو **نجی** یا **عوامی بنانے کا اختیار ہوتا ہے۔ ** + +![ذخیرہ بنائیں](/assets/images/legal/repo-create-name.png) + +**اپنے GitHub پروجیکٹ کو عوامی بنانا اپنے پروجیکٹ کو لائسنس دینے کے مترادف ہے۔** عوامی پروجیکٹس [GitHub کی سروس کی شرائط] (https://help.github.com/en/github/site-policy/github-) کے تحت آتے ہیں۔ سروس کی شرائط#3-مالک-آف-مواد-کے-دائیں-سے-پوسٹ-اور-لائسنس-گرانٹس)، جو دوسروں کو آپ کے پروجیکٹ کو دیکھنے اور فورک کرنے کی اجازت دیتی ہے، لیکن آپ کا کام بصورت دیگر بغیر اجازت کے آتا ہے۔ + +اگر آپ چاہتے ہیں کہ دوسرے آپ کے پروجیکٹ کو استعمال کریں، تقسیم کریں، اس میں ترمیم کریں یا اس میں حصہ ڈالیں، تو آپ کو اوپن سورس لائسنس شامل کرنا ہوگا۔ مثال کے طور پر، کوئی شخص آپ کے GitHub پروجیکٹ کے کسی بھی حصے کو اپنے کوڈ میں قانونی طور پر استعمال نہیں کر سکتا، چاہے وہ عوامی ہی کیوں نہ ہو، جب تک کہ آپ انہیں واضح طور پر ایسا کرنے کا حق نہ دیں۔ + +## بس مجھے TL؛ DR دیں کہ مجھے اپنے پروجیکٹ کی حفاظت کے لیے کیا ضرورت ہے۔ + +آپ خوش قسمت ہیں، کیونکہ آج اوپن سورس لائسنس معیاری اور استعمال میں آسان ہیں۔ آپ کسی موجودہ لائسنس کو براہ راست اپنے پروجیکٹ میں کاپی پیسٹ کر سکتے ہیں۔ + +[MIT](https://choosealicense.com/licenses/mit/)، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/)، اور [GPLv3](https://choosealicense. com/licenses/gpl-3.0/) سب سے زیادہ مقبول اوپن سورس لائسنسز ہیں، لیکن انتخاب کرنے کے لیے دیگر آپشنز موجود ہیں۔ آپ ان لائسنسوں کا مکمل متن، اور ان کے استعمال کے بارے میں ہدایات [choosealicense.com](https://choosealicense.com/) پر حاصل کر سکتے ہیں۔ + +جب آپ GitHub پر ایک نیا پروجیکٹ بناتے ہیں، تو آپ سے [لائسنس شامل کرنے کے لیے کہا جائے گا](https://help.github.com/articles/open-source-licensing/)۔ + + + +## میرے پروجیکٹ کے لیے کون سا اوپن سورس لائسنس مناسب ہے؟ + +اگر آپ خالی سلیٹ سے شروع کر رہے ہیں، تو [MIT لائسنس](https://choosealicense.com/licenses/mit/) کے ساتھ غلط ہونا مشکل ہے۔ یہ مختصر ہے، سمجھنے میں بہت آسان ہے، اور کسی کو بھی اس وقت تک کچھ بھی کرنے کی اجازت دیتا ہے جب تک کہ وہ آپ کے کاپی رائٹ نوٹس سمیت لائسنس کی ایک کاپی اپنے پاس رکھے۔ اگر آپ کو کبھی ضرورت پڑی تو آپ ایک مختلف لائسنس کے تحت پروجیکٹ کو جاری کر سکیں گے۔ + +بصورت دیگر، اپنے پروجیکٹ کے لیے صحیح اوپن سورس لائسنس کا انتخاب آپ کے مقاصد پر منحصر ہے۔ + +آپ کے پروجیکٹ میں **انحصارات** ہونے کا بہت امکان ہے (یا ہوگا)۔ مثال کے طور پر، اگر آپ Node.js پروجیکٹ کو اوپن سورس کر رہے ہیں، تو آپ شاید نوڈ پیکیج مینیجر (npm) کی لائبریریاں استعمال کریں گے۔ ان لائبریریوں میں سے ہر ایک جس پر آپ انحصار کرتے ہیں اس کا اپنا اوپن سورس لائسنس ہوگا۔ اگر ان کا ہر لائسنس "اجازت مند" ہے (عوام کو استعمال کرنے، ترمیم کرنے، اور شیئر کرنے کی اجازت دیتا ہے، بغیر کسی شرط کے ڈاؤن اسٹریم لائسنسنگ)، آپ جو بھی لائسنس چاہتے ہیں استعمال کر سکتے ہیں۔ عام اجازت یافتہ لائسنسوں میں MIT، Apache 2.0، ISC، اور BSD شامل ہیں۔ + +دوسری طرف، اگر آپ کے کسی بھی انحصار کا لائسنس "مضبوط کاپی لیفٹ" ہے (عوامی کو بھی وہی اجازت دیتا ہے، جو اسی لائسنس کو نیچے کی طرف استعمال کرنے کی شرط سے مشروط ہے)، تو آپ کے پروجیکٹ کو وہی لائسنس استعمال کرنا پڑے گا۔ عام مضبوط کاپی لیفٹ لائسنسوں میں GPLv2، GPLv3، اور AGPLv3 شامل ہیں۔ + +آپ ان **کمیونٹیز** پر بھی غور کر سکتے ہیں جن کی آپ کو امید ہے کہ وہ آپ کے پروجیکٹ میں استعمال کریں گے اور تعاون کریں گے: + +* **کیا آپ چاہتے ہیں کہ آپ کے پروجیکٹ کو دوسرے پروجیکٹس کے ذریعے انحصار کے طور پر استعمال کیا جائے؟** اپنی متعلقہ کمیونٹی میں سب سے زیادہ مقبول لائسنس کا استعمال کرنا شاید بہتر ہے۔ مثال کے طور پر، [MIT](https://choosealicense.com/licenses/mit/) [npm لائبریریوں](https://libraries.io/search?platforms=NPM) کے لیے سب سے مقبول لائسنس ہے۔ +* **کیا آپ چاہتے ہیں کہ آپ کا پروجیکٹ بڑے کاروباروں کے لیے اپیل کرے؟** ایک بڑا کاروبار ممکنہ طور پر تمام شراکت داروں سے ایک ایکسپریس پیٹنٹ لائسنس چاہتا ہے۔ اس معاملے میں، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) نے آپ (اور ان کو) کور کیا ہے۔ +* **کیا آپ چاہتے ہیں کہ آپ کا پروجیکٹ ان شراکت داروں سے اپیل کرے جو نہیں چاہتے کہ ان کے تعاون کو بند سورس سافٹ ویئر میں استعمال کیا جائے؟** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) یا (اگر وہ بند سورس سروسز میں حصہ ڈالنا بھی نہیں چاہتے ہیں) + +آپ کی **کمپنی** کے اوپن سورس پروجیکٹس کے لیے مخصوص لائسنسنگ کے تقاضے ہو سکتے ہیں۔ مثال کے طور پر، اسے اجازت دینے والے لائسنس کی ضرورت ہو سکتی ہے تاکہ کمپنی آپ کے پروجیکٹ کو کمپنی کے بند سورس پروڈکٹ میں استعمال کر سکے۔ یا آپ کی کمپنی کو ایک مضبوط کاپی لیفٹ لائسنس اور ایک اضافی شراکت دار معاہدے کی ضرورت ہو سکتی ہے (نیچے دیکھیں) تاکہ صرف آپ کی کمپنی، اور کوئی اور آپ کے پروجیکٹ کو بند سورس سافٹ ویئر میں استعمال نہ کر سکے۔ یا آپ کی کمپنی کو معیارات، سماجی ذمہ داری، یا شفافیت سے متعلق کچھ ضروریات ہو سکتی ہیں، جن میں سے کسی کو بھی لائسنسنگ کی مخصوص حکمت عملی کی ضرورت ہو سکتی ہے۔ اپنے [کمپنی کے قانونی شعبے] سے بات کریں (#what-does-my-companys-legal-team-need-to-know)۔ + +جب آپ GitHub پر ایک نیا پروجیکٹ بناتے ہیں، تو آپ کو لائسنس منتخب کرنے کا اختیار دیا جاتا ہے۔ مذکورہ لائسنسوں میں سے ایک کو شامل کرنا آپ کے GitHub پروجیکٹ کو اوپن سورس بنا دے گا۔ اگر آپ دوسرے اختیارات دیکھنا چاہتے ہیں تو اپنے پروجیکٹ کے لیے صحیح لائسنس تلاش کرنے کے لیے [choosealicense.com](https://choosealicense.com) کو دیکھیں، چاہے یہ [سافٹ ویئر نہیں ہے](https://choosealicense.com) .com/non-software/)۔ + +## اگر میں اپنے پروجیکٹ کا لائسنس تبدیل کرنا چاہتا ہوں تو کیا ہوگا؟ + +زیادہ تر منصوبوں کو کبھی بھی لائسنس تبدیل کرنے کی ضرورت نہیں ہوتی ہے۔ لیکن کبھی کبھار حالات بدل جاتے ہیں۔ + +مثال کے طور پر، جیسے جیسے آپ کا پروجیکٹ بڑھتا ہے اس میں انحصار یا صارفین شامل ہوتے ہیں، یا آپ کی کمپنی حکمت عملی تبدیل کرتی ہے، جن میں سے کسی کو بھی مختلف لائسنس کی ضرورت ہو سکتی ہے یا اس کی ضرورت ہو سکتی ہے۔ اس کے علاوہ، اگر آپ نے شروع سے ہی اپنے پروجیکٹ کو لائسنس دینے میں کوتاہی کی ہے، تو لائسنس کا اضافہ مؤثر طریقے سے لائسنس کو تبدیل کرنے کے مترادف ہے۔ اپنے پروجیکٹ کا لائسنس شامل کرتے یا تبدیل کرتے وقت تین بنیادی چیزوں پر غور کرنا ہے: + +**یہ پیچیدہ ہے۔** لائسنس کی مطابقت اور تعمیل کا تعین کرنا اور کاپی رائٹ کس کے پاس ہے یہ بہت جلد پیچیدہ اور الجھا ہوا ہو سکتا ہے۔ نئی ریلیزز اور شراکتوں کے لیے نئے لیکن ہم آہنگ لائسنس پر سوئچ کرنا تمام موجودہ شراکتوں کو دوبارہ لائسنس دینے سے مختلف ہے۔ لائسنس تبدیل کرنے کی خواہش کے پہلے اشارے پر اپنی قانونی ٹیم کو شامل کریں۔ یہاں تک کہ اگر آپ لائسنس میں تبدیلی کے لیے اپنے پروجیکٹ کے کاپی رائٹ ہولڈرز سے اجازت لے سکتے ہیں یا حاصل کر سکتے ہیں، تب بھی اپنے پروجیکٹ کے دیگر صارفین اور تعاون کنندگان پر تبدیلی کے اثرات پر غور کریں۔ اپنے پروجیکٹ کے لیے لائسنس کی تبدیلی کو ایک "گورننس ایونٹ" کے طور پر سوچیں جو آپ کے پروجیکٹ کے اسٹیک ہولڈرز کے ساتھ واضح مواصلت اور مشاورت کے ساتھ آسانی سے چل سکے گا۔ اپنے پراجیکٹ کے آغاز سے ہی مناسب لائسنس کا انتخاب کرنے اور استعمال کرنے کی تمام زیادہ وجہ! + +**آپ کے پروجیکٹ کا موجودہ لائسنس۔** اگر آپ کے پروجیکٹ کا موجودہ لائسنس اس لائسنس کے ساتھ مطابقت رکھتا ہے جس میں آپ تبدیل کرنا چاہتے ہیں، تو آپ بس نئے لائسنس کا استعمال شروع کر سکتے ہیں۔ اس کی وجہ یہ ہے کہ اگر لائسنس A لائسنس B کے ساتھ مطابقت رکھتا ہے، تو آپ B کی شرائط کی تعمیل کرتے ہوئے A کی شرائط کی تعمیل کریں گے (لیکن ضروری نہیں کہ اس کے برعکس ہو)۔ لہذا اگر آپ فی الحال اجازت دینے والا لائسنس استعمال کر رہے ہیں (مثال کے طور پر، MIT)، تو آپ مزید شرائط کے ساتھ لائسنس میں تبدیل ہو سکتے ہیں، جب تک کہ آپ MIT لائسنس کی ایک کاپی اور کسی بھی متعلقہ کاپی رائٹ نوٹس (یعنی، کی تعمیل جاری رکھیں) MIT لائسنس کی کم سے کم شرائط)۔ لیکن اگر آپ کا موجودہ لائسنس قابل اجازت نہیں ہے (مثال کے طور پر کاپی لیفٹ، یا آپ کے پاس لائسنس نہیں ہے) اور آپ واحد کاپی رائٹ ہولڈر نہیں ہیں، تو آپ اپنے پروجیکٹ کے لائسنس کو MIT میں تبدیل نہیں کر سکتے۔ بنیادی طور پر، اجازت دینے والے لائسنس کے ساتھ پروجیکٹ کے کاپی رائٹ ہولڈرز نے لائسنس تبدیل کرنے کی پیشگی اجازت دے دی ہے۔ + +**آپ کے پراجیکٹ کے موجودہ کاپی رائٹ ہولڈرز۔** اگر آپ اپنے پروجیکٹ کے واحد تعاون کنندہ ہیں تو آپ یا آپ کی کمپنی پروجیکٹ کے واحد کاپی رائٹ ہولڈر ہیں۔ آپ جو بھی لائسنس آپ یا آپ کی کمپنی چاہتے ہیں اس میں شامل یا تبدیل کر سکتے ہیں۔ بصورت دیگر کاپی رائٹ ہولڈرز ہو سکتے ہیں جن سے آپ کو لائسنس تبدیل کرنے کے لیے معاہدے کی ضرورت ہے۔ وہ کون ہیں؟ جو لوگ آپ کے پروجیکٹ میں کام کرتے ہیں وہ شروع کرنے کے لیے ایک اچھی جگہ ہے۔ لیکن کچھ معاملات میں کاپی رائٹ ان لوگوں کے آجروں کے پاس ہوگا۔ کچھ معاملات میں لوگوں نے صرف کم سے کم تعاون کیا ہوگا، لیکن اس میں کوئی سخت اور تیز قاعدہ نہیں ہے کہ کوڈ کی کچھ لائنوں کے تحت کی جانے والی شراکتیں کاپی رائٹ کے تابع نہ ہوں۔ کیا کرنا ہے؟ یہ منحصر کرتا ہے. نسبتاً چھوٹے اور نوجوان پروجیکٹ کے لیے، یہ ممکن ہو سکتا ہے کہ تمام موجودہ شراکت داروں کو کسی مسئلے میں لائسنس کی تبدیلی یا پل کی درخواست پر رضامندی دلائیں۔ بڑے اور طویل المدتی منصوبوں کے لیے، آپ کو بہت سے شراکت داروں اور یہاں تک کہ ان کے وارثوں کو تلاش کرنا پڑ سکتا ہے۔ موزیلا کو فائر فاکس، تھنڈر برڈ، اور متعلقہ سافٹ ویئر کو دوبارہ لائسنس دینے میں (2001-2006) سال لگے۔ + +متبادل طور پر، آپ شراکت کنندگان کو کچھ شرائط کے تحت لائسنس کی کچھ تبدیلیوں کے لیے پیشگی (اضافی شراکت کنندہ کے معاہدے کے ذریعے - نیچے دیکھیں) سے اتفاق کر سکتے ہیں، جو آپ کے موجودہ اوپن سورس لائسنس کی اجازت سے ہٹ کر ہے۔ یہ لائسنسوں کو تبدیل کرنے کی پیچیدگی کو تھوڑا سا بدل دیتا ہے۔ آپ کو سامنے اپنے وکلاء سے مزید مدد کی ضرورت ہوگی، اور آپ پھر بھی لائسنس کی تبدیلی کو انجام دیتے وقت اپنے پروجیکٹ کے اسٹیک ہولڈرز سے واضح طور پر بات چیت کرنا چاہیں گے۔ + +## کیا میرے پروجیکٹ کو شراکت دار کے اضافی معاہدے کی ضرورت ہے؟ + +شاید نہیں۔ اوپن سورس پروجیکٹس کی اکثریت کے لیے، اوپن سورس لائسنس واضح طور پر ان باؤنڈ (مطابقت کنندگان سے) اور آؤٹ باؤنڈ (دوسرے شراکت داروں اور صارفین کے لیے) لائسنس کے طور پر کام کرتا ہے۔ اگر آپ کا پروجیکٹ GitHub پر ہے تو، GitHub کی سروس کی شرائط "inbound=outbound" کو [explicit default](https://help.github.com/en/github/site-policy/github-terms-of-service# 6-تعاون-کم-ذخیرہ-لائسنس)۔ + +ایک اضافی کنٹریبیوٹر ایگریمنٹ - جسے اکثر کنٹریبیوٹر لائسنس ایگریمنٹ (CLA) کہا جاتا ہے - پروجیکٹ مینٹینرز کے لیے انتظامی کام کر سکتا ہے۔ معاہدے میں کتنا کام شامل ہوتا ہے اس کا انحصار اس منصوبے اور عمل درآمد پر ہوتا ہے۔ ایک سادہ معاہدے کے لیے ضروری ہو سکتا ہے کہ شراکت کنندگان ایک کلک کے ساتھ تصدیق کریں کہ ان کے پاس پروجیکٹ کے اوپن سورس لائسنس کے تحت تعاون کرنے کے لیے ضروری حقوق ہیں۔ ایک زیادہ پیچیدہ معاہدے کے لیے شراکت داروں کے آجروں سے قانونی جائزہ لینے اور دستخط کرنے کی ضرورت پڑ سکتی ہے۔ + +اس کے علاوہ، "کاغذی کارروائی" کو شامل کرنے سے جو کچھ کے خیال میں غیر ضروری، سمجھنا مشکل، یا غیر منصفانہ ہے (جب معاہدے کے وصول کنندہ کو شراکت داروں یا عوام کو پروجیکٹ کے اوپن سورس لائسنس کے ذریعے سے زیادہ حقوق ملتے ہیں)، ایک اضافی شراکت کنندہ کے معاہدے کو غیر دوستانہ سمجھا جا سکتا ہے۔ پروجیکٹ کی کمیونٹی کو۔ + + + +کچھ حالات جہاں آپ اپنے پروجیکٹ کے لیے اضافی شراکت دار کے معاہدے پر غور کرنا چاہتے ہیں ان میں شامل ہیں: + +* آپ کے وکلاء چاہتے ہیں کہ تمام شراکت دار واضح طور پر (_sign_، آن لائن یا آف لائن) شراکت کی شرائط کو قبول کریں، شاید اس لیے کہ انہیں لگتا ہے کہ اوپن سورس لائسنس خود کافی نہیں ہے (حالانکہ یہ ہے!) اگر یہ واحد تشویش ہے تو، ایک شراکت دار معاہدہ جو پروجیکٹ کے اوپن سورس لائسنس کی توثیق کرتا ہے کافی ہونا چاہئے۔ [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) ہلکے وزن کے اضافی کنٹریبیوٹر کے معاہدے کی ایک اچھی مثال ہے۔ +* آپ یا آپ کے وکلاء چاہتے ہیں کہ ڈویلپر اس بات کی نمائندگی کریں کہ وہ جو بھی عہد کرتے ہیں وہ مجاز ہے۔ ایک [Developer Certificate of Origin](https://developercertificate.org/) کی ضرورت یہ ہے کہ کتنے پروجیکٹ اسے حاصل کرتے ہیں۔ مثال کے طور پر، Node.js کمیونٹی [استعمال کرتا ہے](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [اس کے بجائے](https://nodejs.org/en/blog/ ان کے سابقہ ​​CLA کی غیر زمرہ بندی/نوٹس-فرم-دی-روڈ/#آسان شراکت)۔ آپ کے ذخیرے پر DCO کے نفاذ کو خودکار کرنے کا ایک آسان آپشن [DCO Probot](https://github.com/probot/dco) ہے۔ +* آپ کا پروجیکٹ اوپن سورس لائسنس کا استعمال کرتا ہے جس میں ایکسپریس پیٹنٹ گرانٹ شامل نہیں ہے (جیسے MIT)، اور آپ کو تمام شراکت داروں سے پیٹنٹ گرانٹ کی ضرورت ہے، جن میں سے کچھ بڑے پیٹنٹ پورٹ فولیوز والی کمپنیوں کے لیے کام کر سکتی ہیں جو آپ کو نشانہ بنانے کے لیے استعمال ہو سکتی ہیں۔ یا پروجیکٹ کے دوسرے معاونین اور صارفین۔ [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) ایک عام طور پر استعمال ہونے والا اضافی شراکت دار معاہدہ ہے جس میں پیٹنٹ گرانٹ ہے جو Apache لائسنس 2.0 میں پایا جاتا ہے۔ +* آپ کا پروجیکٹ کاپی لیفٹ لائسنس کے تحت ہے، لیکن آپ کو پروجیکٹ کا ملکیتی ورژن بھی تقسیم کرنا ہوگا۔ آپ کو کاپی رائٹ تفویض کرنے یا آپ کو (لیکن عوام کو نہیں) اجازت دینے والا لائسنس دینے کے لیے ہر تعاون کنندہ کی ضرورت ہوگی۔ [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) اس قسم کے معاہدے کی ایک مثال ہے۔ +* آپ کو لگتا ہے کہ آپ کے پروجیکٹ کو اس کی زندگی بھر کے لیے لائسنسوں کو تبدیل کرنے کی ضرورت پڑ سکتی ہے اور آپ چاہتے ہیں کہ شراکت دار اس طرح کی تبدیلیوں کے لیے پیشگی اتفاق کریں۔ + +اگر آپ کو اپنے پروجیکٹ کے ساتھ اضافی کنٹریبیوٹر کا معاہدہ استعمال کرنے کی ضرورت ہے، تو کنٹریبیوٹر کی خلفشار کو کم کرنے کے لیے انٹیگریشن جیسے [CLA اسسٹنٹ](https://github.com/cla-assistant/cla-assistant) استعمال کرنے پر غور کریں۔ + +## میری کمپنی کی قانونی ٹیم کو کیا جاننے کی ضرورت ہے؟ + +اگر آپ کمپنی کے ملازم کے طور پر اوپن سورس پروجیکٹ جاری کر رہے ہیں، تو پہلے، آپ کی قانونی ٹیم کو معلوم ہونا چاہیے کہ آپ کسی پروجیکٹ کو اوپن سورس کر رہے ہیں۔ + +بہتر یا بدتر کے لیے، انہیں بتانے پر غور کریں چاہے یہ ایک ذاتی پروجیکٹ ہو۔ شاید آپ کا اپنی کمپنی کے ساتھ "ملازمین کا IP معاہدہ" ہے جو انہیں آپ کے پروجیکٹس کا کچھ کنٹرول دیتا ہے، خاص طور پر اگر وہ کمپنی کے کاروبار سے بالکل متعلق ہوں یا آپ پروجیکٹ کو تیار کرنے کے لیے کمپنی کے کسی وسائل کا استعمال کرتے ہوں۔ آپ کی کمپنی کو آسانی سے آپ کو اجازت دینی چاہیے، اور ہو سکتا ہے کہ پہلے سے ہی ملازم دوست IP معاہدے یا کمپنی کی پالیسی کے ذریعے ہو۔ اگر نہیں، تو آپ گفت و شنید کر سکتے ہیں (مثال کے طور پر، وضاحت کریں کہ آپ کا پروجیکٹ آپ کے لیے کمپنی کے پیشہ ورانہ سیکھنے اور ترقی کے مقاصد کو پورا کرتا ہے)، یا جب تک آپ کو کوئی بہتر کمپنی نہ مل جائے اپنے پروجیکٹ پر کام کرنے سے گریز کریں۔ + +**اگر آپ اپنی کمپنی کے لیے کسی پروجیکٹ کو اوپن سورس کر رہے ہیں، تو انہیں ضرور بتائیں۔ آپ کی قانونی ٹیم کے پاس کمپنی کی کاروباری ضروریات اور اس بات کو یقینی بنانے کے بارے میں مہارت کی بنیاد پر اوپن سورس لائسنس (اور ہوسکتا ہے کہ اضافی کنٹریبیوٹر ایگریمنٹ) استعمال کرنے کے لیے پہلے سے ہی پالیسیاں موجود ہیں تاکہ یہ یقینی بنایا جا سکے کہ آپ کا پروجیکٹ اس کے انحصار کے لائسنس کی تعمیل کرتا ہے۔ اگر نہیں، تو آپ اور وہ قسمت میں ہیں! آپ کی قانونی ٹیم کو اس چیز کا پتہ لگانے کے لیے آپ کے ساتھ کام کرنے کے لیے بے تاب ہونا چاہیے۔ سوچنے کے لیے کچھ چیزیں: + +* ** فریق ثالث کا مواد:** کیا آپ کے پروجیکٹ میں دوسروں کی طرف سے تخلیق کردہ انحصارات ہیں یا بصورت دیگر دوسروں کے کوڈ کو شامل یا استعمال کرتے ہیں؟ اگر یہ اوپن سورس ہیں، تو آپ کو مواد کے اوپن سورس لائسنس کی تعمیل کرنے کی ضرورت ہوگی۔ اس کا آغاز ایک ایسے لائسنس کے انتخاب سے ہوتا ہے جو تھرڈ پارٹی اوپن سورس لائسنس کے ساتھ کام کرتا ہے (اوپر دیکھیں)۔ اگر آپ کا پروجیکٹ تیسرے فریق کے اوپن سورس مواد میں ترمیم کرتا ہے یا تقسیم کرتا ہے، تو آپ کی قانونی ٹیم یہ بھی جاننا چاہے گی کہ آپ فریق ثالث کے اوپن سورس لائسنس کی دیگر شرائط کو پورا کر رہے ہیں جیسے کاپی رائٹ نوٹسز کو برقرار رکھنا۔ اگر آپ کا پراجیکٹ دوسروں کا کوڈ استعمال کرتا ہے جس کے پاس اوپن سورس لائسنس نہیں ہے، تو آپ کو ممکنہ طور پر فریق ثالث سے پوچھنا پڑے گا کہ وہ [اوپن سورس لائسنس شامل کریں](https://choosealicense.com/no-license/# for-users)، اور اگر آپ اسے حاصل نہیں کر سکتے، تو اپنے پروجیکٹ میں ان کا کوڈ استعمال کرنا بند کر دیں۔ + +* **تجارتی راز:** غور کریں کہ کیا اس پروجیکٹ میں کوئی ایسی چیز ہے جسے کمپنی عام لوگوں کے لیے دستیاب نہیں کرانا چاہتی۔ اگر ایسا ہے تو، آپ جس مواد کو نجی رکھنا چاہتے ہیں اسے نکالنے کے بعد، آپ اپنے باقی پروجیکٹ کو اوپن سورس کر سکتے ہیں۔ + +* **پیٹنٹ:** کیا آپ کی کمپنی کسی ایسے پیٹنٹ کے لیے درخواست دے رہی ہے جس کی اوپن سورسنگ سے آپ کا پروجیکٹ [عوامی انکشاف](https://en.wikipedia.org/wiki/Public_disclosure) پر مشتمل ہوگا؟ افسوس کی بات ہے، آپ کو انتظار کرنے کے لیے کہا جا سکتا ہے (یا ہو سکتا ہے کہ کمپنی درخواست کی حکمت پر نظر ثانی کرے گی)۔ اگر آپ بڑے پیٹنٹ پورٹ فولیوز والی کمپنیوں کے ملازمین سے اپنے پروجیکٹ میں شراکت کی توقع کر رہے ہیں، تو آپ کی قانونی ٹیم آپ کو شراکت داروں (جیسے Apache 2.0 یا GPLv3) کی طرف سے ایکسپریس پیٹنٹ گرانٹ کے ساتھ لائسنس استعمال کرنے کی خواہش کر سکتی ہے، یا ایک اضافی شراکت دار معاہدہ ( اوپر ملاحظہ کریں). + +* **ٹریڈ مارکس:** دو بار چیک کریں کہ آپ کے پروجیکٹ کا نام [کسی موجودہ ٹریڈ مارکس سے متصادم نہیں ہے](../starting-a-project/#avoiding-name-conflicts)۔ اگر آپ پروجیکٹ میں اپنی کمپنی کے ٹریڈ مارک استعمال کرتے ہیں، تو چیک کریں کہ اس سے کوئی تنازعہ تو نہیں بنتا۔ [FOSSmarks](http://fossmarks.org/) مفت اور اوپن سورس پروجیکٹس کے تناظر میں ٹریڈ مارکس کو سمجھنے کے لیے ایک عملی گائیڈ ہے۔ + +* **رازداری:** کیا آپ کا پروجیکٹ صارفین کا ڈیٹا اکٹھا کرتا ہے؟ کمپنی کے سرورز کو "فون ہوم"؟ آپ کی قانونی ٹیم کمپنی کی پالیسیوں اور بیرونی ضوابط کی تعمیل میں آپ کی مدد کر سکتی ہے۔ + +اگر آپ اپنی کمپنی کا پہلا اوپن سورس پروجیکٹ جاری کر رہے ہیں، تو اوپر سے گزرنے کے لیے کافی ہے (لیکن فکر نہ کریں، زیادہ تر پروجیکٹس کو کوئی بڑی تشویش نہیں ہونی چاہیے)۔ + +طویل مدتی، آپ کی قانونی ٹیم کمپنی کی اوپن سورس میں شمولیت سے مزید فائدہ اٹھانے اور محفوظ رہنے میں مدد کرنے کے لیے مزید کچھ کر سکتی ہے: + +* **ملازمین کی شراکت کی پالیسیاں:** ایک کارپوریٹ پالیسی تیار کرنے پر غور کریں جو یہ بتاتی ہو کہ آپ کے ملازمین اوپن سورس پروجیکٹس میں کس طرح تعاون کرتے ہیں۔ ایک واضح پالیسی آپ کے ملازمین کے درمیان الجھن کو کم کرے گی اور کمپنی کے بہترین مفاد میں اوپن سورس پروجیکٹس میں حصہ ڈالنے میں ان کی مدد کرے گی، چاہے وہ ان کی ملازمت کے حصے کے طور پر ہو یا اپنے فارغ وقت میں۔ ایک اچھی مثال Rackspace کی [ماڈل IP اور اوپن سورس کنٹری بیوشن پالیسی](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) ہے۔ + + + +* **کیا جاری کرنا ہے:** [(تقریباً) سب کچھ؟](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) اگر آپ کی قانونی ٹیم سمجھتی ہے اور آپ کی کمپنی کی اوپن سورس حکمت عملی میں سرمایہ کاری کی گئی ہے، وہ آپ کی کوششوں میں رکاوٹ ڈالنے کے بجائے مدد کرنے کے بہترین اہل ہوں گے۔ +* **تعمیل:** یہاں تک کہ اگر آپ کی کمپنی کوئی اوپن سورس پروجیکٹ جاری نہیں کرتی ہے، تو وہ دوسروں کے اوپن سورس سافٹ ویئر کا استعمال کرتی ہے۔ [آگاہی اور عمل](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) سر درد، مصنوعات میں تاخیر، اور قانونی چارہ جوئی کو روک سکتا ہے۔ . + + + +* **پیٹنٹ:** آپ کی کمپنی [اوپن انوینشن نیٹ ورک](https://www.openinventionnetwork.com/) میں شامل ہونا چاہتی ہے، جو ایک مشترکہ دفاعی پیٹنٹ پول ہے جو ممبران کے بڑے اوپن سورس پروجیکٹس کے استعمال کی حفاظت کرتا ہے، یا دریافت کرتا ہے۔ دیگر [متبادل پیٹنٹ لائسنسنگ](https://www.eff.org/document/hacking-patent-system-2016)۔ +* **گورننس:** خاص طور پر اگر اور جب کسی پروجیکٹ کو [کمپنی سے باہر قانونی ادارہ] میں منتقل کرنا سمجھ میں آتا ہے (../leadership-and-governance/#do-i-need-a-legal-entity -میرے پروجیکٹ کی حمایت کرنے کے لیے)۔ diff --git a/_articles/ur/maintaining-balance-for-open-source-maintainers.md b/_articles/ur/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..73e905a5243 --- /dev/null +++ b/_articles/ur/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,226 @@ +--- +lang: en +untranslated: true +title: اوپن سورس مینٹینرز کے لیے توازن برقرار رکھنا +description: دیکھ بھال کرنے والے کے طور پر خود کی دیکھ بھال اور برن آؤٹ سے بچنے کے لیے نکات۔ +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +جیسا کہ ایک اوپن سورس پروجیکٹ کی مقبولیت میں اضافہ ہوتا ہے، یہ ضروری ہو جاتا ہے کہ آپ کو توازن برقرار رکھنے میں مدد کرنے کے لیے واضح حدود کا تعین کیا جائے تاکہ آپ طویل مدت تک تروتازہ اور نتیجہ خیز رہیں۔ + +مینٹینرز کے تجربات اور توازن تلاش کرنے کے لیے ان کی حکمت عملیوں کے بارے میں بصیرت حاصل کرنے کے لیے، ہم نے مینٹینر کمیونٹی کے 40 اراکین کے ساتھ ایک ورکشاپ چلائی، جس سے ہمیں اجازت ملی۔ اوپن سورس میں برن آؤٹ اور ان طریقوں سے سیکھنے کے لیے جو ان کے کام میں توازن برقرار رکھنے میں ان کی مدد کرتے ہیں۔ یہیں سے ذاتی ماحولیات کا تصور عمل میں آتا ہے۔ + +تو، ذاتی ماحولیات کیا ہے؟ جیسا کہ روک ووڈ لیڈرشپ انسٹی ٹیوٹ کے ذریعہ بیان کیا گیا ہے، اس میں "توازن برقرار رکھنا، پیسنگ، زندگی بھر ہماری توانائی کو برقرار رکھنے کی کارکردگی۔" اس نے ہماری گفتگو کو ترتیب دیا، جس سے دیکھ بھال کرنے والوں کو ان کے اعمال اور شراکت کو ایک بڑے ماحولیاتی نظام کے حصوں کے طور پر پہچاننے میں مدد ملتی ہے جو وقت کے ساتھ ساتھ تیار ہوتا ہے۔ برن آؤٹ، کام کی جگہ پر دائمی تناؤ کے نتیجے میں پیدا ہونے والا ایک سنڈروم جیسا کہ [WHO کی طرف سے بیان کیا گیا ہے](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281) ، دیکھ بھال کرنے والوں میں غیر معمولی نہیں ہے۔ یہ اکثر حوصلہ افزائی کی کمی، توجہ مرکوز کرنے میں ناکامی، اور تعاون کرنے والوں اور کمیونٹی کے ساتھ ہمدردی کی کمی کا باعث بنتا ہے جس کے ساتھ آپ کام کرتے ہیں۔ + + + +ذاتی ماحولیات کے تصور کو اپناتے ہوئے، دیکھ بھال کرنے والے فعال طور پر برن آؤٹ سے بچ سکتے ہیں، خود کی دیکھ بھال کو ترجیح دے سکتے ہیں، اور اپنا بہترین کام کرنے کے لیے توازن کے احساس کو برقرار رکھ سکتے ہیں۔ + +## ایک مینٹینر کے طور پر خود کی دیکھ بھال اور برن آؤٹ سے بچنے کے لیے نکات: + +### اوپن سورس میں کام کرنے کے اپنے محرکات کی شناخت کریں۔ + +اس بات پر غور کرنے کے لیے وقت نکالیں کہ اوپن سورس مینٹیننس کے کون سے حصے آپ کو متحرک کرتے ہیں۔ اپنے محرکات کو سمجھنا آپ کو کام کو اس انداز میں ترجیح دینے میں مدد دے سکتا ہے جو آپ کو نئے چیلنجوں کے لیے مصروف اور تیار رکھے۔ چاہے یہ صارفین کی طرف سے مثبت تاثرات ہوں، کمیونٹی کے ساتھ تعاون کرنے اور سماجی بنانے کی خوشی، یا کوڈ میں ڈوبنے کا اطمینان، آپ کے محرکات کو پہچاننا آپ کی توجہ مرکوز کرنے میں مدد کر سکتا ہے۔ + +### اس بات پر غور کریں کہ آپ کو توازن سے باہر ہونے اور دباؤ ڈالنے کی وجہ کیا ہے۔ + +یہ سمجھنا ضروری ہے کہ ہمیں جلانے کی کیا وجہ ہے۔ یہاں کچھ عام تھیمز ہیں جو ہم نے اوپن سورس مینٹینرز کے درمیان دیکھے ہیں: + +* **مثبت تاثرات کا فقدان:** صارفین کو شکایت ہونے پر ان تک پہنچنے کا امکان بہت زیادہ ہوتا ہے۔ اگر سب کچھ بہت اچھا کام کرتا ہے، تو وہ خاموش رہتے ہیں. مثبت تاثرات کے بغیر مسائل کی بڑھتی ہوئی فہرست کو دیکھنا حوصلہ شکنی ہو سکتا ہے کہ آپ کی شراکتیں کس طرح فرق کر رہی ہیں۔ + + + +*** 'نہیں' نہ کہنا:** اوپن سورس پروجیکٹ پر آپ کو اس سے زیادہ ذمہ داریاں سنبھالنا آسان ہوسکتا ہے۔ چاہے یہ صارفین، تعاون کنندگان، یا دیگر دیکھ بھال کرنے والوں کی طرف سے ہو – ہم ہمیشہ ان کی توقعات پر پورا نہیں اتر سکتے۔ + + + +*** تنہا کام کرنا:** دیکھ بھال کرنے والا ہونا ناقابل یقین حد تک تنہا ہوسکتا ہے۔ یہاں تک کہ اگر آپ دیکھ بھال کرنے والوں کے ایک گروپ کے ساتھ کام کرتے ہیں تو، پچھلے کچھ سالوں میں تقسیم شدہ ٹیموں کو ذاتی طور پر بلانا مشکل رہا ہے۔ + + + +* **کافی وقت یا وسائل نہیں:** یہ خاص طور پر ان رضاکاروں کے لیے درست ہے جنہیں کسی پروجیکٹ پر کام کرنے کے لیے اپنا فارغ وقت قربان کرنا پڑتا ہے۔ + + + +* **متضاد مطالبات:** اوپن سورس مختلف محرکات والے گروپس سے بھرا ہوا ہے، جن پر تشریف لانا مشکل ہوسکتا ہے۔ اگر آپ کو اوپن سورس کرنے کے لیے ادائیگی کی جاتی ہے، تو آپ کے آجر کے مفادات بعض اوقات کمیونٹی کے ساتھ متصادم ہو سکتے ہیں۔ + + + +### برن آؤٹ کی علامات پر دھیان دیں۔ + +کیا آپ 10 ہفتوں تک اپنی رفتار برقرار رکھ سکتے ہیں؟ 10 ماہ؟ 10 سال؟ + +[@shaunagm](https://github.com/shaunagm) سے [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) اور موزیلا کے [ذاتی ایکولوجی سیلف اسیسمنٹ کٹ](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) جو آپ کو اپنی موجودہ رفتار پر غور کرنے اور یہ دیکھنے میں مدد کر سکتی ہے کہ کیا آپ کوئی ایڈجسٹمنٹ کر سکتے ہیں۔ . کچھ دیکھ بھال کرنے والے بھی پہننے کے قابل ٹکنالوجی کا استعمال کرتے ہوئے میٹرکس جیسے نیند کے معیار اور دل کی شرح کی تغیرات (دونوں تناؤ سے منسلک) کو ٹریک کرتے ہیں۔ + + + +### اپنے آپ کو اور اپنی کمیونٹی کو برقرار رکھنے کے لیے آپ کو کس چیز کی ضرورت ہوگی؟ + +یہ ہر دیکھ بھال کرنے والے کے لیے مختلف نظر آئے گا، اور آپ کی زندگی کے مرحلے اور دیگر بیرونی عوامل کے لحاظ سے بدل جائے گا۔ لیکن یہاں کچھ موضوعات ہیں جو ہم نے سنا: + +* **کمیونٹی پر جھکاؤ:** وفد اور شراکت داروں کی تلاش کام کے بوجھ کو کم کرسکتی ہے۔ کسی پروجیکٹ کے لیے متعدد پوائنٹس کا رابطہ آپ کو پریشان کیے بغیر وقفہ لینے میں مدد دے سکتا ہے۔ دوسرے مینٹینرز اور وسیع تر کمیونٹی کے ساتھ جڑیں – گروپس جیسے کہ [مینٹینر کمیونٹی](http://maintainers.github.com/)۔ یہ ہم مرتبہ کی مدد اور سیکھنے کے لیے ایک بہترین ذریعہ ہو سکتا ہے۔ + + آپ صارف برادری کے ساتھ مشغول ہونے کے طریقے بھی تلاش کر سکتے ہیں، تاکہ آپ باقاعدگی سے تاثرات سن سکیں اور اپنے اوپن سورس کام کے اثرات کو سمجھ سکیں۔ + +* **فنڈنگ ​​دریافت کریں:** چاہے آپ پیزا کے پیسے تلاش کر رہے ہوں، یا کل وقتی اوپن سورس جانے کی کوشش کر رہے ہوں، مدد کے لیے بہت سے وسائل موجود ہیں! پہلے قدم کے طور پر، دوسروں کو آپ کے اوپن سورس کام کو سپانسر کرنے کی اجازت دینے کے لیے [GitHub Sponsors](https://github.com/sponsors) کو آن کرنے پر غور کریں۔ اگر آپ مکمل وقت پر چھلانگ لگانے کے بارے میں سوچ رہے ہیں، تو [GitHub Accelerator](http://accelerator.github.com/) کے اگلے دور کے لیے درخواست دیں۔ + + + +* **ٹولز کا استعمال کریں:** دنیا کو خودکار بنانے کے لیے [GitHub Copilot](https://github.com/features/copilot/) اور [GitHub ایکشنز](https://github.com/features/actions) جیسے ٹولز کو دریافت کریں۔ مزید بامعنی شراکت کے لیے کام کریں اور اپنا وقت خالی کریں۔ + + + +* **آرام کریں اور ری چارج کریں:** اوپن سورس سے باہر اپنے مشاغل اور دلچسپیوں کے لیے وقت نکالیں۔ آرام اور جوان ہونے کے لیے ویک اینڈ پر چھٹیاں لیں–اور اپنی [GitHub اسٹیٹس](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your- profile/personalizing-your-profile#setting-a-status) آپ کی دستیابی کو ظاہر کرنے کے لیے! اچھی رات کی نیند آپ کی کوششوں کو طویل مدتی برقرار رکھنے کی آپ کی صلاحیت میں بڑا فرق پیدا کر سکتی ہے۔ + + اگر آپ کو اپنے پروجیکٹ کے کچھ پہلو خاص طور پر خوشگوار معلوم ہوتے ہیں، تو اپنے کام کی ساخت بنانے کی کوشش کریں تاکہ آپ اسے پورے دن تجربہ کر سکیں۔ + + + +* **حدیں طے کریں:** آپ ہر درخواست پر ہاں نہیں کہہ سکتے۔ یہ اتنا ہی آسان ہو سکتا ہے جتنا یہ کہنا کہ "میں ابھی اس تک نہیں پہنچ سکتا اور میرا مستقبل میں کوئی منصوبہ نہیں ہے" یا یہ بتانا کہ آپ README میں کیا کرنا چاہتے ہیں اور کیا نہیں کرنا چاہتے۔ مثال کے طور پر، آپ کہہ سکتے ہیں: "میں صرف PRs کو ضم کرتا ہوں جس میں واضح طور پر درج کیا گیا ہے کہ وہ کیوں بنائے گئے تھے،" یا، "میں صرف متبادل جمعرات کو شام 6 سے 7 بجے تک مسائل کا جائزہ لیتا ہوں۔" یہ دوسروں کے لیے توقعات کا تعین کرتا ہے، اور آپ کو کچھ دیتا ہے۔ آپ کے وقت پر شراکت داروں یا صارفین کے مطالبات کو کم کرنے میں مدد کرنے کے لیے دوسرے اوقات میں اشارہ کرنا۔ + + + + زہریلے رویے اور منفی تعاملات کو بند کرنے میں ثابت قدم رہنا سیکھیں۔ ان چیزوں کو توانائی نہ دینا ٹھیک ہے جن کی آپ کو پرواہ نہیں ہے۔ + + + + + +یاد رکھیں، ذاتی ماحولیات ایک جاری مشق ہے جو آپ کے اوپن سورس سفر میں ترقی کے ساتھ ساتھ تیار ہوتی جائے گی۔ خود کی دیکھ بھال کو ترجیح دے کر اور توازن کے احساس کو برقرار رکھ کر، آپ اوپن سورس کمیونٹی میں مؤثر اور پائیدار حصہ ڈال سکتے ہیں، جس سے آپ کی فلاح و بہبود اور طویل مدت کے لیے آپ کے منصوبوں کی کامیابی دونوں کو یقینی بنایا جا سکتا ہے۔ + +## اضافی وسائل + +* [Maintainer Community](http://maintainers.github.com/) +* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon +* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg +* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge +* [SustainOSS](https://sustainoss.org/) +* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla +* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/) +* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid +* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com) +* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series + +##تعاون کرنے والے + +تمام دیکھ بھال کرنے والوں کا بہت شکریہ جنہوں نے اس گائیڈ کے لیے اپنے تجربات اور تجاویز ہمارے ساتھ شیئر کیں! + +## Contributors + +Many thanks to all the maintainers who shared their experiences and tips with us for this guide! + +This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: + +[@agnostic-apollo](https://github.com/agnostic-apollo) +[@AndreaGriffiths11](https://github.com/AndreaGriffiths11) +[@antfu](https://github.com/antfu) +[@anthonyronda](https://github.com/anthonyronda) +[@CBID2](https://github.com/CBID2) +[@Cli4d](https://github.com/Cli4d) +[@confused-Techie](https://github.com/confused-Techie) +[@danielroe](https://github.com/danielroe) +[@Dexters-Hub](https://github.com/Dexters-Hub) +[@eddiejaoude](https://github.com/eddiejaoude) +[@Eugeny](https://github.com/Eugeny) +[@ferki](https://github.com/ferki) +[@gabek](https://github.com/gabek) +[@geromegrignon](https://github.com/geromegrignon) +[@hynek](https://github.com/hynek) +[@IvanSanchez](https://github.com/IvanSanchez) +[@karasowles](https://github.com/karasowles) +[@KoolTheba](https://github.com/KoolTheba) +[@leereilly](https://github.com/leereilly) +[@ljharb](https://github.com/ljharb) +[@nightlark](https://github.com/nightlark) +[@plarson3427](https://github.com/plarson3427) +[@Pradumnasaraf](https://github.com/Pradumnasaraf) +[@RichardLitt](https://github.com/RichardLitt) +[@rrousselGit](https://github.com/rrousselGit) +[@sansyrox](https://github.com/sansyrox) +[@schlessera](https://github.com/schlessera) +[@shyim](https://github.com/shyim) +[@smashah](https://github.com/smashah) +[@ssalbdivad](https://github.com/ssalbdivad) +[@The-Compiler](https://github.com/The-Compiler) +[@thehale](https://github.com/thehale) +[@Areebey](https://github.com/Areebey) +[@thisisnic](https://github.com/thisisnic) +[@tudoramariei](https://github.com/tudoramariei) +[@UlisesGascon](https://github.com/UlisesGascon) +[@waldyrious](https://github.com/waldyrious) + many others! diff --git a/_articles/ur/metrics.md b/_articles/ur/metrics.md new file mode 100644 index 00000000000..e556acdf4f5 --- /dev/null +++ b/_articles/ur/metrics.md @@ -0,0 +1,131 @@ +--- +lang: en +title: اوپن سورس میٹرکس +description: اپنے اوپن سورس پروجیکٹ کی کامیابی کی پیمائش اور ان کا سراغ لگا کر اسے پھلنے پھولنے میں مدد کرنے کے لیے باخبر فیصلے کریں۔ +class: metrics +order: 9 +image: /assets/images/cards/metrics.png +related: + - finding + - best-practices +--- + +## کسی چیز کی پیمائش کیوں؟ + +ڈیٹا، جب سمجھداری سے استعمال کیا جائے تو، آپ کو اوپن سورس مینٹینر کے طور پر بہتر فیصلے کرنے میں مدد مل سکتی ہے۔ + +مزید معلومات کے ساتھ، آپ کر سکتے ہیں: + +* سمجھیں کہ صارفین ایک نئی خصوصیت پر کیسے ردعمل دیتے ہیں۔ +* معلوم کریں کہ نئے صارفین کہاں سے آتے ہیں۔ +* شناخت کریں، اور فیصلہ کریں کہ آیا سپورٹ کرنا ہے، بیرونی استعمال کا معاملہ یا فعالیت +* اپنے پروجیکٹ کی مقبولیت کا اندازہ لگائیں۔ +* سمجھیں کہ آپ کا پروجیکٹ کیسے استعمال ہوتا ہے۔ +* اسپانسرشپ اور گرانٹس کے ذریعے رقم اکٹھا کریں۔ + +مثال کے طور پر، [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) نے پایا کہ Google Analytics کام کو ترجیح دینے میں ان کی مدد کرتا ہے: + +> ہومبریو مفت فراہم کی جاتی ہے اور اسے مکمل طور پر رضاکار اپنے فارغ وقت میں چلاتے ہیں۔ نتیجے کے طور پر، ہمارے پاس ہومبریو صارفین کے تفصیلی یوزر اسٹڈیز کرنے کے لیے وسائل نہیں ہیں تاکہ یہ فیصلہ کیا جا سکے کہ مستقبل کی خصوصیات کو کس طرح بہترین طریقے سے ڈیزائن کیا جائے اور موجودہ کام کو ترجیح دی جائے۔ گمنام مجموعی صارف کے تجزیات ہمیں اس بات کی بنیاد پر اصلاحات اور خصوصیات کو ترجیح دینے کی اجازت دیتے ہیں کہ لوگ Homebrew کا استعمال کیسے، کہاں اور کب کرتے ہیں۔ + +مقبولیت ہی سب کچھ نہیں ہے۔ ہر کوئی مختلف وجوہات کی بنا پر اوپن سورس میں آتا ہے۔ اگر اوپن سورس مینٹینر کے طور پر آپ کا مقصد آپ کے کام کو ظاہر کرنا، اپنے کوڈ کے بارے میں شفاف ہونا، یا صرف مزہ کرنا ہے، تو میٹرکس آپ کے لیے اہم نہیں ہو سکتے۔ + +اگر آپ اپنے پروجیکٹ کو گہری سطح پر سمجھنے میں دلچسپی رکھتے ہیں، تو اپنے پروجیکٹ کی سرگرمی کا تجزیہ کرنے کے طریقے پڑھیں۔ + +## دریافت + +اس سے پہلے کہ کوئی بھی آپ کے پروجیکٹ کو استعمال کر سکے یا اس میں حصہ ڈال سکے، انہیں یہ جاننے کی ضرورت ہے کہ یہ موجود ہے۔ اپنے آپ سے پوچھیں: _کیا لوگ اس پروجیکٹ کو تلاش کر رہے ہیں؟_ + +![ٹریفک گراف](/assets/images/metrics/repo_traffic_graphs_tooltip.png) + +اگر آپ کا پروجیکٹ GitHub پر ہوسٹ کیا گیا ہے، تو [آپ دیکھ سکتے ہیں](https://help.github.com/articles/about-repository-graphs/#traffic) کتنے لوگ آپ کے پروجیکٹ پر اترتے ہیں اور وہ کہاں سے آتے ہیں۔ اپنے پروجیکٹ کے صفحہ سے، "بصیرت"، پھر "ٹریفک" پر کلک کریں۔ اس صفحے پر، آپ دیکھ سکتے ہیں: + +* **صفحہ کے کل ملاحظات:** آپ کو بتاتا ہے کہ آپ کے پروجیکٹ کو کتنی بار دیکھا گیا۔ + +* **کُل منفرد وزیٹرز:** آپ کو بتاتا ہے کہ آپ کے پروجیکٹ کو کتنے لوگوں نے دیکھا + +* **ریفرنگ سائٹس:** آپ کو بتاتا ہے کہ زائرین کہاں سے آئے ہیں۔ یہ میٹرک آپ کو یہ جاننے میں مدد کر سکتا ہے کہ آپ کے سامعین تک کہاں پہنچنا ہے اور کیا آپ کی پروموشن کی کوششیں کام کر رہی ہیں۔ + +* **مقبول مواد:** آپ کو بتاتا ہے کہ وزیٹر آپ کے پروجیکٹ پر کہاں جاتے ہیں، صفحہ کے ملاحظات اور منفرد ملاحظہ کاروں کے حساب سے تقسیم ہوتے ہیں۔ + +[GitHub stars](https://help.github.com/articles/about-stars/) بھی مقبولیت کا بنیادی پیمانہ فراہم کرنے میں مدد کر سکتا ہے۔ اگرچہ GitHub ستارے ضروری طور پر ڈاؤن لوڈز اور استعمال سے منسلک نہیں ہوتے، وہ آپ کو بتا سکتے ہیں کہ کتنے لوگ آپ کے کام کا نوٹس لے رہے ہیں۔ + +آپ [مخصوص جگہوں پر دریافت ہونے کا سراغ لگانا](https://opensource.com/business/16/6/pirate-metrics): مثال کے طور پر، Google PageRank، آپ کے پروجیکٹ کی ویب سائٹ سے ریفرل ٹریفک، یا دیگر اوپن سے حوالہ جات ماخذ منصوبوں یا ویب سائٹس. + +## استعمال + +لوگ آپ کے پروجیکٹ کو اس جنگلی اور پاگل چیز پر تلاش کر رہے ہیں جسے ہم انٹرنیٹ کہتے ہیں۔ مثالی طور پر، جب وہ آپ کا پروجیکٹ دیکھیں گے، تو وہ کچھ کرنے پر مجبور محسوس کریں گے۔ دوسرا سوال جو آپ پوچھنا چاہیں گے وہ ہے: _کیا لوگ اس پروجیکٹ کو استعمال کر رہے ہیں؟_ + +اگر آپ اپنے پروجیکٹ کو تقسیم کرنے کے لیے پیکیج مینیجر، جیسے npm یا RubyGems.org استعمال کرتے ہیں، تو آپ اپنے پروجیکٹ کے ڈاؤن لوڈز کو ٹریک کرنے کے قابل ہو سکتے ہیں۔ + +ہر پیکج مینیجر "ڈاؤن لوڈ" کی قدرے مختلف تعریف استعمال کر سکتا ہے، اور ڈاؤن لوڈز لازمی طور پر انسٹال یا استعمال سے منسلک نہیں ہوتے، لیکن یہ موازنہ کے لیے کچھ بنیادی لائن فراہم کرتا ہے۔ بہت سے مشہور پیکیج مینیجرز کے استعمال کے اعدادوشمار کو ٹریک کرنے کے لیے [Libraries.io](https://libraries.io/) استعمال کرنے کی کوشش کریں۔ + + +اگر آپ کا پروجیکٹ GitHub پر ہے، تو "ٹریفک" صفحہ پر دوبارہ جائیں۔ آپ یہ دیکھنے کے لیے [کلون گراف](https://github.com/blog/1873-clone-graphs) کا استعمال کر سکتے ہیں کہ آپ کے پروجیکٹ کو ایک مخصوص دن میں کتنی بار کلون کیا گیا ہے، کل کلون اور منفرد کلونرز کے حساب سے ٹوٹا ہوا ہے۔ + +![کلون گراف](/assets/images/metrics/clone_graph.png) + +اگر آپ کے پروجیکٹ کو دریافت کرنے والے لوگوں کی تعداد کے مقابلے میں استعمال کم ہے، تو غور کرنے کے لیے دو مسائل ہیں۔ یا تو: + +* آپ کا پروجیکٹ کامیابی سے آپ کے سامعین کو تبدیل نہیں کر رہا ہے، یا +* آپ غلط سامعین کو اپنی طرف متوجہ کر رہے ہیں۔ + +مثال کے طور پر، اگر آپ کا پراجیکٹ ہیکر نیوز کے صفحہ اول پر آتا ہے، تو آپ کو ممکنہ طور پر دریافت (ٹریفک) میں اضافہ، لیکن تبادلوں کی شرح کم نظر آئے گی، کیونکہ آپ ہیکر نیوز پر ہر کسی تک پہنچ رہے ہیں۔ اگر آپ کے روبی پروجیکٹ کو روبی کانفرنس میں نمایاں کیا گیا ہے، تاہم، آپ کو ہدف بنائے گئے سامعین سے زیادہ تبادلوں کی شرح دیکھنے کا زیادہ امکان ہے۔ + +یہ جاننے کی کوشش کریں کہ آپ کے سامعین کہاں سے آرہے ہیں اور اپنے پروجیکٹ کے صفحے پر دوسروں سے رائے طلب کریں تاکہ یہ معلوم کیا جا سکے کہ آپ کو ان دو مسائل میں سے کس کا سامنا ہے۔ + +ایک بار جب آپ کو معلوم ہو جائے کہ لوگ آپ کے پروجیکٹ کو استعمال کر رہے ہیں، تو آپ یہ جاننے کی کوشش کر سکتے ہیں کہ وہ اس کے ساتھ کیا کر رہے ہیں۔ کیا وہ آپ کے کوڈ کو فورک کرکے اور خصوصیات شامل کرکے اس پر تعمیر کررہے ہیں؟ کیا وہ اسے سائنس یا کاروبار کے لیے استعمال کر رہے ہیں؟ + +## برقرار رکھنا + +لوگ آپ کے پروجیکٹ کو تلاش کر رہے ہیں اور وہ اسے استعمال کر رہے ہیں۔ اگلا سوال جو آپ اپنے آپ سے پوچھنا چاہیں گے وہ ہے: _کیا لوگ اس پروجیکٹ میں حصہ ڈال رہے ہیں؟_ + +تعاون کرنے والوں کے بارے میں سوچنا شروع کرنے میں کبھی جلدی نہیں ہوتی۔ دوسرے لوگوں کے اندر آنے کے بغیر، آپ اپنے آپ کو ایک غیر صحت بخش صورتحال میں ڈالنے کا خطرہ مول لیتے ہیں جہاں آپ کا پروجیکٹ _popular_ ہے (بہت سے لوگ اسے استعمال کرتے ہیں) لیکن _supported_ نہیں (مطالبہ کو پورا کرنے کے لیے مینٹینر کا کافی وقت نہیں)۔ + +برقرار رکھنے کے لیے [نئے تعاون کنندگان کی آمد] (http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2) کی بھی ضرورت ہوتی ہے، جیسا کہ پہلے فعال شراکت دار آخر کار آگے بڑھیں گے۔ دوسری چیزوں کو. + +کمیونٹی میٹرکس کی مثالیں جنہیں آپ باقاعدگی سے ٹریک کرنا چاہتے ہیں ان میں شامل ہیں: + +* **مطلوبہ کنٹریبیوٹر کی کل تعداد اور فی کنٹریبیوٹر کی تعداد:** آپ کو بتاتا ہے کہ آپ کے پاس کتنے کنٹریبیوٹر ہیں اور کون کم یا زیادہ فعال ہے۔ GitHub پر، آپ اسے "Insights" -> "Contributors" کے تحت دیکھ سکتے ہیں۔ ابھی، یہ گراف صرف ان شراکت داروں کو شمار کرتا ہے جنہوں نے ریپوزٹری کی ڈیفالٹ برانچ سے وابستگی کی ہے۔ + +![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png) + +* **پہلی بار، آرام دہ اور بار بار تعاون کرنے والے:** آپ کو یہ ٹریک کرنے میں مدد کرتا ہے کہ آیا آپ کو نئے تعاون کنندگان مل رہے ہیں، اور آیا وہ واپس آتے ہیں۔ (آرام دہ تعاون کرنے والے کمٹ کی تعداد کے ساتھ شراکت دار ہوتے ہیں۔ چاہے وہ ایک کمٹ، پانچ سے کم کمٹ، یا کچھ اور آپ پر منحصر ہے۔) نئے تعاون کنندگان کے بغیر، آپ کے پروجیکٹ کی کمیونٹی جمود کا شکار ہو سکتی ہے۔ + +* **اوپن ایشوز اور اوپن پل کی درخواستوں کی تعداد:** اگر یہ تعداد بہت زیادہ ہوجاتی ہے، تو آپ کو ایشو ٹریجنگ اور کوڈ کے جائزوں میں مدد کی ضرورت پڑسکتی ہے۔ + +* **_کھولے ہوئے_ ایشوز اور _opened_ پل کی درخواستوں کی تعداد:** کھولے گئے مسائل کا مطلب ہے کہ کوئی مسئلہ کھولنے کے لیے آپ کے پروجیکٹ کا کافی خیال رکھتا ہے۔ اگر وقت کے ساتھ اس تعداد میں اضافہ ہوتا ہے، تو اس سے پتہ چلتا ہے کہ لوگ آپ کے پروجیکٹ میں دلچسپی رکھتے ہیں۔ + +* **تعاون کی اقسام:** مثال کے طور پر، کمٹ، ٹائپ کی غلطیوں یا بگس کو ٹھیک کرنا، یا کسی مسئلے پر تبصرہ کرنا۔ + + + +## مینٹینر کی سرگرمی + +آخر میں، آپ اس بات کو یقینی بنا کر لوپ کو بند کرنا چاہیں گے کہ آپ کے پروجیکٹ کے مینٹینرز موصول ہونے والے تعاون کے حجم کو سنبھالنے کے قابل ہیں۔ آخری سوال جو آپ خود سے پوچھنا چاہیں گے وہ ہے: _کیا میں (یا ہم) اپنی کمیونٹی کو جواب دے رہا ہوں؟_ + +غیر ذمہ دار مینٹینرز اوپن سورس پروجیکٹس کے لیے رکاوٹ بن جاتے ہیں۔ اگر کوئی شراکت جمع کراتا ہے لیکن دیکھ بھال کرنے والے کی طرف سے کبھی نہیں سنتا ہے، تو وہ حوصلہ شکنی محسوس کر سکتے ہیں اور چھوڑ سکتے ہیں۔ + +[موزیلا کی طرف سے تحقیق](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) تجویز کرتا ہے کہ ریپیٹننس کو برقرار رکھنے والے حقیقت میں ریپیٹرنیس کا حصہ ہے۔ + +غور کریں [ٹریک کرنے میں کہ آپ (یا کسی دوسرے مینٹینر) کو شراکت کا جواب دینے میں کتنا وقت لگتا ہے](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discuss/) چاہے کوئی مسئلہ ہو یا پل کی درخواست۔ جواب دینے کے لیے کارروائی کی ضرورت نہیں ہے۔ یہ اتنا ہی آسان ہو سکتا ہے جتنا کہ: _"آپ کی جمع کرانے کا شکریہ! میں اگلے ہفتے میں اس کا جائزہ لوں گا۔"_ + +آپ شراکت کے عمل کے مراحل کے درمیان منتقل ہونے میں لگنے والے وقت کی پیمائش بھی کر سکتے ہیں، جیسے: + +* اوسط وقت کوئی مسئلہ کھلا رہتا ہے۔ +* آیا مسائل PRs کے ذریعہ بند ہوجاتے ہیں۔ +* چاہے باسی مسائل بند ہوجائیں +* پل کی درخواست کو ضم کرنے کا اوسط وقت + +## لوگوں کے بارے میں جاننے کے لیے 📊 استعمال کریں۔ + +میٹرکس کو سمجھنے سے آپ کو ایک فعال، بڑھتا ہوا اوپن سورس پروجیکٹ بنانے میں مدد ملے گی۔ یہاں تک کہ اگر آپ ڈیش بورڈ پر ہر میٹرک کو ٹریک نہیں کرتے ہیں، تو اوپر والے فریم ورک کا استعمال کرتے ہوئے اپنی توجہ اس طرز عمل پر مرکوز کریں جس سے آپ کے پروجیکٹ کو پھلنے پھولنے میں مدد ملے گی۔ + +[CHAOSS](https://chaoss.community/) ایک خوش آئند، اوپن سورس کمیونٹی ہے جو کمیونٹی کی صحت کے لیے تجزیات، میٹرکس اور سافٹ ویئر پر مرکوز ہے۔ + diff --git a/_articles/ur/starting-a-project.md b/_articles/ur/starting-a-project.md new file mode 100644 index 00000000000..ca2d2f772cc --- /dev/null +++ b/_articles/ur/starting-a-project.md @@ -0,0 +1,357 @@ +--- +lang: en +title: اوپن سورس پروجیکٹ شروع کرنا +description: اوپن سورس کی دنیا کے بارے میں مزید جانیں اور اپنا پروجیکٹ شروع کرنے کے لیے تیار ہوجائیں۔ +class: beginners +order: 2 +image: /assets/images/cards/beginner.png +related: + - finding + - building +--- + +## اوپن سورس کا "کیا" اور "کیوں" + +تو آپ اوپن سورس کے ساتھ شروع کرنے کے بارے میں سوچ رہے ہیں؟ مبارک ہو! دنیا آپ کے تعاون کی تعریف کرتی ہے۔ آئیے اس بارے میں بات کرتے ہیں کہ اوپن سورس کیا ہے اور لوگ ایسا کیوں کرتے ہیں۔ + +### "اوپن سورس" کا کیا مطلب ہے؟ + +جب کوئی پروجیکٹ اوپن سورس ہوتا ہے، تو اس کا مطلب ہے کہ **کوئی بھی شخص کسی بھی مقصد کے لیے آپ کے پروجیکٹ کو استعمال کرنے، مطالعہ کرنے، اس میں ترمیم کرنے اور تقسیم کرنے کے لیے آزاد ہے۔** یہ اجازتیں [اوپن سورس لائسنس] (https://opensource.org) کے ذریعے نافذ کی جاتی ہیں۔ /لائسنس)۔ + +اوپن سورس طاقتور ہے کیونکہ یہ اپنانے اور تعاون کی راہ میں حائل رکاوٹوں کو کم کرتا ہے، جس سے لوگوں کو پراجیکٹس کو تیزی سے پھیلانے اور بہتر بنانے کا موقع ملتا ہے۔ اس کے علاوہ اس لیے کہ یہ صارفین کو اپنے کمپیوٹنگ کو کنٹرول کرنے کی صلاحیت فراہم کرتا ہے، جو بند سورس کے مقابلے میں ہے۔ مثال کے طور پر، اوپن سورس سافٹ ویئر استعمال کرنے والے کاروبار کے پاس کسی بند سورس وینڈر کے پروڈکٹ کے فیصلوں پر مکمل انحصار کرنے کے بجائے، سافٹ ویئر میں اپنی مرضی کے مطابق بہتری لانے کے لیے کسی کی خدمات حاصل کرنے کا اختیار ہوتا ہے۔ + +_Free software_ سے مراد پروجیکٹس کے وہی سیٹ ہیں جیسے _open source_۔ بعض اوقات آپ [یہ شرائط](https://en.wikipedia.org/wiki/Free_and_open-source_software) کو "فری اور اوپن سورس سافٹ ویئر" (FOSS) یا "مفت، آزاد اور اوپن سورس سافٹ ویئر" کے طور پر بھی دیکھیں گے۔ (فلوس)۔ _Free_اور_libre_ آزادی کا حوالہ دیتے ہیں، [قیمت نہیں](#does-open-source-mean-free-of-charge)۔ + +### لوگ اپنے کام کو اوپن سورس کیوں کرتے ہیں؟ + + + +[اس کی بہت سی وجوہات ہیں](https://ben.balter.com/2015/11/23/why-open-source/) کیوں کوئی شخص یا ادارہ کسی پروجیکٹ کو اوپن سورس کرنا چاہے گا۔ کچھ مثالوں میں شامل ہیں: + +* **تعاون:** اوپن سورس پروجیکٹس دنیا میں کسی سے بھی تبدیلیاں قبول کر سکتے ہیں۔ [Exercism](https://github.com/exercism/)، مثال کے طور پر، 350 سے زیادہ شراکت داروں کے ساتھ ایک پروگرامنگ ورزش پلیٹ فارم ہے۔ + +* **گود لینا اور دوبارہ مکس کرنا:** اوپن سورس پروجیکٹس کو کوئی بھی تقریباً کسی بھی مقصد کے لیے استعمال کرسکتا ہے۔ لوگ اسے دوسری چیزیں بنانے کے لیے بھی استعمال کر سکتے ہیں۔ [WordPress](https://github.com/WordPress)، مثال کے طور پر، [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part نامی ایک موجودہ پروجیکٹ کے کانٹے کے طور پر شروع ہوا %201/2-b2-cafelog.md)۔ + +* **شفافیت:** کوئی بھی غلطیوں یا عدم مطابقتوں کے لیے اوپن سورس پروجیکٹ کا معائنہ کر سکتا ہے۔ [بلغاریہ](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) یا [ریاستہائے متحدہ](https://sourcecode.cio) جیسی حکومتوں کے لیے شفافیت کے معاملات .gov/)، ریگولیٹڈ انڈسٹریز جیسے بینکنگ یا ہیلتھ کیئر، اور سیکیورٹی سافٹ ویئر جیسے [Let's Encrypt](https://github.com/letsencrypt)۔ + +اوپن سورس صرف سافٹ ویئر کے لیے نہیں ہے۔ آپ ڈیٹا سیٹ سے لے کر کتابوں تک سب کچھ کھول سکتے ہیں۔ آپ اور کیا اوپن سورس کر سکتے ہیں اس بارے میں خیالات کے لیے [GitHub Explore](https://github.com/explore) کو دیکھیں۔ + +### کیا اوپن سورس کا مطلب "مفت" ہے؟ + +اوپن سورس کی سب سے بڑی قرعہ اندازی یہ ہے کہ اس پر پیسہ خرچ نہیں ہوتا ہے۔ "مفت"، تاہم، اوپن سورس کی مجموعی قدر کا ایک ضمنی پروڈکٹ ہے۔ + +چونکہ [اوپن سورس لائسنس کی ضرورت ہوتی ہے](https://opensource.org/osd-annotated) جسے کوئی بھی آپ کے پروجیکٹ کو تقریباً کسی بھی مقصد کے لیے استعمال، اس میں ترمیم اور اشتراک کر سکتا ہے، اس لیے پروجیکٹ خود ہی مفت ہوتے ہیں۔ اگر اس منصوبے کے استعمال میں پیسے خرچ ہوتے ہیں، تو کوئی بھی قانونی طور پر ایک کاپی بنا سکتا ہے اور اس کے بجائے مفت ورژن استعمال کر سکتا ہے۔ + +نتیجے کے طور پر، زیادہ تر اوپن سورس پروجیکٹ مفت ہیں، لیکن "مفت" اوپن سورس کی تعریف کا حصہ نہیں ہے۔ اوپن سورس پروجیکٹس کے لیے بالواسطہ طور پر دوہری لائسنسنگ یا محدود خصوصیات کے ذریعے چارج کرنے کے طریقے موجود ہیں، جبکہ اوپن سورس کی آفیشل تعریف کی تعمیل کرتے ہوئے بھی۔ + +## کیا مجھے اپنا اوپن سورس پروجیکٹ شروع کرنا چاہیے؟ +مختصر جواب ہاں میں ہے، کیونکہ نتیجہ کچھ بھی ہو، اپنا پروجیکٹ شروع کرنا یہ جاننے کا بہترین طریقہ ہے کہ اوپن سورس کیسے کام کرتا ہے۔ + +اگر آپ نے پہلے کبھی بھی اوپن سورس شدہ پروجیکٹ کو نہیں کھولا ہے، تو آپ اس بات سے گھبرا سکتے ہیں کہ لوگ کیا کہیں گے، یا کسی کو بالکل بھی نظر آئے گا۔ اگر یہ آپ کی طرح لگتا ہے، تو آپ اکیلے نہیں ہیں! + +اوپن سورس کام کسی بھی دوسری تخلیقی سرگرمی کی طرح ہے، چاہے وہ تحریر ہو یا پینٹنگ۔ دنیا کے ساتھ اپنے کام کا اشتراک کرنا خوفناک محسوس ہوسکتا ہے، لیکن بہتر ہونے کا واحد طریقہ مشق کرنا ہے - چاہے آپ کے سامعین نہ ہوں۔ + +اگر آپ ابھی تک قائل نہیں ہیں، تو سوچیں کہ آپ کے مقاصد کیا ہو سکتے ہیں۔ + +### اپنے اہداف کا تعین کرنا + +اہداف آپ کو یہ جاننے میں مدد کر سکتے ہیں کہ کس چیز پر کام کرنا ہے، کس چیز کو نہیں کہنا ہے، اور آپ کو دوسروں سے کہاں مدد کی ضرورت ہے۔ اپنے آپ سے پوچھ کر شروع کریں، _میں اس پروجیکٹ کو اوپن سورس کیوں کر رہا ہوں؟_ + +اس سوال کا کوئی صحیح جواب نہیں ہے۔ آپ کے ایک پروجیکٹ کے لیے ایک سے زیادہ اہداف ہوسکتے ہیں، یا مختلف اہداف کے ساتھ مختلف پروجیکٹس۔ + +اگر آپ کا واحد مقصد اپنے کام کو ظاہر کرنا ہے، تو ہو سکتا ہے آپ کو تعاون بھی نہ چاہیں، اور یہاں تک کہ اپنے README میں بھی کہہ دیں۔ دوسری طرف، اگر آپ شراکت دار چاہتے ہیں، تو آپ واضح دستاویزات میں وقت لگائیں گے اور نئے آنے والوں کو خوش آئند محسوس کریں گے۔ + + + +جیسے جیسے آپ کا پروجیکٹ بڑھتا ہے، آپ کی کمیونٹی کو آپ کے کوڈ سے زیادہ کی ضرورت ہو سکتی ہے۔ مسائل کا جواب دینا، کوڈ کا جائزہ لینا، اور اپنے پروجیکٹ کی بشارت دینا اوپن سورس پروجیکٹ میں تمام اہم کام ہیں۔ + +اگرچہ آپ نان کوڈنگ کے کاموں پر جتنا وقت صرف کرتے ہیں اس کا انحصار آپ کے پروجیکٹ کے سائز اور دائرہ کار پر ہوگا، آپ کو ایک مینٹینر کے طور پر تیار رہنا چاہیے کہ وہ خود ان سے نمٹنے کے لیے یا آپ کی مدد کے لیے کسی کو تلاش کریں۔ + +**اگر آپ کسی پروجیکٹ کو اوپن سورس کرنے والی کمپنی کا حصہ ہیں،** تو یقینی بنائیں کہ آپ کے پروجیکٹ میں داخلی وسائل ہیں جو اسے پھلنے پھولنے کے لیے درکار ہیں۔ آپ اس بات کی نشاندہی کرنا چاہیں گے کہ لانچ کے بعد پراجیکٹ کو برقرار رکھنے کا ذمہ دار کون ہے، اور آپ ان کاموں کو اپنی کمیونٹی کے ساتھ کیسے بانٹیں گے۔ + +اگر آپ کو پروموشن، آپریشنز اور پراجیکٹ کو برقرار رکھنے کے لیے وقف بجٹ یا عملہ کی ضرورت ہے، تو وہ بات چیت جلد شروع کریں۔ + + + +### دوسرے منصوبوں میں تعاون کرنا + +اگر آپ کا مقصد دوسروں کے ساتھ تعاون کرنے کا طریقہ سیکھنا ہے یا یہ سمجھنا ہے کہ اوپن سورس کیسے کام کرتا ہے، تو موجودہ پروجیکٹ میں تعاون کرنے پر غور کریں۔ ایک پروجیکٹ کے ساتھ شروع کریں جسے آپ پہلے سے استعمال کرتے ہیں اور پسند کرتے ہیں۔ کسی پروجیکٹ میں تعاون اتنا ہی آسان ہوسکتا ہے جتنا کہ ٹائپ کی غلطیوں کو ٹھیک کرنا یا دستاویزات کو اپ ڈیٹ کرنا۔ + +اگر آپ اس بات کا یقین نہیں کر رہے ہیں کہ شراکت کنندہ کے طور پر کیسے شروع کیا جائے، تو ہماری [اوپن سورس میں تعاون کرنے کا طریقہ] (../how-to-contribute/) دیکھیں۔ + +## آپ کا اپنا اوپن سورس پروجیکٹ شروع کرنا + +آپ کے کام کو اوپن سورس کرنے کا کوئی بہترین وقت نہیں ہے۔ آپ کسی آئیڈیا کو اوپن سورس کر سکتے ہیں، کوئی کام جاری ہے، یا سالوں کے بند سورس ہونے کے بعد۔ + +عام طور پر، آپ کو اپنے پروجیکٹ کو اوپن سورس کرنا چاہیے جب آپ دوسروں کو اپنے کام کو دیکھنے اور اس پر رائے دینے میں راحت محسوس کریں۔ + +اس سے کوئی فرق نہیں پڑتا ہے کہ آپ اپنے پروجیکٹ کو اوپن سورس کرنے کا فیصلہ کرتے ہیں، ہر پروجیکٹ میں درج ذیل دستاویزات شامل ہونی چاہئیں: + +* [اوپن سورس لائسنس](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) +* [شریک رہنما خطوط](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [ضابطہ اخلاق](../code-of-conduct/) + +ایک دیکھ بھال کرنے والے کے طور پر، یہ اجزاء آپ کو توقعات سے بات چیت کرنے، شراکت کا نظم کرنے، اور ہر ایک کے قانونی حقوق (بشمول آپ کے اپنے) کے تحفظ میں مدد کریں گے۔ وہ آپ کے مثبت تجربہ کرنے کے امکانات کو نمایاں طور پر بڑھا دیتے ہیں۔ + +اگر آپ کا پروجیکٹ GitHub پر ہے، تو ان فائلوں کو اپنی روٹ ڈائرکٹری میں تجویز کردہ فائل ناموں کے ساتھ ڈالنے سے GitHub کو پہچاننے اور خود بخود آپ کے قارئین کے سامنے لانے میں مدد ملے گی۔ + +### لائسنس کا انتخاب + +اوپن سورس لائسنس اس بات کی ضمانت دیتا ہے کہ دوسرے آپ کے پراجیکٹ کو استعمال کر سکتے ہیں، کاپی کر سکتے ہیں، اس میں ترمیم کر سکتے ہیں اور بغیر کسی نقصان کے آپ کے پروجیکٹ میں حصہ ڈال سکتے ہیں۔ یہ آپ کو چپچپا قانونی حالات سے بھی بچاتا ہے۔ **آپ کو اوپن سورس پروجیکٹ شروع کرتے وقت لائسنس شامل کرنا ہوگا۔** + +قانونی کام کوئی مزہ نہیں ہے۔ اچھی خبر یہ ہے کہ آپ موجودہ لائسنس کو اپنے ذخیرے میں کاپی اور پیسٹ کر سکتے ہیں۔ آپ کی محنت کی حفاظت میں صرف ایک منٹ لگے گا۔ + +[MIT](https://choosealicense.com/licenses/mit/)، [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/)، اور [GPLv3](https://choosealicense. com/licenses/gpl-3.0/) سب سے زیادہ مقبول اوپن سورس لائسنس ہیں، لیکن [دوسرے اختیارات ہیں](https://choosealicense.com) میں سے انتخاب کریں۔ + +جب آپ GitHub پر ایک نیا پروجیکٹ بناتے ہیں، تو آپ کو لائسنس منتخب کرنے کا اختیار دیا جاتا ہے۔ اوپن سورس لائسنس کو شامل کرنا آپ کے GitHub پروجیکٹ کو اوپن سورس بنا دے گا۔ + +![لائسنس چنیں](/assets/images/starting-a-project/repository-license-picker.png) + +اگر آپ کے پاس اوپن سورس پروجیکٹ کے انتظام کے قانونی پہلوؤں کے بارے میں دیگر سوالات یا خدشات ہیں تو، [ہم نے آپ کو کور کر لیا ہے](../legal/)۔ + +### ایک README لکھنا + +READMEs آپ کے پروجیکٹ کو استعمال کرنے کے طریقے کی وضاحت سے زیادہ کام کرتے ہیں۔ وہ یہ بھی بتاتے ہیں کہ آپ کا پروجیکٹ کیوں اہمیت رکھتا ہے، اور آپ کے صارفین اس کے ساتھ کیا کر سکتے ہیں۔ + +اپنے README میں، درج ذیل سوالات کے جواب دینے کی کوشش کریں: + +* یہ پروجیکٹ کیا کرتا ہے؟ +* یہ منصوبہ مفید کیوں ہے؟ +* میں کیسے شروع کروں؟ +* اگر مجھے ضرورت ہو تو مجھے مزید مدد کہاں سے مل سکتی ہے؟ + +آپ اپنے README کو دوسرے سوالات کے جوابات دینے کے لیے استعمال کر سکتے ہیں، جیسے کہ آپ شراکت کو کیسے ہینڈل کرتے ہیں، پروجیکٹ کے مقاصد کیا ہیں، اور لائسنس اور انتساب کے بارے میں معلومات۔ اگر آپ شراکتیں قبول نہیں کرنا چاہتے، یا آپ کا پروجیکٹ ابھی پروڈکشن کے لیے تیار نہیں ہے، تو یہ معلومات لکھ دیں۔ + + + +بعض اوقات، لوگ README لکھنے سے گریز کرتے ہیں کیونکہ انہیں لگتا ہے کہ پروجیکٹ نامکمل ہے، یا وہ شراکت نہیں چاہتے ہیں۔ یہ سب ایک لکھنے کی بہت اچھی وجوہات ہیں۔ + +مزید حوصلہ افزائی کے لیے، @dguo کی ["ReADME بنائیں" گائیڈ](https://www.makeareadme.com/) یا @PurpleBooth کی [README ٹیمپلیٹ](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) استعمال کرنے کی کوشش کریں۔ مکمل README لکھنے کے لیے۔ + +جب آپ روٹ ڈائرکٹری میں README فائل شامل کرتے ہیں، تو GitHub اسے خودکار طور پر ریپوزٹری ہوم پیج پر ظاہر کرے گا۔ + +### اپنے تعاون کے رہنما خطوط لکھنا + +ایک CONTRIBUTING فائل آپ کے سامعین کو بتاتی ہے کہ آپ کے پروجیکٹ میں کیسے حصہ لیا جائے۔ مثال کے طور پر، آپ اس پر معلومات شامل کر سکتے ہیں: + +* بگ رپورٹ کیسے درج کی جائے (استعمال کرنے کی کوشش کریں [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates)) +* ایک نئی خصوصیت کی تجویز کیسے کریں۔ +* اپنے ماحول کو ترتیب دینے اور ٹیسٹ چلانے کا طریقہ + +تکنیکی تفصیلات کے علاوہ، ایک CONTRIBUTING فائل شراکت کے لیے آپ کی توقعات کو بتانے کا ایک موقع ہے، جیسے: + +* شراکت کی وہ اقسام جن کی آپ تلاش کر رہے ہیں۔ +* منصوبے کے لیے آپ کا روڈ میپ یا وژن +* تعاون کرنے والوں کو آپ سے کس طرح رابطہ کرنا چاہیے (یا نہیں ہونا چاہیے) + +گرمجوشی، دوستانہ لہجے کا استعمال کرنا اور شراکت کے لیے مخصوص تجاویز پیش کرنا (جیسے دستاویزات لکھنا، یا ویب سائٹ بنانا) نئے آنے والوں کو شرکت کرنے کے لیے خوش آئند اور پرجوش محسوس کرنے میں ایک طویل سفر طے کر سکتا ہے۔ + +مثال کے طور پر، [ایکٹو ایڈمن](https://github.com/activeadmin/activeadmin/) شروع کرتا ہے [اس کا تعاون کرنے والی گائیڈ](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) کے ساتھ: + +> سب سے پہلے، ایکٹو ایڈمن میں تعاون کرنے پر غور کرنے کے لیے آپ کا شکریہ۔ یہ آپ جیسے لوگ ہیں جو ایکٹو ایڈمن کو ایک بہترین ٹول بناتے ہیں۔ + +آپ کے پروجیکٹ کے ابتدائی مراحل میں، آپ کی CONTRIBUTING فائل آسان ہو سکتی ہے۔ آپ کو ہمیشہ یہ بتانا چاہیے کہ کیڑے یا فائل کے مسائل کی اطلاع کیسے دی جائے، اور شراکت کرنے کے لیے کوئی تکنیکی تقاضے (جیسے ٹیسٹ)۔ + +وقت گزرنے کے ساتھ، آپ اپنی CONTRIBUTING فائل میں دوسرے اکثر پوچھے گئے سوالات شامل کر سکتے ہیں۔ اس معلومات کو لکھنے کا مطلب ہے کہ بہت کم لوگ آپ سے وہی سوالات بار بار پوچھیں گے۔ + +اپنی CONTRIBUTING فائل لکھنے میں مزید مدد کے لیے، @nayafia کا [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) یا @mozilla کا ["کیسے کرنا ایک CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) بنائیں۔ + +اپنے README سے اپنی CONTRIBUTING فائل سے لنک کریں، تاکہ زیادہ لوگ اسے دیکھ سکیں۔ اگر آپ [کونٹریبیوٹنگ فائل کو اپنے پروجیکٹ کے ریپوزٹری میں رکھتے ہیں] یا پل کی درخواست کھولتا ہے۔ + +! + +### ضابطہ اخلاق کا قیام + + + + +آخر میں، ضابطہ اخلاق آپ کے پروجیکٹ کے شرکاء کے لیے رویے کے لیے بنیادی اصول طے کرنے میں مدد کرتا ہے۔ یہ خاص طور پر قابل قدر ہے اگر آپ کسی کمیونٹی یا کمپنی کے لیے اوپن سورس پروجیکٹ شروع کر رہے ہیں۔ ایک ضابطہ اخلاق آپ کو صحت مند، تعمیری کمیونٹی کے رویے میں سہولت فراہم کرنے کا اختیار دیتا ہے، جس سے ایک مینٹینر کے طور پر آپ کے تناؤ کو کم کیا جائے گا۔ + +مزید معلومات کے لیے، ہماری [کوڈ آف کنڈکٹ گائیڈ](../code-of-conduct/) دیکھیں۔ + +بات چیت کرنے کے علاوہ کہ آپ شرکاء سے برتاؤ کی توقع کرتے ہیں، ایک ضابطہ اخلاق یہ بھی بیان کرتا ہے کہ یہ توقعات کس پر لاگو ہوتی ہیں، کب وہ لاگو ہوتی ہیں، اور اگر خلاف ورزی ہوتی ہے تو کیا کرنا چاہیے۔ + +اوپن سورس لائسنس کی طرح، ضابطہ اخلاق کے لیے بھی ابھرتے ہوئے معیارات ہیں، لہذا آپ کو خود لکھنے کی ضرورت نہیں ہے۔ [Contributor Covenant](https://contributor-covenant.org/) ایک ڈراپ ان ضابطہ اخلاق ہے جسے [40,000 سے زیادہ اوپن سورس پروجیکٹس] (https://www.contributor-covenant.org/adopters) کے ذریعے استعمال کیا جاتا ہے )، بشمول Kubernetes، Rails، اور Swift۔ اس سے کوئی فرق نہیں پڑتا ہے کہ آپ جو بھی متن استعمال کرتے ہیں، آپ کو ضرورت پڑنے پر اپنے ضابطہ اخلاق کو نافذ کرنے کے لیے تیار رہنا چاہیے۔ + +متن کو براہ راست اپنے ذخیرہ میں CODE_OF_CONDUCT فائل میں چسپاں کریں۔ فائل کو اپنے پروجیکٹ کی روٹ ڈائرکٹری میں رکھیں تاکہ اسے تلاش کرنا آسان ہو، اور اسے اپنے README سے لنک کریں۔ + +## اپنے پروجیکٹ کا نام اور برانڈنگ + +برانڈنگ ایک چمکدار لوگو یا پرکشش پروجیکٹ کے نام سے زیادہ ہے۔ یہ اس بارے میں ہے کہ آپ اپنے پروجیکٹ کے بارے میں کیسے بات کرتے ہیں، اور آپ اپنے پیغام کے ساتھ کس تک پہنچتے ہیں۔ + +### صحیح نام کا انتخاب + +ایک ایسا نام منتخب کریں جو یاد رکھنے میں آسان ہو اور مثالی طور پر، پروجیکٹ کے کام کے بارے میں کچھ اندازہ ہو۔ مثال کے طور پر: + +* [Sentry](https://github.com/getsentry/sentry) کریش رپورٹنگ کے لیے ایپس کی نگرانی کرتا ہے +* [تھن](https://github.com/macournoyer/thin) ایک تیز اور آسان روبی ویب سرور ہے + +اگر آپ کسی موجودہ پروجیکٹ پر تعمیر کر رہے ہیں، تو ان کے نام کو بطور سابقہ ​​استعمال کرنے سے یہ واضح کرنے میں مدد مل سکتی ہے کہ آپ کا پروجیکٹ کیا کرتا ہے (مثال کے طور پر، [node-fetch](https://github.com/bitinn/node-fetch) ونڈو لاتا ہے Node.js پر .fetch)۔ + +سب سے بڑھ کر وضاحت پر غور کریں۔ پینس تفریحی ہیں، لیکن یاد رکھیں کہ کچھ لطیفے دوسری ثقافتوں یا آپ کے مختلف تجربات والے لوگوں کے لیے ترجمہ نہیں کر سکتے۔ آپ کے ممکنہ صارفین میں سے کچھ کمپنی کے ملازمین ہو سکتے ہیں: جب انہیں کام پر آپ کے پروجیکٹ کی وضاحت کرنی ہو تو آپ انہیں بے چین نہیں کرنا چاہتے! + +### نام کے تنازعات سے بچنا + +[اسی طرح کے نام کے ساتھ اوپن سورس پروجیکٹس کو چیک کریں](http://ivantomic.com/projects/ospnc/)، خاص طور پر اگر آپ ایک ہی زبان یا ماحولیاتی نظام کا اشتراک کرتے ہیں۔ اگر آپ کا نام کسی مشہور موجودہ پروجیکٹ کے ساتھ اوورلیپ ہوتا ہے، تو آپ اپنے سامعین کو الجھ سکتے ہیں۔ + +اگر آپ چاہتے ہیں کہ کوئی ویب سائٹ، ٹویٹر ہینڈل، یا دیگر پراپرٹیز آپ کے پروجیکٹ کی نمائندگی کریں، تو یقینی بنائیں کہ آپ اپنے مطلوبہ نام حاصل کر سکتے ہیں۔ مثالی طور پر، ذہنی سکون کے لیے [ان ناموں کو ابھی محفوظ کریں](https://instantdomainsearch.com/)، چاہے آپ ابھی ان کو استعمال کرنے کا ارادہ نہیں رکھتے۔ + +یقینی بنائیں کہ آپ کے پروجیکٹ کا نام کسی ٹریڈ مارک کی خلاف ورزی نہیں کرتا ہے۔ کوئی کمپنی آپ کو بعد میں اپنا پروجیکٹ ختم کرنے کے لیے کہہ سکتی ہے، یا آپ کے خلاف قانونی کارروائی بھی کر سکتی ہے۔ یہ صرف خطرے کے قابل نہیں ہے۔ + +آپ ٹریڈ مارک کے تنازعات کے لیے [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) کو چیک کر سکتے ہیں۔ اگر آپ کسی کمپنی میں ہیں، تو یہ ان چیزوں میں سے ایک ہے جس میں آپ کی [قانونی ٹیم آپ کی مدد کر سکتی ہے](../legal/)۔ + +آخر میں، اپنے پروجیکٹ کے نام کے لیے فوری گوگل سرچ کریں۔ کیا لوگ آپ کے پروجیکٹ کو آسانی سے تلاش کر سکیں گے؟ کیا تلاش کے نتائج میں کچھ اور ظاہر ہوتا ہے جسے آپ نہیں چاہیں گے کہ وہ دیکھیں؟ + +### آپ کیسے لکھتے ہیں (اور کوڈ) آپ کے برانڈ کو بھی متاثر کرتا ہے! + +اپنے پروجیکٹ کی پوری زندگی میں، آپ بہت ساری تحریریں کریں گے: READMEs، سبق، کمیونٹی دستاویزات، مسائل کا جواب دینا، شاید نیوز لیٹر اور میلنگ لسٹ بھی۔ + +چاہے یہ آفیشل دستاویزات ہوں یا کوئی معمولی ای میل، آپ کا تحریری انداز آپ کے پروجیکٹ کے برانڈ کا حصہ ہے۔ اس بات پر غور کریں کہ آپ اپنے سامعین تک کیسے پہنچ سکتے ہیں اور کیا یہ وہی لہجہ ہے جسے آپ بیان کرنا چاہتے ہیں۔ + + + +گرم، جامع زبان کا استعمال (جیسے "وہ"، یہاں تک کہ جب ایک فرد کا حوالہ دے رہے ہوں) آپ کے پروجیکٹ کو نئے شراکت داروں کا خیرمقدم کرنے کا احساس دلانے میں بہت آگے جا سکتا ہے۔ سادہ زبان پر قائم رہیں، کیونکہ ہو سکتا ہے آپ کے بہت سے قارئین مقامی انگریزی بولنے والے نہ ہوں۔ + +آپ الفاظ کیسے لکھتے ہیں اس کے علاوہ، آپ کا کوڈنگ کا انداز بھی آپ کے پروجیکٹ کے برانڈ کا حصہ بن سکتا ہے۔ [Angular](https://angular.io/guide/styleguide) اور [jQuery](https://contribute.jquery.org/style-guide/js/) کوڈنگ کے سخت انداز اور رہنما خطوط کے ساتھ پروجیکٹس کی دو مثالیں ہیں۔ + +یہ ضروری نہیں ہے کہ آپ اپنے پروجیکٹ کے لیے اسٹائل گائیڈ لکھیں جب آپ ابھی شروعات کر رہے ہوں، اور آپ کو معلوم ہو سکتا ہے کہ آپ اپنے پروجیکٹ میں مختلف کوڈنگ اسٹائلز کو شامل کرنے سے لطف اندوز ہوتے ہیں۔ لیکن آپ کو اندازہ لگانا چاہیے کہ آپ کی تحریر اور کوڈنگ کا انداز مختلف قسم کے لوگوں کو کس طرح اپنی طرف متوجہ یا حوصلہ شکنی کر سکتا ہے۔ آپ کے پروجیکٹ کے ابتدائی مراحل آپ کے لیے وہ نظیر قائم کرنے کا موقع ہیں جسے آپ دیکھنا چاہتے ہیں۔ + +## آپ کی پری لانچ چیک لسٹ + +اپنے پروجیکٹ کو اوپن سورس کرنے کے لیے تیار ہیں؟ مدد کے لیے یہاں ایک چیک لسٹ ہے۔ تمام خانوں کو چیک کریں؟ آپ جانے کے لیے تیار ہیں! ["شائع کریں" پر کلک کریں](https://help.github.com/articles/making-a-private-repository-public/) اور اپنے آپ کو پیٹھ پر تھپتھپائیں۔ + +**دستاویزات** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**کوڈ** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**لوگ** + +اگر آپ ایک فرد ہیں: + +
+ + +
+ +اگر آپ ایک کمپنی یا تنظیم ہیں: + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## تم نے یہ کیا! + +آپ کے پہلے پروجیکٹ کو اوپن سورس کرنے پر مبارکباد۔ نتائج سے کوئی فرق نہیں پڑتا، عوام میں کام کرنا کمیونٹی کے لیے ایک تحفہ ہے۔ ہر عزم، تبصرہ، اور پل کی درخواست کے ساتھ، آپ اپنے لیے اور دوسروں کے لیے سیکھنے اور بڑھنے کے مواقع پیدا کر رہے ہیں۔ \ No newline at end of file