हां, प्रतिक्रिया को यथासंभव, पेशेवर और तकनीकी के रूप में रखें, संभावित "सबसे खराब मामले" परिदृश्यों के साथ अपनी चिंताओं का बैक अप लें ताकि उन सुविधाओं और/या यह विशेष कार्यान्वयन के नुकसान स्पष्ट रूप से स्पष्ट हो जाएं।
इसके अलावा, इस सुविधाओं/कोड है कि बहुत विशिष्ट हैं और अधिकांश उपयोगकर्ताओं के लिए किसी काम के नहीं हैं, कोड/उपयोग अनुपात के बारे में अपनी चिंताओं को व्यक्त के बारे में है - वृद्धि हुई कोड बेस जटिलता आदि
के बारे में चिंताओं का संकेत आदर्श रूप में, अपनी चिंताओं को ओपन-एंडेड प्रश्नों के रूप में प्रस्तुत करें - इस अर्थ में: "हालांकि, मैं सोच रहा हूं कि ऐसा करने का यह तरीका लंबी अवधि में काम कर सकता है ..."। ताकि आप वास्तव में योगदानकर्ताओं के बीच एक सक्रिय संवाद को प्रोत्साहित कर सकें।
अपने सहयोगी योगदानकर्ताओं और उपयोगकर्ताओं को इन चिंताओं पर अपनी राय प्रदान करने के लिए आमंत्रित करें, वास्तव में अन्य लोगों/योगदानकर्ताओं से पूछें कि वे इस अतिरिक्त के बारे में क्या सोच रहे हैं (पेशेवर & विपक्ष, आवश्यकताओं, कोड गुणवत्ता के संदर्भ में), बयान दें यदि आप अन्य योगदानकर्ता/उपयोगकर्ता इसी अंतर्दृष्टि प्रदान कर सकते हैं तो आप अपनी वर्तमान स्थिति पर पुनर्विचार करने के इच्छुक हैं।
आप मूल रूप से एक अनौपचारिक समीक्षा को प्रोत्साहित कर रहे हैं, जिससे आप अपने समुदाय से प्रस्तावित परिवर्धनों को भी देख सकें, ताकि फायदे और नुकसान पर चर्चा की जा सके।
तो, जो कुछ भी निर्णय होगा, वह एक समुदाय समर्थित है, न केवल आपके द्वारा बनाया गया है।
आप मूल डिजाइन के आर्किटेक्ट हैं, वास्तुकला के कारणों को प्रदान करने के लिए उत्कृष्ट स्थिति में भी हैं, क्यों कुछ शामिल नहीं है (अभी तक) शामिल/तैनाती के लिए उपयुक्त है।
यदि स्थिरता, जटिलता या कोड की गुणवत्ता एक वास्तविक चिंता है, तो यह बताएं कि स्वीकार्य होने के लिए एक निश्चित समीक्षा प्रक्रिया के माध्यम से अन्य योगदानों को कैसे जाना है।
आप यह भी उल्लेख कर सकते हैं कि विशिष्ट कोड वास्तव में आपके वर्तमान डिज़ाइन के साथ कैसे संरेखित नहीं होता है, या भविष्य में विस्तार के साथ यह आपके वर्तमान डिज़ाइन के साथ कितना अच्छा नहीं हो सकता है, इसी प्रकार आप स्पष्ट कर सकते हैं कि कुछ सामान स्पष्ट रूप से क्यों छोड़े गए थे।
आप वास्तव में सुविधाओं या मूल विचार की तरह, उत्कृष्ट इसके अलावा इन सुविधाओं होगा अगर ठीक से लागू और एकीकृत हाइलाइट करना सुनिश्चित, लेकिन यह भी उजागर करते हैं मौजूदा कार्यान्वयन एक की वजह से वास्तव में उचित नहीं है कि अगर कारणों की संख्या।
यदि आप कर सकते हैं, सुधार के लिए विशिष्ट सुझाव दें, चीजों को बेहतर तरीके से कैसे करें, और इससे बचने के लिए उदाहरण दें कि आप उम्मीद करते हैं कि इसे आपके प्रोजेक्ट के समुदाय की मदद से जोड़ा जा सकता है।
आदर्श रूप से, इस योगदान को वास्तव में स्वीकार करने के लिए अपनी आवश्यकताओं को प्रस्तुत करें और अपनी आवश्यकताओं के लिए पृष्ठभूमि का जिक्र करें, आप वास्तव में कह सकते हैं कि आप इन आवश्यकताओं में से कुछ से नफरत करते हैं।
उन उदाहरणों को प्राथमिकतापूर्वक, उपस्थित करें और उन पर चर्चा करें जहां आपने स्वयं को समान कोड (या इससे भी बदतर कोड) का योगदान दिया है और आप अपने कोड के कारण बड़े मुद्दों का सामना कर रहे हैं, ताकि इन नीतियों को ऐसे मुद्दों को रोकने के लिए अब जगह हो। वास्तव में अपने स्वयं के खराब कोड के बारे में बात करके, आप वास्तव में बहुत ही व्यक्तिपरक हो सकते हैं।
जोर देते हैं कि आप आम तौर पर प्रयास की सराहना करते हैं, और आप कोड को प्रश्न में बेहतर आकार और रूप में लाने के लिए आवश्यक सहायता और पॉइंटर्स प्रदान करने के इच्छुक हैं। साथ ही, प्रोत्साहित करें कि समान मुद्दों से बचने के लिए, भविष्य में समान योगदान को आपके समुदाय के भीतर उचित रूप से समन्वयित किया जाना चाहिए।
हमेशा सुविधाओं और कार्यक्षमता के संदर्भ में सोचें (और अपने योगदानकर्ता को ऐसा करने के लिए याद दिलाएं), कोड नहीं - इसे पूरी तरह से कोड समीक्षा प्रक्रिया की तरह कल्पना करें, जहां अंतिम कोड जो प्रतिबद्ध/स्वीकृत होने पर समाप्त होता है, शायद ही कभी हो मूल कार्यान्वयन के साथ कुछ भी सामान्य है।
यह फिर से एक अच्छी संभावना है, उदाहरणों को पेश करने के लिए जहां आपने स्वयं विकसित कोड विकसित किया है जो बड़े पैमाने पर पुनर्निर्मित हो गया है, ताकि इसमें से अधिकतर अब बेहतर कार्यान्वयन से बदल दिया जा सके।
इसी तरह, हमेशा ऐसे कोड के साथ समस्या होती है जिसमें कोई सक्रिय रखरखाव नहीं होता है, इसलिए आप आसानी से सुझाव दे सकते हैं कि आप ऐसे कोड के बारे में चिंतित हैं जो अनियंत्रित हो सकता है, आप यह भी पूछ सकते हैं कि संबंधित डेवलपर तैयार होगा या नहीं उस कोड को संभवतः एक अलग शाखा में बनाए रखने में मदद करें।
इसी तरह, हमेशा उचित टिप्पणियों, दस्तावेज़ीकरण और अन्य अपडेट के साथ नए कोड की आवश्यकता होती है। दूसरे शब्दों में, कोड जो नई जोड़ता है या मौजूदा कार्यक्षमता को बदलता है, हमेशा सभी प्रासंगिक दस्तावेजों के अपडेट के साथ होना चाहिए।
आखिरकार, यदि आप तुरंत जानते हैं कि आप निकट भविष्य में उस कोड को स्वीकार नहीं कर सकते हैं और स्वीकार नहीं करेंगे, तो आप कम से कम डेवलपर को शाखा में या यहां तक कि अपनी परियोजना को फोर्क कर सकते हैं, संभवतया आप में रिपोजिटरी और आपकी मदद से और मार्गदर्शन, ताकि आप अभी भी अपनी परियोजना के साथ काम करने के लिए अपना आभार व्यक्त कर सकें।
अच्छे कोडिंग प्रथाओं पर एक पुस्तक के साथ उसे मारने के बारे में कैसे? ;-) –