Jump to content

إدارة البلاغات عن الأعطال البرمجية/دورة حياة البلاغات عن الأعطال البرمجية

From mediawiki.org
This page is a translated version of the page Bug management/Bug report life cycle and the translation is 100% complete.

هذه الصفحة تصف حياة المهمة (تقرير الأخطاء، طلبات الميزات، إلخ) في فبريكاتور .

  • عند إنشاء مهمة لأول مرة، يتم تعيين الحالة Open لها.
  • عندما يتم العمل على المهمة بشكل فعّال، يمكن تعيين الحالة In Progress لها.
  • عندما يخطط مطوّر محدد للعمل على مهمة أو يعمل عليها بالفعل، فمن الأفضل تعيين هذا المطوّر كمسؤول (assignee) عن المهمة.
  • إذا تم إرسال تصحيح أولية لمهمة ما إلى أداة مراجعة الشيفرة جيريت، فسيُضاف المشروع Patch-For-Review تلقائيًا إلى المهمة. (انظر Gerrit/Commit message guidelines .)
  • إغلاق مهمة:
    • تُعطى المهمة الحالة Resolved عندما يتم دمج تغيير في الشيفرة يُصلح المهمة في جيريت. هذا لا يعني أن الإصلاح متاح فورًا على أحد مواقع ويكيميديا، إذ قد يستغرق الأمر ما يصل إلى أسبوعين.
    • تُعطى المهمة الحالة Declined عندما يتعذر إعادة إنتاج المشكلة، أو عند عدم توفير المعلومات المطلوبة، أو عندما يتوفر حل بديل مقبول يحقق نتيجة مشابهة للمطلوب. تُعيَّن هذه الحالة أيضًا عندما يوجد توافق على أن تنفيذ مهمة معينة سيكون فكرة غير جيدة. على سبيل المثال، عندما تتعارض مهمة ما مع نطاق مشروع معيّن أو مع مبادئه، بحيث يُمنع اعتماد إصلاحها من قِبل القائمين على صيانة المشروع (أو مديري المنتج، إن وُجدوا). وبحسب التفاصيل، قد تكون تفضيلات المستخدم، أو متغيّر إعداد عام، أو إعادة تنفيذ، أو تفرع الشيفرة (fork) بدائل عن وسم المهمة على أنها مرفوضة.
    • تُعطى المهمة الحالة Invalid عندما لا تصف سلوكًا خاطئًا فعليًا، أو عندما تكون التغييرات المطلوبة خارج نطاق صلاحيات مطوّري المكوّن. على سبيل المثال، تُعدّ المهام التي تقترح تغييرات على برمجيات طرف ثالث أو إعدادات مواقع طرف ثالث INVALID، وكذلك الطلبات التي تتعارض مع الالتزامات القانونية أو التعاقدية.
    • تُعطى المهمة الحالة Duplicate عندما تكون قد أُبلغ عنها سابقًا وتم دمجها في مهمة أخرى، سواء كانت تلك المهمة قد حُلّت بالفعل أم لا.
    • يمكن اختياريًا تعيين الوسم Verified إذا أكّد مختبِر ضمان الجودة (QA) أو صاحب المهمة إصلاحها بعد دمجه في جيريت وذلك بعد أن تم نشره.
  • إذا تم وسم مهمة ما على أنها Resolved ثم تبيّن أن ذلك كان غير صحيح، يمكن إعادة حالة المهمة إلى Open.
  • إذا كانت المهمة بانتظار مدخلات إضافية (مثلًا من مُنشئ المهمة أو من طرف ثالث مثل upstream) ولا يمكن العمل عليها حاليًا، تُمنح مؤقتًا الحالة Stalled. يمكن أيضًا تعيين الحالة Stalled عندما تكون المهمة بانتظار حلّ مهامها الفرعية أولًا.

إكمال المهام

تُنجز الفرق المختلفة العمل على المهام بطرق مختلفة، انظر Phabricator/Project management . تنقل بعض الفرق المهمة إلى عمود Done في لوحة عمل المشروع بعد أن يراجع فريق ضمان الجودة (QA) وإدارة المنتج التغيير، ولا تغيّر حالة المهمة إلى Resolved إلا عند إكمال «السبرنت» الحالي أو عند إتاحة الشيفرة في بيئة الإنتاج. بينما تقوم فرق أخرى بتغيير حالة المهمة إلى Resolved فور دمج تغيير في الشيفرة يُكمل المهمة، مع ترك الوسوم وعمود لوحة العمل دون تغيير.

متى يمكنني استخدام الإصلاح

الإجابة المختصرة لمواقع ويكيميديا هي: في غضون فترة تتراوح بين أسبوع وثلاثة أسابيع بعد إغلاق المهمة على أنها Resolved. للحصول على تفاصيل، انظر wikitech:Deployments.