.. _bug_triaging: تصنيف الأخطاء ومعالجة المشكلات =============================== يُعد `متتبع المشكلات `_ مهمًا للتواصل في المشروع: فهو يساعد المطورين على تحديد المشاريع الرئيسية للعمل عليها، بالإضافة إلى مناقشة الأولويات. لهذا السبب، من المهم تنظيمها، وإضافة تسميات للمشكلات وإغلاق المشكلات غير الضرورية. العمل على المشكلات لتحسينها --------------------------------- يؤدي تحسين المشكلات إلى زيادة فرص حلها بنجاح. يمكن العثور على إرشادات حول إرسال مشكلات جيدة :ref:`هنا `. يمكن لطرف ثالث تقديم ملاحظات مفيدة أو حتى إضافة تعليقات على المشكلة. عادةً ما تكون الإجراءات التالية مفيدة: - توثيق المشكلات التي تفتقد إلى عناصر لإعادة إنتاج المشكلة مثل نماذج التعليمات البرمجية - اقتراح استخدام أفضل لتنسيق التعليمات البرمجية - اقتراح إعادة صياغة العنوان والوصف لجعلهما أكثر وضوحًا بشأن المشكلة المراد حلها - ربط المشكلات أو المناقشات ذات الصلة مع وصف موجز لكيفية ارتباطها، على سبيل المثال "انظر أيضًا #xyz لمحاولة مماثلة لهذا" أو "انظر أيضًا #xyz حيث حدث الشيء نفسه في SomeEstimator" يوفر سياقًا ويساعد في المناقشة. .. topic:: مناقشات مثمرة قد تكون المناقشات عبر الإنترنت أصعب مما تبدو للوهلة الأولى، على وجه الخصوص نظرًا لأن الشخص الجديد في المصادر المفتوحة قد يكون لديه فهم مختلف تمامًا للإجراء مقارنةً بمسؤول الصيانة المتمرس. بشكل عام، من المفيد البقاء إيجابيًا وافتراض حسن النية. `المقالة التالية `_ تستكشف كيفية إدارة المناقشات عبر الإنترنت في سياق المصادر المفتوحة. العمل على طلبات السحب للمساعدة في المراجعة ----------------------------------------------- نشجع أيضًا مراجعة التعليمات البرمجية. يُرحَّب بالمساهمين والمستخدمين للمشاركة في عملية المراجعة باتباع :ref:`إرشادات المراجعة الخاصة بنا `. عمليات التنظيم لأعضاء فرق الخبرة الأساسية والمساهمة ------------------------------------------------------ بالإضافة إلى ما سبق، يمكن لأعضاء الفريق الأساسي وفريق تجربة المساهمين القيام بالمهام المهمة التالية: - تحديث :ref:`تسميات المشكلات وطلبات السحب `: انظر قائمة `تسميات github المتاحة `_. - :ref:`تحديد ما إذا كان يجب إعادة تسمية طلب السحب على أنه متوقف ` أو يحتاج إلى مساعدة (عادةً ما يكون هذا مهمًا جدًا في سياق السباقات السريعة، حيث يكون الخطر هو إنشاء العديد من طلبات السحب غير المكتملة) - إذا تم الاستيلاء على طلب سحب متوقف بواسطة طلب سحب أحدث، فقم بتسمية طلب السحب المتوقف باسم "Superseded"، واترك تعليقًا على طلب السحب المتوقف الذي يربط بطلب السحب الجديد، و على الأرجح أغلق طلب السحب المتوقف. - تنظيم المشكلات: - **إغلاق أسئلة الاستخدام** وتوجيه المبلغ بأدب لاستخدام Stack Overflow بدلاً من ذلك. - **إغلاق المشكلات المكررة**، بعد التحقق من أنها مكررة بالفعل. من الناحية المثالية، ينقل المُرسِل الأصلي المناقشة إلى المشكلة الأقدم والمكررة - **إغلاق المشكلات التي لا يمكن تكرارها**، بعد ترك الوقت (على الأقل أسبوع) لإضافة معلومات إضافية :ref:`الردود المحفوظة ` مفيدة لاكتساب الوقت ومع ذلك تكون مرحبة ومهذبة عند التنظيم. انظر وصف github لـ `الأدوار في المنظمة `_. .. topic:: إغلاق المشكلات: قرار صعب عند عدم التأكد مما إذا كان ينبغي إغلاق مشكلة أم لا، فمن الأفضل السعي لتحقيق توافق في الآراء مع الملصق الأصلي، وربما طلب خبرة ذات صلة. ومع ذلك، عندما تكون المشكلة عبارة عن سؤال استخدام، أو عندما تم اعتبارها غير واضحة لسنوات عديدة، فيجب إغلاقها. سير عمل نموذجي لتنظيم المشكلات --------------------------------- سير العمل التالي [1]_ هو طريقة جيدة للتعامل مع تنظيم المشكلات: #. اشكر المُبلِّغ على فتح مشكلة يُعد متتبع المشكلات أول تفاعل للعديد من الأشخاص مع مشروع scikit-learn نفسه، إلى جانب مجرد استخدام المكتبة. على هذا النحو، نريده أن يكون تجربة ممتعة ومرحبة. #. هل هذا سؤال استخدام؟ إذا كان الأمر كذلك، فأغلقه برسالة مهذبة (:ref:`هنا مثال `). #. هل المعلومات اللازمة متوفرة؟ إذا كانت المعلومات المهمة (مثل إصدار scikit-learn المستخدم) مفقودة، فلا تتردد في طلب ذلك وتسمية المشكلة باسم "Needs info". #. هل هذه مشكلة مكررة؟ لدينا العديد من المشكلات المفتوحة. إذا بدت مشكلة جديدة وكأنها مكررة، فأشر إلى المشكلة الأصلية. إذا كانت مكررة واضحة، أو كان هناك إجماع على أنها زائدة عن الحاجة، فأغلقها. تأكد من شكر المُبلِّغ، وشجعه على المشاركة في المشكلة الأصلية، و ربما حاول إصلاحها. إذا كانت المشكلة الجديدة توفر معلومات ذات صلة، مثل مثال أفضل أو مختلف قليلاً، فأضفه إلى المشكلة الأصلية كتعليق أو تعديل على المنشور الأصلي. #. تأكد من أن العنوان يعكس المشكلة بدقة. إذا كانت لديك الأذونات اللازمة، فقم بتحريره بنفسك إذا لم يكن واضحًا. #. هل المشكلة بسيطة وقابلة للتكرار؟ بالنسبة لتقارير الأخطاء، نطلب من المُبلِّغ تقديم مثال بسيط قابل للتكرار. انظر `هذا المنشور المفيد `_ بقلم Matthew Rocklin للحصول على شرح جيد. إذا لم يكن المثال قابلًا للتكرار، أو إذا لم يكن بسيطًا بشكل واضح، فلا تتردد في سؤال المُبلِّغ عما إذا كان بإمكانه تقديم مثال أو تبسيط المثال المقدم. يجب الاعتراف بأن كتابة أمثلة بسيطة قابلة للتكرار عمل شاق. إذا كان المُبلِّغ يواجه صعوبة، يمكنك محاولة كتابة واحدة بنفسك. إذا تم تقديم مثال قابل للتكرار، ولكنك ترى تبسيطًا، فأضف مثال التكرار الأبسط الخاص بك. #. أضف التسميات ذات الصلة، مثل "Documentation" عندما تتعلق المشكلة بالوثائق، و "Bug" إذا كانت خطأً واضحًا، و "Enhancement" إذا كانت طلب تحسين، ... إذا تم تحديد المشكلة بوضوح ويبدو الإصلاح بسيطًا نسبيًا، فسمِّ المشكلة باسم "Good first issue". يمكن أن تكون خطوة مفيدة إضافية هي وضع علامة على الوحدة المقابلة، على سبيل المثال `sklearn.linear_models` عند الصلة. #. قم بإزالة تسمية "Needs Triage" من المشكلة إذا كانت التسمية موجودة. .. [1] مقتبس من `دليل المسؤولين عن مشروع pandas `_