सामुदायिक दिशानिर्देश — Remote Valley OS

हामी कसरी सँगै काम गर्छौं, सञ्चार गर्छौं र निर्माण गर्छौं।

यी दिशानिर्देशले आचार संहितालाई पूरक बनाउँछन्। तिनले हामी दैनिक रूपमा — इस्यू, pull request, छलफल र सामुदायिक कलमा — कसरी सहकार्य गर्छौं वर्णन गर्छन्।

सञ्चार मापदण्ड

स्पष्ट हुनुहोस्

भन्न खोजेको कुरा भन्नुहोस्। सन्दर्भ दिनुहोस्। समस्या वर्णन गर्दा स्क्रिनसट, लग वा कोड स्निपेट समावेश गर्नुहोस्।

राम्रो: "परीक्षणमा एक्सट्रुडर तापक्रम सेन्सरले थर्मोकपलभन्दा १५°C बढी देखाउँछ।
यहाँ वायरिङ आरेखण र कच्चा सिरियल निर्गत छ।"

राम्रो होइन: "एक्सट्रुडरको तापक्रम गलत छ।"

सद्भावना मान्नुहोस्

अधिकांश मानिस सहयोग गर्न खोजिरहेका हुन्छन्। कुनै टिप्पणी कठोर वा आलोचनात्मक लाग्यो भने, जवाफ दिनु अघि उदार नियतले फेरि पढ्नुहोस्। खराब नियत मान्नु अघि स्पष्ट पार्ने प्रश्न सोध्नुहोस्।

रचनात्मक रूपमा असहमति जनाउनुहोस्

असहमति स्वस्थ हो। यसलाई व्यक्तिको वरिपरि होइन, विचारको वरिपरि बनाउनुहोस्।

राम्रो: "यहाँ गुरुत्व-आपूर्त पानी इनटेक बढी भरपर्दो हुनेछ, किनकि यसले पम्प फेल हुने बिन्दु हटाउँछ।"

राम्रो होइन: "यो पम्प डिजाइन गलत छ।"

सार्वजनिकलाई पूर्वनिर्धारित गर्नुहोस्

गोपनीयताको विशेष कारण (निजी जानकारी, सुरक्षा, आचार संहिता रिपोर्ट) नभएसम्म कुराकानी सार्वजनिक GitHub इस्यू, छलफल र pull request मा राख्नुहोस्। सार्वजनिक छलफलले सबैलाई सिकाउँछ र भावी योगदानकर्तालाई जवाफ खोज्न दिन्छ।

समावेशी भाषा प्रयोग गर्नुहोस्

• सम्भव भएसम्म शब्दजाल, संक्षेप र आन्तरिक सन्दर्भबाट बच्नुहोस्
• प्राविधिक शब्द प्रयोग गर्नैपरे व्याख्या गर्नुहोस्
• अंग्रेजी सबैको पहिलो भाषा नहुन सक्छ सम्झनुहोस्
• गैर-मातृभाषीसँग धैर्य गर्नुहोस् — सामग्री र व्याकरणभन्दा विचार महत्त्वपूर्ण छ

हामी GitHub कसरी प्रयोग गर्छौं

इस्यू कामका लागि

• बग रिपोर्ट, सुविधा अनुरोध र विशेष कार्य
• हरेक इस्यूले एउटा कुरा स्पष्ट वर्णन गर्नुपर्छ
• वर्गीकरणका लागि लेबल प्रयोग गर्नुहोस्: bug, enhancement, good-first-issue, help-wanted, documentation, question

छलफल कुराकानीका लागि

• सामान्य प्रश्न, विचार, ब्रेनस्टर्मिङ, सामुदायिक परिचय
• “म योगदान गर्न चाहन्छु तर कहाँबाट सुरु गर्ने थाहा छैन” → छलफल
• “के हामीले सेन्सर संकलन पाइपलाइन पुनःडिजाइन गर्नुपर्छ?” → छलफल (त्यसपछि RFC इस्यूमा बदलिन्छ)

pull request प्रस्तावित परिवर्तनका लागि

• सम्भव भए सधैं सम्बन्धित इस्यूमा लिंक गर्नुहोस्
• PR लाई एउटा परिवर्तनमा केन्द्रित राख्नुहोस्
• ठूला परिवर्तन धेरै PR मा बाँड्नुपर्छ

निर्णय-निर्माण मापदण्ड

गति होइन, सहमति खोज्नुहोस्

अधिकांश निर्णय आजै गर्नु आवश्यक छैन। मानिसलाई जवाफ दिन समय दिनुहोस्। महत्त्वपूर्ण निर्णयमा टिप्पणीका लागि कम्तीमा ४८ घण्टा मानक हो।

अल्छी सहमति

तपाईंले प्रस्ताव खोल्नुभयो र टिप्पणी अवधिभित्र कसैले आपत्ति जनाएन भने, स्वीकृत मानिन्छ। सबै कुराका लागि स्पष्ट स्वीकृति आवश्यक छैन। तर कसैले आपत्ति जनाए भने, जबरजस्ती अगाडि बढाउनुको सट्टा रोकी छलफल गर्नुहोस्।

अड्किँदा माथि पुर्‍याउनुहोस्

छलफल एक हप्ताभन्दा बढी घुमिरहेको छ भने, सहजीकरणका लागि मर्मतकर्तालाई ट्याग गर्नुहोस्। कहिलेकाहीं बाहिरी दृष्टिकोणले सहयोग गर्छ।

सामुदायिक भूमिका (अनौपचारिक)

तपाईं भूमिकाबीच स्वतन्त्र रूपमा आवतजावत गर्न सक्नुहुन्छ। कुनै पदोन्नति समारोह छैन। काम गर्दै तपाईं भूमिकामा हुर्किनुहुन्छ।

सामुदायिक स्थानहरू

प्रतिक्रिया दिने र लिने

प्रतिक्रिया दिँदा

• तपाईंलाई मन परेको कुराबाट सुरु गर्नुहोस्
• सुधार गर्न सकिने कुरामा स्पष्ट हुनुहोस्
• किन भन्ने व्याख्या गर्नुहोस् — तर्क रायभन्दा महत्त्वपूर्ण छ
• आलोचना मात्र होइन, विकल्प प्रस्ताव गर्नुहोस्

प्रतिक्रिया लिँदा

• प्रतिरक्षा गर्न होइन, बुझ्न सुन्नुहोस्
• स्पष्ट पार्ने प्रश्न सोध्नुहोस्
• व्यक्तिको समय र ध्यानका लागि धन्यवाद दिनुहोस्
• प्रतिरक्षात्मक महसुस भए जवाफ दिनु अघि समय लिनुहोस्

मान्यता मापदण्ड

• हरेक मर्ज भएको pull request योगदानकर्ता सूचीमा स्थान पाउँछ
• महत्त्वपूर्ण योगदान (नयाँ मोड्युल, प्रमुख पुनःडिजाइन, क्षेत्र अनुकूलन) ले सम्बन्धित कागजातमा सह-लेखकत्व पाउँछ
• मासिक सामुदायिक कलले योगदानकर्ताको काम उजागर गर्छ
• मर्मतकर्ता संस्था पृष्ठ र मोड्युल README मा सूचीबद्ध हुन्छन्

गतिका बारे एक टिप्पणी

यो स्वयंसेवक समुदाय हो (सशुल्क आवास पद बाहेक)। मानिसहरू समय र ऊर्जा हुँदा योगदान गर्छन्। सोही दिनको जवाफ अपेक्षा नगर्नुहोस्। मर्मतकर्तामाथि दबाब नदिनुहोस्। कुनै कुरा आपत्कालीन छ भने किन भन्नुहोस् — र तैपनि प्राथमिकता नपाए बुझाइ देखाउनुहोस्।

दायराका बारे एक टिप्पणी

Remote Valley OS को एउटा विशेष मिशन छ: दुर्गम समुदायका लागि खुला स्रोत पूर्वाधार बनाउने। हरेक राम्रो विचार यहाँ नपर्न सक्छ। तपाईंको विचार मिशनमा नमिले त्यो तपाईं वा तपाईंको विचारको अस्वीकार होइन। त्यो फरक परियोजनामा पर्न सक्छ। फोर्क गर्नुहोस्।

यी दिशानिर्देश जीवित दस्तावेज हुन्। pull request वा छलफलमार्फत परिवर्तन प्रस्ताव गर्नुहोस्।