बग प्रबंधन/फैब्रिकेटर शिष्टाचार

कृपया इन दिशानिर्देशों का पालन करें ताकि यह सुनिश्चित हो सके कि Phabricator बग रिपोर्ट और फ़ीचर अनुरोधों के प्रबंधन के लिए एक उत्पादक और सहयोगात्मक वातावरण हो।

You must also follow the Code of Conduct.

• कमेंट्स सीधे तौर पर रिपोर्टिंग, कन्फर्म करने, गंभीरता का मूल्यांकन करने, या बग को ठीक करने से संबंधित होने चाहिए। रिपोर्ट के टॉपिक से हटकर बातें (जैसे, आम तौर पर प्रायोरिटीज़ पर मेटा-लेवल चर्चा या यह कि क्या कोई नया एक्सटेंशन चाहिए भी या नहीं) सही मेलिंग लिस्ट, विकी टॉक पेज, या अलग रिपोर्ट में जानी चाहिए।
  • विचारों की आलोचना करें, लोगों की नहीं। स्वस्थ मात्रा में रचनात्मक आलोचना और जीवंत बहस हमारे सॉफ्टवेयर को बेहतर बनाने में मदद करती है और इसे प्रोत्साहित किया जाता है।
  • सार्वजनिक रूप से कार्य करें जब तक आप किसी सिक्योरिटी इश्यू की रिपोर्ट नहीं कर रहे हैं या आपको किसी को खास जानकारी के साथ ईमेल करने के लिए नहीं कहा गया है, तब तक बग रिपोर्ट से जुड़ी सभी टेक्निकल जानकारी रिपोर्ट में ही डालें।
• रिपोर्ट के स्टेटस और प्राथमिकता सारांश असलियत को पेश और दिखाया जाता है, न कि वे असलियत को जन्म देते हैं। Read about the meaning of the Priority field values and, when in doubt, do not change them, but add a comment suggesting the change and convincing reasons for it.
  • आम तौर पर, किसी बग को ठीक करवाने का सबसे तेज़ तरीका है एक पैच देना (यह भी देखें डेवलपमेंट प्रायोरिटी तय करना)।
  • एक बग की प्राथमिकता बढ़ाने के लिए आश्वस्त करने वाले कारणों में इस बात का प्रमाण शामिल है कि यह सामान्य, रोजमर्रा के काम को महत्वपूर्ण रूप से प्रभावित करता है। बनावटी उदाहरण या समस्याएं जो केवल असामान्य परिस्थितियों में ही सामने आती हैं, उन्हें आम तौर पर समस्या को "कम" प्राथमिकता देने का सबूत माना जाता है, क्योंकि किसी भी नॉन-ट्रिवियल सॉफ्टवेयर की सीमाओं को पार किया जा सकता है अगर आप काफी कोशिश करें।
  • वोट या टिप्पणी पोस्ट न करें जैसे "इसे अभी ठीक करें"।
• किसी को भी टास्क तभी मैन्युअल रूप से असाइन करें जब उन्होंने पहले से इसके लिए सहमति दी हो। यह डेवलपर्स (या उनके उत्पाद प्रबंधकों) पर निर्भर करता है कि वे किस पर काम करने की योजना बना रहे हैं।
• किसी व्यक्ति के असली नाम या दूसरे पर्सनल आइडेंटिफ़ायर के बजाय फैब्रिकेटर यूज़रनेम (जैसे @username) इस्तेमाल करें। गोपनीयता और अनावश्यक भ्रम दोनों के बारे में चिंताओं को दूर करने के लिए, विभिन्न कार्यों, पेस्ट, फेम पोस्ट आदि पर संवाद करते समय, कृपया फैब्रिकेटर उपयोगकर्ता नामों का उपयोग करें। भले ही आप व्यक्तिगत स्तर पर व्यक्तियों को जानते हों (वास्तविक नाम, आदि), वे उस जानकारी को अपने फैब्रिकेटर उपयोगकर्ता नाम से जोड़ना नहीं चाहेंगे। यह अन्य फैब्रिकेटर उपयोगकर्ताओं के लिए भ्रम की एक परत भी प्रस्तुत करता है जो किसी के वास्तविक नाम या अन्य व्यक्तिगत पहचानकर्ताओं से अवगत नहीं हैं।
• Use notification features (such as mentions, subscriptions, and Herald rules) with care and respect for others. Prefer rules which follow specific items (project tags, tasks, etc.) rather than individual users. Avoid creating Herald rules which subscribe you to an individual users' activity unless there is a clear and shared reason for doing so (for example, mentorship or collaboration). If you are asked to stop such activity, take steps to narrow or disable such activity. Persisting after such a request can become unwanted attention or hounding as defined in the Code of Conduct.

यदि आप किसी को इन दिशानिर्देशों का पालन नहीं करते हुए या उत्पादक नहीं होते हुए देखते हैंः

1. पहला कदम उनसे संपर्क करना है। यह छोटे मामलों में निजी ईमेल के माध्यम से किया जा सकता है, या बड़े मामलों में सार्वजनिक रूप से सहन किए जाने वाले व्यवहार की किसी भी बाद की धारणा से बचने के लिए किया जा सकता हैं।
   • जानकारीपूर्ण रहें – उन्हें बताएं कि वे क्या कर रहे हैं जो उन्हें नहीं करना चाहिए। यदि प्रासंगिक हो तो उन्हें इस दस्तावेज़ के बारे में अवगत कराएँ।
   • उत्प्रेरक बनें – Tell what they should do instead. कभी-कभी यह "नियमों" की एक घनी सूची से बेहतर, उत्साहजनक और प्रेरक हो सकता है।
2. अगर इन गाइडलाइंस को लगातार नज़रअंदाज़ किया जाता है, तो विकिमीडिया IRC पर #wikimedia-releng ^{जुड़ें} में फैब्रिकेटर एडमिनिस्ट्रेटर को पिंग करें या बगवरैंगलर से संपर्क करें और उनसे इस मामले को देखने के लिए कहें। अगर इस अनदेखी को कोड ऑफ़ कंडक्ट में बताए गए नियमों के हिसाब से गलत व्यवहार माना जाता है, तो कोड ऑफ़ कंडक्ट कमेटी को जानकारी दी जाएगी।

दस्तावेज़ प्रेरणा

• शिष्टाचार
• बग्ज़िला मोज़िला डेवलपर नेटवर्क पर क्या करें और क्या न करें
• टीमप्रैक्टिस मेलिंग लिस्ट पर बातचीत, बगज़िला में RESOLVED WONTFIX के उपयोग (फैब्रिकेटर में अब "अस्वीकृत") और संबंधित समस्याओं के बारे में।

इन्हें भी देखें

• अभी तक किसी ने इस समस्या का समाधान क्यों नहीं किया? इन परिवर्तनों के बारे में मुझसे परामर्श क्यों नहीं किया गया? जिस पर काम किया जा रहा है, मैं उसे कैसे प्रभावित कर सकता हूं?
• बग रिपोर्ट जीवन चक्र
• बगज़िला पद्धति और विकी पद्धति के बीच समानताएं और अंतर
• किसी बग की शिकायत करें
• Phabricator/सहायता
• अपेक्षित व्यवहार