نظرة عامة
يصف هذا المستند كيفية تغيير مواصفات 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إذا تم إجراء تغييرات كبيرة على هذا المقترح التي لا تغير بشكل كبير محتواه. إذا تم تغيير المحتوى بشكل كبير، يجب إضافة مؤلف إضافي أو إنشاء مقترح جديد يحل محل هذا.
هذه الحقول اختيارية ولكنها موصى بها:
:target:
:implementedin:
- يجب أن يصف حقل
targetالإصدار الذي يأمل في تنفيذ المقترح فيه (إذا كان مفتوحًا أو مقبولًا). - يجب أن يصف حقل
implementedinالإصدار الذي تم تنفيذ المقترح فيه (إذا كان منتهيًا أو مغلقًا).
يجب أن يبدأ جسم المقترح بجزء نظرة عامة يشرح ما هو المقترح، وماذا يفعله، وما هو حالته.
بعد نظرة عامة، يصبح المقترح أكثر حرية في الشكل. اعتمادًا على طوله وcomplexity، يمكن أن يقسم المقترح إلى أقسام كما هو مناسب، أو اتباع تنسيق قصير. يجب أن يحتوي كل مقترح على الأقل المعلومات التالية قبل قبوله، على الرغم من أن المعلومات لا تحتاج إلى أن تكون في أقسام باسم هذه الأسماء.
- الدافع
- ما هو المشكلة التي يحاول المقترح حلها؟ لماذا تهتم هذه المشكلة؟ إذا كانت هناك عدة طرق ممكنة، لماذا نتبع هذه الطريقة؟
- التصميم
- نظرة عامة عالية المستوى على الميزات الجديدة أو المعدلة، وكيف تعمل الميزات الجديدة أو المعدلة، وكيف تعمل معًا، وكيف تتفاعل مع بقية I2P. هذا هو الجسم الرئيسي للمقترح. بعض المقترحات ستبدأ فقط مع دافع وتصميم، وستنتظر مواصفة حتى يبدو التصميم تقريبًا صحيحًا.
- آثار الأمان
- ما هي الآثار التي قد يكون لها التغييرات المقترحة على عدم الكشف عن الهوية، وكيف يُفهم هذه الآثار، وما إلى ذلك.
- المواصفة
- وصف مفصل لما يحتاج إلى إضافته إلى مواصفات I2P لتنفيذ المقترح. يجب أن يكون هذا في التفاصيل نفسها التي ستحتويها المواصفات في النهاية: يجب أن يكون من الممكن لمبرمجين مستقلين كتابة تنفيذات متوافقة مع المقترح بناءً على مواصفاته.
- التوافق
- هل ستكون إصدارات I2P التي تتبع المقترح متوافقة مع الإصدارات التي لا تفعل ذلك؟ إذا كان الأمر كذلك، كيف سيتم تحقيق التوافق؟ بشكل عام، نحاول عدم إسقاط التوافق إذا كان ذلك ممكنًا؛ لم نقم بتغيير “يوم العلامة” منذ مارس 2008، ولا نريد القيام بذلك مرة أخرى.
- التنفيذ
- إذا كان المقترح سيكون صعبًا في تنفيذه في هيكل I2P الحالي، يمكن أن يحتوي المستند على بعض المناقشة حول كيفية جعلها تعمل. يجب أن تذهب التعديلات الفعلية إلى فروع Monotone العامة، أو يتم تحميلها إلى Trac.
- ملاحظات الأداء والتوسع
- إذا كانت الميزة سوف تؤثر على الأداء (في ذاكرة الوصول العشوائي، وحدة المعالجة المركزية، عرض النطاق الترددي) أو التوسع، يجب أن يكون هناك بعض التحليل حول مدى أهمية هذا التأثير، حتى نتمكن من تجنب انخفاضات الأداء باهظة الثمن، ونتمكن من تجنب فقدان الوقت على مكاسب غير مهمة.
- ** المراجع**
- إذا كان المقترح يشير إلى مستندات خارجية، يجب أن تتم فهرستها.
حالة المقترح
- مفتوح
- مقترح قيد المناقشة.
- مقبول
- المقترح كاملة، ونحن نعتزم تنفيذها. بعد هذه النقطة، يجب تجنب التغييرات المهمة للمقترح، وينظر إليها على أنها علامة على فشل العملية في مكان ما.
- منتهي
- المقترح تم قبولها وتنفيذها. بعد هذه النقطة، لا يجب تغيير المقترح.
- مغلق
- المقترح تم قبولها وتنفيذها ودمجها في المستندات الرئيسية للمواصفة. لا يجب تغيير المقترح بعد هذه النقطة.
- مرفوض
- لن ننفذ الميزة كما هو موضح هنا، على الرغم من أننا قد نفعل بعض الإصدارات الأخرى. انظر التعليقات في المستند للحصول على التفاصيل. لا يجب تغيير المقترح بعد هذه النقطة؛ لرفع بعض الإصدارات الأخرى من الفكرة، اكتب مقترحًا جديدًا.
- مسودة
- هذا ليس مقترحًا كاملاً بعد؛ هناك قطع مفقودة محددة. يرجى عدم إضافة أي مقترحات جديدة بهذا الحالة؛ ضعها في دليل “الأفكار” بدلاً من ذلك.
- يحتاج إلى تعديل
- فكرة المقترح جيدة، ولكن المقترح كما هو موجود لديه مشاكل خطيرة تمنعه من القبول. انظر التعليقات في المستند للحصول على التفاصيل.
- ميت
- لم يتم لمس المقترح منذ فترة طويلة، ولا يبدو أن أي شخص سينفذه قريبًا. يمكن أن يصبح “مفتوحًا” مرة أخرى إذا حصل على مؤيد جديد.
- يحتاج إلى بحث
- هناك مشاكل بحثية تحتاج إلى حل قبل أن يصبح واضحًا ما إذا كان المقترح فكرة جيدة.
- ميتا
- هذا ليس مقترحًا، ولكن مستندًا حول المقترحات.
- احتياطي
- هذا المقترح ليس شيئًا نخطط حاليًا لتنفيذه، ولكننا قد نريد إحياؤه في يوم ما إذا قررنا القيام بشيء مشابه لما يقترحه.
- إعلامي
- هذا المقترح هو الكلمة الأخيرة حول ما يفعله. لن يصبح مواصفة حتى شخص ما يقوم بنسخ ولصقها إلى مواصفة جديدة لنظام فرعي جديد.
يحافظ المحررون على حالة المقترحات بشكل صحيح، بناءً على إجماع تقريبي وتصرفهم الخاص.
ترقيم المقترحات
الأرقام 000-099 محجوزة للمقترحات الخاصة والمتعلقة بالبيانات. 100 واعلى تستخدم للمقترحات الفعلية. لا يتم إعادة تدوير الأرقام.