الخلاصة
- ينص ميثاق CPC على أن ممثلي المشروعات غير Impact وممثلي Regular Members التصويتيين سيتحولون، ابتداءً من دورة خريف 2026، إلى ما يصل إلى خمسة مقاعد Community Voting Member.
- الحضور كمراقب، وصف Regular Member، والدخول في هيئة الناخبين، وحيازة مقعد تصويتي ليست حالة واحدة. يلزم المرشح للفئة الجديدة أن يكون Regular Member وألا يكون في الوقت ذاته ممثلاً تصويتياً لمشروع Impact.
- ينبغي أن يفصل سجل الانتقال بين وضع الدورة، والمقعد السابق، والأهلية، ومقام الناخبين، والنتيجة، وقيد صاحب العمل، وصلاحيات Board وCPC والمشروعات، من دون تحويل خطة مستقبلية إلى نتيجة أو عملية داخلية إلى تفويض عام.
قاعدة معلنة للمستقبل ليست هيئة قائمة بالفعل
قد يظهر نص الحوكمة قبل أن يظهر الأثر الذي ينظمه. قد يضيف الميثاق اسماً لفئة جديدة، وقد تكون الجلسة مفتوحة للمراقبين، وقد يعرض المستودع ترتيباً مرتقباً. هذه وقائع نافعة، لكنها لا تثبت فتح باب الترشيح أو تدقيق أهلية الناخبين أو فرز الأصوات أو تولي شخص بعينه مقعداً.
يبين ميثاق OpenJS هذا الفصل بوضوح. فالـ CPC هو القيادة التقنية للمؤسسة، في حين أن Board هو قيادتها التجارية. يضع Board السياسة العامة للـ CPC، ويعمل CPC كجسم تقني مفوض داخل ذلك النطاق. ويقول النص نفسه إن مساري التصويت غير المرتبطين بمشروعات Impact سيجتمعان في فئة Community Voting Members في دورة خريف 2026.
إذن ما تدعمه المصادر هو تغيير مقرر، لا نتيجة مكتملة. لا تثبت المصادر العامة التي روجعت بدء الترشيحات أو قائمة مرشحين معتمدة أو عدد المقاعد التي ملئت أو هوية الفائزين أو تاريخ سريان النتيجة. صياغة القاعدة المستقبلية كأنها تعيين مكتمل تستبدل الدليل بالتوقع.
بعد الانتقال، ينبغي أن يستطيع المساهم فهم حالة كل مسار من دون الاعتماد على ذاكرة المشاركين. هل أنهى الممثل السابق ولايته، أم استقال، أم استُبدل، أم صار Regular Member فقط، أم ترشح للفئة الجديدة؟ كم مقعداً من الخمسة المحتملة شُغل؟ كم كان عدد Impact Project Voting Members وRegular Members المؤهلين في التاريخ المعني؟ على أي مجموع جرى اختبار حد الربع لانتماء Voting Members إلى صاحب عمل واحد؟ وهل القرار الذي يهم القارئ من اختصاص Board أو CPC أو عملية مشروع مستقلة؟
هذه ليست أسئلة اتهام. إنها حقول لازمة كي لا تُقرأ قائمة أسماء محدّثة لاحقاً بوصفها نقل سلطة بلا مصدر ظاهر.
أربع طبقات تختبئ خلف كلمة «المجتمع»
يفصل الميثاق بين Observers وRegular Members وVoting Members. يتيح مستودع CPC العلني لغير الأعضاء حضور الاجتماعات بصفة مراقبين. وتصف وثيقة الحوكمة طريق طلب صفة Regular Member لمن لديه نشاط حديث ومستمر في OpenJS. أما ناخبو Community Voting Members فهم دائرة أضيق: Impact Project Voting Members وRegular Members.
يستطيع Observer متابعة العمل العلني والمساهمة في السعي إلى التوافق. هذه مشاركة حقيقية، لكنها لا تمنحه تلقائياً حقاً انتخابياً أو مقعداً.
ولـ Regular Member صفة مؤسسية أكثر تحديداً. تشترط القواعد مساهمة حديثة ومستدامة في مشروع أو مجتمع أو مساحة تعاون أو في عمل CPC، مع إجراء مراجعة. هذه الصفة شرط للترشح وجزء من هيئة الناخبين، لكنها ليست دليلاً على الفوز بمقعد.
أما Impact Project Voting Member فيصل عبر مصدر مختلف. يجوز لكل مشروع Impact أن يسمي، وفق طريقته، شخصين كحد أقصى. تبقى هذه الفئة قائمة في الترتيب الجديد. مشاركة أعضائها في انتخاب الفئة المجتمعية لا تمحو مصدر مقاعدهم هم.
وCommunity Voting Member فئة تصويت محددة للدورة المقبلة لا يزيد عدد مقاعدها على خمسة. يجب أن يكون المرشح Regular Member وألا يمثل مشروع Impact تصويتياً. لذلك قد تخفي عبارة «المجتمع اختار» أربع دعاوى مختلفة: من حضر، ومن صار Regular Member، ومن كان ناخباً، ومن حصل فعلاً على مقعد. يحدد الميثاق الفروق الأولى؛ وعلي سجل الانتخاب أن يثبت البقية.
هنا تنفع قاعدة لو هنغ في تمييز المشاركة من السلطة. فالمشاركة قد تقدم معرفة وإنذاراً واعتراضاً، لكنها لا تنشئ وحدها تفويض الأصل عن كل من يتأثر بالقرار. اجتماع CPC المفتوح أو انتخاب داخلي دليل على عملية محددة داخل المؤسسة، لا دليل تمثيل مفوض للبيئة الكاملة للـ JavaScript.
المقعد الجديد لا يبتلع السلطات الأخرى
لا يعيد تغيير فئة التصويت توزيع كل السلطات المحيطة بـ CPC. يتحمل Voting Members المسؤوليات النهائية التي يسندها الميثاق إلى CPC. ويسعى CPC إلى lazy consensus ويستعمل مسار تصويت محدداً عندما لا تُحل الاعتراضات. يحتفظ Board بالسياسة العامة والصلاحيات القانونية خصوصاً ودوره في اعتماد تعديل الميثاق. وتبقى المشروعات ذاتية الحوكمة في عملياتها التقنية الموثقة ضمن إرشادات CPC.
هناك وصلات بين هذه الطبقات، لكنها ليست هوية واحدة. قد يمثل CPC Director المشروعات والمجتمعات المتصلة أمام Board. وقد يحتاج تغيير ميثاق مشروع إلى موافقة CPC. وقد يصعد موضوع تقني إلى Board. لكن Community Voting Member لا يصبح لهذا السبب Board Director أو ممثل كل القائمين على الصيانة أو صاحب القرار الداخلي في مشروع. يجب أن يسمي السجل الصفة المطبقة فعلاً.
توجد أصلاً أسطح متعددة للسجل: issue علني عند بداية الترشيح، وpull request لتحديث README بعد الانتخاب، وإشعار نتيجة في قائمة خاصة، وجدول أعمال ومواد اجتماعات. كما توجد حدود مشروعة للخصوصية في المسائل الشخصية والقانونية وبعض معلومات Board. لا تعني الشفافية نشر كل ملف خاص؛ بل تعني إمكان وصل الوقائع العلنية الحاسمة.
فالاسم الجديد في README وحده لا يحدد انتهاء المقعد السابق أو المدة أو مقام الناخبين. وتنص الحوكمة على أن Voting Member الذي انتهت ولايته يصير عادة Regular Member ما لم يذكر غير ذلك. هذه حالة افتراضية مفيدة، وليست إيصال خروج فردي. وكذلك عبارة «حتى خمسة» لا تخبرنا كم مقعداً امتلأ. ولا يمكن إعادة اختبار حد الربع لصاحب العمل من دون عدد إجمالي مؤرخ ومعيار للانتماء.
سجل انتقال Community Voting Members
يقترح Daniel Kade سجل انتقال Community Voting Members مختصراً. لا يغير الميثاق ولا يطلب نشر مواد المرشحين الخاصة. وظيفته جمع الوقائع التي ستبقى، بغير ذلك، موزعة بين issues وجداول الأعمال والقوائم وتحديثات المستودع.
أول حقل هو حالة الدورة: انتقال مخطط، ترشيحات مفتوحة، تصويت جار، نتيجة مصدقة أو تصحيح. عليه أن يصل إلى نص الميثاق الحاكم ويسمي الفئتين القديمة والجديدة، حتى لا تبدو قاعدة مستقبلية كأنها تعيين منجز.
ثاني الحقول هو خريطة المقاعد. لكل مسار قديم متأثر، تسجل مصدر المقعد، والشاغل إذا كان معلناً، ونهاية الولاية العادية، وحالة الخروج: مكتملة، استقالة، استبدال، عودة إلى Regular Member فقط، ترشح للفئة الجديدة، أو غير معلن. وللمقاعد الجديدة تسجل ما إذا كان كل واحد من الخمسة الممكنة مشغولاً أو شاغراً أو غير محدد علناً. لا ينبغي تحويل غياب الاسم إلى إثبات شغور تلقائي.
ثالثاً، يسجل قسم الأهلية والناخبين شرط الترشح وفئتي الناخبين المنصوص عليهما، مع عدد مؤرخ أو طريقة تدقيق محتفظ بها. لا حاجة إلى كشف سبب الأهلية الخاص بكل فرد، لكن يجب أن يكون مقام النتيجة مفهوماً.
رابعاً، يصل قسم الإجراء والنتيجة بين issue الترشيح وطريقة الانتخاب الفعلية إذا نشرت وإشعار النتيجة وpull request الخاص بـ README وتاريخ السريان وقائمة Voting Members الناتجة. يذكر الميثاق أساليب ممكنة مثل Condorcet وSingle Transferable Vote؛ ولا يبرر ذلك افتراض أي منها لدورة بعينها.
خامساً، تأتي مراجعة التركيب: العدد الكلي لـ Voting Members في يوم السريان، وأساس الانتماء لصاحب العمل إذا كان عاماً، وسقف الربع، والحالة: مستوفى أو صُحح أو معلق أو غير منشور. فحص شرط من شروط الميثاق ليس اتهاماً بتعارض مصالح.
وأخيراً، تضع حدود الصلاحية وسجل التصحيحات روابط منفصلة لـ Board وCPC وCPC Directors واستقلال المشروع، وتذكر ما لا تثبته المصادر العلنية: سبب أهلية خاص أو عدد أصوات غير منشور أو استقالة لاحقة أو قرار Board. يصبح التصحيح إضافة مؤرخة لا استبدالاً صامتاً للقائمة.
الحوكمة المفتوحة لا تعني أن كل مشارك يملك كل الصلاحيات. معناها أن لكل صلاحية فعلية مصدراً ونطاقاً ونهاية مرئية. يمنح انتقال الخريف OpenJS فرصة لتسجيل هذا الفرق حين يصبح مهماً.
المصادر
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
