الملخص

  • بدأت W3C Team في 10 أغسطس مرحلة refinement لمشروع ميثاق Immersive Web Working Group. وحدد الإشعار issue 564 للنقاش العلني، وأتاح للأعضاء النقاش عبر القائمة السرية w3c-ac-forum.
  • يوجب القسم 4.2 من W3C Process معالجة جميع issues المقدمة ضد المشروع رسمياً، وتتبع حلولها في disposition of comments مع إبراز ما لم يُحل بالتوافق.
  • يعرض السجل العلني سلسلة قابلة للفحص: ملاحظة أمنية موصوفة بأنها blocking، ورد وPR 862؛ وأسئلة من APA وردود وPR 865. وحتى 30 أغسطس ظل الطلبان مفتوحين وغير مدمجين.
  • السرية ليست خللاً. يحمي القسمان 7.2 و7.3 معلومات Member-only، ويسمحان للجهة المخولة بإعداد نسخة علنية غير منسوبة تنقل المطلوب بصورة معقولة من دون كشف الأصل المحمي.
  • ينبغي للسجل المشترك أن يذكر فئة المسألة، وإصدار الميثاق وقسمه، والرد، والفرق العلني أو سبب عدم التغيير، وحالة التوافق، وخطوة السلطة التالية، وسجل الاستبدال. ولا يحتاج إلى أسماء أو نصوص سرية أو أعداد تكشف الهوية.
  • تقدم المشاركة أدلة وخبرة، لكنها ليست تصويتاً في Advisory Committee ولا تفويضاً عاماً باسم الجمهور. تظل refinement وTeam Decision وAC Review وW3C Decision حالات سلطة منفصلة.

اختلاف البابين لا يعني اختلاف العملية

كان إشعار 10 أغسطس واضحاً. دعا إلى نقاش مبكر في مستودع Strategy العلني، وأتاح للأعضاء منتدى سرياً. ومع ذلك، يوجد Chartering Facilitator واحد وفترة refinement واحدة مقدر أن تنتهي قرابة 7 سبتمبر لمشروع واحد.

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

لذلك لا يثبت وجود قائمة سرية أن القرار يُدار في الخفاء، ولا يثبت حتى أن القائمة استُخدمت. وفي المقابل، لا تصبح GitHub واجهة بلا أثر لمجرد وجود باب آخر. السؤال يبدأ بعد وصول الرأي: هل يبقى مسار عام يربطه بالنص؟

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

السجل العلني يبين أن الحالة ليست ثنائية

لاحظ مراجع أمني أن المشروع يستخدم كلمة «sections» عند الحديث عن آثار الأمن والخصوصية، بينما يستخدم النموذج الحالي «separate sections». وصف الملاحظة بأنها blocking وحدد شرط الإغلاق. أقر الرد بالفارق وفتح PR 862، ثم قال المراجع إنه سيعد العائق محلولاً بعد الدمج.

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

اتخذت مراجعة APA شكلاً آخر. سألت عن التداخل بين plane وmesh detection، وعن جدول WebGPU واستمرار WebGL، وعن موقع CSS Spatial Layout وhaptics. أوضحت الردود الحدود وربطت PR 865. قالت APA إن الأسئلة الأولى قد أجيب عنها، ثم طرحت سؤالاً جديداً عن اتساق «detection» و«tracking» و«sensing».

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

كما أن ظهور 14 تعليقاً لا يقيس التمثيل. قد يتضمن تعليق واحد خمسة أسئلة، وقد يعمل عدة أشخاص على عبارة واحدة. الصمت قد يعني قبولاً أو امتناعاً أو عدم علم أو غياب سلطة القرار. النشاط ليس اقتراعاً.

المطلوب في Process هو التصرف في المسائل

لبدء refinement، تنشر Team المشروع وتشرح المشاركة وتعلن مدة لا تقل عن 28 يوماً وتسمي Facilitator. وتكتمل wide review أثناء المرحلة. يسعى Facilitator إلى توافق المشاركين؛ وإذا تعذر، يمكنه طلب Team Decision مع توثيق السبب.

وتلزم القاعدة المركزية بمعالجة كل issues المقدمة ضد المشروع رسمياً، وتتبع حلولها في disposition of comments يبرز المسائل التي لم تُحل بالتوافق.

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

قبل نهاية المدة، يجب على Team بدء AC Review أو التخلي عن المقترح أو تمديد refinement. ويُعلن القرار بالوضوح المطلوب، مع سبب حين لا تبدأ AC Review.

أما AC Review فهي مرحلة أخرى. تقدم كل منظمة عضو review واحدة عبر ممثلها، ويجب التعبير عن dissent في صورة Formal Objection. تعليق GitHub أثناء refinement ليس تلك المراجعة، والملاحظة السرية لا تتحول آلياً إلى اعتراض رسمي لاحق.

يمكن نشر فهرس من دون كشف القناة

يميز القسم 7.2 بين public وMember-only وTeam-only، ويلزم المخولين بحماية المواد المقيدة. نسخ الرسالة أو تسمية كاتبها أو ذكر منتج يكشف الشركة سيخرق الحد نفسه.

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

يمكن أن يرد في السجل: «فئة Member-only M-03: حد نطاق deliverable مقترح»، مع القسم وcommit والتغيير العلني وحالة disposition. ولا يذكر من تحدث أو عدد الأعضاء أو المنتج أو نصاً من القائمة.

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

ولا تثبت المصادر أن تعليقات سرية قُدمت فعلاً حول هذا الميثاق. إتاحة القناة ليست دليلاً على استخدامها. يجب ألا يخترع السجل مادة غير مرئية.

الخبرة مهمة لكنها لا تنشئ تفويضاً مطلقاً

يطلب Process مراعاة الآراء والاعتراضات المشروعة من المشاركين وغيرهم، بما في ذلك الجمهور. يستطيع خبير في accessibility أوsecurity أوprivacy أوinternationalization أوarchitecture كشف نقص حقيقي، ويستطيع منفذ إثبات أن موعداً غير واقعي.

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

في refinement، يسعى Facilitator إلى توافق المشاركين. تمارس Team القرارات المسندة إليها وتحدد المرحلة التالية. ثم يجري Advisory Committee مراجعته الرسمية، وتتبعها W3C Decision.

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

الحد الأدنى للسجل المشترك

لكل issue أو فئة آمنة، ينبغي إدراج:

  1. معرف ثابت؛
  2. نوع القناة public أوMember-only، بلا هوية أو عدد محمي؛
  3. صياغة علنية آمنة للمسألة؛
  4. القسم وcommit الدقيقان؛
  5. الدور المجيب والتاريخ؛
  6. PR أوdiff أو نص بديل أو سبب عدم التغيير؛
  7. disposition مثل مقبول، جزئي، بلا تغيير، مستبدل، مسحوب، مؤجل أو غير محلول؛
  8. حالة التوافق التي يتطلبها Process؛
  9. السلطة التالية: مزيد من refinement أوTeam Decision أوAC Review أوتمديد أوتخلٍ؛
  10. الإغلاق والاستبدال والتصحيحات.

نوع القناة ليس وزناً. لا تتفوق Member-only بطبيعتها على مراجعة فنية علنية حاسمة، ولا تعني public أنها تمثيلية. القناة تصف الحفظ، أما القرار فتحمله أسبابه وإجراءاته.

وتمنع النسخة المثبتة خلط المراحل. PR مفتوح ليس نصاً مدمجاً، والنص المدمج ليس ميثاقاً معتمداً. لا يتحقق الشرط إلا إذا وصل التغيير إلى النسخة التي تتقدم.

حدود النتيجة

في 30 أغسطس، ظل issue 564 وPR 862 وPR 865 مفتوحة، وبقيت وثيقة 2026 draft. وأظهرت صفحة المجموعة أن الميثاق الحالي يمتد حتى 25 سبتمبر.

لا يثبت ذلك مخالفة أو تأخيراً غير مشروع أو ضعفاً تقنياً. refinement هي مرحلة التعليقات والتغييرات المعلقة. وكان 7 سبتمبر تقديراً، ويجيز Process تمديداً معلناً.

رابط الدليل إلى privacy سياقي فقط؛ فهو يعبر عن حد السرية الذي تحلله المقالة، ولا يعرّف W3C أوImmersive Web Working Group أوWebXR ولا يعني تأييداً.

الاقتراح محدود: الإبقاء على البابين، واحترام قواعدهما، ونشر أقل حالة تكفي لفحص نسب ميثاق واحد.

المصادر

  1. W3C — بدء refinement لميثاق Immersive Web، 10 أغسطس 2026
  2. W3C — مشروع ميثاق Immersive Web Working Group
  3. w3c/strategy issue 564
  4. w3c/charter-drafts PR 831 — المشروع الأول لعام 2026
  5. w3c/charter-drafts PR 862 — نص coordination
  6. w3c/charter-drafts PR 865 — أوصاف المواصفات
  7. W3C Process Document، 18 أغسطس 2025
  8. W3C — Immersive Web Working Group
  9. W3C — الميثاق الحالي الصادر في سبتمبر 2024
  10. w3c/charter-drafts — سجل commits لمشروع 2026
  11. w3c/charter-drafts commit 488587ec141b — علامة DRAFT
  12. W3C — Horizontal Review
  13. Heng Lu — On the Multi-Stakeholder Mirage
  14. Heng Lu — On the Reality Layers of Internet Governance