الوحدة 5 · التبنّي على نطاق واسع
المساهمة والـ Governance
18 دقراءة 3 درتّب الخطوات
الدرس في لمحة
أدِر contribution model (نموذج مساهمة) بمستويات واضحة للإصلاحات والتحسينات والمكوّنات الجديدة، وفرز الطلبات بمسار قرار محدّد، وجهّز governance خفيفة تقرّر بسرعة وفي العلن.
لا فيديو هنا، بل الشيء الحقيقي: درس مكتوب وأمثلة قابلة للتشغيل واختبار وتدريب.
في أول عام فتحت فيه Northwind باب المساهمات، تلقّينا 112 pull request ودمجنا 41 منها. ومات معظم البقية وهو ينتظر: مراجعة API بلا موعد، أو مصمّمًا كان في مشروع آخر، أو قرارًا لم يشعر أحد أنه مخوّل باتخاذه. وتعلّمت الفرق الدرس سريعًا. بحلول الشهر التاسع كادت المساهمات تتوقّف، وعادت ثلاث فرق إلى مجلّدات مكوّناتها الخاصة. الـ contribution model ليس وثيقة؛ إنه وعد بمدى سرعة فريق النواة وعدله في الاستجابة.
ثلاثة مستويات للمساهمة
كان الإصلاح أن نتوقّف عن معاملة كل المساهمات بالطريقة نفسها. لدى Northwind اليوم ثلاثة مستويات، لكلٍّ منها مساره:
| المستوى | أمثلة | المسار | أول ردّ |
|---|---|---|---|
| إصلاح | خلل، خطأ في التوثيق، story ناقصة | pull request، ومراجع واحد من النواة | يوما عمل |
| تحسين | variant جديد، prop جديد، token جديد | issue باقتراح قصير، ثم pull request | أسبوع |
| مكوّن جديد | منتقي تاريخ، جدول بيانات | RFC، ثم مراجعة API، ثم البناء مع ثنائي من النواة | أسبوعان حتى القرار |
الإصلاح لا يحتاج إذنًا. والتحسين يحتاج حجّة قصيرة مكتوبة: ما المشكلة، وأيّ الفرق، ومقطع الـ API المقترح، لأن الـ props API عام إلى الأبد. أما المكوّن الجديد فيحتاج طلب تعليقات (RFC)، وهو وثيقة تعرض المشكلة، وأدلّة من فريقين على الأقل، ومسوّدة الـ API، ومصفوفة الحالات، وخطة إمكانية الوصول. ويُناقش الـ RFC في مراجعة الـ API الأسبوعية، ويخرج منها أحد ومعه قرار.
ملف CODEOWNERS يجعل التوجيه آليًا: فريق النواة يملك ملفات الـ tokens وما يُصدَّر من الـ API العام، فيطلب أي تغيير فيها مراجعة من النواة، بينما يمكن لأي مساهم متمرّس أن يوافق على صفحات التوثيق.
الفرز: أين ينتمي الطلب؟
أغلب الطلبات تنتهي عند السؤال الأول. نحو نصف طلبات «المكوّن الجديد» في Northwind يتبيّن أنها مكوّن موجود لم يجعله التوثيق سهل الإيجاد، فيصبح الطلب إصلاحًا في التوثيق.
السؤال الثاني هو حيث تتوتّر الفرق، لأن «ابنِه محليًا» تبدو رفضًا. وهي ليست كذلك. المكوّن الخاص بفريق واحد والمبني من tokens النظام ومكوّناته يبدو أصيلًا ولا يكلّف النظام شيئًا في الصيانة. تحتفظ Northwind بقائمة بهذه المكوّنات المحلية، مع مالكيها، وتراجعها كل ربع سنة. وحين يحتاج فريق ثانٍ شيئًا من القائمة، يصبح المكوّن الأصلي نقطة انطلاق لـ RFC. ثلاثة من مكوّناتنا الحالية، منها منتقي التاريخ، بدأت بهذه الطريقة.
Governance بلا بيروقراطية
الـ governance (الحوكمة) هي طريقة اتخاذ القرارات حين يختلف الناس. ونسخة Northwind منها تتّسع في صفحة واحدة:
- فريق النواة يقرّر في كل ما يصبح API عامًا، بعد الاستماع إلى الفرق المتأثّرة.
- القرارات تُتّخذ علنًا، في مراجعة الـ API الأسبوعية التي يمكن لأي أحد حضورها، أو بشكل غير متزامن في الـ RFC.
- الحجج تستند إلى المبادئ والأدلّة، مثل أرقام الاستخدام أو نتائج البحث، لا إلى المسمّيات الوظيفية.
- كل قرار يُكتب في سجلّ قرارات مع أسبابه، حتى تمكن مراجعته حين تتغيّر الأدلّة بدل إعادة الجدال فيه من الذاكرة.
السرعة مهمّة بقدر العدل. «لا» واضحة خلال أسبوعين أفضل لفريق المنتج من «ربما» لشهرين، لأنه يستطيع التخطيط حول الـ «لا».
في التمرين ترتّب مسار مكوّن جديد إلى داخل النظام. وبعدها توسّع معمارية الـ theming لتشمل علامة ثانية.
أهم النقاط
- طابِق العملية مع حجم المساهمة؛ فإصلاح خطأ إملائي ومكوّن جديد يجب ألا يمرّا من البوابة نفسها.
- يدخل المكوّن الجديد النظام حين تحتاجه عدّة فرق، لا حين يبنيه فريق واحد أولًا.
- البناء المحلي نتيجة مشروعة للفرز، ويجب أن يجعله النظام سهلًا لا مخجلًا.
- تنجح الـ governance حين تكون القرارات سريعة ومكتوبة ومبنيّة على المبادئ، لا على الأقدمية.