الخلاصة

  • يقول تحديث أغسطس 2026 إن هناك آلافاً من قضايا GitHub العالقة، منها نحو 1.1 ألف في Datatracker كمثال، وإن معظمها لا يدخل في بنية عمل مترابطة ولم يُقدّر جهده أو أولويته.
  • تنظم الخطة القضايا وفق Goal -> Project -> Epic -> Task، ثم تقدّر أدنى Tasks، ثم تضع Tools Team مسودة أولى للأولوية على مستوى Goals وProjects قبل فتحها لملاحظات المجتمع بآلية لم تكن قد حُددت.
  • تثبت القضية العامة أن طلباً سُجل؛ ولا تثبت أنه صُدق عليه أو قُبل أو مُول أو جُدول أو نُفذ أو أصبح إجماعاً لدى IETF.
  • يستطيع سجل علني لتصرف القضية أن يربط المصدر بالتصنيف والتقدير والأولوية والملاحظات والنتيجة، من دون نشر ZenHub الداخلي أو الثغرات أو العقود أو بيانات الأداء الفردية.

طلب صغير في الواجهة، مشروع متعدد الاعتماديات

تطلب القضية #9204 في Datatracker إظهار صفة Designated Expert في الصفحة الشخصية. تبدو المطالبة، من ظاهرها، تعديلاً محدوداً في العرض. وقد فُتحت في يوليو 2025، وظلت في صفحة GitHub العامة عند موعد الرصد بلا assignee أو project أو milestone أو relationship أو branch أو pull request.

لا تسمح هذه الخانات الفارغة بالقول إن أحداً تجاهل الطلب. إنها تثبت فقط أن الواجهة العامة لا تعرض الطريق المؤسسي اللاحق. فتحديث أغسطس يشرح أن التنفيذ قد يتطلب مواصفة API تقدم إلى IANA، ونموذجاً لأنواع مختلفة من Designated Expert — شخص أو دور Area Director أو قائمة أو مجموعة من chairs — ثم مطابقة بيانات IANA مع Datatracker، وأخيراً استيراداً حياً عبر الواجهة.

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

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

الحالة العامة الواحدة تخفي قرارات كثيرة

تظهر المستودعات عادة open أو closed. لكن حوكمة العمل تمر بأفعال منفصلة. intake يسجل ما طُلب ومتى. triage يقرر: يحتاج إيضاحاً، مؤكد، مكرر، مستبدل، خارج النطاق، أم مقيد لأسباب أمنية. التصنيف يربطه بـ Goal وProject وEpic وTask. التقدير يفحص الجهد والاعتماديات. تحديد الأولوية يقارن البدائل. تفويض الموارد يسمح بالقدرة أو الإنفاق. بعد ذلك تأتي roadmap والتنفيذ والإصدار والتصحيح والإغلاق.

لا يملك فاعل واحد كل هذه السلطات. صاحب الطلب يعرف الضرر الذي رآه، لكنه لا يلزم ميزانية IETF. والمطور يعرف كلفة التنفيذ، لكنه لا يحدد وحده الاستراتيجية. ويمكن لـ Tools Team أن تضع الجولة الأولى من الأولويات من دون أن تجعلها إجماعاً تقنياً. ويستطيع المجتمع تقديم أدلة تغير القرار، لكن كثرة التعليقات ليست تفويض إنفاق.

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

كان تقرير أغسطس دقيقاً: معظم القضايا لم يُقدّر جهدها أو أولويتها. ولم يقل إن القدم يمنح حق السبق، أو إن كل قضية تمثل إرادة مجتمع واسع. ظهور الطلب ووجود سلطة لتخصيص الموارد أمران مختلفان.

خارطة 2025 فقدت الوصلة نفسها

في ديسمبر 2025، شرحت Tools Team سبب سحب خارطة سابقة. قُسمت مشاريع تمتد على أرباع متعددة إلى مراحل لم يكن مضمونها واضحاً. واختلطت Goals مؤسسية بمشاريع تفصيلية. والأهم أن مشاريع الخارطة لم ترتبط بقضايا GitHub في مستودعات الأدوات المختلفة.

استخدم البديل GitHub project للقراءة فقط تديره Tools Team، وفصل Goals عن Projects. وطُرح على المجتمع ما إذا كان الهيكل يلبي حاجته، وما إذا كانت المستويات مفيدة لفهم الخطة والتأثير فيها، وما إذا كانت أهداف ومشاريع 2026 صحيحة. والقراءة فقط لا تلغي المشاورة؛ فهي تمنع التعديل العشوائي على السجل الرسمي وتترك باب الملاحظات مفتوحاً.

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

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

وفي أبريل، وُضع عمل الخارطة جانباً إلى أن يكتمل نشر تحديث RFC Production Center. وفي يونيو، ظلت من دون تحديث، وكان مقرراً مناقشة التخطيط ومشاركة المجتمع في retreat منتصف الشهر. لا يثبت ذلك التخلي. بل يظهر منافسة حقيقية على القدرة: مشروع تشغيلي متعدد السنوات يستطيع أن يؤخر حتى تحسين أداة التخطيط التي يفترض أن تشرح هذا الاختيار.

ثلاث مراحل لا عملاً واحداً اسمه «الأولوية»

المرحلة الأولى تصنف. كان الفريق سيخصص ثلاثة أسابيع بعد IETF 126 في فيينا لمراجعة القضايا ووضعها في Goal -> Project -> Epic -> Task. سيجري معظم العمل في ZenHub غير المرئي للمجتمع، مع نية ربط النتيجة بالمستودعات العامة. يمكن اكتشاف الحالات العاجلة، لكن معظم القضايا لا تُقدّر ولا تُرتب في هذه المرحلة. وحذر التقرير من أن ثلاثة أسابيع قد لا تكفي وأن sprint آخر قد يلزم.

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

المرحلة الثالثة تشكل الأولوية. تكون عادة على مستوى Goal وProject. تضع Tools Team المسودة الأولى كنقطة بداية، ثم تفتحها للمجتمع. وفي 6 أغسطس لم تكن آلية الملاحظات محددة. لذلك لا تمثل المسودة تفويضاً مجتمعياً، ولا ينبغي وصف المشاركة المقبلة بأنها اقتراع.

المصنف ليس مقبولاً بالضرورة. والمقدر ليس مجدولاً. وأولوية Project لا تجعل كل Tasks جاهزة. وموعد roadmap ليس معياراً فنياً أو ضماناً. وحكم Tools Team الإداري لا يصبح rough consensus لمجرد ظهوره في فضاء IETF.

ملاحظات المجتمع أدلة لا أصوات

للمجتمع معرفة ضرورية. تدعم Datatracker الوثائق وWorking Groups والمراجعات وballots والاجتماعات والأدوار، بينما تدعم أدوات أخرى البريد والتأليف وسجل RFC. وقد يفرض خلل صغير في نظر المشغل كلفة متكررة على المشاركين. ولهذا دُعي Tools Architecture and Strategy Team تاريخياً إلى التشاور الواسع، مع بقاء التنفيذ والصيانة والتشغيل لدى Tools Team.

غير أن القناة المفتوحة لا تصنع هيئة ناخبة ممثلة. ربما لا يعلق الخبير لأنه ابتكر workaround. وقد تجمع ميزة مرئية ردوداً أكثر من ترقية أمن أو ترحيل framework أو مطابقة بيانات، رغم أن تعطل الأعمال الصامتة أخطر. عد التعليقات يكافئ الصوت والوضوح، لا الضرر بالضرورة.

ينبغي أن تطلب آلية الملاحظات فئات دليل: workflow المتأثر، التكرار، الشدة، الأدوار، الحل البديل، أثر الاستمرارية، الموعد الخارجي، والرابط. وبعدها تنشر Tools Team تصرفاً محدوداً: إعادة تصنيف؛ قبول مع تأجيل؛ تغطية في Project آخر؛ خروج عن النطاق؛ تقييد أمني؛ أو إبقاء الأولوية مع سبب.

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

سجل التصرف من القضية إلى الخارطة

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

وحيث يكون النشر آمناً، يربط Goal وProject وEpic وTask العامة، ويذكر فئات الاعتماد والعوائق. يظهر الجهد كنطاق له تاريخ وثقة. «لم تُقدّر بعد» حالة صحيحة؛ والفراغ ليس كذلك. وللأولوية فئة وتاريخ وصاحب السلطة الحالي وسبب موجز، أو «لم تُحدد بعد».

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

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

ويجب أن يكون السجل projection من نظام التخطيط نفسه، لا قائمة رابعة يحررها شخص يدوياً. وإلا اختلفت GitHub وZenHub والخارطة العامة، وصارت أداة الشرح مصدراً جديداً للغموض.

ما ينبغي أن يبقى خاصاً

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

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

كما أن السجل لا يعيد توزيع السلطة. تحتفظ Tools Team بالمسودة الأولى للأولوية. ويحتفظ Executive Director وهيكل IETF LLC بمسؤوليات الإدارة والعقود والموارد، مع رقابة استراتيجية للـ Board. ويقدم المجتمع الأدلة ويطعن في الأسباب. وتبقى سلطة المعايير التقنية داخل عمليات IETF. السجل يوضح الحدود ولا يخترعها.

المصادر

  1. August Tools Update
  2. Introducing a new roadmap framework
  3. Public Executive Director Report, 18 February 2026
  4. March tools update discussion
  5. IETF tools update 2026-04
  6. June tools update
  7. The Tools Team
  8. Tools Architecture and Strategy Team
  9. RFC 8711
  10. IETF Administrative Strategic Plan 2020
  11. Datatracker issue #9204