अवलोकन
यह दस्तावेज़ बताता है कि I2P विनिर्देशों में कैसे बदलाव किया जाए, I2P प्रस्ताव कैसे काम करते हैं, और I2P प्रस्तावों और विनिर्देशों के बीच संबंध क्या है।
यह दस्तावेज़ Tor प्रस्ताव प्रक्रिया से अनुकूलित किया गया है, और नीचे दिए गए अधिकांश सामग्री मूल रूप से Nick Mathewson द्वारा लिखी गई थी।
यह एक सूचनात्मक दस्तावेज़ है।
प्रेरणा
पहले, हमारी I2P विनिर्देशों को अद्यतन करने की प्रक्रिया अपेक्षाकृत अनौपचारिक थी: हम विकास मंच पर एक प्रस्ताव बनाते थे और चर्चा करते थे, फिर हम सहमति तक पहुंचते थे और विनिर्देश को मसौदा परिवर्तनों (आवश्यक रूप से उस क्रम में) के साथ अद्यतन करते थे, और अंत में हम परिवर्तनों को लागू करते थे।
इसमें कुछ समस्याएं थीं।
पहला, यहां तक कि अपने सबसे कुशल रूप में, पुरानी प्रक्रिया अक्सर विनिर्देश को कोड के साथ असिंक्रोनस बना देती थी। सबसे खराब मामले वे थे जहां कार्यान्वयन स्थगित कर दिया गया था: विनिर्देश और कोड एक से अधिक संस्करणों के लिए असिंक्रोनस रह सकते थे।
दूसरा, चर्चा में भाग लेना मुश्किल था, क्योंकि यह हमेशा स्पष्ट नहीं था कि चर्चा धागे के कौन से हिस्से प्रस्ताव का हिस्सा थे, या विनिर्देश में कौन से परिवर्तन लागू किए गए थे। विकास मंच केवल I2P के अंदर ही पहुंच योग्य हैं, जिसका अर्थ है कि प्रस्ताव केवल उन लोगों द्वारा देखे जा सकते थे जो I2P का उपयोग करते हैं।
तीसरा, यह बहुत आसान था कि कुछ प्रस्तावों को भूल जाएं क्योंकि वे मंच धागे सूची में कई पृष्ठों पीछे दब जाते थे।
विनिर्देशों को कैसे बदलना है अब
पहले, कोई एक प्रस्ताव दस्तावेज़ लिखता है। इसमें विस्तार से बताना चाहिए कि क्या बदलाव किया जाना चाहिए, और कुछ विचार देना चाहिए कि इसे कैसे लागू किया जाए। एक बार यह पर्याप्त रूप से विकसित हो जाए, तो यह एक प्रस्ताव बन जाता है।
एक आरएफसी की तरह, प्रत्येक प्रस्ताव को एक संख्या मिलती है। आरएफसी के विपरीत, प्रस्ताव समय के साथ बदल सकते हैं और एक ही संख्या रख सकते हैं, जब तक वे अंततः स्वीकृत या अस्वीकृत नहीं हो जाते। प्रत्येक प्रस्ताव के लिए इतिहास I2P वेबसाइट रिपॉजिटरी में संग्रहीत किया जाएगा।
एक बार प्रस्ताव रिपॉजिटरी में हो जाने के बाद, हमें इसे संबंधित धागे पर चर्चा करनी चाहिए और इसे तब तक बेहतर बनाना चाहिए जब तक हमें यह सहमति न हो जाए कि यह एक अच्छा विचार है, और यह विस्तार से पर्याप्त है कि इसे लागू किया जा सके। जब यह होता है, तो हम प्रस्ताव को लागू करते हैं और इसे विनिर्देशों में शामिल करते हैं। इस प्रकार, विनिर्देश I2P प्रोटोकॉल के लिए निर्धारित दस्तावेज़ बने रहते हैं: कोई प्रस्ताव कभी भी लागू की गई सुविधा के लिए निर्धारित दस्तावेज़ नहीं होता है।
(यह प्रक्रिया पाइथन एन्हांसमेंट प्रोसेस के समान है, लेकिन एक बड़ा अंतर यह है कि I2P प्रस्ताव लागू करने के बाद विनिर्देशों में पुनः एकीकृत हो जाते हैं, जबकि PEP नए विनिर्देश बन जाते हैं।)
छोटे परिवर्तन
यह अभी भी ठीक है कि यदि कोड तुरंत लिखा जा सकता है या कोई कोड परिवर्तन की आवश्यकता नहीं है तो विनिर्देश में सीधे छोटे परिवर्तन किए जाएं। यह दस्तावेज़ वर्तमान विकासकर्ताओं के उद्देश्य को दर्शाता है, न कि भविष्य में इस प्रक्रिया का हमेशा उपयोग करने का एक स्थायी वादा: हमें यह अधिकार है कि हम वास्तव में उत्साहित हो जाएं और एक कैफीन-या एमएंडएम-ईंधन वाली सभी रात्रि हैकिंग सत्र में कुछ लागू करें।
नए प्रस्ताव कैसे जोड़े जाते हैं
एक प्रस्ताव जमा करने के लिए, इसे विकास मंच पर पोस्ट करें या एक टिकट दर्ज करें जिसमें प्रस्ताव संलग्न हो।
एक बार एक विचार प्रस्तावित हो जाने के बाद, एक उचित रूप से स्वरूपित (नीचे देखें) मसौदा अस्तित्व में है, और सक्रिय विकास समुदाय के भीतर एक खुरदरा सहमति है कि यह विचार विचार के योग्य है, प्रस्ताव संपादक आधिकारिक तौर पर प्रस्ताव जोड़ेंगे।
वर्तमान प्रस्ताव संपादक zzz और str4d हैं।
प्रस्ताव में क्या जाना चाहिए
प्रत्येक प्रस्ताव में एक हेडर होना चाहिए जिसमें निम्नलिखित क्षेत्र हों:
:author:
:created:
:thread:
:lastupdated:
:status:
authorक्षेत्र में इस प्रस्ताव के लेखकों के नाम होने चाहिए।threadक्षेत्र में विकास मंच धागे का लिंक होना चाहिए जहां यह प्रस्ताव मूल रूप से पोस्ट किया गया था, या इस प्रस्ताव की चर्चा के लिए एक नया धागा बनाया गया था।lastupdatedक्षेत्र को最初createdक्षेत्र के समान होना चाहिए, और इसे तब अद्यतन किया जाना चाहिए जब प्रस्ताव में कोई परिवर्तन किया जाता है।
निम्नलिखित क्षेत्रों को आवश्यकतानुसार सेट किया जाना चाहिए:
:supercedes:
:supercededby:
:editor:
supercedesक्षेत्र में उन सभी प्रस्तावों की एक अल्पविराम से अलग सूची होनी चाहिए जिन्हें यह प्रस्ताव प्रतिस्थापित करता है। उन प्रस्तावों को अस्वीकृत किया जाना चाहिए और उनकेsupercededbyक्षेत्र को इस प्रस्ताव की संख्या में सेट किया जाना चाहिए।editorक्षेत्र को तब सेट किया जाना चाहिए जब इस प्रस्ताव में महत्वपूर्ण परिवर्तन किए जाते हैं जो इसकी सामग्री को मूल रूप से नहीं बदलते हैं। यदि सामग्री को मूल रूप से बदला जा रहा है, तो एक अतिरिक्तauthorजोड़ा जाना चाहिए, या इसे प्रतिस्थापित करने वाला एक नया प्रस्ताव बनाया जाना चाहिए।
निम्नलिखित क्षेत्र वैकल्पिक हैं लेकिन अनुशंसित हैं:
:target:
:implementedin:
targetक्षेत्र में यह बताना चाहिए कि प्रस्ताव को किस संस्करण में लागू किया जाना है (यदि यह खुला या स्वीकृत है)।implementedinक्षेत्र में यह बताना चाहिए कि प्रस्ताव को किस संस्करण में लागू किया गया था (यदि यह समाप्त या बंद है)।
प्रस्ताव के शरीर को एक अवलोकन अनुभाग से शुरू करना चाहिए जो बताता है कि प्रस्ताव किस बारे में है, यह क्या करता है, और इसकी वर्तमान स्थिति क्या है।
अवलोकन के बाद, प्रस्ताव अधिक मुक्त रूप से बन जाता है। इसकी लंबाई और जटिलता के आधार पर, प्रस्ताव को अनुभागों में विभाजित किया जा सकता है या एक छोटी सी चर्चा प्रारूप का पालन किया जा सकता है। प्रत्येक प्रस्ताव में निम्नलिखित जानकारी होनी चाहिए, हालांकि यह जानकारी इन नामों के साथ अनुभागों में नहीं होनी चाहिए:
- प्रेरणा
- प्रस्ताव किस समस्या का समाधान करने की कोशिश कर रहा है? यह समस्या क्यों महत्वपूर्ण है? यदि कई दृष्टिकोण संभव हैं, तो इस दृष्टिकोण को क्यों अपनाया जाए?
- डिज़ाइन
- नए या संशोधित सुविधाओं का एक उच्च-स्तरीय दृश्य, वे कैसे काम करते हैं, वे एक दूसरे के साथ कैसे सहयोग करते हैं, और वे I2P के शेष भाग के साथ कैसे बातचीत करते हैं। यह प्रस्ताव का मुख्य भाग है। कुछ प्रस्ताव केवल प्रेरणा और डिज़ाइन के साथ शुरू हो सकते हैं और विनिर्देश तक प्रतीक्षा कर सकते हैं जब तक कि डिज़ाइन लगभग सही न हो जाए।
- सुरक्षा प्रभाव
- प्रस्तावित परिवर्तनों के गुमनामी पर क्या प्रभाव पड़ सकते हैं, इन प्रभावों को कितनी अच्छी तरह से समझा जाता है, और इसी तरह।
- विनिर्देश
- प्रस्ताव को लागू करने के लिए I2P विनिर्देशों में क्या जोड़ा जाना चाहिए, इसका एक विस्तृत विवरण। यह विनिर्देशों में अंततः शामिल की जाने वाली विस्तार से होना चाहिए: यह संभव होना चाहिए कि स्वतंत्र प्रोग्रामर प्रस्ताव के विनिर्देशों के आधार पर संगत कार्यान्वयन लिखें।
- संगतता
- क्या I2P के संस्करण जो प्रस्ताव का पालन करते हैं उन संस्करणों के साथ संगत होंगे जो नहीं करते हैं? यदि हां, तो संगतता कैसे प्राप्त की जाएगी? आमतौर पर, हम संगतता को तोड़ने से बचने की कोशिश करते हैं; हमने मार्च 2008 से एक “फ्लैग दिवस” परिवर्तन नहीं किया है, और हम ऐसा फिर से नहीं करना चाहते हैं।
- कार्यान्वयन
- यदि प्रस्ताव I2P की वर्तमान वास्तुकला में कार्यान्वित करना मुश्किल होगा, तो दस्तावेज़ में इसके कार्यान्वयन के बारे में कुछ चर्चा हो सकती है। वास्तविक पैच सार्वजनिक मोनोटोन शाखाओं पर होने चाहिए, या ट्रैक पर अपलोड किए जाने चाहिए।
- प्रदर्शन और स्केलेबिलिटी नोट्स
- यदि सुविधा प्रदर्शन (रैम, सीपीयू, बैंडविड्थ) या स्केलेबिलिटी पर प्रभाव डालेगी, तो इसका कुछ विश्लेषण होना चाहिए कि यह प्रभाव कितना महत्वपूर्ण होगा, ताकि हम वास्तव में महंगे प्रदर्शन प्रतिगमन से बच सकें, और हम महत्वहीन लाभ पर समय बर्बाद न करें।
- संदर्भ
- यदि प्रस्ताव बाहरी दस्तावेजों को संदर्भित करता है, तो उन्हें सूचीबद्ध किया जाना चाहिए।
प्रस्ताव स्थिति
- खुला
- चर्चा के तहत एक प्रस्ताव।
- स्वीकृत
- प्रस्ताव पूरा हो गया है, और हम इसका कार्यान्वयन करने का इरादा रखते हैं। इस बिंदु के बाद, प्रस्ताव में मूलभूत परिवर्तन से बचा जाना चाहिए, और इसे प्रक्रिया में कहीं न कहीं विफलता के संकेत के रूप में माना जाना चाहिए।
- समाप्त
- प्रस्ताव स्वीकृत और कार्यान्वित किया गया है। इस बिंदु के बाद, प्रस्ताव को नहीं बदलना चाहिए।
- बंद
- प्रस्ताव स्वीकृत, कार्यान्वित और मुख्य विनिर्देश दस्तावेजों में विलय कर दिया गया है। प्रस्ताव को इस बिंदु के बाद नहीं बदलना चाहिए।
- अस्वीकृत
- हम इस प्रस्ताव के अनुसार सुविधा को लागू नहीं करेंगे, हालांकि हम इसके कुछ अन्य संस्करण को कर सकते हैं। विवरण के लिए दस्तावेज़ में टिप्पणियां देखें। प्रस्ताव को इस बिंदु के बाद नहीं बदलना चाहिए; किसी अन्य संस्करण को लाने के लिए, एक नया प्रस्ताव लिखें।
- मसौदा
- यह अभी तक एक पूर्ण प्रस्ताव नहीं है; इसमें अभी भी कुछ缺के हैं। कृपया इस स्थिति के साथ कोई नया प्रस्ताव न जोड़ें; इसके बजाय इसे “विचार” उप-निर्देशिका में रखें।
- संशोधन की आवश्यकता
- प्रस्ताव का विचार एक अच्छा है, लेकिन प्रस्ताव के रूप में यह गंभीर समस्याओं से ग्रस्त है जो इसे स्वीकृत होने से रोकती हैं। विवरण के लिए दस्तावेज़ में टिप्पणियां देखें।
- मृत
- प्रस्ताव को लंबे समय से छुआ नहीं गया है, और ऐसा नहीं लगता कि कोई इसे जल्द ही पूरा करेगा। यह फिर से “खुला” हो सकता है यदि यह एक नया प्रस्तावक प्राप्त करता है।
- अनुसंधान की आवश्यकता
- अनुसंधान समस्याएं हैं जिन्हें हल करने की आवश्यकता है trước कि यह स्पष्ट हो जाए कि प्रस्ताव एक अच्छा विचार है या नहीं।
- मेटा
- यह एक प्रस्ताव नहीं है, बल्कि प्रस्तावों के बारे में एक दस्तावेज़ है।
- reserve
- यह प्रस्ताव कुछ ऐसा नहीं है जिसे हम वर्तमान में लागू करने की योजना बना रहे हैं, लेकिन हम इसे किसी दिन पुनर्जीवित कर सकते हैं यदि हम यह तय करते हैं कि हम कुछ ऐसा करना चाहते हैं जो यह प्रस्ताव प्रस्तावित करता है।
- सूचनात्मक
- यह प्रस्ताव जो कर रहा है उस पर अंतिम शब्द है। यह एक विनिर्देश में तब तक नहीं बदलेगा जब तक कि कोई इसे एक नए उप-प्रणाली के लिए एक नए विनिर्देश में कॉपी-पेस्ट नहीं करता।
संपादक प्रस्तावों की सही स्थिति को बनाए रखते हैं, खुरदरी सहमति और अपने विवेक के आधार पर।
प्रस्ताव संख्यांकन
संख्या 000-099 विशेष और मेटा-प्रस्तावों के लिए आरक्षित हैं। 100 और ऊपर वास्तविक प्रस्तावों के लिए उपयोग किए जाते हैं। संख्याएं पुनर्नवीन नहीं की जाती हैं।