"यह एक खुला स्रोत है, एक पैच सबमिट करें" के लिए कैनोनिकल रिटॉर्ट क्या है? [बन्द है]


215

किसी उत्पाद, विशेष रूप से खुले स्रोत पर कुछ सुविधा का सुझाव देने का खतरा यह है कि आपको प्रतिक्रिया मिलेगी, "आप ऐसा क्यों नहीं करते?"।

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

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

[पीएस (कुछ दिनों में) - मुझे ध्यान देना चाहिए कि "सबमिट ए पैच" अक्सर विनोदी हास्य के साथ कहा जाता है, और मैं एक उपयुक्त मजाकिया प्रतिक्रिया मांग रहा हूं।]


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

62
मुझे लगता है "मुझे क्या लगता है, एक बेरोजगार कोड बंदर? मेरे पास एक जीवन है!" नहीं एक स्वीकार्य प्रत्युत्तर ;-) है
स्टीवन ए लोव

12
मेरे अनुभव में, "सबमिट ए पैच" जवाब आमतौर पर तब आता है जब डेवलपर पहले ही बता चुका होता है कि फीचर जोड़ना व्यावहारिक क्यों नहीं होगा।
user16764

7
@ सही, आप पर निर्भर करता है कि आप अपमान करना चाहते हैं या वास्तव में उन्हें वही करना चाहिए जो आपको चाहिए। मेरा मानना ​​है कि यदि आप उत्तरार्द्ध चाहते हैं तो यह एक इष्टतम रणनीति नहीं है।

12
@orokusaki: या डी) वे इस सुविधा को अन्य सुविधाओं की तुलना में कम मूल्यवान मानते हैं जिन पर वे काम कर सकते हैं, और उनके पास सीमित संसाधन हैं।
डेविड थॉर्नले

जवाबों:


115

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

यह कहा जा रहा है, "एक पैच सबमिट करें" एक वैध जवाब नहीं है। यह विनम्र नहीं है। यह सही नहीं है। यहां तक ​​कि एक ओपन सोर्स प्रोडक्ट के लिए भी। "पैच सबमिट करें" इसका संक्षिप्त संस्करण है:

"हमें परवाह नहीं है कि आप हमारे उत्पाद को पसंद करते हैं या नहीं। यदि आप चाहें तो इसे संशोधित और संशोधित करें, लेकिन अपने ग्राहक अनुरोधों से हमें परेशान न करें।"

पैच जमा करने के बारे में क्या?

खैर, यह इतना आसान नहीं है। इसे करने के लिए:

  • आपको ओपन सोर्स प्रोजेक्ट में इस्तेमाल की जाने वाली भाषा पता होनी चाहिए।

  • आप इसे संशोधित करने में सक्षम होने के लिए संस्करण नियंत्रण से स्रोत कोड लोड करने में सक्षम होना चाहिए।

  • आपके पास किसी भी बिल्ड निर्भरता के सभी सही संस्करण स्थापित होने चाहिए (रनटाइम लाइब्रेरी और बिल्ड टूल दोनों सहित)।

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

  • आपको यह अच्छी तरह से समझना चाहिए कि परियोजना कैसे की जाती है , कोडिंग शैली का उपयोग करने के लिए क्या है, यदि कोई हो, इकाई परीक्षण कैसे चलाएं, आदि। ), यह वास्तव में कठिन हो सकता है।

  • आपको अपने आप को परियोजना के लिए और डेवलपर्स की आदतों के अनुकूल होना चाहिए जो परियोजना में सक्रिय रूप से भाग ले रहे हैं। उदाहरण के लिए, यदि आप प्रतिदिन .NET फ्रेमवर्क 4 का उपयोग करते हैं, लेकिन प्रोजेक्ट .NET फ्रेमवर्क 2.0 का उपयोग करता है, तो आप LINQ, और न ही कॉन्ट्रैक्ट कॉन्ट्रैक्ट्स का उपयोग नहीं कर सकते हैं, न ही फ्रेमवर्क के नवीनतम संस्करणों के अन्य हजारों नए फीचर।

  • आपके पैच को स्वीकार किया जाना चाहिए (जब तक आप केवल खुद के लिए बदलाव नहीं करते हैं, बिना समुदाय के साथ साझा करने के इरादे से)।

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

तो क्या यह "खुला स्रोत, एक पैच सबमिट करें" के लिए एक विहित जवाब है? मुझे ऐसा नहीं लगता। या तो आप उस व्यक्ति को समझाएं कि वह अयोग्य है, या आप उससे बात करना बंद कर दें।


9
ऐसा लगता है कि यह किसी के द्वारा लिखा गया था जिसमें कोई भी अनुभव नहीं है जो एक खुला स्रोत परियोजना बनाए रखता है।
रीन हेनरिच

46
@ रिन: एक ओपन सोर्स प्रोजेक्ट को बनाए रखना किसी भी अन्य प्रोजेक्ट को बनाए रखने से अलग नहीं है। आपके पास ग्राहक हैं। यदि आप उन ग्राहकों को अनदेखा करते हैं, तो वे आपको मूल्यवान प्रतिक्रिया देना बंद कर देंगे, और वे अपने समाधान के लिए कहीं और जाएंगे। हो सकता है कि यह ओपन सोर्स लोगों के साथ ठीक हो, लेकिन मुझे यकीन है कि मैं जानना चाहूंगा कि क्या मैं ओपन सोर्स सॉफ्टवेयर के एक टुकड़े को बग फिक्स करने के लिए पूरी तरह से जिम्मेदार होने जा रहा हूं, क्योंकि इससे मुझे इसके इस्तेमाल के बारे में दो बार सोचना पड़ेगा।
रॉबर्ट हार्वे

17
@ रीन: अब तक मैंने दो बार कहा कि आपने सुना है कि हम नहीं जानते कि हम किस बारे में बात कर रहे हैं। हो सकता है कि आप हमें बता सकते हैं, एह?
रॉबर्ट हार्वे

8
@ हेन हेनरिक्स: आपकी पहली दो टिप्पणियाँ '' विज्ञापन होमिनेम '' हमले हैं। यदि दोनों के बीच मतभेद हैं, तो कहें कि वे क्या हैं, कहने के बजाय अन्य लोग कुछ भी नहीं जानते हैं।
एंड्रयू ग्रिम

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

79

विहित प्रतिलेख एक पैच प्रस्तुत करना है।


47
या बेहतर है, कहने के लिए, "मैं पहले से ही छह महीने पहले किया था। जब आप लोग इसे समीक्षा करने और इसे करने के लिए चारों ओर जाने वाले हैं?"
बॉब मर्फी

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

19
-1 ओपन सोर्स गधे जवाब। उपयोगी नहीं। (क्षमा करें।) कोई विहित "मुंहतोड़ जवाब" नहीं है। सर्वश्रेष्ठ प्रतिक्रिया (ओपी का मानना ​​है कि केवल एक पैच प्रस्तुत नहीं किया जा सकता है, जो मुझे लगता है कि इस मामले में एक उचित धारणा है) एक (1) में से एक है "मेरे पास एक पैच उत्पन्न करने की क्षमता या संसाधन नहीं हैं [और संभवतः इसमें शामिल हैं इस बहुत ही प्रश्न से लिंक] ", (2) आईरोल, कोई प्रतिक्रिया नहीं, इसकी वर्तमान स्थिति में उपकरण का उपयोग, या (3) बेहतर टूल की खोज करें।
JohnL4

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

67

यह मानक उत्तर है जब डेवलपर्स को नहीं लगता कि वे किसी भी उचित समय सीमा में कुछ करने के लिए चारों ओर मिलेंगे, लेकिन इसे बार-बार लाया गया है।

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

यदि आप बार-बार स्वयं एक अनुरोध ला रहे हैं, तो "पैच लेना" संभवतः एक अपेक्षाकृत विनम्र ब्रश-बंद होने का इरादा है, बनाम कुछ कम विनम्र विकल्प ...

और फिर निश्चित रूप से असभ्य अनुचर हैं जो कहेंगे "पैच लेना" किसी के साथ कभी भी स्पष्टीकरण नहीं है, लेकिन मैं कहूंगा कि यह अल्पसंख्यक है।

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

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

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

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

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


4
@Aaronaught मैंने लगभग सैकड़ों ओपन सोर्स प्रोजेक्ट्स किए हैं और DIY को डिफ़ॉल्ट प्रतिक्रिया के रूप में नहीं देखा है। यह अनुरोध के कुछ स्वादों के लिए एक प्रतिक्रिया है।
हैवोक पी।

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

5
इसके अलावा, जबकि यह कम या ज्यादा विनम्रता phrased जा सकता है, अगर एक मेंटेनर उनके मन में एक काम बैकलॉग है, वे शायद 1 बात वे खुद के लिए प्राप्त कर सकते हैं, हर 100 बातों के लिए उनके पास हैं के लिए है क्योंकि वे चाहते हैं एक पैच ले सुविधा; और फिर वहाँ परिवर्तनों की एक और श्रेणी है, भले ही वे किसी और ने काम किया हो, वे अस्वीकार कर देंगे। इसलिए संचार करने के लिए कुछ तरीका होना चाहिए "मैं उस बदलाव को ले लूंगा, लेकिन इसे स्वयं करने की योजना नहीं है।" यहाँ कुछ लोगों को लगता है कि "निश्चित रूप से सही आ रहा है" केवल स्वीकार्य उत्तर है। लेकिन "उस पर पैच लेना" एक वास्तविक श्रेणी है।
हैवोक पी।

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

2
दरअसल, "हम इसके लिए एक पैच लेंगे" दो सूक्ष्म लेकिन महत्वपूर्ण तरीकों से अलग है: (1) यह सीधे उपयोगकर्ता पर जिम्मेदारी नहीं डालता है , और (2) यह स्वीकार करता है कि अनुरोध नहीं होने के बावजूद गंभीरता से विचार किया गया है कार्यान्वित किया। हालांकि शुद्ध परिणाम अनिवार्य रूप से एक ही है, यह एक बहुत अधिक मानवीय जवाब है। (फिर भी, यह स्पष्ट रूप से निहित को जोड़ने के लिए चोट नहीं पहुंचाएगा ... लेकिन हमारे पास अभी खुद को पूरा करने के लिए संसाधन नहीं हैं। )
हारून को

43

इस प्रतिक्रिया को प्राप्त करने का कारण यह नहीं है कि अनुरक्षक झटके हैं, यह है कि आपने उन्हें आपके लिए आपके फीचर पर काम करने के मूल्य प्रस्ताव के पर्याप्त रूप से आश्वस्त नहीं किया है

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

यदि सुविधा केवल आपके लिए और समुदाय के लिए कम मूल्य के लिए मूल्यवान है, तो मुझे लगता है कि पैसा एक उत्कृष्ट प्रेरक है, जबकि उनके रवैये के बारे में शिकायत नहीं है।


15
बेशक, शायद वे झटके हैं। अकेले यह प्रतिक्रिया बहुत सटीक संकेतक नहीं है, क्योंकि इसका उपयोग गैर-झटके द्वारा भी किया जाता है जब पूछने वाला झटका होता है।
रीन हेनरिक्स

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

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

4
इसी तरह, जब लोगों को उत्तर के रूप में RTFM या DAFS मिलता है, या SE पर -1, ऐसा इसलिए है क्योंकि प्रश्नकर्ता ने उनके लिए उनके प्रश्न का उत्तर देने के मूल्य प्रस्ताव के उत्तरदाता को पर्याप्त रूप से आश्वस्त नहीं किया है । मुझे यकीन है कि आप में से कई इस भावना से संबंधित हो सकते हैं।
रीन हेनरिक्स

1
@Walter Yep, यही वजह है कि मैंने "पूरे समुदाय के रूप में आपके फ़ीचर के मूल्य" के व्यक्ति को समझाने का सुझाव दिया।
रीन हेनरिच

31

"यह एक खुला स्रोत है, एक पैच सबमिट करें" के लिए कैनोनिकल रिटॉर्ट क्या है?

कोई उचित मुंहतोड़ जवाब देने के लिए कोई फर्क नहीं पड़ता है। स्वयंसेवकों को कुछ ऐसा करने के लिए मनाने की कोशिश करना, जो करने का उनका कोई इरादा नहीं है, आपके समय की बर्बादी है ... या इससे भी बदतर।

आपके विकल्प हैं:

  • प्रतिक्रिया जो बताए; यानी फीचर को लागू करें और इसे पैच के रूप में सबमिट करें। इसे "कुछ वापस देना" कहा जाता है।

  • किसी ऐसे व्यक्ति को खोजें, जो वास्तविक धन के लिए आपके लिए सुविधा लागू करने के लिए तैयार हो। यह स्वयं प्रोजेक्ट हो सकता है (जैसे प्रायोजन के बदले में), परियोजना से जुड़ा कोई व्यक्ति, या किराए के लिए कुछ यादृच्छिक "कोडर"।

  • एक वैकल्पिक उत्पाद का पता लगाएं।


यदि आपको "मददगार" सुझाव देने पर यह प्रतिक्रिया मिली, तो विचार करें कि यदि आप उसके जूते में थे, तो आपने कैसे प्रतिक्रिया दी होगी। उदाहरण के लिए, यदि आप सोचते हैं कि सुझाव सार्थक / सुविचारित / समझदार / आदि नहीं था, तो आप कैसे प्रतिक्रिया देंगे, लेकिन एक लंबी बहस में शामिल होने का समय या धैर्य नहीं था?


मैं एक लंबे समय से चल रहे ओपन सोर्स OS प्रोजेक्ट में शामिल रहा हूं, और सबसे अधिक कष्टप्रद चीजों में से एक ऐसे लोग हैं जो "मूंगफली गैलरी" में बैठते हैं और आपको चीजों को "बेहतर" करने के बारे में सुझावों की एक धारा के साथ काली मिर्च करते हैं:

  • अपूर्ण, अचूक या सर्वथा निरर्थक हैं,
  • सफलता के एक निष्पक्ष रूप से कम अवसर के साथ अविवाहित विचार हैं,
  • लागू करने के लिए प्रयास की एक बड़ी राशि की आवश्यकता होगी, और / या
  • परियोजना के घोषित लक्ष्यों के लिए काउंटर हैं।

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

बेशक, ऐसे लोगों के लिए दूसरी प्रतिक्रिया बिल्कुल भी प्रतिक्रिया नहीं करना है, या उन्हें पूरी तरह से अनदेखा करना है।


7
"यदि आप सोचते हैं कि सुझाव सार्थक / सुविचारित / समझदार / आदि नहीं था तो आप कैसे प्रतिक्रिया देंगे" - ठीक इसी तरह से हर दूसरे पेशेवर जवाब देता है। "क्या आप समझा सकते हैं / कुछ उदाहरण दे सकते हैं जो आप पूछ रहे हैं?" या "क्या आप मुझे इस बारे में कुछ पृष्ठभूमि दे सकते हैं कि आपको क्यों इस सुविधा की आवश्यकता है?" या "अगर हमने इसके बजाय यह काम किया, तो क्या यह आपके लिए काम करेगा?" या कैसे के बारे में "आपके सुझाव के लिए धन्यवाद, हम इसे भविष्य के रिलीज के लिए विचार करेंगे।" यह बुनियादी पारस्परिक कौशल है, न कि रॉकेट विज्ञान।
आरोह

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

6
@ ठाकुरजी - वास्तव में, यदि प्रश्न वाले लोग डीआईडी ​​जमा करते हैं, तो वे निश्चित रूप से विचार करेंगे। समस्या यह है कि प्रश्न वाले लोग "सभी मुंह" हैं; यानी किसी भी प्रयास में कोई दिलचस्पी नहीं है।
स्टीफन सी

10
क्योंकि ठेठ ओपन सोर्स डेवलपर के पास पहले से ही एक नौकरी है, और वे अपने ओपन सोर्स डेवलपमेंट को मजे के लिए करते हैं। दूसरे लोग जो करना चाहते हैं, वह करना काम है। आप जो करना चाहते हैं, वह करना मजेदार है।
प्रोडिजीसिम

8
@ चेतावनी: क्या बहुत सारे झटके का सम्मानपूर्वक व्यवहार करना आवश्यक है? एक सार्वजनिक सेवा को देखते हुए, ऐसे लोग होंगे जो अनुचित मांग करते हैं, अक्सर अपमानजनक रूप में। मूर्ख मूर्खों के साथ व्यवहार करना एक वास्तविक दर्द हो सकता है। उनके लिए सम्मानजनक होने की आवश्यकता एफ / ओएस व्यवसाय से बहुत से लोगों को निकाल देगी, और यह हर किसी के लिए नुकसान दायक होगा।
डेविड थॉर्नले

20

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

आप बराबरी नहीं कर रहे हैं (या आप शायद बस कर दिया होगा) तो मैं एक उचित मुंहतोड़ जवाब दूंगा:

"कोई तरीका नहीं है कि मैं इसे जितना संभव हो उतना तेज़ और अच्छा कर सकता हूं, यही कारण है कि मैंने आपको पहली जगह में मेरी मदद करने के लिए कहा। कृपया!"

मेरा मानना ​​है कि यह कहने के लिए मौलिक मानव स्वभाव के खिलाफ जाता है, "ओह, हां, इस चीज पर मैंने एक लंबा समय बिताया है और वास्तव में अच्छा है, इतना सरल है कि कोई भी सड़क से आ सकता है और उतना ही अच्छा काम कर सकता है जितना कि मैं कर सकता हूँ ”।


सिवाय इसके कि वास्तव में वे क्या कह रहे हैं। वे कह रहे हैं "यह बात जो आप चाहते हैं वह कुछ नहीं है जो समुदाय चाहता है, इसलिए हम वास्तव में इस पर काम करने में रुचि नहीं रखते हैं। यदि आप इस पर काम करना चाहते हैं तो हम एक पैच स्वीकार कर सकते हैं।" यदि हम चाहते हैं कि समुदाय चाहे तो अपने विचारों को बदल सकता है। याद रखें कि "मैं चाहता हूं कि आप मेरी मदद करें " खुले स्रोत परियोजनाओं की मूल प्रकृति के खिलाफ जाता है , जहां (मेरे स्टार ट्रेक नीडर को सहन करने के लिए पूरी ताकत लाने के लिए) कई लोगों में से कुछ का भला होता है।
रीन हेनरिक्स

खैर, जब तक उन लोगों के पास बहुत पैसा नहीं है, ऐतिहासिक रूप से बोल रहा हूं।
रीन हेनरिक्स

2
@ रेइन, नहीं, वे जो कह रहे हैं वह यह है कि वे इसे नहीं करना चाहते हैं। यह सब "समुदाय चाहता है" सिर्फ एक पुआल आदमी है। संपूर्ण बिंदु यह है कि COMMUNITY में से एक इसे अनुरोध कर रहा है।

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

1
@ थोरबजोरन आह हां। ठीक है, वास्तव में खुले स्रोत के रख-रखाव से मैं परिचित हूं निश्चित रूप से ऐसा नहीं लगता है। वास्तव में, हम लोगों को परियोजना को सीखने में मदद करने के लिए डेवलपर दिशानिर्देश और प्रलेखन प्रदान करने के लिए हमारे रास्ते से बाहर जाते हैं और इसे ठीक से योगदान देने के लिए सम्मेलनों को करते हैं क्योंकि हम कौशल अंतर से अवगत हैं। उदाहरण के लिए, rubini.us/doc/en/contributing
Rein Henrichs

16

कैनोनिकल रिटॉर्ट प्रोजेक्ट को कांटा करना है।


8
या एक पैच जमा करें
कामिल स्ज़ोट

2
क्या अच्छा फोर्किंग आपको लाएगा?

1
@ थोरबॉर्न: हर कोई अब और फिर से एक अच्छा कांटा इस्तेमाल कर सकता है। यहां तक ​​कि एक दया कांटा भी।
user18014

15

"एक पैच सबमिट करने" का विहित उत्तर है:

"मेरे पास कौशल, अनुभव या समय की आवश्यकता नहीं है, तो क्या आप मुझे यह बता सकते हैं कि बीयर के मामलों को उस व्यक्ति को कैसे भेजना है जो मेरे लिए यह कर सकता है"


13

एक व्यापक परीक्षण मामला प्रस्तुत करें


1
मुझे यह पसंद है, हालांकि, ऐसा करने में अक्सर पैच को सबमिट करने की तुलना में अधिक समय लगेगा! यहाँ निरंतर कोड आधार के साथ परिचित होने का समय है और सबसे अधिक संभावना है कि या तो परीक्षण बनाने या सीधे पैच लिखने का सबसे बड़ा हिस्सा है!
न्यूटोपियन

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

11

"यदि आप इसे करते हैं, तो मैं इसे शामिल करूंगा" से बेहतर है "नहीं।"

यदि आप एक कारण या किसी अन्य के लिए कार्य करने में असमर्थ हैं, तो निजी में प्रोजेक्ट अनुचर को परिस्थिति स्पष्ट करें।

यदि आप किसी ओपन-सोर्स प्रोजेक्ट में किसी तरह से योगदान करने के लिए तैयार नहीं हैं, जिसे आप उपयोग करना चाहते हैं, तो आपको इसके बजाय वाणिज्यिक सहायता या किसी अन्य वाणिज्यिक उत्पाद की तलाश में होना चाहिए।


5
तो केवल जो लोग सीधे योगदान करते हैं उन्हें बग या लापता सुविधा के बारे में शिकायत करने का कोई अधिकार है? ठीक है, मुझे लगता है, लेकिन इसका मतलब यह भी है कि न तो योगदानकर्ताओं और न ही उपयोगकर्ताओं को गोद लेने की कमी के बारे में शिकायत करने का कोई अधिकार नहीं है।
आरोह

@Aaronaught नहीं, उन्हें शिकायत करने का अधिकार है, लेकिन अवैतनिक समय की एक सीमा है जो एक डेवलपर किसी परियोजना में निवेश कर सकता है और उपयोगकर्ताओं के लिए इसे पहचानना महत्वपूर्ण है। अपने स्वयं के काम में, मैं उन सुविधाओं के लिए "मैं एक पैच / पुल अनुरोध का स्वागत करता हूं" जिनके लिए घटिया प्रयास / सामुदायिक मूल्य प्रस्ताव हैं। या जहां उपयोगकर्ता जोर दे रहे हैं, वे अभी सुविधा प्राप्त करते हैं और किसी और के समय या अन्य परियोजना प्रतिबद्धताओं का सम्मान नहीं करते हैं।
BobMcGee

10

"जवाब के लिए धन्यवाद।"

चूंकि:

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

9

आपको कुछ कहने की जरूरत नहीं है। डेवलपर्स ने जो जवाब दिया है, वह इस बात का पर्याप्त संकेत है कि उन्हें पहले से ही समस्या मौजूद है और कम से कम उपयोगकर्ताओं के लिए दर्द का कारण है।

दिन के अंत में, आप जो कुछ नहीं कहते हैं वह डेवलपर को आपके लिए काम करने के लिए मनाने जा रहा है यदि वे नहीं चाहते हैं।


9

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


8

व्यक्तिगत रूप से, मुझे इसके बजाय "यह एक ज्ञात मुद्दा है, लेकिन एक प्रतिक्रिया मिलेगी, लेकिन दुर्भाग्य से यह जल्द ही किसी भी समय संबोधित नहीं किया जाने वाला मुद्दा है। डेवलपर्स अन्य मुद्दों पर काम कर रहे हैं। फिलहाल कोई ईटीए नहीं है।"

"पैच सबमिट करें" प्रतिक्रिया बहुत असभ्य है, क्योंकि यह कई चीजों को मानता है:

  1. कार्यक्रम के सभी उपयोगकर्ता प्रोग्रामर हैं या सभी बग रिपोर्टर प्रोग्रामर हैं।
  2. सभी प्रोग्रामर जानते हैं कि प्रोग्राम किस भाषा में है।
  3. सभी प्रोग्रामर को हर तरह की समस्या के बारे में पता होता है।
  4. सभी प्रोग्रामर्स के पास ओपन सोर्स प्रोजेक्ट पर काम करने के लिए खाली समय है।

यहां तक ​​कि अगर हम मानते हैं कि "एक पैच सबमिट करें" प्रतिक्रिया निर्माता उपरोक्त सभी को जानता है, तो बस यह बयान देता है जैसे "मेरा समय का एक्स घंटे आपके समय के घंटों से अधिक परिमाण के आदेशों से अधिक है, जो आप उठ सकते हैं। इस मुद्दे को गति देने और ठीक करने के लिए "।

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


क्या आपका मतलब है "मुझे इसके बजाय" मुझे नहीं बल्कि "मिलेगा के रूप में" की प्रतिक्रिया मिली?
एंड्रयू ग्रिम

विशेष रूप से पहले पैराग्राफ के लिए धन्यवाद। यह आश्चर्यजनक है कि पेशेवर शिष्टाचार का ऐसा मूल रूप कितने लोगों के लिए विदेशी हो सकता है। आपको भुगतान किया जाता है या नहीं, उचित प्रतिक्रिया इस मुद्दे को स्वीकार करने और इसकी स्थिति को समझाने के लिए है (भले ही स्थिति "स्थगित" हो)।
आरोहण

8

बस "पैच सबमिट करें" का जवाब देना असभ्य IMO है, लेकिन फिर भी ... यदि आप किसी भी गंभीर चीज के लिए ओपन सोर्स सॉफ्टवेयर का उपयोग करते हैं, तो आपको इस बात का ध्यान रखने के लिए तैयार रहना चाहिए कि आवश्यकता उत्पन्न होनी चाहिए।

निम्नलिखित जेरेमीस मर्की (अपाचे FOP की प्रसिद्धि) द्वारा पोस्ट पर आधारित है :

यदि आपके लिए कुछ काम नहीं करता है, तो आपके पास कई विकल्प हैं:

  • यह खुला स्रोत है: आप इसे स्वयं ठीक कर सकते हैं।
  • यदि आप इसे स्वयं ठीक नहीं कर सकते हैं, तो आप तब तक इंतजार कर सकते हैं जब तक किसी के पास खाली समय नहीं है और यह सोचता है कि इसे लागू करना मजेदार है।
  • यदि ऐसा नहीं होता है, तो आप किसी को यह करने के लिए पा सकते हैं या उसे किराए पर ले सकते हैं।

मुझे लगता है कि यह "सबमिट ए पैच" उत्तर का एक बहुत ही मान्य पूर्ण संस्करण है।


6

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

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

जैसा कि @ मेनमा ने कहा कि एक नए प्रोजेक्ट में योगदान करना बहुत मुश्किल है। अधिकांश डेवलपर्स इसे नहीं समझते हैं क्योंकि वे महीनों / वर्षों से परियोजना पर काम कर रहे हैं और यह उनके लिए समझ में आता है। यह कभी-कभी एक ईमानदार गलती हो सकती है।


3

मैं कभी-कभी मजाक करता हूं कि मुफ्त सॉफ्टवेयर बीयर की तरह मुफ्त हो सकता है, मुफ्त में बोल सकता है या मुफ्त में आप के लिए भुगतान करते हैं।

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

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

हम अक्सर ऐसे सॉफ्टवेयर के बारे में सोचते हैं जो बीयर की तरह फ्री है लेकिन स्पीच में नहीं है (यह नॉन-ओपन फ्रीवेयर है)। शायद यह एक ऐसा मामला है जहां हमें सॉफ्टवेयर के बारे में भाषण में मुफ्त में सोचना चाहिए, लेकिन बीयर में नहीं


2

अच्छी तरह से बनाए रखा विकल्प पर स्विच करें।

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


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

1

"मैं एक समय में केवल एक चीज पर काम कर सकता हूं, लेकिन मैं एक ही बार में कई चीजों के बारे में शिकायत कर सकता हूं। मुझे लगता है कि दोनों कार्य उपयोगी हैं।" - यॉम्बिनेटर पर akkartik


1

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

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


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

1
@ चेतावनी: वे मुफ्त परीक्षण प्रदान कर रहे हैं यदि वे बग रिपोर्ट दर्ज करते हैं जो काम करने के लिए पर्याप्त विस्तृत हैं। मैंने खराब बग रिपोर्ट का अपना हिस्सा देखा है। वे अच्छा विज्ञापन प्रदान कर रहे हैं या नहीं कर सकते हैं। ज्यादातर लोग जो एफ / ओएसएस का उपयोग करते हैं, वे कुछ भी उपयोगी नहीं देते हैं, जो ठीक है, लेकिन यह सुनिश्चित है कि अनुबंध का एक पक्ष नहीं है।
डेविड थॉर्नले

1
@ डेविड: क्या आप केवल सबसे मुश्किल / अनुत्पादक उपयोगकर्ताओं के लिए बातचीत को प्रतिबंधित करने की कोशिश करना बंद कर देंगे? यदि हम सामान्यीकरण करने जा रहे हैं, तो उस सामान्यीकरण को संपूर्ण उपयोगकर्ता और योगदानकर्ता आधार के लिए एक सामूहिक के रूप में होना चाहिए; जनता को जारी करने से आपको इन सभी लोगों को मिल जाता है। उनमें से कई से आपको जो अच्छाई मिलती है, उसके बदले में आपको कई अन्य लोगों से कुछ समस्याएं मिलती हैं। यही ज़िन्दगी है।
१।'११ को ११:३६

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

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

1

इसके कई तरीके होने चाहिए।

  • फीचर प्रस्ताव और वोट। लेकिन इसमें समय लगता है।

  • एक कंपनी द्वारा किराए पर लें जिसे पैच बनाने के लिए इसकी आवश्यकता है। जाहिर है कि यह सबसे अच्छा समाधान है, लेकिन उस व्यक्ति के साथ सहयोग करने के लिए तैयार हो जाइए, जिसे आप ओपन सोर्स सॉफ्टवेयर बनाना चाहते हैं जिसे आप अपग्रेड करना चाहते हैं।

  • यह पता लगाना कि पहली बार में यह सुविधा क्यों लागू नहीं की गई है, यह भी महत्वपूर्ण है। अक्सर फ़ीचर सॉफ़्टवेयर प्रोजेक्ट की लाइन से बाहर होता है: टीम इस फ़ीचर को नहीं चाहती, ज़रूरी नहीं समझती या उन्हें लगता है कि यह कुछ करने का अच्छा तरीका नहीं है। इस मामले में आपको बस परियोजना को कांटा करना चाहिए और इसे स्वयं बनाना चाहिए।

  • मालिकाना सॉफ्टवेयर का उपयोग करें जो आपको चाहिए।

  • याद रखें कि ओओपी सॉफ्टवेयर अक्सर एक सुविधा को एकीकृत करने की प्रक्रिया को आसान बनाता है।

  • मेलिंग सूची पर, irc पर या एक मंच पर प्रोग्रामर सिर्फ प्रोग्रामर्स को पेशाब करेगा, और ओमो के प्रस्तावकों को बारूद देगा।


0

कुछ भी नहीं आप कह सकते हैं होगा कि नहीं है बनाने के लिए उसे यह करना। आखिर वह क्यों करे? एक उपयोगकर्ता की इच्छाओं के कारण? यह पर्याप्त कारण नहीं है।

लेकिन , यदि आप उचित संख्या में उपयोगकर्ता एकत्र कर सकते हैं और तर्कसंगत कारण दे सकते हैं ("मैं चाहता हूं" यह तर्कसंगत कारण नहीं है।) क्यों यह सुविधा उपयोगी हो सकती है, सामान्य रूप से और आपके और दूसरों की संख्या में वह बस अपना दिमाग बदल सकता है। ।

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


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

@ डेविड थॉर्नले - वह भी।
रूक

0

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

साथ ही, हाँ, खुले स्रोत को प्रकाशित करने के पीछे के विचारों में से कोई भी किसी और के लिए अपना योगदान देने का अधिकार और जिम्मेदारी है।

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


2
सही योगदान करने के लिए, हाँ, लेकिन पिछली बार मैं जीपीएल पढ़ा इसके बारे में कुछ उल्लेख नहीं था, जिम्मेदारी अंत उपयोगकर्ताओं को अपने स्वयं योगदान करने के लिए के लिए। यह थोड़ी दूर की बात है, क्या आपको नहीं लगता?
हारून को

0

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

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

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


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

@ राई मियासाका: व्यक्तिगत रूप से, मैं उग्र हो जाऊंगा यदि मुझे "एक पैच सबमिट करें", एक अच्छी गुणवत्ता वाला पैच बनाने के लिए काम किया, और फिर कहा गया कि वे वैसे भी सुविधा नहीं चाहते हैं।
डेविड थॉर्नले

@ दाविद हाँ एह? मैं एक या दो कुर्सी फेंक दूंगा।
री मियासाका

0

"सबमिट ए पैच" उन विचारों के लिए एक वैध ब्रश है जो परियोजना के लक्ष्यों में फिट नहीं होते हैं। शायद यह लंबे समय में बेहतर है कि आप सिर्फ यह बताएं कि यह विचार बेकार है या आप इस परियोजना का उपयोग करने की कोशिश कर रहे हैं, यह अभीष्ट दायरे से बाहर है, लेकिन "हे, अगर आपको लगता है कि आप जो पूछ रहे हैं वह इतना तुच्छ है, तो डॉन ' t आप इसे हमारे मौजूदा कोड बेस में फिट करने का प्रयास करते हैं "कुछ समय के लिए उपयुक्त है।

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

एक मामूली साधारण बदलाव की तरह लग सकता है जो उपयोगकर्ताओं के टन में मदद करेगा वास्तव में गधे में एक बड़ा दर्द हो सकता है जो आपके अलावा कोई भी उपयोग नहीं करेगा। "एक पैच सबमिट करें" के लिए यह सबसे अच्छा मामला है।

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


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

2
"एक पैच जमा करें" वास्तव में घटिया ब्रशऑफ़ बनाता है, क्योंकि यह संभव है कि कोई व्यक्ति एक पैच प्रस्तुत करेगा। इसे कम-प्राथमिकता वाले अच्छे-से-बाजों के लिए आरक्षित किया जाना चाहिए।
डेविड थोरले

0

मेरा सुझाव है कि RentACoder / ELance / आदि जैसी साइटों पर सुविधा को लागू करने के लिए एक परियोजना बनाई जाए और इसके बारे में मूल ओपन सोर्स प्रोजेक्ट के फ़ोरम पर पोस्ट किया जाए। लेखक सहित खुले स्रोत परियोजनाओं में से कोई भी प्रोग्रामर, अब आपके अनुरोध पर विचार करने के लिए वित्तीय प्रोत्साहन देता है।


-1

मैंने वास्तव में इस प्रश्न का उत्तर देने के लिए साइन अप किया है।

क्या मुंहतोड़ जवाब की जरूरत है? इस प्रतिक्रिया का उपयोग आमतौर पर तब किया जाता है जब डेवलपर को मुद्दे के बारे में पता होता है, लेकिन वह इसे महत्वपूर्ण नहीं मानता है।

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

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

यदि यह एक वास्तविक तकनीकी समस्या थी, तो मैं शायद कार्रवाई करूंगा लेकिन यह विशुद्ध रूप से एक राजनीतिक पैंतरेबाज़ी है, इसलिए नहीं मुझे ऐसा नहीं लगता।

नहीं, मैं इसे सिर्फ श्वेत सूची में रखूंगा

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

निचला रेखा: विहित प्रतिलेख पैच को सबमिट करने के लिए होगा, लेकिन यदि आप नहीं कर सकते हैं तो एक मुंहतोड़ जवाब की आवश्यकता नहीं है


-1

इच्छित सुविधा के लिए एक इनाम शुरू करें।

या बाहर जाओ और उस उत्पाद को खरीदो जो दावा करता है कि आप क्या चाहते हैं और अपने सहायक कर्मियों का दुरुपयोग करते हैं जब आपको पता चलता है कि विपणन आपकी अपेक्षाओं से मेल नहीं खाता है।


-2

सबसे अच्छा मैं सोच सकता हूं कि "आप चूसते हैं"।

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.