صحافة Ctrl / Cmd + P. لطباعة
أو احفظه بصيغة PDF

قضايا جديدة

السؤال: كم عدد الأعداد الجديدة التي تم إنشاؤها خلال فترة معينة؟

نظرة عامة

تقيس Issues New عدد المشكلات الجديدة التي تم إنشاؤها خلال فترة محددة. يتم فتح (إرسال) كل من هذه التذاكر (القضايا) بواسطة شخص معين، ويتم التعليق عليها لاحقًا وشرحها بواسطة العديد من الأشخاص الآخرين. تتكون نقاط البيانات من عدد المشكلات التي تم فتحها أو إرسالها في البداية خلال فترة القياس. يمكن إعادة فتح المشكلات بعد إغلاقها. يمكن اعتبار إعادة فتح مشكلة بمثابة فتح مشكلة جديدة (انظر المعلمات أدناه). على سبيل المثال، تتوافق "القضايا" مع "القضايا" في حالة GitHub أو GitLab أو Jira، و"تقارير الأخطاء" في حالة Bugzilla، و"القضايا" أو "التذاكر" في أنظمة أخرى. يوفر تتبع المشكلات رؤى حول نشاط المشروع والمشاركة. يشير الحجم الكبير من المشكلات الجديدة إلى مجتمع نشط يناقش المشكلات ويقترح الحلول ويساهم في تطوير المشروع. تراقب Issues New مستوى المناقشة والمشاركة الجارية أيضًا. يمكن أن يوفر تحليل أنواع المشكلات التي يتم إنشاؤها رؤى حول المجالات المحتملة حيث قد تكون هناك حاجة إلى جهود DEI لمعالجة مخاوف محددة للمشاركة.

اريد معرفة المزيد؟

انقر هنا لقراءة المزيد حول هذا المقياس.

استراتيجيات جمع البيانات

وصف محدد: جيثب

في حالة GitHub، يتم تعريف المشكلة على أنها "مشكلة".

يمكن تحديد تاريخ الإصدار (لنظره في فترة أو لا) بأنه التاريخ الذي تم فيه فتح الإصدار (التقديم).

وصف محدد: GitLab

في حالة GitHub، يتم تعريف المشكلة على أنها "مشكلة".

يمكن تحديد تاريخ الإصدار (لنظره في فترة أو لا) بأنه التاريخ الذي تم فيه فتح الإصدار (التقديم).

وصف محدد: جيرا

في حالة جيرا، يتم تعريف القضية على أنها "قضية".

يمكن تحديد تاريخ الإصدار (لنظره في فترة أو لا) بأنه التاريخ الذي تم فيه فتح الإصدار (التقديم).

وصف محدد: بوغزيلا

في حالة Bugzilla، يتم تعريف المشكلة على أنها "تقرير خطأ"، طالما أنها مرتبطة بملفات التعليمات البرمجية المصدر.

يمكن تحديد تاريخ المشكلة (لنظرها في فترة ما أو لا) بالتاريخ الذي تم فيه فتح تقرير الخطأ (تقديمه).

المجمعات:

  • عدد. إجمالي عدد الإصدارات الجديدة خلال الفترة.
  • نسبة. نسبة الأعداد الجديدة إلى إجمالي عدد الأعداد خلال تلك الفترة.

المعلمات:

  • فترة من الزمن. تاريخ البدء والانتهاء للفترة التي يتم خلالها النظر في المشكلات. الافتراضي: إلى الأبد.

  • معيار الكود المصدر. الخوارزمية. الافتراضي: جميع المشكلات مرتبطة بالكود المصدر. إذا ركزنا على الكود المصدر، فنحن بحاجة إلى معيار لتحديد ما إذا كانت المشكلة مرتبطة بالكود المصدر أم لا.

  • إعادة الفتح كإصدار جديد. قيمة منطقية. افتراضي: خطأ.\ معيار لتحديد ما إذا كانت المشكلات التي أعيد فتحها تعتبر مشكلات جديدة.

فلاتر (زيت، هوا، مكيف)

  • من قبل الممثلين (مقدم ، معلق ، أقرب). يتطلب دمج الهويات المقابلة لنفس المؤلف.
  • حسب مجموعات الفاعلين (صاحب العمل ، الجنس ... لكل ممثل). يتطلب تجميع الممثلين ، وعلى الأرجح ، دمج الممثلين.

المرئيات

  • عد لكل فترة زمنية بمرور الوقت
  • النسبة لكل فترة زمنية بمرور الوقت

ويمكن تجميعها عن طريق تطبيق عوامل التصفية المحددة أعلاه. ويمكن تمثيلها كمخططات شريطية، مع مرور الوقت في المحور X. سيمثل كل شريط مقترحات لتغيير الكود خلال فترة معينة (شهر على سبيل المثال).


المساهمين

  • جورج جي بي لينك
  • داون فوستر
  • كيفن لومبارد
  • غريب سي أوميه

معلومات إضافية

لتحرير هذا المقياس، يرجى قم بتقديم طلب التغيير هنا

للإشارة إلى هذا المقياس في البرامج أو المنشورات ، يرجى استخدام عنوان URL الثابت هذا: https://chaoss.community/?p=3634

قد يؤدي استخدام المقاييس الصحية ونشرها إلى انتهاكات الخصوصية. قد تتعرض المنظمات للمخاطر. قد تتدفق هذه المخاطر من الامتثال للائحة العامة لحماية البيانات في الاتحاد الأوروبي ، أو مع قانون الولاية في الولايات المتحدة ، أو مع قوانين أخرى. قد تكون هناك أيضًا مخاطر تعاقدية ناتجة عن شروط الخدمة لموفري البيانات مثل GitHub و GitLab. يجب فحص استخدام المقاييس بحثًا عن المخاطر ومشكلات أخلاقيات البيانات المحتملة. لطفا أنظر وثيقة أخلاقيات البيانات CHAOSS للحصول على إرشادات إضافية.