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