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/) تو آپ کے پاس ریپوزٹری کو **نجی** یا **عوامی بنانے کا اختیار ہوتا ہے۔ **
+
+
+
+**اپنے 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 کا استعمال کیسے، کہاں اور کب کرتے ہیں۔
+
+مقبولیت ہی سب کچھ نہیں ہے۔ ہر کوئی مختلف وجوہات کی بنا پر اوپن سورس میں آتا ہے۔ اگر اوپن سورس مینٹینر کے طور پر آپ کا مقصد آپ کے کام کو ظاہر کرنا، اپنے کوڈ کے بارے میں شفاف ہونا، یا صرف مزہ کرنا ہے، تو میٹرکس آپ کے لیے اہم نہیں ہو سکتے۔
+
+اگر آپ اپنے پروجیکٹ کو گہری سطح پر سمجھنے میں دلچسپی رکھتے ہیں، تو اپنے پروجیکٹ کی سرگرمی کا تجزیہ کرنے کے طریقے پڑھیں۔
+
+## دریافت
+
+اس سے پہلے کہ کوئی بھی آپ کے پروجیکٹ کو استعمال کر سکے یا اس میں حصہ ڈال سکے، انہیں یہ جاننے کی ضرورت ہے کہ یہ موجود ہے۔ اپنے آپ سے پوچھیں: _کیا لوگ اس پروجیکٹ کو تلاش کر رہے ہیں؟_
+
+
+
+اگر آپ کا پروجیکٹ 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) کا استعمال کر سکتے ہیں کہ آپ کے پروجیکٹ کو ایک مخصوص دن میں کتنی بار کلون کیا گیا ہے، کل کلون اور منفرد کلونرز کے حساب سے ٹوٹا ہوا ہے۔
+
+
+
+اگر آپ کے پروجیکٹ کو دریافت کرنے والے لوگوں کی تعداد کے مقابلے میں استعمال کم ہے، تو غور کرنے کے لیے دو مسائل ہیں۔ یا تو:
+
+* آپ کا پروجیکٹ کامیابی سے آپ کے سامعین کو تبدیل نہیں کر رہا ہے، یا
+* آپ غلط سامعین کو اپنی طرف متوجہ کر رہے ہیں۔
+
+مثال کے طور پر، اگر آپ کا پراجیکٹ ہیکر نیوز کے صفحہ اول پر آتا ہے، تو آپ کو ممکنہ طور پر دریافت (ٹریفک) میں اضافہ، لیکن تبادلوں کی شرح کم نظر آئے گی، کیونکہ آپ ہیکر نیوز پر ہر کسی تک پہنچ رہے ہیں۔ اگر آپ کے روبی پروجیکٹ کو روبی کانفرنس میں نمایاں کیا گیا ہے، تاہم، آپ کو ہدف بنائے گئے سامعین سے زیادہ تبادلوں کی شرح دیکھنے کا زیادہ امکان ہے۔
+
+یہ جاننے کی کوشش کریں کہ آپ کے سامعین کہاں سے آرہے ہیں اور اپنے پروجیکٹ کے صفحے پر دوسروں سے رائے طلب کریں تاکہ یہ معلوم کیا جا سکے کہ آپ کو ان دو مسائل میں سے کس کا سامنا ہے۔
+
+ایک بار جب آپ کو معلوم ہو جائے کہ لوگ آپ کے پروجیکٹ کو استعمال کر رہے ہیں، تو آپ یہ جاننے کی کوشش کر سکتے ہیں کہ وہ اس کے ساتھ کیا کر رہے ہیں۔ کیا وہ آپ کے کوڈ کو فورک کرکے اور خصوصیات شامل کرکے اس پر تعمیر کررہے ہیں؟ کیا وہ اسے سائنس یا کاروبار کے لیے استعمال کر رہے ہیں؟
+
+## برقرار رکھنا
+
+لوگ آپ کے پروجیکٹ کو تلاش کر رہے ہیں اور وہ اسے استعمال کر رہے ہیں۔ اگلا سوال جو آپ اپنے آپ سے پوچھنا چاہیں گے وہ ہے: _کیا لوگ اس پروجیکٹ میں حصہ ڈال رہے ہیں؟_
+
+تعاون کرنے والوں کے بارے میں سوچنا شروع کرنے میں کبھی جلدی نہیں ہوتی۔ دوسرے لوگوں کے اندر آنے کے بغیر، آپ اپنے آپ کو ایک غیر صحت بخش صورتحال میں ڈالنے کا خطرہ مول لیتے ہیں جہاں آپ کا پروجیکٹ _popular_ ہے (بہت سے لوگ اسے استعمال کرتے ہیں) لیکن _supported_ نہیں (مطالبہ کو پورا کرنے کے لیے مینٹینر کا کافی وقت نہیں)۔
+
+برقرار رکھنے کے لیے [نئے تعاون کنندگان کی آمد] (http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2) کی بھی ضرورت ہوتی ہے، جیسا کہ پہلے فعال شراکت دار آخر کار آگے بڑھیں گے۔ دوسری چیزوں کو.
+
+کمیونٹی میٹرکس کی مثالیں جنہیں آپ باقاعدگی سے ٹریک کرنا چاہتے ہیں ان میں شامل ہیں:
+
+* **مطلوبہ کنٹریبیوٹر کی کل تعداد اور فی کنٹریبیوٹر کی تعداد:** آپ کو بتاتا ہے کہ آپ کے پاس کتنے کنٹریبیوٹر ہیں اور کون کم یا زیادہ فعال ہے۔ GitHub پر، آپ اسے "Insights" -> "Contributors" کے تحت دیکھ سکتے ہیں۔ ابھی، یہ گراف صرف ان شراکت داروں کو شمار کرتا ہے جنہوں نے ریپوزٹری کی ڈیفالٹ برانچ سے وابستگی کی ہے۔
+
+
+
+* **پہلی بار، آرام دہ اور بار بار تعاون کرنے والے:** آپ کو یہ ٹریک کرنے میں مدد کرتا ہے کہ آیا آپ کو نئے تعاون کنندگان مل رہے ہیں، اور آیا وہ واپس آتے ہیں۔ (آرام دہ تعاون کرنے والے کمٹ کی تعداد کے ساتھ شراکت دار ہوتے ہیں۔ چاہے وہ ایک کمٹ، پانچ سے کم کمٹ، یا کچھ اور آپ پر منحصر ہے۔) نئے تعاون کنندگان کے بغیر، آپ کے پروجیکٹ کی کمیونٹی جمود کا شکار ہو سکتی ہے۔
+
+* **اوپن ایشوز اور اوپن پل کی درخواستوں کی تعداد:** اگر یہ تعداد بہت زیادہ ہوجاتی ہے، تو آپ کو ایشو ٹریجنگ اور کوڈ کے جائزوں میں مدد کی ضرورت پڑسکتی ہے۔
+
+* **_کھولے ہوئے_ ایشوز اور _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 پروجیکٹ کو اوپن سورس بنا دے گا۔
+
+
+
+اگر آپ کے پاس اوپن سورس پروجیکٹ کے انتظام کے قانونی پہلوؤں کے بارے میں دیگر سوالات یا خدشات ہیں تو، [ہم نے آپ کو کور کر لیا ہے](../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