लेखक और कई ओपन सोर्स प्रोजेक्ट्स के मेंटेनर एंड्रयू गैलेंट हाल ही में ओपन सोर्स कम्युनिटी में जमा हुए तनाव को दूर करने की कोशिश कर रहे हैं। आत्मा की रोना "यह एक मुफ्त सॉफ्टवेयर अनुरक्षक की तरह क्या है" , "कृतघ्न ओपनसोर्स" और अनुरक्षकों की अन्य शिकायतों ने आक्रामकता, अशिष्टता, अकर्मण्यता, भावनात्मक बर्नआउट और परियोजनाओं के लिए निस्वार्थ समर्थन की गंभीरता के बारे में चर्चा को जन्म दिया। 19 जनवरी, 2020 को पोस्ट प्रकाशित किया गया था - लगभग। प्रति।

मैं तकनीकी विषयों पर लगभग सख्ती से बोलने की परंपरा से दूर जाना चाहता हूं - और मैं अपने कुछ निजी संबंधों को मुक्त और खुले स्रोत सॉफ़्टवेयर (एफओएसएस) के साथ साझा करूंगा। हालांकि सभी लोग अलग हैं, मुझे उम्मीद है कि विचारों के आदान-प्रदान से हमारे समुदाय में आपसी समझ, सहानुभूति और विश्वास बनाने में मदद मिलेगी।

कृपया इस पोस्ट को किसी अन्य अनुचर के कार्यों के लिए प्रत्यक्ष प्रतिक्रिया के रूप में नहीं मानें। यह आदर्श व्यवहार के लिए एक नुस्खा नहीं है, बल्कि इस उम्मीद में व्यक्तिगत प्रतिबिंब है कि वे खुले स्रोत के साथ अपने स्वयं के रिश्तों को प्रतिबिंबित करने के लिए दूसरों के लिए एक अवसर बन जाएंगे। एक अच्छा अनुरक्षक बनने का कोई सही तरीका नहीं है। प्रत्येक के पास इससे निपटने के अपने तरीके हैं।

यह मदद के लिए कोई मतलब नहीं है। यह समझने की बात है। मैं FOSS अर्थव्यवस्था में बदलाव या अपने मानसिक स्वास्थ्य पर चर्चा नहीं कर रहा हूं। मैं अतिरिक्त रखवाले को आकर्षित करने के बारे में बात नहीं कर रहा हूँ। मैं सिर्फ अपनी कहानी साझा करना चाहता हूं और FOSS समुदाय में सहानुभूति बढ़ाने की कोशिश करता हूं।

लक्षित दर्शक : खुले स्रोत में शामिल सभी लोग।

सामग्री

• कहानी
  
• धिक्कार है भावनाओं को
  
• पुरुलेंट नेगेटिव
  
• शक्ति के माध्यम से काम करें
  
• बेअदबी
  
• अधिकार
  
• क्षमता के बारे में अधिक
  
• भरोसा
  
• इससे अच्छा तो लगता है
  
• निष्कर्ष

कहानी

मेरे बहुत पहले ओपन सोर्स प्रोजेक्ट लगभग 16 साल पहले आया था - PHP में बुलेटिन बोर्ड। उस समय, लगभग सभी ने इस तरह की चीजें बनाईं, और यही मैंने प्रोग्राम करना सीखा। परियोजना शुरू में चर्चा के लिए एक स्कूल प्रणाली के रूप में शुरू हुई (उस समय, स्कूलों ने इंटरनेट के साथ बिल्कुल भी काम नहीं किया, सिवाय भद्दे साइटों की मेजबानी के)। तब मैंने पहली बार अनुमान लगाने में कठिनाई का सामना किया। यह परियोजना एक सेमेस्टर से अधिक समय तक घसीटती रही, और धीरे-धीरे एक शौक में बदल गई जो स्कूल परियोजना के दायरे से परे चली गई।

व्यक्तिगत रूप से, मैं हमेशा केवल मनोरंजन के लिए कार्यक्रम करना पसंद करता था। मैं सभी चरणों को पसंद करता हूं: पहले एक विषय की जांच करना, व्यवहार्यता का निर्धारण करना, एक प्रारंभिक योजना विकसित करना, जुनूनी कोडिंग और यहां तक ​​कि इसके बारे में सोचना, मुझे यह सब पसंद है।

प्रोग्रामिंग का आनंद लेने के लिए, मुझे अपने काम के परिणामों को साझा करने की आवश्यकता नहीं है। हालांकि, खुला स्रोत जल्दी से मेरी विकास प्रक्रिया का एक स्वाभाविक हिस्सा बन गया, जो 16 वर्षों तक एक या दूसरे रूप में बना रहा। वास्तव में, मुझे जो सबसे अच्छा लगता है वह यह है कि यदि कोड किसी को अपनी समस्या को अधिक कुशलता से हल करने की अनुमति देता है। जितना अच्छा मेरा कोड लाता है, उतना ही सुखद। एक नियम के रूप में, मुझे परवाह नहीं है कि दूसरी तरफ कौन हैकर सिर्फ एक और हैकर है जो अपनी जिज्ञासा को संतुष्ट करता है, या एक विशालकाय निगम एक अविश्वसनीय पैमाने पर कुछ दिलचस्प कर रहा है।

मेरी FOSS कहानी मेरे बुलेटिन बोर्ड और wtcSQLite , phpMyAdmin के एक साधारण क्लोन के कई रिलीज के साथ चली गई, लेकिन SQLite के लिए।

जब मैंने 2009 के आसपास विंडोज से लिनक्स पर स्विच किया, तो मैंने और भी प्रोजेक्ट लॉन्च किए, लेकिन पायथन और एक्स 11 में। उनमें से मल्टी-विंडो मैनेजर और ओपनबॉक्स-मल्टीहेड में फ्रेम फिक्सिंग के लिए पायलेट हैं, ओपनबॉक्स में मल्टी-मॉनिटर समर्थन का मेरा कार्यान्वयन। गो के कुछ शोधों के साथ, इन परियोजनाओं ने मुझे गो पर विंडो मैनेजर बनाने के लिए प्रेरित किया, जिसका मैं अभी भी उपयोग करता हूं।

जैसे-जैसे समय बीतता गया और लगभग छह साल पहले मैंने रस्ट में लिखना शुरू किया। क्विकचेक पहला पुस्तकालय बन गया, लेकिन इसके बाद अन्य लोगों का एक समूह बन गया: अगले छह वर्षों में regex , docopt.rs , जंग- csv , fst , termcolor , walkdir और कई अन्य।

हालाँकि, मेरी Rust परियोजनाओं में से अधिकांश पुस्तकालय हैं, लेकिन xsv और ripgrep जैसे कमांड लाइन उपकरण हैं।

मेरी कई पुरानी परियोजनाएं अब वास्तव में मृत हैं या दूसरों द्वारा समर्थित हैं, लेकिन मैं अधिकांश रुस्ट परियोजनाओं का समर्थन करना जारी रखता हूं। या उन्हें किसी और के बेहतर गुणवत्ता वाले रैक (उदाहरण के लिए, क्रॉसबीम-चैनल ने चान को कैसे दबाया ) द्वारा दबाया गया था।

आज, मैं अभी भी बहुत प्रोग्राम करना पसंद करता हूं, लेकिन मैं कोड की समीक्षाओं पर बहुत समय बिताता हूं, अंत उपयोगकर्ताओं के साथ समस्याएं डीबग करना, फीचर अनुरोधों का जवाब देना, और ऐसी अन्य चीजें। यह हमेशा अन्य लोगों के साथ बातचीत, काम और संचार का मतलब है।

धिक्कार है भावनाओं को

मेरी युवावस्था में मुझे अपने "तर्क" और "निष्पक्ष निर्णय लेने" पर गर्व था। जैसा कि हर अच्छे आत्म-धोखे में होता है, यहाँ सत्य का एक दाना होता है। लेकिन संक्षेप में, मैं व्यक्तिगत रूप से एक गहरा भावनात्मक व्यक्ति हूं।

भावनाएं गहरी बहती हैं और आंतरिक प्रेरणा के लिए वास्तव में उपयोगी स्रोत हो सकती हैं। उदाहरण के लिए, रिपग्रेप की रिहाई के कुछ समय बाद, मैं वास्तव में खोज परिणामों को प्रदर्शित करने के लिए जिम्मेदार कोड को छूने से नफरत करता था। वह उलझन में था, छोटी गाड़ी और बदलना मुश्किल था। कोड को पूरी तरह से फिर से लिखना एक पूरी तरह से तार्किक निर्णय है जो विशुद्ध रूप से तकनीकी आधार पर किया जा सकता है, लेकिन मुझे यह घृणा की भावना से बाहर करने के लिए प्रेरित किया गया था। मैं सिर्फ अपनी भावनाओं की तरह नहीं था । भावनाओं ने मुझे स्थिति को ठीक करने में मदद की, खुद की मदद की। उदाहरण के लिए, अब पूरी तरह से परीक्षण के साथ एक अलग पुस्तकालय में आउटपुट को अलग कर दिया जाता है, और मुझे हर बार इस कोड में जाने और कुछ करने की आवश्यकता होती है। यह अभी भी मेरा सबसे अच्छा काम नहीं है, लेकिन यह पहले से ही एक बड़ा सुधार है - कम से कम भावनात्मक दृष्टिकोण से - पिछले राज्य की तुलना में।

भावनाएं एक मजेदार चीज हैं क्योंकि वे आपको वास्तव में अद्भुत राज्यों में ले जा सकती हैं। कहते हैं, पिछले उदाहरण में, आउटपुट कोड को फिर से लिखने के लिए कुछ तकनीकी कारण पर्याप्त हैं? यहां आपको निर्णय लेने की आवश्यकता है। लेकिन अगर कोई प्रेरणा नहीं है, तो शायद मैं कभी भी रिफ्लेक्टर करने की हिम्मत नहीं करूंगा। और बिना रिफैक्टिंग के, सबसे अधिक संभावना है कि कोड आधार स्थिर हो जाएगा, और कार्यक्रम विफल होने लगेगा, या दोनों के कुछ संयोजन। यदि भावनाएं प्रेरणा देती हैं, तो रिफैक्टरिंग एक बेहतर भविष्य खोलेगी, जहां आप विश्वसनीयता से समझौता किए बिना सॉफ़्टवेयर में अधिक कार्यों को लागू कर सकते हैं।

भावनाओं का नकारात्मक पक्ष है। जो भी जारी किया और कुछ काफी लोकप्रिय सॉफ़्टवेयर का समर्थन किया, वह अन्य लोगों से संपर्क करना सुनिश्चित था। यह पता चला है कि एक अन्य व्यक्ति आपके भावनात्मक स्थिति पर आश्चर्यजनक प्रभाव डाल सकता है। एक सकारात्मक इशारा या टिप्पणी आपके दिन को रोशन कर सकती है। वही भावना: हाँ, मेरा कोड अपलोड करना इतना महत्वपूर्ण था कि इसने इस व्यक्ति की मदद की । लेकिन, जैसा कि किसी भी अनुरक्षक की पुष्टि होती है, सकारात्मक टिप्पणी लगभग हमेशा नकारात्मक लोगों द्वारा देखी जाती है।

नकारात्मक टिप्पणियां इतनी बुरी नहीं हैं। जब आप अन्य उपयोगकर्ताओं को इसका उपयोग करने और समस्याओं की रिपोर्ट करने के लिए आमंत्रित करते हैं तो यह कोड साझा करने का एक स्वाभाविक परिणाम है । जब कोई त्रुटि संदेश प्रकट होता है, तो आपको लगता है कि आप इस उपयोगकर्ता को विफल कर चुके हैं। जब आपने कोड लिखा था, तो आप सुनिश्चित थे कि आपने इसे अच्छी तरह से परीक्षण किया है, लेकिन यह अभी भी गलत है । क्या बग रिपोर्ट कभी बंद नहीं होगी? बग के कारण इस उपयोगकर्ता ने कितना समय बर्बाद किया? मुझे सब कुछ ठीक करने में कितना समय लगेगा? यह भी नहीं: मुझे बस एक मोड पर स्विच करने में कितना समय लगेगा जिसमें इसे ठीक करने की कम से कम उम्मीद है?

ये विचार भावनाओं को जन्म दे सकते हैं जो आपको नष्ट करना शुरू करते हैं। और यह सबसे अधिक संभावना परिदृश्य है जब यह नकारात्मक टिप्पणियों की बात आती है।

पुरुलेंट नेगेटिव

मैंने बग रिपोर्ट्स से नकारात्मक भावनाओं को दूर करना सीख लिया। वास्तव में, आसानी से पढ़े जाने वाले अच्छे त्रुटि संदेश जल्द ही सुखद हो जाते हैं क्योंकि वे आमतौर पर बहुत दुर्लभ होते हैं। अधिकांश बग्स को पुन: प्रस्तुत नहीं किया जाता है, भले ही आप सभी मापदंडों (समस्या टेम्पलेट) के लिए स्पष्ट अनुरोधों के साथ समस्या के लिए एक टेम्पलेट प्रदान करते हैं। प्रेषक शायद सबसे अच्छा चाहता है, लेकिन जानकारी केवल त्रुटि को पुन: पेश करने के लिए पर्याप्त नहीं है। और बग को अलग करने के प्रयास में उपद्रव शुरू होता है।

मेरे लिए व्यक्तिगत रूप से, यह सबसे दर्दनाक क्षेत्र है। भावनाएं ऊपरी हाथ हासिल करती हैं क्योंकि मैं केवल एक चीज के बारे में सोच सकता हूं: इस व्यक्ति ने समस्या के लिए टेम्पलेट को पढ़ने और भरने के लिए समय क्यों नहीं लिया ? या अगर बग उस उपयोगकर्ता की गलती के कारण होता है, जिसने दस्तावेज़ीकरण नहीं पढ़ा है, तो मैं केवल यह सोच सकता हूं: मैंने इस उपयोगकर्ता को कुछ सॉफ़्टवेयर देने के लिए समय लिया, और बग रिपोर्ट प्रस्तुत करने से पहले वह README भी नहीं पढ़ सकता है?

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

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

यह उपयोगकर्ताओं और अनुचर के बीच की विषमता को रेखांकित करता है। कई बग रिपोर्ट के लेखक मेरे साथ एक या दो संदेशों का आदान-प्रदान कर सकते हैं। उनके लिए, एक खराब लिखित बग रिपोर्ट वास्तव में मायने नहीं रखती है। लेकिन मैं गलत पक्ष में हूं, क्योंकि मेरे पास यह दृश्य मेरे सभी प्रोजेक्ट्स में बार-बार खेला जाता है। हर समय। लगभग हर दिन। ऐसी स्थिति में सहानुभूति बनाए रखना बेहद मुश्किल है, खासकर अगर आपका दिन खराब हो। कभी-कभी क्या होता है।

कभी-कभी मेरी अधीरता बहुत कम उत्तरों में प्रकट होती है। मैं इस संबंध में बेहतर करने की पूरी कोशिश करता हूं। आत्म-सुधार की प्रक्रिया अभी पूरी नहीं हुई है।

शक्ति के माध्यम से काम करें

यदि आप एक लोकप्रिय परियोजना या कई नियमित रिपोजिटरी के रखवाले हैं, तो आपको बग रिपोर्ट और पूल अनुरोधों की लगभग निरंतर धारा मिलती है। वे रोज आते हैं। उसके साथ रहना लगभग असंभव है। मेरे मस्तिष्क का कैश आकार असामान्य रूप से छोटा है, इसलिए मैं परियोजनाओं के बीच संदर्भ बदलने में बहुत अच्छा नहीं हूं। इस घटना के परिणामस्वरूप, मैंने उन परियोजनाओं के लिए बग रिपोर्ट और पूल अनुरोधों को जल्दी से रेक किया, जिनके साथ मैंने हाल ही में काम किया था। ये परियोजनाएं संभवतः मस्तिष्क के कैश के अंतिम पृष्ठों पर अधिक सुलभ या बेहतर हैं।

लेकिन अन्य परियोजनाओं में, समस्याओं की सूची जमा होने लगती है। हर दिन आप एक नया मुद्दा देखते हैं और अपने आप से कहते हैं: "हां, मैं वास्तव में इस पर गौर करूंगा जैसे ही मैं काम से वापस लौटूंगा।" लेकिन कुछ नया आ रहा है। नतीजतन, संदर्भ को स्विच करने की प्रेरणा केवल तब उत्पन्न होती है जब उपयोगकर्ता आपको चार महीने के लिए मासिक करता है - शायद उसका पूल अनुरोध वास्तव में महत्वपूर्ण है।

क्षमा करें, अंतिम वाक्य में थोड़ा व्यंग्य था, लेकिन साथ ही यह सच भी था। उपयोगकर्ताओं और अनुरक्षकों की विषमता वापस कार्रवाई में है, लेकिन मैं वास्तव में अनुरोध-कतारों के पूल को खाली करने और परियोजना को विकसित करने की कोशिश कर रहा हूं। मैं इस उपयोगकर्ता का योगदान करना चाहता हूं, न केवल मेरे कोड का उपयोग करना जारी रखना, बल्कि उसे खुश करना भी है। कई मामलों में, पूल अनुरोधों और उन सभी समस्याओं को हल करने के लिए सिर्फ एक घंटे का समय पर्याप्त होता है, जिनमें कार्रवाई की आवश्यकता होती है।

लेकिन मैंने चार महीने सिर्फ दुख के साथ बिताए हैं कि उन समस्याओं को कैसे हल किया जाए जो बिना समाधान के प्रवेश करते हैं।

इस घटना के लिए, मैंने एक ऐसी विधि लागू की जिसका उपयोग मैं अपने व्यक्तिगत जीवन में बहुत प्रभावी ढंग से करता हूं: सीमाएं निर्धारित करने के लिए। विनम्रता से, लेकिन सीमाओं को दृढ़ता से स्थापित करना उन जादुई जीवन हैक में से एक है जो आपके सीखते ही लाभांश अर्जित करता है। यदि आप नहीं जानते कि यह कैसे करना है, तो मैं शायद ही समझा सकता हूं। हालाँकि, सीमाएँ निर्धारित करने से आपको इस बात पर ध्यान केंद्रित करने की अनुमति मिलती है कि आपके लिए क्या महत्वपूर्ण है, अन्य नहीं।

जाहिर है, एक संतुलन के लिए प्रयास करना चाहिए। सीमाओं की स्थापना का मतलब यह नहीं है कि आप केवल अपने मामलों पर ध्यान केंद्रित कर सकते हैं। लेकिन इस दीवार को लगाने और कहने की क्षमता: "नहीं, मैं एक्स नहीं करता, लेकिन मैं ख़ुशी से वाई करता हूँ" - यह वास्तव में मेरे लिए अद्भुत काम किया। मेरा रहस्य यह तर्क देना है कि दूसरे मेरे अपने अनुभव और इच्छाओं के आधार पर बहस नहीं कर सकते।

खुले स्रोत के साथ इसका क्या करना है? मेरे लिए व्यक्तिगत रूप से, कुंजी खुद के बीच एक सीमा स्थापित करना था - और पूल अनुरोधों के साथ इन सभी अनाथ समस्याओं। आपको किसी तरह अपने आप को प्रभावित करने की आवश्यकता है: “मैं स्वेच्छा से अपना समय व्यतीत करता हूं, और यह सामान्य है कि मैं समय पर प्रतिक्रिया नहीं देता। मुझे यकीन है कि ज्यादातर लोग इसे समझेंगे और उचित होगा। ”

नई सुविधाओं के अनुरोधों पर चर्चा करते समय यह भी दिखाई देता है। कभी-कभी अनुरोध आपके प्रोजेक्ट के लिए कुछ मायने रख सकता है, लेकिन यह फ़ंक्शन समर्थन का एक बड़ा बोझ है। मैंने सीमाओं को निर्धारित करना सीख लिया: आप केवल इस आधार पर एक फ़ंक्शन के लिए "नहीं" कह सकते हैं कि आप समर्थन पर अतिरिक्त समय खर्च नहीं करना चाहते हैं। जैसा कि एक से अधिक बार हुआ है, तो आप अपना मन बदल सकते हैं! उदाहरण के लिए, यदि कोड में सुधार हुआ है, तो रखरखाव के लिए और अधिक सुलभ हो गया है - आप अपने आप को नई कार्यक्षमता शुरू करने की अधिक इच्छा में नोटिस कर सकते हैं। लेकिन अगर नहीं, तो मैं अपनी सीमाओं को टटोलने की पूरी कोशिश करता हूं और खुद को अतिरिक्त काम के साथ लोड करने से मना करता हूं जो खुशी नहीं देता है।

मैं समस्याओं के ढेर के कारण फर्म की सीमाओं को निर्धारित करने और खराब महसूस करने के बारे में कदम-दर-चरण निर्देश लिखना चाहूंगा। यह पूरी तरह से नकारात्मक को खत्म नहीं करता है, लेकिन यह बहुत मदद करता है।

बेअदबी

स्पष्ट रूप से ट्रोल आमतौर पर निपटने में आसान होते हैं। यह उन लोगों का समूह है जिनके पास आपको पेशाब करने के लिए स्पष्ट इरादे हैं। ट्रोल्स आमतौर पर कोई कोड नहीं भेजते हैं, इसलिए उनकी टिप्पणियों पर अधिक ध्यान देने की आवश्यकता नहीं है। कम से कम, यही मैं खुद को रक्षा तंत्र के ढांचे में कहता हूं। अगर मुझे कोई ट्रोल दिखता है, तो मैं आमतौर पर इसे बाद में अवरुद्ध करने के साथ गिटहब के समर्थन में रिपोर्ट करता हूं। सामान्य तौर पर, मैं बहुत कम ही ऐसे पात्रों से मिलता हूं, इसलिए यहां मैं भाग्यशाली लगता हूं।

लेकिन अशिष्टता कई रूप लेती है। मेरी भावनात्मकता शालीनता के बजाय एक तंग रूपरेखा तय करती है, इसलिए आप इस सभी अशिष्टता पर विचार नहीं कर सकते। लेकिन मेरे दृष्टिकोण से, यह कम से कम बिना मुंह वाला है।

• "आपका उपकरण काम नहीं करता है [मेरे आला मामले के लिए], इसलिए यह टूट गया है।"
  
• "मैं यह कहने के लिए हस्तक्षेप नहीं करूंगा कि मैं भी इस सुविधा को पसंद करूंगा" (नोट। ऐसा लगता है कि कुछ पाठक इसे "अशिष्टता" कहते हैं, जो शायद बहुत कठिन है। " "ऐड-ऑन", यह सिर्फ ईमेल में शोर जोड़ता है और कष्टप्रद हो सकता है। इसके बजाय, इमोटिकॉन्स का स्वागत है या आप अपने विशिष्ट उपयोग के मामले में कुछ विवरण जोड़ सकते हैं। हालांकि, यह पृष्ठभूमि के खिलाफ बहुत छोटा दिखता है, और मैं वास्तव में यहां देखता हूं। बुनियादी तौर पर मेरी समस्या)।
  
• जोर देकर कहा कि समारोह को लागू करने के लिए आपको " बस एक्स बनाने के लिए" की आवश्यकता है।
  
• जब आप फ़ंक्शन अनुरोध पर पास होते हैं, तो आक्रामक आक्रामकता।
  
• [यहां किसी भी सोशल मीडिया में डालें] सॉफ्टवेयर के बारे में असंवेदनशील नागवार।
  
• विषय पर भिन्नताएं "आप पहिया को क्यों सुदृढ़ कर रहे हैं?" या "इसके बजाय एक मौजूदा परियोजना में योगदान क्यों नहीं?"

कई मामलों में, अशिष्टता उपयोगकर्ता की ओर से वास्तविक निराशा का परिणाम है। जब आप किसी उपकरण को आपके इच्छित तरीके से व्यवहार नहीं करते हैं तो आपने कितनी बार अपनी सांस के तहत म्यूट किया है? इससे कोई फर्क नहीं पड़ता कि यह उपकरण संभवतः आपके लिए मुफ्त में प्रस्तुत किया गया है। आप बस एक समस्या को हल करने की कोशिश कर रहे हैं, और उपकरण आपके रास्ते में हो रहा है। मैंने खुद इसे जरूर महसूस किया। मेरी राय में, एक पूरी तरह से सामान्य मानवीय भावना।

कभी-कभी अशिष्टता प्रबल होती है, जो विभिन्न अनुत्पादक तरीकों से व्यक्त की जाती है। मुझे पता है कि मैंने खुद ऐसा किया है और निश्चित रूप से, दूसरी तरफ भी हुआ है। यह सभी को शामिल करने के लिए अविश्वसनीय रूप से परेशान है।

अन्य मामलों में, कुछ लोग स्वयं अपनी अशिष्टता को नहीं समझते हैं। हो सकता है कि भाषा की बाधा के कारण, या क्योंकि वे नहीं जानते थे कि उनके शब्दों का दूसरों पर क्या प्रभाव पड़ेगा। काफी निर्दोष है, लेकिन मेरी ओर से भावनाओं को नहीं बदलता है।

इस तरह की अशिष्टता से निपटना बहुत मुश्किल हो सकता है। शायद ये समस्याएँ किसी को परेशान न करें, लेकिन मैं उनमें से नहीं हूँ। मैं दिखावा कर सकता था कि यह मुझे परेशान नहीं करता, लेकिन मुझे यकीन है कि इससे खुले स्रोत का अपमान होगा और इससे भी ज्यादा निराशा होगी।

यहाँ फिर से, सीमाओं की स्थापना ने मेरी मदद की। यदि हम ट्रॉल्स को छोड़ देते हैं, तो आमतौर पर स्नैपर के विशाल बहुमत काफी अच्छी तरह से प्रतिक्रिया देते हैं, यदि आप उन्हें विनम्रता से संबोधित करते हैं। मैंने अक्सर अपने बग ट्रैकर्स में ऐसा किया, और इससे आम तौर पर स्थिति में सुधार हुआ। मैं अपमान महसूस नहीं करता क्योंकि मैं खुद की रक्षा करता हूं, और साथ ही साथ मैं बेहतर महसूस करता हूं जब दूसरा व्यक्ति माफी मांगता है, जो अधिकांश मामलों में होता है।

ऐसा करने के लिए, बस यह कहना पर्याप्त है: "जैसा मैंने X कहा था वैसा नहीं है। मुझे लगता है कि अगर भविष्य में हम इस तरह की अपील से इनकार करते हैं तो यह बहुत अधिक उत्पादक होगा।"

लेकिन कुछ मामलों में, लोग ऐसे शब्दों पर बहुत अच्छी प्रतिक्रिया नहीं देते हैं। मेरे अनुभव में, वे आमतौर पर उन्हें अनदेखा करते हैं। यदि वे असभ्य बने रहे, तो मैं इसे एक-दो बार दोहरा सकता हूं, क्योंकि कुछ को उन तक पहुंचने के लिए एक बार से अधिक कुछ सुनने की जरूरत है। कम से कम मुझे यह अपने आप पता है (मेरी पत्नी की नाराजगी के लिए) यदि यह अभी भी काम नहीं करता है, और उनका स्वर अभी भी मुझे परेशान करता है, तो मैं बातचीत करना बंद कर देता हूं। बस समस्या या पूल अनुरोध को बंद करें या ब्लॉक करें, या तब तक आगे बढ़ें जब तक कि उपयोगकर्ता को [यहां सोशल मीडिया डालें]।

अधिकार

एक बार, मैंने कुछ करीबी दोस्तों के साथ बात की, जो विदेश यात्रा कर रहे थे। संयुक्त राज्य अमेरिका में लौटने पर, उन्होंने सांस्कृतिक झटके का एक छोटा सा उदाहरण साझा किया। मुख्य बात है?

मैंने कभी नहीं सोचा था कि अमेरिकियों को कितना प्यार करना पसंद है।

चाहे यह सभी अमेरिकी संस्कृति की विशेषता हो या सिर्फ पर्यावरण की - हम चर्चा नहीं करेंगे। मुद्दा यह है कि कुछ लोग इस बारे में बात करना पसंद करते हैं कि दूसरे लोगों को क्या करना चाहिए । मैं पावर पदानुक्रम के सबसे अलग स्तरों के लोगों से इस तरह के फ़ीड पर बड़ा हुआ - और मैं वास्तव में इसके लिए एक जन्मजात घृणा महसूस करता हूं।

मुझे पूरा यकीन है कि ज्यादातर लोगों को इस तरह के व्यवहार का एहसास नहीं है। कुछ आपके जीवन में नहीं आना चाहते, लेकिन बस सलाह देने की कोशिश करते हैं। जब मैं विशेष रूप से जोर-जबरदस्ती के मामलों को इंगित करता हूं, तो वे कम से कम कैसे जवाब देते हैं।

थोड़ा पीछे हटना, शब्द "चाहिए" का उपयोग करना अपने आप में बुरा नहीं है। लेकिन क्या वास्तव में इसका अर्थ बदल जाता है, मेरी राय में, एक निमंत्रण की उपस्थिति है। यदि आपने किसी से किसी विषय पर सलाह मांगी है, और वह कहता है कि "हाँ, आपको एक्स बनाना है", तो यह इतना बुरा नहीं है। , .

:

• .
  
• [ ].
  
• .
  
• [ ].
  
• .

, - . . , , - , . , - , - , .

, , . :

• , « ?», , . FAQ .
  
• . , - , .

, . , Rust, UNLICENSE . - «» , () , . . . - , .

, . - , . . , .

, . , , , - .

, - ( ), . . . -, . - , — , , — . , -: - , .

. . , , .

. open source. , , , .

FOSS — . , . FOSS , , . , .

, . - , , , .

. , . :

• , , ?
  
• ?
  
• ?
  
• ?

, . , . , . . — , . , , .

, JSON, , . , / . .

, , . . , . , , . , .

, , . , , FOSS.

,

. : « ?» , . . , , . , ( ) .

, :

• , . , . , : «, , . ».
  
• -, .
  
• -, , , . — , .
  
• changelog, , . , , .
  
• , , . , .
  
• . , , .
  
• . , , .

, — — . . , , , . .

निष्कर्ष

FOSS, . , . , . , . , , . , . - , FOSS.

, , , , . , .

लेख में, मैंने कई प्रकार के व्यवहार सूचीबद्ध किए हैं जिन्हें मैं नकारात्मक मानता हूं। हर कोई उन्हें उतना नकारात्मक नहीं समझेगा जितना मैं करता हूं। यह सामान्य और अपेक्षित है । इसके अलावा, मैंने खुद इनमें से कुछ नकारात्मक बातें कीं। लोग परिपूर्ण नहीं हैं, और हम 100% समय के लिए पूरी तरह उत्तरदायी नहीं हो सकते। ये सूक्ष्म सवाल हैं, और मुझे उम्मीद है कि हम स्थिति को बेहतर कर सकते हैं, कम से कम थोड़ा।