قد ينجح اتفاق خدمة RFC ويبقى المؤلف في الانتظار

الخلاصة

• يفيد تقرير التشاور بأن الاتفاق القديم تحقق في 42.5% فقط من الأرباع المقاسة منذ 2016، وأن بيانات الحالات القديمة لم تفصل دائماً انتظار المؤلف أو انتظار تعيين المحرر أو الجزء الذي يخص RPC في مرحلة AUTH48.
• يقترح البديل نافذة سنة متحركة، وقياس التدفق والتراكم، وثلاث فئات للحجم، ونسباً مئينية وحدوداً تضيق تدريجياً، على أن يقتصر الحساب على الزمن الذي يستطيع RPC التحكم فيه.
• يقدّر التقرير الرحلة الحالية لوثيقة نموذجية من 30 إلى 50 صفحة بنحو 245 يوماً تقويمياً، ويربط نحو 115 يوماً بالتراكم، ويذكر متوسطاً يقارب 97 يوماً خارج سيطرة RPC. هذه مناظير إجمالية متداخلة وليست ثلاثة مقاطع يجوز جمعها.
• يقترح Daniel Kade سجلاً منسوباً لكل إحالة، يحتفظ ببداية الحالة ونهايتها وصاحبها والفعل التالي وأساس الساعة والسبب والتصعيد والتصحيح، كي يظهر زمن المسؤولية والمدة الكاملة معاً.

الساعة العادلة لا تكفي وحدها

عندما يرسل المحرر سؤالاً إلى المؤلف، يجب أن تتوقف ساعة RPC. لا يملك مركز الإنتاج الإجابة، ولا يجوز أن يفشل في التزام تعاقدي بسبب عمل موجود لدى شخص آخر. لكن اليوم الذي يمر لا يختفي من رحلة الوثيقة. إنه زمن حقيقي، وله صاحب فعل تالٍ، وقد يحتاج إلى تذكير أو تصعيد أو إعادة تصميم في حال تكرره.

هذه ليست مفاضلة بين الصدق والكفاءة، بل بين سؤالين. السؤال الأول: هل أنجز RPC ما كان تحت سيطرته ضمن الحد؟ السؤال الثاني: متى تحولت المسودة المقبولة إلى RFC منشور؟ الأول ينسب المسؤولية بدقة. والثاني يقيس النتيجة المشتركة. إذا استعملنا الأول بدلاً من الثاني اختفت بعض التجربة؛ وإذا حمّلنا الأول كل ما في الثاني نسبنا التأخير إلى الجهة الخطأ.

يشرح التشاور لماذا لم يعد المقياس السابق يؤدي وظيفته. فبحسب تحليله، تحقق في 42.5% من الأرباع المقاسة منذ 2016. حين تصبح المخالفة هي الحالة المعتادة، لا يعود المؤشر قادراً على تمييز حادث استثنائي من عجز بنيوي أو هدف فقد صلته بالعمل الفعلي.

وكانت أسماء الحالات نفسها ناقصة. قبل الربع الثاني من 2025، نادراً ما استعملت حالة تعليق العمل بانتظار المؤلف، فكان من الممكن أن يظهر RPC على الساعة وهو ينتظر جواباً. ولم توجد حالة مستقلة لوثيقة تنتظر تعيين محرر. كما ظلت أجزاء من AUTH48 التي يعمل فيها RPC خارج الحساب. قد تكون العمليات الحسابية صحيحة بالنسبة إلى الحقول المسجلة، بينما تظل دلالتها التشغيلية ملتبسة.

ما الذي يريد الاقتراح قياسه؟

لا يفترض التصميم أن كل RFC يحمل عبء العمل نفسه. يقدّر تقرير التشاور أن الصفحة تضيف في المتوسط نحو 0.34 يوم من زمن RPC. ولهذا يقسم الوثائق إلى ثلاث فئات. في خط البداية المقترح، ينبغي أن تنتهي 75% من الوثائق ضمن 130 يوماً من زمن RPC إذا كانت في 15 صفحة أو أقل، و170 يوماً إذا كانت بين 16 و40 صفحة، و190 يوماً إذا تجاوزت 40 صفحة.

ثم يعمل مساران للتشديد. ترتفع النسبة المطلوبة نقطة مئوية واحدة كل ربع سنة حتى تبلغ 85%. وبعد السنة الأولى، تنخفض الحدود الزمنية القصوى 5% في كل سنة. الأول يطلب إدخال حصة أكبر من الوثائق في النتيجة؛ والثاني يطلب تحقيق ذلك في وقت أقصر. وبدلاً من الحكم على ربع واحد متقلب، يحتسب التدفق على سنة متحركة.

ولا يعتمد الاتفاق على زمن المعالجة وحده. يقترح أيضاً حداً أقصى للتراكم النشط وقياساً للوثائق والصفحات. هذا مهم لأن متوسطاً جيداً قد يتعايش مع ذيل قديم، كما يمكن لتدفق قوي أن يتعايش مع وصول طلبات أسرع من الإنجاز. النسب المئينية والحجم والتراكم تجيب عن أبعاد مختلفة.

لكن النموذج يحمل فرضيات لا ينبغي دفنها داخل الرسم. فهو يفترض ثبات الموارد التحريرية الإجمالية وثبات نطاق عمل RPC، ويختار خفضاً بطيئاً للتراكم من الموارد الحالية لا استثماراً مؤقتاً إضافياً. في هذه الظروف، يتوقع خفض التراكم بنحو 20% خلال ثلاث سنوات والتخلص منه خلال سبع إلى اثنتي عشرة سنة. هذا مسار مشروط لا موعد مضمون.

إذا ارتفع معدل وصول الوثائق، أو تغير التعقيد، أو توسعت متطلبات الوصول والتحقق، أو تبدل عدد المحررين، تغيرت النتيجة. ولهذا يسأل التشاور صراحة عن الاستثمار قصير الأجل، وتحديد الأولويات، وجودة الخدمة، ورضا المؤلفين، وما إذا كان ينبغي وقف بعض الأعمال لتحسين السرعة. كل خيار ينقل تكلفة إلى مكان ما.

ثلاثة أرقام لا تشكل عملية جمع

يقدّر التشاور أن RFC نموذجياً من 30 إلى 50 صفحة يستغرق حالياً نحو 245 يوماً تقويمياً من الاستلام إلى النشر. ويربط نحو 115 يوماً من الوضع الراهن بالتراكم، ويعرض تقديراً يقارب 130 يوماً من دون ذلك التراكم. كما يقول إن الزمن خارج سيطرة RPC يبلغ في المتوسط نحو 97 يوماً ولا يعتمد كثيراً على عدد الصفحات.

لا تعني هذه الصياغة أن 245 و115 و97 ثلاث كتل مستقلة. بعضها وصف للرحلة، وبعضها أثر مقدّر، وبعضها متوسط عبر حالات وأدوار مختلفة. جمعها يعطي رقماً لا تقوله الوثيقة. كما أنها لا تثبت سبب انتظار RFC بعينه. الغرض منها رؤية بنية الخدمة، لا إعادة بناء ملف حالة فردي.

ومع هذا، تكشف الأرقام إمكان التباعد. يستطيع RPC خفض زمنه بينما يبقى التأخير الكلي ثابتاً لأن الطابور السابق للتعيين أو فعل المؤلف أو IESG أو IANA يستوعب الفرق. وقد يبقى مقياس RPC سيئاً رغم تحسن زمن النشر إذا تغير تركيب الوثائق أو ازداد العمل النوعي. لا بد أن تبقى النظرتان متاحتين حتى لا نستنتج علاقة سببية من لوحة واحدة.

التراكم مهم بوجه خاص لأنه قد يسبق أول لمسة تحريرية. إذا بدأت الساعة عند العمل النشط، فإن عمر الانتظار غير المعنون يصبح خارج قصة الأداء. الاعتراف بحالة انتظار التعيين يحول غرفة الانتظار إلى شيء يمكن إدارته: نعرف عمرها، وحجمها، والموارد التي تستطيع تغييرها.

AUTH48 يكشف معنى الإسناد

مرحلة AUTH48 قريبة من النهاية، لكنها ليست إجراء شكلياً. يراجع المؤلفون والمراجعون المعينون النص المحرر، وقد تتطلب الدقة التقنية سؤالاً أو تصحيحاً أو تنسيقاً مع IANA. هذه المراجعة تحمي قيمة السلسلة الأرشيفية. ليست كل وقفة هدراً ينبغي ضغطه.

إذا بقيت الإجابة لدى المؤلف، لا يحتسب الزمن على RPC. لكن السجل الكامل ينبغي أن يحفظ متى خرج السؤال، ومن يملك الفعل التالي، وما الاعتماد المرتبط به، وما إذا كان تجاوز عتبة التصعيد، ومتى عاد. الإسناد يمنع اللوم الخاطئ من دون تحويل الوقفة إلى فراغ.

إظهار الإحالة لا يصنع تفويضاً جديداً

وينطبق المنطق نفسه على مدير المسار أو IESG أو IANA. الاتفاق الإداري لا يستطيع أن يقرر مضموناً تقنياً أو يفرض موافقة بمجرد بدء مؤقت. RFC 9280 يفصل سياسة سلسلة RFC عن تنفيذ الإنتاج، ويضع أدواراً مختلفة لـ RSWG وRSAB وRPC وIETF LLC. كما يمنح RFC 8711 الشركة مسؤولية إدارية وتشغيلية ومالية من دون سلطة على تطوير معايير IETF.

لذلك يجب أن يعبر السجل الحدود المؤسسية من دون أن يمحوها. لا يحتاج كل مشارك إلى سلطة على الآخر. يحتاج كل مقطع إلى مالك واضح، وفعل تالٍ، ودليل على الانتقال. إنه سجل مشترك محدود الوظيفة، لا حاكم يبتلع السلطات المنفصلة.

ولا يغير سجل الإحالة توزيع السلطة. فهو يثبت فقط وقت دخول الوثيقة إلى مقطع كل جهة وخروجها منه، ومن يملك الفعل التالي، وكيف صحح السجل لاحقاً. تستطيع الأدلة عبور الحدود المؤسسية من دون أن يحصل المسؤول الإداري أو RPC أو المقياس نفسه على السلطة الموجودة في الجانب الآخر.

سجل الإحالة المقترح

تبدأ الوحدة بهوية المسودة المقبولة والوثيقة النهائية. لكل حالة وقت دخول ووقت خروج، مع بيان ما إذا كانت الساعة أيام عمل أم أياماً تقويمية، وما إذا كانت تعمل أم متوقفة. يسجل صاحب الحالة، وحامل الفعل التالي، والسبب القابل للمعالجة الآلية، والطلب المحدد، والاعتماد، وعتبة التذكير أو التصعيد.

عند تغيير التصنيف، لا يمحى السجل القديم. تحفظ القيمة السابقة، والسبب، والتاريخ، والجهة المخولة بالتصحيح. يمكن عندئذ إعادة حساب السلسلة الحالية، مع بقاء تفسير الفرق بينها وبين تقرير سابق. التصحيح ضروري؛ إعادة كتابة الماضي بصمت ليست كذلك.

لا يلزم كشف المراسلات التحريرية الحساسة. يستطيع التقرير العام جمع الحالات بحسب فئة الحجم أو المسار أو نوع الاعتماد. لكنه ينبغي أن ينتج ثلاثة مجاميع على الأقل: زمن RPC، والزمن المنسوب إلى الجهات الأخرى، والزمن التقويمي الكامل. ويضاف إلى ذلك عمر التراكم قبل التعيين حتى لا تختبئ المرحلة التي لا يعمل فيها محرر بعد.

هذا السجل ليس اتفاق خدمة ثانياً. لا يفرض عقوبة على المؤلف ولا يمنح IETF LLC حق التدخل في قرار معياري. إنه طبقة إثبات تجعل النتيجة الخضراء قابلة للتفسير. فإذا تحسن زمن RPC ولم تتحسن الرحلة، أمكن البحث عن الإحالة التي امتصت الانتظار. وإذا طال الزمن الكلي بسبب مراجعة لازمة، بقيت الجودة مرئية بدلاً من وصفها تلقائياً بالفشل.

السرعة ليست الجودة

ازدادت مهام الإنتاج وتعقيدها. يسرد التشاور RFCXML v3 والتحقق من YANG والشفرة، ودعم النصوص غير اللاتينية واتجاه اليمين إلى اليسار، والعمل على الوصول، وتصحيح الأخطاء التحريرية، ودعم GitHub وMarkdown، وصيانة المواقع والأدوات. ويشير إلى تباطؤ تدريجي يقارب ستة أيام لكل وثيقة في السنة من دون رده إلى حادثة واحدة.

قد يتحسن الرقم إذا حذف جزء من العمل. وربما يكون تضييق النطاق قراراً مشروعاً إذا وافقت عليه الجهة المختصة وتحملت كلفته جهة معلومة. لكنه ليس الدليل نفسه على تحسن الكفاءة. ينبغي أن تظهر تغييرات النطاق بجانب السلسلة الزمنية حتى لا يقارن المجتمع خدمتين مختلفتين كما لو كانتا واحدة.

وتحتاج الجودة إلى مؤشرات منفصلة: إعادة العمل الموضوعية، والتصحيحات المهمة بعد النشر، ووضوح التواصل للمؤلف، والاتساق التحريري، والخلاف على التغييرات. أما رضا المؤلفين فينبغي تقسيمه بحسب الخبرة والمسار؛ فقد يجد رئيس مجموعة مخضرم العملية سهلة بينما يواجه مؤلف للمرة الأولى عائقاً لا يظهر في المتوسط.

الهدف ليس تعظيم عدد الوثائق بأي ثمن. الغرض من سلسلة RFC حفظ سجل تقني موثوق. يمكن للزمن والجودة أن يتجاورا في لوحة واحدة من دون أن يبتلع أحدهما الآخر.

التشاور يختار ما سيصبح قابلاً للرؤية

تعليق Mirja Kühlewind المنشور يرى أفق سبع إلى اثنتي عشرة سنة طويلاً ويتساءل عن فائدة الحدود الثابتة وحدها. ويركز رد Acee Lindem على تقليل الزمن من دخول الطابور إلى AUTH48 ويشكك في إضافة عمليات أو مقاييس. كلاهما رأي فردي منسوب، لا إجماعاً لـ IETF.

تظهر الرسالتان أن الخلاف لا يدور فقط حول رقم أسرع. إنه يدور حول ما ينبغي قياسه، وما العمل الذي يستحق التمويل، وما إذا كانت الحدود ستقود السلوك أم تصفه. حين يعتمد المؤشر، يدخل في العقود وتقارير المجلس والموازنات. وإذا لم تحفظ بيانات الرحلة الآن، لن يستطيع تقييم لاحق استعادتها.

القرار الأفضل قبل 6 سبتمبر ليس إسقاط الحد المسؤول. يحتاج RPC إلى معيار يمكنه التأثير فيه. القرار هو اعتماد هذا الحد مع رؤية غير عقابية للمسار الكامل. ضيق المساءلة يحمي العدالة؛ اكتمال السجل يحمي الحقيقة التشغيلية.

المصادر

1. التشاور حول اتفاق مستوى خدمة تحرير RFC ونشره
2. إعلان IETF Administration LLC عن التشاور
3. RFC 9280: نموذج محرر RFC، الإصدار الثالث
4. RFC 8711: بنية نشاط الدعم الإداري لـ IETF
5. مسار النشر الموجه للمؤلفين
6. شرح طابور RFC Editor
7. تقرير RPC الموجه إلى رؤساء مجموعات العمل
8. تقرير حالات النشر والتوقيت
9. رد Mirja Kühlewind الفردي
10. رد Acee Lindem الفردي