अगर आपको उपयोगकर्ता के लिए उपलब्ध किसी सुविधा को जोड़ना, बदलना या हटाना है या अनोखे आर्किटेक्चर के लिए, आपको डिज़ाइन ज़रूर करना होगा दस्तावेज़ सबमिट करें और बदलाव सबमिट करने से पहले उसकी समीक्षा करवाएं.
यहां बड़े बदलावों के कुछ उदाहरण दिए गए हैं:
- नेटिव बिल्ड नियमों को जोड़ना या मिटाना
- नेटिव नियमों में हुए बदलाव
- नेटिव बिल्ड नियम के सिमेंटिक्स में बदलाव, जो ज़्यादा कन्वर्ज़न पाने के व्यवहार पर असर डालते हैं एक नियम की तुलना में
- Baज़ल के नियम से जुड़ी परिभाषा वाले एपीआई में बदलाव
- उन एपीआई में बदलाव जिनका इस्तेमाल Basel ने दूसरे सिस्टम से कनेक्ट करने के लिए किया
- Starlark की भाषा, सिमेंटिक्स या एपीआई में बदलाव
- ऐसे बदलाव जिनसे बैज की परफ़ॉर्मेंस या मेमोरी पर काफ़ी असर पड़ सकता है इस्तेमाल (बेहतर या खराब के लिए)
- बड़े पैमाने पर इस्तेमाल किए जाने वाले इंटरनल एपीआई में बदलाव
- फ़्लैग और कमांड-लाइन इंटरफ़ेस में किए गए बदलाव.
डिज़ाइन की समीक्षा करने की वजहें
डिज़ाइन से जुड़ा दस्तावेज़ लिखते समय, अन्य Basel डेवलपर के साथ मिलकर काम किया जा सकता है और बेज़ल की मुख्य टीम से सलाह लें. उदाहरण के लिए, जब कोई प्रस्ताव जोड़ता है, BUILD, वर्कस्पेस, या bzl फ़ाइलों में, Starlark टीम को समीक्षकों के तौर पर जोड़ें. सबमिट करने से पहले डिज़ाइन से जुड़े दस्तावेज़ों की समीक्षा की जाती है, क्योंकि:
- बेज़ल एक बहुत ही जटिल सिस्टम है; स्थानीय बदलावों की वजह से वैश्विक स्तर पर गंभीर परिणाम हो सकते हैं.
- टीम को उपयोगकर्ताओं से कई सुविधा के अनुरोध मिलते हैं; इस तरह के अनुरोधों को न केवल तकनीकी संभावना के आधार पर, बल्कि सुविधा के अन्य अनुरोध शामिल हैं.
- Basel की सुविधाओं को अक्सर, मुख्य टीम से बाहर के लोग इस्तेमाल करते हैं; ऐसे लोगों के पास बेज़ेल विशेषज्ञता के स्तर में काफ़ी अंतर है.
- बेज़ल टीम के पास विशेषज्ञता के अलग-अलग लेवल हैं; टीम का कोई एक सदस्य नहीं है बेज़ल के हर कोने की पूरी जानकारी है.
- Basel में किए गए बदलावों को पुराने सिस्टम के साथ काम करने के लिए ज़रूरी है. साथ ही, इसे इस्तेमाल किए जाने से रोका जाना चाहिए बदलाव.
बेज़ेल की डिज़ाइन की समीक्षा से जुड़ी नीति की मदद से, इस बात की संभावना बढ़ जाती है कि:
- सुविधा के सभी अनुरोधों को बुनियादी स्तर की जांच मिलती है.
- कारोबार में निवेश करने से पहले, सही लोगों के डिज़ाइन पर ध्यान दिया जाएगा जो शायद काम न करे.
शुरू करने में आपकी मदद करने के लिए, बेज़ल प्रपोज़ल रिपॉज़िटरी. डिज़ाइन पर काम चल रहा है. इसलिए, इन्हें लागू करने की जानकारी में समय के साथ बदलाव हो सकता है साथ ही, सुझाव देना भी ज़रूरी है. डिज़ाइन से जुड़े पब्लिश किए गए दस्तावेज़ों में शुरुआती डिज़ाइन, और डिज़ाइन लागू होने के बाद होने वाले बदलावों नहीं. हमेशा Basel के मौजूदा फ़ंक्शन की जानकारी देने वाले दस्तावेज़.
योगदान देने वाले का वर्कफ़्लो
योगदान देने वाले के तौर पर, आपके पास डिज़ाइन से जुड़ा दस्तावेज़ लिखने, पुल के अनुरोध भेजने, और अपने प्रस्ताव के लिए समीक्षकों से अनुरोध करें.
डिज़ाइन से जुड़ा दस्तावेज़ लिखें
डिज़ाइन से जुड़े सभी दस्तावेज़ों में एक हेडर होना चाहिए. इसमें ये चीज़ें शामिल होनी चाहिए:
- लेखक
- पिछले बड़े बदलाव की तारीख
- समीक्षा करने वालों की सूची. इसमें सिर्फ़ एक समीक्षक शामिल होता है लीड समीक्षक
- मौजूदा स्थिति (ड्राफ़्ट, समीक्षा में है, स्वीकार किया गया, अस्वीकार किया गया, लागू किया जा रहा है, लागू किया गया)
- चर्चा के थ्रेड का लिंक (घोषणा के बाद जोड़ा जाएगा)
दस्तावेज़ को या तो दुनिया भर में पढ़ने लायक Google दस्तावेज़ के तौर पर लिखा जा सकता है या markडाउन की मदद से. इस बारे में नीचे पढ़ें कि मार्कडाउन / Google Docs की तुलना.
जिन प्रस्तावों का असर उपयोगकर्ताओं को दिखता है उनमें एक ऐसा सेक्शन शामिल होना चाहिए जिसमें इसका असर, पुराने सिस्टम के साथ काम करने की सुविधा (और अगर ज़रूरी हो, तो रोल आउट प्लान) पर पड़ेगा.
पुल का अनुरोध करें
अपने डिज़ाइन दस्तावेज़ को शेयर करने के लिए, पुल का अनुरोध (पीआर) बनाएं और उसमें दस्तावेज़ जोड़ें डिज़ाइन इंडेक्स में दिया गया है. जोड़ें आपके PR के दस्तावेज़ का लिंक भी हो.
जब भी हो सके, लीड समीक्षक चुनें. साथ ही, अन्य समीक्षकों की कॉपी भी शामिल करें. अगर आपने लीड की समीक्षा करने वाले व्यक्ति को नहीं चुना है, तो मेंटेनर आपके पीआर को एक असाइन करेगा.
पीआर बनाने के बाद, समीक्षक आपके वीडियो के दौरान शुरुआती टिप्पणियां कर सकते हैं कोड समीक्षा. उदाहरण के लिए, लीड समीक्षक अतिरिक्त समीक्षकों का सुझाव दे सकता है या छूटी हुई जानकारी दिखाएं. लीड समीक्षक पीआर को तब मंज़ूरी देता है, जब वे तो माना कि समीक्षा की प्रोसेस शुरू हो सकती है. इसका मतलब यह नहीं है कि प्रस्ताव सही है या उन्हें मंज़ूरी मिल जाएगी; इसका यह मतलब है कि प्रस्ताव में ऐसी जानकारी है जिससे चर्चा शुरू करें.
नए प्रस्ताव की घोषणा करें
इन्हें सूचना भेजें bazel-dev, जब पीआर सबमिट कर दिया जाता है.
आपके पास अन्य ग्रुप को कॉपी करने का विकल्प होता है (उदाहरण के लिए, basel-discuss, ताकि आपको प्लैटफ़ॉर्म के असली उपयोगकर्ताओं से सुझाव, राय या शिकायतें मिल सकें.
समीक्षकों के साथ दोहराएं
इसमें दिलचस्पी रखने वाला कोई भी व्यक्ति आपके प्रस्ताव पर टिप्पणी कर सकता है. सवालों के जवाब देने की कोशिश करें, प्रस्ताव को साफ़ तौर पर बताएं और समस्याओं पर ध्यान दें.
बातचीत, सूचना वाले थ्रेड पर होनी चाहिए. अगर प्रस्ताव Google Doc, तो इसके बजाय टिप्पणियों का इस्तेमाल किया जा सकता है (ध्यान दें कि पहचान छिपाकर की गई टिप्पणियां अनुमति है).
स्टेटस अपडेट करना
बार-बार किए जाने वाले प्रस्ताव की स्थिति अपडेट करने के लिए एक नया पीआर बनाएं पूरा हुआ. पीआर को उसी लीड समीक्षक को भेजें और दूसरे समीक्षकों को कॉपी भेजें.
प्रस्ताव को आधिकारिक रूप से स्वीकार करने के लिए, मुख्य समीक्षक यह पक्का करना कि अन्य समीक्षक फ़ैसले से सहमत हैं.
पहली घोषणा और मंज़ूरी के बीच कम से कम 1 सप्ताह का समय होना चाहिए एक प्रस्ताव. इससे यह पक्का होता है कि उपयोगकर्ताओं को दस्तावेज़ को पढ़ने के लिए ज़रूरी समय मिले और अपनी समस्याएं शेयर करें.
प्रस्ताव स्वीकार किए जाने से पहले लागू किया जा सकता है, उदाहरण के लिए: किसी कानूनी समझौते का सबूत है. हालांकि, आपके पास बदलाव सबमिट करने का विकल्प नहीं होगा में तय करें.
लीड समीक्षक चुनना
लीड समीक्षक एक ऐसा डोमेन विशेषज्ञ होना चाहिए जो:
- ऐसे सबसिस्टम की जानकारी है जिन्हें इस काम के सबसिस्टम के बारे में जानकारी है
- इसका मकसद, रचनात्मक सुझाव या राय देना या शिकायत करना
- समीक्षा की प्रोसेस पूरी करने के लिए, यह सुविधा पूरी समीक्षा अवधि के लिए उपलब्ध रहती है
अलग-अलग टीम के संपर्कों की जांच करें लेबल हैं.
Markdown बनाम Google Docs
तय करें कि आपके लिए सबसे अच्छा क्या रहेगा, क्योंकि दोनों को स्वीकार कर लिया गया है.
Google Docs इस्तेमाल करने के फ़ायदे:
- सोच-विचार करने के लिए असरदार, क्योंकि शुरुआत करना आसान है.
- साथ मिलकर बदलाव करना.
- तुरंत दोहराएं.
- बदलाव सुझाने का आसान तरीका.
Markdown फ़ाइलों को इस्तेमाल करने के फ़ायदे:
- लिंक करने के लिए साफ़ यूआरएल.
- बदलावों का साफ़ तौर पर रिकॉर्ड किया गया रिकॉर्ड.
- किसी लिंक का प्रमोशन करने से पहले, ऐक्सेस के अधिकार सेट अप करना न भूलें.
- इसे सर्च इंजन की मदद से आसानी से खोजा जा सकता है.
- आने वाले समय के हिसाब से: सामान्य टेक्स्ट पर किसी खास टूल का असर नहीं पड़ता और इसके लिए इंटरनेट कनेक्शन की ज़रूरत नहीं होती.
- इन्हें अपडेट किया जा सकता है, भले ही लेखक अब आस-पास न हो.
- उन्हें अपने-आप प्रोसेस किया जा सकता है (इस्तेमाल न होने वाले लिंक अपडेट करें/उनका पता लगाएं, फ़ेच करें लेखकों की सूची वगैरह).
आप पहले किसी Google दस्तावेज़ पर दोहराने और फिर उसे आने वाले दिनों के लिए मार्कडाउन.
Google Docs का इस्तेमाल करना
एक जैसा अनुभव पाने के लिए, Baज़ल डिज़ाइन दस्तावेज़ का टेंप्लेट इस्तेमाल करें. इसमें ज़रूरी हेडर शामिल होता है और यह विज़ुअल का इस्तेमाल कम या ज़्यादा किया जा सकता है. ऐसा करने के लिए, फ़ाइल > कॉपी बनाएं या डिज़ाइन दस्तावेज़ की कॉपी बनाने के लिए, इस लिंक पर क्लिक करें टेंप्लेट के बारे में ज़्यादा जानें.
अपने दस्तावेज़ को दुनिया भर में पढ़ने लायक बनाने के लिए, शेयर करें > बेहतर > बदलें... और "चालू करें - वे सभी लोग जिनके पास लिंक है" चुनें. अगर आपने दस्तावेज़ पर टिप्पणी करने की अनुमति दी है, कोई भी व्यक्ति पहचान छिपाकर टिप्पणी कर सकता है. वह भी Google खाते के बिना भी.
Markdown का इस्तेमाल करना
दस्तावेज़ GitHub पर सेव किए जाते हैं और मार्कडाउन का GitHub फ़्लेवर (खास जानकारी).
मौजूदा दस्तावेज़ को अपडेट करने के लिए पीआर बनाएं. ज़रूरी बदलाव की समीक्षा करते हैं. मामूली बदलाव (जैसे कि टाइपिंग की गलतियां, फ़ॉर्मैटिंग) किसी भी व्यक्ति से अनुमति मिल सकती है.
समीक्षक का वर्कफ़्लो
एक समीक्षक डिज़ाइन से जुड़े दस्तावेज़ों पर टिप्पणियां करता है, उनकी समीक्षा करता है, और उन्हें मंज़ूरी देता है.
समीक्षक की सामान्य ज़िम्मेदारियां
डिज़ाइन से जुड़े दस्तावेज़ों की समीक्षा करने की ज़िम्मेदारी आपकी है. साथ ही, आपसे अतिरिक्त जानकारी मांगी जा रही है जानकारी दें. साथ ही, ऐसे डिज़ाइन को मंज़ूरी दें जो समीक्षा की प्रोसेस में पास हो.
आपको नया प्रस्ताव मिलने पर
- दस्तावेज़ पर एक नज़र डालें.
- अगर अहम जानकारी मौजूद न हो या डिज़ाइन फ़िट न हो, तो टिप्पणी करें प्रोजेक्ट के लक्ष्यों के साथ.
- अतिरिक्त समीक्षकों का सुझाव दें.
- समीक्षा के लिए तैयार होने पर पीआर को मंज़ूरी दें.
समीक्षा की प्रोसेस के दौरान
- डिज़ाइन के लेखक से उन समस्याओं के बारे में बातचीत करें जिनसे समस्याएं पैदा होती हैं या व्याख्या की ज़रूरत है.
- अगर ठीक लगे, तो समीक्षा न करने वाले उन लोगों की टिप्पणियों को न्योता दें जिन्हें इनके बारे में जानकारी होनी चाहिए डिज़ाइन.
- यह तय करना ज़रूरी है कि लेखक को किन टिप्पणियों पर जवाब देने की ज़रूरत है की अनुमति है.
- "LGTM" लिखें (मुझे अच्छा लगता है) प्रस्ताव की मौजूदा स्थिति से खुश है.
डिज़ाइन की समीक्षा से जुड़े सभी अनुरोधों के लिए, यह प्रोसेस अपनाएं. डिज़ाइन स्वीकार न करें बेज़ल को प्रभावित कर रहा है, अगर वह डिज़ाइन इंडेक्स में दिया गया है.
मुख्य समीक्षक की ज़िम्मेदारियां
लागू करने से जुड़ा कोई भी फ़ैसला लेने की ज़िम्मेदारी आपकी है एक लंबित डिज़ाइन के. अगर आप ऐसा नहीं कर पा रहे हैं, तो आपको (प्रतिनिधि को पीआर को फिर से असाइन करना) या बग आगे के खर्च के लिए बेज़ल मैनेजर.
समीक्षा की प्रोसेस के दौरान
- पक्का करें कि टिप्पणी करने और डिज़ाइन करने की प्रोसेस आगे भी जारी रहे मदद मिलती है.
- अनुमति देने से पहले, पक्का करें कि दूसरे समीक्षकों की समस्याएं समाधान किया गया.
सभी समीक्षकों की अनुमति के बाद
- पक्का करें कि YouTube TV की सदस्यता का एलान किए जाने के बाद, कम से कम एक हफ़्ता बीत चुका हो ईमेल पाने वाले लोगों की सूची.
- पक्का करें कि पीआर से स्टेटस अपडेट हो जाए.
- प्रस्ताव के लेखक की ओर से भेजी गई पीआर को मंज़ूरी दें.
डिज़ाइन अस्वीकार किए जा रहे हैं
- पक्का करें कि पीआर के लेखक ने पीआर भेजें; या पीआर खत्म करने की कोशिश करते हैं.
- पीआर से दस्तावेज़ की स्थिति को अपडेट किया जाता है.
- दस्तावेज़ में एक टिप्पणी जोड़ें और बताएं कि डिज़ाइन को मंज़ूरी क्यों नहीं दी जा सकती उसकी मौजूदा स्थिति और अगर कोई हो, तो अगले चरणों के बारे में जानकारी देना. जैसे, "अमान्य पेज को फिर से विज़िट करें" और फिर से सबमिट करें").