قضايا جديدة
السؤال: كم عدد الأعداد الجديدة التي تم إنشاؤها خلال فترة معينة؟
نظرة عامة
تقيس المشكلات الجديدة عدد المشكلات الجديدة التي تم إنشاؤها خلال فترة زمنية محددة. يتم فتح (إرسال) كل من هذه التذاكر (المشكلات) بواسطة شخص معين، ثم يتم التعليق عليها وشرحها لاحقًا بواسطة العديد من الأشخاص الآخرين. اعتمادًا على نظام المشكلات الذي يتم النظر فيه، يمكن أن تمر المشكلة بعدة حالات (على سبيل المثال، "مصنفة"، "تعمل"، "مُصلحة"، "لن يتم إصلاحها")، أو يتم وضع علامة عليها بوسم واحد أو أكثر، أو يتم تعيينها لشخص واحد أو أكثر. ولكن في أي نظام لتتبع المشكلات، تكون المشكلة عادةً عبارة عن مجموعة من التعليقات وتغييرات الحالة، ربما مع تعليقات توضيحية أخرى. يمكن أيضًا ربط المشكلات، في بعض الأنظمة، بإنجازات أو فروع أو ملاحم أو قصص. في بعض الحالات، تكون بعض هذه المشكلات أيضًا مشكلات بحد ذاتها. تتكون نقاط البيانات من عدد المشكلات التي تم فتحها أو تقديمها في البداية خلال فترة القياس. يمكن إعادة فتح المشكلات بعد إغلاقها. يمكن اعتبار إعادة فتح مشكلة بمثابة فتح مشكلة جديدة (انظر المعلمات أدناه). على سبيل المثال، تتوافق "القضايا" مع "القضايا" في حالة GitHub أو GitLab أو Jira، و"تقارير الأخطاء" في حالة Bugzilla، و"القضايا" أو "التذاكر" في أنظمة أخرى. يوفر تتبع القضايا رؤى حول نشاط المشروع والمشاركة. يشير الحجم الكبير من القضايا الجديدة إلى مجتمع نشط يناقش المشاكل ويقترح الحلول ويساهم في تطوير المشروع. تراقب القضايا الجديدة أيضًا مستوى المناقشة والمشاركة الجارية. يمكن أن يوفر تحليل أنواع القضايا التي يتم إنشاؤها رؤى حول المجالات المحتملة حيث قد تكون هناك حاجة إلى جهود DEI لمعالجة مخاوف محددة للمشاركة.
اريد معرفة المزيد؟
انقر هنا لقراءة المزيد حول هذا المقياس.
استراتيجيات جمع البيانات
وصف محدد: جيثب
في حالة GitHub، يتم تعريف المشكلة على أنها "مشكلة".
يمكن تحديد تاريخ الإصدار (لنظره في فترة أو لا) بأنه التاريخ الذي تم فيه فتح الإصدار (التقديم).
وصف محدد: GitLab
في حالة GitHub، يتم تعريف المشكلة على أنها "مشكلة".
يمكن تحديد تاريخ الإصدار (لنظره في فترة أو لا) بأنه التاريخ الذي تم فيه فتح الإصدار (التقديم).
وصف محدد: جيرا
في حالة جيرا، يتم تعريف القضية على أنها "قضية".
يمكن تحديد تاريخ الإصدار (لنظره في فترة أو لا) بأنه التاريخ الذي تم فيه فتح الإصدار (التقديم).
وصف محدد: بوغزيلا
في حالة Bugzilla، يتم تعريف المشكلة على أنها "تقرير خطأ"، طالما أنها مرتبطة بملفات التعليمات البرمجية المصدر.
يمكن تحديد تاريخ المشكلة (لنظرها في فترة ما أو لا) بالتاريخ الذي تم فيه فتح تقرير الخطأ (تقديمه).
المجمعات:
- عدد. إجمالي عدد الإصدارات الجديدة خلال الفترة.
- نسبة. نسبة الأعداد الجديدة إلى إجمالي عدد الأعداد خلال تلك الفترة.
المعلمات:
-
فترة من الزمن. تاريخ البدء والانتهاء للفترة التي يتم خلالها النظر في المشكلات. الافتراضي: إلى الأبد.
-
معيار الكود المصدر. الخوارزمية. الافتراضي: جميع المشكلات مرتبطة بالكود المصدر. إذا ركزنا على الكود المصدر، فنحن بحاجة إلى معيار لتحديد ما إذا كانت المشكلة مرتبطة بالكود المصدر أم لا.
- إعادة الفتح كإصدار جديد. قيمة منطقية. افتراضي: خطأ.\ معيار لتحديد ما إذا كانت المشكلات التي أعيد فتحها تعتبر مشكلات جديدة.
فلاتر
- من قبل الممثلين (مقدم ، معلق ، أقرب). يتطلب دمج الهويات المقابلة لنفس المؤلف.
- حسب مجموعات الفاعلين (صاحب العمل ، الجنس ... لكل ممثل). يتطلب تجميع الممثلين ، وعلى الأرجح ، دمج الممثلين.
المرئيات
- عد لكل فترة زمنية بمرور الوقت
- النسبة لكل فترة زمنية بمرور الوقت
ويمكن تجميعها عن طريق تطبيق عوامل التصفية المحددة أعلاه. ويمكن تمثيلها كمخططات شريطية، مع مرور الوقت في المحور X. سيمثل كل شريط مقترحات لتغيير الكود خلال فترة معينة (شهر على سبيل المثال).
المساهمين
- جورج جي بي لينك
- داون فوستر
- كيفن لومبارد
- غريب سي أوميه
معلومات اضافية
لتحرير هذا المقياس، يرجى قم بتقديم طلب التغيير هنا
للإشارة إلى هذا المقياس في البرامج أو المنشورات ، يرجى استخدام عنوان URL الثابت هذا: https://chaoss.community/?p=3587
قد يؤدي استخدام المقاييس الصحية ونشرها إلى انتهاكات الخصوصية. قد تتعرض المنظمات للمخاطر. قد تتدفق هذه المخاطر من الامتثال للائحة العامة لحماية البيانات في الاتحاد الأوروبي ، أو مع قانون الولاية في الولايات المتحدة ، أو مع قوانين أخرى. قد تكون هناك أيضًا مخاطر تعاقدية ناتجة عن شروط الخدمة لموفري البيانات مثل GitHub و GitLab. يجب فحص استخدام المقاييس بحثًا عن المخاطر ومشكلات أخلاقيات البيانات المحتملة. لطفا أنظر وثيقة أخلاقيات البيانات CHAOSS للحصول على إرشادات إضافية.