प्रत्येक नया TensorFlow फीचर टिप्पणी के लिए अनुरोध (RFC) के रूप में शुरू होता है।
RFC एक दस्तावेज़ है जो एक आवश्यकता और उसे हल करने वाले प्रस्तावित परिवर्तनों का वर्णन करता है। विशेष रूप से, RFC करेगा:
- RFC टेम्प्लेट के अनुसार स्वरूपित किया जाए।
- समुदाय/आरएफसीएस निर्देशिका में पुल अनुरोध के रूप में सबमिट किया जाए।
- स्वीकृति से पहले चर्चा और समीक्षा बैठक का विषय बनें।
टिप्पणियाँ के लिए TensorFlow अनुरोध (RFC) का उद्देश्य हितधारकों और विशेषज्ञों से प्रतिक्रिया प्राप्त करके, और डिज़ाइन परिवर्तनों को व्यापक रूप से संप्रेषित करके TensorFlow समुदाय को विकास में शामिल करना है।
आरएफसी कैसे जमा करें
आरएफसी जमा करने से पहले, परियोजना योगदानकर्ताओं और अनुरक्षकों के साथ अपने लक्ष्यों पर चर्चा करें और शीघ्र प्रतिक्रिया प्राप्त करें। संबंधित प्रोजेक्ट के लिए डेवलपर मेलिंग सूची (developers@tensorflow.org, या प्रासंगिक SIG के लिए सूची) का उपयोग करें।
अपना आरएफसी ड्राफ्ट करें।
- डिज़ाइन समीक्षा मानदंड पढ़ें
- RFC टेम्पलेट का पालन करें.
- अपनी RFC फ़ाइल को
YYYYMMDD-descriptive-name.md
नाम दें, जहांYYYYMMDD
सबमिशन की तारीख है, औरdescriptive-name
आपके RFC के शीर्षक से संबंधित है। (उदाहरण के लिए, यदि आपके RFC का शीर्षक Parallel Widgets API है, तो आप फ़ाइल नाम20180531-parallel-widgets.md
का उपयोग कर सकते हैं। - यदि आपके पास छवियां या अन्य सहायक फ़ाइलें हैं, तो
YYYYMMDD-descriptive-name
फ़ॉर्म की एक निर्देशिका बनाएं जिसमें उन फ़ाइलों को संग्रहीत किया जाए।
आरएफसी ड्राफ्ट लिखने के बाद, इसे जमा करने से पहले अनुरक्षकों और योगदानकर्ताओं से प्रतिक्रिया प्राप्त करें।
कार्यान्वयन कोड लिखना एक आवश्यकता नहीं है, लेकिन यह चर्चाओं को डिज़ाइन करने में मदद कर सकता है।
एक प्रायोजक भर्ती करें.
- एक प्रायोजक को परियोजना का अनुरक्षक होना चाहिए।
- पीआर पोस्ट करने से पहले आरएफसी में प्रायोजक की पहचान करें।
आप प्रायोजक के बिना आरएफसी पोस्ट कर सकते हैं , लेकिन यदि पीआर पोस्ट करने के एक महीने के भीतर भी कोई प्रायोजक नहीं है, तो इसे बंद कर दिया जाएगा।
अपने RFC को Tensorflow/community/rfcs पर पुल अनुरोध के रूप में सबमिट करें।
मार्कडाउन का उपयोग करके अपने पुल अनुरोध की टिप्पणी में हेडर तालिका और उद्देश्य अनुभाग की सामग्री शामिल करें। उदाहरण के लिए, कृपया यह उदाहरण RFC देखें। सह-लेखकों, समीक्षकों और प्रायोजकों के GitHub हैंडल शामिल करें।
पीआर के शीर्ष पर पहचानें कि टिप्पणी की अवधि कितनी लंबी होगी। पीआर पोस्ट करने से कम से कम दो सप्ताह का समय होना चाहिए।
डेवलपर मेलिंग सूची को संक्षिप्त विवरण, पीआर के लिंक और समीक्षा के अनुरोध के साथ ईमेल करें। पिछली मेलिंग के प्रारूप का पालन करें, जैसा कि आप इस उदाहरण में देख सकते हैं।
प्रायोजक आरएफसी पीआर पोस्ट होने के दो सप्ताह से पहले समीक्षा समिति की बैठक का अनुरोध करेगा। यदि चर्चा जीवंत है, तो समीक्षा पर जाने से पहले इसके शांत होने तक प्रतीक्षा करें। समीक्षा बैठक का लक्ष्य छोटी-मोटी समस्याओं का समाधान करना है; प्रमुख मुद्दों पर पहले ही सहमति बना लेनी चाहिए.
बैठक आरएफसी को मंजूरी दे सकती है, इसे अस्वीकार कर सकती है, या फिर से विचार करने से पहले बदलाव की आवश्यकता हो सकती है। स्वीकृत आरएफसी को समुदाय/आरएफसी में विलय कर दिया जाएगा, और अस्वीकृत आरएफसी के पीआर बंद कर दिए जाएंगे।
आरएफसी प्रतिभागी
RFC प्रक्रिया में कई लोग शामिल हैं:
आरएफसी लेखक - एक या अधिक समुदाय सदस्य जो आरएफसी लिखते हैं और प्रक्रिया के माध्यम से इसका समर्थन करने के लिए प्रतिबद्ध हैं
आरएफसी प्रायोजक - एक अनुरक्षक जो आरएफसी को प्रायोजित करता है और आरएफसी समीक्षा प्रक्रिया के माध्यम से इसका प्रबंधन करेगा
समीक्षा समिति - अनुरक्षकों का एक समूह जिनके पास आरएफसी को अपनाने की सिफारिश करने की जिम्मेदारी है
समुदाय का कोई भी सदस्य इस पर फीडबैक देकर मदद कर सकता है कि आरएफसी उनकी जरूरतों को पूरा करेगा या नहीं।
आरएफसी प्रायोजक
प्रायोजक एक परियोजना अनुरक्षक होता है जो आरएफसी प्रक्रिया के सर्वोत्तम संभव परिणाम सुनिश्चित करने के लिए जिम्मेदार होता है। यह भी शामिल है:
- प्रस्तावित डिज़ाइन की वकालत करना।
- मौजूदा डिज़ाइन और शैली परंपराओं का पालन करने के लिए आरएफसी का मार्गदर्शन करना।
- उत्पादक सर्वसम्मति पर पहुंचने के लिए समीक्षा समिति का मार्गदर्शन करना।
- यदि समीक्षा समिति द्वारा परिवर्तनों का अनुरोध किया जाता है, तो सुनिश्चित करें कि ये किए गए हैं और समिति के सदस्यों से बाद में अनुमोदन प्राप्त करें।
- यदि आरएफसी कार्यान्वयन की ओर बढ़ता है:
- यह सुनिश्चित करना कि प्रस्तावित कार्यान्वयन डिज़ाइन का पालन करता है।
- कार्यान्वयन को सफलतापूर्वक जमीन पर उतारने के लिए उपयुक्त पक्षों के साथ समन्वय करें।
आरएफसी समीक्षा समितियाँ
समीक्षा समिति आम सहमति के आधार पर निर्णय लेती है कि परिवर्तनों को स्वीकृत करना है, अस्वीकार करना है या अनुरोध करना है। वे इसके लिए जिम्मेदार हैं:
- यह सुनिश्चित करना कि जनता की प्रतिक्रिया की महत्वपूर्ण बातों का ध्यान रखा गया है।
- उनके मीटिंग नोट्स को पीआर में टिप्पणियों के रूप में जोड़ना।
- उनके निर्णयों के लिए कारण प्रदान करना।
समीक्षा समिति का गठन प्रत्येक परियोजना की विशिष्ट शासन शैली और नेतृत्व के अनुसार बदल सकता है। कोर टेन्सरफ्लो के लिए, समिति में टेन्सरफ्लो परियोजना के योगदानकर्ता शामिल होंगे जिनके पास संबंधित डोमेन क्षेत्र में विशेषज्ञता है।
समुदाय के सदस्य और आरएफसी प्रक्रिया
RFC का उद्देश्य यह सुनिश्चित करना है कि TensorFlow में नए परिवर्तनों के माध्यम से समुदाय का अच्छी तरह से प्रतिनिधित्व और सेवा हो। यह समुदाय के सदस्यों की ज़िम्मेदारी है कि वे आरएफसी की समीक्षा में भाग लें जहां परिणाम में उनकी रुचि हो।
समुदाय के सदस्य जो आरएफसी में रुचि रखते हैं, उन्हें यह करना चाहिए:
- विचार के लिए पर्याप्त समय देने के लिए यथाशीघ्र प्रतिक्रिया प्रदान करें ।
- फीडबैक देने से पहले आरएफसी को अच्छी तरह से पढ़ें ।
- सभ्य और रचनात्मक बनें.
नई सुविधाएँ लागू करना
एक बार RFC स्वीकृत हो जाने के बाद, कार्यान्वयन शुरू हो सकता है।
यदि आप RFC लागू करने के लिए नए कोड पर काम कर रहे हैं:
- सुनिश्चित करें कि आप आरएफसी में अनुमोदित सुविधा और डिज़ाइन को समझते हैं। काम शुरू करने से पहले प्रश्न पूछें और दृष्टिकोण पर चर्चा करें।
- नई सुविधाओं में नए यूनिट परीक्षण शामिल होने चाहिए जो यह सत्यापित करें कि सुविधा अपेक्षा के अनुरूप काम करती है। कोड लिखने से पहले इन परीक्षणों को लिखना एक अच्छा विचार है।
- TensorFlow कोड स्टाइल गाइड का पालन करें
- प्रासंगिक एपीआई दस्तावेज़ जोड़ें या अपडेट करें। नए दस्तावेज़ में RFC का संदर्भ लें।
- आप जिस प्रोजेक्ट रेपो में योगदान दे रहे हैं, उसमें
CONTRIBUTING.md
फ़ाइल में दिए गए किसी भी अन्य दिशानिर्देश का पालन करें। - अपना कोड सबमिट करने से पहले यूनिट परीक्षण चलाएँ।
- नए कोड को सफलतापूर्वक लागू करने के लिए RFC प्रायोजक के साथ काम करें।
बार को ऊँचा रखना
जबकि हम प्रत्येक योगदानकर्ता को प्रोत्साहित करते हैं और उसका जश्न मनाते हैं, आरएफसी स्वीकृति का स्तर जानबूझकर ऊंचा रखा जाता है। किसी नई सुविधा को इनमें से किसी भी चरण में अस्वीकार किया जा सकता है या महत्वपूर्ण संशोधन की आवश्यकता हो सकती है:
- प्रासंगिक मेलिंग सूची पर प्रारंभिक डिज़ाइन वार्तालाप।
- प्रायोजक की भर्ती करने में विफलता.
- फीडबैक चरण के दौरान गंभीर आपत्तियाँ।
- डिज़ाइन समीक्षा के दौरान सर्वसम्मति प्राप्त करने में विफलता।
- कार्यान्वयन के दौरान उठाई गई चिंताएँ (उदाहरण के लिए: पश्चगामी अनुकूलता प्राप्त करने में असमर्थता, रखरखाव के बारे में चिंताएँ)।
यदि यह प्रक्रिया अच्छी तरह से काम कर रही है, तो आरएफसी के बाद के चरणों के बजाय पहले चरण में विफल होने की उम्मीद है। एक अनुमोदित आरएफसी कार्यान्वयन की प्रतिबद्धता की कोई गारंटी नहीं है, और प्रस्तावित आरएफसी कार्यान्वयन की स्वीकृति अभी भी सामान्य कोड समीक्षा प्रक्रिया के अधीन है।
यदि इस प्रक्रिया के बारे में आपके कोई प्रश्न हैं, तो बेझिझक डेवलपर्स मेलिंग सूची पर पूछें या टेंसरफ़्लो/समुदाय में समस्या दर्ज करें।