Add Urdu translation

Author: rohaanmd

_articles/ur/best-practices.md

@@ -0,0 +1,108 @@
+---
+lang: ur
+title: خوش آمدید کہنے والی کمیونٹیز بنانا
+description: ایسی کمیونٹی بنانا جو لوگوں کو آپ کے پروجیکٹ کو استعمال کرنے، تعاون کرنے، اور پرچار کرنے کی ترغیب دے۔
+class: building
+order: 4
+image: /assets/images/cards/building.png
+related:
+  - best-practices
+  - coc
+---
+
+<div dir="rtl">
+
+## اپنے پروجیکٹ کو کامیاب بنانے کے لیے تیار کرنا
+
+آپ نے اپنا پروجیکٹ لانچ کر دیا، آپ اس کی تشہیر کر رہے ہیں، اور لوگ اسے دیکھ رہے ہیں۔ شاندار! اب، آپ انہیں کس طرح مستقل رکھنے کا ارادہ رکھتے ہیں؟
+
+ایک خوش آمدید کہنے والی کمیونٹی آپ کے پروجیکٹ کے مستقبل اور شہرت میں سرمایہ کاری ہے۔ اگر آپ کا پروجیکٹ ابھی پہلی بار تعاون دیکھ رہا ہے، تو ابتدائی شراکت داروں کو مثبت تجربہ فراہم کریں، اور انہیں واپس آنے میں آسانی پیدا کریں۔
+
+### لوگوں کو خوش آمدید محسوس کرائیں
+
+آپ اپنے پروجیکٹ کی کمیونٹی کو اس طرح دیکھ سکتے ہیں جیسا کہ @MikeMcQuaid نے [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/) کہا:
+
+![Contributor funnel starts with users, then contributors, then maintainers.](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
+
+جب آپ اپنی کمیونٹی بنا رہے ہیں، تو غور کریں کہ کسی شخص (ممکنہ صارف) کے لیے فَنل کے اوپر سے نیچے (فعال مینٹینر) تک پہنچنا کیسے ممکن ہے۔ آپ کا مقصد ہر مرحلے میں رکاوٹ کو کم کرنا ہے۔ جب لوگ آسان کامیابیاں حاصل کرتے ہیں، تو وہ مزید کرنے کے لیے ترغیب محسوس کریں گے۔
+
+اپنی دستاویزات سے شروع کریں:
+
+* **کسی کے لیے پروجیکٹ استعمال کرنا آسان بنائیں۔** [دوست دار README](../starting-a-project/#writing-a-readme) اور واضح کوڈ مثالیں کسی کے لیے بھی پروجیکٹ شروع کرنا آسان بنائیں گی۔
+* **وضاحت سے بتائیں کہ تعاون کیسے کریں،** [CONTRIBUTING فائل](../starting-a-project/#writing-your-contributing-guidelines) استعمال کریں اور اپنے مسائل کو اپ ڈیٹ رکھیں۔
+* **ابتدائی مسائل:** نئے شراکت داروں کو شروع کرنے میں مدد دینے کے لیے، [ان مسائل کو واضح طور پر لیبل کریں جو ابتدائیوں کے لیے آسان ہیں](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels)۔ GitHub پھر انہیں مختلف جگہوں پر دکھائے گا، مفید تعاون بڑھائے گا، اور صارفین کے لیے پیچیدہ مسائل سے رکاوٹ کم کرے گا۔
+
+[GitHub کا 2017 Open Source Survey](http://opensourcesurvey.org/2017/) ظاہر کرتا ہے کہ نامکمل یا الجھی ہوئی دستاویزات اوپن سورس صارفین کے لیے سب سے بڑا مسئلہ ہیں۔ اچھی دستاویزات لوگوں کو آپ کے پروجیکٹ کے ساتھ بات چیت کی دعوت دیتی ہیں۔ آخر میں، کوئی مسئلہ یا پل ریکویسٹ کھولے گا۔ ان تعاملات کو فَنل کے نیچے لے جانے کے مواقع کے طور پر استعمال کریں۔
+
+* **جب کوئی نیا آپ کے پروجیکٹ پر آئے، تو ان کا شکریہ ادا کریں!** ایک منفی تجربہ کافی ہے کہ کوئی واپس نہ آئے۔
+* **جواب دینے والا بنیں۔** اگر آپ ایک ماہ تک ان کے مسئلے کا جواب نہیں دیتے، تو امکان ہے کہ وہ پہلے ہی آپ کے پروجیکٹ کو بھول چکے ہوں۔
+* **قبول کرنے والے تعاون کی اقسام کے بارے میں کھلے دماغ رکھیں۔** بہت سے شراکت دار ایک بگ رپورٹ یا چھوٹی اصلاح سے شروع کرتے ہیں۔ پروجیکٹ میں [شراکت کرنے کے بہت سے طریقے](../how-to-contribute/#what-it-means-to-contribute) ہیں۔ لوگوں کو وہ کرنے دیں جو وہ کرنا چاہتے ہیں۔
+* **اگر کوئی تعاون آپ کے مطابق نہیں ہے،** ان کے خیال کا شکریہ ادا کریں اور [وضاحت کریں کہ یہ پروجیکٹ کے دائرہ کار میں کیوں نہیں آتا](../best-practices/#learning-to-say-no)۔
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/mikeal?s=180" class="pquote-avatar" alt="">
+  کچھ لوگوں کے لیے اوپن سورس میں تعاون کرنا آسان ہے اور کچھ کے لیے مشکل۔ بہت سے لوگ غلط کرنے یا فٹ نہ ہونے کے خوف سے ہچکچاتے ہیں۔ (...) ابتدائی سطح کی تکنیکی مہارت (دستاویزات، ویب مواد، مارک ڈاؤن وغیرہ) کے لیے تعاون کی جگہ دے کر آپ یہ خدشات کم کر سکتے ہیں۔
+  <p markdown="1" class="pquote-credit">
+— @mikeal, ["Modern Open Source میں contributor base بڑھانا"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)
+  </p>
+</aside>
+
+زیادہ تر اوپن سورس شراکت دار "casual contributors" ہیں: جو کبھی کبھار ہی تعاون کرتے ہیں۔ ایک casual contributor آپ کے پروجیکٹ کو مکمل طور پر سمجھنے کے لیے وقت نہیں رکھتا، لہذا آپ کا کام ہے کہ انہیں آسانی سے تعاون کرنے کا موقع دیں۔
+
+دوسرے شراکت داروں کو بڑھاوا دینا بھی آپ میں سرمایہ کاری ہے۔ جب آپ اپنے سب سے بڑے مداحوں کو اس کام کے لیے اختیار دیتے ہیں جو وہ کرنا چاہتے ہیں، تو سب کچھ خود کرنے کا دباؤ کم ہو جاتا ہے۔
+
+### سب کچھ دستاویزی بنائیں
+
+<aside markdown="1" class="pquote">
+  <img src="https://avatars.githubusercontent.com/janl?s=180" class="pquote-avatar" alt="">
+  کبھی کسی (ٹیک) ایونٹ میں گئے ہیں جہاں آپ کسی کو نہیں جانتے، لیکن سب گروپ میں کھڑے اور بات کر رہے ہیں؟ (...) اب تصور کریں کہ آپ اوپن سورس پروجیکٹ میں تعاون کرنا چاہتے ہیں، لیکن یہ سمجھ نہیں آ رہا کہ یہ کیسے ہو رہا ہے۔
+  <p markdown="1" class="pquote-credit">
+— @janl, ["Sustainable Open Source"](https://web.archive.org/web/20200723213552/https://writing.jan.io/2015/11/20/sustainable-open-source.html)
+  </p>
+</aside>
+
+جب آپ نیا پروجیکٹ شروع کرتے ہیں، تو کام کو نجی رکھنا فطری لگتا ہے۔ لیکن اوپن سورس پروجیکٹس اس وقت کامیاب ہوتے ہیں جب آپ اپنے عمل کو عوامی طور پر دستاویزی بنائیں۔
+
+جب آپ چیزیں لکھتے ہیں، تو زیادہ لوگ ہر قدم پر حصہ لے سکتے ہیں۔ آپ کو مدد مل سکتی ہے جس کی آپ کو ضرورت بھی نہیں معلوم تھی۔
+
+چیزیں لکھنا صرف تکنیکی دستاویزات سے زیادہ ہے۔ جب بھی آپ کچھ لکھنے یا نجی طور پر بات کرنے کا ارادہ کریں، سوچیں کہ کیا آپ اسے عوامی بنا سکتے ہیں۔
+
+اپنے پروجیکٹ کے روڈ میپ، تعاون کی اقسام، جائزہ لینے کا طریقہ، یا کسی فیصلے کے پیچھے وجہ کے بارے میں شفاف رہیں۔
+
+اگر آپ دیکھیں کہ متعدد صارفین ایک ہی مسئلے کا سامنا کر رہے ہیں، تو جواب README میں دستاویزی کریں۔
+
+میٹنگز کے لیے، اپنے نوٹس یا نتائج کو متعلقہ مسئلے میں شائع کرنے پر غور کریں۔ اس شفافیت سے آپ کو جو فیڈ بیک ملے گا، وہ حیران کن ہو سکتا ہے۔
+
+سب کچھ دستاویزی بنانا آپ کے کام پر بھی لاگو ہوتا ہے۔ اگر آپ پروجیکٹ میں کوئی بڑا اپڈیٹ کر رہے ہیں، تو اسے پل ریکویسٹ میں رکھیں اور WIP نشان زد کریں۔ اس طرح، دوسرے لوگ ابتدائی طور پر عمل میں شامل ہو سکتے ہیں۔
+
+### جواب دینے والا بنیں
+
+جب آپ [اپنے پروجیکٹ کی تشہیر](../finding-users) کرتے ہیں، لوگ آپ کو فیڈ بیک دیں گے۔ وہ سوالات پوچھ سکتے ہیں یا مدد چاہتے ہیں۔
+
+کوشش کریں کہ جب کوئی مسئلہ فائل کرے، پل ریکویسٹ جمع کرے، یا سوال پوچھے، تو جواب دیں۔ جلد جواب دینے سے لوگ بات چیت کا حصہ محسوس کریں گے اور زیادہ پرجوش ہوں گے۔
+
+اگر آپ فوری طور پر جائزہ نہیں لے سکتے، تو اسے جلدی تسلیم کرنا مصروفیت بڑھانے میں مدد دیتا ہے۔
+
+![Middleman PR example](/assets/images/building-community/middleman_pr.png)
+
+[Mozilla کے مطالعے سے معلوم ہوا](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) کہ 48 گھنٹے کے اندر کوڈ ریویو حاصل کرنے والے شراکت داروں کی واپسی اور دوبارہ تعاون کی شرح زیادہ تھی۔
+
+آپ کے پروجیکٹ کے بارے میں گفتگو دوسرے مقامات پر بھی ہو سکتی ہے، جیسے Stack Overflow، Twitter، یا Reddit۔ کچھ جگہوں پر نوٹیفیکیشن سیٹ کریں تاکہ جب کوئی آپ کے پروجیکٹ کا ذکر کرے، تو آپ کو اطلاع ملے۔
+
+### کمیونٹی کو اجتماع کی جگہ دیں
+
+کمیونٹی کو اجتماع کی جگہ دینے کی دو وجوہات ہیں:
+
+پہلی وجہ ان کے لیے ہے۔ لوگوں کو ایک دوسرے کو جاننے میں مدد کریں۔ مشترکہ دلچسپی رکھنے والے لوگ بات کرنے کے لیے جگہ چاہتے ہیں۔ جب بات چیت عوامی اور قابل رسائی ہو، تو کوئی بھی پچھلے ارکائیوز دیکھ سکتا ہے۔
+
+دوسری وجہ آپ کے لیے ہے۔ اگر آپ لوگوں کو عوامی جگہ نہ دیں، تو وہ آپ سے براہ راست رابطہ کریں گے۔ شروع میں، یہ آسان لگتا ہے "صرف اس بار" نجی پیغام کا جواب دینا۔ لیکن وقت کے ساتھ، خاص طور پر اگر پروجیکٹ مقبول ہو، آپ تھک جائیں گے۔ لوگوں کو نجی بات چیت کرنے سے منع کریں، اور انہیں عوامی چینل پر بھیجیں۔
+
+عوامی بات چیت اتنی آسان ہو سکتی ہے کہ لوگ براہ راست ای میل کرنے کے بجائے مسئلہ کھولیں۔ آپ میلنگ لسٹ، Twitter، Slack، یا IRC چینل بھی بنا سکتے ہیں۔ یا سب استعمال کریں!
+
+[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) ہر دوسرے ہفتے کمیونٹی کے لیے آفس آور رکھتا ہے:
+
+> Kops ہر دوسرے ہفتے کمیونٹی کے لیے مدد اور رہنمائی کے لیے وقت مخصوص کرتا ہے۔ مینٹینرز نے طے کیا ہے کہ وہ نئے آنے والوں کے ساتھ کام کرنے، PRs میں مدد کرنے، اور نئی خصوصیات پر بات کرنے کے لیے وقت مخصوص کریں گے۔
+
+سیکورٹی مسائل اور حساس code of conduct خلاف ورزیوں کے لیے ہمیشہ نجی رپورٹنگ کا طریقہ ہونا چاہیے۔ اگر ذاتی ای میل استعمال نہیں کرنا چاہتے، تو ایک مخصوص ای میل ایڈریس بنائیں۔
+
+</div>