Gitter द्वारा
_एंड्रयू फिशर एक ऐसे प्रोजेक्ट पर काम करते हैं जो हार्डवेयर और सॉफ्टवेयर को मिलाकर सुंदर लाइटिंग इफेक्ट्स बनाता है। उन्होंने हमें अपने प्रोजेक्ट के आसपास ओपन सोर्स समुदाय को बढ़ावा देने और प्रबंधित करने के अपने तरीके के बारे में बताया। पता करें कि वह क्या कहते हैं और Node-Pixel Gitter चैनल देखें।_
हमें अपने और Node-Pixel समुदाय के बारे में थोड़ा बताएं। Node-Pixel क्या है? यह सब कैसे शुरू हुआ?
मैं 20 वर्षों का एक करियर वेब डेवलपर हूं और अब LUXE City Guides का CTO हूं। मैं हमेशा विभिन्न रूपों में ओपन सोर्स समुदाय में शामिल रहा हूं और पिछले कुछ वर्षों में JavaScript रोबोटिक्स (nodebots) समुदाय में गहराई से शामिल रहा हूं।
Node-Pixel उसी से निकला, जिसमें प्रोजेक्ट विशेष रूप से हार्डवेयर और सॉफ्टवेयर (JavaScript) को एक साथ मिलाकर सुंदर लाइटिंग इफेक्ट्स बनाता है। यह इसलिए शुरू हुआ क्योंकि ऐतिहासिक रूप से JS हार्डवेयर की दुनिया में ऐसा करने का कोई आसान तरीका नहीं था और मुझे सुंदर लाइट्स पसंद हैं इसलिए मैंने कुछ ऐसा बनाने का फैसला किया जो यह करे।
समुदाय निश्चित रूप से Johnny-Five और NodeBots समुदायों का एक सबसेट है जिसमें वे लोग शामिल हैं जो विशेष रूप से हार्डवेयर लाइटिंग में रुचि रखते हैं (अन्य समूह पारंपरिक रोबोटिक्स या होम ऑटोमेशन आदि में अधिक रुचि रखते हैं)। इस प्रोजेक्ट को दुनिया भर के कुछ आश्चर्यजनक रूप से प्रतिभाशाली डेवलपर्स के कमिट्स मिले हैं जिन्होंने JavaScript से हार्डवेयर लाइटिंग को नियंत्रित करने के एक सीधे तरीके के लक्ष्य को साकार करने में मदद की है।
एक समुदाय के रूप में आपके क्या सामान्य लक्ष्य हैं?
वास्तव में ऊपर बताए अनुसार, लोगों को JavaScript के साथ हार्डवेयर का उपयोग करते देखना और विशेष रूप से बहुत परिष्कृत हार्डवेयर के साथ काम करने का एक सीधा तरीका होना।
Node Pixel प्रोजेक्ट से संबंधित कौन से मुद्दे आपको इन दिनों सबसे ज्यादा उत्साहित करते हैं?
निश्चित रूप से Interchange में व्यापक एकीकरण, जो एक प्रोजेक्ट है जिसमें मैं भी शामिल हूं। Interchange हार्डवेयर फर्मवेयर्स के लिए वही हल करता है जो pip और npm पायथन और JavaScript मॉड्यूल के लिए हल करते हैं - यानी विशिष्ट लक्ष्यों के लिए पैकेज मैनेजमेंट। Node Pixel प्रोजेक्ट ने JS हार्डवेयर की दुनिया में इस आवश्यकता को चित्रित किया और Interchange को जन्म दिया, इसलिए इसे Interchange के साथ पूरी तरह से संगत बनाना एक बड़ा लक्ष्य है।
इससे परे अगला बड़ा प्रयास लाइब्रेरी को एनिमेशन जैसी चीजों के लिए अधिक सक्षम बनाना है, ताकि वास्तव में परिष्कृत लाइटिंग इफेक्ट्स बनाए जा सकें और उन सभी को NodeJS से या संभावित रूप से सीधे ब्राउज़र से ट्रिगर किया जा सके।
समुदाय बनाते और बनाए रखते समय आपने सबसे महत्वपूर्ण कारकों को क्या ध्यान में रखा है? आपके समुदाय की सफलता में कौन से कारक योगदान करते हैं?
सबसे बड़ी चीजें वास्तव में मुझे लगता है कि पारदर्शिता रही है - हम Gitter और GitHub इश्यूज का एक बड़ा हिस्सा के रूप में उपयोग करते हैं ताकि भौगोलिक रूप से अलग-अलग लोगों के बीच सहयोग को बढ़ावा दिया जा सके। हमारी चर्चाओं के लॉग आदि होने से समुदाय को वापस जाकर किसी चीज के पीछे के तर्क को समझाना आसान हो जाता है, खासकर यदि वे प्रोजेक्ट के उपयोगकर्ता हैं लेकिन उसमें योगदान नहीं दे सकते।
इससे संबंधित यह है कि हम प्रोजेक्ट में योगदान के लिए आचार संहिता का पालन करते हैं और शुरुआत से ही हमने हमेशा एक खुले, भरोसेमंद, सुरक्षित और जिम्मेदार समुदाय को बढ़ावा देने का प्रयास किया है। मुझे लगता है कि जब लोग इसे सिर्फ "चीजों का तरीका" के रूप में स्थापित करते हैं तो यह लोगों को उन मानकों को अपनाने में मदद करता है जब वे जुड़ते हैं। Node Pixel उस संबंध में अच्छा रहा है लेकिन वास्तव में Johnny-Five और सामान्य रूप से JavaScript द्वारा JS हार्डवेयर की दुनिया में किए जा रहे व्यापक कार्य का बहुत ऋणी है ताकि सुरक्षित स्थान सुनिश्चित किए जा सकें।
समुदाय का प्रबंधन करते समय आपको किन प्रमुख चुनौतियों का सामना करना पड़ता है?
टाइम जोन्स!!!!
मैं ऑस्ट्रेलिया में हूं और मेरे अधिकांश सहयोगी US और EU में हैं इसलिए जब हम फीचर्स आदि बनाने के माध्यम से काम कर रहे होते हैं तो ओवरलैप प्राप्त करना वास्तव में चुनौतीपूर्ण हो सकता है। प्रशांत या हिंद महासागर को उनके आकार का लगभग आधा बनाने की आवश्यकता है ;)
Gitter पर Node Pixel प्रोजेक्ट चैनल में चर्चा किए जाने वाले मुख्य मुद्दे क्या हैं?
दिन-प्रतिदिन की बहुत सी चीजें प्रोजेक्ट का उपयोग करने वाले लोगों के लिए समर्थन के इर्द-गिर्द घूमती हैं। हम Gitter के उपयोग के बारे में एक प्राथमिक समर्थन चैनल के रूप में बहुत मुखर हैं इसलिए लोगों को अंदर आने और सवाल पूछने के लिए प्रोत्साहित करते हैं। यह लोगों को प्रोजेक्ट के साथ बहुत तेजी से उठने और चलने में मदद करता है।
इसके अलावा, जैसा कि हम फीचर्स बना रहे हैं, दृष्टिकोणों, कोड समीक्षाओं पर नोट्स आदि के बारे में बहुत सी आगे-पीछे की चर्चा होती है। GitHub इसमें मदद करता है, हालांकि हम इसे इस अधिक मुक्त-प्रवाह वाली बातचीत के दूसरे भाग के रूप में उपयोग करते हैं जब हम एक दृष्टिकोण पर पहुंचते हैं फिर GitHub का उपयोग इश्यूज और समाधान के चरणों को दस्तावेजित करने के लिए करते हैं।
अपने अनुभव के आधार पर, क्या आपको लगता है कि ओपन सोर्स समुदाय पिछले वर्षों में बदले और विकसित हुए हैं? यदि हां, तो कैसे?
निश्चित रूप से। इसमें कुछ अच्छा और बुरा है। एक तरफ ओपन सोर्स ने कमोबेश "जीत" लिया है कि हम सॉफ्टवेयर कैसे बनाते हैं। डेवलपर्स के रूप में हम उस कोड को देखना, मान्य करना और बदलना चाहते हैं जो हम अपने प्रोजेक्ट्स में चला रहे हैं। इस तरह मुझे लगता है कि सॉफ्टवेयर विकास सभी के लिए बहुत अधिक खुला हो गया है और उम्मीद है कि यह भविष्य के डेवलपर्स को सीखने और अतीत की गलतियों को न दोहराने में मदद कर रहा है क्योंकि जानकारी की कमी के कारण।
बुरा हिस्सा यह है कि "फ्री" भाग के बहुत अधिक उपभोग हो सकते हैं फ्री और ओपन सोर्स सॉफ्टवेयर में जहां प्रोजेक्ट्स के उपभोक्ता तुरंत फिक्स होने या एक नया फीचर जोड़े जाने की उम्मीद करते हैं सिर्फ इसलिए क्योंकि उन्होंने पूछा। लोगों से जुड़ने के लिए टूल्स का उपयोग करके इस दृष्टिकोण को नरम करने में सक्षम होना अमूल्य है, क्योंकि आप अक्सर किसी को योगदान करने के लिए प्रोत्साहित कर सकते हैं और संभावित रूप से वह फीचर बना सकते हैं जिसे वे प्रोजेक्ट के हिस्से के रूप में देखना चाहते हैं।
कुल मिलाकर, मुझे लगता है कि समुदाय अब अधिक समुदाय है और मेरा मानना है कि अच्छा निश्चित रूप से नकारात्मक पहलुओं से अधिक है - लेकिन हमें हमेशा यह देखना चाहिए कि सभी प्रोजेक्ट्स को बेहतर अनुभव देने के लिए क्या किया जा सकता है।
किसी ऐसे व्यक्ति को आप क्या सलाह देंगे जो स्क्रैच से एक ऑनलाइन ओपन सोर्स समुदाय शुरू करना चाहता है?
अपने आप से बात करें।
यह अजीब लगता है लेकिन जब आप एक प्रोजेक्ट पर काम करने वाले एकमात्र व्यक्ति होते हैं तो यह डराने वाला हो सकता है। आपके पास एक विचार है, आप अपना कोड वहां डालते हैं और आप लोगों द्वारा इसकी आलोचना करने की प्रतीक्षा करते हैं। यह बहुत चुनौतीपूर्ण हो सकता है क्योंकि आप खुद को संभावित आलोचना के लिए खोल रहे हैं।
इससे पार पाने के तरीकों में से एक है अपने GitHub में इश्यूज उठाना और उन्हें खुद को असाइन करना। मैं अपने खुद के कोड की कोड समीक्षा करता हूं और इसके बारे में नोट्स बनाता हूं और कोड को ठीक करने के लिए टिकट उठाता हूं। मैं Gitter में वर्तमान स्थितियों आदि को भी अक्सर नोट करता हूं भले ही मुझे संदेह है कि कोई इसे पढ़ेगा।
हालांकि इस दृष्टिकोण के साथ मजेदार बात यह है कि यह आपको बाद में अपने प्रोजेक्ट के बारे में दूसरों से बात करने के तरीके में अधिक परिष्कृत होने में मदद करता है, और आप अपने प्रोजेक्ट के बारे में दस्तावेजीकरण, तर्क और "जीवंतता" का एक शरीर भी बनाते हैं और यह दूसरों के लिए योगदान करना आसान बनाता है - भले ही वे सोचें कि वे एक पागल व्यक्ति के साथ सहयोग कर रहे हैं जो खुद से बात करता है (जो हम वैसे भी करते हैं)।
तो मेरी सलाह है अपने आप से बात करें। यह आपके प्रोजेक्ट को स्पष्ट करने में मदद करता है, आपको पहुंच योग्य बनाता है और एक समुदाय को एक व्यक्ति से शुरू होना होता है तो वो व्यक्ति बनें जिससे यह शुरू होता है।
धन्यवाद!