نموذج مقاييس صحة المشروع المبدئي
لماذا يهم
قد يكون قياس صحة المشروع مفتوح المصدر أمرًا صعبًا نظرًا لوجود العديد من المقاييس التي يمكن استخدامها. ونتيجة لذلك، غالبًا ما يواجه الأشخاص صعوبة في البدء بقياس صحة المشروع بطريقة تسمح لهم باستخلاص استنتاجات ذات معنى دون أن يصبحوا مرهقين. يعد قياس الجوانب الرئيسية لسلامة المشروع خطوة أولى مهمة نحو فهم كيفية تحسين مشروع مفتوح المصدر وتحديد مكان تركيز جهود التحسين. من المهم ملاحظة أنه ليس كل مقياس مناسبًا لكل مشروع كما هو موضح بمزيد من التفاصيل في قسم رؤى البيانات أدناه.
تم تصميم نموذج المقاييس هذا لمساعدة الأشخاص على البدء بأربعة مقاييس رئيسية لسلامة المشروع يمكنهم التوسع فيها وتخصيصها لتلبية احتياجاتهم الفريدة لاحقًا.
قصص المستخدم
- باعتباري OSPO، أريد مساعدة المساهمين مفتوحي المصدر لدينا على تحسين صحة المشاريع مفتوحة المصدر المدفوعة من داخل مؤسستنا.
- كمساهم، أريد أن أعرف أين يمكنني تركيز جهودي للمساعدة في جعل المشروع أكثر صحة ونجاحًا.
المقاييس في نموذج المقاييس
- حان وقت الاستجابة الأولى حدد مقدار الوقت بين وقت فتح النشاط (مثل إصدار أو طلب تغيير) ووقت تلقيه أول استجابة من أحد الأشخاص.
-
تغيير نسبة إغلاق الطلب قم بقياس النسبة بين إجمالي عدد طلبات التغيير المفتوحة خلال فترة زمنية مقابل إجمالي عدد طلبات التغيير المغلقة في نفس الفترة.
-
عامل غياب المساهم تحديد أصغر عدد من الأشخاص الذين يقدمون 50% من المساهمات
- تردد الإصدار تحديد تكرار إصدارات المشروع (بما في ذلك إصدارات النقاط مع إصلاحات الأخطاء)
رؤى البيانات
خلفية السياق الذي تم التحقيق فيه
يمتلك برنامج VMware العديد من مستودعات المشاريع مفتوحة المصدر المنتشرة عبر بضع عشرات من مؤسسات GitHub المنفصلة، لذلك كان وجود نهج قابل للتطوير لقياس صحة المشروع أمرًا مهمًا حقًا. كان OSPO الخاص بنا بحاجة إلى مقاييس بسيطة بما يكفي بحيث يمكن لأي شخص داخل المؤسسة استخدامها بسهولة لاتخاذ قرارات بشأن المكان الذي يعمل فيه المشروع بشكل جيد وما يمكن تحسينه دون الحاجة إلى أي تدريب.
لقد اخترنا أربعة قياسات أساسية يمكن استخدامها كوسيلة لـ OSPO لتقييم صحة المشروع بسرعة على مستوى أساسي للغاية. نحن نرى هذه المقاييس كنقطة انطلاق للمشاريع مع توقع أن تقوم المشاريع الفردية بتطوير مقاييس إضافية لفهم الجوانب الأخرى لسلامة المشروع بشكل أفضل والتي تعتبر مهمة بالنسبة لاحتياجاتهم الخاصة.
رؤى مستمدة من نموذج المقاييس
عند النظر إلى صحة المشروع، من المهم أن تتذكر أن كل مشروع يختلف قليلاً، لذا من المهم تفسير المقاييس في ضوء احتياجات المشروع. نظرًا لاختلاف كل مشروع، فإننا لا نقارن المشاريع ببعضها البعض، ولكن بدلاً من ذلك، نتوقع من الفرق استخدام مقاييسها لإجراء تحسينات وتصبح في أفضل حالاتها قدر الإمكان. على هذا النحو، تكون الرؤى المرسومة على مستوى كل مشروع مع الرؤى الواردة أدناه كأمثلة من المشاريع الفردية.
حتى عند التحقيق في مشروع ما، قد تعمل المستودعات المختلفة بشكل مختلف قليلاً. على سبيل المثال، قد تعمل المستودعات التي تحتفظ بمستندات إدارة المشروع بشكل مختلف عن المستودعات التي تحتفظ بمكونات البرامج.
من المهم أيضًا أن تضع في اعتبارك أن التشغيل الآلي ونشاط الروبوت يمكن أن يؤثر على فائدة العديد من المقاييس في هذا النموذج، ولا سيما وقت الاستجابة الأولى ونسبة إغلاق طلب التغيير. لا تنطبق هذه المقاييس إلا عندما تكون هذه الأنشطة مدفوعة بشكل أساسي بالبشر، وليس الاستجابات الآلية. وبالمثل، يعتمد مقياس تكرار الإصدار على ما إذا كان يتم نشر الإصدارات وكيفية نشرها، نظرًا لأن مستودعات المعلومات قد لا تحتوي على أي إصدارات على الإطلاق، وقد تقوم بعض المشاريع بإصدار إصدارات في أماكن مختلفة (على سبيل المثال، GitHub، PyPI).
رؤى محددة للمقاييس مستمدة من نموذج المقاييس
عامل غياب المساهم
في هذا المثال، يكون عامل غياب المساهم هو 5، نظرًا لأنه أصغر عدد من الأشخاص داخل المجتمع الذين يشكلون 50% من الالتزامات، وبالتالي من المرجح أن يستمر هذا المشروع مع الحد الأدنى من الانقطاع إذا غادر شخصان المشروع فجأة.
حان وقت الاستجابة الأولى
يمكن أن يشعر المساهمون بالإحباط عندما لا يتلقون ردًا في الوقت المناسب على المساهمة. إن إرشاداتنا الداخلية للمشاريع هي أن كل علاقات عامة يجب أن تتلقى ردًا من أحد الأشخاص خلال يومي عمل، وبالتالي فإن السطر العلوي هو إجمالي عدد العلاقات العامة والخط الأخضر المنقط أدناه يوضح العلاقات العامة التي تم الرد عليها خلال يومي عمل. ما أبحث عنه هنا هو أن هذه الخطوط يجب أن تكون قريبة من بعضها البعض قدر الإمكان دون أي فجوات كبيرة. يمكنك أن ترى في هذه الحالة أنه كان هناك القليل من الفجوة، ولكن يمكنك أيضًا أن ترى أين قاموا في منتصف الطريق خلال هذا الوقت بتحسين وقت الاستجابة الأولى، لذلك من المهم ليس فقط النظر إلى الأرقام، ولكن أيضًا إلى اتجاهات.
تغيير نسبة إغلاق الطلب
من المهم مواكبة العلاقات العامة وحلها في الوقت المناسب حتى يتمكن المساهمون من الحصول على قرار في الوقت المناسب بشأن مساهماتهم. تعرض هذه الشريحة نفس الخط الأسود لطلبات السحب الإجمالية بينما يعرض الخط الأخضر المنقط طلبات السحب المغلقة، لذا فهي إما مدمجة أو مغلقة بدون دمج. في هذه الحالة، يقوم المشروع باستمرار بعمل جيد في إغلاق العلاقات العامة دون التخلف عن الركب.
تردد الإصدار
من المهم جدًا أن يتم إصدار التحديثات الأمنية وإصلاحات الأخطاء والميزات الجديدة في الوقت المناسب. عند النظر إلى إيقاع الإصدار، من المهم ألا يقتصر الأمر على تضمين الإصدارات الكبيرة فحسب، بل أيضًا جميع الإصدارات الصغيرة، نظرًا لأن الإصلاحات الأمنية العاجلة يتم إصدارها عادةً خارج الإصدارات الرئيسية. في هذا المثال، من المحتمل أن تكون الفترة المنتصف التي استغرقها المشروع حوالي 3 أشهر دون إصدار مشكلة إذا كانت هناك أية مخاوف أمنية، لكن بقية العام تبدو جيدة جدًا. ضع في اعتبارك أن تفسير هذا المقياس قد يكون أمرًا صعبًا نظرًا لأن الأنواع المختلفة من المشاريع والمواقف المختلفة يمكن أن تؤثر على ما إذا كان المشروع يحتاج إلى إيقاع إصدار أكثر تكرارًا أو أقل تكرارًا. وجود تردد إصدار ثابت يمكن أن يشير إلى مشروع أكثر استقرارًا أو نضجًا.
مراجع حسابات
المساهمين
- داون فوستر
- يهوي وانغ
- كيفن لومبارد
- شون جوجينز
- مات جيرمونبريز
- فينود أهوجا
- إليزابيث بارون
- صوفيا فارغاس
للإشارة إلى هذا المقياس في البرامج أو المنشورات ، يرجى استخدام عنوان URL الثابت هذا: https://chaoss.community/?p=4769