OpenXLA में कोई भी योगदान दे सकता है और हम सभी के योगदान को अहमियत देते हैं. यहां योगदान देने के कई तरीके हैं. जैसे:
OpenXLA के चर्चा फ़ोरम पर सवालों के जवाब (openxla-discuss)
OpenXLA के दस्तावेज़ में सुधार करना या उसे बड़ा करना
OpenXLA के कोड बेस में योगदान देना
OpenXLA पर बनाई गई लाइब्रेरी के नेटवर्क में ऊपर बताए गए किसी भी तरीके से योगदान देना
OpenXLA प्रोजेक्ट, Google के ओपन सोर्स के कम्यूनिटी दिशा-निर्देशों का पालन करता है.
शुरू करने से पहले
योगदान देने वाले के लाइसेंस के कानूनी समझौते पर हस्ताक्षर करें
इस प्रोजेक्ट में दिए गए योगदान के साथ, योगदान देने वालों को लाइसेंस देने के लिए कानूनी समझौता (सीएलए) होना ज़रूरी है. आपके (या आपको नौकरी देने वाली कंपनी) के पास आपके योगदान का कॉपीराइट होता है. इससे हमें सिर्फ़ प्रोजेक्ट के हिस्से के तौर पर आपके योगदान का इस्तेमाल करने और उन्हें फिर से डिस्ट्रिब्यूट करने की अनुमति मिलती है.
अगर आपने या आपको नौकरी देने वाली मौजूदा कंपनी ने पहले ही Google सीएलए पर हस्ताक्षर किया है (भले ही वह किसी दूसरे प्रोजेक्ट के लिए हो), तो शायद आपको दोबारा ऐसा करने की ज़रूरत न हो.
अपने मौजूदा कानूनी समझौते देखने या नए कानूनी समझौते पर हस्ताक्षर करने के लिए, <https://cla.developers.google.com/> पर जाएं.
आचार संहिता की समीक्षा करें
यह प्रोजेक्ट TensorFlow की आचार संहिता का पालन करता है.
योगदान देने की प्रोसेस
डेवलपर गाइड
OpenXLA के लिए डेवलपमेंट एनवायरमेंट सेटअप करने के तरीके के बारे में गाइड के लिए, कृपया डेवलपर गाइड देखें. इसमें, कोड पाने, उसे बनाने, टेस्ट करने, और बदलाव सबमिट करने जैसी जानकारी शामिल है.
कोड के स्टैंडर्ड
कोडिंग की स्टाइल: हम Google की कोड स्टाइल गाइड का पालन करते हैं. खास तौर पर, C/C++ और Python गाइड देखें. सबमिट किए गए सभी कोड, इन स्टाइल गाइड के मुताबिक होने चाहिए.
छोटे बदलाव: हम Google के इंजीनियरिंग तरीकों का पालन करते हैं. खास तौर पर, कृपया छोटे बदलाव लिखने के बारे में गाइड देखें. ऐसा करने से कोड को मर्ज करने की रफ़्तार काफ़ी बढ़ जाएगी. इस वजह से, कोड की समीक्षा बेहतर तरीके से की जा सकेगी. साथ ही, बदलाव से अनजाने में होने वाले खराब असर की संभावना भी कम हो जाएगी. बड़ा बदलाव होने पर भी, इसे ज़्यादा बढ़ोतरी वाले बदलावों में बांटने के लिए कई रणनीतियां हैं.
टेस्ट कवरेज: सभी बदलावों में सही यूनिट की जांच शामिल होनी चाहिए. यूनिट की जांच, खास हार्डवेयर (सीपीयू, जीपीयू वगैरह) के टाइमिंग पर निर्भर नहीं होनी चाहिए. साथ ही, टेस्ट करने के मकसद से, मॉक या नकली का इस्तेमाल सोच-समझकर होना चाहिए. ऐसे मौजूदा कोड को बढ़ाने के लिए किए गए बदलाव जिनकी फ़िलहाल टेस्टिंग मुश्किल है. उनसे टेस्टेबिलिटी में ज़रूरी सुधार किए जाने चाहिए.
सभी बदलावों के साथ सही बेंचमार्क नतीजे के साथ-साथ बदलाव के शीर्षक में यह जानकारी शामिल होनी चाहिए, ताकि यह पक्का किया जा सके कि फ़ायदों को साफ़ तौर पर समझा जा रहा है.
जब कोड के अंदर के कन्वेंशन को लेकर संदेह हो, तो पहले से मौजूद कोड की जांच करना और OpenXLA में पहले से मौजूद पैटर्न को फ़ॉलो करना हमेशा अच्छा आइडिया होता है.
प्रोसेस की समीक्षा करें
सभी सबमिशन की समीक्षा ज़रूरी है. इनमें प्रोजेक्ट के सदस्यों के किए गए सबमिशन भी शामिल हैं. इसके लिए, हम GitHub पुल के अनुरोधों का इस्तेमाल करते हैं. पुल के अनुरोधों का इस्तेमाल करने के बारे में ज़्यादा जानकारी के लिए, GitHub सहायता पर जाएं.
समीक्षा करने से पहले, कोड को ऊपर दिए गए सभी मानकों का पालन करना होगा. ये ज़रूरी नहीं हैं. समीक्षा का अनुरोध करने से पहले, सबमिट करने वाले व्यक्ति को यह पक्का करना चाहिए कि उसका कोड सही है. इससे, बदलावों को समय पर स्वीकार किया जा सकेगा.
सभी टेस्ट पास होना ज़रूरी है. अगर आपको पता चलता है कि कोई टेस्ट ठीक से काम नहीं कर रहा है और यह समस्या आपके बिल्ड एनवायरमेंट या आपके बदलावों से जुड़ी नहीं है, तो कृपया रखरखाव करने वाले लोगों से संपर्क करें.
समीक्षा के दौरान स्कोप के कम होने से बचने की कोशिश करें. यह सबमिट करने वाले और समीक्षक, दोनों की ज़िम्मेदारी है. अगर कोई बदलाव बहुत बड़ा होना शुरू हो जाता है, तो उसे कई बदलावों में बांटकर देखें.
किसी बदलाव को मर्ज करने से पहले, उसकी अंदरूनी जांच की जाएगी. इसमें, Google और दूसरे हार्डवेयर वेंडर के लिए अंदरूनी कोड का इस्तेमाल किया जाता है. अगर इंटरनल टेस्ट की ऐसी कोई गड़बड़ी होती है जिसे हमारे सार्वजनिक सीआई को पकड़ नहीं पाता है, तो समीक्षा की प्रोसेस में ज़्यादा चरण जोड़े जा सकते हैं. जो Googler आपके बदलाव की समीक्षा कर रहा है, वह किसी भी अंदरूनी टेस्ट के फ़ेल होने पर जानकारी देगा और बताएगा कि किस समस्या को ठीक करने की ज़रूरत है.
अक्सर पूछे जाने वाले सवाल
"इंफ़्रास्ट्रक्चर में यह बदलाव मेरे पीआर से जुड़ा नहीं है. मुझे ऐसा क्यों करना चाहिए?"
XLA की टीम में एक खास इन्फ़्रास्ट्रक्चर टीम नहीं है, इसलिए यह हम सब की ज़िम्मेदारी है कि हम हेल्पर लाइब्रेरी बनाएं और तकनीकी क़र्ज़ से बचें. हम इसे एक्सएलए में बदलाव करने का एक सामान्य हिस्सा मानते हैं और उम्मीद है कि सभी लोग इसमें हिस्सा लेंगे. आम तौर पर, कोड लिखते समय हम ज़रूरत के हिसाब से इंफ़्रास्ट्रक्चर बनाते हैं.
XLA के समीक्षक, खुद आपके लिखे हुए पीआर के साथ कुछ इन्फ़्रास्ट्रक्चर बनाने (या पीआर में कोई बड़ा बदलाव करने) के लिए कह सकते हैं. आप जो बदलाव करना चाहते हैं, उसके लिए यह अनुरोध गैर-ज़रूरी या टेढ़ा-मेढ़ा लग सकता है. इसकी वजह यह हो सकती है कि आपको 4 बनाने की ज़रूरत है या नहीं. साथ ही, समीक्षा करने वाले व्यक्ति की उम्मीदें भी नहीं हैं.
उम्मीदों के मेल न खाने में कोई दिक्कत नहीं है! ऐसा तब होता है, जब आपका कोई प्रोजेक्ट नया होता है (और कभी-कभी हमारे साथ पुरानी हैट भी होती है). ऐसा हो सकता है कि जिन प्रोजेक्ट पर आपने पहले काम किया है उनकी उम्मीदें अलग हों. यह भी ठीक है और उम्मीद के मुताबिक! इसका यह मतलब नहीं है कि इनमें से किसी भी प्रोजेक्ट का तरीका गलत है; वे अलग-अलग हैं. हमारा सुझाव है कि आप समीक्षा से जुड़ी अन्य सभी टिप्पणियों के साथ-साथ, इंफ़्रास्ट्रक्चर के अनुरोध भी स्वीकार करें. इससे हमें यह जानने में मदद मिलेगी कि इस प्रोजेक्ट से हमें क्या उम्मीद है.
"क्या मैं आने वाले समय में पीआर में आपकी टिप्पणी का जवाब दे सकता/सकती हूं?"
पीआर में, इन्फ़्रास्ट्रक्चर के अनुरोधों (या दूसरे बड़े अनुरोधों) के बारे में अक्सर यह सवाल होता है कि ओरिजनल पीआर में बदलाव किया जाना चाहिए या नहीं या उसे आने वाले समय में पीआर में फ़ॉलो-अप के तौर पर किया जा सकता है या नहीं.
आम तौर पर, XLA में पीआर के लेखकों को, फ़ॉलो-अप पीआर के साथ टिप्पणियों की समीक्षा करने की अनुमति नहीं होती है. जब समीक्षक यह तय करता है कि दिए गए PR में किसी चीज़ पर ध्यान देने की ज़रूरत है, तो हम आम तौर पर लेखकों से उस PR में समाधान की उम्मीद करते हैं, चाहे जो अनुरोध किया गया है वह बहुत बड़ा बदलाव हो. यह स्टैंडर्ड, Google के बाहर और Google में अंदरूनी तौर पर भी लागू होता है.
XLA के इस तरीके को अपनाने की कुछ वजहें हो सकती हैं.
भरोसा: समीक्षकों का भरोसा हासिल करना, सबसे अहम चीज़ है. किसी ओपन सोर्स प्रोजेक्ट में, योगदान देने वाले अपनी मर्ज़ी से दिख सकते हैं या हट सकते हैं. किसी पीआर को अनुमति देने के बाद, समीक्षा करने वाले लोगों के पास यह पक्का करने का कोई तरीका नहीं होता कि वादा किए गए फ़ॉलो-अप सही हैं या नहीं.
दूसरे डेवलपर पर असर: अगर आपने XLA के किसी खास हिस्से को पीआर भेजा है, तो इस बात की संभावना है कि दूसरे लोग भी उसी हिस्से को देख रहे हों. अगर हम आपके पीआर में तकनीकी क़र्ज़ स्वीकार करते हैं, तो इस फ़ाइल को देखने वाले हर व्यक्ति पर तब तक इस क़र्ज़ का असर होगा, जब तक फ़ॉलो-अप सबमिट नहीं किया जाता.
समीक्षक बैंडविथ: फ़ॉलो-अप ड्राफ़्ट में बदलाव करने से, हमारे उन समीक्षकों पर कई शुल्क लग सकते हैं जो पहले से ज़्यादा व्यस्त हैं. समीक्षक शायद फ़ॉलो-अप का इंतज़ार करते समय यह भूल जाएंगे कि पहली पीआर के बारे में क्या बात थी. इससे अगली समीक्षा करना और भी मुश्किल हो जाता है. साथ ही, समीक्षकों को फ़ॉलो-अप की उम्मीदों पर नज़र रखनी होगी, ताकि यह पक्का किया जा सके कि वे असल में होते हैं. अगर बदलाव इस तरह से किया जा सकता है कि वह मूल पीआर से वाकई में जुड़ता हो, ताकि कुछ अन्य समीक्षक उसकी समीक्षा कर सकें, तो बैंडविथ की समस्या कम होगी. हमारे अनुभव में, ऐसा शायद ही कभी होता है.