अवलोकन
यह दस्तावेज़ I2P विनिर्देशों को बदलने की प्रक्रिया, I2P प्रस्ताव कैसे काम करते हैं, और I2P प्रस्तावों और विनिर्देशों के बीच संबंध को वर्णित करता है।
यह दस्तावेज़ Tor प्रस्ताव प्रक्रिया से लिया गया है, और नीचे दिया गया अधिकांश सामग्री मूल रूप से Nick Mathewson द्वारा लिखी गई थी।
यह एक सूचनात्मक दस्तावेज़ है।
प्रेरणा
पहले, I2P विनिर्देशों को अपडेट करने की हमारी प्रक्रिया अपेक्षाकृत अनौपचारिक थी: हम विकास मंच पर एक प्रस्ताव पेश करते और बदलावों पर चर्चा करते, फिर हम सहमति प्राप्त करते और मसौदा परिवर्तनों के साथ विनिर्देश को पैच करते (हमें यह आदेश नहीं हो सकता है), और अंततः हम बदलाव लागू करते।
इसमें कुछ समस्याएँ थीं।
पहले, अपनी अधिकतम दक्षता पर भी, पुरानी प्रक्रिया अक्सर स्पेक को कोड के साथ सिंक से बाहर रखती थी। सबसे खराब मामले वे थे जहाँ कार्यान्वयन टाल दिया गया था: स्पेक और कोड संस्करणों के लिए समय के साथ कभी-कभी अलग हो सकते थे।
दूसरी बात, चर्चा में भाग लेना कठिन था, क्योंकि यह हमेशा स्पष्ट नहीं था कि चर्चा धागे के कौन से भाग प्रस्ताव का हिस्सा थे, या स्पेक में कौन से बदलाव लागू किए गए थे। विकास मंच भी केवल I2P के अंदर तक ही पहुँचा जा सकता है, जिसका मतलब था कि प्रस्ताव केवल I2P उपयोगकर्ताओं द्वारा ही देखे जा सकते थे।
तीसरी बात, कुछ प्रस्तावों को भूलना बहुत आसान था क्योंकि वे मंच की धागा सूची में कई पृष्ठों पीछे दब जाते थे।
अब स्पेक्स कैसे बदलें
पहले, कोई व्यक्ति एक प्रस्ताव दस्तावेज़ लिखता है। इसमें विस्तार से बदलाव का वर्णन करना चाहिए, और इसे कैसे लागू किया जाए इसका कुछ विचार देना चाहिए। एक बार जब यह पर्याप्त रूप से परिपक्व हो जाता है, तो यह एक प्रस्ताव बन जाता है।
RFC की तरह, हर प्रस्ताव को एक अंक प्राप्त होता है। RFCs के विपरीत, प्रस्ताव समय के साथ बदल सकते हैं और जब तक वे अंततः स्वीकार या अस्वीकार नहीं हो जाते, तब तक उसी अंक को बनाए रखते हैं। प्रत्येक प्रस्ताव का इतिहास I2P वेबसाइट रिपॉजिटरी में संग्रहीत किया जाएगा।
एक बार जब प्रस्ताव रिपॉजिटरी में होता है, तो हमें इसे संबंधित धागे पर चर्चा करनी चाहिए और इसे तब तक सुधारना चाहिए जब तक कि हमें यह सहमति नहीं मिल जाती कि यह एक अच्छा विचार है, और यह लागू करने के लिए पर्याप्त विस्तृत है। जब ऐसा होता है, तो हम प्रस्ताव को लागू करते हैं और इसे विनिर्देशों में शामिल करते हैं। इस प्रकार, स्पेक्स I2P प्रोटोकॉल के लिए मानक डॉक्यूमेंटेशन बने रहते हैं: कोई प्रस्ताव कभी भी किसी कार्यान्वित फीचर के लिए मानक दस्तावेज़ नहीं होता है।
(यह प्रक्रिया काफी हद तक पायथन एन्हांसमेंट प्रक्रिया के समान है, मुख्य अपवाद के साथ कि I2P प्रस्ताव कार्यान्वयन के बाद विनिर्देशों में पुनः एकीकृत होते हैं और PEPs नया स्पेक बन जाते हैं।)
छोटे बदलाव
यदि कोड को लगभग तुरंत लिखा जा सकता है, तो स्पेक में सीधे छोटे परिवर्तन करना ठीक है, या यदि कोई कोड परिवर्तन आवश्यक नहीं है तो सौंदर्यशास्त्रिक परिवर्तन भी। यह दस्तावेज़ वर्तमान डेवलपर्स के इरादे को दर्शाता है, भविष्य में हमेशा इस प्रक्रिया का उपयोग करने के लिए कोई स्थायी वादा नहीं: हम अधिकार सुरक्षित रखते हैं कि वास्तविक रूप से उत्साहित होकर कुछ नया लागू करने के लिए, एक कैफीन- या M&M-संचालित सारी रात चलने वाले हैकिंग सत्र में।
नए प्रस्ताव कैसे जोड़े जाते हैं
प्रस्ताव प्रस्तुत करने के लिए, इसे विकास मंच पर पोस्ट करें या प्रस्ताव संलग्न के साथ एक टिकट दर्ज करें।
एक बार जब एक विचार प्रस्तावित किया गया है, और ठीक से स्वरूपित (नीचे देखें) मसौदा मौजूद है, और सक्रिय विकास समुदाय के भीतर मोटे तौर पर सहमति है कि यह विचार विचारण के योग्य है, प्रस्ताव संपादक आधिकारिक रूप से प्रस्ताव जोड़ देंगे।
वर्तमान प्रस्ताव संपादक zzz और str4d हैं।
प्रस्ताव में क्या होना चाहिए
हर प्रस्ताव में निम्नलिखित फ़ील्ड्स के साथ एक हेडर होना चाहिए:
:author:
:created:
:thread:
:lastupdated:
:status:
authorफ़ील्ड में इस प्रस्ताव के लेखक के नाम होने चाहिए।threadफ़ील्ड में विकास मंच धागे का लिंक होना चाहिए जहाँ यह प्रस्ताव मूल रूप से पोस्ट किया गया था, या इस प्रस्ताव पर चर्चा करने के लिए बनाए गए नए धागे का लिंक होना चाहिए।lastupdatedफ़ील्ड शुरुआत मेंcreatedफ़ील्ड के बराबर होनी चाहिए, और जब भी प्रस्ताव में बदलाव होता है, इसे अपडेट किया जाना चाहिए।
ये फ़ील्ड आवश्यकतानुसार सेट की जानी चाहिए:
:supercedes:
:supercededby:
:editor:
supercedesफ़ील्ड सभी प्रस्तावों की कॉमा से अलग की गई तालिका है जो इस प्रस्ताव को प्रतिस्थापित करती है। उन प्रस्तावों को अस्वीकृत कर देना चाहिए और उनकीsupercededbyफ़ील्ड को इस प्रस्ताव की संख्या पर सेट कर देना चाहिए।editorफ़ील्ड को उस परिस्थिति में सेट करना चाहिए यदि इस प्रस्ताव में महत्वपूर्ण बदलाव किए गए हों जो इसकी सामग्री को काफी हद तक नहीं बदलते। अगर सामग्री को काफी हद तक बदला जा रहा है, तो या तो एक अतिरिक्तauthorजोड़ा जाना चाहिए, या इस प्रस्ताव को प्रतिस्थापित करने वाला एक नया प्रस्ताव बनाया जाना चाहिए।
ये फ़ील्ड वैकल्पिक हैं लेकिन अनुशंसनीय:
:target:
:implementedin:
targetफ़ील्ड में उस संस्करण का वर्णन होना चाहिए जिसमें प्रस्ताव को लागू करने की उम्मीद है (यदि यह Open या Accepted है)।implementedinफ़ील्ड में उस संस्करण का वर्णन होना चाहिए जिसमें प्रस्ताव लागू किया गया था (यदि यह Finished या Closed है)।
प्रस्ताव का मुख्य शरीर एक अवलोकन अनुभाग के साथ शुरू होना चाहिए, जो बताएगा कि प्रस्ताव किस बारे में है, यह क्या करता है, और यह किस स्थिति में है।
अवलोकन के बाद, प्रस्ताव अधिक स्वतंत्र रूप से स्वरूपित हो जाता है। अपनी लंबाई और जटिलता के अनुसार, प्रस्ताव उपयुक्त खंडों में विभाजित हो सकता है, या एक छोटे वर्णनात्मक प्रारूप का पालन कर सकता है। हर प्रस्ताव में कम से कम निम्नलिखित जानकारी होनी चाहिए इससे पहले कि यह Accepted हो, हालांकि जानकारी को इन नामों के साथ खंडों में होने की आवश्यकता नहीं है।
- प्रेरणा
- प्रस्ताव किस समस्या को हल करने का प्रयास कर रहा है? यह समस्या क्यों महत्वपूर्ण है? अगर कई दृष्टिकोण संभव हैं, तो इस दृष्टिकोण को क्यों अपनाएँ?
- डिजाइन
- नए या संशोधित विशेषताएँ क्या हैं, नए या संशोधित विशेषताएँ कैसे काम करती हैं, वे एक दूसरे के साथ कैसे इंटरऑपरेट करती हैं, और वे I2P के बाकी हिस्सों के साथ कैसे इंटरैक्ट करती हैं। यह प्रस्ताव का मुख्य भाग है। कुछ प्रस्ताव केवल प्रेरणा और डिज़ाइन के साथ शुरू होते हैं, और डिज़ाइन के लगभग सही लगने तक विनिर्देश के लिए प्रतीक्षा करते हैं।
- सुरक्षा प्रभाव
- प्रस्तावित बदलावों का गुमनामी पर क्या प्रभाव हो सकता है, ये प्रभाव कितने अच्छे से समझे जाते हैं, वगैरह।
- विनिर्देशन
- विनिर्देशों में प्रस्ताव को लागू करने के लिए जोड़े जाने की आवश्यकता वाली चीजों का विस्तृत विवरण। यह लगभग उतनी ही विवरण में होना चाहिए जितनी कि स्पेसिफिकेशन्स अंततः होंगे: स्वतंत्र प्रोग्रामर्स द्वारा प्रस्ताव के स्पेसिफिकेशन्स के आधार पर परस्पर संगत कार्यान्वयन लिखना संभव होना चाहिए।
- अनुकूलता
- क्या प्रस्ताव के बाद के संस्करण, उन संस्करणों के साथ संगत होंगे जो नहीं हैं? अगर ऐसा है, तो अनुकूलता कैसे प्राप्त की जाएगी? सामान्यतः, हम जहाँ तक संभव हो, अनुकूलता न गिराने की कोशिश करते हैं; हमने मार्च 2008 के बाद से “फ्लैग डे” परिवर्तन नहीं किया है, और हम एक और नहीं करना चाहते हैं।
- कार्यान्वयन
- अगर प्रस्ताव को I2P के मौजूदा आर्किटेक्चर में लागू करना मुश्किल होगा, तो दस्तावेज़ में इसे काम करने के तरीके के लिए कुछ चर्चा शामिल हो सकती है। वास्तविक पैच सार्वजनिक मोनोटोन ब्रांचेज पर जाने चाहिए, या ट्रैक पर अपलोड होने चाहिए।
- प्रदर्शन और मापनीयता टिप्पणियाँ
- अगर फीचर का प्रदर्शन (RAM, CPU, बैंडविड्थ) या मापनीयता पर कोई प्रभाव होगा, तो इस प्रभाव के महत्वपूर्ण होने के विश्लेषण पर कुछ चर्चा होनी चाहिए, ताकि हम महंगे प्रदर्शन प्रतिगमन से बच सकें, और ताकि हम नगण्य लाभों पर समय बर्बाद करने से बच सकें।
- संदर्भ
- यदि प्रस्ताव बाहरी दस्तावेज़ों का संदर्भ देता है, तो उन्हें सूचीबद्ध किया जाना चाहिए।
प्रस्ताव स्थिति
- Open
- चर्चा के अधीन प्रस्ताव।
- Accepted
- प्रस्ताव पूरा हो गया है, और इसे लागू करने का हमारा इरादा है। इस बिंदु के बाद, प्रस्ताव में भौतिक परिवर्तन से बचना चाहिए, और इसे प्रक्रिया की कहीं विफलता का संकेत मानना चाहिए।
- Finished
- प्रस्ताव स्वीकार और कार्यान्वित किया गया है। इस बिंदु के बाद, प्रस्ताव को बदला नहीं जाना चाहिए।
- Closed
- प्रस्ताव स्वीकार कर लिया गया है, कार्यान्वित कर लिया गया है, और मुख्य विनिर्देशन दस्तावेजों में मिला दिया गया है। इस बिंदु के बाद प्रस्ताव को बदला नहीं जाना चाहिए।
- Rejected
- हम यहाँ वर्णित विशेषता को नहीं लागू करेंगे, लेकिन हम कुछ और संस्करण कर सकते हैं। दस्तावेज़ में विवरण के लिए टिप्पणियाँ देखें। इस बिंदु के बाद प्रस्ताव को बदला नहीं जाना चाहिए; विचार का कोई और संस्करण लाने के लिए, एक नया प्रस्ताव लिखें।
- Draft
- यह अभी तक एक पूर्ण प्रस्ताव नहीं है; इसमें निश्चित रूप से कुछ कमी है। कृपया इस स्थिति के साथ कोई नया प्रस्ताव न जोड़ें; उन्हें “आइडियाज” सब-डायरेक्टरी में डालें।
- Needs-Revision
- प्रस्ताव के लिए विचार अच्छा है, लेकिन प्रस्ताव का मौजूदा रूप इसे स्वीकार किए जाने से रोकता है। दस्तावेज़ में विवरण के लिए टिप्पणियाँ देखें।
- Dead
- प्रस्ताव को लंबे समय से नहीं छुआ गया है, और ऐसा नहीं लगता कि कोई इसे जल्द ही पूरा करेगा। अगर इसे एक नए प्रस्तावक द्वारा पुर्नजीवित किया जाता है, तो यह फिर से “Open” बन सकता है।
- Needs-Research
- ऐसे शोध समस्याएँ हैं जिन्हें हल करने की आवश्यकता है इससे पहले कि यह स्पष्ट हो सके कि प्रस्ताव एक अच्छा विचार है।
- Meta
- यह एक प्रस्ताव नहीं है, बल्कि प्रस्तावों के बारे में एक दस्तावेज़ है।
- Reserve
- यह प्रस्ताव कुछ ऐसा नहीं है जिसे हम वर्तमान में लागू करने की योजना बना रहे हैं, लेकिन हम इसे कभी फिर से जीवित करना चाहते हैं अगर हम यह करने का निर्णय लेते हैं जैसा कि यह प्रस्ताव करता है।
- Informational
- यह प्रस्ताव जो कर रहा है, वह इस पर अंतिम शब्द है। यह एक स्पेक में नहीं बदलने जा रहा है जब तक कि कोई इसे एक नए उपसिस्टम के लिए एक नए स्पेक में कॉपी और पेस्ट नहीं करता।
संपादक प्रस्तावों की सही स्थिति बनाए रखते हैं, मोटे तौर पर सहमति और अपने विवेक के आधार पर।
प्रस्ताव संख्या
संख्याएं 000-099 विशेष और मेटा-प्रस्तावों के लिए आरक्षित हैं। 100 और उससे ऊपर का उपयोग वास्तविक प्रस्तावों के लिए किया जाता है। संख्याओं को पुनः उपयोग नहीं किया जाता है।