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