{"id":"l-ds-5-1","courseId":"design-systems","lang":"ar","kind":"lesson","summary":"أدِر contribution model (نموذج مساهمة) بمستويات واضحة للإصلاحات والتحسينات والمكوّنات الجديدة، وفرز الطلبات بمسار قرار محدّد، وجهّز governance خفيفة تقرّر بسرعة وفي العلن.","html":"

في أول عام فتحت فيه Northwind باب المساهمات، تلقّينا 112 pull request ودمجنا 41 منها. ومات معظم البقية وهو ينتظر: مراجعة API بلا موعد، أو مصمّمًا كان في مشروع آخر، أو قرارًا لم يشعر أحد أنه مخوّل باتخاذه. وتعلّمت الفرق الدرس سريعًا. بحلول الشهر التاسع كادت المساهمات تتوقّف، وعادت ثلاث فرق إلى مجلّدات مكوّناتها الخاصة. الـ contribution model ليس وثيقة؛ إنه وعد بمدى سرعة فريق النواة وعدله في الاستجابة.

\n

ثلاثة مستويات للمساهمة

\n

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

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
المستوىأمثلةالمسارأول ردّ
إصلاحخلل، خطأ في التوثيق، story ناقصةpull request، ومراجع واحد من النواةيوما عمل
تحسينvariant جديد، prop جديد، token جديدissue باقتراح قصير، ثم pull requestأسبوع
مكوّن جديدمنتقي تاريخ، جدول بياناتRFC، ثم مراجعة API، ثم البناء مع ثنائي من النواةأسبوعان حتى القرار

الإصلاح لا يحتاج إذنًا. والتحسين يحتاج حجّة قصيرة مكتوبة: ما المشكلة، وأيّ الفرق، ومقطع الـ API المقترح، لأن الـ props API عام إلى الأبد. أما المكوّن الجديد فيحتاج طلب تعليقات (RFC)، وهو وثيقة تعرض المشكلة، وأدلّة من فريقين على الأقل، ومسوّدة الـ API، ومصفوفة الحالات، وخطة إمكانية الوصول. ويُناقش الـ RFC في مراجعة الـ API الأسبوعية، ويخرج منها أحد ومعه قرار.

\n

ملف CODEOWNERS يجعل التوجيه آليًا: فريق النواة يملك ملفات الـ tokens وما يُصدَّر من الـ API العام، فيطلب أي تغيير فيها مراجعة من النواة، بينما يمكن لأي مساهم متمرّس أن يوافق على صفحات التوثيق.

\n

الفرز: أين ينتمي الطلب؟

\n
\n مسار قرار. هل يستطيع مكوّن موجود أن يؤدّي المهمّة، ربما مع توثيق أفضل؟ إن كانت الإجابة نعم، أشِر إليه. وإن كانت لا، فهل يحتاجه فريقان أو أكثر؟ إن كانت لا، ابنِه محليًا من قطع النظام. وإن كانت نعم، ساهم به في النظام مع ثنائي من النواة.\n \n طلب\n \n هل يغطّيه مكوّن\n موجود؟\n \n أشِر إليه وأصلح التوثيق\n \n هل يحتاجه فريقان\n أو أكثر؟\n \n ابنِه محليًا\n \n RFC\n ثم ساهم\n \n \n نعم\n \n لا\n \n لا\n \n نعم\n
كيف تفرز Northwind طلب مكوّن جديد
\n

أغلب الطلبات تنتهي عند السؤال الأول. نحو نصف طلبات «المكوّن الجديد» في Northwind يتبيّن أنها مكوّن موجود لم يجعله التوثيق سهل الإيجاد، فيصبح الطلب إصلاحًا في التوثيق.

\n

السؤال الثاني هو حيث تتوتّر الفرق، لأن «ابنِه محليًا» تبدو رفضًا. وهي ليست كذلك. المكوّن الخاص بفريق واحد والمبني من tokens النظام ومكوّناته يبدو أصيلًا ولا يكلّف النظام شيئًا في الصيانة. تحتفظ Northwind بقائمة بهذه المكوّنات المحلية، مع مالكيها، وتراجعها كل ربع سنة. وحين يحتاج فريق ثانٍ شيئًا من القائمة، يصبح المكوّن الأصلي نقطة انطلاق لـ RFC. ثلاثة من مكوّناتنا الحالية، منها منتقي التاريخ، بدأت بهذه الطريقة.

\n\n

Governance بلا بيروقراطية

\n

الـ governance (الحوكمة) هي طريقة اتخاذ القرارات حين يختلف الناس. ونسخة Northwind منها تتّسع في صفحة واحدة:

\n\n

السرعة مهمّة بقدر العدل. «لا» واضحة خلال أسبوعين أفضل لفريق المنتج من «ربما» لشهرين، لأنه يستطيع التخطيط حول الـ «لا».

\n\n

في التمرين ترتّب مسار مكوّن جديد إلى داخل النظام. وبعدها توسّع معمارية الـ theming لتشمل علامة ثانية.

\n","toc":[{"id":"sec-1","text":"ثلاثة مستويات للمساهمة","level":2},{"id":"sec-2","text":"الفرز: أين ينتمي الطلب؟","level":2},{"id":"sec-3","text":"Governance بلا بيروقراطية","level":2}],"takeaways":["طابِق العملية مع حجم المساهمة؛ فإصلاح خطأ إملائي ومكوّن جديد يجب ألا يمرّا من البوابة نفسها.","يدخل المكوّن الجديد النظام حين تحتاجه عدّة فرق، لا حين يبنيه فريق واحد أولًا.","البناء المحلي نتيجة مشروعة للفرز، ويجب أن يجعله النظام سهلًا لا مخجلًا.","تنجح الـ governance حين تكون القرارات سريعة ومكتوبة ومبنيّة على المبادئ، لا على الأقدمية."],"further":[{"title":"Contributing guidelines for a repository (GitHub Docs)","url":"https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors"},{"title":"About code owners (GitHub Docs)","url":"https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners"},{"title":"Contribute to the U.S. Web Design System","url":"https://designsystem.digital.gov/about/contribute/"}],"quiz":[{"q":"

يصلح فريق خطأً إملائيًا في توثيق Tabs ويفتح pull request. دليل المساهمة يشترط RFC ومراجعة API لكل تغيير. ما النتيجة المرجّحة مع الوقت؟

","options":[{"text":"جودة أعلى، لأن كل تغيير يُراجَع بدقّة.","why":"المراجعة الثقيلة على التغييرات التافهة لا تضيف جودة؛ إنها تضيف تأخيرًا في الغالب."},{"text":"تتوقّف الفرق عن المساهمة بالإصلاحات الصغيرة وتلتفّ على المشكلات محليًا بدلًا من ذلك.","why":"صحيح. حين تتجاوز تكلفة المساهمة تكلفة الحلّ المحلي، يختار الناس الحلّ المحلي."},{"text":"يحصل فريق النواة على وقت أكثر للعمل المهمّ.","why":"يصرف فريق النواة ذلك الوقت في إدارة العملية الثقيلة نفسها."},{"text":"لا شيء يتغيّر؛ الفرق تتقبّل العمليات كجزء من العمل.","why":"الناس يستجيبون للاحتكاك؛ وتكلفة العملية تظهر دائمًا في السلوك."}],"answer":1},{"q":"

يطلب فريق الفوترة أن يضيف النظام مكوّنًا باسم InvoiceTimeline. ولا يوجد فريق آخر لديه حاجة مشابهة. بماذا يوصي الفرز في Northwind؟

","options":[{"text":"إضافته إلى النظام، لأن المساهمة قدرة مجانية.","why":"كل مكوّن في النظام تكلفة صيانة طويلة الأمد يدفعها فريق النواة، حتى لو كتبه شخص آخر."},{"text":"رفضه وإخبار الفريق أن ينتظر حتى يحتاجه فريق آخر.","why":"فريق الفوترة يحتاجه الآن؛ والانتظار لا يفيد أحدًا."},{"text":"الطلب من فريق النواة أن يبنيه كأولوية.","why":"صرف قدرة النواة على مكوّن لفريق واحد يسحبها من الاحتياجات المشتركة."},{"text":"بناؤه محليًا من tokens النظام ومكوّناته، وإعادة النظر فيه إن احتاجت فرق أخرى شيئًا مشابهًا.","why":"صحيح. يتحرّر الفريق من التعطيل، وتبدو النتيجة أصيلة في النظام، ويتعلّم النظام هل الحاجة مشتركة."}],"answer":3},{"q":"

يختلف مصمّمان كبيران حول هل يجب أن يسمح Select بإدخال نص حرّ. أيّ نهج للـ governance يحسم ذلك على أفضل وجه؟

","options":[{"text":"طرحه في مراجعة الـ API الأسبوعية، والنقاش بالاستناد إلى المبادئ وأدلّة الاستخدام، وتسجيل القرار وأسبابه.","why":"صحيح. القرارات المتّخذة علنًا والمكتوبة يمكن مراجعتها بأدلّة جديدة بدل إعادة الجدال فيها من الصفر."},{"text":"ترك القرار للمصمّم الأقدم.","why":"الأقدمية تحسم الجدال اليوم وتعلّم الجميع أن الأدلّة لا تهمّ."},{"text":"إطلاق السلوكين خلف prop منطقي.","why":"تجنّب القرار ينقله إلى كل فريق منتج، ويضيف prop يتفاعل مع كل prop آخر."}],"answer":0}],"exercise":{"kind":"order","items":["search","evidence","rfc","review","build","release"],"title":"أدخِل منتقي التاريخ إلى النظام","prompt":"

بنى فريق الـ dispatch منتقيًا جيدًا لنطاق التواريخ محليًا. والآن يريد فريقا الفوترة والتقارير واحدًا مثله. رتّب الخطوات التي تُدخله إلى Northwind UI، متّبعًا الـ contribution model من الدرس.

\n","hints":["يبدأ الفرز بالتحقّق مما إذا كانت الحاجة مغطّاة أصلًا.","الـ RFC يحتاج أدلّة قبل أن يراجعه أحد، والمراجعة تسبق بناء نسخة النظام."],"explanation":"

يتأكّد الفرز أولًا من أن أي مكوّن موجود لا يغطّي الحاجة، ثم يجمع الأدلّة على أن عدّة فرق تتشاركها، وهذا ما ينقل المكوّن من المحلي إلى النظام. ويحوّل الـ RFC هذه الأدلّة إلى مسوّدة API ومصفوفة حالات وخطة لإمكانية الوصول، وتنتج مراجعة الـ API العلنية قرارًا مسجّلًا. وعندها فقط يبني فريق الـ dispatch نسخة النظام مع ثنائي من النواة، وتُطلَق كأي تغيير آخر: stories وتوثيق وchangeset ونسبة الفضل للمساهمين في ملاحظات الإصدار.

\n","checkLabels":{},"itemText":{"search":"التأكّد من أن أي مكوّن موجود، أو توثيقًا أفضل لأحدها، لا يغطّي اختيار النطاقات أصلًا","evidence":"جمع حالات الاستخدام من فرق الـ dispatch والفوترة والتقارير","rfc":"كتابة RFC فيه مسوّدة الـ API ومصفوفة الحالات وخطة إمكانية الوصول","review":"مناقشته في مراجعة الـ API الأسبوعية وتسجيل القرار وأسبابه","build":"إعادة بناء المنتقي في مستودع النظام بالعمل الثنائي مع مصمّم ومهندس من النواة","release":"إطلاقه مع stories وتوثيق وchangeset، ونسبة الفضل لفريق الـ dispatch في ملاحظات الإصدار"}},"words":558,"readMinutes":3}